Re: [PATCH] printk: introduce should_ignore_loglevel()
On (06/24/16 18:05), Petr Mladek wrote:
[..]
> > +static bool should_ignore_loglevel(int level)
> > +{
> > + return (level >= console_loglevel && !ignore_loglevel);
>
> The patch looks fine. It is nice optimization.
>
> I was just quite confused by the name of this function. A function
> called should_ignore_loglevel() should not return false when
> ignore_loglevel variable is true.
>
> I would call it ignore_message() or ignore_message_on_console() or so.
Hello Petr, you are right.
I was thinking about
s/should_ignore_loglevel/suppress_message/g
or s/should_ignore_loglevel/suppress_message_by_level/g
s/should_ignore_loglevel/suppress_message_printing/g
suppress_message_printing() is probably fine.
will it work for you guys?
-ss
[PATCH] scsi: ufs: remove unnecessary goto label
When buff_ascii kmalloc failed, there is no need to call kfree,
it should return -ENOMEM directly, this patch fixes it.
Signed-off-by: Tiezhu Yang
---
drivers/scsi/ufs/ufshcd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 8e8989a..f08d41a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2137,7 +2137,7 @@ int ufshcd_read_string_desc(struct ufs_hba *hba, int
desc_index, u8 *buf,
buff_ascii = kmalloc(ascii_len, GFP_KERNEL);
if (!buff_ascii) {
err = -ENOMEM;
- goto out_free_buff;
+ goto out;
}
/*
@@ -2156,7 +2156,6 @@ int ufshcd_read_string_desc(struct ufs_hba *hba, int
desc_index, u8 *buf,
size - QUERY_DESC_HDR_SIZE);
memcpy(buf + QUERY_DESC_HDR_SIZE, buff_ascii, ascii_len);
buf[QUERY_DESC_LENGTH_OFFSET] = ascii_len + QUERY_DESC_HDR_SIZE;
-out_free_buff:
kfree(buff_ascii);
}
out:
--
1.8.3.1
Re: [PATCH] orangefs: fix namespace handling
Jann Horn writes:
> diff --git a/fs/orangefs/devorangefs-req.c b/fs/orangefs/devorangefs-req.c
> index db170be..a287a66 100644
> --- a/fs/orangefs/devorangefs-req.c
> +++ b/fs/orangefs/devorangefs-req.c
> @@ -116,6 +116,13 @@ static int orangefs_devreq_open(struct inode *inode,
> struct file *file)
> {
> int ret = -EINVAL;
>
> + /* in order to ensure that the filesystem driver sees correct UIDs */
> + if (file->f_cred->user_ns != &init_user_ns) {
> + gossip_err("%s: device cannot be opened outside init_user_ns\n",
> +__func__);
> + goto out;
> + }
> +
Not necessarily in this patch but the code should also verify that the
opener is also in the initial pid namespace as pids are transferred in
the upcalls as well.
> if (!(file->f_flags & O_NONBLOCK)) {
> gossip_err("%s: device cannot be opened in blocking mode\n",
> __func__);
Eric
[PATCH v2 02/14] thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3
From: Ondrej Jirman
This patch adds support for the sun8i thermal sensor on
Allwinner H3 SoC.
Signed-off-by: Ondřej Jirman
---
v2:
- removed incorrect use of SID driver in sun8i_ths
- read calibration data directly from iomem
- better explanation for the thermal sensor driver
- dt documentation fixes
- dropped unncecessary macros and init code reorganization
- moved resource aquisition from init to probe function
- deassert reset after clock rate is set, not before
- enable irq after all other registers are configured
---
drivers/thermal/Kconfig | 7 ++
drivers/thermal/Makefile| 1 +
drivers/thermal/sun8i_ths.c | 260
3 files changed, 268 insertions(+)
create mode 100644 drivers/thermal/sun8i_ths.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..d3209d9 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -351,6 +351,13 @@ config MTK_THERMAL
Enable this option if you want to have support for thermal management
controller present in Mediatek SoCs
+config SUN8I_THS
+ tristate "Thermal sensor driver for Allwinner H3"
+ depends on MACH_SUN8I
+ depends on OF
+ help
+ Enable this to support thermal reporting on some newer Allwinner SoCs.
+
menu "Texas Instruments thermal drivers"
depends on ARCH_HAS_BANDGAP || COMPILE_TEST
depends on HAS_IOMEM
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..7261ee8 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM) += tegra/
obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
+obj-$(CONFIG_SUN8I_THS)+= sun8i_ths.o
diff --git a/drivers/thermal/sun8i_ths.c b/drivers/thermal/sun8i_ths.c
new file mode 100644
index 000..9ba0f96
--- /dev/null
+++ b/drivers/thermal/sun8i_ths.c
@@ -0,0 +1,260 @@
+/*
+ * Thermal sensor driver for Allwinner H3 SoC
+ *
+ * Copyright (C) 2016 Ondřej Jirman
+ * Based on the work of Josef Gajdusek
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define THS_H3_CTRL0 0x00
+#define THS_H3_CTRL2 0x40
+#define THS_H3_INT_CTRL0x44
+#define THS_H3_STAT0x48
+#define THS_H3_FILTER 0x70
+#define THS_H3_CDATA 0x74
+#define THS_H3_DATA0x80
+
+#define THS_H3_CTRL0_SENSOR_ACQ0(x) (x)
+#define THS_H3_CTRL2_SENSE_EN BIT(0)
+#define THS_H3_CTRL2_SENSOR_ACQ1(x) ((x) << 16)
+#define THS_H3_INT_CTRL_DATA_IRQ_EN BIT(8)
+#define THS_H3_INT_CTRL_THERMAL_PER(x) ((x) << 12)
+#define THS_H3_STAT_DATA_IRQ_STSBIT(8)
+#define THS_H3_FILTER_TYPE(x) ((x) << 0)
+#define THS_H3_FILTER_ENBIT(2)
+
+#define THS_H3_CLK_IN 4000 /* Hz */
+#define THS_H3_DATA_PERIOD 330 /* ms */
+
+#define THS_H3_FILTER_TYPE_VALUE 2 /* average over 2^(n+1)
samples */
+#define THS_H3_FILTER_DIV (1 << (THS_H3_FILTER_TYPE_VALUE
+ 1))
+#define THS_H3_INT_CTRL_THERMAL_PER_VALUE \
+ (THS_H3_DATA_PERIOD * (THS_H3_CLK_IN / 1000) / THS_H3_FILTER_DIV / 4096
- 1)
+#define THS_H3_CTRL0_SENSOR_ACQ0_VALUE 0x3f /* 16us */
+#define THS_H3_CTRL2_SENSOR_ACQ1_VALUE 0x3f
+
+struct sun8i_ths_data {
+ struct reset_control *reset;
+ struct clk *clk;
+ struct clk *busclk;
+ void __iomem *regs;
+ void __iomem *calreg;
+ struct thermal_zone_device *tzd;
+ u32 temp;
+};
+
+static int sun8i_ths_get_temp(void *_data, int *out)
+{
+ struct sun8i_ths_data *data = _data;
+
+ if (data->temp == 0)
+ return -EINVAL;
+
+ /* Formula and parameters from the Allwinner 3.4 kernel */
+ *out = 217000 - (int)((data->temp * 100) / 8253);
+ return 0;
+}
+
+static irqreturn_t sun8i_ths_irq_thread(int irq, void *_data)
+{
+ struct sun8i_ths_data *data = _data;
+
+ writel(THS_H3_STAT_DATA_IRQ_STS, data->regs + THS_H3_STAT);
+
+ data->temp = readl(data->regs + THS_H3_DATA);
+ if (data->temp)
+ thermal_zone_device_update(data->tzd);
+
+ return IRQ_HANDLED;
+}
+
+static void sun8i_ths_h3_init(struct sun8i_ths_data *data)
+{
+ u32 caldata;
+
+ caldata = readl(data->calreg) & 0xfff;
+ if
[PATCH v2 01/14] ARM: clk: sunxi: Add driver for the H3 THS clock
From: Josef Gajdusek
This patch adds a driver for the THS clock which is present on the
Allwinner H3.
Signed-off-by: Josef Gajdusek
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/Makefile| 1 +
drivers/clk/sunxi/clk-h3-ths.c| 98 +++
3 files changed, 100 insertions(+)
create mode 100644 drivers/clk/sunxi/clk-h3-ths.c
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 8f7619d..5faae05 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -87,6 +87,7 @@ Required properties:
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
"allwinner,sun6i-a31-display-clk" - for the display clocks
+ "allwinner,sun8i-h3-ths-clk" - for THS on H3
Required properties for all clocks:
- reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 39d2044..8e245e3 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -9,6 +9,7 @@ obj-y += clk-a10-mod1.o
obj-y += clk-a10-pll2.o
obj-y += clk-a10-ve.o
obj-y += clk-a20-gmac.o
+obj-y += clk-h3-ths.o
obj-y += clk-mod0.o
obj-y += clk-simple-gates.o
obj-y += clk-sun4i-display.o
diff --git a/drivers/clk/sunxi/clk-h3-ths.c b/drivers/clk/sunxi/clk-h3-ths.c
new file mode 100644
index 000..c1d6d32
--- /dev/null
+++ b/drivers/clk/sunxi/clk-h3-ths.c
@@ -0,0 +1,98 @@
+/*
+ * sun8i THS clock driver
+ *
+ * Copyright (C) 2015 Josef Gajdusek
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#define SUN8I_H3_THS_CLK_ENABLE31
+#define SUN8I_H3_THS_CLK_DIVIDER_SHIFT 0
+#define SUN8I_H3_THS_CLK_DIVIDER_WIDTH 2
+
+static DEFINE_SPINLOCK(sun8i_h3_ths_clk_lock);
+
+static const struct clk_div_table sun8i_h3_ths_clk_table[] __initconst = {
+ { .val = 0, .div = 1 },
+ { .val = 1, .div = 2 },
+ { .val = 2, .div = 4 },
+ { .val = 3, .div = 6 },
+ { } /* sentinel */
+};
+
+static void __init sun8i_h3_ths_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_gate *gate;
+ struct clk_divider *div;
+ const char *parent;
+ const char *clk_name = node->name;
+ void __iomem *reg;
+ int err;
+
+ reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+
+ if (IS_ERR(reg))
+ return;
+
+ gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+ if (!gate)
+ goto err_unmap;
+
+ div = kzalloc(sizeof(*gate), GFP_KERNEL);
+ if (!div)
+ goto err_gate_free;
+
+ of_property_read_string(node, "clock-output-names", &clk_name);
+ parent = of_clk_get_parent_name(node, 0);
+
+ gate->reg = reg;
+ gate->bit_idx = SUN8I_H3_THS_CLK_ENABLE;
+ gate->lock = &sun8i_h3_ths_clk_lock;
+
+ div->reg = reg;
+ div->shift = SUN8I_H3_THS_CLK_DIVIDER_SHIFT;
+ div->width = SUN8I_H3_THS_CLK_DIVIDER_WIDTH;
+ div->table = sun8i_h3_ths_clk_table;
+ div->lock = &sun8i_h3_ths_clk_lock;
+
+ clk = clk_register_composite(NULL, clk_name, &parent, 1,
+NULL, NULL,
+&div->hw,
&clk_divider_ops,
+&gate->hw,
&clk_gate_ops,
+
CLK_SET_RATE_PARENT);
+
+ if (IS_ERR(clk))
+ goto err_div_free;
+
+ err = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ if (err)
+ goto err_unregister_clk;
+
+ return;
+
+err_unregister_clk:
+ clk_unregister(clk);
+err_gate_free:
+ kfree(gate);
+err_div_free:
+ kfree(div);
+err_unmap:
+ iounmap(reg);
+}
+
+CLK_OF_DECLARE(sun8i_h3_ths_clk, "allwinner,sun8i-h3-ths-clk",
+ sun8i_h3_ths_clk_setup);
--
2.9.0
[PATCH v2 05/14] dt-bindings: document SY8106A regulator driver
From: Ondrej Jirman
This patch adds the binding documentation for the
sy8106a regulator driver.
Signed-off-by: Ondrej Jirman
---
.../bindings/regulator/sy8106a-regulator.txt| 21 +
1 file changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
new file mode 100644
index 000..1e623a34
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
@@ -0,0 +1,21 @@
+SY8106A Voltage regulator
+
+Required properties:
+- compatible: Must be "silergy,sy8106a"
+- reg: I2C slave address - must be <0x65>
+
+Any property defined as part of the core regulator binding, defined in
+regulator.txt, can also be used.
+
+Example:
+
+ sy8106a {
+ compatible = "silergy,sy8106a";
+ reg = <0x65>;
+ regulator-name = "sy8106a-vdd";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ regulator-ramp-delay = <200>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
--
2.9.0
[PATCH v2 07/14] ARM: dts: sun8i: Use sun8i-h3-pll1-clk for pll1 in H3
From: Ondrej Jirman
PLL1 on H3 requires special factors application algorithm,
when the rate is changed. This algorithm was extracted
from the arisc code that handles frequency scaling
in the BSP kernel.
This algorithm is implemented by sun8i-h3-pll1-clk.
Signed-off-by: Ondrej Jirman
---
arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 4a4926b..b3247f4 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -106,7 +106,7 @@
pll1: clk@01c2 {
#clock-cells = <0>;
- compatible = "allwinner,sun8i-a23-pll1-clk";
+ compatible = "allwinner,sun8i-h3-pll1-clk";
reg = <0x01c2 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll1";
--
2.9.0
[PATCH v2 09/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi
From: Ondrej Jirman
Add label to the first cpu so that it can be referenced
from derived dts files.
Signed-off-by: Ondrej Jirman
---
v2
- move clocks/clock-latency to sun8i-h3.dtsi
---
arch/arm/boot/dts/sun8i-h3.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index d3c29cc..56f211e 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -52,7 +52,9 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu@0 {
+ cpu0: cpu@0 {
+ clocks = <&cpu>;
+ clock-latency = <244144>; /* 8 32k periods */
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
--
2.9.0
[PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One
From: Ondrej Jirman
Use Xulong Orange Pi One GPIO based regulator for
passive cooling and thermal management.
Signed-off-by: Ondrej Jirman
---
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 +
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index b1bd6b0..a38d871 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -109,6 +109,45 @@
};
};
+&cpu0 {
+ operating-points = <
+ /* kHzuV */
+ 1296000 130
+ 120 130
+ 624000 110
+ 48 110
+ 312000 110
+ 24 110
+ >;
+ #cooling-cells = <2>;
+ cooling-min-level = <0>;
+ cooling-max-level = <5>;
+ cpu0-supply = <&vdd_soc>;
+};
+
+&cpu_thermal {
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device = <&cpu0 (-1) (-1)>;
+ };
+ };
+
+ trips {
+ cpu_alert0: cpu_alert0 {
+ temperature = <8>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_crit: cpu_crit {
+ temperature = <10>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+};
+
&ehci1 {
status = "okay";
};
--
2.9.0
[PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method
From: Ondrej Jirman
PLL1 on H3 requires special factors application algorithm,
when the rate is changed. This algorithm was extracted
from the arisc code that handles frequency scaling
in the BSP kernel.
This commit adds optional apply function to
struct factors_data, that can implement non-trivial
factors application method, when necessary.
Also struct clk_factors_config is extended with position
of the PLL lock flag.
Signed-off-by: Ondrej Jirman
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/clk-factors.c | 34 +--
drivers/clk/sunxi/clk-factors.h | 12
drivers/clk/sunxi/clk-sunxi.c | 72 ++-
4 files changed, 98 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 5faae05..774500c 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -10,6 +10,7 @@ Required properties:
"allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
"allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
+ "allwinner,sun8i-h3-pll1-clk" - for the main PLL clock on H3
"allwinner,sun4i-a10-pll3-clk" - for the video PLL clock on A10
"allwinner,sun9i-a80-pll4-clk" - for the peripheral PLLs on A80
"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index ddefe96..7c165db 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -34,13 +34,6 @@
#define FACTORS_MAX_PARENTS5
-#define SETMASK(len, pos) (((1U << (len)) - 1) << (pos))
-#define CLRMASK(len, pos) (~(SETMASK(len, pos)))
-#define FACTOR_GET(bit, len, reg) (((reg) & SETMASK(len, bit)) >> (bit))
-
-#define FACTOR_SET(bit, len, reg, val) \
- (((reg) & CLRMASK(len, bit)) | (val << (bit)))
-
static unsigned long clk_factors_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
@@ -150,20 +143,24 @@ static int clk_factors_set_rate(struct clk_hw *hw,
unsigned long rate,
if (factors->lock)
spin_lock_irqsave(factors->lock, flags);
- /* Fetch the register value */
- reg = readl(factors->reg);
+ if (factors->apply) {
+ factors->apply(factors, &req);
+ } else {
+ /* Fetch the register value */
+ reg = readl(factors->reg);
- /* Set up the new factors - macros do not do anything if width is 0 */
- reg = FACTOR_SET(config->nshift, config->nwidth, reg, req.n);
- reg = FACTOR_SET(config->kshift, config->kwidth, reg, req.k);
- reg = FACTOR_SET(config->mshift, config->mwidth, reg, req.m);
- reg = FACTOR_SET(config->pshift, config->pwidth, reg, req.p);
+ /* Set up the new factors - macros do not do anything if width
is 0 */
+ reg = FACTOR_SET(config->nshift, config->nwidth, reg, req.n);
+ reg = FACTOR_SET(config->kshift, config->kwidth, reg, req.k);
+ reg = FACTOR_SET(config->mshift, config->mwidth, reg, req.m);
+ reg = FACTOR_SET(config->pshift, config->pwidth, reg, req.p);
- /* Apply them now */
- writel(reg, factors->reg);
+ /* Apply them now */
+ writel(reg, factors->reg);
- /* delay 500us so pll stabilizes */
- __delay((rate >> 20) * 500 / 2);
+ /* delay 500us so pll stabilizes */
+ __delay((rate >> 20) * 500 / 2);
+ }
if (factors->lock)
spin_unlock_irqrestore(factors->lock, flags);
@@ -213,6 +210,7 @@ struct clk *sunxi_factors_register(struct device_node *node,
factors->config = data->table;
factors->get_factors = data->getter;
factors->recalc = data->recalc;
+ factors->apply = data->apply;
factors->lock = lock;
/* Add a gate if this factor clock can be gated */
diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
index 1e63c5b..661a45a 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -6,6 +6,13 @@
#define SUNXI_FACTORS_NOT_APPLICABLE (0)
+#define SETMASK(len, pos) (((1U << (len)) - 1) << (pos))
+#define CLRMASK(len, pos) (~(SETMASK(len, pos)))
+#define FACTOR_GET(bit, len, reg) (((reg) & SETMASK(len, bit)) >> (bit))
+
+#define FACTOR_SET(bit, len, reg, val) \
+ (((reg) & CLRMASK(len, bit)) | (val << (bit)))
+
struct clk_factors_config {
u8 nshift;
u8 nwidth;
@@ -16,6 +23,7 @@ struct clk_factors_config {
u8 pshift;
u8 pwidth;
u8 n_start;
+ u8 lock;
};
s
[PATCH v2 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One
From: Ondrej Jirman
Xulong Orange Pi One uses GPIO based regulator that
switches between two voltages: 1.1V and 1.3V. The
regulator is controlled from the PL6 pin.
Signed-off-by: Ondrej Jirman
---
v2
- add missing pinctrl-names for gpio-regulator
---
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 0adf932..b1bd6b0 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -88,6 +88,25 @@
gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
};
};
+
+ vdd_soc: gpio-regulator {
+ compatible = "regulator-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vdd_reg_r_opc>;
+
+ regulator-name = "soc-vdd-supply";
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <130>;
+ regulator-boot-on;
+ regulator-type = "voltage";
+
+ gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>;
+ states = <110 0x0
+ 130 0x1>;
+
+ startup-delay-us = <10>;
+ enable-active-high;
+ };
};
&ehci1 {
@@ -131,6 +150,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+ vdd_reg_r_opc: regulator_pins@0 {
+ allwinner,pins = "PL6";
+ allwinner,function = "gpio_out";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
};
&uart0 {
--
2.9.0
[PATCH v2 08/14] ARM: dts: sun8i: Add thermal sensor node to the sun8i-h3.dtsi
From: Ondrej Jirman
This patch adds nodes for the thermal sensor driver and
the THS clock to the Allwinner sun8i-h3.dtsi file.
Signed-off-by: Ondrej Jirman
---
arch/arm/boot/dts/sun8i-h3.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index b3247f4..d3c29cc 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -77,6 +77,14 @@
};
};
+ thermal-zones {
+ cpu_thermal: cpu_thermal {
+ polling-delay-passive = <330>;
+ polling-delay = <1000>;
+ thermal-sensors = <&ths 0>;
+ };
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -239,6 +247,14 @@
"bus_scr", "bus_ephy", "bus_dbg";
};
+ ths_clk: clk@01c20074 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun8i-h3-ths-clk";
+ reg = <0x01c20074 0x4>;
+ clocks = <&osc24M>;
+ clock-output-names = "ths";
+ };
+
mmc0_clk: clk@01c20088 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
@@ -574,6 +590,18 @@
interrupts = ;
};
+ ths: ths@01c25000 {
+ #thermal-sensor-cells = <0>;
+ compatible = "allwinner,sun8i-h3-ths";
+ reg = <0x01c25000 0x400>,
+ <0x01c14234 0x4>;
+ interrupts = ;
+ resets = <&apb1_rst 8>;
+ reset-names = "ahb";
+ clocks = <&bus_gates 72>, <&ths_clk>;
+ clock-names = "ahb", "ths";
+ };
+
uart0: serial@01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
--
2.9.0
[PATCH v2 11/14] ARM: dts: sun8i: Add sy8106a regulator to Orange Pi PC
From: Ondrej Jirman
Add sy8106a regulator to r_twi bus and enable the r_twi bus on
Orange Pi PC. This regulator controls the CPUX voltage.
Signed-off-by: Ondrej Jirman
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index daf50b9a6..79f0b49 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -90,6 +90,20 @@
};
};
+&r_twi {
+ status = "okay";
+
+ vdd_cpu: regulator@65 {
+ compatible = "silergy,sy8106a";
+ reg = <0x65>;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ regulator-ramp-delay = <200>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
&ehci1 {
status = "okay";
};
--
2.9.0
[PATCH v2 10/14] ARM: dts: sun8i: Add r_twi I2C controller
From: Ondrej Jirman
H3 SoC contains I2C controller optionally available
on the PL0 and PL1 pins. This patch makes this controller
available.
Signed-off-by: Ondrej Jirman
---
arch/arm/boot/dts/sun8i-h3.dtsi | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 56f211e..e32f211 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -322,8 +322,9 @@
reg = <0x01f01428 0x4>;
#clock-cells = <1>;
clocks = <&apb0>;
- clock-indices = <0>, <1>;
- clock-output-names = "apb0_pio", "apb0_ir";
+ clock-indices = <0>, <1>, <6>;
+ clock-output-names = "apb0_pio", "apb0_ir", "apb0_i2c";
+
};
ir_clk: ir_clk@01f01454 {
@@ -656,6 +657,20 @@
status = "disabled";
};
+ r_twi: i2c@01f02400 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01f02400 0x400>;
+ interrupts = ;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_twi_pins_a>;
+ clocks = <&apb0_gates 6>;
+ clock-frequency = <10>;
+ resets = <&apb0_reset 6>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
gic: interrupt-controller@01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
@@ -707,6 +722,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+ r_twi_pins_a: r_twi@0 {
+ allwinner,pins = "PL0", "PL1";
+ allwinner,function = "s_twi";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
};
};
};
--
2.9.0
[PATCH v2 12/14] ARM: dts: sun8i: Setup CPU operating points for Onrage PI PC
From: Ondrej Jirman
Orange PI PC uses SY8106A regulator for fine grained CPUX voltage
regulation. Setup appropriate operating points for the board.
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 48 ++
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 79f0b49..1b029e9 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -90,6 +90,54 @@
};
};
+&cpu0 {
+ operating-points = <
+ /* kHzuV */
+ 1512000 140
+ 144 140
+ 1368000 134
+ 1344000 134
+ 1296000 134
+ 1248000 130
+ 1224000 130
+ 120 130
+ 1104000 120
+ 1008000 114
+ 96 110
+ 648000 110
+ 48 110
+ 24 110
+ 12 110
+ >;
+ #cooling-cells = <2>;
+ cooling-min-level = <0>;
+ cooling-max-level = <14>;
+ cpu0-supply = <&vdd_cpu>;
+};
+
+&cpu_thermal {
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device = <&cpu0 (-1) (-1)>;
+ };
+ };
+
+ trips {
+ cpu_alert0: cpu_alert0 {
+ temperature = <8>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_crit: cpu_crit {
+ temperature = <10>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+};
+
&r_twi {
status = "okay";
--
2.9.0
[PATCH v2 04/14] regulator: SY8106A regulator driver
From: Ondrej Jirman
SY8106A is I2C attached single output voltage regulator
made by Silergy.
Signed-off-by: Ondrej Jirman
---
v2
- added dt-bindings for the regulator
- changed to use of_device_id for probing
- added initialization failure checks
---
drivers/regulator/Kconfig | 8 +-
drivers/regulator/Makefile| 2 +-
drivers/regulator/sy8106a-regulator.c | 171 ++
3 files changed, 179 insertions(+), 2 deletions(-)
create mode 100644 drivers/regulator/sy8106a-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 144cbf5..93f3fe4f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -702,6 +702,13 @@ config REGULATOR_STW481X_VMMC
This driver supports the internal VMMC regulator in the STw481x
PMIC chips.
+config REGULATOR_SY8106A
+ tristate "Silergy SY8106A"
+ depends on I2C && (OF || COMPILE_TEST)
+ select REGMAP_I2C
+ help
+ This driver provides support for SY8106A voltage regulator.
+
config REGULATOR_TPS51632
tristate "TI TPS51632 Power Regulator"
depends on I2C
@@ -861,4 +868,3 @@ config REGULATOR_WM8994
WM8994 CODEC.
endif
-
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 85a1d44..e3f720f 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
+obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
obj-$(CONFIG_REGULATOR_TPS62360) += tps62360-regulator.o
@@ -111,5 +112,4 @@ obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
-
ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
diff --git a/drivers/regulator/sy8106a-regulator.c
b/drivers/regulator/sy8106a-regulator.c
new file mode 100644
index 000..98626bc
--- /dev/null
+++ b/drivers/regulator/sy8106a-regulator.c
@@ -0,0 +1,171 @@
+/*
+ * sy8106a-regulator.c - Regulator device driver for SY8106A
+ *
+ * Copyright (C) 2016 Ondřej Jirman
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Library General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Library General Public License for more details.
+ *
+ * You should have received a copy of the GNU Library General Public
+ * License along with this library; if not, write to the
+ * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SY8106A_REG_VOUT1_SEL 0x01
+#define SY8106A_REG_VOUT_COM 0x02
+#define SY8106A_REG_VOUT1_SEL_MASK 0x7f
+#define SY8106A_DISABLE_REGBIT(0)
+#define SY8106A_GO_BIT BIT(7)
+
+struct sy8106a {
+ struct regulator_dev *rdev;
+ struct regmap *regmap;
+};
+
+static const struct regmap_config sy8106a_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned sel)
+{
+ /* We use our set_voltage_sel in order to avoid unnecessary I2C chatter,
+* because the regulator_get_voltage_sel_regmap using apply_bit
+* would perform 4 unnecessary transfers instead of one, increasing the
+* chance of error.
+*/
+ return regmap_write(rdev->regmap, rdev->desc->vsel_reg,
+ sel | SY8106A_GO_BIT);
+}
+
+static const struct regulator_ops sy8106a_ops = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_voltage_sel = sy8106a_set_voltage_sel,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_linear,
+};
+
+/* Default limits measured in millivolts and milliamps */
+#define SY8106A_MIN_MV 680
+#define SY8106A_MAX_MV 1950
+#define SY8106A_STEP_MV10
+
+static const struct regulator_desc sy8106a_reg = {
+ .name = "SY8106A",
+ .id = 0,
+ .ops = &sy8106a_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = ((SY8106A_MAX_MV - SY8106A_MIN_MV) / SY8106A_STEP_MV) + 1,
+ .min_uV = (SY8106A_MIN_MV * 1000),
+ .uV_step = (SY8106A_STEP_MV * 10
[PATCH v2 03/14] dt-bindings: document sun8i_ths - H3 thermal sensor driver
From: Ondrej Jirman
This patch adds the binding documentation for the
sun8i_ths driver. This is a driver for thermal sensor
found in Allwinner H3 SoC.
Signed-off-by: Ondřej Jirman
---
.../devicetree/bindings/thermal/sun8i-ths.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-ths.txt
diff --git a/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
new file mode 100644
index 000..76859d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
@@ -0,0 +1,26 @@
+* Thermal sensor driver for Allwinner H3 SoC
+
+Required properties:
+- compatible : "allwinner,sun8i-h3-ths"
+- reg : Address range of the thermal sensor registers and of the calibration
+ data
+- resets : Must contain phandles to reset controls matching the entries
+ of the names
+- reset-names : Must include the name "ahb"
+- clocks : Must contain phandles to clock controls matching the entries
+ of the names
+- clock-names : Must contain "ahb" for the bus gate and "ths" for the THS
+ clock
+
+Example:
+ths: ths@01c25000 {
+ #thermal-sensor-cells = <0>;
+ compatible = "allwinner,sun8i-h3-ths";
+ reg = <0x01c25000 0x400>,
+ <0x01c14234 0x4>;
+ interrupts = ;
+ resets = <&bus_rst 136>;
+ reset-names = "ahb";
+ clocks = <&bus_gates 72>, <&ths_clk>;
+ clock-names = "ahb", "ths";
+};
--
2.9.0
Re: [RFC/PATCH] ftrace: Reduce size of function graph entries
On Sat, Jun 25, 2016 at 2:29 AM, Steven Rostedt wrote:
> On Sat, 25 Jun 2016 01:15:34 +0900
> Namhyung Kim wrote:
>
>> On Fri, Jun 24, 2016 at 12:04:40PM -0400, Steven Rostedt wrote:
>> > On Fri, 24 Jun 2016 15:35:44 +0900
>> > Namhyung Kim wrote:
>> >
>> >
>> > > > > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
>> > > > > index dea12a6e413b..35c523ba5c59 100644
>> > > > > --- a/include/linux/ftrace.h
>> > > > > +++ b/include/linux/ftrace.h
>> > > > > @@ -751,25 +751,33 @@ extern void ftrace_init(void);
>> > > > > static inline void ftrace_init(void) { }
>> > > > > #endif
>> > > > >
>> > > > > +#ifndef CONFIG_HAVE_64BIT_ALIGNED_ACCESS
>> > > > > +# define FTRACE_ALIGNMENT4
>> > > > > +#else
>> > > > > +# define FTRACE_ALIGNMENT8
>> > > > > +#endif
>> > > >
>>
>> As far as I can see, the ring buffer has following code in ring_buffer.c:
>>
>> #define RB_ALIGNMENT4U
>> #define RB_MAX_SMALL_DATA (RB_ALIGNMENT * RINGBUF_TYPE_DATA_TYPE_LEN_MAX)
>> #define RB_EVNT_MIN_SIZE8U /* two 32bit words */
>>
>> #ifndef CONFIG_HAVE_64BIT_ALIGNED_ACCESS
>> # define RB_FORCE_8BYTE_ALIGNMENT 0
>> # define RB_ARCH_ALIGNMENT RB_ALIGNMENT
>> #else
>> # define RB_FORCE_8BYTE_ALIGNMENT 1
>> # define RB_ARCH_ALIGNMENT 8U
>> #endif
>>
>> #define RB_ALIGN_DATA __aligned(RB_ARCH_ALIGNMENT)
>>
>
> Right, what I meant was that we should just define FTRACE_ALIGNMENT
> unconditionally to 4. If CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set,
> it will add the buffered space regardless.
>
> You already moved "overrun", I don't see anything that would be out of
> alignment if the structure itself is aligned.
In that case if CONFIG_HAVE_64BIT_ALIGNED_ACCESS is set, the ring
buffer is 8-byte aligned but the struct is 4-byte aligned, right? Note
that the function graph tracer saves the data in a local variable (of
the struct) first and copies to the ring buffer later. Wouldn't it be
a problem?
Thanks,
Namhyung
[RFT PATCH] regmap-i2c: Only use I2C_FUNC_I2C if val_bits == 8
On chips with a register value size of 16 bits, I2C block reads will
typically not return the expected values. Instead, returned values
are most likely undefined if an operation crosses a register boundary.
This can be observed, for example, with a TMP102 connected to an omap
i2c controller. With this chip, the initial regmap read operation to fill
the register cache looks as follows (debug log from modified kernel).
omap_i2c 4807.i2c: MSG[0]: add=0x0048, len: 1, flags: 0x0
omap_i2c 4807.i2c: [0] 0x00
omap_i2c 4807.i2c: MSG[1]: add=0x0048, len: 8, flags: 0x1
omap_i2c 4807.i2c: [0] 0x23
omap_i2c 4807.i2c: [1] 0xa0
omap_i2c 4807.i2c: [2] 0xff
omap_i2c 4807.i2c: [3] 0xff
omap_i2c 4807.i2c: [4] 0xff
omap_i2c 4807.i2c: [5] 0xff
omap_i2c 4807.i2c: [6] 0xff
omap_i2c 4807.i2c: [7] 0xff
Reported-by: Nishanth Menon
Cc: Nishanth Menon
Signed-off-by: Guenter Roeck
---
Nishanth,
it would be great if you can test this patch, to see if it solves the problem
you had observed. Please note that https://patchwork.kernel.org/patch/9191185/
needs to be applied first (it is available in next-20160624).
drivers/base/regmap/regmap-i2c.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap-i2c.c b/drivers/base/regmap/regmap-i2c.c
index 4735318f4268..f319e6829816 100644
--- a/drivers/base/regmap/regmap-i2c.c
+++ b/drivers/base/regmap/regmap-i2c.c
@@ -257,7 +257,8 @@ static struct regmap_bus regmap_i2c_smbus_i2c_block = {
static const struct regmap_bus *regmap_get_i2c_bus(struct i2c_client *i2c,
const struct regmap_config *config)
{
- if (i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C))
+ if (config->val_bits == 8 &&
+ i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C))
return ®map_i2c;
else if (config->val_bits == 8 && config->reg_bits == 8 &&
i2c_check_functionality(i2c->adapter,
--
2.5.0
[PATCH] notifier: Fix soft lockup for notifier_call_chain().
The problem was occurs in my system that a lot of drviers register its own handler to the notifier call chain for netdev_chain, and then create 4095 vlan dev for one nic, and add several ipv6 address on each one of them, just like this: for i in `seq 1 4095`; do ip link add link eth0 name eth0.$i type vlan id $i; done for i in `seq 1 4095`; do ip -6 addr add 2001::$i dev eth0.$i; done for i in `seq 1 4095`; do ip -6 addr add 2002::$i dev eth0.$i; done for i in `seq 1 4095`; do ip -6 addr add 2003::$i dev eth0.$i; done ifconfig eth0 up ifconfig eth0 down then it will halt several seconds, and occurs softlockup: <0>[ 7620.364058]NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [ifconfig:19186] <0>[ 7620.364592]Call trace: <4>[ 7620.364599][] dump_backtrace+0x0/0x220 <4>[ 7620.364603][] show_stack+0x20/0x28 <4>[ 7620.364607][] dump_stack+0x90/0xb0 <4>[ 7620.364612][] watchdog_timer_fn+0x41c/0x460 <4>[ 7620.364617][] __run_hrtimer+0x98/0x2d8 <4>[ 7620.364620][] hrtimer_interrupt+0x110/0x288 <4>[ 7620.364624][] arch_timer_handler_phys+0x38/0x48 <4>[ 7620.364628][] handle_percpu_devid_irq+0x9c/0x190 <4>[ 7620.364632][] generic_handle_irq+0x40/0x58 <4>[ 7620.364635][] __handle_domain_irq+0x68/0xc0 <4>[ 7620.364638][] gic_handle_irq+0xc4/0x1c8 <4>[ 7620.364641]Exception stack(0xffc0309b3640 to 0xffc0309b3770) <4>[ 7620.364644]3640: 1000 ffc0309b37c0 ffbfa1019cf8 <4>[ 7620.364647]3660: 8145 ffc0309b3958 ffbfa1013008 <4>[ 7620.364651]3680: 07f0 ffbfa131b770 ffd08aaadc40 ffbfa1019cf8 <4>[ 7620.364654]36a0: ffbfa1019cc4 ffd089c2b000 ffd08eff8000 ffc0309b3958 <4>[ 7620.364656]36c0: ffbfa101c5c0 ffbfa101c66c <4>[ 7620.364659]36e0: 7f7f7f7f7f7f7f7f 0030 <4>[ 7620.364662]3700: ffc000393d58 007f794d67b0 <4>[ 7620.364665]3720: 007fe62215d0 ffc0309b3830 ffc00021d8e0 ffbfa1049b68 <4>[ 7620.364668]3740: ffc000697578 ffc0006974b8 ffc0309b3958 <4>[ 7620.364670]3760: ffbfa1013008 07f0 <4>[ 7620.364673][] el1_irq+0x80/0x100 <4>[ 7620.364692][] fib6_walk+0x3c/0x70 [ipv6] <4>[ 7620.364710][] fib6_clean_tree+0x68/0x90 [ipv6] <4>[ 7620.364727][] __fib6_clean_all+0x88/0xc0 [ipv6] <4>[ 7620.364746][] fib6_clean_all+0x28/0x30 [ipv6] <4>[ 7620.364763][] rt6_ifdown+0x64/0x148 [ipv6] <4>[ 7620.364781][] addrconf_ifdown+0x68/0x540 [ipv6] <4>[ 7620.364798][] addrconf_notify+0xd0/0x8b8 [ipv6] <4>[ 7620.364801][] notifier_call_chain+0x5c/0xa0 <4>[ 7620.364804][] raw_notifier_call_chain+0x20/0x28 <4>[ 7620.364809][] call_netdevice_notifiers_info+0x4c/0x80 <4>[ 7620.364812][] dev_close_many+0xd0/0x138 <4>[ 7620.364821][] vlan_device_event+0x4a8/0x6a0 [8021q] <4>[ 7620.364824][] notifier_call_chain+0x5c/0xa0 <4>[ 7620.364827][] raw_notifier_call_chain+0x20/0x28 <4>[ 7620.364830][] call_netdevice_notifiers_info+0x4c/0x80 <4>[ 7620.364833][] __dev_notify_flags+0xb8/0xe0 <4>[ 7620.364836][] dev_change_flags+0x54/0x68 <4>[ 7620.364840][] devinet_ioctl+0x650/0x700 <4>[ 7620.364843][] inet_ioctl+0xa4/0xc8 <4>[ 7620.364847][] sock_do_ioctl+0x44/0x88 <4>[ 7620.364850][] sock_ioctl+0x23c/0x308 <4>[ 7620.364854][] do_vfs_ioctl+0x48c/0x620 <4>[ 7620.364857][] SyS_ioctl+0x94/0xa8 =cut here It looks that the notifier_call_chain has to deal with too much handler, and will not feed the watchdog until finish the work, so add cond_resched() in the loops to fix this problem, and it will not panic again. Signed-off-by: Ding Tianhong --- kernel/notifier.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/notifier.c b/kernel/notifier.c index fd2c9ac..9c30411 100644 --- a/kernel/notifier.c +++ b/kernel/notifier.c @@ -92,6 +92,8 @@ static int notifier_call_chain(struct notifier_block **nl, #endif ret = nb->notifier_call(nb, val, v); + cond_resched(); + if (nr_calls) (*nr_calls)++; -- 1.9.0
Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)
On Fri, Jun 24, 2016 at 2:34 PM, Andy Lutomirski wrote:
>>
>> So let me get the pure semantic patches done, and then for 4.8 when we
>> do the things that actually change real meaning we'll have a sane
>> base. Ok?
>
> Works for me. I'll see whether my vmap patches still apply and, if
> needed, rebase and send a v5.
Ok, I'e pushed out the cleanups (and all the pulls that always come in
on Friday afternoon - gaah, I shouldn't have tried doing this on a
Friday).
I'm attaching the current left-over patch that actually changes
things. It's obviously a composite, and includes your "remove
stack_smp_processor_id()" thing etc, so it's not meant to be used
as-is, but it does seem to work.
Interestingly, it seems pretty clean too, removing more lines than it
adds (despite the fact that it adds a new config option), and
generally making things prettier rather than the reverse.
That's always a good sign.
Linus
This is an attempt at moving the thread_info into the task_struct
arch/x86/Kconfig | 1 +
arch/x86/entry/common.c| 21 +++--
arch/x86/entry/entry_64.S | 9 ++---
arch/x86/include/asm/cpu.h | 1 -
arch/x86/include/asm/smp.h | 6 --
arch/x86/include/asm/switch_to.h | 6 ++
arch/x86/include/asm/thread_info.h | 37 +++--
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/irq_64.c | 3 +--
arch/x86/kernel/process.c | 6 ++
arch/x86/um/ptrace_32.c| 8
include/linux/init_task.h | 9 +
include/linux/sched.h | 18 +++---
init/Kconfig | 3 +++
init/init_task.c | 7 +--
15 files changed, 59 insertions(+), 78 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d9a94da0c29f..f33bc80577c5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -154,6 +154,7 @@ config X86
select SPARSE_IRQ
select SRCU
select SYSCTL_EXCEPTION_TRACE
+ select THREAD_INFO_IN_TASK
select USER_STACKTRACE_SUPPORT
select VIRT_TO_BUS
select X86_DEV_DMA_OPS if X86_64
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index ec138e538c44..d5feac5f252d 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -31,13 +31,6 @@
#define CREATE_TRACE_POINTS
#include
-static struct thread_info *pt_regs_to_thread_info(struct pt_regs *regs)
-{
- unsigned long top_of_stack =
- (unsigned long)(regs + 1) + TOP_OF_KERNEL_STACK_PADDING;
- return (struct thread_info *)(top_of_stack - THREAD_SIZE);
-}
-
#ifdef CONFIG_CONTEXT_TRACKING
/* Called on entry from user mode with IRQs off. */
__visible void enter_from_user_mode(void)
@@ -78,7 +71,7 @@ static void do_audit_syscall_entry(struct pt_regs *regs, u32
arch)
*/
unsigned long syscall_trace_enter_phase1(struct pt_regs *regs, u32 arch)
{
- struct thread_info *ti = pt_regs_to_thread_info(regs);
+ struct thread_info *ti = current_thread_info();
unsigned long ret = 0;
u32 work;
@@ -156,7 +149,7 @@ unsigned long syscall_trace_enter_phase1(struct pt_regs
*regs, u32 arch)
long syscall_trace_enter_phase2(struct pt_regs *regs, u32 arch,
unsigned long phase1_result)
{
- struct thread_info *ti = pt_regs_to_thread_info(regs);
+ struct thread_info *ti = current_thread_info();
long ret = 0;
u32 work = ACCESS_ONCE(ti->flags) & _TIF_WORK_SYSCALL_ENTRY;
@@ -239,7 +232,7 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32
cached_flags)
/* Disable IRQs and retry */
local_irq_disable();
- cached_flags = READ_ONCE(pt_regs_to_thread_info(regs)->flags);
+ cached_flags = READ_ONCE(current_thread_info()->flags);
if (!(cached_flags & EXIT_TO_USERMODE_LOOP_FLAGS))
break;
@@ -250,7 +243,7 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32
cached_flags)
/* Called with IRQs disabled. */
__visible inline void prepare_exit_to_usermode(struct pt_regs *regs)
{
- struct thread_info *ti = pt_regs_to_thread_info(regs);
+ struct thread_info *ti = current_thread_info();
u32 cached_flags;
if (IS_ENABLED(CONFIG_PROVE_LOCKING) && WARN_ON(!irqs_disabled()))
@@ -309,7 +302,7 @@ static void syscall_slow_exit_work(struct pt_regs *regs,
u32 cached_flags)
*/
__visible inline void syscall_return_slowpath(struct pt_regs *regs)
{
- struct thread_info *ti = pt_regs_to_thread_info(regs);
+ struct thread_info *ti = current_thread_info();
u32 cached_flags = READ_ONCE(ti->flags);
CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
@@ -332,7 +325,7 @@ __visible inline void syscall_return_slowpath(struct
pt_regs *regs)
#ifdef CONFIG_X86_64
__visible void do_sys
Re: [PATCH] block-dev: enable writeback cgroup support
On 02/01/2016 08:50 PM, Shaohua Li wrote: > block_dev's .writepages/.writepage already handles > wbc_init_bio/wbc_account_io. We only set the SB_I_CGROUPWB bit to > suppport writeback cgroup support. > > Signed-off-by: Shaohua Li Hey Shaohua, I'm seeing the following while fuzzing: [ 496.950320] kasan: CONFIG_KASAN_INLINE enabled [ 496.950952] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 496.950954] general protection fault: [#1] PREEMPT SMP KASAN [ 496.950978] Modules linked in: [ 496.951026] CPU: 4 PID: 8535 Comm: syz-executor Tainted: G W 4.7.0-rc4-next-20160624-sasha-00024-gdee1616 #3132 [ 496.951051] task: 8801bb0a9000 ti: 8801b5b7 task.ti: 8801b5b7 [ 496.951406] RIP: bd_mount (fs/block_dev.c:663) [ 496.951423] RSP: 0018:8801b5b77c48 EFLAGS: 00010207 [ 496.951437] RAX: dc00 RBX: RCX: [ 496.951452] RDX: 000c RSI: aa2dc3e0 RDI: 0067 [ 496.951466] RBP: 8801b5b77c58 R08: 8801c45b8008 R09: [ 496.951522] R10: ed00190c9c00 R11: R12: abba6360 [ 496.951533] R13: 8800c79c92b8 R14: 8800c864e000 R15: 8011 [ 496.951545] FS: 7fc253974700() GS:8801d410() knlGS: [ 496.951553] CS: 0010 DS: ES: CR0: 80050033 [ 496.951561] CR2: 006f CR3: 0001b876c000 CR4: 000406a0 [ 496.951577] Stack: [ 496.951593] 8801d0af1160 abba6360 8801b5b77c98 9d831a20 [ 496.951607] 24ee 8800c1b1b040 abba6360 8800c79c92b8 [ 496.951622] 8011 fff4 8801b5b77cd8 9d88bf7a [ 496.951625] Call Trace: [ 496.951660] mount_fs (fs/super.c:1178) [ 496.951682] vfs_kern_mount (fs/namespace.c:949) [ 496.951701] do_mount (fs/namespace.c:2393 fs/namespace.c:2714) [ 496.951733] ? ___slab_alloc (mm/slub.c:2576) [ 496.951751] ? copy_mount_string (fs/namespace.c:2645) [ 496.953177] ? preempt_schedule_irq (./arch/x86/include/asm/bitops.h:311 include/linux/thread_info.h:92 include/linux/sched.h:3269 kernel/sched/core.c:3535) [ 496.953447] ? __sanitizer_cov_trace_pc (kernel/kcov.c:72) [ 496.953469] ? copy_mount_options (fs/namespace.c:2622) [ 496.953486] SyS_mount (fs/namespace.c:2908 fs/namespace.c:2883) [ 496.953501] ? copy_mnt_ns (fs/namespace.c:2883) [ 496.953542] do_syscall_64 (arch/x86/entry/common.c:284) [ 496.953560] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:251) [ 496.953700] Code: a0 d9 73 a7 e8 43 e8 fc ff 48 85 c0 48 89 c3 74 63 e8 86 54 cf ff 48 8d 7b 68 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 74 05 e8 c6 9b ed ff 4c 8b 63 68 4d 85 e4 75 0e 31 All code 0: a0 d9 73 a7 e8 43 e8movabs 0xfffce843e8a773d9,%al 7: fc ff 9: 48 85 c0test %rax,%rax c: 48 89 c3mov%rax,%rbx f: 74 63 je 0x74 11: e8 86 54 cf ff callq 0xffcf549c 16: 48 8d 7b 68 lea0x68(%rbx),%rdi 1a: 48 b8 00 00 00 00 00movabs $0xdc00,%rax 21: fc ff df 24: 48 89 famov%rdi,%rdx 27: 48 c1 ea 03 shr$0x3,%rdx 2b:* 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction 2f: 74 05 je 0x36 31: e8 c6 9b ed ff callq 0xffed9bfc 36: 4c 8b 63 68 mov0x68(%rbx),%r12 3a: 4d 85 e4test %r12,%r12 3d: 75 0e jne0x4d 3f: 31 00 xor%eax,(%rax) Code starting with the faulting instruction === 0: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) 4: 74 05 je 0xb 6: e8 c6 9b ed ff callq 0xffed9bd1 b: 4c 8b 63 68 mov0x68(%rbx),%r12 f: 4d 85 e4test %r12,%r12 12: 75 0e jne0x22 14: 31 00 xor%eax,(%rax) [ 496.953718] RIP bd_mount (fs/block_dev.c:663) [ 496.953723] RSP
Re: [PATCH] hwmon: (emc6w201): trivial fix of spelling mistake "Unknwown" -> "Unknown"
On 06/24/2016 10:31 AM, Colin King wrote: From: Colin Ian King trivial fix to spelling mistake in dev_dbg message Signed-off-by: Colin Ian King --- Applied to -next. Thanks, Guenter
Re: [RFC] reference count hardening via kref: another attempt
On Fri, Jun 24, 2016 at 6:13 PM, Jann Horn wrote: > I would like to harden the kernel against reference count > overflow bugs. The commit message of the patch contains > a short analysis of code size impact, an explanation why I > want reference count hardening to land in the kernel, and a > description of the algorithm I'd want to use. > > The reason I'm writing a cover letter is that my patch, on > its own, is pretty useless: My patch only adds hardening to > struct kref, but nearly all reference counters are > currently implemented using atomic_t, which is a generic > atomic number type. For the patch to be useful, I'll have > to go through the kernel and, for every atomic_t, decide > whether it is a reference count and, if so, change it > (together with all accesses to it) to a kref. According to > a quick grep, there are currently about 2700 atomic_t > struct members or variables in the kernel, so it's going to > be a big amount of work, and the resulting patches will be > gigantic. > > Therefore, before I actually spend lots of time on this, > I'd like to know: > > - Does the reference count hardening in my patch look >okay, and does it have good chances to get accepted >when submitted for inclusion in the kernel at a later >point in time? > > - If I manually go through the kernel and write a >gigantic atomic_t -> struct kref patch (or a few >patches coarsely grouped by subsystem), how high is >the probability that it will get accepted? My main concern is atomic_t will continue to get misused. While I have no problem with wrap-checking kref, I think that we need to follow grsecurity and introduce a new type (in grsec it is "atomic_unchecked_t", but I think a more descriptive name would be "atomic_wrap_t") and add them everywhere they're needed, and then globally protect atomic_t wrapping. kref would gain the protections automatically, though it would be arch-dependent... -Kees > > (Note: I won't have much time for kernel work in the next > four months or so - but afterwards, I could probably > allocate time for getting this done.) > > Jann Horn (1): > kref: pin objects with dangerously high reference count > > include/linux/kref.h | 39 +-- > init/Kconfig | 16 > kernel/Makefile | 2 +- > kernel/kref.c| 17 + > 4 files changed, 67 insertions(+), 7 deletions(-) > create mode 100644 kernel/kref.c > > -- > 2.8.0.rc3.226.g39d4020 > -- Kees Cook Chrome OS & Brillo Security
[PATCH] perf build: Add libbabeltrace to build-test
'make build-test' doesn't test LIBBABELTRACE=1. It misses a building
failure caused by commit 41840d211c51 ("perf config: Move config
declarations from util/cache.h to util/config.h"), breaks bisect.
Add LIBBABELTRACE=1 to build-test.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
---
tools/perf/tests/make | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index cac15d9..51966d9 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -81,6 +81,7 @@ make_no_libbionic := NO_LIBBIONIC=1
make_no_auxtrace:= NO_AUXTRACE=1
make_no_libbpf := NO_LIBBPF=1
make_no_libcrypto := NO_LIBCRYPTO=1
+make_with_babeltrace:= LIBBABELTRACE=1
make_tags := tags
make_cscope := cscope
make_help := help
@@ -136,6 +137,7 @@ run += make_no_libaudit
run += make_no_libbionic
run += make_no_auxtrace
run += make_no_libbpf
+run += make_with_babeltrace
run += make_help
run += make_doc
run += make_perf_o
--
1.8.3.4
Re: kernel-4.7 bug in Intel sound and/or ACPI
On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote: > > Can you give it a try? Whell, I tried to no avail. Wether it is on 4.6 or 4.7, with or without your previous patch, I keep getting rejected hunks. For example, here the line to be deleted is nowhere to be found: > diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c > index 714ba4d..c2f22c9 100644 > --- a/drivers/acpi/pci_link.c > +++ b/drivers/acpi/pci_link.c > @@ -497,7 +497,7 @@ static int acpi_irq_get_penalty(int irq) > int penalty = 0; > > if (irq < ACPI_MAX_ISA_IRQS) > - penalty += acpi_isa_irq_penalty[irq]; > + return acpi_isa_irq_penalty[irq]; > > /* > * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict Regards, Wim. - w...@djo.tudelft.nl -
Re: [PATCH 5/8] KEYS: Provide software public key query function [ver #2]
On Fri, Jun 24, 2016 at 01:06:02PM +0100, David Howells wrote: > > The problem is that if I'm to produce consistency with, say, the TPM > interface, then I have to deal in wrapped/padded data - leastways as far as I > can tell from reading the docs. So the TPM device is accessed through the same interface? Where is the code for it? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] perf data convert: Include config.h header
You can add:
Fixes: 41840d211c51 ("perf config: Move config declarations from
util/cache.h to util/config.h")
Thank you.
On 2016/6/24 20:40, Jiri Olsa wrote:
otherwise some compiler might scream:
$ make LIBBABELTRACE_DIR=/opt/libbabeltrace/ LIBBABELTRACE=1
BUILD: Doing 'make -j4' parallel build
CC util/data-convert-bt.o
util/data-convert-bt.c: In function ‘convert__config’:
util/data-convert-bt.c:1299:19: error: implicit declaration of function
‘perf_config_u64’ [-Werror=implicit-function-declaration]
c->queue_size = perf_config_u64(var, value);
...
Link: http://lkml.kernel.org/n/tip-t9dyx71w49dy5tacpdzr5...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/data-convert-bt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/data-convert-bt.c
b/tools/perf/util/data-convert-bt.c
index 9f53020c3269..5186bb1168af 100644
--- a/tools/perf/util/data-convert-bt.c
+++ b/tools/perf/util/data-convert-bt.c
@@ -26,6 +26,7 @@
#include "evlist.h"
#include "evsel.h"
#include "machine.h"
+#include "config.h"
#define pr_N(n, fmt, ...) \
eprintf(n, debug_data_convert, fmt, ##__VA_ARGS__)
Re: [PATCH 1/5] hwmon: (tmp102) Use devm_add_action to register cleanup function
On 06/24/2016 11:21 AM, Nishanth Menon wrote: On 06/24/2016 01:18 PM, Guenter Roeck wrote: On Fri, Jun 24, 2016 at 01:02:32PM -0500, Nishanth Menon wrote: On 06/24/2016 11:36 AM, Guenter Roeck wrote: On Fri, Jun 24, 2016 at 10:23:10AM -0500, Nishanth Menon wrote: On 06/24/2016 09:54 AM, Guenter Roeck wrote: On 06/24/2016 07:30 AM, Guenter Roeck wrote: Hi Nishanth, On 06/24/2016 07:13 AM, Nishanth Menon wrote: On 06/23/2016 07:28 PM, Guenter Roeck wrote: By registering a cleanup function with devm_add_action(), we can simplify the error path in the probe function and drop the remove function entirely. Signed-off-by: Guenter Roeck I dont seem to have a cover letter to reply to... but anyways.. Before: http://pastebin.ubuntu.com/17801376/ After all 5 patches: http://pastebin.ubuntu.com/17801824/ Fails on beagleboard-X15 with: [ 36.781509] tmp102 0-0048: No cache defaults, reading back from HW [ 36.795940] tmp102 0-0048: unexpected config register value I have'nt bisected down on the specific patch in the series. Have you had a chance to test the series? Thanks for testing. Yes, I did test it. Maybe different chip revisions, or different initial config register values and I messed up there. Can you send me the output of i2cdump (word wide) ? Before 5 patches: # i2cdump -f 0 0x48 w 0,8 1,9 2,a 3,b 4,c 5,d 6,e 7,f 00: 7912 b062 004b 0050 c018 e006 [ ... ] After 5 patches: i2cdump -y 0 0x48 w 0,8 1,9 2,a 3,b 4,c 5,d 6,e 7,f 00: 5024 a060 004b 0050 c018 e006 [ ] I can try and debug the series once I get some spare time, might be over the weekend or next week. The register map, at least the initial one, is pretty much the same as mine and as expected. The configuration register in the second map is messed up, possible because of a write with wrong endianness. Got a few mins skipping lunch.. ;) I did a quick bisect, and it is indeed the patch #5 that breaks. added http://pastebin.ubuntu.com/17812044/ and got: tmp102 0-0048: regval = 0x That was weird. Does'nt look like endian-ness swap thingy So, did the following hack to see all messages flowing in and out from 0x48 at bus controller driver level: http://pastebin.ubuntu.com/17813093/ / # dmesg|grep XXX / # Before patch #5 (and on next-20160624): the same diff gave: http://pastebin.ubuntu.com/17813303/ I bet the regmap_read() of the configuration register returns 0xa060 (or 0xb062) instead of 0x60a0 / 0x62b0 on your system. If you find the time, it would be great if you can confirm by printing the register value with the "unexpected config register value" message (guess I should have left that in place - I used it during testing ;-). If that is the case, I'll probably have to drop the regmap changes, at least for now. It would mean that regmap is broken for chips like the LM75 (ie for all chips with 16-bit registers) on controllers supporting I2C_FUNC_I2C. It does look like everything is getting cached out and no actual reads are actually getting through to the bus controller driver even. Yes, that is really weird. It also seems to fill the cache with 0x, which is even more weird. Ok, looks like converting drivers to regmap isn't a good idea. I'll need to get a system with an adapter supporting I2C_FUNC_I2C and do some more testing. I tested on next-20160624 and used omap2plus_defconfig for the test. Thanks a lot for the information, and for testing this with your system. here is more: http://pastebin.ubuntu.com/17814261/ Looks like return for is_writable etc should probably be true or false But it is. The result of "reg != TMP102_TEMP_REG" is a boolean. Even if that was not the case, the function return value is bool, so per C standard a non-boolean return value would be auto-converted to 0 / 1. [ 32.609935] at24 0-0050: 4096 byte 24c32 EEPROM, writable, 1 bytes/write [ 32.751560] rtc-ds1307 2-006f: SET TIME! [ 32.857593] palmas_pwrbutton 4807.i2c:tps659038@58:tps659038_pwr_button: h/w controlled shutdown duration=12 s econds [ 33.047265] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0 [ 33.135774] tmp102 0-0048: No cache defaults, reading back from HW [ 33.538655] rtc-ds1307 2-006f: 64 bytes nvram [ 34.202107] omap_rng 4809.rng: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info [ 34.211191] omap_rng 4809.rng: Failed to runtime_get device: -19 [ 34.217869] omap_rng 4809.rng: initialization failed. [ 34.229190] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as rtc2 [ 34.371375] omap_i2c 4807.i2c: XXX MSG[0]: add=0x0048, len: 1, flags: 0x0 [ 34.378893] omap_i2c 4807.i2c: XXX:[0] 0x00 / # [ 34.457000] omap_i2c 4807.i2c: XXX MSG[1]: add=0x0048, len: 8, flags: 0x1 [ 34.464476] omap_i2c 4807.i2c: XXX:[0] 0x23 [ 34.469255] omap_i2c 4807.i2c: XXX:[1] 0xa0 [ 34.473999] omap_i2c 4807.i2c:
Re: [PATCH] memory:bugxfix panic on cat or write /dev/kmem
On 2016/6/23 20:42, Michal Hocko wrote:
On Fri 24-06-16 01:30:10, chenj...@huawei.com wrote:
From: chenjie
cat /dev/kmem and echo > /dev/kmem will lead panic
Writing to /dev/kmem without being extremely careful is a disaster AFAIK
and even reading from the file can lead to unexpected results. Anyway
I am trying to understand what exactly you are trying to fix here. Why
writing to/reading from zero pfn should be any special wrt. any other
potentially dangerous addresses
cat /dev/mem not panic. cat /dev/kmem, just the user's operation for
nothing.
Signed-off-by: chenjie
---
drivers/char/mem.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 71025c2..4bdde28 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -412,6 +412,8 @@ static ssize_t read_kmem(struct file *file, char __user
*buf,
* by the kernel or data corruption may occur
*/
kbuf = xlate_dev_kmem_ptr((void *)p);
+ if (!kbuf)
+ return -EFAULT;
if (copy_to_user(buf, kbuf, sz))
return -EFAULT;
@@ -482,6 +484,11 @@ static ssize_t do_write_kmem(unsigned long p, const char
__user *buf,
* corruption may occur.
*/
ptr = xlate_dev_kmem_ptr((void *)p);
+ if (!ptr) {
+ if (written)
+ break;
+ return -EFAULT;
+ }
copied = copy_from_user(ptr, buf, sz);
if (copied) {
--
1.8.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org";> em...@kvack.org
[RFC] kref: pin objects with dangerously high reference count
Reference counting is a frequent source of (security) trouble in the
kernel. Here are the three main things that can, as far as I know, go wrong
with it, together with examples of specific bugs:
- reference count overdecrement: If something (e.g. a normally-unused
error path) decrements a reference counter more than it was previously
incremented, this can cause the reference counter to end up lower than
it was before. This will cause the object to be freed before the last
reference to the object is gone.
This bug class is hard to mitigate - it isn't very different from a
generic use-after-free.
Vulnerability examples:
commit 8358b02bf67d ("bpf: fix double-fdput [...]")
Bug examples where I haven't looked at impact:
commit 75f0b68b75da ("debugfs: [...]: avoid double fops release")
commit 121323ae668e ("drivers/perf: [...]: Fix reference count[...]")
- reference count overincrement: If an error path omits a necessary
reference count decrement, this can cause the reference counter to end
up higher than it was before even though no new reference to the object
was created. If such a bug is triggered around 2^32 times, the (32 bits
wide) reference counter overflows to a small value. After dropping a
few references so that exactly 2^32 references remain, the object will
be freed prematurely.
This kind of bug can easily occur when mistakes are made while writing
error handling code.
Vulnerability examples:
commit 23567fd052a9 ("KEYS: Fix keyring ref leak [...]")
Bug examples where I haven't looked at impact:
commit b10e3e90485e ("debugfs: [...]: free proxy on ->open() failure")
commit 3ea411c56ef5 ("android: fix reference leak in [...]")
commit 8ed9e0e1b602 ("Input: turbografx - fix reference counting")
- simple reference count overflow: If there are over 2^32 legitimate
references to an object, a 32-bit reference counter can overflow. Since
this can't happen on 32-bit architectures and normal references require
at least a pointer, the minimum amount of physical memory required to
hit this bug class is sizeof(void*) * 2^32 = 32 GiB ~= 34.36 GB.
One example of a reference count overflow that could be triggered in
some uncommon configurations on systems with 40GB of RAM is
commit 92117d8443bc ("bpf: fix refcnt overflow").
The nasty thing about this bug class is that it doesn't require a "real"
reference counting bug, and with increasing amounts of physical memory,
the number of reachable instances of this issue increases. (Probably not
at 64GB or so; but it might get dangerous around 1TB or so.)
This patch is a first step towards addressing overincrements and simple
overflows, but not overdecrements.
My concerns when choosing an appropriate fix implementation are:
- memory usage: An easy fix would be to increase the size of refcounts to
64 bits. However, that would both increase memory usage and mess with
data structures that have been designed carefully to e.g. fit into a
single cacheline.
(Note: Because file descriptor tables can contain lots of struct file
pointers and are relatively dense, struct file already has a 64-bit
refcount.)
- CPU usage: Refcounting is a central, relatively hot piece of kernel
code, so a fix must not use a lot of CPU time. In particular, additional
or less deterministic atomic operations should be avoided.
- complexity: A fix shouldn't involve significant changes in arch-specific
code.
- crashiness: While these kinds of bugs currently cause (potentially
exploitable) crashes and oopsing would be a big improvement over that,
ideally the system should just keep going without killing anything.
- impact on non-refcounting code: atomic_t is a generic atomic type, and
while a lot of code uses it for reference counting, it also has other
users for whom reference count hardening might mess up things.
Since 2009 or so, PaX had reference count overflow mitigation code. My main
reasons for reinventing the wheel are:
- PaX adds arch-specific code, both in the atomic_t operations and in
exception handlers. I'd like to keep the code as
architecture-independent as possible, especially without adding
complexity to assembler code, to make it more maintainable and
auditable.
- The refcounting hardening from PaX does not handle the "simple reference
count overflow" case when just the refcounting hardening code is used as
a standalone patch. (On a system with the full PaX patch, the active
response code would probably prevent exploitation of this case.)
I think that the biggest disadvantages of my code are:
- It increases the size of the inline code for kref_get_unless_zero() and,
if CONFIG_HARDEN_KREF_BIGMEM is enabled, of kref_sub(). (Also of
kref_put_mutex(), but that method isn't used often.)
- If CONFIG_HARDEN_KREF_BIGMEM is enabled, its kref_sub() implementation
always has to do an additional
[RFC] reference count hardening via kref: another attempt
I would like to harden the kernel against reference count overflow bugs. The commit message of the patch contains a short analysis of code size impact, an explanation why I want reference count hardening to land in the kernel, and a description of the algorithm I'd want to use. The reason I'm writing a cover letter is that my patch, on its own, is pretty useless: My patch only adds hardening to struct kref, but nearly all reference counters are currently implemented using atomic_t, which is a generic atomic number type. For the patch to be useful, I'll have to go through the kernel and, for every atomic_t, decide whether it is a reference count and, if so, change it (together with all accesses to it) to a kref. According to a quick grep, there are currently about 2700 atomic_t struct members or variables in the kernel, so it's going to be a big amount of work, and the resulting patches will be gigantic. Therefore, before I actually spend lots of time on this, I'd like to know: - Does the reference count hardening in my patch look okay, and does it have good chances to get accepted when submitted for inclusion in the kernel at a later point in time? - If I manually go through the kernel and write a gigantic atomic_t -> struct kref patch (or a few patches coarsely grouped by subsystem), how high is the probability that it will get accepted? (Note: I won't have much time for kernel work in the next four months or so - but afterwards, I could probably allocate time for getting this done.) Jann Horn (1): kref: pin objects with dangerously high reference count include/linux/kref.h | 39 +-- init/Kconfig | 16 kernel/Makefile | 2 +- kernel/kref.c| 17 + 4 files changed, 67 insertions(+), 7 deletions(-) create mode 100644 kernel/kref.c -- 2.8.0.rc3.226.g39d4020
Re: [linux-sunxi] Re: [PATCH 01/14] ARM: dts: sun8i: Add SID node
Hi,
On Sat, Jun 25, 2016 at 3:58 AM, Ondřej Jirman wrote:
> Hello,
>
> thank you for the review.
>
> On 24.6.2016 04:41, Chen-Yu Tsai wrote:
>> On Fri, Jun 24, 2016 at 3:20 AM, wrote:
>>> From: Josef Gajdusek
>>>
>>> Add a node describing the Security ID memory to the Allwinner H3 .dtsi file.
>>>
>>> Signed-off-by: Josef Gajdusek
>>> ---
>>> arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 4a4926b..172576d 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -389,6 +389,13 @@
>>> #size-cells = <0>;
>>> };
>>>
>>> + sid: eeprom@01c14000 {
>>> + compatible = "allwinner,sun4i-a10-sid";
>>
>> This has been discussed before. The hardware is not compatible.
>> The write control registers are at different offsets.
>
> I'm not sure what you mean by write control registers. Code in
> sunxi_sid.c implements only read access to the nvram. Can you pelase
> elaborate?
See
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/388022.html
Also, different compatibles are used for different hardware, regardless
of how close the drivers may be. The driver might only be compatible when
implementing a subset of the possible features. If one were to fully
implement it, they would become incompatible.
To put it another way, the compatible string designates the hardware,
and the driver implements support for that compatible string.
ChenYu
> Ondrej
>
>>
>> ChenYu
>>
>>> + reg = <0x01c14000 0x400>;
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + };
>>> +
>>> usbphy: phy@01c19400 {
>>> compatible = "allwinner,sun8i-h3-usb-phy";
>>> reg = <0x01c19400 0x2c>,
>>> --
>>> 2.9.0
>>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Re: [RESEND PATCH v2 1/2] power/cpuidle: enhance the precision of state select
On Fri, Jun 17, 2016 at 11:13 AM, Zhaoyang Huang
wrote:
> In previous version, cpu_pm_enter is invoked
By whom? Not by the core surely?
> after the governor select the state, which cause the executing time of
> cpu_pm_enter
> is included in the idle time. Moving it before the state selection.
>
> Signed-off-by: Zhaoyang Huang
> ---
> kernel/sched/idle.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index bd12c6c..929da2e 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -130,6 +131,7 @@ static void cpuidle_idle_call(void)
> struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
> struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
> int next_state, entered_state;
> + int ret;
>
> /*
> * Check if the idle task must be rescheduled. If it is the
> @@ -174,12 +176,16 @@ static void cpuidle_idle_call(void)
> /*
> * Ask the cpuidle framework to choose a convenient idle
> state.
> */
> - next_state = cpuidle_select(drv, dev);
> - entered_state = call_cpuidle(drv, dev, next_state);
> - /*
> -* Give the governor an opportunity to reflect on the outcome
> -*/
> - cpuidle_reflect(dev, entered_state);
> + ret = cpu_pm_enter();
"To move" usually means "take it away from there and put it here" as
far as kernel patches are concerned, but I only see it added here.
> + if (!ret) {
> + next_state = cpuidle_select(drv, dev);
> + entered_state = call_cpuidle(drv, dev, next_state);
> + cpu_pm_exit();
> + /*
> +* Give the governor an opportunity to reflect on the
> outcome
> +*/
> + cpuidle_reflect(dev, entered_state);
> + }
> }
>
> exit_idle:
> --
No way I will agree to add that notification stuff to the core.
Thanks,
Rafael
Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi
On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman wrote:
> Hello,
>
> comments below.
>
> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>> On Fri, Jun 24, 2016 at 3:20 AM, wrote:
>>> From: Ondrej Jirman
>>>
>>> Add label to the first cpu so that it can be referenced
>>> from derived dts files.
>>>
>>> Signed-off-by: Ondrej Jirman
>>> ---
>>> arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 9938972..82faefc 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -52,7 +52,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> - cpu@0 {
>>> + cpu0: cpu@0 {
>>> compatible = "arm,cortex-a7";
>>> device_type = "cpu";
>>> reg = <0>;
>>
>> Can you also set the cpu clock here? It is part of the SoC
>> and does not belong in the board DTS files.
>
> Do you mean operating-points, or something else? Different SBCs will
> probably require different combinations of operating points just for
> safety's sake, because they have different regulators and [some have
> botched] thermal designs, so it might make sense to customize it for
> differnt boards, and I don't feel adventurous enough setting it for all
> H3 boards out there.
I meant clocks = <...> and clock-latency = <...>.
These 2 are part of the SoC.
The OPP can stay in the board files. It's a pity there's no standard
OPP table for H3 though. :(
ChenYu
>
> Or is this comment related to the missing cpu clock rate message I see
> on every boot?
>
> [0.058912] /cpus/cpu@0 missing clock-frequency property
>
> regards,
> Ondrej
>
>> Otherwise this one looks good.
>>
>> ChenYu
>>
>>> --
>>> 2.9.0
>>>
>
Re: [PATCH 07/14] regulator: SY8106A regulator driver
On Sat, Jun 25, 2016 at 8:11 AM, Ondřej Jirman wrote:
> Hi,
>
> thank you for the review. I've resolved most of the issues. Some more
> comments below.
>
> On 24.6.2016 05:41, Chen-Yu Tsai wrote:
>> On Fri, Jun 24, 2016 at 3:20 AM, wrote:
>>> From: Ondrej Jirman
>>>
>>> SY8106A is I2C attached single output voltage regulator
>>> made by Silergy.
>>>
>>> Signed-off-by: Ondrej Jirman
>>> ---
>>> drivers/regulator/Kconfig | 8 +-
>>> drivers/regulator/Makefile| 2 +-
>>> drivers/regulator/sy8106a-regulator.c | 153
>>> ++
>>> 3 files changed, 161 insertions(+), 2 deletions(-)
>>> create mode 100644 drivers/regulator/sy8106a-regulator.c
>>>
>>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>>> index 144cbf5..fc3fae2 100644
>>> --- a/drivers/regulator/Kconfig
>>> +++ b/drivers/regulator/Kconfig
>>> @@ -860,5 +860,11 @@ config REGULATOR_WM8994
>>> This driver provides support for the voltage regulators on the
>>> WM8994 CODEC.
>>>
>>> -endif
>>> +config REGULATOR_SY8106A
>>> + tristate "Silergy SY8106A"
>>> + depends on I2C
>>
>> Maybe you should also depend on OF since the driver is going to crippled
>> without any constraints set, or (OF || COMPILE_TEST) if you want some
>> compile test coverage.
>>
>>> + select REGMAP_I2C
>>> + help
>>> + This driver provides support for the voltage regulator SY8106A.
>>>
>>> +endif
>>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>>> index 85a1d44..f382095 100644
>>> --- a/drivers/regulator/Makefile
>>> +++ b/drivers/regulator/Makefile
>>> @@ -110,6 +110,6 @@ obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o
>>> obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
>>> obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>>> obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>>> -
>>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
>>
>> Follow the existing ordering in the Makefile.
>>
>>>
>>> ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>>> diff --git a/drivers/regulator/sy8106a-regulator.c
>>> b/drivers/regulator/sy8106a-regulator.c
>>> new file mode 100644
>>> index 000..34bd69c
>>> --- /dev/null
>>> +++ b/drivers/regulator/sy8106a-regulator.c
>>> @@ -0,0 +1,153 @@
>>> +/*
>>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>>> + *
>>> + * Copyright (C) 2016 Ondřej Jirman
>>> + *
>>> + * This library is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Library General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2 of the License, or (at your option) any later version.
>>> + *
>>> + * This library is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * Library General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Library General Public
>>> + * License along with this library; if not, write to the
>>> + * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
>>> + * Boston, MA 02110-1301, USA.
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>
>> Do you need this one?
>>
>>> +#include
>>> +#include
>>
>> And this one?
>>
>>> +#include
>>> +#include
>>
>> Sort alphabetically please.
>>
>>> +
>>> +#define SY8106A_REG_VOUT1_SEL 0x01
>>> +#define SY8106A_REG_VOUT_COM 0x02
>>> +#define SY8106A_REG_VOUT1_SEL_MASK 0x7f
>>> +#define SY8106A_DISABLE_REG0x01
>>
>> BIT(0) would be clearer.
>>
>>> +
>>> +struct sy8106a {
>>> + struct regulator_dev *rdev;
>>> + struct regmap *regmap;
>>> +};
>>> +
>>> +static const struct regmap_config sy8106a_regmap_config = {
>>> + .reg_bits = 8,
>>> + .val_bits = 8,
>>> +};
>>> +
>>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned
>>> sel)
>>> +{
>>> + return regmap_update_bits(rdev->regmap, rdev->desc->vsel_reg,
>>> + 0xff, sel | 0x80);
>>
>> Can you use .apply_bit / .apply_reg with regulator_set_voltage_sel_regmap?
>
> I understand the code savings, but I'd rather avoid that, because it
> would involve 2 needless readouts and rewrites of the voltage setting
> register. I'd rather change this to regmap_write, so that the regulator
> only receives writes over I2C, to minimize possibility of bit flip error
> by minimizing the communication over the I2C bus.
OK. It's best to add a comment then, in case someone comes in and refactors it.
>
>>> +}
>>> +
>>> +static const struct regulator_ops sy8106a_ops = {
>>> + .is_enabled = regulator_is_enabled_regmap,
>>> + .set_voltage_sel = sy8106a_set_voltage_sel,
>>> + .set_voltage_time_sel = regulator_set_voltage_time_sel,
>>> + .get_voltage_sel = regulator_g
Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3
On 25.6.2016 02:54, Chen-Yu Tsai wrote:
> On Sat, Jun 25, 2016 at 8:35 AM, Ondřej Jirman wrote:
>> On 24.6.2016 05:09, Chen-Yu Tsai wrote:
+static int sun8i_ths_h3_init(struct platform_device *pdev,
+struct sun8i_ths_data *data)
+{
+ int ret;
+ size_t callen;
+ s32 *caldata;
+
+ data->busclk = devm_clk_get(&pdev->dev, "ahb");
+ if (IS_ERR(data->busclk)) {
+ ret = PTR_ERR(data->busclk);
+ dev_err(&pdev->dev, "failed to get ahb clk: %d\n", ret);
+ return ret;
+ }
+
+ data->clk = devm_clk_get(&pdev->dev, "ths");
+ if (IS_ERR(data->clk)) {
+ ret = PTR_ERR(data->clk);
+ dev_err(&pdev->dev, "failed to get ths clk: %d\n", ret);
+ return ret;
+ }
+
+ data->reset = devm_reset_control_get(&pdev->dev, "ahb");
>>>
>>> IIRC with the new shared reset control stuff merged, you are supposed
>>> to specify whether you want a shared or exclusive one when you ask for
>>> it.
>>
>> Here devm_reset_control_get will get the exclusive reference. So this
>> should be ok.
>
> See https://patchwork.kernel.org/patch/9158691/
>
> The generic ones might be removed later on. I remember in another thread
> it was asked that new users should use the explicit API, and avoid having
> to be converted.
I see, thank you, I'll change that.
regards,
Ondrej
> ChenYu
>
>>
>> regards,
>> Ondrej
>>
>>>
>>> Regards
>>> ChenYu
>>>
+MODULE_LICENSE("GPL v2");
--
2.9.0
>>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3
On Sat, Jun 25, 2016 at 8:35 AM, Ondřej Jirman wrote:
> On 24.6.2016 05:09, Chen-Yu Tsai wrote:
>>> +static int sun8i_ths_h3_init(struct platform_device *pdev,
>>> +struct sun8i_ths_data *data)
>>> +{
>>> + int ret;
>>> + size_t callen;
>>> + s32 *caldata;
>>> +
>>> + data->busclk = devm_clk_get(&pdev->dev, "ahb");
>>> + if (IS_ERR(data->busclk)) {
>>> + ret = PTR_ERR(data->busclk);
>>> + dev_err(&pdev->dev, "failed to get ahb clk: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + data->clk = devm_clk_get(&pdev->dev, "ths");
>>> + if (IS_ERR(data->clk)) {
>>> + ret = PTR_ERR(data->clk);
>>> + dev_err(&pdev->dev, "failed to get ths clk: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + data->reset = devm_reset_control_get(&pdev->dev, "ahb");
>>
>> IIRC with the new shared reset control stuff merged, you are supposed
>> to specify whether you want a shared or exclusive one when you ask for
>> it.
>
> Here devm_reset_control_get will get the exclusive reference. So this
> should be ok.
See https://patchwork.kernel.org/patch/9158691/
The generic ones might be removed later on. I remember in another thread
it was asked that new users should use the explicit API, and avoid having
to be converted.
ChenYu
>
> regards,
> Ondrej
>
>>
>> Regards
>> ChenYu
>>
>>> +MODULE_LICENSE("GPL v2");
>>> --
>>> 2.9.0
>>>
>
Re: [PATCH v3] Input: synaptics-rmi4: Support regulator supplies
On 06/10/2016 10:25 PM, Bjorn Andersson wrote:
From: Bjorn Andersson
Support the two supplies - vdd and vio - to make it possible to control
power to the Synaptics chip.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Reviewed-by: Andrew Duggan
---
.../devicetree/bindings/input/rmi4/rmi_i2c.txt | 9 +
drivers/input/rmi4/rmi_i2c.c | 41 ++
2 files changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
index 95fa715c6046..ec908b91fd90 100644
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
@@ -22,6 +22,15 @@ See
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- syna,reset-delay-ms: The number of milliseconds to wait after resetting the
device.
+- syna,startup-delay-ms: The number of milliseconds to wait after powering on
+the device.
+
+- vdd-supply: VDD power supply.
+See ../regulator/regulator.txt
+
+- vio-supply: VIO power supply
+See ../regulator/regulator.txt
+
Function Parameters:
Parameters specific to RMI functions are contained in child nodes of the rmi
device
node. Documentation for the parameters of each function can be found in:
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index a96a326b53bd..71dc6cdde8ac 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -11,6 +11,8 @@
#include
#include
#include
+#include
+#include
#include "rmi_driver.h"
#define BUFFER_SIZE_INCREMENT 32
@@ -37,6 +39,9 @@ struct rmi_i2c_xport {
u8 *tx_buf;
size_t tx_buf_size;
+
+ struct regulator_bulk_data supplies[2];
+ u32 startup_delay;
};
#define RMI_PAGE_SELECT_REGISTER 0xff
@@ -246,6 +251,24 @@ static int rmi_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
+ rmi_i2c->supplies[0].supply = "vdd";
+ rmi_i2c->supplies[1].supply = "vio";
+ retval = devm_regulator_bulk_get(&client->dev,
+ARRAY_SIZE(rmi_i2c->supplies),
+rmi_i2c->supplies);
+ if (retval < 0)
+ return retval;
+
+ retval = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies),
+ rmi_i2c->supplies);
+ if (retval < 0)
+ return retval;
+
+ of_property_read_u32(client->dev.of_node, "syna,startup-delay-ms",
+&rmi_i2c->startup_delay);
+
+ msleep(rmi_i2c->startup_delay);
+
rmi_i2c->client = client;
mutex_init(&rmi_i2c->page_mutex);
@@ -286,6 +309,7 @@ static int rmi_i2c_remove(struct i2c_client *client)
struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
rmi_unregister_transport_device(&rmi_i2c->xport);
+ regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies),
rmi_i2c->supplies);
return 0;
}
@@ -308,6 +332,9 @@ static int rmi_i2c_suspend(struct device *dev)
dev_warn(dev, "Failed to enable irq for wake: %d\n",
ret);
}
+
+ regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies),
rmi_i2c->supplies);
+
return ret;
}
@@ -317,6 +344,12 @@ static int rmi_i2c_resume(struct device *dev)
struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
int ret;
+ ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies), rmi_i2c->supplies);
+ if (ret)
+ return ret;
+
+ msleep(rmi_i2c->startup_delay);
+
enable_irq(rmi_i2c->irq);
if (device_may_wakeup(&client->dev)) {
ret = disable_irq_wake(rmi_i2c->irq);
@@ -346,6 +379,8 @@ static int rmi_i2c_runtime_suspend(struct device *dev)
disable_irq(rmi_i2c->irq);
+ regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies), rmi_i2c->supplies);
+
return 0;
}
@@ -355,6 +390,12 @@ static int rmi_i2c_runtime_resume(struct device *dev)
struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
int ret;
+ ret = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies), rmi_i2c->supplies);
+ if (ret)
+ return ret;
+
+ msleep(rmi_i2c->startup_delay);
+
enable_irq(rmi_i2c->irq);
ret = rmi_driver_resume(rmi_i2c->xport.rmi_dev);
Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3
On 24.6.2016 05:09, Chen-Yu Tsai wrote:
>> +static int sun8i_ths_h3_init(struct platform_device *pdev,
>> +struct sun8i_ths_data *data)
>> +{
>> + int ret;
>> + size_t callen;
>> + s32 *caldata;
>> +
>> + data->busclk = devm_clk_get(&pdev->dev, "ahb");
>> + if (IS_ERR(data->busclk)) {
>> + ret = PTR_ERR(data->busclk);
>> + dev_err(&pdev->dev, "failed to get ahb clk: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + data->clk = devm_clk_get(&pdev->dev, "ths");
>> + if (IS_ERR(data->clk)) {
>> + ret = PTR_ERR(data->clk);
>> + dev_err(&pdev->dev, "failed to get ths clk: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + data->reset = devm_reset_control_get(&pdev->dev, "ahb");
>
> IIRC with the new shared reset control stuff merged, you are supposed
> to specify whether you want a shared or exclusive one when you ask for
> it.
Here devm_reset_control_get will get the exclusive reference. So this
should be ok.
regards,
Ondrej
>
> Regards
> ChenYu
>
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.9.0
>>
signature.asc
Description: OpenPGP digital signature
[perf core] c5dfd78eb7: BUG: unable to handle kernel NULL pointer dereference at 00000c40
extra tests on HEAD of linux-devel/devel-hourly-2016062414
git bisect bad e8d665056895dafedd7882bfe250ff6cf7dfbc0d # 08:10 0-
53 0day head guard for 'devel-hourly-2016062414'
# extra tests on tree/branch linus/master
git bisect bad 63c04ee7d3b7c8d8e2726cb7c5f8a5f6fcc1e3b2 # 08:22 0-
3 Merge tag 'upstream-4.7-rc5' of git://git.infradead.org/linux-ubifs
# extra tests on tree/branch linus/master
git bisect bad 63c04ee7d3b7c8d8e2726cb7c5f8a5f6fcc1e3b2 # 08:23 0-
5 Merge tag 'upstream-4.7-rc5' of git://git.infradead.org/linux-ubifs
# extra tests on tree/branch linux-next/master
git bisect bad 2cf991dfda8b36d2878c249bcdf492366ec24c19 # 08:29 14-
1 Add linux-next specific files for 20160624
This script may reproduce the error.
#!/bin/bash
kernel=$1
initrd=quantal-core-i386.cgz
wget --no-clobber
https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
kvm=(
qemu-system-x86_64
-enable-kvm
-cpu kvm64
-kernel $kernel
-initrd $initrd
-m 300
-smp 2
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null
)
append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
systemd.log_level=err
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)
"${kvm[@]}" --append "${append[*]}"
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
dmesg-quantal-kbuild-53:20160625075710:i386-randconfig-h0-06242012:4.6.0-rc4-00181-gc5dfd78:1.gz
Description: application/gzip
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.6.0-rc4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CO
Re: [PATCH v2 14/15] clk: sunxi-ng: Add H3 clocks
Hi Maxime,
Nice series! Looks really great to me. :-)
Quoting Maxime Ripard (2016-06-07 13:41:53)
> +static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpux_clk, "pll-cpux",
> +"osc24M", 0x000,
> +8, 5, /* N */
> +4, 2, /* K */
> +0, 2, /* M */
> +16, 2, /* P */
> +BIT(31), /* gate */
> +BIT(28), /* lock */
> +0);
I'm more of a fan of expanding the struct with designated initializers
versus macro use, but that's only personal preference.
> +static const char * const ahb2_parents[] = { "ahb1" , "pll-periph0" };
> +static struct ccu_mux ahb2_clk = {
> + .mux= {
> + .shift = 0,
> + .width = 1,
> +
> + .fixed_prediv = {
> + .index = 1,
> + .div= 2,
> + },
> + },
> +
> + .common = {
> + .reg= 0x05c,
> + .features = CCU_FEATURE_FIXED_PREDIV,
> + .hw.init= SUNXI_HW_INIT_PARENTS("ahb2",
> + ahb2_parents,
Note that it's possible to initialize the parent strings here if you
prefer:
.hw.init = &(struct clk_init_data){
.parent_names = (const char *[]){ "ahb1",
"pll-periph0" };
Similar to the above, no big deal, just an observation.
> +static struct ccu_common *sun8i_h3_ccu_clks[] = {
> + [CLK_PLL_CPUX] = &pll_cpux_clk.common,
> + [CLK_PLL_AUDIO_BASE]= &pll_audio_base_clk.common,
> + [CLK_PLL_AUDIO] = &pll_audio_clk.common,
OK, it looks like you followed the qcom clk driver approach here, which
is a nice way to do things. However, as Stephen alluded to in his
response to the cover letter, the clk_hw_* api's are an even more
friendly interface for clock providers. For example, check out the gxbb
clk driver probe:
static int gxbb_clkc_probe(struct platform_device *pdev)
{
void __iomem *clk_base;
int ret, clkid, i;
struct device *dev = &pdev->dev;
/* Generic clocks and PLLs */
clk_base = of_iomap(dev->of_node, 0);
if (!clk_base) {
pr_err("%s: Unable to map clk base\n", __func__);
return -ENXIO;
}
/* Populate base address for PLLs */
for (i = 0; i < ARRAY_SIZE(gxbb_clk_plls); i++)
gxbb_clk_plls[i]->base = clk_base;
/* Populate base address for MPLLs */
for (i = 0; i < ARRAY_SIZE(gxbb_clk_mplls); i++)
gxbb_clk_mplls[i]->base = clk_base;
...
/*
* register all clks
*/
for (clkid = 0; clkid < NR_CLKS; clkid++) {
ret = devm_clk_hw_register(dev,
gxbb_hw_onecell_data.hws[clkid]);
if (ret)
goto iounmap;
}
The nice thing about struct ccu_common is that you don't have to walk
the list of clocks for each separate clock type like the above probe
function does. I'm still thinking of the best way to solve this
generically. Maybe add a .base member struct clk_hw? I dunno, and I've
resisted the urge to add stuff to struct clk_hw in the past... But I
really want to minimize this .probe as much as possible, and I do not
want every clock provider driver to be forced to invent something like
struct ccu_common every time. Anyways, that is not a blocker for your
implementation to be merged, but Stephen's question in patch #4 got me
thinking about this again...
The real nice part is the call to devm_clk_hw_register. That uses the
new clk_hw_* apis and struct clk_hw_onecell_data, which is initialized
statically like so:
static struct clk_hw_onecell_data gxbb_hw_onecell_data = {
.hws = {
[CLKID_SYS_PLL] = &gxbb_sys_pll.hw,
[CLKID_CPUCLK]= &gxbb_cpu_clk.hw,
...
},
.num = NR_CLKS,
};
Unfortunately I believe it impossible to replace NR_CLKS with some
ARRAY_SIZE stuff because C. As Stephen mentioned, please use this method
instead.
> diff --git a/include/dt-bindings/clock/sun8i-h3.h
> b/include/dt-bindings/clock/sun8i-h3.h
> new file mode 100644
> index ..96eced56e7a2
> --- /dev/null
> +++ b/include/dt-bindings/clock/sun8i-h3.h
> @@ -0,0 +1,162 @@
> +#ifndef _DT_BINDINGS_CLK_SUN8I_H3_H_
> +#define _DT_BINDINGS_CLK_
[PATCH v2 1/2] namespaces: don't use from_k*id_munged() with init_user_ns
For init_user_ns, from_kuid_munged() and from_kgid_munged() are
guaranteed to be identical to from_kuid() and from_kgid(). In
preparation for another patch, change all usages of the _munged
variants that explicitly use init_user_ns to the non-munged ones.
This patch by itself should not have any effect.
Signed-off-by: Jann Horn
---
arch/s390/hypfs/inode.c | 4 ++--
arch/x86/kernel/vm86_32.c | 2 +-
drivers/connector/cn_proc.c | 8
fs/adfs/super.c | 4 ++--
fs/autofs4/inode.c | 4 ++--
fs/cifs/cifs_spnego.c | 4 ++--
fs/cifs/cifsfs.c| 8
fs/debugfs/inode.c | 4 ++--
fs/devpts/inode.c | 4 ++--
fs/ext2/super.c | 4 ++--
fs/ext4/super.c | 4 ++--
fs/fat/inode.c | 4 ++--
fs/fuse/dev.c | 4 ++--
fs/fuse/inode.c | 4 ++--
fs/hfs/super.c | 4 ++--
fs/hfsplus/options.c| 4 ++--
fs/hpfs/super.c | 4 ++--
fs/ncpfs/inode.c| 6 +++---
fs/ntfs/inode.c | 4 ++--
fs/proc/inode.c | 2 +-
fs/quota/netlink.c | 2 +-
fs/tracefs/inode.c | 4 ++--
kernel/cred.c | 16
mm/shmem.c | 4 ++--
net/netfilter/nf_log_common.c | 4 ++--
net/netfilter/nfnetlink_queue.c | 4 ++--
net/netfilter/nft_meta.c| 4 ++--
27 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/arch/s390/hypfs/inode.c b/arch/s390/hypfs/inode.c
index 255c7ee..df0e2f3 100644
--- a/arch/s390/hypfs/inode.c
+++ b/arch/s390/hypfs/inode.c
@@ -259,8 +259,8 @@ static int hypfs_show_options(struct seq_file *s, struct
dentry *root)
{
struct hypfs_sb_info *hypfs_info = root->d_sb->s_fs_info;
- seq_printf(s, ",uid=%u", from_kuid_munged(&init_user_ns,
hypfs_info->uid));
- seq_printf(s, ",gid=%u", from_kgid_munged(&init_user_ns,
hypfs_info->gid));
+ seq_printf(s, ",uid=%u", from_kuid(&init_user_ns, hypfs_info->uid));
+ seq_printf(s, ",gid=%u", from_kgid(&init_user_ns, hypfs_info->gid));
return 0;
}
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index 3dce1ca..23d8541 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -259,7 +259,7 @@ static long do_sys_vm86(struct vm86plus_struct __user
*user_vm86, bool plus)
*/
pr_info_once("Denied a call to vm86(old) from %s[%d] (uid: %d).
Set the vm.mmap_min_addr sysctl to 0 and/or adjust LSM mmap_min_addr policy to
enable vm86 if you are using a vm86-based DOS emulator.\n",
current->comm, task_pid_nr(current),
-from_kuid_munged(&init_user_ns, current_uid()));
+from_kuid(&init_user_ns, current_uid()));
return -EPERM;
}
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 15d06fc..89c3b6f 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -140,11 +140,11 @@ void proc_id_connector(struct task_struct *task, int
which_id)
rcu_read_lock();
cred = __task_cred(task);
if (which_id == PROC_EVENT_UID) {
- ev->event_data.id.r.ruid = from_kuid_munged(&init_user_ns,
cred->uid);
- ev->event_data.id.e.euid = from_kuid_munged(&init_user_ns,
cred->euid);
+ ev->event_data.id.r.ruid = from_kuid(&init_user_ns, cred->uid);
+ ev->event_data.id.e.euid = from_kuid(&init_user_ns, cred->euid);
} else if (which_id == PROC_EVENT_GID) {
- ev->event_data.id.r.rgid = from_kgid_munged(&init_user_ns,
cred->gid);
- ev->event_data.id.e.egid = from_kgid_munged(&init_user_ns,
cred->egid);
+ ev->event_data.id.r.rgid = from_kgid(&init_user_ns, cred->gid);
+ ev->event_data.id.e.egid = from_kgid(&init_user_ns, cred->egid);
} else {
rcu_read_unlock();
return;
diff --git a/fs/adfs/super.c b/fs/adfs/super.c
index c9fdfb1..48b9195 100644
--- a/fs/adfs/super.c
+++ b/fs/adfs/super.c
@@ -131,9 +131,9 @@ static int adfs_show_options(struct seq_file *seq, struct
dentry *root)
struct adfs_sb_info *asb = ADFS_SB(root->d_sb);
if (!uid_eq(asb->s_uid, GLOBAL_ROOT_UID))
- seq_printf(seq, ",uid=%u", from_kuid_munged(&init_user_ns,
asb->s_uid));
+ seq_printf(seq, ",uid=%u", from_kuid(&init_user_ns,
asb->s_uid));
if (!gid_eq(asb->s_gid, GLOBAL_ROOT_GID))
- seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns,
asb->s_gid));
+ seq_printf(seq, ",gid=%u", from_kgid(&init_user_ns,
asb->s_gid));
if (asb->s_owner_mask != ADFS_DEFAULT_OWNER_MASK)
seq_printf(seq, ",ownmask=%o", asb->s_owner_mask);
i
[PATCH v2 2/2] namespaces: add transparent user namespaces
This allows the admin of a user namespace to mark the namespace as transparent. All other namespaces, by default, are opaque. While the current behavior of user namespaces is appropriate for use in containers, there are many programs that only use user namespaces because doing so enables them to do other things (e.g. unsharing the mount or network namespace) that require namespaced capabilities. For them, the inability to see the real UIDs and GIDs of things from inside the user namespace can be very annoying. In a transparent namespace, all UIDs and GIDs that are mapped into its first opaque ancestor are visible and are not remapped. This means that if a process e.g. stat()s the real root directory in a namespace, it will still see it as owned by UID 0. Traditionally, any UID or GID that was visible in a user namespace was also mapped into the namespace, giving the namespace admin full access to it. This patch introduces a distinction: In a transparent namespace, UIDs and GIDs can be visible without being mapped. Non-mapped, visible UIDs can be passed from the kernel to userspace, but userspace can't send them back to the kernel. In order to be able to fully use specific UIDs/GIDs and gain privileges over them, mappings need to be set up in the usual way - however, to avoid aliasing problems, only identity mappings are permitted. v2: Ensure that all relevant from_k[ug]id callers show up in the patch. _transparent would be more verbose than _tp, but considering the line length rule, that's just too long. Yes, this makes the patch rather large. Behavior should be the same as in v1, except that I'm not touching orangefs in this patch because every single use of from_k[ug]id in it is wrong in some way. (Thanks for making me reread all that stuff, Eric.) I'll write a separate patch or at least report the issue with more detail later. (Also, the handling of user namespaces when dealing with signals is super-ugly and kind of incorrect. That should probably be cleaned up.) posix_acl_to_xattr would have changed behavior in the v1 patch, but isn't changed here. Because it's only used with init_user_ns, that won't change user-visible behavior relative to v1. This patch was compile-tested with allyesconfig. I also ran a VM with this patch applied and checked that it still works, but that probably doesn't mean much. Signed-off-by: Jann Horn --- arch/alpha/kernel/osf_sys.c | 4 +- arch/arm/kernel/sys_oabi-compat.c | 4 +- arch/ia64/kernel/signal.c | 4 +- arch/s390/kernel/compat_linux.c | 26 +++--- arch/sparc/kernel/sys_sparc32.c | 4 +- arch/x86/ia32/sys_ia32.c | 4 +- drivers/android/binder.c | 2 +- drivers/gpu/drm/drm_info.c| 2 +- drivers/gpu/drm/drm_ioctl.c | 2 +- drivers/net/tun.c | 4 +- fs/autofs4/dev-ioctl.c| 4 +- fs/autofs4/waitq.c| 4 +- fs/binfmt_elf.c | 12 +-- fs/binfmt_elf_fdpic.c | 12 +-- fs/compat.c | 4 +- fs/fcntl.c| 4 +- fs/ncpfs/ioctl.c | 12 +-- fs/posix_acl.c| 11 ++- fs/proc/array.c | 18 ++-- fs/proc/base.c| 30 +-- fs/quota/kqid.c | 12 ++- fs/stat.c | 12 +-- include/linux/uidgid.h| 24 +++-- include/linux/user_namespace.h| 4 + include/net/scm.h | 4 +- ipc/mqueue.c | 2 +- ipc/msg.c | 8 +- ipc/sem.c | 8 +- ipc/shm.c | 8 +- ipc/util.c| 8 +- kernel/acct.c | 4 +- kernel/exit.c | 6 +- kernel/groups.c | 2 +- kernel/signal.c | 16 ++-- kernel/sys.c | 24 ++--- kernel/trace/trace.c | 2 +- kernel/tsacct.c | 4 +- kernel/uid16.c| 22 ++--- kernel/user.c | 1 + kernel/user_namespace.c | 178 +++--- net/appletalk/atalk_proc.c| 2 +- net/ax25/ax25_uid.c | 4 +- net/bluetooth/af_bluetooth.c | 2 +- net/core/sock.c | 4 +- net/ipv4/inet_diag.c | 2 +- net/ipv4/ping.c | 2 +- net/ipv4/raw.c| 2 +- net/ipv4/sysctl_net_ipv4.c| 4 +- net/ipv4/tcp_ipv4.c | 6 +- net/ipv4/udp.c| 2 +- net/ipv6/datagram.c | 2 +- net/ipv6/ip6_flowlabel.c | 2 +- net/ipv6/tcp_ipv6.c | 6 +- net/ipx/ipx_proc.c| 2 +- net/key/af_key.c | 2 +- net/llc/llc_proc.c| 2 +- net/netfilter/nfnetlink_log.c | 4 +- net/packet/af_packet.c| 2 +-
Re: [PATCH 2/2] acpi: pmic: intel: initialize result to 0
On Wednesday, June 22, 2016 05:55:40 PM Heikki Krogerus wrote:
> From: Felipe Balbi
>
> Fixes compiler warning.
>
> Signed-off-by: Felipe Balbi
> Signed-off-by: Heikki Krogerus
> ---
> drivers/acpi/pmic/intel_pmic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
> index 3a3d416..1742718 100644
> --- a/drivers/acpi/pmic/intel_pmic.c
> +++ b/drivers/acpi/pmic/intel_pmic.c
> @@ -215,7 +215,7 @@ static acpi_status intel_pmic_regs_handler(u32 function,
> void *handler_context, void *region_context)
> {
> struct intel_pmic_opregion *opregion = region_context;
> - int result;
> + int result = 0;
>
> switch (address) {
> case 0:
Applied, thanks!
Re: [PATCH v6 0/5] ACPI / processor_idle: Add ACPI v6.0 LPI support
On Thursday, June 23, 2016 02:42:57 AM Rafael J. Wysocki wrote: > On Wednesday, June 22, 2016 06:45:15 PM Sudeep Holla wrote: > > Hi Rafael, > > > > On 14/06/16 15:48, Sudeep Holla wrote: > > > ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate > > > method to describe processor idle states. It extends the specification > > > to allow the expression of idle states like C-states selectable by the > > > OSPM when a processor goes idle, but may affect more than one processor, > > > and may affect other system components. > > > > > > LPI extensions leverages the processor container device(again introduced > > > in ACPI 6.0) allowing to express which parts of the system are affected > > > by a given LPI state. It defines the local power states for each node > > > in a hierarchical processor topology. The OSPM can use _LPI object to > > > select a local power state for each level of processor hierarchy in the > > > system. They used to produce a composite power state request that is > > > presented to the platform by the OSPM. > > > > > > Since multiple processors affect the idle state for any non-leaf hierarchy > > > node, coordination of idle state requests between the processors is > > > required. ACPI supports two different coordination schemes: Platform > > > coordinated and OS initiated. > > > > > > This series aims at providing basic and initial support for platform > > > coordinated LPI states. > > > > > > > Gentle ping, was hoping to target this series for v4.8 > > On my list of things to take care of this week. But this is a long list ... Well, there are comments from Lorenzo and Daniel that need addressing, so can you please do that and resend? Thanks, Rafael
[PATCH v3] HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4
The Synaptics RMI4 driver provides support for RMI4 devices. Instead of
duplicating the RMI4 processing code, make hid-rmi a transport driver
and register it with the Synaptics RMI4 core.
Signed-off-by: Andrew Duggan
---
In v3 I went ahead and added RMI4_F12 to the Kconfig so we will have it
ready for Precision Touchpad. I also added documentation for xport in
rmi_data.
Also, after thinking about this a bit more I think it makes sense to
enable dribble by default. With dribble disable the device reports
a single lift event. If that report gets dropped for some reason then
that will result in stuck contacts. The downside of dribble packets is that
it increases the amount of interrupts. But, this increase is really not
significant to overall performace. I also don't think it is worth trying
to identify platforms which have issues with dropped reports so that we
can set quirks or maintain a device list to enable dribble only on those
devices.
Andrew
drivers/hid/Kconfig | 4 +
drivers/hid/hid-rmi.c | 963 --
2 files changed, 142 insertions(+), 825 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 4117225..336b79d 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -747,6 +747,10 @@ config HID_SUNPLUS
config HID_RMI
tristate "Synaptics RMI4 device support"
depends on HID
+ select RMI4_CORE
+ select RMI4_F11
+ select RMI4_F12
+ select RMI4_F30
---help---
Support for Synaptics RMI4 touchpads.
Say Y here if you have a Synaptics RMI4 touchpads over i2c-hid or usbhid
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 9cd2ca3..d2739db 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -19,6 +19,8 @@
#include
#include
#include
+#include
+#include
#include "hid-ids.h"
#define RMI_MOUSE_REPORT_ID0x01 /* Mouse emulation Report */
@@ -33,9 +35,6 @@
#define RMI_READ_DATA_PENDING 1
#define RMI_STARTED2
-#define RMI_SLEEP_NORMAL 0x0
-#define RMI_SLEEP_DEEP_SLEEP 0x1
-
/* device flags */
#define RMI_DEVICE BIT(0)
#define RMI_DEVICE_HAS_PHYS_BUTTONSBIT(1)
@@ -54,18 +53,10 @@ enum rmi_mode_type {
RMI_MODE_NO_PACKED_ATTN_REPORTS = 2,
};
-struct rmi_function {
- unsigned page; /* page of the function */
- u16 query_base_addr;/* base address for queries */
- u16 command_base_addr; /* base address for commands */
- u16 control_base_addr; /* base address for controls */
- u16 data_base_addr; /* base address for datas */
- unsigned int interrupt_base;/* cross-function interrupt number
-* (uniq in the device)*/
- unsigned int interrupt_count; /* number of interrupts */
- unsigned int report_size; /* size of a report */
- unsigned long irq_mask; /* mask of the interrupts
-* (to be applied against ATTN IRQ) */
+/* Structure for storing attn report plus size of valid data in the kfifo */
+struct rmi_attn_report {
+ int size;
+ u8 data[];
};
/**
@@ -73,6 +64,7 @@ struct rmi_function {
*
* @page_mutex: Locks current page to avoid changing pages in unexpected ways.
* @page: Keeps track of the current virtual page
+ * @xport: transport device to be registered with the RMI4 core.
*
* @wait: Used for waiting for read data
*
@@ -84,26 +76,22 @@ struct rmi_function {
*
* @flags: flags for the current device (started, reading, etc...)
*
- * @f11: placeholder of internal RMI function F11 description
- * @f30: placeholder of internal RMI function F30 description
- *
- * @max_fingers: maximum finger count reported by the device
- * @max_x: maximum x value reported by the device
- * @max_y: maximum y value reported by the device
- *
- * @gpio_led_count: count of GPIOs + LEDs reported by F30
- * @button_count: actual physical buttons count
- * @button_mask: button mask used to decode GPIO ATTN reports
- * @button_state_mask: pull state of the buttons
- *
- * @input: pointer to the kernel input device
- *
* @reset_work: worker which will be called in case of a mouse report
+ * @attn_work: worker used for processing attention reports
* @hdev: pointer to the struct hid_device
+ *
+ * @device_flags: flags which describe the device
+ *
+ * @attn_report_fifo: Store attn reports for deferred processing by worker
+ * @attn_report_size: size of an input report plus the size int
+ * @attn_report: buffer for storing the attn report while it is being processes
+ * @in_attn_report: buffer for storing input report plus size before adding it
+ * to the fifo.
*/
struct rmi_data {
struct mutex page_mutex;
int page;
+ struct rmi_transport_dev xport;
wait_queue_head_t wait;
@@ -115,34 +1
[PATCH v2 8/8] Input: synaptics-rmi4: Use the RMI_F11_REL_BYTES define in rmi_f11_rel_pos_report
The size of relative data in F11 is already defined by RMI_F11_REL_BYTES. Use the define in rmi_f11_rel_pos_report() to be consistent. Signed-off-by: Andrew Duggan --- drivers/input/rmi4/rmi_f11.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c index 3fda75b..cce82a1 100644 --- a/drivers/input/rmi4/rmi_f11.c +++ b/drivers/input/rmi4/rmi_f11.c @@ -530,8 +530,8 @@ static void rmi_f11_rel_pos_report(struct f11_data *f11, u8 n_finger) struct f11_2d_data *data = &f11->data; s8 x, y; - x = data->rel_pos[n_finger * 2]; - y = data->rel_pos[n_finger * 2 + 1]; + x = data->rel_pos[n_finger * RMI_F11_REL_BYTES]; + y = data->rel_pos[n_finger * RMI_F11_REL_BYTES + 1]; rmi_2d_sensor_rel_report(sensor, x, y); } -- 2.5.0
[PATCH v2 7/8] Input: synaptics-rmi4: Handle incomplete input data
Commit 5b65c2a02966 ("HID: rmi: check sanity of the incoming report") added
support for handling incomplete HID reports do to the input data being
corrupted in transit. This patch reimplements this functionality in the
function drivers so they can handle getting less valid data then they
expect.
Signed-off-by: Andrew Duggan
---
drivers/input/rmi4/rmi_f11.c | 54
drivers/input/rmi4/rmi_f12.c | 23 ++-
drivers/input/rmi4/rmi_f30.c | 4
3 files changed, 61 insertions(+), 20 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 688e604..3fda75b 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -572,31 +572,48 @@ static inline u8 rmi_f11_parse_finger_state(const u8
*f_state, u8 n_finger)
static void rmi_f11_finger_handler(struct f11_data *f11,
struct rmi_2d_sensor *sensor,
- unsigned long *irq_bits, int num_irq_regs)
+ unsigned long *irq_bits, int num_irq_regs,
+ int size)
{
const u8 *f_state = f11->data.f_state;
u8 finger_state;
u8 i;
+ int abs_fingers;
+ int rel_fingers;
+ int abs_size = sensor->nbr_fingers * RMI_F11_ABS_BYTES;
int abs_bits = bitmap_and(f11->result_bits, irq_bits, f11->abs_mask,
num_irq_regs * 8);
int rel_bits = bitmap_and(f11->result_bits, irq_bits, f11->rel_mask,
num_irq_regs * 8);
- for (i = 0; i < sensor->nbr_fingers; i++) {
- /* Possible of having 4 fingers per f_statet register */
- finger_state = rmi_f11_parse_finger_state(f_state, i);
- if (finger_state == F11_RESERVED) {
- pr_err("Invalid finger state[%d]: 0x%02x", i,
- finger_state);
- continue;
- }
+ if (abs_bits) {
+ if (abs_size > size)
+ abs_fingers = size / RMI_F11_ABS_BYTES;
+ else
+ abs_fingers = sensor->nbr_fingers;
+
+ for (i = 0; i < abs_fingers; i++) {
+ /* Possible of having 4 fingers per f_state register */
+ finger_state = rmi_f11_parse_finger_state(f_state, i);
+ if (finger_state == F11_RESERVED) {
+ pr_err("Invalid finger state[%d]: 0x%02x", i,
+ finger_state);
+ continue;
+ }
- if (abs_bits)
rmi_f11_abs_pos_process(f11, sensor, &sensor->objs[i],
finger_state, i);
+ }
+ }
+
+ if (rel_bits) {
+ if ((abs_size + sensor->nbr_fingers * RMI_F11_REL_BYTES) > size)
+ rel_fingers = (size - abs_size) / RMI_F11_REL_BYTES;
+ else
+ rel_fingers = sensor->nbr_fingers;
- if (rel_bits)
+ for (i = 0; i < rel_fingers; i++)
rmi_f11_rel_pos_report(f11, i);
}
@@ -612,7 +629,7 @@ static void rmi_f11_finger_handler(struct f11_data *f11,
sensor->nbr_fingers,
sensor->dmax);
- for (i = 0; i < sensor->nbr_fingers; i++) {
+ for (i = 0; i < abs_fingers; i++) {
finger_state = rmi_f11_parse_finger_state(f_state, i);
if (finger_state == F11_RESERVED)
/* no need to send twice the error */
@@ -1266,10 +1283,19 @@ static int rmi_f11_attention(struct rmi_function *fn,
unsigned long *irq_bits)
struct f11_data *f11 = dev_get_drvdata(&fn->dev);
u16 data_base_addr = fn->fd.data_base_addr;
int error;
+ int valid_bytes = f11->sensor.pkt_size;
if (rmi_dev->xport->attn_data) {
+ /*
+* The valid data in the attention report is less then
+* expected. Only process the complete fingers.
+*/
+ if (f11->sensor.attn_size > rmi_dev->xport->attn_size)
+ valid_bytes = rmi_dev->xport->attn_size;
+ else
+ valid_bytes = f11->sensor.attn_size;
memcpy(f11->sensor.data_pkt, rmi_dev->xport->attn_data,
- f11->sensor.attn_size);
+ valid_bytes);
rmi_dev->xport->attn_data += f11->sensor.attn_size;
rmi_dev->xport->attn_size -= f11->sensor.attn_size;
} else {
@@ -1281,7 +1307,7 @@ static int rmi_f11_attention(struct rmi_function *fn,
unsigned long *irq_bi
Re: [PATCH v4 0/3] acpi/pmic: add opregion driver for Intel BXT WhiskeyCove PMIC
On Friday, June 24, 2016 10:25:21 AM Aaron Lu wrote: > On 06/24/2016 08:43 AM, Bin Gao wrote: > > This series modifies the pen function signature to take bit field > > and adds a new opregion driver for Intel BXT WhiskeyCove PMIC. It > > also adds support for PMIC regs operation region. > > Reviewed-by: Aaron Lu OK, all [1-3/3] applied, thanks!
[PATCH v2 6/8] Input: synaptics-rmi4: Remove unneeded variable
Remove the data_base_addr_offset variable in rmi_f11_attention(). The
f11 data is read as a single block so there is no need to store an offset
to the data address.
Signed-off-by: Andrew Duggan
---
drivers/input/rmi4/rmi_f11.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index e691432..688e604 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1265,7 +1265,6 @@ static int rmi_f11_attention(struct rmi_function *fn,
unsigned long *irq_bits)
struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
struct f11_data *f11 = dev_get_drvdata(&fn->dev);
u16 data_base_addr = fn->fd.data_base_addr;
- u16 data_base_addr_offset = 0;
int error;
if (rmi_dev->xport->attn_data) {
@@ -1275,8 +1274,7 @@ static int rmi_f11_attention(struct rmi_function *fn,
unsigned long *irq_bits)
rmi_dev->xport->attn_size -= f11->sensor.attn_size;
} else {
error = rmi_read_block(rmi_dev,
- data_base_addr + data_base_addr_offset,
- f11->sensor.data_pkt,
+ data_base_addr, f11->sensor.data_pkt,
f11->sensor.pkt_size);
if (error < 0)
return error;
@@ -1284,7 +1282,6 @@ static int rmi_f11_attention(struct rmi_function *fn,
unsigned long *irq_bits)
rmi_f11_finger_handler(f11, &f11->sensor, irq_bits,
drvdata->num_of_irq_regs);
- data_base_addr_offset += f11->sensor.pkt_size;
return 0;
}
--
2.5.0
[PATCH v2 5/8] Input: synaptics-rmi4: Remove pointer to rmi_function in f12_data
The pointer to struct rmi_function in f12_data is never set and was never
used. The fn pointer is also stored in rmi_2d_sensor which is a member of
f12_data.
Signed-off-by: Andrew Duggan
---
drivers/input/rmi4/rmi_f12.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 041a91d..7d66766 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -27,7 +27,6 @@ enum rmi_f12_object_type {
};
struct f12_data {
- struct rmi_function *fn;
struct rmi_2d_sensor sensor;
struct rmi_2d_sensor_platform_data sensor_pdata;
bool has_dribble;
--
2.5.0
[PATCH v2 4/8] Input: synaptics-rmi4: Add support for controlling dribble packets in F12
Implements reading and setting the dribble bit in F12's control registers.
Signed-off-by: Andrew Duggan
---
drivers/input/rmi4/rmi_f12.c | 74 +++-
1 file changed, 73 insertions(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
index 8dd3fb5..041a91d 100644
--- a/drivers/input/rmi4/rmi_f12.c
+++ b/drivers/input/rmi4/rmi_f12.c
@@ -30,6 +30,7 @@ struct f12_data {
struct rmi_function *fn;
struct rmi_2d_sensor sensor;
struct rmi_2d_sensor_platform_data sensor_pdata;
+ bool has_dribble;
u16 data_addr;
@@ -228,12 +229,79 @@ static int rmi_f12_attention(struct rmi_function *fn,
return 0;
}
+static int rmi_f12_write_control_regs(struct rmi_function *fn)
+{
+ int ret;
+ const struct rmi_register_desc_item *item;
+ struct rmi_device *rmi_dev = fn->rmi_dev;
+ struct f12_data *f12 = dev_get_drvdata(&fn->dev);
+ int control_size;
+ char buf[3];
+ u16 control_offset = 0;
+ u8 subpacket_offset = 0;
+
+ if (f12->has_dribble
+ && (f12->sensor.dribble != RMI_REG_STATE_DEFAULT)) {
+ item = rmi_get_register_desc_item(&f12->control_reg_desc, 20);
+ if (item) {
+ control_offset = rmi_register_desc_calc_reg_offset(
+ &f12->control_reg_desc, 20);
+
+ /*
+* The byte containing the EnableDribble bit will be
+* in either byte 0 or byte 2 of control 20. Depending
+* on the existence of subpacket 0. If control 20 is
+* larger then 3 bytes, just read the first 3.
+*/
+ if (item->reg_size >= 3)
+ control_size = 3;
+ else
+ control_size = item->reg_size;
+
+ ret = rmi_read_block(rmi_dev, fn->fd.control_base_addr
+ + control_offset, buf, control_size);
+ if (ret)
+ return ret;
+
+ if (rmi_register_desc_has_subpacket(item, 0))
+ subpacket_offset += 1;
+
+ switch (f12->sensor.dribble) {
+ case RMI_REG_STATE_OFF:
+ buf[subpacket_offset] &= ~BIT(2);
+ break;
+ case RMI_REG_STATE_ON:
+ buf[subpacket_offset] |= BIT(2);
+ break;
+ case RMI_REG_STATE_DEFAULT:
+ default:
+ break;
+ }
+
+ ret = rmi_write_block(rmi_dev,
+ fn->fd.control_base_addr + control_offset,
+ buf, control_size);
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+
+}
+
static int rmi_f12_config(struct rmi_function *fn)
{
struct rmi_driver *drv = fn->rmi_dev->driver;
+ int ret;
drv->set_irq_bits(fn->rmi_dev, fn->irq_mask);
+ ret = rmi_f12_write_control_regs(fn);
+ if (ret)
+ dev_warn(&fn->dev,
+ "Failed to write F12 control registers: %d\n", ret);
+
return 0;
}
@@ -260,16 +328,19 @@ static int rmi_f12_probe(struct rmi_function *fn)
}
++query_addr;
- if (!(buf & 0x1)) {
+ if (!(buf & BIT(0))) {
dev_err(&fn->dev,
"Behavior of F12 without register descriptors is
undefined.\n");
return -ENODEV;
}
+
f12 = devm_kzalloc(&fn->dev, sizeof(struct f12_data), GFP_KERNEL);
if (!f12)
return -ENOMEM;
+ f12->has_dribble = !!(buf & BIT(3));
+
if (fn->dev.of_node) {
ret = rmi_2d_sensor_of_probe(&fn->dev, &f12->sensor_pdata);
if (ret)
@@ -318,6 +389,7 @@ static int rmi_f12_probe(struct rmi_function *fn)
sensor->x_mm = f12->sensor_pdata.x_mm;
sensor->y_mm = f12->sensor_pdata.y_mm;
+ sensor->dribble = f12->sensor_pdata.dribble;
if (sensor->sensor_type == rmi_sensor_default)
sensor->sensor_type =
--
2.5.0
[PATCH v2 3/8] Input: synaptics-rmi4: Add dribble and palm gesture parameters to device tree
Signed-off-by: Andrew Duggan --- .../devicetree/bindings/input/rmi4/rmi_2d_sensor.txt | 4 drivers/input/rmi4/rmi_2d_sensor.c| 11 +++ 2 files changed, 15 insertions(+) diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt index f2c30c8..86cb8e3 100644 --- a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt @@ -37,6 +37,10 @@ Optional Properties: disable reporing absolute position data. - syna,rezero-wait-ms: Time in miliseconds to wait after issuing a rezero command. +- syna,dribble-enable: Enable reporting of dribble packets in the firmware. +- syna,dribble-disable: Disable reporting of dribble packets in the firmware. +- syna,palm-detect-enable: Enable reporting the palm detect gesture in the firmware. +- syna,palm-detect-disable: Disable reporting the palm detect gesture in the firmware. Example of a RMI4 I2C device with F11: diff --git a/drivers/input/rmi4/rmi_2d_sensor.c b/drivers/input/rmi4/rmi_2d_sensor.c index e97bd7f..ee26e35 100644 --- a/drivers/input/rmi4/rmi_2d_sensor.c +++ b/drivers/input/rmi4/rmi_2d_sensor.c @@ -317,6 +317,17 @@ int rmi_2d_sensor_of_probe(struct device *dev, pdata->rezero_wait = val; + if (of_property_read_bool(dev->of_node, "syna,dribble-enable")) + pdata->dribble = RMI_REG_STATE_ON; + else if (of_property_read_bool(dev->of_node, "syna,dribble-disable")) + pdata->dribble = RMI_REG_STATE_OFF; + + if (of_property_read_bool(dev->of_node, "syna,palm-detect-enable")) + pdata->palm_detect = RMI_REG_STATE_ON; + else if (of_property_read_bool(dev->of_node, + "syna,palm-detect-disable")) + pdata->palm_detect = RMI_REG_STATE_OFF; + return 0; } #else -- 2.5.0
[PATCH v2 1/8] Input: synaptics-rmi4: Increment the refcount of the transport dev's of_node
Increment the refcount for the transport device's of_node before calling
of_find_node_by_name(). Since of_find_node_by_name() assumes the refcount
was incremented by the caller and calls of_node_put() when it is done.
Signed-off-by: Andrew Duggan
---
drivers/input/rmi4/rmi_bus.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index b368b05..55b5336 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -157,11 +157,12 @@ static int rmi_function_match(struct device *dev, struct
device_driver *drv)
static void rmi_function_of_probe(struct rmi_function *fn)
{
char of_name[9];
+ struct device_node *node = fn->rmi_dev->xport->dev->of_node;
snprintf(of_name, sizeof(of_name), "rmi4-f%02x",
fn->fd.function_number);
- fn->dev.of_node = of_find_node_by_name(
- fn->rmi_dev->xport->dev->of_node, of_name);
+ of_node_get(node);
+ fn->dev.of_node = of_find_node_by_name(node, of_name);
}
#else
static inline void rmi_function_of_probe(struct rmi_function *fn)
--
2.5.0
[PATCH v2 2/8] Input: synaptics-rmi4: Add parameters for dribble packets and palm detect gesture
The rmi_f11 driver currently disables dribble packets and the palm detect
gesture for all devices. This patch creates a parameter in the 2d sensor
platform data for controlling this functionality on a per device basis.
For more information on dribble packets:
Commit 05ba999fcabb ("HID: rmi: disable dribble packets on Synaptics
touchpads")
For more information on the palm detect gesture:
Commit f097deef59a6 ("HID: rmi: disable palm detect gesture when present")
Signed-off-by: Andrew Duggan
---
drivers/input/rmi4/rmi_2d_sensor.h | 2 ++
drivers/input/rmi4/rmi_f01.c | 6 +++---
drivers/input/rmi4/rmi_f11.c | 32
include/linux/rmi.h| 21 +
4 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/input/rmi4/rmi_2d_sensor.h
b/drivers/input/rmi4/rmi_2d_sensor.h
index 77fcdfe..c871bef 100644
--- a/drivers/input/rmi4/rmi_2d_sensor.h
+++ b/drivers/input/rmi4/rmi_2d_sensor.h
@@ -67,6 +67,8 @@ struct rmi_2d_sensor {
u8 report_rel;
u8 x_mm;
u8 y_mm;
+ enum rmi_reg_state dribble;
+ enum rmi_reg_state palm_detect;
};
int rmi_2d_sensor_of_probe(struct device *dev,
diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index fac81fc..2cfa9f6 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -327,12 +327,12 @@ static int rmi_f01_probe(struct rmi_function *fn)
}
switch (pdata->power_management.nosleep) {
- case RMI_F01_NOSLEEP_DEFAULT:
+ case RMI_REG_STATE_DEFAULT:
break;
- case RMI_F01_NOSLEEP_OFF:
+ case RMI_REG_STATE_OFF:
f01->device_control.ctrl0 &= ~RMI_F01_CTRL0_NOSLEEP_BIT;
break;
- case RMI_F01_NOSLEEP_ON:
+ case RMI_REG_STATE_ON:
f01->device_control.ctrl0 |= RMI_F01_CTRL0_NOSLEEP_BIT;
break;
}
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index ec8a10d..e691432 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1125,6 +1125,8 @@ static int rmi_f11_initialize(struct rmi_function *fn)
sensor->topbuttonpad = f11->sensor_pdata.topbuttonpad;
sensor->kernel_tracking = f11->sensor_pdata.kernel_tracking;
sensor->dmax = f11->sensor_pdata.dmax;
+ sensor->dribble = f11->sensor_pdata.dribble;
+ sensor->palm_detect = f11->sensor_pdata.palm_detect;
if (f11->sens_query.has_physical_props) {
sensor->x_mm = f11->sens_query.x_sensor_size_mm;
@@ -1192,11 +1194,33 @@ static int rmi_f11_initialize(struct rmi_function *fn)
ctrl->ctrl0_11[RMI_F11_DELTA_Y_THRESHOLD] =
sensor->axis_align.delta_y_threshold;
- if (f11->sens_query.has_dribble)
- ctrl->ctrl0_11[0] = ctrl->ctrl0_11[0] & ~BIT(6);
+ if (f11->sens_query.has_dribble) {
+ switch (sensor->dribble) {
+ case RMI_REG_STATE_OFF:
+ ctrl->ctrl0_11[0] = ctrl->ctrl0_11[0] & ~BIT(6);
+ break;
+ case RMI_REG_STATE_ON:
+ ctrl->ctrl0_11[0] = ctrl->ctrl0_11[0] | BIT(6);
+ break;
+ case RMI_REG_STATE_DEFAULT:
+ default:
+ break;
+ }
+ }
- if (f11->sens_query.has_palm_det)
- ctrl->ctrl0_11[11] = ctrl->ctrl0_11[11] & ~BIT(0);
+ if (f11->sens_query.has_palm_det) {
+ switch (sensor->palm_detect) {
+ case RMI_REG_STATE_OFF:
+ ctrl->ctrl0_11[11] = ctrl->ctrl0_11[11] & ~BIT(0);
+ break;
+ case RMI_REG_STATE_ON:
+ ctrl->ctrl0_11[11] = ctrl->ctrl0_11[11] & BIT(0);
+ break;
+ case RMI_REG_STATE_DEFAULT:
+ default:
+ break;
+ }
+ }
rc = f11_write_control_regs(fn, &f11->sens_query,
&f11->dev_controls, fn->fd.query_base_addr);
diff --git a/include/linux/rmi.h b/include/linux/rmi.h
index e0aca14..bda72f2 100644
--- a/include/linux/rmi.h
+++ b/include/linux/rmi.h
@@ -99,6 +99,8 @@ struct rmi_2d_sensor_platform_data {
bool topbuttonpad;
bool kernel_tracking;
int dmax;
+ int dribble;
+ int palm_detect;
};
/**
@@ -116,14 +118,17 @@ struct rmi_f30_data {
bool disable;
};
-/**
- * struct rmi_f01_power - override default power management settings.
- *
+
+/*
+ * Set the state of a register
+ * DEFAULT - use the default value set by the firmware config
+ * OFF - explicitly disable the register
+ * ON - explicitly enable the register
*/
-enum rmi_f01_nosleep {
- RMI_F01_NOSLEEP_DEFAULT = 0,
- RMI_F01_NOSLEEP_OFF = 1,
- RMI_F01_NOSLEEP_ON = 2
+enum rmi_reg_state {
+ R
[PATCH v2 0/8] Input: synaptics-rmi4: Reimplement functionality from hid-rmi
The majority of this patch is reimplementing some of the functionality which was initially implemented in hid-rmi and reimplements it in the core. When hid-rmi is converted into a transport for rmi_core the functionality of existing touchpads should not change. Several of these patches address the feedback in the message: https://lkml.org/lkml/2016/4/12/434 I decided to go ahead and do a respin of this patch series. It includes changes to the device tree parameters and additional feedback from the first series. I also split out using the RMI_F11_REL_BYTES define from patch 7 into its own patch. Andrew Duggan (8): Input: synaptics-rmi4: Increment the refcount of the transport dev's of_node Input: synaptics-rmi4: Add parameters for dribble packets and palm detect gesture Input: synaptics-rmi4: Add dribble and palm gesture parameters to device tree Input: synaptics-rmi4: Add support for controlling dribble packets in F12 Input: synaptics-rmi4: Remove pointer to rmi_function in f12_data Input: synaptics-rmi4: Remove unneeded variable Input: synaptics-rmi4: Handle incomplete input data Input: synaptics-rmi4: Use the RMI_F11_REL_BYTES define in rmi_f11_rel_pos_report .../bindings/input/rmi4/rmi_2d_sensor.txt | 4 + drivers/input/rmi4/rmi_2d_sensor.c | 11 +++ drivers/input/rmi4/rmi_2d_sensor.h | 2 + drivers/input/rmi4/rmi_bus.c | 5 +- drivers/input/rmi4/rmi_f01.c | 6 +- drivers/input/rmi4/rmi_f11.c | 95 +++-- drivers/input/rmi4/rmi_f12.c | 98 -- drivers/input/rmi4/rmi_f30.c | 4 + include/linux/rmi.h| 21 +++-- 9 files changed, 201 insertions(+), 45 deletions(-) -- 2.5.0
Re: [PATCH 07/14] regulator: SY8106A regulator driver
Hi,
thank you for the review. I've resolved most of the issues. Some more
comments below.
On 24.6.2016 05:41, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM, wrote:
>> From: Ondrej Jirman
>>
>> SY8106A is I2C attached single output voltage regulator
>> made by Silergy.
>>
>> Signed-off-by: Ondrej Jirman
>> ---
>> drivers/regulator/Kconfig | 8 +-
>> drivers/regulator/Makefile| 2 +-
>> drivers/regulator/sy8106a-regulator.c | 153
>> ++
>> 3 files changed, 161 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/regulator/sy8106a-regulator.c
>>
>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>> index 144cbf5..fc3fae2 100644
>> --- a/drivers/regulator/Kconfig
>> +++ b/drivers/regulator/Kconfig
>> @@ -860,5 +860,11 @@ config REGULATOR_WM8994
>> This driver provides support for the voltage regulators on the
>> WM8994 CODEC.
>>
>> -endif
>> +config REGULATOR_SY8106A
>> + tristate "Silergy SY8106A"
>> + depends on I2C
>
> Maybe you should also depend on OF since the driver is going to crippled
> without any constraints set, or (OF || COMPILE_TEST) if you want some
> compile test coverage.
>
>> + select REGMAP_I2C
>> + help
>> + This driver provides support for the voltage regulator SY8106A.
>>
>> +endif
>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>> index 85a1d44..f382095 100644
>> --- a/drivers/regulator/Makefile
>> +++ b/drivers/regulator/Makefile
>> @@ -110,6 +110,6 @@ obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o
>> obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
>> obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>> obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>> -
>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
>
> Follow the existing ordering in the Makefile.
>
>>
>> ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>> diff --git a/drivers/regulator/sy8106a-regulator.c
>> b/drivers/regulator/sy8106a-regulator.c
>> new file mode 100644
>> index 000..34bd69c
>> --- /dev/null
>> +++ b/drivers/regulator/sy8106a-regulator.c
>> @@ -0,0 +1,153 @@
>> +/*
>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>> + *
>> + * Copyright (C) 2016 Ondřej Jirman
>> + *
>> + * This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Library General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2 of the License, or (at your option) any later version.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Library General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Library General Public
>> + * License along with this library; if not, write to the
>> + * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
>> + * Boston, MA 02110-1301, USA.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>
> Do you need this one?
>
>> +#include
>> +#include
>
> And this one?
>
>> +#include
>> +#include
>
> Sort alphabetically please.
>
>> +
>> +#define SY8106A_REG_VOUT1_SEL 0x01
>> +#define SY8106A_REG_VOUT_COM 0x02
>> +#define SY8106A_REG_VOUT1_SEL_MASK 0x7f
>> +#define SY8106A_DISABLE_REG0x01
>
> BIT(0) would be clearer.
>
>> +
>> +struct sy8106a {
>> + struct regulator_dev *rdev;
>> + struct regmap *regmap;
>> +};
>> +
>> +static const struct regmap_config sy8106a_regmap_config = {
>> + .reg_bits = 8,
>> + .val_bits = 8,
>> +};
>> +
>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned sel)
>> +{
>> + return regmap_update_bits(rdev->regmap, rdev->desc->vsel_reg,
>> + 0xff, sel | 0x80);
>
> Can you use .apply_bit / .apply_reg with regulator_set_voltage_sel_regmap?
I understand the code savings, but I'd rather avoid that, because it
would involve 2 needless readouts and rewrites of the voltage setting
register. I'd rather change this to regmap_write, so that the regulator
only receives writes over I2C, to minimize possibility of bit flip error
by minimizing the communication over the I2C bus.
>> +}
>> +
>> +static const struct regulator_ops sy8106a_ops = {
>> + .is_enabled = regulator_is_enabled_regmap,
>> + .set_voltage_sel = sy8106a_set_voltage_sel,
>> + .set_voltage_time_sel = regulator_set_voltage_time_sel,
>> + .get_voltage_sel = regulator_get_voltage_sel_regmap,
>> + .list_voltage = regulator_list_voltage_linear,
>> +};
>> +
>> +/* Default limits measured in millivolts and milliamps */
>> +#define SY8106A_MIN_MV 680
>> +#define SY8106A_MAX_MV 1950
>> +#define SY8106A_STEP_MV10
Re: regression caused by bb6ab52f2bef ("intel_pstate: Do not set utilization update hook too early")
On Friday, June 17, 2016 04:09:33 PM Jisheng Zhang wrote:
> Dear all,
>
> If using acpi-cpufreq instead, v4.6, v4.6-rc3, v4.7-rc3 can't reproduce the
> issue. It seems
> only intel_pstate is impacted.
Which is quite obvious, since the commit your bisection led to was
intel_pstate-specific. :-)
If the issue is what I'm thinking it is, the patch below should help, so
can you please test it?
Thanks,
Rafael
---
From: Rafael J. Wysocki
Subject: [PATCH] intel_pstate: Do not clear utilization update hooks on policy
changes
intel_pstate_set_policy() is invoked by the cpufreq core during
driver initialization, on changes of policy attributes (minimim and
maximum frequency, for example) via sysfs and via CPU notifications
from the platform firmware. On some platforms the latter may occur
relatively often.
Commit bb6ab52f2bef (intel_pstate: Do not set utilization update hook
too early) made intel_pstate_set_policy() clear the CPU's utilization
update hook before updating the policy attributes for it (and set the
hook again after doind that), but that involves invoking
synchronize_sched() and adds overhead to the CPU notifications
mentioned above and to the sched-RCU handling in general.
That extra overhead is arguably not necessary, because updating
policy attributes when the CPU's utilization update hook is active
should not lead to any adverse effects, so drop the clearing of
the hook from intel_pstate_set_policy() and make it check if
the hook has been set already when attempting to set it.
Fixes: bb6ab52f2bef (intel_pstate: Do not set utilization update hook too early)
Reported-by: Jisheng Zhang
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/intel_pstate.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -1440,6 +1440,9 @@ static void intel_pstate_set_update_util
{
struct cpudata *cpu = all_cpu_data[cpu_num];
+ if (cpu->update_util_set)
+ return;
+
/* Prevent intel_pstate_update_util() from using stale data. */
cpu->sample.time = 0;
cpufreq_add_update_util_hook(cpu_num, &cpu->update_util,
@@ -1480,8 +1483,6 @@ static int intel_pstate_set_policy(struc
if (!policy->cpuinfo.max_freq)
return -ENODEV;
- intel_pstate_clear_update_util_hook(policy->cpu);
-
pr_debug("set_policy cpuinfo.max %u policy->max %u\n",
policy->cpuinfo.max_freq, policy->max);
Re: [PATCH] selftests/lib: set printf.sh executable
Hi SeongJae Park, Thanks for the ping. On 06/24/2016 05:56 PM, SeongJae Park wrote: > Shuah, > > > May I ask your opinion about this patch? > > > Thanks, > SeongJae Park > > On Sun, Jun 19, 2016 at 2:50 AM, Kees Cook wrote: >> On Sat, Jun 18, 2016 at 2:28 AM, SeongJae Park wrote: >>> Test for test_printf module fails always because the test program, >>> printf.sh, has no execution permission. This commit adds execution >>> permission to it. >>> >>> Signed-off-by: SeongJae Park >> >> Acked-by: Kees Cook >> >> (Is this mode change sufficient, or does the selftest infrastructure >> need to explicitly set it executable when running?) This is good and makes it consistent with bitmap.sh the other shell script in this test suite. I will get this into 4.8-rc1 thanks, -- Shuah >> >> -Kees >> >> >>> --- >>> tools/testing/selftests/lib/printf.sh | 0 >>> 1 file changed, 0 insertions(+), 0 deletions(-) >>> mode change 100644 => 100755 tools/testing/selftests/lib/printf.sh >>> >>> diff --git a/tools/testing/selftests/lib/printf.sh >>> b/tools/testing/selftests/lib/printf.sh >>> old mode 100644 >>> new mode 100755 >>> -- >>> 1.9.1 >>> >> >> >> >> -- >> Kees Cook >> Chrome OS & Brillo Security
Re: regression caused by bb6ab52f2bef ("intel_pstate: Do not set utilization update hook too early")
On Thu, Jun 23, 2016 at 6:07 PM, Doug Smythies wrote:
> On 2016.06.17 08:32 Jisheng Zhang wrote:
>
>> Second, sorry again for report incorrect commit,
>> I were too tired this morning so I remember the wrong commit.
>> The regression is caused by bb6ab52f2bef ("intel_pstate: Do not
>> set utilization update hook too early"), so I update the email title.
>
> Summary:
>
> Isn't running powertop itself a significant contributor here?
It shouldn't be, because the overhead in question comes from
->setpolicy and powertop itself should not cause it to be invoked that
often.
Thanks,
Rafael
Re: [GIT PULL] phy: for 4.7 -rc cycle
On Thu, Jun 23, 2016 at 11:32:18AM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find the 2nd pull request for the -rc cycle. This contains minor > fixes in various phy drivers. I've listed the changes in the tag message. > Consider merging it in this -rc cyle. > > Please let me know if I have to change something. > > Thanks > Kishon > > The following changes since commit 31b2a32f708bb33b3f35b03ce3d2cb31f7d1e684: > > phy: ti-pipe3: Program the DPLL even if it was already locked (2016-06-03 > 12:06:41 +0530) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git > tags/phy-for-4.7-rc5 Pulled and pushed out, thanks. greg k-h
Re: [PATCH] selftests/lib: set printf.sh executable
Shuah, May I ask your opinion about this patch? Thanks, SeongJae Park On Sun, Jun 19, 2016 at 2:50 AM, Kees Cook wrote: > On Sat, Jun 18, 2016 at 2:28 AM, SeongJae Park wrote: >> Test for test_printf module fails always because the test program, >> printf.sh, has no execution permission. This commit adds execution >> permission to it. >> >> Signed-off-by: SeongJae Park > > Acked-by: Kees Cook > > (Is this mode change sufficient, or does the selftest infrastructure > need to explicitly set it executable when running?) > > -Kees > > >> --- >> tools/testing/selftests/lib/printf.sh | 0 >> 1 file changed, 0 insertions(+), 0 deletions(-) >> mode change 100644 => 100755 tools/testing/selftests/lib/printf.sh >> >> diff --git a/tools/testing/selftests/lib/printf.sh >> b/tools/testing/selftests/lib/printf.sh >> old mode 100644 >> new mode 100755 >> -- >> 1.9.1 >> > > > > -- > Kees Cook > Chrome OS & Brillo Security
Re: [RESEND PATCH 4/8] clk: core: support clocks which requires parents on (part 2)
Hi Dong,
Quoting Dong Aisheng (2016-04-20 02:34:36)
> On Freescale i.MX7D platform, all clocks operations, including
> enable/disable, rate change and re-parent, requires its parent clock on.
> Current clock core can not support it well.
> This patch adding flag CLK_OPS_PARENT_ON to handle this special case in
> clock core that enable its parent clock firstly for each operation and
> disable it later after operation complete.
>
> The patch part 2 fixes set clock rate and set parent while its parent
> is off. The most special case is for set_parent() operation which requires
> all parents including both old and new one to be enabled at the same time
> during the operation.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: Shawn Guo
> Signed-off-by: Dong Aisheng
> ---
> drivers/clk/clk.c | 45 -
> 1 file changed, 28 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 1f054d1a..d6cef61 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1174,7 +1174,7 @@ static struct clk_core *__clk_set_parent_before(struct
> clk_core *core,
> struct clk_core *old_parent = core->parent;
>
> /*
> -* Migrate prepare state between parents and prevent race with
> +* 1. Migrate prepare state between parents and prevent race with
> * clk_enable().
> *
> * If the clock is not prepared, then a race with
> @@ -1189,13 +1189,16 @@ static struct clk_core
> *__clk_set_parent_before(struct clk_core *core,
> * hardware and software states.
> *
> * See also: Comment for clk_set_parent() below.
> +*
> +* 2. enable parent clocks for CLK_OPS_PARENT_ON clock
> */
> - if (core->prepare_count) {
> - clk_core_prepare(parent);
> - flags = clk_enable_lock();
> - clk_core_enable(parent);
> - clk_core_enable(core);
> - clk_enable_unlock(flags);
> + if (core->prepare_count || core->flags & CLK_OPS_PARENT_ON) {
> + clk_core_prepare_enable(parent);
> + if (core->prepare_count)
> + clk_core_enable_lock(core);
> + else
> + clk_core_prepare_enable(old_parent);
It took me a few seconds to figure out what I was looking at. The
set_parent stuff is tricky enough already ... I think we should keep the
state machine logic very simple. How about:
/* enable old_parent & parent if CLK_OPS_PARENT_ENABLE is set */
if (core->flags & CLK_OPS_PARENT_ENABLE) {
clk_core_prepare_enable(old_parent);
clk_core_prepare_enable(parent);
}
/* migrate prepare count if > 0 */
if (core->prepare_count) {
clk_core_prepare_enable(parent);
clk_core_enable_lock(core);
}
> +
> }
>
> /* update the clk tree topology */
> @@ -1210,18 +1213,16 @@ static void __clk_set_parent_after(struct clk_core
> *core,
>struct clk_core *parent,
>struct clk_core *old_parent)
> {
> - unsigned long flags;
> -
> /*
> * Finish the migration of prepare state and undo the changes done
> * for preventing a race with clk_enable().
> */
> - if (core->prepare_count) {
> - flags = clk_enable_lock();
> - clk_core_disable(core);
> - clk_core_disable(old_parent);
> - clk_enable_unlock(flags);
> - clk_core_unprepare(old_parent);
> + if (core->prepare_count || core->flags & CLK_OPS_PARENT_ON) {
> + clk_core_disable_unprepare(old_parent);
> + if (core->prepare_count)
> + clk_core_disable_lock(core);
> + else
> + clk_core_disable_unprepare(parent);
Similarly, a more readable solution is:
/*
* Finish the migration of prepare state and undo the changes done
* for preventing a race with clk_enable().
*/
if (core->prepare_count) {
clk_core_disable_lock(core);
clk_core_disable_unprepare(old_parent);
/* re-balance ref counting if CLK_OPS_PARENT_ENABLE is set */
if (core->flags & CLK_OPS_PARENT_ENABLE) {
clk_core_disable_unprepare(parent);
clk_core_disable_unprepare(old_parent);
}
> }
> }
>
> @@ -1468,13 +1469,17 @@ static void clk_change_rate(struct clk_core *core)
> unsigned long best_parent_rate = 0;
> bool skip_set_rate = false;
> struct clk_core *old_parent;
> + struct clk_core *parent = NULL;
>
> old_rate = core->rate;
>
> - if (core->new_parent)
> + if (core->new_parent) {
> + parent = core->new_parent;
>
[PATCH] orangefs: fix namespace handling
In orangefs_inode_getxattr(), an fsuid is written to dmesg. The kuid is
converted to a userspace uid via from_kuid(current_user_ns(), [...]), but
since dmesg is global, init_user_ns should be used here instead.
In copy_attributes_from_inode(), op_alloc() and fill_default_sys_attrs(),
upcall structures are populated with uids/gids that have been mapped into
the caller's namespace. However, those upcall structures are read by
another process (the userspace filesystem driver), and that process might
be running in another namespace. This effectively lets any user spoof its
uid and gid as seen by the userspace filesystem driver.
To fix the second issue, I just construct the opcall structures with
init_user_ns uids/gids and require the filesystem server to run in the
init namespace. Since orangefs is full of global state anyway (as the error
message in DUMP_DEVICE_ERROR explains, there can only be one userspace
orangefs filesystem driver at once), that shouldn't be a problem.
[
Why does orangefs even exist in the kernel if everything does upcalls into
userspace? What does orangefs do that couldn't be done with the FUSE
interface? If there is no good answer to those questions, I'd prefer to see
orangefs kicked out of the kernel. Can that be done for something that
shipped in a release?
According to commit f7ab093f74bf ("Orangefs: kernel client part 1"), they
even already have a FUSE daemon, and the only rational reason (apart from
"but most of our users report preferring to use our kernel module instead")
given for not wanting to use FUSE is one "in-the-works" feature that could
probably be integated into FUSE instead.
]
This patch has been compile-tested.
Signed-off-by: Jann Horn
---
fs/orangefs/devorangefs-req.c | 7 +++
fs/orangefs/orangefs-cache.c | 4 ++--
fs/orangefs/orangefs-kernel.h | 4 ++--
fs/orangefs/orangefs-utils.c | 4 ++--
fs/orangefs/xattr.c | 4 ++--
5 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/fs/orangefs/devorangefs-req.c b/fs/orangefs/devorangefs-req.c
index db170be..a287a66 100644
--- a/fs/orangefs/devorangefs-req.c
+++ b/fs/orangefs/devorangefs-req.c
@@ -116,6 +116,13 @@ static int orangefs_devreq_open(struct inode *inode,
struct file *file)
{
int ret = -EINVAL;
+ /* in order to ensure that the filesystem driver sees correct UIDs */
+ if (file->f_cred->user_ns != &init_user_ns) {
+ gossip_err("%s: device cannot be opened outside init_user_ns\n",
+ __func__);
+ goto out;
+ }
+
if (!(file->f_flags & O_NONBLOCK)) {
gossip_err("%s: device cannot be opened in blocking mode\n",
__func__);
diff --git a/fs/orangefs/orangefs-cache.c b/fs/orangefs/orangefs-cache.c
index 900a2e3..b6edbe9 100644
--- a/fs/orangefs/orangefs-cache.c
+++ b/fs/orangefs/orangefs-cache.c
@@ -136,10 +136,10 @@ struct orangefs_kernel_op_s *op_alloc(__s32 type)
llu(new_op->tag),
get_opname_string(new_op));
- new_op->upcall.uid = from_kuid(current_user_ns(),
+ new_op->upcall.uid = from_kuid(&init_user_ns,
current_fsuid());
- new_op->upcall.gid = from_kgid(current_user_ns(),
+ new_op->upcall.gid = from_kgid(&init_user_ns,
current_fsgid());
} else {
gossip_err("op_alloc: kmem_cache_zalloc failed!\n");
diff --git a/fs/orangefs/orangefs-kernel.h b/fs/orangefs/orangefs-kernel.h
index 2281882..a6834d4 100644
--- a/fs/orangefs/orangefs-kernel.h
+++ b/fs/orangefs/orangefs-kernel.h
@@ -600,8 +600,8 @@ int service_operation(struct orangefs_kernel_op_s *op,
#define fill_default_sys_attrs(sys_attr, type, mode) \
do { \
- sys_attr.owner = from_kuid(current_user_ns(), current_fsuid()); \
- sys_attr.group = from_kgid(current_user_ns(), current_fsgid()); \
+ sys_attr.owner = from_kuid(&init_user_ns, current_fsuid()); \
+ sys_attr.group = from_kgid(&init_user_ns, current_fsgid()); \
sys_attr.perms = ORANGEFS_util_translate_mode(mode);\
sys_attr.mtime = 0; \
sys_attr.atime = 0; \
diff --git a/fs/orangefs/orangefs-utils.c b/fs/orangefs/orangefs-utils.c
index 2d129b5..c5fbc62 100644
--- a/fs/orangefs/orangefs-utils.c
+++ b/fs/orangefs/orangefs-utils.c
@@ -153,12 +153,12 @@ static inline int copy_attributes_from_inode(struct inode
*inode,
*/
attrs->mask = 0;
if (iattr->ia_valid & ATTR_UID) {
- attrs->owner = from_kuid(current_user_ns(), iattr->ia_uid);
+ attrs->owner = from_kuid(&init_user_ns, iattr->ia_uid);
attrs->mask |= ORANGEFS_ATTR_SYS_UID
Re: [RESEND PATCH 3/8] clk: core: support clocks which requires parents on (part 1)
Quoting Dong Aisheng (2016-04-20 02:34:35) > On Freescale i.MX7D platform, all clocks operations, including > enable/disable, rate change and re-parent, requires its parent > clock on. Current clock core can not support it well. > This patch introduce a new flag CLK_OPS_PARENT_ON to handle this > special case in clock core that enable its parent clock firstly for > each operation and disable it later after operation complete. > > The patch part 1 fixes the possible disabling clocks while its parent > is off during kernel booting phase in clk_disable_unused_subtree(). > > Before the completion of kernel booting, clock tree is still not built > completely, there may be a case that the child clock is on but its > parent is off which could be caused by either HW initial reset state > or bootloader initialization. > > Taking bootloader as an example, we may enable all clocks in HW by default. > And during kernel booting time, the parent clock could be disabled in its > driver probe due to calling clk_prepare_enable and clk_disable_unprepare. > Because it's child clock is only enabled in HW while its SW usecount > in clock tree is still 0, so clk_disable of parent clock will gate > the parent clock in both HW and SW usecount ultimately. Then there will > be a child clock is still on in HW but its parent is already off. > > Later in clk_disable_unused(), this clock disable accessing while its > parent off will cause system hang due to the limitation of HW which > must require its parent on. > > This patch simply enables the parent clock first before disabling > if flag CLK_OPS_PARENT_ON is set in clk_disable_unused_subtree(). > This is a simple solution and only affects booting time. > > After kernel booting up the clock tree is already created, there will > be no case that child is off but its parent is off. > So no need do this checking for normal clk_disable() later. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Shawn Guo > Signed-off-by: Dong Aisheng > --- > drivers/clk/clk.c| 5 + > include/linux/clk-provider.h | 2 ++ > 2 files changed, 7 insertions(+) > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > index 9f944d4..1f054d1a 100644 > --- a/drivers/clk/clk.c > +++ b/drivers/clk/clk.c > @@ -765,6 +765,9 @@ static void clk_disable_unused_subtree(struct clk_core > *core) > hlist_for_each_entry(child, &core->children, child_node) > clk_disable_unused_subtree(child); > > + if (core->flags & CLK_OPS_PARENT_ON) > + clk_core_prepare_enable(core->parent); > + > flags = clk_enable_lock(); > > if (core->enable_count) > @@ -789,6 +792,8 @@ static void clk_disable_unused_subtree(struct clk_core > *core) > > unlock_out: > clk_enable_unlock(flags); > + if (core->flags & CLK_OPS_PARENT_ON) > + clk_core_disable_unprepare(core->parent); > } > > static bool clk_ignore_unused; > diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h > index 15628644..c878f9c 100644 > --- a/include/linux/clk-provider.h > +++ b/include/linux/clk-provider.h > @@ -33,6 +33,8 @@ > #define CLK_RECALC_NEW_RATES BIT(9) /* recalc rates after notifications */ > #define CLK_SET_RATE_UNGATEBIT(10) /* clock needs to run to set rate */ > #define CLK_IS_CRITICALBIT(11) /* do not gate, ever */ > +/* parents need on during gate/ungate, set rate and re-parent */ > +#define CLK_OPS_PARENT_ON BIT(12) Hi Dong, In the clk framework we use "enabled" instead of "on". How about changing the flag to CLK_OPS_PARENT_ENABLE? Regards, Mike > > struct clk; > struct clk_hw; > -- > 1.9.1 >
Re: [PATCH perf/core v12 00/16] perf-probe --cache and SDT support
On Fri, 24 Jun 2016 13:25:20 -0700 Brendan Gregg wrote: > On Fri, Jun 24, 2016 at 2:05 AM, Masami Hiramatsu wrote: > > Hi, > > > > Here is the 12th version of the patchset for probe-cache and > > initial SDT support. > > > > Here is the previous v11: https://lkml.org/lkml/2016/6/14/1041 > > > > In this version I just rename strlist__for_each to > > strlist__for_each_entry, and change some patch description. > > > > I tested it on Node.js (and applied to acme's perf/core), and it works. > Thanks! > > # perf script > node 36750 [006] 3080.761533: > sdt_node:http__server__request: (da8b0c) > node 36750 [006] 3081.368771: > sdt_node:http__server__request: (da8b0c) > node 36750 [006] 3081.592925: > sdt_node:http__server__request: (da8b0c) > node 36750 [006] 3081.976802: > sdt_node:http__server__request: (da8b0c) > node 36750 [006] 3082.296709: > sdt_node:http__server__request: (da8b0c) > > Since it doesn't set the is-enabled semaphore yet, I had to do that > manually for the probes that use it. I know that will be a latter > addition. Yes, I'd like to support it. However, the question is who should enable it. To enable it from perf, perf must attach the target running processes and change the semaphore. If we run "perf record -a", it has to check all the running process and tweak it. Moreover, it may have to hook the execve syscall. To enable it from kernel, hooking the target process is easier, since we already did it in uprobes. However, it means we'll introduce a special functionality to tweak user binary, and of course it may need to understand SDT section to find out the semaphore. So, one possible solution is, adding a semaphore option(like an address) to uprobe events and enable it via ftrace. On this way, perf just analyzes SDT and pass the semaphore address to ftrace when defining a probe, and ftrace set 1 to the semaphre address. > > # perf list | grep sdt > sdt_node:http__client__request [Tracepoint event] > sdt_node:http__server__request [Tracepoint event] > sdt_node:gc__done [SDT event] > sdt_node:gc__start [SDT event] > sdt_node:http__client__request [SDT event] > sdt_node:http__client__response[SDT event] > sdt_node:http__server__request [SDT event] > sdt_node:http__server__response[SDT event] > sdt_node:net__server__connection [SDT event] > sdt_node:net__stream__end [SDT event] > > It's also a bit weird to see these listed twice, but I understand > what's happening. If this continues to prove confusing, I guess later > on we could change it to exclude listing SDT events that have been > promoted to Tracepoint events, or not list SDT events in "perf list" > at all, leaving them for "perf probe --cache --list". Ah, right. Hmm, at this point, I'd like latter method, since perf record doesn't support SDT directly yet. So we just need to drop 08/16 and 09/16. It should be implemented with perf-record support. Thank you! > > Anyway, this is great as is, and thanks again. > > Brendan > > > > Thank you, > > > > --- > > > > Hemant Kumar (1): > > perf/sdt: ELF support for SDT > > > > Masami Hiramatsu (15): > > perf probe: Use cache entry if possible > > perf probe: Show all cached probes > > perf probe: Remove caches when --cache is given > > perf probe: Add group name support > > perf buildid-cache: Scan and import user SDT events to probe cache > > perf probe: Accept %sdt and %cached event name > > perf-list: Show SDT and pre-cached events > > perf-list: Skip SDTs placed in invalid binaries > > perf: probe-cache: Add for_each_probe_cache_entry() wrapper > > perf probe: Allow wildcard for cached events > > perf probe: Search SDT/cached event from all probe caches > > perf probe: Support @BUILDID or @FILE suffix for SDT events > > perf probe: Support a special SDT probe format > > perf build: Add sdt feature detection > > perf-test: Add a test case for SDT event > > > > > > tools/perf/Documentation/perf-buildid-cache.txt |3 > > tools/perf/Documentation/perf-probe.txt | 30 +- > > tools/perf/Makefile.perf|3 > > tools/perf/builtin-list.c |6 > > tools/perf/builtin-probe.c | 31 ++ > > tools/perf/config/Makefile | 10 + > > tools/perf/tests/Build |1 > > tools/perf/tests/builtin-test.c |4 > > tools/perf/tests/make |3 > > tools/perf/tests/sdt.c | 115 +++ > > tools/perf/tests/tests.h|1 > > tools/perf/util/build-id.c
[PATCH v5 3/3] LSM: Add context interface for proc attrs
Subject: [PATCH v5 3/3] LSM: Add context interface for proc attrs
(I sent this with the wrong version number. This is the same otherwise)
The /proc/.../attr/current interface is used by all three
Linux security modules (SELinux, Smack and AppArmor) to
report and modify the process security attribute. This is
all fine when there is exactly one of these modules active
and the userspace code knows which it module it is.
It would require a major change to the "current" interface
to provide information about more than one set of process
security attributes. Instead, a "context" attribute is
added, which identifies the security module that the
information applies to. The format is:
lsmname='context-value'
When multiple concurrent modules are supported the
/proc/.../attr/context interface will include the data
for all of the active modules.
lsmname1='context-value1',lsmname2='context-value2'
The module specific subdirectories under attr contain context
entries that report the information for that specific module
in the same format.
Signed-off-by: Casey Schaufler
---
Documentation/security/LSM.txt | 8 +++
fs/proc/base.c | 4 ++
security/apparmor/lsm.c| 35 +++--
security/security.c| 108 +
security/selinux/hooks.c | 20 +++-
security/smack/smack_lsm.c | 20
6 files changed, 180 insertions(+), 15 deletions(-)
diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
index 125c489..af3eb11 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/security/LSM.txt
@@ -36,6 +36,14 @@ for SELinux would be in /proc/.../attr/selinux. Using the
files
found directly in /proc/.../attr (e.g. current) should be avoided.
These files remain as legacy interfaces.
+The files named "context" in the attr directories contain the
+same information as the "current" files, but formatted to
+identify the module it comes from.
+
+if selinux is the active security module:
+ /proc/self/attr/context could contain selinux='unconfined_t'
+ /proc/self/attr/selinux/context could contain selinux='unconfined_t'
+
Based on https://lkml.org/lkml/2007/10/26/215,
a new LSM is accepted into the kernel when its intent (a description of
what it tries to protect against and in what cases one would expect to
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 182bc28..df94f26 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2532,6 +2532,7 @@ static const struct pid_entry selinux_attr_dir_stuff[] = {
ATTR("selinux", "fscreate", S_IRUGO|S_IWUGO),
ATTR("selinux", "keycreate",S_IRUGO|S_IWUGO),
ATTR("selinux", "sockcreate", S_IRUGO|S_IWUGO),
+ ATTR("selinux", "context", S_IRUGO|S_IWUGO),
};
LSM_DIR_OPS(selinux);
#endif
@@ -2539,6 +2540,7 @@ LSM_DIR_OPS(selinux);
#ifdef CONFIG_SECURITY_SMACK
static const struct pid_entry smack_attr_dir_stuff[] = {
ATTR("smack", "current",S_IRUGO|S_IWUGO),
+ ATTR("smack", "context",S_IRUGO|S_IWUGO),
};
LSM_DIR_OPS(smack);
#endif
@@ -2548,6 +2550,7 @@ static const struct pid_entry apparmor_attr_dir_stuff[] =
{
ATTR("apparmor", "current", S_IRUGO|S_IWUGO),
ATTR("apparmor", "prev",S_IRUGO),
ATTR("apparmor", "exec",S_IRUGO|S_IWUGO),
+ ATTR("apparmor", "context", S_IRUGO|S_IWUGO),
};
LSM_DIR_OPS(apparmor);
#endif
@@ -2559,6 +2562,7 @@ static const struct pid_entry attr_dir_stuff[] = {
ATTR(NULL, "fscreate", S_IRUGO|S_IWUGO),
ATTR(NULL, "keycreate", S_IRUGO|S_IWUGO),
ATTR(NULL, "sockcreate",S_IRUGO|S_IWUGO),
+ ATTR(NULL, "context", S_IRUGO|S_IWUGO),
#ifdef CONFIG_SECURITY_SELINUX
DIR("selinux", S_IRUGO|S_IXUGO,
proc_selinux_attr_dir_inode_ops, proc_selinux_attr_dir_ops),
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index fb0fb03..5cac15f 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -476,9 +476,13 @@ static int apparmor_getprocattr(struct task_struct *task,
char *name,
const struct cred *cred = get_task_cred(task);
struct aa_task_cxt *cxt = cred_cxt(cred);
struct aa_profile *profile = NULL;
+ char *vp;
+ char *np;
if (strcmp(name, "current") == 0)
profile = aa_get_newest_profile(cxt->profile);
+ else if (strcmp(name, "context") == 0)
+ profile = aa_get_newest_profile(cxt->profile);
else if (strcmp(name, "prev") == 0 && cxt->previous)
profile = aa_get_newest_profile(cxt->previous);
else if (strcmp(name, "exec") == 0 && cxt->onexec)
@@ -486,9 +490,29 @@ static int apparmor_getprocattr(struct task_struct *task,
char *name,
else
error = -EINVAL;
- if (profile)
- error = aa_getprocattr(profile, value);
+ if
Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support
On Fri, Jun 24, 2016 at 09:19:32AM +0200, Benjamin Tissoires wrote:
> On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> > On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > > +
> > > +static struct i2c_driver rmi_smb_driver = {
> > > + .driver = {
> > > + .owner = THIS_MODULE,
> > > + .name = "rmi4_smbus",
> > > + .pm = &rmi_smb_pm,
> > > + .resume = rmi_smb_resume,
> >
> > Why rmi_smb_resume is not part of rmi_smb_pm?
> >
>
> This is because rmi_smbus device both have a PS/2 interface and a SMBus
> one. I'll have to check again now that I have a slightly different way
> of binding smbus devices in my tree, but the issue was:
> - having resume part of pm means it will get caught by PM directly
> - the PS/2 node gets also resumed by PM
> - calling PS/2 commands during resume switches the devices back into
> PS/2 and stops the SMBus communication.
>
> So it's easier to wait only for the PS/2 PM resume call which will call
> the SMBus resume function when the device is in a proper state.
>
> I'll send out the updated patch with your comments next week hopefully.
Hmm, I think you will have to walk me through resume process. How do we
tie in PS/2 and I2C on these devices abd have PS/2 code call into this
driver?
Thanks.
--
Dmitry
[PATCH v4 3/3] LSM: Add context interface for proc attrs
Subject: [PATCH v4 3/3] LSM: Add context interface for proc attrs
The /proc/.../attr/current interface is used by all three
Linux security modules (SELinux, Smack and AppArmor) to
report and modify the process security attribute. This is
all fine when there is exactly one of these modules active
and the userspace code knows which it module it is.
It would require a major change to the "current" interface
to provide information about more than one set of process
security attributes. Instead, a "context" attribute is
added, which identifies the security module that the
information applies to. The format is:
lsmname='context-value'
When multiple concurrent modules are supported the
/proc/.../attr/context interface will include the data
for all of the active modules.
lsmname1='context-value1',lsmname2='context-value2'
The module specific subdirectories under attr contain context
entries that report the information for that specific module
in the same format.
Signed-off-by: Casey Schaufler
---
Documentation/security/LSM.txt | 8 +++
fs/proc/base.c | 4 ++
security/apparmor/lsm.c| 35 +++--
security/security.c| 108 +
security/selinux/hooks.c | 20 +++-
security/smack/smack_lsm.c | 20
6 files changed, 180 insertions(+), 15 deletions(-)
diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
index 125c489..af3eb11 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/security/LSM.txt
@@ -36,6 +36,14 @@ for SELinux would be in /proc/.../attr/selinux. Using the
files
found directly in /proc/.../attr (e.g. current) should be avoided.
These files remain as legacy interfaces.
+The files named "context" in the attr directories contain the
+same information as the "current" files, but formatted to
+identify the module it comes from.
+
+if selinux is the active security module:
+ /proc/self/attr/context could contain selinux='unconfined_t'
+ /proc/self/attr/selinux/context could contain selinux='unconfined_t'
+
Based on https://lkml.org/lkml/2007/10/26/215,
a new LSM is accepted into the kernel when its intent (a description of
what it tries to protect against and in what cases one would expect to
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 182bc28..df94f26 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2532,6 +2532,7 @@ static const struct pid_entry selinux_attr_dir_stuff[] = {
ATTR("selinux", "fscreate", S_IRUGO|S_IWUGO),
ATTR("selinux", "keycreate",S_IRUGO|S_IWUGO),
ATTR("selinux", "sockcreate", S_IRUGO|S_IWUGO),
+ ATTR("selinux", "context", S_IRUGO|S_IWUGO),
};
LSM_DIR_OPS(selinux);
#endif
@@ -2539,6 +2540,7 @@ LSM_DIR_OPS(selinux);
#ifdef CONFIG_SECURITY_SMACK
static const struct pid_entry smack_attr_dir_stuff[] = {
ATTR("smack", "current",S_IRUGO|S_IWUGO),
+ ATTR("smack", "context",S_IRUGO|S_IWUGO),
};
LSM_DIR_OPS(smack);
#endif
@@ -2548,6 +2550,7 @@ static const struct pid_entry apparmor_attr_dir_stuff[] =
{
ATTR("apparmor", "current", S_IRUGO|S_IWUGO),
ATTR("apparmor", "prev",S_IRUGO),
ATTR("apparmor", "exec",S_IRUGO|S_IWUGO),
+ ATTR("apparmor", "context", S_IRUGO|S_IWUGO),
};
LSM_DIR_OPS(apparmor);
#endif
@@ -2559,6 +2562,7 @@ static const struct pid_entry attr_dir_stuff[] = {
ATTR(NULL, "fscreate", S_IRUGO|S_IWUGO),
ATTR(NULL, "keycreate", S_IRUGO|S_IWUGO),
ATTR(NULL, "sockcreate",S_IRUGO|S_IWUGO),
+ ATTR(NULL, "context", S_IRUGO|S_IWUGO),
#ifdef CONFIG_SECURITY_SELINUX
DIR("selinux", S_IRUGO|S_IXUGO,
proc_selinux_attr_dir_inode_ops, proc_selinux_attr_dir_ops),
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index fb0fb03..5cac15f 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -476,9 +476,13 @@ static int apparmor_getprocattr(struct task_struct *task,
char *name,
const struct cred *cred = get_task_cred(task);
struct aa_task_cxt *cxt = cred_cxt(cred);
struct aa_profile *profile = NULL;
+ char *vp;
+ char *np;
if (strcmp(name, "current") == 0)
profile = aa_get_newest_profile(cxt->profile);
+ else if (strcmp(name, "context") == 0)
+ profile = aa_get_newest_profile(cxt->profile);
else if (strcmp(name, "prev") == 0 && cxt->previous)
profile = aa_get_newest_profile(cxt->previous);
else if (strcmp(name, "exec") == 0 && cxt->onexec)
@@ -486,9 +490,29 @@ static int apparmor_getprocattr(struct task_struct *task,
char *name,
else
error = -EINVAL;
- if (profile)
- error = aa_getprocattr(profile, value);
+ if (profile == NULL)
+ goto put_out;
+
+ error = aa_get
[PATCH v5 2/3] LSM: module hierarchy in /proc/.../attr
Subject: [PATCH v5 2/3] LSM: module hierarchy in /proc/.../attr
Back in 2007 I made what turned out to be a rather serious
mistake in the implementation of the Smack security module.
The SELinux module used an interface in /proc to manipulate
the security context on processes. Rather than use a similar
interface, I used the same interface. The AppArmor team did
likewise. Now /proc/.../attr/current will tell you the
security "context" of the process, but it will be different
depending on the security module you're using. That hasn't
been a problem to date, as you can only have one module
that supports process attributes at a time. We are coming
up on a change to that, where multiple modules with process
attributes can be supported. (Not included here)
This patch provides a subdirectory in /proc/.../attr for
each of the security modules that use the LSM hooks
getprocattr() and setprocattr(). Each of the interfaces
used by a module are presented in the subdirectory. The
old interfaces remain and work the same as before.
User space code can begin migrating to the subdirectory
interfaces in anticipation of the time when what comes
from /proc/self/attr/current might not be what a runtime
wants.
The original implementation is by Kees Cook. The code
has been changed a bit to reflect changes in the direction
of the multiple concurrent module work, to be independent
of it, and to bring it up to date with the current tree.
Signed-off-by: Casey Schaufler
---
Documentation/security/LSM.txt | 19 ++---
fs/proc/base.c | 91 +-
fs/proc/internal.h | 1 +
include/linux/security.h | 15 ---
security/security.c| 31 --
5 files changed, 133 insertions(+), 24 deletions(-)
diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
index c2683f2..125c489 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/security/LSM.txt
@@ -16,11 +16,10 @@ MAC extensions, other extensions can be built using the LSM
to provide
specific changes to system operation when these tweaks are not available
in the core functionality of Linux itself.
-Without a specific LSM built into the kernel, the default LSM will be the
-Linux capabilities system. Most LSMs choose to extend the capabilities
-system, building their checks on top of the defined capability hooks.
-For more details on capabilities, see capabilities(7) in the Linux
-man-pages project.
+The Linux capabilities modules will always be included. For more details
+on capabilities, see capabilities(7) in the Linux man-pages project.
+This may be followed by any number of "minor" modules and at most one
+"major" module.
A list of the active security modules can be found by reading
/sys/kernel/security/lsm. This is a comma separated list, and
@@ -29,6 +28,14 @@ order in which checks are made. The capability module will
always
be first, followed by any "minor" modules (e.g. Yama) and then
the one "major" module (e.g. SELinux) if there is one configured.
+Process attributes associated with "major" security modules should
+be accessed and maintained using the special files in the module
+specific subdirectories in /proc/.../attr. The attributes related
+to Smack would be found in /proc/.../attr/smack while the attributes
+for SELinux would be in /proc/.../attr/selinux. Using the files
+found directly in /proc/.../attr (e.g. current) should be avoided.
+These files remain as legacy interfaces.
+
Based on https://lkml.org/lkml/2007/10/26/215,
a new LSM is accepted into the kernel when its intent (a description of
what it tries to protect against and in what cases one would expect to
@@ -38,4 +45,4 @@ that end users and distros can make a more informed decision
about which
LSMs suit their requirements.
For extensive documentation on the available LSM hook interfaces, please
-see include/linux/security.h.
+see include/linux/lsm_hooks.h.
diff --git a/fs/proc/base.c b/fs/proc/base.c
index a11eb71..182bc28 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -131,9 +131,13 @@ struct pid_entry {
#define REG(NAME, MODE, fops) \
NOD(NAME, (S_IFREG|(MODE)), NULL, &fops, {})
#define ONE(NAME, MODE, show) \
- NOD(NAME, (S_IFREG|(MODE)), \
+ NOD(NAME, (S_IFREG|(MODE)), \
NULL, &proc_single_file_operations, \
{ .proc_show = show } )
+#define ATTR(LSM, NAME, MODE) \
+ NOD(NAME, (S_IFREG|(MODE)), \
+ NULL, &proc_pid_attr_operations,\
+ { .lsm = LSM })
/*
* Count the number of hardlinks for the pid_entry table, excluding the .
@@ -2433,7 +2437,7 @@ static ssize_t proc_pid_attr_read(struct file * file,
char __user * buf,
if (!task)
return -ESRCH;
- length = security_getprocattr(task,
+
[PATCH v5 1/3] LSM: Add /sys/kernel/security/lsm
Subject: [PATCH v5 1/3] LSM: Add /sys/kernel/security/lsm
I got tired of having to find indirect ways to
determine what security modules are active on a system.
I have added /sys/kernel/security/lsm, which contains a
comma separated list of the active security modules. No
more groping around in /proc/filesystems, which won't
help if the module doesn't support its own filesystem.
Signed-off-by: Casey Schaufler
---
Documentation/security/LSM.txt | 7 +++
include/linux/lsm_hooks.h | 12
security/apparmor/lsm.c| 3 ++-
security/commoncap.c | 3 ++-
security/inode.c | 26 --
security/loadpin/loadpin.c | 2 +-
security/security.c| 38 ++
security/selinux/hooks.c | 2 +-
security/smack/smack_lsm.c | 2 +-
security/tomoyo/tomoyo.c | 2 +-
security/yama/yama_lsm.c | 2 +-
11 files changed, 82 insertions(+), 17 deletions(-)
diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
index 3db7e67..c2683f2 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/security/LSM.txt
@@ -22,6 +22,13 @@ system, building their checks on top of the defined
capability hooks.
For more details on capabilities, see capabilities(7) in the Linux
man-pages project.
+A list of the active security modules can be found by reading
+/sys/kernel/security/lsm. This is a comma separated list, and
+will always include the capability module. The list reflects the
+order in which checks are made. The capability module will always
+be first, followed by any "minor" modules (e.g. Yama) and then
+the one "major" module (e.g. SELinux) if there is one configured.
+
Based on https://lkml.org/lkml/2007/10/26/215,
a new LSM is accepted into the kernel when its intent (a description of
what it tries to protect against and in what cases one would expect to
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 7ae3976..0bfd441 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1841,6 +1841,7 @@ struct security_hook_list {
struct list_headlist;
struct list_head*head;
union security_list_options hook;
+ char*lsm;
};
/*
@@ -1853,15 +1854,10 @@ struct security_hook_list {
{ .head = &security_hook_heads.HEAD, .hook = { .HEAD = HOOK } }
extern struct security_hook_heads security_hook_heads;
+extern char *lsm_names;
-static inline void security_add_hooks(struct security_hook_list *hooks,
- int count)
-{
- int i;
-
- for (i = 0; i < count; i++)
- list_add_tail_rcu(&hooks[i].list, hooks[i].head);
-}
+extern void security_add_hooks(struct security_hook_list *hooks, int count,
+ char *lsm);
#ifdef CONFIG_SECURITY_SELINUX_DISABLE
/*
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 2660fbc..fb0fb03 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -880,7 +880,8 @@ static int __init apparmor_init(void)
aa_free_root_ns();
goto alloc_out;
}
- security_add_hooks(apparmor_hooks, ARRAY_SIZE(apparmor_hooks));
+ security_add_hooks(apparmor_hooks, ARRAY_SIZE(apparmor_hooks),
+ "apparmor");
/* Report that AppArmor successfully initialized */
apparmor_initialized = 1;
diff --git a/security/commoncap.c b/security/commoncap.c
index e7fadde..d101734 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1090,7 +1090,8 @@ struct security_hook_list capability_hooks[] = {
void __init capability_add_hooks(void)
{
- security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks));
+ security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks),
+ "capability");
}
#endif /* CONFIG_SECURITY */
diff --git a/security/inode.c b/security/inode.c
index 28414b0..235ad82 100644
--- a/security/inode.c
+++ b/security/inode.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
static struct vfsmount *mount;
@@ -208,6 +209,21 @@ void securityfs_remove(struct dentry *dentry)
}
EXPORT_SYMBOL_GPL(securityfs_remove);
+#ifdef CONFIG_SECURITY
+static struct dentry *lsm_dentry;
+static ssize_t lsm_read(struct file *filp, char __user *buf, size_t count,
+ loff_t *ppos)
+{
+ return simple_read_from_buffer(buf, count, ppos, lsm_names,
+ strlen(lsm_names));
+}
+
+static const struct file_operations lsm_ops = {
+ .read = lsm_read,
+ .llseek = generic_file_llseek,
+};
+#endif
+
static int __init securityfs_init(void)
{
int retval;
@@ -217,9 +233,15 @@ static int __init securityfs_init(void)
return retval;
retval = register_filesystem(&fs_type);
-
[PATCH v5 0/3] LSM: security module information improvements
Subject: [PATCH v5 0/3] LSM: security module information improvements Changes from v4: Use kasprintf instead of kzalloc() ... sprintf in more places. More in the documentation. Separate module information in contexts with ",". (not yet visible) Changes from v3: Use kasprintf instead of kzalloc() ... sprintf. Create interfaces that make it possible to deal with process attributes in the face of multiple "major" security modules. Patch 1/3 adds /sys/kernel/security/lsm, which provides a list of the active security modules on the system. $ cat /sys/kernel/security/lsm capability,yama,loadpin,smack Patch 2/3 adds a subdirectory in /proc/.../attr for each security module that exports process attribute data. This allows a program in easily differentiate between the "current" value for Smack and AppArmor. $ cat /proc/self/attr/smack/current System $ cat /proc/self/attr/apparmor/current unconfined Patch 3/3 adds an interface that provides module identified information that otherwise matches the "current" attr. This allows a system with multiple modules to provide the complete security "context" in one place. A (future) system with both Smack and AppArmor might report: $ cat /proc/self/attr/context smack='System',apparmor='unconfined' Signed-off-by: Casey Schaufler --- Documentation/security/LSM.txt | 34 ++-- fs/proc/base.c | 95 +++--- fs/proc/internal.h | 1 + include/linux/lsm_hooks.h | 12 +-- include/linux/security.h | 15 ++-- security/apparmor/lsm.c| 38 +++-- security/commoncap.c | 3 +- security/inode.c | 26 +- security/loadpin/loadpin.c | 2 +- security/security.c| 177 - security/selinux/hooks.c | 22 - security/smack/smack_lsm.c | 22 ++--- security/tomoyo/tomoyo.c | 2 +- security/yama/yama_lsm.c | 2 +- 14 files changed, 395 insertions(+), 56 deletions(-)
Re: [PATCH v3 0/9] reduce memory usage by page_owner
On Fri, 17 Jun 2016 16:57:30 +0900 js1...@gmail.com wrote:
> There was a bug reported by Sasha and minor fixes is needed
> so I send v3.
>
> o fix a bg reported by Sasha (mm/compaction: split freepages
> without holding the zone lock)
> o add code comment for todo list (mm/page_owner: use stackdepot
> to store stacktrace) per Michal
> o add 'inline' keyword (mm/page_alloc: introduce post allocation
> processing on page allocator) per Vlastimil
> o add a patch that clean-up code per Vlastimil
I've gone through v3 patches 2-9 and have plucked out the deltas to
take what-i-had and turn that into what-you-sent. Patch 1/9 has seen a
lot of competing churn in isolate_freepages_block(), so please review
the current version of that, below. Between the "===" markers:
static unsigned long isolate_freepages_block(struct compact_control *cc,
unsigned long *start_pfn,
unsigned long end_pfn,
struct list_head *freelist,
bool strict)
{
int nr_scanned = 0, total_isolated = 0;
struct page *cursor, *valid_page = NULL;
unsigned long flags = 0;
bool locked = false;
unsigned long blockpfn = *start_pfn;
unsigned int order;
cursor = pfn_to_page(blockpfn);
/* Isolate free pages. */
for (; blockpfn < end_pfn; blockpfn++, cursor++) {
int isolated;
struct page *page = cursor;
/*
* Periodically drop the lock (if held) regardless of its
* contention, to give chance to IRQs. Abort if fatal signal
* pending or async compaction detects need_resched()
*/
if (!(blockpfn % SWAP_CLUSTER_MAX)
&& compact_unlock_should_abort(&cc->zone->lock, flags,
&locked, cc))
break;
nr_scanned++;
if (!pfn_valid_within(blockpfn))
goto isolate_fail;
if (!valid_page)
valid_page = page;
/*
* For compound pages such as THP and hugetlbfs, we can save
* potentially a lot of iterations if we skip them at once.
* The check is racy, but we can consider only valid values
* and the only danger is skipping too much.
*/
if (PageCompound(page)) {
unsigned int comp_order = compound_order(page);
if (likely(comp_order < MAX_ORDER)) {
blockpfn += (1UL << comp_order) - 1;
cursor += (1UL << comp_order) - 1;
}
goto isolate_fail;
}
if (!PageBuddy(page))
goto isolate_fail;
/*
* If we already hold the lock, we can skip some rechecking.
* Note that if we hold the lock now, checked_pageblock was
* already set in some previous iteration (or strict is true),
* so it is correct to skip the suitable migration target
* recheck as well.
*/
if (!locked) {
/*
* The zone lock must be held to isolate freepages.
* Unfortunately this is a very coarse lock and can be
* heavily contended if there are parallel allocations
* or parallel compactions. For async compaction do not
* spin on the lock and we acquire the lock as late as
* possible.
*/
locked = compact_trylock_irqsave(&cc->zone->lock,
&flags, cc);
if (!locked)
break;
/* Recheck this is a buddy page under lock */
if (!PageBuddy(page))
goto isolate_fail;
}
/* Found a free page, will break it into order-0 pages */
order = page_order(page);
isolated = __isolate_free_page(page, order);
if (!isolated)
break;
set_page_private(page, order);
total_isolated += isolated;
cc->nr_freepages += isolated;
list_add_tail(&page->lru, freelist);
if (!strict && cc->nr_migratepages <= cc->nr_freepages) {
blockpfn += isolated;
break;
}
/* Advance to the end of split
Re: [PATCH v2 06/24] fs: ext4: Use current_time() for inode timestamps
>> @@ -3727,6 +3727,7 @@ static int ext4_cross_rename(struct inode *old_dir, >> struct dentry *old_dentry, >> }; >> u8 new_file_type; >> int retval; >> + struct timespec ctime; >> >> if ((ext4_encrypted_inode(old_dir) || >> ext4_encrypted_inode(new_dir)) && >> @@ -3829,8 +3830,9 @@ static int ext4_cross_rename(struct inode *old_dir, >> struct dentry *old_dentry, >> * Like most other Unix systems, set the ctime for inodes on a >> * rename. >> */ >> - old.inode->i_ctime = ext4_current_time(old.inode); >> - new.inode->i_ctime = ext4_current_time(new.inode); >> + ctime = current_time(old.inode); >> + old.inode->i_ctime = ctime; >> + new.inode->i_ctime = ctime; >> ext4_mark_inode_dirty(handle, old.inode); >> ext4_mark_inode_dirty(handle, new.inode); >> > > Adding a local variable here looks like it is going to cause us trouble when > we > change the return type of current_time() to timespec64. > > I'd write this as > > new.inode->i_ctime = old.inode->i_ctime; > > instead. This should be fine. There are already instances that use local timespecs for inode time assignments. These can be changed this way: + ctime = vfs_time_to_timespec(current_time(old.inode)); + old.inode->i_ctime = timespec_to_vfs_time(ctime); + new.inode->i_ctime = timespec_to_vfs_time(ctime); This could be a little inefficient, but only temporary. The local variable can be changed to timespec64 when the macros are deleted. I'm trying to make minimal changes. -Deepa
Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data
On Friday, June 24, 2016 09:35:32 AM Hoan Tran wrote: > On Tue, May 31, 2016 at 12:29 PM, Ashwin Chaugule > wrote: > > > > On 27 May 2016 at 12:41, Hoan Tran wrote: > > > Hi Ashwin, > > > > Hi, > > > > > > > > Yes, I saw kernel crash. > > > As cpc_desc_ptr is not NULL, cppc_cpufreq_init() still can pass then > > > crash during cppc_get_perf_caps() access CPPC shared memory. > > > > > > It's not only "PCC channel request fail" can create this issue but > > > "acpi_get_psd() fail" also creates it > > > > > > Thanks > > > Hoan > > > > > > Just for future reference. :) > > > > https://web.archive.org/web/20080722025748/http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt > > > > > > > > > > On Fri, May 27, 2016 at 9:10 AM, Ashwin Chaugule > > > wrote: > > >> On 25 May 2016 at 15:09, Hoan Tran wrote: > > >>> When CPPC fails to request PCC channel, the CPC data is freed > > >>> and cpc_desc_ptr points to the invalid data. This change prevents > > >>> this issue by moving cpc_desc_ptr assignment after PCC channel > > >>> request. > > >>> > > >>> Signed-off-by: Hoan Tran > > >>> --- > > >>> drivers/acpi/cppc_acpi.c | 6 +++--- > > >>> 1 file changed, 3 insertions(+), 3 deletions(-) > > >>> > > >>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c > > >>> index 8adac69..85fd8f7 100644 > > >>> --- a/drivers/acpi/cppc_acpi.c > > >>> +++ b/drivers/acpi/cppc_acpi.c > > >>> @@ -595,9 +595,6 @@ int acpi_cppc_processor_probe(struct acpi_processor > > >>> *pr) > > >>> /* Store CPU Logical ID */ > > >>> cpc_ptr->cpu_id = pr->id; > > >>> > > >>> - /* Plug it into this CPUs CPC descriptor. */ > > >>> - per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr; > > >>> - > > >>> /* Parse PSD data for this CPU */ > > >>> ret = acpi_get_psd(cpc_ptr, handle); > > >>> if (ret) > > >>> @@ -610,6 +607,9 @@ int acpi_cppc_processor_probe(struct acpi_processor > > >>> *pr) > > >>> goto out_free; > > >>> } > > >>> > > >>> + /* Plug PSD data into this CPUs CPC descriptor. */ > > >>> + per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr; > > >>> + > > >> > > >> Are you seeing a real problem without this change? I'm missing where > > >> this pointer is dereferenced if the PCC channel request fails. > > >> > > > > So, after freeing the cpc_ptr, we need to NULL the per-cpu pointer as > > well. Alternately, not assign it until everything passes and rely on > > the static declaration, which is the path you've taken here. > > > > Acked-by: Ashwin Chaugule > > Hi Rafael, > > Do you have plan to apply this patch ? I do now. :-) I've overlooked the Ashwin's ACK, so thanks for the reminder. Thanks, Rafael
mmotm 2016-06-24-15-53 uploaded
The mm-of-the-moment snapshot 2016-06-24-15-53 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (4.x or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 4.7-rc4: (patches marked "*" will be included in linux-next) origin.patch * mmoom_reaper-dont-call-mmput_async-without-atomic_inc_not_zero.patch * oom_reaper-avoid-pointless-atomic_inc_not_zero-usage.patch * selftests-vm-compaction_test-fix-write-to-restore-nr_hugepages.patch * tmpfs-dont-undo-fallocate-past-its-last-page.patch * tree-wide-get-rid-of-__gfp_repeat-for-order-0-allocations-part-i.patch * x86-get-rid-of-superfluous-__gfp_repeat.patch * x86-efi-get-rid-of-superfluous-__gfp_repeat.patch * arm64-get-rid-of-superfluous-__gfp_repeat.patch * arc-get-rid-of-superfluous-__gfp_repeat.patch * mips-get-rid-of-superfluous-__gfp_repeat.patch * nios2-get-rid-of-superfluous-__gfp_repeat.patch * parisc-get-rid-of-superfluous-__gfp_repeat.patch * score-get-rid-of-superfluous-__gfp_repeat.patch * powerpc-get-rid-of-superfluous-__gfp_repeat.patch * sparc-get-rid-of-superfluous-__gfp_repeat.patch * s390-get-rid-of-superfluous-__gfp_repeat.patch * sh-get-rid-of-superfluous-__gfp_repeat.patch * tile-get-rid-of-superfluous-__gfp_repeat.patch * unicore32-get-rid-of-superfluous-__gfp_repeat.patch * jbd2-get-rid-of-superfluous-__gfp_repeat.patch * maintainers-update-calgary-iommu.patch * mm-mempool-kasan-dont-poot-mempool-objects-in-quarantine.patch * mm-slaub-add-__gfp_atomic-to-the-gfp-reclaim-mask.patch * mailmap-antoine-tenarts-email.patch * mailmap-boris-brezillons-email.patch * revert-mm-make-faultaround-produce-old-ptes.patch * revert-mm-disable-fault-around-on-emulated-access-bit-architecture.patch * hugetlb-fix-nr_pmds-accounting-with-shared-page-tables.patch * memcg-mem_cgroup_migrate-may-be-called-with-irq-disabled.patch * memcg-css_alloc-should-return-an-err_ptr-value-on-error.patch * mm-swapc-flush-lru-pvecs-on-compound-page-arrival.patch * mm-hugetlb-clear-compound_mapcount-when-freeing-gigantic-pages.patch * mm-prevent-kasan-false-positives-in-kmemleak.patch * mm-compaction-abort-free-scanner-if-split-fails.patch * ocfs2-disable-bug-assertions-in-reading-blocks.patch * oom-suspend-fix-oom_reaper-vs-oom_killer_disable-race.patch * fs-nilfs2-fix-potential-underflow-in-call-to-crc32_le.patch * tools-vm-slabinfo-fix-spelling-mistake-ocurrences-occurrences.patch * mm-page_owner-use-stackdepot-to-store-stacktrace-fix.patch * autofs-dont-stuck-in-a-loop-if-vfs_write-returns-an-error.patch * init-mainc-fix-initcall_blacklisted-on-ia64-ppc64-and-parisc64.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch * arm-get-rid-of-superfluous-__gfp_repeat.patch * arm-arch-arm-include-asm-pageh-needs-personalityh.patch * dax-use-devm_add_acti
Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi
Hello,
comments below.
On 24.6.2016 05:48, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM, wrote:
>> From: Ondrej Jirman
>>
>> Add label to the first cpu so that it can be referenced
>> from derived dts files.
>>
>> Signed-off-by: Ondrej Jirman
>> ---
>> arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 9938972..82faefc 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -52,7 +52,7 @@
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> - cpu@0 {
>> + cpu0: cpu@0 {
>> compatible = "arm,cortex-a7";
>> device_type = "cpu";
>> reg = <0>;
>
> Can you also set the cpu clock here? It is part of the SoC
> and does not belong in the board DTS files.
Do you mean operating-points, or something else? Different SBCs will
probably require different combinations of operating points just for
safety's sake, because they have different regulators and [some have
botched] thermal designs, so it might make sense to customize it for
differnt boards, and I don't feel adventurous enough setting it for all
H3 boards out there.
Or is this comment related to the missing cpu clock rate message I see
on every boot?
[0.058912] /cpus/cpu@0 missing clock-frequency property
regards,
Ondrej
> Otherwise this one looks good.
>
> ChenYu
>
>> --
>> 2.9.0
>>
signature.asc
Description: OpenPGP digital signature
[GIT PULL] ACPI fix for v4.7-rc5
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.7-rc5 to receive an ACPI update for v4.7-rc5 with top-most commit 2605b98109100f70398115a473ea190ce93fda5e Merge branch 'acpica-fixes' on top of commit 33688abb2802ff3a230bd2441f765477b94cc89e Linux 4.7-rc4 Stable-candidate fix for a deadlock in ACPICA introduced during the 4.5 development cycle by a commit attempting to improve the handling of AML code that doesn't belong to any namespace objects in a given definition block (Lv Zheng). Thanks! --- Lv Zheng (1): ACPICA: Namespace: Fix deadlock triggered by MLC support in dynamic table loading --- drivers/acpi/acpica/exconfig.c | 2 ++ drivers/acpi/acpica/nsparse.c | 9 +++-- 2 files changed, 9 insertions(+), 2 deletions(-)
[GIT PULL] Power management fixes for v4.7-rc5
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.7-rc5 to receive power management fixes for v4.7-rc5 with top-most commit e753f3050935ff5a52069fef802bee72ab19c098 Merge branches 'pm-devfreq-fixes' and 'pm-cpufreq-fixes' on top of commit 33688abb2802ff3a230bd2441f765477b94cc89e Linux 4.7-rc4 Fix for a latent cpufreq driver bug uncovered by a recent ACPICA change and several fixes for the devfreq framework, including one fix for an issue introduced recently. Specifics: - Fix a latent initialization issue in the pcc-cpufreq driver (incorrect initial value of a structure field) that has been uncovered by a recent ACPICA commit (Mike Galbraith). - Add a missing notification in an update_devfreq() error code path forgotten by a recent devfreq commit (Chanwoo Choi). - Fix devfreq device frequency initialization (Lukasz Luba). - Fix an incorrect IS_ERR() check in the devfreq framework discovered by the Smatch checker (Dan Carpenter). - Drop two excessive put_device() calls from the devfreq framework (MyungJoo Ham, Cai Zhiyong). - Fix a possible memory leak in the devfreq framework and drop an unnecessary kfree() invocation from it (MyungJoo Ham). Thanks! --- Cai Zhiyong (1): PM / devfreq: fix double call put_device Chanwoo Choi (1): PM / devfreq: Send the DEVFREQ_POSTCHANGE notification when target() is failed Dan Carpenter (1): PM / devfreq: exynos-nocp: Remove incorrect IS_ERR() check Lukasz Luba (1): PM / devfreq: fix initialization of current frequency in last status Mike Galbraith (1): cpufreq: pcc-cpufreq: Fix doorbell.access_width MyungJoo Ham (3): PM / devfreq: devm_kzalloc to have dev pointer more precisely PM / devfreq: fix duplicated kfree on devfreq pointer PM / devfreq: remove double put_device --- drivers/cpufreq/pcc-cpufreq.c | 2 +- drivers/devfreq/devfreq.c | 27 ++- drivers/devfreq/event/exynos-nocp.c | 3 --- 3 files changed, 15 insertions(+), 17 deletions(-)
Re: [PATCH v6 4/5] arm64: add support for ACPI Low Power Idle(LPI)
On Friday, June 24, 2016 11:04:07 PM Daniel Lezcano wrote:
> On 06/22/2016 04:17 PM, Lorenzo Pieralisi wrote:
> > Hi Sudeep,
> >
> > On Tue, Jun 14, 2016 at 03:48:38PM +0100, Sudeep Holla wrote:
> >> This patch adds appropriate callbacks to support ACPI Low Power Idle
> >> (LPI) on ARM64.
> >>
> >> Now that arm_enter_idle_state is exactly same in both generic ARM{32,64}
> >> CPUIdle driver and ARM64 backend for ACPI processor idle driver, we can
> >> unify it and move to cpuidle-arm.h header.
> >>
> >> Cc: Lorenzo Pieralisi
> >> Cc: Mark Rutland
> >> Cc: Daniel Lezcano
> >> Cc: "Rafael J. Wysocki"
> >> Cc: linux-arm-ker...@lists.infradead.org
> >> Signed-off-by: Sudeep Holla
> >> ---
> >> arch/arm64/kernel/cpuidle.c | 17 +
> >> drivers/cpuidle/cpuidle-arm.c | 23 ++
> >> drivers/firmware/psci.c | 56
> >> +++
> >> include/linux/cpuidle-arm.h | 30 +++
> >> 4 files changed, 105 insertions(+), 21 deletions(-)
> >> create mode 100644 include/linux/cpuidle-arm.h
> >
> > This patch seems fine by me, it would be good if Daniel can have
> > a look too.
> >
> > Some minor comments below.
> >
> > [...]
> >
> >> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> >> index 03e04582791c..c6caa863d156 100644
> >> --- a/drivers/firmware/psci.c
> >> +++ b/drivers/firmware/psci.c
> >> @@ -13,6 +13,7 @@
> >>
> >> #define pr_fmt(fmt) "psci: " fmt
> >>
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -310,11 +311,66 @@ static int psci_dt_cpu_init_idle(struct device_node
> >> *cpu_node, int cpu)
> >>return ret;
> >> }
> >>
> >> +#ifdef CONFIG_ACPI
> >> +#include
> >> +
> >> +static int __maybe_unused psci_acpi_cpu_init_idle(unsigned int cpu)
> >> +{
> >> + int i, count;
> >> + u32 *psci_states;
> >> + struct acpi_processor *pr;
> >> + struct acpi_lpi_state *lpi;
> >> +
> >> + pr = per_cpu(processors, cpu);
> >> + if (unlikely(!pr || !pr->flags.has_lpi))
> >> + return -EINVAL;
> >> +
> >> + /*
> >> + * If the PSCI cpu_suspend function hook has not been initialized
> >> + * idle states must not be enabled, so bail out
> >> + */
> >> + if (!psci_ops.cpu_suspend)
> >> + return -EOPNOTSUPP;
> >> +
> >> + count = pr->power.count - 1;
> >> + if (count <= 0)
> >> + return -ENODEV;
> >> +
> >> + psci_states = kcalloc(count, sizeof(*psci_states), GFP_KERNEL);
> >> + if (!psci_states)
> >> + return -ENOMEM;
> >> +
> >> + for (i = 0; i < count; i++) {
> >> + u32 state;
> >> +
> >> + lpi = &pr->power.lpi_states[i + 1];
> >> + state = lpi->address & 0x;
>
> Why is needed to mask 'address' ?
>
> >> + if (!psci_power_state_is_valid(state)) {
> >> + pr_warn("Invalid PSCI power state %#x\n", state);
> >> + kfree(psci_states);
> >> + return -EINVAL;
> >> + }
> >> + psci_states[i] = state;
> >> + }
> >> + /* Idle states parsed correctly, initialize per-cpu pointer */
> >> + per_cpu(psci_power_state, cpu) = psci_states;
> >> + return 0;
> >
> > Most of the code in this function is FW independent, it would be nice
> > to factor it out and add the respective ACPI/DT helper functions to
> > retrieve idle states count and parameters, we can update it later
> > anyway it is fine by me to leave it as it is.
> >
> >> +}
> >> +#else
> >> +static int __maybe_unused psci_acpi_cpu_init_idle(unsigned int cpu)
> >> +{
> >> + return -EINVAL;
> >> +}
> >> +#endif
> >> +
> >> int psci_cpu_init_idle(unsigned int cpu)
> >> {
> >>struct device_node *cpu_node;
> >>int ret;
> >>
> >> + if (!acpi_disabled)
> >> + return psci_acpi_cpu_init_idle(cpu);
>
> Is it possible the case where there is information in both the DT and in
> ACPI ?
No, it isn't.
It is either-or, never both at the same time.
Thanks,
Rafael
[PATCH v4 2/2] kbuild: Remove stale asm-generic wrappers
When a header file is removed from generic-y (often accompanied by the
addition of an arch specific header), the generated wrapper file will
persist, and in some cases may still take precedence over the new arch
header.
For example commit f1fe2d21f4e1 ("MIPS: Add definitions for extended
context") removed ucontext.h from generic-y in arch/mips/include/asm/,
and added an arch/mips/include/uapi/asm/ucontext.h. The continued use of
the wrapper when reusing a dirty build tree resulted in build failures
in arch/mips/kernel/signal.c:
arch/mips/kernel/signal.c: In function ‘sc_to_extcontext’:
arch/mips/kernel/signal.c:142:12: error: ‘struct ucontext’ has no member named
‘uc_extcontext’
return &uc->uc_extcontext;
^
Fix by detecting and removing wrapper headers in generated header
directories that do not correspond to a filename in generic-y, genhdr-y,
or the newly introduced generated-y.
Reported-by: Jacek Anaszewski
Reported-by: Hauke Mehrtens
Reported-by: Heinrich Schuchardt
Signed-off-by: James Hogan
Acked-by: Arnd Bergmann
Acked-by: Florian Fainelli
Cc: Michal Marek
Cc: Arnd Bergmann
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Florian Fainelli
Cc: linux-kbu...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
Changes in v4:
- None (resend).
Changes in v3:
- Ensure FORCE actually gets marked .PHONY.
Changes in v2:
- Rewrite a bit, drawing inspiration from Makefile.headersinst.
- Exclude genhdr-y and generated-y (thanks to kbuild test robot).
---
scripts/Makefile.asm-generic | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.asm-generic b/scripts/Makefile.asm-generic
index 045e0098e962..e4d017d53819 100644
--- a/scripts/Makefile.asm-generic
+++ b/scripts/Makefile.asm-generic
@@ -13,11 +13,26 @@ include scripts/Kbuild.include
# Create output directory if not already present
_dummy := $(shell [ -d $(obj) ] || mkdir -p $(obj))
+# Stale wrappers when the corresponding files are removed from generic-y
+# need removing.
+generated-y := $(generic-y) $(genhdr-y) $(generated-y)
+all-files := $(patsubst %, $(obj)/%, $(generated-y))
+old-headers := $(wildcard $(obj)/*.h)
+unwanted := $(filter-out $(all-files),$(old-headers))
+
quiet_cmd_wrap = WRAP$@
cmd_wrap = echo "\#include " >$@
-all: $(patsubst %, $(obj)/%, $(generic-y))
+quiet_cmd_remove = REMOVE $(unwanted)
+cmd_remove = rm -f $(unwanted)
+
+all: $(patsubst %, $(obj)/%, $(generic-y)) FORCE
+ $(if $(unwanted),$(call cmd,remove),)
@:
$(obj)/%.h:
$(call cmd,wrap)
+
+PHONY += FORCE
+.PHONY: $(PHONY)
+FORCE: ;
--
2.4.10
[PATCH v4 1/2] kbuild, x86: Track generated headers with generated-y
Track generated header files which aren't already in genhdr-y, alongside generic-y wrappers in the */include/generated/[uapi/]asm/ directories. Currently only x86 generates extra headers in these directories, for the purposes of enumerating system calls for different ABIs, and xen hypercalls. This will allow the asm-generic wrapper handling code to remove stale wrappers when files are removed from generic-y, without also removing these headers which are generated separately. Reported-by: kbuild test robot Signed-off-by: James Hogan Acked-by: Arnd Bergmann Cc: Michal Marek Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Jonathan Corbet Cc: linux-kbu...@vger.kernel.org Cc: x...@kernel.org Cc: linux-...@vger.kernel.org --- Changes in v4: - None (resend). Changes in v2: - New patch (thanks to kbuild test robot). --- Documentation/kbuild/makefiles.txt | 14 ++ arch/x86/include/asm/Kbuild| 6 ++ 2 files changed, 20 insertions(+) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 13f888a02a3d..385a5ef41c17 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -47,6 +47,7 @@ This document describes the Linux kernel Makefiles. --- 7.2 genhdr-y --- 7.3 destination-y --- 7.4 generic-y + --- 7.5 generated-y === 8 Kbuild Variables === 9 Makefile language @@ -1319,6 +1320,19 @@ See subsequent chapter for the syntax of the Kbuild file. Example: termios.h #include + --- 7.5 generated-y + + If an architecture generates other header files alongside generic-y + wrappers, and not included in genhdr-y, then generated-y specifies + them. + + This prevents them being treated as stale asm-generic wrappers and + removed. + + Example: + #arch/x86/include/asm/Kbuild + generated-y += syscalls_32.h + === 8 Kbuild Variables The top Makefile exports the following variables: diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild index aeac434c9feb..2cfed174e3c9 100644 --- a/arch/x86/include/asm/Kbuild +++ b/arch/x86/include/asm/Kbuild @@ -1,5 +1,11 @@ +generated-y += syscalls_32.h +generated-y += syscalls_64.h +generated-y += unistd_32_ia32.h +generated-y += unistd_64_x32.h +generated-y += xen-hypercalls.h + genhdr-y += unistd_32.h genhdr-y += unistd_64.h genhdr-y += unistd_x32.h -- 2.4.10
[PATCH v4 0/2] kbuild: Remove stale asm-generic wrappers
This patchset attempts to fix kbuild to automatically remove stale asm-generic wrappers, i.e. when files are removed from generic-y and added directly into arch/*/include/uapi/asm/, but where the existing wrapper in arch/*/include/generated/asm/ continues to be used. MIPS was recently burned by this in v4.3 (see patch 2), with continuing reports of build failures when people upgrade their trees, which go away after arch/mips/include/generated is removed (or reportedly make mrproper/distclean). It is particularly irritating during bisection. Since v2 I've seen other cases of this breaking MIPS build, and testing on x86_64, starting a build first on v4.0 and then on mainline with this patchset shows one stale generated header: REMOVE arch/x86/include/generated/asm/scatterlist.h Changes in v4: - None (resend on Thomas Gleixner's request). Changes in v3: - Ensure FORCE actually gets marked .PHONY. Changes in v2: - New patch 1 to add tracking of generated headers that aren't generic-y wrappers, via generated-y, particularly for x86 (thanks to kbuild test robot). - Rewrite a bit, drawing inspiration from Makefile.headersinst. - Exclude genhdr-y and generated-y (thanks to kbuild test robot). James Hogan (2): kbuild, x86: Track generated headers with generated-y kbuild: Remove stale asm-generic wrappers Documentation/kbuild/makefiles.txt | 14 ++ arch/x86/include/asm/Kbuild| 6 ++ scripts/Makefile.asm-generic | 17 - 3 files changed, 36 insertions(+), 1 deletion(-) Cc: Michal Marek Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Jonathan Corbet Cc: Arnd Bergmann Cc: Ralf Baechle Cc: Paul Burton Cc: Florian Fainelli Cc: Heinrich Schuchardt Cc: linux-kbu...@vger.kernel.org Cc: x...@kernel.org Cc: linux-...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-m...@linux-mips.org -- 2.4.10
Re: [linux-sunxi] [PATCH 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One
Hi Julian,
thank you for the review. You're right. I added the pinctrl client
nodes. Also the patches were split incorrectly, so I fixed that too.
regards,
Ondrej
On 24.6.2016 04:51, Julian Calaby wrote:
> Hi Ondrej,
>
> On Fri, Jun 24, 2016 at 5:21 AM, wrote:
>> From: Ondrej Jirman
>>
>> Xulong Orange Pi One uses GPIO based regulator that
>> switches between two voltages: 1.1V and 1.3V. The
>> regulator is controlled from the PL6 pin.
>>
>> Signed-off-by: Ondrej Jirman
>> ---
>> arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index 0adf932..ce4ba91 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -88,6 +88,25 @@
>> gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
>> };
>> };
>> +
>> + vdd_soc: gpio-regulator {
>> + compatible = "regulator-gpio";
>> +
>> + regulator-name = "soc-vdd-supply";
>> + regulator-min-microvolt = <110>;
>> + regulator-max-microvolt = <130>;
>> + regulator-boot-on;
>> + regulator-type = "voltage";
>> +
>> + gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>;
>> + states = <110 0x0
>> + 130 0x1>;
>> +
>> + startup-delay-us = <10>;
>> + enable-active-high;
>
> Don't you need to reference the new pinctl node in this one?
>
> Thanks,
>
signature.asc
Description: OpenPGP digital signature
Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel
Hi Peter, I have compiled your version of linux kernel and run the SPECjvm2008 tests. Results are fine, performance is at the level of 4.6 kernel. $ git rev-parse HEAD 02548776ded1185e6e16ad0a475481e982741ee9 Jirka On Fri, Jun 24, 2016 at 5:54 PM, Peter Zijlstra wrote: > On Fri, Jun 24, 2016 at 03:42:26PM +0200, Peter Zijlstra wrote: >> On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote: >> > > --- a/kernel/sched/fair.c >> > > +++ b/kernel/sched/fair.c >> > > @@ -2484,7 +2484,7 @@ static inline long calc_tg_weight(struct >> > > task_group *tg, struct cfs_rq *cfs_rq) >> > > */ >> > > tg_weight = atomic_long_read(&tg->load_avg); >> > > tg_weight -= cfs_rq->tg_load_avg_contrib; >> > > - tg_weight += cfs_rq->load.weight; >> > > + tg_weight += cfs_rq->avg.load_avg; >> > >> > IIUC, you are reverting >> > commit fde7d22e01aa (sched/fair: Fix overly small weight for >> > interactive group entities) >> >> Hurm.. looking at that commit again, that seems to wreck >> effective_load(), since that doesn't compensate. >> >> Maybe I'll remove calc_tg_weight and open code its slightly different >> usages in the two sites. > > OK, sorry for not actually posting, but I need to run. Please find the > two patches in: > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/urgent
Re: [PATCH v3 0/6] watchdog: add watchdog pretimeout framework
Hi Wolfram, Guenter, On 24.06.2016 16:45, Guenter Roeck wrote: > On 06/24/2016 02:46 AM, Wolfram Sang wrote: >> On Tue, Jun 07, 2016 at 08:38:41PM +0300, Vladimir Zapolskiy wrote: >>> The change adds a simple watchdog pretimeout framework infrastructure, >>> its purpose is to allow users to select a desired handling of watchdog >>> pretimeout events, which may be generated by a watchdog driver. >> >> Any news? We'd really like to have it in 4.8, at least the non-sleeping >> stuff. >> I continued to cut the change into smaller pieces, but then in a series a lot of code copy-paste cases between files appear, so eventually I think that the essential part should be submitted undivided. > Kind of cutting it close. v4 would have to be quite clean for this to happen, > and arrive very soon. I don't think it would be a good idea to rush this in. > Unfortunately the task didn't get enough priority on my end due to something else, anyway it is not abandoned. Guenter, some relatively small preliminary parts from Wolfram based on Robin's work can be included into v4.8 IMHO. -- With best wishes, Vladimir
[GIT PULL] bugfixes for 4.7
Please pull the following nfsd changes from the nfsd-4.7-2 tag at: git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.7-2 --b. Fix missing server-side permission checks on setting NFS ACLs. Andreas Gruenbacher (1): posix_acl: Add set_posix_acl Ben Hutchings (1): nfsd: check permissions when setting ACLs fs/nfsd/nfs2acl.c | 20 ++-- fs/nfsd/nfs3acl.c | 16 +++- fs/nfsd/nfs4acl.c | 16 fs/posix_acl.c| 42 +++--- 4 files changed, 48 insertions(+), 46 deletions(-)
Re: [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey
On Fri, Jun 24, 2016 at 11:18:04AM +0200, Neil Armstrong wrote:
> In order to support pwrkey for Qualcomm MDM9615 SoC, add support
> for the pm8018 pwrkey in pmic8xxx-pwrkey.
>
> Reviewed-by: Bjorn Andersson
> Signed-off-by: Neil Armstrong
NAK.
> ---
> Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt | 1 +
> drivers/input/misc/pmic8xxx-pwrkey.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
> b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
> index 588536c..9e530e2 100644
> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
> @@ -8,6 +8,7 @@ PROPERTIES
> Definition: must be one of:
> "qcom,pm8058-pwrkey"
> "qcom,pm8921-pwrkey"
> + "qcom,pm8018-pwrkey"
>
> - reg:
> Usage: required
> diff --git a/drivers/input/misc/pmic8xxx-pwrkey.c
> b/drivers/input/misc/pmic8xxx-pwrkey.c
> index 67aab86..f6f9b87 100644
> --- a/drivers/input/misc/pmic8xxx-pwrkey.c
> +++ b/drivers/input/misc/pmic8xxx-pwrkey.c
> @@ -446,6 +446,7 @@ static int pmic8xxx_pwrkey_remove(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id pm8xxx_pwr_key_id_table[] = {
> + { .compatible = "qcom,pm8018-pwrkey", .data = &pm8921_pwrkey_shutdown },
> { .compatible = "qcom,pm8058-pwrkey", .data = &pm8058_pwrkey_shutdown },
> { .compatible = "qcom,pm8921-pwrkey", .data = &pm8921_pwrkey_shutdown },
> { }
> --
> 1.9.1
>
--
Dmitry
Re: [PATCH 2/4] input: touchscreen: crtouch_ts: Add driver
Hi Anthony,
On Fri, Jun 24, 2016 at 03:44:44PM -0400, Anthony Felice wrote:
> Add driver for the Vybrid Tower CRTouch-based touchscreen. This is
> required for the touchscreen on the TWR-LCD-RGB to work on the Vybrid
> Tower platform.
>
> There is a known issue with this driver: rarely, SW1 on the TWR-LCD-RGB
> module needs to be pressed in order for the touchscreen to begin
> functioning.
Hmm. Could it be that you want level interrupt and not edge? Or maybe
you want to read state after requesting interrupt?
>
> Signed-off-by: Anthony Felice
> ---
> .../bindings/input/touchscreen/crtouch_ts.txt | 14 ++
> drivers/input/touchscreen/Kconfig | 10 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/crtouch_ts.c | 279
> +
> 4 files changed, 304 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
> create mode 100644 drivers/input/touchscreen/crtouch_ts.c
>
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
> b/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
> new file mode 100644
> index 000..cfb966c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt
> @@ -0,0 +1,14 @@
> +* Freescale CRTOUCH based touchscreen
> +
> +Required Properties:
> +- compatible must be fsl,crtouch_ts
> +- reg: I2C address of the touchscreen
> +- irq-gpio: GPIO to use as event IRQ
> +
> +Example:
> +
> + touch: crtouch@49 {
> + compatible = "fsl,crtouch_ts";
> + reg = <0x49>;
> + irq-gpio = <&gpio0 21 GPIO_ACTIVE_HIGH>;
You are not using it as gpio but only as interrupt source, so please
set it up as regular interrupt and let I2C core set it up for you so
that you will only need to call request_irq(client->irq, ...)
interrupts = <&gpio0 21 IRQ_TYPE_EDGE_FALLING>;
> + };
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 8ecdc38..799e342 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1155,4 +1155,14 @@ config TOUCHSCREEN_ROHM_BU21023
> To compile this driver as a module, choose M here: the
> module will be called bu21023_ts.
>
> +config TOUCHSCREEN_CRTOUCH
> + tristate "Freescale CRTOUCH based touchscreen"
> + depends on I2C
> + help
> + Say Y here if you have a CRTOUCH based touchscreen
> + controller.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called crtouch_ts.
> +
> endif
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index f42975e..8cb0a7a 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -95,3 +95,4 @@ obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
> obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
> obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
> obj-$(CONFIG_TOUCHSCREEN_ROHM_BU21023) += rohm_bu21023.o
> +obj-$(CONFIG_TOUCHSCREEN_CRTOUCH)+= crtouch_ts.o
> diff --git a/drivers/input/touchscreen/crtouch_ts.c
> b/drivers/input/touchscreen/crtouch_ts.c
> new file mode 100644
> index 000..bb87a8e
> --- /dev/null
> +++ b/drivers/input/touchscreen/crtouch_ts.c
> @@ -0,0 +1,279 @@
> +/*
> + * Driver for Freescale Semiconductor CRTOUCH - A Resistive and Capacitive
> + * touch device with i2c interface
> + *
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Resistive touch sense status registers */
> +#define RES_STA_ERROR0x00
> +#define RES_STA_STATUS1 0x01
> +#define RES_STA_STATUS2 0x02
> +#define RES_STA_X_MSB0x03
> +#define RES_STA_X_LSB0x04
> +#define RES_STA_Y_MSB0x05
> +#define RES_STA_Y_LSB0x06
> +#define RES_STA_PRES_MSB 0x07
> +#define RES_STA_RRES_LSB 0x08
> +#define RES_STA_FIFO_STATUS 0x09
> +#define RES_STA_FIFO_X_MSB 0x0a
> +#define RES_STA_FIFO_X_LSB 0x0b
> +#define RES_STA_FIFO_Y_MSB 0x0c
> +#define RES_STA_FIFO_Y_LSB 0x0d
> +#define RES_STA_FIFO_PRES_MSB0x0e
> +#define RES_STA_FIFO_PRES_LSB0x0f
> +#define RES_STA_UART_BRATE_MSB 0x10
> +#define RES_STA_UART_BRATE_MID 0
Re: [PATCH] mfd: intel-lpss: fix compilation issue if PM_SLEEP is not set
On 24.06.2016 11:28, Andy Shevchenko wrote: > On Fri, 2016-06-24 at 03:11 +0300, Vladimir Zapolskiy wrote: >> If kernel build configuration has enabled CONFIG_PM and unset >> CONFIG_PM_SLEEP, then intel-lpss-pci.c and intel-lpss-acpi.c can not >> be compiled due to a missing INTEL_LPSS_SLEEP_PM_OPS macro >> declaration: >> >> drivers/mfd/intel-lpss-pci.c:63:8: error: undefined identifier >> 'INTEL_LPSS_SLEEP_PM_OPS' >> drivers/mfd/intel-lpss-pci.c:63:58: error: ‘INTEL_LPSS_SLEEP_PM_OPS’ >> undeclared here (not in a function) > > And may I ask what ancient kernel you are using? > > commit 47b91923ea41288751e83a5b080576085a831333 > Author: Andy Shevchenko > Date: Mon Sep 14 11:32:47 2015 +0300 > > mfd: intel-lpss: Fix build error when !CONFIG_PM_SLEEP The original driver was backported to 4.1 Thanks for the reference to a fixup, I'll backport it as well. Lee, please ignore this change. -- With best wishes, Vladimir
Ignore these, sorry!
Sorry about that; I accidentally did a git send-email with some older patches leftover in my patch folder. Just ignore this thread On Fri, 2016-06-24 at 17:45 -0400, Lyude wrote: > Latest version of: > > https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.htm > l > > The only patch that's changed here is 4/4, the rest are just being > sent so that > they can be in one thread to make things easier for reviewers > > Lyude (4): > drm/i915/vlv: Make intel_crt_reset() per-encoder > drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init() > drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug() > drm/i915: Enable polling when we don't have hpd > > drivers/gpu/drm/i915/i915_drv.c | 3 + > drivers/gpu/drm/i915/i915_drv.h | 5 ++ > drivers/gpu/drm/i915/intel_crt.c| 28 ++-- > drivers/gpu/drm/i915/intel_drv.h| 4 +- > drivers/gpu/drm/i915/intel_hotplug.c| 117 > > drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +++ > 6 files changed, 148 insertions(+), 18 deletions(-) > -- Cheers, Lyude
[PATCH 1/2 RESEND] drm/radeon: Poll for both connect/disconnect on analog connectors
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.
Easy way to reproduce:
- Grab a machine with a radeon GPU and a VGA port
- Plug a monitor into the VGA port, wait for it to update the connector
from disconnected to connected
- Disconnect the monitor on VGA, a hotplug event is never sent for the
removal of the connector.
Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good
idea since doing VGA polling can sometimes result in having to mess with
the DAC voltages to figure out whether or not there's actually something
there since VGA doesn't have HPD. Doing this would have the potential of
showing visible artifacts on the screen every time we ran a poll while a
VGA display was connected. Luckily, radeon_vga_detect() only resorts to
this sort of polling if the poll is forced, and DRM's polling helper
doesn't force it's polls.
Additionally, this removes some assignments to connector->polled that
weren't actually doing anything.
Cc: sta...@vger.kernel.org
Signed-off-by: Lyude
---
drivers/gpu/drm/radeon/radeon_connectors.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 81a63d7..b79f3b0 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -2064,7 +2064,6 @@ radeon_add_atom_connector(struct drm_device *dev,
RADEON_OUTPUT_CSC_BYPASS);
/* no HPD on analog connectors */
radeon_connector->hpd.hpd = RADEON_HPD_NONE;
- connector->polled = DRM_CONNECTOR_POLL_CONNECT;
connector->interlace_allowed = true;
connector->doublescan_allowed = true;
break;
@@ -2314,8 +2313,10 @@ radeon_add_atom_connector(struct drm_device *dev,
}
if (radeon_connector->hpd.hpd == RADEON_HPD_NONE) {
- if (i2c_bus->valid)
- connector->polled = DRM_CONNECTOR_POLL_CONNECT;
+ if (i2c_bus->valid) {
+ connector->polled = DRM_CONNECTOR_POLL_CONNECT |
+ DRM_CONNECTOR_POLL_DISCONNECT;
+ }
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
@@ -2391,7 +2392,6 @@ radeon_add_legacy_connector(struct drm_device *dev,
1);
/* no HPD on analog connectors */
radeon_connector->hpd.hpd = RADEON_HPD_NONE;
- connector->polled = DRM_CONNECTOR_POLL_CONNECT;
connector->interlace_allowed = true;
connector->doublescan_allowed = true;
break;
@@ -2476,10 +2476,13 @@ radeon_add_legacy_connector(struct drm_device *dev,
}
if (radeon_connector->hpd.hpd == RADEON_HPD_NONE) {
- if (i2c_bus->valid)
- connector->polled = DRM_CONNECTOR_POLL_CONNECT;
+ if (i2c_bus->valid) {
+ connector->polled = DRM_CONNECTOR_POLL_CONNECT |
+ DRM_CONNECTOR_POLL_DISCONNECT;
+ }
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
+
connector->display_info.subpixel_order = subpixel_order;
drm_connector_register(connector);
}
--
2.7.4
[PATCH 2/2 RESEND] drm/amdgpu: Poll for both connect/disconnect on analog connectors
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.
Easy way to reproduce:
- Grab a machine with an AMD GPU and a VGA port
- Plug a monitor into the VGA port, wait for it to update the connector
from disconnected to connected
- Disconnect the monitor on VGA, a hotplug event is never sent for the
removal of the connector.
Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good
idea since doing VGA polling can sometimes result in having to mess with
the DAC voltages to figure out whether or not there's actually something
there since VGA doesn't have HPD. Doing this would have the potential of
showing visible artifacts on the screen every time we ran a poll while a
VGA display was connected. Luckily, amdgpu_vga_detect() only resorts to
this sort of polling if the poll is forced, and DRM's polling helper
doesn't force it's polls.
Additionally, this removes some assignments to connector->polled that
weren't actually doing anything.
Cc: sta...@vger.kernel.org
Signed-off-by: Lyude
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index cb07da4..ff0b55a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1690,7 +1690,6 @@ amdgpu_connector_add(struct amdgpu_device *adev,
DRM_MODE_SCALE_NONE);
/* no HPD on analog connectors */
amdgpu_connector->hpd.hpd = AMDGPU_HPD_NONE;
- connector->polled = DRM_CONNECTOR_POLL_CONNECT;
connector->interlace_allowed = true;
connector->doublescan_allowed = true;
break;
@@ -1893,8 +1892,10 @@ amdgpu_connector_add(struct amdgpu_device *adev,
}
if (amdgpu_connector->hpd.hpd == AMDGPU_HPD_NONE) {
- if (i2c_bus->valid)
- connector->polled = DRM_CONNECTOR_POLL_CONNECT;
+ if (i2c_bus->valid) {
+ connector->polled = DRM_CONNECTOR_POLL_CONNECT |
+ DRM_CONNECTOR_POLL_DISCONNECT;
+ }
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
--
2.7.4
Re: [PATCH 1/2] drm/radeon: Poll for both connect/disconnect on analog connectors
Whoops, very sorry about this! I ran git send-email, and it looks like
I had forgotten to remove some other patches in my patches/ folder.
Going to resend this to avoid confusing anyone trying to review this.
On Fri, 2016-06-24 at 17:45 -0400, Lyude wrote:
> DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
> disconnections. Because of this, we end up losing hotplug polling for
> analog connectors once they get connected.
>
> Easy way to reproduce:
> - Grab a machine with a radeon GPU and a VGA port
> - Plug a monitor into the VGA port, wait for it to update the
> connector
> from disconnected to connected
> - Disconnect the monitor on VGA, a hotplug event is never sent for
> the
> removal of the connector.
>
> Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a
> good
> idea since doing VGA polling can sometimes result in having to mess
> with
> the DAC voltages to figure out whether or not there's actually
> something
> there since VGA doesn't have HPD. Doing this would have the potential
> of
> showing visible artifacts on the screen every time we ran a poll
> while a
> VGA display was connected. Luckily, radeon_vga_detect() only resorts
> to
> this sort of polling if the poll is forced, and DRM's polling helper
> doesn't force it's polls.
>
> Additionally, this removes some assignments to connector->polled that
> weren't actually doing anything.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lyude
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 81a63d7..b79f3b0 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -2064,7 +2064,6 @@ radeon_add_atom_connector(struct drm_device
> *dev,
> RADEON_OU
> TPUT_CSC_BYPASS);
> /* no HPD on analog connectors */
> radeon_connector->hpd.hpd = RADEON_HPD_NONE;
> - connector->polled =
> DRM_CONNECTOR_POLL_CONNECT;
> connector->interlace_allowed = true;
> connector->doublescan_allowed = true;
> break;
> @@ -2314,8 +2313,10 @@ radeon_add_atom_connector(struct drm_device
> *dev,
> }
>
> if (radeon_connector->hpd.hpd == RADEON_HPD_NONE) {
> - if (i2c_bus->valid)
> - connector->polled =
> DRM_CONNECTOR_POLL_CONNECT;
> + if (i2c_bus->valid) {
> + connector->polled =
> DRM_CONNECTOR_POLL_CONNECT |
> + DRM_CONNECTOR_POLL_DISCO
> NNECT;
> + }
> } else
> connector->polled = DRM_CONNECTOR_POLL_HPD;
>
> @@ -2391,7 +2392,6 @@ radeon_add_legacy_connector(struct drm_device
> *dev,
> 1);
> /* no HPD on analog connectors */
> radeon_connector->hpd.hpd = RADEON_HPD_NONE;
> - connector->polled = DRM_CONNECTOR_POLL_CONNECT;
> connector->interlace_allowed = true;
> connector->doublescan_allowed = true;
> break;
> @@ -2476,10 +2476,13 @@ radeon_add_legacy_connector(struct drm_device
> *dev,
> }
>
> if (radeon_connector->hpd.hpd == RADEON_HPD_NONE) {
> - if (i2c_bus->valid)
> - connector->polled =
> DRM_CONNECTOR_POLL_CONNECT;
> + if (i2c_bus->valid) {
> + connector->polled =
> DRM_CONNECTOR_POLL_CONNECT |
> + DRM_CONNECTOR_POLL_DISCO
> NNECT;
> + }
> } else
> connector->polled = DRM_CONNECTOR_POLL_HPD;
> +
> connector->display_info.subpixel_order = subpixel_order;
> drm_connector_register(connector);
> }
--
Cheers,
Lyude
Re: [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3
Thanks, I've incorporated all the suggestions (and more :)), except for the threaded IRQ, which si expalined below. regards, Ondrej On 24.6.2016 05:09, Chen-Yu Tsai wrote: > Hi, > > On Fri, Jun 24, 2016 at 3:20 AM, wrote: >> From: Ondrej Jirman >> > > The subject could read: > > thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3 > >> This patch adds support for the sun8i thermal sensor on >> Allwinner H3 SoC. >> >> Signed-off-by: Ondřej Jirman >> --- >> drivers/thermal/Kconfig | 7 ++ >> drivers/thermal/Makefile| 1 + >> drivers/thermal/sun8i_ths.c | 295 >> >> 3 files changed, 303 insertions(+) >> create mode 100644 drivers/thermal/sun8i_ths.c >> >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index 2d702ca..3de0f8d 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -351,6 +351,13 @@ config MTK_THERMAL >> Enable this option if you want to have support for thermal >> management >> controller present in Mediatek SoCs >> >> +config SUN8I_THS >> + tristate "sun8i THS driver" > > Explain THS. > >> + depends on MACH_SUN8I >> + depends on OF >> + help >> + Enable this to support thermal reporting on some newer Allwinner >> SoCs. >> + >> menu "Texas Instruments thermal drivers" >> depends on ARCH_HAS_BANDGAP || COMPILE_TEST >> depends on HAS_IOMEM >> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >> index 10b07c1..7261ee8 100644 >> --- a/drivers/thermal/Makefile >> +++ b/drivers/thermal/Makefile >> @@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM) += tegra/ >> obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o >> obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o >> obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o >> +obj-$(CONFIG_SUN8I_THS)+= sun8i_ths.o >> diff --git a/drivers/thermal/sun8i_ths.c b/drivers/thermal/sun8i_ths.c >> new file mode 100644 >> index 000..618ccc3 >> --- /dev/null >> +++ b/drivers/thermal/sun8i_ths.c >> @@ -0,0 +1,295 @@ >> +/* >> + * sun8i THS driver > > Explain THS. > >> + * >> + * Copyright (C) 2016 Ondřej Jirman >> + * Based on the work of Josef Gajdusek >> + * >> + * This software is licensed under the terms of the GNU General Public >> + * License version 2, as published by the Free Software Foundation, and >> + * may be copied, distributed, and modified under those terms. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define THS_H3_CTRL0 0x00 >> +#define THS_H3_CTRL2 0x40 >> +#define THS_H3_INT_CTRL0x44 >> +#define THS_H3_STAT0x48 >> +#define THS_H3_FILTER 0x70 >> +#define THS_H3_CDATA 0x74 >> +#define THS_H3_DATA0x80 >> + >> +#define THS_H3_CTRL0_SENSOR_ACQ0_OFFS 0 >> +#define THS_H3_CTRL0_SENSOR_ACQ0(x) \ >> +((x) << THS_H3_CTRL0_SENSOR_ACQ0_OFFS) >> +#define THS_H3_CTRL2_SENSE_EN_OFFS 0 >> +#define THS_H3_CTRL2_SENSE_EN \ >> +BIT(THS_H3_CTRL2_SENSE_EN_OFFS) >> +#define THS_H3_CTRL2_SENSOR_ACQ1_OFFS 16 >> +#define THS_H3_CTRL2_SENSOR_ACQ1(x) \ >> +((x) << THS_H3_CTRL2_SENSOR_ACQ1_OFFS) >> + >> +#define THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS8 >> +#define THS_H3_INT_CTRL_DATA_IRQ_EN \ >> + BIT(THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS) >> +#define THS_H3_INT_CTRL_THERMAL_PER_OFFS12 >> +#define THS_H3_INT_CTRL_THERMAL_PER(x) \ >> + ((x) << THS_H3_INT_CTRL_THERMAL_PER_OFFS) >> + >> +#define THS_H3_STAT_DATA_IRQ_STS_OFFS 8 >> +#define THS_H3_STAT_DATA_IRQ_STS \ >> +BIT(THS_H3_STAT_DATA_IRQ_STS_OFFS) >> + >> +#define THS_H3_FILTER_TYPE_OFFS 0 >> +#define THS_H3_FILTER_TYPE(x) \ >> +((x) << THS_H3_FILTER_TYPE_OFFS) >> +#define THS_H3_FILTER_EN_OFFS 2 >> +#define THS_H3_FILTER_EN \ >> +BIT(THS_H3_FILTER_EN_OFFS) > > Is it really necessary to split the lines of all the macros? > It makes it harder to find and read stuff. > > You're also not using any of the *_OFFS macros in the actual code, > so just drop them. > >> + >> +#define THS_H3_CLK_IN 4000 /* Hz */ >> +#define THS_H3_DATA_PERIOD 330 /* ms */ >> + >> +#define THS_H3_FILTER_TYPE_VALUE 2 /* average over 2^(n+1) >> samples */ >> +#define THS_H3_FILTER_DIV (1 << >> (THS_H3_FILTER_TYPE_VALUE + 1)) >> +#define THS_H3_INT_CTRL_THERMAL_PER_VALUE \ >> + (THS_H3_DATA_PERIOD * (THS_H3_CLK_IN / 1000) / THS_H3_FILTER_DIV / >> 4096 - 1) >> +#define THS_H3_CTRL0_SENSOR_ACQ0_VALUE
Re: [PATCH v9 2/2] Input: synaptics-rmi4 - add SMBus support
Hi, [auto build test WARNING on wsa/i2c/for-next] [also build test WARNING on v4.7-rc4 next-20160624] [cannot apply to input/next] [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/Benjamin-Tissoires/i2c-i801-add-support-of-Host-Notify/20160624-224821 base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux i2c/for-next coccinelle warnings: (new ones prefixed by >>) >> drivers/input/rmi4/rmi_smbus.c:448:3-8: No need to set .owner here. The core >> will do it. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] Input: fix platform_no_drv_owner.cocci warnings
drivers/input/rmi4/rmi_smbus.c:448:3-8: No need to set .owner here. The core
will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: Benjamin Tissoires
Signed-off-by: Fengguang Wu
---
rmi_smbus.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/input/rmi4/rmi_smbus.c
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -445,7 +445,6 @@ MODULE_DEVICE_TABLE(i2c, rmi_id);
static struct i2c_driver rmi_smb_driver = {
.driver = {
- .owner = THIS_MODULE,
.name = "rmi4_smbus",
.pm = &rmi_smb_pm,
.resume = rmi_smb_resume,
[PATCH v6 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder
This lets call intel_crt_reset() in contexts where IRQs are disabled and
as such, can't hold the locks required to work with the connectors.
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Acked-by: Daniel Vetter
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_crt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index e115bcc..dfcd718 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,11 +713,11 @@ static int intel_crt_set_property(struct drm_connector
*connector,
return 0;
}
-static void intel_crt_reset(struct drm_connector *connector)
+static void intel_crt_reset(struct drm_encoder *encoder)
{
- struct drm_device *dev = connector->dev;
+ struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crt *crt = intel_attached_crt(connector);
+ struct intel_crt *crt = intel_encoder_to_crt(to_intel_encoder(encoder));
if (INTEL_INFO(dev)->gen >= 5) {
u32 adpa;
@@ -739,7 +739,6 @@ static void intel_crt_reset(struct drm_connector *connector)
*/
static const struct drm_connector_funcs intel_crt_connector_funcs = {
- .reset = intel_crt_reset,
.dpms = drm_atomic_helper_connector_dpms,
.detect = intel_crt_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -757,6 +756,7 @@ static const struct drm_connector_helper_funcs
intel_crt_connector_helper_funcs
};
static const struct drm_encoder_funcs intel_crt_enc_funcs = {
+ .reset = intel_crt_reset,
.destroy = intel_encoder_destroy,
};
@@ -901,5 +901,5 @@ void intel_crt_init(struct drm_device *dev)
dev_priv->fdi_rx_config = I915_READ(FDI_RX_CTL(PIPE_A)) &
fdi_config;
}
- intel_crt_reset(connector);
+ intel_crt_reset(&crt->base.base);
}
--
2.5.5
[PATCH v6 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA get cleared and
consequently VGA hotplugging gets disabled. This causes bugs such as one
we found on an Intel NUC, where doing the following sequence of
hotplugs:
- Disconnect all monitors
- Connect VGA
- Disconnect VGA
- Connect HDMI
Would result in VGA hotplugging becoming disabled, due to the powerwells
getting toggled in the process of connecting HDMI.
Changes since v3:
- Expose intel_crt_reset() through intel_drv.h and call that in
vlv_display_power_well_init() instead of
encoder->base.funcs->reset(&encoder->base);
Changes since v2:
- Use intel_encoder structs instead of drm_encoder structs
Changes since v1:
- Instead of handling the register writes ourself, we just reuse
intel_crt_detect()
- Instead of resetting the ADPA during display IRQ installation, we now
reset them in vlv_display_power_well_init()
Cc: sta...@vger.kernel.org
Acked-by: Daniel Vetter
Signed-off-by: Lyude
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_crt.c| 2 +-
drivers/gpu/drm/i915/intel_drv.h| 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 7 +++
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index dfcd718..220be7a 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,7 +713,7 @@ static int intel_crt_set_property(struct drm_connector
*connector,
return 0;
}
-static void intel_crt_reset(struct drm_encoder *encoder)
+void intel_crt_reset(struct drm_encoder *encoder)
{
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 496c962..dcbfdde 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1075,7 +1075,7 @@ void gen8_irq_power_well_pre_disable(struct
drm_i915_private *dev_priv,
/* intel_crt.c */
void intel_crt_init(struct drm_device *dev);
-
+void intel_crt_reset(struct drm_encoder *encoder);
/* intel_ddi.c */
void intel_ddi_clk_select(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index e856d49..f88ef76 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1065,6 +1065,7 @@ static void vlv_init_display_clock_gating(struct
drm_i915_private *dev_priv)
static void vlv_display_power_well_init(struct drm_i915_private *dev_priv)
{
+ struct intel_encoder *encoder;
enum pipe pipe;
/*
@@ -1100,6 +1101,12 @@ static void vlv_display_power_well_init(struct
drm_i915_private *dev_priv)
intel_hpd_init(dev_priv);
+ /* Re-enable the ADPA, if we have one */
+ for_each_intel_encoder(dev_priv->dev, encoder) {
+ if (encoder->type == INTEL_OUTPUT_ANALOG)
+ intel_crt_reset(&encoder->base);
+ }
+
i915_redisable_vga_power_on(dev_priv->dev);
}
--
2.5.5
