Re: pull-request: wireless-drivers 2015-10-17
From: Kalle Valo Date: Sat, 17 Oct 2015 08:26:19 +0300 > few small fixes I would like to get to 4.3 still. Please let me know if > there are any problems. Pulled, thanks Kalle. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] perf: fix building for ARCv1
Vineet Gupta writes: > > But this user space - so IMHO UP/SMP doesn't matter and we can't simulate > them in > C just by itself. It matters when you access the perf ring buffer which is updated by kernel. Also perf is now multi threaded to some degree. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/11] dts: pinctrl: Add GPIO to Pinctrl pin mapping in DT
ASIU gpio controller's pins are muxed with pin-cntroller.
Add this mapping through property "gpio-ranges".
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 53 +--
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index e1ac07a..6621f13 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -84,10 +84,59 @@
#gpio-cells = <2>;
gpio-controller;
- pinmux = <>;
-
interrupt-controller;
interrupts = ;
+ gpio-ranges = < 0 42 1>,
+ < 1 44 3>,
+ < 4 48 1>,
+ < 5 50 3>,
+ < 8 126 1>,
+ < 9 155 1>,
+ < 10 152 1>,
+ < 11 154 1>,
+ < 12 153 1>,
+ < 13 127 3>,
+ < 16 140 1>,
+ < 17 145 7>,
+ < 24 130 10>,
+ < 34 141 4>,
+ < 38 54 1>,
+ < 39 56 3>,
+ < 42 60 3>,
+ < 45 64 3>,
+ < 48 68 2>,
+ < 50 84 6>,
+ < 56 94 6>,
+ < 62 72 1>,
+ < 63 70 1>,
+ < 64 80 1>,
+ < 65 74 3>,
+ < 68 78 1>,
+ < 69 82 1>,
+ < 70 156 17>,
+ < 87 104 12>,
+ < 99 102 2>,
+ < 101 90 4>,
+ < 105 116 6>,
+ < 111 100 2>,
+ < 113 122 4>,
+ < 123 11 1>,
+ < 124 38 4>,
+ < 128 43 1>,
+ < 129 47 1>,
+ < 130 49 1>,
+ < 131 53 1>,
+ < 132 55 1>,
+ < 133 59 1>,
+ < 134 63 1>,
+ < 135 67 1>,
+ < 136 71 1>,
+ < 137 73 1>,
+ < 138 77 1>,
+ < 139 79 1>,
+ < 140 81 1>,
+ < 141 83 1>,
+ < 142 10 1>;
};
amba {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/11] pinctrl: Add new compatible string to GPIO controller driver
This compatible string should be used for all new iproc based future
SoCs having the same GPIO controller hardware.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
index 498a58a..d0d788f 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
@@ -646,6 +646,7 @@ static const struct of_device_id cygnus_gpio_of_match[] = {
{ .compatible = "brcm,cygnus-ccm-gpio" },
{ .compatible = "brcm,cygnus-asiu-gpio" },
{ .compatible = "brcm,cygnus-crmu-gpio" },
+ { .compatible = "brcm,iproc-gpio" },
{ }
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/11] pinctrl: Rename gpio driver from cygnus to iproc
Rename gpio driver file name from pinctrl-cygnus-gpio.c to
pinctrl-iproc-gpio.c to make it more generic so that all
iproc based future SoCs using the same gpio block could
use this driver.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/pinctrl/bcm/Kconfig| 30 --
drivers/pinctrl/bcm/Makefile | 2 +-
...{pinctrl-cygnus-gpio.c => pinctrl-iproc-gpio.c} | 3 +--
3 files changed, 24 insertions(+), 11 deletions(-)
rename drivers/pinctrl/bcm/{pinctrl-cygnus-gpio.c => pinctrl-iproc-gpio.c}
(99%)
diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
index cd11d4d..5949547 100644
--- a/drivers/pinctrl/bcm/Kconfig
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -20,27 +20,41 @@ config PINCTRL_BCM2835
select PINMUX
select PINCONF
-config PINCTRL_CYGNUS_GPIO
- bool "Broadcom Cygnus GPIO (with PINCONF) driver"
- depends on OF_GPIO && ARCH_BCM_CYGNUS
+config PINCTRL_IPROC_GPIO
+ bool "Broadcom iProc GPIO (with PINCONF) driver"
+ depends on OF_GPIO && (ARCH_BCM_IPROC || COMPILE_TEST)
select GPIOLIB_IRQCHIP
select PINCONF
select GENERIC_PINCONF
- default ARCH_BCM_CYGNUS
+ default ARCH_BCM_IPROC
help
- Say yes here to enable the Broadcom Cygnus GPIO driver.
+ Say yes here to enable the Broadcom iProc GPIO driver.
+
+ The Broadcom iProc based SoCs- Cygnus, NS2, NSP and Stingray, use
+ same GPIO Controller IP hence this driver could be used for all.
The Broadcom Cygnus SoC has 3 GPIO controllers including the ASIU
GPIO controller (ASIU), the chipCommonG GPIO controller (CCM), and
the always-ON GPIO controller (CRMU/AON). All 3 GPIO controllers are
supported by this driver.
- All 3 Cygnus GPIO controllers support basic PINCONF functions such
+ The Broadcom NSP has two GPIO controllers including the ChipcommonA
+ GPIO, the ChipcommonB GPIO. Later controller is supported by this
+ driver.
+
+ The Broadcom NS2 has two GPIO controller including the CRMU GPIO,
+ the ChipcommonG GPIO. Both controllers are supported by this driver.
+
+ The Broadcom Stingray GPIO controllers are supported by this driver.
+
+ All above SoCs GPIO controllers support basic PINCONF functions such
as bias pull up, pull down, and drive strength configurations, when
these pins are muxed to GPIO.
- Pins from the ASIU GPIO can be individually muxed to GPIO function,
- through interaction with the Cygnus IOMUX controller.
+ It provides the framework where pins from the individual GPIO can be
+ individually muxed to GPIO function, through interaction with the
+ SoCs IOMUX controller. This features could be used only on SoCs which
+ support individual pin muxing.
config PINCTRL_CYGNUS_MUX
bool "Broadcom Cygnus IOMUX driver"
diff --git a/drivers/pinctrl/bcm/Makefile b/drivers/pinctrl/bcm/Makefile
index 2b2f70e..9ac6370 100644
--- a/drivers/pinctrl/bcm/Makefile
+++ b/drivers/pinctrl/bcm/Makefile
@@ -2,5 +2,5 @@
obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
-obj-$(CONFIG_PINCTRL_CYGNUS_GPIO) += pinctrl-cygnus-gpio.o
+obj-$(CONFIG_PINCTRL_IPROC_GPIO) += pinctrl-iproc-gpio.o
obj-$(CONFIG_PINCTRL_CYGNUS_MUX) += pinctrl-cygnus-mux.o
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
similarity index 99%
rename from drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
rename to drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index ed21ab2..de09859 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -531,8 +531,7 @@ static int iproc_pin_config_get(struct pinctrl_dev
*pctldev, unsigned pin,
ret = iproc_gpio_get_strength(chip, gpio, );
if (ret)
return ret;
- else
- *config = pinconf_to_config_packed(param, arg);
+ *config = pinconf_to_config_packed(param, arg);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/11] Documentation: Rename gpio controller name from cygnus to iproc
Renamed gpio controller's driver name from cygnus to iproc to make it
more generic so that all iProc based SoCs having the same gpio controller
could use this.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
.../bindings/pinctrl/{brcm,cygnus-gpio.txt => brcm,iproc-gpio.txt}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename Documentation/devicetree/bindings/pinctrl/{brcm,cygnus-gpio.txt =>
brcm,iproc-gpio.txt} (97%)
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
b/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt
similarity index 97%
rename from Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
rename to Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt
index 655a8d7..7fb4621 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt
@@ -1,4 +1,4 @@
-Broadcom Cygnus GPIO/PINCONF Controller
+Broadcom iProc GPIO/PINCONF Controller
Required properties:
@@ -7,7 +7,7 @@ Required properties:
"brcm,cygnus-crmu-gpio" or "brcm,iproc-gpio"
- reg:
-Define the base and range of the I/O address space that contains the Cygnus
+Define the base and range of the I/O address space that contains SoC
GPIO/PINCONF controller registers
- ngpios:
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/11] gpio: Rename func/macro/var to IP-block,iproc
Change functions, macros and variables name from cygnus to IP block,
iproc, so that it could be used in all iproc based future SoCs having
same GPIO controller block.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 306 +++---
1 file changed, 154 insertions(+), 152 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
index d0d788f..ed21ab2 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
@@ -10,14 +10,16 @@
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
- * This file contains the Broadcom Cygnus GPIO driver that supports 3
- * GPIO controllers on Cygnus including the ASIU GPIO controller, the
+ * This file contains the Broadcom Iproc GPIO driver that supports 3
+ * GPIO controllers on Iproc including the ASIU GPIO controller, the
* chipCommonG GPIO controller, and the always-on GPIO controller. Basic
* PINCONF such as bias pull up/down, and drive strength are also supported
* in this driver.
*
- * Pins from the ASIU GPIO can be individually muxed to GPIO function,
- * through the interaction with the Cygnus IOMUX controller
+ * It provides the functionality where pins from the GPIO can be
+ * individually muxed to GPIO function, if individual pad
+ * configuration is supported, through the interaction with respective
+ * SoCs IOMUX controller.
*/
#include
@@ -34,42 +36,42 @@
#include "../pinctrl-utils.h"
-#define CYGNUS_GPIO_DATA_IN_OFFSET 0x00
-#define CYGNUS_GPIO_DATA_OUT_OFFSET 0x04
-#define CYGNUS_GPIO_OUT_EN_OFFSET0x08
-#define CYGNUS_GPIO_INT_TYPE_OFFSET 0x0c
-#define CYGNUS_GPIO_INT_DE_OFFSET0x10
-#define CYGNUS_GPIO_INT_EDGE_OFFSET 0x14
-#define CYGNUS_GPIO_INT_MSK_OFFSET 0x18
-#define CYGNUS_GPIO_INT_STAT_OFFSET 0x1c
-#define CYGNUS_GPIO_INT_MSTAT_OFFSET 0x20
-#define CYGNUS_GPIO_INT_CLR_OFFSET 0x24
-#define CYGNUS_GPIO_PAD_RES_OFFSET 0x34
-#define CYGNUS_GPIO_RES_EN_OFFSET0x38
+#define IPROC_GPIO_DATA_IN_OFFSET 0x00
+#define IPROC_GPIO_DATA_OUT_OFFSET 0x04
+#define IPROC_GPIO_OUT_EN_OFFSET0x08
+#define IPROC_GPIO_INT_TYPE_OFFSET 0x0c
+#define IPROC_GPIO_INT_DE_OFFSET0x10
+#define IPROC_GPIO_INT_EDGE_OFFSET 0x14
+#define IPROC_GPIO_INT_MSK_OFFSET 0x18
+#define IPROC_GPIO_INT_STAT_OFFSET 0x1c
+#define IPROC_GPIO_INT_MSTAT_OFFSET 0x20
+#define IPROC_GPIO_INT_CLR_OFFSET 0x24
+#define IPROC_GPIO_PAD_RES_OFFSET 0x34
+#define IPROC_GPIO_RES_EN_OFFSET0x38
/* drive strength control for ASIU GPIO */
-#define CYGNUS_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
+#define IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
/* drive strength control for CCM/CRMU (AON) GPIO */
-#define CYGNUS_GPIO_DRV0_CTRL_OFFSET 0x00
+#define IPROC_GPIO_DRV0_CTRL_OFFSET 0x00
#define GPIO_BANK_SIZE 0x200
#define NGPIOS_PER_BANK 32
#define GPIO_BANK(pin) ((pin) / NGPIOS_PER_BANK)
-#define CYGNUS_GPIO_REG(pin, reg) (GPIO_BANK(pin) * GPIO_BANK_SIZE + (reg))
-#define CYGNUS_GPIO_SHIFT(pin) ((pin) % NGPIOS_PER_BANK)
+#define IPROC_GPIO_REG(pin, reg) (GPIO_BANK(pin) * GPIO_BANK_SIZE + (reg))
+#define IPROC_GPIO_SHIFT(pin) ((pin) % NGPIOS_PER_BANK)
#define GPIO_DRV_STRENGTH_BIT_SHIFT 20
#define GPIO_DRV_STRENGTH_BITS 3
#define GPIO_DRV_STRENGTH_BIT_MASK ((1 << GPIO_DRV_STRENGTH_BITS) - 1)
/*
- * Cygnus GPIO core
+ * Iproc GPIO core
*
* @dev: pointer to device
- * @base: I/O register base for Cygnus GPIO controller
- * @io_ctrl: I/O register base for certain type of Cygnus GPIO controller that
+ * @base: I/O register base for Iproc GPIO controller
+ * @io_ctrl: I/O register base for certain type of Iproc GPIO controller that
* has the PINCONF support implemented outside of the GPIO block
* @lock: lock to protect access to I/O registers
* @gc: GPIO chip
@@ -79,7 +81,7 @@
* @pctl: pointer to pinctrl_dev
* @pctldesc: pinctrl descriptor
*/
-struct cygnus_gpio {
+struct iproc_gpio {
struct device *dev;
void __iomem *base;
@@ -96,33 +98,33 @@ struct cygnus_gpio {
struct pinctrl_desc pctldesc;
};
-static inline struct cygnus_gpio *to_cygnus_gpio(struct gpio_chip *gc)
+static inline struct iproc_gpio *to_iproc_gpio(struct gpio_chip *gc)
{
- return container_of(gc, struct cygnus_gpio, gc);
+ return container_of(gc, struct iproc_gpio, gc);
}
/*
* Mapping from PINCONF pins to GPIO pins is 1-to-1
*/
-static inline unsigned cygnus_pin_to_gpio(unsigned pin)
+static inline unsigned iproc_pin_to_gpio(unsigned pin)
{
return pin;
}
/**
- * cygnus_set_bit - set or clear one bit (corresponding to the GPIO pin) in a
- * Cygnus GPIO register
+ * iproc_set_bit - set or clear one bit (corresponding to the GPIO pin) in a
+ * Iproc GPIO register
*
- * @cygnus_gpio: Cygnus GPIO device
+ * @iproc_gpio: Iproc GPIO
[PATCH 02/11] pinctrl: Remove GPIO to Pinctrl pin mapping from driver
Remove gpio to pinctrl pin mapping code from driver and
address this through standard property "gpio-ranges".
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 131 +-
1 file changed, 3 insertions(+), 128 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
index 1ca7830..12a48f4 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include
#include
@@ -597,127 +596,6 @@ static const struct pinconf_ops cygnus_pconf_ops = {
};
/*
- * Map a GPIO in the local gpio_chip pin space to a pin in the Cygnus IOMUX
- * pinctrl pin space
- */
-struct cygnus_gpio_pin_range {
- unsigned offset;
- unsigned pin_base;
- unsigned num_pins;
-};
-
-#define CYGNUS_PINRANGE(o, p, n) { .offset = o, .pin_base = p, .num_pins = n }
-
-/*
- * Pin mapping table for mapping local GPIO pins to Cygnus IOMUX pinctrl pins
- */
-static const struct cygnus_gpio_pin_range cygnus_gpio_pintable[] = {
- CYGNUS_PINRANGE(0, 42, 1),
- CYGNUS_PINRANGE(1, 44, 3),
- CYGNUS_PINRANGE(4, 48, 1),
- CYGNUS_PINRANGE(5, 50, 3),
- CYGNUS_PINRANGE(8, 126, 1),
- CYGNUS_PINRANGE(9, 155, 1),
- CYGNUS_PINRANGE(10, 152, 1),
- CYGNUS_PINRANGE(11, 154, 1),
- CYGNUS_PINRANGE(12, 153, 1),
- CYGNUS_PINRANGE(13, 127, 3),
- CYGNUS_PINRANGE(16, 140, 1),
- CYGNUS_PINRANGE(17, 145, 7),
- CYGNUS_PINRANGE(24, 130, 10),
- CYGNUS_PINRANGE(34, 141, 4),
- CYGNUS_PINRANGE(38, 54, 1),
- CYGNUS_PINRANGE(39, 56, 3),
- CYGNUS_PINRANGE(42, 60, 3),
- CYGNUS_PINRANGE(45, 64, 3),
- CYGNUS_PINRANGE(48, 68, 2),
- CYGNUS_PINRANGE(50, 84, 6),
- CYGNUS_PINRANGE(56, 94, 6),
- CYGNUS_PINRANGE(62, 72, 1),
- CYGNUS_PINRANGE(63, 70, 1),
- CYGNUS_PINRANGE(64, 80, 1),
- CYGNUS_PINRANGE(65, 74, 3),
- CYGNUS_PINRANGE(68, 78, 1),
- CYGNUS_PINRANGE(69, 82, 1),
- CYGNUS_PINRANGE(70, 156, 17),
- CYGNUS_PINRANGE(87, 104, 12),
- CYGNUS_PINRANGE(99, 102, 2),
- CYGNUS_PINRANGE(101, 90, 4),
- CYGNUS_PINRANGE(105, 116, 6),
- CYGNUS_PINRANGE(111, 100, 2),
- CYGNUS_PINRANGE(113, 122, 4),
- CYGNUS_PINRANGE(123, 11, 1),
- CYGNUS_PINRANGE(124, 38, 4),
- CYGNUS_PINRANGE(128, 43, 1),
- CYGNUS_PINRANGE(129, 47, 1),
- CYGNUS_PINRANGE(130, 49, 1),
- CYGNUS_PINRANGE(131, 53, 1),
- CYGNUS_PINRANGE(132, 55, 1),
- CYGNUS_PINRANGE(133, 59, 1),
- CYGNUS_PINRANGE(134, 63, 1),
- CYGNUS_PINRANGE(135, 67, 1),
- CYGNUS_PINRANGE(136, 71, 1),
- CYGNUS_PINRANGE(137, 73, 1),
- CYGNUS_PINRANGE(138, 77, 1),
- CYGNUS_PINRANGE(139, 79, 1),
- CYGNUS_PINRANGE(140, 81, 1),
- CYGNUS_PINRANGE(141, 83, 1),
- CYGNUS_PINRANGE(142, 10, 1)
-};
-
-/*
- * The Cygnus IOMUX controller mainly supports group based mux configuration,
- * but certain pins can be muxed to GPIO individually. Only the ASIU GPIO
- * controller can support this, so it's an optional configuration
- *
- * Return -ENODEV means no support and that's fine
- */
-static int cygnus_gpio_pinmux_add_range(struct cygnus_gpio *chip)
-{
- struct device_node *node = chip->dev->of_node;
- struct device_node *pinmux_node;
- struct platform_device *pinmux_pdev;
- struct gpio_chip *gc = >gc;
- int i, ret = 0;
-
- /* parse DT to find the phandle to the pinmux controller */
- pinmux_node = of_parse_phandle(node, "pinmux", 0);
- if (!pinmux_node)
- return -ENODEV;
-
- pinmux_pdev = of_find_device_by_node(pinmux_node);
- /* no longer need the pinmux node */
- of_node_put(pinmux_node);
- if (!pinmux_pdev) {
- dev_err(chip->dev, "failed to get pinmux device\n");
- return -EINVAL;
- }
-
- /* now need to create the mapping between local GPIO and PINMUX pins */
- for (i = 0; i < ARRAY_SIZE(cygnus_gpio_pintable); i++) {
- ret = gpiochip_add_pin_range(gc, dev_name(_pdev->dev),
-cygnus_gpio_pintable[i].offset,
-cygnus_gpio_pintable[i].pin_base,
-cygnus_gpio_pintable[i].num_pins);
- if (ret) {
- dev_err(chip->dev, "unable to add GPIO pin range\n");
- goto err_put_device;
- }
- }
-
- chip->pinmux_is_supported = true;
-
- /* no need for pinmux_pdev device reference anymore */
- put_device(_pdev->dev);
- return 0;
-
-err_put_device:
- put_device(_pdev->dev);
- gpiochip_remove_pin_ranges(gc);
- return ret;
-}
-
-/*
*
[PATCH 00/11] Generalized broadcom cygnus gpio driver
Generalized pinctrl-cygnus-gpio driver so that it could be used for all
iProc architecture based future SoCs having same gpio pin controller.
Generalization process made the below changes in driver-
1. Removed pin mapping from driver and addressed this via DT through
"gpio-ranges" property.
2. Addressed number of pins from DT through "ngpios" property and removed
from driver.
3. Since all iProc based SoCs would use this driver hence renamed all
variables/macros/functions and even file name on iproc.
This patchset applies on v4.3-rc4 and is tested on cygnus SVK and could be
find at-
https://github.com/Broadcom/arm64-linux/tree/iproc-gpio-v1
Pramod Kumar (11):
dt-bindings: pinctrl: Optional DT property to support pin mappings
pinctrl: Remove GPIO to Pinctrl pin mapping from driver
dts: pinctrl: Add GPIO to Pinctrl pin mapping in DT
dt-binding: Add new compatible string for gpio controller driver
dt-binding: Add ngpios property to GPIO controller node
dts: define ngpios property in gpio controller's node
pinctrl: use ngpios propety from DT
pinctrl: Add new compatible string to GPIO controller driver
gpio: Rename func/macro/var to IP-block,iproc
Documentation: Rename gpio controller name from cygnus to iproc
pinctrl: Rename gpio driver from cygnus to iproc
.../{brcm,cygnus-gpio.txt => brcm,iproc-gpio.txt} | 25 +-
arch/arm/boot/dts/bcm-cygnus.dtsi | 56 +-
drivers/pinctrl/bcm/Kconfig| 30 +-
drivers/pinctrl/bcm/Makefile | 2 +-
drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 909 -
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 759 +
6 files changed, 854 insertions(+), 927 deletions(-)
rename Documentation/devicetree/bindings/pinctrl/{brcm,cygnus-gpio.txt =>
brcm,iproc-gpio.txt} (75%)
delete mode 100644 drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
create mode 100644 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/11] dt-bindings: pinctrl: Optional DT property to support pin mappings
If GPIO controller's pins are muxed, pin-controller subsystem need to be intimated by defining mapping between gpio and pinmux controller. This patch adds required properties to define this mapping via DT. Signed-off-by: Pramod Kumar Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- .../devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt index 6540ca5..25a5002 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt @@ -26,9 +26,13 @@ Optional properties: - interrupt-controller: Specifies that the node is an interrupt controller -- pinmux: -Specifies the phandle to the IOMUX device, where pins can be individually -muxed to GPIO +- gpio-ranges: +Specifies the mapping between gpio controller and pin-controllers pins. +This requires 4 fields in cells defined as - +1. Phandle of pin-controller. +2. GPIO base pin offset. +3 Pin-control base pin offset. +4. number of gpio pins which are linearly mapped from pin base. Supported generic PINCONF properties in child nodes: @@ -78,6 +82,8 @@ Example: gpio-controller; interrupts = ; interrupt-controller; + gpio-ranges = < 0 42 1>, + < 1 44 3>; }; /* -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/11] dt-binding: Add ngpios property to GPIO controller node
Add ngpios property to the gpio controller's DT node so that controller
driver extracts total number of gpio lines present in controller
from DT and removes dependency on driver.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
index f92b833..655a8d7 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
@@ -10,6 +10,9 @@ Required properties:
Define the base and range of the I/O address space that contains the Cygnus
GPIO/PINCONF controller registers
+- ngpios:
+Total number of GPIOs the controller provides
+
- #gpio-cells:
Must be two. The first cell is the GPIO pin number (within the
controller's pin space) and the second cell is used for the following:
@@ -57,6 +60,7 @@ Example:
compatible = "brcm,cygnus-ccm-gpio";
reg = <0x1800a000 0x50>,
<0x0301d164 0x20>;
+ ngpios = <24>;
#gpio-cells = <2>;
gpio-controller;
interrupts = ;
@@ -78,6 +82,7 @@ Example:
gpio_asiu: gpio@180a5000 {
compatible = "brcm,cygnus-asiu-gpio";
reg = <0x180a5000 0x668>;
+ ngpios = <146>;
#gpio-cells = <2>;
gpio-controller;
interrupts = ;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/11] dt-binding: Add new compatible string for gpio controller driver
This new compatible string, "brcm,iproc-gpio", should be used for all new iproc-based future SoCs. Signed-off-by: Pramod Kumar Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt index 25a5002..f92b833 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt @@ -3,8 +3,8 @@ Broadcom Cygnus GPIO/PINCONF Controller Required properties: - compatible: -Must be "brcm,cygnus-ccm-gpio", "brcm,cygnus-asiu-gpio", or -"brcm,cygnus-crmu-gpio" +Must be "brcm,cygnus-ccm-gpio", "brcm,cygnus-asiu-gpio", +"brcm,cygnus-crmu-gpio" or "brcm,iproc-gpio" - reg: Define the base and range of the I/O address space that contains the Cygnus -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/11] pinctrl: use ngpios propety from DT
Since identical hardware is used in several instances and all pins
are not routed to pinctrl hence getting total number of gpios from
DT make more sense hence stop using total number of gpios pins from
drivers and extract it from DT.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 45 +++
1 file changed, 9 insertions(+), 36 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
index 12a48f4..498a58a 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
@@ -642,35 +642,11 @@ static void cygnus_gpio_unregister_pinconf(struct
cygnus_gpio *chip)
pinctrl_unregister(chip->pctl);
}
-struct cygnus_gpio_data {
- unsigned num_gpios;
-};
-
-static const struct cygnus_gpio_data cygnus_cmm_gpio_data = {
- .num_gpios = 24,
-};
-
-static const struct cygnus_gpio_data cygnus_asiu_gpio_data = {
- .num_gpios = 146,
-};
-
-static const struct cygnus_gpio_data cygnus_crmu_gpio_data = {
- .num_gpios = 6,
-};
-
static const struct of_device_id cygnus_gpio_of_match[] = {
- {
- .compatible = "brcm,cygnus-ccm-gpio",
- .data = _cmm_gpio_data,
- },
- {
- .compatible = "brcm,cygnus-asiu-gpio",
- .data = _asiu_gpio_data,
- },
- {
- .compatible = "brcm,cygnus-crmu-gpio",
- .data = _crmu_gpio_data,
- }
+ { .compatible = "brcm,cygnus-ccm-gpio" },
+ { .compatible = "brcm,cygnus-asiu-gpio" },
+ { .compatible = "brcm,cygnus-crmu-gpio" },
+ { }
};
static int cygnus_gpio_probe(struct platform_device *pdev)
@@ -681,14 +657,6 @@ static int cygnus_gpio_probe(struct platform_device *pdev)
struct gpio_chip *gc;
u32 ngpios;
int irq, ret;
- const struct of_device_id *match;
- const struct cygnus_gpio_data *gpio_data;
-
- match = of_match_device(cygnus_gpio_of_match, dev);
- if (!match)
- return -ENODEV;
- gpio_data = match->data;
- ngpios = gpio_data->num_gpios;
chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
@@ -713,6 +681,11 @@ static int cygnus_gpio_probe(struct platform_device *pdev)
}
}
+ if (of_property_read_u32(dev->of_node, "ngpios", )) {
+ dev_err(>dev, "missing ngpios DT property\n");
+ return -ENODEV;
+ }
+
spin_lock_init(>lock);
gc = >gc;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/11] dts: define ngpios property in gpio controller's node
Add ngpios property in cygnus ASIU, CCM and CRMU gpio controller's
node.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 6621f13..d0fd050 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -64,6 +64,7 @@
compatible = "brcm,cygnus-crmu-gpio";
reg = <0x03024800 0x50>,
<0x03024008 0x18>;
+ ngpios = <6>;
#gpio-cells = <2>;
gpio-controller;
};
@@ -72,6 +73,7 @@
compatible = "brcm,cygnus-ccm-gpio";
reg = <0x1800a000 0x50>,
<0x0301d164 0x20>;
+ ngpios = <24>;
#gpio-cells = <2>;
gpio-controller;
interrupts = ;
@@ -81,6 +83,7 @@
gpio_asiu: gpio@180a5000 {
compatible = "brcm,cygnus-asiu-gpio";
reg = <0x180a5000 0x668>;
+ ngpios = <146>;
#gpio-cells = <2>;
gpio-controller;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] serial: support register interface with 16-bit stride for console
Currently, 8-bit (MMIO) and 32-bit (MMIO32) strides are supported for
the 8250 console, but 16-bit (MMIO16) stride is not. The 8250 UART
device on my board has 16-bit stride (reg-shift = <1>) and I am eager
to use earlycon with it.
Refer to arch/arm/boot/dts/uniphier-support-card.dtsi:
serialsc: uart@000b {
compatible = "ns16550a";
reg = <0x000b 0x20>;
clock-frequency = <12288000>;
reg-shift = <1>;
};
Signed-off-by: Masahiro Yamada
---
Documentation/kernel-parameters.txt | 9 +
drivers/tty/serial/8250/8250_early.c | 5 +
drivers/tty/serial/8250/8250_port.c | 20
drivers/tty/serial/earlycon.c| 15 +++
drivers/tty/serial/serial_core.c | 9 +++--
include/linux/serial_core.h | 1 +
include/uapi/linux/serial.h | 9 +
7 files changed, 54 insertions(+), 14 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 22a4b68..761f08c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -720,16 +720,17 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
uart[8250],io,[,options]
uart[8250],mmio,[,options]
+ uart[8250],mmio16,[,options]
uart[8250],mmio32,[,options]
uart[8250],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later.
MMIO inter-register address stride is either 8-bit
- (mmio) or 32-bit (mmio32).
- If none of [io|mmio|mmio32], is assumed to be
- equivalent to 'mmio'. 'options' are specified in the
- same format described for ttyS above; if unspecified,
+ (mmio), 16-bit (mmio16), or 32-bit (mmio32).
+ If none of [io|mmio|mmio16|mmio32], is assumed
+ to be equivalent to 'mmio'. 'options' are specified in
+ the same format described for ttyS above; if
unspecified,
the h/w is not re-initialized.
hvc Use the hypervisor console device . This is for
diff --git a/drivers/tty/serial/8250/8250_early.c
b/drivers/tty/serial/8250/8250_early.c
index faed05f..7aff3d8 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -40,6 +40,8 @@ static unsigned int __init serial8250_early_in(struct
uart_port *port, int offse
switch (port->iotype) {
case UPIO_MEM:
return readb(port->membase + offset);
+ case UPIO_MEM16:
+ return readw(port->membase + (offset << 1));
case UPIO_MEM32:
return readl(port->membase + (offset << 2));
case UPIO_MEM32BE:
@@ -57,6 +59,9 @@ static void __init serial8250_early_out(struct uart_port
*port, int offset, int
case UPIO_MEM:
writeb(value, port->membase + offset);
break;
+ case UPIO_MEM16:
+ writew(value, port->membase + (offset << 1));
+ break;
case UPIO_MEM32:
writel(value, port->membase + (offset << 2));
break;
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 0bbf340..f976948 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -368,6 +368,18 @@ static void mem_serial_out(struct uart_port *p, int
offset, int value)
writeb(value, p->membase + offset);
}
+static void mem16_serial_out(struct uart_port *p, int offset, int value)
+{
+ offset = offset << p->regshift;
+ writew(value, p->membase + offset);
+}
+
+static unsigned int mem16_serial_in(struct uart_port *p, int offset)
+{
+ offset = offset << p->regshift;
+ return readw(p->membase + offset);
+}
+
static void mem32_serial_out(struct uart_port *p, int offset, int value)
{
offset = offset << p->regshift;
@@ -425,6 +437,11 @@ static void set_io_from_upio(struct uart_port *p)
p->serial_out = mem_serial_out;
break;
+ case UPIO_MEM16:
+ p->serial_in = mem16_serial_in;
+ p->serial_out = mem16_serial_out;
+ break;
+
case UPIO_MEM32:
p->serial_in = mem32_serial_in;
p->serial_out = mem32_serial_out;
@@ -459,6 +476,7 @@ serial_port_out_sync(struct uart_port *p, int offset, int
value)
{
switch (p->iotype) {
case UPIO_MEM:
+ case UPIO_MEM16:
case UPIO_MEM32:
case UPIO_MEM32BE:
case UPIO_AU:
@@ -2447,6 +2465,7 @@ static int
[PATCH 0/2] serial: console: add two features
1/2: add MMIO16 register interface support 2/2: allow to input clock frequency from kernel parameter Masahiro Yamada (2): serial: support register interface with 16-bit stride for console serial: earlycon: allow to specify uartclk in earlycon kernel-parameter Documentation/kernel-parameters.txt | 9 + drivers/tty/serial/8250/8250_early.c | 5 + drivers/tty/serial/8250/8250_port.c | 20 drivers/tty/serial/earlycon.c| 23 ++- drivers/tty/serial/serial_core.c | 9 +++-- include/linux/serial_core.h | 1 + include/uapi/linux/serial.h | 9 + 7 files changed, 61 insertions(+), 15 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] serial: earlycon: allow to specify uartclk in earlycon kernel-parameter
The input clock frequency varies from device to device, but the
earlycon uses the fixed frequency (BASE_BAUD * 16). It makes
impossible to set the correct divisor to the register.
This commit allows to specify the input clock frequency from the
kernel-parameter.
[Example]
earlycon=uart8250,mmio32,0x43fb,115200,12288000
The input clock frequency (12288000, in this case) should be specified
after the baudrate. If not specified, the default (BASE_BAUD * 16) is
used.
Signed-off-by: Masahiro Yamada
---
drivers/tty/serial/earlycon.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 07f7393..8030765 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -95,6 +95,13 @@ static int __init parse_options(struct earlycon_device
*device, char *options)
length = min(strcspn(options, " ") + 1,
(size_t)(sizeof(device->options)));
strlcpy(device->options, options, length);
+ options = strchr(options, ',');
+ if (options) {
+ options++;
+ port->uartclk = simple_strtoul(options, NULL, 0);
+ }
+ if (!port->uartclk)
+ port->uartclk = BASE_BAUD * 16;
}
if (port->iotype == UPIO_MEM || port->iotype == UPIO_MEM16 ||
@@ -122,7 +129,6 @@ static int __init register_earlycon(char *buf, const struct
earlycon_id *match)
if (buf && !parse_options(_console_dev, buf))
buf = NULL;
- port->uartclk = BASE_BAUD * 16;
if (port->mapbase)
port->membase = earlycon_map(port->mapbase, 64);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] bpf: Add new bpf map type for timer
This patch implements a timer map type inherited from array map. eBPF
programs can deloy a timer by updating an entry in timer map, and
destroy that by deleting the entry. The timer delay time(ns) is set by
updating the value field of the entries.
Currently, an intended empty function is called when the timer is
triggered, then eBPF programs can be attatched to this function and
perfrom customized functions.
Signed-off-by: He Kuang
---
Here's a hypothetical scenario to illustrate the use of timer map.
A video frame is updated between frame_refresh_start() and
frame_refresh_end(), in most cases, the interval between these two
functions is less than 40ms, but occasionally over 200ms.
We can set a timer which alarm after the frame_refresh_start() has
been executed 42ms(slightly larger than 40ms) and destory this timer
if frame_refresh_end() is called. So, for most cases, the timer is not
triggered, this can significantly reduce the amount of trace data.
eBPF progs:
struct bpf_map_def SEC("maps") timer_map = {
.type = BPF_MAP_TYPE_TIMER_ARRAY,
.key_size = sizeof(int),
.value_size = sizeof(unsigned long long),
.max_entries = 4,
};
SEC("func1=frame_refresh_start")
int bpf_prog1(struct pt_regs *ctx)
{
int delay_ns = 42 * NSEC_PER_MSEC; /* 42 milliseconds */
unsigned int index = 0;
bpf_map_update_elem(_map, , _ns, BPF_ANY);
return 0;
}
SEC("func2=frame_refresh_end")
int bpf_prog2(struct pt_regs *ctx)
{
unsigned int index = 0;
bpf_map_delete_elem(_map, );
return 0;
}
SEC("func3=bpf_timer_callback")
int bpf_prog3(struct pt_regs *ctx, int result)
{
char fmt[] = "timer triggered\n";
bpf_trace_printk(fmt, sizeof(fmt));
/* If comes here, frame refresh time is beyond the threshold
we can switch on more tracepoints or enable more detailed
trace paramaters to diagnose the problems.
*/
return 0;
}
Then we can write an exec to test the ebpf progs above, each timeout
frame updates will trigger the timer.
---
include/uapi/linux/bpf.h | 1 +
kernel/bpf/arraymap.c| 161 +++
2 files changed, 149 insertions(+), 13 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 92a48e2..c41c80e 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -115,6 +115,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_ARRAY,
BPF_MAP_TYPE_PROG_ARRAY,
BPF_MAP_TYPE_PERF_EVENT_ARRAY,
+ BPF_MAP_TYPE_TIMER_ARRAY,
};
enum bpf_prog_type {
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 29ace10..1e03c70 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -16,18 +16,10 @@
#include
#include
-/* Called from syscall */
-static struct bpf_map *array_map_alloc(union bpf_attr *attr)
+static struct bpf_map *__array_map_alloc(union bpf_attr *attr, u32 elem_size)
{
struct bpf_array *array;
- u32 elem_size, array_size;
-
- /* check sanity of attributes */
- if (attr->max_entries == 0 || attr->key_size != 4 ||
- attr->value_size == 0)
- return ERR_PTR(-EINVAL);
-
- elem_size = round_up(attr->value_size, 8);
+ u32 array_size;
/* check round_up into zero and u32 overflow */
if (elem_size == 0 ||
@@ -54,6 +46,20 @@ static struct bpf_map *array_map_alloc(union bpf_attr *attr)
return >map;
}
+/* Called from syscall */
+static struct bpf_map *array_map_alloc(union bpf_attr *attr)
+{
+ u32 elem_size;
+
+ /* check sanity of attributes */
+ if (attr->max_entries == 0 || attr->key_size != 4 ||
+ attr->value_size == 0)
+ return ERR_PTR(-EINVAL);
+
+ elem_size = round_up(attr->value_size, 8);
+ return __array_map_alloc(attr, elem_size);
+}
+
/* Called from syscall or from eBPF program */
static void *array_map_lookup_elem(struct bpf_map *map, void *key)
{
@@ -171,7 +177,7 @@ static void fd_array_map_free(struct bpf_map *map)
kvfree(array);
}
-static void *fd_array_map_lookup_elem(struct bpf_map *map, void *key)
+static void *empty_array_map_lookup_elem(struct bpf_map *map, void *key)
{
return NULL;
}
@@ -255,7 +261,7 @@ static const struct bpf_map_ops prog_array_ops = {
.map_alloc = fd_array_map_alloc,
.map_free = fd_array_map_free,
.map_get_next_key = array_map_get_next_key,
- .map_lookup_elem = fd_array_map_lookup_elem,
+ .map_lookup_elem = empty_array_map_lookup_elem,
.map_update_elem = fd_array_map_update_elem,
.map_delete_elem = fd_array_map_delete_elem,
.map_fd_get_ptr = prog_fd_array_get_ptr,
@@ -312,7 +318,7 @@ static const struct bpf_map_ops perf_event_array_ops = {
.map_alloc = fd_array_map_alloc,
.map_free = perf_event_array_map_free,
.map_get_next_key =
Re: [PATCH v10 3/3] arm64: dts: mediatek: add xHCI & usb phy for mt8173
On Sun, 2015-10-18 at 14:01 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 10/18/2015 6:51 AM, Chunfeng Yun wrote:
>
> > add xHCI and phy drivers for MT8173-EVB
> >
> > Signed-off-by: Chunfeng Yun
>
> [...]
>
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index d18ee42..46f5f50 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> [...]
> > @@ -487,6 +488,47 @@
> > clock-names = "source", "hclk";
> > status = "disabled";
> > };
> > +
> > + usb30: usb@1127 {
> > + compatible = "mediatek,mt8173-xhci";
> > + reg = <0 0x1127 0 0x1000>,
> > + <0 0x11280700 0 0x0100>;
> > + interrupts = ;
> > + power-domains = < MT8173_POWER_DOMAIN_USB>;
> > + clocks = < CLK_TOP_USB30_SEL>,
> > +< CLK_PERI_USB0>,
> > +< CLK_PERI_USB1>;
> > + clock-names = "sys_ck",
> > + "wakeup_deb_p0",
> > + "wakeup_deb_p1";
> > + phys = <_port0 PHY_TYPE_USB3>,
> > + <_port1 PHY_TYPE_USB2>;
> > + mediatek,syscon-wakeup = <>;
> > + status = "okay";
> > + };
> > +
> > + u3phy: usb-phy@1129 {
> > + compatible = "mediatek,mt8173-u3phy";
> > + reg = <0 0x1129 0 0x800>;
> > + clocks = < CLK_APMIXED_REF2USB_TX>;
> > + clock-names = "u3phya_ref";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > + status = "okay";
>
> Don't you need the "power-domains" prop here as well?
No, the power-domains of MAC and PHY are separated, but PHY's can't be
operated by software.
Thanks.
>
> > +
> > + phy_port0: port@11290800 {
> > + reg = <0 0x11290800 0 0x800>;
> > + #phy-cells = <1>;
> > + status = "okay";
> > + };
> > +
> > + phy_port1: port@11291000 {
> > + reg = <0 0x11291000 0 0x800>;
> > + #phy-cells = <1>;
> > + status = "okay";
> > + };
> > + };
> > };
> > };
> >
>
> MBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 net-next] RDS: fix rds-ping deadlock over TCP transport
From: Santosh Shilimkar
Date: Fri, 16 Oct 2015 22:13:21 -0400
> Sowmini found hang with rds-ping while testing RDS over TCP. Its
> a corner case and doesn't happen always. The issue is not reproducible
> with IB transport. Its clear from below dump why we see it with RDS TCP.
...
> This happens because rds_send_xmit() chain wants to take
> sock_lock which is already taken by tcp_v4_rcv() on its
> way to rds_tcp_data_ready(). Commit db6526dcb51b ("RDS: use
> rds_send_xmit() state instead of RDS_LL_SEND_FULL") which
> was trying to opportunistically finish the send request
> in same thread context.
>
> But because of above recursive lock hang with RDS TCP,
> the send work from rds_send_pong() needs to deferred to
> worker to avoid lock up. Given RDS ping is more of connectivity
> test than performance critical path, its should be ok even
> for transport like IB.
>
> Reported-by: Sowmini Varadhan
> Acked-by: Sowmini Varadhan
> Signed-off-by: Santosh Shilimkar
> Signed-off-by: Santosh Shilimkar
> ---
> v2: Dropped the confusing SEND_LL_FULL check from v1
Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] hwrng: exynos - Fix missing configuration after suspend to RAM
On 19.10.2015 13:37, Krzysztof Kozlowski wrote:
> After suspend to RAM the device stopped to work with ETIMEDOUT error:
>
> $ dd if=/dev/hwrng of=/dev/null bs=1 count=16
> dd: reading `/dev/hwrng': Connection timed out
>
> In the STATUS register the bits #5 (PRNG_DONE) and #1
> (SEED_SETTING_DONE) were not set. Instead PRNG_ERROR (seventh bit) was
> high.
>
> After each system suspend initialize the seed to fix the error.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/char/hw_random/exynos-rng.c | 42
> ++---
> 1 file changed, 35 insertions(+), 7 deletions(-)
>
Oh, I forgot about stable.
Fixes: b329669ea0b5 ("hwrng: exynos - Add support for Exynos random
number generator")
Cc:
I'll add it in respin (if there would be such).
Best regards,
Krzysztof
> diff --git a/drivers/char/hw_random/exynos-rng.c
> b/drivers/char/hw_random/exynos-rng.c
> index dffb8ddd..162adbda1b70 100644
> --- a/drivers/char/hw_random/exynos-rng.c
> +++ b/drivers/char/hw_random/exynos-rng.c
> @@ -53,15 +53,11 @@ static void exynos_rng_writel(struct exynos_rng *rng, u32
> val, u32 offset)
> __raw_writel(val, rng->mem + offset);
> }
>
> -static int exynos_init(struct hwrng *rng)
> +static int exynos_rng_configure(struct exynos_rng *exynos_rng)
> {
> - struct exynos_rng *exynos_rng = container_of(rng,
> - struct exynos_rng, rng);
> int i;
> int ret = 0;
>
> - pm_runtime_get_sync(exynos_rng->dev);
> -
> for (i = 0 ; i < 5 ; i++)
> exynos_rng_writel(exynos_rng, jiffies,
> EXYNOS_PRNG_SEED_OFFSET + 4*i);
> @@ -70,6 +66,17 @@ static int exynos_init(struct hwrng *rng)
>& SEED_SETTING_DONE))
> ret = -EIO;
>
> + return ret;
> +}
> +
> +static int exynos_init(struct hwrng *rng)
> +{
> + struct exynos_rng *exynos_rng = container_of(rng,
> + struct exynos_rng, rng);
> + int ret = 0;
> +
> + pm_runtime_get_sync(exynos_rng->dev);
> + ret = exynos_rng_configure(exynos_rng);
> pm_runtime_put_noidle(exynos_rng->dev);
>
> return ret;
> @@ -155,10 +162,31 @@ static int exynos_rng_runtime_resume(struct device *dev)
>
> return clk_prepare_enable(exynos_rng->clk);
> }
> +
> +static int exynos_rng_suspend(struct device *dev)
> +{
> + return pm_runtime_force_suspend(dev);
> +}
> +
> +static int exynos_rng_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct exynos_rng *exynos_rng = platform_get_drvdata(pdev);
> + int ret;
> +
> + ret = pm_runtime_force_resume(dev);
> + if (ret)
> + return ret;
> +
> + return exynos_rng_configure(exynos_rng);
> +}
> #endif
>
> -static UNIVERSAL_DEV_PM_OPS(exynos_rng_pm_ops, exynos_rng_runtime_suspend,
> - exynos_rng_runtime_resume, NULL);
> +static const struct dev_pm_ops exynos_rng_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(exynos_rng_suspend, exynos_rng_resume)
> + SET_RUNTIME_PM_OPS(exynos_rng_runtime_suspend,
> +exynos_rng_runtime_resume, NULL)
> +};
>
> static struct platform_driver exynos_rng_driver = {
> .driver = {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: dts: Enable PRNG module on exynos4412-trats2
Enable Pseudo Random Number Generator (PRNG) on Trats2 board. This
allows using hardware random number generator:
$ echo exynos > /sys/class/misc/hw_random/rng_current
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 40a474c4374b..a6f78c3da935 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -1234,6 +1234,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
clocks = < CLK_RTC>, < MAX77686_CLK_AP>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: dts: Add PRNG module for exynos4
Add Pseudo Random Number Generator (PRNG) node of Security Sub System
(SSS) to Exynos 4 DTSI.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3184e10f260a..a6b9913ea2b5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -954,4 +954,12 @@
power-domains = <_lcd0>;
#iommu-cells = <0>;
};
+
+ prng: rng@10830400 {
+ compatible = "samsung,exynos4-rng";
+ reg = <0x10830400 0x200>;
+ clocks = < CLK_SSS>;
+ clock-names = "secss";
+ status = "disabled";
+ };
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] clk: samsung: exynos4: Add SSS gate clock
Add a gate clock for controlling all clocks of Security Sub System
(SSS).
Signed-off-by: Krzysztof Kozlowski
---
drivers/clk/samsung/clk-exynos4.c | 1 +
include/dt-bindings/clock/exynos4.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 7f370d3e0983..ac03e4fe2871 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -1024,6 +1024,7 @@ static struct samsung_gate_clock exynos4_gate_clks[]
__initdata = {
0, 0),
GATE(CLK_AC97, "ac97", "aclk100", GATE_IP_PERIL, 27,
0, 0),
+ GATE(CLK_SSS, "sss", "aclk133", GATE_IP_DMC, 4, 0, 0),
GATE(CLK_PPMUDMC0, "ppmudmc0", "aclk133", GATE_IP_DMC, 8, 0, 0),
GATE(CLK_PPMUDMC1, "ppmudmc1", "aclk133", GATE_IP_DMC, 9, 0, 0),
GATE(CLK_PPMUCPU, "ppmucpu", "aclk133", GATE_IP_DMC, 10, 0, 0),
diff --git a/include/dt-bindings/clock/exynos4.h
b/include/dt-bindings/clock/exynos4.h
index c4b1676ea674..c40111f36d5e 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -93,6 +93,7 @@
#define CLK_SCLK_FIMG2D177
/* gate clocks */
+#define CLK_SSS255
#define CLK_FIMC0 256
#define CLK_FIMC1 257
#define CLK_FIMC2 258
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] ARM: dts: Enable Exynos RNG module
Hi, The patchset adds necessary clock from Security SubSystem (SSS) and enables the PRNG module of Exynos for Trats2 board. The first patch (clock) is required for other ones so please take everything in one step. The actual Device Tree support (and compatible) was sent in separate patch: - https://patchwork.kernel.org/patch/7432891/ - http://marc.info/?l=linux-crypto-vger=144522952725052=2 The device can be tested (after applying both patchsets) with: $ echo exynos > /sys/class/misc/hw_random/rng_current $ dd if=/dev/hwrng of=/dev/null bs=1 count=16 Best regards, Krzysztof Krzysztof Kozlowski (3): clk: samsung: exynos4: Add SSS gate clock ARM: dts: Add PRNG module for exynos4 ARM: dts: Enable PRNG module on exynos4412-trats2 arch/arm/boot/dts/exynos4.dtsi | 8 arch/arm/boot/dts/exynos4412-trats2.dts | 4 drivers/clk/samsung/clk-exynos4.c | 1 + include/dt-bindings/clock/exynos4.h | 1 + 4 files changed, 14 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] perf: fix building for ARCv1
On Monday 19 October 2015 04:45 AM, Andi Kleen wrote: > Alexey Brodkin writes: >> So the best we may do is to implement detection of atomics in the toolchain >> and if there's no atomics hard stop with >> perf building. > If your target is single cpu only you can always simulate them in C. > > -Andi But this user space - so IMHO UP/SMP doesn't matter and we can't simulate them in C just by itself. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] x86: Kill notsc
On Sun, Oct 18, 2015 at 7:20 AM, Borislav Petkov wrote: > Ok, > > let's try this and see where it takes us. Patch has been only lightly > tested in kvm - I'll hammer on it for real once we agree about the > general form. > > Aanyway, this patch is something Peter and I have been talking about on > IRC a couple of times already. I finally found some free time to poke at > it, here's the result. > > Thoughts? I'm a bit confused. Is it currently the case that, if you boot a normal kernel on a TSC-less machine without notsc, it fails? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/asm] x86/entry/32: Fix entry_INT80_32() to expect interrupts to be on
On Oct 18, 2015 3:16 AM, "tip-bot for Andy Lutomirski" wrote: > > Commit-ID: 657c1eea0019e80685a84cbb1919794243a187c9 > Gitweb: http://git.kernel.org/tip/657c1eea0019e80685a84cbb1919794243a187c9 > Author: Andy Lutomirski > AuthorDate: Fri, 16 Oct 2015 15:42:54 -0700 > Committer: Ingo Molnar > CommitDate: Sun, 18 Oct 2015 12:11:16 +0200 > > x86/entry/32: Fix entry_INT80_32() to expect interrupts to be on FWIW, I may want to revert this down the road, but it's fine for now. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] hwrng: exynos - Add Device Tree support
Add Device Tree support for the driver. The Pseudo Random Number
Generator module is the same in almost all of Exynos SoCs, since
Exynos4210 (however the tests were done only on Trats2 board with
Exynos4412). There are some differences on newer Exynos Octa
(Exynos542x) SoCs.
Signed-off-by: Krzysztof Kozlowski
---
drivers/char/hw_random/exynos-rng.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/char/hw_random/exynos-rng.c
b/drivers/char/hw_random/exynos-rng.c
index 162adbda1b70..7077c7741dae 100644
--- a/drivers/char/hw_random/exynos-rng.c
+++ b/drivers/char/hw_random/exynos-rng.c
@@ -188,10 +188,19 @@ static const struct dev_pm_ops exynos_rng_pm_ops = {
exynos_rng_runtime_resume, NULL)
};
+static const struct of_device_id exynos_rng_dt_match[] = {
+ {
+ .compatible = "samsung,exynos4-rng",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, exynos_rng_dt_match);
+
static struct platform_driver exynos_rng_driver = {
.driver = {
.name = "exynos-rng",
.pm = _rng_pm_ops,
+ .of_match_table = exynos_rng_dt_match,
},
.probe = exynos_rng_probe,
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] dt-bindings: rng: Describe Exynos4 PRNG bindings
Document the bindings used by exynos-rng Pseudo Random Number Generator
driver.
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/rng/samsung,exynos-rng4.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt
diff --git a/Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt
b/Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt
new file mode 100644
index ..4ca8dd4d7e66
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt
@@ -0,0 +1,17 @@
+Exynos Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should be "samsung,exynos4-rng".
+- reg : Specifies base physical address and size of the registers map.
+- clocks : Phandle to clock-controller plus clock-specifier pair.
+- clock-names : "secss" as a clock name.
+
+Example:
+
+ rng@10830400 {
+ compatible = "samsung,exynos4-rng";
+ reg = <0x10830400 0x200>;
+ clocks = < CLK_SSS>;
+ clock-names = "secss";
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] hwrng: exynos - Fix missing configuration after suspend to RAM
After suspend to RAM the device stopped to work with ETIMEDOUT error:
$ dd if=/dev/hwrng of=/dev/null bs=1 count=16
dd: reading `/dev/hwrng': Connection timed out
In the STATUS register the bits #5 (PRNG_DONE) and #1
(SEED_SETTING_DONE) were not set. Instead PRNG_ERROR (seventh bit) was
high.
After each system suspend initialize the seed to fix the error.
Signed-off-by: Krzysztof Kozlowski
---
drivers/char/hw_random/exynos-rng.c | 42 ++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/char/hw_random/exynos-rng.c
b/drivers/char/hw_random/exynos-rng.c
index dffb8ddd..162adbda1b70 100644
--- a/drivers/char/hw_random/exynos-rng.c
+++ b/drivers/char/hw_random/exynos-rng.c
@@ -53,15 +53,11 @@ static void exynos_rng_writel(struct exynos_rng *rng, u32
val, u32 offset)
__raw_writel(val, rng->mem + offset);
}
-static int exynos_init(struct hwrng *rng)
+static int exynos_rng_configure(struct exynos_rng *exynos_rng)
{
- struct exynos_rng *exynos_rng = container_of(rng,
- struct exynos_rng, rng);
int i;
int ret = 0;
- pm_runtime_get_sync(exynos_rng->dev);
-
for (i = 0 ; i < 5 ; i++)
exynos_rng_writel(exynos_rng, jiffies,
EXYNOS_PRNG_SEED_OFFSET + 4*i);
@@ -70,6 +66,17 @@ static int exynos_init(struct hwrng *rng)
& SEED_SETTING_DONE))
ret = -EIO;
+ return ret;
+}
+
+static int exynos_init(struct hwrng *rng)
+{
+ struct exynos_rng *exynos_rng = container_of(rng,
+ struct exynos_rng, rng);
+ int ret = 0;
+
+ pm_runtime_get_sync(exynos_rng->dev);
+ ret = exynos_rng_configure(exynos_rng);
pm_runtime_put_noidle(exynos_rng->dev);
return ret;
@@ -155,10 +162,31 @@ static int exynos_rng_runtime_resume(struct device *dev)
return clk_prepare_enable(exynos_rng->clk);
}
+
+static int exynos_rng_suspend(struct device *dev)
+{
+ return pm_runtime_force_suspend(dev);
+}
+
+static int exynos_rng_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct exynos_rng *exynos_rng = platform_get_drvdata(pdev);
+ int ret;
+
+ ret = pm_runtime_force_resume(dev);
+ if (ret)
+ return ret;
+
+ return exynos_rng_configure(exynos_rng);
+}
#endif
-static UNIVERSAL_DEV_PM_OPS(exynos_rng_pm_ops, exynos_rng_runtime_suspend,
- exynos_rng_runtime_resume, NULL);
+static const struct dev_pm_ops exynos_rng_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(exynos_rng_suspend, exynos_rng_resume)
+ SET_RUNTIME_PM_OPS(exynos_rng_runtime_suspend,
+ exynos_rng_runtime_resume, NULL)
+};
static struct platform_driver exynos_rng_driver = {
.driver = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] hwrng: exynos - Add timeout for waiting on init done
Driver may hang waiting indefinitely for PRNG to finish its initialization stage. Instead of stalling return -ETIMEDOUT error. Signed-off-by: Krzysztof Kozlowski --- drivers/char/hw_random/exynos-rng.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/char/hw_random/exynos-rng.c b/drivers/char/hw_random/exynos-rng.c index dc4701fd814f..dffb8ddd 100644 --- a/drivers/char/hw_random/exynos-rng.c +++ b/drivers/char/hw_random/exynos-rng.c @@ -81,14 +81,17 @@ static int exynos_read(struct hwrng *rng, void *buf, struct exynos_rng *exynos_rng = container_of(rng, struct exynos_rng, rng); u32 *data = buf; + int retry = 100; pm_runtime_get_sync(exynos_rng->dev); exynos_rng_writel(exynos_rng, PRNG_START, 0); while (!(exynos_rng_readl(exynos_rng, - EXYNOS_PRNG_STATUS_OFFSET) & PRNG_DONE)) + EXYNOS_PRNG_STATUS_OFFSET) & PRNG_DONE) && --retry) cpu_relax(); + if (!retry) + return -ETIMEDOUT; exynos_rng_writel(exynos_rng, PRNG_DONE, EXYNOS_PRNG_STATUS_OFFSET); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] serial: 8250_uniphier: fix dl_read and dl_write functions
The register offset must be shifted by regshift, otherwise the
baudrate is not set. I missed the issue probably because the
divisor register was already set by the boot loader.
Fixes: 1a8d2903cb6a ("serial: 8250_uniphier: add UniPhier serial driver")
Signed-off-by: Masahiro Yamada
---
Hi Greg,
Please apply this simple fix for Linux 4.3.
Thanks,
Masahiro
drivers/tty/serial/8250/8250_uniphier.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_uniphier.c
b/drivers/tty/serial/8250/8250_uniphier.c
index d11621e..245edbb 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -115,12 +115,16 @@ static void uniphier_serial_out(struct uart_port *p, int
offset, int value)
*/
static int uniphier_serial_dl_read(struct uart_8250_port *up)
{
- return readl(up->port.membase + UNIPHIER_UART_DLR);
+ int offset = UNIPHIER_UART_DLR << up->port.regshift;
+
+ return readl(up->port.membase + offset);
}
static void uniphier_serial_dl_write(struct uart_8250_port *up, int value)
{
- writel(value, up->port.membase + UNIPHIER_UART_DLR);
+ int offset = UNIPHIER_UART_DLR << up->port.regshift;
+
+ writel(value, up->port.membase + offset);
}
static int uniphier_of_serial_setup(struct device *dev, struct uart_port *port,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/mpc5xxx: Avoid dereferencing potentially freed memory
On Fri, 2015-10-16 at 22:05 +0200, Christophe JAILLET wrote: > Hi, > sorry if un-clear. > > What I mean is that in the patch related > 'powerpc/sysdev/mpc5xxx_clocks.c', there was no call to 'be32_to_cpup'. > So in the proposed patch, 'of_property_read_u32' adds it. > > While in the patch against 'powerpc/kernel/prom.c', 'be32_to_cpup' was > called explicitly. > So using 'of_property_read_u32' keep the same logic. Ah right, I understand now. > Basically the code from 'mpc5xxx_clocks.c' and from 'prom.c' were > written the same way. I found spurious that a call to 'be32_to_cpup' was > done in only one case. > Maybe, it was a missing in 'mpc5xxx_clocks.c'. Yes it was missing in that code. But that's not a real bug because that code only ever runs on BE systems. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] hwrng: exynos - Add Device Tree support
Hi, The patchset fixes known issues in Exynos hardware random number generator and adds Device Tree support for it. The device was tested on Trats2 board (Exynos4412). It should work on other Exynos4 and Exynos5 as well... altough it seems that on some of Exynos542x boards the SSS module is secured. Best regards, Krzysztof Krzysztof Kozlowski (4): dt-bindings: rng: Describe Exynos4 PRNG bindings hwrng: exynos - Add timeout for waiting on init done hwrng: exynos - Fix missing configuration after suspend to RAM hwrng: exynos - Add Device Tree support .../bindings/rng/samsung,exynos-rng4.txt | 17 +++ drivers/char/hw_random/exynos-rng.c| 56 ++ 2 files changed, 65 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.2 000/258] 4.2.4-stable review
On 10/17/2015 06:55 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.2.4 release.
There are 258 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Tue Oct 20 01:46:04 UTC 2015.
Anything received after that time might be too late.
Build results:
total: 144 pass: 142 fail: 2
Failed builds:
powerpc:defconfig
powerpc:allmodconfig
Qemu test results:
total: 93 pass: 92 fail: 1
Failed tests:
powerpc:pseries_defconfig
Failures are:
arch/powerpc/kvm/book3s_hv.c: In function 'kvmppc_run_vcpu':
arch/powerpc/kvm/book3s_hv.c:2181:3: error: too few arguments to function
'should_resched'
Caused by "sched/preempt: Fix cond_resched_lock() and cond_resched_softirq()".
Needs c56dadf39761a61 ("sched/preempt, powerpc, kvm: Use need_resched() instead
of should_resched()") as far as I can see.
Details are available at http://server.roeck-us.net:8010/builders.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ***SPAM*** [PATCH 4.1 000/202] 4.1.11-stable review
On 10/17/2015 06:56 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.1.11 release. There are 202 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Oct 20 01:48:10 UTC 2015. Anything received after that time might be too late. Build results: total: 137 pass: 137 fail: 0 Qemu test results: total: 93 pass: 93 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/79] 3.14.55-stable review
On 10/17/2015 07:04 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.55 release. There are 79 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Oct 20 02:00:11 UTC 2015. Anything received after that time might be too late. Build results: total: 127 pass: 125 fail: 2 Failed builds: hexagon:defconfig hexagon:allnoconfig Qemu test results: total: 80 pass: 80 fail: 0 The hexagon build failures are different than before, but the builds still fail. In file included from include/linux/mm.h:19:0, from arch/hexagon/kernel/asm-offsets.c:28: include/linux/bit_spinlock.h: In function 'bit_spin_unlock': include/linux/bit_spinlock.h:62:2: error: implicit declaration of function 'smp_mb__before_clear_bit' In file included from arch/hexagon/kernel/asm-offsets.c:29:0: include/linux/interrupt.h: In function 'tasklet_disable_nosync': include/linux/interrupt.h:541:2: error: implicit declaration of function 'smp_mb__after_atomic_inc' include/linux/interrupt.h: In function 'tasklet_enable': include/linux/interrupt.h:553:2: error: implicit declaration of function 'smp_mb__before_atomic_dec' Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/54] 3.10.91-stable review
On 10/17/2015 07:05 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.91 release. There are 54 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Oct 20 02:00:19 UTC 2015. Anything received after that time might be too late. Build results: total: 121 pass: 121 fail: 0 Qemu test results: total: 70 pass: 70 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/2] bpf: control the trace data output on current cpu when perf sampling
于 2015/10/17 6:06, Alexei Starovoitov 写道:
> On 10/16/15 12:42 AM, Kaixu Xia wrote:
>> This patch adds the flag dump_enable to control the trace data
>> output process when perf sampling. By setting this flag and
>> integrating with ebpf, we can control the data output process and
>> get the samples we are most interested in.
>>
>> The bpf helper bpf_perf_event_dump_control() can control the
>> perf_event on current cpu.
>>
>> Signed-off-by: Kaixu Xia
>> ---
>> include/linux/perf_event.h | 1 +
>> include/uapi/linux/bpf.h| 5 +
>> include/uapi/linux/perf_event.h | 3 ++-
>> kernel/bpf/verifier.c | 3 ++-
>> kernel/events/core.c| 13
>> kernel/trace/bpf_trace.c| 44
>> +
>> 6 files changed, 67 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index 092a0e8..2af527e 100644
>> --- a/include/linux/perf_event.h
>> +++ b/include/linux/perf_event.h
>> @@ -472,6 +472,7 @@ struct perf_event {
>> struct irq_workpending;
>>
>> atomic_tevent_limit;
>> +atomic_tdump_enable;
>
> The naming is the hardest...
> How about calling it 'soft_enable' instead?
>
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -287,6 +287,11 @@ enum bpf_func_id {
>>* Return: realm if != 0
>>*/
>> BPF_FUNC_get_route_realm,
>> +
>> +/**
>> + * u64 bpf_perf_event_dump_control(, index, flag)
>> + */
>> +BPF_FUNC_perf_event_dump_control,
>
> and this one is too long.
> May be bpf_perf_event_control() ?
>
> Daniel, any thoughts on naming?
>
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -331,7 +331,8 @@ struct perf_event_attr {
>> comm_exec : 1, /* flag comm events that are due to
>> an exec */
>> use_clockid: 1, /* use @clockid for time fields */
>> context_switch : 1, /* context switch data */
>> -__reserved_1 : 37;
>> +dump_enable: 1, /* don't output data on samples */
>
> either comment or name is wrong.
> how about calling this one 'soft_disable',
> since you want zero to be default and the event should be on.
>
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index b11756f..74a16af 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -6337,6 +6337,9 @@ static int __perf_event_overflow(struct perf_event
>> *event,
>> irq_work_queue(>pending);
>> }
>>
>> +if (!atomic_read(>dump_enable))
>> +return ret;
>
> I'm not an expert in this piece of perf, but should it be 'return 0'
> instead ?
> and may be moved to is_sampling_event() check?
> Also please add unlikely().
The is_sampling_event() is checked in many other kernel places, not only in
perf events interrupt overflow handle. I'm not sure it is fine if we move it
to there. In addition, I think hwc->interrupts++ should be done in
__perf_event_overflow() before event->soft_enable is checked.
>
>> +static void perf_event_check_dump_flag(struct perf_event *event)
>> +{
>> +if (event->attr.dump_enable == 1)
>> +atomic_set(>dump_enable, 1);
>> +else
>> +atomic_set(>dump_enable, 0);
>
> that looks like it breaks perf, since default for bits is zero
> and all events will be soft-disabled?
> How did you test it?
> Please add a test to samples/bpf/ for this feature.
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] workqueue fixes for v4.3-rc5
On Wed, 2015-10-14 at 16:24 -0400, Tejun Heo wrote: > But in terms of API consistency, it sucks to have queue_work() > guarantee local queueing but not queue_delayed_work(). The ideal > situation would be updating both so that neither guarantees. You don't have to change anything to have neither guarantee local queueing. Called from a preemptible context, local means any CPU in ->cpus_allowed... which makes WORK_CPU_UNBOUND mean what one would imagine WORK_CPU_UNBOUND to mean, not bound to any particular cpu. sh-16017 3.N.. 1510500545us : queue_work_on: golly, migrated cpu7 -> cpu3 -- target cpu8 sh-16017 3.N.. 1510500550us : => tty_flip_buffer_push => pty_write => n_tty_write => tty_write => __vfs_write => vfs_write => SyS_write => entry_SYSCALL_64_fastpath That was with a udelay(100) prior to disabling interrupts, but that just makes it easier. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach
Hi Javier,
On 10/15/2015 10:21 PM, Javier Martinez Canillas wrote:
Hello,
The Exynos Chromebooks DTS don't use the correct card detection properties
since these were carried from the vendor tree that had a reason to do so.
There are two things that I noticed:
1) The Marvell WiFi SDIO is marked as broken-cd instead of non-removable:
This causes the device to be removed when the system enters into a suspend
state which leads to the following warning when the system is resumed:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
The rationale for using broken-cd is explained in downstream commit [0] and
was that using the non-removable property caused issues with the mwifiex
driver since the reset logic called the mmc_{remove,add}_host() functions.
But the reset logic in the mwifiex mainline driver has changed and this is
no longer the case so it's safe to use the non-removable property AFAICT.
2) The eMMC node has both broken-cd and non-removable but the MMC DT binding
doc (Documentation/devicetree/bindings/mmc/mmc.txt) mentions that only one
of these card detection properties should be used.
So this series change both the SDIO WiFi and eMMC device nodes in the Snow,
Peach Pi and Peach Pit boards DTS to use the non-removable property.
To test, I've cherry picked commit [1] from the vendor tree that adds a
debugfs entry to force a card reset and after the reset, the WiFi card still
works correctly:
$ echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset
And also tested that both eMMC and WiFi are working correctly after a S2R.
The test were made on an Exynos5800 Peach Pi but I don't have access to a
Snow anymore so testing patch 3/6 and 6/6 on that board will be appreciated.
v1 of the series was [2] and this version fixes issues pointed out by Tomeu.
Changes since v1:
- Replace broken-cd for non-removable in the correct mmc node for Snow.
- Correct the card detetion properties for eMMC in Snow, Pit and Pi.
- Also remove the card-detect-delay property when using non-removable.
[0]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad348e1e2381
[1]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5995363523de
[2]: https://lkml.org/lkml/2015/10/15/294
Best regards,
Javier
Javier Martinez Canillas (6):
ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
This series looks good to me, so feel free to add
Reviewed-by: Alim Akhtar
and for patch 4 and 5: Tested-by: Alim Akhtar
Thanks.
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 6 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts| 5 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
3 files changed, 4 insertions(+), 12 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency
From: Magnus Damm Neither the ARM page table code enabled by IOMMU_IO_PGTABLE_LPAE nor the IPMMU_VMSA driver actually depends on ARM_LPAE, so get rid of the dependency. Tested with ipmmu-vmsa on r8a7794 ALT and a kernel config using: # CONFIG_ARM_LPAE is not set Signed-off-by: Magnus Damm --- drivers/iommu/Kconfig |1 - 1 file changed, 1 deletion(-) --- 0001/drivers/iommu/Kconfig +++ work/drivers/iommu/Kconfig 2015-10-18 14:58:09.080513000 +0900 @@ -324,7 +324,6 @@ config SHMOBILE_IOMMU_L1SIZE config IPMMU_VMSA bool "Renesas VMSA-compatible IPMMU" - depends on ARM_LPAE depends on ARCH_SHMOBILE || COMPILE_TEST select IOMMU_API select IOMMU_IO_PGTABLE_LPAE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 4.3-rc6
On Sun, Oct 18, 2015 at 7:38 PM, Randy Dunlap wrote: > > When using 'patch' and patch-4.3-rc6.gz to create a Linux 4.3-rc6 source tree, > scripts/kernel-doc-xml-ref is not created as executable. (This has been > happening for several -rc releases now). 'patch' doesn't know anything about file modes. It ignores all the nice git extensions, and has no idea what the line new file mode 100755 means in a git patch. (Well, at least traditional "patch" doesn't understand it. I know some people have worked at adding basic git patch support to newer versions of "patch", since things like git rename patches etc are obviously so superior to traditional patches). > Am I doing something wrong? (other than not using git) Use git. You can use "git apply" as a replacement for "patch", even if you don't actually use a git repository or use git in any other form. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/2] bpf: control the trace data output on current cpu when perf sampling
于 2015/10/17 6:06, Alexei Starovoitov 写道:
> On 10/16/15 12:42 AM, Kaixu Xia wrote:
>> This patch adds the flag dump_enable to control the trace data
>> output process when perf sampling. By setting this flag and
>> integrating with ebpf, we can control the data output process and
>> get the samples we are most interested in.
>>
>> The bpf helper bpf_perf_event_dump_control() can control the
>> perf_event on current cpu.
>>
>> Signed-off-by: Kaixu Xia
>> ---
>> include/linux/perf_event.h | 1 +
>> include/uapi/linux/bpf.h| 5 +
>> include/uapi/linux/perf_event.h | 3 ++-
>> kernel/bpf/verifier.c | 3 ++-
>> kernel/events/core.c| 13
>> kernel/trace/bpf_trace.c| 44
>> +
>> 6 files changed, 67 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index 092a0e8..2af527e 100644
>> --- a/include/linux/perf_event.h
>> +++ b/include/linux/perf_event.h
>> @@ -472,6 +472,7 @@ struct perf_event {
>> struct irq_workpending;
>>
>> atomic_tevent_limit;
>> +atomic_tdump_enable;
>
> The naming is the hardest...
> How about calling it 'soft_enable' instead?
>
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -287,6 +287,11 @@ enum bpf_func_id {
>>* Return: realm if != 0
>>*/
>> BPF_FUNC_get_route_realm,
>> +
>> +/**
>> + * u64 bpf_perf_event_dump_control(, index, flag)
>> + */
>> +BPF_FUNC_perf_event_dump_control,
>
> and this one is too long.
> May be bpf_perf_event_control() ?
>
> Daniel, any thoughts on naming?
>
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -331,7 +331,8 @@ struct perf_event_attr {
>> comm_exec : 1, /* flag comm events that are due to
>> an exec */
>> use_clockid: 1, /* use @clockid for time fields */
>> context_switch : 1, /* context switch data */
>> -__reserved_1 : 37;
>> +dump_enable: 1, /* don't output data on samples */
>
> either comment or name is wrong.
> how about calling this one 'soft_disable',
> since you want zero to be default and the event should be on.
>
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index b11756f..74a16af 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -6337,6 +6337,9 @@ static int __perf_event_overflow(struct perf_event
>> *event,
>> irq_work_queue(>pending);
>> }
>>
>> +if (!atomic_read(>dump_enable))
>> +return ret;
>
> I'm not an expert in this piece of perf, but should it be 'return 0'
> instead ?
> and may be moved to is_sampling_event() check?
> Also please add unlikely().
>
>> +static void perf_event_check_dump_flag(struct perf_event *event)
>> +{
>> +if (event->attr.dump_enable == 1)it
>> +atomic_set(>dump_enable, 1);
>> +else
>> +atomic_set(>dump_enable, 0);
>
> that looks like it breaks perf, since default for bits is zero
> and all events will be soft-disabled?
> How did you test it?
> Please add a test to samples/bpf/ for this feature.
It is really hard that adding a test to samples/bpf/. We need to implement most
of
'perf record/report' commands from tools/perf/, like mmap(), dump trace, etc.
Only
the perf_event_open syscall is really not enough.
Actually, this patch set is only the kernel space side, and it still needs the
perf
user space side, you can find the necessary patches in Wang Nan's git tree[1].
Based on Wang Nan's git tree, we can config BPF maps through perf cmdline.
We also need to confing attr->soft_disable in perf user side based on tree[1].
so
it was not included in this patchset. I will send out the perf userspace part
after
this patch set is applied.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/pi3orama/linux.git perf/ebpf
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: hisilicon: add OF dependency
From: Arnd Bergmann Date: Fri, 16 Oct 2015 11:33:49 +0200 > The HNS MDIO driver fails to build on older ARM machines that are not > yet converted to CONFIG_OF: > > drivers/net/ethernet/hisilicon/hns_mdio.c: In function 'hns_mdio_bus_name': > drivers/net/ethernet/hisilicon/hns_mdio.c:405:14: error: 'OF_BAD_ADDR' > undeclared (first use in this function) > u64 taddr = OF_BAD_ADDR; > ^ > drivers/net/ethernet/hisilicon/hns_mdio.c:405:14: note: each undeclared > identifier is reported only once for each function it appears in > drivers/net/ethernet/hisilicon/hns_mdio.c:409:11: error: implicit declaration > of function 'of_translate_address' [-Werror=implicit-function-declaration] >taddr = of_translate_address(np, addr); >^ > > This clarifies the dependency to ensure we don't attempt to build these > drivers without CONFIG_OF, but also adds a COMPILE_TEST alternative to > give us better build coverage testing. > > Build-tested on x86 as well to ensure this actually works. > > Signed-off-by: Arnd Bergmann Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: hix5hd2_gmac: avoid integer overload warning
From: Arnd Bergmann Date: Fri, 16 Oct 2015 12:00:51 +0200 > BITS_RX_EN is an 'unsigned long' constant, so the ones complement of that > has bits set that do not fit into a 32-bit variable on 64-bit architectures, > which causes a harmless gcc warning: > > drivers/net/ethernet/hisilicon/hix5hd2_gmac.c: In function > 'hix5hd2_port_disable': > drivers/net/ethernet/hisilicon/hix5hd2_gmac.c:374:2: warning: large integer > implicitly truncated to unsigned type [-Woverflow] > writel_relaxed(~(BITS_RX_EN | BITS_TX_EN), priv->base + PORT_EN); > > This adds a cast to (u32) to tell gcc that the code is indeed fine. > > Signed-off-by: Arnd Bergmann Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] Staging: rtl8712: fix warning for placing constant on the right side of test
On 10/18/2015 09:00 PM, Greg KH wrote: On Sun, Oct 18, 2015 at 12:02:53PM +0530, punit vara wrote: One more thing I would like suggestion how can start switching this driver to LIB80211 ,MAC80211 ? Which is the first file I should focus ? Simultaneously I am trying to understand the flow of driver . I would like to know the start point from where I can start doing small changes. If you don't understand the wireless stack, I suggest you do some research on it first, converting a driver to the in-kernel stack is a _very_ difficult thing and not something that someone without any experience in this area is going to be able to do easily. I second this suggestion. Your skill level is not nearly sufficient for this sort of task. Note that there is a group working on driver rtl8192su, which should be able to replace rtl8712u. The participants are very highly skilled wireless developers; however, they are having trouble. The internals of the Realtek chips are not revealed to anyone in any form other than the code they release. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: hisilicon: include linux/vmalloc.h in dsaf
From: Arnd Bergmann Date: Fri, 16 Oct 2015 11:30:56 +0200 > Some configurations fail to build the hns dsaf code because of > a missing header file: > > ethernet/hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_init': > ethernet/hisilicon/hns/hns_dsaf_main.c:1096:2: error: implicit declaration of > function 'vzalloc' [-Werror=implicit-function-declaration] > priv->soft_mac_tbl = vzalloc(sizeof(*priv->soft_mac_tbl) > > This adds the correct #include. > > Signed-off-by: Arnd Bergmann Applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 0/2] net: hns: fixes two bugs in hns driver
From: yankejian Date: Fri, 16 Oct 2015 17:03:18 +0800 > This patchset fixes two bugs in hns driver. > - fixes timeout when received pause frame from the connective ports > - should be set by using ethtool -s when the devices are link down Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Introduce kernelcore=reliable option
On 2015/10/15 21:32, Taku Izumi wrote: > Xeon E7 v3 based systems supports Address Range Mirroring > and UEFI BIOS complied with UEFI spec 2.5 can notify which > ranges are reliable (mirrored) via EFI memory map. > Now Linux kernel utilize its information and allocates > boot time memory from reliable region. > > My requirement is: > - allocate kernel memory from reliable region > - allocate user memory from non-reliable region > > In order to meet my requirement, ZONE_MOVABLE is useful. > By arranging non-reliable range into ZONE_MOVABLE, > reliable memory is only used for kernel allocations. > > This patch extends existing "kernelcore" option and > introduces kernelcore=reliable option. By specifying > "reliable" instead of specifying the amount of memory, > non-reliable region will be arranged into ZONE_MOVABLE. > > Earlier discussion is at: > https://lkml.org/lkml/2015/10/9/24 > Hi Taku, If user don't want to waste a lot of memory, and he only set a few memory to mirrored memory, then the kernelcore is very small, right? That means OS will have a very small normal zone and a very large movable zone. Kernel allocation could only use the unmovable zone. As the normal zone is very small, the kernel allocation maybe OOM, right? Do you mean that we will reuse the movable zone in short-term solution and create a new zone(mirrored zone) in future? Thanks, Xishi Qiu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 4.3-rc6
On 10/18/15 16:45, Linus Torvalds wrote: > When using 'patch' and patch-4.3-rc6.gz to create a Linux 4.3-rc6 source tree, scripts/kernel-doc-xml-ref is not created as executable. (This has been happening for several -rc releases now). Am I doing something wrong? (other than not using git) or is there some way that this can be fixed so that building documentation does not fail on trying to execute that script file? lnx-43-rc6> ls -l scripts/kernel-doc-xml-ref -rw-r--r-- 1 rdunlap users 4324 Oct 18 19:29 scripts/kernel-doc-xml-ref thanks, -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v3 0/2] net: hisilicon fix some bugs in HNS drivers
From: huangdaode Date: Fri, 16 Oct 2015 11:54:15 +0800 > This patchset fixes the two bugs in HNS driver, one is remove the hnae sysfs > interface > according to the review comments from Arnd Bergmann , another > is fixing the wrong mac_id judgement bug which is found during internal tests. Series applied, tanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 0/4] BPF updates
From: Daniel Borkmann Date: Fri, 16 Oct 2015 03:09:21 +0200 > This set adds support for persistent maps/progs. Please see > individual patches for further details. > > A man-page update to bpf(2) will be sent afterwards, also a > iproute2 patch for support in tc. > > Thanks! It seems like the design here is still a little bit in flux, so I'm marking this as "changes requested" in patchwork. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] qspinlock: Improve performance by reducing load instruction rollback
From: Ma Ling
All load instructions can run speculatively but they have to follow
memory order rule in multiple cores as below:
_x = _y = 0
Processor 0 Processor 1
mov r1, [ _y] //M1 mov [ _x], 1 //M3
mov r2, [ _x] //M2 mov [ _y], 1 //M4
If r1 = 1, r2 must be 1
In order to guarantee above rule, although Processor 0 execute
M1 and M2 instruction out of order, they are kept in ROB,
when load buffer for _x in Processor 0 received the update
message from Processor 1, Processor 0 need to roll back
from M2 instruction, which will flush the whole pipeline,
the latency is over the penalty from branch prediction miss.
In this patch we use lock cmpxchg instruction to force load
instructions to be serialization, the destination operand
receives a write cycle without regard to the result of
the comparison, which can help us to reduce the penalty
from load instruction roll back.
Our experiment indicates the performance can be improved by 10%~15%
for 2 and 3 threads cases, the conflicts from lock cache line
spend them most of the time.
Thanks
Ling
Signed-off-by: Ma Ling
---
kernel/locking/qspinlock.c | 43 ++-
1 files changed, 18 insertions(+), 25 deletions(-)
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index 87e9ce6..16421f2 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -332,25 +332,14 @@ void queued_spin_lock_slowpath(struct qspinlock *lock,
u32 val)
if (new == _Q_LOCKED_VAL)
return;
- /*
-* we're pending, wait for the owner to go away.
-*
-* *,1,1 -> *,1,0
+ /* we're waiting, and get lock owner
*
-* this wait loop must be a load-acquire such that we match the
-* store-release that clears the locked bit and create lock
-* sequentiality; this is because not all clear_pending_set_locked()
-* implementations imply full barriers.
+* *,1,* -> *,0,1
*/
- while ((val = smp_load_acquire(>val.counter)) & _Q_LOCKED_MASK)
+ while (cmpxchg(&((struct __qspinlock *)lock)->locked_pending,
+ _Q_PENDING_VAL, _Q_LOCKED_VAL) != _Q_PENDING_VAL)
cpu_relax();
-
- /*
-* take ownership and clear the pending bit.
-*
-* *,1,0 -> *,0,1
-*/
- clear_pending_set_locked(lock);
+
return;
/*
@@ -399,17 +388,21 @@ queue:
* we're at the head of the waitqueue, wait for the owner & pending to
* go away.
*
-* *,x,y -> *,0,0
-*
-* this wait loop must use a load-acquire such that we match the
-* store-release that clears the locked bit and create lock
-* sequentiality; this is because the set_locked() function below
-* does not imply a full barrier.
-*
+* *,x,y -> *,0,1
*/
pv_wait_head(lock, node);
- while ((val = smp_load_acquire(>val.counter)) &
_Q_LOCKED_PENDING_MASK)
+ next = READ_ONCE(node->next);
+ while (cmpxchg(&((struct __qspinlock *)lock)->locked_pending, 0,
+ _Q_LOCKED_VAL) != 0) {
+ next = READ_ONCE(node->next);
cpu_relax();
+ }
+
+ if (next)
+ goto next_node;
+
+ val = smp_load_acquire(>val.counter);
+ tail = tail | _Q_LOCKED_VAL;
/*
* claim the lock:
@@ -423,7 +416,6 @@ queue:
*/
for (;;) {
if (val != tail) {
- set_locked(lock);
break;
}
old = atomic_cmpxchg(>val, val, _Q_LOCKED_VAL);
@@ -439,6 +431,7 @@ queue:
while (!(next = READ_ONCE(node->next)))
cpu_relax();
+next_node:
arch_mcs_spin_unlock_contended(>locked);
pv_kick_node(lock, next);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 09/14] ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic
ACPICA commit 0dd68e16274cd38224aa4781eddc57dc2cbaa108
The quit/exit commands shouldn't invoke acpi_terminate_debugger() and
acpi_terminate() right in the user command loop, because when the debugger
exits, the kernel ACPI subsystem shouldn't be terminated (acpi_terminate())
and the debugger should only be terminated by its users
(acpi_terminate_debugger()) rather than being terminated itself. Leaving such
invocations causes kernel panic when the debugger is shipped in the Linux
kernel.
This patch fixes this issue. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/0dd68e16
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acglobal.h |3 ++-
drivers/acpi/acpica/dbinput.c | 16
drivers/acpi/acpica/dbxface.c | 20
drivers/acpi/acpica/utinit.c |2 --
drivers/acpi/acpica/utxface.c |4
5 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 593de41..d82249c 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -324,7 +324,6 @@ ACPI_GLOBAL(struct acpi_external_file *,
acpi_gbl_external_file_list);
#ifdef ACPI_DEBUGGER
-ACPI_INIT_GLOBAL(u8, acpi_gbl_db_terminate_threads, FALSE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_abort_method, FALSE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_method_executing, FALSE);
@@ -336,6 +335,8 @@ ACPI_GLOBAL(char *, acpi_gbl_db_filename);
ACPI_GLOBAL(u32, acpi_gbl_db_debug_level);
ACPI_GLOBAL(u32, acpi_gbl_db_console_debug_level);
ACPI_GLOBAL(struct acpi_namespace_node *, acpi_gbl_db_scope_node);
+ACPI_GLOBAL(u8, acpi_gbl_db_terminate_loop);
+ACPI_GLOBAL(u8, acpi_gbl_db_threads_terminated);
ACPI_GLOBAL(char *, acpi_gbl_db_args[ACPI_DEBUGGER_MAX_ARGS]);
ACPI_GLOBAL(acpi_object_type, acpi_gbl_db_arg_types[ACPI_DEBUGGER_MAX_ARGS]);
diff --git a/drivers/acpi/acpica/dbinput.c b/drivers/acpi/acpica/dbinput.c
index 7f1b6ec..f8cddd6 100644
--- a/drivers/acpi/acpica/dbinput.c
+++ b/drivers/acpi/acpica/dbinput.c
@@ -694,7 +694,7 @@ acpi_db_command_dispatch(char *input_buffer,
/* If acpi_terminate has been called, terminate this thread */
- if (acpi_gbl_db_terminate_threads) {
+ if (acpi_gbl_db_terminate_loop) {
return (AE_CTRL_TERMINATE);
}
@@ -1116,7 +1116,7 @@ acpi_db_command_dispatch(char *input_buffer,
#ifdef ACPI_APPLICATION
acpi_db_close_debug_file();
#endif
- acpi_gbl_db_terminate_threads = TRUE;
+ acpi_gbl_db_terminate_loop = TRUE;
return (AE_CTRL_TERMINATE);
case CMD_NOT_FOUND:
@@ -1166,6 +1166,7 @@ void ACPI_SYSTEM_XFACE acpi_db_execute_thread(void
*context)
acpi_os_release_mutex(acpi_gbl_db_command_complete);
}
+ acpi_gbl_db_threads_terminated = TRUE;
}
/***
@@ -1212,7 +1213,7 @@ acpi_status acpi_db_user_commands(char prompt, union
acpi_parse_object *op)
/* TBD: [Restructure] Need a separate command line buffer for step mode
*/
- while (!acpi_gbl_db_terminate_threads) {
+ while (!acpi_gbl_db_terminate_loop) {
/* Force output to console until a command is entered */
@@ -1261,14 +1262,5 @@ acpi_status acpi_db_user_commands(char prompt, union
acpi_parse_object *op)
}
}
- /* Shut down the debugger */
-
- acpi_terminate_debugger();
-
- /*
-* Only this thread (the original thread) should actually terminate the
-* subsystem, because all the semaphores are deleted during termination
-*/
- status = acpi_terminate();
return (status);
}
diff --git a/drivers/acpi/acpica/dbxface.c b/drivers/acpi/acpica/dbxface.c
index 26023bd..bef5f4e 100644
--- a/drivers/acpi/acpica/dbxface.c
+++ b/drivers/acpi/acpica/dbxface.c
@@ -401,6 +401,10 @@ acpi_status acpi_initialize_debugger(void)
acpi_gbl_db_scope_buf[1] = 0;
acpi_gbl_db_scope_node = acpi_gbl_root_node;
+ /* Initialize user commands loop */
+
+ acpi_gbl_db_terminate_loop = FALSE;
+
/*
* If configured for multi-thread support, the debug executor runs in
* a separate thread so that the front end can be in another address
@@ -426,11 +430,13 @@ acpi_status acpi_initialize_debugger(void)
/* Create the debug execution thread to execute commands */
+ acpi_gbl_db_threads_terminated = FALSE;
status = acpi_os_execute(OSL_DEBUGGER_THREAD,
acpi_db_execute_thread, NULL);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status,
"Could not start debugger thread"));
+ acpi_gbl_db_threads_terminated = TRUE;
return_ACPI_STATUS(status);
[PATCH v2 13/14] ACPICA: Debugger: Fix dead lock issue ocurred in single stepping mode
ACPICA commit 35273add90da19cd8790fdb5735f52e3c9861684
When single step execution is not ended, executing another control methods
leads to dead locks around interpreter lock/namespace lock/method
serialization lock. So we should only allow one execution from the debugger
at same time. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/35273add
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/dbexec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/acpi/acpica/dbexec.c b/drivers/acpi/acpica/dbexec.c
index 258e615..d713e2d 100644
--- a/drivers/acpi/acpica/dbexec.c
+++ b/drivers/acpi/acpica/dbexec.c
@@ -370,7 +370,17 @@ acpi_db_execute(char *name, char **args, acpi_object_type
* types, u32 flags)
#ifdef ACPI_DEBUG_OUTPUT
u32 previous_allocations;
u32 allocations;
+#endif
+ /*
+* Allow one execution to be performed by debugger or single step
+* execution will be dead locked by the interpreter mutexes.
+*/
+ if (acpi_gbl_method_executing) {
+ acpi_os_printf("Only one debugger execution is allowed.\n");
+ return;
+ }
+#ifdef ACPI_DEBUG_OUTPUT
/* Memory allocation tracking */
previous_allocations = acpi_db_get_outstanding_allocations();
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 12/14] ACPI: Enable build of AML interpreter debugger
This patch enables ACPICA debugger files using a configurable CONFIG_ACPI_DEBUGGER configuration item. Those debugger related code that was originally masked as ACPI_FUTURE_USAGE now gets unmasked. Necessary OSL stubs are also added in this patch: 1. acpi_os_readable(): This should be arch specific in Linux, while this patch doesn't introduce real implementation and a complex mechanism to allow architecture specific acpi_os_readable() to be implemented to validate the address. It may be done by future commits. 2. acpi_os_get_line(): This is used to obtain debugger command input. This patch only introduces a simple KDB concept example in it and the example should be co-working with the code implemented in acpi_os_printf(). Since this KDB example won't be compiled unless ENABLE_DEBUGGER is defined and it seems Linux has already stopped to use ENABLE_DEBUGGER, thus do not expect it can work properly. This patch also cleans up all other ACPI_FUTURE_USAGE surroundings accordingly. 1. Since linkage error can be automatically detected, declaration in the headers needn't be surrounded by ACPI_FUTURE_USAGE. So only the following separate exported fuction bodies are masked by this macro (other exported fucntions may have already been masked at entire module level via drivers/acpi/acpica/Makefile): acpi_install_exception_handler() acpi_subsystem_status() acpi_get_system_info() acpi_get_statistics() acpi_install_initialization_handler() 2. Since strip can automatically zap the no-user functions, functions that are not marked with ACPI_EXPORT_SYMBOL() needn't get surrounded by ACPI_FUTURE_USAGE. So the following function which is not used by Linux kernel now won't get surrounded by this macro: acpi_ps_get_name() Signed-off-by: Lv Zheng --- drivers/acpi/Kconfig |9 + drivers/acpi/acpica/Makefile | 18 +- drivers/acpi/acpica/acinterp.h|2 -- drivers/acpi/acpica/acnamesp.h|4 drivers/acpi/acpica/acparser.h|4 drivers/acpi/acpica/acutils.h |2 -- drivers/acpi/acpica/evxface.c |2 +- drivers/acpi/acpica/nsdump.c |6 -- drivers/acpi/acpica/pstree.c |2 -- drivers/acpi/acpica/psutils.c |2 -- drivers/acpi/acpica/rsutils.c |2 -- drivers/acpi/acpica/rsxface.c |4 ++-- drivers/acpi/acpica/utxface.c |2 +- drivers/acpi/osl.c| 11 +++ include/acpi/acpixf.h | 10 -- include/acpi/platform/aclinux.h |7 +-- include/acpi/platform/aclinuxex.h |5 + 17 files changed, 43 insertions(+), 49 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 5d1015c..706c2e9 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -57,6 +57,15 @@ config ACPI_SYSTEM_POWER_STATES_SUPPORT config ACPI_CCA_REQUIRED bool +config ACPI_DEBUGGER + bool "In-kernel debugger (EXPERIMENTAL)" + select ACPI_DEBUG + help + Enable in-kernel debugging facilities: statistics, internal + object dump, single step control method execution. + This is still under development, currently enabling this only + results in the compilation of the ACPICA debugger files. + config ACPI_SLEEP bool depends on SUSPEND || HIBERNATION diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile index ac78d76..885936f 100644 --- a/drivers/acpi/acpica/Makefile +++ b/drivers/acpi/acpica/Makefile @@ -177,8 +177,24 @@ acpi-y += \ utxferror.o \ utxfmutex.o -acpi-$(ACPI_FUTURE_USAGE) += \ +acpi-$(CONFIG_ACPI_DEBUGGER) +=\ + dbcmds.o\ + dbconvert.o \ + dbdisply.o \ + dbexec.o\ + dbhistry.o \ + dbinput.o \ + dbmethod.o \ + dbnames.o \ + dbobject.o \ + dbstats.o \ + dbutils.o \ + dbxface.o \ rsdump.o\ + +acpi-$(ACPI_FUTURE_USAGE) += \ + dbfileio.o \ + dbtest.o\ utcache.o \ utfileio.o \ utprint.o \ diff --git a/drivers/acpi/acpica/acinterp.h b/drivers/acpi/acpica/acinterp.h index e820ed8..e9e936e 100644 --- a/drivers/acpi/acpica/acinterp.h +++ b/drivers/acpi/acpica/acinterp.h @@ -397,12 +397,10 @@ void acpi_ex_dump_operands(union acpi_operand_object **operands, const char *opcode_name, u32 num_opcodes); -#ifdef ACPI_FUTURE_USAGE void acpi_ex_dump_object_descriptor(union acpi_operand_object *object, u32 flags); void acpi_ex_dump_namespace_node(struct acpi_namespace_node *node, u32 flags); -#endif /* ACPI_FUTURE_USAGE */ /*
[PATCH v2 11/14] ACPICA: Debugger: Add thread ID support so that single step mode can only apply to the debugger thread
When the debugger is running in the kernel mode, acpi_db_single_step() may
also be invoked by the kernel runtime code path but the single stepping
command prompt may be erronously logged as the kernel logs and runtime code
path cannot proceed.
This patch fixes this issue by adding acpi_gbl_db_thread_id for the debugger
thread and preventing acpi_db_single_step() to be invoked from other threads.
It is not suitable to add acpi_thread_id parameter for acpi_os_execute() as
the function may be implemented as work queue on some hosts. So it is
better to let the hosts invoke acpi_set_debugger_thread_id(). Currently
acpiexec is not configured as DEBUGGER_MULTI_THREADED, but we can do this.
When we do this, it is better to invoke acpi_set_debugger_thread_id() in
acpi_os_execute() when the execution type is OSL_DEBUGGER_MAIN_THREAD. The
support should look like:
create_thread();
if (type == OSL_DEBUGGER_MAIN_THREAD)
acpi_set_debugger_thread_id(tid);
resume_thread(tid);
Similarly, semop() may be used for pthread implementation. But this patch
simply skips debugger thread ID check for application instead of
introducing such complications as there is no need to skip
acpi_db_single_step() for an application debugger - acpiexec.
Note that the debugger thread ID can also be used by acpi_os_printf() to
filter out debugger output. Lv Zheng.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acglobal.h |1 +
drivers/acpi/acpica/aclocal.h |8
drivers/acpi/acpica/dbexec.c |3 ++-
drivers/acpi/acpica/dbxface.c | 28 +++-
include/acpi/acpiosxf.h|3 ++-
include/acpi/acpixf.h |2 ++
6 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index d82249c..fdef15f 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -326,6 +326,7 @@ ACPI_GLOBAL(struct acpi_external_file *,
acpi_gbl_external_file_list);
ACPI_INIT_GLOBAL(u8, acpi_gbl_abort_method, FALSE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_method_executing, FALSE);
+ACPI_INIT_GLOBAL(acpi_thread_id, acpi_gbl_db_thread_id,
ACPI_INVALID_THREAD_ID);
ACPI_GLOBAL(u8, acpi_gbl_db_opt_no_ini_methods);
ACPI_GLOBAL(u8, acpi_gbl_db_opt_no_region_support);
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 4e41b43..e1dd784 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -109,6 +109,14 @@ struct acpi_rw_lock {
#define ACPI_MUTEX_NOT_ACQUIRED (acpi_thread_id) 0
+/* This Thread ID means an invalid thread ID */
+
+#ifdef ACPI_OS_INVALID_THREAD_ID
+#define ACPI_INVALID_THREAD_ID ACPI_OS_INVALID_THREAD_ID
+#else
+#define ACPI_INVALID_THREAD_ID ((acpi_thread_id) 0x)
+#endif
+
/* Table for the global mutexes */
struct acpi_mutex_info {
diff --git a/drivers/acpi/acpica/dbexec.c b/drivers/acpi/acpica/dbexec.c
index 8eef298..258e615 100644
--- a/drivers/acpi/acpica/dbexec.c
+++ b/drivers/acpi/acpica/dbexec.c
@@ -725,7 +725,8 @@ acpi_db_create_execution_threads(char *num_threads_arg,
for (i = 0; i < (num_threads); i++) {
status =
- acpi_os_execute(OSL_DEBUGGER_THREAD, acpi_db_method_thread,
+ acpi_os_execute(OSL_DEBUGGER_EXEC_THREAD,
+ acpi_db_method_thread,
_gbl_db_method_info);
if (ACPI_FAILURE(status)) {
break;
diff --git a/drivers/acpi/acpica/dbxface.c b/drivers/acpi/acpica/dbxface.c
index bef5f4e..342298a 100644
--- a/drivers/acpi/acpica/dbxface.c
+++ b/drivers/acpi/acpica/dbxface.c
@@ -164,6 +164,12 @@ acpi_db_single_step(struct acpi_walk_state * walk_state,
ACPI_FUNCTION_ENTRY();
+#ifndef ACPI_APPLICATION
+ if (acpi_gbl_db_thread_id != acpi_os_get_thread_id()) {
+ return (AE_OK);
+ }
+#endif
+
/* Check the abort flag */
if (acpi_gbl_abort_method) {
@@ -431,7 +437,7 @@ acpi_status acpi_initialize_debugger(void)
/* Create the debug execution thread to execute commands */
acpi_gbl_db_threads_terminated = FALSE;
- status = acpi_os_execute(OSL_DEBUGGER_THREAD,
+ status = acpi_os_execute(OSL_DEBUGGER_MAIN_THREAD,
acpi_db_execute_thread, NULL);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status,
@@ -439,6 +445,8 @@ acpi_status acpi_initialize_debugger(void)
acpi_gbl_db_threads_terminated = TRUE;
return_ACPI_STATUS(status);
}
+ } else {
+ acpi_gbl_db_thread_id = acpi_os_get_thread_id();
}
return_ACPI_STATUS(AE_OK);
@@ -485,3 +493,21 @@ void acpi_terminate_debugger(void)
}
ACPI_EXPORT_SYMBOL(acpi_terminate_debugger)
+
[PATCH v2 14/14] ACPICA: Update version to 20150930
From: Bob Moore ACPICA commit e9c75ca267262326e80d49a290e8387a5963e2d2 Version 20150930. Link: https://github.com/acpica/acpica/commit/e9c75ca2 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/acpixf.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index ded9fa3..386 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -46,7 +46,7 @@ /* Current ACPICA subsystem version in MMDD format */ -#define ACPI_CA_VERSION 0x20150818 +#define ACPI_CA_VERSION 0x20150930 #include #include -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 10/14] ACPICA: Debugger: Fix "terminate" command by cleaning up subsystem shutdown logic
ACPICA commit 7e823714911480be47e310fb1b3590d289b9fd99
Segmentation fault can be seen for executing the "terminate" command. This
is because acpi_ut_subsystem_shutdown() is errnously called multiple times.
This patch cleans up acpi_ut_subsystem_shutdown() logics to fix this
issue. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/7e823714
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/dbinput.c |3 ++-
drivers/acpi/acpica/utinit.c | 13 +
drivers/acpi/acpica/utxface.c | 13 -
3 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/acpica/dbinput.c b/drivers/acpi/acpica/dbinput.c
index f8cddd6..0480254 100644
--- a/drivers/acpi/acpica/dbinput.c
+++ b/drivers/acpi/acpica/dbinput.c
@@ -1074,6 +1074,7 @@ acpi_db_command_dispatch(char *input_buffer,
* re-creating the semaphores!
*/
+ acpi_gbl_db_terminate_loop = TRUE;
/* acpi_initialize (NULL); */
break;
@@ -1151,7 +1152,7 @@ void ACPI_SYSTEM_XFACE acpi_db_execute_thread(void
*context)
acpi_status status = AE_OK;
acpi_status Mstatus;
- while (status != AE_CTRL_TERMINATE) {
+ while (status != AE_CTRL_TERMINATE && !acpi_gbl_db_terminate_loop) {
acpi_gbl_method_executing = FALSE;
acpi_gbl_step_to_next_call = FALSE;
diff --git a/drivers/acpi/acpica/utinit.c b/drivers/acpi/acpica/utinit.c
index d8699df..ccd0745 100644
--- a/drivers/acpi/acpica/utinit.c
+++ b/drivers/acpi/acpica/utinit.c
@@ -282,6 +282,19 @@ void acpi_ut_subsystem_shutdown(void)
{
ACPI_FUNCTION_TRACE(ut_subsystem_shutdown);
+ /* Just exit if subsystem is already shutdown */
+
+ if (acpi_gbl_shutdown) {
+ ACPI_ERROR((AE_INFO, "ACPI Subsystem is already terminated"));
+ return_VOID;
+ }
+
+ /* Subsystem appears active, go ahead and shut it down */
+
+ acpi_gbl_shutdown = TRUE;
+ acpi_gbl_startup_flags = 0;
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Shutting down ACPI Subsystem\n"));
+
#ifndef ACPI_ASL_COMPILER
/* Close the acpi_event Handling */
diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
index f183daf..a6b0eb0 100644
--- a/drivers/acpi/acpica/utxface.c
+++ b/drivers/acpi/acpica/utxface.c
@@ -67,19 +67,6 @@ acpi_status __init acpi_terminate(void)
ACPI_FUNCTION_TRACE(acpi_terminate);
- /* Just exit if subsystem is already shutdown */
-
- if (acpi_gbl_shutdown) {
- ACPI_ERROR((AE_INFO, "ACPI Subsystem is already terminated"));
- return_ACPI_STATUS(AE_OK);
- }
-
- /* Subsystem appears active, go ahead and shut it down */
-
- acpi_gbl_shutdown = TRUE;
- acpi_gbl_startup_flags = 0;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Shutting down ACPI Subsystem\n"));
-
/* Shutdown and free all resources */
acpi_ut_subsystem_shutdown();
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 02/14] ACPICA: iASL: Add symbolic operator support for Index() operator.
From: Bob Moore
ACPICA commit fbe67c46830f10c839941f8512cac5bddcb86bd3
Index (, 2) is now supported by [2]
This patch doesn't affect Linux kernel.
Link: https://github.com/acpica/acpica/commit/fbe67c46
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/aclocal.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 6f70826..8a66fef 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -848,7 +848,7 @@ struct acpi_parse_state {
#define ACPI_PARSEOP_PARAMLIST 0x02
#define ACPI_PARSEOP_EMPTY_TERMLIST 0x04
#define ACPI_PARSEOP_PREDEF_CHECKED 0x08
-#define ACPI_PARSEOP_SPECIAL0x10
+#define ACPI_PARSEOP_CLOSING_PAREN 0x10
#define ACPI_PARSEOP_COMPOUND 0x20
#define ACPI_PARSEOP_ASSIGNMENT 0x40
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 06/14] ACPICA: Improve typechecking, both compile-time and runtime
From: Bob Moore ACPICA commit 8d0f96e2a11a4ceabb2cae4b41e0ce1f4d3786b9 Adds much stricter typechecking in the iASL compiler, and also adds some additional checking in the interpreter. Link: https://github.com/acpica/acpica/commit/8d0f96e2 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- drivers/acpi/acpica/aclocal.h |8 ++- drivers/acpi/acpica/acopcode.h |4 +- drivers/acpi/acpica/amlcode.h | 11 ++-- drivers/acpi/acpica/exconvrt.c |1 + drivers/acpi/acpica/exresolv.c |1 - drivers/acpi/acpica/exresop.c |2 + drivers/acpi/acpica/exstore.c | 120 ++-- drivers/acpi/acpica/exstoren.c |5 +- drivers/acpi/acpica/nspredef.c |2 +- drivers/acpi/acpica/utdecode.c | 19 ++- include/acpi/acexcep.h |7 ++- 11 files changed, 134 insertions(+), 46 deletions(-) diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h index 918f70d..4e41b43 100644 --- a/drivers/acpi/acpica/aclocal.h +++ b/drivers/acpi/acpica/aclocal.h @@ -285,13 +285,17 @@ acpi_status(*acpi_internal_method) (struct acpi_walk_state * walk_state); #define ACPI_BTYPE_BUFFER_FIELD 0x2000 #define ACPI_BTYPE_DDB_HANDLE 0x4000 #define ACPI_BTYPE_DEBUG_OBJECT 0x8000 -#define ACPI_BTYPE_REFERENCE0x0001 +#define ACPI_BTYPE_REFERENCE_OBJECT 0x0001 /* From Index(), ref_of(), etc (type6_opcodes) */ #define ACPI_BTYPE_RESOURCE 0x0002 +#define ACPI_BTYPE_NAMED_REFERENCE 0x0004 /* Generic unresolved Name or Namepath */ #define ACPI_BTYPE_COMPUTE_DATA (ACPI_BTYPE_INTEGER | ACPI_BTYPE_STRING | ACPI_BTYPE_BUFFER) #define ACPI_BTYPE_DATA (ACPI_BTYPE_COMPUTE_DATA | ACPI_BTYPE_PACKAGE) -#define ACPI_BTYPE_DATA_REFERENCE (ACPI_BTYPE_DATA | ACPI_BTYPE_REFERENCE | ACPI_BTYPE_DDB_HANDLE) + + /* Used by Copy, de_ref_of, Store, Printf, Fprintf */ + +#define ACPI_BTYPE_DATA_REFERENCE (ACPI_BTYPE_DATA | ACPI_BTYPE_REFERENCE_OBJECT | ACPI_BTYPE_DDB_HANDLE) #define ACPI_BTYPE_DEVICE_OBJECTS (ACPI_BTYPE_DEVICE | ACPI_BTYPE_THERMAL | ACPI_BTYPE_PROCESSOR) #define ACPI_BTYPE_OBJECTS_AND_REFS 0x0001 /* ARG or LOCAL */ #define ACPI_BTYPE_ALL_OBJECTS 0x diff --git a/drivers/acpi/acpica/acopcode.h b/drivers/acpi/acpica/acopcode.h index fd85ad0..f9acf92 100644 --- a/drivers/acpi/acpica/acopcode.h +++ b/drivers/acpi/acpica/acopcode.h @@ -211,7 +211,7 @@ #define ARGI_ARG4 ARG_NONE #define ARGI_ARG5 ARG_NONE #define ARGI_ARG6 ARG_NONE -#define ARGI_BANK_FIELD_OP ARGI_INVALID_OPCODE +#define ARGI_BANK_FIELD_OP ARGI_LIST1 (ARGI_INTEGER) #define ARGI_BIT_AND_OP ARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF) #define ARGI_BIT_NAND_OPARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF) #define ARGI_BIT_NOR_OP ARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF) @@ -307,7 +307,7 @@ #define ARGI_SLEEP_OP ARGI_LIST1 (ARGI_INTEGER) #define ARGI_STALL_OP ARGI_LIST1 (ARGI_INTEGER) #define ARGI_STATICSTRING_OPARGI_INVALID_OPCODE -#define ARGI_STORE_OP ARGI_LIST2 (ARGI_DATAREFOBJ, ARGI_TARGETREF) +#define ARGI_STORE_OP ARGI_LIST2 (ARGI_DATAREFOBJ, ARGI_STORE_TARGET) #define ARGI_STRING_OP ARGI_INVALID_OPCODE #define ARGI_SUBTRACT_OPARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF) #define ARGI_THERMAL_ZONE_OPARGI_INVALID_OPCODE diff --git a/drivers/acpi/acpica/amlcode.h b/drivers/acpi/acpica/amlcode.h index be9fd00..883f20c 100644 --- a/drivers/acpi/acpica/amlcode.h +++ b/drivers/acpi/acpica/amlcode.h @@ -277,14 +277,15 @@ #define ARGI_TARGETREF 0x0F /* Target, subject to implicit conversion */ #define ARGI_FIXED_TARGET 0x10 /* Target, no implicit conversion */ #define ARGI_SIMPLE_TARGET 0x11 /* Name, Local, Arg -- no implicit conversion */ +#define ARGI_STORE_TARGET 0x12 /* Target for store is TARGETREF + package objects */ /* Multiple/complex types */ -#define ARGI_DATAOBJECT 0x12 /* Buffer, String, package or reference to a node - Used only by size_of operator */ -#define ARGI_COMPLEXOBJ 0x13 /* Buffer, String, or package (Used by INDEX op only) */ -#define ARGI_REF_OR_STRING 0x14 /* Reference or String (Used by DEREFOF op only) */ -#define ARGI_REGION_OR_BUFFER 0x15 /* Used by LOAD op only */ -#define ARGI_DATAREFOBJ 0x16 +#define ARGI_DATAOBJECT 0x13 /* Buffer, String, package or reference to a node - Used only by size_of operator */ +#define ARGI_COMPLEXOBJ 0x14 /*
[PATCH v2 07/14] ACPICA: iASL: General cleanup of the file suffix #defines
From: Bob Moore
ACPICA commit bed456ed2976bdaafdef406b982fdf6c539befc0
Removed some extraneous defines, reordered others.
Link: https://github.com/acpica/acpica/commit/bed456ed
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acapps.h |2 +-
tools/power/acpi/tools/acpidump/apfiles.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/acapps.h b/drivers/acpi/acpica/acapps.h
index e9f0833..e4cc48f 100644
--- a/drivers/acpi/acpica/acapps.h
+++ b/drivers/acpi/acpica/acapps.h
@@ -88,7 +88,7 @@
acpi_os_printf (" %-18s%s\n", name, description);
#define FILE_SUFFIX_DISASSEMBLY "dsl"
-#define ACPI_TABLE_FILE_SUFFIX ".dat"
+#define FILE_SUFFIX_BINARY_TABLE".dat" /* Needs the dot */
/*
* getopt
diff --git a/tools/power/acpi/tools/acpidump/apfiles.c
b/tools/power/acpi/tools/acpidump/apfiles.c
index a37f970..a1c62de 100644
--- a/tools/power/acpi/tools/acpidump/apfiles.c
+++ b/tools/power/acpi/tools/acpidump/apfiles.c
@@ -150,7 +150,7 @@ int ap_write_to_binary_file(struct acpi_table_header
*table, u32 instance)
strcat(filename, instance_str);
}
- strcat(filename, ACPI_TABLE_FILE_SUFFIX);
+ strcat(filename, FILE_SUFFIX_BINARY_TABLE);
if (gbl_verbose_mode) {
acpi_log_error
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/14] ACPICA: Update exception code for "file not found" error
From: Bob Moore
ACPICA commit ac1564c26d239348ef13455f61d5616f3961ff43
Used by the ACPICA applications.
This patch is a bit broken due to non-portable inclusion as on
some platforms, there is no such a header file for their lib-c exports.
Fortunately, Linux doesn't compile utfileio.c for either the kernel
space ACPICA core (drivers/acpi/acpica) or the userspace ACPICA tools
(tools/power/acpi) for now, so it's safe to leave this patch as it is.
Link: https://github.com/acpica/acpica/commit/ac1564c2
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/utfileio.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/acpi/acpica/utfileio.c b/drivers/acpi/acpica/utfileio.c
index 75a94f5..d435b7b 100644
--- a/drivers/acpi/acpica/utfileio.c
+++ b/drivers/acpi/acpica/utfileio.c
@@ -45,6 +45,7 @@
#include "accommon.h"
#include "actables.h"
#include "acapps.h"
+#include "errno.h"
#ifdef ACPI_ASL_COMPILER
#include "aslcompiler.h"
@@ -301,6 +302,11 @@ acpi_ut_read_table_from_file(char *filename, struct
acpi_table_header ** table)
file = fopen(filename, "rb");
if (!file) {
perror("Could not open input file");
+
+ if (errno == ENOENT) {
+ return (AE_NOT_EXIST);
+ }
+
return (status);
}
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 05/14] ACPICA: Update NFIT table to rename a flags field
From: Bob Moore
ACPICA commit 534deab97fb416a13bfede15c538e2c9eac9384a
Updated one of the memory subtable flags to clarify.
Link: https://github.com/acpica/acpica/commit/534deab9
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/nfit.c |6 +++---
drivers/acpi/nfit.h |2 +-
include/acpi/actbl1.h |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
index c1b8d03..bc18aa2 100644
--- a/drivers/acpi/nfit.c
+++ b/drivers/acpi/nfit.c
@@ -706,7 +706,7 @@ static ssize_t flags_show(struct device *dev,
flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "",
flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail " : "",
flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : "",
- flags & ACPI_NFIT_MEM_ARMED ? "not_armed " : "",
+ flags & ACPI_NFIT_MEM_NOT_ARMED ? "not_armed " : "",
flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart_event " : "");
}
static DEVICE_ATTR_RO(flags);
@@ -815,7 +815,7 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc
*acpi_desc)
flags |= NDD_ALIASING;
mem_flags = __to_nfit_memdev(nfit_mem)->flags;
- if (mem_flags & ACPI_NFIT_MEM_ARMED)
+ if (mem_flags & ACPI_NFIT_MEM_NOT_ARMED)
flags |= NDD_UNARMED;
rc = acpi_nfit_add_dimm(acpi_desc, nfit_mem, device_handle);
@@ -839,7 +839,7 @@ static int acpi_nfit_register_dimms(struct acpi_nfit_desc
*acpi_desc)
mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? " save_fail" : "",
mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? " restore_fail":"",
mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? " flush_fail" : "",
- mem_flags & ACPI_NFIT_MEM_ARMED ? " not_armed" : "");
+ mem_flags & ACPI_NFIT_MEM_NOT_ARMED ? " not_armed" : "");
}
diff --git a/drivers/acpi/nfit.h b/drivers/acpi/nfit.h
index 7e74015..329a1eb 100644
--- a/drivers/acpi/nfit.h
+++ b/drivers/acpi/nfit.h
@@ -24,7 +24,7 @@
#define UUID_NFIT_DIMM "4309ac30-0d11-11e4-9191-0800200c9a66"
#define ACPI_NFIT_MEM_FAILED_MASK (ACPI_NFIT_MEM_SAVE_FAILED \
| ACPI_NFIT_MEM_RESTORE_FAILED | ACPI_NFIT_MEM_FLUSH_FAILED \
- | ACPI_NFIT_MEM_ARMED)
+ | ACPI_NFIT_MEM_NOT_ARMED)
enum nfit_uuids {
NFIT_SPA_VOLATILE,
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index fcd5709..1bb979e 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -1012,7 +1012,7 @@ struct acpi_nfit_memory_map {
#define ACPI_NFIT_MEM_SAVE_FAILED (1)/* 00: Last SAVE to Memory
Device failed */
#define ACPI_NFIT_MEM_RESTORE_FAILED(1<<1) /* 01: Last RESTORE from Memory
Device failed */
#define ACPI_NFIT_MEM_FLUSH_FAILED (1<<2) /* 02: Platform flush failed */
-#define ACPI_NFIT_MEM_ARMED (1<<3) /* 03: Memory Device observed
to be not armed */
+#define ACPI_NFIT_MEM_NOT_ARMED (1<<3) /* 03: Memory Device is not
armed */
#define ACPI_NFIT_MEM_HEALTH_OBSERVED (1<<4) /* 04: Memory Device observed
SMART/health events */
#define ACPI_NFIT_MEM_HEALTH_ENABLED(1<<5) /* 05: SMART/health events
enabled */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 04/14] ACPICA: Debugger: Update mutexes used for multithreaded debugger
From: Bob Moore
ACPICA commit 6b2701f619040e803313363f516b200e362a9100
Make these mutex objects independent of the deadlock detection mechanism.
This mechanism caused failures with the multithread debugger.
This patch doesn't affect Linux kernel as debugger is currently not fully
functioning in the Linux kernel. And the further debugger cleanups will
take care of handling debugger command signalling correctly instead of
using such kind of mutexes. So it is safe to leave this patch as it is.
Link: https://github.com/acpica/acpica/commit/6b2701f6
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acglobal.h |3 +++
drivers/acpi/acpica/aclocal.h |4 +---
drivers/acpi/acpica/utdecode.c |2 --
drivers/acpi/acpica/utmutex.c | 21 +
include/acpi/platform/acenv.h |6 +++---
5 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 09f37b5..593de41 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -357,6 +357,9 @@ ACPI_GLOBAL(u16, acpi_gbl_node_type_count_misc);
ACPI_GLOBAL(u32, acpi_gbl_num_nodes);
ACPI_GLOBAL(u32, acpi_gbl_num_objects);
+ACPI_GLOBAL(acpi_mutex, acpi_gbl_db_command_ready);
+ACPI_GLOBAL(acpi_mutex, acpi_gbl_db_command_complete);
+
#endif /* ACPI_DEBUGGER */
/*
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 8a66fef..918f70d 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -83,10 +83,8 @@ union acpi_parse_object;
#define ACPI_MTX_EVENTS 3 /* Data for ACPI events */
#define ACPI_MTX_CACHES 4 /* Internal caches, general
purposes */
#define ACPI_MTX_MEMORY 5 /* Debug memory tracking lists
*/
-#define ACPI_MTX_DEBUG_CMD_COMPLETE 6 /* AML debugger */
-#define ACPI_MTX_DEBUG_CMD_READY7 /* AML debugger */
-#define ACPI_MAX_MUTEX 7
+#define ACPI_MAX_MUTEX 5
#define ACPI_NUM_MUTEX ACPI_MAX_MUTEX+1
/* Lock structure for reader/writer interfaces */
diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 988e23b..d452a78 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -407,8 +407,6 @@ static char *acpi_gbl_mutex_names[ACPI_NUM_MUTEX] = {
"ACPI_MTX_Events",
"ACPI_MTX_Caches",
"ACPI_MTX_Memory",
- "ACPI_MTX_CommandComplete",
- "ACPI_MTX_CommandReady"
};
char *acpi_ut_get_mutex_name(u32 mutex_id)
diff --git a/drivers/acpi/acpica/utmutex.c b/drivers/acpi/acpica/utmutex.c
index 37b8b58..ce406e3 100644
--- a/drivers/acpi/acpica/utmutex.c
+++ b/drivers/acpi/acpica/utmutex.c
@@ -108,6 +108,21 @@ acpi_status acpi_ut_mutex_initialize(void)
/* Create the reader/writer lock for namespace access */
status = acpi_ut_create_rw_lock(_gbl_namespace_rw_lock);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+#ifdef ACPI_DEBUGGER
+
+ /* Debugger Support */
+
+ status = acpi_os_create_mutex(_gbl_db_command_ready);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+
+ status = acpi_os_create_mutex(_gbl_db_command_complete);
+#endif
+
return_ACPI_STATUS(status);
}
@@ -147,6 +162,12 @@ void acpi_ut_mutex_terminate(void)
/* Delete the reader/writer lock */
acpi_ut_delete_rw_lock(_gbl_namespace_rw_lock);
+
+#ifdef ACPI_DEBUGGER
+ acpi_os_delete_mutex(acpi_gbl_db_command_ready);
+ acpi_os_delete_mutex(acpi_gbl_db_command_complete);
+#endif
+
return_VOID;
}
diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
index 15ef08c..056f245 100644
--- a/include/acpi/platform/acenv.h
+++ b/include/acpi/platform/acenv.h
@@ -304,11 +304,11 @@
* multi-threaded if ACPI_APPLICATION is not set.
*/
#ifndef DEBUGGER_THREADING
-#ifdef ACPI_APPLICATION
-#define DEBUGGER_THREADING DEBUGGER_SINGLE_THREADED
+#if !defined (ACPI_APPLICATION) || defined (ACPI_EXEC_APP)
+#define DEBUGGER_THREADING DEBUGGER_MULTI_THREADED
#else
-#define DEBUGGER_THREADING DEBUGGER_MULTI_THREADED
+#define DEBUGGER_THREADING DEBUGGER_SINGLE_THREADED
#endif
#endif /* !DEBUGGER_THREADING */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 01/14] ACPICA: Remove unnecessary conditional compilation.
From: Bob Moore
ACPICA commit eea1f0e561893b6d6417913b2d224082fe3a0a5e
Remove use of ACPI_DEBUGGER and ACPI_DISASSEMBLER where these
defines are used around entire modules.
Note: This type of code also causes problems with IDEs.
Link: https://github.com/acpica/acpica/commit/eea1f0e5
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/Makefile |2 +-
drivers/acpi/acpica/acdebug.h |6 ++
drivers/acpi/acpica/rsdump.c |3 ---
include/acpi/platform/acenv.h |2 +-
4 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index fedcc16..ac78d76 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -123,7 +123,6 @@ acpi-y += \
rsaddr.o\
rscalc.o\
rscreate.o \
- rsdump.o\
rsdumpinfo.o\
rsinfo.o\
rsio.o \
@@ -179,6 +178,7 @@ acpi-y += \
utxfmutex.o
acpi-$(ACPI_FUTURE_USAGE) += \
+ rsdump.o\
utcache.o \
utfileio.o \
utprint.o \
diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h
index eb2e926..c928ba4 100644
--- a/drivers/acpi/acpica/acdebug.h
+++ b/drivers/acpi/acpica/acdebug.h
@@ -44,6 +44,12 @@
#ifndef __ACDEBUG_H__
#define __ACDEBUG_H__
+/* The debugger is used in conjunction with the disassembler most of time */
+
+#ifdef ACPI_DISASSEMBLER
+#include "acdisasm.h"
+#endif
+
#define ACPI_DEBUG_BUFFER_SIZE 0x4000 /* 16K buffer for return objects */
struct acpi_db_command_info {
diff --git a/drivers/acpi/acpica/rsdump.c b/drivers/acpi/acpica/rsdump.c
index c428bb3..2a09288 100644
--- a/drivers/acpi/acpica/rsdump.c
+++ b/drivers/acpi/acpica/rsdump.c
@@ -51,7 +51,6 @@ ACPI_MODULE_NAME("rsdump")
/*
* All functions in this module are used by the AML Debugger only
*/
-#if defined(ACPI_DEBUGGER)
/* Local prototypes */
static void acpi_rs_out_string(char *title, char *value);
@@ -565,5 +564,3 @@ static void acpi_rs_dump_word_list(u16 length, u16 *data)
acpi_os_printf("%25s%2.2X : %4.4X\n", "Word", i, data[i]);
}
}
-
-#endif
diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
index ec00e2b..15ef08c 100644
--- a/include/acpi/platform/acenv.h
+++ b/include/acpi/platform/acenv.h
@@ -142,7 +142,7 @@
#ifdef ACPI_LIBRARY
#define ACPI_USE_LOCAL_CACHE
-#define ACPI_FUTURE_USAGE
+#define ACPI_FULL_DEBUG
#endif
/* Common for all ACPICA applications */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/3] ARM: dt: fpga: Added binding docs for Xilinx Zynq FPGA manager.
On Sun, 2015-10-18 at 12:51PM -0500, Josh Cartwright wrote: > On Fri, Oct 16, 2015 at 03:42:28PM -0700, Moritz Fischer wrote: > > Signed-off-by: Moritz Fischer > > --- > > > > v2: > > - Clock names are now a required property > > - Removed interrupt-parent property > > > > --- > > .../devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt | 19 > > +++ > > 1 file changed, 19 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt > > > > diff --git > > a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt > > b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt > > new file mode 100644 > > index 000..7018aa8 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt > > @@ -0,0 +1,19 @@ > > +Xilinx Zynq FPGA Manager > > + > > +Required properties: > > +- compatible: should contain "xlnx,zynq-devcfg-1.0" > > +- reg: base address and size for memory mapped io > > +- interrupts: interrupt for the FPGA manager device If we are that picky, this is technically an interrupt specifier :) > > +- clocks: phandle for clocks required operation > > Technically a "clock specifier", but other than that: > > Reviewed-by: Josh Cartwright Reviewed-by: Sören Brinkmann Sören -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/14] ACPICA: 20150930 Release
The 20150930 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + allyes 2. i386 + allno 3. i386 + default + ACPI_DEBUGGER=y 4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y 5. i386 + default + ACPI_DEBUG=n + ACPI=y 6. i386 + default + ACPI=n 7. x86_64 + allyes 8. x86_64 + allno 9. x86_64 + default + ACPI_DEBUGGER=y 10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y 11.x86_64 + default + ACPI_DEBUG=n + ACPI=y 12.x86_64 + default + ACPI=n Boot tests are performed as follows: 1. i386 + default + ACPI_DEBUGGER=y 2. x86_64 + default + ACPI_DEBUGGER=y Where: 1. i386: machine named as "Dell Inspiron Mini 1010" 2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC" 3. default: kernel configuration with following items enabled: All hardware drivers related to the machines of i386/x86_64 All "drivers/acpi" configurations All "drivers/platform" drivers All other drivers that link the APIs provided by ACPICA subsystem The divergences checking result: Before applying (20150818 Release): 517 lines After applying (20150930 Release): 517 lines Note there are still 2 ACPICA debugger patches not released during this release cycle, so the debugger IO driver is not released in this cycle. In this series the ACPICA debugger core is compile time enabled as all ACPICA debugger files can be built with ACPI_DEBUGGER=y, but not runtime enabled as there is no invocations calling ACPICA debugger APIs and its required OSls are just stubs. The embedded debugger invocation acpi_db_single_step() is also stubbed via debugger thread ID support. Bob Moore (8): ACPICA: Remove unnecessary conditional compilation. ACPICA: iASL: Add symbolic operator support for Index() operator. ACPICA: Update exception code for "file not found" error ACPICA: Debugger: Update mutexes used for multithreaded debugger ACPICA: Update NFIT table to rename a flags field ACPICA: Improve typechecking, both compile-time and runtime ACPICA: iASL: General cleanup of the file suffix #defines ACPICA: Update version to 20150930 Lv Zheng (6): ACPICA: Linuxize: Export debugger files to Linux ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic ACPICA: Debugger: Fix "terminate" command by cleaning up subsystem shutdown logic ACPICA: Debugger: Add thread ID support so that single step mode can only apply to the debugger thread ACPI: Enable build of AML interpreter debugger ACPICA: Debugger: Fix dead lock issue ocurred in single stepping mode drivers/acpi/Kconfig |9 + drivers/acpi/acpica/Makefile | 18 +- drivers/acpi/acpica/acapps.h |2 +- drivers/acpi/acpica/acdebug.h |6 + drivers/acpi/acpica/acglobal.h|7 +- drivers/acpi/acpica/acinterp.h|2 - drivers/acpi/acpica/aclocal.h | 22 +- drivers/acpi/acpica/acnamesp.h|4 - drivers/acpi/acpica/acopcode.h|4 +- drivers/acpi/acpica/acparser.h|4 - drivers/acpi/acpica/acutils.h |2 - drivers/acpi/acpica/amlcode.h | 11 +- drivers/acpi/acpica/dbcmds.c | 1187 +++ drivers/acpi/acpica/dbconvert.c | 484 +++ drivers/acpi/acpica/dbdisply.c| 1108 + drivers/acpi/acpica/dbexec.c | 764 + drivers/acpi/acpica/dbfileio.c| 256 ++ drivers/acpi/acpica/dbhistry.c| 239 ++ drivers/acpi/acpica/dbinput.c | 1267 + drivers/acpi/acpica/dbmethod.c| 369 + drivers/acpi/acpica/dbnames.c | 947 + drivers/acpi/acpica/dbobject.c| 533 drivers/acpi/acpica/dbstats.c | 546 + drivers/acpi/acpica/dbtest.c | 1057 drivers/acpi/acpica/dbutils.c | 457 +++ drivers/acpi/acpica/dbxface.c | 513 drivers/acpi/acpica/evxface.c |2 +- drivers/acpi/acpica/exconvrt.c|1 + drivers/acpi/acpica/exresolv.c|1 - drivers/acpi/acpica/exresop.c |2 + drivers/acpi/acpica/exstore.c | 120 ++- drivers/acpi/acpica/exstoren.c|5 +- drivers/acpi/acpica/nsdump.c |6 - drivers/acpi/acpica/nspredef.c|2 +- drivers/acpi/acpica/pstree.c |2 - drivers/acpi/acpica/psutils.c |2 - drivers/acpi/acpica/rsdump.c |3 - drivers/acpi/acpica/rsutils.c |2 - drivers/acpi/acpica/rsxface.c |4 +- drivers/acpi/acpica/utdecode.c| 21 +-
Re: [PATCH net-next v3 0/2] net: hisilicon fix some bugs in HNS drivers
On 2015/10/16 17:30, Arnd Bergmann wrote: On Friday 16 October 2015 11:54:15 huangdaode wrote: This patchset fixes the two bugs in HNS driver, one is remove the hnae sysfs interface according to the review comments from Arnd Bergmann , another is fixing the wrong mac_id judgement bug which is found during internal tests. change log: v3: remove the hnae sysfs interface. v2: 1) remove first bug fix, which is fixed in another patch submitted by Arnd Bergmann 2) change the code sytyle according to Joe. v1: initial version. huangdaode (2): net: hisilicon rm hnae sysfs interface net: hisilicon fix a bug on Hisilicon Network Subsystem drivers/net/ethernet/hisilicon/hns/hnae.c | 47 --- drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 2 +- 2 files changed, 1 insertion(+), 48 deletions(-) I found two more bugs in build testing, will follow up with patches in this thread Arnd. . Hi Arnd, thanks for your comments. i see you adding three patches in this thread to fix related bugs. should I need to re-send a new version patch which contains your other three patches or just wait for David Miller to merge this thread? thanks Daode Huang . -- Best Regards Daode Huang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen-netback: correctly check failed allocation
From: Insu Yun Date: Thu, 15 Oct 2015 18:02:28 + > Since vzalloc can be failed in memory pressure, > writes -ENOMEM to xenstore to indicate error. > > Signed-off-by: Insu Yun Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] net: phy: bcm-phy-lib: Fix module license issue
From: Arun Parameswaran
Date: Thu, 15 Oct 2015 10:37:13 -0700
> The 'bcm-phy-lib.c', added as a part of the commit
> "net: phy: Add Broadcom phy library for common interfaces"
> was missing the module license. This was causing an issue
> when the library is built as a module; "module license
> 'unspecified' taints kernel".
>
> This patch fixes the issue by adding the module license,
> author and description to the bcm-phy-lib.c file.
>
> Fixes: a1cba5613edf5 ("net: phy: Add Broadcom phy library for
> common interfaces")
> Signed-off-by: Arun Parameswaran
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: change to use memmove in efi-stub
Got it , Thanks for your explanation . > On Oct 16, 2015, at 18:57, Mark Rutland wrote: > > Hi, > > On Fri, Oct 16, 2015 at 06:46:07PM +0800, yalin wang wrote: >> Change to use memmove(), in case the dest address overlap with the >> source address. > > This cannot happen, and memove would not be sufficient if it did. > > The destination is a region returned by EFI_BOOT_SERVICES.AllocatePages, > which can only allocate pages which were free to begin with. Therefore > the new region cannot overlap with the stub (whose pages are not free). > > Were the new region to overlap with the stub, the memmove could corrupt > the code/data in use by the stub, and things would explode shortly > thereafter. > > Thanks, > Mark. > >> >> Signed-off-by: yalin wang >> --- >> arch/arm64/kernel/efi-stub.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c >> index 816120e..b6dc44b 100644 >> --- a/arch/arm64/kernel/efi-stub.c >> +++ b/arch/arm64/kernel/efi-stub.c >> @@ -59,7 +59,7 @@ efi_status_t __init handle_kernel_image(efi_system_table_t >> *sys_table_arg, >> } >> *image_addr = *reserve_addr + TEXT_OFFSET; >> } >> -memcpy((void *)*image_addr, old_image_addr, kernel_size); >> +memmove((void *)*image_addr, old_image_addr, kernel_size); >> *reserve_size = kernel_memsize; >> } >> >> -- >> 1.9.1 >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] Staging: rtl8712: fix warning for placing constant on the right side of test
On Sun, Oct 18, 2015 at 12:02:53PM +0530, punit vara wrote: > On Sat, Oct 17, 2015 at 10:46 AM, Greg KH wrote: > > On Wed, Oct 14, 2015 at 11:55:55PM +0530, Punit Vara wrote: > >> Put constant on the right side of a test.Problem found using checkpatch: > >> > >> Warning:Comparisons should place the constant on the right side of the test > >> > >> Signed-off-by: Punit Vara > >> --- > >> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 16 > >> 1 file changed, 8 insertions(+), 8 deletions(-) > > > > Didn't apply to my tree :( > In this case what should I do ? Should I do git reset , git pull and > then do changes on latest tree ? That depends on your workflow, how about pulling and then rebase your branch on mine? That's the easiest workflow to use. > One more thing I would like suggestion how can start switching this > driver to LIB80211 ,MAC80211 ? Which is the first file I should focus > ? Simultaneously I am trying to understand the flow of driver . I > would like to know the start point from where I can start doing small > changes. If you don't understand the wireless stack, I suggest you do some research on it first, converting a driver to the in-kernel stack is a _very_ difficult thing and not something that someone without any experience in this area is going to be able to do easily. good luck! greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] pstore: pmsg: ramoops: add multiple pmsg instances
Hello Mark, (I'm sorry for my late reply.) Mark Salyzyn wrote: >> I'm trying to make the feature of multiple pmsg instances for ramoops. > I like it, in fact I encourage it. Thank you. > Multiple instances does allow one to control individual content aging or > priority, I agree with your assessment, but make sure that you have a > bona fide user for it (even if it is just for yourself)? Yes. There are embedded devices which have limited NVRAM and no HDD/SSD. Especially in our usage, the devices are industrial machinery. When we catch a system failure, for fixing the root cause of the failure, we often have to distinguish if it happend suddenly or if there were signs long before the failure. Multiple pmsg can help this kind of cause analysis with small NVRAM because higher priority messages are preserved for a long time. > NB: ToDo: device tree support for pstore configuration Would you mean pstore backend's configuration (e.g.'mem_address' in ramoops)? Best regards, Hiraku Toyooka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iommu/hisilicon: Add hi6220 iommu driver
On 2015/10/14 20:18, Joerg Roedel wrote:
> On Thu, Oct 08, 2015 at 03:45:47PM +0800, Chen Feng wrote:
>> +static int hi6220_smmu_attach_dev(struct iommu_domain *domain,
>> + struct device *dev)
>> +{
>> +struct hi6220_domain *m_domain = to_hi6220_domain(domain);
>> +
>> +smmu_domain_prepare(m_domain);
>> +dev->archdata.iommu = _domain->smmu_dev->iova_allocator;
>> +
>> +return 0;
>> +}
>
> What happens when you attach devices behind different smmus to one
> domain? Will that overwrite the smmu_dev pointer in the domain?
>
Since the smmu master use the same pagetable, the master can use the
iova_allocator
in smmu driver to allocate iova address.
In this way, the different master can get the different io address.
>> +static size_t hi6220_smmu_unmap(struct iommu_domain *domain, unsigned long
>> iova,
>> +size_t size)
>> +{
>> +struct hi6220_domain *m_domain = to_hi6220_domain(domain);
>> +size_t page_size = m_domain->smmu_dev->page_size;
>> +struct hi6220_smmu *smmu_dev = m_domain->smmu_dev;
>> +int *page_table = (unsigned int *)smmu_dev->pgtable_virt;
>> +
>> +if (size != page_size) {
>> +pr_err("unmap size error, only support %zd\n", page_size);
>> +return 0;
>> +}
>> +
>> +__clear_smmu_pte(page_table + IOVA_PFN(iova));
>> +
>> +return page_size;
>> +}
>
> Don't you need a call to __invalid_smmu_tlb here too?
Thanks, I will fix this next version.
>
>
>
> Joerg
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] tracing: Make tracing work when debugfs is not compiled or initialized.
Sorry for the last patch, please use this to add stub for
debugfs_create_automount().
>From b3b877d8d9fd9795ea1055042039a272e47f4dc5 Mon Sep 17 00:00:00 2001
From: Jiaxing Wang
Date: Mon, 19 Oct 2015 09:46:12 +0800
Subject: [PATCH] debugfs: Add stub function for debugfs_create_automount().
Add stub for debugfs_create_automount() for when debugfs is not configured
in.
Signed-off-by: Jiaxing Wang
---
include/linux/debugfs.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 9beb636..b42ef88 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -160,6 +160,14 @@ static inline struct dentry *debugfs_create_symlink(const
char *name,
return ERR_PTR(-ENODEV);
}
+static inline struct dentry *debugfs_create_automount(const char *name,
+ struct dentry *parent,
+ struct vfsmount *(*f)(void *),
+ void *data)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void debugfs_remove(struct dentry *dentry)
{ }
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/3] pwm: omap: Add PWM support using dual-mode timers
Neil Armstrong writes: > This patch is based on an earlier patch by NeilBrown which is based on > a older patch from Grant Erickson which provided PWM devices using > the 'legacy' interface. > > The pwm driver was renamed to not be confused with the OMAP4 PWM dedicated > hardware and was cleaned with the review from Thierry Reding. > > The first patch introduces a way to select to dmtimer clock source via a > clocks binding and a dedicated function wit the legacy fallback. > > In order to prepare for the future form of the dmtimer (clksource or whatever) > the first patch introduces the PWM driver with all the dmtimer calls into a > platform data structure. > > The structure is then filled in plat-omap and added as auxdata for the > ti,pwm-dmtimer-omap compatible nodes. > > Cc: Grant Erickson > Cc: NeilBrown > Cc: Joachim Eastwood > Suggested-by: Tony Lindgren > > Neil Armstrong (3): > arm: plat-omap: dmtimer: Add clock source from DT > pwm: Add PWM driver for OMAP using dual-mode timers > arm: plat-omap: Add PWM dmtimer platforma data quirks > > .../devicetree/bindings/pwm/pwm-omap-dmtimer.txt | 18 ++ > arch/arm/mach-omap2/pdata-quirks.c | 23 ++ > arch/arm/plat-omap/dmtimer.c | 32 +- > drivers/pwm/Kconfig| 9 + > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-omap-dmtimer.c | 322 > + > include/linux/platform_data/pwm_omap_dmtimer.h | 69 + > 7 files changed, 472 insertions(+), 2 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt > create mode 100644 drivers/pwm/pwm-omap-dmtimer.c > create mode 100644 include/linux/platform_data/pwm_omap_dmtimer.h > Thanks for much for doing this! I haven't looked and wont have a chance for a least a couple of weeks, but I'm very encouraged that someone is pursuing it. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH] hwrng: exynos - Fix unbalanced PM runtime get/puts
On 17.10.2015 01:01, Daniel Thompson wrote: > Currently this driver calls pm_runtime_get_sync() rampantly > but never puts anything back. This makes it impossible for the > device to autosuspend properly; it will remain fully active > after the first use. > > Fix in the obvious way. > > Signed-off-by: Daniel Thompson > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > --- > > Notes: > Compile tested only (CONFIG_PM=y, CONFIG_HW_RANDOM_EXYNOS=m); I spotted > this whilst reviewing the code and don't have an exynos platform to > test on. > > drivers/char/hw_random/exynos-rng.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) To test the patch I had to add OF support to the driver. I have these patches almost ready and I will send them soon. Anyway: Tested on Trats2 board (Exynos4412): Tested-by: Krzysztof Kozlowski Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] userns/capability: Add user namespace capability
On Sun, Oct 18, 2015 at 10:13:54PM +0200, Tobias Markus wrote: > On 17.10.2015 23:55, Serge E. Hallyn wrote: > > On Sat, Oct 17, 2015 at 05:58:04PM +0200, Tobias Markus wrote: > >> Add capability CAP_SYS_USER_NS. > >> Tasks having CAP_SYS_USER_NS are allowed to create a new user namespace > >> when calling clone or unshare with CLONE_NEWUSER. > >> > >> Rationale: > >> > >> Linux 3.8 saw the introduction of unpriviledged user namespaces, > >> allowing unpriviledged users (without CAP_SYS_ADMIN) to be a "fake" root > >> inside a separate user namespace. Before that, any namespace creation > >> required CAP_SYS_ADMIN (or, in practice, the user had to be root). > >> Unfortunately, there have been some security-relevant bugs in the > >> meantime. Because of the fairly complex nature of user namespaces, it is > >> reasonable to say that future vulnerabilties can not be excluded. Some > >> distributions even wholly disable user namespaces because of this. > > > > Fwiw I'm not in favor of this. Debian has a patch (I believe the one > > I originally wrote for Ubuntu but which Ubuntu dropped long ago) adding a > > sysctl, off by default, for enabling user namespaces. > > While it certainly works, enabling a feature like this at runtime > doesn't seem like a long term solution. We shouldn't need a long-term solution. Your concern is bugs. After some time surely we'll feel that we have achieved a stable solution? > The fact that Debian added this patch in the first place already > demonstrates that there is demand for a way to limit unpriviledged user No it does not. As i said, I wrote that patch originally in the very early days, when wanting it turned off was much more understandable. I do not know whether Debian would have written its own patch if I hadn't. (They may have) > namespace creation. Please, don't get me wrong: I would *really like* to > see widespread adoption and continued development of user namespaces! > But the status quo remains: Distributions outright disabling user > namespaces (e.g. Arch Linux) won't make it easier. > > > > > Posix capabilities are intended for privileged actions, not for > > actions which explicitly should not require privilege, but which > > we feel are in development. > > > > Certainly, in an ideal world, user namespaces will never lead to any > kernel-level exploits. But reality is different: There *have been* > serious kernel vulnerabilities due to user namespaces, and there *will > be* serious kernel vulnerabilities due to user namespaces. As there will be due to sctp and futex. > Now, those are the alternatives imho: > > * Status quo: Some distributions will disable user namespaces by default > in some way or another. User wishing to use user namespaces will have to > use a custom kernel or enable a sysctl flag that was patched in by the > downstream developers. On distributions that enable user namespaces by > default, even users that don't wish to use them in the first places will > be affected by vulnerabilities. > > * Adding a capabilitiy: First of all, there would be no need for any > downstream patches or custom kernels. Users that wish to use user > namespaces would only have to enable the capability on the affected > executables, if that hasn't been done by the package maintainers > already. Users that might not even know of user namespaces have their peace. > > > In general, the feeling is that putting a feature like this behind a > > wall will only slow down the finding of any bugs, so I think the goal > > itself is questionable. But the chosen means for achieving your goal > > are definately wrong. > > I'm not talking about removing user namespaces altogether or making them > impossible to use - as I said above, user wouldn't notice anything in > the best case. Replacing setuid binaries with capabilitiy-based ones has > been done for quite some time now and I don't think anyone complained. That's the opposite - making something easier to use with less privilege, as opposed to requiring more. > I honestly don't see why adding a new capability would slow down finding > bugs. Not every program magically profits from user namespaces. Why > would, say, GCC, date or vim improve by using user namespaces? My point this is irrelevant, but I could certainly envision value in something like gcc, which takes arbitrary input, running as kuid -1 (not uid -1). Or especially ffmpeg. chromium. > is that use cases for user namespaces won't magically rain down from > Heaven just because it possible to use them without priviledge. And it > is hardly difficult to add the capabilitiy to those applications that > use user namespaces, is it? setcap cap_sys_user_ns+ep $binary doesn't > sound very complicated to me. But it requires root privilege, for something designed to not need root privilege. > I would actually say not adding this capability would slow down finding > bugs since users are less inclined to enable the feature if they can't > limit its
Re: [RFC PATCH] RDS: convert bind hash table to re-sizable hashtable
From: Santosh Shilimkar Date: Wed, 14 Oct 2015 14:15:31 -0700 > From: Santosh Shilimkar > > To further improve the RDS connection scalabilty on massive systems > where number of sockets grows into tens of thousands of sockets, there > is a need of larger bind hashtable. Pre-allocated 8K or 16K table is > not very flexible in terms of memory utilisation. The rhashtable > infrastructure gives us the flexibility to grow the hashtbable based > on use and also comes up with inbuilt efficient bucket(chain) handling. > > Cc: David Laight > Cc: David Miller > Signed-off-by: Santosh Shilimkar This looks fine as far as I can tell. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote: > Hi, > > This patch set adds the AF_ALG user space API to externalize the > asymmetric cipher API recently added to the kernel crypto API. > > The patch set is tested with the user space library of libkcapi [1]. > Use [1] test/test.sh for a full test run. The test covers the > following scenarios: Thanks Stephan. But I would prefer to defer this til after we have completed the conversion of current in-kernel users. This is because changing the kernel interface is easy while changing the user-space interface is not. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
[snip]
> >
> > So lots of little confusions added up to complete fail :-{
> >
> > Mostly I think it was the UNLOCK x + LOCK x are fully ordered (where I
> > forgot: but not against uninvolved CPUs) and RELEASE/ACQUIRE are
> > transitive (where I forgot: RELEASE/ACQUIRE _chains_ are transitive, but
> > again not against uninvolved CPUs).
> >
> > Which leads me to think I would like to suggest alternative rules for
> > RELEASE/ACQUIRE (to replace those Will suggested; as I think those are
> > partly responsible for my confusion).
>
> Yeah, sorry. I originally used the phrase "fully ordered" but changed it
> to "full barrier", which has stronger transitivity (newly understood
> definition) requirements that I didn't intend.
>
> RELEASE -> ACQUIRE should be used for message passing between two CPUs
> and not have ordering effects on other observers unless they're part of
> the RELEASE -> ACQUIRE chain.
>
> > - RELEASE -> ACQUIRE is fully ordered (but not a full barrier) when
> >they operate on the same variable and the ACQUIRE reads from the
> >RELEASE. Notable, RELEASE/ACQUIRE are RCpc and lack transitivity.
>
> Are we explicit about the difference between "fully ordered" and "full
> barrier" somewhere else, because this looks like it will confuse people.
>
This is confusing me right now. ;-)
Let's use a simple example for only one primitive, as I understand it,
if we say a primitive A is "fully ordered", we actually mean:
1. The memory operations preceding(in program order) A can't be
reordered after the memory operations following(in PO) A.
and
2. The memory operation(s) in A can't be reordered before the
memory operations preceding(in PO) A and after the memory
operations following(in PO) A.
If we say A is a "full barrier", we actually means:
1. The memory operations preceding(in program order) A can't be
reordered after the memory operations following(in PO) A.
and
2. The memory ordering guarantee in #1 is visible globally.
Is that correct? Or "full barrier" is more strong than I understand,
i.e. there is a third property of "full barrier":
3. The memory operation(s) in A can't be reordered before the
memory operations preceding(in PO) A and after the memory
operations following(in PO) A.
IOW, is "full barrier" a more strong version of "fully ordered" or not?
Regards,
Boqun
> > - RELEASE -> ACQUIRE can be upgraded to a full barrier (including
> >transitivity) using smp_mb__release_acquire(), either before RELEASE
> >or after ACQUIRE (but consistently [*]).
>
> Hmm, but we don't actually need this for RELEASE -> ACQUIRE, afaict. This
> is just needed for UNLOCK -> LOCK, and is exactly what RCU is currently
> using (for PPC only).
>
> Stepping back a second, I believe that there are three cases:
>
>
> RELEASE X -> ACQUIRE Y (same CPU)
>* Needs a barrier on TSO architectures for full ordering
>
> UNLOCK X -> LOCK Y (same CPU)
>* Needs a barrier on PPC for full ordering
>
> RELEASE X -> ACQUIRE X (different CPUs)
> UNLOCK X -> ACQUIRE X (different CPUs)
>* Fully ordered everywhere...
>* ... but needs a barrier on PPC to become a full barrier
>
>
signature.asc
Description: PGP signature
linux-next: manual merge of the pm tree with the omap tree
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in:
arch/arm/mach-omap2/timer.c
between commits:
3afbb9afe2c4 ("arm: omap2: timer: move realtime_counter_init() around")
9c46ffcd5214 ("arm: omap2: timer: always call clocksource_of_init() when DT")
from the omap tree and commit:
3722ed2380ad ("clocksource: cosmetic: Drop OF 'dependency' from symbols")
from the pm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/timer.c
index 05c17eb2f2d9,bef41837bf7f..
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@@ -469,64 -476,7 +469,64 @@@ static void __init omap2_gptimer_clocks
clocksource_gpt.name, clksrc.rate);
}
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+static void __init __omap_sync32k_timer_init(int clkev_nr, const char
*clkev_src,
+ const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+ const char *clksrc_prop, bool gptimer)
+{
+ omap_clk_init();
+ omap_dmtimer_init();
+ omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+
+ /* Enable the use of clocksource="gp_timer" kernel parameter */
+ if (use_gptimer_clksrc || gptimer)
+ omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
+ clksrc_prop);
+ else
+ omap2_sync32k_clocksource_init();
+}
+
+void __init omap_init_time(void)
+{
+ __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "timer_sys_ck", NULL, false);
+
+ if (of_have_populated_dt())
- clocksource_of_init();
++ clocksource_probe();
+}
+
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
+void __init omap3_secure_sync32k_timer_init(void)
+{
+ __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
+ 2, "timer_sys_ck", NULL, false);
+}
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+void __init omap3_gptimer_timer_init(void)
+{
+ __omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
+ 1, "timer_sys_ck", "ti,timer-alwon", true);
+}
+#endif
+
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) ||
\
+ defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
+static void __init omap4_sync32k_timer_init(void)
+{
+ __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
+ 2, "sys_clkin_ck", NULL, false);
+}
+
+void __init omap4_local_timer_init(void)
+{
+ omap4_sync32k_timer_init();
- clocksource_of_init();
++ clocksource_probe();
+}
+#endif
+
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
+
/*
* The realtime counter also called master counter, is a free-running
* counter, which is related to real time. It produces the count used
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan
On 2015/10/16 20:35, Ulf Hansson wrote:
On 11 September 2015 at 10:54, Shawn Lin wrote:
This patch adds Generic PHY access for sdhci-of-arasan. Driver
can get PHY handler from dt-binding, and power-on/init the PHY.
Also we add pm ops for PHY here if CONFIG_PM_SLEEP is enabled.
Signed-off-by: Shawn Lin
---
drivers/mmc/host/sdhci-of-arasan.c | 90 ++
1 file changed, 90 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 621c3f4..fdd71c7 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include "sdhci-pltfm.h"
#define SDHCI_ARASAN_CLK_CTRL_OFFSET 0x2c
@@ -35,6 +36,7 @@
*/
struct sdhci_arasan_data {
struct clk *clk_ahb;
+ struct phy *phy;
};
static unsigned int sdhci_arasan_get_timeout_clock(struct sdhci_host *host)
@@ -67,6 +69,62 @@ static struct sdhci_pltfm_data sdhci_arasan_pdata = {
#ifdef CONFIG_PM_SLEEP
/**
+ * sdhci_arasan_suspend_phy - Suspend phy method for the driver
+ * @phy:Handler of phy structure
+ * Returns 0 on success and error value on error
+ *
+ * Put the phy in a deactive state.
+ */
+static int sdhci_arasan_suspend_phy(struct phy *phy)
+{
+ int ret;
+
+ ret = phy_exit(phy);
+ if (ret < 0)
+ goto err_phy_exit;
This odd to me. First you do phy_exit() then phy_power_off(). It seems
like it should be in the opposite order.
yep, there is no need to use phy_exit/init for suspend/resume.
I will do it.
Moreover I wonder why phy_exit() is needed, I expected that to be
called at ->remove() only!?
+
+ ret = phy_power_off(phy);
+ if (ret < 0)
+ goto err_phy_pwr_off;
+
+ return 0;
+
+err_phy_pwr_off:
+ phy_power_on(phy);
+err_phy_exit:
+ phy_init(phy);
+ return ret;
+}
+
+/**
+ * sdhci_arasan_resume_phy - Resume phy method for the driver
+ * @phy:Handler of phy structure
+ * Returns 0 on success and error value on error
+ *
+ * Put the phy in a active state.
+ */
+static int sdhci_arasan_resume_phy(struct phy *phy)
+{
+ int ret;
+
+ ret = phy_power_on(phy);
+ if (ret < 0)
+ goto err_phy_pwr_on;
+
+ ret = phy_init(phy);
+ if (ret < 0)
+ goto err_phy_init;
+
Similar comment as above.
+ return 0;
+
+err_phy_init:
+ phy_exit(phy);
+err_phy_pwr_on:
+ phy_power_off(phy);
+ return ret;
+}
+
+/**
* sdhci_arasan_suspend - Suspend method for the driver
* @dev: Address of the device structure
* Returns 0 on success and error value on error
@@ -88,6 +146,12 @@ static int sdhci_arasan_suspend(struct device *dev)
clk_disable(pltfm_host->clk);
clk_disable(sdhci_arasan->clk_ahb);
+ if (sdhci_arasan->phy) {
+ ret = sdhci_arasan_suspend_phy(sdhci_arasan->phy);
+ if (ret < 0)
+ return ret;
+ }
This means you will suspend the phy after you have disabled the
clocks. Of course I can't tell whether that okay, but it doesn't
follow the same sequence as in ->probe(). To me that indicates that
either probe or suspend/resume could be broken.
phy has a seperate clk for itself, and it's controlled by phy driver.
So, there is no any relationship between controller's clk and phy's clk.
We disable or enable phy's clk internally in
phy_int/exit/power_off/power_on.
Of course if it makes odd to you, I would put suspend_phy before
clk_disable. :)
+
return 0;
}
@@ -119,6 +183,12 @@ static int sdhci_arasan_resume(struct device *dev)
return ret;
}
+ if (sdhci_arasan->phy) {
+ ret = sdhci_arasan_resume_phy(sdhci_arasan->phy);
+ if (ret < 0)
+ return ret;
+ }
+
return sdhci_resume_host(host);
}
#endif /* ! CONFIG_PM_SLEEP */
@@ -163,6 +233,26 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
goto clk_dis_ahb;
}
+ sdhci_arasan->phy = devm_phy_get(>dev, "phy_arasan");
+ if (!IS_ERR(sdhci_arasan->phy)) {
I understand the phy is optional, but you still need to handle the
EPROBE_DEFER case.
Perhaps you should also use devm_phy_optional_get() instead!?
I already changed it in version-2 [1]. :)
phy is mandatory for sdhci-arasan,5.1.
[1]: https://patchwork.kernel.org/patch/7173251/
+ ret = phy_power_on(sdhci_arasan->phy);
This looks a bit weird. Shouldn't you do phy_init() prior phy_power_on()?
Similar comment applies to phy_exit() and phy_power_off().
Both are okay. It depends how the phy-driver implement the four
interfaces. From my case, power_on for arasan's phy driver firstly
enable phy's clk and open power-domain, then programme phy internal
registers to activate phy. Without enabling phy's clk and
Re: [PATCH] userns/capability: Add user namespace capability
On 18 Oct 2015 22:13, Tobias Markus wrote: > On 17.10.2015 22:17, Richard Weinberger wrote: > > On Sat, Oct 17, 2015 at 5:58 PM, Tobias Markus wrote: > >> One question remains though: Does this break userspace executables that > >> expect being able to create user namespaces without priviledge? Since > >> creating user namespaces without CAP_SYS_ADMIN was not possible before > >> Linux 3.8, programs should already expect a potential EPERM upon calling > >> clone. Since creating a user namespace without CAP_SYS_USER_NS would > >> also cause EPERM, we should be on the safe side. > > > > In case of doubt, yes it will break existing software. > > Hiding user namespaces behind CAP_SYS_USER_NS will not magically > > make them secure. > > The goal is not to make user namespaces secure, but to limit access to > them somewhat in order to reduce the potential attack surface. the irony is that disallowing non-privileged processes access to userns means processes cannot jail themselves and thus make themselves more secure. i've been adding userns to various projects purely to get access to things like mount, net, pid, sysv, and ipc namespaces. putting this behind a cap also breaks the Chromium sandbox -- they were able to drop set*id on the sandbox binary and utilize userns instead. https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md https://code.google.com/p/chromium/issues/detail?id=312380 -mike signature.asc Description: Digital signature
Re: [PATCH 0/4] PCI: rcar: Add support for ARM64 and multiple instances
On Fri, Oct 16, 2015 at 04:34:43PM -0500, Bjorn Helgaas wrote: > On Fri, Oct 02, 2015 at 11:25:03AM +0100, Phil Edworthy wrote: > > Fixes and changes to get PCIe working on ARM64 with mulitple instances. > > > > I've tested these on ARM (Koelsch board), and it works fine. > > I've also tested on ARM64 (Salvator-X board), but I currently have an issue > > with inbound PCI accesses. I am reasonably sure that this problem is > > hardware > > related. > > > > Phil Edworthy (4): > > PCI: rcar-pcie: Make PCI aware of the IO resources > > PCI: rcar-pcie: Remove dependency on ARM-specific struct hw_pci > > PCI: rcar-pcie: Set root bus nr to that provided in DT > > PCI: rcar-pcie: Fix IO offset for multiple instances > > This all looks pretty reasonable to me, but I'm waiting for an ack from > Simon before merging it. Acked-by: Simon Horman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] clocksource: mtk_timer: fix pr_warn() messages in mtk_timer_init
On Mon, 2015-10-19 at 03:09 +0300, Alexey Klimov wrote:
> 1) Change pr_warn()s to pr_err()s. These messages are actually
> errors and not warnings.
> 2) Add missing \n.
> 3) Error message for kzalloc() failure is removed per suggestion
> by Joe Perches. There is generic stack_dump() for allocation issues.
Some of the braces around single statements
could also be removed.
> diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
> index ca5ea9e..ac92ca2 100644
> @@ -184,7 +184,6 @@ static void __init mtk_timer_init(struct device_node
> *node)
>
> evt = kzalloc(sizeof(*evt), GFP_KERNEL);
> if (!evt) {
> - pr_warn("Can't allocate mtk clock event driver struct");
> return;
> }
could be written:
evt = kzalloc(sizeof(*evt), GFP_KERNEL);
if (!evt)
return;
etc...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
On Thu, Oct 15, 2015 at 09:30:40AM -0700, Paul E. McKenney wrote: > On Thu, Oct 15, 2015 at 12:48:03PM +0800, Boqun Feng wrote: > > On Wed, Oct 14, 2015 at 08:07:05PM -0700, Paul E. McKenney wrote: [snip] > > > > > Why not try creating a longer litmus test that requires P0's write to > > > "a" to propagate to P1 before both processes complete? > > > > > > > I will try to write one, but to be clear, you mean we still observe > > > > 0:r3 == 0 && a == 2 && 1:r3 == 0 > > > > at the end, right? Because I understand that if P1's write to 'a' > > doesn't override P0's, P0's write to 'a' will propagate. > > Your choice. My question is whether you can come up with a similar > litmus test where lwsync is allowing the behavior here, but clearly > is affecting some other aspect of ordering. > Got it, though my question about the propagation of P0's write to 'a' was originally aimed at understanding the hardware behavior(or model) in your sequence of events ;-) To be clear, by "some other aspect of ordering", you mean something like a paired RELEASE+ACQUIRE senario(i.e. P1 observes P0's write to 'a' via a load, which means P0's write to 'a' propagates at some point), right? If so I haven't yet came up with one, and I think there's probably none, so my worry about "lwsync" in other places is likely unnecessary. Regards, Boqun signature.asc Description: PGP signature
Re: [PATCH v2 5/6] ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
On 16.10.2015 01:51, Javier Martinez Canillas wrote: > The eMMC is non-removable so is marked with the non-removable DT > property to avoid having to redetect it after a suspend/resume. > > But it also has the broken-cd property which is wrong since only > one of the DT properties for card detection should be used. > > Also remove the card-detect-delay property that is not needed with > non-removable. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes since v1: > - None, new patch. > > arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 -- > 1 file changed, 2 deletions(-) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
On 16.10.2015 01:51, Javier Martinez Canillas wrote: > The eMMC is non-removable so mark it using the non-removable DT > property to avoid having to redetect it after a suspend/resume. > > Also remove the card-detect-delay property that is not needed with > non-removable. > > Signed-off-by: Javier Martinez Canillas > > --- > > Changes since v1: > - None, new patch. > > arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/6] ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
On 16.10.2015 01:51, Javier Martinez Canillas wrote: > The eMMC is non-removable so is marked with the non-removable DT > property to avoid having to redetect it after a suspend/resume. > > But it also has the broken-cd property which is wrong since only > one of the DT properties for card detection should be used. > > Also remove the card-detect-delay property that is not needed with > non-removable. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes since v1: > - None, new patch. > > arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 -- > 1 file changed, 2 deletions(-) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] clocksource: mtk_timer: fix pr_warn() messages in mtk_timer_init
1) Change pr_warn()s to pr_err()s. These messages are actually
errors and not warnings.
2) Add missing \n.
3) Error message for kzalloc() failure is removed per suggestion
by Joe Perches. There is generic stack_dump() for allocation issues.
Signed-off-by: Alexey Klimov
---
drivers/clocksource/mtk_timer.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index ca5ea9e..ac92ca2 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -184,7 +184,6 @@ static void __init mtk_timer_init(struct device_node *node)
evt = kzalloc(sizeof(*evt), GFP_KERNEL);
if (!evt) {
- pr_warn("Can't allocate mtk clock event driver struct");
return;
}
@@ -200,24 +199,24 @@ static void __init mtk_timer_init(struct device_node
*node)
evt->gpt_base = of_io_request_and_map(node, 0, "mtk-timer");
if (IS_ERR(evt->gpt_base)) {
- pr_warn("Can't get resource\n");
+ pr_err("Can't get resource\n");
return;
}
evt->dev.irq = irq_of_parse_and_map(node, 0);
if (evt->dev.irq <= 0) {
- pr_warn("Can't parse IRQ");
+ pr_err("Can't parse IRQ\n");
goto err_mem;
}
clk = of_clk_get(node, 0);
if (IS_ERR(clk)) {
- pr_warn("Can't get timer clock");
+ pr_err("Can't get timer clock\n");
goto err_irq;
}
if (clk_prepare_enable(clk)) {
- pr_warn("Can't prepare clock");
+ pr_err("Can't prepare clock\n");
goto err_clk_put;
}
rate = clk_get_rate(clk);
@@ -226,7 +225,7 @@ static void __init mtk_timer_init(struct device_node *node)
if (request_irq(evt->dev.irq, mtk_timer_interrupt,
IRQF_TIMER | IRQF_IRQPOLL, "mtk_timer", evt)) {
- pr_warn("failed to setup irq %d\n", evt->dev.irq);
+ pr_err("failed to setup irq %d\n", evt->dev.irq);
goto err_clk_disable;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
On 16.10.2015 01:51, Javier Martinez Canillas wrote: > The Exynos5800 Peach Pi Chromebook has a Marvell WiFi SDIO chip which > can't neither be removed nor be detected. But the node isn't marked > as non-removable and instead has the broken-cd DT property. > > This causes the device to be removed when the system enters into a > suspend state and the following warnings is shown after a resume: > > [ 181.944636] mmc2: error -2 during resume (card was removed?) > > Also remove the card-detect-delay property that is not needed with > non-removable. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes since v1: > - Remove card-detect-delay property as well. > > arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) That sounds reasonable: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] clocksource: mtk_timer: fix memleak in mtk_timer_init()
Add error path to clear evt struct allocated by kzalloc()
in the beginning of function mtk_timer_init().
Acked-by: Matthias Brugger
Signed-off-by: Alexey Klimov
---
drivers/clocksource/mtk_timer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index ac92ca2..a811e7c 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -200,7 +200,7 @@ static void __init mtk_timer_init(struct device_node *node)
evt->gpt_base = of_io_request_and_map(node, 0, "mtk-timer");
if (IS_ERR(evt->gpt_base)) {
pr_err("Can't get resource\n");
- return;
+ goto err_kzalloc;
}
evt->dev.irq = irq_of_parse_and_map(node, 0);
@@ -255,5 +255,7 @@ err_mem:
iounmap(evt->gpt_base);
of_address_to_resource(node, 0, );
release_mem_region(res.start, resource_size());
+err_kzalloc:
+ kfree(evt);
}
CLOCKSOURCE_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_timer_init);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] clocksource: mtk_timer: add pr_fmt define
It's a bit unclear what subsystem/driver emits some messages to dmesg in function mtk_init_timer(). Use pr_fmt to auto-prefix the messages appropriately. Acked-by: Matthias Brugger Signed-off-by: Alexey Klimov --- drivers/clocksource/mtk_timer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c index 50f0641..ca5ea9e 100644 --- a/drivers/clocksource/mtk_timer.c +++ b/drivers/clocksource/mtk_timer.c @@ -16,6 +16,8 @@ * GNU General Public License for more details. */ +#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt + #include #include #include -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH v2 3/6] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
On 16.10.2015 01:51, Javier Martinez Canillas wrote: > The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which > can't neither be removed nor be detected. But the node isn't marked > as non-removable and instead has the broken-cd DT property. > > This causes the device to be removed when the system enters into a > suspend state and the following warnings is shown after a resume: > > [ 181.944636] mmc2: error -2 during resume (card was removed?) > > Also remove the card-detect-delay property that is not needed with > non-removable. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes since v1: > - Remove card-detect-delay property as well. > - Use the correct mmc node. Suggested by Tomeu. > > arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/6] ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
On 16.10.2015 01:51, Javier Martinez Canillas wrote: > The Exynos5420 Peach Pit Chromebook has a Marvell WiFi SDIO chip which > can't neither be removed nor be detected. But the node isn't marked > as non-removable and instead has the broken-cd DT property. > > This causes the device to be removed when the system enters into a > suspend state and the following warnings is shown after a resume: > > [ 181.944636] mmc2: error -2 during resume (card was removed?) > > Also remove the card-detect-delay property that is not needed with > non-removable. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes since v1: > - Remove card-detect-delay property as well. > > arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Regression since commit 92bac83
Hi,
I recently upgraded the kernel in a Dell Latitude D600 and found that the
touchpad clicks failed. The problem was bisected to commit
92bac83dd79e60e65c475222e41a992a70434beb ("Input: alps - non interleaved V2
dualpoint has separate stick button bits"). The laptop has a combination
touchpad and control stick. For this device, the following values are found:
priv->protoversion is 0x200 (ALPS_PROTO_V2)
priv->flags is 0x6 (ALPS_DUALPOINT | ALPS_PASS)
As a result, the new code added in this patch is executed, and left, right, and
middle are updated. Once this code is introduced, a left click causes some event
as it will wake a sleeping screen, but not select any windows or do anything useful.
Please advise on what information would be needed to help debug this problem.
Thanks,
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
