Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks
On (06/22/18 17:21), Alan Cox wrote: > On Wed, 20 Jun 2018 11:44:13 +0900 > Linus Torvalds wrote: > > > On Wed, Jun 20, 2018 at 11:34 AM Steven Rostedt wrote: > > > > > > Perhaps we should do an audit of the console drivers and remove all > > > printk, pr_* , WARN*, BUG* from them. > > > > Only the actual _printing_ parts. > > No because they are normally rather useful because that port isn't the > console. If you trylock trylock is boring, me wants printk_safe_mask everywhere :) > Really that's all that you need - log the message to whichever console > targets you can currently safely do so. If it's none well there was > always the proposed morse code keyboard light driver 8) Hm, just discard messages? With printk_safe_mask we keep everything in a lockless per-CPU buffer, which we flush [per-CPU buffer -> printk logbuf] from irq_work, so we can print it later. -ss
Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks
On (06/22/18 17:21), Alan Cox wrote: > On Wed, 20 Jun 2018 11:44:13 +0900 > Linus Torvalds wrote: > > > On Wed, Jun 20, 2018 at 11:34 AM Steven Rostedt wrote: > > > > > > Perhaps we should do an audit of the console drivers and remove all > > > printk, pr_* , WARN*, BUG* from them. > > > > Only the actual _printing_ parts. > > No because they are normally rather useful because that port isn't the > console. If you trylock trylock is boring, me wants printk_safe_mask everywhere :) > Really that's all that you need - log the message to whichever console > targets you can currently safely do so. If it's none well there was > always the proposed morse code keyboard light driver 8) Hm, just discard messages? With printk_safe_mask we keep everything in a lockless per-CPU buffer, which we flush [per-CPU buffer -> printk logbuf] from irq_work, so we can print it later. -ss
[PATCH v2 3/3] pinctrl: actions: Add interrupt support for OWL S900 SoC
Add interrupt support for Actions Semi OWL S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
drivers/pinctrl/actions/Kconfig| 1 +
drivers/pinctrl/actions/pinctrl-owl.c | 271 -
drivers/pinctrl/actions/pinctrl-owl.h | 22 +-
drivers/pinctrl/actions/pinctrl-s900.c | 31 +--
4 files changed, 307 insertions(+), 18 deletions(-)
diff --git a/drivers/pinctrl/actions/Kconfig b/drivers/pinctrl/actions/Kconfig
index 490927b4ea76..2397cb0f6011 100644
--- a/drivers/pinctrl/actions/Kconfig
+++ b/drivers/pinctrl/actions/Kconfig
@@ -5,6 +5,7 @@ config PINCTRL_OWL
select PINCONF
select GENERIC_PINCONF
select GPIOLIB
+ select GPIOLIB_IRQCHIP
help
Say Y here to enable Actions Semi OWL pinctrl driver
diff --git a/drivers/pinctrl/actions/pinctrl-owl.c
b/drivers/pinctrl/actions/pinctrl-owl.c
index 76243caa08c6..ce032d71dad5 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.c
+++ b/drivers/pinctrl/actions/pinctrl-owl.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,9 @@ struct owl_pinctrl {
struct clk *clk;
const struct owl_pinctrl_soc_data *soc;
void __iomem *base;
+ struct irq_chip irq_chip;
+ unsigned int num_irq;
+ unsigned int *irq;
};
static void owl_update_bits(void __iomem *base, u32 mask, u32 val)
@@ -701,10 +705,213 @@ static int owl_gpio_direction_output(struct gpio_chip
*chip,
return 0;
}
+static void irq_set_type(struct owl_pinctrl *pctrl, int gpio, unsigned int
type)
+{
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+ unsigned int offset, value, irq_type = 0;
+
+ switch (type) {
+ case IRQ_TYPE_EDGE_BOTH:
+ /*
+* Since the hardware doesn't support interrupts on both edges,
+* emulate it in the software by setting the single edge
+* interrupt and switching to the opposite edge while ACKing
+* the interrupt
+*/
+ if (owl_gpio_get(>chip, gpio))
+ irq_type = OWL_GPIO_INT_EDGE_FALLING;
+ else
+ irq_type = OWL_GPIO_INT_EDGE_RISING;
+ break;
+
+ case IRQ_TYPE_EDGE_RISING:
+ irq_type = OWL_GPIO_INT_EDGE_RISING;
+ break;
+
+ case IRQ_TYPE_EDGE_FALLING:
+ irq_type = OWL_GPIO_INT_EDGE_FALLING;
+ break;
+
+ case IRQ_TYPE_LEVEL_HIGH:
+ irq_type = OWL_GPIO_INT_LEVEL_HIGH;
+ break;
+
+ case IRQ_TYPE_LEVEL_LOW:
+ irq_type = OWL_GPIO_INT_LEVEL_LOW;
+ break;
+
+ default:
+ break;
+ }
+
+ port = owl_gpio_get_port(pctrl, );
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(>lock, flags);
+
+ offset = (gpio < 16) ? 4 : 0;
+ value = readl_relaxed(gpio_base + port->intc_type + offset);
+ value &= ~(OWL_GPIO_INT_MASK << ((gpio % 16) * 2));
+ value |= irq_type << ((gpio % 16) * 2);
+ writel_relaxed(value, gpio_base + port->intc_type + offset);
+
+ raw_spin_unlock_irqrestore(>lock, flags);
+}
+
+static void owl_gpio_irq_mask(struct irq_data *data)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct owl_pinctrl *pctrl = gpiochip_get_data(gc);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+ unsigned int gpio = data->hwirq;
+ u32 val;
+
+ port = owl_gpio_get_port(pctrl, );
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(>lock, flags);
+
+ owl_gpio_update_reg(gpio_base + port->intc_msk, gpio, false);
+
+ /* disable port interrupt if no interrupt pending bit is active */
+ val = readl_relaxed(gpio_base + port->intc_msk);
+ if (val == 0)
+ owl_gpio_update_reg(gpio_base + port->intc_ctl,
+ OWL_GPIO_CTLR_ENABLE, false);
+
+ raw_spin_unlock_irqrestore(>lock, flags);
+}
+
+static void owl_gpio_irq_unmask(struct irq_data *data)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct owl_pinctrl *pctrl = gpiochip_get_data(gc);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+ unsigned int gpio = data->hwirq;
+ u32 value;
+
+ port = owl_gpio_get_port(pctrl, );
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+ raw_spin_lock_irqsave(>lock, flags);
+
+ /* enable port interrupt */
+ value = readl_relaxed(gpio_base + port->intc_ctl);
+ value |=
[PATCH v2 3/3] pinctrl: actions: Add interrupt support for OWL S900 SoC
Add interrupt support for Actions Semi OWL S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
drivers/pinctrl/actions/Kconfig| 1 +
drivers/pinctrl/actions/pinctrl-owl.c | 271 -
drivers/pinctrl/actions/pinctrl-owl.h | 22 +-
drivers/pinctrl/actions/pinctrl-s900.c | 31 +--
4 files changed, 307 insertions(+), 18 deletions(-)
diff --git a/drivers/pinctrl/actions/Kconfig b/drivers/pinctrl/actions/Kconfig
index 490927b4ea76..2397cb0f6011 100644
--- a/drivers/pinctrl/actions/Kconfig
+++ b/drivers/pinctrl/actions/Kconfig
@@ -5,6 +5,7 @@ config PINCTRL_OWL
select PINCONF
select GENERIC_PINCONF
select GPIOLIB
+ select GPIOLIB_IRQCHIP
help
Say Y here to enable Actions Semi OWL pinctrl driver
diff --git a/drivers/pinctrl/actions/pinctrl-owl.c
b/drivers/pinctrl/actions/pinctrl-owl.c
index 76243caa08c6..ce032d71dad5 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.c
+++ b/drivers/pinctrl/actions/pinctrl-owl.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,9 @@ struct owl_pinctrl {
struct clk *clk;
const struct owl_pinctrl_soc_data *soc;
void __iomem *base;
+ struct irq_chip irq_chip;
+ unsigned int num_irq;
+ unsigned int *irq;
};
static void owl_update_bits(void __iomem *base, u32 mask, u32 val)
@@ -701,10 +705,213 @@ static int owl_gpio_direction_output(struct gpio_chip
*chip,
return 0;
}
+static void irq_set_type(struct owl_pinctrl *pctrl, int gpio, unsigned int
type)
+{
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+ unsigned int offset, value, irq_type = 0;
+
+ switch (type) {
+ case IRQ_TYPE_EDGE_BOTH:
+ /*
+* Since the hardware doesn't support interrupts on both edges,
+* emulate it in the software by setting the single edge
+* interrupt and switching to the opposite edge while ACKing
+* the interrupt
+*/
+ if (owl_gpio_get(>chip, gpio))
+ irq_type = OWL_GPIO_INT_EDGE_FALLING;
+ else
+ irq_type = OWL_GPIO_INT_EDGE_RISING;
+ break;
+
+ case IRQ_TYPE_EDGE_RISING:
+ irq_type = OWL_GPIO_INT_EDGE_RISING;
+ break;
+
+ case IRQ_TYPE_EDGE_FALLING:
+ irq_type = OWL_GPIO_INT_EDGE_FALLING;
+ break;
+
+ case IRQ_TYPE_LEVEL_HIGH:
+ irq_type = OWL_GPIO_INT_LEVEL_HIGH;
+ break;
+
+ case IRQ_TYPE_LEVEL_LOW:
+ irq_type = OWL_GPIO_INT_LEVEL_LOW;
+ break;
+
+ default:
+ break;
+ }
+
+ port = owl_gpio_get_port(pctrl, );
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(>lock, flags);
+
+ offset = (gpio < 16) ? 4 : 0;
+ value = readl_relaxed(gpio_base + port->intc_type + offset);
+ value &= ~(OWL_GPIO_INT_MASK << ((gpio % 16) * 2));
+ value |= irq_type << ((gpio % 16) * 2);
+ writel_relaxed(value, gpio_base + port->intc_type + offset);
+
+ raw_spin_unlock_irqrestore(>lock, flags);
+}
+
+static void owl_gpio_irq_mask(struct irq_data *data)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct owl_pinctrl *pctrl = gpiochip_get_data(gc);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+ unsigned int gpio = data->hwirq;
+ u32 val;
+
+ port = owl_gpio_get_port(pctrl, );
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(>lock, flags);
+
+ owl_gpio_update_reg(gpio_base + port->intc_msk, gpio, false);
+
+ /* disable port interrupt if no interrupt pending bit is active */
+ val = readl_relaxed(gpio_base + port->intc_msk);
+ if (val == 0)
+ owl_gpio_update_reg(gpio_base + port->intc_ctl,
+ OWL_GPIO_CTLR_ENABLE, false);
+
+ raw_spin_unlock_irqrestore(>lock, flags);
+}
+
+static void owl_gpio_irq_unmask(struct irq_data *data)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct owl_pinctrl *pctrl = gpiochip_get_data(gc);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+ unsigned int gpio = data->hwirq;
+ u32 value;
+
+ port = owl_gpio_get_port(pctrl, );
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+ raw_spin_lock_irqsave(>lock, flags);
+
+ /* enable port interrupt */
+ value = readl_relaxed(gpio_base + port->intc_ctl);
+ value |=
[PATCH v2 2/3] arm64: dts: actions: Add interrupt properties to pinctrl node for S900
Add interrupt properties to pinctrl node for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index aa3a49b0d646..7ae8b931f000 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -181,6 +181,14 @@
gpio-controller;
gpio-ranges = < 0 0 146>;
#gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = ,
+,
+,
+,
+,
+;
};
timer: timer@e0228000 {
--
2.17.1
[PATCH v2 0/3] Add gpio interrupt support for Actions Semi S900 SoC
This patchset adds interrupt support for Actions Semi S900 GPIO's. Each port has individual register sets for configuring the below interrupt types: 1. Rising Edge Interrupt 2. Falling Edge Interrupt 3. Software Emulation of both Edges 4. High Level Interrupt 5. Low Level Interrupt Thanks, Mani Changes in v2: * Removed custom IRQ domain implementation and used GPIO_IRQCHIP with multi parents based on gpio-tegra186.c * Added support for emulating interrupt on both edges * Added parentheses to the expression as spotted by Linus * Added Rob's Reviewed-by tag for bindings patch Manivannan Sadhasivam (3): dt-bindings: pinctrl: Add gpio interrupt bindings for Actions S900 SoC arm64: dts: actions: Add interrupt properties to pinctrl node for S900 pinctrl: actions: Add interrupt support for OWL S900 SoC .../bindings/pinctrl/actions,s900-pinctrl.txt | 10 + arch/arm64/boot/dts/actions/s900.dtsi | 8 + drivers/pinctrl/actions/Kconfig | 1 + drivers/pinctrl/actions/pinctrl-owl.c | 271 +- drivers/pinctrl/actions/pinctrl-owl.h | 22 +- drivers/pinctrl/actions/pinctrl-s900.c| 31 +- 6 files changed, 325 insertions(+), 18 deletions(-) -- 2.17.1
[PATCH v2 2/3] arm64: dts: actions: Add interrupt properties to pinctrl node for S900
Add interrupt properties to pinctrl node for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index aa3a49b0d646..7ae8b931f000 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -181,6 +181,14 @@
gpio-controller;
gpio-ranges = < 0 0 146>;
#gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = ,
+,
+,
+,
+,
+;
};
timer: timer@e0228000 {
--
2.17.1
[PATCH v2 0/3] Add gpio interrupt support for Actions Semi S900 SoC
This patchset adds interrupt support for Actions Semi S900 GPIO's. Each port has individual register sets for configuring the below interrupt types: 1. Rising Edge Interrupt 2. Falling Edge Interrupt 3. Software Emulation of both Edges 4. High Level Interrupt 5. Low Level Interrupt Thanks, Mani Changes in v2: * Removed custom IRQ domain implementation and used GPIO_IRQCHIP with multi parents based on gpio-tegra186.c * Added support for emulating interrupt on both edges * Added parentheses to the expression as spotted by Linus * Added Rob's Reviewed-by tag for bindings patch Manivannan Sadhasivam (3): dt-bindings: pinctrl: Add gpio interrupt bindings for Actions S900 SoC arm64: dts: actions: Add interrupt properties to pinctrl node for S900 pinctrl: actions: Add interrupt support for OWL S900 SoC .../bindings/pinctrl/actions,s900-pinctrl.txt | 10 + arch/arm64/boot/dts/actions/s900.dtsi | 8 + drivers/pinctrl/actions/Kconfig | 1 + drivers/pinctrl/actions/pinctrl-owl.c | 271 +- drivers/pinctrl/actions/pinctrl-owl.h | 22 +- drivers/pinctrl/actions/pinctrl-s900.c| 31 +- 6 files changed, 325 insertions(+), 18 deletions(-) -- 2.17.1
[PATCH v2 1/3] dt-bindings: pinctrl: Add gpio interrupt bindings for Actions S900 SoC
Add gpio interrupt bindings for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Rob Herring
---
.../bindings/pinctrl/actions,s900-pinctrl.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
index 8fb5a53775e8..81b583ed 100644
--- a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
@@ -19,6 +19,10 @@ Required Properties:
defines the interrupt number, the second encodes
the trigger flags described in
bindings/interrupt-controller/interrupts.txt
+- interrupts: The interrupt outputs from the controller. There is one GPIO
+ interrupt per GPIO bank. The number of interrupts listed depends
+ on the number of GPIO banks on the SoC. The interrupts must be
+ ordered by bank, starting with bank 0.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
@@ -180,6 +184,12 @@ Example:
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ;
uart2-default: uart2-default {
pinmux {
--
2.17.1
[PATCH v2 1/3] dt-bindings: pinctrl: Add gpio interrupt bindings for Actions S900 SoC
Add gpio interrupt bindings for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Rob Herring
---
.../bindings/pinctrl/actions,s900-pinctrl.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
index 8fb5a53775e8..81b583ed 100644
--- a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
@@ -19,6 +19,10 @@ Required Properties:
defines the interrupt number, the second encodes
the trigger flags described in
bindings/interrupt-controller/interrupts.txt
+- interrupts: The interrupt outputs from the controller. There is one GPIO
+ interrupt per GPIO bank. The number of interrupts listed depends
+ on the number of GPIO banks on the SoC. The interrupts must be
+ ordered by bank, starting with bank 0.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
@@ -180,6 +184,12 @@ Example:
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ;
uart2-default: uart2-default {
pinmux {
--
2.17.1
Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode
On Fri, Jun 22, 2018 at 12:49:00PM +0200, Thomas Gleixner wrote:
> On Sun, 27 May 2018, Fenghua Yu wrote:
> > +static void wait_for_reexecution(void)
> > +{
> > + while (time_before(jiffies, disable_split_lock_jiffies +
> > + reenable_split_lock_delay))
> > + cpu_relax();
> > +}
> > +
> > +/*
> > + * TEST_CTL MSR is shared among threads on the same core. To simplify
> > + * situation, disable_split_lock_jiffies is global instead of per core.
>
> This patch surely earns extra points in the trainwreck engineering contest,
> but that's not taking place on LKML.
>
> The whole thing is simply:
>
> handle_ac()
> {
> if (user_mode(regs)) {
>do_trap(AC, SIGBUS, ...);
> } else {
> disable_ac_on_local_cpu();
> WARN_ONCE(1);
> }
> }
Should I add kernel parameter or control knob to opt-out the feature?
I'm afraid firmware may hang system after handling split lock if the
feature is enabled by kernel, e.g. "reboot" hits split lock in firmware
and firmware hangs the system after handling #AC.
Thanks.
-Fenghua
Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode
On Fri, Jun 22, 2018 at 12:49:00PM +0200, Thomas Gleixner wrote:
> On Sun, 27 May 2018, Fenghua Yu wrote:
> > +static void wait_for_reexecution(void)
> > +{
> > + while (time_before(jiffies, disable_split_lock_jiffies +
> > + reenable_split_lock_delay))
> > + cpu_relax();
> > +}
> > +
> > +/*
> > + * TEST_CTL MSR is shared among threads on the same core. To simplify
> > + * situation, disable_split_lock_jiffies is global instead of per core.
>
> This patch surely earns extra points in the trainwreck engineering contest,
> but that's not taking place on LKML.
>
> The whole thing is simply:
>
> handle_ac()
> {
> if (user_mode(regs)) {
>do_trap(AC, SIGBUS, ...);
> } else {
> disable_ac_on_local_cpu();
> WARN_ONCE(1);
> }
> }
Should I add kernel parameter or control knob to opt-out the feature?
I'm afraid firmware may hang system after handling split lock if the
feature is enabled by kernel, e.g. "reboot" hits split lock in firmware
and firmware hangs the system after handling #AC.
Thanks.
-Fenghua
Re: [PATCH 1/2] arm64: dts: uniphier: add headphone detect gpio for LD20 global board
2018-06-19 13:11 GMT+09:00 Katsuhiro Suzuki :
> This patch adds GPIO for headphone detection on LD20 global board.
>
> Signed-off-by: Katsuhiro Suzuki
> ---
> arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> index 6a074a20c924..38b75998e2dd 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> @@ -60,6 +60,7 @@
> _port4
> _port0
> _spdif_port0>;
> + hp-det-gpio = < UNIPHIER_GPIO_PORT(15, 0)
> GPIO_ACTIVE_LOW>;
When you use irq-capable gpio pin (XIRQ0),
please write like follows for consistency.
hp-det-gpio = < UNIPHIER_GPIO_IRQ(0) GPIO_ACTIVE_LOW>;
See uniphier-ld20-ref.dts for example.
> };
>
> spdif-out {
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
Re: [PATCH 1/2] arm64: dts: uniphier: add headphone detect gpio for LD20 global board
2018-06-19 13:11 GMT+09:00 Katsuhiro Suzuki :
> This patch adds GPIO for headphone detection on LD20 global board.
>
> Signed-off-by: Katsuhiro Suzuki
> ---
> arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> index 6a074a20c924..38b75998e2dd 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> @@ -60,6 +60,7 @@
> _port4
> _port0
> _spdif_port0>;
> + hp-det-gpio = < UNIPHIER_GPIO_PORT(15, 0)
> GPIO_ACTIVE_LOW>;
When you use irq-capable gpio pin (XIRQ0),
please write like follows for consistency.
hp-det-gpio = < UNIPHIER_GPIO_IRQ(0) GPIO_ACTIVE_LOW>;
See uniphier-ld20-ref.dts for example.
> };
>
> spdif-out {
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
Re: [PATCH] arm64: dts: uniphier: fix widget name of headphone for LD11/LD20 boards
2018-06-19 13:12 GMT+09:00 Katsuhiro Suzuki :
> This patch fixes wrong name of headphone widget for receiving events
> of insert/remove headphone plug from simple-card or audio-graph-card.
>
> If we use wrong widget name then we get warning messages such as
> "asoc-audio-graph-card sound: ASoC: DAPM unknown pin Headphones"
> when the plug is inserted or removed from headphone jack.
>
> Signed-off-by: Katsuhiro Suzuki
> ---
Applied. Thanks!
> arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 2 +-
> arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
> b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
> index e5bda40b3ec6..7cc3f6dd93d9 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
> @@ -54,7 +54,7 @@
> sound {
> compatible = "audio-graph-card";
> label = "UniPhier LD11";
> - widgets = "Headphone", "Headphone Jack";
> + widgets = "Headphone", "Headphones";
> dais = <_port2
> _port3
> _port4
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> index 38b75998e2dd..575be4ab0072 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> @@ -54,7 +54,7 @@
> sound {
> compatible = "audio-graph-card";
> label = "UniPhier LD20";
> - widgets = "Headphone", "Headphone Jack";
> + widgets = "Headphone", "Headphones";
> dais = <_port2
> _port3
> _port4
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH] arm64: dts: uniphier: fix widget name of headphone for LD11/LD20 boards
2018-06-19 13:12 GMT+09:00 Katsuhiro Suzuki :
> This patch fixes wrong name of headphone widget for receiving events
> of insert/remove headphone plug from simple-card or audio-graph-card.
>
> If we use wrong widget name then we get warning messages such as
> "asoc-audio-graph-card sound: ASoC: DAPM unknown pin Headphones"
> when the plug is inserted or removed from headphone jack.
>
> Signed-off-by: Katsuhiro Suzuki
> ---
Applied. Thanks!
> arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 2 +-
> arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
> b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
> index e5bda40b3ec6..7cc3f6dd93d9 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
> @@ -54,7 +54,7 @@
> sound {
> compatible = "audio-graph-card";
> label = "UniPhier LD11";
> - widgets = "Headphone", "Headphone Jack";
> + widgets = "Headphone", "Headphones";
> dais = <_port2
> _port3
> _port4
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> index 38b75998e2dd..575be4ab0072 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
> @@ -54,7 +54,7 @@
> sound {
> compatible = "audio-graph-card";
> label = "UniPhier LD20";
> - widgets = "Headphone", "Headphone Jack";
> + widgets = "Headphone", "Headphones";
> dais = <_port2
> _port3
> _port4
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
[PATCH] kconfig: document Kconfig source file comments
From: Randy Dunlap I saw this type of Kconfig construct on LKML: config SYMBOOL #bool "prompt string" default y and wondered what it does. Then I wondered if '#' comments are even documented. They aren't, so add a little doc for that. Ah, good. kconfig says: arch/x86/Kconfig:2942:warning: config symbol defined without type Signed-off-by: Randy Dunlap --- Documentation/kbuild/kconfig-language.txt |6 ++ 1 file changed, 6 insertions(+) --- lnx-418-rc1.orig/Documentation/kbuild/kconfig-language.txt +++ lnx-418-rc1/Documentation/kbuild/kconfig-language.txt @@ -430,6 +430,12 @@ This sets the config program's title bar to use it. It should be placed at the top of the configuration, before any other statement. +'#' Kconfig source file comment: + +An unquoted '#' character anywhere in a source file line indicates +the beginning of a source file comment. The remainder of that line +is a comment. + Kconfig hints -
[PATCH] kconfig: document Kconfig source file comments
From: Randy Dunlap I saw this type of Kconfig construct on LKML: config SYMBOOL #bool "prompt string" default y and wondered what it does. Then I wondered if '#' comments are even documented. They aren't, so add a little doc for that. Ah, good. kconfig says: arch/x86/Kconfig:2942:warning: config symbol defined without type Signed-off-by: Randy Dunlap --- Documentation/kbuild/kconfig-language.txt |6 ++ 1 file changed, 6 insertions(+) --- lnx-418-rc1.orig/Documentation/kbuild/kconfig-language.txt +++ lnx-418-rc1/Documentation/kbuild/kconfig-language.txt @@ -430,6 +430,12 @@ This sets the config program's title bar to use it. It should be placed at the top of the configuration, before any other statement. +'#' Kconfig source file comment: + +An unquoted '#' character anywhere in a source file line indicates +the beginning of a source file comment. The remainder of that line +is a comment. + Kconfig hints -
Re: [PATCH] staging: rtl8723bs: do not use assignment in if condition
On Fri, 2018-06-22 at 21:11 +0200, Michael Straube wrote: > On 06/22/18 19:28, Joe Perches wrote: > > Although the last memcpy of a fixed mac address could > > probably use eth_random_addr to reduce the likelihood > > of mac address collision so maybe > > eth_random_addr(mac_addr); > Using a random address would be preffered? mac address duplication is bad, so if there were 2 instances of this device on the same ethernet network, yes. > > Thanks for your help and patience. > Michael
Re: [PATCH] staging: rtl8723bs: do not use assignment in if condition
On Fri, 2018-06-22 at 21:11 +0200, Michael Straube wrote: > On 06/22/18 19:28, Joe Perches wrote: > > Although the last memcpy of a fixed mac address could > > probably use eth_random_addr to reduce the likelihood > > of mac address collision so maybe > > eth_random_addr(mac_addr); > Using a random address would be preffered? mac address duplication is bad, so if there were 2 instances of this device on the same ethernet network, yes. > > Thanks for your help and patience. > Michael
Re: [PATCH v4 10/12] misc: throttler: Add core support for non-thermal throttling
On Thu, Jun 21, 2018 at 07:04:33PM -0700, Brian Norris wrote:
> Hi,
>
> A few more things I noticed; probably my last thoughts on this
> particular patch; and I think I reviewed the rest:
>
> On Wed, Jun 20, 2018 at 06:52:35PM -0700, Matthias Kaehlcke wrote:
> > The purpose of the throttler is to provide support for non-thermal
> > throttling. Throttling is triggered by external event, e.g. the
> > detection of a high battery discharge current, close to the OCP limit
> > of the battery. The throttler is only in charge of the throttling, not
> > the monitoring, which is done by another (possibly platform specific)
> > driver.
> >
> > Signed-off-by: Matthias Kaehlcke
> > ---
> > Changes in v4:
> > - removed OOM logs
> > - "does have no" => "has no" in log message
> > - changed 'level' to unsigned int
> > - hold mutex in throttler_set_level() when checking if level has changed
> > - removed debugfs dir in throttler_teardown()
> > - consolidated update of all devfreq devices in thr_update_devfreq()
> > - added field 'shutting_down' to struct throttler
> > - refactored teardown to avoid deadlocks
> > - minor change in introductory comment
> >
> > Changes in v3:
> > - Kconfig: don't select CPU_FREQ and PM_DEVFREQ
> > - added CONFIG_THROTTLER_DEBUG option
> > - changed 'level' sysfs attribute to debugfs
> > - introduced thr_ macros for logging
> > - added debug logs
> > - added field clamp_freq to struct cpufreq_thrdev and devfreq_thrdev
> > to keep track of the current frequency limits and avoid spammy logs
> >
> > Changes in v2:
> > - completely reworked the driver to support configuration through OPPs,
> > which
> > requires a more dynamic handling
> > - added sysfs attribute to set the level for debugging and testing
> > - Makefile: depend on Kconfig option to traverse throttler directory
> > - Kconfig: removed 'default n'
> > - added SPDX line instead of license boiler-plate
> > - added entry to MAINTAINERS file
> > ---
> > MAINTAINERS | 7 +
> > drivers/misc/Kconfig| 1 +
> > drivers/misc/Makefile | 1 +
> > drivers/misc/throttler/Kconfig | 23 ++
> > drivers/misc/throttler/Makefile | 1 +
> > drivers/misc/throttler/core.c | 705
> > include/linux/throttler.h | 21 +
> > 7 files changed, 759 insertions(+)
> > create mode 100644 drivers/misc/throttler/Kconfig
> > create mode 100644 drivers/misc/throttler/Makefile
> > create mode 100644 drivers/misc/throttler/core.c
> > create mode 100644 include/linux/throttler.h
> >
>
> ...
>
> > diff --git a/drivers/misc/throttler/core.c b/drivers/misc/throttler/core.c
> > new file mode 100644
> > index ..305964cfb0b7
> > --- /dev/null
> > +++ b/drivers/misc/throttler/core.c
> > @@ -0,0 +1,705 @@
> > +// SPDX-License-Identifier: GPL-2.0
>
> ...
>
> > +
> > +static int thr_handle_devfreq_event(struct notifier_block *nb,
> > + unsigned long event, void *data);
> > +
> > +static unsigned long thr_get_throttling_freq(struct thr_freq_table *ft,
> > +unsigned int level)
> > +{
> > + if (level == 0) {
> > + WARN(true, "level == 0");
>
> It's possible to get here, if the level gets changed while you're
> handling a devfreq event. I'd think you can drop the WARN() entirely and
> just make sure to handle this case properly.
Right, I didn't take into account here that level could change. Will
adapt.
> > + return ULONG_MAX;
> > + }
> > +
> > + if (level <= ft->n_entries)
> > + return ft->freqs[level - 1];
> > + else
> > + return ft->freqs[ft->n_entries - 1];
> > +}
> > +
>
> ...
>
> > +static int thr_handle_cpufreq_event(struct notifier_block *nb,
> > + unsigned long event, void *data)
> > +{
> > + struct throttler *thr =
> > + container_of(nb, struct throttler, cpufreq.nb);
> > + struct cpufreq_policy *policy = data;
> > + struct cpufreq_thrdev *cftd;
> > +
> > + if ((event != CPUFREQ_ADJUST) || thr->shutting_down)
> > + return 0;
> > +
> > + mutex_lock(>lock);
> > +
> > + if (cpumask_test_cpu(policy->cpu, >cpufreq.cm_ignore))
> > + goto out;
> > +
> > + if (!cpumask_test_cpu(policy->cpu, >cpufreq.cm_initialized)) {
> > + thr_cpufreq_init(thr, policy->cpu);
> > +
> > + if (cpumask_test_cpu(policy->cpu, >cpufreq.cm_ignore))
> > + goto out;
> > +
> > + thr_dbg(thr, "CPU%d is used for throttling\n", policy->cpu);
> > + }
> > +
> > + /*
> > +* Can't do this check earlier, otherwise we might miss CPU policies
> > +* that are added after setup().
> > +*/
> > + if (thr->level == 0) {
> > + list_for_each_entry(cftd, >cpufreq.list, node) {
> > + if (cftd->cpu != policy->cpu)
> > + continue;
> > +
> > + if (cftd->clamp_freq != 0) {
> > +
Re: [PATCH v4 10/12] misc: throttler: Add core support for non-thermal throttling
On Thu, Jun 21, 2018 at 07:04:33PM -0700, Brian Norris wrote:
> Hi,
>
> A few more things I noticed; probably my last thoughts on this
> particular patch; and I think I reviewed the rest:
>
> On Wed, Jun 20, 2018 at 06:52:35PM -0700, Matthias Kaehlcke wrote:
> > The purpose of the throttler is to provide support for non-thermal
> > throttling. Throttling is triggered by external event, e.g. the
> > detection of a high battery discharge current, close to the OCP limit
> > of the battery. The throttler is only in charge of the throttling, not
> > the monitoring, which is done by another (possibly platform specific)
> > driver.
> >
> > Signed-off-by: Matthias Kaehlcke
> > ---
> > Changes in v4:
> > - removed OOM logs
> > - "does have no" => "has no" in log message
> > - changed 'level' to unsigned int
> > - hold mutex in throttler_set_level() when checking if level has changed
> > - removed debugfs dir in throttler_teardown()
> > - consolidated update of all devfreq devices in thr_update_devfreq()
> > - added field 'shutting_down' to struct throttler
> > - refactored teardown to avoid deadlocks
> > - minor change in introductory comment
> >
> > Changes in v3:
> > - Kconfig: don't select CPU_FREQ and PM_DEVFREQ
> > - added CONFIG_THROTTLER_DEBUG option
> > - changed 'level' sysfs attribute to debugfs
> > - introduced thr_ macros for logging
> > - added debug logs
> > - added field clamp_freq to struct cpufreq_thrdev and devfreq_thrdev
> > to keep track of the current frequency limits and avoid spammy logs
> >
> > Changes in v2:
> > - completely reworked the driver to support configuration through OPPs,
> > which
> > requires a more dynamic handling
> > - added sysfs attribute to set the level for debugging and testing
> > - Makefile: depend on Kconfig option to traverse throttler directory
> > - Kconfig: removed 'default n'
> > - added SPDX line instead of license boiler-plate
> > - added entry to MAINTAINERS file
> > ---
> > MAINTAINERS | 7 +
> > drivers/misc/Kconfig| 1 +
> > drivers/misc/Makefile | 1 +
> > drivers/misc/throttler/Kconfig | 23 ++
> > drivers/misc/throttler/Makefile | 1 +
> > drivers/misc/throttler/core.c | 705
> > include/linux/throttler.h | 21 +
> > 7 files changed, 759 insertions(+)
> > create mode 100644 drivers/misc/throttler/Kconfig
> > create mode 100644 drivers/misc/throttler/Makefile
> > create mode 100644 drivers/misc/throttler/core.c
> > create mode 100644 include/linux/throttler.h
> >
>
> ...
>
> > diff --git a/drivers/misc/throttler/core.c b/drivers/misc/throttler/core.c
> > new file mode 100644
> > index ..305964cfb0b7
> > --- /dev/null
> > +++ b/drivers/misc/throttler/core.c
> > @@ -0,0 +1,705 @@
> > +// SPDX-License-Identifier: GPL-2.0
>
> ...
>
> > +
> > +static int thr_handle_devfreq_event(struct notifier_block *nb,
> > + unsigned long event, void *data);
> > +
> > +static unsigned long thr_get_throttling_freq(struct thr_freq_table *ft,
> > +unsigned int level)
> > +{
> > + if (level == 0) {
> > + WARN(true, "level == 0");
>
> It's possible to get here, if the level gets changed while you're
> handling a devfreq event. I'd think you can drop the WARN() entirely and
> just make sure to handle this case properly.
Right, I didn't take into account here that level could change. Will
adapt.
> > + return ULONG_MAX;
> > + }
> > +
> > + if (level <= ft->n_entries)
> > + return ft->freqs[level - 1];
> > + else
> > + return ft->freqs[ft->n_entries - 1];
> > +}
> > +
>
> ...
>
> > +static int thr_handle_cpufreq_event(struct notifier_block *nb,
> > + unsigned long event, void *data)
> > +{
> > + struct throttler *thr =
> > + container_of(nb, struct throttler, cpufreq.nb);
> > + struct cpufreq_policy *policy = data;
> > + struct cpufreq_thrdev *cftd;
> > +
> > + if ((event != CPUFREQ_ADJUST) || thr->shutting_down)
> > + return 0;
> > +
> > + mutex_lock(>lock);
> > +
> > + if (cpumask_test_cpu(policy->cpu, >cpufreq.cm_ignore))
> > + goto out;
> > +
> > + if (!cpumask_test_cpu(policy->cpu, >cpufreq.cm_initialized)) {
> > + thr_cpufreq_init(thr, policy->cpu);
> > +
> > + if (cpumask_test_cpu(policy->cpu, >cpufreq.cm_ignore))
> > + goto out;
> > +
> > + thr_dbg(thr, "CPU%d is used for throttling\n", policy->cpu);
> > + }
> > +
> > + /*
> > +* Can't do this check earlier, otherwise we might miss CPU policies
> > +* that are added after setup().
> > +*/
> > + if (thr->level == 0) {
> > + list_for_each_entry(cftd, >cpufreq.list, node) {
> > + if (cftd->cpu != policy->cpu)
> > + continue;
> > +
> > + if (cftd->clamp_freq != 0) {
> > +
[PATCH 3/5] tracing: Use swap macro in update_max_tr
From: "Gustavo A. R. Silva"
Make use of the swap macro and remove unnecessary variable _buf_.
This makes the code easier to read and maintain. Also, reduces the
stack usage.
This code was detected with the help of Coccinelle.
Link: http://lkml.kernel.org/r/20180209175316.GA18720@embeddedgus
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index c9336e98ac59..a0079b4c7a49 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1360,8 +1360,6 @@ __update_max_tr(struct trace_array *tr, struct
task_struct *tsk, int cpu)
void
update_max_tr(struct trace_array *tr, struct task_struct *tsk, int cpu)
{
- struct ring_buffer *buf;
-
if (tr->stop_count)
return;
@@ -1375,9 +1373,7 @@ update_max_tr(struct trace_array *tr, struct task_struct
*tsk, int cpu)
arch_spin_lock(>max_lock);
- buf = tr->trace_buffer.buffer;
- tr->trace_buffer.buffer = tr->max_buffer.buffer;
- tr->max_buffer.buffer = buf;
+ swap(tr->trace_buffer.buffer, tr->max_buffer.buffer);
__update_max_tr(tr, tsk, cpu);
arch_spin_unlock(>max_lock);
--
2.17.1
[PATCH 3/5] tracing: Use swap macro in update_max_tr
From: "Gustavo A. R. Silva"
Make use of the swap macro and remove unnecessary variable _buf_.
This makes the code easier to read and maintain. Also, reduces the
stack usage.
This code was detected with the help of Coccinelle.
Link: http://lkml.kernel.org/r/20180209175316.GA18720@embeddedgus
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index c9336e98ac59..a0079b4c7a49 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1360,8 +1360,6 @@ __update_max_tr(struct trace_array *tr, struct
task_struct *tsk, int cpu)
void
update_max_tr(struct trace_array *tr, struct task_struct *tsk, int cpu)
{
- struct ring_buffer *buf;
-
if (tr->stop_count)
return;
@@ -1375,9 +1373,7 @@ update_max_tr(struct trace_array *tr, struct task_struct
*tsk, int cpu)
arch_spin_lock(>max_lock);
- buf = tr->trace_buffer.buffer;
- tr->trace_buffer.buffer = tr->max_buffer.buffer;
- tr->max_buffer.buffer = buf;
+ swap(tr->trace_buffer.buffer, tr->max_buffer.buffer);
__update_max_tr(tr, tsk, cpu);
arch_spin_unlock(>max_lock);
--
2.17.1
[PATCH 5/5] tracing: Fix SKIP_STACK_VALIDATION=1 build due to bad merge with -mrecord-mcount
From: Greg Thelen
Non gcc-5 builds with CONFIG_STACK_VALIDATION=y and
SKIP_STACK_VALIDATION=1 fail.
Example output:
/bin/sh: init/.tmp_main.o: Permission denied
commit 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace"),
added a mismatched endif. This causes cmd_objtool to get mistakenly
set.
Relocate endif to balance the newly added -record-mcount check.
Link: http://lkml.kernel.org/r/20180608214746.136554-1-gthe...@google.com
Fixes: 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace")
Acked-by: Andi Kleen
Tested-by: David Rientjes
Signed-off-by: Greg Thelen
Signed-off-by: Steven Rostedt (VMware)
---
scripts/Makefile.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 34d9e9ce97c2..e7889f486ca1 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -239,6 +239,7 @@ cmd_record_mcount =
\
"$(CC_FLAGS_FTRACE)" ]; then \
$(sub_cmd_record_mcount)\
fi;
+endif # -record-mcount
endif # CONFIG_FTRACE_MCOUNT_RECORD
ifdef CONFIG_STACK_VALIDATION
@@ -263,7 +264,6 @@ ifneq ($(RETPOLINE_CFLAGS),)
objtool_args += --retpoline
endif
endif
-endif
ifdef CONFIG_MODVERSIONS
--
2.17.1
[PATCH 4/5] tracing: Fix some errors in histogram documentation
From: "Joel Fernandes (Google)" Fix typos, inconsistencies in using quotes, incorrect section number, etc. in the trace histogram documentation. Link: http://lkml.kernel.org/r/20180614224859.55864-1-j...@joelfernandes.org Reviewed-by: Masami Hiramatsu Acked-by: Tom Zanussi Signed-off-by: Joel Fernandes (Google) Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/histogram.txt | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/Documentation/trace/histogram.txt b/Documentation/trace/histogram.txt index e73bcf9cb5f3..7ffea6aa22e3 100644 --- a/Documentation/trace/histogram.txt +++ b/Documentation/trace/histogram.txt @@ -1729,35 +1729,35 @@ If a variable isn't a key variable or prefixed with 'vals=', the associated event field will be saved in a variable but won't be summed as a value: - # echo 'hist:keys=next_pid:ts1=common_timestamp ... >> event/trigger + # echo 'hist:keys=next_pid:ts1=common_timestamp ...' >> event/trigger Multiple variables can be assigned at the same time. The below would result in both ts0 and b being created as variables, with both common_timestamp and field1 additionally being summed as values: - # echo 'hist:keys=pid:vals=$ts0,$b:ts0=common_timestamp,b=field1 ... >> \ + # echo 'hist:keys=pid:vals=$ts0,$b:ts0=common_timestamp,b=field1 ...' >> \ event/trigger Note that variable assignments can appear either preceding or following their use. The command below behaves identically to the command above: - # echo 'hist:keys=pid:ts0=common_timestamp,b=field1:vals=$ts0,$b ... >> \ + # echo 'hist:keys=pid:ts0=common_timestamp,b=field1:vals=$ts0,$b ...' >> \ event/trigger Any number of variables not bound to a 'vals=' prefix can also be assigned by simply separating them with colons. Below is the same thing but without the values being summed in the histogram: - # echo 'hist:keys=pid:ts0=common_timestamp:b=field1 ... >> event/trigger + # echo 'hist:keys=pid:ts0=common_timestamp:b=field1 ...' >> event/trigger Variables set as above can be referenced and used in expressions on another event. For example, here's how a latency can be calculated: - # echo 'hist:keys=pid,prio:ts0=common_timestamp ... >> event1/trigger - # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp-$ts0 ... >> event2/trigger + # echo 'hist:keys=pid,prio:ts0=common_timestamp ...' >> event1/trigger + # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp-$ts0 ...' >> event2/trigger In the first line above, the event's timetamp is saved into the variable ts0. In the next line, ts0 is subtracted from the second @@ -1766,7 +1766,7 @@ yet another variable, 'wakeup_lat'. The hist trigger below in turn makes use of the wakeup_lat variable to compute a combined latency using the same key and variable from yet another event: - # echo 'hist:key=pid:wakeupswitch_lat=$wakeup_lat+$switchtime_lat ... >> event3/trigger + # echo 'hist:key=pid:wakeupswitch_lat=$wakeup_lat+$switchtime_lat ...' >> event3/trigger 2.2.2 Synthetic Events -- @@ -1807,10 +1807,11 @@ the command that defined it with a '!': At this point, there isn't yet an actual 'wakeup_latency' event instantiated in the event subsytem - for this to happen, a 'hist trigger action' needs to be instantiated and bound to actual fields -and variables defined on other events (see Section 6.3.3 below). +and variables defined on other events (see Section 2.2.3 below on +how that is done using hist trigger 'onmatch' action). Once that is +done, the 'wakeup_latency' synthetic event instance is created. -Once that is done, an event instance is created, and a histogram can -be defined using it: +A histogram can now be defined for the new synthetic event: # echo 'hist:keys=pid,prio,lat.log2:sort=pid,lat' >> \ /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/trigger @@ -1960,7 +1961,7 @@ hist trigger specification. back to that pid, the timestamp difference is calculated. If the resulting latency, stored in wakeup_lat, exceeds the current maximum latency, the values specified in the save() fields are -recoreded: +recorded: # echo 'hist:keys=pid:ts0=common_timestamp.usecs \ if comm=="cyclictest"' >> \ -- 2.17.1
[PATCH 0/5] [GIT PULL] tracing: A few fixes and a clean up
Linus, This contains a few fixes and a clean up. - A bad merge caused an "endif" to go in the wrong place in scripts/Makefile.build - Softirq tracing fix for tracing that corrupts lockdep and causes a false splat - Histogram documentation typo fixes - Fix a bad memory reference when passing in no filter to the filter code - Simplify code by using the swap macro instead of open coding the swap Please pull the latest trace-v4.18-rc1 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-v4.18-rc1 Tag SHA1: 50d890b32aae88f43b04fe477d9a00db564e78e9 Head SHA1: ed7d40bc67b8353c677b38c6cdddcdc310c0f452 Greg Thelen (1): tracing: Fix SKIP_STACK_VALIDATION=1 build due to bad merge with -mrecord-mcount Gustavo A. R. Silva (1): tracing: Use swap macro in update_max_tr Joel Fernandes (Google) (2): softirq: Reorder trace_softirqs_on to prevent lockdep splat tracing: Fix some errors in histogram documentation Steven Rostedt (VMware) (1): tracing: Check for no filter when processing event filters Documentation/trace/histogram.txt | 23 --- kernel/softirq.c | 6 +- kernel/trace/trace.c | 6 +- kernel/trace/trace_events_filter.c | 10 +- scripts/Makefile.build | 2 +- 5 files changed, 28 insertions(+), 19 deletions(-)
[PATCH 5/5] tracing: Fix SKIP_STACK_VALIDATION=1 build due to bad merge with -mrecord-mcount
From: Greg Thelen
Non gcc-5 builds with CONFIG_STACK_VALIDATION=y and
SKIP_STACK_VALIDATION=1 fail.
Example output:
/bin/sh: init/.tmp_main.o: Permission denied
commit 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace"),
added a mismatched endif. This causes cmd_objtool to get mistakenly
set.
Relocate endif to balance the newly added -record-mcount check.
Link: http://lkml.kernel.org/r/20180608214746.136554-1-gthe...@google.com
Fixes: 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace")
Acked-by: Andi Kleen
Tested-by: David Rientjes
Signed-off-by: Greg Thelen
Signed-off-by: Steven Rostedt (VMware)
---
scripts/Makefile.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 34d9e9ce97c2..e7889f486ca1 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -239,6 +239,7 @@ cmd_record_mcount =
\
"$(CC_FLAGS_FTRACE)" ]; then \
$(sub_cmd_record_mcount)\
fi;
+endif # -record-mcount
endif # CONFIG_FTRACE_MCOUNT_RECORD
ifdef CONFIG_STACK_VALIDATION
@@ -263,7 +264,6 @@ ifneq ($(RETPOLINE_CFLAGS),)
objtool_args += --retpoline
endif
endif
-endif
ifdef CONFIG_MODVERSIONS
--
2.17.1
[PATCH 4/5] tracing: Fix some errors in histogram documentation
From: "Joel Fernandes (Google)" Fix typos, inconsistencies in using quotes, incorrect section number, etc. in the trace histogram documentation. Link: http://lkml.kernel.org/r/20180614224859.55864-1-j...@joelfernandes.org Reviewed-by: Masami Hiramatsu Acked-by: Tom Zanussi Signed-off-by: Joel Fernandes (Google) Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/histogram.txt | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/Documentation/trace/histogram.txt b/Documentation/trace/histogram.txt index e73bcf9cb5f3..7ffea6aa22e3 100644 --- a/Documentation/trace/histogram.txt +++ b/Documentation/trace/histogram.txt @@ -1729,35 +1729,35 @@ If a variable isn't a key variable or prefixed with 'vals=', the associated event field will be saved in a variable but won't be summed as a value: - # echo 'hist:keys=next_pid:ts1=common_timestamp ... >> event/trigger + # echo 'hist:keys=next_pid:ts1=common_timestamp ...' >> event/trigger Multiple variables can be assigned at the same time. The below would result in both ts0 and b being created as variables, with both common_timestamp and field1 additionally being summed as values: - # echo 'hist:keys=pid:vals=$ts0,$b:ts0=common_timestamp,b=field1 ... >> \ + # echo 'hist:keys=pid:vals=$ts0,$b:ts0=common_timestamp,b=field1 ...' >> \ event/trigger Note that variable assignments can appear either preceding or following their use. The command below behaves identically to the command above: - # echo 'hist:keys=pid:ts0=common_timestamp,b=field1:vals=$ts0,$b ... >> \ + # echo 'hist:keys=pid:ts0=common_timestamp,b=field1:vals=$ts0,$b ...' >> \ event/trigger Any number of variables not bound to a 'vals=' prefix can also be assigned by simply separating them with colons. Below is the same thing but without the values being summed in the histogram: - # echo 'hist:keys=pid:ts0=common_timestamp:b=field1 ... >> event/trigger + # echo 'hist:keys=pid:ts0=common_timestamp:b=field1 ...' >> event/trigger Variables set as above can be referenced and used in expressions on another event. For example, here's how a latency can be calculated: - # echo 'hist:keys=pid,prio:ts0=common_timestamp ... >> event1/trigger - # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp-$ts0 ... >> event2/trigger + # echo 'hist:keys=pid,prio:ts0=common_timestamp ...' >> event1/trigger + # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp-$ts0 ...' >> event2/trigger In the first line above, the event's timetamp is saved into the variable ts0. In the next line, ts0 is subtracted from the second @@ -1766,7 +1766,7 @@ yet another variable, 'wakeup_lat'. The hist trigger below in turn makes use of the wakeup_lat variable to compute a combined latency using the same key and variable from yet another event: - # echo 'hist:key=pid:wakeupswitch_lat=$wakeup_lat+$switchtime_lat ... >> event3/trigger + # echo 'hist:key=pid:wakeupswitch_lat=$wakeup_lat+$switchtime_lat ...' >> event3/trigger 2.2.2 Synthetic Events -- @@ -1807,10 +1807,11 @@ the command that defined it with a '!': At this point, there isn't yet an actual 'wakeup_latency' event instantiated in the event subsytem - for this to happen, a 'hist trigger action' needs to be instantiated and bound to actual fields -and variables defined on other events (see Section 6.3.3 below). +and variables defined on other events (see Section 2.2.3 below on +how that is done using hist trigger 'onmatch' action). Once that is +done, the 'wakeup_latency' synthetic event instance is created. -Once that is done, an event instance is created, and a histogram can -be defined using it: +A histogram can now be defined for the new synthetic event: # echo 'hist:keys=pid,prio,lat.log2:sort=pid,lat' >> \ /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/trigger @@ -1960,7 +1961,7 @@ hist trigger specification. back to that pid, the timestamp difference is calculated. If the resulting latency, stored in wakeup_lat, exceeds the current maximum latency, the values specified in the save() fields are -recoreded: +recorded: # echo 'hist:keys=pid:ts0=common_timestamp.usecs \ if comm=="cyclictest"' >> \ -- 2.17.1
[PATCH 0/5] [GIT PULL] tracing: A few fixes and a clean up
Linus, This contains a few fixes and a clean up. - A bad merge caused an "endif" to go in the wrong place in scripts/Makefile.build - Softirq tracing fix for tracing that corrupts lockdep and causes a false splat - Histogram documentation typo fixes - Fix a bad memory reference when passing in no filter to the filter code - Simplify code by using the swap macro instead of open coding the swap Please pull the latest trace-v4.18-rc1 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-v4.18-rc1 Tag SHA1: 50d890b32aae88f43b04fe477d9a00db564e78e9 Head SHA1: ed7d40bc67b8353c677b38c6cdddcdc310c0f452 Greg Thelen (1): tracing: Fix SKIP_STACK_VALIDATION=1 build due to bad merge with -mrecord-mcount Gustavo A. R. Silva (1): tracing: Use swap macro in update_max_tr Joel Fernandes (Google) (2): softirq: Reorder trace_softirqs_on to prevent lockdep splat tracing: Fix some errors in histogram documentation Steven Rostedt (VMware) (1): tracing: Check for no filter when processing event filters Documentation/trace/histogram.txt | 23 --- kernel/softirq.c | 6 +- kernel/trace/trace.c | 6 +- kernel/trace/trace_events_filter.c | 10 +- scripts/Makefile.build | 2 +- 5 files changed, 28 insertions(+), 19 deletions(-)
[PATCH 1/5] tracing: Check for no filter when processing event filters
From: "Steven Rostedt (VMware)"
The syzkaller detected a out-of-bounds issue with the events filter code,
specifically here:
prog[N].pred = NULL;/* #13 */
prog[N].target = 1; /* TRUE */
prog[N+1].pred = NULL;
prog[N+1].target = 0; /* FALSE */
-> prog[N-1].target = N;
prog[N-1].when_to_branch = false;
As that's the first reference to a "N-1" index, it appears that the code got
here with N = 0, which means the filter parser found no filter to parse
(which shouldn't ever happen, but apparently it did).
Add a new error to the parsing code that will check to make sure that N is
not zero before going into this part of the code. If N = 0, then -EINVAL is
returned, and a error message is added to the filter.
Cc: sta...@vger.kernel.org
Fixes: 80765597bc587 ("tracing: Rewrite filter logic to be simpler and faster")
Reported-by: air icy
bugzilla url: https://bugzilla.kernel.org/show_bug.cgi?id=200019
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_events_filter.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index e1c818dbc0d7..0dceb77d1d42 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -78,7 +78,8 @@ static const char * ops[] = { OPS };
C(TOO_MANY_PREDS, "Too many terms in predicate expression"), \
C(INVALID_FILTER, "Meaningless filter expression"), \
C(IP_FIELD_ONLY,"Only 'ip' field is supported for function
trace"), \
- C(INVALID_VALUE,"Invalid value (did you forget quotes)?"),
+ C(INVALID_VALUE,"Invalid value (did you forget quotes)?"), \
+ C(NO_FILTER,"No filter found"),
#undef C
#define C(a, b)FILT_ERR_##a
@@ -550,6 +551,13 @@ predicate_parse(const char *str, int nr_parens, int
nr_preds,
goto out_free;
}
+ if (!N) {
+ /* No program? */
+ ret = -EINVAL;
+ parse_error(pe, FILT_ERR_NO_FILTER, ptr - str);
+ goto out_free;
+ }
+
prog[N].pred = NULL;/* #13 */
prog[N].target = 1; /* TRUE */
prog[N+1].pred = NULL;
--
2.17.1
[PATCH 1/5] tracing: Check for no filter when processing event filters
From: "Steven Rostedt (VMware)"
The syzkaller detected a out-of-bounds issue with the events filter code,
specifically here:
prog[N].pred = NULL;/* #13 */
prog[N].target = 1; /* TRUE */
prog[N+1].pred = NULL;
prog[N+1].target = 0; /* FALSE */
-> prog[N-1].target = N;
prog[N-1].when_to_branch = false;
As that's the first reference to a "N-1" index, it appears that the code got
here with N = 0, which means the filter parser found no filter to parse
(which shouldn't ever happen, but apparently it did).
Add a new error to the parsing code that will check to make sure that N is
not zero before going into this part of the code. If N = 0, then -EINVAL is
returned, and a error message is added to the filter.
Cc: sta...@vger.kernel.org
Fixes: 80765597bc587 ("tracing: Rewrite filter logic to be simpler and faster")
Reported-by: air icy
bugzilla url: https://bugzilla.kernel.org/show_bug.cgi?id=200019
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_events_filter.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index e1c818dbc0d7..0dceb77d1d42 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -78,7 +78,8 @@ static const char * ops[] = { OPS };
C(TOO_MANY_PREDS, "Too many terms in predicate expression"), \
C(INVALID_FILTER, "Meaningless filter expression"), \
C(IP_FIELD_ONLY,"Only 'ip' field is supported for function
trace"), \
- C(INVALID_VALUE,"Invalid value (did you forget quotes)?"),
+ C(INVALID_VALUE,"Invalid value (did you forget quotes)?"), \
+ C(NO_FILTER,"No filter found"),
#undef C
#define C(a, b)FILT_ERR_##a
@@ -550,6 +551,13 @@ predicate_parse(const char *str, int nr_parens, int
nr_preds,
goto out_free;
}
+ if (!N) {
+ /* No program? */
+ ret = -EINVAL;
+ parse_error(pe, FILT_ERR_NO_FILTER, ptr - str);
+ goto out_free;
+ }
+
prog[N].pred = NULL;/* #13 */
prog[N].target = 1; /* TRUE */
prog[N+1].pred = NULL;
--
2.17.1
[PATCH 2/5] softirq: Reorder trace_softirqs_on to prevent lockdep splat
From: "Joel Fernandes (Google)"
I'm able to reproduce a lockdep splat with config options:
CONFIG_PROVE_LOCKING=y,
CONFIG_DEBUG_LOCK_ALLOC=y and
CONFIG_PREEMPTIRQ_EVENTS=y
$ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable
[ 26.112609] DEBUG_LOCKS_WARN_ON(current->softirqs_enabled)
[ 26.112636] WARNING: CPU: 0 PID: 118 at kernel/locking/lockdep.c:3854
[...]
[ 26.144229] Call Trace:
[ 26.144926]
[ 26.145506] lock_acquire+0x55/0x1b0
[ 26.146499] ? __do_softirq+0x46f/0x4d9
[ 26.147571] ? __do_softirq+0x46f/0x4d9
[ 26.148646] trace_preempt_on+0x8f/0x240
[ 26.149744] ? trace_preempt_on+0x4d/0x240
[ 26.150862] ? __do_softirq+0x46f/0x4d9
[ 26.151930] preempt_count_sub+0x18a/0x1a0
[ 26.152985] __do_softirq+0x46f/0x4d9
[ 26.153937] irq_exit+0x68/0xe0
[ 26.154755] smp_apic_timer_interrupt+0x271/0x280
[ 26.156056] apic_timer_interrupt+0xf/0x20
[ 26.157105]
The issue was this:
preempt_count = 1 << SOFTIRQ_SHIFT
__local_bh_enable(cnt = 1 << SOFTIRQ_SHIFT) {
if (softirq_count() == (cnt && SOFTIRQ_MASK)) {
trace_softirqs_on() {
current->softirqs_enabled = 1;
}
}
preempt_count_sub(cnt) {
trace_preempt_on() {
tracepoint() {
rcu_read_lock_sched() {
// jumps into lockdep
Where preempt_count still has softirqs disabled, but
current->softirqs_enabled is true, and we get a splat.
Link: http://lkml.kernel.org/r/20180607201143.247775-1-j...@joelfernandes.org
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Mathieu Desnoyers
Cc: Tom Zanussi
Cc: Namhyung Kim
Cc: Thomas Glexiner
Cc: Boqun Feng
Cc: Paul McKenney
Cc: Masami Hiramatsu
Cc: Todd Kjos
Cc: Erick Reyes
Cc: Julia Cartwright
Cc: Byungchul Park
Cc: sta...@vger.kernel.org
Reviewed-by: Steven Rostedt (VMware)
Fixes: d59158162e032 ("tracing: Add support for preempt and irq enable/disable
events")
Signed-off-by: Joel Fernandes (Google)
Signed-off-by: Steven Rostedt (VMware)
---
kernel/softirq.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index de2f57fddc04..900dcfee542c 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -139,9 +139,13 @@ static void __local_bh_enable(unsigned int cnt)
{
lockdep_assert_irqs_disabled();
+ if (preempt_count() == cnt)
+ trace_preempt_on(CALLER_ADDR0, get_lock_parent_ip());
+
if (softirq_count() == (cnt & SOFTIRQ_MASK))
trace_softirqs_on(_RET_IP_);
- preempt_count_sub(cnt);
+
+ __preempt_count_sub(cnt);
}
/*
--
2.17.1
[PATCH 2/5] softirq: Reorder trace_softirqs_on to prevent lockdep splat
From: "Joel Fernandes (Google)"
I'm able to reproduce a lockdep splat with config options:
CONFIG_PROVE_LOCKING=y,
CONFIG_DEBUG_LOCK_ALLOC=y and
CONFIG_PREEMPTIRQ_EVENTS=y
$ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable
[ 26.112609] DEBUG_LOCKS_WARN_ON(current->softirqs_enabled)
[ 26.112636] WARNING: CPU: 0 PID: 118 at kernel/locking/lockdep.c:3854
[...]
[ 26.144229] Call Trace:
[ 26.144926]
[ 26.145506] lock_acquire+0x55/0x1b0
[ 26.146499] ? __do_softirq+0x46f/0x4d9
[ 26.147571] ? __do_softirq+0x46f/0x4d9
[ 26.148646] trace_preempt_on+0x8f/0x240
[ 26.149744] ? trace_preempt_on+0x4d/0x240
[ 26.150862] ? __do_softirq+0x46f/0x4d9
[ 26.151930] preempt_count_sub+0x18a/0x1a0
[ 26.152985] __do_softirq+0x46f/0x4d9
[ 26.153937] irq_exit+0x68/0xe0
[ 26.154755] smp_apic_timer_interrupt+0x271/0x280
[ 26.156056] apic_timer_interrupt+0xf/0x20
[ 26.157105]
The issue was this:
preempt_count = 1 << SOFTIRQ_SHIFT
__local_bh_enable(cnt = 1 << SOFTIRQ_SHIFT) {
if (softirq_count() == (cnt && SOFTIRQ_MASK)) {
trace_softirqs_on() {
current->softirqs_enabled = 1;
}
}
preempt_count_sub(cnt) {
trace_preempt_on() {
tracepoint() {
rcu_read_lock_sched() {
// jumps into lockdep
Where preempt_count still has softirqs disabled, but
current->softirqs_enabled is true, and we get a splat.
Link: http://lkml.kernel.org/r/20180607201143.247775-1-j...@joelfernandes.org
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Mathieu Desnoyers
Cc: Tom Zanussi
Cc: Namhyung Kim
Cc: Thomas Glexiner
Cc: Boqun Feng
Cc: Paul McKenney
Cc: Masami Hiramatsu
Cc: Todd Kjos
Cc: Erick Reyes
Cc: Julia Cartwright
Cc: Byungchul Park
Cc: sta...@vger.kernel.org
Reviewed-by: Steven Rostedt (VMware)
Fixes: d59158162e032 ("tracing: Add support for preempt and irq enable/disable
events")
Signed-off-by: Joel Fernandes (Google)
Signed-off-by: Steven Rostedt (VMware)
---
kernel/softirq.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index de2f57fddc04..900dcfee542c 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -139,9 +139,13 @@ static void __local_bh_enable(unsigned int cnt)
{
lockdep_assert_irqs_disabled();
+ if (preempt_count() == cnt)
+ trace_preempt_on(CALLER_ADDR0, get_lock_parent_ip());
+
if (softirq_count() == (cnt & SOFTIRQ_MASK))
trace_softirqs_on(_RET_IP_);
- preempt_count_sub(cnt);
+
+ __preempt_count_sub(cnt);
}
/*
--
2.17.1
Re: [PATCH] MAINTAINERS: Add Daniel Lustig as a LKMM reviewer
> > Thanks. Unless anyone has any opposition I'll submit the fixed > > patch as part of my next pull request. > > Works for me, especially if this means that Daniel is RISC-V's official > representative. ;-) I'd rather the "fixed patch" go through the LKMM's tree. If not for other, we tend to use get_maintainer.pl on your (TBD ;/) development branch... > > Acked-by: Paul E. McKenney > > > commit 9d01337e4724be4d34bfe848a7c64d14bfdb89ea > > gpg: Signature made Fri 22 Jun 2018 03:35:24 PM PDT > > gpg:using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41 > > gpg:issuer "pal...@dabbelt.com" > > gpg: Good signature from "Palmer Dabbelt " [ultimate] > > gpg: aka "Palmer Dabbelt " [ultimate] > > Author: Palmer Dabbelt > > Date: Fri Jun 22 14:04:42 2018 -0700 > > > >MAINTAINERS: Add Daniel Lustig as a LKMM reviewer Nit: an LKMM > > > >Dan runs the RISC-V memory model working group. I've been forwarding > >him LKMM emails that end up in my inbox, but I'm far from an expert in > >this stuff. He requested to be added as a reviewer, which seem sane to Nit: which seems > >me as it'll take a human out of the loop. > > > >CC: Daniel Lustig > >Acked-by: Daniel Lustig > >Signed-off-by: Palmer Dabbelt Glad to read this! Please feel free to add: Acked-by: Andrea Parri Andrea > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 9d5eeff51b5f..ac8ed55dbe9b 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -8316,6 +8316,7 @@ M:Jade Alglave > > M: Luc Maranget > > M: "Paul E. McKenney" > > R: Akira Yokosawa > > +R: Daniel Lustig > > L: linux-kernel@vger.kernel.org > > S: Supported > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
Re: [PATCH] MAINTAINERS: Add Daniel Lustig as a LKMM reviewer
> > Thanks. Unless anyone has any opposition I'll submit the fixed > > patch as part of my next pull request. > > Works for me, especially if this means that Daniel is RISC-V's official > representative. ;-) I'd rather the "fixed patch" go through the LKMM's tree. If not for other, we tend to use get_maintainer.pl on your (TBD ;/) development branch... > > Acked-by: Paul E. McKenney > > > commit 9d01337e4724be4d34bfe848a7c64d14bfdb89ea > > gpg: Signature made Fri 22 Jun 2018 03:35:24 PM PDT > > gpg:using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41 > > gpg:issuer "pal...@dabbelt.com" > > gpg: Good signature from "Palmer Dabbelt " [ultimate] > > gpg: aka "Palmer Dabbelt " [ultimate] > > Author: Palmer Dabbelt > > Date: Fri Jun 22 14:04:42 2018 -0700 > > > >MAINTAINERS: Add Daniel Lustig as a LKMM reviewer Nit: an LKMM > > > >Dan runs the RISC-V memory model working group. I've been forwarding > >him LKMM emails that end up in my inbox, but I'm far from an expert in > >this stuff. He requested to be added as a reviewer, which seem sane to Nit: which seems > >me as it'll take a human out of the loop. > > > >CC: Daniel Lustig > >Acked-by: Daniel Lustig > >Signed-off-by: Palmer Dabbelt Glad to read this! Please feel free to add: Acked-by: Andrea Parri Andrea > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 9d5eeff51b5f..ac8ed55dbe9b 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -8316,6 +8316,7 @@ M:Jade Alglave > > M: Luc Maranget > > M: "Paul E. McKenney" > > R: Akira Yokosawa > > +R: Daniel Lustig > > L: linux-kernel@vger.kernel.org > > S: Supported > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
Re: [RFC v2 PATCH 2/2] mm: mmap: zap pages with read mmap_sem for large mapping
Yes, this is true but I guess what Yang Shi meant was that an userspace access racing with munmap is not well defined. You never know whether you get your data, #PTF or SEGV because it depends on timing. The user visible change might be that you lose content and get zero page instead if you hit the race window while we are unmapping which was not possible before. But whouldn't such an access pattern be buggy anyway? You need some form of external synchronization AFAICS. But maybe some userspace depends on "getting right data or get SEGV" semantic. If we have to preserve that then we can come up with a VM_DEAD flag set before we tear it down and force the SEGV on the #PF path. Something similar we already do for MMF_UNSTABLE. Set VM_DEAD with read mmap_sem held? It should be ok since this is the only place to set this flag for this unique special case. BTW, it looks the vm flags have used up in 32 bit. If we really need VM_DEAD, it should be for both 32-bit and 64-bit. Any suggestion? Thanks, Yang Yang
Re: [RFC v2 PATCH 2/2] mm: mmap: zap pages with read mmap_sem for large mapping
Yes, this is true but I guess what Yang Shi meant was that an userspace access racing with munmap is not well defined. You never know whether you get your data, #PTF or SEGV because it depends on timing. The user visible change might be that you lose content and get zero page instead if you hit the race window while we are unmapping which was not possible before. But whouldn't such an access pattern be buggy anyway? You need some form of external synchronization AFAICS. But maybe some userspace depends on "getting right data or get SEGV" semantic. If we have to preserve that then we can come up with a VM_DEAD flag set before we tear it down and force the SEGV on the #PF path. Something similar we already do for MMF_UNSTABLE. Set VM_DEAD with read mmap_sem held? It should be ok since this is the only place to set this flag for this unique special case. BTW, it looks the vm flags have used up in 32 bit. If we really need VM_DEAD, it should be for both 32-bit and 64-bit. Any suggestion? Thanks, Yang Yang
Re: [PATCH 7/7] x86,idle: do not leave mm in idle state
On Fri, 2018-06-22 at 15:05 -0700, Andy Lutomirski wrote: > I think the right solution if you want that last little bit of > performance is to get rid of the code in intel_idle and to add it in > the core idle code. We have fancy scheduler code to estimate the > idle > time, and we should use it here IMO. Good point. However, I suspect we have some lower hanging larger fruit to tackle first. Every time we go into lazy TLB mode, we take a refcount on the mm. Every time we leave lazy TLB mode, we drop the refcount. Every time we switch from the idle task to a kernel thread, the kernel thread takes a refcount, and the idle task drops it. Every time we switch back, we do the same dance in reverse. I am working on a patch to grab the refcount once, and hang onto it while a particular mm is that CPU's lazy_mm. We can release it when we switch to a task with a different mm. The patches we have so far get rid of a lot of the pounding on mm_cpumask(mm). That patch should help us also get rid of tasks pounding on mm->count. After that, the idle state thing is probably of pretty small impact, though I suspect it will still be worth tackling :) As an aside, isn't the fancy CPU power management stuff in the scheduler cpufreq, not cpuidle? The cpuidle stuff in kernel/sched/idle.c looks like it will just call down into the menu governor (and maybe the ladder governor on some systems??) -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
Re: [PATCH 7/7] x86,idle: do not leave mm in idle state
On Fri, 2018-06-22 at 15:05 -0700, Andy Lutomirski wrote: > I think the right solution if you want that last little bit of > performance is to get rid of the code in intel_idle and to add it in > the core idle code. We have fancy scheduler code to estimate the > idle > time, and we should use it here IMO. Good point. However, I suspect we have some lower hanging larger fruit to tackle first. Every time we go into lazy TLB mode, we take a refcount on the mm. Every time we leave lazy TLB mode, we drop the refcount. Every time we switch from the idle task to a kernel thread, the kernel thread takes a refcount, and the idle task drops it. Every time we switch back, we do the same dance in reverse. I am working on a patch to grab the refcount once, and hang onto it while a particular mm is that CPU's lazy_mm. We can release it when we switch to a task with a different mm. The patches we have so far get rid of a lot of the pounding on mm_cpumask(mm). That patch should help us also get rid of tasks pounding on mm->count. After that, the idle state thing is probably of pretty small impact, though I suspect it will still be worth tackling :) As an aside, isn't the fancy CPU power management stuff in the scheduler cpufreq, not cpuidle? The cpuidle stuff in kernel/sched/idle.c looks like it will just call down into the menu governor (and maybe the ladder governor on some systems??) -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] firmware: add more flexible request_firmware_async function
Hi Rafał, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.18-rc1 next-20180622] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Sebastian-Reichel/firmware-add-more-flexible-request_firmware_async-function/20180623-025750 config: powerpc-mpc834x_mds_defconfig (attached as .config) compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=powerpc All errors (new ones prefixed by >>): drivers/net/ethernet/intel/e100.o: In function `__request_firmware_async': >> e100.c:(.text+0x4f40): multiple definition of `__request_firmware_async' drivers/base/firmware_loader/fallback_table.o:fallback_table.c:(.text+0x0): first defined here --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 1/2] firmware: add more flexible request_firmware_async function
Hi Rafał, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.18-rc1 next-20180622] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Sebastian-Reichel/firmware-add-more-flexible-request_firmware_async-function/20180623-025750 config: powerpc-mpc834x_mds_defconfig (attached as .config) compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=powerpc All errors (new ones prefixed by >>): drivers/net/ethernet/intel/e100.o: In function `__request_firmware_async': >> e100.c:(.text+0x4f40): multiple definition of `__request_firmware_async' drivers/base/firmware_loader/fallback_table.o:fallback_table.c:(.text+0x0): first defined here --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 1/2] mm: revert mem_cgroup_put() introduction
Hi Roman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20180622]
[cannot apply to linus/master v4.18-rc1 v4.17 v4.17-rc7 v4.18-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Roman-Gushchin/mm-revert-mem_cgroup_put-introduction/20180623-080942
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: the
linux-review/Roman-Gushchin/mm-revert-mem_cgroup_put-introduction/20180623-080942
HEAD 76214420a3e55c42797f5f22cb04d1a3331c1ece builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
mm/oom_kill.c: In function 'oom_kill_memcg_victim':
>> mm/oom_kill.c:1026:2: error: implicit declaration of function
>> 'mem_cgroup_put'; did you mean 'mem_cgroup_id'?
>> [-Werror=implicit-function-declaration]
mem_cgroup_put(oc->chosen_memcg);
^~
mem_cgroup_id
cc1: some warnings being treated as errors
vim +1026 mm/oom_kill.c
4ac2c83a Roman Gushchin 2018-06-15 997
7388c5c4 Roman Gushchin 2018-06-15 998 static bool
oom_kill_memcg_victim(struct oom_control *oc)
7388c5c4 Roman Gushchin 2018-06-15 999 {
4ac2c83a Roman Gushchin 2018-06-15 1000if (oc->chosen_memcg == NULL ||
oc->chosen_memcg == INFLIGHT_VICTIM)
4ac2c83a Roman Gushchin 2018-06-15 1001return oc->chosen_memcg;
4ac2c83a Roman Gushchin 2018-06-15 1002
7388c5c4 Roman Gushchin 2018-06-15 1003/*
7388c5c4 Roman Gushchin 2018-06-15 1004 * If memory.oom_group is set,
kill all tasks belonging to the sub-tree
7388c5c4 Roman Gushchin 2018-06-15 1005 * of the chosen memory cgroup,
otherwise kill the task with the biggest
7388c5c4 Roman Gushchin 2018-06-15 1006 * memory footprint.
7388c5c4 Roman Gushchin 2018-06-15 1007 */
7388c5c4 Roman Gushchin 2018-06-15 1008if
(mem_cgroup_oom_group(oc->chosen_memcg)) {
7388c5c4 Roman Gushchin 2018-06-15 1009
mem_cgroup_scan_tasks(oc->chosen_memcg, oom_kill_memcg_member,
7388c5c4 Roman Gushchin 2018-06-15 1010
NULL);
7388c5c4 Roman Gushchin 2018-06-15 1011/* We have one or more
terminating processes at this point. */
7388c5c4 Roman Gushchin 2018-06-15 1012oc->chosen_task =
INFLIGHT_VICTIM;
7388c5c4 Roman Gushchin 2018-06-15 1013} else {
4ac2c83a Roman Gushchin 2018-06-15 1014oc->chosen_points = 0;
4ac2c83a Roman Gushchin 2018-06-15 1015oc->chosen_task = NULL;
4ac2c83a Roman Gushchin 2018-06-15 1016
mem_cgroup_scan_tasks(oc->chosen_memcg, oom_evaluate_task, oc);
4ac2c83a Roman Gushchin 2018-06-15 1017
7388c5c4 Roman Gushchin 2018-06-15 1018if (oc->chosen_task ==
NULL ||
7388c5c4 Roman Gushchin 2018-06-15 1019oc->chosen_task ==
INFLIGHT_VICTIM)
4ac2c83a Roman Gushchin 2018-06-15 1020goto out;
4ac2c83a Roman Gushchin 2018-06-15 1021
4ac2c83a Roman Gushchin 2018-06-15 1022
__oom_kill_process(oc->chosen_task);
7388c5c4 Roman Gushchin 2018-06-15 1023}
4ac2c83a Roman Gushchin 2018-06-15 1024
4ac2c83a Roman Gushchin 2018-06-15 1025 out:
4ac2c83a Roman Gushchin 2018-06-15 @1026
mem_cgroup_put(oc->chosen_memcg);
4ac2c83a Roman Gushchin 2018-06-15 1027return oc->chosen_task;
4ac2c83a Roman Gushchin 2018-06-15 1028 }
4ac2c83a Roman Gushchin 2018-06-15 1029
:: The code at line 1026 was first introduced by commit
:: 4ac2c83a8e8a0708278b6f2bb44dc4c880fdcaf6 mm, oom: cgroup-aware OOM killer
:: TO: Roman Gushchin
:: CC: Stephen Rothwell
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v8 0/2] regulator: add QCOM RPMh regulator driver
This patch series adds a driver and device tree binding documentation for PMIC regulator control via Resource Power Manager-hardened (RPMh) on some Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC. The final hardware state of a regulator is determined within RPMh by performing max aggregation of the requests made by all of the processors. The RPMh regulator driver depends upon the RPMh driver [1] and command DB driver [2] which are both still undergoing review. It also depends upon three recent regulator patches: [3], [4], and [5] as well as an RPMh helper patch [6]. Changes since v7 [7]: - Removed the cmd_db_ready() call from the driver probe function as it is now handled by the RPMh driver itself [6] - Added Reviewed-by tag for driver patch 2/2 Changes since v6 [8]: - Removed 'count' parameter from rpmh_regulator_send_request() since it is always 1 - Fixed _rpmh_regulator_vrm_set_voltage_sel() return value - Added a helper function to capture common code between rpmh_regulator_enable() and rpmh_regulator_disable() - Added an iterator for pmic_rpmh_data in rpmh_regulator_init_vreg() - Added Reviewed-by tag for both patches Changes since v5 [9]: - Removed unused constants - Added Reviewed-by tag for DT patch 1/2 Changes since v4 [10]: - Removed support for DT properties qcom,regulator-drms-modes and qcom,drms-mode-max-microamps - Specified fixed DRMS high power mode minimum limits for LDO type regulators - Removed DRMS support for SMPS and BOB type regulators - Simplified voltage caching logic Changes since v3 [11]: - Removed support for DT properties qcom,regulator-initial-microvolt and qcom,headroom-microvolt - Renamed DT property qcom,allowed-drms-modes to be qcom,regulator-drms-modes - Updated DT binding documentation to mention which common regulator bindings can be used for qcom-rpmh-regulator devices - Added voltage caching so that voltage requests are only sent to RPMh after the regulator has been enabled at least once - Changed 'voltage_selector' default value to be -ENOTRECOVERABLE to interact with [5] - Initialized 'enabled' to -EINVAL so that unused regulators are disabled by regulator_late_cleanup() - Removed rpmh_regulator_load_default_parameters() as it is no longer needed - Updated the mode usage description in qcom,rpmh-regulator.h Changes since v2 [12]: - Replaced '_' with '-' in device tree supply property names - Renamed qcom_rpmh-regulator.c to be qcom-rpmh-regulator.c - Updated various DT property names to use "microvolt" and "microamp" - Moved allowed modes constraint specification out of the driver [4] - Replaced rpmh_client with device pointer to match new RPMh API [1] - Corrected drms mode threshold checking - Initialized voltage_selector to -EINVAL when not specified in DT - Added constants for PMIC regulator hardware modes - Corrected type sign of mode mapping tables - Made variable names for mode arrays plural - Simplified Kconfig depends on - Removed unnecessary constants and struct fields - Added some descriptive comments Changes since v1 [13]: - Addressed review feedback from Doug, Mark, and Stephen - Replaced set_voltage()/get_voltage() callbacks with set_voltage_sel()/ get_voltage_sel() - Added set_bypass()/get_bypass() callbacks for BOB pass-through mode control - Removed top-level PMIC data structures - Removed initialization variables from structs and passed them as function parameters - Removed various comments and error messages - Simplified mode handling - Refactored per-PMIC rpmh-regulator data specification - Simplified probe function - Moved header into DT patch - Removed redundant property listings from DT binding documentation [1]: https://lkml.org/lkml/2018/6/20/519 [2]: https://lkml.org/lkml/2018/4/10/714 [3]: https://lkml.org/lkml/2018/4/18/556 [4]: https://lkml.org/lkml/2018/5/11/696 [5]: https://lkml.org/lkml/2018/5/15/1005 [6]: https://lkml.org/lkml/2018/6/18/1188 [7]: https://lkml.org/lkml/2018/6/8/573 [8]: https://lkml.org/lkml/2018/6/4/879 [9]: https://lkml.org/lkml/2018/6/1/895 [10]: https://lkml.org/lkml/2018/5/22/1168 [11]: https://lkml.org/lkml/2018/5/11/701 [12]: https://lkml.org/lkml/2018/4/13/687 [13]: https://lkml.org/lkml/2018/3/16/1431 David Collins (2): regulator: dt-bindings: add QCOM RPMh regulator bindings regulator: add QCOM RPMh regulator driver .../bindings/regulator/qcom,rpmh-regulator.txt | 160 + drivers/regulator/Kconfig | 9 + drivers/regulator/Makefile | 1 + drivers/regulator/qcom-rpmh-regulator.c| 746 + .../dt-bindings/regulator/qcom,rpmh-regulator.h| 36 + 5 files changed, 952 insertions(+) create mode 100644
Re: [PATCH 1/2] mm: revert mem_cgroup_put() introduction
Hi Roman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20180622]
[cannot apply to linus/master v4.18-rc1 v4.17 v4.17-rc7 v4.18-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Roman-Gushchin/mm-revert-mem_cgroup_put-introduction/20180623-080942
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: the
linux-review/Roman-Gushchin/mm-revert-mem_cgroup_put-introduction/20180623-080942
HEAD 76214420a3e55c42797f5f22cb04d1a3331c1ece builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
mm/oom_kill.c: In function 'oom_kill_memcg_victim':
>> mm/oom_kill.c:1026:2: error: implicit declaration of function
>> 'mem_cgroup_put'; did you mean 'mem_cgroup_id'?
>> [-Werror=implicit-function-declaration]
mem_cgroup_put(oc->chosen_memcg);
^~
mem_cgroup_id
cc1: some warnings being treated as errors
vim +1026 mm/oom_kill.c
4ac2c83a Roman Gushchin 2018-06-15 997
7388c5c4 Roman Gushchin 2018-06-15 998 static bool
oom_kill_memcg_victim(struct oom_control *oc)
7388c5c4 Roman Gushchin 2018-06-15 999 {
4ac2c83a Roman Gushchin 2018-06-15 1000if (oc->chosen_memcg == NULL ||
oc->chosen_memcg == INFLIGHT_VICTIM)
4ac2c83a Roman Gushchin 2018-06-15 1001return oc->chosen_memcg;
4ac2c83a Roman Gushchin 2018-06-15 1002
7388c5c4 Roman Gushchin 2018-06-15 1003/*
7388c5c4 Roman Gushchin 2018-06-15 1004 * If memory.oom_group is set,
kill all tasks belonging to the sub-tree
7388c5c4 Roman Gushchin 2018-06-15 1005 * of the chosen memory cgroup,
otherwise kill the task with the biggest
7388c5c4 Roman Gushchin 2018-06-15 1006 * memory footprint.
7388c5c4 Roman Gushchin 2018-06-15 1007 */
7388c5c4 Roman Gushchin 2018-06-15 1008if
(mem_cgroup_oom_group(oc->chosen_memcg)) {
7388c5c4 Roman Gushchin 2018-06-15 1009
mem_cgroup_scan_tasks(oc->chosen_memcg, oom_kill_memcg_member,
7388c5c4 Roman Gushchin 2018-06-15 1010
NULL);
7388c5c4 Roman Gushchin 2018-06-15 1011/* We have one or more
terminating processes at this point. */
7388c5c4 Roman Gushchin 2018-06-15 1012oc->chosen_task =
INFLIGHT_VICTIM;
7388c5c4 Roman Gushchin 2018-06-15 1013} else {
4ac2c83a Roman Gushchin 2018-06-15 1014oc->chosen_points = 0;
4ac2c83a Roman Gushchin 2018-06-15 1015oc->chosen_task = NULL;
4ac2c83a Roman Gushchin 2018-06-15 1016
mem_cgroup_scan_tasks(oc->chosen_memcg, oom_evaluate_task, oc);
4ac2c83a Roman Gushchin 2018-06-15 1017
7388c5c4 Roman Gushchin 2018-06-15 1018if (oc->chosen_task ==
NULL ||
7388c5c4 Roman Gushchin 2018-06-15 1019oc->chosen_task ==
INFLIGHT_VICTIM)
4ac2c83a Roman Gushchin 2018-06-15 1020goto out;
4ac2c83a Roman Gushchin 2018-06-15 1021
4ac2c83a Roman Gushchin 2018-06-15 1022
__oom_kill_process(oc->chosen_task);
7388c5c4 Roman Gushchin 2018-06-15 1023}
4ac2c83a Roman Gushchin 2018-06-15 1024
4ac2c83a Roman Gushchin 2018-06-15 1025 out:
4ac2c83a Roman Gushchin 2018-06-15 @1026
mem_cgroup_put(oc->chosen_memcg);
4ac2c83a Roman Gushchin 2018-06-15 1027return oc->chosen_task;
4ac2c83a Roman Gushchin 2018-06-15 1028 }
4ac2c83a Roman Gushchin 2018-06-15 1029
:: The code at line 1026 was first introduced by commit
:: 4ac2c83a8e8a0708278b6f2bb44dc4c880fdcaf6 mm, oom: cgroup-aware OOM killer
:: TO: Roman Gushchin
:: CC: Stephen Rothwell
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v8 0/2] regulator: add QCOM RPMh regulator driver
This patch series adds a driver and device tree binding documentation for PMIC regulator control via Resource Power Manager-hardened (RPMh) on some Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC. The final hardware state of a regulator is determined within RPMh by performing max aggregation of the requests made by all of the processors. The RPMh regulator driver depends upon the RPMh driver [1] and command DB driver [2] which are both still undergoing review. It also depends upon three recent regulator patches: [3], [4], and [5] as well as an RPMh helper patch [6]. Changes since v7 [7]: - Removed the cmd_db_ready() call from the driver probe function as it is now handled by the RPMh driver itself [6] - Added Reviewed-by tag for driver patch 2/2 Changes since v6 [8]: - Removed 'count' parameter from rpmh_regulator_send_request() since it is always 1 - Fixed _rpmh_regulator_vrm_set_voltage_sel() return value - Added a helper function to capture common code between rpmh_regulator_enable() and rpmh_regulator_disable() - Added an iterator for pmic_rpmh_data in rpmh_regulator_init_vreg() - Added Reviewed-by tag for both patches Changes since v5 [9]: - Removed unused constants - Added Reviewed-by tag for DT patch 1/2 Changes since v4 [10]: - Removed support for DT properties qcom,regulator-drms-modes and qcom,drms-mode-max-microamps - Specified fixed DRMS high power mode minimum limits for LDO type regulators - Removed DRMS support for SMPS and BOB type regulators - Simplified voltage caching logic Changes since v3 [11]: - Removed support for DT properties qcom,regulator-initial-microvolt and qcom,headroom-microvolt - Renamed DT property qcom,allowed-drms-modes to be qcom,regulator-drms-modes - Updated DT binding documentation to mention which common regulator bindings can be used for qcom-rpmh-regulator devices - Added voltage caching so that voltage requests are only sent to RPMh after the regulator has been enabled at least once - Changed 'voltage_selector' default value to be -ENOTRECOVERABLE to interact with [5] - Initialized 'enabled' to -EINVAL so that unused regulators are disabled by regulator_late_cleanup() - Removed rpmh_regulator_load_default_parameters() as it is no longer needed - Updated the mode usage description in qcom,rpmh-regulator.h Changes since v2 [12]: - Replaced '_' with '-' in device tree supply property names - Renamed qcom_rpmh-regulator.c to be qcom-rpmh-regulator.c - Updated various DT property names to use "microvolt" and "microamp" - Moved allowed modes constraint specification out of the driver [4] - Replaced rpmh_client with device pointer to match new RPMh API [1] - Corrected drms mode threshold checking - Initialized voltage_selector to -EINVAL when not specified in DT - Added constants for PMIC regulator hardware modes - Corrected type sign of mode mapping tables - Made variable names for mode arrays plural - Simplified Kconfig depends on - Removed unnecessary constants and struct fields - Added some descriptive comments Changes since v1 [13]: - Addressed review feedback from Doug, Mark, and Stephen - Replaced set_voltage()/get_voltage() callbacks with set_voltage_sel()/ get_voltage_sel() - Added set_bypass()/get_bypass() callbacks for BOB pass-through mode control - Removed top-level PMIC data structures - Removed initialization variables from structs and passed them as function parameters - Removed various comments and error messages - Simplified mode handling - Refactored per-PMIC rpmh-regulator data specification - Simplified probe function - Moved header into DT patch - Removed redundant property listings from DT binding documentation [1]: https://lkml.org/lkml/2018/6/20/519 [2]: https://lkml.org/lkml/2018/4/10/714 [3]: https://lkml.org/lkml/2018/4/18/556 [4]: https://lkml.org/lkml/2018/5/11/696 [5]: https://lkml.org/lkml/2018/5/15/1005 [6]: https://lkml.org/lkml/2018/6/18/1188 [7]: https://lkml.org/lkml/2018/6/8/573 [8]: https://lkml.org/lkml/2018/6/4/879 [9]: https://lkml.org/lkml/2018/6/1/895 [10]: https://lkml.org/lkml/2018/5/22/1168 [11]: https://lkml.org/lkml/2018/5/11/701 [12]: https://lkml.org/lkml/2018/4/13/687 [13]: https://lkml.org/lkml/2018/3/16/1431 David Collins (2): regulator: dt-bindings: add QCOM RPMh regulator bindings regulator: add QCOM RPMh regulator driver .../bindings/regulator/qcom,rpmh-regulator.txt | 160 + drivers/regulator/Kconfig | 9 + drivers/regulator/Makefile | 1 + drivers/regulator/qcom-rpmh-regulator.c| 746 + .../dt-bindings/regulator/qcom,rpmh-regulator.h| 36 + 5 files changed, 952 insertions(+) create mode 100644
[PATCH v8 2/2] regulator: add QCOM RPMh regulator driver
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC. The final
hardware state of a regulator is determined within RPMh by
performing max aggregation of the requests made by all of the
processors.
Add support for PMIC regulator control via the voltage regulator
manager (VRM) and oscillator buffer (XOB) RPMh accelerators.
VRM supports manipulation of enable state, voltage, and mode.
XOB supports manipulation of enable state.
Signed-off-by: David Collins
Reviewed-by: Douglas Anderson
Reviewed-by: Matthias Kaehlcke
---
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom-rpmh-regulator.c | 746
3 files changed, 756 insertions(+)
create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 2964eaea..f9ef567 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -682,6 +682,15 @@ config REGULATOR_QCOM_RPM
Qualcomm RPM as a module. The module will be named
"qcom_rpm-regulator".
+config REGULATOR_QCOM_RPMH
+ tristate "Qualcomm Technologies, Inc. RPMh regulator driver"
+ depends on QCOM_RPMH || COMPILE_TEST
+ help
+ This driver supports control of PMIC regulators via the RPMh hardware
+ block found on Qualcomm Technologies Inc. SoCs. RPMh regulator
+ control allows for voting on regulator state between multiple
+ processors within the SoC.
+
config REGULATOR_QCOM_SMD_RPM
tristate "Qualcomm SMD based RPM regulator driver"
depends on QCOM_SMD_RPM
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index bd818ce..06e76a6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -78,6 +78,7 @@ obj-$(CONFIG_REGULATOR_MT6323)+= mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
diff --git a/drivers/regulator/qcom-rpmh-regulator.c
b/drivers/regulator/qcom-rpmh-regulator.c
new file mode 100644
index 000..422bb81
--- /dev/null
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -0,0 +1,746 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+/**
+ * enum rpmh_regulator_type - supported RPMh accelerator types
+ * %VRM: RPMh VRM accelerator which supports voting on enable, voltage,
+ * and mode of LDO, SMPS, and BOB type PMIC regulators.
+ * %XOB: RPMh XOB accelerator which supports voting on the enable state
+ * of PMIC regulators.
+ */
+enum rpmh_regulator_type {
+ VRM,
+ XOB,
+};
+
+#define RPMH_REGULATOR_REG_VRM_VOLTAGE 0x0
+#define RPMH_REGULATOR_REG_ENABLE 0x4
+#define RPMH_REGULATOR_REG_VRM_MODE0x8
+
+#define RPMH_REGULATOR_MODE_COUNT 4
+
+#define PMIC4_LDO_MODE_RETENTION 4
+#define PMIC4_LDO_MODE_LPM 5
+#define PMIC4_LDO_MODE_HPM 7
+
+#define PMIC4_SMPS_MODE_RETENTION 4
+#define PMIC4_SMPS_MODE_PFM5
+#define PMIC4_SMPS_MODE_AUTO 6
+#define PMIC4_SMPS_MODE_PWM7
+
+#define PMIC4_BOB_MODE_PASS0
+#define PMIC4_BOB_MODE_PFM 1
+#define PMIC4_BOB_MODE_AUTO2
+#define PMIC4_BOB_MODE_PWM 3
+
+/**
+ * struct rpmh_vreg_hw_data - RPMh regulator hardware configurations
+ * @regulator_type:RPMh accelerator type used to manage this
+ * regulator
+ * @ops: Pointer to regulator ops callback structure
+ * @voltage_range: The single range of voltages supported by this
+ * PMIC regulator type
+ * @n_voltages:The number of unique voltage set points
defined
+ * by voltage_range
+ * @hpm_min_load_uA: Minimum load current in microamps that requires
+ * high power mode (HPM) operation. This is used
+ * for LDO hardware type regulators only.
[PATCH v8 2/2] regulator: add QCOM RPMh regulator driver
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC. The final
hardware state of a regulator is determined within RPMh by
performing max aggregation of the requests made by all of the
processors.
Add support for PMIC regulator control via the voltage regulator
manager (VRM) and oscillator buffer (XOB) RPMh accelerators.
VRM supports manipulation of enable state, voltage, and mode.
XOB supports manipulation of enable state.
Signed-off-by: David Collins
Reviewed-by: Douglas Anderson
Reviewed-by: Matthias Kaehlcke
---
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/qcom-rpmh-regulator.c | 746
3 files changed, 756 insertions(+)
create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 2964eaea..f9ef567 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -682,6 +682,15 @@ config REGULATOR_QCOM_RPM
Qualcomm RPM as a module. The module will be named
"qcom_rpm-regulator".
+config REGULATOR_QCOM_RPMH
+ tristate "Qualcomm Technologies, Inc. RPMh regulator driver"
+ depends on QCOM_RPMH || COMPILE_TEST
+ help
+ This driver supports control of PMIC regulators via the RPMh hardware
+ block found on Qualcomm Technologies Inc. SoCs. RPMh regulator
+ control allows for voting on regulator state between multiple
+ processors within the SoC.
+
config REGULATOR_QCOM_SMD_RPM
tristate "Qualcomm SMD based RPM regulator driver"
depends on QCOM_SMD_RPM
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index bd818ce..06e76a6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -78,6 +78,7 @@ obj-$(CONFIG_REGULATOR_MT6323)+= mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
diff --git a/drivers/regulator/qcom-rpmh-regulator.c
b/drivers/regulator/qcom-rpmh-regulator.c
new file mode 100644
index 000..422bb81
--- /dev/null
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -0,0 +1,746 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+/**
+ * enum rpmh_regulator_type - supported RPMh accelerator types
+ * %VRM: RPMh VRM accelerator which supports voting on enable, voltage,
+ * and mode of LDO, SMPS, and BOB type PMIC regulators.
+ * %XOB: RPMh XOB accelerator which supports voting on the enable state
+ * of PMIC regulators.
+ */
+enum rpmh_regulator_type {
+ VRM,
+ XOB,
+};
+
+#define RPMH_REGULATOR_REG_VRM_VOLTAGE 0x0
+#define RPMH_REGULATOR_REG_ENABLE 0x4
+#define RPMH_REGULATOR_REG_VRM_MODE0x8
+
+#define RPMH_REGULATOR_MODE_COUNT 4
+
+#define PMIC4_LDO_MODE_RETENTION 4
+#define PMIC4_LDO_MODE_LPM 5
+#define PMIC4_LDO_MODE_HPM 7
+
+#define PMIC4_SMPS_MODE_RETENTION 4
+#define PMIC4_SMPS_MODE_PFM5
+#define PMIC4_SMPS_MODE_AUTO 6
+#define PMIC4_SMPS_MODE_PWM7
+
+#define PMIC4_BOB_MODE_PASS0
+#define PMIC4_BOB_MODE_PFM 1
+#define PMIC4_BOB_MODE_AUTO2
+#define PMIC4_BOB_MODE_PWM 3
+
+/**
+ * struct rpmh_vreg_hw_data - RPMh regulator hardware configurations
+ * @regulator_type:RPMh accelerator type used to manage this
+ * regulator
+ * @ops: Pointer to regulator ops callback structure
+ * @voltage_range: The single range of voltages supported by this
+ * PMIC regulator type
+ * @n_voltages:The number of unique voltage set points
defined
+ * by voltage_range
+ * @hpm_min_load_uA: Minimum load current in microamps that requires
+ * high power mode (HPM) operation. This is used
+ * for LDO hardware type regulators only.
[PATCH v8 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Introduce bindings for RPMh regulator devices found on some Qualcomm Technlogies, Inc. SoCs. These devices allow a given processor within the SoC to make PMIC regulator requests which are aggregated within the RPMh hardware block along with requests from other processors in the SoC to determine the final PMIC regulator hardware state. Signed-off-by: David Collins Reviewed-by: Rob Herring Reviewed-by: Douglas Anderson --- .../bindings/regulator/qcom,rpmh-regulator.txt | 160 + .../dt-bindings/regulator/qcom,rpmh-regulator.h| 36 + 2 files changed, 196 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt new file mode 100644 index 000..7ef2dbe --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt @@ -0,0 +1,160 @@ +Qualcomm Technologies, Inc. RPMh Regulators + +rpmh-regulator devices support PMIC regulator management via the Voltage +Regulator Manager (VRM) and Oscillator Buffer (XOB) RPMh accelerators. The APPS +processor communicates with these hardware blocks via a Resource State +Coordinator (RSC) using command packets. The VRM allows changing three +parameters for a given regulator: enable state, output voltage, and operating +mode. The XOB allows changing only a single parameter for a given regulator: +its enable state. Despite its name, the XOB is capable of controlling the +enable state of any PMIC peripheral. It is used for clock buffers, low-voltage +switches, and LDO/SMPS regulators which have a fixed voltage and mode. + +=== +Required Node Structure +=== + +RPMh regulators must be described in two levels of device nodes. The first +level describes the PMIC containing the regulators and must reside within an +RPMh device node. The second level describes each regulator within the PMIC +which is to be used on the board. Each of these regulators maps to a single +RPMh resource. + +The names used for regulator nodes must match those supported by a given PMIC. +Supported regulator node names: + PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2 + PMI8998:bob + PM8005: smps1 - smps4 + + +First Level Nodes - PMIC + + +- compatible + Usage: required + Value type: + Definition: Must be one of: "qcom,pm8998-rpmh-regulators", + "qcom,pmi8998-rpmh-regulators" or + "qcom,pm8005-rpmh-regulators". + +- qcom,pmic-id + Usage: required + Value type: + Definition: RPMh resource name suffix used for the regulators found on + this PMIC. Typical values: "a", "b", "c", "d", "e", "f". + +- vdd-s1-supply +- vdd-s2-supply +- vdd-s3-supply +- vdd-s4-supply + Usage: optional (PM8998 and PM8005 only) + Value type: + Definition: phandle of the parent supply regulator of one or more of the + regulators for this PMIC. + +- vdd-s5-supply +- vdd-s6-supply +- vdd-s7-supply +- vdd-s8-supply +- vdd-s9-supply +- vdd-s10-supply +- vdd-s11-supply +- vdd-s12-supply +- vdd-s13-supply +- vdd-l1-l27-supply +- vdd-l2-l8-l17-supply +- vdd-l3-l11-supply +- vdd-l4-l5-supply +- vdd-l6-supply +- vdd-l7-l12-l14-l15-supply +- vdd-l9-supply +- vdd-l10-l23-l25-supply +- vdd-l13-l19-l21-supply +- vdd-l16-l28-supply +- vdd-l18-l22-supply +- vdd-l20-l24-supply +- vdd-l26-supply +- vin-lvs-1-2-supply + Usage: optional (PM8998 only) + Value type: + Definition: phandle of the parent supply regulator of one or more of the + regulators for this PMIC. + +- vdd-bob-supply + Usage: optional (PMI8998 only) + Value type: + Definition: BOB regulator parent supply phandle + +=== +Second Level Nodes - Regulators +=== + +- qcom,always-wait-for-ack + Usage: optional + Value type: + Definition: Boolean flag which indicates that the application processor + must wait for an ACK or a NACK from RPMh for every request + sent for this regulator including those which are for a + strictly lower power state. + +Other properties defined in Documentation/devicetree/bindings/regulator.txt +may also be used. regulator-initial-mode and regulator-allowed-modes may be +specified for VRM regulators using mode values from +include/dt-bindings/regulator/qcom,rpmh-regulator.h. regulator-allow-bypass +may be specified for BOB type regulators managed via VRM. +regulator-allow-set-load may be specified for LDO type regulators managed via +VRM. + + +Examples
[PATCH v8 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Introduce bindings for RPMh regulator devices found on some Qualcomm Technlogies, Inc. SoCs. These devices allow a given processor within the SoC to make PMIC regulator requests which are aggregated within the RPMh hardware block along with requests from other processors in the SoC to determine the final PMIC regulator hardware state. Signed-off-by: David Collins Reviewed-by: Rob Herring Reviewed-by: Douglas Anderson --- .../bindings/regulator/qcom,rpmh-regulator.txt | 160 + .../dt-bindings/regulator/qcom,rpmh-regulator.h| 36 + 2 files changed, 196 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt new file mode 100644 index 000..7ef2dbe --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt @@ -0,0 +1,160 @@ +Qualcomm Technologies, Inc. RPMh Regulators + +rpmh-regulator devices support PMIC regulator management via the Voltage +Regulator Manager (VRM) and Oscillator Buffer (XOB) RPMh accelerators. The APPS +processor communicates with these hardware blocks via a Resource State +Coordinator (RSC) using command packets. The VRM allows changing three +parameters for a given regulator: enable state, output voltage, and operating +mode. The XOB allows changing only a single parameter for a given regulator: +its enable state. Despite its name, the XOB is capable of controlling the +enable state of any PMIC peripheral. It is used for clock buffers, low-voltage +switches, and LDO/SMPS regulators which have a fixed voltage and mode. + +=== +Required Node Structure +=== + +RPMh regulators must be described in two levels of device nodes. The first +level describes the PMIC containing the regulators and must reside within an +RPMh device node. The second level describes each regulator within the PMIC +which is to be used on the board. Each of these regulators maps to a single +RPMh resource. + +The names used for regulator nodes must match those supported by a given PMIC. +Supported regulator node names: + PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2 + PMI8998:bob + PM8005: smps1 - smps4 + + +First Level Nodes - PMIC + + +- compatible + Usage: required + Value type: + Definition: Must be one of: "qcom,pm8998-rpmh-regulators", + "qcom,pmi8998-rpmh-regulators" or + "qcom,pm8005-rpmh-regulators". + +- qcom,pmic-id + Usage: required + Value type: + Definition: RPMh resource name suffix used for the regulators found on + this PMIC. Typical values: "a", "b", "c", "d", "e", "f". + +- vdd-s1-supply +- vdd-s2-supply +- vdd-s3-supply +- vdd-s4-supply + Usage: optional (PM8998 and PM8005 only) + Value type: + Definition: phandle of the parent supply regulator of one or more of the + regulators for this PMIC. + +- vdd-s5-supply +- vdd-s6-supply +- vdd-s7-supply +- vdd-s8-supply +- vdd-s9-supply +- vdd-s10-supply +- vdd-s11-supply +- vdd-s12-supply +- vdd-s13-supply +- vdd-l1-l27-supply +- vdd-l2-l8-l17-supply +- vdd-l3-l11-supply +- vdd-l4-l5-supply +- vdd-l6-supply +- vdd-l7-l12-l14-l15-supply +- vdd-l9-supply +- vdd-l10-l23-l25-supply +- vdd-l13-l19-l21-supply +- vdd-l16-l28-supply +- vdd-l18-l22-supply +- vdd-l20-l24-supply +- vdd-l26-supply +- vin-lvs-1-2-supply + Usage: optional (PM8998 only) + Value type: + Definition: phandle of the parent supply regulator of one or more of the + regulators for this PMIC. + +- vdd-bob-supply + Usage: optional (PMI8998 only) + Value type: + Definition: BOB regulator parent supply phandle + +=== +Second Level Nodes - Regulators +=== + +- qcom,always-wait-for-ack + Usage: optional + Value type: + Definition: Boolean flag which indicates that the application processor + must wait for an ACK or a NACK from RPMh for every request + sent for this regulator including those which are for a + strictly lower power state. + +Other properties defined in Documentation/devicetree/bindings/regulator.txt +may also be used. regulator-initial-mode and regulator-allowed-modes may be +specified for VRM regulators using mode values from +include/dt-bindings/regulator/qcom,rpmh-regulator.h. regulator-allow-bypass +may be specified for BOB type regulators managed via VRM. +regulator-allow-set-load may be specified for LDO type regulators managed via +VRM. + + +Examples
Re: [PATCH v5 2/8] reset: qcom: AOSS (always on subsystem) reset controller
On Mon 21 May 10:27 PDT 2018, Sibi Sankar wrote:
> Add reset controller driver for Qualcomm SDM845 SoC to
> control reset signals provided by AOSS for Modem, Venus
> ADSP, GPU, Camera, Wireless, Display subsystem
>
> Signed-off-by: Sibi Sankar
With the adaptions discussed in the DT binding patch (compatible and
register offsets) you have my:
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/reset/Kconfig | 9 +++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-qcom-aoss.c | 133
> 3 files changed, 143 insertions(+)
> create mode 100644 drivers/reset/reset-qcom-aoss.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index c0b292be1b72..756ad2b27d0f 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -82,6 +82,15 @@ config RESET_PISTACHIO
> help
> This enables the reset driver for ImgTec Pistachio SoCs.
>
> +config RESET_QCOM_AOSS
> + bool "Qcom AOSS Reset Driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + help
> + This enables the AOSS (always on subsystem) reset driver
> + for Qualcomm SDM845 SoCs. Say Y if you want to control
> + reset signals provided by AOSS for Modem, Venus, ADSP,
> + GPU, Camera, Wireless, Display subsystem. Otherwise, say N.
> +
> config RESET_SIMPLE
> bool "Simple Reset Controller Driver" if COMPILE_TEST
> default ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI ||
> ARCH_ZX || ARCH_ASPEED
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index c1261dcfe9ad..6881e4d287f0 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
> obj-$(CONFIG_RESET_MESON) += reset-meson.o
> obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
> obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
> +obj-$(CONFIG_RESET_QCOM_AOSS) += reset-qcom-aoss.o
> obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
> obj-$(CONFIG_RESET_STM32MP157) += reset-stm32mp1.o
> obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
> diff --git a/drivers/reset/reset-qcom-aoss.c b/drivers/reset/reset-qcom-aoss.c
> new file mode 100644
> index ..d9ca7339c434
> --- /dev/null
> +++ b/drivers/reset/reset-qcom-aoss.c
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct qcom_aoss_reset_map {
> + unsigned int reg;
> +};
> +
> +struct qcom_aoss_desc {
> + const struct qcom_aoss_reset_map *resets;
> + size_t num_resets;
> +};
> +
> +struct qcom_aoss_reset_data {
> + struct reset_controller_dev rcdev;
> + void __iomem *base;
> + const struct qcom_aoss_desc *desc;
> +};
> +
> +static const struct qcom_aoss_reset_map sdm845_aoss_resets[] = {
> + [AOSS_CC_MSS_RESTART] = {0x0},
> + [AOSS_CC_CAMSS_RESTART] = {0x1000},
> + [AOSS_CC_VENUS_RESTART] = {0x2000},
> + [AOSS_CC_GPU_RESTART] = {0x3000},
> + [AOSS_CC_DISPSS_RESTART] = {0x4000},
> + [AOSS_CC_WCSS_RESTART] = {0x1},
> + [AOSS_CC_LPASS_RESTART] = {0x2},
> +};
> +
> +static const struct qcom_aoss_desc sdm845_aoss_desc = {
> + .resets = sdm845_aoss_resets,
> + .num_resets = ARRAY_SIZE(sdm845_aoss_resets),
> +};
> +
> +static inline struct qcom_aoss_reset_data *to_qcom_aoss_reset_data(
> + struct reset_controller_dev *rcdev)
> +{
> + return container_of(rcdev, struct qcom_aoss_reset_data, rcdev);
> +}
> +
> +static int qcom_aoss_control_assert(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct qcom_aoss_reset_data *data = to_qcom_aoss_reset_data(rcdev);
> + const struct qcom_aoss_reset_map *map = >desc->resets[idx];
> +
> + writel(1, data->base + map->reg);
> + /* Wait 6 32kHz sleep cycles for reset */
> + usleep_range(200, 300);
> + return 0;
> +}
> +
> +static int qcom_aoss_control_deassert(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct qcom_aoss_reset_data *data = to_qcom_aoss_reset_data(rcdev);
> + const struct qcom_aoss_reset_map *map = >desc->resets[idx];
> +
> + writel(0, data->base + map->reg);
> + /* Wait 6 32kHz sleep cycles for reset */
> + usleep_range(200, 300);
> + return 0;
> +}
> +
> +static int qcom_aoss_control_reset(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + qcom_aoss_control_assert(rcdev, idx);
> +
> + return qcom_aoss_control_deassert(rcdev, idx);
> +}
> +
> +static const struct reset_control_ops qcom_aoss_reset_ops = {
> + .reset = qcom_aoss_control_reset,
> + .assert = qcom_aoss_control_assert,
> + .deassert = qcom_aoss_control_deassert,
> +};
> +
> +static
Re: [PATCH v5 2/8] reset: qcom: AOSS (always on subsystem) reset controller
On Mon 21 May 10:27 PDT 2018, Sibi Sankar wrote:
> Add reset controller driver for Qualcomm SDM845 SoC to
> control reset signals provided by AOSS for Modem, Venus
> ADSP, GPU, Camera, Wireless, Display subsystem
>
> Signed-off-by: Sibi Sankar
With the adaptions discussed in the DT binding patch (compatible and
register offsets) you have my:
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/reset/Kconfig | 9 +++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-qcom-aoss.c | 133
> 3 files changed, 143 insertions(+)
> create mode 100644 drivers/reset/reset-qcom-aoss.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index c0b292be1b72..756ad2b27d0f 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -82,6 +82,15 @@ config RESET_PISTACHIO
> help
> This enables the reset driver for ImgTec Pistachio SoCs.
>
> +config RESET_QCOM_AOSS
> + bool "Qcom AOSS Reset Driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + help
> + This enables the AOSS (always on subsystem) reset driver
> + for Qualcomm SDM845 SoCs. Say Y if you want to control
> + reset signals provided by AOSS for Modem, Venus, ADSP,
> + GPU, Camera, Wireless, Display subsystem. Otherwise, say N.
> +
> config RESET_SIMPLE
> bool "Simple Reset Controller Driver" if COMPILE_TEST
> default ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI ||
> ARCH_ZX || ARCH_ASPEED
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index c1261dcfe9ad..6881e4d287f0 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
> obj-$(CONFIG_RESET_MESON) += reset-meson.o
> obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
> obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
> +obj-$(CONFIG_RESET_QCOM_AOSS) += reset-qcom-aoss.o
> obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
> obj-$(CONFIG_RESET_STM32MP157) += reset-stm32mp1.o
> obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
> diff --git a/drivers/reset/reset-qcom-aoss.c b/drivers/reset/reset-qcom-aoss.c
> new file mode 100644
> index ..d9ca7339c434
> --- /dev/null
> +++ b/drivers/reset/reset-qcom-aoss.c
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct qcom_aoss_reset_map {
> + unsigned int reg;
> +};
> +
> +struct qcom_aoss_desc {
> + const struct qcom_aoss_reset_map *resets;
> + size_t num_resets;
> +};
> +
> +struct qcom_aoss_reset_data {
> + struct reset_controller_dev rcdev;
> + void __iomem *base;
> + const struct qcom_aoss_desc *desc;
> +};
> +
> +static const struct qcom_aoss_reset_map sdm845_aoss_resets[] = {
> + [AOSS_CC_MSS_RESTART] = {0x0},
> + [AOSS_CC_CAMSS_RESTART] = {0x1000},
> + [AOSS_CC_VENUS_RESTART] = {0x2000},
> + [AOSS_CC_GPU_RESTART] = {0x3000},
> + [AOSS_CC_DISPSS_RESTART] = {0x4000},
> + [AOSS_CC_WCSS_RESTART] = {0x1},
> + [AOSS_CC_LPASS_RESTART] = {0x2},
> +};
> +
> +static const struct qcom_aoss_desc sdm845_aoss_desc = {
> + .resets = sdm845_aoss_resets,
> + .num_resets = ARRAY_SIZE(sdm845_aoss_resets),
> +};
> +
> +static inline struct qcom_aoss_reset_data *to_qcom_aoss_reset_data(
> + struct reset_controller_dev *rcdev)
> +{
> + return container_of(rcdev, struct qcom_aoss_reset_data, rcdev);
> +}
> +
> +static int qcom_aoss_control_assert(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct qcom_aoss_reset_data *data = to_qcom_aoss_reset_data(rcdev);
> + const struct qcom_aoss_reset_map *map = >desc->resets[idx];
> +
> + writel(1, data->base + map->reg);
> + /* Wait 6 32kHz sleep cycles for reset */
> + usleep_range(200, 300);
> + return 0;
> +}
> +
> +static int qcom_aoss_control_deassert(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct qcom_aoss_reset_data *data = to_qcom_aoss_reset_data(rcdev);
> + const struct qcom_aoss_reset_map *map = >desc->resets[idx];
> +
> + writel(0, data->base + map->reg);
> + /* Wait 6 32kHz sleep cycles for reset */
> + usleep_range(200, 300);
> + return 0;
> +}
> +
> +static int qcom_aoss_control_reset(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + qcom_aoss_control_assert(rcdev, idx);
> +
> + return qcom_aoss_control_deassert(rcdev, idx);
> +}
> +
> +static const struct reset_control_ops qcom_aoss_reset_ops = {
> + .reset = qcom_aoss_control_reset,
> + .assert = qcom_aoss_control_assert,
> + .deassert = qcom_aoss_control_deassert,
> +};
> +
> +static
Re: [PATCH v5 1/8] dt-bindings: reset: Add AOSS reset bindings for SDM845 SoCs
On Mon 21 May 10:27 PDT 2018, Sibi Sankar wrote:
> Add SDM845 AOSS (always on subsystem) reset controller binding
>
I think it would be better if you made the binding represent the entire
clock controller, rather than only the reset-related portion of it.
As I can't find anything in the downstream kernel that references the
clock part of the hardware block I think the driver can be kept as is
(with updated compatible and adjust the offsets of the registers)
This makes the DT better represents the hardware and it makes it
possible to control the clocks in the future, without breaking backwards
compatibility with existing DTBs.
> Signed-off-by: Sibi Sankar
> ---
> .../bindings/reset/qcom,aoss-reset.txt| 52 +++
> include/dt-bindings/reset/qcom,sdm845-aoss.h | 17 ++
> 2 files changed, 69 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> create mode 100644 include/dt-bindings/reset/qcom,sdm845-aoss.h
>
> diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> new file mode 100644
> index ..cd5dcafb4ed7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> @@ -0,0 +1,52 @@
> +Qualcomm AOSS Reset Controller
> +==
> +
> +This binding describes a reset-controller found on AOSS (always on subsystem)
> +for Qualcomm SDM845 SoCs.
> +
> +Required properties:
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be:
> + "qcom,sdm845-aoss-reset"
qcom,sdm845-aoss-cc
> +
> +- reg:
> + Usage: required
> + Value type:
> + Definition: must specify the base address and size of the register
> + space.
> +
> +- #reset-cells:
> + Usage: required
> + Value type:
> + Definition: must be 1; cell entry represents the reset index.
> +
> +Example:
> +
> +aoss_reset: reset-controller@c2b {
> + compatible = "qcom,sdm845-aoss-reset";
> + reg = <0xc2b 0x21000>;
reg = <0xc2a 0x31000>;
> + #reset-cells = <1>;
> +};
> +
Apart from this the binding looks good!
Regards,
Bjorn
Re: [PATCH v5 1/8] dt-bindings: reset: Add AOSS reset bindings for SDM845 SoCs
On Mon 21 May 10:27 PDT 2018, Sibi Sankar wrote:
> Add SDM845 AOSS (always on subsystem) reset controller binding
>
I think it would be better if you made the binding represent the entire
clock controller, rather than only the reset-related portion of it.
As I can't find anything in the downstream kernel that references the
clock part of the hardware block I think the driver can be kept as is
(with updated compatible and adjust the offsets of the registers)
This makes the DT better represents the hardware and it makes it
possible to control the clocks in the future, without breaking backwards
compatibility with existing DTBs.
> Signed-off-by: Sibi Sankar
> ---
> .../bindings/reset/qcom,aoss-reset.txt| 52 +++
> include/dt-bindings/reset/qcom,sdm845-aoss.h | 17 ++
> 2 files changed, 69 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> create mode 100644 include/dt-bindings/reset/qcom,sdm845-aoss.h
>
> diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> new file mode 100644
> index ..cd5dcafb4ed7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt
> @@ -0,0 +1,52 @@
> +Qualcomm AOSS Reset Controller
> +==
> +
> +This binding describes a reset-controller found on AOSS (always on subsystem)
> +for Qualcomm SDM845 SoCs.
> +
> +Required properties:
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: must be:
> + "qcom,sdm845-aoss-reset"
qcom,sdm845-aoss-cc
> +
> +- reg:
> + Usage: required
> + Value type:
> + Definition: must specify the base address and size of the register
> + space.
> +
> +- #reset-cells:
> + Usage: required
> + Value type:
> + Definition: must be 1; cell entry represents the reset index.
> +
> +Example:
> +
> +aoss_reset: reset-controller@c2b {
> + compatible = "qcom,sdm845-aoss-reset";
> + reg = <0xc2b 0x21000>;
reg = <0xc2a 0x31000>;
> + #reset-cells = <1>;
> +};
> +
Apart from this the binding looks good!
Regards,
Bjorn
Re: [PATCH V7 00/41] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling
Hi David, On 6/22/2018 4:45 PM, David Howells wrote: > Do you have a public git branch with these patches on it somewhere? I just added them to branch cache-pseudo-locking/v7 of https://github.com/rchatre/linux.git Reinette
Re: [PATCH V7 00/41] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling
Hi David, On 6/22/2018 4:45 PM, David Howells wrote: > Do you have a public git branch with these patches on it somewhere? I just added them to branch cache-pseudo-locking/v7 of https://github.com/rchatre/linux.git Reinette
Re: [PATCH] platform/x86: dell-smbios: make a function and a pointer static
On Thu, Jun 21, 2018 at 07:15:24PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The function dell_smbios_smm_call and pointer platform_device are
> local to the source and do not need to be in global scope, so make
> them static.
>
> Cleans up sparse warnings:
> warning: symbol 'platform_device' was not declared. Should it be static?
> warning: symbol 'dell_smbios_smm_call' was not declared. Should it be
> static?
>
> Signed-off-by: Colin Ian King
> ---
> drivers/platform/x86/dell-smbios-smm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/dell-smbios-smm.c
> b/drivers/platform/x86/dell-smbios-smm.c
> index e9e9da556318..97a90bebc360 100644
> --- a/drivers/platform/x86/dell-smbios-smm.c
> +++ b/drivers/platform/x86/dell-smbios-smm.c
> @@ -24,7 +24,7 @@
> static int da_command_address;
> static int da_command_code;
> static struct calling_interface_buffer *buffer;
> -struct platform_device *platform_device;
> +static struct platform_device *platform_device;
> static DEFINE_MUTEX(smm_mutex);
>
> static const struct dmi_system_id dell_device_table[] __initconst = {
> @@ -82,7 +82,7 @@ static void find_cmd_address(const struct dmi_header *dm,
> void *dummy)
> }
> }
>
> -int dell_smbios_smm_call(struct calling_interface_buffer *input)
> +static int dell_smbios_smm_call(struct calling_interface_buffer *input)
Hrm. So these are passed by pointer to dell_smbios_register_device(), which is
in
turn called by dell_smbios_call() from dell-smbios-base.c.
So while it is valid to make these static, since we're not referencing the
symbol, but the pointer value instead - I do worry about the "static" suggesting
to someone reading the code that this data is not used outside of this file,
when it is.
I'm not finding a position on this in coding-style.
Andy, do you care to weigh in on this?
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH] platform/x86: dell-smbios: make a function and a pointer static
On Thu, Jun 21, 2018 at 07:15:24PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The function dell_smbios_smm_call and pointer platform_device are
> local to the source and do not need to be in global scope, so make
> them static.
>
> Cleans up sparse warnings:
> warning: symbol 'platform_device' was not declared. Should it be static?
> warning: symbol 'dell_smbios_smm_call' was not declared. Should it be
> static?
>
> Signed-off-by: Colin Ian King
> ---
> drivers/platform/x86/dell-smbios-smm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/dell-smbios-smm.c
> b/drivers/platform/x86/dell-smbios-smm.c
> index e9e9da556318..97a90bebc360 100644
> --- a/drivers/platform/x86/dell-smbios-smm.c
> +++ b/drivers/platform/x86/dell-smbios-smm.c
> @@ -24,7 +24,7 @@
> static int da_command_address;
> static int da_command_code;
> static struct calling_interface_buffer *buffer;
> -struct platform_device *platform_device;
> +static struct platform_device *platform_device;
> static DEFINE_MUTEX(smm_mutex);
>
> static const struct dmi_system_id dell_device_table[] __initconst = {
> @@ -82,7 +82,7 @@ static void find_cmd_address(const struct dmi_header *dm,
> void *dummy)
> }
> }
>
> -int dell_smbios_smm_call(struct calling_interface_buffer *input)
> +static int dell_smbios_smm_call(struct calling_interface_buffer *input)
Hrm. So these are passed by pointer to dell_smbios_register_device(), which is
in
turn called by dell_smbios_call() from dell-smbios-base.c.
So while it is valid to make these static, since we're not referencing the
symbol, but the pointer value instead - I do worry about the "static" suggesting
to someone reading the code that this data is not used outside of this file,
when it is.
I'm not finding a position on this in coding-style.
Andy, do you care to weigh in on this?
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH] MAINTAINERS: Add Daniel Lustig as a LKMM reviewer
On Fri, Jun 22, 2018 at 03:36:02PM -0700, Palmer Dabbelt wrote: > On Fri, 22 Jun 2018 14:48:56 PDT (-0700), Daniel Lustig wrote: > >On 6/22/2018 2:17 PM, Palmer Dabbelt wrote: > >>Dan runs the RISC-V memory model working group. I've been forwarding > >>him LKMM emails that end up in my inbox, but I'm far from an expert in > >>this stuff. He requested to be added as a reviewer, which seem sane to > >>me as it'll take a human out of the loop. > >> > >>CC: Daniel Lustig > >>Signed-off-by: Palmer Dabbelt > > > >Looks like there's an accidental backquote before my name? > > > >Once that gets fixed: > > > >Acked-by: Daniel Lustig > > Thanks. Unless anyone has any opposition I'll submit the fixed > patch as part of my next pull request. Works for me, especially if this means that Daniel is RISC-V's official representative. ;-) Acked-by: Paul E. McKenney > commit 9d01337e4724be4d34bfe848a7c64d14bfdb89ea > gpg: Signature made Fri 22 Jun 2018 03:35:24 PM PDT > gpg:using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41 > gpg:issuer "pal...@dabbelt.com" > gpg: Good signature from "Palmer Dabbelt " [ultimate] > gpg: aka "Palmer Dabbelt " [ultimate] > Author: Palmer Dabbelt > Date: Fri Jun 22 14:04:42 2018 -0700 > >MAINTAINERS: Add Daniel Lustig as a LKMM reviewer > >Dan runs the RISC-V memory model working group. I've been forwarding >him LKMM emails that end up in my inbox, but I'm far from an expert in >this stuff. He requested to be added as a reviewer, which seem sane to >me as it'll take a human out of the loop. > >CC: Daniel Lustig >Acked-by: Daniel Lustig >Signed-off-by: Palmer Dabbelt > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9d5eeff51b5f..ac8ed55dbe9b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8316,6 +8316,7 @@ M: Jade Alglave > M:Luc Maranget > M:"Paul E. McKenney" > R:Akira Yokosawa > +R: Daniel Lustig > L:linux-kernel@vger.kernel.org > S:Supported > T:git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git >
Re: [PATCH] MAINTAINERS: Add Daniel Lustig as a LKMM reviewer
On Fri, Jun 22, 2018 at 03:36:02PM -0700, Palmer Dabbelt wrote: > On Fri, 22 Jun 2018 14:48:56 PDT (-0700), Daniel Lustig wrote: > >On 6/22/2018 2:17 PM, Palmer Dabbelt wrote: > >>Dan runs the RISC-V memory model working group. I've been forwarding > >>him LKMM emails that end up in my inbox, but I'm far from an expert in > >>this stuff. He requested to be added as a reviewer, which seem sane to > >>me as it'll take a human out of the loop. > >> > >>CC: Daniel Lustig > >>Signed-off-by: Palmer Dabbelt > > > >Looks like there's an accidental backquote before my name? > > > >Once that gets fixed: > > > >Acked-by: Daniel Lustig > > Thanks. Unless anyone has any opposition I'll submit the fixed > patch as part of my next pull request. Works for me, especially if this means that Daniel is RISC-V's official representative. ;-) Acked-by: Paul E. McKenney > commit 9d01337e4724be4d34bfe848a7c64d14bfdb89ea > gpg: Signature made Fri 22 Jun 2018 03:35:24 PM PDT > gpg:using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41 > gpg:issuer "pal...@dabbelt.com" > gpg: Good signature from "Palmer Dabbelt " [ultimate] > gpg: aka "Palmer Dabbelt " [ultimate] > Author: Palmer Dabbelt > Date: Fri Jun 22 14:04:42 2018 -0700 > >MAINTAINERS: Add Daniel Lustig as a LKMM reviewer > >Dan runs the RISC-V memory model working group. I've been forwarding >him LKMM emails that end up in my inbox, but I'm far from an expert in >this stuff. He requested to be added as a reviewer, which seem sane to >me as it'll take a human out of the loop. > >CC: Daniel Lustig >Acked-by: Daniel Lustig >Signed-off-by: Palmer Dabbelt > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9d5eeff51b5f..ac8ed55dbe9b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8316,6 +8316,7 @@ M: Jade Alglave > M:Luc Maranget > M:"Paul E. McKenney" > R:Akira Yokosawa > +R: Daniel Lustig > L:linux-kernel@vger.kernel.org > S:Supported > T:git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git >
Re: [PATCH 2/2] mm: introduce mem_cgroup_put() helper
On Fri, Jun 22, 2018 at 5:06 PM Roman Gushchin wrote:
>
> Introduce the mem_cgroup_put() helper, which helps to eliminate
> guarding memcg css release with "#ifdef CONFIG_MEMCG" in multiple
> places.
>
> Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
> Cc: Shakeel Butt
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Andrew Morton
> ---
> include/linux/memcontrol.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index cf1c3555328f..3607913032be 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -383,6 +383,11 @@ struct mem_cgroup *mem_cgroup_from_css(struct
> cgroup_subsys_state *css){
> return css ? container_of(css, struct mem_cgroup, css) : NULL;
> }
>
> +static inline void mem_cgroup_put(struct mem_cgroup *memcg)
> +{
> + css_put(>css);
> +}
> +
> #define mem_cgroup_from_counter(counter, member) \
> container_of(counter, struct mem_cgroup, member)
>
> @@ -852,6 +857,10 @@ static inline bool task_in_mem_cgroup(struct task_struct
> *task,
> return true;
> }
>
> +static inline void mem_cgroup_put(struct mem_cgroup *memcg)
> +{
> +}
> +
> static inline struct mem_cgroup *
> mem_cgroup_iter(struct mem_cgroup *root,
> struct mem_cgroup *prev,
> --
> 2.14.4
>
Re: [PATCH 2/2] mm: introduce mem_cgroup_put() helper
On Fri, Jun 22, 2018 at 5:06 PM Roman Gushchin wrote:
>
> Introduce the mem_cgroup_put() helper, which helps to eliminate
> guarding memcg css release with "#ifdef CONFIG_MEMCG" in multiple
> places.
>
> Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
> Cc: Shakeel Butt
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Andrew Morton
> ---
> include/linux/memcontrol.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index cf1c3555328f..3607913032be 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -383,6 +383,11 @@ struct mem_cgroup *mem_cgroup_from_css(struct
> cgroup_subsys_state *css){
> return css ? container_of(css, struct mem_cgroup, css) : NULL;
> }
>
> +static inline void mem_cgroup_put(struct mem_cgroup *memcg)
> +{
> + css_put(>css);
> +}
> +
> #define mem_cgroup_from_counter(counter, member) \
> container_of(counter, struct mem_cgroup, member)
>
> @@ -852,6 +857,10 @@ static inline bool task_in_mem_cgroup(struct task_struct
> *task,
> return true;
> }
>
> +static inline void mem_cgroup_put(struct mem_cgroup *memcg)
> +{
> +}
> +
> static inline struct mem_cgroup *
> mem_cgroup_iter(struct mem_cgroup *root,
> struct mem_cgroup *prev,
> --
> 2.14.4
>
Re: [PATCH 3/3] irqchip: RISC-V Local Interrupt Controller Driver
On 06/22/2018 04:20 PM, Palmer Dabbelt wrote: > From: Palmer Dabbelt > > This patch adds a driver that manages the local interrupts on each > RISC-V hart, as specifiec by the RISC-V supervisor level ISA manual. > The local interrupt controller manages software interrupts, timer > interrupts, and hardware interrupts (which are routed via the > platform level interrupt controller). Per-hart local interrupt > controllers are found on all RISC-V systems. > > CC: Michael Clark > Signed-off-by: Palmer Dabbelt > --- > drivers/irqchip/Kconfig | 13 +++ > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-riscv-intc.c | 215 > +++ > 3 files changed, 229 insertions(+) > create mode 100644 drivers/irqchip/irq-riscv-intc.c > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig > index e9233db16e03..bf7fc86673b1 100644 > --- a/drivers/irqchip/Kconfig > +++ b/drivers/irqchip/Kconfig > @@ -372,3 +372,16 @@ config QCOM_PDC > IRQs for Qualcomm Technologies Inc (QTI) mobile chips. > > endmenu > + > +config RISCV_INTC > + #bool "RISC-V Interrupt Controller" Hi, What does the leading '#' do? > + depends on RISCV > + default y > + help > +This enables support for the local interrupt controller found in > +standard RISC-V systems. The local interrupt controller handles > +timer interrupts, software interrupts, and hardware interrupts. > +Without a local interrupt controller the system will be unable to > +handle any interrupts, including those passed via the PLIC. > + > +If you don't know what to do here, say Y. > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile > index 15f268f646bf..74e333cc274c 100644 > --- a/drivers/irqchip/Makefile > +++ b/drivers/irqchip/Makefile > @@ -87,3 +87,4 @@ obj-$(CONFIG_MESON_IRQ_GPIO)+= > irq-meson-gpio.o > obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o > obj-$(CONFIG_NDS32) += irq-ativic32.o > obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o > +obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o -- ~Randy
Re: [PATCH 3/3] irqchip: RISC-V Local Interrupt Controller Driver
On 06/22/2018 04:20 PM, Palmer Dabbelt wrote: > From: Palmer Dabbelt > > This patch adds a driver that manages the local interrupts on each > RISC-V hart, as specifiec by the RISC-V supervisor level ISA manual. > The local interrupt controller manages software interrupts, timer > interrupts, and hardware interrupts (which are routed via the > platform level interrupt controller). Per-hart local interrupt > controllers are found on all RISC-V systems. > > CC: Michael Clark > Signed-off-by: Palmer Dabbelt > --- > drivers/irqchip/Kconfig | 13 +++ > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-riscv-intc.c | 215 > +++ > 3 files changed, 229 insertions(+) > create mode 100644 drivers/irqchip/irq-riscv-intc.c > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig > index e9233db16e03..bf7fc86673b1 100644 > --- a/drivers/irqchip/Kconfig > +++ b/drivers/irqchip/Kconfig > @@ -372,3 +372,16 @@ config QCOM_PDC > IRQs for Qualcomm Technologies Inc (QTI) mobile chips. > > endmenu > + > +config RISCV_INTC > + #bool "RISC-V Interrupt Controller" Hi, What does the leading '#' do? > + depends on RISCV > + default y > + help > +This enables support for the local interrupt controller found in > +standard RISC-V systems. The local interrupt controller handles > +timer interrupts, software interrupts, and hardware interrupts. > +Without a local interrupt controller the system will be unable to > +handle any interrupts, including those passed via the PLIC. > + > +If you don't know what to do here, say Y. > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile > index 15f268f646bf..74e333cc274c 100644 > --- a/drivers/irqchip/Makefile > +++ b/drivers/irqchip/Makefile > @@ -87,3 +87,4 @@ obj-$(CONFIG_MESON_IRQ_GPIO)+= > irq-meson-gpio.o > obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o > obj-$(CONFIG_NDS32) += irq-ativic32.o > obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o > +obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o -- ~Randy
[PATCH 1/2] mm: revert mem_cgroup_put() introduction
This patch should be folded into "mm, oom: cgroup-aware OOM killer".
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 3607913032be..cf1c3555328f 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -383,11 +383,6 @@ struct mem_cgroup *mem_cgroup_from_css(struct
cgroup_subsys_state *css){
return css ? container_of(css, struct mem_cgroup, css) : NULL;
}
-static inline void mem_cgroup_put(struct mem_cgroup *memcg)
-{
- css_put(>css);
-}
-
#define mem_cgroup_from_counter(counter, member) \
container_of(counter, struct mem_cgroup, member)
@@ -857,10 +852,6 @@ static inline bool task_in_mem_cgroup(struct task_struct
*task,
return true;
}
-static inline void mem_cgroup_put(struct mem_cgroup *memcg)
-{
-}
-
static inline struct mem_cgroup *
mem_cgroup_iter(struct mem_cgroup *root,
struct mem_cgroup *prev,
--
2.14.4
[PATCH 1/2] mm: revert mem_cgroup_put() introduction
This patch should be folded into "mm, oom: cgroup-aware OOM killer".
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 3607913032be..cf1c3555328f 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -383,11 +383,6 @@ struct mem_cgroup *mem_cgroup_from_css(struct
cgroup_subsys_state *css){
return css ? container_of(css, struct mem_cgroup, css) : NULL;
}
-static inline void mem_cgroup_put(struct mem_cgroup *memcg)
-{
- css_put(>css);
-}
-
#define mem_cgroup_from_counter(counter, member) \
container_of(counter, struct mem_cgroup, member)
@@ -857,10 +852,6 @@ static inline bool task_in_mem_cgroup(struct task_struct
*task,
return true;
}
-static inline void mem_cgroup_put(struct mem_cgroup *memcg)
-{
-}
-
static inline struct mem_cgroup *
mem_cgroup_iter(struct mem_cgroup *root,
struct mem_cgroup *prev,
--
2.14.4
[PATCH 2/2] mm: introduce mem_cgroup_put() helper
Introduce the mem_cgroup_put() helper, which helps to eliminate
guarding memcg css release with "#ifdef CONFIG_MEMCG" in multiple
places.
Signed-off-by: Roman Gushchin
Cc: Shakeel Butt
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Andrew Morton
---
include/linux/memcontrol.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index cf1c3555328f..3607913032be 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -383,6 +383,11 @@ struct mem_cgroup *mem_cgroup_from_css(struct
cgroup_subsys_state *css){
return css ? container_of(css, struct mem_cgroup, css) : NULL;
}
+static inline void mem_cgroup_put(struct mem_cgroup *memcg)
+{
+ css_put(>css);
+}
+
#define mem_cgroup_from_counter(counter, member) \
container_of(counter, struct mem_cgroup, member)
@@ -852,6 +857,10 @@ static inline bool task_in_mem_cgroup(struct task_struct
*task,
return true;
}
+static inline void mem_cgroup_put(struct mem_cgroup *memcg)
+{
+}
+
static inline struct mem_cgroup *
mem_cgroup_iter(struct mem_cgroup *root,
struct mem_cgroup *prev,
--
2.14.4
[PATCH 2/2] mm: introduce mem_cgroup_put() helper
Introduce the mem_cgroup_put() helper, which helps to eliminate
guarding memcg css release with "#ifdef CONFIG_MEMCG" in multiple
places.
Signed-off-by: Roman Gushchin
Cc: Shakeel Butt
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Andrew Morton
---
include/linux/memcontrol.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index cf1c3555328f..3607913032be 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -383,6 +383,11 @@ struct mem_cgroup *mem_cgroup_from_css(struct
cgroup_subsys_state *css){
return css ? container_of(css, struct mem_cgroup, css) : NULL;
}
+static inline void mem_cgroup_put(struct mem_cgroup *memcg)
+{
+ css_put(>css);
+}
+
#define mem_cgroup_from_counter(counter, member) \
container_of(counter, struct mem_cgroup, member)
@@ -852,6 +857,10 @@ static inline bool task_in_mem_cgroup(struct task_struct
*task,
return true;
}
+static inline void mem_cgroup_put(struct mem_cgroup *memcg)
+{
+}
+
static inline struct mem_cgroup *
mem_cgroup_iter(struct mem_cgroup *root,
struct mem_cgroup *prev,
--
2.14.4
Re: [PATCH] platform/x86: ideapad-laptop: Apply no_hw_rfkill to Y20-15IKBM, too
On Fri, Jun 22, 2018 at 10:59:17AM +0200, Takashi Iwai wrote:
> The commit 5d9f40b56630 ("platform/x86: ideapad-laptop: Add
> Y520-15IKBN to no_hw_rfkill") added the entry for Y20-15IKBN, and it
> turned out that another variant, Y20-15IKBM, also requires the
> no_hw_rfkill.
>
> Trim the last letter from the string so that it matches to both
> Y20-15IKBN and Y20-15IKBM models.
>
> Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1098626
> Cc:
> Signed-off-by: Takashi Iwai
Thanks Takashi, queued.
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH] platform/x86: ideapad-laptop: Apply no_hw_rfkill to Y20-15IKBM, too
On Fri, Jun 22, 2018 at 10:59:17AM +0200, Takashi Iwai wrote:
> The commit 5d9f40b56630 ("platform/x86: ideapad-laptop: Add
> Y520-15IKBN to no_hw_rfkill") added the entry for Y20-15IKBN, and it
> turned out that another variant, Y20-15IKBM, also requires the
> no_hw_rfkill.
>
> Trim the last letter from the string so that it matches to both
> Y20-15IKBN and Y20-15IKBM models.
>
> Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1098626
> Cc:
> Signed-off-by: Takashi Iwai
Thanks Takashi, queued.
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH] platform/x86: dell-smbios-base: Support systems without tokens
On Fri, Jun 15, 2018 at 12:12:51PM -0500, Mario Limonciello wrote: > Some Dell servers can use dell-smbios but they don't support the > token interface. Make it optional. > > Signed-off-by: Mario Limonciello Thanks Mario, queued. -- Darren Hart VMware Open Source Technology Center
Re: [PATCH] platform/x86: dell-smbios-base: Support systems without tokens
On Fri, Jun 15, 2018 at 12:12:51PM -0500, Mario Limonciello wrote: > Some Dell servers can use dell-smbios but they don't support the > token interface. Make it optional. > > Signed-off-by: Mario Limonciello Thanks Mario, queued. -- Darren Hart VMware Open Source Technology Center
Re: [PATCH V7 00/41] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling
Do you have a public git branch with these patches on it somewhere? Thanks, David
Re: [PATCH V7 00/41] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling
Do you have a public git branch with these patches on it somewhere? Thanks, David
Re: [PATCH 3/3] fs, mm: account buffer_head to kmemcg
On Tue, Jun 19, 2018 at 12:55 PM Roman Gushchin wrote:
>
> On Tue, Jun 19, 2018 at 12:51:15PM -0700, Shakeel Butt wrote:
> > On Tue, Jun 19, 2018 at 10:41 AM Roman Gushchin wrote:
> > >
> > > On Tue, Jun 19, 2018 at 12:27:41PM -0400, Johannes Weiner wrote:
> > > > On Mon, Jun 18, 2018 at 10:13:27PM -0700, Shakeel Butt wrote:
> > > > > The buffer_head can consume a significant amount of system memory and
> > > > > is directly related to the amount of page cache. In our production
> > > > > environment we have observed that a lot of machines are spending a
> > > > > significant amount of memory as buffer_head and can not be left as
> > > > > system memory overhead.
> > > > >
> > > > > Charging buffer_head is not as simple as adding __GFP_ACCOUNT to the
> > > > > allocation. The buffer_heads can be allocated in a memcg different
> > > > > from
> > > > > the memcg of the page for which buffer_heads are being allocated. One
> > > > > concrete example is memory reclaim. The reclaim can trigger I/O of
> > > > > pages
> > > > > of any memcg on the system. So, the right way to charge buffer_head is
> > > > > to extract the memcg from the page for which buffer_heads are being
> > > > > allocated and then use targeted memcg charging API.
> > > > >
> > > > > Signed-off-by: Shakeel Butt
> > > > > Cc: Jan Kara
> > > > > Cc: Greg Thelen
> > > > > Cc: Michal Hocko
> > > > > Cc: Johannes Weiner
> > > > > Cc: Vladimir Davydov
> > > > > Cc: Alexander Viro
> > > > > Cc: Andrew Morton
> > > > > ---
> > > > > fs/buffer.c| 14 +-
> > > > > include/linux/memcontrol.h | 7 +++
> > > > > mm/memcontrol.c| 21 +
> > > > > 3 files changed, 41 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/fs/buffer.c b/fs/buffer.c
> > > > > index 8194e3049fc5..26389b7a3cab 100644
> > > > > --- a/fs/buffer.c
> > > > > +++ b/fs/buffer.c
> > > > > @@ -815,10 +815,17 @@ struct buffer_head *alloc_page_buffers(struct
> > > > > page *page, unsigned long size,
> > > > > struct buffer_head *bh, *head;
> > > > > gfp_t gfp = GFP_NOFS;
> > > > > long offset;
> > > > > + struct mem_cgroup *old_memcg;
> > > > > + struct mem_cgroup *memcg = get_mem_cgroup_from_page(page);
> > > > >
> > > > > if (retry)
> > > > > gfp |= __GFP_NOFAIL;
> > > > >
> > > > > + if (memcg) {
> > > > > + gfp |= __GFP_ACCOUNT;
> > > > > + old_memcg = memalloc_memcg_save(memcg);
> > > > > + }
> > > >
> > > > Please move the get_mem_cgroup_from_page() call out of the
> > > > declarations and down to right before the if (memcg) branch.
> > > >
> > > > > head = NULL;
> > > > > offset = PAGE_SIZE;
> > > > > while ((offset -= size) >= 0) {
> > > > > @@ -835,6 +842,11 @@ struct buffer_head *alloc_page_buffers(struct
> > > > > page *page, unsigned long size,
> > > > > /* Link the buffer to its page */
> > > > > set_bh_page(bh, page, offset);
> > > > > }
> > > > > +out:
> > > > > + if (memcg) {
> > > > > + memalloc_memcg_restore(old_memcg);
> > > > > +#ifdef CONFIG_MEMCG
> > > > > + css_put(>css);
> > > > > +#endif
> > > >
> > > > Please add a put_mem_cgroup() ;)
> > >
> > > I've added such helper by commit 8a34a8b7fd62 ("mm, oom: cgroup-aware OOM
> > > killer").
> > > It's in the mm tree.
> > >
> >
> > I was using mem_cgroup_put() defined by Roman's patch but there were a
> > lot of build failure reports where someone was taking this series
> > without Roman's series or applying the series out of order. Andrew
> > asked me to keep it like this and then he will convert these callsites
> > into mem_cgroup_put() after making making sure Roman's series is
> > applied in mm tree. I will recheck with him, how he wants to handle it
> > now.
>
> I can also split the introduction of mem_cgroup_put() into a separate commit,
> as it seems to be usable not only by the cgroup oom stuff.
> Please, let me know, if it's a preferred way to go.
>
Oh I forgot to reply. Yes, let's do that, a separate patch to
introduce mem_cgroup_put() which can used by remote charging and memcg
aware oom-killer patches.
Shakeel
Re: [PATCH 3/3] fs, mm: account buffer_head to kmemcg
On Tue, Jun 19, 2018 at 12:55 PM Roman Gushchin wrote:
>
> On Tue, Jun 19, 2018 at 12:51:15PM -0700, Shakeel Butt wrote:
> > On Tue, Jun 19, 2018 at 10:41 AM Roman Gushchin wrote:
> > >
> > > On Tue, Jun 19, 2018 at 12:27:41PM -0400, Johannes Weiner wrote:
> > > > On Mon, Jun 18, 2018 at 10:13:27PM -0700, Shakeel Butt wrote:
> > > > > The buffer_head can consume a significant amount of system memory and
> > > > > is directly related to the amount of page cache. In our production
> > > > > environment we have observed that a lot of machines are spending a
> > > > > significant amount of memory as buffer_head and can not be left as
> > > > > system memory overhead.
> > > > >
> > > > > Charging buffer_head is not as simple as adding __GFP_ACCOUNT to the
> > > > > allocation. The buffer_heads can be allocated in a memcg different
> > > > > from
> > > > > the memcg of the page for which buffer_heads are being allocated. One
> > > > > concrete example is memory reclaim. The reclaim can trigger I/O of
> > > > > pages
> > > > > of any memcg on the system. So, the right way to charge buffer_head is
> > > > > to extract the memcg from the page for which buffer_heads are being
> > > > > allocated and then use targeted memcg charging API.
> > > > >
> > > > > Signed-off-by: Shakeel Butt
> > > > > Cc: Jan Kara
> > > > > Cc: Greg Thelen
> > > > > Cc: Michal Hocko
> > > > > Cc: Johannes Weiner
> > > > > Cc: Vladimir Davydov
> > > > > Cc: Alexander Viro
> > > > > Cc: Andrew Morton
> > > > > ---
> > > > > fs/buffer.c| 14 +-
> > > > > include/linux/memcontrol.h | 7 +++
> > > > > mm/memcontrol.c| 21 +
> > > > > 3 files changed, 41 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/fs/buffer.c b/fs/buffer.c
> > > > > index 8194e3049fc5..26389b7a3cab 100644
> > > > > --- a/fs/buffer.c
> > > > > +++ b/fs/buffer.c
> > > > > @@ -815,10 +815,17 @@ struct buffer_head *alloc_page_buffers(struct
> > > > > page *page, unsigned long size,
> > > > > struct buffer_head *bh, *head;
> > > > > gfp_t gfp = GFP_NOFS;
> > > > > long offset;
> > > > > + struct mem_cgroup *old_memcg;
> > > > > + struct mem_cgroup *memcg = get_mem_cgroup_from_page(page);
> > > > >
> > > > > if (retry)
> > > > > gfp |= __GFP_NOFAIL;
> > > > >
> > > > > + if (memcg) {
> > > > > + gfp |= __GFP_ACCOUNT;
> > > > > + old_memcg = memalloc_memcg_save(memcg);
> > > > > + }
> > > >
> > > > Please move the get_mem_cgroup_from_page() call out of the
> > > > declarations and down to right before the if (memcg) branch.
> > > >
> > > > > head = NULL;
> > > > > offset = PAGE_SIZE;
> > > > > while ((offset -= size) >= 0) {
> > > > > @@ -835,6 +842,11 @@ struct buffer_head *alloc_page_buffers(struct
> > > > > page *page, unsigned long size,
> > > > > /* Link the buffer to its page */
> > > > > set_bh_page(bh, page, offset);
> > > > > }
> > > > > +out:
> > > > > + if (memcg) {
> > > > > + memalloc_memcg_restore(old_memcg);
> > > > > +#ifdef CONFIG_MEMCG
> > > > > + css_put(>css);
> > > > > +#endif
> > > >
> > > > Please add a put_mem_cgroup() ;)
> > >
> > > I've added such helper by commit 8a34a8b7fd62 ("mm, oom: cgroup-aware OOM
> > > killer").
> > > It's in the mm tree.
> > >
> >
> > I was using mem_cgroup_put() defined by Roman's patch but there were a
> > lot of build failure reports where someone was taking this series
> > without Roman's series or applying the series out of order. Andrew
> > asked me to keep it like this and then he will convert these callsites
> > into mem_cgroup_put() after making making sure Roman's series is
> > applied in mm tree. I will recheck with him, how he wants to handle it
> > now.
>
> I can also split the introduction of mem_cgroup_put() into a separate commit,
> as it seems to be usable not only by the cgroup oom stuff.
> Please, let me know, if it's a preferred way to go.
>
Oh I forgot to reply. Yes, let's do that, a separate patch to
introduce mem_cgroup_put() which can used by remote charging and memcg
aware oom-killer patches.
Shakeel
Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc
On Thu, Jun 21, 2018 at 01:24:34AM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Darren Hart [mailto:dvh...@infradead.org] > > Sent: Wednesday, June 20, 2018 7:17 PM > > To: Kees Cook > > Cc: LKML; Andy Shevchenko; Platform Driver; Mihai Donțu; Limonciello, Mario > > Subject: Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc > > > > On Wed, Jun 20, 2018 at 04:43:14PM -0700, Kees Cook wrote: > > > On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart wrote: > > > > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: > > > >> The probe handler_data was being allocated with __get_free_pages() > > > >> for no reason I could find. The error path was using kfree(). Since > > > > > > > > v4 of Mario's series used kmalloc: > > > > https://patchwork.kernel.org/patch/9985827/ > > > > > > > > This was changed in v10 to use __get_free_pages: > > > > https://patchwork.kernel.org/patch/10018023/ > > > > > > > > But... I'm not finding the discussion that led to this change Mario, > > > > do you recall? Something about contiguous memory? We had a similar > > > > discussion on an earlier series: > > > > > > > > https://patchwork.kernel.org/patch/9975277/ > > > > > > FWIW, kmalloc gets you contiguous memory... > > > > Yeah, I'm not finding a valid reason to use __get_free_pages over kmalloc in > > this case. I'll give Mario a chance to respond in case I'm just missing > > something, but otherwise will plan to apply this patch. > > I think it was for contiguous memory, so if kmalloc is giving that I agree > no need to keep __get_free_pages instead. > > Acked-by: Mario Limonciello Confirmed, kmalloc in physically contiguous. Queued up, and tagged for stable. Thanks everyone. -- Darren Hart VMware Open Source Technology Center
Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc
On Thu, Jun 21, 2018 at 01:24:34AM +, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Darren Hart [mailto:dvh...@infradead.org] > > Sent: Wednesday, June 20, 2018 7:17 PM > > To: Kees Cook > > Cc: LKML; Andy Shevchenko; Platform Driver; Mihai Donțu; Limonciello, Mario > > Subject: Re: [PATCH] platform/x86: wmi: Do not mix pages and kmalloc > > > > On Wed, Jun 20, 2018 at 04:43:14PM -0700, Kees Cook wrote: > > > On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart wrote: > > > > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote: > > > >> The probe handler_data was being allocated with __get_free_pages() > > > >> for no reason I could find. The error path was using kfree(). Since > > > > > > > > v4 of Mario's series used kmalloc: > > > > https://patchwork.kernel.org/patch/9985827/ > > > > > > > > This was changed in v10 to use __get_free_pages: > > > > https://patchwork.kernel.org/patch/10018023/ > > > > > > > > But... I'm not finding the discussion that led to this change Mario, > > > > do you recall? Something about contiguous memory? We had a similar > > > > discussion on an earlier series: > > > > > > > > https://patchwork.kernel.org/patch/9975277/ > > > > > > FWIW, kmalloc gets you contiguous memory... > > > > Yeah, I'm not finding a valid reason to use __get_free_pages over kmalloc in > > this case. I'll give Mario a chance to respond in case I'm just missing > > something, but otherwise will plan to apply this patch. > > I think it was for contiguous memory, so if kmalloc is giving that I agree > no need to keep __get_free_pages instead. > > Acked-by: Mario Limonciello Confirmed, kmalloc in physically contiguous. Queued up, and tagged for stable. Thanks everyone. -- Darren Hart VMware Open Source Technology Center
Re: [PATCH] arch/x86/entry/vsyscall/vsyscall_gtod.c: remove __read_mostly from vclocks_used
On Fri, Jun 22, 2018 at 3:47 PM Thomas Gleixner wrote:
>
> Michael,
>
> On Mon, 4 Jun 2018, Michael Rodin wrote:
>
> > The variable "vclocks_used" doesn't appear to be "read mostly".
> > Measurements of the access frequency with perf stat [1] and
> > perf report show, that approximately half of the accesses to
> > this variable are write accesses and happen in update_vsyscall()
> > in the file arch/x86/entry/vsyscall/vsyscall_gtod.c.
> > The measurements were done with the kernel 4.13.0-43-generic used by
> > ubuntu as well as with the stable kernel 4.16.7 with a custom config.
> > I've used "perf bench sched" and iperf3 as workloads.
> >
> > This was discovered during my master thesis in the CADOS project [2].
>
> Nice find, but ...
>
> The point is that the content of that variable changes once in a blue moon,
> so the intent of marking it read_mostly is almost correct.
I would propose a rather different fix. Add a an
arch_change_clocksource() function. Do:
static inline void arch_change_clocksource(struct clocksource
*new_clocksource) { ... }
#define arch_change_clocksource arch_change_clocksource
and
#ifndef arch_change_clocksource
static inline void arch_change_clocksource(struct clocksource
*new_clocksource) {}
#endif
in the generic header. In change_clocksource(), add a call to
arch_change_clocksource() right after tk_setup_internals(). In x86's
arch_change_clocksource, update vclocks_used.
Now it's genuinely read_mostly, and we don't need to touch that
cacheline at all in the normal clock tick code. Everyone wins.
(vclocks_used is actually rather rarely read. It's only used to
prevent user code from accessing a never-used clocksource through the
vvar area, which is a hardening measure. It's only referenced from
the vvar fault handler code.)
--Andy
Re: [PATCH] arch/x86/entry/vsyscall/vsyscall_gtod.c: remove __read_mostly from vclocks_used
On Fri, Jun 22, 2018 at 3:47 PM Thomas Gleixner wrote:
>
> Michael,
>
> On Mon, 4 Jun 2018, Michael Rodin wrote:
>
> > The variable "vclocks_used" doesn't appear to be "read mostly".
> > Measurements of the access frequency with perf stat [1] and
> > perf report show, that approximately half of the accesses to
> > this variable are write accesses and happen in update_vsyscall()
> > in the file arch/x86/entry/vsyscall/vsyscall_gtod.c.
> > The measurements were done with the kernel 4.13.0-43-generic used by
> > ubuntu as well as with the stable kernel 4.16.7 with a custom config.
> > I've used "perf bench sched" and iperf3 as workloads.
> >
> > This was discovered during my master thesis in the CADOS project [2].
>
> Nice find, but ...
>
> The point is that the content of that variable changes once in a blue moon,
> so the intent of marking it read_mostly is almost correct.
I would propose a rather different fix. Add a an
arch_change_clocksource() function. Do:
static inline void arch_change_clocksource(struct clocksource
*new_clocksource) { ... }
#define arch_change_clocksource arch_change_clocksource
and
#ifndef arch_change_clocksource
static inline void arch_change_clocksource(struct clocksource
*new_clocksource) {}
#endif
in the generic header. In change_clocksource(), add a call to
arch_change_clocksource() right after tk_setup_internals(). In x86's
arch_change_clocksource, update vclocks_used.
Now it's genuinely read_mostly, and we don't need to touch that
cacheline at all in the normal clock tick code. Everyone wins.
(vclocks_used is actually rather rarely read. It's only used to
prevent user code from accessing a never-used clocksource through the
vvar area, which is a hardening measure. It's only referenced from
the vvar fault handler code.)
--Andy
[PATCH 1/3] RISC-V: Don't include irq-riscv-intc.h
This file has never existed in the upstream kernel, but it's guarded by
an #ifdef that's also never existed in the upstream kernel. As a part
of our interrupt controller refactoring this header is no longer
necessary, but this reference managed to sneak in anyway.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/irq.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index b74cbfbce2d0..7bcdaed15703 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -16,10 +16,6 @@
#include
#include
-#ifdef CONFIG_RISCV_INTC
-#include
-#endif
-
void __init init_IRQ(void)
{
irqchip_init();
--
2.16.4
Driver for the RISC-V Interrupt Controller
The RISC-V ISA mandantes the presence of a simple, per-hart (hardware thread) interrupt controller availiable to supervisor mode. This patch set adds a driver for this interrupt controller. The patch set itself has been around in various flavors for a while, but as far as I remember it's never been properly cleaned up and submitted before. As it currently stands it's essentially three seperate patches, but as they're all intertwined I'm keeping them together. Sorry if that's the wrong thing to do. The patches are: * A cleanup to arch/riscv to remove a bit of the old initialization mechanism that snuck in to our arch port. This patch is trivial, so unless there's any feedback on it specificly I'll include it in my next pull request. * The addition of device tree bindings to describe "riscv,cpu-intc". * The actual irqchip driver. If this gets merged before the arch/riscv patch then it'll cause our build to fail, but I'm assuming this will be targeted at the next merge window so we should be safe.
[PATCH 1/3] RISC-V: Don't include irq-riscv-intc.h
This file has never existed in the upstream kernel, but it's guarded by
an #ifdef that's also never existed in the upstream kernel. As a part
of our interrupt controller refactoring this header is no longer
necessary, but this reference managed to sneak in anyway.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/irq.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index b74cbfbce2d0..7bcdaed15703 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -16,10 +16,6 @@
#include
#include
-#ifdef CONFIG_RISCV_INTC
-#include
-#endif
-
void __init init_IRQ(void)
{
irqchip_init();
--
2.16.4
Driver for the RISC-V Interrupt Controller
The RISC-V ISA mandantes the presence of a simple, per-hart (hardware thread) interrupt controller availiable to supervisor mode. This patch set adds a driver for this interrupt controller. The patch set itself has been around in various flavors for a while, but as far as I remember it's never been properly cleaned up and submitted before. As it currently stands it's essentially three seperate patches, but as they're all intertwined I'm keeping them together. Sorry if that's the wrong thing to do. The patches are: * A cleanup to arch/riscv to remove a bit of the old initialization mechanism that snuck in to our arch port. This patch is trivial, so unless there's any feedback on it specificly I'll include it in my next pull request. * The addition of device tree bindings to describe "riscv,cpu-intc". * The actual irqchip driver. If this gets merged before the arch/riscv patch then it'll cause our build to fail, but I'm assuming this will be targeted at the next merge window so we should be safe.
[PATCH 2/3] dt-bindings: interrupt-controller: RISC-V local interrupt controller docs
From: Palmer Dabbelt
This patch adds documentation on the RISC-V local interrupt controller,
which is a per-hart interrupt controller that manages all interrupts
entering a RISC-V hart. This interrupt controller is present on all
RISC-V systems.
Signed-off-by: Palmer Dabbelt
---
.../interrupt-controller/riscv,cpu-intc.txt| 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
new file mode 100644
index ..61900e2e3868
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
@@ -0,0 +1,41 @@
+RISC-V Hart-Level Interrupt Controller (HLIC)
+-
+
+RISC-V cores include Control Status Registers (CSRs) which are local to each
+hart and can be read or written by software. Some of these CSRs are used to
+control local interrupts connected to the core. Every interrupt is ultimately
+routed through a hart's HLIC before it interrupts that hart.
+
+The RISC-V supervisor ISA manual specifies three interrupt sources that are
+attached to every HLIC: software interrupts, the timer interrupt, and external
+interrupts. Software interrupts are used to send IPIs between cores. The
+timer interrupt comes from an architecturally mandated real-time timer that is
+controller via SBI calls and CSR reads. External interrupts connect all other
+device interrupts to the HLIC, which are routed via the platform-level
+interrupt controller (PLIC).
+
+All RISC-V systems that conform to the supervisor ISA specification are
+required to have a HLIC with these three interrupt sources present. Since the
+interrupt map is defined by the ISA it's not listed in the HLIC's device tree
+entry, though external interrupt controllers (like the PLIC, for example) will
+need to define how their interrupts map to the relevant HLICs.
+
+Required properties:
+- compatible : "riscv,cpu-intc"
+- #interrupt-cells : should be <1>
+- interrupt-controller : Identifies the node as an interrupt controller
+
+Furthermore, this interrupt-controller MUST be embedded inside the cpu
+definition of the hart whose CSRs control these local interrupts.
+
+An example device tree entry for a HLIC is show below.
+
+ cpu1: cpu@1 {
+ compatible = "riscv";
+ ...
+ cpu1-intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
--
2.16.4
[PATCH 2/3] dt-bindings: interrupt-controller: RISC-V local interrupt controller docs
From: Palmer Dabbelt
This patch adds documentation on the RISC-V local interrupt controller,
which is a per-hart interrupt controller that manages all interrupts
entering a RISC-V hart. This interrupt controller is present on all
RISC-V systems.
Signed-off-by: Palmer Dabbelt
---
.../interrupt-controller/riscv,cpu-intc.txt| 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
new file mode 100644
index ..61900e2e3868
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
@@ -0,0 +1,41 @@
+RISC-V Hart-Level Interrupt Controller (HLIC)
+-
+
+RISC-V cores include Control Status Registers (CSRs) which are local to each
+hart and can be read or written by software. Some of these CSRs are used to
+control local interrupts connected to the core. Every interrupt is ultimately
+routed through a hart's HLIC before it interrupts that hart.
+
+The RISC-V supervisor ISA manual specifies three interrupt sources that are
+attached to every HLIC: software interrupts, the timer interrupt, and external
+interrupts. Software interrupts are used to send IPIs between cores. The
+timer interrupt comes from an architecturally mandated real-time timer that is
+controller via SBI calls and CSR reads. External interrupts connect all other
+device interrupts to the HLIC, which are routed via the platform-level
+interrupt controller (PLIC).
+
+All RISC-V systems that conform to the supervisor ISA specification are
+required to have a HLIC with these three interrupt sources present. Since the
+interrupt map is defined by the ISA it's not listed in the HLIC's device tree
+entry, though external interrupt controllers (like the PLIC, for example) will
+need to define how their interrupts map to the relevant HLICs.
+
+Required properties:
+- compatible : "riscv,cpu-intc"
+- #interrupt-cells : should be <1>
+- interrupt-controller : Identifies the node as an interrupt controller
+
+Furthermore, this interrupt-controller MUST be embedded inside the cpu
+definition of the hart whose CSRs control these local interrupts.
+
+An example device tree entry for a HLIC is show below.
+
+ cpu1: cpu@1 {
+ compatible = "riscv";
+ ...
+ cpu1-intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
--
2.16.4
[PATCH 3/3] irqchip: RISC-V Local Interrupt Controller Driver
From: Palmer Dabbelt
This patch adds a driver that manages the local interrupts on each
RISC-V hart, as specifiec by the RISC-V supervisor level ISA manual.
The local interrupt controller manages software interrupts, timer
interrupts, and hardware interrupts (which are routed via the
platform level interrupt controller). Per-hart local interrupt
controllers are found on all RISC-V systems.
CC: Michael Clark
Signed-off-by: Palmer Dabbelt
---
drivers/irqchip/Kconfig | 13 +++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-riscv-intc.c | 215 +++
3 files changed, 229 insertions(+)
create mode 100644 drivers/irqchip/irq-riscv-intc.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e9233db16e03..bf7fc86673b1 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -372,3 +372,16 @@ config QCOM_PDC
IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
endmenu
+
+config RISCV_INTC
+ #bool "RISC-V Interrupt Controller"
+ depends on RISCV
+ default y
+ help
+ This enables support for the local interrupt controller found in
+ standard RISC-V systems. The local interrupt controller handles
+ timer interrupts, software interrupts, and hardware interrupts.
+ Without a local interrupt controller the system will be unable to
+ handle any interrupts, including those passed via the PLIC.
+
+ If you don't know what to do here, say Y.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 15f268f646bf..74e333cc274c 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -87,3 +87,4 @@ obj-$(CONFIG_MESON_IRQ_GPIO) += irq-meson-gpio.o
obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o
obj-$(CONFIG_NDS32)+= irq-ativic32.o
obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
+obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o
diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
new file mode 100644
index ..7ca3060e76b4
--- /dev/null
+++ b/drivers/irqchip/irq-riscv-intc.c
@@ -0,0 +1,215 @@
+/*
+ * Copyright (C) 2012 Regents of the University of California
+ * Copyright (C) 2017-2018 SiFive
+ */
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define PTR_BITS (8 * sizeof(uintptr_t))
+
+struct riscv_irq_data {
+ struct irq_chip chip;
+ struct irq_domain *domain;
+ int hart;
+ charname[20];
+};
+DEFINE_PER_CPU(struct riscv_irq_data, riscv_irq_data);
+
+static void riscv_software_interrupt(void)
+{
+#ifdef CONFIG_SMP
+ irqreturn_t ret;
+
+ ret = handle_ipi();
+
+ WARN_ON(ret == IRQ_NONE);
+#else
+ /*
+* We currently only use software interrupts to pass inter-processor
+* interrupts, so if a non-SMP system gets a software interrupt then we
+* don't know what to do.
+*/
+ pr_warning("Software Interrupt without CONFIG_SMP\n");
+#endif
+}
+
+static void riscv_intc_irq(struct pt_regs *regs)
+{
+ struct pt_regs *old_regs = set_irq_regs(regs);
+ struct irq_domain *domain;
+ unsigned long cause = csr_read(scause);
+
+ /*
+* The high order bit of the trap cause register is always set for
+* interrupts, which allows us to differentiate them from exceptions
+* quickly. The INTERRUPT_CAUSE_* macros don't contain that bit, so we
+* need to mask it off here.
+*/
+ WARN_ON((cause & (1UL << (PTR_BITS - 1))) == 0);
+ cause = cause & ~(1UL << (PTR_BITS - 1));
+
+ irq_enter();
+
+ /*
+* There are three classes of interrupt: timer, software, and
+* external devices. We dispatch between them here. External
+* device interrupts use the generic IRQ mechanisms.
+*/
+ switch (cause) {
+ case INTERRUPT_CAUSE_TIMER:
+ riscv_timer_interrupt();
+ break;
+ case INTERRUPT_CAUSE_SOFTWARE:
+ riscv_software_interrupt();
+ break;
+ default:
+ domain = per_cpu(riscv_irq_data, smp_processor_id()).domain;
+ generic_handle_irq(irq_find_mapping(domain, cause));
+ break;
+ }
+
+ irq_exit();
+ set_irq_regs(old_regs);
+}
+
+static int riscv_irqdomain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ struct riscv_irq_data *data = d->host_data;
+
+ irq_set_chip_and_handler(irq, >chip, handle_simple_irq);
+ irq_set_chip_data(irq, data);
+ irq_set_noprobe(irq);
+ irq_set_affinity(irq, cpumask_of(data->hart));
+
+ return 0;
+}
+
+static const struct irq_domain_ops
[PATCH 3/3] irqchip: RISC-V Local Interrupt Controller Driver
From: Palmer Dabbelt
This patch adds a driver that manages the local interrupts on each
RISC-V hart, as specifiec by the RISC-V supervisor level ISA manual.
The local interrupt controller manages software interrupts, timer
interrupts, and hardware interrupts (which are routed via the
platform level interrupt controller). Per-hart local interrupt
controllers are found on all RISC-V systems.
CC: Michael Clark
Signed-off-by: Palmer Dabbelt
---
drivers/irqchip/Kconfig | 13 +++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-riscv-intc.c | 215 +++
3 files changed, 229 insertions(+)
create mode 100644 drivers/irqchip/irq-riscv-intc.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e9233db16e03..bf7fc86673b1 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -372,3 +372,16 @@ config QCOM_PDC
IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
endmenu
+
+config RISCV_INTC
+ #bool "RISC-V Interrupt Controller"
+ depends on RISCV
+ default y
+ help
+ This enables support for the local interrupt controller found in
+ standard RISC-V systems. The local interrupt controller handles
+ timer interrupts, software interrupts, and hardware interrupts.
+ Without a local interrupt controller the system will be unable to
+ handle any interrupts, including those passed via the PLIC.
+
+ If you don't know what to do here, say Y.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 15f268f646bf..74e333cc274c 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -87,3 +87,4 @@ obj-$(CONFIG_MESON_IRQ_GPIO) += irq-meson-gpio.o
obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o
obj-$(CONFIG_NDS32)+= irq-ativic32.o
obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
+obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o
diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
new file mode 100644
index ..7ca3060e76b4
--- /dev/null
+++ b/drivers/irqchip/irq-riscv-intc.c
@@ -0,0 +1,215 @@
+/*
+ * Copyright (C) 2012 Regents of the University of California
+ * Copyright (C) 2017-2018 SiFive
+ */
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define PTR_BITS (8 * sizeof(uintptr_t))
+
+struct riscv_irq_data {
+ struct irq_chip chip;
+ struct irq_domain *domain;
+ int hart;
+ charname[20];
+};
+DEFINE_PER_CPU(struct riscv_irq_data, riscv_irq_data);
+
+static void riscv_software_interrupt(void)
+{
+#ifdef CONFIG_SMP
+ irqreturn_t ret;
+
+ ret = handle_ipi();
+
+ WARN_ON(ret == IRQ_NONE);
+#else
+ /*
+* We currently only use software interrupts to pass inter-processor
+* interrupts, so if a non-SMP system gets a software interrupt then we
+* don't know what to do.
+*/
+ pr_warning("Software Interrupt without CONFIG_SMP\n");
+#endif
+}
+
+static void riscv_intc_irq(struct pt_regs *regs)
+{
+ struct pt_regs *old_regs = set_irq_regs(regs);
+ struct irq_domain *domain;
+ unsigned long cause = csr_read(scause);
+
+ /*
+* The high order bit of the trap cause register is always set for
+* interrupts, which allows us to differentiate them from exceptions
+* quickly. The INTERRUPT_CAUSE_* macros don't contain that bit, so we
+* need to mask it off here.
+*/
+ WARN_ON((cause & (1UL << (PTR_BITS - 1))) == 0);
+ cause = cause & ~(1UL << (PTR_BITS - 1));
+
+ irq_enter();
+
+ /*
+* There are three classes of interrupt: timer, software, and
+* external devices. We dispatch between them here. External
+* device interrupts use the generic IRQ mechanisms.
+*/
+ switch (cause) {
+ case INTERRUPT_CAUSE_TIMER:
+ riscv_timer_interrupt();
+ break;
+ case INTERRUPT_CAUSE_SOFTWARE:
+ riscv_software_interrupt();
+ break;
+ default:
+ domain = per_cpu(riscv_irq_data, smp_processor_id()).domain;
+ generic_handle_irq(irq_find_mapping(domain, cause));
+ break;
+ }
+
+ irq_exit();
+ set_irq_regs(old_regs);
+}
+
+static int riscv_irqdomain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ struct riscv_irq_data *data = d->host_data;
+
+ irq_set_chip_and_handler(irq, >chip, handle_simple_irq);
+ irq_set_chip_data(irq, data);
+ irq_set_noprobe(irq);
+ irq_set_affinity(irq, cpumask_of(data->hart));
+
+ return 0;
+}
+
+static const struct irq_domain_ops
Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode
On Fri, Jun 22, 2018 at 01:59:44PM +0200, Thomas Gleixner wrote:
> On Fri, 22 Jun 2018, Thomas Gleixner wrote:
> > The whole thing is simply:
> >
> > handle_ac()
> > {
> > if (user_mode(regs)) {
> > do_trap(AC, SIGBUS, ...);
> > } else {
> > disable_ac_on_local_cpu();
> > WARN_ONCE(1);
> > }
> > }
> >
> > That wants #AC enabled as early as possible so the kernel gets as much
> > coverage as it can. If it trips in the kernel it's a bug and needs to be
> > fixed and we can them fix ONE by ONE.
>
> That said, #AC is just yet another badly defined and hastily bolted on
> (mis)feature. This should have been:
>
> Bit A: Enable #AC if CPL < 3
> Bit B: Enable #AC if CPL == 3
>
> But that would have been too useful and would allow sensible use of #AC
> without creating software trainwrecks.
>
The two bits would be ideal.
So I will do SIGBUG for user and WARN/disable for kernel in the next version.
Thanks.
-Fenghua
Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode
On Fri, Jun 22, 2018 at 01:59:44PM +0200, Thomas Gleixner wrote:
> On Fri, 22 Jun 2018, Thomas Gleixner wrote:
> > The whole thing is simply:
> >
> > handle_ac()
> > {
> > if (user_mode(regs)) {
> > do_trap(AC, SIGBUS, ...);
> > } else {
> > disable_ac_on_local_cpu();
> > WARN_ONCE(1);
> > }
> > }
> >
> > That wants #AC enabled as early as possible so the kernel gets as much
> > coverage as it can. If it trips in the kernel it's a bug and needs to be
> > fixed and we can them fix ONE by ONE.
>
> That said, #AC is just yet another badly defined and hastily bolted on
> (mis)feature. This should have been:
>
> Bit A: Enable #AC if CPL < 3
> Bit B: Enable #AC if CPL == 3
>
> But that would have been too useful and would allow sensible use of #AC
> without creating software trainwrecks.
>
The two bits would be ideal.
So I will do SIGBUG for user and WARN/disable for kernel in the next version.
Thanks.
-Fenghua
Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface
Hi, On 04/26/2018 07:23 PM, Sujeev Dias wrote: > diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig > index d1c0b60..e15d56d 100644 > --- a/drivers/bus/Kconfig > +++ b/drivers/bus/Kconfig > @@ -171,6 +171,23 @@ config DA8XX_MSTPRI > configuration. Allows to adjust the priorities of all master > peripherals. > > +config MHI_BUS > + tristate "Modem Host Interface" > + help > + MHI Host Interface is a communication protocol to be used by the host MHI (Modem Host Interface) is > + to control and communcate with modem over a high speed peripheral bus. communicate > + Enabling this module will allow host to communicate with external > + devices that support MHI protocol. > + > +config MHI_DEBUG > + bool "MHI debug support" > + depends on MHI_BUS > + help > +Say yes here to enable debugging support in the MHI transport > +and individual MHI client drivers. This option will impact > +throughput as individual MHI packets and state transitions > +will be logged. > + > source "drivers/bus/fsl-mc/Kconfig" > > endmenu -- ~Randy
Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface
Hi, On 04/26/2018 07:23 PM, Sujeev Dias wrote: > diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig > index d1c0b60..e15d56d 100644 > --- a/drivers/bus/Kconfig > +++ b/drivers/bus/Kconfig > @@ -171,6 +171,23 @@ config DA8XX_MSTPRI > configuration. Allows to adjust the priorities of all master > peripherals. > > +config MHI_BUS > + tristate "Modem Host Interface" > + help > + MHI Host Interface is a communication protocol to be used by the host MHI (Modem Host Interface) is > + to control and communcate with modem over a high speed peripheral bus. communicate > + Enabling this module will allow host to communicate with external > + devices that support MHI protocol. > + > +config MHI_DEBUG > + bool "MHI debug support" > + depends on MHI_BUS > + help > +Say yes here to enable debugging support in the MHI transport > +and individual MHI client drivers. This option will impact > +throughput as individual MHI packets and state transitions > +will be logged. > + > source "drivers/bus/fsl-mc/Kconfig" > > endmenu -- ~Randy
Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode
On Sat, 23 Jun 2018, Thomas Gleixner wrote: > On Fri, 22 Jun 2018, Fenghua Yu wrote: > > On Fri, Jun 22, 2018 at 01:59:44PM +0200, Thomas Gleixner wrote: > > > Aside of that the spec says: > > > > > > 31 Disable LOCK# assertion for split locked access. > > > > > > Can you pretty please make sure that this bit enforces #AC enable? If 31 > > > is > > > ever set and such an access happens then the resulting havoc will takes > > > ages to decode. > > > > > > That bit is also mentioned in the SDM with ZERO explanation why it exists > > > in the first place and why anyone would ever enable it and without a big > > > fat warning about the possible consequences. Can this pretty please be > > > fixed? > > > > The bit 31 already exits on all processors. Hardware always sets its value > > as zero after power on. It has been legacy for 20 years. It was added for > > one customer 20 years ago. Now Intel hardware design team doesn't expect > > anyone to set the bit. > > Doesn't expect. ROTFL. > > That's the most stupiest excuse for not adding a big fat warning into the > SDM why this abomination should never be used at all. > > Aside of that does the Intel hardware design team expect that this one > customer is still depending on this nonsense and is therefore proliferating > it forever? Forgot to add that there are a lot of things nobody expects to be done, but especially BIOS/SMM people have a tendency to flip random bits as they see fit. Maybe not this one, but only for the reason that they did not notice it yet. Thanks, tglx
Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode
On Sat, 23 Jun 2018, Thomas Gleixner wrote: > On Fri, 22 Jun 2018, Fenghua Yu wrote: > > On Fri, Jun 22, 2018 at 01:59:44PM +0200, Thomas Gleixner wrote: > > > Aside of that the spec says: > > > > > > 31 Disable LOCK# assertion for split locked access. > > > > > > Can you pretty please make sure that this bit enforces #AC enable? If 31 > > > is > > > ever set and such an access happens then the resulting havoc will takes > > > ages to decode. > > > > > > That bit is also mentioned in the SDM with ZERO explanation why it exists > > > in the first place and why anyone would ever enable it and without a big > > > fat warning about the possible consequences. Can this pretty please be > > > fixed? > > > > The bit 31 already exits on all processors. Hardware always sets its value > > as zero after power on. It has been legacy for 20 years. It was added for > > one customer 20 years ago. Now Intel hardware design team doesn't expect > > anyone to set the bit. > > Doesn't expect. ROTFL. > > That's the most stupiest excuse for not adding a big fat warning into the > SDM why this abomination should never be used at all. > > Aside of that does the Intel hardware design team expect that this one > customer is still depending on this nonsense and is therefore proliferating > it forever? Forgot to add that there are a lot of things nobody expects to be done, but especially BIOS/SMM people have a tendency to flip random bits as they see fit. Maybe not this one, but only for the reason that they did not notice it yet. Thanks, tglx
Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode
On Fri, 22 Jun 2018, Fenghua Yu wrote: > On Fri, Jun 22, 2018 at 01:59:44PM +0200, Thomas Gleixner wrote: > > Aside of that the spec says: > > > > 31 Disable LOCK# assertion for split locked access. > > > > Can you pretty please make sure that this bit enforces #AC enable? If 31 is > > ever set and such an access happens then the resulting havoc will takes > > ages to decode. > > > > That bit is also mentioned in the SDM with ZERO explanation why it exists > > in the first place and why anyone would ever enable it and without a big > > fat warning about the possible consequences. Can this pretty please be > > fixed? > > The bit 31 already exits on all processors. Hardware always sets its value > as zero after power on. It has been legacy for 20 years. It was added for > one customer 20 years ago. Now Intel hardware design team doesn't expect > anyone to set the bit. Doesn't expect. ROTFL. That's the most stupiest excuse for not adding a big fat warning into the SDM why this abomination should never be used at all. Aside of that does the Intel hardware design team expect that this one customer is still depending on this nonsense and is therefore proliferating it forever? > Currently Linux kernel doesn't define this bit and doesn't set this bit. Thanks for the education. I knew that already, but it still does not make the existence of it in contemporary CPUs any better or more justified. Thanks, tglx
Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode
On Fri, 22 Jun 2018, Fenghua Yu wrote: > On Fri, Jun 22, 2018 at 01:59:44PM +0200, Thomas Gleixner wrote: > > Aside of that the spec says: > > > > 31 Disable LOCK# assertion for split locked access. > > > > Can you pretty please make sure that this bit enforces #AC enable? If 31 is > > ever set and such an access happens then the resulting havoc will takes > > ages to decode. > > > > That bit is also mentioned in the SDM with ZERO explanation why it exists > > in the first place and why anyone would ever enable it and without a big > > fat warning about the possible consequences. Can this pretty please be > > fixed? > > The bit 31 already exits on all processors. Hardware always sets its value > as zero after power on. It has been legacy for 20 years. It was added for > one customer 20 years ago. Now Intel hardware design team doesn't expect > anyone to set the bit. Doesn't expect. ROTFL. That's the most stupiest excuse for not adding a big fat warning into the SDM why this abomination should never be used at all. Aside of that does the Intel hardware design team expect that this one customer is still depending on this nonsense and is therefore proliferating it forever? > Currently Linux kernel doesn't define this bit and doesn't set this bit. Thanks for the education. I knew that already, but it still does not make the existence of it in contemporary CPUs any better or more justified. Thanks, tglx
[PATCH V7 02/41] x86/intel_rdt: Document new mode, size, and bit_usage
By default resource groups allow sharing of their cache allocations. There is nothing that prevents a resource group from configuring a cache allocation that overlaps with that of an existing resource group. To enable resource groups to specify that their cache allocations cannot be shared a resource group "mode" is introduced to support two possible modes: "shareable" and "exclusive". A "shareable" resource group allows sharing of its cache allocations, an "exclusive" resource group does not. A new resctrl file "mode" associated with each resource group is used to communicate its (the associated resource group's) mode setting and allow the mode to be changed. The new "mode" file as well as two other resctrl files, "bit_usage" and "size", are introduced in this series. Add documentation for the three new resctrl files as well as one example demonstrating their use. Signed-off-by: Reinette Chatre Signed-off-by: Thomas Gleixner Cc: fenghua...@intel.com Cc: tony.l...@intel.com Cc: vikas.shiva...@linux.intel.com Cc: gavin.hind...@intel.com Cc: jithu.jos...@intel.com Cc: dave.han...@intel.com Cc: h...@zytor.com Link: https://lkml.kernel.org/r/cc1e6234f80e07eef65529bd6c25db0a688bba12.1527593970.git.reinette.cha...@intel.com --- Documentation/x86/intel_rdt_ui.txt | 99 +- 1 file changed, 97 insertions(+), 2 deletions(-) diff --git a/Documentation/x86/intel_rdt_ui.txt b/Documentation/x86/intel_rdt_ui.txt index a16aa2113840..de913e00e922 100644 --- a/Documentation/x86/intel_rdt_ui.txt +++ b/Documentation/x86/intel_rdt_ui.txt @@ -65,6 +65,27 @@ related to allocation: some platforms support devices that have their own settings for cache use which can over-ride these bits. +"bit_usage": Annotated capacity bitmasks showing how all + instances of the resource are used. The legend is: + "0" - Corresponding region is unused. When the system's + resources have been allocated and a "0" is found + in "bit_usage" it is a sign that resources are + wasted. + "H" - Corresponding region is used by hardware only + but available for software use. If a resource + has bits set in "shareable_bits" but not all + of these bits appear in the resource groups' + schematas then the bits appearing in + "shareable_bits" but no resource group will + be marked as "H". + "X" - Corresponding region is available for sharing and + used by hardware and software. These are the + bits that appear in "shareable_bits" as + well as a resource group's allocation. + "S" - Corresponding region is used by software + and available for sharing. + "E" - Corresponding region is used exclusively by + one resource group. No sharing allowed. Memory bandwitdh(MB) subdirectory contains the following files with respect to allocation: @@ -163,6 +184,16 @@ When control is enabled all CTRL_MON groups will also contain: A list of all the resources available to this group. Each resource has its own line and format - see below for details. +"size": + Mirrors the display of the "schemata" file to display the size in + bytes of each allocation instead of the bits representing the + allocation. + +"mode": + The "mode" of the resource group dictates the sharing of its + allocations. A "shareable" resource group allows sharing of its + allocations while an "exclusive" resource group does not. + When monitoring is enabled all MON groups will also contain: "mon_data": @@ -502,7 +533,71 @@ siblings and only the real time threads are scheduled on the cores 4-7. # echo F0 > p0/cpus -4) Locking between applications +Example 4 +- + +The resource groups in previous examples were all in the default "shareable" +mode allowing sharing of their cache allocations. If one resource group +configures a cache allocation then nothing prevents another resource group +to overlap with that allocation. + +In this example a new exclusive resource group will be created on a L2 CAT +system with two L2 cache instances that can be configured with an 8-bit +capacity bitmask. The new exclusive resource group will be configured to use +25% of each cache instance. + +# mount -t resctrl resctrl /sys/fs/resctrl/ +# cd /sys/fs/resctrl + +First, we observe that the default group is configured to allocate to all L2 +cache: + +# cat schemata +L2:0=ff;1=ff + +We could attempt to create the new resource
[PATCH V7 19/41] x86/intel_rdt: Add utility to test if tasks assigned to resource group
In considering changes to a resource group it becomes necessary to know
whether tasks have been assigned to the resource group in question.
Introduce a new utility that can be used to check if any tasks have been
assigned to a particular resource group.
Signed-off-by: Reinette Chatre
Signed-off-by: Thomas Gleixner
Cc: fenghua...@intel.com
Cc: tony.l...@intel.com
Cc: vikas.shiva...@linux.intel.com
Cc: gavin.hind...@intel.com
Cc: jithu.jos...@intel.com
Cc: dave.han...@intel.com
Cc: h...@zytor.com
Link:
https://lkml.kernel.org/r/9149005d01de4b197bae13a45e6efdb536383ca1.1527593970.git.reinette.cha...@intel.com
---
arch/x86/kernel/cpu/intel_rdt.h | 1 +
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 26
2 files changed, 27 insertions(+)
diff --git a/arch/x86/kernel/cpu/intel_rdt.h b/arch/x86/kernel/cpu/intel_rdt.h
index bda87f5ef7bc..10a1539cbec6 100644
--- a/arch/x86/kernel/cpu/intel_rdt.h
+++ b/arch/x86/kernel/cpu/intel_rdt.h
@@ -480,6 +480,7 @@ bool rdtgroup_cbm_overlaps(struct rdt_resource *r, struct
rdt_domain *d,
unsigned int rdtgroup_cbm_to_size(struct rdt_resource *r, struct rdt_domain *d,
u32 cbm);
enum rdtgrp_mode rdtgroup_mode_by_closid(int closid);
+int rdtgroup_tasks_assigned(struct rdtgroup *r);
struct rdt_domain *get_domain_from_cpu(int cpu, struct rdt_resource *r);
int update_domains(struct rdt_resource *r, int closid);
void closid_free(int closid);
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 352475a6cf43..5a2a34d68722 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -564,6 +564,32 @@ static int __rdtgroup_move_task(struct task_struct *tsk,
return ret;
}
+/**
+ * rdtgroup_tasks_assigned - Test if tasks have been assigned to resource group
+ * @r: Resource group
+ *
+ * Return: 1 if tasks have been assigned to @r, 0 otherwise
+ */
+int rdtgroup_tasks_assigned(struct rdtgroup *r)
+{
+ struct task_struct *p, *t;
+ int ret = 0;
+
+ lockdep_assert_held(_mutex);
+
+ rcu_read_lock();
+ for_each_process_thread(p, t) {
+ if ((r->type == RDTCTRL_GROUP && t->closid == r->closid) ||
+ (r->type == RDTMON_GROUP && t->rmid == r->mon.rmid)) {
+ ret = 1;
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return ret;
+}
+
static int rdtgroup_task_write_permission(struct task_struct *task,
struct kernfs_open_file *of)
{
--
2.17.0
[PATCH V7 02/41] x86/intel_rdt: Document new mode, size, and bit_usage
By default resource groups allow sharing of their cache allocations. There is nothing that prevents a resource group from configuring a cache allocation that overlaps with that of an existing resource group. To enable resource groups to specify that their cache allocations cannot be shared a resource group "mode" is introduced to support two possible modes: "shareable" and "exclusive". A "shareable" resource group allows sharing of its cache allocations, an "exclusive" resource group does not. A new resctrl file "mode" associated with each resource group is used to communicate its (the associated resource group's) mode setting and allow the mode to be changed. The new "mode" file as well as two other resctrl files, "bit_usage" and "size", are introduced in this series. Add documentation for the three new resctrl files as well as one example demonstrating their use. Signed-off-by: Reinette Chatre Signed-off-by: Thomas Gleixner Cc: fenghua...@intel.com Cc: tony.l...@intel.com Cc: vikas.shiva...@linux.intel.com Cc: gavin.hind...@intel.com Cc: jithu.jos...@intel.com Cc: dave.han...@intel.com Cc: h...@zytor.com Link: https://lkml.kernel.org/r/cc1e6234f80e07eef65529bd6c25db0a688bba12.1527593970.git.reinette.cha...@intel.com --- Documentation/x86/intel_rdt_ui.txt | 99 +- 1 file changed, 97 insertions(+), 2 deletions(-) diff --git a/Documentation/x86/intel_rdt_ui.txt b/Documentation/x86/intel_rdt_ui.txt index a16aa2113840..de913e00e922 100644 --- a/Documentation/x86/intel_rdt_ui.txt +++ b/Documentation/x86/intel_rdt_ui.txt @@ -65,6 +65,27 @@ related to allocation: some platforms support devices that have their own settings for cache use which can over-ride these bits. +"bit_usage": Annotated capacity bitmasks showing how all + instances of the resource are used. The legend is: + "0" - Corresponding region is unused. When the system's + resources have been allocated and a "0" is found + in "bit_usage" it is a sign that resources are + wasted. + "H" - Corresponding region is used by hardware only + but available for software use. If a resource + has bits set in "shareable_bits" but not all + of these bits appear in the resource groups' + schematas then the bits appearing in + "shareable_bits" but no resource group will + be marked as "H". + "X" - Corresponding region is available for sharing and + used by hardware and software. These are the + bits that appear in "shareable_bits" as + well as a resource group's allocation. + "S" - Corresponding region is used by software + and available for sharing. + "E" - Corresponding region is used exclusively by + one resource group. No sharing allowed. Memory bandwitdh(MB) subdirectory contains the following files with respect to allocation: @@ -163,6 +184,16 @@ When control is enabled all CTRL_MON groups will also contain: A list of all the resources available to this group. Each resource has its own line and format - see below for details. +"size": + Mirrors the display of the "schemata" file to display the size in + bytes of each allocation instead of the bits representing the + allocation. + +"mode": + The "mode" of the resource group dictates the sharing of its + allocations. A "shareable" resource group allows sharing of its + allocations while an "exclusive" resource group does not. + When monitoring is enabled all MON groups will also contain: "mon_data": @@ -502,7 +533,71 @@ siblings and only the real time threads are scheduled on the cores 4-7. # echo F0 > p0/cpus -4) Locking between applications +Example 4 +- + +The resource groups in previous examples were all in the default "shareable" +mode allowing sharing of their cache allocations. If one resource group +configures a cache allocation then nothing prevents another resource group +to overlap with that allocation. + +In this example a new exclusive resource group will be created on a L2 CAT +system with two L2 cache instances that can be configured with an 8-bit +capacity bitmask. The new exclusive resource group will be configured to use +25% of each cache instance. + +# mount -t resctrl resctrl /sys/fs/resctrl/ +# cd /sys/fs/resctrl + +First, we observe that the default group is configured to allocate to all L2 +cache: + +# cat schemata +L2:0=ff;1=ff + +We could attempt to create the new resource
[PATCH V7 19/41] x86/intel_rdt: Add utility to test if tasks assigned to resource group
In considering changes to a resource group it becomes necessary to know
whether tasks have been assigned to the resource group in question.
Introduce a new utility that can be used to check if any tasks have been
assigned to a particular resource group.
Signed-off-by: Reinette Chatre
Signed-off-by: Thomas Gleixner
Cc: fenghua...@intel.com
Cc: tony.l...@intel.com
Cc: vikas.shiva...@linux.intel.com
Cc: gavin.hind...@intel.com
Cc: jithu.jos...@intel.com
Cc: dave.han...@intel.com
Cc: h...@zytor.com
Link:
https://lkml.kernel.org/r/9149005d01de4b197bae13a45e6efdb536383ca1.1527593970.git.reinette.cha...@intel.com
---
arch/x86/kernel/cpu/intel_rdt.h | 1 +
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 26
2 files changed, 27 insertions(+)
diff --git a/arch/x86/kernel/cpu/intel_rdt.h b/arch/x86/kernel/cpu/intel_rdt.h
index bda87f5ef7bc..10a1539cbec6 100644
--- a/arch/x86/kernel/cpu/intel_rdt.h
+++ b/arch/x86/kernel/cpu/intel_rdt.h
@@ -480,6 +480,7 @@ bool rdtgroup_cbm_overlaps(struct rdt_resource *r, struct
rdt_domain *d,
unsigned int rdtgroup_cbm_to_size(struct rdt_resource *r, struct rdt_domain *d,
u32 cbm);
enum rdtgrp_mode rdtgroup_mode_by_closid(int closid);
+int rdtgroup_tasks_assigned(struct rdtgroup *r);
struct rdt_domain *get_domain_from_cpu(int cpu, struct rdt_resource *r);
int update_domains(struct rdt_resource *r, int closid);
void closid_free(int closid);
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 352475a6cf43..5a2a34d68722 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -564,6 +564,32 @@ static int __rdtgroup_move_task(struct task_struct *tsk,
return ret;
}
+/**
+ * rdtgroup_tasks_assigned - Test if tasks have been assigned to resource group
+ * @r: Resource group
+ *
+ * Return: 1 if tasks have been assigned to @r, 0 otherwise
+ */
+int rdtgroup_tasks_assigned(struct rdtgroup *r)
+{
+ struct task_struct *p, *t;
+ int ret = 0;
+
+ lockdep_assert_held(_mutex);
+
+ rcu_read_lock();
+ for_each_process_thread(p, t) {
+ if ((r->type == RDTCTRL_GROUP && t->closid == r->closid) ||
+ (r->type == RDTMON_GROUP && t->rmid == r->mon.rmid)) {
+ ret = 1;
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return ret;
+}
+
static int rdtgroup_task_write_permission(struct task_struct *task,
struct kernfs_open_file *of)
{
--
2.17.0
