[PATCH 1/2] gpio: gpio-pch.c: changed every 'unsigned' to 'unsigned int'

[Abanoub Sameh]

Changed 'unsigned' to 'unsigned int'.
This makes the code more uniform, and compliant with the kernel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-pch.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
index e96d28bf43b4..71dde7ceb7af 100644
--- a/drivers/gpio/gpio-pch.c
+++ b/drivers/gpio/gpio-pch.c
@@ -95,7 +95,7 @@ struct pch_gpio {
spinlock_t spinlock;
 };
 
-static void pch_gpio_set(struct gpio_chip *gpio, unsigned nr, int val)
+static void pch_gpio_set(struct gpio_chip *gpio, unsigned int nr, int val)
 {
u32 reg_val;
struct pch_gpio *chip = gpiochip_get_data(gpio);
@@ -112,14 +112,14 @@ static void pch_gpio_set(struct gpio_chip *gpio, unsigned 
nr, int val)
spin_unlock_irqrestore(>spinlock, flags);
 }
 
-static int pch_gpio_get(struct gpio_chip *gpio, unsigned nr)
+static int pch_gpio_get(struct gpio_chip *gpio, unsigned int nr)
 {
struct pch_gpio *chip = gpiochip_get_data(gpio);
 
return !!(ioread32(>reg->pi) & BIT(nr));
 }
 
-static int pch_gpio_direction_output(struct gpio_chip *gpio, unsigned nr,
+static int pch_gpio_direction_output(struct gpio_chip *gpio, unsigned int nr,
 int val)
 {
struct pch_gpio *chip = gpiochip_get_data(gpio);
@@ -146,7 +146,7 @@ static int pch_gpio_direction_output(struct gpio_chip 
*gpio, unsigned nr,
return 0;
 }
 
-static int pch_gpio_direction_input(struct gpio_chip *gpio, unsigned nr)
+static int pch_gpio_direction_input(struct gpio_chip *gpio, unsigned int nr)
 {
struct pch_gpio *chip = gpiochip_get_data(gpio);
u32 pm;
@@ -196,7 +196,7 @@ static void __maybe_unused pch_gpio_restore_reg_conf(struct 
pch_gpio *chip)
iowrite32(chip->pch_gpio_reg.gpio_use_sel_reg, 
>reg->gpio_use_sel);
 }
 
-static int pch_gpio_to_irq(struct gpio_chip *gpio, unsigned offset)
+static int pch_gpio_to_irq(struct gpio_chip *gpio, unsigned int offset)
 {
struct pch_gpio *chip = gpiochip_get_data(gpio);
return chip->irq_base + offset;
-- 
2.28.0.rc0

[PATCH 2/4] gpio: gpio-msic.c: fixed style of a block comment

[Abanoub Sameh]

Added asterisk to each line of a block and fixed and moved the ending to
the next line.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-msic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-msic.c b/drivers/gpio/gpio-msic.c
index ea5ff2c84a26..0bef1a5a9b70 100644
--- a/drivers/gpio/gpio-msic.c
+++ b/drivers/gpio/gpio-msic.c
@@ -183,8 +183,9 @@ static void msic_bus_sync_unlock(struct irq_data *data)
u8 trig = 0;
 
/* We can only get one change at a time as the buslock covers the
-  entire transaction. The irq_desc->lock is dropped before we are
-  called but that is fine */
+* entire transaction. The irq_desc->lock is dropped before we are
+* called but that is fine
+*/
if (mg->trig_change_mask) {
offset = __ffs(mg->trig_change_mask);
 
-- 
2.28.0.rc0

Re: [PATCH] LICENSES: Replace HTTP links with HTTPS ones

[Greg KH]

On Mon, Jul 13, 2020 at 10:42:31AM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely or at least not just 
> HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  LICENSES/dual/Apache-2.0 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/LICENSES/dual/Apache-2.0 b/LICENSES/dual/Apache-2.0
> index 6e89ddeab187..fd71308fd2c3 100644
> --- a/LICENSES/dual/Apache-2.0
> +++ b/LICENSES/dual/Apache-2.0
> @@ -15,7 +15,7 @@ Apache License
>  
>  Version 2.0, January 2004
>  
> -http://www.apache.org/licenses/
> +https://www.apache.org/licenses/
>  
>  TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
>  
> -- 
> 2.27.0
> 

You can't change the text of a license that comes from elsewhere.  This
file is fine as-is.

thanks,

greg k-h

[PATCH 1/3] gpio: gpio-intel-mid.c: changed every 'unsigned' to 'unsigned int'

[Abanoub Sameh]

Changed 'unsigned' to 'unsigned int'.
This makes the code more uniform, and compliant with the kernel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-intel-mid.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-intel-mid.c b/drivers/gpio/gpio-intel-mid.c
index 86a10c808ef6..6487acab104c 100644
--- a/drivers/gpio/gpio-intel-mid.c
+++ b/drivers/gpio/gpio-intel-mid.c
@@ -64,27 +64,27 @@ struct intel_mid_gpio {
struct pci_dev  *pdev;
 };
 
-static void __iomem *gpio_reg(struct gpio_chip *chip, unsigned offset,
+static void __iomem *gpio_reg(struct gpio_chip *chip, unsigned int offset,
  enum GPIO_REG reg_type)
 {
struct intel_mid_gpio *priv = gpiochip_get_data(chip);
-   unsigned nreg = chip->ngpio / 32;
+   unsigned int nreg = chip->ngpio / 32;
u8 reg = offset / 32;
 
return priv->reg_base + reg_type * nreg * 4 + reg * 4;
 }
 
-static void __iomem *gpio_reg_2bit(struct gpio_chip *chip, unsigned offset,
+static void __iomem *gpio_reg_2bit(struct gpio_chip *chip, unsigned int offset,
   enum GPIO_REG reg_type)
 {
struct intel_mid_gpio *priv = gpiochip_get_data(chip);
-   unsigned nreg = chip->ngpio / 32;
+   unsigned int nreg = chip->ngpio / 32;
u8 reg = offset / 16;
 
return priv->reg_base + reg_type * nreg * 4 + reg * 4;
 }
 
-static int intel_gpio_request(struct gpio_chip *chip, unsigned offset)
+static int intel_gpio_request(struct gpio_chip *chip, unsigned int offset)
 {
void __iomem *gafr = gpio_reg_2bit(chip, offset, GAFR);
u32 value = readl(gafr);
@@ -97,14 +97,14 @@ static int intel_gpio_request(struct gpio_chip *chip, 
unsigned offset)
return 0;
 }
 
-static int intel_gpio_get(struct gpio_chip *chip, unsigned offset)
+static int intel_gpio_get(struct gpio_chip *chip, unsigned int offset)
 {
void __iomem *gplr = gpio_reg(chip, offset, GPLR);
 
return !!(readl(gplr) & BIT(offset % 32));
 }
 
-static void intel_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+static void intel_gpio_set(struct gpio_chip *chip, unsigned int offset, int 
value)
 {
void __iomem *gpsr, *gpcr;
 
@@ -117,7 +117,7 @@ static void intel_gpio_set(struct gpio_chip *chip, unsigned 
offset, int value)
}
 }
 
-static int intel_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+static int intel_gpio_direction_input(struct gpio_chip *chip, unsigned int 
offset)
 {
struct intel_mid_gpio *priv = gpiochip_get_data(chip);
void __iomem *gpdr = gpio_reg(chip, offset, GPDR);
@@ -140,7 +140,7 @@ static int intel_gpio_direction_input(struct gpio_chip 
*chip, unsigned offset)
 }
 
 static int intel_gpio_direction_output(struct gpio_chip *chip,
-   unsigned offset, int value)
+   unsigned int offset, int value)
 {
struct intel_mid_gpio *priv = gpiochip_get_data(chip);
void __iomem *gpdr = gpio_reg(chip, offset, GPDR);
@@ -163,7 +163,7 @@ static int intel_gpio_direction_output(struct gpio_chip 
*chip,
return 0;
 }
 
-static int intel_mid_irq_type(struct irq_data *d, unsigned type)
+static int intel_mid_irq_type(struct irq_data *d, unsigned int type)
 {
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
struct intel_mid_gpio *priv = gpiochip_get_data(gc);
@@ -297,7 +297,7 @@ static int intel_mid_irq_init_hw(struct gpio_chip *chip)
 {
struct intel_mid_gpio *priv = gpiochip_get_data(chip);
void __iomem *reg;
-   unsigned base;
+   unsigned int base;
 
for (base = 0; base < priv->chip.ngpio; base += 32) {
/* Clear the rising-edge detect register */
-- 
2.28.0.rc0

[PATCH 2/3] gpio: gpio-intel-mid.c: fixed alignment of a block comment

[Abanoub Sameh]

A small to the coding style of a comment to make it compliant with the coding 
style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-intel-mid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-intel-mid.c b/drivers/gpio/gpio-intel-mid.c
index 6487acab104c..a9cef06b813b 100644
--- a/drivers/gpio/gpio-intel-mid.c
+++ b/drivers/gpio/gpio-intel-mid.c
@@ -38,7 +38,7 @@
  * reg_addr = reg_base + GPDR * nreg * 4 + reg * 4;
  *
  * so the bit of reg_addr is to control pin offset's GPDR feature
-*/
+ */
 
 enum GPIO_REG {
GPLR = 0,   /* pin level read-only */
-- 
2.28.0.rc0

[PATCH 2/2] gpio: gpio-ml-ioh.c: fixed a coding style issue

[Abanoub Sameh]

Added a line after a declaration to fix a coding style issue.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-ml-ioh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-ml-ioh.c b/drivers/gpio/gpio-ml-ioh.c
index f1b754b60413..7007621a5b55 100644
--- a/drivers/gpio/gpio-ml-ioh.c
+++ b/drivers/gpio/gpio-ml-ioh.c
@@ -212,6 +212,7 @@ static void ioh_gpio_restore_reg_conf(struct ioh_gpio *chip)
 static int ioh_gpio_to_irq(struct gpio_chip *gpio, unsigned int offset)
 {
struct ioh_gpio *chip = gpiochip_get_data(gpio);
+
return chip->irq_base + offset;
 }
 
-- 
2.28.0.rc0

[PATCH 1/2] gpio: gpio-ml-ioh.c: changed every 'unsigned' to 'unsigned int'

[Abanoub Sameh]

Changed 'unsigned' to 'unsigned int'.
This makes the code more uniform, and compliant with the kernel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-ml-ioh.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-ml-ioh.c b/drivers/gpio/gpio-ml-ioh.c
index 92b6e958cfed..f1b754b60413 100644
--- a/drivers/gpio/gpio-ml-ioh.c
+++ b/drivers/gpio/gpio-ml-ioh.c
@@ -89,7 +89,7 @@ struct ioh_gpio {
 
 static const int num_ports[] = {6, 12, 16, 16, 15, 16, 16, 12};
 
-static void ioh_gpio_set(struct gpio_chip *gpio, unsigned nr, int val)
+static void ioh_gpio_set(struct gpio_chip *gpio, unsigned int nr, int val)
 {
u32 reg_val;
struct ioh_gpio *chip = gpiochip_get_data(gpio);
@@ -106,14 +106,14 @@ static void ioh_gpio_set(struct gpio_chip *gpio, unsigned 
nr, int val)
spin_unlock_irqrestore(>spinlock, flags);
 }
 
-static int ioh_gpio_get(struct gpio_chip *gpio, unsigned nr)
+static int ioh_gpio_get(struct gpio_chip *gpio, unsigned int nr)
 {
struct ioh_gpio *chip = gpiochip_get_data(gpio);
 
return !!(ioread32(>reg->regs[chip->ch].pi) & (1 << nr));
 }
 
-static int ioh_gpio_direction_output(struct gpio_chip *gpio, unsigned nr,
+static int ioh_gpio_direction_output(struct gpio_chip *gpio, unsigned int nr,
 int val)
 {
struct ioh_gpio *chip = gpiochip_get_data(gpio);
@@ -139,7 +139,7 @@ static int ioh_gpio_direction_output(struct gpio_chip 
*gpio, unsigned nr,
return 0;
 }
 
-static int ioh_gpio_direction_input(struct gpio_chip *gpio, unsigned nr)
+static int ioh_gpio_direction_input(struct gpio_chip *gpio, unsigned int nr)
 {
struct ioh_gpio *chip = gpiochip_get_data(gpio);
u32 pm;
@@ -209,7 +209,7 @@ static void ioh_gpio_restore_reg_conf(struct ioh_gpio *chip)
 }
 #endif
 
-static int ioh_gpio_to_irq(struct gpio_chip *gpio, unsigned offset)
+static int ioh_gpio_to_irq(struct gpio_chip *gpio, unsigned int offset)
 {
struct ioh_gpio *chip = gpiochip_get_data(gpio);
return chip->irq_base + offset;
-- 
2.28.0.rc0

[PATCH 3/3] gpio: gpio-intel-mid.c: fixed a coding style issue

[Abanoub Sameh]

Added an empty line after a declaration to fix a coding style issue.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-intel-mid.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-intel-mid.c b/drivers/gpio/gpio-intel-mid.c
index a9cef06b813b..a609964645c1 100644
--- a/drivers/gpio/gpio-intel-mid.c
+++ b/drivers/gpio/gpio-intel-mid.c
@@ -317,6 +317,7 @@ static int intel_mid_irq_init_hw(struct gpio_chip *chip)
 static int __maybe_unused intel_gpio_runtime_idle(struct device *dev)
 {
int err = pm_schedule_suspend(dev, 500);
+
return err ?: -EBUSY;
 }
 
-- 
2.28.0.rc0

Re: [PATCHv3 00/19] perf metric: Add support to reuse metric

[Paul A. Clarke]

On Sun, Jul 19, 2020 at 08:13:01PM +0200, Jiri Olsa wrote:
> hi,
> this patchset is adding the support to reused metric in
> another metric.
> 
> For example, to define IPC by using CPI with change like:
> 
>  {
>  "BriefDescription": "Instructions Per Cycle (per Logical Processor)",
> -"MetricExpr": "INST_RETIRED.ANY / CPU_CLK_UNHALTED.THREAD",
> +"MetricExpr": "1/CPI",
>  "MetricGroup": "TopDownL1",
>  "MetricName": "IPC"
>  },
> 
> I won't be able to find all the possible places we could
> use this at, so I wonder you guys (who was asking for this)
> would try it and come up with comments if there's something
> missing or we could already use it at some places.
> 
> It's based on Arnaldo's tmp.perf/core.
> 
> v3 changes:
>   - added some acks
>   - some patches got merged
>   - added missing zalloc include [John Garry]
>   - added ids array outside the egroup object [Ian]
>   - removed wrong m->has_constraint assignment [Ian]
>   - renamed 'list' to 'metric_list' [Ian]
>   - fixed group metric and added test for it [Paul A. Clarke]
>   - fixed memory leak [Arnaldo]
>   - using lowercase keys for metrics in hashmap, because jevents
> converts metric_expr to lowercase
> 
> Also available in here:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/metric

These changes seem to be mostly working for me.

I attempted to exploit the new capability in the metrics definitions in
tools/perf/pmu-events/arch/powerpc/power9/metrics.json.  Those changes
are included below.

The one problem I found is with the "cpi_breakdown" metric group, as it
no longer works:
```
# perf stat --metrics cpi_breakdown ./command
Cannot find metric or group `cpi_breakdown'
```

"cpi_breakdown" does show up in `perf list --metricgroup`, and all of the
(95!) metrics listed in that group are usable, so it's not obvious whether
my changes have a problem, or merely provoke one.

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
index 80816d6402e9..f8784c608479 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
@@ -60,7 +60,7 @@
 },
 {
 "BriefDescription": "Stalls due to short latency decimal floating 
ops.",
-"MetricExpr": "(PM_CMPLU_STALL_DFU - 
PM_CMPLU_STALL_DFLONG)/PM_RUN_INST_CMPL",
+"MetricExpr": "dfu_stall_cpi - dflong_stall_cpi",
 "MetricGroup": "cpi_breakdown",
 "MetricName": "dfu_other_stall_cpi"
 },
@@ -72,7 +72,7 @@
 },
 {
 "BriefDescription": "Completion stall by Dcache miss which resolved 
off node memory/cache",
-"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS - 
PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM - 
PM_CMPLU_STALL_DMISS_REMOTE)/PM_RUN_INST_CMPL",
+"MetricExpr": "dmiss_non_local_stall_cpi - dmiss_remote_stall_cpi",
 "MetricGroup": "cpi_breakdown",
 "MetricName": "dmiss_distant_stall_cpi"
 },
@@ -90,7 +90,7 @@
 },
 {
 "BriefDescription": "Completion stall due to cache miss that resolves 
in the L2 or L3 without conflict",
-"MetricExpr": "(PM_CMPLU_STALL_DMISS_L2L3 - 
PM_CMPLU_STALL_DMISS_L2L3_CONFLICT)/PM_RUN_INST_CMPL",
+"MetricExpr": "dmiss_l2l3_stall_cpi - dmiss_l2l3_conflict_stall_cpi",
 "MetricGroup": "cpi_breakdown",
 "MetricName": "dmiss_l2l3_noconflict_stall_cpi"
 },
@@ -114,7 +114,7 @@
 },
 {
 "BriefDescription": "Completion stall by Dcache miss which resolved 
outside of local memory",
-"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS - 
PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM)/PM_RUN_INST_CMPL",
+"MetricExpr": "dmiss_l3miss_stall_cpi - dmiss_l21_l31_stall_cpi - 
dmiss_lmem_stall_cpi",
 "MetricGroup": "cpi_breakdown",
 "MetricName": "dmiss_non_local_stall_cpi"
 },
@@ -126,7 +126,7 @@
 },
 {
 "BriefDescription": "Stalls due to short latency double precision 
ops.",
-"MetricExpr": "(PM_CMPLU_STALL_DP - 
PM_CMPLU_STALL_DPLONG)/PM_RUN_INST_CMPL",
+"MetricExpr": "dp_stall_cpi - dplong_stall_cpi",
 "MetricGroup": "cpi_breakdown",
 "MetricName": "dp_other_stall_cpi"
 },
@@ -155,7 +155,7 @@
 "MetricName": "emq_full_stall_cpi"
 },
 {
-"MetricExpr": "(PM_CMPLU_STALL_ERAT_MISS + 
PM_CMPLU_STALL_EMQ_FULL)/PM_RUN_INST_CMPL",
+"MetricExpr": "erat_miss_stall_cpi + emq_full_stall_cpi",
 "MetricGroup": "cpi_breakdown",
 "MetricName": "emq_stall_cpi"
 },
@@ -173,7 +173,7 @@
 },
 {
 "BriefDescription": "Completion stall due to execution units for other 
reasons.",
-"MetricExpr": "(PM_CMPLU_STALL_EXEC_UNIT - PM_CMPLU_STALL_FXU - 
PM_CMPLU_STALL_DP - PM_CMPLU_STALL_DFU - PM_CMPLU_STALL_PM - 
PM_CMPLU_STALL_CRYPTO - PM_CMPLU_STALL_VFXU - 

[PATCH] gpio: gpio-ich.c: changed every 'unsigned' to 'unsigned int'

[Abanoub Sameh]

Changed 'unsigned' to 'unsigned int'.
This makes the code more uniform, and compliant with the kernel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-ich.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpio/gpio-ich.c b/drivers/gpio/gpio-ich.c
index 9960bb8b0f5b..de56c013a658 100644
--- a/drivers/gpio/gpio-ich.c
+++ b/drivers/gpio/gpio-ich.c
@@ -74,8 +74,8 @@ struct ichx_desc {
u32 use_sel_ignore[3];
 
/* Some chipsets have quirks, let these use their own request/get */
-   int (*request)(struct gpio_chip *chip, unsigned offset);
-   int (*get)(struct gpio_chip *chip, unsigned offset);
+   int (*request)(struct gpio_chip *chip, unsigned int offset);
+   int (*get)(struct gpio_chip *chip, unsigned int offset);
 
/*
 * Some chipsets don't let reading output values on GPIO_LVL register
@@ -100,7 +100,7 @@ static int modparam_gpiobase = -1;  /* dynamic */
 module_param_named(gpiobase, modparam_gpiobase, int, 0444);
 MODULE_PARM_DESC(gpiobase, "The GPIO number base. -1 means dynamic, which is 
the default.");
 
-static int ichx_write_bit(int reg, unsigned nr, int val, int verify)
+static int ichx_write_bit(int reg, unsigned int nr, int val, int verify)
 {
unsigned long flags;
u32 data, tmp;
@@ -132,7 +132,7 @@ static int ichx_write_bit(int reg, unsigned nr, int val, 
int verify)
return (verify && data != tmp) ? -EPERM : 0;
 }
 
-static int ichx_read_bit(int reg, unsigned nr)
+static int ichx_read_bit(int reg, unsigned int nr)
 {
unsigned long flags;
u32 data;
@@ -152,12 +152,12 @@ static int ichx_read_bit(int reg, unsigned nr)
return !!(data & BIT(bit));
 }
 
-static bool ichx_gpio_check_available(struct gpio_chip *gpio, unsigned nr)
+static bool ichx_gpio_check_available(struct gpio_chip *gpio, unsigned int nr)
 {
return !!(ichx_priv.use_gpio & BIT(nr / 32));
 }
 
-static int ichx_gpio_get_direction(struct gpio_chip *gpio, unsigned nr)
+static int ichx_gpio_get_direction(struct gpio_chip *gpio, unsigned int nr)
 {
if (ichx_read_bit(GPIO_IO_SEL, nr))
return GPIO_LINE_DIRECTION_IN;
@@ -165,7 +165,7 @@ static int ichx_gpio_get_direction(struct gpio_chip *gpio, 
unsigned nr)
return GPIO_LINE_DIRECTION_OUT;
 }
 
-static int ichx_gpio_direction_input(struct gpio_chip *gpio, unsigned nr)
+static int ichx_gpio_direction_input(struct gpio_chip *gpio, unsigned int nr)
 {
/*
 * Try setting pin as an input and verify it worked since many pins
@@ -174,7 +174,7 @@ static int ichx_gpio_direction_input(struct gpio_chip 
*gpio, unsigned nr)
return ichx_write_bit(GPIO_IO_SEL, nr, 1, 1);
 }
 
-static int ichx_gpio_direction_output(struct gpio_chip *gpio, unsigned nr,
+static int ichx_gpio_direction_output(struct gpio_chip *gpio, unsigned int nr,
int val)
 {
/* Disable blink hardware which is available for GPIOs from 0 to 31. */
@@ -191,12 +191,12 @@ static int ichx_gpio_direction_output(struct gpio_chip 
*gpio, unsigned nr,
return ichx_write_bit(GPIO_IO_SEL, nr, 0, 1);
 }
 
-static int ichx_gpio_get(struct gpio_chip *chip, unsigned nr)
+static int ichx_gpio_get(struct gpio_chip *chip, unsigned int nr)
 {
return ichx_read_bit(GPIO_LVL, nr);
 }
 
-static int ich6_gpio_get(struct gpio_chip *chip, unsigned nr)
+static int ich6_gpio_get(struct gpio_chip *chip, unsigned int nr)
 {
unsigned long flags;
u32 data;
@@ -223,7 +223,7 @@ static int ich6_gpio_get(struct gpio_chip *chip, unsigned 
nr)
}
 }
 
-static int ichx_gpio_request(struct gpio_chip *chip, unsigned nr)
+static int ichx_gpio_request(struct gpio_chip *chip, unsigned int nr)
 {
if (!ichx_gpio_check_available(chip, nr))
return -ENXIO;
@@ -240,7 +240,7 @@ static int ichx_gpio_request(struct gpio_chip *chip, 
unsigned nr)
return ichx_read_bit(GPIO_USE_SEL, nr) ? 0 : -ENODEV;
 }
 
-static int ich6_gpio_request(struct gpio_chip *chip, unsigned nr)
+static int ich6_gpio_request(struct gpio_chip *chip, unsigned int nr)
 {
/*
 * Fixups for bits 16 and 17 are necessary on the Intel ICH6/3100
@@ -254,7 +254,7 @@ static int ich6_gpio_request(struct gpio_chip *chip, 
unsigned nr)
return ichx_gpio_request(chip, nr);
 }
 
-static void ichx_gpio_set(struct gpio_chip *chip, unsigned nr, int val)
+static void ichx_gpio_set(struct gpio_chip *chip, unsigned int nr, int val)
 {
ichx_write_bit(GPIO_LVL, nr, val, 0);
 }
-- 
2.28.0.rc0

[PATCH] gpio: gpio-crystalcove.c: changed every 'unsigned' to 'unsigned int'

[Abanoub Sameh]

Changed 'unsigned' to 'unsigned int'.
This makes the code more uniform, and compliant with the kernel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-crystalcove.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
index 14d1f4c933b6..9391722ec107 100644
--- a/drivers/gpio/gpio-crystalcove.c
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -129,7 +129,7 @@ static void crystalcove_update_irq_ctrl(struct 
crystalcove_gpio *cg, int gpio)
regmap_update_bits(cg->regmap, reg, CTLI_INTCNT_BE, cg->intcnt_value);
 }
 
-static int crystalcove_gpio_dir_in(struct gpio_chip *chip, unsigned gpio)
+static int crystalcove_gpio_dir_in(struct gpio_chip *chip, unsigned int gpio)
 {
struct crystalcove_gpio *cg = gpiochip_get_data(chip);
int reg = to_reg(gpio, CTRL_OUT);
@@ -140,7 +140,7 @@ static int crystalcove_gpio_dir_in(struct gpio_chip *chip, 
unsigned gpio)
return regmap_write(cg->regmap, reg, CTLO_INPUT_SET);
 }
 
-static int crystalcove_gpio_dir_out(struct gpio_chip *chip, unsigned gpio,
+static int crystalcove_gpio_dir_out(struct gpio_chip *chip, unsigned int gpio,
int value)
 {
struct crystalcove_gpio *cg = gpiochip_get_data(chip);
@@ -152,7 +152,7 @@ static int crystalcove_gpio_dir_out(struct gpio_chip *chip, 
unsigned gpio,
return regmap_write(cg->regmap, reg, CTLO_OUTPUT_SET | value);
 }
 
-static int crystalcove_gpio_get(struct gpio_chip *chip, unsigned gpio)
+static int crystalcove_gpio_get(struct gpio_chip *chip, unsigned int gpio)
 {
struct crystalcove_gpio *cg = gpiochip_get_data(chip);
unsigned int val;
@@ -169,7 +169,7 @@ static int crystalcove_gpio_get(struct gpio_chip *chip, 
unsigned gpio)
 }
 
 static void crystalcove_gpio_set(struct gpio_chip *chip,
-unsigned gpio, int value)
+unsigned int gpio, int value)
 {
struct crystalcove_gpio *cg = gpiochip_get_data(chip);
int reg = to_reg(gpio, CTRL_OUT);
@@ -183,7 +183,7 @@ static void crystalcove_gpio_set(struct gpio_chip *chip,
regmap_update_bits(cg->regmap, reg, 1, 0);
 }
 
-static int crystalcove_irq_type(struct irq_data *data, unsigned type)
+static int crystalcove_irq_type(struct irq_data *data, unsigned int type)
 {
struct crystalcove_gpio *cg =
gpiochip_get_data(irq_data_get_irq_chip_data(data));
-- 
2.28.0.rc0

Re: [PATCH 2/2] fpga: dfl: create a dfl bus type to support DFL devices

[Xu Yilun]

On Tue, Jul 21, 2020 at 07:41:27PM +0800, Wu, Hao wrote:
> > > > +}
> > > > +
> > > > +dfl_dev->type = feature_dev_id_type(pdev);
> > > > +dfl_dev->feature_id = (unsigned long long)feature->id;
> > > > +
> > > > +dfl_dev->dev.parent  = >dev;
> > > > +dfl_dev->dev.bus = _bus_type;
> > > > +dfl_dev->dev.release = release_dfl_dev;
> > > > +dev_set_name(_dev->dev, "%s.%d", dev_name(>dev),
> > > > + feature->index);
> > >
> > > Or it's better to have a generic name for the device on the bus.
> >
> > mm.. It is good suggestion, we should have a unified name for dfl
> > devices.
> >
> > How about ("dfl.%d.%d", pdev->id, feature->index)
> 
> It's quite difficult for people to use related information from these magic
> numbers. They are not ids defined in the spec, so just dfl_dev.x with one
> unique id seems to be better. If you really need to expose some id
> information, maybe you can consider adding some standard sysfs entry
> to all dfl_dev, I think that will be easier for users. How do you think?

I'm fine with the dfl_dev.x solution.

> 
> Thanks
> Hao

Re: [PATCH for v5.9] ARM: mach-davinci: Replace HTTP links with HTTPS ones

[Sekhar Nori]

On 7/19/20 3:50 PM, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 

> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index f2e7609e5346..87c517d65f62 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -2,7 +2,7 @@
>  /*
>   * Device Tree for DA850 EVM board
>   *
> - * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
>   */
>  /dts-v1/;
>  #include "da850.dtsi"
> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> index d028d38a44bf..5b0125f1265c 100644
> --- a/arch/arm/mach-davinci/Kconfig
> +++ b/arch/arm/mach-davinci/Kconfig
> @@ -201,7 +201,7 @@ config MACH_MITYOMAPL138
>   help
> Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
> System on Module.  Information on this SoM may be found at
> -   http://www.mitydsp.com
> +   https://www.mitydsp.com
>  
>  config MACH_OMAPL138_HAWKBOARD
>   bool "TI AM1808 / OMAPL-138 Hawkboard platform"
> @@ -209,7 +209,7 @@ config MACH_OMAPL138_HAWKBOARD
>   help
> Say Y here to select the TI AM1808 / OMAPL-138 Hawkboard platform .
> Information of this board may be found at
> -   http://www.hawkboard.org/
> +   https://www.hawkboard.org/

This now redirects to something irrelevant. So, dropped the URL
altogether. Also, we use prefix "ARM: davinci: " in subject line.

I made those changes locally and committed the patch. Will try to send
for v5.9, but its getting quite late.

Thanks,
Sekhar

RE: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu

[Limonciello, Mario]

> -Original Message-
> From: iommu  On Behalf Of Lu
> Baolu
> Sent: Monday, July 20, 2020 7:17 PM
> To: Joerg Roedel
> Cc: Ashok Raj; linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Koba
> Ko; io...@lists.linux-foundation.org
> Subject: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated
> iommu
> 
> The VT-d spec requires (10.4.4 Global Command Register, TE field) that:
> 
> Hardware implementations supporting DMA draining must drain any in-flight
> DMA read/write requests queued within the Root-Complex before completing
> the translation enable command and reflecting the status of the command
> through the TES field in the Global Status register.
> 
> Unfortunately, some integrated graphic devices fail to do so after some
> kind of power state transition. As the result, the system might stuck in
> iommu_disable_translation(), waiting for the completion of TE transition.
> 
> This provides a quirk list for those devices and skips TE disabling if
> the qurik hits.
> 
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=208363
That one is for TGL.

I think you also want to add this one for ICL:
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=206571

> Tested-by: Koba Ko 
> Cc: Ashok Raj 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lu Baolu 
> ---
>  drivers/iommu/intel/dmar.c  |  1 +
>  drivers/iommu/intel/iommu.c | 27 +++
>  include/linux/dmar.h|  1 +
>  include/linux/intel-iommu.h |  2 ++
>  4 files changed, 31 insertions(+)
> 
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
> index 683b812c5c47..16f47041f1bf 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -1102,6 +1102,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
>   }
> 
>   drhd->iommu = iommu;
> + iommu->drhd = drhd;
> 
>   return 0;
> 
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 98390a6d8113..11418b14cc3f 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -356,6 +356,7 @@ static int intel_iommu_strict;
>  static int intel_iommu_superpage = 1;
>  static int iommu_identity_mapping;
>  static int intel_no_bounce;
> +static int iommu_skip_te_disable;
> 
>  #define IDENTMAP_GFX 2
>  #define IDENTMAP_AZALIA  4
> @@ -1633,6 +1634,10 @@ static void iommu_disable_translation(struct
> intel_iommu *iommu)
>   u32 sts;
>   unsigned long flag;
> 
> + if (iommu_skip_te_disable && iommu->drhd->gfx_dedicated &&
> + (cap_read_drain(iommu->cap) || cap_write_drain(iommu->cap)))
> + return;
> +
>   raw_spin_lock_irqsave(>register_lock, flag);
>   iommu->gcmd &= ~DMA_GCMD_TE;
>   writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
> @@ -4043,6 +4048,7 @@ static void __init init_no_remapping_devices(void)
> 
>   /* This IOMMU has *only* gfx devices. Either bypass it or
>  set the gfx_mapped flag, as appropriate */
> + drhd->gfx_dedicated = 1;
>   if (!dmar_map_gfx) {
>   drhd->ignored = 1;
>   for_each_active_dev_scope(drhd->devices,
> @@ -6160,6 +6166,27 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
> 0x0044, quirk_calpella_no_shadow_g
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0062,
> quirk_calpella_no_shadow_gtt);
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x006a,
> quirk_calpella_no_shadow_gtt);
> 
> +static void quirk_igfx_skip_te_disable(struct pci_dev *dev)
> +{
> + unsigned short ver;
> +
> + if (!IS_GFX_DEVICE(dev))
> + return;
> +
> + ver = (dev->device >> 8) & 0xff;
> + if (ver != 0x45 && ver != 0x46 && ver != 0x4c &&
> + ver != 0x4e && ver != 0x8a && ver != 0x98 &&
> + ver != 0x9a)
> + return;
> +
> + if (risky_device(dev))
> + return;
> +
> + pci_info(dev, "Skip IOMMU disabling for graphics\n");
> + iommu_skip_te_disable = 1;
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
> quirk_igfx_skip_te_disable);
> +
>  /* On Tylersburg chipsets, some BIOSes have been known to enable the
> ISOCH DMAR unit for the Azalia sound device, but not give it any
> TLB entries, which causes it to deadlock. Check for that.  We do
> diff --git a/include/linux/dmar.h b/include/linux/dmar.h
> index d7bf029df737..65565820328a 100644
> --- a/include/linux/dmar.h
> +++ b/include/linux/dmar.h
> @@ -48,6 +48,7 @@ struct dmar_drhd_unit {
>   u16 segment;/* PCI domain   */
>   u8  ignored:1;  /* ignore drhd  */
>   u8  include_all:1;
> + u8  gfx_dedicated:1;/* graphic dedicated*/
>   struct intel_iommu *iommu;
>  };
> 
> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index bf6009a344f5..329629e1e9de 100644
> --- a/include/linux/intel-iommu.h
> +++ b/include/linux/intel-iommu.h
> @@ 

Re: PROBLEM: cgroup cost too much memory when transfer small files to tmpfs

[Shakeel Butt]

On Tue, Jul 21, 2020 at 4:20 AM jingrui  wrote:
>
> Cc: Johannes Weiner  ; Michal Hocko ; 
> Vladimir Davydov 
>
> Thanks.
>
> ---
> PROBLEM: cgroup cost too much memory when transfer small files to tmpfs.
>
> keywords: cgroup PERCPU/memory cost too much.
>
> description:
>
> We send small files from node-A to node-B tmpfs /tmp directory using sftp. On
> node-B the systemd configured with pam on like below.
>
> cat /etc/pam.d/password-auth | grep systemd
> -session optional  pam_systemd.so
>
> So when transfer a file, a systemd session is created, that means a cgroup is
> created, then file saved at /tmp will associated with a cgroup object. After
> file transferred, session and cgroup-dir will be removed, but the file in /tmp
> still associated with the cgroup object.

Is there a way for you to re-use the cgroup instead of creating and
deleting cgroup for each individual file transfer session?

> The PERCPU memory in cgroup/css object
> cost a lot(about 0.5MB/per-cgroup-object) on 200/cpus machine.
>
> When lot of small files transferred to tmpfs, the cgroup/css object memory
> cost become huge in this scenes to be used.
>
> systemd related issue: https://github.com/systemd/systemd/issues/16499
>
> kernel version: 4.19+
>
> Problem:
>
> 1. Do we have any idea to descrease cgroup memory cost in this case?
> 2. When user remove cgroup directory, does it possible associated file memory 
> to root cgroup?

No, the memory remains associated with the cgroup and the cgroup
becomes zombie on deletion.

> 3. Can we provide an option that do not associate memory with cgroup in tmpfs?

Only way, if you don't want to disable memcg, is to move the file
receiver process to root cgroup.

[PATCH v2 4/7] usb: bdc: Adb shows offline after resuming from S2

[Al Cooper]

On Android systems, After temporarily putting device to S2 by
short pressing the power button on the remote, the display turns
off. Then press the power button to turn the display back up. Adb
devices would show the devices is offline. It needs a physical
disconnect of the usb cable or power cycle to bring the device
back online. The device is operational otherwise.

The problem is that during S2 resume, the ADB gadget driver could
not link back with the BDC driver because the endpoint flags were
cleared. The fix is to clear the endpoint flags for the disconnect
case only and not for S2 exit.

Signed-off-by: Al Cooper 
---
 drivers/usb/gadget/udc/bdc/bdc_core.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c 
b/drivers/usb/gadget/udc/bdc/bdc_core.c
index b70b438efff4..2c2f7aef7ba7 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -292,9 +292,13 @@ static void bdc_mem_init(struct bdc *bdc, bool reinit)
/* Initialize SRR to 0 */
memset(bdc->srr.sr_bds, 0,
NUM_SR_ENTRIES * sizeof(struct bdc_bd));
-   /* clear ep flags to avoid post disconnect stops/deconfigs */
-   for (i = 1; i < bdc->num_eps; ++i)
-   bdc->bdc_ep_array[i]->flags = 0;
+   /*
+* clear ep flags to avoid post disconnect stops/deconfigs but
+* not during S2 exit
+*/
+   if (!bdc->gadget.speed)
+   for (i = 1; i < bdc->num_eps; ++i)
+   bdc->bdc_ep_array[i]->flags = 0;
} else {
/* One time initiaization only */
/* Enable status report function pointers */
-- 
2.17.1

[PATCH v2 5/7] usb: bdc: driver runs out of buffer descriptors on large ADB transfers

[Al Cooper]

Version v1.0.40 of the Android host ADB software increased maximum
transfer sizes from 256K to 1M. Since the STB ADB gadget driver
requests only 16K at a time, the BDC driver ran out of buffer
descriptors (BDs) if the queuing happens faster than the incoming
16K transfers. This issue is fixed by doubling the number of BDs
that can be queued so that the entire 1M request can be queued
without running out of buffers.

Signed-off-by: Al Cooper 
---
 drivers/usb/gadget/udc/bdc/bdc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc.h b/drivers/usb/gadget/udc/bdc/bdc.h
index 6e1e881dc51e..ac75e25c3b6a 100644
--- a/drivers/usb/gadget/udc/bdc/bdc.h
+++ b/drivers/usb/gadget/udc/bdc/bdc.h
@@ -44,7 +44,7 @@
 #define NUM_SR_ENTRIES 64
 
 /* Num of bds per table */
-#define NUM_BDS_PER_TABLE  32
+#define NUM_BDS_PER_TABLE  64
 
 /* Num of tables in bd list for control,bulk and Int ep */
 #define NUM_TABLES 2
-- 
2.17.1

[PATCH v2 7/7] usb: bdc: Use devm_clk_get_optional()

[Al Cooper]

From: Florian Fainelli 

The BDC clock is optional and we may get an -EPROBE_DEFER error code
which would not be propagated correctly, fix this by using
devm_clk_get_optional().

Signed-off-by: Florian Fainelli 
Signed-off-by: Al Cooper 
---
 drivers/usb/gadget/udc/bdc/bdc_core.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c 
b/drivers/usb/gadget/udc/bdc/bdc_core.c
index c1650247ea39..f6e4026618e8 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -497,11 +497,9 @@ static int bdc_probe(struct platform_device *pdev)
 
dev_dbg(dev, "%s()\n", __func__);
 
-   clk = devm_clk_get(dev, "sw_usbd");
-   if (IS_ERR(clk)) {
-   dev_info(dev, "Clock not found in Device Tree\n");
-   clk = NULL;
-   }
+   clk = devm_clk_get_optional(dev, "sw_usbd");
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
 
ret = clk_prepare_enable(clk);
if (ret) {
-- 
2.17.1

[PATCH v2 6/7] usb: bdc: Halt controller on suspend

[Al Cooper]

From: Danesh Petigara 

GISB bus error kernel panics have been observed during S2 transition
tests on the 7271t platform. The errors are a result of the BDC
interrupt handler trying to access BDC register space after the
system's suspend callbacks have completed.

Adding a suspend hook to the BDC driver that halts the controller before
S2 entry thus preventing unwanted access to the BDC register space during
this transition.

Signed-off-by: Danesh Petigara 
Signed-off-by: Al Cooper 
---
 drivers/usb/gadget/udc/bdc/bdc_core.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c 
b/drivers/usb/gadget/udc/bdc/bdc_core.c
index 2c2f7aef7ba7..c1650247ea39 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -607,9 +607,14 @@ static int bdc_remove(struct platform_device *pdev)
 static int bdc_suspend(struct device *dev)
 {
struct bdc *bdc = dev_get_drvdata(dev);
+   int ret;
 
-   clk_disable_unprepare(bdc->clk);
-   return 0;
+   /* Halt the controller */
+   ret = bdc_stop(bdc);
+   if (!ret)
+   clk_disable_unprepare(bdc->clk);
+
+   return ret;
 }
 
 static int bdc_resume(struct device *dev)
-- 
2.17.1

[PATCH v2 2/7] usb: bdc: Add compatible string for new style USB DT nodes

[Al Cooper]

Add compatible string for some newer boards that only have this
as there match sting. Remove unused compatible string "brcm,bdc-v0.16".

Signed-off-by: Al Cooper 
---
 drivers/usb/gadget/udc/bdc/bdc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c 
b/drivers/usb/gadget/udc/bdc/bdc_core.c
index 02a3a774670b..18d510fc02fb 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -629,7 +629,7 @@ static SIMPLE_DEV_PM_OPS(bdc_pm_ops, bdc_suspend,
bdc_resume);
 
 static const struct of_device_id bdc_of_match[] = {
-   { .compatible = "brcm,bdc-v0.16" },
+   { .compatible = "brcm,bdc-udc-v2" },
{ .compatible = "brcm,bdc" },
{ /* sentinel */ }
 };
-- 
2.17.1

[PATCH v2 1/7] dt-bindings: usb: bdc: Update compatible strings

[Al Cooper]

Remove "brcm,bdc-v0.16" because it was never used on any system.
Add "brcm,bdc-udc-v2" which exists for any STB system with BDC.

Signed-off-by: Al Cooper 
---
 Documentation/devicetree/bindings/usb/brcm,bdc.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/brcm,bdc.txt 
b/Documentation/devicetree/bindings/usb/brcm,bdc.txt
index 63e63af3bf59..c9f52b97cef1 100644
--- a/Documentation/devicetree/bindings/usb/brcm,bdc.txt
+++ b/Documentation/devicetree/bindings/usb/brcm,bdc.txt
@@ -4,7 +4,7 @@ Broadcom USB Device Controller (BDC)
 Required properties:
 
 - compatible: must be one of:
-"brcm,bdc-v0.16"
+"brcm,bdc-udc-v2"
 "brcm,bdc"
 - reg: the base register address and length
 - interrupts: the interrupt line for this controller
@@ -21,7 +21,7 @@ On Broadcom STB platforms, these properties are required:
 Example:
 
 bdc@f0b02000 {
-compatible = "brcm,bdc-v0.16";
+compatible = "brcm,bdc-udc-v2";
 reg = <0xf0b02000 0xfc4>;
 interrupts = <0x0 0x60 0x0>;
 phys = <_0 0x0>;
-- 
2.17.1

[PATCH v2 3/7] bdc: Fix bug causing crash after multiple disconnects

[Al Cooper]

From: Sasi Kumar 

Multiple connects/disconnects can cause a crash on the second
disconnect. The driver had a problem where it would try to send
endpoint commands after it was disconnected which is not allowed
by the hardware. The fix is to only allow the endpoint commands
when the endpoint is connected. This will also fix issues that
showed up when using configfs to create gadgets.

Signed-off-by: Sasi Kumar 
Signed-off-by: Al Cooper 
---
 drivers/usb/gadget/udc/bdc/bdc_core.c |  4 
 drivers/usb/gadget/udc/bdc/bdc_ep.c   | 16 ++--
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c 
b/drivers/usb/gadget/udc/bdc/bdc_core.c
index 18d510fc02fb..b70b438efff4 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -282,6 +282,7 @@ static void bdc_mem_init(struct bdc *bdc, bool reinit)
 * in that case reinit is passed as 1
 */
if (reinit) {
+   int i;
/* Enable interrupts */
temp = bdc_readl(bdc->regs, BDC_BDCSC);
temp |= BDC_GIE;
@@ -291,6 +292,9 @@ static void bdc_mem_init(struct bdc *bdc, bool reinit)
/* Initialize SRR to 0 */
memset(bdc->srr.sr_bds, 0,
NUM_SR_ENTRIES * sizeof(struct bdc_bd));
+   /* clear ep flags to avoid post disconnect stops/deconfigs */
+   for (i = 1; i < bdc->num_eps; ++i)
+   bdc->bdc_ep_array[i]->flags = 0;
} else {
/* One time initiaization only */
/* Enable status report function pointers */
diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c 
b/drivers/usb/gadget/udc/bdc/bdc_ep.c
index d49c6dc1082d..9ddc0b4e92c9 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c
@@ -615,7 +615,6 @@ int bdc_ep_enable(struct bdc_ep *ep)
}
bdc_dbg_bd_list(bdc, ep);
/* only for ep0: config ep is called for ep0 from connect event */
-   ep->flags |= BDC_EP_ENABLED;
if (ep->ep_num == 1)
return ret;
 
@@ -759,10 +758,13 @@ static int ep_dequeue(struct bdc_ep *ep, struct bdc_req 
*req)
__func__, ep->name, start_bdi, end_bdi);
dev_dbg(bdc->dev, "ep_dequeue ep=%p ep->desc=%p\n",
ep, (void *)ep->usb_ep.desc);
-   /* Stop the ep to see where the HW is ? */
-   ret = bdc_stop_ep(bdc, ep->ep_num);
-   /* if there is an issue with stopping ep, then no need to go further */
-   if (ret)
+   /* if still connected, stop the ep to see where the HW is ? */
+   if (!(bdc_readl(bdc->regs, BDC_USPC) & BDC_PST_MASK)) {
+   ret = bdc_stop_ep(bdc, ep->ep_num);
+   /* if there is an issue, then no need to go further */
+   if (ret)
+   return 0;
+   } else
return 0;
 
/*
@@ -1911,7 +1913,9 @@ static int bdc_gadget_ep_disable(struct usb_ep *_ep)
__func__, ep->name, ep->flags);
 
if (!(ep->flags & BDC_EP_ENABLED)) {
-   dev_warn(bdc->dev, "%s is already disabled\n", ep->name);
+   if (bdc->gadget.speed != USB_SPEED_UNKNOWN)
+   dev_warn(bdc->dev, "%s is already disabled\n",
+ep->name);
return 0;
}
spin_lock_irqsave(>lock, flags);
-- 
2.17.1

[PATCH v2 0/7] usb: bdc: Updates and fixes to the USB BDC driver

[Al Cooper]

v2 - Fix Signed-off-by issues, remove internal bug reference.
 Fix binding document to match driver.

Updates and fixes to the Broadcom USB BDC driver.

Al Cooper (4):
  dt-bindings: usb: bdc: Update compatible strings
  usb: bdc: Add compatible string for new style USB DT nodes
  usb: bdc: Adb shows offline after resuming from S2
  usb: bdc: driver runs out of buffer descriptors on large ADB transfers

Danesh Petigara (1):
  usb: bdc: Halt controller on suspend

Florian Fainelli (1):
  usb: bdc: Use devm_clk_get_optional()

Sasi Kumar (1):
  bdc: Fix bug causing crash after multiple disconnects

 .../devicetree/bindings/usb/brcm,bdc.txt  |  4 +--
 drivers/usb/gadget/udc/bdc/bdc.h  |  2 +-
 drivers/usb/gadget/udc/bdc/bdc_core.c | 27 +--
 drivers/usb/gadget/udc/bdc/bdc_ep.c   | 16 ++-
 4 files changed, 32 insertions(+), 17 deletions(-)

-- 
2.17.1

Re: [PATCH v4 0/6] TI K3 DSP remoteproc driver for C66x DSPs

[Suman Anna]

Hi Bjorn,

On 7/17/20 6:47 PM, Suman Anna wrote:

Hi All,

The following is v4 of the K3 DSP remoteproc driver supporting the C66x DSPs
on the TI K3 J721E SoCs. The patches apply cleanly both on v5.8-rc1 as well
as laster commit on the master branch.

This series is largely unchanged, addressing various minor comments from
Mathieu and Rob. The ti,k3-sci-proc bindings patch (patch #3) is the only
patch without an Ack from v3.

Following are the changes in v4:
  - Fixed Rob's review comments on ti,k3-sci-proc.yaml
  - Moved the ti_sci_protocol.h header file from ti_k3_dsp_remoteproc.c
to ti_sci_proc.h
  - Replaced the TI http link with https following similar changes
submitted recently
  - Removed an unnecesary addr check before iounmap

Please see the individual patches for further delta differences.

v3: https://patchwork.kernel.org/cover/11602331/
v2: https://patchwork.kernel.org/cover/11561787/
v1: https://patchwork.kernel.org/cover/11458573/

C71x v3: https://patchwork.kernel.org/cover/11602345/

Hi Bjorn,
This series is ready to be picked up for 5.9 merge window. Please also
pick the C71x v3 series on top of this, there are no pending comments
on that one and is waiting for this series.


Can you pick up both the K3 DSP series for 5.9, the last pending 
dt-bindings patch from this series has also been acked now.


Thanks,
Suman



regards
Suman

Suman Anna (6):
   remoteproc: Introduce rproc_of_parse_firmware() helper
   remoteproc: k3: Add TI-SCI processor control helper functions
   dt-bindings: remoteproc: Add common TI SCI rproc bindings
   dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
   remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPs
   remoteproc: k3-dsp: Add support for L2RAM loading on C66x DSPs

  .../bindings/remoteproc/ti,k3-dsp-rproc.yaml  | 139 
  .../bindings/remoteproc/ti,k3-sci-proc.yaml   |  48 ++
  drivers/remoteproc/Kconfig|  13 +
  drivers/remoteproc/Makefile   |   1 +
  drivers/remoteproc/remoteproc_core.c  |  23 +
  drivers/remoteproc/remoteproc_internal.h  |   2 +
  drivers/remoteproc/ti_k3_dsp_remoteproc.c | 771 ++
  drivers/remoteproc/ti_sci_proc.h  | 104 +++
  8 files changed, 1101 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
  create mode 100644 
Documentation/devicetree/bindings/remoteproc/ti,k3-sci-proc.yaml
  create mode 100644 drivers/remoteproc/ti_k3_dsp_remoteproc.c
  create mode 100644 drivers/remoteproc/ti_sci_proc.h

Re: [PATCH 2/2] fpga: dfl: create a dfl bus type to support DFL devices

[Xu Yilun]

> > +static int dfl_devs_init(struct platform_device *pdev)
> > +{
> > +   struct dfl_feature_platform_data *pdata = dev_get_platdata(>dev);
> > +   struct dfl_feature *feature;
> > +   struct dfl_device *dfl_dev;
> > +
> > +   dfl_fpga_dev_for_each_feature(pdata, feature) {
> > +   if (feature->ioaddr || feature->priv)
> > +   continue;
> > +
> > +   dfl_dev = dfl_dev_add(pdata, feature);
> > +   if (IS_ERR(dfl_dev)) {
> > +   dfl_devs_uinit(pdata);
> > +   return PTR_ERR(dfl_dev);
> What happens to dfl_dev's that were successful. Need a clean up ?

Yes, the already added dfl devices under this pdev will be unregistered
in function dfl_devs_uinit()

> > +   }
> > +
> > +   feature->priv = dfl_dev;
> > +   }
> > +
> > +   return 0;
> > +}

[PATCH net 0/2] qed: suppress irrelevant error messages on HW init

[Alexander Lobakin]

This raises the verbosity level of several error/warning messages on
driver/module initialization, most of which are false-positives, and
the one actively spamming the log for no reason.

Alexander Lobakin (2):
  qed: suppress "don't support RoCE & iWARP" flooding on HW init
  qed: suppress false-positives interrupt error messages on HW init

 drivers/net/ethernet/qlogic/qed/qed_cxt.c |  4 +-
 drivers/net/ethernet/qlogic/qed/qed_dev.c |  2 +-
 drivers/net/ethernet/qlogic/qed/qed_int.c | 50 +--
 drivers/net/ethernet/qlogic/qed/qed_int.h |  4 +-
 4 files changed, 34 insertions(+), 26 deletions(-)

-- 
2.25.1

Re: [PATCH 2/4] printk: store instead of processing cont parts

[Sergey Senozhatsky]

On (20/07/20 11:30), Linus Torvalds wrote:
> > Do I get it right, what you are saying is - when we process a PR_CONT
> > message the cont buffer should already contain previous non-LOG_NEWLINE
> > and non-PR_CONT message, otherwise it's a bug?
> 
> No.
> 
> I'm saying that the code that does PR_CONT should have done *some*
> printing before, otherwise it's at the very least questionable.
> 
> IOW, you can't just randomly start printing with PR_CONT, without
> having established _some_ context for it.

OK, I see. I sort of suspect that we may actually have code that does
just pr_cont() (e.g. what Joe pointed out). It doesn't seem like that
"establish a context" was ever enforced, doing a bunch of pr_cont()
simply works.

[..]
> That said, we have traditionally used not just "current process", but
> also "last irq-level" as the context information, so I do think it
> would be good to continue to do that.

OK, so basically, extending printk_caller_id() so that for IRQ/NMI
we will have more info than just "0x8000 + raw_smp_processor_id()".

-ss

[PATCH net 2/2] qed: suppress false-positives interrupt error messages on HW init

[Alexander Lobakin]

It was found that qed_pglueb_rbc_attn_handler() can produce a lot of
false-positive error detections on driver load/reload (especially after
crashes/recoveries) and spam the kernel log:

[4.958275] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d00ff0
[ 2079.146764] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0
[ 2116.374631] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0
[ 2135.250564] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0
[...]

Reduce the logging level of two false-positive prone error messages from
notice to verbose on initialization (only) to not mix it with real error
attentions while debugging.

Fixes: 666db4862f2d ("qed: Revise load sequence to avoid PCI errors")
Signed-off-by: Alexander Lobakin 
Signed-off-by: Igor Russkikh 
Signed-off-by: Michal Kalderon 
---
 drivers/net/ethernet/qlogic/qed/qed_dev.c |  2 +-
 drivers/net/ethernet/qlogic/qed/qed_int.c | 50 +--
 drivers/net/ethernet/qlogic/qed/qed_int.h |  4 +-
 3 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c 
b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 9c26fde663b3..dbdac983ccde 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -3102,7 +3102,7 @@ int qed_hw_init(struct qed_dev *cdev, struct 
qed_hw_init_params *p_params)
}
 
/* Log and clear previous pglue_b errors if such exist */
-   qed_pglueb_rbc_attn_handler(p_hwfn, p_hwfn->p_main_ptt);
+   qed_pglueb_rbc_attn_handler(p_hwfn, p_hwfn->p_main_ptt, true);
 
/* Enable the PF's internal FID_enable in the PXP */
rc = qed_pglueb_set_pfid_enable(p_hwfn, p_hwfn->p_main_ptt,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_int.c 
b/drivers/net/ethernet/qlogic/qed/qed_int.c
index 7e13a9d9b89c..5eec1fc6229d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_int.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_int.c
@@ -257,9 +257,10 @@ static int qed_grc_attn_cb(struct qed_hwfn *p_hwfn)
 #define PGLUE_ATTENTION_ZLR_VALID  (1 << 25)
 #define PGLUE_ATTENTION_ILT_VALID  (1 << 23)
 
-int qed_pglueb_rbc_attn_handler(struct qed_hwfn *p_hwfn,
-   struct qed_ptt *p_ptt)
+int qed_pglueb_rbc_attn_handler(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+   bool hw_init)
 {
+   char msg[256];
u32 tmp;
 
tmp = qed_rd(p_hwfn, p_ptt, PGLUE_B_REG_TX_ERR_WR_DETAILS2);
@@ -273,22 +274,23 @@ int qed_pglueb_rbc_attn_handler(struct qed_hwfn *p_hwfn,
details = qed_rd(p_hwfn, p_ptt,
 PGLUE_B_REG_TX_ERR_WR_DETAILS);
 
-   DP_NOTICE(p_hwfn,
- "Illegal write by chip to [%08x:%08x] blocked.\n"
- "Details: %08x [PFID %02x, VFID %02x, VF_VALID 
%02x]\n"
- "Details2 %08x [Was_error %02x BME deassert %02x 
FID_enable deassert %02x]\n",
- addr_hi, addr_lo, details,
- (u8)GET_FIELD(details, PGLUE_ATTENTION_DETAILS_PFID),
- (u8)GET_FIELD(details, PGLUE_ATTENTION_DETAILS_VFID),
- GET_FIELD(details,
-   PGLUE_ATTENTION_DETAILS_VF_VALID) ? 1 : 0,
- tmp,
- GET_FIELD(tmp,
-   PGLUE_ATTENTION_DETAILS2_WAS_ERR) ? 1 : 0,
- GET_FIELD(tmp,
-   PGLUE_ATTENTION_DETAILS2_BME) ? 1 : 0,
- GET_FIELD(tmp,
-   PGLUE_ATTENTION_DETAILS2_FID_EN) ? 1 : 0);
+   snprintf(msg, sizeof(msg),
+"Illegal write by chip to [%08x:%08x] blocked.\n"
+"Details: %08x [PFID %02x, VFID %02x, VF_VALID %02x]\n"
+"Details2 %08x [Was_error %02x BME deassert %02x 
FID_enable deassert %02x]",
+addr_hi, addr_lo, details,
+(u8)GET_FIELD(details, PGLUE_ATTENTION_DETAILS_PFID),
+(u8)GET_FIELD(details, PGLUE_ATTENTION_DETAILS_VFID),
+!!GET_FIELD(details, PGLUE_ATTENTION_DETAILS_VF_VALID),
+tmp,
+!!GET_FIELD(tmp, PGLUE_ATTENTION_DETAILS2_WAS_ERR),
+!!GET_FIELD(tmp, PGLUE_ATTENTION_DETAILS2_BME),
+!!GET_FIELD(tmp, PGLUE_ATTENTION_DETAILS2_FID_EN));
+
+   if (hw_init)
+   DP_VERBOSE(p_hwfn, NETIF_MSG_INTR, "%s\n", msg);
+   else
+   DP_NOTICE(p_hwfn, "%s\n", msg);
}
 
tmp = qed_rd(p_hwfn, p_ptt, PGLUE_B_REG_TX_ERR_RD_DETAILS2);
@@ -321,8 +323,14 @@ int qed_pglueb_rbc_attn_handler(struct qed_hwfn *p_hwfn,
}
 
tmp = 

[PATCH net 1/2] qed: suppress "don't support RoCE & iWARP" flooding on HW init

[Alexander Lobakin]

Change the verbosity of the "don't support RoCE & iWARP simultaneously"
warning to debug level to stop flooding on driver/hardware initialization:

[4.783230] qede 01:00.00: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth0]
[4.810020] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only
[4.861186] qede 01:00.01: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth1]
[4.893311] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only
[5.181713] qede a1:00.00: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth2]
[5.224740] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only
[5.276449] qede a1:00.01: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth3]
[5.318671] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only
[5.369548] qede a1:00.02: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth4]
[5.411645] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE & iWARP simultaneously on the same PF. Default to RoCE-only

Fixes: e0a8f9de16fc ("qed: Add iWARP enablement support")
Signed-off-by: Alexander Lobakin 
Signed-off-by: Igor Russkikh 
Signed-off-by: Michal Kalderon 
---
 drivers/net/ethernet/qlogic/qed/qed_cxt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c 
b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index 08ba9d54ab63..d13ec88313c3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -2008,8 +2008,8 @@ static void qed_rdma_set_pf_params(struct qed_hwfn 
*p_hwfn,
enum protocol_type proto;
 
if (p_hwfn->mcp_info->func_info.protocol == QED_PCI_ETH_RDMA) {
-   DP_NOTICE(p_hwfn,
- "Current day drivers don't support RoCE & iWARP 
simultaneously on the same PF. Default to RoCE-only\n");
+   DP_VERBOSE(p_hwfn, QED_MSG_SP,
+  "Current day drivers don't support RoCE & iWARP 
simultaneously on the same PF. Default to RoCE-only\n");
p_hwfn->hw_info.personality = QED_PCI_ETH_ROCE;
}
 
-- 
2.25.1

Re: [PATCH v4 2/6] media: v4l2: Add extended buffer operations

[Helen Koike]

On 7/21/20 11:30 AM, Stanimir Varbanov wrote:
> Hi Helen,
> 
> On 7/21/20 4:54 PM, Helen Koike wrote:
>> Hi,
>>
>> On 7/21/20 8:26 AM, Stanimir Varbanov wrote:
>>>
>>>
>>> On 7/17/20 2:54 PM, Helen Koike wrote:
 From: Hans Verkuil 

 Those extended buffer ops have several purpose:
 1/ Fix y2038 issues by converting the timestamp into an u64 counting
the number of ns elapsed since 1970
 2/ Unify single/multiplanar handling
 3/ Add a new start offset field to each v4l2 plane buffer info struct
to support the case where a single buffer object is storing all
planes data, each one being placed at a different offset

 New hooks are created in v4l2_ioctl_ops so that drivers can start using
 these new objects.

 The core takes care of converting new ioctls requests to old ones
 if the driver does not support the new hooks, and vice versa.

 Note that the timecode field is gone, since there doesn't seem to be
 in-kernel users. We can be added back in the reserved area if needed or
 use the Request API to collect more metadata information from the
 frame.

 Signed-off-by: Hans Verkuil 
 Signed-off-by: Boris Brezillon 
 Signed-off-by: Helen Koike 
 ---
 Changes in v4:
 - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
 making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
 - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
 was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
 I think we can add this later, so I removed it from this RFC to simplify 
 it.
 - Remove num_planes field from struct v4l2_ext_buffer
 - Add flags field to struct v4l2_ext_create_buffers
 - Reformulate struct v4l2_ext_plane
 - Fix some bugs caught by v4l2-compliance
 - Rebased on top of media/master (post 5.8-rc1)

 Changes in v3:
 - Rebased on top of media/master (post 5.4-rc1)

 Changes in v2:
 - Add reserved space to v4l2_ext_buffer so that new fields can be added
   later on
 ---
  drivers/media/v4l2-core/v4l2-dev.c   |  29 ++-
  drivers/media/v4l2-core/v4l2-ioctl.c | 349 +--
  include/media/v4l2-ioctl.h   |  26 ++
  include/uapi/linux/videodev2.h   |  89 +++
  4 files changed, 471 insertions(+), 22 deletions(-)

>>>
>>> 
>>>
 +/**
 + * struct v4l2_ext_plane - extended plane buffer info
 + * @buffer_length:size of the entire buffer in bytes, should fit
 + *@offset + @plane_length
 + * @plane_length: size of the plane in bytes.
 + * @userptr:  when memory is V4L2_MEMORY_USERPTR, a userspace 
 pointer pointing
 + *to this plane.
 + * @dmabuf_fd:when memory is V4L2_MEMORY_DMABUF, a userspace 
 file descriptor
 + *associated with this plane.
 + * @offset:   offset in the memory buffer where the plane 
 starts. If
 + *V4L2_MEMORY_MMAP is used, then it can be a 
 "cookie" that
 + *should be passed to mmap() called on the video 
 node.
 + * @reserved: extra space reserved for future fields, must be 
 set to 0.
 + *
 + *
 + * Buffers consist of one or more planes, e.g. an YCbCr buffer with two 
 planes
 + * can have one plane for Y, and another for interleaved CbCr components.
 + * Each plane can reside in a separate memory buffer, or even in
 + * a completely separate memory node (e.g. in embedded devices).
 + */
 +struct v4l2_ext_plane {
 +  __u32 buffer_length;
 +  __u32 plane_length;
 +  union {
 +  __u64 userptr;
 +  __s32 dmabuf_fd;
 +  } m;
 +  __u32 offset;
 +  __u32 reserved[4];
 +};
 +
  /**
   * struct v4l2_buffer - video buffer info
   * @index:id number of the buffer
 @@ -1055,6 +1086,36 @@ struct v4l2_buffer {
};
  };
  
 +/**
 + * struct v4l2_ext_buffer - extended video buffer info
 + * @index:id number of the buffer
 + * @type: V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT
 + * @flags:buffer informational flags
 + * @field:enum v4l2_field; field order of the image in the buffer
 + * @timestamp:frame timestamp
 + * @sequence: sequence count of this frame
 + * @memory:   enum v4l2_memory; the method, in which the actual video 
 data is
 + *passed
 + * @planes:   per-plane buffer information
 + * @request_fd:   fd of the request that this buffer should use
 + * @reserved: extra space reserved for future fields, must be set to 0
 + *
 + * Contains data exchanged by application and driver using one of 

Re: [PATCH v3 2/3] powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable

[Nicholas Piggin]

Excerpts from Pratik Sampat's message of July 21, 2020 8:29 pm:
> 
> 
> On 20/07/20 5:27 am, Nicholas Piggin wrote:
>> Excerpts from Pratik Rajesh Sampat's message of July 18, 2020 4:53 am:
>>> Replace the variable name from using "pnv_first_spr_loss_level" to
>>> "pnv_first_fullstate_loss_level".
>>>
>>> As pnv_first_spr_loss_level is supposed to be the earliest state that
>>> has OPAL_PM_LOSE_FULL_CONTEXT set, however as shallow states too loose
>>> SPR values, render an incorrect terminology.
>> It also doesn't lose "full" state at this loss level though. From the
>> architecture it could be called "hv state loss level", but in POWER10
>> even that is not strictly true.
>>
> Right. Just discovered that deep stop states won't loose full state
> P10 onwards.
> Would it better if we rename it as "pnv_all_spr_loss_state" instead
> so that it stays generic enough while being semantically coherent?

It doesn't lose all SPRs. It does physically, but for Linux it appears 
at least timebase SPRs are retained and that's mostly how it's 
documented.

Maybe there's no really good name for it, but we do call it "deep" stop 
in other places, you could call it deep_spr_loss maybe. I don't mind too 
much though, whatever Gautham is happy with.

Thanks,
Nick

Re: [PATCH v4 2/6] media: v4l2: Add extended buffer operations

[Helen Koike]

Hello,

On 7/21/20 7:48 AM, Hans Verkuil wrote:
> On 17/07/2020 13:54, Helen Koike wrote:
>> From: Hans Verkuil 
>>
>> Those extended buffer ops have several purpose:
>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting
>>the number of ns elapsed since 1970
>> 2/ Unify single/multiplanar handling
>> 3/ Add a new start offset field to each v4l2 plane buffer info struct
>>to support the case where a single buffer object is storing all
>>planes data, each one being placed at a different offset
>>
>> New hooks are created in v4l2_ioctl_ops so that drivers can start using
>> these new objects.
>>
>> The core takes care of converting new ioctls requests to old ones
>> if the driver does not support the new hooks, and vice versa.
>>
>> Note that the timecode field is gone, since there doesn't seem to be
>> in-kernel users. We can be added back in the reserved area if needed or
>> use the Request API to collect more metadata information from the
>> frame.
>>
>> Signed-off-by: Hans Verkuil 
>> Signed-off-by: Boris Brezillon 
>> Signed-off-by: Helen Koike 
>> ---
>> Changes in v4:
>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
>> I think we can add this later, so I removed it from this RFC to simplify it.
>> - Remove num_planes field from struct v4l2_ext_buffer
>> - Add flags field to struct v4l2_ext_create_buffers
>> - Reformulate struct v4l2_ext_plane
>> - Fix some bugs caught by v4l2-compliance
>> - Rebased on top of media/master (post 5.8-rc1)
>>
>> Changes in v3:
>> - Rebased on top of media/master (post 5.4-rc1)
>>
>> Changes in v2:
>> - Add reserved space to v4l2_ext_buffer so that new fields can be added
>>   later on
>> ---
>>  drivers/media/v4l2-core/v4l2-dev.c   |  29 ++-
>>  drivers/media/v4l2-core/v4l2-ioctl.c | 349 +--
>>  include/media/v4l2-ioctl.h   |  26 ++
>>  include/uapi/linux/videodev2.h   |  89 +++
>>  4 files changed, 471 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
>> b/drivers/media/v4l2-core/v4l2-dev.c
>> index e1829906bc086..cb21ee8eb075c 100644
>> --- a/drivers/media/v4l2-core/v4l2-dev.c
>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
>> @@ -720,15 +720,34 @@ static void determine_valid_ioctls(struct video_device 
>> *vdev)
>>  SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, vidioc_try_fmt_sdr_out);
>>  }
>>  
>> +if (is_vid || is_tch) {
>> +/* ioctls valid for video and touch */
>> +if (ops->vidioc_querybuf || ops->vidioc_ext_querybuf)
>> +set_bit(_IOC_NR(VIDIOC_EXT_QUERYBUF), valid_ioctls);
>> +if (ops->vidioc_qbuf || ops->vidioc_ext_qbuf)
>> +set_bit(_IOC_NR(VIDIOC_EXT_QBUF), valid_ioctls);
>> +if (ops->vidioc_dqbuf || ops->vidioc_ext_dqbuf)
>> +set_bit(_IOC_NR(VIDIOC_EXT_DQBUF), valid_ioctls);
>> +if (ops->vidioc_create_bufs || ops->vidioc_ext_create_bufs)
>> +set_bit(_IOC_NR(VIDIOC_EXT_CREATE_BUFS), valid_ioctls);
>> +if (ops->vidioc_prepare_buf || ops->vidioc_ext_prepare_buf)
>> +set_bit(_IOC_NR(VIDIOC_EXT_PREPARE_BUF), valid_ioctls);
>> +}
>> +
>>  if (is_vid || is_vbi || is_sdr || is_tch || is_meta) {
>>  /* ioctls valid for video, vbi, sdr, touch and metadata */
>>  SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
>> -SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
>> -SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
>>  SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf);
>> -SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
>> -SET_VALID_IOCTL(ops, VIDIOC_CREATE_BUFS, vidioc_create_bufs);
>> -SET_VALID_IOCTL(ops, VIDIOC_PREPARE_BUF, vidioc_prepare_buf);
>> +if (ops->vidioc_querybuf || ops->vidioc_ext_querybuf)
>> +set_bit(_IOC_NR(VIDIOC_QUERYBUF), valid_ioctls);
>> +if (ops->vidioc_qbuf || ops->vidioc_ext_qbuf)
>> +set_bit(_IOC_NR(VIDIOC_QBUF), valid_ioctls);
>> +if (ops->vidioc_dqbuf || ops->vidioc_ext_dqbuf)
>> +set_bit(_IOC_NR(VIDIOC_DQBUF), valid_ioctls);
>> +if (ops->vidioc_create_bufs || ops->vidioc_ext_create_bufs)
>> +set_bit(_IOC_NR(VIDIOC_CREATE_BUFS), valid_ioctls);
>> +if (ops->vidioc_prepare_buf || ops->vidioc_ext_prepare_buf)
>> +set_bit(_IOC_NR(VIDIOC_PREPARE_BUF), valid_ioctls);
>>  SET_VALID_IOCTL(ops, VIDIOC_STREAMON, vidioc_streamon);
>>  SET_VALID_IOCTL(ops, VIDIOC_STREAMOFF, vidioc_streamoff);
>>  }
>> diff --git 

Re: [PATCH v3 0/6] powerpc: queued spinlocks and rwlocks

[Waiman Long]

On 7/21/20 7:08 AM, Nicholas Piggin wrote:

diff --git a/arch/powerpc/include/asm/qspinlock.h 
b/arch/powerpc/include/asm/qspinlock.h
index b752d34517b3..26d8766a1106 100644
--- a/arch/powerpc/include/asm/qspinlock.h
+++ b/arch/powerpc/include/asm/qspinlock.h
@@ -31,16 +31,57 @@ static inline void queued_spin_unlock(struct qspinlock 
*lock)
  
  #else

  extern void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
+extern void queued_spin_lock_slowpath_queue(struct qspinlock *lock);
  #endif
  
  static __always_inline void queued_spin_lock(struct qspinlock *lock)

  {
-   u32 val = 0;
-
-   if (likely(atomic_try_cmpxchg_lock(>val, , _Q_LOCKED_VAL)))
+   atomic_t *a = >val;
+   u32 val;
+
+again:
+   asm volatile(
+"1:\t"   PPC_LWARX(%0,0,%1,1) " # queued_spin_lock  
\n"
+   : "=" (val)
+   : "r" (>counter)
+   : "memory");
+
+   if (likely(val == 0)) {
+   asm_volatile_goto(
+   "  stwcx.  %0,0,%1 \n"
+   "  bne-%l[again]   \n"
+   "\t"  PPC_ACQUIRE_BARRIER "  
\n"
+   :
+   : "r"(_Q_LOCKED_VAL), "r" (>counter)
+   : "cr0", "memory"
+   : again );
return;
-
-   queued_spin_lock_slowpath(lock, val);
+   }
+
+   if (likely(val == _Q_LOCKED_VAL)) {
+   asm_volatile_goto(
+   "  stwcx.  %0,0,%1 \n"
+   "  bne-%l[again]   \n"
+   :
+   : "r"(_Q_LOCKED_VAL | _Q_PENDING_VAL), "r" (>counter)
+   : "cr0", "memory"
+   : again );
+
+   atomic_cond_read_acquire(a, !(VAL & _Q_LOCKED_MASK));
+// clear_pending_set_locked(lock);
+   WRITE_ONCE(lock->locked_pending, _Q_LOCKED_VAL);
+// lockevent_inc(lock_pending);
+   return;
+   }
+
+   if (val == _Q_PENDING_VAL) {
+   int cnt = _Q_PENDING_LOOPS;
+   val = atomic_cond_read_relaxed(a,
+  (VAL != _Q_PENDING_VAL) || 
!cnt--);
+   if (!(val & ~_Q_LOCKED_MASK))
+   goto again;
+}
+   queued_spin_lock_slowpath_queue(lock);
  }
  #define queued_spin_lock queued_spin_lock
  


I am fine with the arch code override some part of the generic code.



diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index b9515fcc9b29..ebcc6f5d99d5 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -287,10 +287,14 @@ static __always_inline u32  __pv_wait_head_or_lock(struct 
qspinlock *lock,
  
  #ifdef CONFIG_PARAVIRT_SPINLOCKS

  #define queued_spin_lock_slowpath native_queued_spin_lock_slowpath
+#define queued_spin_lock_slowpath_queue
native_queued_spin_lock_slowpath_queue
  #endif
  
  #endif /* _GEN_PV_LOCK_SLOWPATH */
  
+void queued_spin_lock_slowpath_queue(struct qspinlock *lock);

+static void __queued_spin_lock_slowpath_queue(struct qspinlock *lock);
+
  /**
   * queued_spin_lock_slowpath - acquire the queued spinlock
   * @lock: Pointer to queued spinlock structure
@@ -314,12 +318,6 @@ static __always_inline u32  __pv_wait_head_or_lock(struct 
qspinlock *lock,
   */
  void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
  {
-   struct mcs_spinlock *prev, *next, *node;
-   u32 old, tail;
-   int idx;
-
-   BUILD_BUG_ON(CONFIG_NR_CPUS >= (1U << _Q_TAIL_CPU_BITS));
-
if (pv_enabled())
goto pv_queue;
  
@@ -397,6 +395,26 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)

  queue:
lockevent_inc(lock_slowpath);
  pv_queue:
+   __queued_spin_lock_slowpath_queue(lock);
+}
+EXPORT_SYMBOL(queued_spin_lock_slowpath);
+
+void queued_spin_lock_slowpath_queue(struct qspinlock *lock)
+{
+   lockevent_inc(lock_slowpath);
+   __queued_spin_lock_slowpath_queue(lock);
+}
+EXPORT_SYMBOL(queued_spin_lock_slowpath_queue);
+
+static void __queued_spin_lock_slowpath_queue(struct qspinlock *lock)
+{
+   struct mcs_spinlock *prev, *next, *node;
+   u32 old, tail;
+   u32 val;
+   int idx;
+
+   BUILD_BUG_ON(CONFIG_NR_CPUS >= (1U << _Q_TAIL_CPU_BITS));
+
node = this_cpu_ptr([0].mcs);
idx = node->count++;
tail = encode_tail(smp_processor_id(), idx);
@@ -559,7 +577,6 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 
val)
 */
__this_cpu_dec(qnodes[0].mcs.count);
  }
-EXPORT_SYMBOL(queued_spin_lock_slowpath);
  
  /*

   * Generate the paravirt code for queued_spin_unlock_slowpath().

I would prefer to extract out the pending bit handling code out into a 
separate helper function which can be overridden by the arch code 
instead of breaking the slowpath 

Re: [PATCH v4 0/6] media: v4l2: Add extended fmt and buffer ioctls

[Hans Verkuil]

On 21/07/2020 16:23, Helen Koike wrote:
> Hi,
> 
> On 7/21/20 7:24 AM, Hans Verkuil wrote:
>> On 17/07/2020 13:54, Helen Koike wrote:
>>> Hi,
>>>
>>> I'm sorry for taking too long to submit v4.
>>>
>>> It is not perfect, not all v4l2-compliance tests passes, but I'd like a 
>>> review,
>>> specially on the API and potential problems, so I can focus on improving 
>>> implementation
>>> and maybe drop the RFC tag for next version.
>>>
>>> Follow below what changed in v4 and some items I'd like to discuss:
>>>
>>>
>>> * Ioctl to replace v4l2_pix_format
>>> -
>>> During last media summit, we agreed to create ioctls that replace the 
>>> v4l2_pix_format
>>> struct and leave the other structs in the v4l2_format union alone.
>>> Thus I refactored the code to receive struct v4l2_ext_pix_format, and I 
>>> renamed the
>>> ioctls, so now we have:
>>>
>>> int ioctl(int fd, VIDIOC_G_EXT_FMT, struct v4l2_ext_pix_format *argp);
>>> int ioctl(int fd, VIDIOC_S_EXT_FMT, struct v4l2_ext_pix_format *argp);
>>> int ioctl(int fd, VIDIOC_TRY_EXT_FMT, struct v4l2_ext_pix_format *argp);
>>>
>>> The only valid types are V4L2_BUF_TYPE_VIDEO_CAPTURE and 
>>> V4L2_BUF_TYPE_VIDEO_OUTPUT,
>>> all the other types are invalid with this API.
>>>
>>>
>>> * Modifiers
>>> -
>>> I understand that unifying DRM and V4L2 pixel formats is not possible, but 
>>> I'd like
>>> to unify the modifiers [1].
>>>
>>> [1] 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h#n290
>>>
>>> Should we use the DRM modifiers directly in the V4L2 API?
>>
>> For now, yes. Most of the modifier work is done in DRM, it is only fairly 
>> recent
>> that the media subsystem starts to have a need for it. So for now just use 
>> the drm
>> header and prefixes.
> 
> ack
> 
>>
>>> Or should we move this header to a common place and change the prefix? 
>>> (which requires
>>> us to sync with DRM community).
>>> Or should we create a v4l2 header, defining V4L2_ prefixed macros mapping 
>>> to DRM_
>>> macros?
>>>
>>> For now, patch 1/6 includes drm/drm_fourcc.h and it is using 
>>> DRM_FORMAT_MOD_*
>>>
>>> As discussed before, It would be nice to have documentation describing DRM 
>>> fourcc
>>> equivalents (I'm not sure if someone started this already), listing the 
>>> number of
>>> planes per format.
>>>
>>> We should also document which pixelformats are valid for the EXT_API, since 
>>> multiplanar
>>> and tile versions like V4L2_PIX_FMT_NV12MT_16X16 (which seems equivalent to
>>> DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, and could have a more generic name) 
>>> should be
>>> replaced by a modifier.
>>>
>>> Regarding flags [2] field in struct v4l2_pix_format_mplane [3]:
>>> The only defined flag is V4L2_PIX_FMT_FLAG_PREMUL_ALPHA, and it is only 
>>> used by vsp1 driver.
>>> Which I believe could be replaced by a modifier, to avoid another field 
>>> that changes
>>> pixel formats, so I removed it from the EXT API (we can always add it back 
>>> later with
>>> the reserved fields).
>>
>> The colorspace series that Dafna is working on will add a 
>> V4L2_PIX_FMT_FLAG_SET_CSC
>> flag, so this flags field will be needed.
> 
> This was because the CSC fields were defined in the API as read only (filled 
> by the driver),
> what if those fields in struct v4l2_ext_pix_format allows user to change the 
> CSC fields,
> and it will just fill the right one if it is not supported (similar to how 
> other fields works
> already).
> Please, let me know if I'm missing something.

Ah, that's true, I forgot about that.

> 
>>
>>>
>>> [2] 
>>> https://linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/v4l/pixfmt-reserved.html#format-flags
>>> [3] 
>>> https://linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/v4l/pixfmt-v4l2-mplane.html?highlight=v4l2_pix_format_mplane#c.v4l2_pix_format_mplane
>>>
>>> We also discussed to add a new ENUM_FMT_EXT ioctl to return all 
>>> pixelformats + modifiers
>>> combinations. I still didn't add it in this version, but I don't think it 
>>> affects
>>> what is in this RFC and it can be added later.
>>>
>>>
>>> * Buffers/Plane offset
>>> -
>>>
>>> My understanding is that inside a memory buffer we can have multiple planes 
>>> in random
>>> offsets.
>>> I was comparing with the DRM API [4], where it can have the same dmabuf for 
>>> multiple
>>> planes in different offsets, and I started to think we could simplify our 
>>> API, so
>>> I took the liberty to do some more changes, please review struct 
>>> v4l2_ext_plane in
>>> this RFC.
>>>
>>> I removed the data_offset, since it is unused (See Laurent's RFC 
>>> repurposing this
>>> field [5]). And comparing to the DRM API, it seems to me we only need a 
>>> single offset
>>> field.
>>>
>>> We could also check about 

Re: [PATCH 3/8] kcsan: Skew delay to be longer for certain access types

[peterz]

On Tue, Jul 21, 2020 at 04:26:54PM +0200, Marco Elver wrote:

> I'll rewrite the commit message:
> 
>   For compound instrumentation and assert accesses, skew the
>   watchpoint delay to be longer if randomized. This is useful to
>   improve race detection for such accesses.
> 
>   For compound accesses we should increase the delay as we've
>   aggregated both read and write instrumentation. By giving up 1
>   call into the runtime, we're less likely to set up a watchpoint
>   and thus less likely to detect a race. We can balance this by
>   increasing the watchpoint delay.

Aah, makes sense now. Thanks!

Re: io_uring vs in_compat_syscall()

[Christoph Hellwig]

On Tue, Jul 21, 2020 at 07:31:02AM -0700, Andy Lutomirski wrote:
> > What do you mean with "properly wired up".  Do you really want to spread
> > ->compat_foo methods everywhere, including read and write?  I found
> > in_compat_syscall() a lot small and easier to maintain than all the
> > separate compat cruft.
> 
> I was imagining using a flag.  Some of the net code uses
> MSG_CMSG_COMPAT for this purpose.

Killing that nightmarish monster is what actually got me into looking
io_uring and starting this thread.

Re: kworker/0:3+pm hogging CPU

[Alan Stern]

On Tue, Jul 21, 2020 at 07:59:17AM +0200, Michal Hocko wrote:
> > Sorry, my mistake.  The module name needs to be "xhci_hcd" with an '_' 
> > character, not a '-' character -- the same as what shows up in the lsmod 
> > output.
> 
> 
> [14766.973734] xhci_hcd :00:14.0: Get port status 2-1 read: 0xe88, 
> return 0x88
> [14766.973738] xhci_hcd :00:14.0: Get port status 2-2 read: 0xe88, 
> return 0x88
> [14766.973742] xhci_hcd :00:14.0: Get port status 2-3 read: 0xe0002a0, 
> return 0x2a0
> [14766.973746] xhci_hcd :00:14.0: Get port status 2-4 read: 0xe0002a0, 
> return 0x2a0
> [14766.973750] xhci_hcd :00:14.0: Get port status 2-5 read: 0xe0002a0, 
> return 0x2a0
> [14766.973754] xhci_hcd :00:14.0: Get port status 2-6 read: 0xe0002a0, 
> return 0x2a0
> [14766.973759] xhci_hcd :00:14.0: Get port status 2-1 read: 0xe88, 
> return 0x88
> [14766.973763] xhci_hcd :00:14.0: Get port status 2-2 read: 0xe88, 
> return 0x88

According to the xHCI specification, those 02a0 values are normal and 
the 0088 values indicate the port is disabled and has an over-current 
condition.  I don't know about the e000 bits in the upper part of the 
word; according to my copy of the spec those bits should be 0.

If your machine has only two physical SuperSpeed (USB-3) ports then 
perhaps the other four ports are internally wired in a way that creates 
a permanent over-current indication.

> [14766.973771] xhci_hcd :00:14.0: set port remote wake mask, actual port 
> 0 status  = 0xe88
> [14766.973780] xhci_hcd :00:14.0: set port remote wake mask, actual port 
> 1 status  = 0xe88
> [14766.973789] xhci_hcd :00:14.0: set port remote wake mask, actual port 
> 2 status  = 0xe0002a0
> [14766.973798] xhci_hcd :00:14.0: set port remote wake mask, actual port 
> 3 status  = 0xe0002a0
> [14766.973807] xhci_hcd :00:14.0: set port remote wake mask, actual port 
> 4 status  = 0xe0002a0
> [14766.973816] xhci_hcd :00:14.0: set port remote wake mask, actual port 
> 5 status  = 0xe0002a0
> [14766.973830] xhci_hcd :00:14.0: Bus suspend bailout, port over-current 
> detected
> 
> Repeating again and again. The last message suggests a HW problem? But
> why does the kernel try the same thing over and over?

Because over-current is supposed to be a transient condition that goes 
away quickly.  It means there's a short circuit or something similar.

> > You could also try collect a usbmon trace from the .../2u file.  It does 
> > seem that bus 2 is where the problem occurs.
> 
> a random sample

...
> 888040808cc0 2551256922 S Ci:2:001:0 s a3 00  0001 0004 4 <
> 888040808cc0 2551256925 C Ci:2:001:0 0 4 = 8800
> 888040808cc0 2551256927 S Ci:2:001:0 s a3 00  0002 0004 4 <
> 888040808cc0 2551256933 S Ci:2:001:0 s a3 00  0003 0004 4 <
> 888040808cc0 2551256936 C Ci:2:001:0 0 4 = a002
> 888040808cc0 2551256942 C Ci:2:001:0 0 4 = a002
...

The usbmon output has a lot of gaps, but here we can see some of the 
port status data contains 0x0088 (four bytes little-endian) and some 
contains 0x02a0 -- the same as what the debugging log says.

So yes, this looks like a hardware design error.  Turning off 
autosuspend by writing to the sysfs power/control file is probably the 
best way to handle the problem.

Alan Stern

Re: [PATCH v0] clk: qcom: gcc: Update disp gpll0 branch for 7180/845

[Dmitry Baryshkov]

On 15/07/2020 09:54, Taniya Das wrote:

The display gpll0 branch clock needs to be always left enabled, thus
move the clock ops to _aon branch ops.


Does this also apply to sm8250/sm8150?


Signed-off-by: Taniya Das 
---
  drivers/clk/qcom/gcc-sc7180.c | 2 +-
  drivers/clk/qcom/gcc-sdm845.c | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/qcom/gcc-sc7180.c b/drivers/clk/qcom/gcc-sc7180.c
index ca4383e..538677b 100644
--- a/drivers/clk/qcom/gcc-sc7180.c
+++ b/drivers/clk/qcom/gcc-sc7180.c
@@ -1061,7 +1061,7 @@ static struct clk_branch gcc_disp_gpll0_clk_src = {
.hw = ,
},
.num_parents = 1,
-   .ops = _branch2_ops,
+   .ops = _branch2_aon_ops,
},
},
  };
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index f6ce888..90f7feb 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -1,6 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0
  /*
- * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2018, 2020, The Linux Foundation. All rights reserved.
   */

  #include 
@@ -1344,7 +1344,7 @@ static struct clk_branch gcc_disp_gpll0_clk_src = {
"gpll0",
},
.num_parents = 1,
-   .ops = _branch2_ops,
+   .ops = _branch2_aon_ops,
},
},
  };
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.




--
With best wishes
Dmitry

Re: [PATCH V6 09/14] perf/x86/intel: Support TopDown metrics on Ice Lake

[peterz]

On Tue, Jul 21, 2020 at 10:23:36AM -0400, Liang, Kan wrote:

> Patch 13 forces the slots event to be part of a metric group. In patch 7,
> for a metric group, we only update the values once with slots event.
> I think the normal case mentioned above should not happen.
> 
> + /* Only need to call update_topdown_event() once for group read. */
> + if ((cpuc->txn_flags & PERF_PMU_TXN_READ) &&
> + !is_slots_event(event))
> + return;
> +
> + perf_pmu_disable(event->pmu);
> + x86_pmu.update_topdown_event(event);
> + perf_pmu_enable(event->pmu);

Ah, I missed that.

That also requires SLOTS to be the leader so that it will be the first
read. Did we enforce that somewhere?

Re: [PATCH v1] mptfusion: use generic power management

[Vaibhav Gupta]

This patch is compile-tested only.

--Vaibhav Gupta

Re: io_uring vs in_compat_syscall()

[Andy Lutomirski]

On Tue, Jul 21, 2020 at 12:07 AM Christoph Hellwig  wrote:
>
> On Mon, Jul 20, 2020 at 10:28:55AM -0700, Andy Lutomirski wrote:
> > > Sure, I'd consider that implementation detail for the actual patch(es)
> > > for this issue.
> >
> > There’s a corner case, though: doesn’t io_uring submission frequently do 
> > the work synchronously in the context of the calling thread?
>
> Yes.
>
> > If so, can a thread do a 64-bit submit with 32-bit work or vice versa?
>
> In theory you could share an fd created in a 32-bit thread to a 64-bit
> thread or vice versa, but I think at that point you absolutely are in
> "you get to keep the pieces" land.

That seems potentially okay as long as these are pieces of userspace
and not pieces of the kernel.  If the kernel freaks out, we have a
problem.

>
> > Sometimes I think that in_compat_syscall() should have a mode in which 
> > calling it warns (e.g. not actually in a syscall when doing things in 
> > io_uring).  And the relevant operations should be properly wired up to 
> > avoid global state like this.
>
> What do you mean with "properly wired up".  Do you really want to spread
> ->compat_foo methods everywhere, including read and write?  I found
> in_compat_syscall() a lot small and easier to maintain than all the
> separate compat cruft.

I was imagining using a flag.  Some of the net code uses
MSG_CMSG_COMPAT for this purpose.

--Andy

[PATCH v1] mptfusion: use generic power management

[Vaibhav Gupta]

Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.

Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the unnecessary load from the driver.
This also avoids the need for the driver to directly call most of the PCI
helper functions and device power state control functions as through
the generic framework, PCI Core takes care of the necessary operations,
and drivers are required to do only device-specific jobs.

Signed-off-by: Vaibhav Gupta 
---
 drivers/message/fusion/mptbase.c  | 36 +++
 drivers/message/fusion/mptbase.h  |  7 +++---
 drivers/message/fusion/mptfc.c|  5 +
 drivers/message/fusion/mptsas.c   |  5 +
 drivers/message/fusion/mptscsih.c | 36 +++
 drivers/message/fusion/mptscsih.h |  7 +++---
 drivers/message/fusion/mptspi.c   | 26 +-
 7 files changed, 53 insertions(+), 69 deletions(-)

diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 5216487db4fb..13a839c855a1 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -2139,23 +2139,19 @@ mpt_detach(struct pci_dev *pdev)
 /**
  * Power Management
  */
-#ifdef CONFIG_PM
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
 /**
  * mpt_suspend - Fusion MPT base driver suspend routine.
- * @pdev: Pointer to pci_dev structure
- * @state: new state to enter
+ * @dev: Pointer to device structure
  */
-int
-mpt_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused
+mpt_suspend(struct device *dev)
 {
-   u32 device_state;
+   struct pci_dev *pdev = to_pci_dev(dev);
MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
 
-   device_state = pci_choose_state(pdev, state);
printk(MYIOC_s_INFO_FMT "pci-suspend: pdev=0x%p, slot=%s, Entering "
-   "operating state [D%d]\n", ioc->name, pdev, pci_name(pdev),
-   device_state);
+   "suspend state\n", ioc->name, pdev, pci_name(pdev));
 
/* put ioc into READY_STATE */
if (SendIocReset(ioc, MPI_FUNCTION_IOC_MESSAGE_UNIT_RESET, CAN_SLEEP)) {
@@ -2174,21 +2170,18 @@ mpt_suspend(struct pci_dev *pdev, pm_message_t state)
if (ioc->msi_enable)
pci_disable_msi(ioc->pcidev);
ioc->pci_irq = -1;
-   pci_save_state(pdev);
-   pci_disable_device(pdev);
-   pci_release_selected_regions(pdev, ioc->bars);
-   pci_set_power_state(pdev, device_state);
return 0;
 }
 
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
 /**
  * mpt_resume - Fusion MPT base driver resume routine.
- * @pdev: Pointer to pci_dev structure
+ * @dev: Pointer to device structure
  */
-int
-mpt_resume(struct pci_dev *pdev)
+static int __maybe_unused
+mpt_resume(struct device *dev)
 {
+   struct pci_dev *pdev = to_pci_dev(dev);
MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
u32 device_state = pdev->current_state;
int recovery_state;
@@ -2198,9 +2191,6 @@ mpt_resume(struct pci_dev *pdev)
"operating state [D%d]\n", ioc->name, pdev, pci_name(pdev),
device_state);
 
-   pci_set_power_state(pdev, PCI_D0);
-   pci_enable_wake(pdev, PCI_D0, 0);
-   pci_restore_state(pdev);
ioc->pcidev = pdev;
err = mpt_mapresources(ioc);
if (err)
@@ -2256,7 +2246,9 @@ mpt_resume(struct pci_dev *pdev)
return 0;
 
 }
-#endif
+
+SIMPLE_DEV_PM_OPS(mpt_pm_ops, mpt_suspend, mpt_resume);
+EXPORT_SYMBOL(mpt_pm_ops);
 
 static int
 mpt_signal_reset(u8 index, MPT_ADAPTER *ioc, int reset_phase)
@@ -8440,10 +8432,6 @@ mpt_iocstatus_info(MPT_ADAPTER *ioc, u32 ioc_status, 
MPT_FRAME_HDR *mf)
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
 EXPORT_SYMBOL(mpt_attach);
 EXPORT_SYMBOL(mpt_detach);
-#ifdef CONFIG_PM
-EXPORT_SYMBOL(mpt_resume);
-EXPORT_SYMBOL(mpt_suspend);
-#endif
 EXPORT_SYMBOL(ioc_list);
 EXPORT_SYMBOL(mpt_register);
 EXPORT_SYMBOL(mpt_deregister);
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index 813d46311f6a..b4ae350acd6c 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -909,10 +909,9 @@ typedef struct _x_config_parms {
  */
 extern int  mpt_attach(struct pci_dev *pdev, const struct pci_device_id 
*id);
 extern void mpt_detach(struct pci_dev *pdev);
-#ifdef CONFIG_PM
-extern int  mpt_suspend(struct pci_dev *pdev, pm_message_t state);
-extern int  mpt_resume(struct pci_dev *pdev);
-#endif
+
+extern const struct dev_pm_ops mpt_pm_ops;
+
 extern u8   mpt_register(MPT_CALLBACK cbfunc, MPT_DRIVER_CLASS dclass,
char *func_name);
 

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

[Nicholas Piggin]

Excerpts from Mathieu Desnoyers's message of July 21, 2020 11:11 pm:
> - On Jul 21, 2020, at 6:04 AM, Nicholas Piggin npig...@gmail.com wrote:
> 
>> Excerpts from Mathieu Desnoyers's message of July 21, 2020 2:46 am:
> [...]
>> 
>> Yeah you're probably right in this case I think. Quite likely most kernel
>> tasks that asynchronously write to user memory would at least have some
>> kind of producer-consumer barriers.
>> 
>> But is that restriction of all async modifications documented and enforced
>> anywhere?
>> 
 How about other memory accesses via kthread_use_mm? Presumably there is
 still ordering requirement there for membarrier,
>>> 
>>> Please provide an example case with memory accesses via kthread_use_mm where
>>> ordering matters to support your concern.
>> 
>> I think the concern Andy raised with io_uring was less a specific
>> problem he saw and more a general concern that we have these memory
>> accesses which are not synchronized with membarrier.
>> 
 so I really think
 it's a fragile interface with no real way for the user to know how
 kernel threads may use its mm for any particular reason, so membarrier
 should synchronize all possible kernel users as well.
>>> 
>>> I strongly doubt so, but perhaps something should be clarified in the
>>> documentation
>>> if you have that feeling.
>> 
>> I'd rather go the other way and say if you have reasoning or numbers for
>> why PF_KTHREAD is an important optimisation above rq->curr == rq->idle
>> then we could think about keeping this subtlety with appropriate
>> documentation added, otherwise we can just kill it and remove all doubt.
>> 
>> That being said, the x86 sync core gap that I imagined could be fixed
>> by changing to rq->curr == rq->idle test does not actually exist because
>> the global membarrier does not have a sync core option. So fixing the
>> exit_lazy_tlb points that this series does *should* fix that. So
>> PF_KTHREAD may be less problematic than I thought from implementation
>> point of view, only semantics.
> 
> Today, the membarrier global expedited command explicitly skips kernel 
> threads,
> but it happens that membarrier private expedited considers those with the
> same mm as target for the IPI.
> 
> So we already implement a semantic which differs between private and global
> expedited membarriers.

Which is not a good thing.

> This can be explained in part by the fact that
> kthread_use_mm was introduced after 4.16, where the most recent membarrier
> commands where introduced. It seems that the effect on membarrier was not
> considered when kthread_use_mm was introduced.

No it was just renamed, it used to be called use_mm and has been in the 
kernel for ~ever.

That you hadn't considered this is actually weight for my point, which 
is that there's so much subtle behaviour that's easy to miss we're 
better off with simpler and fewer special cases until it's proven 
they're needed. Not the other way around.

> 
> Looking at membarrier(2) documentation, it states that IPIs are only sent to
> threads belonging to the same process as the calling thread. If my 
> understanding
> of the notion of process is correct, this should rule out sending the IPI to
> kernel threads, given they are not "part" of the same process, only borrowing
> the mm. But I agree that the distinction is moot, and should be clarified.

It does if you read it in a user-hostile legalistic way. The reality is 
userspace shouldn't and can't know about how the kernel might implement 
functionality.

> Without a clear use-case to justify adding a constraint on membarrier, I am
> tempted to simply clarify documentation of current membarrier commands,
> stating clearly that they are not guaranteed to affect kernel threads. Then,
> if we have a compelling use-case to implement a different behavior which 
> covers
> kthreads, this could be added consistently across membarrier commands with a
> flag (or by adding new commands).
> 
> Does this approach make sense ?

The other position is without a clear use case for PF_KTHREAD, seeing as 
async kernel accesses had not been considered before now, we limit the 
optimision to only skipping the idle thread. I think that makes more 
sense (unless you have a reason for PF_KTHREAD but it doesn't seem like 
there is much of one).

Thanks,
Nick

Re: [PATCH v4 2/6] media: v4l2: Add extended buffer operations

[Stanimir Varbanov]

Hi Helen,

On 7/21/20 4:54 PM, Helen Koike wrote:
> Hi,
> 
> On 7/21/20 8:26 AM, Stanimir Varbanov wrote:
>>
>>
>> On 7/17/20 2:54 PM, Helen Koike wrote:
>>> From: Hans Verkuil 
>>>
>>> Those extended buffer ops have several purpose:
>>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting
>>>the number of ns elapsed since 1970
>>> 2/ Unify single/multiplanar handling
>>> 3/ Add a new start offset field to each v4l2 plane buffer info struct
>>>to support the case where a single buffer object is storing all
>>>planes data, each one being placed at a different offset
>>>
>>> New hooks are created in v4l2_ioctl_ops so that drivers can start using
>>> these new objects.
>>>
>>> The core takes care of converting new ioctls requests to old ones
>>> if the driver does not support the new hooks, and vice versa.
>>>
>>> Note that the timecode field is gone, since there doesn't seem to be
>>> in-kernel users. We can be added back in the reserved area if needed or
>>> use the Request API to collect more metadata information from the
>>> frame.
>>>
>>> Signed-off-by: Hans Verkuil 
>>> Signed-off-by: Boris Brezillon 
>>> Signed-off-by: Helen Koike 
>>> ---
>>> Changes in v4:
>>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
>>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
>>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
>>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
>>> I think we can add this later, so I removed it from this RFC to simplify it.
>>> - Remove num_planes field from struct v4l2_ext_buffer
>>> - Add flags field to struct v4l2_ext_create_buffers
>>> - Reformulate struct v4l2_ext_plane
>>> - Fix some bugs caught by v4l2-compliance
>>> - Rebased on top of media/master (post 5.8-rc1)
>>>
>>> Changes in v3:
>>> - Rebased on top of media/master (post 5.4-rc1)
>>>
>>> Changes in v2:
>>> - Add reserved space to v4l2_ext_buffer so that new fields can be added
>>>   later on
>>> ---
>>>  drivers/media/v4l2-core/v4l2-dev.c   |  29 ++-
>>>  drivers/media/v4l2-core/v4l2-ioctl.c | 349 +--
>>>  include/media/v4l2-ioctl.h   |  26 ++
>>>  include/uapi/linux/videodev2.h   |  89 +++
>>>  4 files changed, 471 insertions(+), 22 deletions(-)
>>>
>>
>> 
>>
>>> +/**
>>> + * struct v4l2_ext_plane - extended plane buffer info
>>> + * @buffer_length: size of the entire buffer in bytes, should fit
>>> + * @offset + @plane_length
>>> + * @plane_length:  size of the plane in bytes.
>>> + * @userptr:   when memory is V4L2_MEMORY_USERPTR, a userspace 
>>> pointer pointing
>>> + * to this plane.
>>> + * @dmabuf_fd: when memory is V4L2_MEMORY_DMABUF, a userspace 
>>> file descriptor
>>> + * associated with this plane.
>>> + * @offset:offset in the memory buffer where the plane 
>>> starts. If
>>> + * V4L2_MEMORY_MMAP is used, then it can be a "cookie" that
>>> + * should be passed to mmap() called on the video node.
>>> + * @reserved:  extra space reserved for future fields, must be 
>>> set to 0.
>>> + *
>>> + *
>>> + * Buffers consist of one or more planes, e.g. an YCbCr buffer with two 
>>> planes
>>> + * can have one plane for Y, and another for interleaved CbCr components.
>>> + * Each plane can reside in a separate memory buffer, or even in
>>> + * a completely separate memory node (e.g. in embedded devices).
>>> + */
>>> +struct v4l2_ext_plane {
>>> +   __u32 buffer_length;
>>> +   __u32 plane_length;
>>> +   union {
>>> +   __u64 userptr;
>>> +   __s32 dmabuf_fd;
>>> +   } m;
>>> +   __u32 offset;
>>> +   __u32 reserved[4];
>>> +};
>>> +
>>>  /**
>>>   * struct v4l2_buffer - video buffer info
>>>   * @index: id number of the buffer
>>> @@ -1055,6 +1086,36 @@ struct v4l2_buffer {
>>> };
>>>  };
>>>  
>>> +/**
>>> + * struct v4l2_ext_buffer - extended video buffer info
>>> + * @index: id number of the buffer
>>> + * @type:  V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT
>>> + * @flags: buffer informational flags
>>> + * @field: enum v4l2_field; field order of the image in the buffer
>>> + * @timestamp: frame timestamp
>>> + * @sequence:  sequence count of this frame
>>> + * @memory:enum v4l2_memory; the method, in which the actual video 
>>> data is
>>> + * passed
>>> + * @planes:per-plane buffer information
>>> + * @request_fd:fd of the request that this buffer should use
>>> + * @reserved:  extra space reserved for future fields, must be set to 0
>>> + *
>>> + * Contains data exchanged by application and driver using one of the 
>>> Streaming
>>> + * I/O methods.
>>> + */
>>> +struct v4l2_ext_buffer {
>>> +   __u32 index;
>>> +   __u32 type;
>>> +   __u32 flags;
>>> +   __u32 field;
>>> +   __u64 timestamp;
>>> +   __u32 sequence;
>>> +   __u32 memory;
>>> +   

Re: [PATCH] sched: Fix race against ptrace_freeze_trace()

[Christian Brauner]

On Tue, Jul 21, 2020 at 02:13:08PM +0200, pet...@infradead.org wrote:
> 
> There is apparently one site that violates the rule that only current
> and ttwu() will modify task->state, namely ptrace_{,un}freeze_traced()
> will change task->state for a remote task.
> 
> Oleg explains:
> 
>   "TASK_TRACED/TASK_STOPPED was always protected by siglock. In
> particular, ttwu(__TASK_TRACED) must be always called with siglock
> held. That is why ptrace_freeze_traced() assumes it can safely do
> s/TASK_TRACED/__TASK_TRACED/ under spin_lock(siglock)."
> 
> This breaks the ordering scheme introduced by commit:
> 
>   dbfb089d360b ("sched: Fix loadavg accounting race")
> 
> Specifically, the reload not matching no longer implies we don't have
> to block.
> 
> Simply things by noting that what we need is a LOAD->STORE ordering
> and this can be provided by a control dependency.
> 
> So replace:
> 
>   prev_state = prev->state;
>   raw_spin_lock(>lock);
>   smp_mb__after_spinlock(); /* SMP-MB */
>   if (... && prev_state && prev_state == prev->state)
>   deactivate_task();
> 
> with:
> 
>   prev_state = prev->state;
>   if (... && prev_state) /* CTRL-DEP */
>   deactivate_task();
> 
> Since that already implies the 'prev->state' load must be complete
> before allowing the 'prev->on_rq = 0' store to become visible.
> 
> Fixes: dbfb089d360b ("sched: Fix loadavg accounting race")
> Reported-by: Jiri Slaby 
> Signed-off-by: Peter Zijlstra (Intel) 
> Tested-by: Paul Gortmaker 
> ---

Thank you. I applied this on top of v5.8-rc6 and re-ran the strace-test
suite successfully. So at least

Tested-by: Christian Brauner 

> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4193,9 +4193,6 @@ static void __sched notrace __schedule(b
>   local_irq_disable();
>   rcu_note_context_switch(preempt);
>  
> - /* See deactivate_task() below. */
> - prev_state = prev->state;
> -
>   /*
>* Make sure that signal_pending_state()->signal_pending() below
>* can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
> @@ -4219,11 +4216,16 @@ static void __sched notrace __schedule(b
>   update_rq_clock(rq);
>  
>   switch_count = >nivcsw;
> +
>   /*
> -  * We must re-load prev->state in case ttwu_remote() changed it
> -  * before we acquired rq->lock.
> +  * We must load prev->state once (task_struct::state is volatile), such
> +  * that:
> +  *
> +  *  - we form a control dependency vs deactivate_task() below.
> +  *  - ptrace_{,un}freeze_traced() can change ->state underneath us.
>*/
> - if (!preempt && prev_state && prev_state == prev->state) {
> + prev_state = prev->state;
> + if (!preempt && prev_state) {
>   if (signal_pending_state(prev_state, prev)) {
>   prev->state = TASK_RUNNING;
>   } else {
> @@ -4237,10 +4239,12 @@ static void __sched notrace __schedule(b
>  
>   /*
>* __schedule() ttwu()
> -  *   prev_state = prev->state;if 
> (READ_ONCE(p->on_rq) && ...)
> -  *   LOCK rq->lock  goto out;
> -  *   smp_mb__after_spinlock();
> smp_acquire__after_ctrl_dep();
> -  *   p->on_rq = 0;p->state = 
> TASK_WAKING;
> +  *   if (prev_state)  if (p->on_rq && ...)
> +  * p->on_rq = 0;goto out;
> +  *
> smp_acquire__after_ctrl_dep();
> +  *p->state = TASK_WAKING
> +  *
> +  * Where __schedule() and ttwu() have matching control 
> dependencies.
>*
>* After this, schedule() must not care about p->state 
> any more.
>*/

Re: [PATCH v3 3/3] media: i2c: imx274: Add IMX274 power on and off sequence

[Sowjanya Komatineni]

On 7/21/20 7:03 AM, Luca Ceresoli wrote:

Hi Sowjanya,

On 20/07/20 19:01, Sowjanya Komatineni wrote:

IMX274 has VANA analog 2.8V supply, VDIG digital core 1.8V supply,
and VDDL digital io 1.2V supply which are optional based on camera
module design.

IMX274 also need external 24Mhz clock and is optional based on
camera module design.

This patch adds support for IMX274 power on and off to enable and
disable these supplies and external clock.

Signed-off-by: Sowjanya Komatineni 
---

In the future please add a log of changes since previous versions here.

As far as the patch is concerned:
Reviewed-by: Luca Ceresoli 

Thanks.


Sure.

Thanks

Sowjanya

Re: [PATCH] docs: core-api/printk-formats.rst: use literal block syntax

[Sergey Senozhatsky]

On (20/07/21 08:24), Jonathan Corbet wrote:
> On Tue, 21 Jul 2020 23:02:46 +0900
> 
> I'm happy either way.  I'll grab it

Please go ahead.

-ss

Re: [PATCH v5 0/6] Add support for GPU DDR BW scaling

[Rob Clark]

On Mon, Jul 20, 2020 at 8:24 PM Viresh Kumar  wrote:
>
> On 20-07-20, 08:03, Rob Clark wrote:
> > On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar  
> > wrote:
> > >
> > > On 15-07-20, 08:36, Rob Clark wrote:
> > > > I can take the first two into msm-next, the 3rd will need to wait
> > > > until dev_pm_opp_set_bw() lands
> > >
> > > You can base that on a8351c12c6c7 in linux-next, I will make sure not to 
> > > rebase
> > > it anymore.
>
> This was 5.8-rc1 + 2 patches for OPP. That's all.
>
> > >
> >
> > I can't really base on something newer than drm-next
>
> But you need the OPP dependency, isn't it ?

With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
tree and merge it via msm-next -> drm-next -> linus

Otherwise I can send a second later pull req that adds the final patch
after has rebased to 5.9-rc1 (by which point the opp next tree will
have presumably been merged

BR,
-R

>
> --
> viresh

Re: [PATCH 3/8] kcsan: Skew delay to be longer for certain access types

[Marco Elver]

On Tue, Jul 21, 2020 at 04:05PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 21, 2020 at 12:30:11PM +0200, Marco Elver wrote:
> > For compound instrumentation and assert accesses, skew the watchpoint
> > delay to be longer. We still shouldn't exceed the maximum delays, but it
> > is safe to skew the delay for these accesses.
> 
> Complete lack of actual justification.. *why* are you doing this, and
> *why* is it safe etc..

CONFIG_KCSAN_UDELAY_{TASK,INTERRUPT} define the upper bound. When
randomized, the delays aggregate around a mean of KCSAN_UDELAY/2. We're
not breaking the promise of not exceeding the max by skewing the delay
if randomized. That's all this was meant to say.

I'll rewrite the commit message:

For compound instrumentation and assert accesses, skew the
watchpoint delay to be longer if randomized. This is useful to
improve race detection for such accesses.

For compound accesses we should increase the delay as we've
aggregated both read and write instrumentation. By giving up 1
call into the runtime, we're less likely to set up a watchpoint
and thus less likely to detect a race. We can balance this by
increasing the watchpoint delay.

For assert accesses, we know these are of increased interest,
and we wish to increase our chances of detecting races for such
checks.

Note that, CONFIG_KCSAN_UDELAY_{TASK,INTERRUPT} define the upper
bound delays. Skewing the delay does not break this promise as
long as the defined upper bounds are still adhered to.

Thanks,
-- Marco

Re: [PATCH V6 07/14] perf/x86/intel: Generic support for hardware TopDown metrics

[peterz]

On Tue, Jul 21, 2020 at 10:05:55AM -0400, Liang, Kan wrote:
> On 7/21/2020 5:43 AM, Peter Zijlstra wrote:
> > @@ -1098,37 +1105,20 @@ static int collect_events(struct cpu_hw_
> > cpuc->pebs_output = is_pebs_pt(leader) + 1;
> > }
> > -   if (x86_pmu.intel_cap.perf_metrics &&
> > -   add_nr_metric_event(cpuc, leader, _count, false))
> > +   if (is_x86_event(leader) && collect_event(cpuc, leader, max_count, n))
> > return -EINVAL;
> > +   n++;
> 
> If a leader is not an x86 event, n will be mistakenly increased.
> But is it possible that a leader is not an x86 event here?

You're right, and yes that can happen, see the move_group=1 case in
sys_perf_event_open().

if (is_x86_event(leader)) {
if (collect_event(cpuc, leader, max_count, n))
return -EINVAL;
n++;
}

it is then..

Re: [PATCH] docs: core-api/printk-formats.rst: use literal block syntax

[Jonathan Corbet]

On Tue, 21 Jul 2020 23:02:46 +0900
Sergey Senozhatsky  wrote:

> Jonathan, will you route it via the Documentation tree or do
> you want it to land in the printk tree?

I'm happy either way.  I'll grab it unless you tell me you'd rather pick
it up.

Thanks,

jon

Re: [PATCH V6 09/14] perf/x86/intel: Support TopDown metrics on Ice Lake

[Liang, Kan]

On 7/21/2020 8:40 AM, Peter Zijlstra wrote:

On Fri, Jul 17, 2020 at 07:05:49AM -0700, kan.li...@linux.intel.com wrote:


+static inline u64 icl_get_metrics_event_value(u64 metric, u64 slots, int idx)
+{
+   u32 val;
+
+   /*
+* The metric is reported as an 8bit integer fraction
+* suming up to 0xff.
+* slots-in-metric = (Metric / 0xff) * slots
+*/
+   val = (metric >> ((idx - INTEL_PMC_IDX_METRIC_BASE) * 8)) & 0xff;
+   return  mul_u64_u32_div(slots, val, 0xff);
+}
+
+static void __icl_update_topdown_event(struct perf_event *event,
+  u64 slots, u64 metrics)
+{
+   int idx = event->hw.idx;
+   u64 delta;
+
+   if (is_metric_idx(idx))
+   delta = icl_get_metrics_event_value(metrics, slots, idx);
+   else
+   delta = slots;
+
+   local64_add(delta, >count);
+}
+
+/*
+ * Update all active Topdown events.
+ *
+ * The PERF_METRICS and Fixed counter 3 are read separately. The values may be
+ * modify by a NMI. PMU has to be disabled before calling this function.
+ */
+static u64 icl_update_topdown_event(struct perf_event *event)
+{
+   struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
+   struct perf_event *other;
+   u64 slots, metrics;
+   int idx;
+
+   /* read Fixed counter 3 */
+   rdpmcl((3 | INTEL_PMC_FIXED_RDPMC_BASE), slots);
+   if (!slots)
+   return 0;
+
+   /* read PERF_METRICS */
+   rdpmcl(INTEL_PMC_FIXED_RDPMC_METRICS, metrics);
+
+   for_each_set_bit(idx, cpuc->active_mask, INTEL_PMC_IDX_TD_BE_BOUND + 1) 
{
+   if (!is_topdown_idx(idx))
+   continue;
+   other = cpuc->events[idx];
+   __icl_update_topdown_event(other, slots, metrics);
+   }
+
+   /*
+* Check and update this event, which may have been cleared
+* in active_mask e.g. x86_pmu_stop()
+*/
+   if (event && !test_bit(event->hw.idx, cpuc->active_mask))
+   __icl_update_topdown_event(event, slots, metrics);
+
+   /*
+* Software is recommended to periodically clear both registers
+* in order to maintain accurate measurements, which is required for
+* certain scenarios that involve sampling metrics at high rates.


I'll maintain that that statement is clear as mud and therefore useless.


+* Software should always write fixed counter 3 before write to
+* PERF_METRICS.
+*/
+   wrmsrl(MSR_CORE_PERF_FIXED_CTR3, 0);
+   wrmsrl(MSR_PERF_METRICS, 0);
+
+   return slots;
+}


So in the normal case, this ends up calling into this function _5_
times, once for each event. Now the first time, it will actually do
something useful, but the other 4 times it's just wasting cycles.

Also, that for_each_set_bit() loop, trying to find the events to
update...

Can't we, instead, make the SLOTS update advance 5 running counters in
cpuc and feed the events off of that?



Patch 13 forces the slots event to be part of a metric group. In patch 
7, for a metric group, we only update the values once with slots event.

I think the normal case mentioned above should not happen.

+   /* Only need to call update_topdown_event() once for group read. */
+   if ((cpuc->txn_flags & PERF_PMU_TXN_READ) &&
+   !is_slots_event(event))
+   return;
+
+   perf_pmu_disable(event->pmu);
+   x86_pmu.update_topdown_event(event);
+   perf_pmu_enable(event->pmu);

Thanks,
Kan

Re: [PATCH v4 0/6] media: v4l2: Add extended fmt and buffer ioctls

[Helen Koike]

Hi,

On 7/21/20 7:24 AM, Hans Verkuil wrote:
> On 17/07/2020 13:54, Helen Koike wrote:
>> Hi,
>>
>> I'm sorry for taking too long to submit v4.
>>
>> It is not perfect, not all v4l2-compliance tests passes, but I'd like a 
>> review,
>> specially on the API and potential problems, so I can focus on improving 
>> implementation
>> and maybe drop the RFC tag for next version.
>>
>> Follow below what changed in v4 and some items I'd like to discuss:
>>
>>
>> * Ioctl to replace v4l2_pix_format
>> -
>> During last media summit, we agreed to create ioctls that replace the 
>> v4l2_pix_format
>> struct and leave the other structs in the v4l2_format union alone.
>> Thus I refactored the code to receive struct v4l2_ext_pix_format, and I 
>> renamed the
>> ioctls, so now we have:
>>
>> int ioctl(int fd, VIDIOC_G_EXT_FMT, struct v4l2_ext_pix_format *argp);
>> int ioctl(int fd, VIDIOC_S_EXT_FMT, struct v4l2_ext_pix_format *argp);
>> int ioctl(int fd, VIDIOC_TRY_EXT_FMT, struct v4l2_ext_pix_format *argp);
>>
>> The only valid types are V4L2_BUF_TYPE_VIDEO_CAPTURE and 
>> V4L2_BUF_TYPE_VIDEO_OUTPUT,
>> all the other types are invalid with this API.
>>
>>
>> * Modifiers
>> -
>> I understand that unifying DRM and V4L2 pixel formats is not possible, but 
>> I'd like
>> to unify the modifiers [1].
>>
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h#n290
>>
>> Should we use the DRM modifiers directly in the V4L2 API?
> 
> For now, yes. Most of the modifier work is done in DRM, it is only fairly 
> recent
> that the media subsystem starts to have a need for it. So for now just use 
> the drm
> header and prefixes.

ack

> 
>> Or should we move this header to a common place and change the prefix? 
>> (which requires
>> us to sync with DRM community).
>> Or should we create a v4l2 header, defining V4L2_ prefixed macros mapping to 
>> DRM_
>> macros?
>>
>> For now, patch 1/6 includes drm/drm_fourcc.h and it is using DRM_FORMAT_MOD_*
>>
>> As discussed before, It would be nice to have documentation describing DRM 
>> fourcc
>> equivalents (I'm not sure if someone started this already), listing the 
>> number of
>> planes per format.
>>
>> We should also document which pixelformats are valid for the EXT_API, since 
>> multiplanar
>> and tile versions like V4L2_PIX_FMT_NV12MT_16X16 (which seems equivalent to
>> DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, and could have a more generic name) 
>> should be
>> replaced by a modifier.
>>
>> Regarding flags [2] field in struct v4l2_pix_format_mplane [3]:
>> The only defined flag is V4L2_PIX_FMT_FLAG_PREMUL_ALPHA, and it is only used 
>> by vsp1 driver.
>> Which I believe could be replaced by a modifier, to avoid another field that 
>> changes
>> pixel formats, so I removed it from the EXT API (we can always add it back 
>> later with
>> the reserved fields).
> 
> The colorspace series that Dafna is working on will add a 
> V4L2_PIX_FMT_FLAG_SET_CSC
> flag, so this flags field will be needed.

This was because the CSC fields were defined in the API as read only (filled by 
the driver),
what if those fields in struct v4l2_ext_pix_format allows user to change the 
CSC fields,
and it will just fill the right one if it is not supported (similar to how 
other fields works
already).
Please, let me know if I'm missing something.

> 
>>
>> [2] 
>> https://linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/v4l/pixfmt-reserved.html#format-flags
>> [3] 
>> https://linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/v4l/pixfmt-v4l2-mplane.html?highlight=v4l2_pix_format_mplane#c.v4l2_pix_format_mplane
>>
>> We also discussed to add a new ENUM_FMT_EXT ioctl to return all pixelformats 
>> + modifiers
>> combinations. I still didn't add it in this version, but I don't think it 
>> affects
>> what is in this RFC and it can be added later.
>>
>>
>> * Buffers/Plane offset
>> -
>>
>> My understanding is that inside a memory buffer we can have multiple planes 
>> in random
>> offsets.
>> I was comparing with the DRM API [4], where it can have the same dmabuf for 
>> multiple
>> planes in different offsets, and I started to think we could simplify our 
>> API, so
>> I took the liberty to do some more changes, please review struct 
>> v4l2_ext_plane in
>> this RFC.
>>
>> I removed the data_offset, since it is unused (See Laurent's RFC repurposing 
>> this
>> field [5]). And comparing to the DRM API, it seems to me we only need a 
>> single offset
>> field.
>>
>> We could also check about overlapping planes in a memory buffer, but this is 
>> complicated
>> if we use the same memory buffer with different v4l2_ext_buffer objects. We 
>> can also leave
>> to the driver to check situations that may cause HW errors.
>>
>> 

Re: [PATCH v15 2/3] drivers: input:keyboard: Add mtk keypad driver

[Andy Shevchenko]

On Tue, Jul 21, 2020 at 3:38 PM Mattijs Korpershoek
 wrote:
> Fengping yu  writes:

> > This adds matrix keypad support for Mediatek SoCs.

...

> > + keypad->regmap = devm_regmap_init_mmio(>dev,
> > +keypad->base,
> > +_regmap_cfg);
> > + if (IS_ERR(keypad->regmap)) {
> > + dev_err(>dev,
> > + "regmap init failed:%ld\n", PTR_ERR(keypad->regmap));
> > + return PTR_ERR(keypad->regmap);
> > + }

Okay, because another comment appeared, I would suggest to switch to
%pe at the same time.

dev_err(>dev,   "regmap init failed: %pe\n", keypad->regmap);

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 4/4] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

[Guenter Roeck]

On Tue, Jul 21, 2020 at 01:29:01PM +0200, Enric Balletbo i Serra wrote:
> Hi Guenter,
> 
> Thank you for work on this. Cc'ing Gwendal as he has a deep knowledge of the 
> EC
> and their errors.
> 
> On 20/7/20 22:22, Guenter Roeck wrote:
> > The EC reports a variety of error codes. Most of those, with the exception
> > of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual
> > error code gets lost. In cros_ec_cmd_xfer_status(), convert all EC errors
> > to Linux error codes to report a more meaningful error to the caller to aid
> > debugging.
> > 
> > Cc: Yu-Hsuan Hsu 
> > Cc: Prashant Malani 
> > Signed-off-by: Guenter Roeck 
> > ---
> > v2: No change
> > 
> > Notes:
> > I would welcome feedback on the error code translations.
> > Can we do better ?
> > 
> > -ENOTSUPP is not a recommended error code, and checkpatch complains
> > about it. It is used in existing code, so I did not change it, but it
> > might be worthwhile exploring if we can find a better error code to
> > report "version not supported". Possible candidates might be EPROTOTYPE,
> > ENOPROTOOPT, EPROTONOSUPPORT, EPFNOSUPPORT, or EAFNOSUPPORT. I don't
> > see a direct match, but NFS reports -EPROTONOSUPPORT for unsupported
> > protocol versions.
> > 
> >  drivers/platform/chrome/cros_ec_proto.c | 37 +++--
> >  1 file changed, 29 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> > b/drivers/platform/chrome/cros_ec_proto.c
> > index 3e745e0fe092..10aa9e483d35 100644
> > --- a/drivers/platform/chrome/cros_ec_proto.c
> > +++ b/drivers/platform/chrome/cros_ec_proto.c
> > @@ -543,6 +543,29 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
> >  }
> >  EXPORT_SYMBOL(cros_ec_cmd_xfer);
> >  
> > +static const int cros_ec_error_map[] = {
> > +   [EC_RES_INVALID_COMMAND] = -EOPNOTSUPP,
> > +   [EC_RES_ERROR] = -EIO,
> 
> nit -EREMOTEIO? To make explicit that the error is "remote" from the host.
> Although -EIO seems to be more generic.
> 
I think using -EREMOTEIO is a good idea; some SPI/I2C controller error
might return -EIO.

> > +   [EC_RES_INVALID_PARAM] = -EINVAL,
> > +   [EC_RES_ACCESS_DENIED] = -EACCES,
> > +   [EC_RES_INVALID_RESPONSE] = -EPROTO,
> > +   [EC_RES_INVALID_VERSION] = -ENOTSUPP,
> 
> +1 for EPROTONOSUPPORT to match with EC_RES_INVALID_VERSION
> 
Ok. I'll do that with a separate patch.

> > +   [EC_RES_INVALID_CHECKSUM] = -EBADMSG,
> > +   [EC_RES_IN_PROGRESS] = -EINPROGRESS,
> > +   [EC_RES_UNAVAILABLE] = -ENODATA,
> > +   [EC_RES_TIMEOUT] = -ETIMEDOUT,
> > +   [EC_RES_OVERFLOW] = -EOVERFLOW,
> > +   [EC_RES_INVALID_HEADER] = -EBADR,
> > +   [EC_RES_REQUEST_TRUNCATED] = -EBADR,
> > +   [EC_RES_RESPONSE_TOO_BIG] = -EFBIG,
> > +   [EC_RES_BUS_ERROR] = -EFAULT,
> > +   [EC_RES_BUSY] = -EBUSY,
> 
> Although the name matches, I'm wondering if we should use -EAGAIN instead as 
> per
> EC documentation:
> 
>   EC_RES_BUSY - Up but too busy. Should retry.
> 
> hmm, however, for the audio codec, for example, this seems to have a slightly
> different meaning and retry is not what we want, so let's do direct 
> translation
> and stay with -EBUSY.
> 
> > +   [EC_RES_INVALID_HEADER_VERSION] = -EBADMSG,

Any idea for EC_RES_INVALID_HEADER_VERSION ? I am not entirely happy
with -EBADMSG: the error is distinctly different to CRC errors.
EPROTONOSUPPORT as well, maybe, or something else ?

Thanks,
Guenter

> > +   [EC_RES_INVALID_HEADER_CRC] = -EBADMSG,
> > +   [EC_RES_INVALID_DATA_CRC] = -EBADMSG,
> > +   [EC_RES_DUP_UNAVAILABLE] = -ENODATA,
> > +};
> > +
> >  /**
> >   * cros_ec_cmd_xfer_status() - Send a command to the ChromeOS EC.
> >   * @ec_dev: EC device.
> > @@ -555,8 +578,7 @@ EXPORT_SYMBOL(cros_ec_cmd_xfer);
> >   *
> >   * Return:
> >   * >=0 - The number of bytes transferred
> > - * -ENOTSUPP - Operation not supported
> > - * -EPROTO - Protocol error
> > + * <0 - Linux error code
> >   */
> >  int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> > struct cros_ec_command *msg)
> > @@ -566,13 +588,12 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device 
> > *ec_dev,
> > ret = cros_ec_cmd_xfer(ec_dev, msg);
> > if (ret < 0) {
> > dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
> > -   } else if (msg->result == EC_RES_INVALID_VERSION) {
> > -   dev_dbg(ec_dev->dev, "Command invalid version (err:%d)\n",
> > -   msg->result);
> > -   return -ENOTSUPP;
> > } else if (msg->result != EC_RES_SUCCESS) {
> > -   dev_dbg(ec_dev->dev, "Command result (err: %d)\n", msg->result);
> > -   return -EPROTO;
> > +   if (msg->result < ARRAY_SIZE(cros_ec_error_map) && 
> > cros_ec_error_map[msg->result])
> > +   ret = cros_ec_error_map[msg->result];
> > +   else
> > +   ret = -EPROTO;
> > +   dev_dbg(ec_dev->dev, "Command result (err: %d [%d])\n", 
> > msg->result, 

Re: [PATCH 4/8] kcsan: Add missing CONFIG_KCSAN_IGNORE_ATOMICS checks

[Marco Elver]

On Tue, 21 Jul 2020 at 16:09, Peter Zijlstra  wrote:
>
> On Tue, Jul 21, 2020 at 12:30:12PM +0200, Marco Elver wrote:
> > Add missing CONFIG_KCSAN_IGNORE_ATOMICS checks for the builtin atomics
> > instrumentation.
> >
> > Signed-off-by: Marco Elver 
> > ---
> > Added to this series, as it would otherwise cause patch conflicts.
> > ---
> >  kernel/kcsan/core.c | 25 +
> >  1 file changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
> > index 4633baebf84e..f53524ea0292 100644
> > --- a/kernel/kcsan/core.c
> > +++ b/kernel/kcsan/core.c
> > @@ -892,14 +892,17 @@ EXPORT_SYMBOL(__tsan_init);
> >   u##bits __tsan_atomic##bits##_load(const u##bits *ptr, int memorder); 
> >  \
> >   u##bits __tsan_atomic##bits##_load(const u##bits *ptr, int memorder)  
> >  \
> >   { 
> >  \
> > - check_access(ptr, bits / BITS_PER_BYTE, KCSAN_ACCESS_ATOMIC); 
> >  \
> > + if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS)) 
> >  \
> > + check_access(ptr, bits / BITS_PER_BYTE, 
> > KCSAN_ACCESS_ATOMIC);  \
> >   return __atomic_load_n(ptr, memorder);
> >  \
> >   } 
> >  \
> >   EXPORT_SYMBOL(__tsan_atomic##bits##_load);
> >  \
> >   void __tsan_atomic##bits##_store(u##bits *ptr, u##bits v, int 
> > memorder);   \
> >   void __tsan_atomic##bits##_store(u##bits *ptr, u##bits v, int 
> > memorder)\
> >   { 
> >  \
> > - check_access(ptr, bits / BITS_PER_BYTE, KCSAN_ACCESS_WRITE | 
> > KCSAN_ACCESS_ATOMIC); \
> > + if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS)) 
> >  \
> > + check_access(ptr, bits / BITS_PER_BYTE,   
> >  \
> > +  KCSAN_ACCESS_WRITE | 
> > KCSAN_ACCESS_ATOMIC);\
> >   __atomic_store_n(ptr, v, memorder);   
> >  \
> >   } 
> >  \
> >   EXPORT_SYMBOL(__tsan_atomic##bits##_store)
> > @@ -908,8 +911,10 @@ EXPORT_SYMBOL(__tsan_init);
> >   u##bits __tsan_atomic##bits##_##op(u##bits *ptr, u##bits v, int 
> > memorder); \
> >   u##bits __tsan_atomic##bits##_##op(u##bits *ptr, u##bits v, int 
> > memorder)  \
> >   { 
> >  \
> > - check_access(ptr, bits / BITS_PER_BYTE,   
> >  \
> > -  KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE | 
> > KCSAN_ACCESS_ATOMIC);\
> > + if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS)) 
> >  \
> > + check_access(ptr, bits / BITS_PER_BYTE,   
> >  \
> > +  KCSAN_ACCESS_COMPOUND | 
> > KCSAN_ACCESS_WRITE |  \
> > +  KCSAN_ACCESS_ATOMIC);
> >  \
> >   return __atomic_##op##suffix(ptr, v, memorder);   
> >  \
> >   } 
> >  \
> >   EXPORT_SYMBOL(__tsan_atomic##bits##_##op)
> > @@ -937,8 +942,10 @@ EXPORT_SYMBOL(__tsan_init);
> >   int __tsan_atomic##bits##_compare_exchange_##strength(u##bits *ptr, 
> > u##bits *exp,  \
> > u##bits val, 
> > int mo, int fail_mo)\
> >   { 
> >  \
> > - check_access(ptr, bits / BITS_PER_BYTE,   
> >  \
> > -  KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE | 
> > KCSAN_ACCESS_ATOMIC);\
> > + if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS)) 
> >  \
> > + check_access(ptr, bits / BITS_PER_BYTE,   
> >  \
> > +  KCSAN_ACCESS_COMPOUND | 
> > KCSAN_ACCESS_WRITE |  \
> > +  KCSAN_ACCESS_ATOMIC);
> >  \
> > 

Re: [PATCH v7 2/5] drm/imx: Add initial support for DCSS on iMX8MQ

[Laurentiu Palcu]

Hi Philipp,

On Tue, Jul 21, 2020 at 02:43:28PM +0200, Philipp Zabel wrote:
> Hi Laurentiu,
> 
> On Tue, 2020-07-21 at 13:20 +0300, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu 
> > 
> > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> > Some of its capabilities include:
> >  * 4K@60fps;
> >  * HDR10;
> >  * one graphics and 2 video pipelines;
> >  * on-the-fly decompression of compressed video and graphics;
> > 
> > The reference manual can be found here:
> > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM
> > 
> > The current patch adds only basic functionality: one primary plane for
> > graphics, linear, tiled and super-tiled buffers support (no graphics
> > decompression yet), no HDR10 and no video planes.
> > 
> > Video planes support and HDR10 will be added in subsequent patches once
> > per-plane de-gamma/CSC/gamma support is in.
> > 
> > Signed-off-by: Laurentiu Palcu 
> > Reviewed-by: Lucas Stach 
> > ---
> >  drivers/gpu/drm/imx/Kconfig|   2 +
> >  drivers/gpu/drm/imx/Makefile   |   1 +
> >  drivers/gpu/drm/imx/dcss/Kconfig   |   9 +
> >  drivers/gpu/drm/imx/dcss/Makefile  |   6 +
> >  drivers/gpu/drm/imx/dcss/dcss-blkctl.c |  70 +++
> >  drivers/gpu/drm/imx/dcss/dcss-crtc.c   | 219 +++
> >  drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 424 +
> >  drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++
> >  drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++
> >  drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 +
> >  drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 +
> >  drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 
> >  drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++
> >  drivers/gpu/drm/imx/dcss/dcss-kms.h|  43 ++
> >  drivers/gpu/drm/imx/dcss/dcss-plane.c  | 405 
> >  drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 +
> >  drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++
> >  17 files changed, 3962 insertions(+)
> >  create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
> >  create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c
> > 
> > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> > index 207bf7409dfb..6231048aa5aa 100644
> > --- a/drivers/gpu/drm/imx/Kconfig
> > +++ b/drivers/gpu/drm/imx/Kconfig
> > @@ -39,3 +39,5 @@ config DRM_IMX_HDMI
> > depends on DRM_IMX
> > help
> >   Choose this if you want to use HDMI on i.MX6.
> > +
> > +source "drivers/gpu/drm/imx/dcss/Kconfig"
> > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> > index 21cdcc2faabc..b644deffe948 100644
> > --- a/drivers/gpu/drm/imx/Makefile
> > +++ b/drivers/gpu/drm/imx/Makefile
> > @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
> >  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
> >  
> >  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> > +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
> > diff --git a/drivers/gpu/drm/imx/dcss/Kconfig 
> > b/drivers/gpu/drm/imx/dcss/Kconfig
> > new file mode 100644
> > index ..988979bc22cc
> > --- /dev/null
> > +++ b/drivers/gpu/drm/imx/dcss/Kconfig
> > @@ -0,0 +1,9 @@
> > +config DRM_IMX_DCSS
> > +   tristate "i.MX8MQ DCSS"
> > +   select RESET_CONTROLLER
> 
> Why does DCSS select RESET_CONTROLLER?

Why indeed? Apparently, for no reason at all... :/ I must've used SRC at
some point, at the very beginning, though I don't even remember using
it... Hmm, weird. I'll remove it. Thanks for spotting it.

Thanks,
Laurentiu

> 
> regards
> Philipp

Re: [PATCH 8/8] locking/atomics: Use read-write instrumentation for atomic RMWs

[Peter Zijlstra]

On Tue, Jul 21, 2020 at 12:30:16PM +0200, Marco Elver wrote:

> diff --git a/scripts/atomic/gen-atomic-instrumented.sh 
> b/scripts/atomic/gen-atomic-instrumented.sh
> index 6afadf73da17..5cdcce703660 100755
> --- a/scripts/atomic/gen-atomic-instrumented.sh
> +++ b/scripts/atomic/gen-atomic-instrumented.sh
> @@ -5,9 +5,10 @@ ATOMICDIR=$(dirname $0)
>  
>  . ${ATOMICDIR}/atomic-tbl.sh
>  
> -#gen_param_check(arg)
> +#gen_param_check(meta, arg)
>  gen_param_check()
>  {
> + local meta="$1"; shift
>   local arg="$1"; shift
>   local type="${arg%%:*}"
>   local name="$(gen_param_name "${arg}")"
> @@ -17,17 +18,24 @@ gen_param_check()
>   i) return;;
>   esac
>  
> - # We don't write to constant parameters
> - [ ${type#c} != ${type} ] && rw="read"
> + if [ ${type#c} != ${type} ]; then
> + # We don't write to constant parameters
> + rw="read"
> + elif [ "${meta}" != "s" ]; then
> + # Atomic RMW
> + rw="read_write"
> + fi

If we have meta, should we then not be consistent and use it for read
too? Mark?

>  
>   printf "\tinstrument_atomic_${rw}(${name}, sizeof(*${name}));\n"
>  }
>  
> -#gen_param_check(arg...)
> +#gen_params_checks(meta, arg...)
>  gen_params_checks()
>  {
> + local meta="$1"; shift
> +
>   while [ "$#" -gt 0 ]; do
> - gen_param_check "$1"
> + gen_param_check "$meta" "$1"
>   shift;
>   done
>  }
> @@ -77,7 +85,7 @@ gen_proto_order_variant()
>  
>   local ret="$(gen_ret_type "${meta}" "${int}")"
>   local params="$(gen_params "${int}" "${atomic}" "$@")"
> - local checks="$(gen_params_checks "$@")"
> + local checks="$(gen_params_checks "${meta}" "$@")"
>   local args="$(gen_args "$@")"
>   local retstmt="$(gen_ret_stmt "${meta}")"
>  
> -- 
> 2.28.0.rc0.105.gf9edc3c819-goog
> 

Re: [PATCH v3] pinctrl: core: print gpio in pins debugfs file

[Andy Shevchenko]

On Tue, Jul 21, 2020 at 5:17 PM Andy Shevchenko
 wrote:
> On Tue, Jul 21, 2020 at 5:10 PM Drew Fustini  wrote:
> > On Tue, Jul 21, 2020 at 04:02:34PM +0200, Drew Fustini wrote:
> > > If there is a gpio range mapping for the pin, then print out the gpio
> > > chip and line index for the pin in the debugfs 'pins' file with the
> > > format: "[gpiochip-label]:line-[index] "

...

> > > pin 25 (PIN25) gpio-32-63:line-25 44e10864 0037 pinctrl-single
> > > pin 26 (PIN26) gpio-32-63:line-26 44e10868 0037 pinctrl-single
> > > pin 27 (PIN27) gpio-32-63:line-27 44e1086c 0037 pinctrl-single
> > > pin 28 (PIN28) NA 44e10870 0036 pinctrl-single
> > > pin 29 (PIN29) NA 44e10874 0006 pinctrl-single

And would be also better to have

0:N/A

to keep both arguments in it.

> Because line is integer and label is string it is better (from parsing
> of view) to put it other way around, i.e.
>
> %u:%s, label, line
>
> ...
>
> > Apologies - I should not have put the change log in the commit message.
> > Please let me know if I should resubmit.
>
> Since the above comment, I guess it would be good.
> Thanks for doing this!

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 4/5] MIPS: Loongson64: DTS: Fix ISA range for RS780E PCH

[Jiaxun Yang]

Ranges should express the actual physical address on bus.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/boot/dts/loongson/rs780e-pch.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/boot/dts/loongson/rs780e-pch.dtsi 
b/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
index d4c803d74036..99174b52dfb8 100644
--- a/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
@@ -25,7 +25,7 @@ isa {
compatible = "isa";
#address-cells = <2>;
#size-cells = <1>;
-   ranges = <1 0 0 0 0x4000>;
+   ranges = <1 0 0 0x1800 0x4000>;
 
rtc0: rtc@70 {
compatible = "motorola,mc146818";
-- 
2.28.0.rc1

[PATCH v2 2/5] MIPS: Loongson64: Process ISA Node in DeviceTree

[Jiaxun Yang]

Previously, we're hardcoding resserved ISA I/O Space in code, now
we're processing reverved I/O via DeviceTree directly. Using the ranges
property to determine the size and address of reserved I/O space.

Signed-off-by: Jiaxun Yang 
--
v2: Use range_parser instead of pci_range_parser
---
 arch/mips/loongson64/init.c | 88 ++---
 1 file changed, 63 insertions(+), 25 deletions(-)

diff --git a/arch/mips/loongson64/init.c b/arch/mips/loongson64/init.c
index 59ddadace83f..67e95193758e 100644
--- a/arch/mips/loongson64/init.c
+++ b/arch/mips/loongson64/init.c
@@ -7,6 +7,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -63,41 +65,77 @@ void __init prom_free_prom_memory(void)
 {
 }
 
-static __init void reserve_pio_range(void)
+static int __init add_legacy_isa_io(struct fwnode_handle *fwnode, 
resource_size_t hw_start,
+   resource_size_t size)
 {
+   int ret = 0;
struct logic_pio_hwaddr *range;
+   unsigned long vaddr;
 
range = kzalloc(sizeof(*range), GFP_ATOMIC);
if (!range)
-   return;
+   return -ENOMEM;
 
-   range->fwnode = _root->fwnode;
-   range->size = MMIO_LOWER_RESERVED;
-   range->hw_start = LOONGSON_PCIIO_BASE;
+   range->fwnode = fwnode;
+   range->size = size;
+   range->hw_start = hw_start;
range->flags = LOGIC_PIO_CPU_MMIO;
 
-   if (logic_pio_register_range(range)) {
-   pr_err("Failed to reserve PIO range for legacy ISA\n");
-   goto free_range;
+   ret = logic_pio_register_range(range);
+   if (ret) {
+   kfree(range);
+   return ret;
+   }
+
+   /* Legacy ISA must placed at the start of PCI_IOBASE */
+   if (range->io_start != 0) {
+   logic_pio_unregister_range(range);
+   kfree(range);
+   return -EINVAL;
}
 
-   if (WARN(range->io_start != 0,
-   "Reserved PIO range does not start from 0\n"))
-   goto unregister;
-
-   /*
-* i8259 would access I/O space, so mapping must be done here.
-* Please remove it when all drivers can be managed by logic_pio.
-*/
-   ioremap_page_range(PCI_IOBASE, PCI_IOBASE + MMIO_LOWER_RESERVED,
-   LOONGSON_PCIIO_BASE,
-   pgprot_device(PAGE_KERNEL));
-
-   return;
-unregister:
-   logic_pio_unregister_range(range);
-free_range:
-   kfree(range);
+   vaddr = PCI_IOBASE + range->io_start;
+
+   ioremap_page_range(vaddr, vaddr + size, hw_start, 
pgprot_device(PAGE_KERNEL));
+
+   return 0;
+}
+
+static __init void reserve_pio_range(void)
+{
+   struct device_node *np;
+
+   for_each_node_by_name(np, "isa") {
+   struct of_range range;
+   struct of_range_parser parser;
+
+   pr_info("ISA Bridge: %pOF\n", np);
+
+   if (of_range_parser_init(, np)) {
+   pr_info("Failed to parse resources.\n");
+   break;
+   }
+
+   for_each_of_range(, ) {
+   switch (range.flags & IORESOURCE_TYPE_BITS) {
+   case IORESOURCE_IO:
+   pr_info(" IO 0x%016llx..0x%016llx  ->  
0x%016llx\n",
+   range.cpu_addr,
+   range.cpu_addr + range.size - 1,
+   range.bus_addr);
+   if (add_legacy_isa_io(>fwnode, 
range.cpu_addr + range.bus_addr,
+ range.size))
+   pr_warn("Failed to reserve legacy IO in 
Logic PIO\n");
+   break;
+   case IORESOURCE_MEM:
+   pr_info(" MEM 0x%016llx..0x%016llx  ->  
0x%016llx\n",
+   range.cpu_addr,
+   range.cpu_addr + range.size - 1,
+   range.bus_addr);
+   break;
+   }
+   }
+   }
 }
 
 void __init arch_init_irq(void)
-- 
2.28.0.rc1

[PATCH v2 3/5] MIPS: Loongson64: Enlarge IO_SPACE_LIMIT

[Jiaxun Yang]

It can be very big on LS7A PCH systems.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/include/asm/io.h | 3 ++-
 arch/mips/include/asm/mach-loongson64/spaces.h | 3 +--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 346fffd9e972..0072489325fa 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -50,8 +50,9 @@
 # define __relaxed_ioswabq ioswabq
 
 /* ioswab[bwlq], __mem_ioswab[bwlq] are defined in mangle-port.h */
-
+#ifndef IO_SPACE_LIMIT
 #define IO_SPACE_LIMIT 0x
+#endif
 
 /*
  * On MIPS I/O ports are memory mapped, so we access them using normal
diff --git a/arch/mips/include/asm/mach-loongson64/spaces.h 
b/arch/mips/include/asm/mach-loongson64/spaces.h
index 3de0ac9d8829..fa5ea4ee8b6c 100644
--- a/arch/mips/include/asm/mach-loongson64/spaces.h
+++ b/arch/mips/include/asm/mach-loongson64/spaces.h
@@ -11,8 +11,7 @@
 #define PCI_IOSIZE SZ_16M
 #define MAP_BASE   (PCI_IOBASE + PCI_IOSIZE)
 
-/* Reserved at the start of PCI_IOBASE for legacy drivers */
-#define MMIO_LOWER_RESERVED0x1
+#define IO_SPACE_LIMIT  PCI_IOSIZE
 
 #include 
 #endif
-- 
2.28.0.rc1

[PATCH v2 5/5] MIPS: Loongson64: Add ISA node for LS7A PCH

[Jiaxun Yang]

Although currently we're not enabling any ISA device in devicetree,
but this node is required to express the ranges of address reserved
for ISA.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi 
b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index 1c286bb8c703..e574a062dfae 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -367,5 +367,12 @@ pci_bridge@14,0 {
interrupt-map = <0 0 0 0  39 
IRQ_TYPE_LEVEL_HIGH>;
};
};
+
+   isa {
+   compatible = "isa";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <1 0 0 0x1800 0x2>;
+   };
};
 };
-- 
2.28.0.rc1

[PATCH v2 1/5] of_address: Add bus type match for pci ranges parser

[Jiaxun Yang]

So the parser can be used to parse range property of ISA bus.

As they're all using PCI-like method of range property, there is no need
start a new parser.

Signed-off-by: Jiaxun Yang 

--
v2: Drop useless check, fix some na for bus_addr
add define of of_range_parser_init according to
Rob's suggestion.
---
 drivers/of/address.c   | 27 +++
 include/linux/of_address.h |  5 +
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8eea3f6e29a4..7406636cea87 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -698,9 +698,10 @@ static int parser_init(struct of_pci_range_parser *parser,
 
parser->node = node;
parser->pna = of_n_addr_cells(node);
-   parser->na = of_bus_n_addr_cells(node);
-   parser->ns = of_bus_n_size_cells(node);
parser->dma = !strcmp(name, "dma-ranges");
+   parser->bus = of_match_bus(node);
+
+   parser->bus->count_cells(parser->node, >na, >ns);
 
parser->range = of_get_property(node, name, );
if (parser->range == NULL)
@@ -732,6 +733,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
int na = parser->na;
int ns = parser->ns;
int np = parser->pna + na + ns;
+   int busflag_na = 0;
 
if (!range)
return NULL;
@@ -739,12 +741,14 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
if (!parser->range || parser->range + np > parser->end)
return NULL;
 
-   if (parser->na == 3)
-   range->flags = of_bus_pci_get_flags(parser->range);
-   else
-   range->flags = 0;
+   range->flags = parser->bus->get_flags(parser->range);
+
+   /* PCI and ISA have a extra cell for resource flags */
+   if (strcmp(parser->bus->name, "pci") ||
+   strcmp(parser->bus->name, "isa"))
+   busflag_na = 1;
 
-   range->pci_addr = of_read_number(parser->range, na);
+   range->bus_addr = of_read_number(parser->range + busflag_na, na - 
busflag_na);
 
if (parser->dma)
range->cpu_addr = of_translate_dma_address(parser->node,
@@ -759,11 +763,10 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
/* Now consume following elements while they are contiguous */
while (parser->range + np <= parser->end) {
u32 flags = 0;
-   u64 pci_addr, cpu_addr, size;
+   u64 bus_addr, cpu_addr, size;
 
-   if (parser->na == 3)
-   flags = of_bus_pci_get_flags(parser->range);
-   pci_addr = of_read_number(parser->range, na);
+   flags = parser->bus->get_flags(parser->range);
+   bus_addr = of_read_number(parser->range + busflag_na, na - 
busflag_na);
if (parser->dma)
cpu_addr = of_translate_dma_address(parser->node,
parser->range + na);
@@ -774,7 +777,7 @@ struct of_pci_range *of_pci_range_parser_one(struct 
of_pci_range_parser *parser,
 
if (flags != range->flags)
break;
-   if (pci_addr != range->pci_addr + range->size ||
+   if (bus_addr != range->bus_addr + range->size ||
cpu_addr != range->cpu_addr + range->size)
break;
 
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 763022ed3456..3e8d6489cbf1 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -6,8 +6,11 @@
 #include 
 #include 
 
+struct of_bus;
+
 struct of_pci_range_parser {
struct device_node *node;
+   struct of_bus *bus;
const __be32 *range;
const __be32 *end;
int na;
@@ -53,6 +56,7 @@ extern const __be32 *of_get_address(struct device_node *dev, 
int index,
 
 extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
struct device_node *node);
+#define of_range_parser_init of_pci_range_parser_init
 extern int of_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
struct device_node *node);
 extern struct of_pci_range *of_pci_range_parser_one(
@@ -83,6 +87,7 @@ static inline int of_pci_range_parser_init(struct 
of_pci_range_parser *parser,
 {
return -ENOSYS;
 }
+#define of_range_parser_init of_pci_range_parser_init
 
 static inline int of_pci_dma_range_parser_init(struct of_pci_range_parser 
*parser,
struct device_node *node)
-- 
2.28.0.rc1

[PATCH v2 0/5] MIPS: Loongson64: Process ISA Node in DeviceTree

[Jiaxun Yang]

Hi,

This series convert reservation of Loongson64 Logic PIO into DeviceTree based
method.

It can be used to replace Huacai's
"MIPS: Loongson64: Reserve legacy MMIO space according to bridge type".

Thanks.

v2:
  - Address Rob and Huacai's review comments.

Jiaxun Yang (5):
  of_address: Add bus type match for pci ranges parser
  MIPS: Loongson64: Process ISA Node in DeviceTree
  MIPS: Loongson64: Enlarge IO_SPACE_LIMIT
  MIPS: Loongson64: DTS: Fix ISA range for RS780E PCH
  MIPS: Loongson64: Add ISA node for LS7A PCH

 arch/mips/boot/dts/loongson/ls7a-pch.dtsi |  7 ++
 arch/mips/boot/dts/loongson/rs780e-pch.dtsi   |  2 +-
 arch/mips/include/asm/io.h|  3 +-
 .../mips/include/asm/mach-loongson64/spaces.h |  3 +-
 arch/mips/loongson64/init.c   | 88 +--
 drivers/of/address.c  | 27 +++---
 include/linux/of_address.h|  5 ++
 7 files changed, 94 insertions(+), 41 deletions(-)

-- 
2.28.0.rc1

Re: [RFC PATCH] mm: silence soft lockups from unlock_page

[Chris Down]

I understand the pragmatic considerations here, but I'm quite concerned about 
the maintainability and long-term ability to reason about a patch like this.  
For example, how do we know when this patch is safe to remove? Also, what other 
precedent does this set for us covering for poor userspace behaviour?


Speaking as a systemd maintainer, if udev could be doing something better on 
these machines, we'd be more than receptive to help fix it. In general I am 
against explicit watchdog tweaking here because a.) there's potential to mask 
other problems, and b.) it seems like the kind of one-off trivia nobody is 
going to remember exists when doing complex debugging in future.


Is there anything preventing this being remedied in udev, instead of the 
kernel?

Re: [PATCH v4 05/10] powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR

[Ravi Bangoria]

On 7/21/20 7:37 PM, Michael Ellerman wrote:

Ravi Bangoria  writes:

On 7/21/20 4:59 PM, Michael Ellerman wrote:

Ravi Bangoria  writes:

On 7/17/20 11:14 AM, Jordan Niethe wrote:

On Fri, Jul 17, 2020 at 2:10 PM Ravi Bangoria
 wrote:


Add new device-tree feature for 2nd DAWR. If this feature is present,
2nd DAWR is supported, otherwise not.

Signed-off-by: Ravi Bangoria 
---
arch/powerpc/include/asm/cputable.h | 7 +--
arch/powerpc/kernel/dt_cpu_ftrs.c   | 7 +++
2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index e506d429b1af..3445c86e1f6f 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -214,6 +214,7 @@ static inline void cpu_feature_keys_init(void) { }
#define CPU_FTR_P9_TLBIE_ERAT_BUG  LONG_ASM_CONST(0x0001)
#define CPU_FTR_P9_RADIX_PREFETCH_BUG  LONG_ASM_CONST(0x0002)
#define CPU_FTR_ARCH_31
LONG_ASM_CONST(0x0004)
+#define CPU_FTR_DAWR1  LONG_ASM_CONST(0x0008)

#ifndef __ASSEMBLY__

@@ -497,14 +498,16 @@ static inline void cpu_feature_keys_init(void) { }
#define CPU_FTRS_POSSIBLE  \
   (CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | CPU_FTRS_POWER8 | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | CPU_FTRS_POWER9 | \
-CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
+CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 | 
\
+CPU_FTR_DAWR1)
#else
#define CPU_FTRS_POSSIBLE  \
   (CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
CPU_FTRS_POWER8 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \
CPU_FTR_VSX_COMP | CPU_FTR_ALTIVEC_COMP | CPU_FTRS_POWER9 | \
-CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
+CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 | 
\
+CPU_FTR_DAWR1)



Instead of putting CPU_FTR_DAWR1 into CPU_FTRS_POSSIBLE should it go
into CPU_FTRS_POWER10?
Then it will be picked up by CPU_FTRS_POSSIBLE.


I remember a discussion about this with Mikey and we decided to do it
this way. Obviously, the purpose is to make CPU_FTR_DAWR1 independent of
CPU_FTRS_POWER10 because DAWR1 is an optional feature in p10. I fear
including CPU_FTR_DAWR1 in CPU_FTRS_POWER10 can make it forcefully enabled
even when device-tree property is not present or pa-feature bit it not set,
because we do:

 {   /* 3.1-compliant processor, i.e. Power10 "architected" mode */
 .pvr_mask   = 0x,
 .pvr_value  = 0x0f06,
 .cpu_name   = "POWER10 (architected)",
 .cpu_features   = CPU_FTRS_POWER10,


The pa-features logic will turn it off if the feature bit is not set.

So you should be able to put it in CPU_FTRS_POWER10.

See for example CPU_FTR_NOEXECUTE.


Ah ok. scan_features() clears the feature if the bit is not set in
pa-features. So it should work find for powervm. I'll verify the same
thing happens in case of baremetal where we use cpu-features not
pa-features. If it works in baremetal as well, will put it in
CPU_FTRS_POWER10.


When we use DT CPU features we don't use CPU_FTRS_POWER10 at all.

We construct a cpu_spec from scratch with just the base set of features:

static struct cpu_spec __initdata base_cpu_spec = {
.cpu_name   = NULL,
.cpu_features   = CPU_FTRS_DT_CPU_BASE,


And then individual features are enabled via the device tree flags.


Ah good. I was under a wrong impression that we use cpu_specs[] for all
the cases. Thanks mpe for explaining in detail :)

Ravi

Re: [PATCH v3] pinctrl: core: print gpio in pins debugfs file

[Andy Shevchenko]

On Tue, Jul 21, 2020 at 5:10 PM Drew Fustini  wrote:
> On Tue, Jul 21, 2020 at 04:02:34PM +0200, Drew Fustini wrote:
> > If there is a gpio range mapping for the pin, then print out the gpio
> > chip and line index for the pin in the debugfs 'pins' file with the
> > format: "[gpiochip-label]:line-[index] "
> >
> > For example, here is a section of 'pins' the PocketBeagle (AM3358):
> > /sys/kernel/debug/pinctrl/44e10800.pinmux-pinctrl-single/pins
> >
> > pin 25 (PIN25) gpio-32-63:line-25 44e10864 0037 pinctrl-single
> > pin 26 (PIN26) gpio-32-63:line-26 44e10868 0037 pinctrl-single
> > pin 27 (PIN27) gpio-32-63:line-27 44e1086c 0037 pinctrl-single
> > pin 28 (PIN28) NA 44e10870 0036 pinctrl-single
> > pin 29 (PIN29) NA 44e10874 0006 pinctrl-single
> > pin 30 (PIN30) gpio-32-63:line-28 44e10878 0027 pinctrl-single
> > pin 31 (PIN31) gpio-32-63:line-29 44e1087c 0037 pinctrl-single
> > pin 32 (PIN32) gpio-32-63:line-30 44e10880 0037 pinctrl-single
> > pin 33 (PIN33) gpio-32-63:line-31 44e10884 0037 pinctrl-single
> > pin 34 (PIN34) gpio-64-95:line-0 44e10888 0037 pinctrl-single
> > pin 35 (PIN35) gpio-64-95:line-1 44e1088c 0037 pinctrl-single

Because line is integer and label is string it is better (from parsing
of view) to put it other way around, i.e.

%u:%s, label, line

...

> Apologies - I should not have put the change log in the commit message.
> Please let me know if I should resubmit.

Since the above comment, I guess it would be good.
Thanks for doing this!

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH] mm: silence soft lockups from unlock_page

[Qian Cai]

On Tue, Jul 21, 2020 at 03:38:35PM +0200, Michal Hocko wrote:
> On Tue 21-07-20 09:23:44, Qian Cai wrote:
> > On Tue, Jul 21, 2020 at 02:17:52PM +0200, Michal Hocko wrote:
> > > On Tue 21-07-20 07:44:07, Qian Cai wrote:
> > > > 
> > > > 
> > > > > On Jul 21, 2020, at 7:25 AM, Michal Hocko  wrote:
> > > > > 
> > > > > Are these really important? I believe I can dig that out from the bug
> > > > > report but I didn't really consider that important enough.
> > > > 
> > > > Please dig them out. We have also been running those things on
> > > > “large” powerpc as well and never saw such soft-lockups. Those
> > > > details may give us some clues about the actual problem.
> > > 
> > > I strongly suspect this is not really relevant but just FYI this is
> > > 16Node, 11.9TB with 1536CPUs system.
> > 
> > Okay, we are now talking about the HPC special case. Just brain-storming 
> > some
> > ideas here.
> > 
> > 
> > 1) What about increase the soft-lockup threshold early at boot and restore
> > afterwards? As far as I can tell, those soft-lockups are just a few bursts 
> > of
> > things and then cure itself after the booting.
> 
> Is this really better option than silencing soft lockup from the code
> itself? What if the same access pattern happens later on?

It is better because it does not require a code change? Did your customers see
the similar soft-lockups after booting was done?

[PATCH] KEYS: remove redundant memsets

[trix]

From: Tom Rix 

Reviewing use of memset in keyctrl_pkey.c

keyctl_pkey_params_get prologue code to set params up

memset(params, 0, sizeof(*params));
params->encoding = "raw";

keyctl_pkey_params_get_2 and keyctl_pkey_query have the same
prologue and they call keyctl_pkey_params_get.

So remove the prologue from the callers.

In keyctl_pkey_params_get_2, reorder the copy_from_user
of uparams to closer to it's use to ensure that
the keyctrl_pkey_params_get is called first.

Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for 
asymmetric keys [ver #2]")

Signed-off-by: Tom Rix 
---
 security/keys/keyctl_pkey.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
index 931d8dfb4a7f..60b504681388 100644
--- a/security/keys/keyctl_pkey.c
+++ b/security/keys/keyctl_pkey.c
@@ -119,12 +119,6 @@ static int keyctl_pkey_params_get_2(const struct 
keyctl_pkey_params __user *_par
struct kernel_pkey_query info;
int ret;
 
-   memset(params, 0, sizeof(*params));
-   params->encoding = "raw";
-
-   if (copy_from_user(, _params, sizeof(uparams)) != 0)
-   return -EFAULT;
-
ret = keyctl_pkey_params_get(uparams.key_id, _info, params);
if (ret < 0)
return ret;
@@ -133,6 +127,9 @@ static int keyctl_pkey_params_get_2(const struct 
keyctl_pkey_params __user *_par
if (ret < 0)
return ret;
 
+   if (copy_from_user(, _params, sizeof(uparams)) != 0)
+   return -EFAULT;
+
switch (op) {
case KEYCTL_PKEY_ENCRYPT:
case KEYCTL_PKEY_DECRYPT:
@@ -166,8 +163,6 @@ long keyctl_pkey_query(key_serial_t id,
struct kernel_pkey_query res;
long ret;
 
-   memset(, 0, sizeof(params));
-
ret = keyctl_pkey_params_get(id, _info, );
if (ret < 0)
goto error;
-- 
2.18.1

Re: [PATCH v2 4/4] platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes

[Guenter Roeck]

Hi Enric,

On Tue, Jul 21, 2020 at 01:29:01PM +0200, Enric Balletbo i Serra wrote:
> Hi Guenter,
> 
> Thank you for work on this. Cc'ing Gwendal as he has a deep knowledge of the 
> EC
> and their errors.

The series is now also available in Gerrit at

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2306731/3
for integration/testing into ChromeOS.

Thanks,
Guenter

> 
> On 20/7/20 22:22, Guenter Roeck wrote:
> > The EC reports a variety of error codes. Most of those, with the exception
> > of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual
> > error code gets lost. In cros_ec_cmd_xfer_status(), convert all EC errors
> > to Linux error codes to report a more meaningful error to the caller to aid
> > debugging.
> > 
> > Cc: Yu-Hsuan Hsu 
> > Cc: Prashant Malani 
> > Signed-off-by: Guenter Roeck 
> > ---
> > v2: No change
> > 
> > Notes:
> > I would welcome feedback on the error code translations.
> > Can we do better ?
> > 
> > -ENOTSUPP is not a recommended error code, and checkpatch complains
> > about it. It is used in existing code, so I did not change it, but it
> > might be worthwhile exploring if we can find a better error code to
> > report "version not supported". Possible candidates might be EPROTOTYPE,
> > ENOPROTOOPT, EPROTONOSUPPORT, EPFNOSUPPORT, or EAFNOSUPPORT. I don't
> > see a direct match, but NFS reports -EPROTONOSUPPORT for unsupported
> > protocol versions.
> > 
> >  drivers/platform/chrome/cros_ec_proto.c | 37 +++--
> >  1 file changed, 29 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> > b/drivers/platform/chrome/cros_ec_proto.c
> > index 3e745e0fe092..10aa9e483d35 100644
> > --- a/drivers/platform/chrome/cros_ec_proto.c
> > +++ b/drivers/platform/chrome/cros_ec_proto.c
> > @@ -543,6 +543,29 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
> >  }
> >  EXPORT_SYMBOL(cros_ec_cmd_xfer);
> >  
> > +static const int cros_ec_error_map[] = {
> > +   [EC_RES_INVALID_COMMAND] = -EOPNOTSUPP,
> > +   [EC_RES_ERROR] = -EIO,
> 
> nit -EREMOTEIO? To make explicit that the error is "remote" from the host.
> Although -EIO seems to be more generic.
> 
> > +   [EC_RES_INVALID_PARAM] = -EINVAL,
> > +   [EC_RES_ACCESS_DENIED] = -EACCES,
> > +   [EC_RES_INVALID_RESPONSE] = -EPROTO,
> > +   [EC_RES_INVALID_VERSION] = -ENOTSUPP,
> 
> +1 for EPROTONOSUPPORT to match with EC_RES_INVALID_VERSION
> 
> > +   [EC_RES_INVALID_CHECKSUM] = -EBADMSG,
> > +   [EC_RES_IN_PROGRESS] = -EINPROGRESS,
> > +   [EC_RES_UNAVAILABLE] = -ENODATA,
> > +   [EC_RES_TIMEOUT] = -ETIMEDOUT,
> > +   [EC_RES_OVERFLOW] = -EOVERFLOW,
> > +   [EC_RES_INVALID_HEADER] = -EBADR,
> > +   [EC_RES_REQUEST_TRUNCATED] = -EBADR,
> > +   [EC_RES_RESPONSE_TOO_BIG] = -EFBIG,
> > +   [EC_RES_BUS_ERROR] = -EFAULT,
> > +   [EC_RES_BUSY] = -EBUSY,
> 
> Although the name matches, I'm wondering if we should use -EAGAIN instead as 
> per
> EC documentation:
> 
>   EC_RES_BUSY - Up but too busy. Should retry.
> 
> hmm, however, for the audio codec, for example, this seems to have a slightly
> different meaning and retry is not what we want, so let's do direct 
> translation
> and stay with -EBUSY.
> 
> > +   [EC_RES_INVALID_HEADER_VERSION] = -EBADMSG,
> > +   [EC_RES_INVALID_HEADER_CRC] = -EBADMSG,
> > +   [EC_RES_INVALID_DATA_CRC] = -EBADMSG,
> > +   [EC_RES_DUP_UNAVAILABLE] = -ENODATA,
> > +};
> > +
> >  /**
> >   * cros_ec_cmd_xfer_status() - Send a command to the ChromeOS EC.
> >   * @ec_dev: EC device.
> > @@ -555,8 +578,7 @@ EXPORT_SYMBOL(cros_ec_cmd_xfer);
> >   *
> >   * Return:
> >   * >=0 - The number of bytes transferred
> > - * -ENOTSUPP - Operation not supported
> > - * -EPROTO - Protocol error
> > + * <0 - Linux error code
> >   */
> >  int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> > struct cros_ec_command *msg)
> > @@ -566,13 +588,12 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device 
> > *ec_dev,
> > ret = cros_ec_cmd_xfer(ec_dev, msg);
> > if (ret < 0) {
> > dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
> > -   } else if (msg->result == EC_RES_INVALID_VERSION) {
> > -   dev_dbg(ec_dev->dev, "Command invalid version (err:%d)\n",
> > -   msg->result);
> > -   return -ENOTSUPP;
> > } else if (msg->result != EC_RES_SUCCESS) {
> > -   dev_dbg(ec_dev->dev, "Command result (err: %d)\n", msg->result);
> > -   return -EPROTO;
> > +   if (msg->result < ARRAY_SIZE(cros_ec_error_map) && 
> > cros_ec_error_map[msg->result])
> > +   ret = cros_ec_error_map[msg->result];
> > +   else
> > +   ret = -EPROTO;
> > +   dev_dbg(ec_dev->dev, "Command result (err: %d [%d])\n", 
> > msg->result, ret);
> > }
> >  
> > return ret;
> > 

[PATCH] dynamic debug: allow printing to trace event

[Vincent Whitchurch]

When debugging device drivers, I've found it very useful to be able to
redirect existing pr_debug()/dev_dbg() prints to the trace buffer
instead of dmesg.  Among the many advantages of the trace buffer is that
it can be dynamically resized, allows these prints to combined with
other trace events, and doesn't fill up system logs.

Since dynamic debug already has hooks in these call sites, getting these
prints into the ftrace buffer is straightforward if we have dynamic
debug do it.

Add an "x" flag to make the dynamic debug call site print to a new
printk:dynamic trace event.  The trace event can be emitted instead of
or in addition to the printk().  The print buffer is placed on the stack
and is limited to a somewhat arbitrarily chosen 256 bytes; anything
larger will be truncated.

Signed-off-by: Vincent Whitchurch 
---
 .../admin-guide/dynamic-debug-howto.rst   |   1 +
 include/linux/dynamic_debug.h |   7 +-
 include/trace/events/printk.h |  16 +++
 lib/dynamic_debug.c   | 124 ++
 4 files changed, 120 insertions(+), 28 deletions(-)

diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst 
b/Documentation/admin-guide/dynamic-debug-howto.rst
index 1012bd9305e9..b235327fbb53 100644
--- a/Documentation/admin-guide/dynamic-debug-howto.rst
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst
@@ -224,6 +224,7 @@ of the characters::
 The flags are::
 
   penables the pr_debug() callsite.
+  xenables trace to the printk:dynamic event
   fInclude the function name in the printed message
   lInclude line number in the printed message
   mInclude module name in the printed message
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index abcd5fde30eb..9dee405985c4 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -27,13 +27,16 @@ struct _ddebug {
 * writes commands to /dynamic_debug/control
 */
 #define _DPRINTK_FLAGS_NONE0
-#define _DPRINTK_FLAGS_PRINT   (1<<0) /* printk() a message using the format */
+#define _DPRINTK_FLAGS_PRINTK  (1<<0) /* printk() a message using the format */
 #define _DPRINTK_FLAGS_INCL_MODNAME(1<<1)
 #define _DPRINTK_FLAGS_INCL_FUNCNAME   (1<<2)
 #define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
 #define _DPRINTK_FLAGS_INCL_TID(1<<4)
+#define _DPRINTK_FLAGS_TRACE   (1<<5)
+#define _DPRINTK_FLAGS_PRINT   (_DPRINTK_FLAGS_PRINTK | \
+_DPRINTK_FLAGS_TRACE)
 #if defined DEBUG
-#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
+#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINTK
 #else
 #define _DPRINTK_FLAGS_DEFAULT 0
 #endif
diff --git a/include/trace/events/printk.h b/include/trace/events/printk.h
index 13d405b2fd8b..696d6e19a9b7 100644
--- a/include/trace/events/printk.h
+++ b/include/trace/events/printk.h
@@ -31,6 +31,22 @@ TRACE_EVENT(console,
 
TP_printk("%s", __get_str(msg))
 );
+
+TRACE_EVENT(dynamic,
+   TP_PROTO(const char *message),
+
+   TP_ARGS(message),
+
+   TP_STRUCT__entry(
+   __string(message, message)
+   ),
+
+   TP_fast_assign(
+   __assign_str(message, message);
+   ),
+
+   TP_printk("%s", __get_str(message))
+);
 #endif /* _TRACE_PRINTK_H */
 
 /* This part must be outside protection */
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 321437bbf87d..9f6d8867af7c 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -79,11 +80,12 @@ static inline const char *trim_prefix(const char *path)
 }
 
 static struct { unsigned flag:8; char opt_char; } opt_array[] = {
-   { _DPRINTK_FLAGS_PRINT, 'p' },
+   { _DPRINTK_FLAGS_PRINTK, 'p' },
{ _DPRINTK_FLAGS_INCL_MODNAME, 'm' },
{ _DPRINTK_FLAGS_INCL_FUNCNAME, 'f' },
{ _DPRINTK_FLAGS_INCL_LINENO, 'l' },
{ _DPRINTK_FLAGS_INCL_TID, 't' },
+   { _DPRINTK_FLAGS_TRACE, 'x' },
{ _DPRINTK_FLAGS_NONE, '_' },
 };
 
@@ -550,6 +552,65 @@ static char *dynamic_emit_prefix(const struct _ddebug 
*desc, char *buf)
return buf;
 }
 
+static void dynamic_trace(const char *fmt, va_list args)
+{
+   char buf[256];
+   int len;
+
+   len = vscnprintf(buf, sizeof(buf), fmt, args);
+   if (!len)
+   return;
+
+   if (buf[len - 1] == '\n')
+   buf[len - 1] = '\0';
+
+   trace_dynamic(buf);
+}
+
+static void dynamic_printk(unsigned int flags, const char *fmt, ...)
+{
+   if (flags & _DPRINTK_FLAGS_TRACE) {
+   va_list args;
+
+   va_start(args, fmt);
+   /*
+* All callers include the KERN_DEBUG prefix to keep the
+* vprintk case simple; strip it out for tracing.
+*/
+   dynamic_trace(fmt + strlen(KERN_DEBUG), args);
+   va_end(args);
+   

Re: [PATCH v3] pinctrl: core: print gpio in pins debugfs file

[Drew Fustini]

On Tue, Jul 21, 2020 at 04:02:34PM +0200, Drew Fustini wrote:
> If there is a gpio range mapping for the pin, then print out the gpio
> chip and line index for the pin in the debugfs 'pins' file with the
> format: "[gpiochip-label]:line-[index] "
> 
> For example, here is a section of 'pins' the PocketBeagle (AM3358):
> /sys/kernel/debug/pinctrl/44e10800.pinmux-pinctrl-single/pins
> 
> pin 25 (PIN25) gpio-32-63:line-25 44e10864 0037 pinctrl-single 
> pin 26 (PIN26) gpio-32-63:line-26 44e10868 0037 pinctrl-single 
> pin 27 (PIN27) gpio-32-63:line-27 44e1086c 0037 pinctrl-single 
> pin 28 (PIN28) NA 44e10870 0036 pinctrl-single 
> pin 29 (PIN29) NA 44e10874 0006 pinctrl-single 
> pin 30 (PIN30) gpio-32-63:line-28 44e10878 0027 pinctrl-single 
> pin 31 (PIN31) gpio-32-63:line-29 44e1087c 0037 pinctrl-single 
> pin 32 (PIN32) gpio-32-63:line-30 44e10880 0037 pinctrl-single 
> pin 33 (PIN33) gpio-32-63:line-31 44e10884 0037 pinctrl-single 
> pin 34 (PIN34) gpio-64-95:line-0 44e10888 0037 pinctrl-single 
> pin 35 (PIN35) gpio-64-95:line-1 44e1088c 0037 pinctrl-single 
> 
> Suggested-by: Andy Shevchenko 
> Suggested-by: Tony Lindgren 
> Signed-off-by: Drew Fustini 
> 
> v3 changes:
> - gpio column is now gpiochip label and line index
> 
> v2 changes:
> - print 'NA' if pin does not have a GPIO number
> - change gpio_num from unsigned to unsigned int per checkpatch
> ---
>  drivers/pinctrl/core.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> index 821242bb4b16..a23dc264cae7 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -27,6 +27,7 @@
>  #include 
>  
>  #ifdef CONFIG_GPIOLIB
> +#include "../gpio/gpiolib.h"
>  #include 
>  #endif
>  
> @@ -1601,6 +1602,9 @@ static int pinctrl_pins_show(struct seq_file *s, void 
> *what)
>   struct pinctrl_dev *pctldev = s->private;
>   const struct pinctrl_ops *ops = pctldev->desc->pctlops;
>   unsigned i, pin;
> + struct pinctrl_gpio_range *range;
> + unsigned int gpio_num;
> + struct gpio_chip *chip;
>  
>   seq_printf(s, "registered pins: %d\n", pctldev->desc->npins);
>  
> @@ -1618,6 +1622,23 @@ static int pinctrl_pins_show(struct seq_file *s, void 
> *what)
>  
>   seq_printf(s, "pin %d (%s) ", pin, desc->name);
>  
> +#ifdef CONFIG_GPIOLIB
> + gpio_num = 0;
> + list_for_each_entry(range, >gpio_ranges, node) {
> + if ((pin >= range->pin_base) &&
> + (pin < (range->pin_base + range->npins))) {
> + gpio_num = range->base + (pin - 
> range->pin_base);
> + break;
> + }
> + }
> + chip = gpio_to_chip(gpio_num);
> + if (chip && chip->gpiodev && chip->gpiodev->base)
> + seq_printf(s, "%s:line-%u ", chip->label,
> + gpio_num - chip->gpiodev->base);
> + else
> + seq_puts(s, "NA ");
> +#endif
> +
>   /* Driver-specific info per pin */
>   if (ops->pin_dbg_show)
>   ops->pin_dbg_show(pctldev, s, pin);
> -- 
> 2.25.1
> 

Apologies - I should not have put the change log in the commit message.
Please let me know if I should resubmit.

thanks,
drew

Re: [PATCH 4/8] kcsan: Add missing CONFIG_KCSAN_IGNORE_ATOMICS checks

[Peter Zijlstra]

On Tue, Jul 21, 2020 at 12:30:12PM +0200, Marco Elver wrote:
> Add missing CONFIG_KCSAN_IGNORE_ATOMICS checks for the builtin atomics
> instrumentation.
> 
> Signed-off-by: Marco Elver 
> ---
> Added to this series, as it would otherwise cause patch conflicts.
> ---
>  kernel/kcsan/core.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
> index 4633baebf84e..f53524ea0292 100644
> --- a/kernel/kcsan/core.c
> +++ b/kernel/kcsan/core.c
> @@ -892,14 +892,17 @@ EXPORT_SYMBOL(__tsan_init);
>   u##bits __tsan_atomic##bits##_load(const u##bits *ptr, int memorder);   
>\
>   u##bits __tsan_atomic##bits##_load(const u##bits *ptr, int memorder)
>\
>   {   
>\
> - check_access(ptr, bits / BITS_PER_BYTE, KCSAN_ACCESS_ATOMIC);   
>\
> + if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS))   
>\
> + check_access(ptr, bits / BITS_PER_BYTE, 
> KCSAN_ACCESS_ATOMIC);  \
>   return __atomic_load_n(ptr, memorder);  
>\
>   }   
>\
>   EXPORT_SYMBOL(__tsan_atomic##bits##_load);  
>\
>   void __tsan_atomic##bits##_store(u##bits *ptr, u##bits v, int 
> memorder);   \
>   void __tsan_atomic##bits##_store(u##bits *ptr, u##bits v, int memorder) 
>\
>   {   
>\
> - check_access(ptr, bits / BITS_PER_BYTE, KCSAN_ACCESS_WRITE | 
> KCSAN_ACCESS_ATOMIC); \
> + if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS))   
>\
> + check_access(ptr, bits / BITS_PER_BYTE, 
>\
> +  KCSAN_ACCESS_WRITE | KCSAN_ACCESS_ATOMIC); 
>\
>   __atomic_store_n(ptr, v, memorder); 
>\
>   }   
>\
>   EXPORT_SYMBOL(__tsan_atomic##bits##_store)
> @@ -908,8 +911,10 @@ EXPORT_SYMBOL(__tsan_init);
>   u##bits __tsan_atomic##bits##_##op(u##bits *ptr, u##bits v, int 
> memorder); \
>   u##bits __tsan_atomic##bits##_##op(u##bits *ptr, u##bits v, int 
> memorder)  \
>   {   
>\
> - check_access(ptr, bits / BITS_PER_BYTE, 
>\
> -  KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE | 
> KCSAN_ACCESS_ATOMIC);\
> + if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS))   
>\
> + check_access(ptr, bits / BITS_PER_BYTE, 
>\
> +  KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE 
> |  \
> +  KCSAN_ACCESS_ATOMIC);  
>\
>   return __atomic_##op##suffix(ptr, v, memorder); 
>\
>   }   
>\
>   EXPORT_SYMBOL(__tsan_atomic##bits##_##op)
> @@ -937,8 +942,10 @@ EXPORT_SYMBOL(__tsan_init);
>   int __tsan_atomic##bits##_compare_exchange_##strength(u##bits *ptr, 
> u##bits *exp,  \
> u##bits val, int 
> mo, int fail_mo)\
>   {   
>\
> - check_access(ptr, bits / BITS_PER_BYTE, 
>\
> -  KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE | 
> KCSAN_ACCESS_ATOMIC);\
> + if (!IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS))   
>\
> + check_access(ptr, bits / BITS_PER_BYTE, 
>\
> +  KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE 
> |  \
> +  KCSAN_ACCESS_ATOMIC);  
>\
>   return __atomic_compare_exchange_n(ptr, exp, val, weak, mo, 
> fail_mo);  \
>   }   
>\
>   

Re: [PATCH v4 05/10] powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR

[Michael Ellerman]

Ravi Bangoria  writes:
> On 7/21/20 4:59 PM, Michael Ellerman wrote:
>> Ravi Bangoria  writes:
>>> On 7/17/20 11:14 AM, Jordan Niethe wrote:
 On Fri, Jul 17, 2020 at 2:10 PM Ravi Bangoria
  wrote:
>
> Add new device-tree feature for 2nd DAWR. If this feature is present,
> 2nd DAWR is supported, otherwise not.
>
> Signed-off-by: Ravi Bangoria 
> ---
>arch/powerpc/include/asm/cputable.h | 7 +--
>arch/powerpc/kernel/dt_cpu_ftrs.c   | 7 +++
>2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cputable.h 
> b/arch/powerpc/include/asm/cputable.h
> index e506d429b1af..3445c86e1f6f 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -214,6 +214,7 @@ static inline void cpu_feature_keys_init(void) { }
>#define CPU_FTR_P9_TLBIE_ERAT_BUG  
> LONG_ASM_CONST(0x0001)
>#define CPU_FTR_P9_RADIX_PREFETCH_BUG  
> LONG_ASM_CONST(0x0002)
>#define CPU_FTR_ARCH_31
> LONG_ASM_CONST(0x0004)
> +#define CPU_FTR_DAWR1  LONG_ASM_CONST(0x0008)
>
>#ifndef __ASSEMBLY__
>
> @@ -497,14 +498,16 @@ static inline void cpu_feature_keys_init(void) { }
>#define CPU_FTRS_POSSIBLE  \
>   (CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | CPU_FTRS_POWER8 | \
>CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | CPU_FTRS_POWER9 
> | \
> -CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | 
> CPU_FTRS_POWER10)
> +CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | 
> CPU_FTRS_POWER10 | \
> +CPU_FTR_DAWR1)
>#else
>#define CPU_FTRS_POSSIBLE  \
>   (CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
>CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
>CPU_FTRS_POWER8 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \
>CPU_FTR_VSX_COMP | CPU_FTR_ALTIVEC_COMP | CPU_FTRS_POWER9 
> | \
> -CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | 
> CPU_FTRS_POWER10)
> +CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | 
> CPU_FTRS_POWER10 | \
> +CPU_FTR_DAWR1)
>> 
 Instead of putting CPU_FTR_DAWR1 into CPU_FTRS_POSSIBLE should it go
 into CPU_FTRS_POWER10?
 Then it will be picked up by CPU_FTRS_POSSIBLE.
>>>
>>> I remember a discussion about this with Mikey and we decided to do it
>>> this way. Obviously, the purpose is to make CPU_FTR_DAWR1 independent of
>>> CPU_FTRS_POWER10 because DAWR1 is an optional feature in p10. I fear
>>> including CPU_FTR_DAWR1 in CPU_FTRS_POWER10 can make it forcefully enabled
>>> even when device-tree property is not present or pa-feature bit it not set,
>>> because we do:
>>>
>>> {   /* 3.1-compliant processor, i.e. Power10 "architected" mode 
>>> */
>>> .pvr_mask   = 0x,
>>> .pvr_value  = 0x0f06,
>>> .cpu_name   = "POWER10 (architected)",
>>> .cpu_features   = CPU_FTRS_POWER10,
>> 
>> The pa-features logic will turn it off if the feature bit is not set.
>> 
>> So you should be able to put it in CPU_FTRS_POWER10.
>> 
>> See for example CPU_FTR_NOEXECUTE.
>
> Ah ok. scan_features() clears the feature if the bit is not set in
> pa-features. So it should work find for powervm. I'll verify the same
> thing happens in case of baremetal where we use cpu-features not
> pa-features. If it works in baremetal as well, will put it in
> CPU_FTRS_POWER10.

When we use DT CPU features we don't use CPU_FTRS_POWER10 at all.

We construct a cpu_spec from scratch with just the base set of features:

static struct cpu_spec __initdata base_cpu_spec = {
.cpu_name   = NULL,
.cpu_features   = CPU_FTRS_DT_CPU_BASE,


And then individual features are enabled via the device tree flags.

cheers

Re: [PATCH V6 07/14] perf/x86/intel: Generic support for hardware TopDown metrics

[Liang, Kan]

On 7/21/2020 5:43 AM, Peter Zijlstra wrote:

On Fri, Jul 17, 2020 at 07:05:47AM -0700, kan.li...@linux.intel.com wrote:

@@ -1031,6 +1034,35 @@ int x86_schedule_events(struct cpu_hw_events *cpuc, int 
n, int *assign)
return unsched ? -EINVAL : 0;
  }
  
+static int add_nr_metric_event(struct cpu_hw_events *cpuc,

+  struct perf_event *event,
+  int *max_count, bool sibling)
+{
+   /* The TopDown metrics events cannot be shared. */
+   if (is_metric_event(event) &&
+   (++cpuc->n_metric_event > INTEL_TD_METRIC_NUM)) {
+   cpuc->n_metric_event--;
+   return -EINVAL;
+   }
+
+   /*
+* Take the accepted metrics events into account for leader event.
+*/
+   if (!sibling)
+   *max_count += cpuc->n_metric_event;
+   else if (is_metric_event(event))
+   (*max_count)++;
+
+   return 0;
+}
+
+static void del_nr_metric_event(struct cpu_hw_events *cpuc,
+   struct perf_event *event)
+{
+   if (is_metric_event(event))
+   cpuc->n_metric_event--;
+}
+
  /*
   * dogrp: true if must collect siblings events (group)
   * returns total number of events and error code
@@ -1066,6 +1098,10 @@ static int collect_events(struct cpu_hw_events *cpuc, 
struct perf_event *leader,
cpuc->pebs_output = is_pebs_pt(leader) + 1;
}
  
+	if (x86_pmu.intel_cap.perf_metrics &&

+   add_nr_metric_event(cpuc, leader, _count, false))
+   return -EINVAL;
+
if (is_x86_event(leader)) {
if (n >= max_count)
return -EINVAL;
@@ -1082,6 +1118,10 @@ static int collect_events(struct cpu_hw_events *cpuc, 
struct perf_event *leader,
event->state <= PERF_EVENT_STATE_OFF)
continue;
  
+		if (x86_pmu.intel_cap.perf_metrics &&

+   add_nr_metric_event(cpuc, event, _count, true))
+   return -EINVAL;
+
if (n >= max_count)
return -EINVAL;
  


Something like so perhaps ?

--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1035,24 +1035,14 @@ int x86_schedule_events(struct cpu_hw_ev
  }
  
  static int add_nr_metric_event(struct cpu_hw_events *cpuc,

-  struct perf_event *event,
-  int *max_count, bool sibling)
+  struct perf_event *event)
  {
-   /* The TopDown metrics events cannot be shared. */
-   if (is_metric_event(event) &&
-   (++cpuc->n_metric_event > INTEL_TD_METRIC_NUM)) {
-   cpuc->n_metric_event--;
-   return -EINVAL;
+   if (is_metric_event(event)) {
+   if (cpuc->n_metric == INTEL_TD_METRIC_NUM)
+   return -EINVAL;
+   cpuc->n_metric++;
}
  
-	/*

-* Take the accepted metrics events into account for leader event.
-*/
-   if (!sibling)
-   *max_count += cpuc->n_metric_event;
-   else if (is_metric_event(event))
-   (*max_count)++;
-
return 0;
  }
  
@@ -1060,7 +1050,24 @@ static void del_nr_metric_event(struct c

struct perf_event *event)
  {
if (is_metric_event(event))
-   cpuc->n_metric_event--;
+   cpuc->n_metric--;
+}
+
+static int collect_event(struct cpu_hw_events *cpuc, struct perf_event *event,
+int max_count, int n)
+{
+
+   if (x86_pmu.intel_cap.perf_metrics && add_nr_metric_event(cpuc, event))
+   return -EINVAL;
+
+   if (n >= max_count + cpuc->n_metric)
+   return -EINVAL;
+
+   cpuc->event_list[n] = event;
+   if (is_counter_pair(>hw))
+   cpuc->n_pair++;
+
+   return 0;
  }
  
  /*

@@ -1098,37 +1105,20 @@ static int collect_events(struct cpu_hw_
cpuc->pebs_output = is_pebs_pt(leader) + 1;
}
  
-	if (x86_pmu.intel_cap.perf_metrics &&

-   add_nr_metric_event(cpuc, leader, _count, false))
+   if (is_x86_event(leader) && collect_event(cpuc, leader, max_count, n))
return -EINVAL;
+   n++;


If a leader is not an x86 event, n will be mistakenly increased.
But is it possible that a leader is not an x86 event here?

Seems impossible for now. A SW event cannot be a leader for a mix group.
We don't allow the core PMU and the perf_invalid_context PMU in the same 
group.
If so, I think it deserves a comment, in case the situation changes 
later, e.g.,


 +  if (is_x86_event(leader) && collect_event(cpuc, leader, max_count, n))
return -EINVAL;
 +  /*
 +   * Currently, for a x86 core event group, the leader must be a
 +   * x86 core event. A SW event cannot be a leader for a mix
 +	 * group. We don't allow the core PMU and the perf_invalid_contex +	 
* PMU in the 

Re: [PATCH v2] dt-bindings: ingenic,pinctrl: Support pinmux/pinconf nodes

[Linus Walleij]

On Mon, Jul 20, 2020 at 5:45 PM Paul Cercueil  wrote:

> Add YAML to describe the pinmux/pinconf sub-nodes of the pinctrl IP on
> Ingenic SoCs.
>
> Signed-off-by: Paul Cercueil 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 2/8] objtool, kcsan: Add __tsan_read_write to uaccess whitelist

[Peter Zijlstra]

On Tue, Jul 21, 2020 at 12:30:10PM +0200, Marco Elver wrote:
> Adds the new __tsan_read_write compound instrumentation to objtool's
> uaccess whitelist.
> 
> Signed-off-by: Marco Elver 

Acked-by: Peter Zijlstra (Intel) 

> ---
>  tools/objtool/check.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 63d8b630c67a..38d82e705c93 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -528,6 +528,11 @@ static const char *uaccess_safe_builtin[] = {
>   "__tsan_write4",
>   "__tsan_write8",
>   "__tsan_write16",
> + "__tsan_read_write1",
> + "__tsan_read_write2",
> + "__tsan_read_write4",
> + "__tsan_read_write8",
> + "__tsan_read_write16",
>   "__tsan_atomic8_load",
>   "__tsan_atomic16_load",
>   "__tsan_atomic32_load",
> -- 
> 2.28.0.rc0.105.gf9edc3c819-goog
> 

Re: [PATCH 3/8] kcsan: Skew delay to be longer for certain access types

[Peter Zijlstra]

On Tue, Jul 21, 2020 at 12:30:11PM +0200, Marco Elver wrote:
> For compound instrumentation and assert accesses, skew the watchpoint
> delay to be longer. We still shouldn't exceed the maximum delays, but it
> is safe to skew the delay for these accesses.

Complete lack of actual justification.. *why* are you doing this, and
*why* is it safe etc..

Re: [RFC PATCH 05/16] sched: Basic tracking of matching tasks(Internet mail)

[蒋彪]

Hi, perter

> On Jul 1, 2020, at 5:32 AM, Vineeth Remanan Pillai  
> wrote:
> 
> From: Peter Zijlstra 
> 
> Introduce task_struct::core_cookie as an opaque identifier for core
> scheduling. When enabled; core scheduling will only allow matching
> task to be on the core; where idle matches everything.
> 
> When task_struct::core_cookie is set (and core scheduling is enabled)
> these tasks are indexed in a second RB-tree, first on cookie value
> then on scheduling function, such that matching task selection always
> finds the most elegible match.
> 
> NOTE: *shudder* at the overhead...
> 
> NOTE: *sigh*, a 3rd copy of the scheduling function; the alternative
> is per class tracking of cookies and that just duplicates a lot of
> stuff for no raisin (the 2nd copy lives in the rt-mutex PI code).
> 
> Signed-off-by: Peter Zijlstra (Intel) 
> Signed-off-by: Vineeth Remanan Pillai 
> Signed-off-by: Julien Desfossez 
> ---
> include/linux/sched.h |   8 ++-
> kernel/sched/core.c   | 146 ++
> kernel/sched/fair.c   |  46 -
> kernel/sched/sched.h  |  55 
> 4 files changed, 208 insertions(+), 47 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 4418f5cb8324..3c8dcc5ff039 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -683,10 +683,16 @@ struct task_struct {
>   const struct sched_class*sched_class;
>   struct sched_entity se;
>   struct sched_rt_entity  rt;
> + struct sched_dl_entity  dl;
> +
> +#ifdef CONFIG_SCHED_CORE
> + struct rb_node  core_node;
> + unsigned long   core_cookie;
> +#endif
> +
> #ifdef CONFIG_CGROUP_SCHED
>   struct task_group   *sched_task_group;
> #endif
> - struct sched_dl_entity  dl;
> 
> #ifdef CONFIG_UCLAMP_TASK
>   /* Clamp values requested for a scheduling entity */
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 4b81301e3f21..b21bcab20da6 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -77,6 +77,141 @@ int sysctl_sched_rt_runtime = 95;
> 
> DEFINE_STATIC_KEY_FALSE(__sched_core_enabled);
> 
> +/* kernel prio, less is more */
> +static inline int __task_prio(struct task_struct *p)
> +{
> + if (p->sched_class == _sched_class) /* trumps deadline */
> + return -2;
> +
> + if (rt_prio(p->prio)) /* includes deadline */
> + return p->prio; /* [-1, 99] */
> +
> + if (p->sched_class == _sched_class)
> + return MAX_RT_PRIO + NICE_WIDTH; /* 140 */

return MAX_PRIO; 
May be simpler?

> +
> + return MAX_RT_PRIO + MAX_NICE; /* 120, squash fair */

MAX_RT_PRIO(100) + MAX_NICE(19) Should be 119?  :)

Thx.
Regards,
Jiang

> +}
> +
> +/*
> + * l(a,b)
> + * le(a,b) := !l(b,a)
> + * g(a,b)  := l(b,a)
> + * ge(a,b) := !l(a,b)
> + */
> +
> +/* real prio, less is less */
> +static inline bool prio_less(struct task_struct *a, struct task_struct *b)
> +{
> +
> + int pa = __task_prio(a), pb = __task_prio(b);
> +
> + if (-pa < -pb)
> + return true;
> +
> + if (-pb < -pa)
> + return false;
> +
> + if (pa == -1) /* dl_prio() doesn't work because of stop_class above */
> + return !dl_time_before(a->dl.deadline, b->dl.deadline);
> +
> + if (pa == MAX_RT_PRIO + MAX_NICE)  { /* fair */
> + u64 vruntime = b->se.vruntime;
> +
> + /*
> +  * Normalize the vruntime if tasks are in different cpus.
> +  */
> + if (task_cpu(a) != task_cpu(b)) {
> + vruntime -= task_cfs_rq(b)->min_vruntime;
> + vruntime += task_cfs_rq(a)->min_vruntime;
> + }
> +
> + return !((s64)(a->se.vruntime - vruntime) <= 0);
> + }
> +
> + return false;
> +}
> +
> +static inline bool __sched_core_less(struct task_struct *a, struct 
> task_struct *b)
> +{
> + if (a->core_cookie < b->core_cookie)
> + return true;
> +
> + if (a->core_cookie > b->core_cookie)
> + return false;
> +
> + /* flip prio, so high prio is leftmost */
> + if (prio_less(b, a))
> + return true;
> +
> + return false;
> +}
> +
> +static void sched_core_enqueue(struct rq *rq, struct task_struct *p)
> +{
> + struct rb_node *parent, **node;
> + struct task_struct *node_task;
> +
> + rq->core->core_task_seq++;
> +
> + if (!p->core_cookie)
> + return;
> +
> + node = >core_tree.rb_node;
> + parent = *node;
> +
> + while (*node) {
> + node_task = container_of(*node, struct task_struct, core_node);
> + parent = *node;
> +
> + if (__sched_core_less(p, node_task))
> + node = >rb_left;
> + else
> + node = >rb_right;
> + }
> +
> + rb_link_node(>core_node, parent, node);
> + 

[PATCH v3] pinctrl: core: print gpio in pins debugfs file

[Drew Fustini]

If there is a gpio range mapping for the pin, then print out the gpio
chip and line index for the pin in the debugfs 'pins' file with the
format: "[gpiochip-label]:line-[index] "

For example, here is a section of 'pins' the PocketBeagle (AM3358):
/sys/kernel/debug/pinctrl/44e10800.pinmux-pinctrl-single/pins

pin 25 (PIN25) gpio-32-63:line-25 44e10864 0037 pinctrl-single 
pin 26 (PIN26) gpio-32-63:line-26 44e10868 0037 pinctrl-single 
pin 27 (PIN27) gpio-32-63:line-27 44e1086c 0037 pinctrl-single 
pin 28 (PIN28) NA 44e10870 0036 pinctrl-single 
pin 29 (PIN29) NA 44e10874 0006 pinctrl-single 
pin 30 (PIN30) gpio-32-63:line-28 44e10878 0027 pinctrl-single 
pin 31 (PIN31) gpio-32-63:line-29 44e1087c 0037 pinctrl-single 
pin 32 (PIN32) gpio-32-63:line-30 44e10880 0037 pinctrl-single 
pin 33 (PIN33) gpio-32-63:line-31 44e10884 0037 pinctrl-single 
pin 34 (PIN34) gpio-64-95:line-0 44e10888 0037 pinctrl-single 
pin 35 (PIN35) gpio-64-95:line-1 44e1088c 0037 pinctrl-single 

Suggested-by: Andy Shevchenko 
Suggested-by: Tony Lindgren 
Signed-off-by: Drew Fustini 

v3 changes:
- gpio column is now gpiochip label and line index

v2 changes:
- print 'NA' if pin does not have a GPIO number
- change gpio_num from unsigned to unsigned int per checkpatch
---
 drivers/pinctrl/core.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 821242bb4b16..a23dc264cae7 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -27,6 +27,7 @@
 #include 
 
 #ifdef CONFIG_GPIOLIB
+#include "../gpio/gpiolib.h"
 #include 
 #endif
 
@@ -1601,6 +1602,9 @@ static int pinctrl_pins_show(struct seq_file *s, void 
*what)
struct pinctrl_dev *pctldev = s->private;
const struct pinctrl_ops *ops = pctldev->desc->pctlops;
unsigned i, pin;
+   struct pinctrl_gpio_range *range;
+   unsigned int gpio_num;
+   struct gpio_chip *chip;
 
seq_printf(s, "registered pins: %d\n", pctldev->desc->npins);
 
@@ -1618,6 +1622,23 @@ static int pinctrl_pins_show(struct seq_file *s, void 
*what)
 
seq_printf(s, "pin %d (%s) ", pin, desc->name);
 
+#ifdef CONFIG_GPIOLIB
+   gpio_num = 0;
+   list_for_each_entry(range, >gpio_ranges, node) {
+   if ((pin >= range->pin_base) &&
+   (pin < (range->pin_base + range->npins))) {
+   gpio_num = range->base + (pin - 
range->pin_base);
+   break;
+   }
+   }
+   chip = gpio_to_chip(gpio_num);
+   if (chip && chip->gpiodev && chip->gpiodev->base)
+   seq_printf(s, "%s:line-%u ", chip->label,
+   gpio_num - chip->gpiodev->base);
+   else
+   seq_puts(s, "NA ");
+#endif
+
/* Driver-specific info per pin */
if (ops->pin_dbg_show)
ops->pin_dbg_show(pctldev, s, pin);
-- 
2.25.1

Re: [PATCH] docs: core-api/printk-formats.rst: use literal block syntax

[Sergey Senozhatsky]

On (20/07/18 13:51), Daniel W. S. Almeida wrote:
> From: Daniel W. S. Almeida 
> 
> Fix the following warning:
> 
> WARNING: Definition list ends without a blank line;
> unexpected unindent.
> 
> By switching to the literal block syntax.
> 
> Signed-off-by: Daniel W. S. Almeida 

Jonathan, will you route it via the Documentation tree or do
you want it to land in the printk tree?

-ss

Re: [PATCH v3 3/3] media: i2c: imx274: Add IMX274 power on and off sequence

[Luca Ceresoli]

Hi Sowjanya,

On 20/07/20 19:01, Sowjanya Komatineni wrote:
> IMX274 has VANA analog 2.8V supply, VDIG digital core 1.8V supply,
> and VDDL digital io 1.2V supply which are optional based on camera
> module design.
> 
> IMX274 also need external 24Mhz clock and is optional based on
> camera module design.
> 
> This patch adds support for IMX274 power on and off to enable and
> disable these supplies and external clock.
> 
> Signed-off-by: Sowjanya Komatineni 
> ---

In the future please add a log of changes since previous versions here.

As far as the patch is concerned:
Reviewed-by: Luca Ceresoli 

Thanks.
-- 
Luca

Re: [PATCHv3 2/6] irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts

[Grzegorz Jaszczyk]

Hi Marc,

Thank you again.

On Tue, 21 Jul 2020 at 12:10, Marc Zyngier  wrote:
>
> On 2020-07-21 10:27, Grzegorz Jaszczyk wrote:
> > Hi Marc,
> >
> > First of all thank you very much for your review. I apologize in
> > advance if the description below is too verbose or not detailed
> > enough.
> >
> > On Fri, 17 Jul 2020 at 14:36, Marc Zyngier  wrote:
> >>
> >> Suman, Grzegorz,
> >>
> >> On Wed, 15 Jul 2020 14:38:05 +0100,
> >> Grzegorz Jaszczyk  wrote:
> >> >
> >> > Hi Marc,
> >> >
> >> > > On 7/8/20 5:47 AM, Marc Zyngier wrote:
> >> > > > On 2020-07-08 08:04, Grzegorz Jaszczyk wrote:
> >> > > >> On Sun, 5 Jul 2020 at 22:45, Marc Zyngier  wrote:
> >> > > >>>
> >> > > >>> On 2020-07-05 14:26, Grzegorz Jaszczyk wrote:
> >> > > >>> > On Sat, 4 Jul 2020 at 11:39, Marc Zyngier  
> >> > > >>> > wrote:
> >> > > >>> >>
> >> > > >>> >> On 2020-07-03 15:28, Grzegorz Jaszczyk wrote:
> >> > > >>>
> >> > > >>> [...]
> >> > > >>>
> >> > > >>> >> It still begs the question: if the HW can support both edge and 
> >> > > >>> >> level
> >> > > >>> >> triggered interrupts, why isn't the driver supporting this 
> >> > > >>> >> diversity?
> >> > > >>> >> I appreciate that your HW may only have level interrupts so 
> >> > > >>> >> far, but
> >> > > >>> >> what guarantees that this will forever be true? It would imply a
> >> > > >>> >> change
> >> > > >>> >> in the DT binding, which isn't desirable.
> >> > > >>> >
> >> > > >>> > Ok, I've got your point. I will try to come up with something 
> >> > > >>> > later
> >> > > >>> > on. Probably extending interrupt-cells by one and passing 
> >> > > >>> > interrupt
> >> > > >>> > type will be enough for now. Extending this driver to actually 
> >> > > >>> > support
> >> > > >>> > it can be handled later if needed. Hope it works for you.
> >> > > >>>
> >> > > >>> Writing a set_type callback to deal with this should be pretty 
> >> > > >>> easy.
> >> > > >>> Don't delay doing the right thing.
> >> > > >>
> >> > > >> Ok.
> >> > >
> >> > > Sorry for the typo in my comment causing this confusion.
> >> > >
> >> > > The h/w actually doesn't support the edge-interrupts. Likewise, the
> >> > > polarity is always high. The individual register bit descriptions
> >> > > mention what the bit values 0 and 1 mean, but there is additional
> >> > > description in the TRMs on all the SoCs that says
> >> > > "always write 1 to the bits of this register" for PRUSS_INTC_SIPR(x) 
> >> > > and
> >> > > "always write 0 to the bits of this register" for PRUSS_INTC_SITR(x).
> >> > > FWIW, these are also the reset values.
> >> > >
> >> > > Eg: AM335x TRM - https://www.ti.com/lit/pdf/spruh73
> >> > > Please see Section 4.4.2.5 and the register descriptions in 4.5.3.49,
> >> > > 4.5.3.51. Please also see Section 4.4.2.3 that explains the PRUSS INTC
> >> > > methodology.
> >> > >
> >> > > >>
> >> > > >>>
> >> > > >>> [...]
> >> > > >>>
> >> > > >>> >> >> > + hwirq = hipir & GENMASK(9, 0);
> >> > > >>> >> >> > + virq = irq_linear_revmap(intc->domain, 
> >> > > >>> >> >> > hwirq);
> >> > > >>> >> >>
> >> > > >>> >> >> And this is where I worry. You seems to have a single 
> >> > > >>> >> >> irqdomain
> >> > > >>> >> >> for all the muxes. Are you guaranteed that you will have no
> >> > > >>> >> >> overlap between muxes? And please use irq_find_mapping(), as
> >> > > >>> >> >> I have top-secret plans to kill irq_linear_revmap().
> >> > > >>> >> >
> >> > > >>> >> > Regarding irq_find_mapping - sure.
> >> > > >>> >> >
> >> > > >>> >> > Regarding irqdomains:
> >> > > >>> >> > It is a single irqdomain since the hwirq (system event) can be
> >> > > >>> mapped
> >> > > >>> >> > to different irq_host (muxes). Patch #6
> >> > > >>> >> > https://lkml.org/lkml/2020/7/2/616 implements and describes 
> >> > > >>> >> > how
> >> > > >>> input
> >> > > >>> >> > events can be mapped to some output host interrupts through 2
> >> > > >>> levels
> >> > > >>> >> > of many-to-one mapping i.e. events to channel mapping and
> >> > > >>> channels to
> >> > > >>> >> > host interrupts. Mentioned implementation ensures that 
> >> > > >>> >> > specific
> >> > > >>> system
> >> > > >>> >> > event (hwirq) can be mapped through PRUSS specific channel 
> >> > > >>> >> > into a
> >> > > >>> >> > single host interrupt.
> >> > > >>> >>
> >> > > >>> >> Patch #6 is a nightmare of its own, and I haven't fully groked 
> >> > > >>> >> it
> >> > > >>> yet.
> >> > > >>> >> Also, this driver seems to totally ignore the 2-level routing. 
> >> > > >>> >> Where
> >> > > >>> >> is it set up? map/unmap in this driver do exactly *nothing*, so
> >> > > >>> >> something somewhere must set it up.
> >> > > >>> >
> >> > > >>> > The map/unmap is updated in patch #6 and it deals with those 
> >> > > >>> > 2-level
> >> > > >>> > routing setup. Map is responsible for programming the Channel Map
> >> > > >>> > Registers (CMRx) and Host-Interrupt Map Registers (HMRx) basing 
> >> > > >>> > on
> >> > > >>> > provided configuration from the one parsed in 

[GIT PULL] timer drivers fix for 5.8-rc7

[Daniel Lezcano]

Hi Thomas,

The following changes since commit 30c66fc30ee7a98c4f3adf5fb7e213b61884474f:

  timer: Prevent base->clk from moving backward (2020-07-09 11:56:57 +0200)

are available in the Git repository at:

  https://git.linaro.org/people/daniel.lezcano/linux.git
tags/timers-v5.8-rc7

for you to fetch changes up to 6cfcd5563b4fadbf49ba8fa481978e5e86d30322:

  clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and
am4 (2020-07-21 15:48:33 +0200)


- Fix kernel panic at suspend / resume time on TI am3/am4 (Tony Lindgren)


Tony Lindgren (1):
  clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3
and am4

 drivers/bus/ti-sysc.c  | 22 ++
 drivers/clocksource/timer-ti-dm-systimer.c | 46
--
 2 files changed, 58 insertions(+), 10 deletions(-)

-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 6/7] KVM: x86: Use common definition for kvm_nested_vmexit tracepoint

[Vitaly Kuznetsov]

Sean Christopherson  writes:

> On Mon, Jul 20, 2020 at 06:52:15PM +0200, Vitaly Kuznetsov wrote:
>> Sean Christopherson  writes:
>> > +TRACE_EVENT_KVM_EXIT(kvm_nested_vmexit);
>> >  
>> >  /*
>> >   * Tracepoint for #VMEXIT reinjected to the guest
>> > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
>> > index fc70644b916ca..f437d99f4db09 100644
>> > --- a/arch/x86/kvm/vmx/nested.c
>> > +++ b/arch/x86/kvm/vmx/nested.c
>> > @@ -5912,10 +5912,7 @@ bool nested_vmx_reflect_vmexit(struct kvm_vcpu 
>> > *vcpu)
>> >exit_intr_info = vmx_get_intr_info(vcpu);
>> >exit_qual = vmx_get_exit_qual(vcpu);
>> >  
>> > -  trace_kvm_nested_vmexit(vcpu, exit_reason, exit_qual,
>> > -  vmx->idt_vectoring_info, exit_intr_info,
>> > -  vmcs_read32(VM_EXIT_INTR_ERROR_CODE),
>> > -  KVM_ISA_VMX);
>> > +  trace_kvm_nested_vmexit(exit_reason, vcpu, KVM_ISA_VMX);
>> >  
>> >/* If L0 (KVM) wants the exit, it trumps L1's desires. */
>> >if (nested_vmx_l0_wants_exit(vcpu, exit_reason))
>> 
>> With so many lines removed I'm almost in love with the patch! However,
>> when testing on SVM (unrelated?) my trace log looks a bit ugly:
>> 
>><...>-315119 [010]  3733.092646: kvm_nested_vmexit:CAN'T FIND 
>> FIELD "rip"vcpu 0 reason npf rip 0x400433 info1 
>> 0x00020006 info2 0x00641000 intr_info 0x error_code 
>> 0x
>><...>-315119 [010]  3733.092655: kvm_nested_vmexit:CAN'T FIND 
>> FIELD "rip"vcpu 0 reason npf rip 0x400433 info1 
>> 0x00010014 info2 0x0040 intr_info 0x error_code 
>> 0x
>> 
>> ...
>> 
>> but after staring at this for some time I still don't see where this
>> comes from :-( ... but reverting this commit helps:
>
> The CAN'T FIND FIELD blurb comes from tools/lib/traceevent/event-parse.c.
>
> I assume you are using tooling of some form to generate the trace, i.e. the
> issue doesn't show up in /sys/kernel/debug/tracing/trace.  If that's the
> case, this is more or less ABI breakage :-(
>  

Right you are,

the tool is called 'trace-cmd record -e kvm ...' / 'trace-cmd report'
but I always thought it's not any different from looking at
/sys/kernel/debug/tracing/trace directly. Apparently I was wrong. 'cat
/sys/kernel/debug/tracing/trace' seems to be OK, e.g.:

 qemu-system-x86-20263 [006]  75982.292657: kvm_nested_vmexit: vcpu 0 
reason hypercall rip 0x40122f info1 0x info2 0x 
intr_info 0x error_code 0x

-- 
Vitaly

Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

[Daniel Vetter]

On Tue, Jul 21, 2020 at 2:59 PM Melissa Wen  wrote:
>
> Hi all,
>
> I traced the subtests' execution to figure out what happens (or not) in
> a clean run and a blocked run, and this led me to suspect the
> vkms_crtc_atomic_flush function. Examining the code and considering the
> DRM doc, it seemed to me that a drm_crtc_vblank_get call was missing a
> drm_crtc_vblank_put pair. So I checked it that way, and again, the
> problem of sequential execution + dpms/suspend failures disappeared.
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..f60bf1495306 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -240,30 +240,31 @@ static void vkms_crtc_atomic_flush(struct drm_crtc 
> *crtc,
> spin_lock(>dev->event_lock);
>
> if (drm_crtc_vblank_get(crtc) != 0)
> drm_crtc_send_vblank_event(crtc, crtc->state->event);
> else
> drm_crtc_arm_vblank_event(crtc, crtc->state->event);
>
> spin_unlock(>dev->event_lock);
>
> crtc->state->event = NULL;
> }
>
> vkms_output->composer_state = to_vkms_crtc_state(crtc->state);
>
> spin_unlock_irq(_output->lock);
> +   drm_crtc_vblank_put(crtc);
>  }
>
> However, I'm not sure if it's just another duck-tape proposal or if it
> makes any sense. I'm still investigating better, but I think sharing
> with you may be more productive.

Wow nice find, really great debug work! And checking history, this bug
was there from the beginning. Now I have questions why this never
really blew up before ...

For the patch just a small fix needed, the put needs to be moved into
the if block. Otherwise we call _put() without calling _get(), and
that's also not good. Then just wrap it into a nice patch with the
commit message explaining the entire debug story (i.e. all the
evidence that lead you to this) and we should be good to go.

I'm still not really clear on why this breaks stuff when re-enabling
the crtc ...
-Daniel

> Melissa
>
> On 07/21, Daniel Vetter wrote:
> > On Tue, Jul 21, 2020 at 05:33:00AM +, Sidong Yang wrote:
> > > Hi, Daniel and Melissa
> > >
> > > I tested some code for this problem trying to find the code that make 
> > > problem in igt test.
> > > kms_cursor_crc test in igt test has 3 steps (preparation, test, cleanup). 
> > > I check each steps
> > > and I found that without cleanup step, the problem solved.
> > > In cleanup step, igt test code seems like this.
> > >
> > > drmModeSetCrtc(display->drm_fd, crtc_id, 0 /* fb_id */, 0,
> > > 0 /* x, y */, NULL /* connector */, 0, NULL /* mode */)
> > >
> > > I commented out this function call and there is no problem in executing 
> > > tests repeatedly.
> > > I'm trying to find out what's happen in this call. but don't know until 
> > > now
> > > I hope this information help to solve the problem.
> >
> > Ah yes that fits the evidence we have from Melissa pretty well: Not
> > turning off the CRTC means the next test wont have to turn it back on
> > again. And the vblank bug seems to be in the code which turns the crtc
> > back on. At least inserting a vblank wait in there is enough to paper over
> > all the issues, per Melissa's testing.
> >
> > So at least we're now fairly confident where the bug is, that's some solid
> > progress.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3] lib: overflow_kunit: add KUnit test conversion of check_*_overflow

[kernel test robot]

Hi Vitor,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on c63d2dd7e134ebddce4745c51f9572b3f0d92b26]

url:
https://github.com/0day-ci/linux/commits/Vitor-Massaru-Iha/lib-overflow_kunit-add-KUnit-test-conversion-of-check_-_overflow/20200721-064712
base:c63d2dd7e134ebddce4745c51f9572b3f0d92b26
config: x86_64-randconfig-c002-20200719 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> WARNING: modpost: lib/overflow_kunit.o(.data+0x0): Section mismatch in 
>> reference from the variable suites to the variable 
>> .init.data:overflow_test_suite
   The variable suites references
   the variable __initdata overflow_test_suite
   If the reference is valid then annotate the
   variable with or __refdata (see linux/init.h) or name the variable:
   

---
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 v4 0/6] media: v4l2: Add extended fmt and buffer ioctls

[Helen Koike]

Hi Boris,

On 7/21/20 8:15 AM, Boris Brezillon wrote:
> Hello Helen,
> 
> Just a few drive-by comments.
> 
> On Fri, 17 Jul 2020 08:54:29 -0300
> Helen Koike  wrote:
> 
>> Hi,
>>
>> I'm sorry for taking too long to submit v4.
>>
>> It is not perfect, not all v4l2-compliance tests passes, but I'd like a 
>> review,
>> specially on the API and potential problems, so I can focus on improving 
>> implementation
>> and maybe drop the RFC tag for next version.
>>
>> Follow below what changed in v4 and some items I'd like to discuss:
>>
>>
>> * Ioctl to replace v4l2_pix_format
>> -
>> During last media summit, we agreed to create ioctls that replace the 
>> v4l2_pix_format
>> struct and leave the other structs in the v4l2_format union alone.
>> Thus I refactored the code to receive struct v4l2_ext_pix_format, and I 
>> renamed the
>> ioctls, so now we have:
>>
>> int ioctl(int fd, VIDIOC_G_EXT_FMT, struct v4l2_ext_pix_format *argp);
> 
> Maybe use the EXT_PIX_FMT suffix here since the struct is really only
> about pixel formats.

Sorry, this is a copy error, I'm already using this suffix in the code, 
except for the ioctls
that handle buffers (since they get v4l2_ext_buffer struct).

Regards,
Helen

> 
>> int ioctl(int fd, VIDIOC_S_EXT_FMT, struct v4l2_ext_pix_format *argp);
>> int ioctl(int fd, VIDIOC_TRY_EXT_FMT, struct v4l2_ext_pix_format *argp);
>>
>> The only valid types are V4L2_BUF_TYPE_VIDEO_CAPTURE and 
>> V4L2_BUF_TYPE_VIDEO_OUTPUT,
>> all the other types are invalid with this API.
>>
> 
> [...]
> 
>>
>>
>> Boris Brezillon (5):
>>   media: v4l2: Extend pixel formats to unify single/multi-planar
>> handling (and more)
>>   media: videobuf2: Expose helpers to implement the _ext_fmt and
>> _ext_buf hooks
>>   media: mediabus: Add helpers to convert a ext_pix format to/from a
>> mbus_fmt
>>   media: vivid: Convert the capture and output drivers to
>> EXT_FMT/EXT_BUF
>>   media: vimc: Implement the ext_fmt and ext_buf hooks
> 
> I think you should take ownership of these patches. The end result is
> likely to be completely different from what I initially posted, and
> you're the one doing the hard work here.
> 
>>
>> Hans Verkuil (1):
>>   media: v4l2: Add extended buffer operations
>>
>>  .../media/common/videobuf2/videobuf2-core.c   |   2 +
>>  .../media/common/videobuf2/videobuf2-v4l2.c   | 549 +-
>>  .../media/test-drivers/vimc/vimc-capture.c|  61 +-
>>  drivers/media/test-drivers/vimc/vimc-common.c |   6 +-
>>  drivers/media/test-drivers/vimc/vimc-common.h |   2 +-
>>  drivers/media/test-drivers/vivid/vivid-core.c |  70 +-
>>  .../test-drivers/vivid/vivid-touch-cap.c  |  26 +-
>>  .../test-drivers/vivid/vivid-touch-cap.h  |   3 +-
>>  .../media/test-drivers/vivid/vivid-vid-cap.c  | 169 +---
>>  .../media/test-drivers/vivid/vivid-vid-cap.h  |  15 +-
>>  .../media/test-drivers/vivid/vivid-vid-out.c  | 193 ++--
>>  .../media/test-drivers/vivid/vivid-vid-out.h  |  15 +-
>>  drivers/media/v4l2-core/v4l2-dev.c|  50 +-
>>  drivers/media/v4l2-core/v4l2-ioctl.c  | 934 --
>>  include/media/v4l2-ioctl.h|  60 ++
>>  include/media/v4l2-mediabus.h |  42 +
>>  include/media/videobuf2-core.h|   6 +-
>>  include/media/videobuf2-v4l2.h|  21 +-
>>  include/uapi/linux/videodev2.h| 144 +++
>>  19 files changed, 1650 insertions(+), 718 deletions(-)
>>
> 

Re: [PATCH v4 2/6] media: v4l2: Add extended buffer operations

[Helen Koike]

Hi,

On 7/21/20 8:26 AM, Stanimir Varbanov wrote:
> 
> 
> On 7/17/20 2:54 PM, Helen Koike wrote:
>> From: Hans Verkuil 
>>
>> Those extended buffer ops have several purpose:
>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting
>>the number of ns elapsed since 1970
>> 2/ Unify single/multiplanar handling
>> 3/ Add a new start offset field to each v4l2 plane buffer info struct
>>to support the case where a single buffer object is storing all
>>planes data, each one being placed at a different offset
>>
>> New hooks are created in v4l2_ioctl_ops so that drivers can start using
>> these new objects.
>>
>> The core takes care of converting new ioctls requests to old ones
>> if the driver does not support the new hooks, and vice versa.
>>
>> Note that the timecode field is gone, since there doesn't seem to be
>> in-kernel users. We can be added back in the reserved area if needed or
>> use the Request API to collect more metadata information from the
>> frame.
>>
>> Signed-off-by: Hans Verkuil 
>> Signed-off-by: Boris Brezillon 
>> Signed-off-by: Helen Koike 
>> ---
>> Changes in v4:
>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
>> I think we can add this later, so I removed it from this RFC to simplify it.
>> - Remove num_planes field from struct v4l2_ext_buffer
>> - Add flags field to struct v4l2_ext_create_buffers
>> - Reformulate struct v4l2_ext_plane
>> - Fix some bugs caught by v4l2-compliance
>> - Rebased on top of media/master (post 5.8-rc1)
>>
>> Changes in v3:
>> - Rebased on top of media/master (post 5.4-rc1)
>>
>> Changes in v2:
>> - Add reserved space to v4l2_ext_buffer so that new fields can be added
>>   later on
>> ---
>>  drivers/media/v4l2-core/v4l2-dev.c   |  29 ++-
>>  drivers/media/v4l2-core/v4l2-ioctl.c | 349 +--
>>  include/media/v4l2-ioctl.h   |  26 ++
>>  include/uapi/linux/videodev2.h   |  89 +++
>>  4 files changed, 471 insertions(+), 22 deletions(-)
>>
> 
> 
> 
>> +/**
>> + * struct v4l2_ext_plane - extended plane buffer info
>> + * @buffer_length:  size of the entire buffer in bytes, should fit
>> + *  @offset + @plane_length
>> + * @plane_length:   size of the plane in bytes.
>> + * @userptr:when memory is V4L2_MEMORY_USERPTR, a userspace 
>> pointer pointing
>> + *  to this plane.
>> + * @dmabuf_fd:  when memory is V4L2_MEMORY_DMABUF, a userspace 
>> file descriptor
>> + *  associated with this plane.
>> + * @offset: offset in the memory buffer where the plane starts. If
>> + *  V4L2_MEMORY_MMAP is used, then it can be a "cookie" that
>> + *  should be passed to mmap() called on the video node.
>> + * @reserved:   extra space reserved for future fields, must be 
>> set to 0.
>> + *
>> + *
>> + * Buffers consist of one or more planes, e.g. an YCbCr buffer with two 
>> planes
>> + * can have one plane for Y, and another for interleaved CbCr components.
>> + * Each plane can reside in a separate memory buffer, or even in
>> + * a completely separate memory node (e.g. in embedded devices).
>> + */
>> +struct v4l2_ext_plane {
>> +__u32 buffer_length;
>> +__u32 plane_length;
>> +union {
>> +__u64 userptr;
>> +__s32 dmabuf_fd;
>> +} m;
>> +__u32 offset;
>> +__u32 reserved[4];
>> +};
>> +
>>  /**
>>   * struct v4l2_buffer - video buffer info
>>   * @index:  id number of the buffer
>> @@ -1055,6 +1086,36 @@ struct v4l2_buffer {
>>  };
>>  };
>>  
>> +/**
>> + * struct v4l2_ext_buffer - extended video buffer info
>> + * @index:  id number of the buffer
>> + * @type:   V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT
>> + * @flags:  buffer informational flags
>> + * @field:  enum v4l2_field; field order of the image in the buffer
>> + * @timestamp:  frame timestamp
>> + * @sequence:   sequence count of this frame
>> + * @memory: enum v4l2_memory; the method, in which the actual video data is
>> + *  passed
>> + * @planes: per-plane buffer information
>> + * @request_fd: fd of the request that this buffer should use
>> + * @reserved:   extra space reserved for future fields, must be set to 0
>> + *
>> + * Contains data exchanged by application and driver using one of the 
>> Streaming
>> + * I/O methods.
>> + */
>> +struct v4l2_ext_buffer {
>> +__u32 index;
>> +__u32 type;
>> +__u32 flags;
>> +__u32 field;
>> +__u64 timestamp;
>> +__u32 sequence;
>> +__u32 memory;
>> +__u32 request_fd;
> 
> This should be __s32, at least for consistency with dmabuf_fd?

I see that in struct v4l2_buffer, we have __s32, I don't mind changing it
to keep the 

Re: [PATCH 1/1] video: backlight: cr_bllcd: Remove unused variable 'intensity'

[Daniel Thompson]

On Tue, Jul 21, 2020 at 08:39:19AM +0100, Lee Jones wrote:
> Fixes the following kernel build warning:
> 
>  drivers/video/backlight/cr_bllcd.c: In function ‘cr_backlight_set_intensity’:
>  drivers/video/backlight/cr_bllcd.c:62:6: warning: unused variable 
> ‘intensity’ [-Wunused-variable]
>  62 | int intensity = bd->props.brightness;
>  | ^
> 
> Cc: Sam Ravnborg 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Fixes: 24d34617c24f ("backlight: cr_bllcd: Introduce gpio-backlight 
> semantics")
> Signed-off-by: Lee Jones 

I doubt you are awaiting this for a one line fixup... but just in case:

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH v16 16/22] mm/mlock: reorder isolation sequence during munlock

[Alex Shi]

在 2020/7/21 下午5:26, Alex Shi 写道:
> 
> 
> 在 2020/7/21 上午2:51, Alexander Duyck 写道:
>>> Look into the __split_huge_page_tail, there is a tiny gap between tail page
>>> get PG_mlocked, and it is added into lru list.
>>> The TestClearPageLRU could blocked memcg changes of the page from stopping
>>> isolate_lru_page.
>> I get that there is a gap between the two in __split_huge_page_tail.
>> My concern is more the fact that you are pulling the bit testing
>> outside of the locked region when I don't think it needs to be. The
>> lock is being taken unconditionally, so why pull the testing out when
>> you could just do it inside the lock anyway? My worry is that you
>> might be addressing __split_huge_page_tail but in the process you
>> might be introducing a new race with something like
>> __pagevec_lru_add_fn.
> 
> Yes, the page maybe interfered by clear_page_mlock and add pages to wrong lru
> list.
> 
>>
>> If I am not mistaken the Mlocked flag can still be cleared regardless
>> of if the LRU bit is set or not. So you can still clear the LRU bit
>> before you pull the page out of the list, but it can be done after
>> clearing the Mlocked flag instead of before you have even taken the
>> LRU lock. In that way it would function more similar to how you
>> handled pagevec_lru_move_fn() as all this function is really doing is
>> moving the pages out of the unevictable list into one of the other LRU
>> lists anyway since the Mlocked flag was cleared.
>>
> 
> Without the lru bit guard, the page may be moved between memcgs, luckly,
> lock_page would stop the mem_cgroup_move_account with BUSY state cost.
> whole new change would like the following, I will testing/resend again.
> 

Hi Johannes,

It looks like lock_page_memcg() could be used to replace lock_page(), which
could change retry into spinlock wait. Would you like to give some comments?

Thank
Alex
> Thanks!
> Alex
> 
> @@ -182,7 +179,7 @@ static void __munlock_isolation_failed(struct page *page)
>  unsigned int munlock_vma_page(struct page *page)
>  {
> int nr_pages;
> -   pg_data_t *pgdat = page_pgdat(page);
> +   struct lruvec *lruvec;
> 
> /* For try_to_munlock() and to serialize with page migration */
> BUG_ON(!PageLocked(page));
> @@ -190,11 +187,11 @@ unsigned int munlock_vma_page(struct page *page)
> VM_BUG_ON_PAGE(PageTail(page), page);
> 
> /*
> -* Serialize with any parallel __split_huge_page_refcount() which
> +* Serialize split tail pages in __split_huge_page_tail() which
>  * might otherwise copy PageMlocked to part of the tail pages before
>  * we clear it in the head page. It also stabilizes hpage_nr_pages().
>  */
> -   spin_lock_irq(>lru_lock);
> +   lruvec = lock_page_lruvec_irq(page);
> 
> if (!TestClearPageMlocked(page)) {
> /* Potentially, PTE-mapped THP: do not skip the rest PTEs */
> @@ -205,15 +202,15 @@ unsigned int munlock_vma_page(struct page *page)
> nr_pages = hpage_nr_pages(page);
> __mod_zone_page_state(page_zone(page), NR_MLOCK, -nr_pages);
> 
> -   if (__munlock_isolate_lru_page(page, true)) {
> -   spin_unlock_irq(>lru_lock);
> +   if (__munlock_isolate_lru_page(page, lruvec, true)) {
> +   unlock_page_lruvec_irq(lruvec);
> __munlock_isolated_page(page);
> goto out;
> }
> __munlock_isolation_failed(page);
> 
>  unlock_out:
> -   spin_unlock_irq(>lru_lock);
> +   unlock_page_lruvec_irq(lruvec);
> 
>  out:
> return nr_pages - 1;
> @@ -293,23 +290,27 @@ static void __munlock_pagevec(struct pagevec *pvec, 
> struct zone *zone)
> int nr = pagevec_count(pvec);
> int delta_munlocked = -nr;
> struct pagevec pvec_putback;
> +   struct lruvec *lruvec = NULL;
> int pgrescued = 0;
> 
> pagevec_init(_putback);
> 
> /* Phase 1: page isolation */
> -   spin_lock_irq(>zone_pgdat->lru_lock);
> for (i = 0; i < nr; i++) {
> struct page *page = pvec->pages[i];
> 
> +   /* block memcg change in mem_cgroup_move_account */
> +   lock_page(page);
> +   lruvec = relock_page_lruvec_irq(page, lruvec);
> if (TestClearPageMlocked(page)) {
> /*
>  * We already have pin from follow_page_mask()
>  * so we can spare the get_page() here.
>  */
> -   if (__munlock_isolate_lru_page(page, false))
> +   if (__munlock_isolate_lru_page(page, lruvec, false)) {
> +   unlock_page(page);
> continue;
> -   else
> +   } else
> __munlock_isolation_failed(page);
> } else {
> delta_munlocked++;
> @@ -321,11 

Do note that your e-mail box account urgently needs to be verify now

[Felipe Francisco Romero Ruiz]

MICROSOFT URGENT NOTIFICATION

Do note that your e-mail box account urgently needs to be verify now in other 
to release about 20 of your incoming messages that has been currently 
suspended.Do click on the verify below to verify your account now.


VERIFY 


Microsoft Verification Team


Copyright © 2020 Microsoft .Inc . All rights reserved.

Re: [PATCH] clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4

[Daniel Lezcano]

On 21/07/2020 15:11, Carlos Hernandez wrote:
> 
> On 7/17/20 6:29 AM, Daniel Lezcano wrote:
>> On 13/07/2020 18:26, Tony Lindgren wrote:
>>> Carlos Hernandez  reported that we now have a suspend and
>>> resume regresssion on am3 and am4 compared to the earlier kernels. While
>>> suspend and resume works with v5.8-rc3, we now get errors with rtcwake:
>>>
>>> pm33xx pm33xx: PM: Could not transition all powerdomains to target state
>>> ...
>>> rtcwake: write error
>>>
>>> This is because we now fail to idle the system timer clocks that the
>>> idle code checks and the error gets propagated to the rtcwake.
>>>
>>> Turns out there are several issues that need to be fixed:
>>>
>>> 1. Ignore no-idle and no-reset configured timers for the ti-sysc
>>>     interconnect target driver as otherwise it will keep the system
>>> timer
>>>     clocks enabled
>>>
>>> 2. Toggle the system timer functional clock for suspend for am3 and am4
>>>     (but not for clocksource on am3)
>>>
>>> 3. Only reconfigure type1 timers in dmtimer_systimer_disable()
>>>
>>> 4. Use of_machine_is_compatible() instead of of_device_is_compatible()
>>>     for checking the SoC type
>>>
>>> Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent
>>> and clocksource support")
>>> Reported-by: Carlos Hernandez 
>>> Signed-off-by: Tony Lindgren 
>>> ---
> 
> Tested-by: Carlos Hernandez 

Thanks

>> Carlos, were you able to test this patch ?
>>


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH] MIPS: OCTEON: add missing put_device() call in dwc3_octeon_device_init()

[Yu Kuai]

if of_find_device_by_node() succeed, dwc3_octeon_device_init() doesn't have
a corresponding put_device(). Thus add put_device() to fix the exception
handling for this function implementation.

Fixes: 93e502b3c2d4 ("MIPS: OCTEON: Platform support for OCTEON III USB 
controller")
Signed-off-by: Yu Kuai 
---
 arch/mips/cavium-octeon/octeon-usb.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/cavium-octeon/octeon-usb.c 
b/arch/mips/cavium-octeon/octeon-usb.c
index 1fd85c559700..950e6c6e8629 100644
--- a/arch/mips/cavium-octeon/octeon-usb.c
+++ b/arch/mips/cavium-octeon/octeon-usb.c
@@ -518,6 +518,7 @@ static int __init dwc3_octeon_device_init(void)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
+   put_device(>dev);
dev_err(>dev, "No memory resources\n");
return -ENXIO;
}
@@ -529,8 +530,10 @@ static int __init dwc3_octeon_device_init(void)
 * know the difference.
 */
base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(base))
+   if (IS_ERR(base)) {
+   put_device(>dev);
return PTR_ERR(base);
+   }
 
mutex_lock(_octeon_clocks_mutex);
dwc3_octeon_clocks_start(>dev, (u64)base);
-- 
2.25.4

Re: [PATCH 0/7] usb: bdc: Updates and fixes to the USB BDC driver

[Alan Cooper]

On Tue, Jul 21, 2020 at 5:33 AM Felipe Balbi  wrote:
>
>
> Hi,
>
> Al Cooper  writes:
> > Updates and fixes to the Broadcom USB BDC driver.
> >
> > Al Cooper (4):
> >   dt-bindings: usb: bdc: Update compatible strings
> >   usb: bdc: Add compatible string for new style USB DT nodes
> >   usb: bdc: Adb shows offline after resuming from S2
> >   usb: bdc: driver runs out of buffer descriptors on large ADB transfers
> >
> > Danesh Petigara (1):
> >   usb: bdc: Halt controller on suspend
> >
> > Florian Fainelli (1):
> >   usb: bdc: Use devm_clk_get_optional()
> >
> > Sasi Kumar (1):
> >   bdc: Fix bug causing crash after multiple disconnects
>
> What should we do here? There are few comments which seem
> unresolved. Are we getting a new version?

I'm resolving the comments and submitting v2 today.

Thanks
Al

>
> --
> balbi

Re: [PATCH v5 03/17] perf ftrace: add option -t/--tid to filter by thread id

[Namhyung Kim]

Hi Steve,

On Sat, Jul 18, 2020 at 4:44 AM Steven Rostedt  wrote:
>
> On Fri, 17 Jul 2020 16:34:55 -0300
> Arnaldo Carvalho de Melo  wrote:
>
> Thinking a bit more, I have to ask. Does perf use the kernel when
> getting all the children of an existing task, or is that done only in
> userspace?
>
> That is, is there a perf syscall that says "start tracing this task and
> all its existing children"?
>
> Or is it done by perf user space looking at the /proc filesystem (like
> ps does).

Yep, perf does look up the /proc to get a list of threads in a process.

Thanks
Namhyung


>
> I'm asking because if perf has a syscall to do that, then I probably
> should add a way to do that with ftrace as well. But that's really
> trivial, because all it would take is grabbing the task_list lock and
> iterating over all the children. Getting new children was the
> non-trivial part, which was what I focused on (with the fork options).
>
> If perf does it with proc files, then we don't need to change anything
> as that could still be used with ftrace.
>
> > Changbin, you can take from here :-)
> >
> > And to reiterate, for me the value of 'perf ftrace' is to allow people
> > used to perf to be able to switch to ftrace quickly, just changing:
> >
> >perf record/top/stat/trace/report/script/etc --pid 1234
> >
> > by:
> >
> >perf ftrace --pid 1234
> >
> > And have the tracefs ftrace knobs set up to have what is expected in
> > terms of targets to trace as the other perf tools.
> >
> > And not just --pid and --tid, but --cgroup, --cpu, etc.
> >
> > i.e., 'perf ftrace' being _a_ front-end aplication to ftrace.
> >
> > :-)
>
>
> I have no problem with this, and I'm quite excited about it. I would
> like it to use libtracefs, as it looks to be exactly what we are
> working on. And this is now a high priority to get out, and I don't
> expect another year (or two) in doing so ;-)
>
> -- Steve

[PATCH] ARM: socfpga: PM: add missing put_device() call in socfpga_setup_ocram_self_refresh()

[Yu Kuai]

if of_find_device_by_node() succeed, socfpga_setup_ocram_self_refresh
doesn't have a corresponding put_device(). Thus add a jump target to
fix the exception handling for this function implementation.

Fixes: 44fd8c7d4005 ("ARM: socfpga: support suspend to ram")
Signed-off-by: Yu Kuai 
---
 arch/arm/mach-socfpga/pm.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-socfpga/pm.c b/arch/arm/mach-socfpga/pm.c
index 6ed887cf8dc9..365c0428b21b 100644
--- a/arch/arm/mach-socfpga/pm.c
+++ b/arch/arm/mach-socfpga/pm.c
@@ -49,14 +49,14 @@ static int socfpga_setup_ocram_self_refresh(void)
if (!ocram_pool) {
pr_warn("%s: ocram pool unavailable!\n", __func__);
ret = -ENODEV;
-   goto put_node;
+   goto put_device;
}
 
ocram_base = gen_pool_alloc(ocram_pool, socfpga_sdram_self_refresh_sz);
if (!ocram_base) {
pr_warn("%s: unable to alloc ocram!\n", __func__);
ret = -ENOMEM;
-   goto put_node;
+   goto put_device;
}
 
ocram_pbase = gen_pool_virt_to_phys(ocram_pool, ocram_base);
@@ -67,7 +67,7 @@ static int socfpga_setup_ocram_self_refresh(void)
if (!suspend_ocram_base) {
pr_warn("%s: __arm_ioremap_exec failed!\n", __func__);
ret = -ENOMEM;
-   goto put_node;
+   goto put_device;
}
 
/* Copy the code that puts DDR in self refresh to ocram */
@@ -81,6 +81,8 @@ static int socfpga_setup_ocram_self_refresh(void)
if (!socfpga_sdram_self_refresh_in_ocram)
ret = -EFAULT;
 
+put_device:
+   put_device(>dev);
 put_node:
of_node_put(np);
 
-- 
2.25.4

Re: [PATCH net-next 3/7] net: macb: parse PHY nodes found under an MDIO node

[Codrin.Ciubotariu]

On 21.07.2020 16:36, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> content is safe
> 
>> @@ -755,7 +765,6 @@ static int macb_mdiobus_register(struct macb *bp)
>> * decrement it before returning.
>> */
>>of_node_put(child);
>> -
>>return of_mdiobus_register(bp->mii_bus, np);
>>}
> 
> Please avoid white space changes like this.

Sorry about this, it was not intended. Will fix in v2. Thanks!

> 
> Otherwise this looks O.K.
> 
> Andrew
> 

Re: [PATCH net-next 2/7] macb: bindings doc: use an MDIO node as a container for PHY nodes

[Codrin.Ciubotariu]

On 21.07.2020 16:29, Alexandre Belloni wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> content is safe
> 
> Hi,
> 
> The proper subject prefix is dt-bindings: net: macb:

Will fix in v2. Thanks!

> 
> On 21/07/2020 13:02:29+0300, Codrin Ciubotariu wrote:
>> The MACB driver embeds an MDIO bus controller and for this reason there
>> was no need for an MDIO sub-node present to contain the PHY nodes. Adding
>> MDIO devies directly under an Ethernet node is deprecated, so an MDIO node
>> is included to contain of the PHY nodes (and other MDIO devices' nodes).
>>
>> Signed-off-by: Codrin Ciubotariu 
>> ---
>>   Documentation/devicetree/bindings/net/macb.txt | 15 ---
>>   1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/macb.txt 
>> b/Documentation/devicetree/bindings/net/macb.txt
>> index 0b61a90f1592..88d5199c2279 100644
>> --- a/Documentation/devicetree/bindings/net/macb.txt
>> +++ b/Documentation/devicetree/bindings/net/macb.txt
>> @@ -32,6 +32,11 @@ Required properties:
>>   The MAC address will be determined using the optional properties
>>   defined in ethernet.txt.
>>
>> +Optional subnodes:
>> +- mdio : specifies the MDIO bus in the MACB, used as a container for PHY 
>> nodes or other
>> +  nodes of devices present on the MDIO bus. Please see ethernet-phy.yaml in 
>> the same
>> +  directory for more details.
>> +
>>   Optional properties for PHY child node:
>>   - reset-gpios : Should specify the gpio for phy reset
>>   - magic-packet : If present, indicates that the hardware supports waking
>> @@ -48,8 +53,12 @@ Examples:
>>local-mac-address = [3a 0e 03 04 05 06];
>>clock-names = "pclk", "hclk", "tx_clk";
>>clocks = < 30>, < 30>, < 13>;
>> - ethernet-phy@1 {
>> - reg = <0x1>;
>> - reset-gpios = < 6 1>;
>> + mdio {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + ethernet-phy@1 {
>> + reg = <0x1>;
>> + reset-gpios = < 6 1>;
>> + };
>>};
>>};
>> --
>> 2.25.1
>>
> 
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>