[PATCH 4/4] phy: berlin-usb: fix divider for BG2
From: Thomas Hebb
The USB PLL divider set by the marvell,berlin2-usb-phy compatible is not
correct for BG2. We couldn't change it before because BG2Q incorrectly
used the same compatible string. Now that BG2Q's compatible is fixed,
change BG2's divider to the correct value.
Signed-off-by: Thomas Hebb
Tested-by: Antoine Tenart
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/phy-berlin-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/phy-berlin-usb.c b/drivers/phy/phy-berlin-usb.c
index ab54f28..335e06d 100644
--- a/drivers/phy/phy-berlin-usb.c
+++ b/drivers/phy/phy-berlin-usb.c
@@ -105,7 +105,7 @@
static const u32 phy_berlin_pll_dividers[] = {
/* Berlin 2 */
- CLK_REF_DIV(0xc) | FEEDBACK_CLK_DIV(0x54),
+ CLK_REF_DIV(0x6) | FEEDBACK_CLK_DIV(0x55),
/* Berlin 2CD/Q */
CLK_REF_DIV(0xc) | FEEDBACK_CLK_DIV(0x54),
};
--
1.7.9.5
--
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] phy: berlin-usb: fix divider for BG2CD
From: Thomas Hebb
The marvell,berlin2cd-usb-phy compatible incorrectly sets the PLL
divider to BG2's value instead of BG2CD/BG2Q's. Change it to the right
value.
Signed-off-by: Thomas Hebb
Cc: sta...@vger.kernel.org
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/phy-berlin-usb.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-berlin-usb.c b/drivers/phy/phy-berlin-usb.c
index c6fc95b..ab54f28 100644
--- a/drivers/phy/phy-berlin-usb.c
+++ b/drivers/phy/phy-berlin-usb.c
@@ -106,8 +106,8 @@
static const u32 phy_berlin_pll_dividers[] = {
/* Berlin 2 */
CLK_REF_DIV(0xc) | FEEDBACK_CLK_DIV(0x54),
- /* Berlin 2CD */
- CLK_REF_DIV(0x6) | FEEDBACK_CLK_DIV(0x55),
+ /* Berlin 2CD/Q */
+ CLK_REF_DIV(0xc) | FEEDBACK_CLK_DIV(0x54),
};
struct phy_berlin_usb_priv {
--
1.7.9.5
--
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] phy/pxa: add HAS_IOMEM dependency
From: Sebastian Ott Fix this compile error: drivers/built-in.o: In function 'mv_usb2_phy_probe': phy-pxa-28nm-usb2.c:(.text+0x25ec): undefined reference to 'devm_ioremap_resource' drivers/built-in.o: In function 'mv_hsic_phy_probe': phy-pxa-28nm-hsic.c:(.text+0x3084): undefined reference to 'devm_ioremap_resource' Signed-off-by: Sebastian Ott Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index c0e6ede..6b8dd16 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -56,6 +56,7 @@ config PHY_EXYNOS_MIPI_VIDEO config PHY_PXA_28NM_HSIC tristate "Marvell USB HSIC 28nm PHY Driver" + depends on HAS_IOMEM select GENERIC_PHY help Enable this to support Marvell USB HSIC PHY driver for Marvell @@ -66,6 +67,7 @@ config PHY_PXA_28NM_HSIC config PHY_PXA_28NM_USB2 tristate "Marvell USB 2.0 28nm PHY Driver" + depends on HAS_IOMEM select GENERIC_PHY help Enable this to support Marvell USB 2.0 PHY driver for Marvell -- 1.7.9.5 -- 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] phy: ti-pipe3: fix suspend
From: Roger Quadros
Relying on PM-ops for shutting down PHY clocks was a
bad idea since the users (e.g. PCIe/SATA) might not
have been suspended by then.
The main culprit for not shutting down the clocks was
the stray pm_runtime_get() call in probe.
Fix the whole thing in the right way by getting rid
of that pm_runtime_get() call from probe and
removing all PM-ops. It is the sole responsibility
of the PHY user to properly turn OFF and de-initialize
the PHY as part of its suspend routine.
As PHY core serializes init/exit we don't need
to use a spinlock in this driver. So get rid of it.
Signed-off-by: Roger Quadros
Signed-off-by: Sekhar Nori
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/phy-ti-pipe3.c | 172 +++-
1 file changed, 41 insertions(+), 131 deletions(-)
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 53f295c..3510b81 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
#definePLL_STATUS 0x0004
#definePLL_GO 0x0008
@@ -83,10 +82,6 @@ struct ti_pipe3 {
struct clk *refclk;
struct clk *div_clk;
struct pipe3_dpll_map *dpll_map;
- boolenabled;
- spinlock_t lock; /* serialize clock enable/disable */
- /* the below flag is needed specifically for SATA */
- boolrefclk_enabled;
};
static struct pipe3_dpll_map dpll_map_usb[] = {
@@ -137,6 +132,9 @@ static struct pipe3_dpll_params
*ti_pipe3_get_dpll_params(struct ti_pipe3 *phy)
return NULL;
}
+static int ti_pipe3_enable_clocks(struct ti_pipe3 *phy);
+static void ti_pipe3_disable_clocks(struct ti_pipe3 *phy);
+
static int ti_pipe3_power_off(struct phy *x)
{
struct ti_pipe3 *phy = phy_get_drvdata(x);
@@ -217,6 +215,7 @@ static int ti_pipe3_init(struct phy *x)
u32 val;
int ret = 0;
+ ti_pipe3_enable_clocks(phy);
/*
* Set pcie_pcs register to 0x96 for proper functioning of phy
* as recommended in AM572x TRM SPRUHZ6, section 18.5.2.2, table
@@ -250,33 +249,35 @@ static int ti_pipe3_exit(struct phy *x)
u32 val;
unsigned long timeout;
- /* SATA DPLL can't be powered down due to Errata i783 and PCIe
-* does not have internal DPLL
-*/
- if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata") ||
- of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie"))
+ /* SATA DPLL can't be powered down due to Errata i783 */
+ if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata"))
return 0;
- /* Put DPLL in IDLE mode */
- val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
- val |= PLL_IDLE;
- ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val);
-
- /* wait for LDO and Oscillator to power down */
- timeout = jiffies + msecs_to_jiffies(PLL_IDLE_TIME);
- do {
- cpu_relax();
- val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
- if ((val & PLL_TICOPWDN) && (val & PLL_LDOPWDN))
- break;
- } while (!time_after(jiffies, timeout));
+ /* PCIe doesn't have internal DPLL */
+ if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
+ /* Put DPLL in IDLE mode */
+ val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
+ val |= PLL_IDLE;
+ ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val);
- if (!(val & PLL_TICOPWDN) || !(val & PLL_LDOPWDN)) {
- dev_err(phy->dev, "Failed to power down: PLL_STATUS 0x%x\n",
- val);
- return -EBUSY;
+ /* wait for LDO and Oscillator to power down */
+ timeout = jiffies + msecs_to_jiffies(PLL_IDLE_TIME);
+ do {
+ cpu_relax();
+ val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
+ if ((val & PLL_TICOPWDN) && (val & PLL_LDOPWDN))
+ break;
+ } while (!time_after(jiffies, timeout));
+
+ if (!(val & PLL_TICOPWDN) || !(val & PLL_LDOPWDN)) {
+ dev_err(phy->dev, "Failed to power down: PLL_STATUS
0x%x\n",
+ val);
+ return -EBUSY;
+ }
}
+ ti_pipe3_disable_clocks(phy);
+
return 0;
}
static struct phy_ops ops = {
@@ -306,7 +307,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
return -ENOMEM;
phy->dev= >dev;
- spin_lock_init(>lock);
if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
[GIT PULL 0/4] phy: for 4.2 -rc cycle
Hi Greg, Please find the pull request for 4.2 -rc cycle. This includes a couple of driver fixes, one to fix suspend/resume and the other to fix pll divider values. It also includes a Kconfig fix to fix a compiler error. Let me know if I have to change something. Cheers Kishon The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git tags/phy-for-4.2-rc for you to fetch changes up to dcb54fcb3483862e993abdae99cec22fb3ae4099: phy: berlin-usb: fix divider for BG2 (2015-07-15 20:02:09 +0530) phy: for 4.2-rc *) Fix PIPE3 PM so that all its users (PCIe, SATA, USB) can idle and resume *) Fix a compiler error in pxa *) Fix pll divider values in berlin-usb phy driver Signed-off-by: Kishon Vijay Abraham I Roger Quadros (1): phy: ti-pipe3: fix suspend Sebastian Ott (1): phy/pxa: add HAS_IOMEM dependency Thomas Hebb (2): phy: berlin-usb: fix divider for BG2CD phy: berlin-usb: fix divider for BG2 drivers/phy/Kconfig |2 + drivers/phy/phy-berlin-usb.c |4 +- drivers/phy/phy-ti-pipe3.c | 172 ++ 3 files changed, 45 insertions(+), 133 deletions(-) -- 1.7.9.5 -- 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 v7 1/3] dt/bindings: Add binding for the Raspberry Pi firmware driver
This driver will provide support for calls into the firmware that will
be used by other drivers like cpufreq and vc4.
Signed-off-by: Eric Anholt
Acked-by: Stephen Warren
---
v2: Improve commit message, point to mailbox.txt for how mboxes work.
v3: Use Lee's suggestion for mailbox phandle docs, fix spelling of
"raspberry".
v4: Change the compatible string to "raspberrypi,bcm2835-firmware"
(requested by Lee, agreed by Stephen)
v5: Add missing s-o-b, fix spelling.
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt | 14 ++
1 file changed, 14 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
diff --git
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
new file mode 100644
index 000..6824b31
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
@@ -0,0 +1,14 @@
+Raspberry Pi VideoCore firmware driver
+
+Required properties:
+
+- compatible: Should be "raspberrypi,bcm2835-firmware"
+- mboxes: Phandle to the firmware device's Mailbox.
+ (See: ../mailbox/mailbox.txt for more information)
+
+Example:
+
+firmware {
+ compatible = "raspberrypi,bcm2835-firmware";
+ mboxes = <>;
+};
--
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 v7 2/3] ARM: bcm2835: Add the Raspberry Pi firmware driver
This gives us a function for making mailbox property channel requests
of the firmware, which is most notable in that it will let us get and
set clock rates.
Signed-off-by: Eric Anholt
Acked-by: Stephen Warren
---
v2: Drop power-domains stuff for now since we don't have the driver
core support to make it useful. Move to drivers/firmware/.
Capitalize the enums. De-global the firmware variable. Use the
firmware device to allocate our DMA buffer, so that the dma-ranges
DT property gets respected. Simplify the property tag transaction
interface even more, leaving a multi-tag interface still
available. For conciseness, rename "raspberrypi" to "rpi" on all
functions/enums/structs, and the "firmware" variable to "fw".
Print when the driver is probed successfully, since debugging
-EPROBE_DEFER handling is such a big part of bcm2835 development.
Drop -EBUSY mailbox handling since the mailbox core has been fixed
to return -EPROBE_DEFER in -next.
v3: Use kernel-doc style for big comments (from Noralf), drop stale
comment, use "dev" when freeing DMA as well.
v4: Move description comment into copyright comment, drop a dead
initialization of "ret", and print the firmware revision at probe
time.
v5: Rename the compatible to "raspberrypi,bcm2835-firmware", move
include to not say "property", add functions to get struct
rpi_firmware from the device_node and put when done, make property
functions take the rpi_firmware instead and never return
-EPROBE_DEFER, put the driver under its own RASPBERRYPI_FIRMWARE
Kconfig.
v6: Drop the try_module_get/module_put stuff, since all clients will
be referencing our symbols in order to call those functions,
anyway. Fix the kerneldoc comments for the changes in v5.
drivers/firmware/Kconfig | 7 +
drivers/firmware/Makefile | 1 +
drivers/firmware/raspberrypi.c | 260 +
include/soc/bcm2835/raspberrypi-firmware.h | 115 +
4 files changed, 383 insertions(+)
create mode 100644 drivers/firmware/raspberrypi.c
create mode 100644 include/soc/bcm2835/raspberrypi-firmware.h
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 99c69a3..1faf511 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -136,6 +136,13 @@ config QCOM_SCM
bool
depends on ARM || ARM64
+config RASPBERRYPI_FIRMWARE
+ tristate "Raspberry Pi Firmware Driver"
+ depends on BCM2835_MBOX
+ help
+ This option enables support for communicating with the firmware on the
+ Raspberry Pi.
+
source "drivers/firmware/broadcom/Kconfig"
source "drivers/firmware/google/Kconfig"
source "drivers/firmware/efi/Kconfig"
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 4a4b897..95efc8f 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o
obj-$(CONFIG_QCOM_SCM) += qcom_scm.o
obj-$(CONFIG_QCOM_SCM) += qcom_scm-32.o
CFLAGS_qcom_scm-32.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
+obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
obj-y += broadcom/
obj-$(CONFIG_GOOGLE_FIRMWARE) += google/
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
new file mode 100644
index 000..dd506cd3
--- /dev/null
+++ b/drivers/firmware/raspberrypi.c
@@ -0,0 +1,260 @@
+/*
+ * Defines interfaces for interacting wtih the Raspberry Pi firmware's
+ * property channel.
+ *
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MBOX_MSG(chan, data28) (((data28) & ~0xf) | ((chan) & 0xf))
+#define MBOX_CHAN(msg) ((msg) & 0xf)
+#define MBOX_DATA28(msg) ((msg) & ~0xf)
+#define MBOX_CHAN_PROPERTY 8
+
+struct rpi_firmware {
+ struct mbox_client cl;
+ struct mbox_chan *chan; /* The property channel. */
+ struct completion c;
+ u32 enabled;
+};
+
+static DEFINE_MUTEX(transaction_lock);
+
+static void response_callback(struct mbox_client *cl, void *msg)
+{
+ struct rpi_firmware *fw = container_of(cl, struct rpi_firmware, cl);
+ complete(>c);
+}
+
+/*
+ * Sends a request to the firmware through the BCM2835 mailbox driver,
+ * and synchronously waits for the reply.
+ */
+static int
+rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
+{
+ u32 message = MBOX_MSG(chan, data);
+ int ret;
+
+ WARN_ON(data & 0xf);
+
+ mutex_lock(_lock);
+ reinit_completion(>c);
+ ret = mbox_send_message(fw->chan, );
+ if (ret >= 0) {
+
[PATCH v7 3/3] ARM: bcm2835: Add the firmware driver information to the RPi DT
Signed-off-by: Eric Anholt
Acked-by: Lee Jones (previous version with pm-domains)
Acked-by: Stephen Warren
---
v2: Drop pm-domains stuff since I've dropped it from the firmware
driver for now, until we get drivers/base fixed.
v3: Rename the compatible to "raspberrypi,bcm2835-firmware"
arch/arm/boot/dts/bcm2835-rpi.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 46780bb..ab5474e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -14,6 +14,13 @@
linux,default-trigger = "heartbeat";
};
};
+
+ soc {
+ firmware: firmware {
+ compatible = "raspberrypi,bcm2835-firmware";
+ mboxes = <>;
+ };
+ };
};
{
--
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/
good afternoon
Hi samsung s6,280euro, imac,nikon,samsung products site: isgayre. com
Re: [PATCHv2] x86, CPU: Restore MSR_IA32_ENERGY_PERF_BIAS after resume
On Fri, Jul 17, 2015 at 10:39:25PM +0200, Thomas Gleixner wrote: > Aside of documenting what that resume thing is for and why > init_intel_energy_perf() needs to be called, I'm quite sure that this > will fill up pretty fast with other stuff which gets lost across S/R. Haha, I was thinking the same thing... So we better lay the foundations properly, from the beginning. :-) -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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/2] ASoC: rockchip: Add machine driver for max98090 codec
From: zhengxing
The driver is used for rockchip board using a max98090.
Reviewed-by: Dylan Reid
Signed-off-by: zhengxing
---
Changes in v2: None
.../bindings/sound/rockchip-max98090.txt | 19 ++
sound/soc/rockchip/Kconfig | 10 +
sound/soc/rockchip/Makefile|4 +
sound/soc/rockchip/rockchip_max98090.c | 247
4 files changed, 280 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/rockchip-max98090.txt
create mode 100644 sound/soc/rockchip/rockchip_max98090.c
diff --git a/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
b/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
new file mode 100644
index 000..a805aa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
@@ -0,0 +1,19 @@
+ROCKCHIP with MAX98090 CODEC
+
+Required properties:
+- compatible: "rockchip,rockchip-audio-max98090"
+- rockchip,model: The user-visible name of this sound complex
+- rockchip,i2s-controller: The phandle of the Rockchip I2S controller that's
+ connected to the CODEC
+- rockchip,audio-codec: The phandle of the MAX98090 audio codec
+- rockchip,headset-codec: The phandle of Ext chip for jack detection
+
+Example:
+
+sound {
+ compatible = "rockchip,rockchip-audio-max98090";
+ rockchip,model = "ROCKCHIP-I2S";
+ rockchip,i2s-controller = <>;
+ rockchip,audio-codec = <>;
+ rockchip,headset-codec = <>;
+};
diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index e181826..d123566 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -14,3 +14,13 @@ config SND_SOC_ROCKCHIP_I2S
Say Y or M if you want to add support for I2S driver for
Rockchip I2S device. The device supports upto maximum of
8 channels each for play and record.
+
+config SND_SOC_ROCKCHIP_MAX98090
+ tristate "ASoC support for Rockchip boards using a MAX98090 codec"
+ depends on SND_SOC_ROCKCHIP && I2C && GPIOLIB
+ select SND_SOC_ROCKCHIP_I2S
+ select SND_SOC_MAX98090
+ select SND_SOC_TS3A227E
+ help
+ Say Y or M here if you want to add support for SoC audio on Rockchip
+ boards using the MAX98090 codec, such as Veyron.
diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile
index b921909..df3445b 100644
--- a/sound/soc/rockchip/Makefile
+++ b/sound/soc/rockchip/Makefile
@@ -2,3 +2,7 @@
snd-soc-i2s-objs := rockchip_i2s.o
obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-i2s.o
+
+snd-soc-rockchip-max98090-objs := rockchip_max98090.o
+
+obj-$(CONFIG_SND_SOC_ROCKCHIP_MAX98090) += snd-soc-rockchip-max98090.o
diff --git a/sound/soc/rockchip/rockchip_max98090.c
b/sound/soc/rockchip/rockchip_max98090.c
new file mode 100644
index 000..f6644b3
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_max98090.c
@@ -0,0 +1,247 @@
+/*
+ * Rockchip machine ASoC driver for boards using a MAX90809 CODEC.
+ *
+ * Copyright (c) 2014, ROCKCHIP CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[PATCH v2 0/2] Add codec machine driver for rockchip platform
From: zhengxing Hi, The simple-card is not common at present, soc maybe need own machine driver for jack detection. Add drivers for two families of rockchip-bases chromebooks. These machine drives don't use simplecard because we need custom jack detection plumbing. - use ts3a227e for ext jack detection with max98090 - call rt5645_set_jack_detect function via rt5645 codec driver Thanks. Changes in v2: Signed-off-by: zhengxing zhengxing (2): ASoC: rockchip: Add machine driver for max98090 codec ASoC: rockchip: Add machine driver for rt5645/rt5650 codec .../bindings/sound/rockchip-max98090.txt | 19 ++ .../devicetree/bindings/sound/rockchip-rt5645.txt | 17 ++ sound/soc/rockchip/Kconfig | 19 ++ sound/soc/rockchip/Makefile|6 + sound/soc/rockchip/rockchip_max98090.c | 247 sound/soc/rockchip/rockchip_rt5645.c | 236 +++ 6 files changed, 544 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/rockchip-max98090.txt create mode 100644 Documentation/devicetree/bindings/sound/rockchip-rt5645.txt create mode 100644 sound/soc/rockchip/rockchip_max98090.c create mode 100644 sound/soc/rockchip/rockchip_rt5645.c -- 1.7.9.5 -- 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/2] ASoC: rockchip: Add machine driver for rt5645/rt5650 codec
From: zhengxing
The driver is used for rockchip board using a rt5645/rt5650.
Reviewed-by: Dylan Reid
Signed-off-by: zhengxing
---
Changes in v2:
Signed-off-by: zhengxing
.../devicetree/bindings/sound/rockchip-rt5645.txt | 17 ++
sound/soc/rockchip/Kconfig |9 +
sound/soc/rockchip/Makefile|2 +
sound/soc/rockchip/rockchip_rt5645.c | 236
4 files changed, 264 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/rockchip-rt5645.txt
create mode 100644 sound/soc/rockchip/rockchip_rt5645.c
diff --git a/Documentation/devicetree/bindings/sound/rockchip-rt5645.txt
b/Documentation/devicetree/bindings/sound/rockchip-rt5645.txt
new file mode 100644
index 000..411a62b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip-rt5645.txt
@@ -0,0 +1,17 @@
+ROCKCHIP with RT5645/RT5650 CODECS
+
+Required properties:
+- compatible: "rockchip,rockchip-audio-rt5645"
+- rockchip,model: The user-visible name of this sound complex
+- rockchip,i2s-controller: The phandle of the Rockchip I2S controller that's
+ connected to the CODEC
+- rockchip,audio-codec: The phandle of the RT5645/RT5650 audio codec
+
+Example:
+
+sound {
+ compatible = "rockchip,rockchip-audio-rt5645";
+ rockchip,model = "ROCKCHIP-I2S";
+ rockchip,i2s-controller = <>;
+ rockchip,audio-codec = <>;
+};
diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index d123566..58bae8e 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -24,3 +24,12 @@ config SND_SOC_ROCKCHIP_MAX98090
help
Say Y or M here if you want to add support for SoC audio on Rockchip
boards using the MAX98090 codec, such as Veyron.
+
+config SND_SOC_ROCKCHIP_RT5645
+ tristate "ASoC support for Rockchip boards using a RT5645/RT5650 codec"
+ depends on SND_SOC_ROCKCHIP && I2C && GPIOLIB
+ select SND_SOC_ROCKCHIP_I2S
+ select SND_SOC_RT5645
+ help
+ Say Y or M here if you want to add support for SoC audio on Rockchip
+ boards using the RT5645/RT5650 codec, such as Veyron.
diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile
index df3445b..1bc1dc3 100644
--- a/sound/soc/rockchip/Makefile
+++ b/sound/soc/rockchip/Makefile
@@ -4,5 +4,7 @@ snd-soc-i2s-objs := rockchip_i2s.o
obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-i2s.o
snd-soc-rockchip-max98090-objs := rockchip_max98090.o
+snd-soc-rockchip-rt5645-objs := rockchip_rt5645.o
obj-$(CONFIG_SND_SOC_ROCKCHIP_MAX98090) += snd-soc-rockchip-max98090.o
+obj-$(CONFIG_SND_SOC_ROCKCHIP_RT5645) += snd-soc-rockchip-rt5645.o
diff --git a/sound/soc/rockchip/rockchip_rt5645.c
b/sound/soc/rockchip/rockchip_rt5645.c
new file mode 100644
index 000..ded3e47
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_rt5645.c
@@ -0,0 +1,236 @@
+/*
+ * Rockchip machine ASoC driver for boards using a RT5645/RT5650 CODEC.
+ *
+ * Copyright (c) 2015, ROCKCHIP CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
Re: [RFC PATCH 04/21] x86/hweight: Add stack frame dependency for __arch_hweight*()
On Fri, Jul 17, 2015 at 12:32:20PM -0500, Josh Poimboeuf wrote: > Well, but this isn't some whitelist code to make stackvalidate happy. > > It's actually a real runtime frame pointer bug, and the rsp dependency > is real. If it does the call without first creating the stack frame > then it breaks frame pointer based stack traces. I think we can live with the stack trace being a little wrong in those __sw_* variants. And besides, we're talking about the very very small percentage of machines (which keeps getting smaller) which don't support POPCNT. And from those, only for the cases where the arg is not __builtin_constant_p() because there we do the __const_hweight* thing. I'd prefer to not clutter the code more in that case. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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/3] staging: sm7xxfb: move sm712fb out of staging
On Fri, Jul 17, 2015 at 09:52:35AM -0700, Greg Kroah-Hartman wrote: > On Fri, Jul 17, 2015 at 06:51:18PM +0530, Sudip Mukherjee wrote: > > Now since all cleanups are done and the code is ready to be merged lets > > move it out of staging into fbdev location. > > This is really hard for the fbdev developers to review. Care to just > make up a single patch that adds the driver to the tree in that location > so they can read the code and review it? I think i misunderstood you. I sent the v2 which was generated with git format-patch. So the part about deleting it from staging is also there. Did you mean to only send the part which is adding to the fbdev or is v2 ok? regards sudip -- 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 5/6] staging: rtl8188eu: stop using DBG_88E
On Fri, Jul 17, 2015 at 05:33:55PM +0200, Jakub Sitnicki wrote:
> On Thu, Jul 16, 2015 at 01:28 PM CEST, Sudip Mukherjee
> wrote:
> > Stop using DBG_88E which is a custom macro for printing debugging
> > messages. Instead start using pr_debug and in the process define
> > pr_fmt.
>
> In the end, don't we want to use netdev_dbg() everywhere where we work
> with a struct net_device? And use dev_dbg() everywhere where we work
> with a struct device (or a struct usb_interface)?
Looks like in some places we can get net_device from usb_interface.
struct dvobj_priv *dvobj = usb_get_intfdata(pusb_intf);
struct adapter *padapter = dvobj->if1;
struct net_device *pnetdev = padapter->pnetdev;
>
> At least that's how I understand commit 8f26b8376faa ("checkpatch:
> update suggested printk conversions") description:
>
> Direct conversion of printk(KERN_... to pr_ isn't the
> preferred conversion when a struct net_device or struct device is
> available.
>
> Do you think it is worth going straight for netdev_dbg()/dev_dbg() to
> avoid redoing it later?
At the end it should be netdev_* or dev_* and if both are not available
then pr_*. Here my main intention was to remove the custom defined
macro. And while doing this it is easier to use a script to reduce the
chances of error. Now that the custom macro is out of the way we can
concentrate on converting it to netdev_* or dev_*.
>
> >
> >
> > +#define pr_fmt(fmt) "R8188EU: " fmt
> > #include
> > #include
> > #include
>
> If we're going to stay with pr_debug(), using KBUILD_MODNAME seems to be
> the convention among drivers when defining pr_fmt():
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
yes, KBUILD_MODNAME is the usual convention but you will also find many
places where that has not been used. Here I have used R8188EU to keep it
same for all the messages that will be printed from the other files of
this driver else it might be confusing for the user.
regards
sudip
--
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] ASoC: rockchip: Add machine driver for max98090 codec
+static int snd_rk_mc_remove(struct platform_device *pdev)
+{
+struct snd_soc_card *soc_card = platform_get_drvdata(pdev);
+
+snd_soc_card_set_drvdata(soc_card, NULL);
+snd_soc_unregister_card(soc_card);
+platform_set_drvdata(pdev, NULL);
No need for any of the _set_drvdata() calls, the core does them and they
shouldn't make any difference anyway.
Done. I will remove *_set_drvdata and *get_drvdata because we don't
need them any more.
Sorry, I mean just remove platform_set_drvdata(pdev, NULL);
--
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] Documentation/fb: add documentation for sm712fb
Create the documentation for SM712. Mention all the supported modes and how to use. Signed-off-by: Sudip Mukherjee --- Documentation/fb/sm712fb.txt | 31 +++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/fb/sm712fb.txt diff --git a/Documentation/fb/sm712fb.txt b/Documentation/fb/sm712fb.txt new file mode 100644 index 000..c388442 --- /dev/null +++ b/Documentation/fb/sm712fb.txt @@ -0,0 +1,31 @@ +What is sm712fb? += + +This is a graphics framebuffer driver for Silicon Motion SM712 based processors. + +How to use it? +== + +Switching modes is done using the video=sm712fb:... boot parameter. + +If you want, for example, enable a resolution of 1280x1024x24bpp you should +pass to the kernel this command line: "video=sm712fb:0x31B". + +You should not compile-in vesafb. + +Currently supported video modes are: + +[Graphic modes] + +bpp | 640x480 800x600 1024x768 1280x1024 ++ + 8 | 0x3010x3030x3050x307 + 16 | 0x3110x3140x3170x31A + 24 | 0x3120x3150x3180x31B + +Missing Features + +(alias TODO list) + + * 2D acceleratrion + * dual-head support -- 1.8.1.2 -- 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] MAINTAINERS: update maintainers list
Now since sm712fb has moved out of staging update the maintainers list accordingly. Signed-off-by: Sudip Mukherjee --- MAINTAINERS | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8133cef..2c77c30 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9301,6 +9301,15 @@ S: Maintained F: drivers/media/i2c/ov2659.c F: include/media/ov2659.h +SILICON MOTION SM712 FRAME BUFFER DRIVER +M: Sudip Mukherjee +M: Teddy Wang +M: Sudip Mukherjee +L: linux-fb...@vger.kernel.org +S: Maintained +F: drivers/video/fbdev/sm712* +F: Documentation/fb/sm712fb.txt + SIS 190 ETHERNET DRIVER M: Francois Romieu L: net...@vger.kernel.org @@ -9721,14 +9730,6 @@ L: linux-wirel...@vger.kernel.org S: Maintained F: drivers/staging/rtl8723au/ -STAGING - SILICON MOTION SM7XX FRAME BUFFER DRIVER -M: Sudip Mukherjee -M: Teddy Wang -M: Sudip Mukherjee -L: linux-fb...@vger.kernel.org -S: Maintained -F: drivers/staging/sm7xxfb/ - STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER M: Sudip Mukherjee M: Teddy Wang -- 1.8.1.2 -- 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] staging: sm7xxfb: move sm712fb out of staging
Now since all cleanups are done and the code is ready to be merged lets move it out of staging into fbdev location. Signed-off-by: Sudip Mukherjee --- drivers/staging/Kconfig |2 - drivers/staging/Makefile |1 - drivers/staging/sm7xxfb/Kconfig | 13 - drivers/staging/sm7xxfb/Makefile |1 - drivers/staging/sm7xxfb/TODO | 12 - drivers/staging/sm7xxfb/sm7xx.h | 116 --- drivers/staging/sm7xxfb/sm7xxfb.c | 1653 - drivers/video/fbdev/Kconfig | 14 + drivers/video/fbdev/Makefile |1 + drivers/video/fbdev/sm712.h | 116 +++ drivers/video/fbdev/sm712fb.c | 1653 + 11 files changed, 1784 insertions(+), 1798 deletions(-) delete mode 100644 drivers/staging/sm7xxfb/Kconfig delete mode 100644 drivers/staging/sm7xxfb/Makefile delete mode 100644 drivers/staging/sm7xxfb/TODO delete mode 100644 drivers/staging/sm7xxfb/sm7xx.h delete mode 100644 drivers/staging/sm7xxfb/sm7xxfb.c create mode 100644 drivers/video/fbdev/sm712.h create mode 100644 drivers/video/fbdev/sm712fb.c diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 7f6cae5..a969276 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -56,8 +56,6 @@ source "drivers/staging/vt6656/Kconfig" source "drivers/staging/iio/Kconfig" -source "drivers/staging/sm7xxfb/Kconfig" - source "drivers/staging/sm750fb/Kconfig" source "drivers/staging/xgifb/Kconfig" diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 347f647..2747c82 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -22,7 +22,6 @@ obj-$(CONFIG_VT6655) += vt6655/ obj-$(CONFIG_VT6656) += vt6656/ obj-$(CONFIG_VME_BUS) += vme/ obj-$(CONFIG_IIO) += iio/ -obj-$(CONFIG_FB_SM7XX) += sm7xxfb/ obj-$(CONFIG_FB_SM750) += sm750fb/ obj-$(CONFIG_FB_XGI) += xgifb/ obj-$(CONFIG_USB_EMXX) += emxx_udc/ diff --git a/drivers/staging/sm7xxfb/Kconfig b/drivers/staging/sm7xxfb/Kconfig deleted file mode 100644 index e2922ae..000 --- a/drivers/staging/sm7xxfb/Kconfig +++ /dev/null @@ -1,13 +0,0 @@ -config FB_SM7XX - tristate "Silicon Motion SM7XX framebuffer support" - depends on FB && PCI - select FB_CFB_FILLRECT - select FB_CFB_COPYAREA - select FB_CFB_IMAGEBLIT - help - Frame buffer driver for the Silicon Motion SM710, SM712, SM721 - and SM722 chips. - - This driver is also available as a module. The module will be - called sm7xxfb. If you want to compile it as a module, say M - here and read . diff --git a/drivers/staging/sm7xxfb/Makefile b/drivers/staging/sm7xxfb/Makefile deleted file mode 100644 index 48f471c..000 --- a/drivers/staging/sm7xxfb/Makefile +++ /dev/null @@ -1 +0,0 @@ -obj-$(CONFIG_FB_SM7XX) += sm7xxfb.o diff --git a/drivers/staging/sm7xxfb/TODO b/drivers/staging/sm7xxfb/TODO deleted file mode 100644 index 7cb0b24..000 --- a/drivers/staging/sm7xxfb/TODO +++ /dev/null @@ -1,12 +0,0 @@ -TODO: -- Dual head support -- 2D acceleration support -- use kernel coding style -- refine the code and remove unused code -- move it to drivers/video/fbdev/sm7xxfb.c - -Please send any patches to - Greg Kroah-Hartman - Sudip Mukherjee - Teddy Wang - Sudip Mukherjee diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h deleted file mode 100644 index aad1cc4..000 --- a/drivers/staging/sm7xxfb/sm7xx.h +++ /dev/null @@ -1,116 +0,0 @@ -/* - * Silicon Motion SM712 frame buffer device - * - * Copyright (C) 2006 Silicon Motion Technology Corp. - * Authors:Ge Wang, gew...@siliconmotion.com - * Boyod boyod.y...@siliconmotion.com.cn - * - * Copyright (C) 2009 Lemote, Inc. - * Author: Wu Zhangjin, wuzhang...@gmail.com - * - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file COPYING in the main directory of this archive for - * more details. - */ - -#define FB_ACCEL_SMI_LYNX 88 - -#define SCREEN_X_RES 1024 -#define SCREEN_Y_RES 600 -#define SCREEN_BPP16 - -/*Assume SM712 graphics chip has 4MB VRAM */ -#define SM712_VIDEOMEMORYSIZE0x0040 -/*Assume SM722 graphics chip has 8MB VRAM */ -#define SM722_VIDEOMEMORYSIZE0x0080 - -#define dac_reg(0x3c8) -#define dac_val(0x3c9) - -extern void __iomem *smtc_regbaseaddress; -#define smtc_mmiowb(dat, reg) writeb(dat, smtc_regbaseaddress + reg) - -#define smtc_mmiorb(reg) readb(smtc_regbaseaddress + reg) - -#define SIZE_SR00_SR04 (0x04 - 0x00 + 1) -#define SIZE_SR10_SR24 (0x24 - 0x10 + 1) -#define SIZE_SR30_SR75 (0x75 - 0x30 + 1) -#define SIZE_SR80_SR93 (0x93 - 0x80 + 1) -#define SIZE_SRA0_SRAF (0xAF - 0xA0 + 1) -#define SIZE_GR00_GR08 (0x08 - 0x00 + 1) -#define SIZE_AR00_AR14 (0x14 - 0x00 + 1)
Re: [PATCH 2/2] ASoC: rockchip: Add machine driver for rt5645/rt5650 codec
Hi Mark, On 2015年07月18日 02:11, Mark Brown wrote: On Wed, Jul 15, 2015 at 11:15:43AM +0800, Xing Zheng wrote: From: zhengxing The driver is used for rockchip board using a rt5645/rt5650. Same comments here, mostly good but some minor issues. The other thing with both of these is that you need to have a binding document for them. OK. 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 1/2] ASoC: rockchip: Add machine driver for max98090 codec
On 2015年07月18日 02:04, Mark Brown wrote:
On Wed, Jul 15, 2015 at 11:15:42AM +0800, Xing Zheng wrote:
This looks pretty good, a couple of minor points below which should be
quick to fix.
+static int rk_init(struct snd_soc_pcm_runtime *runtime)
+{
+ struct snd_soc_card *card = runtime->card;
+
+ card->dapm.idle_bias_off = true;
You shouldn't need to do this? If you do need to do it we should make
it possible to do it from the card struct.
Done, we don't need it in the machine driver.
+ ret = snd_soc_register_card(card);
+ if (ret) {
+ pr_err("snd_soc_register_card failed %d\n", ret);
+ return ret;
+ }
+
+ ret = snd_soc_of_parse_card_name(card, "rockchip,model");
+ if (ret)
+ return ret;
This should be devm_snd_soc_register_card() and you need to parse the
card name before registering it, otherwise the card might instantiate
before the name is set.
Done.
+static int snd_rk_mc_remove(struct platform_device *pdev)
+{
+ struct snd_soc_card *soc_card = platform_get_drvdata(pdev);
+
+ snd_soc_card_set_drvdata(soc_card, NULL);
+ snd_soc_unregister_card(soc_card);
+ platform_set_drvdata(pdev, NULL);
No need for any of the _set_drvdata() calls, the core does them and they
shouldn't make any difference anyway.
Done. I will remove *_set_drvdata and *get_drvdata because we don't need
them any more.
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: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in aesni-intel_asm.S
On Sat, Jul 18, 2015 at 04:51:16AM +0200, Ingo Molnar wrote: > Note what the names _don't_ contain: that we generate debug info! That fact > is not > present in the naming, and that's very much intentional, because the precise > form > of debug info is conditional: > > - if CONFIG_FRAME_POINTERS=y then we push/pop a stack frame > > - if (later on) we do CFI annotations we don't push/pop a stack frame but > emit > CFI debuginfo According to current plan, the macro won't add CFI annotations. That will be done instead by a separate tool. So the macro really is frame pointer specific. > > In that sense 'FRAME' should never be in these names I think, nor 'PROC' > (which is > not symmetric). > > Plus all 3 variants I suggested are very easy to remember, why I'd always > have to > look up any non-symmetric macro name called 'PROC'... The reason I suggested to put FRAME in the macro name is to try to prevent it from being accidentally used for leaf functions, where it isn't needed. Also the naming of FUNCTION_ENTRY and FUNCTION_RETURN doesn't do anything to distinguish them from the already ubiquitous ENTRY and ENDPROC. So as a kernel developer it seems confusing to me, e.g. how do I remember when to use FUNCTION_ENTRY vs ENTRY? -- Josh -- 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 12/21] sched: Add __schedule() to stackvalidate whitelist
* Andy Lutomirski wrote:
> On Fri, Jul 17, 2015 at 12:46 PM, Peter Zijlstra wrote:
> > On Fri, Jul 17, 2015 at 11:47:28AM -0500, Josh Poimboeuf wrote:
> >> stackvalidate reports the following warnings for __schedule():
> >>
> >> stackvalidate: kernel/sched/core.o: __schedule()+0x3e7: duplicate frame
> >> pointer save
> >> stackvalidate: kernel/sched/core.o: __schedule()+0x424: sibling call
> >> from callable instruction with changed frame pointer
> >> stackvalidate: kernel/sched/core.o: __schedule()+0x431: call without
> >> frame pointer save/setup
> >> stackvalidate: kernel/sched/core.o: __schedule()+0x8b8: frame pointer
> >> state mismatch
> >> stackvalidate: kernel/sched/core.o: __schedule()+0x447: frame pointer
> >> state mismatch
> >>
> >> __schedule() is obviously a special case which is allowed to do unusual
> >> things with the frame pointer.
> >
> > Yes, but is the code actually correct? We can't dismiss the warnings
> > just on that basis alone.
>
> It's really only __switch_to that does weird things, right? I kinda
> want to rework that thing anyway to have a well-defined saved state
> format anyway, which would have the nice benefit of letting us get rid
> of all the ret_from_fork crap.
>
> That is, we'd context switch like:
>
> static inline void __switch_to(...) {
> switch extra stuff;
> switch everything except gpregs;
> asm volatile ("call __switch_stack_and_ip" : [__sp thing goes here]
> : "S" (>bottom_of_stack), "D" (>bottom_of_stack) :
> "basically all regs and flags");
> }
>
> Then the low level bit would be:
>
> __switch_stack_and_ip:
> pushq %rbp
> mov %rsp, (%rsi)
> mov (%rdi), %rsp
> popq %rbp
> ret
>
> Now, when we create a new task, we can set up its stack directly
> rather than setting some TI flag, because we actually know the layout.
>
> Hmm?
Sounds good to me!
Thanks,
Ingo
--
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/2] dma: rename write-combine APIs with short form
* Luis R. Rodriguez wrote: > On Thu, Jul 09, 2015 at 06:34:22PM -0700, Luis R. Rodriguez wrote: > > From: "Luis R. Rodriguez" > > > > Ingo, > > > > You had asked for this to be kept in my tree until the end of the > > merge window. I sent it a bit earlier than the end of the merge window, > > it failed to apply to Boris' tree as my series was based on linux-next > > and then I went on a small vacation. Boris is now on vacation as well. > > I've respinned this series today -- and fortunatley both of the patches > > in this series apply to both Linus' tree and linux-next, I am in hopes > > it applies to any other tree as well without conflicts. If not it should > > be easy to respin with the Coccinelle SmPL rule defined. > > > > I'll note that there are a few outstanding series related to MTRR, but > > those do not have conflicts with these patches at all so feel free > > to consider these before or after. Also I tried to get an ack for the > > first patch [1] but that has gone under the radar I believe so > > merging it now as part of this series and Cc'ing the maintainers. > > That change is needed in order to make the code match the grammar > > used by Coccinelle used in the expressed transformation. > > > > [0] http://lkml.kernel.org/r/20150601085332.ga14...@gmail.com > > [1] > > http://lkml.kernel.org/r/1434483609-25498-1-git-send-email-mcg...@do-not-panic.com > > > > Luis R. Rodriguez (2): > > drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style > > dma: rename dma_*_writecombine() to dma_*_wc() > > This series requires some adjustments based on linux-next. Do we accept > renames > on -rcs? If so should I respin? If its too late for v4.2 I can try to shoot > for > v4.3 but timing sending this at the right exact time seems a bit hard so any > advice for that is highly appreciated. Could you please also add the old API names as aliases, so that we won't break the build if some driver bleeds in the old API use via linux-next? Then we can remove the old APIs in a kernel cycle or two. It doesn't look too bad so I'll apply this (for v4.3) once you've done that and will carry it. Thanks, Ingo -- 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, fpu: dynamically allocate 'struct fpu'
* H. Peter Anvin wrote: > On 07/16/2015 12:14 PM, Dave Hansen wrote: > > The FPU rewrite removed the dynamic allocations of 'struct fpu'. > > But, this potentially wastes massive amounts of memory (2k per > > task on systems that do not have AVX-512 for instance). > > > > Instead of having a separate slab, this patch just appends the > > space that we need to the 'task_struct' which we dynamically > > allocate already. This saves from doing an extra slab allocation > > at fork(). The only real downside here is that we have to stick > > everything and the end of the task_struct. But, I think the > > BUILD_BUG_ON()s I stuck in there should keep that from being too > > fragile. > > > > This survives a quick build and boot in a VM. Does anyone see any > > real downsides to this? > > No. I have also long advocated for merging task_struct and thread_info into > a > common structure and get it off the stack; it would improve security and > avoid > weird corner cases in the irqstack handling. Note that we have 3 related 'task state' data structures with overlapping purpose: task_struct thread_struct thread_info where thread_struct is embedded in task_struct currently. So to turn it all into a single structure we'd have to merge thread_info into thread_struct. thread_info was put on the kernel stack due to the ESP trick we played long ago - but that is moot these days. So I think what we want is not some common structure, but to actually merge all of thread_info into thread_struct for arch details and into task_struct for generic fields, and only have: task_struct/* generic fields */ thread_struct /* arch details */ this can be done gradually, field by field, and in the end thread_info can be eliminated altogether. The only real complication is that it affects every architecture. The good news is that most of the thread_info layout details are wrapped in various constructs like test_ti_thread_flag() and task_thread_info(). While at it we might as well rename 'thread_struct' to 'arch_task_struct': task_struct /* generic fields */ arch_task_struct /* arch details */ to make it really clear and easy to understand at a glance - as the current naming is has become ambiguous and slightly confusing the moment we introduced threading. Thanks, Ingo -- 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/
[tip:x86/urgent] x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86
Commit-ID: 5aaeb5c01c5b6c0be7b7aadbf3ace9f3a4458c3d
Gitweb: http://git.kernel.org/tip/5aaeb5c01c5b6c0be7b7aadbf3ace9f3a4458c3d
Author: Ingo Molnar
AuthorDate: Fri, 17 Jul 2015 12:28:12 +0200
Committer: Ingo Molnar
CommitDate: Sat, 18 Jul 2015 03:42:51 +0200
x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on
x86
Don't burden architectures without dynamic task_struct sizing
with the overhead of dynamic sizing.
Also optimize the x86 code a bit by caching task_struct_size.
Acked-and-Tested-by: Dave Hansen
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1437128892-9831-3-git-send-email-mi...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/Kconfig | 4
arch/x86/Kconfig | 1 +
arch/x86/kernel/fpu/init.c | 17 +
arch/x86/kernel/process.c | 2 +-
fs/proc/kcore.c| 4 ++--
include/linux/sched.h | 6 +-
kernel/fork.c | 11 +--
7 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index bec..8a8ea71 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -221,6 +221,10 @@ config ARCH_TASK_STRUCT_ALLOCATOR
config ARCH_THREAD_INFO_ALLOCATOR
bool
+# Select if arch wants to size task_struct dynamically via
arch_task_struct_size:
+config ARCH_WANTS_DYNAMIC_TASK_STRUCT
+ bool
+
config HAVE_REGS_AND_STACK_ACCESS_API
bool
help
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3dbb7e7..b3a1a5d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -41,6 +41,7 @@ config X86
select ARCH_USE_CMPXCHG_LOCKREF if X86_64
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
+ select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_WANT_FRAME_POINTERS
select ARCH_WANT_IPC_PARSE_VERSION if X86_32
select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index deacbfa..0b39173 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -4,6 +4,8 @@
#include
#include
+#include
+
/*
* Initialize the TS bit in CR0 according to the style of context-switches
* we are using:
@@ -136,16 +138,14 @@ static void __init fpu__init_system_generic(void)
unsigned int xstate_size;
EXPORT_SYMBOL_GPL(xstate_size);
-#define CHECK_MEMBER_AT_END_OF(TYPE, MEMBER) \
- BUILD_BUG_ON((sizeof(TYPE) -\
- offsetof(TYPE, MEMBER) -\
- sizeof(((TYPE *)0)->MEMBER)) > \
- 0) \
+/* Enforce that 'MEMBER' is the last field of 'TYPE': */
+#define CHECK_MEMBER_AT_END_OF(TYPE, MEMBER) \
+ BUILD_BUG_ON(sizeof(TYPE) != offsetofend(TYPE, MEMBER))
/*
- * We append the 'struct fpu' to the task_struct.
+ * We append the 'struct fpu' to the task_struct:
*/
-int __weak arch_task_struct_size(void)
+static void __init fpu__init_task_struct_size(void)
{
int task_size = sizeof(struct task_struct);
@@ -172,7 +172,7 @@ int __weak arch_task_struct_size(void)
CHECK_MEMBER_AT_END_OF(struct thread_struct, fpu);
CHECK_MEMBER_AT_END_OF(struct task_struct, thread);
- return task_size;
+ arch_task_struct_size = task_size;
}
/*
@@ -326,6 +326,7 @@ void __init fpu__init_system(struct cpuinfo_x86 *c)
fpu__init_system_generic();
fpu__init_system_xstate_size_legacy();
fpu__init_system_xstate();
+ fpu__init_task_struct_size();
fpu__init_system_ctx_switch();
}
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 975420e..397688b 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -81,7 +81,7 @@ EXPORT_SYMBOL_GPL(idle_notifier_unregister);
*/
int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
{
- memcpy(dst, src, arch_task_struct_size());
+ memcpy(dst, src, arch_task_struct_size);
return fpu__copy(>thread.fpu, >thread.fpu);
}
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index a0fe994..92e6726 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -92,7 +92,7 @@ static size_t get_kcore_size(int *nphdr, size_t *elf_buflen)
roundup(sizeof(CORE_STR), 4)) +
roundup(sizeof(struct elf_prstatus), 4) +
roundup(sizeof(struct elf_prpsinfo), 4) +
- roundup(arch_task_struct_size(), 4);
+ roundup(arch_task_struct_size, 4);
*elf_buflen = PAGE_ALIGN(*elf_buflen);
return size + *elf_buflen;
}
@@ -415,7 +415,7 @@ static void elf_kcore_store_hdr(char *bufp, int nphdr, int
dataoff)
/* set up the task structure */
notes[2].name = CORE_STR;
[tip:x86/urgent] x86/fpu, sched: Dynamically allocate 'struct fpu '
Commit-ID: 0c8c0f03e3a292e031596484275c14cf39c0ab7a
Gitweb: http://git.kernel.org/tip/0c8c0f03e3a292e031596484275c14cf39c0ab7a
Author: Dave Hansen
AuthorDate: Fri, 17 Jul 2015 12:28:11 +0200
Committer: Ingo Molnar
CommitDate: Sat, 18 Jul 2015 03:42:35 +0200
x86/fpu, sched: Dynamically allocate 'struct fpu'
The FPU rewrite removed the dynamic allocations of 'struct fpu'.
But, this potentially wastes massive amounts of memory (2k per
task on systems that do not have AVX-512 for instance).
Instead of having a separate slab, this patch just appends the
space that we need to the 'task_struct' which we dynamically
allocate already. This saves from doing an extra slab
allocation at fork().
The only real downside here is that we have to stick everything
and the end of the task_struct. But, I think the
BUILD_BUG_ON()s I stuck in there should keep that from being too
fragile.
Signed-off-by: Dave Hansen
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1437128892-9831-2-git-send-email-mi...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/fpu/types.h | 72 +---
arch/x86/include/asm/processor.h | 10 --
arch/x86/kernel/fpu/init.c | 39 ++
arch/x86/kernel/process.c| 2 +-
fs/proc/kcore.c | 4 +--
include/linux/sched.h| 12 +--
kernel/fork.c| 8 -
7 files changed, 104 insertions(+), 43 deletions(-)
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 0637826..c49c517 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -189,6 +189,7 @@ union fpregs_state {
struct fxregs_state fxsave;
struct swregs_state soft;
struct xregs_state xsave;
+ u8 __padding[PAGE_SIZE];
};
/*
@@ -198,40 +199,6 @@ union fpregs_state {
*/
struct fpu {
/*
-* @state:
-*
-* In-memory copy of all FPU registers that we save/restore
-* over context switches. If the task is using the FPU then
-* the registers in the FPU are more recent than this state
-* copy. If the task context-switches away then they get
-* saved here and represent the FPU state.
-*
-* After context switches there may be a (short) time period
-* during which the in-FPU hardware registers are unchanged
-* and still perfectly match this state, if the tasks
-* scheduled afterwards are not using the FPU.
-*
-* This is the 'lazy restore' window of optimization, which
-* we track though 'fpu_fpregs_owner_ctx' and 'fpu->last_cpu'.
-*
-* We detect whether a subsequent task uses the FPU via setting
-* CR0::TS to 1, which causes any FPU use to raise a #NM fault.
-*
-* During this window, if the task gets scheduled again, we
-* might be able to skip having to do a restore from this
-* memory buffer to the hardware registers - at the cost of
-* incurring the overhead of #NM fault traps.
-*
-* Note that on modern CPUs that support the XSAVEOPT (or other
-* optimized XSAVE instructions), we don't use #NM traps anymore,
-* as the hardware can track whether FPU registers need saving
-* or not. On such CPUs we activate the non-lazy ('eagerfpu')
-* logic, which unconditionally saves/restores all FPU state
-* across context switches. (if FPU state exists.)
-*/
- union fpregs_state state;
-
- /*
* @last_cpu:
*
* Records the last CPU on which this context was loaded into
@@ -288,6 +255,43 @@ struct fpu {
* deal with bursty apps that only use the FPU for a short time:
*/
unsigned char counter;
+ /*
+* @state:
+*
+* In-memory copy of all FPU registers that we save/restore
+* over context switches. If the task is using the FPU then
+* the registers in the FPU are more recent than this state
+* copy. If the task context-switches away then they get
+* saved here and represent the FPU state.
+*
+* After context switches there may be a (short) time period
+* during which the in-FPU hardware registers are unchanged
+* and still perfectly match this state, if the tasks
+* scheduled afterwards are not using the FPU.
+*
+* This is the 'lazy restore' window of optimization, which
+* we track though 'fpu_fpregs_owner_ctx' and 'fpu->last_cpu'.
+*
+* We detect whether a subsequent task uses the FPU via setting
+* CR0::TS to 1, which causes any
[tip:x86/asm] x86/entry: Fix _TIF_USER_RETURN_NOTIFY check in prepare_exit_to_usermode
Commit-ID: d132803e6c611d50c19baedc8ae520203a2baca7
Gitweb: http://git.kernel.org/tip/d132803e6c611d50c19baedc8ae520203a2baca7
Author: Andy Lutomirski
AuthorDate: Wed, 15 Jul 2015 14:25:16 -0700
Committer: Ingo Molnar
CommitDate: Fri, 17 Jul 2015 16:08:22 +0200
x86/entry: Fix _TIF_USER_RETURN_NOTIFY check in prepare_exit_to_usermode
Linus noticed that the early return check was missing
_TIF_USER_RETURN_NOTIFY. If the only work flag was
_TIF_USER_RETURN_NOTIFY, we'd skip user return notifiers. Fix
it. (This is the only missing bit.)
This fixes double faults on a KVM host. It's the same issue as
last time, except that this time it's very easy to trigger.
Apparently no one uses -next as a KVM host.
( I'm still not quite sure what it is that KVM does that blows up
so badly if we miss a user return notifier. My best guess is that KVM
lets KERNEL_GS_BASE (i.e. the user's gs base) be negative and fixes
it up in a user return notifier. If we actually end up in user mode
with a negative gs base, we blow up pretty badly. )
Reported-by: Linus Torvalds
Signed-off-by: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: c5c46f59e4e7 ("x86/entry: Add new, comprehensible entry and exit
handlers written in C")
Link:
http://lkml.kernel.org/r/3f801104d24ee7a6bb1446408d9950777aa63277.1436995419.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/entry/common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index febc530..a3e9c7f 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -264,7 +264,8 @@ __visible void prepare_exit_to_usermode(struct pt_regs
*regs)
READ_ONCE(pt_regs_to_thread_info(regs)->flags);
if (!(cached_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME |
- _TIF_UPROBE | _TIF_NEED_RESCHED)))
+ _TIF_UPROBE | _TIF_NEED_RESCHED |
+ _TIF_USER_RETURN_NOTIFY)))
break;
/* We have work to do. */
--
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/
[tip:perf/urgent] perf tools: Really allow to specify custom CC, AR or LD
Commit-ID: 3c71ba3f80bbd476bbfb2a008da9b676031cbd32
Gitweb: http://git.kernel.org/tip/3c71ba3f80bbd476bbfb2a008da9b676031cbd32
Author: Alexey Brodkin
AuthorDate: Tue, 14 Jul 2015 12:05:20 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Jul 2015 11:57:28 -0300
perf tools: Really allow to specify custom CC, AR or LD
Commit 5ef7bbb09f7b ("perf tools: Allow to specify custom linker
command") was meant to enable usage non $(CROSS_COMPILE)ld linker during
perf building.
But implementation didn't take into account the fact that LD is a
pre-defined variable in GNU Make. I.e. it is always defined.
Which means there's no point to check "LD ?= ..." because it will never
succeed.
And so LD will be either that explicitly passed to make like this:
--->8---
make LD=path_to_my_ld ...
--->8---
or default value, which is host's "ld".
Latter leads to failure of cross-linkage because instead of cross linker
"$(CROSS_COMPILE)ld" host's "ld" is used.
Fortunately there's a way to do correct substitution of $(CROSS_COMPILE)ld
with user defined LD on command-line.
As a reference was used implementation in "tools/lib/traceevent/Makefile".
Build tested for x86_64 and ARC.
Thanks Jiri for this hint.
Signed-off-by: Alexey Brodkin
Fixes: 5ef7bbb09f7b ("perf tools: Allow to specify custom linker command")
Cc: Aaro Koskinen
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Vineet Gupta
Cc: Vineet Gupta
Cc: linux-a...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1436864720-26316-1-git-send-email-abrod...@synopsys.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Makefile.perf | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 7a4b549..bba3463 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -109,9 +109,22 @@ $(OUTPUT)PERF-VERSION-FILE: ../../.git/HEAD
$(Q)$(SHELL_PATH) util/PERF-VERSION-GEN $(OUTPUT)
$(Q)touch $(OUTPUT)PERF-VERSION-FILE
-CC = $(CROSS_COMPILE)gcc
-LD ?= $(CROSS_COMPILE)ld
-AR = $(CROSS_COMPILE)ar
+# Makefiles suck: This macro sets a default value of $(2) for the
+# variable named by $(1), unless the variable has been set by
+# environment or command line. This is necessary for CC and AR
+# because make sets default values, so the simpler ?= approach
+# won't work as expected.
+define allow-override
+ $(if $(or $(findstring environment,$(origin $(1))),\
+$(findstring command line,$(origin $(1,,\
+$(eval $(1) = $(2)))
+endef
+
+# Allow setting CC and AR and LD, or setting CROSS_COMPILE as a prefix.
+$(call allow-override,CC,$(CROSS_COMPILE)gcc)
+$(call allow-override,AR,$(CROSS_COMPILE)ar)
+$(call allow-override,LD,$(CROSS_COMPILE)ld)
+
PKG_CONFIG = $(CROSS_COMPILE)pkg-config
RM = rm -f
--
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/
[tip:perf/urgent] perf auxtrace: Fix misplaced check for HAVE_SYNC_COMPARE_AND_SWAP_SUPPORT
Commit-ID: a7fde09a78a8ae40b81cfb5096c3cefef6c078c9
Gitweb: http://git.kernel.org/tip/a7fde09a78a8ae40b81cfb5096c3cefef6c078c9
Author: Adrian Hunter
AuthorDate: Tue, 14 Jul 2015 15:32:41 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Jul 2015 11:57:28 -0300
perf auxtrace: Fix misplaced check for HAVE_SYNC_COMPARE_AND_SWAP_SUPPORT
Move the checking for HAVE_SYNC_COMPARE_AND_SWAP_SUPPORT for AUX area mmaps
until after checking if such mmaps are used anyway.
Reported-by: Alexey Brodkin
Signed-off-by: Adrian Hunter
Tested-by: Alexey Brodkin
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Vineet Gupta
Cc: linux-a...@vger.kernel.org
Link: http://lkml.kernel.org/r/55a5023c.7020...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/auxtrace.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index 7e7405c..83d9dd9 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -53,11 +53,6 @@ int auxtrace_mmap__mmap(struct auxtrace_mmap *mm,
{
struct perf_event_mmap_page *pc = userpg;
-#if BITS_PER_LONG != 64 && !defined(HAVE_SYNC_COMPARE_AND_SWAP_SUPPORT)
- pr_err("Cannot use AUX area tracing mmaps\n");
- return -1;
-#endif
-
WARN_ONCE(mm->base, "Uninitialized auxtrace_mmap\n");
mm->userpg = userpg;
@@ -73,6 +68,11 @@ int auxtrace_mmap__mmap(struct auxtrace_mmap *mm,
return 0;
}
+#if BITS_PER_LONG != 64 && !defined(HAVE_SYNC_COMPARE_AND_SWAP_SUPPORT)
+ pr_err("Cannot use AUX area tracing mmaps\n");
+ return -1;
+#endif
+
pc->aux_offset = mp->offset;
pc->aux_size = mp->len;
--
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 RFC 0/4] change sb_writers to use percpu_rw_semaphore
On Fri, Jul 17, 2015 at 07:31:17PM +0200, Oleg Nesterov wrote: > On 07/17, Dave Chinner wrote: > > > > On Thu, Jul 16, 2015 at 07:32:56PM +0200, Oleg Nesterov wrote: > > > > > > #ifdef CONFIG_LOCKDEP > > > /* > > >* We want lockdep to tell us about possible deadlocks with > > > freezing but > > >* it's it bit tricky to properly instrument it. Getting a > > > freeze protection > > >* works as getting a read lock but there are subtle problems. > > > XFS for example > > >* gets freeze protection on internal level twice in some > > > cases, which is OK > > > > Sorry, I've missed something here - where is XFS nesting > > sb_start_intwrite() calls? > > Heh ;) I too tried to understand thi but failed. I was not surprized, > I know nothing about fs/. > > Dave, I didn't write this comment. Please look at acquire_freeze_lock(). > If we can remove this logic - great! but this needs a separate change. Oh, I think I know what it was - when we duplicate a transaction for a rolling commit, we do it before committing the current transaction is committed. I *think* that used to take a second freeze reference, which only existed until the first transaction was committed. We do things a bit differently now - we hold a state flag on the transaction to indicate it needs to release the freeze reference when it is freed and we pass it to the new transaction so that the first transaction commit doesn't release it. So, yes, it may well be a stale comment now. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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/
[GIT PULL] x86 fixes
Linus, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: 5aaeb5c01c5b6c0be7b7aadbf3ace9f3a4458c3d x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86 Two families of fixes: - Fix an FPU context related boot crash on newer x86 hardware with larger context sizes than what most people test. To fix this without ugly kludges or extensive reverts we had to touch core task allocator, to allow x86 to determine the task size dynamically, at boot time. I've tested it on a number of x86 platforms, and I cross-built it to a handful of architectures: (warns) (warns) testing x86-64: -git: pass (0), -tip: pass (0) testing x86-32: -git: pass (0), -tip: pass (0) testingarm: -git: pass ( 1359), -tip: pass ( 1359) testing cris: -git: pass ( 1031), -tip: pass ( 1031) testing m32r: -git: pass ( 1135), -tip: pass ( 1135) testing m68k: -git: pass ( 1471), -tip: pass ( 1471) testing mips: -git: pass ( 1162), -tip: pass ( 1162) testingmn10300: -git: pass ( 1058), -tip: pass ( 1058) testing parisc: -git: pass ( 1846), -tip: pass ( 1846) testing sparc: -git: pass ( 1185), -tip: pass ( 1185) ... so I hope the cross-arch impact 'none', as intended. (by Dave Hansen) - Fix various NMI handling related bugs unearthed by the big asm code rewrite and generally make the NMI code more robust and more maintainable while at it. These changes are a bit late in the cycle, I hope they are still acceptable. (by Andy Lutomirski) out-of-topic modifications in x86-urgent-for-linus: - arch/Kconfig # 5aaeb5c01c5b: x86/fpu, sched: Introduce CO fs/proc/kcore.c# 5aaeb5c01c5b: x86/fpu, sched: Introduce CO kernel/fork.c # 0c8c0f03e3a2: x86/fpu, sched: Dynamically Thanks, Ingo --> Andy Lutomirski (9): x86/nmi: Enable nested do_nmi() handling for 64-bit kernels x86/nmi/64: Remove asm code that saves CR2 x86/nmi/64: Switch stacks on userspace NMI entry x86/nmi/64: Improve nested NMI comments x86/nmi/64: Reorder nested NMI checks x86/nmi/64: Use DF to avoid userspace RSP confusing nested NMI detection x86/nmi/64: Minor asm simplification x86/nmi/64: Make the "NMI executing" variable more consistent x86/entry/64, x86/nmi/64: Add CONFIG_DEBUG_ENTRY NMI testing code Dave Hansen (1): x86/fpu, sched: Dynamically allocate 'struct fpu' Ingo Molnar (1): x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86 arch/Kconfig | 4 + arch/x86/Kconfig | 1 + arch/x86/Kconfig.debug | 12 ++ arch/x86/entry/entry_64.S| 299 ++- arch/x86/include/asm/fpu/types.h | 72 +- arch/x86/include/asm/processor.h | 10 +- arch/x86/kernel/fpu/init.c | 40 ++ arch/x86/kernel/nmi.c| 123 +++- arch/x86/kernel/process.c| 2 +- fs/proc/kcore.c | 4 +- include/linux/sched.h| 16 ++- kernel/fork.c| 7 +- 12 files changed, 376 insertions(+), 214 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index beca3cc4..8a8ea7110de8 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -221,6 +221,10 @@ config ARCH_TASK_STRUCT_ALLOCATOR config ARCH_THREAD_INFO_ALLOCATOR bool +# Select if arch wants to size task_struct dynamically via arch_task_struct_size: +config ARCH_WANTS_DYNAMIC_TASK_STRUCT + bool + config HAVE_REGS_AND_STACK_ACCESS_API bool help diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 3dbb7e7909ca..b3a1a5d77d92 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -41,6 +41,7 @@ config X86 select ARCH_USE_CMPXCHG_LOCKREF if X86_64 select ARCH_USE_QUEUED_RWLOCKS select ARCH_USE_QUEUED_SPINLOCKS + select ARCH_WANTS_DYNAMIC_TASK_STRUCT select ARCH_WANT_FRAME_POINTERS select ARCH_WANT_IPC_PARSE_VERSION if X86_32 select ARCH_WANT_OPTIONAL_GPIOLIB diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index a15893d17c55..d8c0d3266173 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -297,6 +297,18 @@ config OPTIMIZE_INLINING If unsure, say N. +config DEBUG_ENTRY + bool "Debug low-level entry code" + depends on DEBUG_KERNEL + ---help--- + This option enables sanity checks in x86's low-level entry code. + Some of these sanity checks
[GIT PULL] timer fix
Linus, Please pull the latest timers-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus # HEAD: 0f44705175347ec96935d60b765b5d14ecc763bb tick: Move the export of tick_broadcast_oneshot_control to the proper place Fix for a misplaced export that can cause build failures in certain (rare) Kconfig situations. Thanks, Ingo --> Thomas Gleixner (1): tick: Move the export of tick_broadcast_oneshot_control to the proper place kernel/time/tick-broadcast.c | 1 - kernel/time/tick-common.c| 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c index 52b9e199b5ac..f6aae7977824 100644 --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@ -839,7 +839,6 @@ int __tick_broadcast_oneshot_control(enum tick_broadcast_state state) raw_spin_unlock(_broadcast_lock); return ret; } -EXPORT_SYMBOL_GPL(tick_broadcast_oneshot_control); /* * Reset the one shot broadcast for a cpu diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index 55e13efff1ab..f8bf47571dda 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -363,6 +363,7 @@ int tick_broadcast_oneshot_control(enum tick_broadcast_state state) return __tick_broadcast_oneshot_control(state); } +EXPORT_SYMBOL_GPL(tick_broadcast_oneshot_control); #ifdef CONFIG_HOTPLUG_CPU /* -- 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 00/21] x86: Proposed fixes for stackvalidate warnings
* Andy Lutomirski wrote: > On Fri, Jul 17, 2015 at 9:47 AM, Josh Poimboeuf wrote: > > These patches fix many of the warnings reported by stackvalidate. > > They're based on top of the "Compile-time stack validation" v7 patch set > > [1]. > > > > They've been compile-tested and boot tested in a VM, but I haven't > > attempted any meaningful testing for most of them. This should give an > > idea of what kinds of changes I think are needed. > > > > [1] https://lkml.kernel.org/r/cover.1436893563.git.jpoim...@redhat.com > > > > Nothing here looks all that bad, but I think the extra frame pointers > staring us in the face (as opposed to the ones that gcc adds > transparently) might serve as added incentive to suck it up and get > CFI unwinding working. So there are two aspects to frame pointers staring us in the face: - Syntactically there's extra debuginfo cruft added to the source code. Not good but very fixable: I already made a couple of suggestions of how to trim all that in a way that improves general readability as well over what we have today. - Instruction wise in the generated code. I'm afraid the 'transparent' frame pointers added by GCC are staring me in the face in perf top/report disassembly output just as much! ;-) But naming details aside, I like the direction of these patches a lot better than that of any previous debuginfo approach, because the approach is very proactive. ( Which it really has to be, given that deep down these patches are motivated by enabling more complex models of live kernel patching. But that's a win-win. ) Once the cleanliness of the annotations is improved and we have a reasonable path towards having no warnings on a regular kernel build, I plan on starting to apply the patches. So if anyone has any deep objections that were kept close to the vest so far, please holler now. Thanks, Ingo -- 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/
[GIT PULL] scheduler fix
Linus, Please pull the latest sched-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-urgent-for-linus # HEAD: d49db342f0e276b354383b3281c5668b6b80f5c2 sched/fair: Test list head instead of list entry in throttle_cfs_rq() A rq throttling fix. Thanks, Ingo --> Cong Wang (1): sched/fair: Test list head instead of list entry in throttle_cfs_rq() kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 65c8f3ebdc3c..d113c3ba8bc4 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3683,7 +3683,7 @@ static void throttle_cfs_rq(struct cfs_rq *cfs_rq) cfs_rq->throttled = 1; cfs_rq->throttled_clock = rq_clock(rq); raw_spin_lock(_b->lock); - empty = list_empty(_rq->throttled_list); + empty = list_empty(_b->throttled_cfs_rq); /* * Add to the _head_ of the list, so that an already-started -- 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/
[GIT PULL] perf fixes
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: a6acd6a41168dc304738e84c8360cda9a6b86887 Merge tag
'perf-urgent-for-mingo' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
Mostly tooling fixes, plus a static key fix fixing /sys/devices/cpu/rdpmc.
Thanks,
Ingo
-->
Adrian Hunter (2):
perf tools: Fix lockup using 32-bit compat vdso
perf auxtrace: Fix misplaced check for HAVE_SYNC_COMPARE_AND_SWAP_SUPPORT
Alexey Brodkin (1):
perf tools: Really allow to specify custom CC, AR or LD
Arnaldo Carvalho de Melo (5):
perf thread_map: Fix the sizeof() calculation for map entries
perf tools: Fix the detached tarball wrt rbtree copy
tools: Copy lib/hweight.c from the kernel sources
perf symbols: Store if there is a filter in place
perf hists browser: Take the --comm, --dsos, etc filters into account
Jiri Olsa (1):
perf stat: Fix shadow declaration of close
Peter Zijlstra (1):
x86, perf: Fix static_key bug in load_mm_cr4()
Riku Voipio (1):
tools lib: Improve clean target
arch/x86/include/asm/mmu_context.h | 2 +-
tools/lib/api/Makefile | 2 +-
tools/lib/hweight.c| 62 ++
tools/lib/traceevent/Makefile | 2 +-
tools/perf/MANIFEST| 2 +-
tools/perf/Makefile.perf | 19 ++--
tools/perf/builtin-stat.c | 4 +--
tools/perf/ui/browsers/hists.c | 2 +-
tools/perf/util/Build | 2 +-
tools/perf/util/auxtrace.c | 10 +++---
tools/perf/util/python-ext-sources | 4 +--
tools/perf/util/symbol.c | 2 ++
tools/perf/util/symbol.h | 3 +-
tools/perf/util/thread_map.c | 3 +-
tools/perf/util/vdso.c | 8 ++---
15 files changed, 101 insertions(+), 26 deletions(-)
create mode 100644 tools/lib/hweight.c
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index 5e8daee7c5c9..804a3a6030ca 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -23,7 +23,7 @@ extern struct static_key rdpmc_always_available;
static inline void load_mm_cr4(struct mm_struct *mm)
{
- if (static_key_true(_always_available) ||
+ if (static_key_false(_always_available) ||
atomic_read(>context.perf_rdpmc_allowed))
cr4_set_bits(X86_CR4_PCE);
else
diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile
index 8bd960658463..fe1b02c2c95b 100644
--- a/tools/lib/api/Makefile
+++ b/tools/lib/api/Makefile
@@ -36,7 +36,7 @@ $(LIBFILE): $(API_IN)
clean:
$(call QUIET_CLEAN, libapi) $(RM) $(LIBFILE); \
- find $(if $(OUTPUT),$(OUTPUT),.) -name \*.o | xargs $(RM)
+ find $(if $(OUTPUT),$(OUTPUT),.) -name \*.o -or -name \*.o.cmd -or
-name \*.o.d | xargs $(RM)
FORCE:
diff --git a/tools/lib/hweight.c b/tools/lib/hweight.c
new file mode 100644
index ..0b859b884339
--- /dev/null
+++ b/tools/lib/hweight.c
@@ -0,0 +1,62 @@
+#include
+#include
+
+/**
+ * hweightN - returns the hamming weight of a N-bit word
+ * @x: the word to weigh
+ *
+ * The Hamming Weight of a number is the total number of bits set in it.
+ */
+
+unsigned int __sw_hweight32(unsigned int w)
+{
+#ifdef CONFIG_ARCH_HAS_FAST_MULTIPLIER
+ w -= (w >> 1) & 0x;
+ w = (w & 0x) + ((w >> 2) & 0x);
+ w = (w + (w >> 4)) & 0x0f0f0f0f;
+ return (w * 0x01010101) >> 24;
+#else
+ unsigned int res = w - ((w >> 1) & 0x);
+ res = (res & 0x) + ((res >> 2) & 0x);
+ res = (res + (res >> 4)) & 0x0F0F0F0F;
+ res = res + (res >> 8);
+ return (res + (res >> 16)) & 0x00FF;
+#endif
+}
+
+unsigned int __sw_hweight16(unsigned int w)
+{
+ unsigned int res = w - ((w >> 1) & 0x);
+ res = (res & 0x) + ((res >> 2) & 0x);
+ res = (res + (res >> 4)) & 0x0F0F;
+ return (res + (res >> 8)) & 0x00FF;
+}
+
+unsigned int __sw_hweight8(unsigned int w)
+{
+ unsigned int res = w - ((w >> 1) & 0x55);
+ res = (res & 0x33) + ((res >> 2) & 0x33);
+ return (res + (res >> 4)) & 0x0F;
+}
+
+unsigned long __sw_hweight64(__u64 w)
+{
+#if BITS_PER_LONG == 32
+ return __sw_hweight32((unsigned int)(w >> 32)) +
+ __sw_hweight32((unsigned int)w);
+#elif BITS_PER_LONG == 64
+#ifdef CONFIG_ARCH_HAS_FAST_MULTIPLIER
+ w -= (w >> 1) & 0xul;
+ w = (w & 0xul) + ((w >> 2) & 0xul);
+ w = (w + (w >> 4)) & 0x0f0f0f0f0f0f0f0ful;
+ return (w * 0x0101010101010101ul) >> 56;
+#else
+ __u64 res = w - ((w >> 1) & 0xul);
+ res = (res & 0xul) + ((res >> 2) &
0xul);
+ res = (res + (res >> 4)) &
Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in aesni-intel_asm.S
* Josh Poimboeuf wrote: > On Fri, Jul 17, 2015 at 12:44:42PM -0700, Andy Lutomirski wrote: > > On Fri, Jul 17, 2015 at 12:43 PM, Ingo Molnar wrote: > > > > > > * Josh Poimboeuf wrote: > > > > > >> ENTRY(aesni_set_key) > > >> + FRAME > > >> #ifndef __x86_64__ > > >> pushl KEYP > > >> movl 8(%esp), KEYP # ctx > > >> @@ -1905,6 +1907,7 @@ ENTRY(aesni_set_key) > > >> #ifndef __x86_64__ > > >> popl KEYP > > >> #endif > > >> + ENDFRAME > > >> ret > > >> ENDPROC(aesni_set_key) > > > > > > So cannot we make this a bit more compact and less fragile? > > > > > > Instead of: > > > > > > ENTRY(aesni_set_key) > > > FRAME > > > ... > > > ENDFRAME > > > ret > > > ENDPROC(aesni_set_key) > > > > > > > > > How about writing this as: > > > > > > FUNCTION_ENTRY(aesni_set_key) > > > ... > > > FUNCTION_RETURN(aesni_set_key) > > > > > > which does the same thing in a short, symmetric construct? > > > > > > One potential problem with this approach would be that what 'looks' like > > > an entry > > > declaration, but it will now generate real code. > > > > > > OTOH if people find this intuitive enough then it's a lot harder to mess > > > it up, > > > and I think 'RETURN' makes it clear enough that there's a real instruction > > > generated there. > > > > > > > How about FUNCTION_PROLOGUE and FUNCTION_EPILOGUE? > > Perhaps the macro name should describe what the epilogue does, since > frame pointers aren't required for _all_ functions, only those which > don't have call instructions. > > What do you think about ENTRY_FRAME and ENDPROC_FRAME_RETURN? The > ending macro is kind of long, but at least it a) matches the existing > ENTRY/ENDPROC convention for asm functions; b) gives a clue that frame > pointers are involved; and c) lets you know that the return is there. So the thing I like about these: FUNCTION_ENTRY(aesni_set_key) ... FUNCTION_RETURN(aesni_set_key) is the symmetry - it's a lot harder to misplace/miswrite these than two completely separately named things: ENTRY_FRAME(aesni_set_key) ... ENDPROC_FRAME_RETURN(aesni_set_key) Also, the 'FRAME' part will be pointless and somewhat misleading once we do dwarves, right? Another valid variants would be: FUNCTION_ENTER(aesni_set_key) ... FUNCTION_RET(aesni_set_key) or: FUNCTION_START(aesni_set_key) ... FUNCTION_RET(aesni_set_key) or: ASM_FUNCTION_START(aesni_set_key) ... ASM_FUNCTION_RET(aesni_set_key) Note that the name has two parts: - The symmetric 'FUNCTION_' prefix tells us that this is a callable function that we are defining. That is a very significant property of this construct, and should be present in both the 'start' and the 'end' markers. - The '_RET' stresses the fact that it always generates a 'ret' instruction. Note what the names _don't_ contain: that we generate debug info! That fact is not present in the naming, and that's very much intentional, because the precise form of debug info is conditional: - if CONFIG_FRAME_POINTERS=y then we push/pop a stack frame - if (later on) we do CFI annotations we don't push/pop a stack frame but emit CFI debuginfo In that sense 'FRAME' should never be in these names I think, nor 'PROC' (which is not symmetric). Plus all 3 variants I suggested are very easy to remember, why I'd always have to look up any non-symmetric macro name called 'PROC'... Thanks, Ingo -- 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/
Letter of Intent.
I am David Wei .I am involved with the Guiyang Intellectual property bureau which is in the Guizhou province of mainland China. I am getting in touch with you regarding property investment that was facilitated by myself and my colleagues a few years ago. We had started this process with a gentleman by the name of Mr. Norman Gerr a while back but had to suspend same due to unfortunate events concerning Mr. Norman . I would respectfully request that you keep the contents of this mail confidential and respect the integrity of the information you come by as a result of this mail. I contact you independently and no one is informed of this communication. We contact you however because you share a similar surname with Norman, please get back to me once you get this letter regardless of being related to Mr. Norman in anyway as this can be very beneficial for all involved. I await your response. David Wei. david@asia.com -- 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-next: build failure after merge of the rcu tree
* Paul E. McKenney wrote:
> On Fri, Jul 17, 2015 at 09:51:31PM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney wrote:
> >
> > > And here is a prototype patch, which I intend to merge with the existing
> > > patch
> > > that renames rcu_lockdep_assert() to RCU_LOCKDEP_WARN(). I will also
> > > queue a
> > > revert of the patch below for 4.4.
> > >
> > > Thoughts?
> > >
> > > Thanx, Paul
> > >
> > >
> > >
> > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > index 41c49b12fe6d..663d6e028c3d 100644
> > > --- a/include/linux/rcupdate.h
> > > +++ b/include/linux/rcupdate.h
> > > @@ -536,9 +536,29 @@ static inline int rcu_read_lock_sched_held(void)
> > >
> > > #endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > >
> > > +/* Deprecate the rcu_lockdep_assert() macro. */
> > > +static inline void __attribute((deprecated))
> > > deprecate_rcu_lockdep_assert(void)
> > > +{
> > > +}
> > > +
> > > #ifdef CONFIG_PROVE_RCU
> > >
> > > /**
> > > + * rcu_lockdep_assert - emit lockdep splat if specified condition not met
> > > + * @c: condition to check
> > > + * @s: informative message
> > > + */
> > > +#define rcu_lockdep_assert(c, s) \
> > > + do {\
> > > + static bool __section(.data.unlikely) __warned; \
> > > + deprecate_rcu_lockdep_assert(); \
> > > + if (debug_lockdep_rcu_enabled() && !__warned && !(c)) { \
> > > + __warned = true;\
> > > + lockdep_rcu_suspicious(__FILE__, __LINE__, s); \
> > > + } \
> >
> > Btw., out of general macro paranoia I'd write such constructs as something
> > like:
> >
> > if (!(c) && debug_lockdep_rcu_enabled() && !__warned) { \
> >
> > I.e. always evaluate 'c' even if debugging is off. This way if the
> > construct is
> > fed an expression with a side effect (bad idea!) then it still works
> > regardless of
> > whether the warning triggered already or not.
>
> If you feel strongly about this, I will need to make lockdep_is_held()
> be defined when lockdep is disabled. [...]
No need - if it goes deeper then I wouldn't worry.
Thanks,
Ingo
--
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 v9 07/22] tracing: Add lock-free tracing_map
- On Jul 17, 2015, at 7:44 PM, Tom Zanussi tom.zanu...@linux.intel.com wrote: > On Fri, 2015-07-17 at 15:48 +, Mathieu Desnoyers wrote: >> - On Jul 16, 2015, at 9:35 PM, Tom Zanussi tom.zanu...@linux.intel.com >> wrote: >> >> > Hi Mathieu, >> > >> > On Thu, 2015-07-16 at 23:25 +, Mathieu Desnoyers wrote: >> >> * Tom Zanussi wrote: >> >> >> Add tracing_map, a special-purpose lock-free map for tracing. >> >> >> >> >> >> tracing_map is designed to aggregate or 'sum' one or more values >> >> >> associated with a specific object of type tracing_map_elt, which >> >> >> is associated by the map to a given key. >> >> >> >> >> >> It provides various hooks allowing per-tracer customization and is >> >> >> separated out into a separate file in order to allow it to be shared >> >> >> between multiple tracers, but isn't meant to be generally used outside >> >> >> of that context. >> >> >> >> >> >> The tracing_map implementation was inspired by lock-free map >> >> >> algorithms originated by Dr. Cliff Click: >> >> >> >> >> >> http://www.azulsystems.com/blog/cliff/2007-03-26-non-blocking-hashtable >> >> >> http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf >> >> >> >> Hi Tom, >> >> >> >> First question: what is the rationale for implementing another >> >> hash table from scratch here ? What is missing in the pre-existing >> >> hash table implementations ? >> >> >> > >> > None of the other hash tables allow for lock-free insertion (and I >> > didn't see an easy way to add it). >> >> This is one of the nice things about the Userspace RCU lock-free hash >> table we've done a few years ago: it provides lock-free add, add_unique, >> removal, and replace, as well as RCU wait-free lookups and traversals. >> Resize can be done concurrently by a worker thread. I ported it to the >> Linux kernel for Julien's work on latency tracker. You can find the >> implementation here: https://github.com/jdesfossez/latency_tracker >> (see rculfhash*) >> It is a simplified version that has the "resize" feature removed for >> simplicity sake. The "insert and lookup" feature you need is called >> "add_unique" in our API: it behaves both as a lookup and as an atomic >> insert if the key is not found. >> > > Interesting, but it's just as much not upstream as mine is. ;-) Fair point, although the userspace RCU lock-free hash table has been heavily tested and used in user-space in the context of routing tables (I remember Stephen Hemminger uses it at Vyatta). So being in userspace RCU library got it some exposure and use over years. > > From the perspective of the hist triggers, it doesn't matter what hash > table implementation it uses as long as whatever it is supports > insertion in any context. In fact the current tracing_map > implementation is already the second completely different implementation > it's plugged into (see v2 of this patchset for the first). If yours is > better and going upstream, I'd be happy to make it the third and forget > about mine. I'm a big fan of awaiting that people show a need before proposing something for Linux mainline. Having a lock-free hash table for the sake of tracing triggers appears to be the perfect use-case. If you think it can be useful to you, I can look into doing a proper port to the Linux kernel. Thanks, Mathieu > > Tom > >> Thanks, >> >> Mathieu >> >> > >> >> Moreover, you might want to handle the case where jhash() returns >> >> 0. AFAIU, there is a race on "insert" in this scenario. >> >> >> > >> > You're right, in that case you'd accidentally overwrite an already >> > claimed slot. Thanks for pointing that out. >> > >> > Tom >> > >> >> Thanks, >> >> >> >> Mathieu >> >> >> >> >> >> >> >> Signed-off-by: Tom Zanussi >> >> >> --- >> >> >> kernel/trace/Makefile | 1 + >> >> >> kernel/trace/tracing_map.c | 935 >> >> >> + >> >> >> kernel/trace/tracing_map.h | 258 + >> >> >> 3 files changed, 1194 insertions(+) >> >> >> create mode 100644 kernel/trace/tracing_map.c >> >> >> create mode 100644 kernel/trace/tracing_map.h >> >> >> >> >> >> diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile >> >> >> index 9b1044e..3b26cfb 100644 >> >> >> --- a/kernel/trace/Makefile >> >> >> +++ b/kernel/trace/Makefile >> >> >> @@ -31,6 +31,7 @@ obj-$(CONFIG_TRACING) += trace_output.o >> >> >> obj-$(CONFIG_TRACING) += trace_seq.o >> >> >> obj-$(CONFIG_TRACING) += trace_stat.o >> >> >> obj-$(CONFIG_TRACING) += trace_printk.o >> >> >> +obj-$(CONFIG_TRACING) += tracing_map.o >> >> >> obj-$(CONFIG_CONTEXT_SWITCH_TRACER) += trace_sched_switch.o >> >> >> obj-$(CONFIG_FUNCTION_TRACER) += trace_functions.o >> >> >> obj-$(CONFIG_IRQSOFF_TRACER) += trace_irqsoff.o >> >> >> diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c >> >> >> new file mode 100644 >> >> >> index 000..a505025 >> >> >> --- /dev/null >> >> >> +++ b/kernel/trace/tracing_map.c >> >> >> @@ -0,0 +1,935 @@ >>
[GIT PULL] irq fixes
Linus,
Please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
# HEAD: 591e5bec13f15feb13fc445b6c9c59954711c4ac irqchip/gicv3-its: Fix
mapping of LPIs to collections
Misc irq fixes:
- two driver fixes,
- a Xen regression fix,
- a nested irq thread crash fix.
Thanks,
Ingo
-->
Marc Zyngier (1):
irqchip/gicv3-its: Fix mapping of LPIs to collections
Thomas Gleixner (3):
gpio/davinci: Fix race in installing chained irq handler
genirq: Revert sparse irq locking around __cpu_up() and move it to x86
for now
genirq: Prevent resend to interrupts marked IRQ_NESTED_THREAD
arch/x86/kernel/smpboot.c| 11
drivers/gpio/gpio-davinci.c | 6 +--
drivers/irqchip/irq-gic-v3-its.c | 111 ++-
kernel/cpu.c | 9
kernel/irq/resend.c | 18 +--
5 files changed, 101 insertions(+), 54 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index d3010aa79daf..b1f3ed9c7a9e 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -992,8 +992,17 @@ int native_cpu_up(unsigned int cpu, struct task_struct
*tidle)
common_cpu_up(cpu, tidle);
+ /*
+* We have to walk the irq descriptors to setup the vector
+* space for the cpu which comes online. Prevent irq
+* alloc/free across the bringup.
+*/
+ irq_lock_sparse();
+
err = do_boot_cpu(apicid, cpu, tidle);
+
if (err) {
+ irq_unlock_sparse();
pr_err("do_boot_cpu failed(%d) to wakeup CPU#%u\n", err, cpu);
return -EIO;
}
@@ -1011,6 +1020,8 @@ int native_cpu_up(unsigned int cpu, struct task_struct
*tidle)
touch_nmi_watchdog();
}
+ irq_unlock_sparse();
+
return 0;
}
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index c5e05c82d67c..c246ac3dda7c 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -578,15 +578,13 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
writel_relaxed(~0, >clr_falling);
writel_relaxed(~0, >clr_rising);
- /* set up all irqs in this bank */
- irq_set_chained_handler(bank_irq, gpio_irq_handler);
-
/*
* Each chip handles 32 gpios, and each irq bank consists of 16
* gpio irqs. Pass the irq bank's corresponding controller to
* the chained irq handler.
*/
- irq_set_handler_data(bank_irq, [gpio / 32]);
+ irq_set_chained_handler_and_data(bank_irq, gpio_irq_handler,
+[gpio / 32]);
binten |= BIT(bank);
}
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 1b7e155869f6..c00e2db351ba 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -75,6 +75,13 @@ struct its_node {
#define ITS_ITT_ALIGN SZ_256
+struct event_lpi_map {
+ unsigned long *lpi_map;
+ u16 *col_map;
+ irq_hw_number_t lpi_base;
+ int nr_lpis;
+};
+
/*
* The ITS view of a device - belongs to an ITS, a collection, owns an
* interrupt translation table, and a list of interrupts.
@@ -82,11 +89,8 @@ struct its_node {
struct its_device {
struct list_headentry;
struct its_node *its;
- struct its_collection *collection;
+ struct event_lpi_mapevent_map;
void*itt;
- unsigned long *lpi_map;
- irq_hw_number_t lpi_base;
- int nr_lpis;
u32 nr_ites;
u32 device_id;
};
@@ -99,6 +103,14 @@ static struct rdists *gic_rdists;
#define gic_data_rdist() (raw_cpu_ptr(gic_rdists->rdist))
#define gic_data_rdist_rd_base() (gic_data_rdist()->rd_base)
+static struct its_collection *dev_event_to_col(struct its_device *its_dev,
+ u32 event)
+{
+ struct its_node *its = its_dev->its;
+
+ return its->collections + its_dev->event_map.col_map[event];
+}
+
/*
* ITS command descriptors - parameters to be encoded in a command
* block.
@@ -134,7 +146,7 @@ struct its_cmd_desc {
struct {
struct its_device *dev;
struct its_collection *col;
- u32 id;
+ u32 event_id;
} its_movi_cmd;
struct {
@@ -241,7 +253,7 @@ static struct its_collection *its_build_mapd_cmd(struct
its_cmd_block *cmd,
its_fixup_cmd(cmd);
Re: [PATCH 1/3] fixed_phy: handle link-down case
Le 07/17/15 16:53, Stas Sergeev a écrit :
> 18.07.2015 02:35, Florian Fainelli пишет:
>> On 17/07/15 16:24, Stas Sergeev wrote:
>>> 18.07.2015 01:01, Florian Fainelli пишет:
On 17/07/15 13:03, Stas Sergeev wrote:
> 17.07.2015 21:50, Florian Fainelli пишет:
>> On 17/07/15 04:26, Stas Sergeev wrote:
>>> 17.07.2015 02:25, Florian Fainelli пишет:
On 16/07/15 07:50, Stas Sergeev wrote:
> Currently fixed_phy driver recognizes only the link-up state.
> This simple patch adds an implementation of link-down state.
> It fixes the status registers when link is down, and also allows
> to register the fixed-phy with link down without specifying the
> speed.
This patch still breaks my setups here, e.g:
drivers/net/dsa/bcm_sf2.c,
but I will look into it.
Do we really need this for now for your two other patches to work
properly, or is it just nicer to have?
>>> Yes, absolutely.
>>> Otherwise registering fixed phy will return -EINVAL
>>> because of the missing link speed (even though the link
>>> is down).
>> Ok, I see the problem that you have now. Arguably you could say that
>> according to the fixed-link binding, speed needs to be specified and
>> the
>> code correctly errors out with such an error if you do not specify
>> it. I
> Aren't you missing the fact that .link=0?
> I think what you say is true only for the link-up case, no?
> .speed==0 is valid for link-down IMHO: no link - zero speed.
Pardon me being very dense and stupid here, but your problem is that
the
"speed" parameter is not specified in your DT,
>>> Not even a fixed-link at all, since the latest patches.
>>> I removed fixed-link defs from my DT.
>> Hummm, okay, so you just have the inband-status property and that's it,
>> not even a fixed-link node anymore, right? How does
>> mvneta_fixed_link_update() work then since it needs a fixed PHY to be
>> registered?
> You can see it from my patch:
> ---
>
> +err = of_property_read_string(np, "managed", );
> +if (err == 0) {
> +if (strcmp(managed, "in-band-status") == 0) {
> +/* status is zeroed, namely its .link member */
> +phy = fixed_phy_register(PHY_POLL, , np);
> +return IS_ERR(phy) ? PTR_ERR(phy) : 0;
> +}
> +}
>
> ---
> which is the hunk added to the of_phy_register_fixed_link().
> So in that case we register fixed-phy, but do not parse the fixed-link.
Ok, I missed that part. Could not you just override everything that is
needed here to get past the point where you register your fixed PHY even
with link = 0, this will be discarded anyway once you start in-band
negotiation.
>
>>> AFAIK when link is down, you are not allowed to rely on the PHY
>>> status registers to read speed from, or am I wrong? So if my
>>> understanding is correct, this was working by a pure luck.
>> Well, it's more like it is undefined, and before this patch, the fixed
>> PHY would update everything except the link status indication.
> And what about the real MDIO PHY? Or does it never hit this
> "undefined" code path?
> Anyway, if you call it undefined, I guess you automatically agree
> this needs to be fixed. :)
I should have been clearer; it is undefined for real PHYs it was not for
fixed PHYs, you can rely on the configuration that was done during
registration. Maybe not the best assumption; but it worked, and with
this patch it no longer works, so we want to find something here.
>
>>> As for the quick fix - why not to do this pre-init in
>>> fixed_link_update()
>>> instead of adjust_link()? In fixed_link_update() you'll get the speed
>>> right from DT, so it will be correct.
>> fixed_link_update() only gets called once you start your PHY state
>> machine, unfortunately, not upon fixed PHY device registration, and it
>> runs before your adjust_link callback does,
> So you say fixed_link_update() runs before adjust_link callback does,
> which looks logical. Why would you need it to run on device registration,
> if it runs earlier than adjust_link (which you use for init) even now?
There could be multiple reasons:
- device might be clock gated, until you "open" it you cannot
necessarily start making register accesses
- interfaces can be brought up/down separately so you want to stop the
PHY state machine accordingly
I will work on something anyway.
--
Florian
--
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] soc: Mediatek: Add SCPSYS CPU power domain driver
Hi Matthias,
Sascha hopes we can put CPU MTCMOS driver to his mtk-scpsys.c. We
understood but please let us describe our opinion.
(1) The code to initial CPU for SMP operation is in very early stage
during bring-up, the mtk-scpsys.c is not ready at the moment.
(2) The CPU MTCMOS driver may chip dependent, it’s more simple and easy
maintenance for us.
(3) There are some precedents that locate the CPU power control under
arch/arm/mach- folder.
Please let us have more discussion about this.
Thanks a lot.
Scott
On Fri, 2015-07-10 at 16:31 +0200, Matthias Brugger wrote:
> On Friday, July 10, 2015 02:04:05 PM Scott Shu wrote:
> > This adds a CPU power domain driver for the Mediatek SCPSYS unit on
> > MT6580.
> >
> > Signed-off-by: Scott Shu
> > ---
> > arch/arm/mach-mediatek/Makefile | 2 +-
> > arch/arm/mach-mediatek/generic.h | 23
> > arch/arm/mach-mediatek/hotplug.c | 267
> > +++ 3 files changed, 291 insertions(+),
> > 1 deletion(-)
> > create mode 100644 arch/arm/mach-mediatek/generic.h
> > create mode 100644 arch/arm/mach-mediatek/hotplug.c
> >
> > diff --git a/arch/arm/mach-mediatek/Makefile
> > b/arch/arm/mach-mediatek/Makefile index 2116460..b2e4ef5 100644
> > --- a/arch/arm/mach-mediatek/Makefile
> > +++ b/arch/arm/mach-mediatek/Makefile
> > @@ -1,4 +1,4 @@
> > ifeq ($(CONFIG_SMP),y)
> > -obj-$(CONFIG_ARCH_MEDIATEK) += platsmp.o
> > +obj-$(CONFIG_ARCH_MEDIATEK) += platsmp.o hotplug.o
> > endif
> > obj-$(CONFIG_ARCH_MEDIATEK) += mediatek.o
> > diff --git a/arch/arm/mach-mediatek/generic.h
> > b/arch/arm/mach-mediatek/generic.h new file mode 100644
> > index 000..376f183
> > --- /dev/null
> > +++ b/arch/arm/mach-mediatek/generic.h
> > @@ -0,0 +1,23 @@
> > +/*
> > + * Copyright (c) 2015 Mediatek Inc.
> > + * Author: Scott Shu
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +#ifndef __MACH_GENERIC_H
> > +#define __MACH_GENERIC_H
> > +
> > +#include
> > +
> > +int spm_cpu_mtcmos_init(void);
> > +int spm_cpu_mtcmos_on(int cpu);
> > +int spm_cpu_mtcmos_off(int cpu, bool wfi);
> > +
> > +#endif
> > diff --git a/arch/arm/mach-mediatek/hotplug.c
> > b/arch/arm/mach-mediatek/hotplug.c new file mode 100644
> > index 000..bd97f2e
> > --- /dev/null
> > +++ b/arch/arm/mach-mediatek/hotplug.c
> > @@ -0,0 +1,267 @@
> > +/*
> > + * Copyright (c) 2015 Mediatek Inc.
> > + * Author: Scott Shu
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* SCPSYS registers */
> > +#define SPM_POWERON_CONFIG_SET 0x
> > +
> > +#define SPM_CA7_CPU0_PWR_CON 0x0200
> > +#define SPM_CA7_CPU1_PWR_CON 0x0218
> > +#define SPM_CA7_CPU2_PWR_CON 0x021c
> > +#define SPM_CA7_CPU3_PWR_CON 0x0220
> > +
> > +#define SPM_CA7_CPU0_L1_PDN0x025c
> > +#define SPM_CA7_CPU1_L1_PDN0x0264
> > +#define SPM_CA7_CPU2_L1_PDN0x026c
> > +#define SPM_CA7_CPU3_L1_PDN0x0274
> > +
> > +#define SPM_PWR_STATUS 0x060c
> > +#define SPM_PWR_STATUS_2ND 0x0610
> > +#define SPM_SLEEP_TIMER_STA0x0720
> > +
> > +/* bit definition in SPM_CA7_CPUx_PWR_CON */
> > +#define SRAM_ISOINT_B BIT(6)
> > +#define SRAM_CKISO BIT(5)
> > +#define PWR_CLK_DISBIT(4)
> > +#define PWR_ON_2ND BIT(3)
> > +#define PWR_ON BIT(2)
> > +#define PWR_ISOBIT(1)
> > +#define PWR_RST_B BIT(0)
> > +
> > +/* bit definition in SPM_CA7_CPUx_L1_PDN */
> > +#define L1_PDN_ACK BIT(8)
> > +#define L1_PDN BIT(0)
> > +
> > +#define MT6580_MAX_CPUS4
> > +
> > +static DEFINE_SPINLOCK(spm_cpu_lock);
> > +
> > +void __iomem *spm_cpu_base;
> > +
> > +u32 spm_cpu_pwr_con[MT6580_MAX_CPUS] = {
> > + SPM_CA7_CPU0_PWR_CON,
> > + SPM_CA7_CPU1_PWR_CON,
> > + SPM_CA7_CPU2_PWR_CON,
> > + SPM_CA7_CPU3_PWR_CON,
> > +};
> > +
> > +u32
Re: BUG: perf error on syscalls for powerpc64.
On 2015年07月17日 09:59, Ian Munsie wrote: Excerpts from Sukadev Bhattiprolu's message of 2015-07-17 11:51:04 +1000: Are you seeing this on big-endian or little-endian system? IIRC, I saw the opposite behavior on an LE system a few months ago. i.e. without 1028ccf5, 'perf listf|grep syscall' failed. Applying 1028ccf5, seemed to fix it. You could be on to something there - IIRC the ABI was changed for LE to remove the dot symbols. Might be worth testing on both. Yeah, thanks Ian for your hints. it should be the dot symbols. So I'll believe it's good in 4.x, thanks Michael for your patience as well. Cheers, Zumeng Cheers, -Ian ___ Linuxppc-dev mailing list linuxppc-...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- 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] x86/fpu, fork: Dynamically allocate 'struct fpu'
* Dave Hansen wrote: > On 07/17/2015 12:23 PM, Ingo Molnar wrote: > > > Dave, can I put your Signed-off-by into this patch? I have already tested > > these > > two patches and they are looking good here - so unless you can see some > > breakage > > or other problem I'd prefer it to keep it two patches. > > Everything looks good here with your actual two patches applied: > > Signed-off-by: Dave Hansen Great, thanks! Ingo -- 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 RESEND 0/3] mm, x86: Fix ioremap RAM check interfaces
On Thu, Jul 16, 2015 at 4:23 PM, Toshi Kani wrote: > ioremap() checks if a target range is in RAM and fails the request > if true. There are multiple issues in the iormap RAM check interfaces. > > 1. region_is_ram() always fails with -1. > 2. The check calls two functions, region_is_ram() and > walk_system_ram_range(), which are redundant as both walk the > same iomem_resource table. > 3. walk_system_ram_range() requires RAM ranges be page-aligned in > the iomem_resource table to work properly. This restriction > has allowed multiple ioremaps to RAM which are page-unaligned. > > This patchset solves issue 1 and 2. It does not address issue 3, > but continues to allow the existing ioremaps to work until it is > addressed. > > --- > resend: > - Rebased to 4.2-rc2 (no change needed). Modified change logs. > > --- > Toshi Kani (3): > 1/3 mm, x86: Fix warning in ioremap RAM check > 2/3 mm, x86: Remove region_is_ram() call from ioremap > 3/3 mm: Fix bugs in region_is_ram() > For the series... Reviewed-by: Dan Williams I'm going to base my ioremap + memremap series on top of these fixes. -- 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/6] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter
On 7/17/15 6:02 PM, pi3orama wrote: An example: we want to count the number of cycles between entry and exit point of a particular library function (glibc write() for example). Context switch is possible, but we don't care cycles consumed by other tasks. Then we need to create a perf event in task context using: perf _event_open(, pid, -1/* cpu */, ...); Since it is a library function, we have to choose pids we interest. sure. just store that fd under whatever index in perf_event_array and use it from the program. index is not cpuid. it's just an index. We should also probe sys_clone and create new perf event when thread creating, we haven't think how to do that now. opening a perf_event from the program? That will be very very hard. Much easier to kprobe sys_clone and signal to user space via bpf_output_trace_data() and user space will be perf_event_open-ing new event for new task. ps please tweak your email client to wrap lines. -- 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/6] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter
发自我的 iPhone > 在 2015年7月18日，上午8:42，Alexei Starovoitov 写道： > >> On 7/17/15 4:27 PM, pi3orama wrote: >> Then we also need another BPF_MAP_TYPE_PERF_EVENT_HASHMAP for events in task >> context. > > hmm. why? don't see a use case yet. An example: we want to count the number of cycles between entry and exit point of a particular library function (glibc write() for example). Context switch is possible, but we don't care cycles consumed by other tasks. Then we need to create a perf event in task context using: perf _event_open(, pid, -1/* cpu */, ...); Since it is a library function, we have to choose pids we interest. We should also probe sys_clone and create new perf event when thread creating, we haven't think how to do that now. Then when inserting into map, the meaning of key should not 'cpuid'. Pid should be mush reasonable. Although we can use a auxiliary map which maps pid to array index... Thank you. > >> I choose current implementation because I think we may need perf event not >> wrapped in map in future (for example, tracepoints). With the design you >> suggested in this case we have to create a map with only 1 element in it. > > what you had also needs a map of one element. > also I don't think perf_events can be 'detached'. User space always will > perf_event_open one first and only then program will use it. > So passing FD from user space to the program is inevitable. > Other than storing FD into map the other alternative is to use ld_imm64 > mechanism. Then the helper will only have one argument, > but then you'd need to extend 'used_maps' logic with 'used_fds'. > It's doable as well, but I think the use case of only one pmu counter > per cpu is artificial. You'll always have an array of events. One for > each cpu. So perf_event_array mechanism fits the best. > >>> >btw, make sure you do your tests with lockdep and other debugs on. >>> >and for the sample code please use C for the bpf program. Not many >>> >people can read bpf asm ;) >>> > >> We still need some perf side code to make a c program work. > > no, what I meant is to do sample code as tracex[1-5]* > where there is distinct kernel and user space parts. Both in C. > At this stage perf patches are way too early. -- 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] zsmalloc: do not take class lock in zs_shrinker_count()
Hi, On (07/18/15 07:42), Minchan Kim wrote: > I asked to remove the comment of zs_can_compact about lock. > "Should be called under class->lock." Oh... I somehow quickly read it and thought you were talking about the commit message. Fixed and resent. > Otherwise, > > Acked-by: Minchan Kim Thanks. -ss > > --- > > mm/zsmalloc.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > > index 1edd8a0..ed64cf5 100644 > > --- a/mm/zsmalloc.c > > +++ b/mm/zsmalloc.c > > @@ -1836,9 +1836,7 @@ static unsigned long zs_shrinker_count(struct > > shrinker *shrinker, > > if (class->index != i) > > continue; > > > > - spin_lock(>lock); > > pages_to_free += zs_can_compact(class); > > - spin_unlock(>lock); > > } > > > > return pages_to_free; > > -- > > 2.4.6 > > > > -- > Kind regards, > Minchan Kim > -- 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 5/6] clk: sunxi: make use of of_clk_parent_fill helper function
On 07/06, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock names' array. > > Signed-off-by: Dinh Nguyen > Cc: Maxime Ripard > Cc: "Emilio López" > --- Applied to clk-next with that fix I posted. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 4/6] clk: st: make use of of_clk_parent_fill helper function
On 07/06, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock names' array. > > Signed-off-by: Dinh Nguyen > Tested-by Gabriel Fernandez > Cc: Peter Griffin > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 6/6] clk: ti: make use of of_clk_parent_fill helper function
On 07/06, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock names' array. > > Signed-off-by: Dinh Nguyen > Cc: Tero Kristo > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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/6] clk: at91: make use of of_clk_parent_fill helper function
On 07/06, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock names' array. > > Signed-off-by: Dinh Nguyen > Cc: Boris Brezillon > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 3/6] clk: keystone: make use of of_clk_parent_fill helper function
On 07/06, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock names' array. > > Signed-off-by: Dinh Nguyen > Acked-by: Santosh Shilimkar > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 2/6] clk: qoriq: make use of of_clk_parent_fill helper function
On 07/06, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock names' array. > > Signed-off-by: Dinh Nguyen > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 5/6] clk: sunxi: make use of of_clk_parent_fill helper function
On 07/06, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock names' array. > > Signed-off-by: Dinh Nguyen > Cc: Maxime Ripard > Cc: "Emilio López" > --- Adds a warning. Squashed this in: diff --git a/drivers/clk/sunxi/clk-sun6i-ar100.c b/drivers/clk/sunxi/clk-sun6i-ar100.c index a203b6f62ee7..3a2ea010f148 100644 --- a/drivers/clk/sunxi/clk-sun6i-ar100.c +++ b/drivers/clk/sunxi/clk-sun6i-ar100.c @@ -182,7 +182,6 @@ static int sun6i_a31_ar100_clk_probe(struct platform_device *pdev) struct resource *r; struct clk *clk; int nparents; - int i; ar100 = devm_kzalloc(>dev, sizeof(*ar100), GFP_KERNEL); if (!ar100) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 v3] zsmalloc: do not take class lock in zs_shrinker_count()
We can avoid taking class ->lock around zs_can_compact() in
zs_shrinker_count(), because the number that we return back
is outdated in general case, by design. We have different
sources that are able to change class's state right after we
return from zs_can_compact() -- ongoing I/O operations, manually
triggered compaction, or two of them happening simultaneously.
We re-do this calculations during compaction on a per class basis
anyway.
zs_unregister_shrinker() will not return until we have an
active shrinker, so classes won't unexpectedly disappear
while zs_shrinker_count() iterates them.
Signed-off-by: Sergey Senozhatsky
Acked-by: Minchan Kim
---
mm/zsmalloc.c | 4
1 file changed, 4 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 1edd8a0..c1399e8 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1711,8 +1711,6 @@ static struct page *isolate_source_page(struct size_class
*class)
*
* Based on the number of unused allocated objects calculate
* and return the number of pages that we can free.
- *
- * Should be called under class->lock.
*/
static unsigned long zs_can_compact(struct size_class *class)
{
@@ -1836,9 +1834,7 @@ static unsigned long zs_shrinker_count(struct shrinker
*shrinker,
if (class->index != i)
continue;
- spin_lock(>lock);
pages_to_free += zs_can_compact(class);
- spin_unlock(>lock);
}
return pages_to_free;
--
2.4.6
--
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] ACPI / processor: Drop an unused argument of a cleanup routine
From: Rafael J. Wysocki
acpi_processor_unregister_performance() actually doesn't use its
first argument, so drop it and update the callers accordingly.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/processor_perflib.c|4 +---
drivers/cpufreq/acpi-cpufreq.c |5 ++---
drivers/cpufreq/e_powersaver.c |2 +-
drivers/cpufreq/ia64-acpi-cpufreq.c |5 ++---
drivers/cpufreq/powernow-k7.c |4 ++--
drivers/cpufreq/powernow-k8.c |5 ++---
drivers/xen/xen-acpi-processor.c|4 ++--
include/acpi/processor.h|5 +
8 files changed, 13 insertions(+), 21 deletions(-)
Index: linux-pm/drivers/acpi/processor_perflib.c
===
--- linux-pm.orig/drivers/acpi/processor_perflib.c
+++ linux-pm/drivers/acpi/processor_perflib.c
@@ -780,9 +780,7 @@ acpi_processor_register_performance(stru
EXPORT_SYMBOL(acpi_processor_register_performance);
-void
-acpi_processor_unregister_performance(struct acpi_processor_performance
- *performance, unsigned int cpu)
+void acpi_processor_unregister_performance(unsigned int cpu)
{
struct acpi_processor *pr;
Index: linux-pm/include/acpi/processor.h
===
--- linux-pm.orig/include/acpi/processor.h
+++ linux-pm/include/acpi/processor.h
@@ -228,10 +228,7 @@ extern int acpi_processor_preregister_pe
extern int acpi_processor_register_performance(struct
acpi_processor_performance
*performance, unsigned int cpu);
-extern void acpi_processor_unregister_performance(struct
- acpi_processor_performance
- *performance,
- unsigned int cpu);
+extern void acpi_processor_unregister_performance(unsigned int cpu);
/* note: this locks both the calling module and the processor module
if a _PPC object exists, rmmod is disallowed then */
Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -842,7 +842,7 @@ static int acpi_cpufreq_cpu_init(struct
err_freqfree:
kfree(data->freq_table);
err_unreg:
- acpi_processor_unregister_performance(perf, cpu);
+ acpi_processor_unregister_performance(cpu);
err_free_mask:
free_cpumask_var(data->freqdomain_cpus);
err_free:
@@ -860,8 +860,7 @@ static int acpi_cpufreq_cpu_exit(struct
if (data) {
policy->driver_data = NULL;
- acpi_processor_unregister_performance(data->acpi_data,
- data->acpi_perf_cpu);
+ acpi_processor_unregister_performance(data->acpi_perf_cpu);
free_cpumask_var(data->freqdomain_cpus);
kfree(data->freq_table);
kfree(data);
Index: linux-pm/drivers/cpufreq/e_powersaver.c
===
--- linux-pm.orig/drivers/cpufreq/e_powersaver.c
+++ linux-pm/drivers/cpufreq/e_powersaver.c
@@ -78,7 +78,7 @@ static int eps_acpi_init(void)
static int eps_acpi_exit(struct cpufreq_policy *policy)
{
if (eps_acpi_cpu_perf) {
- acpi_processor_unregister_performance(eps_acpi_cpu_perf, 0);
+ acpi_processor_unregister_performance(0);
free_cpumask_var(eps_acpi_cpu_perf->shared_cpu_map);
kfree(eps_acpi_cpu_perf);
eps_acpi_cpu_perf = NULL;
Index: linux-pm/drivers/cpufreq/ia64-acpi-cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/ia64-acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/ia64-acpi-cpufreq.c
@@ -313,7 +313,7 @@ acpi_cpufreq_cpu_init (
err_freqfree:
kfree(data->freq_table);
err_unreg:
- acpi_processor_unregister_performance(>acpi_data, cpu);
+ acpi_processor_unregister_performance(cpu);
err_free:
kfree(data);
acpi_io_data[cpu] = NULL;
@@ -332,8 +332,7 @@ acpi_cpufreq_cpu_exit (
if (data) {
acpi_io_data[policy->cpu] = NULL;
- acpi_processor_unregister_performance(>acpi_data,
- policy->cpu);
+ acpi_processor_unregister_performance(policy->cpu);
kfree(data);
}
Index: linux-pm/drivers/cpufreq/powernow-k7.c
===
--- linux-pm.orig/drivers/cpufreq/powernow-k7.c
+++ linux-pm/drivers/cpufreq/powernow-k7.c
@@ -421,7 +421,7 @@ static int powernow_acpi_init(void)
return 0;
err2:
- acpi_processor_unregister_performance(acpi_processor_perf, 0);
+
[PATCH 2/2] cpufreq: acpi-cpufreq: Drop acpi_data from struct acpi_cpufreq_data
From: Rafael J. Wysocki
After commit 8cfcfd39000d (acpi-cpufreq: Fix an ACPI perf unregister
issue) we store both a pointer to per-CPU data of the first policy
CPU and the number of that CPU which are redundant.
Since the CPU number has to be stored anyway for the unregistration,
the pointer to the CPU's per-CPU data may be dropped and we can
access the data in question via per_cpu_ptr().
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/acpi-cpufreq.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -65,7 +65,6 @@ enum {
#define MSR_K7_HWCR_CPB_DIS(1ULL << 25)
struct acpi_cpufreq_data {
- struct acpi_processor_performance *acpi_data;
struct cpufreq_frequency_table *freq_table;
unsigned int resume;
unsigned int cpu_feature;
@@ -201,7 +200,7 @@ static unsigned extract_io(u32 value, st
struct acpi_processor_performance *perf;
int i;
- perf = data->acpi_data;
+ perf = per_cpu_ptr(acpi_perf_data, data->acpi_perf_cpu);
for (i = 0; i < perf->state_count; i++) {
if (value == perf->states[i].status)
@@ -220,7 +219,7 @@ static unsigned extract_msr(u32 msr, str
else
msr &= INTEL_MSR_RANGE;
- perf = data->acpi_data;
+ perf = per_cpu_ptr(acpi_perf_data, data->acpi_perf_cpu);
cpufreq_for_each_entry(pos, data->freq_table)
if (msr == perf->states[pos->driver_data].status)
@@ -346,7 +345,7 @@ get_cur_val(const struct cpumask *mask,
break;
case SYSTEM_IO_CAPABLE:
cmd.type = SYSTEM_IO_CAPABLE;
- perf = data->acpi_data;
+ perf = per_cpu_ptr(acpi_perf_data, data->acpi_perf_cpu);
cmd.addr.io.port = perf->control_register.address;
cmd.addr.io.bit_width = perf->control_register.bit_width;
break;
@@ -364,6 +363,7 @@ get_cur_val(const struct cpumask *mask,
static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
{
+ struct acpi_processor_performance *perf;
struct acpi_cpufreq_data *data;
struct cpufreq_policy *policy;
unsigned int freq;
@@ -377,10 +377,11 @@ static unsigned int get_cur_freq_on_cpu(
data = policy->driver_data;
cpufreq_cpu_put(policy);
- if (unlikely(!data || !data->acpi_data || !data->freq_table))
+ if (unlikely(!data || !data->freq_table))
return 0;
- cached_freq = data->freq_table[data->acpi_data->state].frequency;
+ perf = per_cpu_ptr(acpi_perf_data, data->acpi_perf_cpu);
+ cached_freq = data->freq_table[perf->state].frequency;
freq = extract_freq(get_cur_val(cpumask_of(cpu), data), data);
if (freq != cached_freq) {
/*
@@ -419,12 +420,11 @@ static int acpi_cpufreq_target(struct cp
unsigned int next_perf_state = 0; /* Index into perf table */
int result = 0;
- if (unlikely(data == NULL ||
-data->acpi_data == NULL || data->freq_table == NULL)) {
+ if (unlikely(data == NULL || data->freq_table == NULL)) {
return -ENODEV;
}
- perf = data->acpi_data;
+ perf = per_cpu_ptr(acpi_perf_data, data->acpi_perf_cpu);
next_perf_state = data->freq_table[index].driver_data;
if (perf->state == next_perf_state) {
if (unlikely(data->resume)) {
@@ -487,8 +487,9 @@ out:
static unsigned long
acpi_cpufreq_guess_freq(struct acpi_cpufreq_data *data, unsigned int cpu)
{
- struct acpi_processor_performance *perf = data->acpi_data;
+ struct acpi_processor_performance *perf;
+ perf = per_cpu_ptr(acpi_perf_data, data->acpi_perf_cpu);
if (cpu_khz) {
/* search the closest match to cpu_khz */
unsigned int i;
@@ -677,18 +678,17 @@ static int acpi_cpufreq_cpu_init(struct
goto err_free;
}
- data->acpi_data = per_cpu_ptr(acpi_perf_data, cpu);
+ perf = per_cpu_ptr(acpi_perf_data, cpu);
data->acpi_perf_cpu = cpu;
policy->driver_data = data;
if (cpu_has(c, X86_FEATURE_CONSTANT_TSC))
acpi_cpufreq_driver.flags |= CPUFREQ_CONST_LOOPS;
- result = acpi_processor_register_performance(data->acpi_data, cpu);
+ result = acpi_processor_register_performance(perf, cpu);
if (result)
goto err_free_mask;
- perf = data->acpi_data;
policy->shared_type = perf->shared_type;
/*
--
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
[PATCH 0/2] ACPI / cpufreq: ACPI processor driver and ACPI cpufreq driver cleanups
Hi, The following two patches clean up a couple of things in the ACPI processor driver and the ACPI cpufreq driver: [1/2] Drop the unused first argument of acpi_processor_unregister_performance(). [2/2] Drop the now redundant acpi_data pointer from acpi_cpufreq_data. Both patches on top of the current linux-next branch of the linux-pm.git tree. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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 3/3] clk: mediatek: Add MT8173 MMPLL change rate support
On 07/10, James Liao wrote: > MT8173 MMPLL frequency settings are different from common PLLs. > It needs different post divider settings for some ranges of frequency. > This patch add support for MT8173 MMPLL frequency setting by adding > div-rate table to lookup suitable post divider setting under a > specified frequency. > > Signed-off-by: James Liao > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 2/3] clk: mediatek: Fix calculation of PLL rate settings
On 07/10, James Liao wrote: > Avoid u32 overflow when calculate post divider setting, and > increase the max post divider setting from 3 (/8) to 4 (/16). > > Signed-off-by: James Liao > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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/3] clk: mediatek: Fix PLL registers setting flow
On 07/10, James Liao wrote: > Write postdiv and pcw settings at the same time for PLLs if postdiv > and pcw settings are on the same register. > > This is need by PLLs such as MT8173 MMPLL and ARM*PLL. > > Signed-off-by: James Liao > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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/6] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter
On 7/17/15 4:27 PM, pi3orama wrote: Then we also need another BPF_MAP_TYPE_PERF_EVENT_HASHMAP for events in task context. hmm. why? don't see a use case yet. I choose current implementation because I think we may need perf event not wrapped in map in future (for example, tracepoints). With the design you suggested in this case we have to create a map with only 1 element in it. what you had also needs a map of one element. also I don't think perf_events can be 'detached'. User space always will perf_event_open one first and only then program will use it. So passing FD from user space to the program is inevitable. Other than storing FD into map the other alternative is to use ld_imm64 mechanism. Then the helper will only have one argument, but then you'd need to extend 'used_maps' logic with 'used_fds'. It's doable as well, but I think the use case of only one pmu counter per cpu is artificial. You'll always have an array of events. One for each cpu. So perf_event_array mechanism fits the best. >btw, make sure you do your tests with lockdep and other debugs on. >and for the sample code please use C for the bpf program. Not many >people can read bpf asm ;) > We still need some perf side code to make a c program work. no, what I meant is to do sample code as tracex[1-5]* where there is distinct kernel and user space parts. Both in C. At this stage perf patches are way too early. -- 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/6] Input: pmic8xxx-keypad - change name of wakeup property
On 07/17/2015 05:36 PM, Dmitry Torokhov wrote: Wakeup property of device is not Linux-specific, it describes intended system behavior regardless of the OS being used. Therefore let's drop "linux," prefix, and, while at it, use the same name as I2C bus does: "wakeup-source". We keep parsing old name to keep compatibility with old DTSes. Signed-off-by: Dmitry Torokhov Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 v5 2/2] staging: rtl8192u: remove unneeded bool
On Fri, 2015-07-17 at 11:35 +0200, Luis de Bethencourt wrote:
> bool Reval is set to match the value of bHalfWirelessN24GMode just to
> this. The value can be returned directly. Removing uneeded bool.
trivia:
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
> b/drivers/staging/rtl8192u/r8192U_core.c
[]
> @@ -2043,16 +2043,10 @@ static bool GetNmodeSupportBySecCfg8192(struct
> net_device *dev)
> static bool GetHalfNmodeSupportByAPs819xUsb(struct net_device *dev)
> {
> - boolReval;
> struct r8192_priv *priv = ieee80211_priv(dev);
> struct ieee80211_device *ieee = priv->ieee80211;
There doesn't seem to be much value in this temporary.
> - if (ieee->bHalfWirelessN24GMode)
> - Reval = true;
> - else
> - Reval = false;
> -
> - return Reval;
> + return ieee->bHalfWirelessN24GMode;
return priv->ieee80211->bHalfWirelessN24GMode;
would work as well. But no doubt the compiler does the
same thing in any case.
--
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/6] Input: pmic8xxx-keypad - change name of wakeup property
Wakeup property of device is not Linux-specific, it describes intended
system behavior regardless of the OS being used. Therefore let's drop
"linux," prefix, and, while at it, use the same name as I2C bus does:
"wakeup-source".
We keep parsing old name to keep compatibility with old DTSes.
Signed-off-by: Dmitry Torokhov
---
Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt | 2 +-
drivers/input/keyboard/pmic8xxx-keypad.c | 10 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
index 7d8cb92..ee62156 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
@@ -33,7 +33,7 @@ PROPERTIES
Value type:
Definition: don't enable autorepeat feature.
-- linux,keypad-wakeup:
+- wakeup-source:
Usage: optional
Value type:
Definition: use any event on keypad as wakeup event.
diff --git a/drivers/input/keyboard/pmic8xxx-keypad.c
b/drivers/input/keyboard/pmic8xxx-keypad.c
index 32580af..5c68e3f 100644
--- a/drivers/input/keyboard/pmic8xxx-keypad.c
+++ b/drivers/input/keyboard/pmic8xxx-keypad.c
@@ -507,6 +507,7 @@ static void pmic8xxx_kp_close(struct input_dev *dev)
*/
static int pmic8xxx_kp_probe(struct platform_device *pdev)
{
+ struct device_node *np = pdev->dev.of_node;
unsigned int rows, cols;
bool repeat;
bool wakeup;
@@ -524,10 +525,11 @@ static int pmic8xxx_kp_probe(struct platform_device *pdev)
return -EINVAL;
}
- repeat = !of_property_read_bool(pdev->dev.of_node,
- "linux,input-no-autorepeat");
- wakeup = of_property_read_bool(pdev->dev.of_node,
- "linux,keypad-wakeup");
+ repeat = !of_property_read_bool(np, "linux,input-no-autorepeat");
+
+ wakeup = of_property_read_bool(np, "wakeup-source") ||
+/* legacy name */
+of_property_read_bool(np, "linux,keypad-wakeup");
kp = devm_kzalloc(>dev, sizeof(*kp), GFP_KERNEL);
if (!kp)
--
2.4.3.573.g4eafbef
--
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/6] Input: ads7846 - change name of wakeup property to "wakeup-source"
Wakeup property of device is not Linux-specific, it describes intended system behavior regardless of the OS being used. Therefore let's drop "linux," prefix, and, while at it, use the same name as I2C bus does: "wakeup-source". We keep parsing old name to keep compatibility with old DTSes. Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/ads7846.txt | 2 +- drivers/input/touchscreen/ads7846.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/ads7846.txt index 5f7619c..df8b127 100644 --- a/Documentation/devicetree/bindings/input/ads7846.txt +++ b/Documentation/devicetree/bindings/input/ads7846.txt @@ -64,7 +64,7 @@ Optional properties: pendown-gpio (u32). pendown-gpioGPIO handle describing the pin the !PENIRQ line is connected to. - linux,wakeupuse any event on touchscreen as wakeup event. + wakeup-source use any event on touchscreen as wakeup event. Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC:: diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index e4eb8a6..0f5f968 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -1234,7 +1234,8 @@ static const struct ads7846_platform_data *ads7846_probe_dt(struct device *dev) of_property_read_u32(node, "ti,pendown-gpio-debounce", >gpio_pendown_debounce); - pdata->wakeup = of_property_read_bool(node, "linux,wakeup"); + pdata->wakeup = of_property_read_bool(node, "wakeup-source") || + of_property_read_bool(node, "linux,wakeup"); pdata->gpio_pendown = of_get_named_gpio(dev->of_node, "pendown-gpio", 0); -- 2.4.3.573.g4eafbef -- 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 5/6] Input: samsung-keypad - change name of wakeup property
Wakeup property of device is not Linux-specific, it describes intended system behavior regardless of the OS being used. Therefore let's drop "linux," prefix, and, while at it, use the same name as I2C bus does: "wakeup-source". We keep parsing old name to keep compatibility with old DTSes. Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/samsung-keypad.txt | 4 +++- drivers/input/keyboard/samsung-keypad.c| 6 -- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt b/Documentation/devicetree/bindings/input/samsung-keypad.txt index 942d071..863e77f 100644 --- a/Documentation/devicetree/bindings/input/samsung-keypad.txt +++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt @@ -36,9 +36,11 @@ Required Board Specific Properties: - pinctrl-0: Should specify pin control groups used for this controller. - pinctrl-names: Should contain only one value - "default". +Optional Properties: +- wakeup-source: use any event on keypad as wakeup event. + Optional Properties specific to linux: - linux,keypad-no-autorepeat: do no enable autorepeat feature. -- linux,keypad-wakeup: use any event on keypad as wakeup event. Example: diff --git a/drivers/input/keyboard/samsung-keypad.c b/drivers/input/keyboard/samsung-keypad.c index 43e48dac..dc05f39 100644 --- a/drivers/input/keyboard/samsung-keypad.c +++ b/drivers/input/keyboard/samsung-keypad.c @@ -299,8 +299,10 @@ samsung_keypad_parse_dt(struct device *dev) if (of_get_property(np, "linux,input-no-autorepeat", NULL)) pdata->no_autorepeat = true; - if (of_get_property(np, "linux,input-wakeup", NULL)) - pdata->wakeup = true; + pdata->wakeup = of_property_read_bool(pp, "wakeup-source") || + /* legacy name */ + of_property_read_bool(pp, "linux,input-wakeup"); + return pdata; } -- 2.4.3.573.g4eafbef -- 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/6] Input: gpio_keys[_polled] - change name of wakeup property
Wakeup property of device is not Linux-specific, it describes intended system behavior regardless of the OS being used. Therefore let's drop "linux," prefix, and, while at it, use the same name as I2C bus does: "wakeup-source". We keep parsing old name to keep compatibility with old DTSes. Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/gpio-keys-polled.txt | 2 +- Documentation/devicetree/bindings/input/gpio-keys.txt| 2 +- drivers/input/keyboard/gpio_keys.c | 4 +++- drivers/input/keyboard/gpio_keys_polled.c| 5 - 4 files changed, 9 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/input/gpio-keys-polled.txt b/Documentation/devicetree/bindings/input/gpio-keys-polled.txt index 313abef..5b91f5a 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys-polled.txt +++ b/Documentation/devicetree/bindings/input/gpio-keys-polled.txt @@ -20,7 +20,7 @@ Optional subnode-properties: If not specified defaults to <1> == EV_KEY. - debounce-interval: Debouncing interval time in milliseconds. If not specified defaults to 5. - - gpio-key,wakeup: Boolean, button can wake-up the system. + - wakeup-source: Boolean, button can wake-up the system. Example nodes: diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt b/Documentation/devicetree/bindings/input/gpio-keys.txt index 44b7057..072bf75 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys.txt +++ b/Documentation/devicetree/bindings/input/gpio-keys.txt @@ -23,7 +23,7 @@ Optional subnode-properties: If not specified defaults to <1> == EV_KEY. - debounce-interval: Debouncing interval time in milliseconds. If not specified defaults to 5. - - gpio-key,wakeup: Boolean, button can wake-up the system. + - wakeup-source: Boolean, button can wake-up the system. - linux,can-disable: Boolean, indicates that button is connected to dedicated (not shared) interrupt which can be disabled to suppress events from the button. diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c index ddf4045..1df4507 100644 --- a/drivers/input/keyboard/gpio_keys.c +++ b/drivers/input/keyboard/gpio_keys.c @@ -655,7 +655,9 @@ gpio_keys_get_devtree_pdata(struct device *dev) if (of_property_read_u32(pp, "linux,input-type", >type)) button->type = EV_KEY; - button->wakeup = !!of_get_property(pp, "gpio-key,wakeup", NULL); + button->wakeup = of_property_read_bool(pp, "wakeup-source") || +/* legacy name */ +of_property_read_bool(pp, "gpio-key,wakeup"); button->can_disable = !!of_get_property(pp, "linux,can-disable", NULL); diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c index 097d721..5a0c999 100644 --- a/drivers/input/keyboard/gpio_keys_polled.c +++ b/drivers/input/keyboard/gpio_keys_polled.c @@ -152,7 +152,10 @@ static struct gpio_keys_platform_data *gpio_keys_polled_get_devtree_pdata(struct >type)) button->type = EV_KEY; - button->wakeup = fwnode_property_present(child, "gpio-key,wakeup"); + button->wakeup = + fwnode_property_read_bool(child, "wakeup-source") || + /* legacy name */ + fwnode_property_read_bool(child, "gpio-key,wakeup"); if (fwnode_property_read_u32(child, "debounce-interval", >debounce_interval)) -- 2.4.3.573.g4eafbef -- 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/6] Input: standardize on "wakeup-source" property
Hi, Currently input drivers use many forms of annotating devices that should be set up as wakeup sources for the system. This patch series converts them all to use "wakeup-source" name (to match what i2c devices are using) while keeping old names as fallback to keep compatibility with existing DTSes. Maybe in the future we could move parsing of "wakeup-source" into device core. Thanks. -- Dmitry -- 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/6] Input: matrix_keypad - change name of wakeup property to "wakeup-source"
Wakeup property of device is not Linux-specific, it describes intended system behavior regardless of the OS being used. Therefore let's drop "linux," prefix, and, while at it, use the same name as I2C bus does: "wakeup-source". We keep parsing old name to keep compatibility with old DTSes. Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt | 2 +- drivers/input/keyboard/matrix_keypad.c | 6 -- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt index ead641c..4d86059 100644 --- a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt +++ b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt @@ -19,7 +19,7 @@ Required Properties: Optional Properties: - linux,no-autorepeat: do no enable autorepeat feature. -- linux,wakeup:use any event on keypad as wakeup event. +- wakeup-source: use any event on keypad as wakeup event. - debounce-delay-ms: debounce interval in milliseconds - col-scan-delay-us: delay, measured in microseconds, that is needed before we can scan keypad after activating column gpio diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c index b370a59..7f12b65 100644 --- a/drivers/input/keyboard/matrix_keypad.c +++ b/drivers/input/keyboard/matrix_keypad.c @@ -425,8 +425,10 @@ matrix_keypad_parse_dt(struct device *dev) if (of_get_property(np, "linux,no-autorepeat", NULL)) pdata->no_autorepeat = true; - if (of_get_property(np, "linux,wakeup", NULL)) - pdata->wakeup = true; + + pdata->wakeup = of_property_read_bool(np, "wakeup-source") || + of_property_read_bool(np, "linux,wakeup"); /* legacy */ + if (of_get_property(np, "gpio-activelow", NULL)) pdata->active_low = true; -- 2.4.3.573.g4eafbef -- 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 6/6] Input: tc3589x-keypad - change name of wakeup property
Wakeup property of device is not Linux-specific, it describes intended
system behavior regardless of the OS being used. Therefore let's drop
"linux," prefix, and, while at it, use the same name as I2C bus does:
"wakeup-source".
We keep parsing old name to keep compatibility with old DTSes.
Signed-off-by: Dmitry Torokhov
---
Documentation/devicetree/bindings/mfd/tc3589x.txt | 4 ++--
drivers/input/keyboard/tc3589x-keypad.c | 5 -
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/tc3589x.txt
b/Documentation/devicetree/bindings/mfd/tc3589x.txt
index 6fcedba..37bf7f1 100644
--- a/Documentation/devicetree/bindings/mfd/tc3589x.txt
+++ b/Documentation/devicetree/bindings/mfd/tc3589x.txt
@@ -55,7 +55,7 @@ Optional nodes:
- linux,keymap: the definition can be found in
bindings/input/matrix-keymap.txt
- linux,no-autorepeat: do no enable autorepeat feature.
- - linux,wakeup: use any event on keypad as wakeup event.
+ - wakeup-source: use any event on keypad as wakeup event.
Example:
@@ -84,7 +84,6 @@ tc35893@44 {
keypad,num-columns = <8>;
keypad,num-rows = <8>;
linux,no-autorepeat;
- linux,wakeup;
linux,keymap = <0x0301006b
0x04010066
0x06040072
@@ -103,5 +102,6 @@ tc35893@44 {
0x01030039
0x07060069
0x050500d9>;
+ wakeup-source;
};
};
diff --git a/drivers/input/keyboard/tc3589x-keypad.c
b/drivers/input/keyboard/tc3589x-keypad.c
index 31c606a..565805e 100644
--- a/drivers/input/keyboard/tc3589x-keypad.c
+++ b/drivers/input/keyboard/tc3589x-keypad.c
@@ -352,7 +352,10 @@ tc3589x_keypad_of_probe(struct device *dev)
}
plat->no_autorepeat = of_property_read_bool(np, "linux,no-autorepeat");
- plat->enable_wakeup = of_property_read_bool(np, "linux,wakeup");
+
+ plat->enable_wakeup = of_property_read_bool(np, "wakeup-source") ||
+ /* legacy name */
+ of_property_read_bool(np, "linux,wakeup");
/* The custom delay format is ms/16 */
of_property_read_u32(np, "debounce-delay-ms", _ms);
--
2.4.3.573.g4eafbef
--
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] ARM: mm: do not use virt_to_idmap() for NOMMU systems
The "ARM: mm: Introduce virt_to_idmap() with an arch hook" defines arch_virt_to_idmap hook in arch/arm/mm/idmap.c. That breaks systems w/o MMU because that file is not built for them. This patch fixes this bug. Signed-off-by: Vitaly Andrianov --- arch/arm/include/asm/memory.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h index 6f225ac..114abe3 100644 --- a/arch/arm/include/asm/memory.h +++ b/arch/arm/include/asm/memory.h @@ -279,6 +279,7 @@ static inline void *phys_to_virt(phys_addr_t x) extern phys_addr_t (*arch_virt_to_idmap)(unsigned long x); +#ifdef CONFIG_MMU /* * These are for systems that have a hardware interconnect supported alias of * physical memory for idmap purposes. Most cases should leave these @@ -293,6 +294,9 @@ static inline phys_addr_t __virt_to_idmap(unsigned long x) } #define virt_to_idmap(x) __virt_to_idmap((unsigned long)(x)) +#else +#define virt_to_idmap(x) __virt_to_phys((unsigned long)(x)) +#endif /* * Virtual <-> DMA view memory address translations -- 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 5/5] drivers: staging: rtl8192u: fixed coding style issues in r8192U_core.c
On Fri, 2015-07-17 at 15:59 +0200, Joseph-Eugene Winzer wrote: > Fixed a few lines that were longer than 80 chars. [] > diff --git a/drivers/staging/rtl8192u/r8192U_core.c > b/drivers/staging/rtl8192u/r8192U_core.c [] > @@ -212,7 +212,9 @@ static void rtl819x_set_channel_map(u8 channel_plan, > struct r8192_priv *priv) > ChannelPlan[channel_plan].Channel[i] > > max_chan) > break; > - > GET_DOT11D_INFO(ieee)->channel_map[ChannelPlan[channel_plan].Channel[i]] = 1; > + GET_DOT11D_INFO(ieee)-> > + channel_map[ChannelPlan[channel_plan]. > + Channel[i]] = 1; That's _very_ not nice to read. Try using more temporaries instead. index = ChannelPlan[channel_plan].Channel[i]; GET_DOT11D_INFO(ieee)->channel_map[index] = 1; 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 2/5] drivers: staging: rtl8192u: fixing coding style issues in r8192U_core.c
On Fri, 2015-07-17 at 15:59 +0200, Joseph-Eugene Winzer wrote:
> Reformatting the code without introducing other warnings
> like 'Avoid unnecessary line continuations' or breaking strings.
Very few of these seem to be improvements and many
of them should likely be in separate patches.
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
> b/drivers/staging/rtl8192u/r8192U_core.c
[]
> @@ -143,17 +143,35 @@ struct CHANNEL_LIST {
> };
>
> static struct CHANNEL_LIST ChannelPlan[] = {
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64,
> 149, 153, 157, 161, 165}, 24}, /* FCC */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11}, /* IC */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56,
> 60, 64}, 21}, /* ETSI */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* Spain. Change to
> ETSI. */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* France. Change to
> ETSI. */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
> 56, 60, 64}, 22}, /* MKK //MKK */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
> 56, 60, 64}, 22}, /* MKK1 */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* Israel. */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
> 56, 60, 64}, 22}, /* For 11a , TELEC */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
> 56, 60, 64}, 22}, /* MIC */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14} /* For Global
> Domain. 1-11:active scan, 12-14 passive scan. //+YJ, 080626 */
If these were to be reformatted, it'd probably be better
to use 10 per line so that the Len value that follows is
more obvious. Likely this struct should be const too.
Maybe something like:
static const struct CHANNEL_LIST ChannelPlan[] = {
{
.Channel = {
1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 36, 40, 44, 48, 52, 56, 60, 64,149,
153,157,161,165
},
.Len = 24,
},
etc. Add more spaces between channels if you really want.
> @@ -179,7 +197,9 @@ static void rtl819x_set_channel_map(u8 channel_plan,
> struct r8192_priv *priv)
> min_chan = 1;
> max_chan = 14;
> } else {
> - RT_TRACE(COMP_ERR, "unknown rf chip, can't set channel
> map in function:%s()\n", __func__);
> + RT_TRACE(COMP_ERR,
> + "unknown rf chip, can't set channel map in
> function:%s()\n"
> + , __func__);
No leading commas please. Put the comma after the format.
> @@ -187,7 +207,10 @@ static void rtl819x_set_channel_map(u8 channel_plan,
> struct r8192_priv *priv)
> sizeof(GET_DOT11D_INFO(ieee)->channel_map));
> /* Set new channel map */
> for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
> - if (ChannelPlan[channel_plan].Channel[i] <
> min_chan || ChannelPlan[channel_plan].Channel[i] > max_chan)
> + if (ChannelPlan[channel_plan].Channel[i] <
> + min_chan ||
> + ChannelPlan[channel_plan].Channel[i] >
> + max_chan)
Likely better to use a temporary for ChannelPlan[channel_plan]
so these could become:
if (cp->Channel[i] < min_chan ||
cp->Channel[i] > max_chan)
etc...
> @@ -1490,7 +1523,8 @@ static u8 QueryIsShort(u8 TxHT, u8 TxRate, cb_desc
> *tcb_desc)
> {
> u8 tmp_Short;
>
> - tmp_Short = (TxHT == 1) ? ((tcb_desc->bUseShortGI) ? 1 : 0) :
> ((tcb_desc->bUseShortPreamble) ? 1 : 0);
> + tmp_Short = (TxHT == 1) ? ((tcb_desc->bUseShortGI) ? 1 : 0) :
> + ((tcb_desc->bUseShortPreamble) ? 1 : 0);
>
> if (TxHT == 1 && TxRate != DESC90_RATEMCS15)
> tmp_Short = 0;
Maybe using bool would be better.
> @@ -1673,7 +1711,8 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff
> *skb)
> 0, tx_zero_isr, dev);
> status = usb_submit_urb(tx_urb_zero, GFP_ATOMIC);
> if (status) {
> - RT_TRACE(COMP_ERR, "Error TX URB for zero byte
> %d, error %d", atomic_read(>tx_pending[tcb_desc->queue_index]), status);
> + RT_TRACE(COMP_ERR,
> + "Error TX URB for zero byte %d, error
> %d", atomic_read(>tx_pending[tcb_desc->queue_index]), status);
Probably better line wrapped after format
etc...
--
To unsubscribe from this list: send the
Re: [PATCH] acpi-cpufreq: Add a miss ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
On Tuesday, July 14, 2015 10:52:35 AM Pan Xinhui wrote:
> hi, Rafael,
> let me do more explanation :)
>
> On 2015年07月14日 10:09, Pan Xinhui wrote:
> > hi, Rafael,
> > thanks for you reply :)
> > On 2015年07月14日 07:26, Rafael J. Wysocki wrote:
> >> On Monday, July 13, 2015 02:33:08 PM Pan Xinhui wrote:
> >>> hi, Rafeal
> >>> thanks for your reply. :)
> >>>
> >>> On 2015年07月11日 04:44, Rafael J. Wysocki wrote:
> Hi,
>
> On Fri, Jul 10, 2015 at 7:50 AM, Pan Xinhui
> wrote:
> >
> > If CONFIG_X86_ACPI_CPUFREQ_CPB has not been defined, the placeholder for
> > cpb is not needed. Add ifdef around it.
> >
> > Signed-off-by: Pan Xinhui
> > ---
> > drivers/cpufreq/acpi-cpufreq.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/cpufreq/acpi-cpufreq.c
> > b/drivers/cpufreq/acpi-cpufreq.c
> > index e7fcaa6..314a19e 100644
> > --- a/drivers/cpufreq/acpi-cpufreq.c
> > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > @@ -884,7 +884,9 @@ static int acpi_cpufreq_resume(struct
> > cpufreq_policy *policy)
> > static struct freq_attr *acpi_cpufreq_attr[] = {
> > _freq_attr_scaling_available_freqs,
> > _cpus,
> > +#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
> > NULL, /* this is a placeholder for cpb, do not remove */
> > +#endif
>
> Adding the ifdef here doesn't change anything, because the next NULL
> will play the role of the one you've just #ifdefed and the structure
> will be filled with zeros from that point on anyway.
>
> >>> Yes, adding ifdef here does not change any binary codes. But I want to
> >>> make the codes more readable. :)
> >>> Patch author has noticed two *NULL* here would confuse people, especially
> >>> who first read this acpi-cpufreq.c file
> >>> From code style point, it would be better to have #ifdef around it.
> >>
> >> Not really.
> >>
> >> Why don't you simply drop *both* NULLs?
> >>
> > Just like string end with *NULL* :)
> >
> > 1021 static int cpufreq_add_dev_interface(struct cpufreq_policy *policy,
> > 1022 struct device *dev)
> > 1023 {
> > 1024 struct freq_attr **drv_attr;
> > 1025 int ret = 0;
> > 1026
> > 1027 /* set up files for this cpu device */
> > 1028 drv_attr = cpufreq_driver->attr;
> > 1029 while (drv_attr && *drv_attr) {
> > 1030 ret = sysfs_create_file(>kobj, &((*drv_attr)->attr));
> > 1031 if (ret)
> > 1032 return ret;
> > 1033 drv_attr++;
> > 1034 }
> > If struct freq_attr *acpi_cpufreq_attr[] did not end with NULL, line 1033
> > will access invalid data area.
> > If *drv_attr(the data after struct freq_attr * array[]) happened to be not
> > NULL. panic may hit in sysfs_create_file :(
> > So at least one *NULL* must be in the end of freq_attr *array[].
OK, so the array is NULL-terminated and one NULL is needed to mark the end of
it.
> >
> > Actually in acpi-cpufreq.c, in acpi_cpufreq_init function.
> > 957 struct freq_attr **iter;
> > 958
> > 959 pr_debug("adding sysfs entry for cpb\n");
> > 960
> > 961 for (iter = acpi_cpufreq_attr; *iter != NULL; iter++)
> > 962 ;
> > 963
> > 964 /* make sure there is a terminator behind it */
> > 965 if (iter[1] == NULL)
> > 966 *iter =
> > 967 }
> > line965, check of iter[1] is not needed. Maybe the patch author was afraid
> > of an unexpected remove of first *NULL*.
> > It might be a better solution to add ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
> > around that *NULL*, and remove this !iter[1] check.
Ah, so that is an exceptionally ugly piece of code.
What about the patch below?
---
drivers/cpufreq/acpi-cpufreq.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -884,7 +884,9 @@ static int acpi_cpufreq_resume(struct cp
static struct freq_attr *acpi_cpufreq_attr[] = {
_freq_attr_scaling_available_freqs,
_cpus,
- NULL, /* this is a placeholder for cpb, do not remove */
+#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
+ ,
+#endif
NULL,
};
@@ -957,17 +959,16 @@ static int __init acpi_cpufreq_init(void
* only if configured. This is considered legacy code, which
* will probably be removed at some point in the future.
*/
- if (check_amd_hwpstate_cpu(0)) {
- struct freq_attr **iter;
-
- pr_debug("adding sysfs entry for cpb\n");
+ if (!check_amd_hwpstate_cpu(0)) {
+ struct freq_attr **attr;
- for (iter = acpi_cpufreq_attr; *iter != NULL; iter++)
- ;
+ pr_debug("CPB unsupported, do not expose it\n");
-
Re: Reconciling rcu_irq_enter()/rcu_nmi_enter() with context tracking
On Fri, Jul 17, 2015 at 04:20:57PM -0700, Andy Lutomirski wrote: > On Fri, Jul 17, 2015 at 3:55 PM, Paul E. McKenney > wrote: > > On Fri, Jul 17, 2015 at 03:13:36PM -0700, Andy Lutomirski wrote: > >> On Fri, Jul 17, 2015 at 2:19 PM, Paul E. McKenney > >> wrote: > >> > On Fri, Jul 17, 2015 at 01:32:27PM -0700, Andy Lutomirski wrote: > >> >> True. But context tracking wouldn't object to being exact. And I > >> >> think we need context tracking to treat user mode as quiescent, so > >> >> they're at least related. > >> > > >> > And RCU would be happy to be able to always detect usermode execution. > >> > But there are configurations and architectures that exclude context > >> > tracking, which means that RCU has to roll its own in those cases. > >> > >> We could slowly fix them, perhaps. I suspect that I'm half-way done > >> with accidentally enabling it for x86_32 :) > > > > If there was an appropriate Kconfig variable, I could do things one way > > or the other, depending on what the architecture was doing. > > There's CONFIG_CONTEXT_TRACKING. > > IMO it would be nice if there was a sort of clear spec for what > promises an arch needs to make for proper RCU operation and what > additional promises it needs to make for RCU idle during user mode. Well, if RCU is going to delegate that responsibility to the architectures, as you are suggesting, something will indeed be required. ;-) If we come up with something workable, I will document it. Self-defense and all that. > > So you are -unconditionally- enabling context tracking for x86_32? > > Doesn't that increase kernel-user transition overhead? > > No, I'm just adding the user_enter and user_exit calls. This might > let us enable HAVE_CONTEXT_TRACKING. Someone still needs to flip it > on. Whew! ;-) On the other hand, RCU will need to be set up to work either way. Shouldn't be too hard, though. > >> >> >> > 3. In some configurations, RCU needs to be able to block > >> >> >> > entry into > >> >> >> > nohz state, both for idle and userspace. > >> >> >> > >> >> >> Hmm. I suppose we could be CONTEXT_USER but still have RCU awake, > >> >> >> although the tick would have to stay on. > >> >> > > >> >> > Right, there are situations where RCU needs a given CPU to keep the > >> >> > tick > >> >> > going, for example, when there are RCU callbacks queued on that CPU. > >> >> > Failing to keep the tick going could result in a system hang, because > >> >> > that callback might never be invoked. > >> >> > >> >> Can't we just fire the callbacks right away? > >> > > >> > Absolutely not!!! > >> > > >> > At least not on multi-CPU systems. There might be an RCU read-side > >> > critical section on some other CPU that we still have to wait for. > >> > >> Oh, right, obviously. Could you kick them over to a different CPU, though? > > > > For CONFIG_RCU_NOCB_CPUS=y kernels, no problem, they will execute on > > whatever CPU the scheduler or the sysadm chooses, as the case may be. > > Otherwise, it gets really hard to make sure that a given CPU's callbacks > > execute in order, which is required for rcu_barrier() to work properly. > > > > There was some thought of making CONFIG_RCU_NOCB_CPUS=y be the only > > way that RCU callbacks were invoked, but the overhead is higher and > > turns out to be all too noticeable on some workloads. :-( > > Yuck. What if we make CONFIG_RCU_NOCB_CPUS=y mandatory for NOHZ_FULL? > In any case, the people who want their systems to be really truly > quiescent in user space will have CONFIG_RCU_NOCB_CPUS=y. It is already mandatory, NO_HZ_FULL selects RCU_NOCB_CPUS. However, the choice of which CPU will really do nohz (and thus nocbs as well) happens at boot time. So a given NO_HZ_FULL system will typically have at least one non-RCU_NOCB_CPUS CPU, namely the boot CPU, which cannot be a nohz CPU. Thankfully, the choices are automated at Kconfig and boot time, so the right thing should happen without any undue user consternation. > >> Why is idle-to-RCU different from user-to-RCU? > > > > Full-system-idle checking that is supposed to someday allow CPU 0's > > scheduling-clock interrupt to be turned off on CONFIG_NO_HZ_FULL > > systems. In this case, RCU treats user as non-idle for the purpose > > of determining whether or not CPU 0's scheduling-clock interrupt can > > be stopped. > > I'm not quite sure I understand this. We can turn off the tick if > truly idle but not if in user mode? Why? Because of the need to maintain time synchronization at all times that at least one CPU is non-idle. User-mode code might access fine-grained time, and might care about time synchronization. The scheduling-clock interrupt handler takes care of this when needed. > >> I feel like RCU and context tracking are implementing more or less the > >> same thing, and the fact that they're not shared makes life > >> complicated. > >> > >> >From my perspective, I want to be able to say "I'm transitioning to > >> user mode right now"
Re: [PATCH 0/7] Initial support for user namespace owned mounts
On Thu, Jul 16, 2015 at 07:42:03PM -0500, Eric W. Biederman wrote: > Dave Chinner writes: > > > On Wed, Jul 15, 2015 at 11:47:08PM -0500, Eric W. Biederman wrote: > >> Casey Schaufler writes: > >> > On 7/15/2015 6:08 PM, Andy Lutomirski wrote: > >> >> If I mount an unprivileged filesystem, then either the contents were > >> >> put there *by me*, in which case letting me access them are fine, or > >> >> (with Seth's patches and then some) I control the backing store, in > >> >> which case I can do whatever I want regardless of what LSM thinks. > >> >> > >> >> So I don't see the problem. Why would Smack or any other LSM care at > >> >> all, unless it wants to prevent me from mounting the fs in the first > >> >> place? > >> > > >> > First off, I don't cotton to the notion that you should be able > >> > to mount filesystems without privilege. But it seems I'm being > >> > outvoted on that. I suspect that there are cases where it might > >> > be safe, but I can't think of one off the top of my head. > >> > >> There are two fundamental issues mounting filesystems without privielge, > >> by which I actually mean mounting filesystems as the root user in a user > >> namespace. > >> > >> - Are the semantics safe. > >> - Is the extra attack surface a problem. > > > > I think the attack surface this exposes is the biggest problem > > facing this proposal. > > I completely agree. > > >> Figuring out how to make semantics safe is what we are talking about. > >> > >> Once we sort out the semantics we can look at the handful of filesystems > >> like fuse where the extra attack surface is not a concern. > >> > >> With that said desktop environments have for a long time been > >> automatically mounting whichever filesystem you place in your computer, > >> so in practice what this is really about is trying to align the kernel > >> with how people use filesystems. > > > > The key difference is that desktops only do this when you physically > > plug in a device. With unprivileged mounts, a hostile attacker > > doesn't need physical access to the machine to exploit lurking > > kernel filesystem bugs. i.e. they can just use loopback mounts, and > > they can keep mounting corrupted images until they find something > > that works. > > Yep. That magnifies the problem quite a bit. > > > User namespaces are supposed to provide trust separation. The > > kernel filesystems simply aren't hardened against unprivileged > > attacks from below - there is a trust relationship between root and > > the filesystem in that they are the only things that can write to > > the disk. Mounts from within a userns destroys this relationship as > > the userns root, by definition, is not a trusted actor. > > I talked to Ted Tso a while back and ext4 is at least in principle > already hardened against that kind of attack. I am not certain I > believe it, but if it is true I think it is fantastic. Not sure what he said in private, but at the kernel summit last year what he said was not that it was "hardened", but that any bugs which would result from mounting a garbage image (i.e. an unpriv user fuzzing) would be deemed by him a real bug. As opposed to saying "don't do that". To the best of my knowledge that's so far only the case with Ted/ext4, which I assume is why Seth started with ext4. -serge -- 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/3] fixed_phy: handle link-down case
18.07.2015 02:35, Florian Fainelli пишет:
On 17/07/15 16:24, Stas Sergeev wrote:
18.07.2015 01:01, Florian Fainelli пишет:
On 17/07/15 13:03, Stas Sergeev wrote:
17.07.2015 21:50, Florian Fainelli пишет:
On 17/07/15 04:26, Stas Sergeev wrote:
17.07.2015 02:25, Florian Fainelli пишет:
On 16/07/15 07:50, Stas Sergeev wrote:
Currently fixed_phy driver recognizes only the link-up state.
This simple patch adds an implementation of link-down state.
It fixes the status registers when link is down, and also allows
to register the fixed-phy with link down without specifying the
speed.
This patch still breaks my setups here, e.g:
drivers/net/dsa/bcm_sf2.c,
but I will look into it.
Do we really need this for now for your two other patches to work
properly, or is it just nicer to have?
Yes, absolutely.
Otherwise registering fixed phy will return -EINVAL
because of the missing link speed (even though the link
is down).
Ok, I see the problem that you have now. Arguably you could say that
according to the fixed-link binding, speed needs to be specified and
the
code correctly errors out with such an error if you do not specify
it. I
Aren't you missing the fact that .link=0?
I think what you say is true only for the link-up case, no?
.speed==0 is valid for link-down IMHO: no link - zero speed.
Pardon me being very dense and stupid here, but your problem is that the
"speed" parameter is not specified in your DT,
Not even a fixed-link at all, since the latest patches.
I removed fixed-link defs from my DT.
Hummm, okay, so you just have the inband-status property and that's it,
not even a fixed-link node anymore, right? How does
mvneta_fixed_link_update() work then since it needs a fixed PHY to be
registered?
You can see it from my patch:
---
+ err = of_property_read_string(np, "managed", );
+ if (err == 0) {
+ if (strcmp(managed, "in-band-status") == 0) {
+ /* status is zeroed, namely its .link member */
+ phy = fixed_phy_register(PHY_POLL, , np);
+ return IS_ERR(phy) ? PTR_ERR(phy) : 0;
+ }
+ }
---
which is the hunk added to the of_phy_register_fixed_link().
So in that case we register fixed-phy, but do not parse the fixed-link.
AFAIK when link is down, you are not allowed to rely on the PHY
status registers to read speed from, or am I wrong? So if my
understanding is correct, this was working by a pure luck.
Well, it's more like it is undefined, and before this patch, the fixed
PHY would update everything except the link status indication.
And what about the real MDIO PHY? Or does it never hit this
"undefined" code path?
Anyway, if you call it undefined, I guess you automatically agree
this needs to be fixed. :)
As for the quick fix - why not to do this pre-init in fixed_link_update()
instead of adjust_link()? In fixed_link_update() you'll get the speed
right from DT, so it will be correct.
fixed_link_update() only gets called once you start your PHY state
machine, unfortunately, not upon fixed PHY device registration, and it
runs before your adjust_link callback does,
So you say fixed_link_update() runs before adjust_link callback does,
which looks logical. Why would you need it to run on device registration,
if it runs earlier than adjust_link (which you use for init) even now?
--
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/3] x86, perf: Add PEBS frontend profiling for Skylake
On Fri, Jul 17, 2015 at 4:31 PM, Andi Kleen wrote:
> On Fri, Jul 17, 2015 at 03:00:18PM -0700, Stephane Eranian wrote:
>> Andi,
>>
>> On Fri, Jul 17, 2015 at 2:19 PM, Andi Kleen wrote:
>> >> But then, the SDM is misleading. It is not describing what's
>> >> implemented for SKL.
>> >
>> > Actually it has a list of valid values you can put into the various fields.
>> > None of them have the bits set you're trying to set.
>> >
>> You are talking about the events (bit 0-7). I am talking about the bubble
>> thresholds. I am okay with the event list for bits 0-7.
>
> Fair enough. There's a one-off in the MSR table and table 18-54. The IDQ
> bubble width is only 21:20. I'll ask for that to be fixed in both places
> that document them.
>
There is still something broken here, if bit 22 is not implemented,
then you have
a bunch of frontend events in the SKL event table (download.01.org) which are
bogus:
{
"EventCode": "0xC6",
"UMask": "0x01",
"EventName": "FRONTEND_RETIRED.LATENCY_GE_8",
"BriefDescription": "Retired instructions that are fetched after
an interval where the front-end delivered no uops for a period of 8
cycles which was not interrupted by a back-end stall.",
"PublicDescription": "Retired instructions that are fetched after
an interval where the front-end delivered no uops for a period of 8
cycles which was not interrupted by a back-end stall.",
"Counter": "0,1,2,3",
"CounterHTOff": "0,1,2,3",
"SampleAfterValue": "17",
"MSRIndex": "0x3F7",
"MSRValue": "0x400806", <=
},
{
"EventCode": "0xC6",
"UMask": "0x01",
"EventName": "FRONTEND_RETIRED.LATENCY_GE_16",
"BriefDescription": "Retired instructions that are fetched after
an interval where the front-end delivered no uops for a period of 16
cycles which was not interrupted by a back-end stall.",
"PublicDescription": "Retired instructions that are fetched after
an interval where the front-end delivered no uops for a period of 16
cycles which was not interrupted by a back-end stall.",
"Counter": "0,1,2,3",
"CounterHTOff": "0,1,2,3",
"SampleAfterValue": "17",
"MSRIndex": "0x3F7",
"MSRValue": "0x401006", <=
...
},
{
"EventCode": "0xC6",
"UMask": "0x01",
"EventName": "FRONTEND_RETIRED.LATENCY_GE_32",
"BriefDescription": "Retired instructions that are fetched after
an interval where the front-end delivered no uops for a period of 32
cycles which was not interrupted by a back-end stall.",
"PublicDescription": "Retired instructions that are fetched after
an interval where the front-end delivered no uops for a period of 32
cycles which was not interrupted by a back-end stall.",
"Counter": "0,1,2,3",
"CounterHTOff": "0,1,2,3",
"SampleAfterValue": "17",
"MSRIndex": "0x3F7",
"MSRValue": "0x402006", <=
...
},
--
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 000/208] big x86 FPU code rewrite
On Tue, May 5, 2015 at 10:50 AM, Ingo Molnar wrote: > > * Linus Torvalds wrote: > >> On Tue, May 5, 2015 at 9:23 AM, Ingo Molnar wrote: >> > 83 files changed, 3742 insertions(+), 2841 deletions(-) >> >> How much of this is just the added instrumentation? [...] > > Half of it is that, plus a lot of comments. > >> [...] Because that's almost a thousand new lines, which makes me >> unhappy. The *last* thing we want is to make this thing bigger. >> [...] > > So Boris suggested that I should move fpu/measure.c out of the FPU > code anyway, which is fair enough, as it measures a lot of other low > level details as well. Consider it done. Where did the measurement code go? Regardless of where it lives, I liked it. --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: [PATCH RFC V1 3/3] devicetree: da9062: Add device tree bindings for DA9062 RTC
On 09/07/2015 at 08:45:54 +0100, S Twiss wrote :
> From: S Twiss
>
> Add device tree bindings for the DA9062 RTC driver component
>
> Signed-off-by: Steve Twiss
>
> ---
> Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
> da9062.txttotal: 0 errors, 0 warnings, 88 lines checked
> This patch applies against linux-next and next-20150708
>
>
> Documentation/devicetree/bindings/mfd/da9062.txt | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt
> b/Documentation/devicetree/bindings/mfd/da9062.txt
> index 5765ed9..38802b5 100644
> --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -5,6 +5,7 @@ DA9062 consists of a large and varied group of sub-devices:
> Device Supply NamesDescription
> -- ---
> da9062-regulator: : LDOs & BUCKs
> +da9062-rtc : : Real-Time Clock
> da9062-watchdog : : Watchdog Timer
>
> ==
> @@ -41,6 +42,10 @@ Sub-nodes:
>Documentation/devicetree/bindings/regulator/regulator.txt
>
>
> +- rtc : This node defines settings required for the Real-Time Clock
> associated
> + with the DA9062. There are currently no entries in this binding, however
> + compatible = "dlg,da9062-rtc" should be added if a node is created.
> +
> - watchdog: This node defines the settings for the watchdog driver associated
>with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be
> added
>if a node is created.
> @@ -55,6 +60,10 @@ Example:
> interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> interrupt-controller;
>
> + rtc {
> + compatible = "dlg,da9062-rtc";
> + };
> +
Are those subnodes even parsed? As the parent node is not compatible
with "simple-bus" or "simple-mfd", I guess not. You driver is probed
from the mfd_cells in da9063-core.c
> watchdog {
> compatible = "dlg,da9062-watchdog";
> };
> --
> end-of-patch for PATCH RFC V1
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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 0/7] Add rcu_sync infrastructure to avoid _expedited() in percpu-rwsem
On Sat, Jul 18, 2015 at 01:29:30AM +0200, Oleg Nesterov wrote: > On 07/15, Paul E. McKenney wrote: > > > > On Wed, Jul 15, 2015 at 09:36:01PM +0200, Oleg Nesterov wrote: > > > > > > Do you mean you need another user except percpu_rw_semaphore? I do > > > not see any right now... > > > > Not asking for more than one use, but it does need a use. I believe > > that percpu_rw_semaphore suffices. > > > > > Let me remind about sb_writers again. It actually has 3 rw_sem's > > > and I am trying to turn then into percpu_rw_semaphore's. > > > > > > In this case freeze_super() will need 6 synchronize_sched_expedited(). > > > This just looks ugly. But if we have rcu_sync primitives, all 3 sem's > > > in struct super_block can share the same "struct rcu_sync", and > > > freeze_super() will need only once synchronize_sched(). > > > > Makes sense. > > Great, thanks. And iiuc Linus doesn't object to this particular change. > Plus I see the "Make checkpatch.pl warn on expedited RCU grace periods" > patch ;) Note that it is a warning rather than an error. ;-) > So can I assume you will take these changes? > > I do not need them right now, just I need to know what should I do in > destroy_super() and (much more importantly) what should I say in the > changelogs if I try to convert sb_writers to use percpu_rw_semaphore. Yes, given a real use case, which you do appear to have, I will take these changes. Thanx, Paul -- 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 tip/core/rcu 4/6] rcutorture: Fix rcu_torture_cbflood() for callback-free RCU
From: "Paul E. McKenney"
The rcu_torture_cbflood() function correctly checks for flavors of
RCU that lack analogs to call_rcu() and rcu_barrier(), but in that
case it fails to terminate correctly. In fact, it terminates so
incorrectly that segfaults can result. This commit therefore causes
rcu_torture_cbflood() to do the proper wait-for-stop procedure.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 1cead7806ca6..e0eda3c1b621 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -823,9 +823,7 @@ rcu_torture_cbflood(void *arg)
}
if (err) {
VERBOSE_TOROUT_STRING("rcu_torture_cbflood disabled: Bad args
or OOM");
- while (!torture_must_stop())
- schedule_timeout_interruptible(HZ);
- return 0;
+ goto wait_for_stop;
}
VERBOSE_TOROUT_STRING("rcu_torture_cbflood task started");
do {
@@ -844,6 +842,7 @@ rcu_torture_cbflood(void *arg)
stutter_wait("rcu_torture_cbflood");
} while (!torture_must_stop());
vfree(rhp);
+wait_for_stop:
torture_kthread_stopping("rcu_torture_cbflood");
return 0;
}
--
1.8.1.5
--
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 RFC V1 2/3] rtc: da9063: Add DA9062 RTC capability to DA9063 RTC driver
Hi,
On 09/07/2015 at 08:45:53 +0100, S Twiss wrote :
> From: S Twiss
>
> Add DA9062 RTC support into the existing DA9063 RTC driver component by
> using generic access tables for common register and bit mask definitions.
>
> The following change will add generic register and bit mask support to the
> DA9063 RTC. The changes are slightly complicated by requiring support for
> three register sets: DA9063-AD, DA9063-BB and DA9062-AA.
>
> The following alterations have been made to the DA9063 RTC:
>
> - Addition of a da9063_compatible_rtc_regmap structure to hold all generic
> registers and bitmasks for this type of RTC component.
> - A re-write of struct da9063 to use pointers for regmap and compatible
> registers/masks definitions
> - Addition of a of_device_id table for DA9063 and DA9062 defaults
> - Refactoring functions to use struct da9063_compatible_rtc accesses to
> generic registers/masks instead of using defines from registers.h
> - Addition of a re-try when reading the RTC inside da9063_rtc_read_time()
Can you separate that change in another patch as it is a change in the
behaviour of the driver? And maybe give a word or two on why this is
needed.
> - Re-work of da9063_rtc_probe() to use of_match_node() and dev_get_regmap()
> to provide initialisation of generic registers and masks and access to
> regmap
>
> Signed-off-by: Steve Twiss
>
> ---
> Checks performed with linux-next/next-20150708/scripts/checkpatch.pl
> Kconfig total: 0 errors, 15 warnings, 1600 lines checked
> rtc-da9063.c total: 0 errors, 0 warnings, 531 lines checked
This is not true, there is a warning:
WARNING: DT compatible string "dlg,da9062-rtc" appears un-documented
-- check /home/alex/M/linux/Documentation/devicetree/bindings/
#275: FILE: drivers/rtc/rtc-da9063.c:171:
+ { .compatible = "dlg,da9062-rtc", .data = _aa_regs },
patch 3/3 should come before 2/3 if you want to avoid that.
> diff --git a/drivers/rtc/rtc-da9063.c b/drivers/rtc/rtc-da9063.c
> index 7ffc570..e94fb6d 100644
> --- a/drivers/rtc/rtc-da9063.c
> +++ b/drivers/rtc/rtc-da9063.c
> @@ -1,127 +1,274 @@
> -/* rtc-da9063.c - Real time clock device driver for DA9063
> - * Copyright (C) 2013-14 Dialog Semiconductor Ltd.
> +/*
> + * Real time clock device driver for DA9063/DA9062
> + * Copyright (C) 2013-15 Dialog Semiconductor Ltd.
> *
> - * This library is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Library General Public
> - * License as published by the Free Software Foundation; either
> - * version 2 of the License, or (at your option) any later version.
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> *
> - * This library is distributed in the hope that it will be useful,
> + * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - * Library General Public License for more details.
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> */
>
Please also list that license change in the commit log. It should also
probably be separated in another patch.
[...]
> static int da9063_rtc_probe(struct platform_device *pdev)
> {
> - struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
> - struct da9063_rtc *rtc;
> + struct da9063_compatible_rtc *rtc;
> + const struct da9063_compatible_rtc_regmap *config;
> + const struct of_device_id *match;
> int irq_alarm;
> u8 data[RTC_DATA_LEN];
> int ret;
>
> - ret = regmap_update_bits(da9063->regmap, DA9063_REG_CONTROL_E,
> - DA9063_RTC_EN, DA9063_RTC_EN);
> + match = of_match_node(da9063_compatible_reg_id_table,
> + pdev->dev.of_node);
> + if (!match)
This will never happen if you are only probed from DT and this is waht
you expect now.
> + return -ENXIO;
> +
> + rtc = devm_kzalloc(>dev, sizeof(*rtc), GFP_KERNEL);
> + if (!rtc)
> + return -ENOMEM;
> +
> + if (strncmp(match->name, "dlg,da9063-rtc", 14) == 0) {
You must not do that.
You should add a new compatible and change the of_compatible string of
the mfd_cell in drivers/mfd/da9063-core.c onc you know the variant.
> + struct da9063 *chip = dev_get_drvdata(pdev->dev.parent);
> +
> + if (chip->variant_code == PMIC_DA9063_AD)
> + rtc->config = _ad_regs;
> + } else
> + rtc->config = match->data;
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from
[PATCH tip/core/rcu 0/6] Torture-test updates for 4.3
Hello! This series contains torture-test updates: 1. Improve bounds checking for n_barrier_cbs: No more negatives. 2. Improve bounds checking for nfakewriters: No more negatives. 3. Improve bounds checking for shuffle_interval: No more negatives. 4. Fix rcu_torture_cbflood() for callback-free RCU to avoid occasional segfaults when disabled. 5. Add RCU-tasks qualifier to dereference to avoid lockdep false positives during torture testing. 6. Enable lockdep-RCU on TASKS01 to improve test coverage. Thanx, Paul b/kernel/rcu/rcutorture.c| 40 ++- b/tools/testing/selftests/rcutorture/configs/rcu/TASKS01 |4 - 2 files changed, 29 insertions(+), 15 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 tip/core/rcu 3/6] rcutorture: Bounds-check rcutorture.shuffle_interval
From: "Paul E. McKenney"
Specifying a negative rcutorture.shuffle_interval value will cause a
negative value to be used as a sleep time. This commit therefore
refuses to start shuffling unless the rcutorture.shuffle_interval
value is greater than zero.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 2cbe569ac5dd..1cead7806ca6 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -1821,7 +1821,7 @@ rcu_torture_init(void)
if (firsterr)
goto unwind;
}
- if (test_no_idle_hz) {
+ if (test_no_idle_hz && shuffle_interval > 0) {
firsterr = torture_shuffle_init(shuffle_interval * HZ);
if (firsterr)
goto unwind;
--
1.8.1.5
--
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 tip/core/rcu 2/6] rcutorture: Check nfakewriters parameter
From: "Paul E. McKenney"
Currently, a negative value for rcutorture.nfakewriters= can cause
rcutorture to pass a negative size to the memory allocator, which
is not really a particularly good thing to do. This commit therefore
adds bounds checking to this parameter, so that values that are less
than or equal to zero disable fake writing.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 7e29a3266139..2cbe569ac5dd 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -1786,12 +1786,15 @@ rcu_torture_init(void)
writer_task);
if (firsterr)
goto unwind;
- fakewriter_tasks = kzalloc(nfakewriters * sizeof(fakewriter_tasks[0]),
- GFP_KERNEL);
- if (fakewriter_tasks == NULL) {
- VERBOSE_TOROUT_ERRSTRING("out of memory");
- firsterr = -ENOMEM;
- goto unwind;
+ if (nfakewriters > 0) {
+ fakewriter_tasks = kzalloc(nfakewriters *
+ sizeof(fakewriter_tasks[0]),
+ GFP_KERNEL);
+ if (fakewriter_tasks == NULL) {
+ VERBOSE_TOROUT_ERRSTRING("out of memory");
+ firsterr = -ENOMEM;
+ goto unwind;
+ }
}
for (i = 0; i < nfakewriters; i++) {
firsterr = torture_create_kthread(rcu_torture_fakewriter,
--
1.8.1.5
--
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 tip/core/rcu 5/6] rcutorture: Add RCU-tasks qualifier to dereference
From: "Paul E. McKenney"
Although RCU-tasks isn't really designed to support rcu_dereference()
and list manipulation, that is how rcutorture tests it. Which means
that lockdep-RCU complains about the rcu_dereference_check() invocations
because RCU-tasks doesn't have read-side markers. This commit therefore
creates a torturing_tasks() to silence the lockdep-RCU complaints from
rcu_dereference_check() when RCU-tasks is being tortured.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index e0eda3c1b621..67b3f260720e 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -684,10 +684,20 @@ static struct rcu_torture_ops tasks_ops = {
#define RCUTORTURE_TASKS_OPS _ops,
+static bool __maybe_unused torturing_tasks(void)
+{
+ return cur_ops == _ops;
+}
+
#else /* #ifdef CONFIG_TASKS_RCU */
#define RCUTORTURE_TASKS_OPS
+static bool torturing_tasks(void)
+{
+ return false;
+}
+
#endif /* #else #ifdef CONFIG_TASKS_RCU */
/*
@@ -1087,7 +1097,8 @@ static void rcu_torture_timer(unsigned long unused)
p = rcu_dereference_check(rcu_torture_current,
rcu_read_lock_bh_held() ||
rcu_read_lock_sched_held() ||
- srcu_read_lock_held(srcu_ctlp));
+ srcu_read_lock_held(srcu_ctlp) ||
+ torturing_tasks());
if (p == NULL) {
/* Leave because rcu_torture_writer is not yet underway */
cur_ops->readunlock(idx);
@@ -1161,7 +1172,8 @@ rcu_torture_reader(void *arg)
p = rcu_dereference_check(rcu_torture_current,
rcu_read_lock_bh_held() ||
rcu_read_lock_sched_held() ||
- srcu_read_lock_held(srcu_ctlp));
+ srcu_read_lock_held(srcu_ctlp) ||
+ torturing_tasks());
if (p == NULL) {
/* Wait for rcu_torture_writer to get underway */
cur_ops->readunlock(idx);
--
1.8.1.5
--
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 tip/core/rcu 6/6] rcutorture: Enable lockdep-RCU on TASKS01
From: "Paul E. McKenney" Currently none of the RCU-tasks scenarios enables lockdep-RCU, which causes bugs to be missed. This commit therefore enables lockdep-RCU on TASKS01. Signed-off-by: Paul E. McKenney --- tools/testing/selftests/rcutorture/configs/rcu/TASKS01 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TASKS01 b/tools/testing/selftests/rcutorture/configs/rcu/TASKS01 index 2cc0e60eba6e..bafe94cbd739 100644 --- a/tools/testing/selftests/rcutorture/configs/rcu/TASKS01 +++ b/tools/testing/selftests/rcutorture/configs/rcu/TASKS01 @@ -5,6 +5,6 @@ CONFIG_PREEMPT_NONE=n CONFIG_PREEMPT_VOLUNTARY=n CONFIG_PREEMPT=y CONFIG_DEBUG_LOCK_ALLOC=y -CONFIG_PROVE_LOCKING=n -#CHECK#CONFIG_PROVE_RCU=n +CONFIG_PROVE_LOCKING=y +#CHECK#CONFIG_PROVE_RCU=y CONFIG_RCU_EXPERT=y -- 1.8.1.5 -- 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 tip/core/rcu 1/6] rcutorture: Better bounds checking for n_barrier_cbs
From: "Paul E. McKenney"
A negative value for rcutorture.n_barrier_cbs can pass a negative value
to the memory allocator, so this commit instead causes rcu_barrier()
testing to be disabled in this case.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 59e32684c23b..7e29a3266139 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -1507,7 +1507,7 @@ static int rcu_torture_barrier_init(void)
int i;
int ret;
- if (n_barrier_cbs == 0)
+ if (n_barrier_cbs <= 0)
return 0;
if (cur_ops->call == NULL || cur_ops->cb_barrier == NULL) {
pr_alert("%s" TORTURE_FLAG
--
1.8.1.5
--
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] input: Drop owner assignment from i2c_driver
On Fri, Jul 10, 2015 at 03:00:33PM +0900, Krzysztof Kozlowski wrote:
> i2c_driver does not need to set an owner because i2c_register_driver()
> will set it.
>
> Signed-off-by: Krzysztof Kozlowski
Applied, thank you.
>
> ---
>
> The coccinelle script which generated the patch was sent here:
> http://www.spinics.net/lists/kernel/msg2029903.html
> ---
> drivers/input/keyboard/adp5589-keys.c | 1 -
> drivers/input/keyboard/cap11xx.c| 1 -
> drivers/input/keyboard/lm8333.c | 1 -
> drivers/input/keyboard/mcs_touchkey.c | 1 -
> drivers/input/keyboard/mpr121_touchkey.c| 1 -
> drivers/input/keyboard/qt1070.c | 1 -
> drivers/input/keyboard/qt2160.c | 1 -
> drivers/input/keyboard/tca8418_keypad.c | 1 -
> drivers/input/misc/adxl34x-i2c.c| 1 -
> drivers/input/misc/bma150.c | 1 -
> drivers/input/misc/cma3000_d0x_i2c.c| 1 -
> drivers/input/misc/drv260x.c| 1 -
> drivers/input/misc/drv2665.c| 1 -
> drivers/input/misc/drv2667.c| 1 -
> drivers/input/misc/gp2ap002a00f.c | 1 -
> drivers/input/misc/kxtj9.c | 1 -
> drivers/input/misc/mpu3050.c| 1 -
> drivers/input/misc/pcf8574_keypad.c | 1 -
> drivers/input/mouse/cyapa.c | 1 -
> drivers/input/mouse/elan_i2c_core.c | 1 -
> drivers/input/mouse/synaptics_i2c.c | 1 -
> drivers/input/touchscreen/ad7879-i2c.c | 1 -
> drivers/input/touchscreen/ar1021_i2c.c | 1 -
> drivers/input/touchscreen/atmel_mxt_ts.c| 1 -
> drivers/input/touchscreen/auo-pixcir-ts.c | 1 -
> drivers/input/touchscreen/bu21013_ts.c | 1 -
> drivers/input/touchscreen/chipone_icn8318.c | 1 -
> drivers/input/touchscreen/cy8ctmg110_ts.c | 1 -
> drivers/input/touchscreen/cyttsp4_i2c.c | 1 -
> drivers/input/touchscreen/cyttsp_i2c.c | 1 -
> drivers/input/touchscreen/edt-ft5x06.c | 1 -
> drivers/input/touchscreen/egalax_ts.c | 1 -
> drivers/input/touchscreen/elants_i2c.c | 1 -
> drivers/input/touchscreen/goodix.c | 1 -
> drivers/input/touchscreen/ili210x.c | 1 -
> drivers/input/touchscreen/max11801_ts.c | 1 -
> drivers/input/touchscreen/mms114.c | 1 -
> drivers/input/touchscreen/pixcir_i2c_ts.c | 1 -
> drivers/input/touchscreen/st1232.c | 1 -
> drivers/input/touchscreen/tsc2007.c | 1 -
> drivers/input/touchscreen/wacom_i2c.c | 1 -
> drivers/input/touchscreen/zforce_ts.c | 1 -
> 42 files changed, 42 deletions(-)
>
> diff --git a/drivers/input/keyboard/adp5589-keys.c
> b/drivers/input/keyboard/adp5589-keys.c
> index 6ed83cf8b74e..4d446d5085aa 100644
> --- a/drivers/input/keyboard/adp5589-keys.c
> +++ b/drivers/input/keyboard/adp5589-keys.c
> @@ -1097,7 +1097,6 @@ MODULE_DEVICE_TABLE(i2c, adp5589_id);
> static struct i2c_driver adp5589_driver = {
> .driver = {
> .name = KBUILD_MODNAME,
> - .owner = THIS_MODULE,
> .pm = _dev_pm_ops,
> },
> .probe = adp5589_probe,
> diff --git a/drivers/input/keyboard/cap11xx.c
> b/drivers/input/keyboard/cap11xx.c
> index f07461a64d85..b58fd9d72d92 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
> @@ -361,7 +361,6 @@ MODULE_DEVICE_TABLE(i2c, cap11xx_i2c_ids);
> static struct i2c_driver cap11xx_i2c_driver = {
> .driver = {
> .name = "cap11xx",
> - .owner = THIS_MODULE,
> .of_match_table = cap11xx_dt_ids,
> },
> .id_table = cap11xx_i2c_ids,
> diff --git a/drivers/input/keyboard/lm8333.c b/drivers/input/keyboard/lm8333.c
> index 0ad422b8a260..c717e8f3c964 100644
> --- a/drivers/input/keyboard/lm8333.c
> +++ b/drivers/input/keyboard/lm8333.c
> @@ -223,7 +223,6 @@ MODULE_DEVICE_TABLE(i2c, lm8333_id);
> static struct i2c_driver lm8333_driver = {
> .driver = {
> .name = "lm8333",
> - .owner = THIS_MODULE,
> },
> .probe = lm8333_probe,
> .remove = lm8333_remove,
> diff --git a/drivers/input/keyboard/mcs_touchkey.c
> b/drivers/input/keyboard/mcs_touchkey.c
> index 375b05ca8e2a..31090d71a685 100644
> --- a/drivers/input/keyboard/mcs_touchkey.c
> +++ b/drivers/input/keyboard/mcs_touchkey.c
> @@ -265,7 +265,6 @@ MODULE_DEVICE_TABLE(i2c, mcs_touchkey_id);
> static struct i2c_driver mcs_touchkey_driver = {
> .driver = {
> .name = "mcs_touchkey",
> - .owner = THIS_MODULE,
> .pm = _touchkey_pm_ops,
> },
> .probe = mcs_touchkey_probe,
> diff --git a/drivers/input/keyboard/mpr121_touchkey.c
> b/drivers/input/keyboard/mpr121_touchkey.c
> index 3aa2ec45bcab..0fd612dd76ed 100644
> --- a/drivers/input/keyboard/mpr121_touchkey.c
> +++ b/drivers/input/keyboard/mpr121_touchkey.c
> @@ -305,7 +305,6 @@
Re: [PATCH v9 07/22] tracing: Add lock-free tracing_map
On Fri, 2015-07-17 at 15:48 +, Mathieu Desnoyers wrote: > - On Jul 16, 2015, at 9:35 PM, Tom Zanussi tom.zanu...@linux.intel.com > wrote: > > > Hi Mathieu, > > > > On Thu, 2015-07-16 at 23:25 +, Mathieu Desnoyers wrote: > >> * Tom Zanussi wrote: > >> >> Add tracing_map, a special-purpose lock-free map for tracing. > >> >> > >> >> tracing_map is designed to aggregate or 'sum' one or more values > >> >> associated with a specific object of type tracing_map_elt, which > >> >> is associated by the map to a given key. > >> >> > >> >> It provides various hooks allowing per-tracer customization and is > >> >> separated out into a separate file in order to allow it to be shared > >> >> between multiple tracers, but isn't meant to be generally used outside > >> >> of that context. > >> >> > >> >> The tracing_map implementation was inspired by lock-free map > >> >> algorithms originated by Dr. Cliff Click: > >> >> > >> >> http://www.azulsystems.com/blog/cliff/2007-03-26-non-blocking-hashtable > >> >> http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf > >> > >> Hi Tom, > >> > >> First question: what is the rationale for implementing another > >> hash table from scratch here ? What is missing in the pre-existing > >> hash table implementations ? > >> > > > > None of the other hash tables allow for lock-free insertion (and I > > didn't see an easy way to add it). > > This is one of the nice things about the Userspace RCU lock-free hash > table we've done a few years ago: it provides lock-free add, add_unique, > removal, and replace, as well as RCU wait-free lookups and traversals. > Resize can be done concurrently by a worker thread. I ported it to the > Linux kernel for Julien's work on latency tracker. You can find the > implementation here: https://github.com/jdesfossez/latency_tracker > (see rculfhash*) > It is a simplified version that has the "resize" feature removed for > simplicity sake. The "insert and lookup" feature you need is called > "add_unique" in our API: it behaves both as a lookup and as an atomic > insert if the key is not found. > Interesting, but it's just as much not upstream as mine is. ;-) >From the perspective of the hist triggers, it doesn't matter what hash table implementation it uses as long as whatever it is supports insertion in any context. In fact the current tracing_map implementation is already the second completely different implementation it's plugged into (see v2 of this patchset for the first). If yours is better and going upstream, I'd be happy to make it the third and forget about mine. Tom > Thanks, > > Mathieu > > > > >> Moreover, you might want to handle the case where jhash() returns > >> 0. AFAIU, there is a race on "insert" in this scenario. > >> > > > > You're right, in that case you'd accidentally overwrite an already > > claimed slot. Thanks for pointing that out. > > > > Tom > > > >> Thanks, > >> > >> Mathieu > >> > >> >> > >> >> Signed-off-by: Tom Zanussi > >> >> --- > >> >> kernel/trace/Makefile | 1 + > >> >> kernel/trace/tracing_map.c | 935 > >> >> + > >> >> kernel/trace/tracing_map.h | 258 + > >> >> 3 files changed, 1194 insertions(+) > >> >> create mode 100644 kernel/trace/tracing_map.c > >> >> create mode 100644 kernel/trace/tracing_map.h > >> >> > >> >> diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile > >> >> index 9b1044e..3b26cfb 100644 > >> >> --- a/kernel/trace/Makefile > >> >> +++ b/kernel/trace/Makefile > >> >> @@ -31,6 +31,7 @@ obj-$(CONFIG_TRACING) += trace_output.o > >> >> obj-$(CONFIG_TRACING) += trace_seq.o > >> >> obj-$(CONFIG_TRACING) += trace_stat.o > >> >> obj-$(CONFIG_TRACING) += trace_printk.o > >> >> +obj-$(CONFIG_TRACING) += tracing_map.o > >> >> obj-$(CONFIG_CONTEXT_SWITCH_TRACER) += trace_sched_switch.o > >> >> obj-$(CONFIG_FUNCTION_TRACER) += trace_functions.o > >> >> obj-$(CONFIG_IRQSOFF_TRACER) += trace_irqsoff.o > >> >> diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c > >> >> new file mode 100644 > >> >> index 000..a505025 > >> >> --- /dev/null > >> >> +++ b/kernel/trace/tracing_map.c > >> >> @@ -0,0 +1,935 @@ > >> >> +/* > >> >> + * tracing_map - lock-free map for tracing > >> >> + * > >> >> + * This program is free software; you can redistribute it and/or modify > >> >> + * it under the terms of the GNU General Public License as published by > >> >> + * the Free Software Foundation; either version 2 of the License, or > >> >> + * (at your option) any later version. > >> >> + * > >> >> + * This program is distributed in the hope that it will be useful, > >> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of > >> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >> >> + * GNU General Public License for more details. > >> >> + * > >> >> + * Copyright (C) 2015 Tom Zanussi > >> >> + * > >> >> + * tracing_map implementation inspired by
Re: [PATCH v2 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50
Hi Sanchayan,
On Thu, Jul 16, 2015 at 08:43:21PM +0530, Sanchayan Maity wrote:
> The Colibri Vybrid VF50 module supports 4-wire touchscreens using
> FETs and ADC inputs. This driver uses the IIO consumer interface
> and relies on the vf610_adc driver based on the IIO framework.
This looks pretty good, thank you. Just a few comments below.
>
> Signed-off-by: Sanchayan Maity
> ---
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/colibri-vf50-ts.c | 451
>
> 3 files changed, 464 insertions(+)
> create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 80f6386..28948ca 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
> To compile this driver as a module, choose M here: the
> module will be called zforce_ts.
>
> +config TOUCHSCREEN_COLIBRI_VF50
> + tristate "Toradex Colibri on board touchscreen driver"
> + depends on GPIOLIB && IIO && VF610_ADC
> + help
> + Say Y here if you have a Colibri VF50 and plan to use
> + the on-board provided 4-wire touchscreen driver.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called colibri_vf50_ts.
> +
> endif
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index 44deea7..93746a0 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
> obj-$(CONFIG_TOUCHSCREEN_SX8654) += sx8654.o
> obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
> obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
> diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c
> b/drivers/input/touchscreen/colibri-vf50-ts.c
> new file mode 100644
> index 000..eb16bdc
> --- /dev/null
> +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
> @@ -0,0 +1,451 @@
> +/* Copyright 2015 Toradex AG
> + *
> + * Toradex Colibri VF50 Touchscreen driver
> + *
> + * Originally authored by Stefan Agner for 3.0 kernel
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
Why?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Is not used as far as I can see.
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "colibri-vf50-ts"
> +#define DRV_VERSION "1.0"
> +
> +#define VF_ADC_MAX ((1 << 12) - 1)
> +
> +#define COLI_TOUCH_MIN_DELAY_US 1000
> +#define COLI_TOUCH_MAX_DELAY_US 2000
> +
> +static int min_pressure = 200;
> +
> +struct vf50_touch_device {
> + struct platform_device *pdev;
> + struct input_dev*ts_input;
> + struct workqueue_struct *ts_workqueue;
> + struct work_struct ts_work;
> + struct iio_channel *channels;
> + struct gpio_desc *gpio_xp;
> + struct gpio_desc *gpio_xm;
> + struct gpio_desc *gpio_yp;
> + struct gpio_desc *gpio_ym;
> + struct gpio_desc *gpio_pen_detect;
> + struct gpio_desc *gpio_pen_detect_pullup;
> + int pen_irq;
> + bool stop_touchscreen;
> +};
> +
> +/*
> + * Enables given plates and measures touch parameters using ADC
> + */
> +static int adc_ts_measure(struct iio_channel *channel,
> + struct gpio_desc *plate_p, struct gpio_desc *plate_m)
> +{
> + int i, value = 0, val = 0;
> + int ret;
> +
> + gpiod_set_value(plate_p, 1);
> + gpiod_set_value(plate_m, 1);
> +
> + usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
> +
> + for (i = 0; i < 5; i++) {
> + ret = iio_read_channel_raw(channel, );
> + if (ret < 0)
> + return -EINVAL;
> +
> + value += val;
> + }
> +
> + value /= 5;
> +
> + gpiod_set_value(plate_p, 0);
> + gpiod_set_value(plate_m, 0);
> +
> + return value;
> +}
> +
> +/*
> + * Enable touch detection using falling edge detection on XM
> + */
> +static void vf50_ts_enable_touch_detection(struct vf50_touch_device *vf50_ts)
> +{
> + /* Enable plate YM (needs to be strong GND, high active) */
> + gpiod_set_value(vf50_ts->gpio_ym, 1);
> +
> + /*
> + * Let the platform mux to idle state in order to enable
> + * Pull-Up on GPIO
> + */
> + pinctrl_pm_select_idle_state(_ts->pdev->dev);
> +}
> +
> +/*
> + * ADC touch screen sampling worker function
> + */
> +static
Re: [PATCH 1/3] fixed_phy: handle link-down case
On 17/07/15 16:24, Stas Sergeev wrote: > 18.07.2015 01:01, Florian Fainelli пишет: >> On 17/07/15 13:03, Stas Sergeev wrote: >>> 17.07.2015 21:50, Florian Fainelli пишет: On 17/07/15 04:26, Stas Sergeev wrote: > 17.07.2015 02:25, Florian Fainelli пишет: >> On 16/07/15 07:50, Stas Sergeev wrote: >>> Currently fixed_phy driver recognizes only the link-up state. >>> This simple patch adds an implementation of link-down state. >>> It fixes the status registers when link is down, and also allows >>> to register the fixed-phy with link down without specifying the >>> speed. >> This patch still breaks my setups here, e.g: >> drivers/net/dsa/bcm_sf2.c, >> but I will look into it. >> >> Do we really need this for now for your two other patches to work >> properly, or is it just nicer to have? > Yes, absolutely. > Otherwise registering fixed phy will return -EINVAL > because of the missing link speed (even though the link > is down). Ok, I see the problem that you have now. Arguably you could say that according to the fixed-link binding, speed needs to be specified and the code correctly errors out with such an error if you do not specify it. I >>> Aren't you missing the fact that .link=0? >>> I think what you say is true only for the link-up case, no? >>> .speed==0 is valid for link-down IMHO: no link - zero speed. >> Pardon me being very dense and stupid here, but your problem is that the >> "speed" parameter is not specified in your DT, > Not even a fixed-link at all, since the latest patches. > I removed fixed-link defs from my DT. Hummm, okay, so you just have the inband-status property and that's it, not even a fixed-link node anymore, right? How does mvneta_fixed_link_update() work then since it needs a fixed PHY to be registered? > >> and we end-up returning >> -EINVAL from of_phy_register_fixed_link(), is that what is happening? > Yes. > >> And even if we silenced that error, > I don't agree with calling it an error silencing. > To me it is a fix. It will also return a more correct status when > link is down. > >> we would end-up calling >> fixed_phy_add() which would also return -EINVAL because then, we would >> have status.link = 1, but no speed. > Why link=1 and no speed? This is not valid, should never > be used. The error checking is still there to prevent it. > >> So I better understand what is it >> that you are after here, and that is also a broken Device Tree, is not >> it? > I don't understand. If you didn't specify the in-band status, you > _must_ set the speed. There is no broken DT in either case. > >> So this was the reason why in earlier versions of the patchset you >> ended-up with a given speed which would make us pass this condition, >> right? > As explained earlier, yes. > > So is different is that I use a link_update callback, and so we rely on at least one call of this function to initialize the hardware in drivers/net/dsa/bcm_sf2.c >>> Do you mean this?: >>> core_writel(priv, reg, CORE_STS_OVERRIDE_GMIIP_PORT(port)); >>> Maybe just moving the HW initialization bits to some init func >>> will be a quick fix? >> Well, the problem with that is that to know how we should be configuring >> the hardware in the adjust_link function, we need to run the link_update >> function first. By default, there is no auto-negotiation on these fixed >> links at all, so we cannot rely on any value being programmed other than >> those specified in DT. > Ah, so is my understanding correct that in fixed_link_update() > you set .link=0 and as a result get wrong speed in adjust_link(), > which gets then written to init HW? Yes, that's what happens. > AFAIK when link is down, you are not allowed to rely on the PHY > status registers to read speed from, or am I wrong? So if my > understanding is correct, this was working by a pure luck. Well, it's more like it is undefined, and before this patch, the fixed PHY would update everything except the link status indication. > As for the quick fix - why not to do this pre-init in fixed_link_update() > instead of adjust_link()? In fixed_link_update() you'll get the speed > right from DT, so it will be correct. fixed_link_update() only gets called once you start your PHY state machine, unfortunately, not upon fixed PHY device registration, and it runs before your adjust_link callback does, that's why starting with correct parameters is kind of important here. Of course, this could be fixed. > >> The changes are not trivial, it took a while to get that logic done > For a longer term fix, > how about adding a *status arg to of_phy_register_fixed_link() to > always get the status back to the driver, unless NULL is provided? > Using an update callback for that doesn't look like the best thing > to do. And besides, if we move to my fixed_phy_update_state(), > this will be needed anyway. I agree that the link_update callback is not the
[PATCH tip/core/rcu 18/19] rcu: Rename RCU_GP_DONE_FQS to RCU_GP_DOING_FQS
From: "Paul E. McKenney"
The grace-period kthread sleeps waiting to do a force-quiescent-state
scan, and when awakened sets rsp->gp_state to RCU_GP_DONE_FQS.
However, this is confusing because the kthread has not done the
force-quiescent-state, but is instead just starting to do it. This commit
therefore renames RCU_GP_DONE_FQS to RCU_GP_DOING_FQS in order to make
things a bit easier on reviewers.
Reported-by: Peter Zijlstra
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 2 +-
kernel/rcu/tree.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index b2803730ac13..f66f6e7730bc 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2088,7 +2088,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
rsp->gp_state = RCU_GP_WAIT_FQS;
ret = wait_event_interruptible_timeout(rsp->gp_wq,
rcu_gp_fqs_check_wake(rsp, ), j);
- rsp->gp_state = RCU_GP_DONE_FQS;
+ rsp->gp_state = RCU_GP_DOING_FQS;
/* Locking provides needed memory barriers. */
/* If grace period done, leave loop. */
if (!READ_ONCE(rnp->qsmask) &&
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index b3ae8d3cffbc..543ba726396c 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -535,7 +535,7 @@ struct rcu_state {
#define RCU_GP_WAIT_GPS 1 /* Wait for grace-period start. */
#define RCU_GP_DONE_GPS 2 /* Wait done for grace-period start. */
#define RCU_GP_WAIT_FQS 3 /* Wait for force-quiescent-state time. */
-#define RCU_GP_DONE_FQS 4 /* Wait done for force-quiescent-state time. */
+#define RCU_GP_DOING_FQS 4 /* Wait done for force-quiescent-state time. */
#define RCU_GP_CLEANUP 5 /* Grace-period cleanup started. */
#define RCU_GP_CLEANED 6 /* Grace-period cleanup complete. */
--
1.8.1.5
--
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 tip/core/rcu 03/19] rcu: Switch synchronize_sched_expedited() to stop_one_cpu()
From: Peter Zijlstra
The synchronize_sched_expedited() currently invokes try_stop_cpus(),
which schedules the stopper kthreads on each online non-idle CPU,
and waits until all those kthreads are running before letting any
of them stop. This is disastrous for real-time workloads, which
get hit with a preemption that is as long as the longest scheduling
latency on any CPU, including any non-realtime housekeeping CPUs.
This commit therefore switches to using stop_one_cpu() on each CPU
in turn. This avoids inflicting the worst-case scheduling latency
on the worst-case CPU onto all other CPUs, and also simplifies the
code a little bit.
Follow-up commits will simplify the counter-snapshotting algorithm
and convert a number of the counters that are now protected by the
new ->expedited_mutex to non-atomic.
Signed-off-by: Peter Zijlstra
[ paulmck: Kept stop_one_cpu(), dropped disabling of "guardrails". ]
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 41 ++---
kernel/rcu/tree.h | 1 +
2 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index a2147d7b51c0..ae39a49daa58 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -103,6 +103,7 @@ struct rcu_state sname##_state = { \
.orphan_nxttail = ##_state.orphan_nxtlist, \
.orphan_donetail = ##_state.orphan_donelist, \
.barrier_mutex = __MUTEX_INITIALIZER(sname##_state.barrier_mutex), \
+ .expedited_mutex = __MUTEX_INITIALIZER(sname##_state.expedited_mutex), \
.name = RCU_STATE_NAME(sname), \
.abbr = sabbr, \
}
@@ -3305,8 +3306,6 @@ static int synchronize_sched_expedited_cpu_stop(void
*data)
*/
void synchronize_sched_expedited(void)
{
- cpumask_var_t cm;
- bool cma = false;
int cpu;
long firstsnap, s, snap;
int trycount = 0;
@@ -3342,28 +3341,11 @@ void synchronize_sched_expedited(void)
}
WARN_ON_ONCE(cpu_is_offline(raw_smp_processor_id()));
- /* Offline CPUs, idle CPUs, and any CPU we run on are quiescent. */
- cma = zalloc_cpumask_var(, GFP_KERNEL);
- if (cma) {
- cpumask_copy(cm, cpu_online_mask);
- cpumask_clear_cpu(raw_smp_processor_id(), cm);
- for_each_cpu(cpu, cm) {
- struct rcu_dynticks *rdtp = _cpu(rcu_dynticks, cpu);
-
- if (!(atomic_add_return(0, >dynticks) & 0x1))
- cpumask_clear_cpu(cpu, cm);
- }
- if (cpumask_weight(cm) == 0)
- goto all_cpus_idle;
- }
-
/*
* Each pass through the following loop attempts to force a
* context switch on each CPU.
*/
- while (try_stop_cpus(cma ? cm : cpu_online_mask,
-synchronize_sched_expedited_cpu_stop,
-NULL) == -EAGAIN) {
+ while (!mutex_trylock(>expedited_mutex)) {
put_online_cpus();
atomic_long_inc(>expedited_tryfail);
@@ -3373,7 +3355,6 @@ void synchronize_sched_expedited(void)
/* ensure test happens before caller kfree */
smp_mb__before_atomic(); /* ^^^ */
atomic_long_inc(>expedited_workdone1);
- free_cpumask_var(cm);
return;
}
@@ -3383,7 +3364,6 @@ void synchronize_sched_expedited(void)
} else {
wait_rcu_gp(call_rcu_sched);
atomic_long_inc(>expedited_normal);
- free_cpumask_var(cm);
return;
}
@@ -3393,7 +3373,6 @@ void synchronize_sched_expedited(void)
/* ensure test happens before caller kfree */
smp_mb__before_atomic(); /* ^^^ */
atomic_long_inc(>expedited_workdone2);
- free_cpumask_var(cm);
return;
}
@@ -3408,16 +3387,23 @@ void synchronize_sched_expedited(void)
/* CPU hotplug operation in flight, use normal GP. */
wait_rcu_gp(call_rcu_sched);
atomic_long_inc(>expedited_normal);
- free_cpumask_var(cm);
return;
}
snap = atomic_long_read(>expedited_start);
smp_mb(); /* ensure read is before try_stop_cpus(). */
}
- atomic_long_inc(>expedited_stoppedcpus);
-all_cpus_idle:
- free_cpumask_var(cm);
+ /* Stop each CPU that is online, non-idle, and not us. */
+ for_each_online_cpu(cpu) {
+ struct rcu_dynticks *rdtp = _cpu(rcu_dynticks, cpu);
+
+ /* Skip our CPU and any idle CPUs. */
+ if (raw_smp_processor_id() == cpu ||
+
[PATCH tip/core/rcu 02/19] rcu: Remove CONFIG_RCU_CPU_STALL_INFO
From: "Paul E. McKenney"
The CONFIG_RCU_CPU_STALL_INFO has been default-y for a couple of
releases with no complaints, so it is time to eliminate this Kconfig
option entirely, so that the long-form RCU CPU stall warnings cannot
be disabled. This commit does just that.
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/stallwarn.txt| 12 +-
kernel/rcu/tree.h | 4 --
kernel/rcu/tree_plugin.h | 45 --
lib/Kconfig.debug | 14 ---
.../selftests/rcutorture/configs/rcu/TREE01| 1 -
.../selftests/rcutorture/configs/rcu/TREE02| 1 -
.../selftests/rcutorture/configs/rcu/TREE02-T | 1 -
.../selftests/rcutorture/configs/rcu/TREE03| 1 -
.../selftests/rcutorture/configs/rcu/TREE04| 1 -
.../selftests/rcutorture/configs/rcu/TREE05| 1 -
.../selftests/rcutorture/configs/rcu/TREE06| 1 -
.../selftests/rcutorture/configs/rcu/TREE07| 1 -
.../selftests/rcutorture/configs/rcu/TREE08| 1 -
.../selftests/rcutorture/configs/rcu/TREE08-T | 1 -
.../selftests/rcutorture/configs/rcu/TREE09| 1 -
.../selftests/rcutorture/doc/TREE_RCU-kconfig.txt | 1 -
16 files changed, 2 insertions(+), 85 deletions(-)
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index b57c0c1cdac6..046f32637b95 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -26,12 +26,6 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
Stall-warning messages may be enabled and disabled completely via
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.
-CONFIG_RCU_CPU_STALL_INFO
-
- This kernel configuration parameter causes the stall warning to
- print out additional per-CPU diagnostic information, including
- information on scheduling-clock ticks and RCU's idle-CPU tracking.
-
RCU_STALL_DELAY_DELTA
Although the lockdep facility is extremely useful, it does add
@@ -101,15 +95,13 @@ interact. Please note that it is not possible to entirely
eliminate this
sort of false positive without resorting to things like stop_machine(),
which is overkill for this sort of problem.
-If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
-more information is printed with the stall-warning message, for example:
+Recent kernels will print a long form of the stall-warning message:
INFO: rcu_preempt detected stall on CPU
0: (63959 ticks this GP) idle=241/3fff/0 softirq=82/543
(t=65000 jiffies)
-In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
-printed:
+In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed:
INFO: rcu_preempt detected stall on CPU
0: (64628 ticks this GP) idle=dd5/3fff/0 softirq=82/543
last_accelerate: a345/d342 nonlazy_posted: 25 .D
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index faee5242d6ff..7c0b09d754a1 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -288,12 +288,10 @@ struct rcu_data {
boolgpwrap; /* Possible gpnum/completed wrap. */
struct rcu_node *mynode;/* This CPU's leaf of hierarchy */
unsigned long grpmask; /* Mask to apply to leaf qsmask. */
-#ifdef CONFIG_RCU_CPU_STALL_INFO
unsigned long ticks_this_gp; /* The number of scheduling-clock */
/* ticks this CPU has handled */
/* during and after the last grace */
/* period it is aware of. */
-#endif /* #ifdef CONFIG_RCU_CPU_STALL_INFO */
/* 2) batch handling */
/*
@@ -388,9 +386,7 @@ struct rcu_data {
#endif /* #ifdef CONFIG_RCU_NOCB_CPU */
/* 8) RCU CPU stall data. */
-#ifdef CONFIG_RCU_CPU_STALL_INFO
unsigned int softirq_snap; /* Snapshot of softirq activity. */
-#endif /* #ifdef CONFIG_RCU_CPU_STALL_INFO */
int cpu;
struct rcu_state *rsp;
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 7234f03e0aa2..ef41c1b04ba6 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -82,8 +82,6 @@ static void __init rcu_bootup_announce_oddness(void)
pr_info("\tRCU lockdep checking is enabled.\n");
if (IS_ENABLED(CONFIG_RCU_TORTURE_TEST_RUNNABLE))
pr_info("\tRCU torture testing starts during boot.\n");
- if (IS_ENABLED(CONFIG_RCU_CPU_STALL_INFO))
- pr_info("\tAdditional per-CPU info printed with stalls.\n");
if (RCU_NUM_LVLS >= 4)
pr_info("\tFour(or more)-level hierarchy is enabled.\n");
if (RCU_FANOUT_LEAF != 16)
@@ -418,8 +416,6 @@ static void rcu_print_detail_task_stall(struct rcu_state
*rsp)
rcu_print_detail_task_stall_rnp(rnp);
}
-#ifdef
