Re: [PATCH 1/2] thermal: exynos: Fix wrong control of power down detection mode for Exynos7
Hi Eduardo,
Hi Lukasz,
On Wed, Feb 25, 2015 at 2:33 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Hi Abhilash,
This patch fixes the wrong control of PD_DET_EN (power down
detection mode) for Exynos7 because exynos7_tmu_control() always
enables the power down detection mode regardless 'on' parameter.
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527
100644 --- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
platform_device *pdev, bool on)
if (on) {
con |= (1 EXYNOS_TMU_CORE_EN_SHIFT);
+ con |= (1 EXYNOS7_PD_DET_EN_SHIFT);
interrupt_en =
(of_thermal_is_trip_valid(tz, 7)
EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
@@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
platform_device *pdev, bool on) interrupt_en
EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
con = ~(1 EXYNOS_TMU_CORE_EN_SHIFT);
+ con = ~(1 EXYNOS7_PD_DET_EN_SHIFT);
interrupt_en = 0; /* Disable all interrupts */
}
- con |= 1 EXYNOS7_PD_DET_EN_SHIFT;
writel(interrupt_en, data-base + EXYNOS7_TMU_REG_INTEN);
writel(con, data-base + EXYNOS_TMU_REG_CONTROL);
Could you test this patch if it isn't introducing any regression on
your HW?
The patch does not cause any regression on exynos7 and seems
logically correct.
Tested-by: Abhilash Kesavan a.kesa...@samsung.com
Eduardo, it is up to you if you prefer to take this fix directly or via
the new thermal-samsung tree ?
From when shall I regard myself as a maintainer? :-)
Regards,
Abhilash
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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/7] drivers: Introduce new eFuse subsystem stub
Hi, [adding devicetree list] Am 25.02.2015 um 12:45 schrieb Ezequiel Garcia: This commit introduces a new eFuse subsystem stub to hold all the eFuse-like device drivers. This will be used to host the currently supported Tegra eFuse driver, and will allow to add support for other platforms as well. as i mentioned in the old discussion it would be nice to keep drivers and devicetree binding documentation consistent. So how about renaming? Documentation/devicetree/bindings/fuse/ - Documentation/devicetree/bindings/efuse/ Best regards Stefan -- 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: doubt about sm7xxfb
On Wed, Feb 11, 2015 at 02:33:51PM +0800, Greg Kroah-Hartman wrote: On Wed, Feb 11, 2015 at 11:58:18AM +0530, Sudip Mukherjee wrote: Ok, that makes sense, I was thinking this was a new driver, instead of a vendor driver crud. Hi Greg, The SM750 driver is almost ready for staging, it now compiles without any error with today's linux-next and is working properly , ok, there are lots of warning when compiling and checkpatch will give lots of complaints. But in total it is creating 34 files and the size of the patch is 360K. So should i send it with mail, just the way we send other patches or should i send you a git pull request? regards sudip thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/7] New eFuse subsystem
Hi Maxime, -Original Message- From: Ezequiel Garcia Sent: 25 February 2015 12:30 To: Maxime Ripard Cc: Thierry Reding; Stephen Warren; Arnd Bergmann; Andrew Bresticker; James Hartley; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org Subject: Re: [PATCH 0/7] New eFuse subsystem On 02/25/2015 09:02 AM, Maxime Ripard wrote: Hi Ezequiel, On Wed, Feb 25, 2015 at 08:45:12AM -0300, Ezequiel Garcia wrote: This patchset introduces a new driver subsystem, meant to support eFuse (alias OTP, one-time-programmable) devices. The motivation behind this work is to have a common place for drivers that are currently more or less scattered: the tegra efuses are in drivers/soc/ and the sunxi efuses in drivers/misc/eeprom. For now, there's no proposal for a generic efuse API. Instead, we simply group the drivers together. This patchset is the result of the initial submission for IMG Pistachio eFuse support [1]. Our first proposal was to follow the Tegra efuse, and put the Pistachio efuse in drivers/soc. After some discussion we finally agreed [2] to first create an efuse directoy, and then put all efuse drivers in it. As always, all comments are welcome! [1] http://www.spinics.net/lists/devicetree/msg59246.html [2] http://www.spinics.net/lists/arm-kernel/msg389325.html Have you looked at the EEPROM framework currently in discussions? The two seems to be covering pretty much the same use cases. Shouldn't this be a PROM framework if it is going to support both EEPROM and EFUSE/QFPROM, or am I missing something here (since an eFuse is not eraseable)? Nope, I was obviously unaware of that. Guess we'll wait until the discussion is settled and use that framework. Thanks! -- Ezequiel Thanks, James. -- 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/8 v2] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
On 24/02/15 22:05, Robert ABEL wrote:
DTS output was formatted to require additional work when copy-pasting into
DTS.
Nano-second timings were removed, because they were not a confidence interval
nor
an indication what timing values would result in the same #ticks
If they were not is it possible to dump min,max timings that will result in
the same ticks?
Otherwise patch is fine.
cheers,
-roger
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index b5c8305..ff1a1e7 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -337,32 +337,45 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
}
#ifdef DEBUG
+/**
+ * get_gpmc_timing_reg - read a timing parameter and print DTS settings for
it.
+ * @cs Chip Select Region
+ * @reg GPMC_CS_CONFIGn register offset.
+ * @st_bit Start Bit
+ * @end_bit End Bit. Must be = @st_bit.
+ * @nameDTS node name, w/o gpmc,
+ * @raw Raw Format Option.
+ * raw format: gpmc,name = value
+ * tick format: gpmc,name = value /zwj;* x ticks *zwj;/
+ * @noval Parameter values equal to 0 are not printed.
+ * @shift Parameter value left shifts @shift, which is then printed
instead of value.
+ *
+ */
static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
bool raw, bool noval, int shift,
const char *name)
{
u32 l;
- int nr_bits, max_value, mask;
+ int nr_bits;
+ int mask;
l = gpmc_cs_read_reg(cs, reg);
nr_bits = end_bit - st_bit + 1;
- max_value = (1 nr_bits) - 1;
- mask = max_value st_bit;
- l = (l mask) st_bit;
+ mask = (1 nr_bits) - 1;;
+ l = (l st_bit) mask;
if (shift)
l = (shift l);
if (noval (l == 0))
return 0;
if (!raw) {
- unsigned int time_ns_min, time_ns, time_ns_max;
+ /* DTS tick format for timings in ns */
+ unsigned int time_ns;
- time_ns_min = gpmc_ticks_to_ns(l ? l - 1 : 0);
time_ns = gpmc_ticks_to_ns(l);
- time_ns_max = gpmc_ticks_to_ns(l + 1 max_value ?
-max_value : l + 1);
- pr_info(gpmc,%s = %u (%u - %u ns, %i ticks)\n,
- name, time_ns, time_ns_min, time_ns_max, l);
+ pr_info(gpmc,%s = %u /* %i ticks */\n,
+ name, time_ns, l);
} else {
+ /* raw format */
pr_info(gpmc,%s = %u\n, name, l);
}
--
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: Trying to use 'perf probe' to debug perf itself
Em Wed, Feb 25, 2015 at 11:53:16AM +0900, Masami Hiramatsu escreveu: (2015/02/25 3:49), Arnaldo Carvalho de Melo wrote: Available variables at thread__get @thread__get+0 struct thread* thread [root@ssdandy ~]# cool, so I thought it would be just a matter of asking to put the probes and get the value of 'thread', then match things, but: [root@ssdandy ~]# perf probe -v ~/bin/perf thread__put thread SNIP Writing event: p:probe_perf/thread__put /root/bin/perf:0xd03d2 thread=-32(%sp):u64 Failed to write event: Invalid argument Error: Failed to add events. Reason: Invalid argument (Code: -22) [root@ssdandy ~]# Not possible :-\ Hmm, strange. Could you tell me the version of your kernel? [root@ssdandy ~]# uname -r 3.10.0-210.el7.x86_64 It seems that the kernel newer than 3.14 supports uprobes with memory dereference (e.g. -32(%sp) )feature. Right, that must be the case, will test, but then, would it be possible for the kernel, in such cases, return something line EOPNOTSUP? I will try to figure out a better error message on the tooling side, something like: . Realize we're asking for memory dereference in uprobes . If it fails with EINVAL, check the kernel version and say something like: Please upgrade your kernel to at least x.y.z to have access to feature FOO_BAR. - Arnaldo (it was actually introduced by 5baaa59e, and git-describe told it was v3.13-rc4-22-g5baaa59) And also, could you try to write the result command to uprobe_event as below? # echo p:probe_perf/thread__put /root/bin/perf:0xd03d2 thread=-32(%sp):u64 \ /sys/kernel/debug/tracing/uprobe_events Well, I'll try that if it fails after I upgrade to 3.14. please let me know if you need some file, here is the readelf -wi for those two routines: This should not be the problem of dwarf-analysis. It seems kernel-side (uprobe) problem. Thanks a lot! - Arnaldo -- 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 v4 8/9] rtc: st: add new driver for ST's LPC RTC
ST's Low Power Controller (LPC) controls two devices; watchdog and RTC.
Only one of the devices can be used at any one time. This is enforced
by the correlating MFD driver. This portion of the driver-set controls
the Real Time Clock.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/rtc/Kconfig | 12 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-st-lpc.c | 354 +++
3 files changed, 367 insertions(+)
create mode 100644 drivers/rtc/rtc-st-lpc.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b5b5c3d..08a1020 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1500,6 +1500,18 @@ config RTC_DRV_SIRFSOC
Say yes here to support the real time clock on SiRF SOC chips.
This driver can also be built as a module called rtc-sirfsoc.
+config RTC_DRV_ST_LPC
+ tristate STMicroelectronics LPC RTC
+ depends on ARCH_STI
+ depends on OF
+ select MFD_ST_LPC
+ help
+ Say Y here to include STMicroelectronics Low Power Controller
+ (LPC) based RTC support.
+
+ To compile this driver as a module, choose M here: the
+ module will be called rtc-st-lpc.
+
config RTC_DRV_MOXART
tristate MOXA ART RTC
depends on ARCH_MOXART || COMPILE_TEST
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 69c8706..dda6e33 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -152,4 +152,5 @@ obj-$(CONFIG_RTC_DRV_WM8350)+= rtc-wm8350.o
obj-$(CONFIG_RTC_DRV_X1205)+= rtc-x1205.o
obj-$(CONFIG_RTC_DRV_XGENE)+= rtc-xgene.o
obj-$(CONFIG_RTC_DRV_SIRFSOC) += rtc-sirfsoc.o
+obj-$(CONFIG_RTC_DRV_ST_LPC) += rtc-st-lpc.o
obj-$(CONFIG_RTC_DRV_MOXART) += rtc-moxart.o
diff --git a/drivers/rtc/rtc-st-lpc.c b/drivers/rtc/rtc-st-lpc.c
new file mode 100644
index 000..ab8cee9
--- /dev/null
+++ b/drivers/rtc/rtc-st-lpc.c
@@ -0,0 +1,354 @@
+/*
+ * rtc-st-lpc.c - ST's LPC RTC, powered by the Low Power Timer
+ *
+ * Copyright (C) 2014 STMicroelectronics Limited
+ *
+ * Author: David Paris david.pa...@st.com for STMicroelectronics
+ * Lee Jones lee.jo...@linaro.org for STMicroelectronics
+ *
+ * Based on the original driver written by Stuart Menefy.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/platform_device.h
+#include linux/rtc.h
+
+#include dt-bindings/mfd/st-lpc.h
+
+/* Low Power Timer */
+#define LPC_LPT_LSB_OFF0x400
+#define LPC_LPT_MSB_OFF0x404
+#define LPC_LPT_START_OFF 0x408
+
+/* Low Power Alarm */
+#define LPC_LPA_LSB_OFF0x410
+#define LPC_LPA_MSB_OFF0x414
+#define LPC_LPA_START_OFF 0x418
+
+/* LPC as WDT */
+#define LPC_WDT_OFF0x510
+#define LPC_WDT_FLAG_OFF 0x514
+
+struct st_rtc {
+ struct rtc_device *rtc_dev;
+ struct rtc_wkalrm alarm;
+ struct resource *res;
+ struct clk *clk;
+ unsigned long clkrate;
+ void __iomem *ioaddr;
+ bool irq_enabled:1;
+ spinlock_t lock;
+ short irq;
+};
+
+static void st_rtc_set_hw_alarm(struct st_rtc *rtc,
+ unsigned long msb, unsigned long lsb)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(rtc-lock, flags);
+
+ writel_relaxed(1, rtc-ioaddr + LPC_WDT_OFF);
+
+ writel_relaxed(msb, rtc-ioaddr + LPC_LPA_MSB_OFF);
+ writel_relaxed(lsb, rtc-ioaddr + LPC_LPA_LSB_OFF);
+ writel_relaxed(1, rtc-ioaddr + LPC_LPA_START_OFF);
+
+ writel_relaxed(0, rtc-ioaddr + LPC_WDT_OFF);
+
+ spin_unlock_irqrestore(rtc-lock, flags);
+}
+
+static irqreturn_t st_rtc_handler(int this_irq, void *data)
+{
+ struct st_rtc *rtc = (struct st_rtc *)data;
+
+ rtc_update_irq(rtc-rtc_dev, 1, RTC_AF);
+
+ return IRQ_HANDLED;
+}
+
+static int st_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct st_rtc *rtc = dev_get_drvdata(dev);
+ unsigned long lpt_lsb, lpt_msb;
+ unsigned long long lpt;
+ unsigned long flags;
+
+ spin_lock_irqsave(rtc-lock, flags);
+
+ do {
+ lpt_msb = readl_relaxed(rtc-ioaddr + LPC_LPT_MSB_OFF);
+ lpt_lsb = readl_relaxed(rtc-ioaddr + LPC_LPT_LSB_OFF);
+ } while (readl_relaxed(rtc-ioaddr + LPC_LPT_MSB_OFF) != lpt_msb);
+
+ spin_unlock_irqrestore(rtc-lock, flags);
+
+ lpt = ((unsigned long long)lpt_msb 32) | lpt_lsb;
+ do_div(lpt, rtc-clkrate);
+ rtc_time_to_tm(lpt, tm);
+
+ return 0;
+}
+
+static int
Re: [PATCH 2/4] x86: get rid of KERNEL_STACK_OFFSET
* Denys Vlasenko dvlas...@redhat.com wrote: The decision on how exactly we should fix KERNEL_STACK_OFFSET (set it to SIZEOF_PTREGS or to zero) depends on whether we switch to using PUSHes, or not. What do you think? Yes. A data point. I implemented push-based creation of pt_regs and benchmarked it. The patch is on top of all my latest patches sent to ML. On SandyBridge CPU, it does not get slower: seems to be 1 cycle faster per syscall. We lose a number of large insns there: text data bss dec hex filename - 9863 0 098632687 entry_64.o + 9671 0 0967125c7 entry_64.o That's a nice reduction in I$ footprint ... + /* Construct struct pt_regs on stack */ + pushq $__USER_DS /* pt_regs-ss */ + pushq PER_CPU_VAR(old_rsp)/* pt_regs-sp */ + pushq %r11/* pt_regs-flags */ Btw., this could also construct all the dwarf annotations in a natural, maintainable fashion - pushq_cfi and friends? + pushq $__USER_CS /* pt_regs-cs */ + pushq %rcx/* pt_regs-ip */ + pushq %rax/* pt_regs-orig_ax */ + pushq %rdi/* pt_regs-di */ + pushq %rsi/* pt_regs-si */ + pushq %rdx/* pt_regs-dx */ + pushq %rcx/* pt_regs-cx */ + pushq $-ENOSYS/* pt_regs-ax */ + pushq %r8 /* pt_regs-r8 */ + pushq %r9 /* pt_regs-r9 */ + pushq %r10/* pt_regs-r10 */ + sub $(7*8),%rsp /* pt_regs-r11,bp,bx,r12-15 */ So the 'SUB' there is a bit sad, but push sequences are generally easier to read, so I like it altogether. Then we could indeed get rid of KERNEL_STACK_OFFSET. 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/
[PATCH v4 6/9] watchdog: st_wdt: Add new driver for ST's LPC Watchdog
Reviewed-by: Guenter Roeck li...@roeck-us.net
Signed-off-by: David Paris david.pa...@st.com
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
drivers/watchdog/Kconfig | 13 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/st_lpc_wdt.c | 333 ++
3 files changed, 347 insertions(+)
create mode 100644 drivers/watchdog/st_lpc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 16f2023..023df6d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -471,6 +471,19 @@ config SIRFSOC_WATCHDOG
Support for CSR SiRFprimaII and SiRFatlasVI watchdog. When
the watchdog triggers the system will be reset.
+config ST_LPC_WATCHDOG
+ tristate STMicroelectronics LPC Watchdog
+ depends on ARCH_STI
+ depends on OF
+ select WATCHDOG_CORE
+ select MFD_ST_LPC
+ help
+ Say Y here to include STMicroelectronics Low Power Controller
+ (LPC) based Watchdog timer support.
+
+ To compile this driver as a module, choose M here: the
+ module will be called st_wdt.
+
config TEGRA_WATCHDOG
tristate Tegra watchdog
depends on (ARCH_TEGRA || COMPILE_TEST) HAS_IOMEM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5c19294..d98768c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
obj-$(CONFIG_SIRFSOC_WATCHDOG) += sirfsoc_wdt.o
+obj-$(CONFIG_ST_LPC_WATCHDOG) += st_lpc_wdt.o
obj-$(CONFIG_QCOM_WDT) += qcom-wdt.o
obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o
obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
diff --git a/drivers/watchdog/st_lpc_wdt.c b/drivers/watchdog/st_lpc_wdt.c
new file mode 100644
index 000..91bb631
--- /dev/null
+++ b/drivers/watchdog/st_lpc_wdt.c
@@ -0,0 +1,333 @@
+/*
+ * st-wdt.c - ST's LPC Watchdog
+ *
+ * Copyright (C) 2014 STMicroelectronics -- All Rights Reserved
+ *
+ * Author: David Paris david.pa...@st.com for STMicroelectronics
+ * Lee Jones lee.jo...@linaro.org for STMicroelectronics
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/watchdog.h
+
+#include dt-bindings/mfd/st-lpc.h
+
+/* Low Power Alarm */
+#define LPC_LPA_LSB_OFF0x410
+#define LPC_LPA_START_OFF 0x418
+
+/* LPC as WDT */
+#define LPC_WDT_OFF0x510
+
+static struct watchdog_device st_wdog_dev;
+
+struct st_wdog_syscfg {
+ unsigned int reset_type_reg;
+ unsigned int reset_type_mask;
+ unsigned int enable_reg;
+ unsigned int enable_mask;
+};
+
+struct st_wdog {
+ void __iomem *base;
+ struct device *dev;
+ struct regmap *regmap;
+ struct st_wdog_syscfg *syscfg;
+ struct clk *clk;
+ unsigned long clkrate;
+ bool warm_reset;
+};
+
+static struct st_wdog_syscfg stid127_syscfg = {
+ .reset_type_reg = 0x004,
+ .reset_type_mask= BIT(2),
+ .enable_reg = 0x000,
+ .enable_mask= BIT(2),
+};
+
+static struct st_wdog_syscfg stih415_syscfg = {
+ .reset_type_reg = 0x0B8,
+ .reset_type_mask= BIT(6),
+ .enable_reg = 0x0B4,
+ .enable_mask= BIT(7),
+};
+
+static struct st_wdog_syscfg stih416_syscfg = {
+ .reset_type_reg = 0x88C,
+ .reset_type_mask= BIT(6),
+ .enable_reg = 0x888,
+ .enable_mask= BIT(7),
+};
+
+static struct st_wdog_syscfg stih407_syscfg = {
+ .enable_reg = 0x204,
+ .enable_mask= BIT(19),
+};
+
+static const struct of_device_id st_wdog_match[] = {
+ {
+ .compatible = st,stih407-lpc,
+ .data = stih407_syscfg,
+ },
+ {
+ .compatible = st,stih416-lpc,
+ .data = stih416_syscfg,
+ },
+ {
+ .compatible = st,stih415-lpc,
+ .data = stih415_syscfg,
+ },
+ {
+ .compatible = st,stid127-lpc,
+ .data = stid127_syscfg,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, st_wdog_match);
+
+static void st_wdog_setup(struct st_wdog *st_wdog, bool enable)
+{
+ /* Type of watchdog reset - 0: Cold 1: Warm */
+ if (st_wdog-syscfg-reset_type_reg)
+
[PATCH v4 4/9] ARM: STi: DT: STiH407: Add Device Tree node for the LPC
On current ST platforms the LPC controls a number of functions. This
patch enables support for the LPC Watchdog and LPC RTC devices on LPC1
and LPC2 respectively.
Signed-off-by: David Paris david.pa...@st.com
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/stih407-family.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index c06a546..2b2315d 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -7,6 +7,7 @@
* publishhed by the Free Software Foundation.
*/
#include stih407-pinctrl.dtsi
+#include dt-bindings/mfd/st-lpc.h
#include dt-bindings/reset-controller/stih407-resets.h
/ {
#address-cells = 1;
@@ -336,5 +337,24 @@
resets = softreset STIH407_MIPHY2_SOFTRESET;
};
};
+
+ /* Watchdog and Real-Time Clock */
+ lpc@8787000 {
+ compatible = st,stih407-lpc;
+ reg = 0x8787000 0x1000;
+ interrupts = GIC_SPI 129 IRQ_TYPE_EDGE_RISING;
+ clocks = clk_s_d3_flexgen CLK_LPC_0;
+ timeout-sec = 120;
+ st,syscfg = syscfg_core;
+ st,lpc-mode = ST_LPC_MODE_WDT;
+ };
+
+ lpc@8788000 {
+ compatible = st,stih407-lpc;
+ reg = 0x8788000 0x1000;
+ interrupts = GIC_SPI 130 IRQ_TYPE_EDGE_RISING;
+ clocks = clk_s_d3_flexgen CLK_LPC_1;
+ st,lpc-mode = ST_LPC_MODE_RTC;
+ };
};
};
--
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-3.18.7-rt1]sunrpc: make svc_xprt_do_enqueue() use get_cpu_light()
* Mike Galbraith | 2015-02-18 16:05:28 [+0100]: [ 37.667792] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 37.720307] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:915 [ 37.720307] in_atomic(): 1, irqs_disabled(): 0, pid: 3194, name: rpc.nfsd [ 37.720318] Preemption disabled at:[a06bf0bb] svc_xprt_received+0x4b/0xc0 [sunrpc] applied Sebastian -- 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] virtio-balloon: do not call blocking ops when !TASK_RUNNING
virtio balloon has this code:
wait_event_interruptible(vb-config_change,
(diff = towards_target(vb)) != 0
|| vb-need_stats_update
|| kthread_should_stop()
|| freezing(current));
Which is a problem because towards_target() call might block after
wait_event_interruptible sets task state to TAST_INTERRUPTIBLE, causing
the task_struct::state collision typical of nesting of sleeping
primitives
See also http://lwn.net/Articles/628628/ or Thomas's
bug report
http://article.gmane.org/gmane.linux.kernel.virtualization/24846
for a fuller explanation.
To fix, rewrite using wait_woken.
Cc: sta...@vger.kernel.org
Reported-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/virtio/virtio_balloon.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 0413157..2f19f65 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -29,6 +29,7 @@
#include linux/module.h
#include linux/balloon_compaction.h
#include linux/oom.h
+#include linux/wait.h
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -334,12 +335,25 @@ static int virtballoon_oom_notify(struct notifier_block
*self,
static int balloon(void *_vballoon)
{
struct virtio_balloon *vb = _vballoon;
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
set_freezable();
while (!kthread_should_stop()) {
s64 diff;
try_to_freeze();
+
+ add_wait_queue(vb-config_change, wait);
+ for (;;) {
+ if ((diff = towards_target(vb)) != 0 ||
+ vb-need_stats_update ||
+ kthread_should_stop() ||
+ freezing(current))
+ break;
+ wait_woken(wait, TASK_INTERRUPTIBLE,
MAX_SCHEDULE_TIMEOUT);
+ }
+ remove_wait_queue(vb-config_change, wait);
+
wait_event_interruptible(vb-config_change,
(diff = towards_target(vb)) != 0
|| vb-need_stats_update
--
MST
--
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] mfd: arizona: Move useful defines into a dt-binding include
Why are you using this address for MFD?
Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in
the dt-binding directory for use by device tree bindings. This also
makes gpio.h redundant so remove it in the process.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
Acked-by: Mark Brown broo...@kernel.org
---
Changes since v1:
- Removed some defines that will never be used in DT from the
dt-binding include
- Added some convience defines for the most common pin configs
(input/output/default)
- Updated the binding documentation to use the new defines to
give some context to their usage
Thanks,
Charles
Documentation/devicetree/bindings/mfd/arizona.txt | 20 ++--
include/dt-bindings/mfd/arizona.h | 93
include/linux/mfd/arizona/gpio.h | 96
-
include/linux/mfd/arizona/pdata.h | 22 +-
sound/soc/codecs/arizona.c|1 -
5 files changed, 105 insertions(+), 127 deletions(-)
create mode 100644 include/dt-bindings/mfd/arizona.h
delete mode 100644 include/linux/mfd/arizona/gpio.h
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 7bd1273..bfef000 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -36,11 +36,11 @@ Optional properties:
- wlf,reset : GPIO specifier for the GPIO controlling /RESET
- wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
- - wlf,gpio-defaults : A list of GPIO configuration register values. If
-absent, no configuration of these registers is performed. If any
-entry has a value that is out of range for a 16 bit register then
-the chip default will be used. If present exactly five values must
-be specified.
+ - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
+for the appropriate values can found in dt-bindings/mfd/arizona.txt. If
+absent, no configuration of these registers is performed. If any entry
has
+a value that is out of range for a 16 bit register then the chip default
+will be used. If present exactly five values must be specified.
- wlf,inmode : A list of INn_MODE register values, where n is the number
of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
@@ -73,10 +73,10 @@ codec: wm5102@1a {
#gpio-cells = 2;
wlf,gpio-defaults =
- 0x /* AIF1TXLRCLK */
- 0x
- 0x
- 0x
- 0x
+ ARIZONA_GP_FN_TXLRCLK
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
;
};
diff --git a/include/dt-bindings/mfd/arizona.h
b/include/dt-bindings/mfd/arizona.h
new file mode 100644
index 000..c7af7c7
--- /dev/null
+++ b/include/dt-bindings/mfd/arizona.h
@@ -0,0 +1,93 @@
+/*
+ * Device Tree defines for Arizona devices
+ *
+ * Copyright 2015 Cirrus Logic Inc.
+ *
+ * Author: Charles Keepax ckee...@opensource.wolfsonmicro.com
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_MFD_ARIZONA_H
+#define _DT_BINDINGS_MFD_ARIZONA_H
+
+/* GPIO Function Definitions */
+#define ARIZONA_GP_FN_TXLRCLK0x00
+#define ARIZONA_GP_FN_GPIO 0x01
+#define ARIZONA_GP_FN_IRQ1 0x02
+#define ARIZONA_GP_FN_IRQ2 0x03
+#define ARIZONA_GP_FN_OPCLK 0x04
+#define ARIZONA_GP_FN_FLL1_OUT 0x05
+#define ARIZONA_GP_FN_FLL2_OUT 0x06
+#define ARIZONA_GP_FN_PWM1 0x08
+#define ARIZONA_GP_FN_PWM2 0x09
+#define ARIZONA_GP_FN_SYSCLK_UNDERCLOCKED0x0A
+#define ARIZONA_GP_FN_ASYNCCLK_UNDERCLOCKED 0x0B
+#define ARIZONA_GP_FN_FLL1_LOCK 0x0C
+#define ARIZONA_GP_FN_FLL2_LOCK 0x0D
+#define ARIZONA_GP_FN_FLL1_CLOCK_OK 0x0F
+#define ARIZONA_GP_FN_FLL2_CLOCK_OK 0x10
+#define ARIZONA_GP_FN_HEADPHONE_DET 0x12
+#define ARIZONA_GP_FN_MIC_DET0x13
+#define ARIZONA_GP_FN_WSEQ_STATUS0x15
+#define ARIZONA_GP_FN_CIF_ADDRESS_ERROR 0x16
+#define ARIZONA_GP_FN_ASRC1_LOCK 0x1A
+#define ARIZONA_GP_FN_ASRC2_LOCK 0x1B
+#define ARIZONA_GP_FN_ASRC_CONFIG_ERROR 0x1C
+#define ARIZONA_GP_FN_DRC1_SIGNAL_DETECT 0x1D
+#define ARIZONA_GP_FN_DRC1_ANTICLIP 0x1E
+#define ARIZONA_GP_FN_DRC1_DECAY
Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver
On Wed, Feb 25, 2015 at 10:53:11AM +, Stathis Voukelatos wrote: On 25/02/15 09:50, Richard Cochran wrote: The Linux kernel already fully supports this kind of application via the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms. We certainly don't need another another interface just for someone's warped hardware design. I suggest that you find a way to make your HW work within the existing frame work. The driver already uses that framework for returning timestamps to user space. It does not introduce any new interface. No, it only abuses the interfaces that we already have. The time stamp handling is not within the existing frame work by any means. However, there is a way to integrate this hardware properly... The H/W could not support that: With these new explanations, now I understand the code and how this is supposed to work. I'll put further comments in a reply to your newer series. Thanks, Richard -- 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] mfd: arizona: Move useful defines into a dt-binding include
On Wed, Feb 25, 2015 at 8:09 AM, Charles Keepax
ckee...@opensource.wolfsonmicro.com wrote:
Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in
the dt-binding directory for use by device tree bindings. This also
makes gpio.h redundant so remove it in the process.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
Acked-by: Mark Brown broo...@kernel.org
Acked-by: Rob Herring r...@kernel.org
---
Changes since v1:
- Removed some defines that will never be used in DT from the
dt-binding include
- Added some convience defines for the most common pin configs
(input/output/default)
- Updated the binding documentation to use the new defines to
give some context to their usage
Thanks,
Charles
Documentation/devicetree/bindings/mfd/arizona.txt | 20 ++--
include/dt-bindings/mfd/arizona.h | 93
include/linux/mfd/arizona/gpio.h | 96
-
include/linux/mfd/arizona/pdata.h | 22 +-
sound/soc/codecs/arizona.c|1 -
5 files changed, 105 insertions(+), 127 deletions(-)
create mode 100644 include/dt-bindings/mfd/arizona.h
delete mode 100644 include/linux/mfd/arizona/gpio.h
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 7bd1273..bfef000 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -36,11 +36,11 @@ Optional properties:
- wlf,reset : GPIO specifier for the GPIO controlling /RESET
- wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
- - wlf,gpio-defaults : A list of GPIO configuration register values. If
-absent, no configuration of these registers is performed. If any
-entry has a value that is out of range for a 16 bit register then
-the chip default will be used. If present exactly five values must
-be specified.
+ - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
+for the appropriate values can found in dt-bindings/mfd/arizona.txt. If
+absent, no configuration of these registers is performed. If any entry
has
+a value that is out of range for a 16 bit register then the chip default
+will be used. If present exactly five values must be specified.
- wlf,inmode : A list of INn_MODE register values, where n is the number
of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
@@ -73,10 +73,10 @@ codec: wm5102@1a {
#gpio-cells = 2;
wlf,gpio-defaults =
- 0x /* AIF1TXLRCLK */
- 0x
- 0x
- 0x
- 0x
+ ARIZONA_GP_FN_TXLRCLK
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
;
};
diff --git a/include/dt-bindings/mfd/arizona.h
b/include/dt-bindings/mfd/arizona.h
new file mode 100644
index 000..c7af7c7
--- /dev/null
+++ b/include/dt-bindings/mfd/arizona.h
@@ -0,0 +1,93 @@
+/*
+ * Device Tree defines for Arizona devices
+ *
+ * Copyright 2015 Cirrus Logic Inc.
+ *
+ * Author: Charles Keepax ckee...@opensource.wolfsonmicro.com
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_MFD_ARIZONA_H
+#define _DT_BINDINGS_MFD_ARIZONA_H
+
+/* GPIO Function Definitions */
+#define ARIZONA_GP_FN_TXLRCLK0x00
+#define ARIZONA_GP_FN_GPIO 0x01
+#define ARIZONA_GP_FN_IRQ1 0x02
+#define ARIZONA_GP_FN_IRQ2 0x03
+#define ARIZONA_GP_FN_OPCLK 0x04
+#define ARIZONA_GP_FN_FLL1_OUT 0x05
+#define ARIZONA_GP_FN_FLL2_OUT 0x06
+#define ARIZONA_GP_FN_PWM1 0x08
+#define ARIZONA_GP_FN_PWM2 0x09
+#define ARIZONA_GP_FN_SYSCLK_UNDERCLOCKED0x0A
+#define ARIZONA_GP_FN_ASYNCCLK_UNDERCLOCKED 0x0B
+#define ARIZONA_GP_FN_FLL1_LOCK 0x0C
+#define ARIZONA_GP_FN_FLL2_LOCK 0x0D
+#define ARIZONA_GP_FN_FLL1_CLOCK_OK 0x0F
+#define ARIZONA_GP_FN_FLL2_CLOCK_OK 0x10
+#define ARIZONA_GP_FN_HEADPHONE_DET 0x12
+#define ARIZONA_GP_FN_MIC_DET0x13
+#define ARIZONA_GP_FN_WSEQ_STATUS0x15
+#define ARIZONA_GP_FN_CIF_ADDRESS_ERROR 0x16
+#define ARIZONA_GP_FN_ASRC1_LOCK 0x1A
+#define ARIZONA_GP_FN_ASRC2_LOCK 0x1B
+#define ARIZONA_GP_FN_ASRC_CONFIG_ERROR 0x1C
+#define ARIZONA_GP_FN_DRC1_SIGNAL_DETECT
Re: [PATCH RT 1/2] rwsem-rt: Do not allow readers to nest
On 02/18/2015 09:13 PM, Steven Rostedt wrote: Here the same thing but without cmpxchg(). _If_ after an increment the value is negative then we take slowpath. Otherwise we have the lock. OK, so I need to make it so it can nest with trylock. I have to look at the patch again because it has been a while. I have reverted the patch and can confirm that cpufreq works again. I did some testing on vanilla and -RT: - down_read(l) + down_read(l) this triggers a lockdep warning about a possible deadlock the lock is obtained. - down_read(l) + down_read_trylock() this passes without a warning. So I think we good now. An RW sem must not do two down_read()s on the same lock (it's fine for a trylock if it has a fail safe for it). The reason is, the second down_read() will block if there's a writer waiting. Thus you are guaranteed a deadlock if you have the lock for read, a write comes in and waits, and you grab the RW sem again, because it will block, and the writer is waiting for the reader to release. Thus you have a deadlock. I fully understand. However nesting is allowed according to the code in vanilla and now again in -RT. Lockdep complains properly so we should catch people doing it wrong in both trees. I'll have to revisit this. I also need to revisit the multi readers (although Thomas hates it, but he even admitted there's a better way to do it. Now only if I could remember what that was ;-) Okay. For now I keep the revert since it looks sane and simple. Thanks, -- Steve Sebastian -- 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/4] x86: get rid of KERNEL_STACK_OFFSET
On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar mi...@kernel.org wrote: * Denys Vlasenko dvlas...@redhat.com wrote: PER_CPU_VAR(kernel_stack) was set up in a way where it points five stack slots below the top of stack. Presumably, it was done to avoid one sub $5*8,%rsp in syscall/sysenter code paths, where iret frame needs to be created by hand. Ironically, none of them benefit from this optimization, since all of them need to allocate additional data on stack (struct pt_regs), so they still have to perform subtraction. Well, the original idea of percpu::kernel_stack was that of an optimization of the 64-bit system_call() path: to set up RSP as it has to be before we call into system calls. This optimization has bitrotted away: because these days the first SAVE_ARGS in the 64-bit entry path modifies RSP as well, undoing the optimization. Yes, I figured this is how it was supposed to work. But the fix should be to not touch RSP in SAVE_ARGS, to keep percpu::kernel_stack as an optimized entry point - with KERNEL_STACK_OFFSET pointing to. So NAK - this should be fixed for real. IOW, the proposal is to set KERNEL_STACK_OFFSET to SIZEOF_PTREGS. I can do that. However. There is an ortogonal idea we were discussing: to save registers and construct iret frame using PUSH insns, not MOVs. IIRC Andy and Linus liked it. I am ambivalent: the code will be smaller, but might get slower (at least on some CPUs). If we go that way, we will require KERNEL_STACK_OFFSET = 0 (IOW: the current patch). The decision on how exactly we should fix KERNEL_STACK_OFFSET (set it to SIZEOF_PTREGS or to zero) depends on whether we switch to using PUSHes, or not. What do you think? -- vda -- 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: [Linaro-acpi] [PATCH v3 3/9] ACPI: clean up checkpatch warnings for various bits of syntax
On 2015年02月25日 08:36, al.st...@linaro.org wrote:
From: Al Stoneal.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up a bunch of warnings for odd bits of syntax:
-- remove CVS keyword markers
-- remove a space from between a function name and an opening parenthesis
-- clean up all but one line 80 characters (one just looks silly if you
make it less than 80)
-- add blank lines after declarations in functions
-- remove extraneous braces ({})
Signed-off-by: Al Stoneal.st...@linaro.org
Reviewd-by: Hanjun Guo hanjun@linaro.org
Thanks
Hanjun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] MODSIGN: Provide a utility to append a PKCS#7 signature to a module [ver #3]
On 2015-02-06 15:59, David Howells wrote:
+ if (argc == 5) {
+ dest_name = argv[4];
+ replace_orig = false;
+ } else {
+ ERR(asprintf(dest_name, %s.~signed~, module_name) 0,
+ asprintf);
+ replace_orig = true;
+ }
+
+ ERR_load_crypto_strings();
+ ERR_clear_error();
The error queue initialization should be done before the first use of
the ERR() macro. Or the asprintf check should be open-coded, because it
has nothing to do with openssl.
Michal
--
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] MAINTAINERS: Add phy-miphy28lp.c to ARCH/STI architecture
This patch adds the phy-miphy28lp.c phy driver found on STMicroelectronics stih407 family SoC's into the STI arch section of the maintainers file. Signed-off-by: Peter Griffin peter.grif...@linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index ddc5a8c..1a6180a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1457,6 +1457,7 @@ F:drivers/clocksource/arm_global_timer.c F: drivers/i2c/busses/i2c-st.c F: drivers/media/rc/st_rc.c F: drivers/mmc/host/sdhci-st.c +F: drivers/phy/phy-miphy28lp.c F: drivers/phy/phy-stih407-usb.c F: drivers/phy/phy-stih41x-usb.c F: drivers/pinctrl/pinctrl-st.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 5/9] watchdog: bindings: Provide ST bindings for ST's LPC Watchdog device
On current ST platforms the LPC controls a number of functions including
Watchdog and Real Time Clock. This patch provides the bindings used to
configure LPC in Watchdog mode.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
.../devicetree/bindings/watchdog/st_lpc_wdt.txt| 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt
b/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt
new file mode 100644
index 000..1bdf023
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt
@@ -0,0 +1,38 @@
+STMicroelectronics Low Power Controller (LPC) - Watchdog
+
+
+LPC currently supports Watchdog OR Real Time Clock functionality.
+
+[See: ../rtc/rtc-st-lpc.txt for RTC options]
+
+Required properties
+
+- compatible : Must be one of: st,stih407-lpc st,stih416-lpc
+ st,stih415-lpc st,stid127-lpc
+- reg : LPC registers base address + size
+- interrupts: LPC interrupt line number and associated flags
+- clocks : Clock used by LPC device (See: ../clock/clock-bindings.txt)
+- st,lpc-mode : The LPC can run either one of two modes ST_LPC_MODE_RTC [0] or
+ ST_LPC_MODE_WDT [1]. One (and only one) mode must be
+ selected.
+
+Required properties [watchdog mode]
+
+- st,syscfg: Phandle to syscfg node used to enable watchdog and configure
+ CPU reset type.
+- timeout-sec : Watchdog timeout in seconds
+
+Optional properties [watchdog mode]
+
+- st,warm-reset: If present reset type will be 'warm' - if not it will
be cold
+
+Example:
+ lpc@fde05000 {
+ compatible = st,stih416-lpc-watchdog;
+ reg = 0xfde05000 0x1000;
+ clocks = clk_s_d3_flexgen CLK_LPC_0;
+ st,syscfg = syscfg_core;
+ timeout-sec = 120;
+ st,lpc-mode = ST_LPC_MODE_WDT;
+ st,warm-reset;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 9/9] MAINTAINERS: Add Watchdog and RTC files to STI's maintainer entry
Signed-off-by: Lee Jones lee.jo...@linaro.org --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ddc5a8c..19af007 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1461,10 +1461,12 @@ F: drivers/phy/phy-stih407-usb.c F: drivers/phy/phy-stih41x-usb.c F: drivers/pinctrl/pinctrl-st.c F: drivers/reset/sti/ +F: drivers/rtc/rtc-st-lpc.c F: drivers/tty/serial/st-asc.c F: drivers/usb/dwc3/dwc3-st.c F: drivers/usb/host/ehci-st.c F: drivers/usb/host/ohci-st.c +F: drivers/watchdog/st_lpc_wdt.c F: drivers/ata/ahci_st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: emxx_udc: fix warnings
From: Matteo Semenzato mattew8...@gmail.com
This patch fixes the following warning:
__aligned(size) is preferred over __attribute__((aligned(size)))
Signed-off-by: Matteo Semenzato mattew8...@gmail.com
---
drivers/staging/emxx_udc/emxx_udc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.h
b/drivers/staging/emxx_udc/emxx_udc.h
index 202e2dc..6f90d5e 100644
--- a/drivers/staging/emxx_udc/emxx_udc.h
+++ b/drivers/staging/emxx_udc/emxx_udc.h
@@ -535,7 +535,7 @@ typedef struct _T_FC_REGS {
u8 Reserved1200[0x1000-0x200]; /* Reserved */
-} __attribute__ ((aligned(32))) T_FC_REGS, *PT_FC_REGS;
+} __aligned(32) T_FC_REGS, *PT_FC_REGS;
--
2.3.0
--
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 v4 2/9] ARM: multi_v7_defconfig: Enable support for ST's LPC Watchdog
Signed-off-by: Lee Jones lee.jo...@linaro.org --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index e8a4c95..0f172f8 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -288,6 +288,7 @@ CONFIG_WATCHDOG=y CONFIG_XILINX_WATCHDOG=y CONFIG_ARM_SP805_WATCHDOG=y CONFIG_ORION_WATCHDOG=y +CONFIG_ST_LPC_WATCHDOG=y CONFIG_SUNXI_WATCHDOG=y CONFIG_MESON_WATCHDOG=y CONFIG_MFD_AS3722=y -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 7/9] rtc: bindings: Provide ST bindings for ST's LPC RTC device
On current ST platforms the LPC controls a number of functions including
Watchdog and Real Time Clock. This patch provides the bindings used to
configure LPC in RTC mode.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
.../devicetree/bindings/rtc/rtc-st-lpc.txt | 25 ++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-st-lpc.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-st-lpc.txt
b/Documentation/devicetree/bindings/rtc/rtc-st-lpc.txt
new file mode 100644
index 000..aaf9855
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-st-lpc.txt
@@ -0,0 +1,25 @@
+STMicroelectronics Low Power Controller (LPC) - RTC
+===
+
+LPC currently supports Watchdog OR Real Time Clock functionality.
+
+[See: ../watchdog/st_lpc_wdt.txt for Watchdog options]
+
+Required properties
+
+- compatible : Must be one of: st,stih407-lpc st,stih416-lpc
+ st,stih415-lpc st,stid127-lpc
+- reg : LPC registers base address + size
+- interrupts: LPC interrupt line number and associated flags
+- clocks : Clock used by LPC device (See: ../clock/clock-bindings.txt)
+- st,lpc-mode : The LPC can run either one of two modes ST_LPC_MODE_RTC [0] or
+ ST_LPC_MODE_WDT [1]. One (and only one) mode must be
+ selected.
+
+Example:
+ lpc@fde05000 {
+ compatible = st,stih416-lpc-watchdog;
+ reg = 0xfde05000 0x1000;
+ clocks = clk_s_d3_flexgen CLK_LPC_0;
+ st,lpc-mode = ST_LPC_MODE_RTC;
+ };
--
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-3.18.7-rt1] snd/pcm: fix snd_pcm_stream_lock*() irqs_disabled() splats
* Mike Galbraith | 2015-02-18 15:09:23 [+0100]: Locking functions previously using read_lock_irq()/read_lock_irqsave() were changed to local_irq_disable/save(), leading to gripes. Use nort variants. applied Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM64: Add new Xilinx ZynqMP SoC
Hi Mark,
On 02/24/2015 07:38 PM, Mark Rutland wrote:
Hi Michal,
I have a few minor comments below, but generally this is looking like
one of the best dts submissions I've seen!
thanks appreciate it.
[...]
+/ {
+ model = ZynqMP EP108;
+
+ aliases {
+ serial0 = uart0;
+ };
+
+ chosen {
+ stdout-path = serial0:115200n8;
+ };
Thanks for using stdout-path with the full parameters.
Does your UART have earlycon support?
yes earlycon support is already in the kernel.
btw: I found that only stdout-path has different behavior
compare to console=ttyPS0,115200 passed via bootargs.
But I have to look at details to be accurate.
+/ {
+ compatible = xlnx,zynqmp;
+ #address-cells = 2;
+ #size-cells = 1;
I guess this is fine, though to me it feels more natural to use
#size-cells = 2 in case we need to describe larger ranges for some bus
later.
I can fix it when it is needed.
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ compatible = arm,cortex-a53, arm,armv8;
+ device_type = cpu;
+ enable-method = psci;
+ reg = 0x0;
+ };
+
+ cpu@1 {
+ compatible = arm,cortex-a53, arm,armv8;
+ device_type = cpu;
+ enable-method = psci;
+ reg = 0x1;
+ };
+
+ cpu@2 {
+ compatible = arm,cortex-a53, arm,armv8;
+ device_type = cpu;
+ enable-method = psci;
+ reg = 0x2;
+ };
+
+ cpu@3 {
+ compatible = arm,cortex-a53, arm,armv8;
+ device_type = cpu;
+ enable-method = psci;
+ reg = 0x3;
+ };
+ };
These look fine.
good
+
+ psci {
+ compatible = arm,psci-0.2;
+ method = smc;
+ };
Neat!
What are you using as your implementation? Are all the mandatory
PSCIv0.2 features implemented (e.g. MIGRATE_INFO_TYPE)?
ATF.
I take it this boots at EL2 on all CPUs?
yep.
Does CPU0 hotplug work?
cpu shutdown is working fine with the current firmware.
I didn't try anything else.
Do you need to keep a CPU online or do you require MIGRATE? e.g. does
MIGRATE_INFO_TYPE return something other than 2 (MP or not present)?
We are not require migrate and we don't need to keep CPU online now.
Migrate should return -1.
[...]
+ amba_apu {
+ compatible = simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+
+ timer {
+ compatible = arm,armv8-timer;
+ interrupt-parent = gic;
+ interrupts = 1 13 0xff01,
+1 14 0xff01,
+1 11 0xff01,
+1 10 0xff01;
+ };
The architected timer should just be under the root node, given it's a
component of the CPU -- it doesn't live on any bus.
Fair enough - will add it there.
I take it CNTFRQ is configured appropriately on all CPUs?
I believe so. :-)
[...]
+ i2c_clk: i2c_clk {
+ compatible = fixed-clock;
+ #clock-cells = 0x0;
+ clock-frequency = 1;
+ };
That clock-frequency looks a little odd. Is that right?
why is it odd? Is value too high?
It is exactly what we need to get to get i2c working.
I haven't taken an in-depth look at the other nodes. They look sane at a
high-level, and assuming they are all already documented and supported
they look fine to me.
I was checking that and hopefully I didn't miss anything.
Thanks,
Michal
--
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/2] drivers: cpuidle: add driver/device checks in cpuidle_enter_freeze()
On 02/24/2015 06:58 PM, Lorenzo Pieralisi wrote:
The changes in commit:
381063133246 (PM / sleep: Re-implement suspend-to-idle handling)
let suspend-to-idle code bypass the cpuidle_select() function to
enter the deepest idle state. The sanity checks carried out in
cpuidle_select() are bypassed too and this can cause breakage
on systems that try to suspend-to-idle with no registered cpuidle
driver.
This patch factors out a function cpuidle_device_disabled() that
is used to carry out sanity checks (ie CPUidle is disabled on the
cpu executing the code) in both cpuidle_select() and cpuidle_enter_freeze()
so that the checks are unified and carried out in both control paths.
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
drivers/cpuidle/cpuidle.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index f47edc6c..344fe6c 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -44,6 +44,12 @@ void disable_cpuidle(void)
off = 1;
}
+static bool cpuidle_device_disabled(struct cpuidle_driver *drv,
+ struct cpuidle_device *dev)
+{
+ return (off || !initialized || !drv || !dev || !dev-enabled);
+}
This is getting a bit fuzzy IMO. What means disabled ? :)
/**
* cpuidle_play_dead - cpu off-lining
*
@@ -124,6 +130,11 @@ void cpuidle_enter_freeze(void)
struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
int index;
I think this is exploding before because of dev == NULL in the line above.
+ if (cpuidle_device_disabled(drv, dev)) {
+ arch_cpu_idle();
+ return;
+ }
+
/*
* Find the deepest state with -enter_freeze present, which guarantees
* that interrupts won't be enabled when it exits and allows the tick to
@@ -202,11 +213,8 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct
cpuidle_driver *drv,
*/
int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
{
- if (off || !initialized)
- return -ENODEV;
-
- if (!drv || !dev || !dev-enabled)
- return -EBUSY;
+ if (cpuidle_device_disabled(drv, dev))
+ return -1;
return cpuidle_curr_governor-select(drv, dev);
}
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
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/4] x86: entry.S: tidy up several suboptimal insns
On Wed, 25 Feb 2015 10:20:43 +0100 Ingo Molnar mi...@kernel.org wrote: But, if we do that, we can do even better, and also do an optimization of the 64-bit entry path as well: we could simply mask RAX with 0x3ff and not do a compare. Pad the syscall table up to 0x400 (1024) entries and fill in the table with sys_ni syscall entries. This is valid on 64-bit and 32-bit kernels as well, and it allows the removal of a compare from the syscall entry path, at the cost of a couple of kilobytes of unused syscall table. The downside would be that if we ever grow past 1024 syscall entries we'll be in trouble if new userspace calls syscall 513 on an old kernel and gets syscall 1. What if we test against ~0x3ff and jump to sys_ni if anything is set. This would still work with new userspace calls on older kernels. -- Steve -- 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] thermal: exynos: Fix wrong control of power down detection mode for Exynos7
Hi Lukasz,
On Wed, Feb 25, 2015 at 2:33 PM, Lukasz Majewski l.majew...@samsung.com wrote:
Hi Abhilash,
This patch fixes the wrong control of PD_DET_EN (power down detection
mode) for Exynos7 because exynos7_tmu_control() always enables the
power down detection mode regardless 'on' parameter.
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
platform_device *pdev, bool on)
if (on) {
con |= (1 EXYNOS_TMU_CORE_EN_SHIFT);
+ con |= (1 EXYNOS7_PD_DET_EN_SHIFT);
interrupt_en =
(of_thermal_is_trip_valid(tz, 7)
EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
@@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
platform_device *pdev, bool on) interrupt_en
EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
con = ~(1 EXYNOS_TMU_CORE_EN_SHIFT);
+ con = ~(1 EXYNOS7_PD_DET_EN_SHIFT);
interrupt_en = 0; /* Disable all interrupts */
}
- con |= 1 EXYNOS7_PD_DET_EN_SHIFT;
writel(interrupt_en, data-base + EXYNOS7_TMU_REG_INTEN);
writel(con, data-base + EXYNOS_TMU_REG_CONTROL);
Could you test this patch if it isn't introducing any regression on your
HW?
The patch does not cause any regression on exynos7 and seems logically correct.
Tested-by: Abhilash Kesavan a.kesa...@samsung.com
Regards,
Abhilash
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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] media: em28xx replace printk in dprintk macros
Em Tue, 24 Feb 2015 19:45:50 -0800
Joe Perches j...@perches.com escreveu:
On Tue, 2015-02-24 at 16:41 -0700, Shuah Khan wrote:
On 02/24/2015 03:03 PM, Mauro Carvalho Chehab wrote:
Em Tue, 24 Feb 2015 11:53:47 -0700 Shuah Khan shua...@osg.samsung.com
escreveu:
Replace printk macro in dprintk macros in em28xx audio, dvb,
and input files with pr_* equivalent routines.
[]
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
[]
#define dprintk(fmt, arg...) \
if (ir_debug) { \
-printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
+pr_debug(%s/ir: fmt, ir-name, ## arg); \
NACK.
This is the worse of two words, as it would require both to enable
each debug line via dynamic printk setting and to enable ir_debug.
Ah. I missed that. Sorry for the noise.
It's
At some point, I'm going to propose a standard mechanism
similar to netif_level that does bitmap matching for
dynamic_debug and generic debugging.
Such mechanism would make sense for media drivers.
Regards,
Mauro
--
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] ARM: Don't use complete() during __cpu_die
On Thu, Feb 05, 2015 at 04:11:00PM +, Russell King - ARM Linux wrote: On Thu, Feb 05, 2015 at 06:29:18AM -0800, Paul E. McKenney wrote: Works for me, assuming no hidden uses of RCU in the IPI code. ;-) Sigh... I kind'a new it wouldn't be this simple. The gic code which actually raises the IPI takes a raw spinlock, so it's not going to be this simple - there's a small theoretical window where we have taken this lock, written the register to send the IPI, and then dropped the lock - the update to the lock to release it could get lost if the CPU power is quickly cut at that point. Also, we _do_ need the second cache flush in place to ensure that the unlock is seen to other CPUs. It's time to start discussing this problem again now that we're the other side of the merge window. I've been thinking about the lock in the GIC code. Do we actually need this lock in gic_raise_softirq(), or could we move this lock into the higher level code? Let's consider the bL switcher. I think the bL switcher is racy wrt CPU hotplug at the moment. What happens if we're sleeping in wait_for_completion(inbound_alive) and CPU hotplug unplugs the CPU outgoing CPU? What protects us against this scenario? I can't see anything in bL_switch_to() which ensures that CPU hotplug can't run. Let's assume that this rather glaring bug has been fixed, and that CPU hotplug can't run in parallel with the bL switcher (and hence gic_migrate_target() can't run concurrently with a CPU being taken offline.) If we have that guarantee, then we don't need to take a lock when sending the completion IPI - we would know that while a CPU is being taken down, the bL switcher could not run. What we now need is a lock-less way to raise an IPI. Now, is the locking between the normal IPI paths and the bL switcher something that is specific to the interrupt controller, or should generic code care about it? I think it's something generic code should care about - and I believe that would make life a little easier. The current bL switcher idea is to bring the new CPU up, disable IRQs and FIQs on the outgoing CPU, change the IRQ/IPI targets, then read any pending SGIs and raise them on the new CPU. But what about any pending SPIs? These look like they could be lost. How about this for an idea instead - the bL switcher code: - brings the new CPU online. - disables IRQs and FIQs. - takes the IPI lock, which prevents new IPIs being raised. - re-targets IRQs and IPIs onto the new CPU. - releases the IPI lock. - re-enables IRQs and FIQs. - polls the IRQ controller to wait for any remaining IRQs and IPIs to be delivered. - re-disables IRQs and FIQs (which shouldn't be received anyway since they're now targetting the new CPU.) - shuts down the tick device. - completes the switch What this means is that we're not needing to have complex code in the interrupt controllers to re-raise interrupts on other CPUs, and we don't need a lock in the interrupt controller code synchronising IPI raising with the bL switcher. I'd also suggest is that this IPI lock should _not_ be a spinlock - it should be a read/write spin lock - it's perfectly acceptable to have multiple CPUs raising IPIs to each other, but it is not acceptable to have any CPU raising an IPI when the bL switcher is modifying the IRQ targets. That fits the rwlock semantics. What this means is that gic_raise_softirq() should again become a lock- less function, which opens the door to using an IPI to complete the CPU hot-unplug operation cleanly. Thoughts (especially from Nico)? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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/9] ACPI: clear up warnings on use of printk reported by checkpatch.pl
On 2015年02月25日 08:36, al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clear up all the warnings reported by checkpatch.pl where pr_* should
be used instead of printk(KERN_* ...).
Signed-off-by: Al Stone al.st...@linaro.org
---
drivers/acpi/osl.c | 46 +++---
1 file changed, 19 insertions(+), 27 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 1dc3a3b..865317c 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -141,7 +141,7 @@ static u32 acpi_osi_handler(acpi_string interface, u32
supported)
{
if (!strcmp(Linux, interface)) {
- printk_once(KERN_NOTICE FW_BUG PREFIX
+ pr_notice_once(FW_BUG PREFIX
I think you can use pr_fmt() and then remove all the PREFIX in
this patch, just
#define pr_fmt(fmt) ACPI: fmt
in top of this file before all #includes.
Thanks
Hanjun
--
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 v4 4/4] phy: add phy-hi6220-usb
On 02/23/2015 11:36 PM, Felipe Balbi wrote:
Hi,
On Sun, Feb 22, 2015 at 11:10:36AM +0800, zhangfei wrote:
+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
+{
+ struct usb_otg *otg = priv-phy.otg;
+
+ if (!otg-gadget)
+ return;
+
+ if (on)
+ usb_gadget_connect(otg-gadget);
+ else
+ usb_gadget_disconnect(otg-gadget);
why is the PHY fiddling with pullups ?
We use this to enable/disable otg gadget mode.
I got that, but the pullups don't belong to the PHY, they belong to the
gadget.
The gpio_id gpio_vbus are used to distinguish otg gadget mode or
host mode.
When micro usb or otg device attached to otg, gpio_vbus falling down.
And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.
all of that I understood clearly :-)
So when micro usb attached, we enable gadget mode; while micro usb
detached, we disable gadget mode, and dwc2 will automatically set to
host mode.
that's all fine, I'm concerned about letting the PHY fiddle with
something it doesn't own. If I am to change pullups rules in udc-core,
this is likely to break down miserably and I don't want to have to go
through that.
Thanks for the clarifying.
no problem.
How about using usb_gadget_vbus_connect/disconnect, which are used in many
files under drivers/usb/phy.
There is no vbus_session in dwc2/gadget.c, I thought it would be same as
pullup.
However, usb_gadget_vbus_connect still need para gadget, where should we put
this file, drivers/usb/phy or drivers/phy
drivers/phy, if the framework misses anything you need, it's a great
opportunity to give back to the community by extending the framework.
Sorry, I am a little confused.
I need some concrete suggestion for the next step of this patch, which is
required for the community board, hikey board.
Do you mean in the future we need use hsotg-phy instead of hsotg-uphy.
struct phy *phy;
struct usb_phy *uphy;
yes, we need to move everybody to use struct phy, instead of struct
usb_phy.
usb_phy has many members that struct phy does not have, including otg.
struct usb_otg *otg;
Is that mean we need port such member from usb_phy to phy.
This means we have a little ground work to do before we can add your phy
driver to that framework, right ? As I said, if the framework is missing
anything, work with Kishon (generic phy maintainer) to add those missing
pieces generically.
OK, got it.
Besides, are you ok with using usb_gadget_vbus_connect/disconnect.
Scratching one's own itch kinda thing...
+static void hi6220_detect_work(struct work_struct *work)
+{
+ struct hi6220_priv *priv =
+ container_of(work, struct hi6220_priv, work.work);
+ int gpio_id, gpio_vbus;
+ enum usb_otg_state state;
+
+ if (!gpio_is_valid(priv-gpio_id) || !gpio_is_valid(priv-gpio_vbus))
+ return;
+
+ gpio_id = gpio_get_value_cansleep(priv-gpio_id);
+ gpio_vbus = gpio_get_value_cansleep(priv-gpio_vbus);
looks like this should be using extcon
Not used extcon before.
However, we need gpio_vbus interrupt.
Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
interrupt.
Will investigate tomorrow.
drivers/extcon/extcon-gpio.c
I think there is no need to use extcon, gpio is clear enough.
extcon-gpio.c even do not support dt.
well, add DT. The whole idea of free software is that we improve on
things we already have. EXTCON is *the* API to handle such things.
I think I am still not understanding extcon-gpio, not sure why need
use this API here.
because extcon is the API to use for external connectors. The same way
you use regulator framework to control that single GPIO tied to an
enable signal of a fixed regulator, you use extcon when you need to read
that gpio signal tied to id pin of the USB connector.
Here two gpio requires, one gpio as interrupt, in the interrupt
handler, we detect the gpio status judging the otg status.
extcon-gpio.c use the interrupt, then can we also use the gpio
interrupt. Using extcon-gpio is used for saving gpio_request?
extcon is used to hide gpio_request from dwc2. dwc2 only knows about
extcon, not gpios. extcon will request the gpio and use it as interrupt
source. When an IRQ fires, it will read the gpio state and decide if it
should broadcast a message to tell dwc2 to become host or peripheral.
Thanks for the kind education, understand 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 v4 5/8] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
Hi Eduardo,
On Wed, Feb 18, 2015 at 11:07:33AM +0100, Lukasz Majewski wrote:
With those bindings it is possible to use pwm-fan device available
in Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to ARM dts
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33
++- 1 file changed, 32 insertions(+), 1
deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts index 60bd1e4..3e5df3e
100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,11 +32,42 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = pwm-fan;
pwms = pwm 0 1 0;
+ cooling-min-state = 0;
+ cooling-max-state = 3;
+ #cooling-cells = 2;
+ cooling-levels = 0 102 170 230;
status = okay;
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
This thermal zone misses the mandatory properties as per
Documentation/devicetree/bindings/thermal/thermal.txt
Following mandatory properties:
thermal-sensors = tmu 0;
polling-delay-passive = 0;
polling-delay = 0;
trips {
}
are defined in exynos4-cpu-thermal.dtsi included by this file.
In this patch only device dependent changes are stated.
+ cooling-maps {
+ map0 {
+trip = cpu_alert1;
+cooling-device = cpu0 7 7;
+ };
+ map1 {
+trip = cpu_alert2;
+cooling-device = cpu0 13
13;
+ };
+ map2 {
+trip = cpu_alert0;
+cooling-device = fan0 0 1;
+ };
+ map3 {
+trip = cpu_alert1;
+cooling-device = fan0 1 2;
+ };
+ map4 {
+trip = cpu_alert2;
+cooling-device = fan0 2 3;
+ };
+ };
+ };
+ };
};
pwm {
--
2.0.0.rc2
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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] phy: miphy365x: Use the generic phy type constants in dt-bindings/phy/phy.h
Now there are generic phy type constants declared in phy.h, migrate over to
using them rather than defining our own. This change has been done as one
atomic commit to be bisectable.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
Documentation/devicetree/bindings/phy/phy-miphy365x.txt | 8
arch/arm/boot/dts/stih416.dtsi | 4 ++--
drivers/phy/phy-miphy365x.c | 14 +++---
include/dt-bindings/phy/phy-miphy365x.h | 14 --
4 files changed, 13 insertions(+), 27 deletions(-)
delete mode 100644 include/dt-bindings/phy/phy-miphy365x.h
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
index 9802d5d..8772900 100644
--- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -20,8 +20,8 @@ Required nodes: A sub-node is required for each
channel the controller
Required properties (port (child) node):
- #phy-cells : Should be 1 (See second example)
Cell after port phandle is device type from:
- - MIPHY_TYPE_SATA
- - MIPHY_TYPE_PCI
+ - PHY_TYPE_SATA
+ - PHY_TYPE_PCI
- reg : Address and length of register sets for each device in
reg-names
- reg-names : The names of the register addresses corresponding to the
@@ -68,10 +68,10 @@ property, containing a phandle to the phy port node and a
device type.
Example:
-#include dt-bindings/phy/phy-miphy365x.h
+#include dt-bindings/phy/phy.h
sata0: sata@fe38 {
...
- phys = phy_port0 MIPHY_TYPE_SATA;
+ phys = phy_port0 PHY_TYPE_SATA;
...
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index ea28eba..eeb7afe 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -10,7 +10,7 @@
#include stih416-clock.dtsi
#include stih416-pinctrl.dtsi
-#include dt-bindings/phy/phy-miphy365x.h
+#include dt-bindings/phy/phy.h
#include dt-bindings/interrupt-controller/arm-gic.h
#include dt-bindings/reset-controller/stih416-resets.h
/ {
@@ -306,7 +306,7 @@
reg = 0xfe38 0x1000;
interrupts = GIC_SPI 157 IRQ_TYPE_NONE;
interrupt-names = hostc;
- phys= phy_port0 MIPHY_TYPE_SATA;
+ phys= phy_port0 PHY_TYPE_SATA;
phy-names = sata-phy;
resets = powerdown STIH416_SATA0_POWERDOWN,
softreset STIH416_SATA0_SOFTRESET;
diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
index 6c80154..98bffbc 100644
--- a/drivers/phy/phy-miphy365x.c
+++ b/drivers/phy/phy-miphy365x.c
@@ -25,7 +25,7 @@
#include linux/mfd/syscon.h
#include linux/regmap.h
-#include dt-bindings/phy/phy-miphy365x.h
+#include dt-bindings/phy/phy.h
#define HFC_TIMEOUT100
@@ -176,7 +176,7 @@ static u8 rx_tx_spd[] = {
static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
struct miphy365x_dev *miphy_dev)
{
- bool sata = (miphy_phy-type == MIPHY_TYPE_SATA);
+ bool sata = (miphy_phy-type == PHY_TYPE_SATA);
return regmap_update_bits(miphy_dev-regmap,
miphy_phy-ctrlreg,
@@ -430,7 +430,7 @@ static int miphy365x_init(struct phy *phy)
}
/* Initialise Miphy for PCIe or SATA */
- if (miphy_phy-type == MIPHY_TYPE_PCIE)
+ if (miphy_phy-type == PHY_TYPE_PCIE)
ret = miphy365x_init_pcie_port(miphy_phy, miphy_dev);
else
ret = miphy365x_init_sata_port(miphy_phy, miphy_dev);
@@ -454,8 +454,8 @@ int miphy365x_get_addr(struct device *dev, struct
miphy365x_phy *miphy_phy,
return ret;
}
- if (!((!strncmp(name, sata, 4) type == MIPHY_TYPE_SATA) ||
- (!strncmp(name, pcie, 4) type == MIPHY_TYPE_PCIE)))
+ if (!((!strncmp(name, sata, 4) type == PHY_TYPE_SATA) ||
+ (!strncmp(name, pcie, 4) type == PHY_TYPE_PCIE)))
return 0;
miphy_phy-base = of_iomap(phynode, index);
@@ -498,8 +498,8 @@ static struct phy *miphy365x_xlate(struct device *dev,
miphy_phy-type = args-args[0];
- if (!(miphy_phy-type == MIPHY_TYPE_SATA ||
- miphy_phy-type == MIPHY_TYPE_PCIE)) {
+ if (!(miphy_phy-type == PHY_TYPE_SATA ||
+ miphy_phy-type == PHY_TYPE_PCIE)) {
dev_err(dev, Unsupported device type: %d\n, miphy_phy-type);
return ERR_PTR(-EINVAL);
}
diff --git a/include/dt-bindings/phy/phy-miphy365x.h
[PATCH 3/6] ARM: DT: STi: STiH407: Update picophyreset for the usb3 controllers usb2 phy
Ths picophyreset is incorrectly defined, which stops the usb2 phy being taken out of reset. Signed-off-by: Peter Griffin peter.grif...@linaro.org --- arch/arm/boot/dts/stih407-family.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi index c06a546..186412d 100644 --- a/arch/arm/boot/dts/stih407-family.dtsi +++ b/arch/arm/boot/dts/stih407-family.dtsi @@ -280,7 +280,7 @@ #phy-cells = 0; st,syscfg = syscfg_core 0x100 0xf4; resets = softreset STIH407_PICOPHY_SOFTRESET, -picophyreset STIH407_PICOPHY0_RESET; +picophyreset STIH407_PICOPHY2_RESET; reset-names = global, port; }; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] usb: dwc3: dwc3-st: Update the DT example.
There is a subtle type phys-names should be phy-names. Using the
current example means you don't have working usb. Also update
the example to use the generic phy type constants which are now
used for miphy28.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
index f9d7025..6634064 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-st.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -62,7 +62,7 @@ st_dwc3: dwc3@8f94000 {
reg = 0x0990 0x10;
interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
dr_mode = host;
- phys-names = usb2-phy, usb3-phy;
- phys= usb2_picophy2, phy_port2 MIPHY_TYPE_USB;
+ phy-names = usb2-phy, usb3-phy;
+ phys= usb2_picophy2, phy_port2 PHY_TYPE_USB3;
};
};
--
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: [STLinux Kernel] [PATCH v3 7/8] rtc: st: add new driver for ST's LPC RTC
Hi Russell, On Wed, 25 Feb 2015, Russell King - ARM Linux wrote: On Mon, Feb 23, 2015 at 10:12:23AM +, Peter Griffin wrote: I think all the writel IO accessors in this driver can be replaced with the *_relaxed variant. This will avoid the overhead of taking a spinlock in the l2 outer cache part of writel. You're really operating on old information. With much improved L2 cache support code which went in a year or so ago, for the popular L2 cache controllers, we don't take a spinlock anymore - we just write to the register directly. The spinlock is only present for L2C-220 controllers, which are rare. Moreover, taking the spinlock is only expensive if you have things like lockdep enabled, otherwise it should be inline and will be fast. However, using the _relaxed variants where we can get away with weaker ordering of the writes to the device is a good thing nevertheless. I'm just pointing out that your reasoning above is wrong. Thanks for pointing this out, I wasn't aware until now that the spinlock had been removed. regards Peter. -- 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] usb: dwc3: dwc3-st: Update the DT example.
On Wed, Feb 25, 2015 at 7:36 AM, Peter Griffin peter.grif...@linaro.org wrote:
There is a subtle type phys-names should be phy-names. Using the
current example means you don't have working usb. Also update
the example to use the generic phy type constants which are now
used for miphy28.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Rob Herring r...@kernel.org
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
index f9d7025..6634064 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-st.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -62,7 +62,7 @@ st_dwc3: dwc3@8f94000 {
reg = 0x0990 0x10;
interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
dr_mode = host;
- phys-names = usb2-phy, usb3-phy;
- phys= usb2_picophy2, phy_port2
MIPHY_TYPE_USB;
+ phy-names = usb2-phy, usb3-phy;
+ phys= usb2_picophy2, phy_port2
PHY_TYPE_USB3;
};
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/7] ARM: tegra: Make sure efuse is always selected
After the introduction of the efuse subsystem, platforms are now required to select the efuse support explicitly. Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: Alexandre Courbot gnu...@gmail.com Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com --- arch/arm/mach-tegra/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index 5d1a318..114ea4e 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -11,6 +11,7 @@ menuconfig ARCH_TEGRA select ARCH_HAS_RESET_CONTROLLER select RESET_CONTROLLER select SOC_BUS + select EFUSE_TEGRA select USB_ULPI if USB_PHY select USB_ULPI_VIEWPORT if USB_PHY help -- 2.3.0 -- 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/7] drivers: Introduce new eFuse subsystem stub
This commit introduces a new eFuse subsystem stub to hold all the eFuse-like device drivers. This will be used to host the currently supported Tegra eFuse driver, and will allow to add support for other platforms as well. Cc: Thierry Reding tred...@nvidia.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Arnd Bergmann a...@arndb.de Cc: Stefan Wahren stefan.wah...@i2se.com Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com --- drivers/Kconfig| 2 ++ drivers/Makefile | 1 + drivers/efuse/Kconfig | 3 +++ drivers/efuse/Makefile | 0 4 files changed, 6 insertions(+) create mode 100644 drivers/efuse/Kconfig create mode 100644 drivers/efuse/Makefile diff --git a/drivers/Kconfig b/drivers/Kconfig index c0cc96b..9c0d93d 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -146,6 +146,8 @@ source drivers/remoteproc/Kconfig source drivers/rpmsg/Kconfig +source drivers/efuse/Kconfig + source drivers/soc/Kconfig source drivers/devfreq/Kconfig diff --git a/drivers/Makefile b/drivers/Makefile index 527a6da..5572728 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -34,6 +34,7 @@ obj-y += amba/ obj-$(CONFIG_DMADEVICES) += dma/ # SOC specific infrastructure drivers. +obj-y += efuse/ obj-y += soc/ obj-$(CONFIG_VIRTIO) += virtio/ diff --git a/drivers/efuse/Kconfig b/drivers/efuse/Kconfig new file mode 100644 index 000..617476f --- /dev/null +++ b/drivers/efuse/Kconfig @@ -0,0 +1,3 @@ +menu eFuse drivers + +endmenu diff --git a/drivers/efuse/Makefile b/drivers/efuse/Makefile new file mode 100644 index 000..e69de29 -- 2.3.0 -- 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: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote: So the process steps basically look like this: 1.) cat capsule_ticket=== acquire a number and lock mutex then expose firmware_class user helper interface as well as start timer for timeout counting 2.) repeat step 1 if obtained a 0 number 3.) echo 1 loading 4.) cat bin data 5.) echo 0 loading=== stop the timeout counting then unlock mutex at the end of callback routine 6.) cat capsule_report === grep the number acquired from beginning for checking succeeded/failed So this sounds pretty overengineered for no reason, or maybe I'm missing the reason. If I had to give an example from the microcode loader, what we do there is put the microcode in /lib/firmware/... and do echo 1 /sys/devices/system/cpu/microcode/reload which goes and calls reload_store() in arch/x86/kernel/cpu/microcode/core.c which grabs a mutex, disables CPU hotplug, etc, etc... And this mechanism is as simple as it can get. Maybe capsules can be loaded like that too? Error code can be propagated too, if needed, of course. -- 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: DMA-API backtrace from rtsx_usb_ms driver
On Thu, 2015-02-19 at 11:58 -0500, Josh Boyer wrote: Hi All, We've had a few bug reports with the stack trace below. It looks like the ms_read_bytes and ms_write_bytes functions in drivers/memstick/host/rtsx_usb_mc.c are using a stack variable when calling rtsx_usb_ep0_read_register. That eventually gets to the DMA-API debugging checks, which throws the warning backtrace. A typical fix is to replace: u8 val; rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, val); dev_dbg(ms_dev(host), MS_TRANS_CFG: 0x%02x\n, val); with something like: u8 val = kzalloc(sizeof(u8), GFP_KERNEL); if (!val) return -ENOMEM; rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, val); dev_dbg(ms_dev(host), MS_TRANS_CFG: 0x%02x\n, val); kfree(val); However, I'm not familiar enough with this driver to know if this function is called frequently in an IRQ handler, etc. If the above pseudo code looks sufficient, I can come up with a patch. Thanks for reporting this. rtsx_usb_ep0_read_register() is not called in any interrupt context. It is a high-priority(control pipe) but less used alternative to communicate with device. It is primarily for error handling. I'll fix it inside rtsx_usb_ep0_read_register() itself by a DMA'able double buffer because it could be called somewhere else(e.g. mmc side). WARNING: CPU: 1 PID: 25 at lib/dma-debug.c:1166 check_for_stack+0x96/0xe0() ehci-pci :00:1a.0: DMA-API: device driver maps memory from stack [addr=8801199e3cef] Modules linked in: rtsx_usb_ms arc4 memstick intel_rapl iosf_mbi rtl8192ce snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel rtl_pci rtl8192c_common snd_hda_controller x86_pkg_temp_thermal snd_hda_codec rtlwifi mac80211 coretemp kvm_intel kvm iTCO_wdt snd_hwdep snd_seq snd_seq_device crct10dif_pclmul iTCO_vendor_support sparse_keymap cfg80211 crc32_pclmul snd_pcm crc32c_intel ghash_clmulni_intel rfkill i2c_i801 snd_timer shpchp snd serio_raw mei_me lpc_ich soundcore mei tpm_tis tpm wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 rtsx_usb_sdmmc mmc_core 8021q uas garp stp i2c_algo_bit llc mrp drm_kms_helper usb_storage drm rtsx_usb mfd_core r8169 mii video CPU: 1 PID: 25 Comm: kworker/1:2 Not tainted 3.20.0-0.rc0.git7.3.fc22.x86_64 #1 Hardware name: WB WB-B06211/WB-B0621, BIOS EB062IWB V1.0 12/12/2013 Workqueue: events rtsx_usb_ms_handle_req [rtsx_usb_ms] 3d188e66 8801199e3808 8187642b 8801199e3860 8801199e3848 810ab39a 8801199e3864 8801199e3cef 880119b57098 880119b37320 Call Trace: [8187642b] dump_stack+0x4c/0x65 [810ab39a] warn_slowpath_common+0x8a/0xc0 [810ab425] warn_slowpath_fmt+0x55/0x70 [8187efe6] ? _raw_spin_unlock_irqrestore+0x36/0x70 [81453156] check_for_stack+0x96/0xe0 [81453934] debug_dma_map_page+0x104/0x150 [81613b86] usb_hcd_map_urb_for_dma+0x646/0x790 [81614165] usb_hcd_submit_urb+0x1d5/0xa90 [81106f8f] ? mark_held_locks+0x7f/0xc0 [81106f8f] ? mark_held_locks+0x7f/0xc0 [81103a15] ? lockdep_init_map+0x65/0x5d0 [81615d7e] usb_submit_urb+0x42e/0x5f0 [81616787] usb_start_wait_urb+0x77/0x190 [8124f035] ? __kmalloc+0x205/0x2d0 [8161697c] usb_control_msg+0xdc/0x130 [a0031669] rtsx_usb_ep0_read_register+0x59/0x70 [rtsx_usb] [a00310c1] ? rtsx_usb_get_rsp+0x41/0x50 [rtsx_usb] [a071da4e] rtsx_usb_ms_handle_req+0x7ce/0x9c5 [rtsx_usb_ms] [810cc60b] ? process_one_work+0x19b/0x860 [810cc6a2] process_one_work+0x232/0x860 [810cc60b] ? process_one_work+0x19b/0x860 [810ccdaa] ? worker_thread+0xda/0x470 [810ccd23] worker_thread+0x53/0x470 [810cccd0] ? process_one_work+0x860/0x860 [810d31b4] kthread+0x104/0x120 [810e7fb5] ? local_clock+0x25/0x30 [810d30b0] ? kthread_create_on_node+0x250/0x250 [8187fb7c] ret_from_fork+0x7c/0xb0 [810d30b0] ? kthread_create_on_node+0x250/0x250 josh --Please consider the environment before printing this e-mail. -- Best regards, Roger Tseng
Re: [Linaro-acpi] [PATCH v3 4/9] ACPI: clean up checkpatch warnings for items with possible semantic value
On 2015年02月25日 08:36, al.st...@linaro.org wrote:
From: Al Stone al.st...@linaro.org
In preparation for later splitting out some of the arch-dependent code from
osl.c, clean up some warnings from checkpatch that fall into more semantic
issues; none of these should change functionality, but they do touch lines
of code with semantic significance:
-- replaced #include asm/foo.h with #include linux/foo.h
-- replaced extern that was only being used for sizeof() with a #define
-- removed use of else after breaks/returns when not useful
-- moved __initdata to the proper place in a definition
-- moved EXPORT_SYMBOL to a line immediately after the function
-- removed unnecessary return statements from void functions
Signed-off-by: Al Stone al.st...@linaro.org
---
drivers/acpi/osl.c | 31 ++-
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 46317ff..af6dda7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -40,9 +40,8 @@
#include linux/list.h
#include linux/jiffies.h
#include linux/semaphore.h
-
-#include asm/io.h
-#include asm/uaccess.h
+#include linux/io.h
+#include linux/uaccess.h
#include internal.h
@@ -66,7 +65,7 @@ struct acpi_os_dpc {
int acpi_in_debugger;
EXPORT_SYMBOL(acpi_in_debugger);
-extern char line_buf[80];
+#define DEBUGGER_LINE_BUFLEN 80
#endif/*ENABLE_DEBUGGER */
static int (*__acpi_os_prepare_sleep)(u8 sleep_state, u32 pm1a_ctrl,
@@ -268,10 +267,8 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
return efi.acpi20;
else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
return efi.acpi;
- else {
- pr_err(PREFIX System description tables not found\n);
- return 0;
- }
+ pr_err(PREFIX System description tables not found\n);
+ return 0;
} else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
acpi_physical_address pa = 0;
@@ -594,7 +591,7 @@ static const char * const table_sigs[] = {
#define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
#define ACPI_OVERRIDE_TABLES 64
-static struct cpio_data __initdata acpi_initrd_files[ACPI_OVERRIDE_TABLES];
+static struct cpio_data acpi_initrd_files[ACPI_OVERRIDE_TABLES] __initdata;
#define MAP_CHUNK_SIZE (NR_FIX_BTMAPS PAGE_SHIFT)
@@ -806,10 +803,10 @@ static irqreturn_t acpi_irq(int irq, void *dev_id)
if (handled) {
acpi_irq_handled++;
return IRQ_HANDLED;
- } else {
- acpi_irq_not_handled++;
- return IRQ_NONE;
}
+
+ acpi_irq_not_handled++;
+ return IRQ_NONE;
}
acpi_status
@@ -911,7 +908,6 @@ acpi_status acpi_os_read_port(acpi_io_address port, u32
*value, u32 width)
return AE_OK;
}
-
EXPORT_SYMBOL(acpi_os_read_port);
acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
@@ -927,7 +923,6 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32
value, u32 width)
return AE_OK;
}
-
EXPORT_SYMBOL(acpi_os_write_port);
#ifdef readq
@@ -1362,7 +1357,7 @@ u32 acpi_os_get_line(char *buffer)
if (acpi_in_debugger) {
u32 chars;
- kdb_read(buffer, sizeof(line_buf));
+ kdb_read(buffer, sizeof(DEBUGGER_LINE_BUFLEN));
I think kdb_read(buffer, DEBUGGER_LINE_BUFLEN); will be fine.
other than that,
Reviewd-by: Hanjun Guo hanjun@linaro.org
Thanks
Hanjun
/* remove the CR kdb includes */
chars = strlen(buffer) - 1;
@@ -1490,8 +1485,6 @@ static void __init set_osi_linux(unsigned int enable)
acpi_osi_setup(Linux);
else
acpi_osi_setup(!Linux);
-
- return;
}
static void __init acpi_cmdline_osi_linux(unsigned int enable)
@@ -1499,8 +1492,6 @@ static void __init acpi_cmdline_osi_linux(unsigned int
enable)
osi_linux.cmdline = 1; /* cmdline set the default and override DMI */
osi_linux.dmi = 0;
set_osi_linux(enable);
-
- return;
}
void __init acpi_dmi_osi_linux(int enable, const struct dmi_system_id *d)
@@ -1512,8 +1503,6 @@ void __init acpi_dmi_osi_linux(int enable, const struct
dmi_system_id *d)
osi_linux.dmi = 1; /* DMI knows that this box asks OSI(Linux) */
set_osi_linux(enable);
-
- return;
}
/*
--
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/4] x86: get rid of KERNEL_STACK_OFFSET
On 02/25/2015 01:48 PM, Denys Vlasenko wrote: On Wed, Feb 25, 2015 at 9:53 AM, Ingo Molnar mi...@kernel.org wrote: But the fix should be to not touch RSP in SAVE_ARGS, to keep percpu::kernel_stack as an optimized entry point - with KERNEL_STACK_OFFSET pointing to. So NAK - this should be fixed for real. IOW, the proposal is to set KERNEL_STACK_OFFSET to SIZEOF_PTREGS. I can do that. However. There is an ortogonal idea we were discussing: to save registers and construct iret frame using PUSH insns, not MOVs. IIRC Andy and Linus liked it. I am ambivalent: the code will be smaller, but might get slower (at least on some CPUs). If we go that way, we will require KERNEL_STACK_OFFSET = 0 (IOW: the current patch). The decision on how exactly we should fix KERNEL_STACK_OFFSET (set it to SIZEOF_PTREGS or to zero) depends on whether we switch to using PUSHes, or not. What do you think? A data point. I implemented push-based creation of pt_regs and benchmarked it. The patch is on top of all my latest patches sent to ML. On SandyBridge CPU, it does not get slower: seems to be 1 cycle faster per syscall. We lose a number of large insns there: text data bss dec hex filename - 9863 0 098632687 entry_64.o + 9671 0 0967125c7 entry_64.o diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index f505cb6..d97bd92 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -128,8 +128,6 @@ ENDPROC(native_usergs_sysret64) * manipulation. */ .macro FIXUP_TOP_OF_STACK tmp offset=0 - movq $__USER_DS,SS+\offset(%rsp) - movq $__USER_CS,CS+\offset(%rsp) movq RIP+\offset(%rsp),\tmp /* get rip */ movq \tmp,RCX+\offset(%rsp) /* copy it to rcx as sysret would do */ movq EFLAGS+\offset(%rsp),\tmp /* ditto for rflags-r11 */ @@ -245,14 +243,22 @@ GLOBAL(system_call_after_swapgs) * and short: */ ENABLE_INTERRUPTS(CLBR_NONE) - ALLOC_PT_GPREGS_ON_STACK 6*8 /* 6*8: space for orig_ax and iret frame */ - movq%rcx,RIP(%rsp) - movq%r11,EFLAGS(%rsp) - movqPER_CPU_VAR(old_rsp),%rcx - movq%rcx,RSP(%rsp) - movq_cfi rax,ORIG_RAX - SAVE_C_REGS_EXCEPT_RAX_RCX_R11 - movq$-ENOSYS,RAX(%rsp) + /* Construct struct pt_regs on stack */ + pushq $__USER_DS /* pt_regs-ss */ + pushq PER_CPU_VAR(old_rsp)/* pt_regs-sp */ + pushq %r11/* pt_regs-flags */ + pushq $__USER_CS /* pt_regs-cs */ + pushq %rcx/* pt_regs-ip */ + pushq %rax/* pt_regs-orig_ax */ + pushq %rdi/* pt_regs-di */ + pushq %rsi/* pt_regs-si */ + pushq %rdx/* pt_regs-dx */ + pushq %rcx/* pt_regs-cx */ + pushq $-ENOSYS/* pt_regs-ax */ + pushq %r8 /* pt_regs-r8 */ + pushq %r9 /* pt_regs-r9 */ + pushq %r10/* pt_regs-r10 */ + sub $(7*8),%rsp /* pt_regs-r11,bp,bx,r12-15 */ CFI_REL_OFFSET rip,RIP testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS) jnz tracesys -- 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] Add dwc3 usb3 DT node and various phy cleanup
Hi, This series primarily adds the dwc3 DT node which activates the usb3 controller on the stih407-b2120 and stih410-b2120 platforms. As part of getting this working I noticed some various errors with the DT documentation examples for how we reference the PHYs which I've also fixed. Whilst doing this I also noticed the miphy365 (found on stih415/6 platforms) could now use the generic PHY constants which are used by miphy28, so I've updated this driver and the DT docs accoringly.. Also miphy28lp driver isn't included in STI section of MAINTAINERS, so rectify that. regards, Peter. Peter Griffin (6): phy: miphy365x: Use the generic phy type constants in dt-bindings/phy/phy.h ahci: st: Update the DT example for how to obtain the PHY. ARM: DT: STi: STiH407: Update picophyreset for the usb3 controllers usb2 phy ARM: DT: STi: STiH407: Add dwc3 usb3 DT node. usb: dwc3: dwc3-st: Update the DT example. MAINTAINERS: Add phy-miphy28lp.c to ARCH/STI architecture Documentation/devicetree/bindings/ata/ahci-st.txt | 4 ++-- .../devicetree/bindings/phy/phy-miphy365x.txt | 8 +++ Documentation/devicetree/bindings/usb/dwc3-st.txt | 4 ++-- MAINTAINERS| 1 + arch/arm/boot/dts/stih407-family.dtsi | 28 +- arch/arm/boot/dts/stih416.dtsi | 4 ++-- drivers/phy/phy-miphy365x.c| 14 +-- include/dt-bindings/phy/phy-miphy365x.h| 14 --- 8 files changed, 45 insertions(+), 32 deletions(-) delete mode 100644 include/dt-bindings/phy/phy-miphy365x.h -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] ARM: DT: STi: STiH407: Add dwc3 usb3 DT node.
Now that both usb2 and usb3 phy drivers, and also the ST dwc3 glue code
are all present upstream, we can add the dwc3 DT node and have a working
usb3 controller on stih407-b2120 and stih410-b2020.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
arch/arm/boot/dts/stih407-family.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index 186412d..18ff5a5 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -7,6 +7,7 @@
* publishhed by the Free Software Foundation.
*/
#include stih407-pinctrl.dtsi
+#include dt-bindings/phy/phy.h
#include dt-bindings/reset-controller/stih407-resets.h
/ {
#address-cells = 1;
@@ -336,5 +337,30 @@
resets = softreset STIH407_MIPHY2_SOFTRESET;
};
};
+
+ st_dwc3: dwc3@8f94000 {
+ compatible = st,stih407-dwc3;
+ reg = 0x08f94000 0x1000, 0x110 0x4;
+ reg-names = reg-glue, syscfg-reg;
+ st,syscfg = syscfg_core;
+ resets = powerdown STIH407_USB3_POWERDOWN,
+ softreset STIH407_MIPHY2_SOFTRESET;
+ reset-names = powerdown,
+ softreset;
+ #address-cells = 1;
+ #size-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usb3;
+ ranges;
+
+ dwc3: dwc3@990 {
+ compatible = snps,dwc3;
+ reg = 0x0990 0x10;
+ interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
+ dr_mode = host;
+ phy-names = usb2-phy, usb3-phy;
+ phys= usb2_picophy0, phy_port2
PHY_TYPE_USB3;
+ };
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] rocker: silence shift wrapping warning
val is declared as a u64 so static checkers complain that this shift can wrap. I don't have the hardware but probably it's doesn't have over 31 ports. Still we may as well silence the warning even if it's not a real bug. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c index 713a13c..9fb6948 100644 --- a/drivers/net/ethernet/rocker/rocker.c +++ b/drivers/net/ethernet/rocker/rocker.c @@ -1257,9 +1257,9 @@ static void rocker_port_set_enable(struct rocker_port *rocker_port, bool enable) u64 val = rocker_read64(rocker_port-rocker, PORT_PHYS_ENABLE); if (enable) - val |= 1 rocker_port-lport; + val |= 1ULL rocker_port-lport; else - val = ~(1 rocker_port-lport); + val = ~(1ULL rocker_port-lport); rocker_write64(rocker_port-rocker, PORT_PHYS_ENABLE, val); } -- 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/2] rocker: silence shift wrapping warning
On Wed, Feb 25, 2015 at 5:36 AM, Dan Carpenter dan.carpen...@oracle.com wrote: val is declared as a u64 so static checkers complain that this shift can wrap. I don't have the hardware but probably it's doesn't have over 31 ports. Still we may as well silence the warning even if it's not a real bug. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c index 713a13c..9fb6948 100644 --- a/drivers/net/ethernet/rocker/rocker.c +++ b/drivers/net/ethernet/rocker/rocker.c @@ -1257,9 +1257,9 @@ static void rocker_port_set_enable(struct rocker_port *rocker_port, bool enable) u64 val = rocker_read64(rocker_port-rocker, PORT_PHYS_ENABLE); if (enable) - val |= 1 rocker_port-lport; + val |= 1ULL rocker_port-lport; else - val = ~(1 rocker_port-lport); + val = ~(1ULL rocker_port-lport); rocker_write64(rocker_port-rocker, PORT_PHYS_ENABLE, val); } Acked-by: Scott Feldman sfel...@gmail.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 v2 00/18] Add support to STMicroelectronics STM32 family
Hello David, 2015-02-24 15:14 GMT+01:00 David Howells dhowe...@redhat.com: Is support for this in upstream binutils and gcc? What's the preferred target tuple? I'll add support to Fedora's cross-binutils and cross-gcc sets if I can. I just rebuilt using latest upstream binutils and gcc. To compile Kernel and bootloader, I build a Bare Metal toolchain with this configuration: --target=arm-none-eabi --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard --with-mode=thumb BR, Maxime David -- 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/7] efuse: Move Sunxi fuse driver
The Sunxi SoC eFuse support is currently located under drivers/eeprom,
although the driver is not an eeprom. This commit just moves the driver
to drivers/efuse. There's no functionality change.
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com
---
drivers/efuse/Kconfig | 12
drivers/efuse/Makefile | 1 +
drivers/{misc/eeprom = efuse}/sunxi_sid.c | 0
drivers/misc/eeprom/Kconfig| 13 -
drivers/misc/eeprom/Makefile | 1 -
5 files changed, 13 insertions(+), 14 deletions(-)
rename drivers/{misc/eeprom = efuse}/sunxi_sid.c (100%)
diff --git a/drivers/efuse/Kconfig b/drivers/efuse/Kconfig
index b84e06b..a91a16e 100644
--- a/drivers/efuse/Kconfig
+++ b/drivers/efuse/Kconfig
@@ -6,5 +6,17 @@ config EFUSE_TEGRA
help
Support for the eFuses available on Tegra SoCs
+config EFUSE_SUNXI_SID
+ tristate Allwinner sunxi security ID support
+ depends on ARCH_SUNXI SYSFS
+ help
+ This is a driver for the 'security ID' available on various Allwinner
+ devices.
+
+ Due to the potential risks involved with changing e-fuses,
+ this driver is read-only.
+
+ This driver can also be built as a module. If so, the module
+ will be called sunxi_sid.
endmenu
diff --git a/drivers/efuse/Makefile b/drivers/efuse/Makefile
index b69a0d6..30f8d5e 100644
--- a/drivers/efuse/Makefile
+++ b/drivers/efuse/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_EFUSE_TEGRA) += tegra/
+obj-$(CONFIG_EFUSE_SUNXI_SID) += sunxi_sid.o
diff --git a/drivers/misc/eeprom/sunxi_sid.c b/drivers/efuse/sunxi_sid.c
similarity index 100%
rename from drivers/misc/eeprom/sunxi_sid.c
rename to drivers/efuse/sunxi_sid.c
diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
index 9536852f..04f2e1f 100644
--- a/drivers/misc/eeprom/Kconfig
+++ b/drivers/misc/eeprom/Kconfig
@@ -96,17 +96,4 @@ config EEPROM_DIGSY_MTC_CFG
If unsure, say N.
-config EEPROM_SUNXI_SID
- tristate Allwinner sunxi security ID support
- depends on ARCH_SUNXI SYSFS
- help
- This is a driver for the 'security ID' available on various Allwinner
- devices.
-
- Due to the potential risks involved with changing e-fuses,
- this driver is read-only.
-
- This driver can also be built as a module. If so, the module
- will be called sunxi_sid.
-
endmenu
diff --git a/drivers/misc/eeprom/Makefile b/drivers/misc/eeprom/Makefile
index 9507aec..fc1e81d 100644
--- a/drivers/misc/eeprom/Makefile
+++ b/drivers/misc/eeprom/Makefile
@@ -4,5 +4,4 @@ obj-$(CONFIG_EEPROM_LEGACY) += eeprom.o
obj-$(CONFIG_EEPROM_MAX6875) += max6875.o
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
obj-$(CONFIG_EEPROM_93XX46)+= eeprom_93xx46.o
-obj-$(CONFIG_EEPROM_SUNXI_SID) += sunxi_sid.o
obj-$(CONFIG_EEPROM_DIGSY_MTC_CFG) += digsy_mtc_eeprom.o
--
2.3.0
--
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/8 v2] ARM OMAP2+ GPMC: add bus children
Robert, On 24/02/15 22:05, Robert ABEL wrote: This patch adds support for spawning busses as children of the GPMC. Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de --- drivers/memory/omap-gpmc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 5cabac8..78b78a64 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -27,6 +27,7 @@ #include linux/of_address.h #include linux/of_mtd.h #include linux/of_device.h +#include linux/of_platform.h #include linux/omap-gpmc.h #include linux/mtd/nand.h #include linux/pm_runtime.h @@ -1800,7 +1801,7 @@ static int gpmc_probe_generic_child(struct platform_device *pdev, gpmc_cs_enable_mem(cs); no_timings: - if (of_platform_device_create(child, NULL, pdev-dev)) + if (!of_platform_populate(child, of_default_bus_match_table, NULL, pdev-dev)) return 0; This creates platform devices for the children of child, but what about platform device for the child itself? e.g. This fails to create the NOR device and instead starts creating children for NOR partitions instead. What bus device are you using. Shouldn't the bus driver for that bus be responsible for spawning children of its bus? dev_err(pdev-dev, failed to create gpmc child %s\n, child-name); cheers, -roger -- 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/7 v3] x86: get rid of KERNEL_STACK_OFFSET
PER_CPU_VAR(kernel_stack) was set up in a way where it points five stack slots below the top of stack. Presumably, it was done to avoid one sub $5*8,%rsp in syscall/sysenter code paths, where iret frame needs to be created by hand. Ironically, none of them benefit from this optimization, since all of them need to allocate additional data on stack (struct pt_regs), so they still have to perform subtraction. And ia32_sysenter_target even needs to *undo* this optimization: it constructs iret stack with pushes instead of movs, so it needs to start right at the top. This patch eliminates KERNEL_STACK_OFFSET. PER_CPU_VAR(kernel_stack) now points directly to top of stack. pt_regs allocations are adjusted to allocate iret frame as well. Semi-mysterious expressions THREAD_INFO(%rsp,RIP) - why RIP?? are now replaced by more logical THREAD_INFO(%rsp,SIZEOF_PTREGS) - rsp is SIZEOF_PTREGS bytes below the top, calculate thread_info's address using that information Net result in code is that one instruction is eliminated, and constants in several others have changed. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- Changes since v1: BUG_ON fix in traps.c Changes since v2: removed 5 slots (iret frame) are preallocated comment arch/x86/ia32/ia32entry.S | 35 +-- arch/x86/include/asm/thread_info.h | 8 +++- arch/x86/kernel/cpu/common.c | 2 +- arch/x86/kernel/entry_64.S | 9 - arch/x86/kernel/process_32.c | 3 +-- arch/x86/kernel/process_64.c | 3 +-- arch/x86/kernel/smpboot.c | 3 +-- arch/x86/kernel/traps.c| 3 ++- arch/x86/xen/smp.c | 3 +-- 9 files changed, 31 insertions(+), 38 deletions(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S index ed97463..eb9d690 100644 --- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -114,7 +114,6 @@ ENTRY(ia32_sysenter_target) CFI_REGISTERrsp,rbp SWAPGS_UNSAFE_STACK movqPER_CPU_VAR(kernel_stack), %rsp - addq$(KERNEL_STACK_OFFSET),%rsp /* * No need to follow this irqs on/off section: the syscall * disabled irqs, here we enable it straight after entry: @@ -128,7 +127,7 @@ ENTRY(ia32_sysenter_target) CFI_REL_OFFSET rsp,0 pushfq_cfi /*CFI_REL_OFFSET rflags,0*/ - movl TI_sysenter_return+THREAD_INFO(%rsp,3*8-KERNEL_STACK_OFFSET),%r10d + movlTI_sysenter_return+THREAD_INFO(%rsp,3*8),%r10d CFI_REGISTER rip,r10 pushq_cfi $__USER32_CS /*CFI_REL_OFFSET cs,0*/ @@ -160,8 +159,8 @@ ENTRY(ia32_sysenter_target) jnz sysenter_fix_flags sysenter_flags_fixed: - orl $TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP) - testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,RIP) + orl $TS_COMPAT,TI_status+THREAD_INFO(%rsp,SIZEOF_PTREGS) + testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS) CFI_REMEMBER_STATE jnz sysenter_tracesys cmpq$(IA32_NR_syscalls-1),%rax @@ -178,10 +177,10 @@ sysenter_dispatch: movq%rax,RAX(%rsp) DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF - testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP) + testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS) jnz sysexit_audit sysexit_from_sys_call: - andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP) + andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,SIZEOF_PTREGS) /* clear IF, that popfq doesn't enable interrupts early */ andl$~0x200,EFLAGS(%rsp) movlRIP(%rsp),%edx /* User %eip */ @@ -226,7 +225,7 @@ sysexit_from_sys_call: .endm .macro auditsys_exit exit - testl $(_TIF_ALLWORK_MASK ~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP) + testl $(_TIF_ALLWORK_MASK ~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS) jnz ia32_ret_from_sys_call TRACE_IRQS_ON ENABLE_INTERRUPTS(CLBR_NONE) @@ -241,7 +240,7 @@ sysexit_from_sys_call: movl $(_TIF_ALLWORK_MASK ~_TIF_SYSCALL_AUDIT),%edi DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF - testl %edi,TI_flags+THREAD_INFO(%rsp,RIP) + testl %edi,TI_flags+THREAD_INFO(%rsp,SIZEOF_PTREGS) jz \exit CLEAR_RREGS jmp int_with_check @@ -263,7 +262,7 @@ sysenter_fix_flags: sysenter_tracesys: #ifdef CONFIG_AUDITSYSCALL
Re: [PATCH 0/7] New eFuse subsystem
On 02/25/2015 09:02 AM, Maxime Ripard wrote: Hi Ezequiel, On Wed, Feb 25, 2015 at 08:45:12AM -0300, Ezequiel Garcia wrote: This patchset introduces a new driver subsystem, meant to support eFuse (alias OTP, one-time-programmable) devices. The motivation behind this work is to have a common place for drivers that are currently more or less scattered: the tegra efuses are in drivers/soc/ and the sunxi efuses in drivers/misc/eeprom. For now, there's no proposal for a generic efuse API. Instead, we simply group the drivers together. This patchset is the result of the initial submission for IMG Pistachio eFuse support [1]. Our first proposal was to follow the Tegra efuse, and put the Pistachio efuse in drivers/soc. After some discussion we finally agreed [2] to first create an efuse directoy, and then put all efuse drivers in it. As always, all comments are welcome! [1] http://www.spinics.net/lists/devicetree/msg59246.html [2] http://www.spinics.net/lists/arm-kernel/msg389325.html Have you looked at the EEPROM framework currently in discussions? The two seems to be covering pretty much the same use cases. Nope, I was obviously unaware of that. Guess we'll wait until the discussion is settled and use that framework. Thanks! -- Ezequiel -- 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] vfs: avoid recopying filename in getname_flags
In the current implementation of getname_flags, filename in the
user-space will be recopied if it takes more space that
EMBEDDED_NAME_MAX, however, at this moment, EMBEDDED_NAME_MAX bytes of
the filename are already copied into kernel space, the only reason why
the recopy is needed is that kname needs to be relocated.
And the recopy can be avoided if we change the memory layout of the
names_cache allocation. By putting the struct filename at the tail
of the allocation instead of the head, relocation of kname is avoided.
Once putting the struct at the tail, each byte in the user space will be
copied only one time, so the recopy is avoided and code is more clear.
Of course, other functions aware of the layout of the names_cache
allocation, i.e., getname_kernel and putname also need to be modified to
adapt to the new layout.
This patch is based on v4.0-rc1.
Cc: Al Viro v...@zeniv.linux.org.uk
Cc: Paul Moore pmo...@redhat.com
Signed-off-by: Boqun Feng boqun.f...@gmail.com
---
fs/namei.c | 50 +++---
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index c83145a..3be372b 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -133,21 +133,20 @@ getname_flags(const char __user *filename, int flags, int
*empty)
if (result)
return result;
- result = __getname();
- if (unlikely(!result))
+ kname = __getname();
+ if (unlikely(!kname))
return ERR_PTR(-ENOMEM);
- result-refcnt = 1;
/*
* First, try to embed the struct filename inside the names_cache
* allocation
*/
- kname = (char *)result + sizeof(*result);
+ result = (struct filename *)(kname + EMBEDDED_NAME_MAX);
result-name = kname;
result-separate = false;
+ result-refcnt = 1;
max = EMBEDDED_NAME_MAX;
-recopy:
len = strncpy_from_user(kname, filename, max);
if (unlikely(len 0)) {
err = ERR_PTR(len);
@@ -157,23 +156,34 @@ recopy:
/*
* Uh-oh. We have a name that's approaching PATH_MAX. Allocate a
* separate struct filename so we can dedicate the entire
-* names_cache allocation for the pathname, and re-do the copy from
+* names_cache allocation for the pathname, and continue the copy from
* userland.
*/
- if (len == EMBEDDED_NAME_MAX max == EMBEDDED_NAME_MAX) {
- kname = (char *)result;
-
+ if (len == EMBEDDED_NAME_MAX) {
result = kzalloc(sizeof(*result), GFP_KERNEL);
if (!result) {
err = ERR_PTR(-ENOMEM);
- result = (struct filename *)kname;
+ result = (struct filename *)(kname + EMBEDDED_NAME_MAX);
goto error;
}
result-name = kname;
result-separate = true;
result-refcnt = 1;
- max = PATH_MAX;
- goto recopy;
+ max = PATH_MAX - EMBEDDED_NAME_MAX;
+ /* we can't simply add the number of rest chars we copy to len,
+* since strncpy_from_user may return negative to indicate
+* something is wrong, so we do the addition later, after
+* strncpy_from_user succeeds, and we know we already copy
+* EMBEDDED_NAME_MAX chars.
+*/
+ len = strncpy_from_user(kname + EMBEDDED_NAME_MAX,
+ filename + EMBEDDED_NAME_MAX, max);
+
+ if (unlikely(len 0)) {
+ err = ERR_PTR(len);
+ goto error;
+ }
+ len += EMBEDDED_NAME_MAX;
}
/* The empty path is special. */
@@ -209,28 +219,30 @@ struct filename *
getname_kernel(const char * filename)
{
struct filename *result;
+ char *kname;
int len = strlen(filename) + 1;
- result = __getname();
- if (unlikely(!result))
+ kname = __getname();
+ if (unlikely(!kname))
return ERR_PTR(-ENOMEM);
if (len = EMBEDDED_NAME_MAX) {
- result-name = (char *)(result) + sizeof(*result);
+ result = (struct filename *)(kname + EMBEDDED_NAME_MAX);
+ result-name = kname;
result-separate = false;
} else if (len = PATH_MAX) {
struct filename *tmp;
tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
if (unlikely(!tmp)) {
- __putname(result);
+ __putname(kname);
return ERR_PTR(-ENOMEM);
}
- tmp-name = (char *)result;
+ tmp-name = kname;
tmp-separate = true;
result = tmp;
} else {
- __putname(result);
+
Re: [PATCH v2] x86, boot: Allow 64bit EFI kernel to be loaded above 4G
On Tue, 24 Feb, at 04:31:27PM, Yinghai Lu wrote: On Tue, Feb 24, 2015 at 1:55 PM, Matt Fleming m...@codeblueprint.co.uk wrote: On Sun, 22 Feb, at 07:43:48PM, Yinghai Lu wrote: +Field name: ext_code32_start +Type:modify (optional, reloc) +Offset/size: 0x268/4 +Protocol:2.14+ + + This field is the upper 32bits of load address when EFI 64bit kernel + is loaded above 4G. And it is used with code32_start to compare to + pref_address to decide if kernel need to be relocated further. I think we can delete the second sentence. But these are minimal changes and I'm happy to fix them up when applying this patch if that's OK? Sure. Please go ahead. Applied, thanks Yinghai. -- Matt Fleming, 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 v2] x86, boot: Allow 64bit EFI kernel to be loaded above 4G
On Wed, 25 Feb, at 11:31:32AM, Ingo Molnar wrote: * Matt Fleming m...@codeblueprint.co.uk wrote: On Sun, 22 Feb, at 07:43:48PM, Yinghai Lu wrote: Index: linux-2.6/arch/x86/boot/header.S === --- linux-2.6.orig/arch/x86/boot/header.S +++ linux-2.6/arch/x86/boot/header.S @@ -301,7 +301,7 @@ _start: # Part 2 of the header, from the old setup.S .ascii HdrS # header signature - .word 0x020d # header version number (= 0x0105) + .word 0x020e # header version number (= 0x0105) # or else old loadlin-1.5 will fail) .globl realmode_swtch realmode_swtch: .word 0, 0# default_switch, SETUPSEG @@ -449,6 +449,7 @@ pref_address: .quad LOAD_PHYSICAL_ADDR #endif init_size: .long INIT_SIZE # kernel initialization size handover_offset: .long 0 # Filled in by build.c +ext_code32_start:.long 0 # werid one! How about a comment like, # Upper 32-bits of code32_start ? Also, in the Linux kernel we should not go about inventing new English words like 'werid', right? Yeah, my intention is to replace werid one with the comment I suggested above. -- Matt Fleming, 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 6/8 v2] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER
On 24/02/15 22:05, Robert ABEL wrote:
The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a
divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
Acked-by: Roger Quadros rog...@ti.com
cheers,
-roger
---
drivers/memory/omap-gpmc.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index ff1a1e7..a6abaf0 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -566,19 +566,14 @@ int gpmc_cs_set_timings(int cs, const struct
gpmc_timings *t)
if (gpmc_capability GPMC_HAS_WR_ACCESS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
- /* caller is expected to have initialized CONFIG1 to cover
- * at least sync vs async
- */
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
- if (l (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
- cs, (div * gpmc_get_fclk_period()) / 1000, div);
+ printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
+ cs, (div * gpmc_get_fclk_period()) / 1000, div);
#endif
- l = ~0x03;
- l |= (div - 1);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
- }
+ l = ~0x03;
+ l |= (div - 1);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
gpmc_cs_bool_timings(cs, t-bool_timings);
gpmc_cs_show_timings(cs, after gpmc_cs_set_timings);
--
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: [Linaro-acpi] [PATCH v3 5/9] ACPI: move acpi_os_handler() so it can be made arch-dependent later
On 2015年02月25日 08:36, al.st...@linaro.org wrote: From: Al Stone al.st...@linaro.org In order to deprecate the use of _OSI for arm64 or other new architectures, we need to make the default handler something we can change for various platforms. This patch moves the definition of acpi_osi_handler() -- the function used by ACPICA as a callback for evaluating _OSI -- into a separate file. Subsequent patches will change which files get built so that we can then build the version of _OSI we need for a particular architecture. There is no functional change. Signed-off-by: Al Stone al.st...@linaro.org --- drivers/acpi/Makefile | 2 +- drivers/acpi/osi.c| 95 +++ drivers/acpi/osl.c| 24 - include/linux/acpi.h | 1 + 4 files changed, 97 insertions(+), 25 deletions(-) create mode 100644 drivers/acpi/osi.c diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index 13536d8..97191eb 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -18,7 +18,7 @@ obj-y += acpi.o \ acpica/ # All the builtin files are in the acpi. module_param namespace. -acpi-y += osl.o utils.o reboot.o +acpi-y += osl.o utils.o reboot.o osi.o acpi-y+= nvs.o # Power management related files diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c new file mode 100644 index 000..f23aa70 --- /dev/null +++ b/drivers/acpi/osi.c @@ -0,0 +1,95 @@ +/* + * osi.c - _OSI implementation (moved from drivers/acpi/osl.c) + * + * Copyright (C) 2000 Andrew Henroid + * Copyright (C) 2001, 2002 Andy Grover andrew.gro...@intel.com + * Copyright (C) 2001, 2002 Paul Diefenbaugh paul.s.diefenba...@intel.com + * Copyright (c) 2008 Intel Corporation + * Author: Matthew Wilcox wi...@linux.intel.com + * + * ~~ + * + * 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. + * + * ~~ + * + */ + +#include linux/acpi.h + +#define _COMPONENT ACPI_OS_SERVICES +ACPI_MODULE_NAME(osi); + +#define PREFIX ACPI: Hi Al, remove PREFIX here and use pr_fmt() instead as I mentioned in previous patch :) Thanks Hanjun -- 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] mfd: arizona: Move useful defines into a dt-binding include
Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in
the dt-binding directory for use by device tree bindings. This also
makes gpio.h redundant so remove it in the process.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
Acked-by: Mark Brown broo...@kernel.org
---
Changes since v1:
- Removed some defines that will never be used in DT from the
dt-binding include
- Added some convience defines for the most common pin configs
(input/output/default)
- Updated the binding documentation to use the new defines to
give some context to their usage
Thanks,
Charles
Documentation/devicetree/bindings/mfd/arizona.txt | 20 ++--
include/dt-bindings/mfd/arizona.h | 93
include/linux/mfd/arizona/gpio.h | 96 -
include/linux/mfd/arizona/pdata.h | 22 +-
sound/soc/codecs/arizona.c|1 -
5 files changed, 105 insertions(+), 127 deletions(-)
create mode 100644 include/dt-bindings/mfd/arizona.h
delete mode 100644 include/linux/mfd/arizona/gpio.h
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 7bd1273..bfef000 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -36,11 +36,11 @@ Optional properties:
- wlf,reset : GPIO specifier for the GPIO controlling /RESET
- wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
- - wlf,gpio-defaults : A list of GPIO configuration register values. If
-absent, no configuration of these registers is performed. If any
-entry has a value that is out of range for a 16 bit register then
-the chip default will be used. If present exactly five values must
-be specified.
+ - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
+for the appropriate values can found in dt-bindings/mfd/arizona.txt. If
+absent, no configuration of these registers is performed. If any entry has
+a value that is out of range for a 16 bit register then the chip default
+will be used. If present exactly five values must be specified.
- wlf,inmode : A list of INn_MODE register values, where n is the number
of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
@@ -73,10 +73,10 @@ codec: wm5102@1a {
#gpio-cells = 2;
wlf,gpio-defaults =
- 0x /* AIF1TXLRCLK */
- 0x
- 0x
- 0x
- 0x
+ ARIZONA_GP_FN_TXLRCLK
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
;
};
diff --git a/include/dt-bindings/mfd/arizona.h
b/include/dt-bindings/mfd/arizona.h
new file mode 100644
index 000..c7af7c7
--- /dev/null
+++ b/include/dt-bindings/mfd/arizona.h
@@ -0,0 +1,93 @@
+/*
+ * Device Tree defines for Arizona devices
+ *
+ * Copyright 2015 Cirrus Logic Inc.
+ *
+ * Author: Charles Keepax ckee...@opensource.wolfsonmicro.com
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_MFD_ARIZONA_H
+#define _DT_BINDINGS_MFD_ARIZONA_H
+
+/* GPIO Function Definitions */
+#define ARIZONA_GP_FN_TXLRCLK0x00
+#define ARIZONA_GP_FN_GPIO 0x01
+#define ARIZONA_GP_FN_IRQ1 0x02
+#define ARIZONA_GP_FN_IRQ2 0x03
+#define ARIZONA_GP_FN_OPCLK 0x04
+#define ARIZONA_GP_FN_FLL1_OUT 0x05
+#define ARIZONA_GP_FN_FLL2_OUT 0x06
+#define ARIZONA_GP_FN_PWM1 0x08
+#define ARIZONA_GP_FN_PWM2 0x09
+#define ARIZONA_GP_FN_SYSCLK_UNDERCLOCKED0x0A
+#define ARIZONA_GP_FN_ASYNCCLK_UNDERCLOCKED 0x0B
+#define ARIZONA_GP_FN_FLL1_LOCK 0x0C
+#define ARIZONA_GP_FN_FLL2_LOCK 0x0D
+#define ARIZONA_GP_FN_FLL1_CLOCK_OK 0x0F
+#define ARIZONA_GP_FN_FLL2_CLOCK_OK 0x10
+#define ARIZONA_GP_FN_HEADPHONE_DET 0x12
+#define ARIZONA_GP_FN_MIC_DET0x13
+#define ARIZONA_GP_FN_WSEQ_STATUS0x15
+#define ARIZONA_GP_FN_CIF_ADDRESS_ERROR 0x16
+#define ARIZONA_GP_FN_ASRC1_LOCK 0x1A
+#define ARIZONA_GP_FN_ASRC2_LOCK 0x1B
+#define ARIZONA_GP_FN_ASRC_CONFIG_ERROR 0x1C
+#define ARIZONA_GP_FN_DRC1_SIGNAL_DETECT 0x1D
+#define ARIZONA_GP_FN_DRC1_ANTICLIP 0x1E
+#define ARIZONA_GP_FN_DRC1_DECAY 0x1F
+#define ARIZONA_GP_FN_DRC1_NOISE 0x20
+#define ARIZONA_GP_FN_DRC1_QUICK_RELEASE 0x21
+#define
[PATCH] phy: miphy28lp: Add missing .owner field in miphy28lp_ops
Add missing .owner field in miphy28lp_ops, which is used for refcounting.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/phy/phy-miphy28lp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/phy-miphy28lp.c b/drivers/phy/phy-miphy28lp.c
index 9b2848e..44e2861 100644
--- a/drivers/phy/phy-miphy28lp.c
+++ b/drivers/phy/phy-miphy28lp.c
@@ -1138,6 +1138,7 @@ static struct phy *miphy28lp_xlate(struct device *dev,
static struct phy_ops miphy28lp_ops = {
.init = miphy28lp_init,
+ .owner = THIS_MODULE,
};
static int miphy28lp_probe_resets(struct device_node *node,
--
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: [Xen-devel] [PATCH 06/13] xen: detect pre-allocated memory interfering with e820 map
On 24/02/15 06:27, Juergen Gross wrote:
On 02/19/2015 07:07 PM, David Vrabel wrote:
On 18/02/2015 06:51, Juergen Gross wrote:
+{
+unsigned long pfn;
+unsigned long area_start, area_end;
+unsigned i;
+
+for (i = 0; i XEN_N_RESERVED_AREAS; i++) {
+
+if (!xen_reserved_area[i].size)
+break;
+
+area_start = PFN_DOWN(xen_reserved_area[i].start);
+area_end = PFN_UP(xen_reserved_area[i].start +
+ xen_reserved_area[i].size);
+if (area_start = end_pfn || area_end = start_pfn)
+continue;
+
+if (area_start start_pfn)
+xen_set_identity_and_remap_chunk(start_pfn, area_start,
+ released, remapped);
+
+if (area_end end_pfn)
+xen_set_identity_and_remap_chunk(area_end, end_pfn,
+ released, remapped);
+
+*remapped += min(area_end, end_pfn) -
+max(area_start, start_pfn);
+
+return;
Why not defer the whole chunk that conflicts? Or for that matter defer
all this remapping to the last minute.
There are two problems arising from this:
- In the initrd case remapping would be deferred too long: the initrd
data is still in use when device initialization is running. And we
really want the remap to have happened before PCI space is being used.
I'm not sure I understand what you're saying here.
I'm suggesting:
1. Reserve all holes.
2. Relocate (if necessary) all modules (initrd, etc.) to regions that
are RAM in the e820.
3. Rebuild the p2m in RAM.
4. Relocate frames from E820 holes/reserved to the end, free p2m pages
from the holes and replacing them with the read-only 1:1 page (where
possible).
- Delaying all remapping to the point where the new p2m list is in place
would either result in a p2m list with all memory holes covered with
individual entries as the new list is built with those holes still
populated, ...
The first option could easily waste significant amounts of memory (on
my test machine with 1TB RAM this would have been about 1GB), while
the second option would be performance critical.
I don't understand how this wastes memory. When you relocate the
frames from the holes you can reclaim the p2m pages for the holes (and
replace them with the r/o mapped identity p2m page).
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm-cci: Split the code for PMU vs driver support
On Wed, 25 Feb 2015, Suzuki K. Poulose wrote: On 24/02/15 22:17, Nicolas Pitre wrote: On Tue, 24 Feb 2015, Suzuki K. Poulose wrote: From: Suzuki K. Poulose suzuki.poul...@arm.com This patch separates the PMU driver code from the low level CCI driver code, and enables the CCI400-PMU for ARM64. Introduces config options for both. - ARM_CCI400_MCPM - controls the low level MCPM driver code for CCI - ARM_CCI400_PMU- controls the PMU driver code - ARM_CCI400_COMMON - CCI400 specific details shared by MCPM and PMU Changes: - ARM_CCI - common code for probing the CCI devices Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Cc: Kukjin Kim kg...@kernel.org Cc: Abhilash Kesavan a.kesa...@samsung.com Cc: Liviu Dudau liviu.du...@arm.com Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com Cc: Sudeep Holla sudeep.ho...@arm.com Signed-off-by: Suzuki K. Poulose suzuki.poul...@arm.com Comments inline. --- arch/arm/mach-exynos/Kconfig |2 +- arch/arm/mach-vexpress/Kconfig |4 ++-- drivers/bus/Kconfig| 28 +++- drivers/bus/arm-cci.c | 25 + include/linux/arm-cci.h|7 ++- 5 files changed, 53 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 603820e..9bc8b4d 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -123,7 +123,7 @@ config SOC_EXYNOS5800 config EXYNOS5420_MCPM bool Exynos5420 Multi-Cluster PM support depends on MCPM SOC_EXYNOS5420 - select ARM_CCI + select ARM_CCI400_MCPM select ARM_CPU_SUSPEND help This is needed to provide CPU and cluster power management diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig index d6b16d9..097912f 100644 --- a/arch/arm/mach-vexpress/Kconfig +++ b/arch/arm/mach-vexpress/Kconfig @@ -53,7 +53,7 @@ config ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA config ARCH_VEXPRESS_DCSCB bool Dual Cluster System Control Block (DCSCB) support depends on MCPM - select ARM_CCI + select ARM_CCI400_MCPM help Support for the Dual Cluster System Configuration Block (DCSCB). This is needed to provide CPU and cluster power management @@ -71,7 +71,7 @@ config ARCH_VEXPRESS_SPC config ARCH_VEXPRESS_TC2_PM bool Versatile Express TC2 power management depends on MCPM - select ARM_CCI + select ARM_CCI400_MCPM select ARCH_VEXPRESS_SPC help Support for CPU and cluster power management on Versatile Express diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index b99729e..91dd013 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -43,12 +43,30 @@ config OMAP_INTERCONNECT help Driver to enable OMAP interconnect error handling driver. -config ARM_CCI - bool ARM CCI driver support - depends on ARM OF CPU_V7 +config ARM_CCI400_MCPM + bool + depends on ARM OF CPU_V7 MCPM MCPM is not an actual dependency and therefore should probably not be added here. OK, will remove that. You removed the prompt string therefore this will only be selectable explicitly as needed. This was intentional, I missed mentioning about it. Do you think we need to change it back ? No. I'm perfectly fine with those platforms needing it for proper operation to explicitly select this. I don't see much value in having this user configurable. Also, shouldn't it select ARM_CCI400_COMMON ? Thanks for that, yes it should. + help + Low level power management driver for CCI400 cache coherent + interconnect for ARM platforms. + +config ARM_CCI400_PMU + bool ARM CCI400 PMU support + depends on ARM || ARM64 + depends on HW_PERF_EVENTS + select ARM_CCI400_COMMON help - Driver supporting the CCI cache coherent interconnect for ARM - platforms. + Support for PMU events monitoring on the ARM CCI cache coherent + interconnect. + + If unsure, say N + +config ARM_CCI400_COMMON + bool + select ARM_CCI + +config ARM_CCI + bool Surely you could do with only one of ARM_CCI or ARM_CCI400_COMMON? Personally I'd go with the later as it is more precise. The ARM_CCI now stands for CCI version agnostic code. This can be used for adding support for the newer versions, e.g CCI-500, which I am planning to post, after this series gets sorted out. OK. Please add a note to that effect in the commit log. config ARM_CCN bool ARM CCN driver support diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c index fe9fa46..7e330fe 100644 --- a/drivers/bus/arm-cci.c +++ b/drivers/bus/arm-cci.c @@ -32,6
RE: [PATCH 1/2] Drivers: hv: hv_balloon: report offline pages as being used
-Original Message-
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
Sent: Thursday, February 19, 2015 8:27 AM
To: KY Srinivasan; de...@linuxdriverproject.org
Cc: Haiyang Zhang; linux-kernel@vger.kernel.org; Dexuan Cui
Subject: [PATCH 1/2] Drivers: hv: hv_balloon: report offline pages as being
used
When hot-added memory pages are not brought online or when some
memory blocks
are sent offline the subsequent ballooning process kills the guest with OOM
killer. This happens as we don't report these pages as neither used nor free
and apparently host algorythm considers them as being unused. Keep track
of
all online/offline operations and report all currently offline pages as being
used so host won't try to balloon them out.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
drivers/hv/hv_balloon.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index a095b70..e4b4454 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -503,6 +503,8 @@ struct hv_dynmem_device {
* Number of pages we have currently ballooned out.
*/
unsigned int num_pages_ballooned;
+ unsigned int num_pages_onlined;
+ unsigned int num_pages_added;
/*
* State to manage the ballooning (up) operation.
@@ -556,12 +558,15 @@ static void post_status(struct hv_dynmem_device
*dm);
static int hv_memory_notifier(struct notifier_block *nb, unsigned long val,
void *v)
{
+ struct memory_notify *mem = (struct memory_notify *)v;
+
switch (val) {
case MEM_GOING_ONLINE:
mutex_lock(dm_device.ha_region_mutex);
break;
case MEM_ONLINE:
+ dm_device.num_pages_onlined += mem-nr_pages;
case MEM_CANCEL_ONLINE:
Why are we not adjusting num_pages_onlined when we cancel the online
Operation.
K. Y
--
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] virtio-balloon: do not call blocking ops when !TASK_RUNNING
On Wed, 25 Feb 2015 15:14:36 +0100
Michael S. Tsirkin m...@redhat.com wrote:
virtio balloon has this code:
wait_event_interruptible(vb-config_change,
(diff = towards_target(vb)) != 0
|| vb-need_stats_update
|| kthread_should_stop()
|| freezing(current));
Which is a problem because towards_target() call might block after
wait_event_interruptible sets task state to TAST_INTERRUPTIBLE, causing
the task_struct::state collision typical of nesting of sleeping
primitives
See also http://lwn.net/Articles/628628/ or Thomas's
bug report
http://article.gmane.org/gmane.linux.kernel.virtualization/24846
for a fuller explanation.
To fix, rewrite using wait_woken.
Cc: sta...@vger.kernel.org
Reported-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/virtio/virtio_balloon.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 0413157..2f19f65 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -29,6 +29,7 @@
#include linux/module.h
#include linux/balloon_compaction.h
#include linux/oom.h
+#include linux/wait.h
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -334,12 +335,25 @@ static int virtballoon_oom_notify(struct notifier_block
*self,
static int balloon(void *_vballoon)
{
struct virtio_balloon *vb = _vballoon;
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
set_freezable();
while (!kthread_should_stop()) {
s64 diff;
try_to_freeze();
+
+ add_wait_queue(vb-config_change, wait);
+ for (;;) {
+ if ((diff = towards_target(vb)) != 0 ||
+ vb-need_stats_update ||
+ kthread_should_stop() ||
+ freezing(current))
+ break;
+ wait_woken(wait, TASK_INTERRUPTIBLE,
MAX_SCHEDULE_TIMEOUT);
+ }
+ remove_wait_queue(vb-config_change, wait);
+
wait_event_interruptible(vb-config_change,
(diff = towards_target(vb)) != 0
|| vb-need_stats_update
Forgot to remove the wait_event_interruptible()?
--
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/6] phy: miphy365x: Use the generic phy type constants in dt-bindings/phy/phy.h
On Wed, Feb 25, 2015 at 7:36 AM, Peter Griffin peter.grif...@linaro.org wrote:
Now there are generic phy type constants declared in phy.h, migrate over to
using them rather than defining our own. This change has been done as one
atomic commit to be bisectable.
You should note that the values of the defines are not changed. If
they did, that would be an ABI breakage.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Rob Herring r...@kernel.org
---
Documentation/devicetree/bindings/phy/phy-miphy365x.txt | 8
arch/arm/boot/dts/stih416.dtsi | 4 ++--
drivers/phy/phy-miphy365x.c | 14 +++---
include/dt-bindings/phy/phy-miphy365x.h | 14 --
4 files changed, 13 insertions(+), 27 deletions(-)
delete mode 100644 include/dt-bindings/phy/phy-miphy365x.h
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
index 9802d5d..8772900 100644
--- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -20,8 +20,8 @@ Required nodes: A sub-node is required for each
channel the controller
Required properties (port (child) node):
- #phy-cells : Should be 1 (See second example)
Cell after port phandle is device type from:
- - MIPHY_TYPE_SATA
- - MIPHY_TYPE_PCI
+ - PHY_TYPE_SATA
+ - PHY_TYPE_PCI
- reg : Address and length of register sets for each device in
reg-names
- reg-names : The names of the register addresses corresponding to the
@@ -68,10 +68,10 @@ property, containing a phandle to the phy port node and a
device type.
Example:
-#include dt-bindings/phy/phy-miphy365x.h
+#include dt-bindings/phy/phy.h
sata0: sata@fe38 {
...
- phys = phy_port0 MIPHY_TYPE_SATA;
+ phys = phy_port0 PHY_TYPE_SATA;
...
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index ea28eba..eeb7afe 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -10,7 +10,7 @@
#include stih416-clock.dtsi
#include stih416-pinctrl.dtsi
-#include dt-bindings/phy/phy-miphy365x.h
+#include dt-bindings/phy/phy.h
#include dt-bindings/interrupt-controller/arm-gic.h
#include dt-bindings/reset-controller/stih416-resets.h
/ {
@@ -306,7 +306,7 @@
reg = 0xfe38 0x1000;
interrupts = GIC_SPI 157 IRQ_TYPE_NONE;
interrupt-names = hostc;
- phys= phy_port0 MIPHY_TYPE_SATA;
+ phys= phy_port0 PHY_TYPE_SATA;
phy-names = sata-phy;
resets = powerdown
STIH416_SATA0_POWERDOWN,
softreset
STIH416_SATA0_SOFTRESET;
diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
index 6c80154..98bffbc 100644
--- a/drivers/phy/phy-miphy365x.c
+++ b/drivers/phy/phy-miphy365x.c
@@ -25,7 +25,7 @@
#include linux/mfd/syscon.h
#include linux/regmap.h
-#include dt-bindings/phy/phy-miphy365x.h
+#include dt-bindings/phy/phy.h
#define HFC_TIMEOUT100
@@ -176,7 +176,7 @@ static u8 rx_tx_spd[] = {
static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
struct miphy365x_dev *miphy_dev)
{
- bool sata = (miphy_phy-type == MIPHY_TYPE_SATA);
+ bool sata = (miphy_phy-type == PHY_TYPE_SATA);
return regmap_update_bits(miphy_dev-regmap,
miphy_phy-ctrlreg,
@@ -430,7 +430,7 @@ static int miphy365x_init(struct phy *phy)
}
/* Initialise Miphy for PCIe or SATA */
- if (miphy_phy-type == MIPHY_TYPE_PCIE)
+ if (miphy_phy-type == PHY_TYPE_PCIE)
ret = miphy365x_init_pcie_port(miphy_phy, miphy_dev);
else
ret = miphy365x_init_sata_port(miphy_phy, miphy_dev);
@@ -454,8 +454,8 @@ int miphy365x_get_addr(struct device *dev, struct
miphy365x_phy *miphy_phy,
return ret;
}
- if (!((!strncmp(name, sata, 4) type == MIPHY_TYPE_SATA) ||
- (!strncmp(name, pcie, 4) type == MIPHY_TYPE_PCIE)))
+ if (!((!strncmp(name, sata, 4) type == PHY_TYPE_SATA) ||
+ (!strncmp(name, pcie, 4) type == PHY_TYPE_PCIE)))
return 0;
miphy_phy-base = of_iomap(phynode, index);
@@ -498,8 +498,8 @@ static struct phy *miphy365x_xlate(struct device *dev,
miphy_phy-type = args-args[0];
- if (!(miphy_phy-type == MIPHY_TYPE_SATA ||
-
Re: stand-alone kvmtool
On Mon, Feb 23, 2015 at 05:23:58PM +, Pekka Enberg wrote: Hi, Hi Pekka, Sorry for the delay, I've been away from email for a few days. On 2/18/15 5:50 PM, Will Deacon wrote: Thanks for doing this. Since it looks unlikely that kvmtool will ever be merged back into the kernel tree, it makes sense to cut the dependency in my opinion. I am certainly OK with a standalone repository which preserves the history. Will, would you like to take over the proposed new repository and put it somewhere on git.kernel.org, perhaps? Sure thing. I'll sync-up with Andre and reply back here when we've got something sensible. One extra point that I don't think has been mentioned in this thread so far is that separating kvmtool from the kernel sources is likely a prerequisite for distribution packaging. Once we've got something sorted out, I'll poke some friendly local debian developers and see if they can't package it up for us. Will -- 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] x86: Move msr accesses out of line
On Mon, Feb 23, 2015 at 09:43:40AM -0800, Andi Kleen wrote:
On Mon, Feb 23, 2015 at 06:04:36PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 05:38:55PM -0800, Andi Kleen wrote:
This patch moves the MSR functions out of line. A MSR access is typically
40-100 cycles or even slower, a call is a few cycles at best, so the
additional function call is not really significant.
If I look at the below PDF a CALL+PUSH EBP+MOV RSP,RBP+ ... +POP+RET
ends up being 5+1.5+0.5+ .. + 1.5+8 = 16.5 + .. cycles.
You cannot just add up the latency cycles. The CPU runs all of this
in parallel.
Latency cycles would only be interesting if these instructions were
on the critical path for computing the result, which they are not.
It should be a few cycles overhead.
I thought that since CALL touches RSP, PUSH touches RSP, MOV RSP,
(obviously) touches RSP, POP touches RSP and well, RET does too. There
were strong dependencies on the instructions and there would be little
room to parallelize things.
I'm glad you so patiently educated me on the wonders of modern
architectures and how it can indeed do all this in parallel.
Still, I wondered, so I ran me a little test. Note that I used a
serializing instruction (LOCK XCHG) because WRMSR is too.
I see a ~14 cycle difference between the inline and noinline version.
If I substitute the LOCK XCHG with XADD, I get to 1,5 cycles in
difference, so clearly there is some magic happening, but serializing
instructions wreck it.
Anybody can explain how such RSP deps get magiced away?
---
root@ivb-ep:~# cat call.c
#define __always_inline inline __attribute__((always_inline))
#define noinline __attribute__((noinline))
static int
#ifdef FOO
noinline
#else
__always_inline
#endif
xchg(int *ptr, int val)
{
asm volatile (LOCK xchgl %0, %1\n
: +r (val), +m (*(ptr))
: : memory, cc);
return val;
}
void main(void)
{
int val = 0, old;
for (int i = 0; i 10; i++)
old = xchg(val, i);
}
root@ivb-ep:~# gcc -std=gnu99 -O3 -fno-omit-frame-pointer -DFOO -o call call.c
root@ivb-ep:~# objdump -D call | awk '/[^]*:/ {p=0} /main:/ {p=1}
/xchg:/ {p=1} { if (p) print $0 }'
004003e0 main:
4003e0: 55 push %rbp
4003e1: 48 89 e5mov%rsp,%rbp
4003e4: 53 push %rbx
4003e5: 31 db xor%ebx,%ebx
4003e7: 48 83 ec 18 sub$0x18,%rsp
4003eb: c7 45 e0 00 00 00 00movl $0x0,-0x20(%rbp)
4003f2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
4003f8: 48 8d 7d e0 lea-0x20(%rbp),%rdi
4003fc: 89 de mov%ebx,%esi
4003fe: 83 c3 01add$0x1,%ebx
400401: e8 fa 00 00 00 callq 400500 xchg
400406: 81 fb 00 ca 9a 3b cmp$0x3b9aca00,%ebx
40040c: 75 ea jne4003f8 main+0x18
40040e: 48 83 c4 18 add$0x18,%rsp
400412: 5b pop%rbx
400413: 5d pop%rbp
400414: c3 retq
00400500 xchg:
400500: 55 push %rbp
400501: 89 f0 mov%esi,%eax
400503: 48 89 e5mov%rsp,%rbp
400506: f0 87 07lock xchg %eax,(%rdi)
400509: 5d pop%rbp
40050a: c3 retq
40050b: 90 nop
40050c: 90 nop
40050d: 90 nop
40050e: 90 nop
40050f: 90 nop
root@ivb-ep:~# gcc -std=gnu99 -O3 -fno-omit-frame-pointer -o call-inline call.c
root@ivb-ep:~# objdump -D call-inline | awk '/[^]*:/ {p=0} /main:/ {p=1}
/xchg:/ {p=1} { if (p) print $0 }'
004003e0 main:
4003e0: 55 push %rbp
4003e1: 31 c0 xor%eax,%eax
4003e3: 48 89 e5mov%rsp,%rbp
4003e6: c7 45 f0 00 00 00 00movl $0x0,-0x10(%rbp)
4003ed: 0f 1f 00nopl (%rax)
4003f0: 89 c2 mov%eax,%edx
4003f2: f0 87 55 f0 lock xchg %edx,-0x10(%rbp)
4003f6: 83 c0 01add$0x1,%eax
4003f9: 3d 00 ca 9a 3b cmp$0x3b9aca00,%eax
4003fe: 75 f0 jne4003f0 main+0x10
400400: 5d pop%rbp
400401: c3 retq
root@ivb-ep:~# perf stat -e cycles:u ./call
Performance counter stats for './call':
36,309,274,162 cycles:u
10.561819310 seconds time elapsed
root@ivb-ep:~# perf stat -e cycles:u ./call-inline
Re: [PATCH v4 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function
Hi Eduardo,
On Wed, Feb 18, 2015 at 11:07:29AM +0100, Lukasz Majewski wrote:
Odroid U3 fan can work without being registered as OF cooling device
(with CONFIG_THERMAL_OF disabled).
In this situation it can be controlled via PWM entry at
/sys/class/hwmon/hwmon0/pwm1.
Therefore, the thermal_of_cooling_device_register() function needs
a stub to allow clean compilation.
I've just applied a patch on this same matter from Nishanth Menon [1].
Can you please check if his patch is enough for you?
[1] -
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=fixesid=12ca7188468ee29c4e717f73db4bf43c90954fc7
I will prepare new PWM-FAN patch set with above changes in mind.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- None
Changes for v3:
- Provide stub declaration when CONFIG_THERMAL is not set
Changes for v4:
- None
---
include/linux/thermal.h | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index fc52e30..eacf2de 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -293,6 +293,20 @@ struct thermal_trip {
};
/* Function declarations */
+#ifdef CONFIG_THERMAL
+struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+ char *type, void *devdata,
+ const struct
thermal_cooling_device_ops *); +#else
+static inline struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+ char *type, void *devdata,
+ const struct
thermal_cooling_device_ops *ops) +{
+ return NULL;
+}
+#endif
#ifdef CONFIG_THERMAL_OF
struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id, void
*data, @@ -328,9 +342,6 @@ void thermal_zone_device_update(struct
thermal_zone_device *);
struct thermal_cooling_device
*thermal_cooling_device_register(char *, void *, const struct
thermal_cooling_device_ops *); -struct thermal_cooling_device *
-thermal_of_cooling_device_register(struct device_node *np, char *,
void *,
- const struct
thermal_cooling_device_ops *); void
thermal_cooling_device_unregister(struct thermal_cooling_device *);
struct thermal_zone_device *thermal_zone_get_zone_by_name(const
char *name); int thermal_zone_get_temp(struct thermal_zone_device
*tz, unsigned long *temp); -- 2.0.0.rc2
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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 0/6] the big khugepaged redesign
On 02/24/2015 12:24 PM, Andrea Arcangeli wrote: Hi everyone, Hi, On Tue, Feb 24, 2015 at 11:32:30AM +0100, Vlastimil Babka wrote: I would suspect mmap_sem being held during whole THP page fault (including the needed reclaim and compaction), which I forgot to mention in the first e-mail - it's not just the problem page fault latency, but also potentially holding back other processes, why we should allow shifting from THP page faults to deferred collapsing. Although the attempts for opportunistic page faults without mmap_sem would also help in this particular case. Khugepaged also used to hold mmap_sem (for read) during the allocation attempt, but that was fixed since then. It could be also zone lru_lock pressure. I'm traveling and I didn't have much time to read the code yet but if I understood well the proposal, I've some doubt boosting khugepaged CPU utilization is going to provide a better universal trade off. I think the low overhead background scan is safer default. Making the background scanning more efficient should be win in any case. If we want to do more async background work and less synchronous work at fault time, what may be more interesting is to generate transparent hugepages in the background and possibly not to invoke compaction (or much compaction) in the page faults. Steps in that direction are in fact part of the patchset :) I'd rather move compaction to a background kernel thread, and to invoke compaction synchronously only in khugepaged. I like it more if nothing else because it is a kind of background load that can come to a full stop, once enough THP have been created. Yes, we agree here. Unlike khugepaged that can never stop to scan and it better be lightweight kind of background load, as it'd be running all the time. IMHO it doesn't hurt if the scanning can focus on mm's where it's more likely to succeed, and tune its activity according to how successful it is. Then you don't need to achieve the lightweightness by setting the existing tunables to very long sleeps and very short scans, which increases the delay until the good collapse candidates are actually found by khugepaged. Creating THP through khugepaged is much more expensive than creating them on page faults. khugepaged will need to halt the userland access on the range once more and it'll have to copy the 2MB. Well, Mel also suggested another thing that I didn't mention yet - in-place collapsing, where the base pages would be allocated on page faults with such layout to allow later collapse without the copying. I think that Kiryl's refcounting changes could potentially allow this by allocating a hugepage, but mapping it using pte's so it could still be tracked which pages are actually accessed, and from which nodes. If after some time it looks like a good candidate, just switch it to pmd, otherwise break the hugepage and free the unused base pages. Overall I agree with Andi we need more data collected for various workloads before embarking into big changes, at least so we can proof the changes to be beneficial to those workloads. OK. I mainly wanted to stir some discussion at this point. I would advise not to make changes for app that are already the biggest users ever of hugetlbfs (like Oracle). Those already are optimized by other means. THP target are apps that have several benefit in not ever using hugetlbfs, so apps that are more dynamic workloads that don't fit well with NUMA hard pinning with numactl or other static placements of memory and CPU. There are also other corner cases to optimize, that have nothing to do with khugepaged nor compaction: for example redis has issues in the way it forks() and then uses the child memory as a snapshot while the parent keeps running and writing to the memory. If THP is enabled, the parent that writes to the memory will allocate and copy 2MB objects instead of 4k objects. That means more memory utilization but especially the problem are those copy_user of 2MB instead of 4k hurting the parent runtime. For redis we need a more finegrined thing than MADV_NOHUGEPAGE. It needs a MADV_COW_NOHUGEPAGE (please think at a better name) that will only prevent THP creation during COW faults but still maximize THP utilization for every other case. Once such a madvise will become available, redis will run faster with THP enabled (currently redis recommends THP disabled because of the higher latencies in the 2MB COW faults while the child process is snapshotting). When the snapshot is finished and the child quits, khugepaged will recreate THP for those fragmented cows. Hm sounds like Kiryl's patchset could also help here? In parent, split only the pmd and do cow on 4k pages, while child keeps the whole THP. Later khugepaged can recreate THP for the parent, as you say. That should be better default behavior than the current 2MB copies, not just for redis? And no new madvise needed. Or maybe with MADV_HUGEPAGE you can assume that the caller
Re: [PATCH v3 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c
On 2015年02月25日 08:36, al.st...@linaro.org wrote: From: Al Stone al.st...@linaro.org In preparation for later splitting out some of the arch-dependent code from osl.c, clean up the errors reported by checkpatch.pl. They fell into these classes: -- remove the FSF address from the GPL notice -- foo * bar should be foo *bar (and the ** variation of same) -- a return is not a function, so parentheses are not required. Signed-off-by: Al Stone al.st...@linaro.org Reviewd-by: Hanjun Guo hanjun@linaro.org Thanks Hanjun -- 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 -next 01/13] serial: earlycon: Refactor parse_options into serial core
Hi Joe,
checkpatch warns on the line below:
On 02/24/2015 11:36 AM, Peter Hurley wrote:
Prepare to support console-defined matching; refactor the command
line parameter string processing from parse_options() into a
new core function, uart_parse_earlycon(), which decodes command line
parameters of the form:
earlycon=name,io|mmio|mmio32,addr,options
console=name,io|mmio|mmio32,addr,options
earlycon=name,0xaddr,options
console=name,0xaddr,options
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/serial/earlycon.c| 39 --
drivers/tty/serial/serial_core.c | 46
include/linux/serial_core.h | 2 ++
3 files changed, 61 insertions(+), 26 deletions(-)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 64fe25a..58d6bcd 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -54,44 +54,31 @@ static void __iomem * __init earlycon_map(unsigned long
paddr, size_t size)
return base;
}
-static int __init parse_options(struct earlycon_device *device,
- char *options)
+static int __init parse_options(struct earlycon_device *device, char
*options)
{
struct uart_port *port = device-port;
- int mmio, mmio32, length;
+ int length;
unsigned long addr;
- if (!options)
- return -ENODEV;
+ if (uart_parse_earlycon(options, port-iotype, addr, options))
+ return -EINVAL;
- mmio = !strncmp(options, mmio,, 5);
- mmio32 = !strncmp(options, mmio32,, 7);
- if (mmio || mmio32) {
- port-iotype = (mmio ? UPIO_MEM : UPIO_MEM32);
- options += mmio ? 5 : 7;
- addr = simple_strtoul(options, NULL, 0);
+ switch (port-iotype) {
+ case UPIO_MEM32:
+ port-regshift = 2; /* fall-through */
+ case UPIO_MEM:
port-mapbase = addr;
- if (mmio32)
- port-regshift = 2;
- } else if (!strncmp(options, io,, 3)) {
- port-iotype = UPIO_PORT;
- options += 3;
- addr = simple_strtoul(options, NULL, 0);
+ break;
+ case UPIO_PORT:
port-iobase = addr;
- mmio = 0;
- } else if (!strncmp(options, 0x, 2)) {
- port-iotype = UPIO_MEM;
- addr = simple_strtoul(options, NULL, 0);
- port-mapbase = addr;
- } else {
+ break;
+ default:
return -EINVAL;
}
port-uartclk = BASE_BAUD * 16;
- options = strchr(options, ',');
if (options) {
- options++;
device-baud = simple_strtoul(options, NULL, 0);
length = min(strcspn(options, ) + 1,
(size_t)(sizeof(device-options)));
@@ -100,7 +87,7 @@ static int __init parse_options(struct earlycon_device
*device,
if (port-iotype == UPIO_MEM || port-iotype == UPIO_MEM32)
pr_info(Early serial console at MMIO%s 0x%llx (options
'%s')\n,
- mmio32 ? 32 : ,
+ (port-iotype == UPIO_MEM32) ? 32 : ,
(unsigned long long)port-mapbase,
device-options);
else
diff --git a/drivers/tty/serial/serial_core.c
b/drivers/tty/serial/serial_core.c
index 6a1055a..3f823c26 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1810,6 +1810,52 @@ uart_get_console(struct uart_port *ports, int nr,
struct console *co)
}
/**
+ * uart_parse_earlycon - Parse earlycon options
+ * @p: ptr to 2nd field (ie., just beyond 'name,')
+ * @iotype: ptr for decoded iotype (out)
+ * @addr:ptr for decoded mapbase/iobase (out)
+ * @options: ptr for options field; NULL if not present (out)
+ *
+ * Decodes earlycon kernel command line parameters of the form
+ * earlycon=name,io|mmio|mmio32,addr,options
+ * console=name,io|mmio|mmio32,addr,options
+ *
+ * The optional form
+ * earlycon=name,0xaddr,options
+ * console=name,0xaddr,options
+ * is also accepted; the returned @iotype will be UPIO_MEM.
+ *
+ * Returns 0 on success or -EINVAL on failure
+ */
+int uart_parse_earlycon(char *p, unsigned char *iotype, unsigned long *addr,
+ char **options)
+{
+ if (strncmp(p, mmio,, 5) == 0) {
+ *iotype = UPIO_MEM;
+ p += 5;
+ } else if (strncmp(p, mmio32,, 7) == 0) {
+ *iotype = UPIO_MEM32;
+ p += 7;
+ } else if (strncmp(p, io,, 3) == 0) {
+ *iotype = UPIO_PORT;
+ p += 3;
+ } else if (strncmp(p, 0x, 2) == 0) {
+ *iotype = UPIO_MEM;
+ } else {
+ return -EINVAL;
+ }
+
+ *addr = simple_strtoul(p, NULL, 0);
[PATCH v2] mfd: arizona: Move useful defines into a dt-binding include
Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in
the dt-binding directory for use by device tree bindings. This also
makes gpio.h redundant so remove it in the process.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
Acked-by: Mark Brown broo...@kernel.org
---
Changes since v1:
- Removed some defines that will never be used in DT from the
dt-binding include
- Added some convience defines for the most common pin configs
(input/output/default)
- Updated the binding documentation to use the new defines to
give some context to their usage
Thanks,
Charles
Documentation/devicetree/bindings/mfd/arizona.txt | 20 ++--
include/dt-bindings/mfd/arizona.h | 93
include/linux/mfd/arizona/gpio.h | 96 -
include/linux/mfd/arizona/pdata.h | 22 +-
sound/soc/codecs/arizona.c|1 -
5 files changed, 105 insertions(+), 127 deletions(-)
create mode 100644 include/dt-bindings/mfd/arizona.h
delete mode 100644 include/linux/mfd/arizona/gpio.h
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 7bd1273..bfef000 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -36,11 +36,11 @@ Optional properties:
- wlf,reset : GPIO specifier for the GPIO controlling /RESET
- wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
- - wlf,gpio-defaults : A list of GPIO configuration register values. If
-absent, no configuration of these registers is performed. If any
-entry has a value that is out of range for a 16 bit register then
-the chip default will be used. If present exactly five values must
-be specified.
+ - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
+for the appropriate values can found in dt-bindings/mfd/arizona.txt. If
+absent, no configuration of these registers is performed. If any entry has
+a value that is out of range for a 16 bit register then the chip default
+will be used. If present exactly five values must be specified.
- wlf,inmode : A list of INn_MODE register values, where n is the number
of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
@@ -73,10 +73,10 @@ codec: wm5102@1a {
#gpio-cells = 2;
wlf,gpio-defaults =
- 0x /* AIF1TXLRCLK */
- 0x
- 0x
- 0x
- 0x
+ ARIZONA_GP_FN_TXLRCLK
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
;
};
diff --git a/include/dt-bindings/mfd/arizona.h
b/include/dt-bindings/mfd/arizona.h
new file mode 100644
index 000..c7af7c7
--- /dev/null
+++ b/include/dt-bindings/mfd/arizona.h
@@ -0,0 +1,93 @@
+/*
+ * Device Tree defines for Arizona devices
+ *
+ * Copyright 2015 Cirrus Logic Inc.
+ *
+ * Author: Charles Keepax ckee...@opensource.wolfsonmicro.com
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_MFD_ARIZONA_H
+#define _DT_BINDINGS_MFD_ARIZONA_H
+
+/* GPIO Function Definitions */
+#define ARIZONA_GP_FN_TXLRCLK0x00
+#define ARIZONA_GP_FN_GPIO 0x01
+#define ARIZONA_GP_FN_IRQ1 0x02
+#define ARIZONA_GP_FN_IRQ2 0x03
+#define ARIZONA_GP_FN_OPCLK 0x04
+#define ARIZONA_GP_FN_FLL1_OUT 0x05
+#define ARIZONA_GP_FN_FLL2_OUT 0x06
+#define ARIZONA_GP_FN_PWM1 0x08
+#define ARIZONA_GP_FN_PWM2 0x09
+#define ARIZONA_GP_FN_SYSCLK_UNDERCLOCKED0x0A
+#define ARIZONA_GP_FN_ASYNCCLK_UNDERCLOCKED 0x0B
+#define ARIZONA_GP_FN_FLL1_LOCK 0x0C
+#define ARIZONA_GP_FN_FLL2_LOCK 0x0D
+#define ARIZONA_GP_FN_FLL1_CLOCK_OK 0x0F
+#define ARIZONA_GP_FN_FLL2_CLOCK_OK 0x10
+#define ARIZONA_GP_FN_HEADPHONE_DET 0x12
+#define ARIZONA_GP_FN_MIC_DET0x13
+#define ARIZONA_GP_FN_WSEQ_STATUS0x15
+#define ARIZONA_GP_FN_CIF_ADDRESS_ERROR 0x16
+#define ARIZONA_GP_FN_ASRC1_LOCK 0x1A
+#define ARIZONA_GP_FN_ASRC2_LOCK 0x1B
+#define ARIZONA_GP_FN_ASRC_CONFIG_ERROR 0x1C
+#define ARIZONA_GP_FN_DRC1_SIGNAL_DETECT 0x1D
+#define ARIZONA_GP_FN_DRC1_ANTICLIP 0x1E
+#define ARIZONA_GP_FN_DRC1_DECAY 0x1F
+#define ARIZONA_GP_FN_DRC1_NOISE 0x20
+#define ARIZONA_GP_FN_DRC1_QUICK_RELEASE 0x21
+#define
Re: [PATCH] kconfig: fix a misspelling in scripts/kconfig/merge_config.sh
On 2014-12-03 07:55, Masahiro Yamada wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- scripts/kconfig/merge_config.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to kbuild.git#kconfig, sorry for the delay. Michal -- 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] mm, oom: do not fail __GFP_NOFAIL allocation if oom killer is disbaled
On Tue 24-02-15 12:23:55, David Rientjes wrote: On Tue, 24 Feb 2015, Johannes Weiner wrote: [...] I'm fine with keeping the allocation looping, but is that message helpful? It seems completely useless to the user encountering it. Is it going to help kernel developers when we get a bug report with it? WARN_ON_ONCE()? Yeah, I'm not sure that the warning is helpful (and it needs s/disbaled/disabled/ if it is to be kept). I also think this check should be moved out of out_of_memory() since gfp/retry logic should be in the page allocator itself and not in the oom killer: just make __alloc_pages_may_oom() also set *did_some_progress = 1 for __GFP_NOFAIL. OK, this is a good point. Updated patch is below: --- From 364fdbdaa175daa4b7353f71c2d8f8707b6bda31 Mon Sep 17 00:00:00 2001 From: Michal Hocko mho...@suse.cz Date: Mon, 23 Feb 2015 10:33:30 +0100 Subject: [PATCH] mm, oom: do not fail __GFP_NOFAIL allocation if oom killer is disbaled Tetsuo Handa has pointed out that __GFP_NOFAIL allocations might fail after OOM killer is disabled if the allocation is performed by a kernel thread. This behavior was introduced from the very beginning by 7f33d49a2ed5 (mm, PM/Freezer: Disable OOM killer when tasks are frozen). This means that the basic contract for the allocation request is broken and the context requesting such an allocation might blow up unexpectedly. There are basically two ways forward. 1) move oom_killer_disable after kernel threads are frozen. This has a risk that the OOM victim wouldn't be able to finish because it would depend on an already frozen kernel thread. This would be really tricky to debug. 2) do not fail GFP_NOFAIL allocation no matter what and risk a potential Freezable kernel threads will loop and fail the suspend. Incidental allocations after kernel threads are frozen will at least dump a warning - if we are lucky and the serial console is still active of course... This patch implements the later option because it is safer. We would see warning rather than allocation failures for the kernel threads which would blow up otherwise and have a higher chances to identify __GFP_NOFAIL users from deeper pm code. Changes since v1 - move the __GFP_NOFAIL check to __alloc_pages_may_oom per David Rientjes - replace WARN by WARN_ON_ONCE as per Johannes Weiner Signed-off-by: Michal Hocko mho...@suse.cz --- mm/page_alloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 2d224bbdf8e8..c2ff40a30003 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2363,7 +2363,8 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, goto out; } /* Exhausted what can be done so it's blamo time */ - if (out_of_memory(ac-zonelist, gfp_mask, order, ac-nodemask, false)) + if (out_of_memory(ac-zonelist, gfp_mask, order, ac-nodemask, false) + || WARN_ON_ONCE(gfp_mask __GFP_NOFAIL)) *did_some_progress = 1; out: oom_zonelist_unlock(ac-zonelist, gfp_mask); -- 2.1.4 -- Michal Hocko SUSE Labs -- 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/7] New Lenovos 2015 touchpads: party time!
On Mon, Feb 16, 2015 at 10:23 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Fri, Feb 6, 2015 at 3:04 PM, Benjamin Tissoires benjamin.tissoi...@redhat.com wrote: Hi, This is the second episode of the Lenovo 2015 party :) Thanks to Andrew, we now have an idea within the driver of what are the extra buttons aimed for, and the patch series looks cleaner. Many thanks for your help. I marked only patches 1/7, 2/7 and 3/7 as stable because they are really stable fixes. Without the rest of the series, user-space can cope with the kernel result, and so there is IMO no need to backport too many patches in stable. I bet distributions will cherry-pick the rest of the series however. Guys, any chances we consider this for 3.20 (or whatever it will be numbered)? I'd really like to see this accepted upstream in one way or one other so we will prevent the mess we had to deal with last year. Hans, Dmitry, well, it's been 3 weeks since I received the loaner I have to support these touchpads. I will have to return it next week or the week after at most. That means that I will not be able to conduct more tests at that point. Can I ask you to please review the series? Sorry for pushing, but I am running out of time and I'd like to be able to include the fixes in RHEL/Fedora too. Cheers, Benjamin Benjamin Tissoires (7): Input: synaptics - fix middle button on Lenovo 2015 products Input: synaptics - handle spurious release of trackstick buttons Input: synaptics - do not retrieve the board id on old firmwares Input: synaptics - retrieve the extended capabilities in query $10 Input: synaptics - remove TOPBUTTONPAD property for Lenovos 2015 Input: synaptics - re-route tracksticks buttons on the Lenovo 2015 series Input: synaptics - Remove X1 Carbon 3rd gen from the topbuttonpad list drivers/input/mouse/synaptics.c | 129 +--- drivers/input/mouse/synaptics.h | 28 + 2 files changed, 122 insertions(+), 35 deletions(-) -- 2.1.0 -- 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/ -- 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] virtio-balloon: do not call blocking ops when !TASK_RUNNING
virtio balloon has this code:
wait_event_interruptible(vb-config_change,
(diff = towards_target(vb)) != 0
|| vb-need_stats_update
|| kthread_should_stop()
|| freezing(current));
Which is a problem because towards_target() call might block after
wait_event_interruptible sets task state to TAST_INTERRUPTIBLE, causing
the task_struct::state collision typical of nesting of sleeping
primitives
See also http://lwn.net/Articles/628628/ or Thomas's
bug report
http://article.gmane.org/gmane.linux.kernel.virtualization/24846
for a fuller explanation.
To fix, rewrite using wait_woken.
Cc: sta...@vger.kernel.org
Reported-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
changes from v1:
remove wait_event_interruptible
noticed by Cornelia Huck cornelia.h...@de.ibm.com
drivers/virtio/virtio_balloon.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 0413157..5a6ad6d 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -29,6 +29,7 @@
#include linux/module.h
#include linux/balloon_compaction.h
#include linux/oom.h
+#include linux/wait.h
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -334,17 +335,25 @@ static int virtballoon_oom_notify(struct notifier_block
*self,
static int balloon(void *_vballoon)
{
struct virtio_balloon *vb = _vballoon;
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
set_freezable();
while (!kthread_should_stop()) {
s64 diff;
try_to_freeze();
- wait_event_interruptible(vb-config_change,
-(diff = towards_target(vb)) != 0
-|| vb-need_stats_update
-|| kthread_should_stop()
-|| freezing(current));
+
+ add_wait_queue(vb-config_change, wait);
+ for (;;) {
+ if ((diff = towards_target(vb)) != 0 ||
+ vb-need_stats_update ||
+ kthread_should_stop() ||
+ freezing(current))
+ break;
+ wait_woken(wait, TASK_INTERRUPTIBLE,
MAX_SCHEDULE_TIMEOUT);
+ }
+ remove_wait_queue(vb-config_change, wait);
+
if (vb-need_stats_update)
stats_handle_request(vb);
if (diff 0)
--
MST
--
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: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
On Wed, Feb 25, 2015 at 12:38:20PM +, Kweh, Hock Leong wrote: The reason we use this interface for efi capsule is that efi capsule support multi binaries to be uploaded and each binary file name can be different. So you can write the file path to a second file and reload then, once per file. Alternatively, you can combine all the files into a cpio archive like we do with the microcode loader too, and let the kernel parse the cpio archive. -- 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 v1] clk: qcom: Add MSM8916 Global Clock Controller support
Hi Georgi,
On 02/24/2015 09:19 PM, Georgi Djakov wrote:
On 02/24/2015 06:49 AM, Archit Taneja wrote:
Hi,
[..]
+
+static struct freq_tbl ftbl_gcc_mdss_pclk[] = {
+{ .src = P_DSI0_PHYPLL_DSI },
+{ }
+};
+
+static struct clk_rcg2 pclk0_clk_src = {
+.cmd_rcgr = 0x4d084,
This should be 0x4d000. Same reason as above.
+.mnd_width = 8,
+.hid_width = 5,
+.parent_map = gcc_xo_gpll0_dsiphy_map,
+.freq_tbl = ftbl_gcc_mdss_pclk,
+.clkr.hw.init = (struct clk_init_data){
+.name = pclk0_clk_src,
+.parent_names = gcc_xo_gpll0_dsiphy,
+.num_parents = 1,
+.ops = clk_rcg2_ops,
+},
+};
+
+static const struct freq_tbl ftbl_gcc_mdss_vsync_clk[] = {
+F(1920, P_XO, 1, 0,0),
+{ }
+};
+
+static struct clk_rcg2 vsync_clk_src = {
+.cmd_rcgr = 0x4d02c,
+.hid_width = 5,
+.parent_map = gcc_xo_gpll0a_map,
+.freq_tbl = ftbl_gcc_mdss_vsync_clk,
+.clkr.hw.init = (struct clk_init_data){
+.name = vsync_clk_src,
+.parent_names = gcc_xo_gpll0a,
+.num_parents = 2,
+.ops = clk_rcg2_ops,
+},
+};
+
I think we can update the clk ops for pclk0_clk_src and byte0_clk_src to
clk_pixel_ops and clk_byte_ops respectively too. The set_rate functions
in these ops have been modified to make it run with DSI PLL.
An Ack by Stephen for this change would be nice, though.
Archit
--
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] arm64: Implement cpu_relax as yield
On Tue, Feb 24, 2015 at 11:07:37PM +, Peter Crosthwaite wrote: ARM64 has the yield nop hint which has the intended semantics of cpu_relax. Implement. The immediate application is ARM CPU emulators. An emulator can take advantage of the yield hint to de-prioritise an emulated CPU in favor of other emulation tasks. QEMU A64 SMP emulation has yield awareness, and sees a significant boot time performance increase with this change. Could you elaborate on the QEMU SMP boot case please? Usually SMP pens for booting make use of wfe/sev to minimise the spinning overhead. Will -- 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] phy: xgene: Remove duplicate code to set ctx-dev
Set it once is enough and it's done after devm_kzalloc(). Signed-off-by: Axel Lin axel@ingics.com --- drivers/phy/phy-xgene.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/phy/phy-xgene.c b/drivers/phy/phy-xgene.c index 29214a3..2263cd0 100644 --- a/drivers/phy/phy-xgene.c +++ b/drivers/phy/phy-xgene.c @@ -1704,7 +1704,6 @@ static int xgene_phy_probe(struct platform_device *pdev) for (i = 0; i MAX_LANE; i++) ctx-sata_param.speed[i] = 2; /* Default to Gen3 */ - ctx-dev = pdev-dev; platform_set_drvdata(pdev, ctx); ctx-phy = devm_phy_create(ctx-dev, NULL, xgene_phy_ops); -- 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 RFC 1/4] mm: throttle MADV_FREE
On Tue 24-02-15 14:54:01, Shaohua Li wrote: On Tue, Feb 24, 2015 at 04:43:18PM +0100, Michal Hocko wrote: On Tue 24-02-15 17:18:14, Minchan Kim wrote: Recently, Shaohua reported that MADV_FREE is much slower than MADV_DONTNEED in his MADV_FREE bomb test. The reason is many of applications went to stall with direct reclaim since kswapd's reclaim speed isn't fast than applications's allocation speed so that it causes lots of stall and lock contention. I am not sure I understand this correctly. So the issue is that there is huge number of MADV_FREE on the LRU and they are not close to the tail of the list so the reclaim has to do a lot of work before it starts dropping them? I thought the main reason is current reclaim stragety. Anonymous pages are considered to be hard to be reclaimed with current policy, VM bias to reclaim file pages (anon pages are in active list first, referenced pte will reactivate anon pages and increase rotate count) Makes sense. We are really biasing to page cache reclaim most of the time. -- Michal Hocko SUSE Labs -- 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] drivers: cpuidle: remove stale irq disabling call in cpuidle_enter_freeze()
On 02/24/2015 06:58 PM, Lorenzo Pieralisi wrote: On return from cpuidle_enter_freeze() irqs are re-enabled by the function caller (ie cpuidle_idle_call) in the idle loop. This patch removes a stale local_irq_disable() call and its stale comment in cpuidle_enter_freeze(), since they disagree and do not serve a useful purpose. Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Daniel Lezcano daniel.lezc...@linaro.org Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- drivers/cpuidle/cpuidle.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c index 4d53458..f47edc6c 100644 --- a/drivers/cpuidle/cpuidle.c +++ b/drivers/cpuidle/cpuidle.c @@ -144,9 +144,6 @@ void cpuidle_enter_freeze(void) cpuidle_enter(drv, dev, index); else arch_cpu_idle(); - - /* Interrupts are enabled again here. */ - local_irq_disable(); } Hmm, I think Rafael added this prevent lockdep to raise a warning. Otherwise, cpuidle_enter or arch_cpu_idle enables the irq again and then when exiting the cpu_idle_call, we enable them again, so leading to a lockdep WARN in trace_hardirqs_on_caller. That said, if we have to do this, it may reveal something is wrong in the code. -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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] checkkconfigsymbols.py: filter reports for tools/
Recent changes to the build system of tools suggest to filter reports for the entire tools directory. Various C preprocessor identifiers are prefixed with CONFIG_ but are NOT defined in Kconfig but in Makefiles in the tools directory. Such identifiers are false positives for most static analysis tools (i.e., scripts/checkkconfigsymbols.py) since the CONFIG_ prefix and the _MODULE suffix is reserved for Kconfig features in CPP and Make syntax. Signed-off-by: Valentin Rothberg valentin.rothb...@lip6.fr --- scripts/checkkconfigsymbols.py | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) mode change 100644 = 100755 scripts/checkkconfigsymbols.py diff --git a/scripts/checkkconfigsymbols.py b/scripts/checkkconfigsymbols.py old mode 100644 new mode 100755 index e9cc689..6445693 --- a/scripts/checkkconfigsymbols.py +++ b/scripts/checkkconfigsymbols.py @@ -2,7 +2,7 @@ Find Kconfig identifiers that are referenced but not defined. -# (c) 2014 Valentin Rothberg valentinrothb...@gmail.com +# (c) 2014-2015 Valentin Rothberg valentin.rothb...@lip6.fr # (c) 2014 Stefan Hengelein stefan.hengel...@fau.de # # Licensed under the terms of the GNU GPL License version 2 @@ -46,8 +46,9 @@ def main(): stdout = stdout[:-1] for gitfile in stdout.rsplit(\n): -if .git in gitfile or ChangeLog in gitfile or \ -.log in gitfile or os.path.isdir(gitfile): +if .git in gitfile or ChangeLog in gitfile or \ +.log in gitfile or os.path.isdir(gitfile) or \ +gitfile.startswith(tools/): continue if REGEX_FILE_KCONFIG.match(gitfile): kconfig_files.append(gitfile) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vhost: cleanup iterator update logic
Recent iterator-related changes in vhost made it
harder to follow the logic fixing up the header.
In fact, the fixup always happens at the same
offset: sizeof(virtio_net_hdr): sometimes the
fixup iterator is updated by copy_to_iter,
sometimes-by iov_iter_advance.
Rearrange code to make this obvious.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index afa06d2..ca70434 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -591,11 +591,6 @@ static void handle_rx(struct vhost_net *net)
* TODO: support TSO.
*/
iov_iter_advance(msg.msg_iter, vhost_hlen);
- } else {
- /* It'll come from socket; we'll need to patch
-* -num_buffers over if VIRTIO_NET_F_MRG_RXBUF
-*/
- iov_iter_advance(fixup, sizeof(hdr));
}
err = sock-ops-recvmsg(NULL, sock, msg,
sock_len, MSG_DONTWAIT | MSG_TRUNC);
@@ -609,11 +604,18 @@ static void handle_rx(struct vhost_net *net)
continue;
}
/* Supply virtio_net_hdr if VHOST_NET_F_VIRTIO_NET_HDR */
- if (unlikely(vhost_hlen)
- copy_to_iter(hdr, sizeof(hdr), fixup) != sizeof(hdr)) {
- vq_err(vq, Unable to write vnet_hdr at addr %p\n,
- vq-iov-iov_base);
- break;
+ if (unlikely(vhost_hlen)) {
+ if (copy_to_iter(hdr, sizeof(hdr),
+fixup) != sizeof(hdr)) {
+ vq_err(vq, Unable to write vnet_hdr
+ at addr %p\n, vq-iov-iov_base);
+ break;
+ }
+ } else {
+ /* Header came from socket; we'll need to patch
+* -num_buffers over if VIRTIO_NET_F_MRG_RXBUF
+*/
+ iov_iter_advance(fixup, sizeof(hdr));
}
/* TODO: Should check and handle checksum. */
--
MST
--
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] vhost: drop hard-coded num_buffers size
The 2 that we use for copy_to_iter comes from sizeof(u16),
it used to be that way before the iov iter update.
Fix it up, making it obvious the size of stack access
is right.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/vhost/net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index ca70434..2bbfc25 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -621,7 +621,8 @@ static void handle_rx(struct vhost_net *net)
num_buffers = cpu_to_vhost16(vq, headcount);
if (likely(mergeable)
- copy_to_iter(num_buffers, 2, fixup) != 2) {
+ copy_to_iter(num_buffers, sizeof num_buffers,
+fixup) != sizeof num_buffers) {
vq_err(vq, Failed num_buffers write);
vhost_discard_vq_desc(vq, headcount);
break;
--
MST
--
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/6] ahci: st: Update the DT example for how to obtain the PHY.
On Wed, Feb 25, 2015 at 7:36 AM, Peter Griffin peter.grif...@linaro.org wrote: The example is wrong in that the phys property should take a phandle to the phy port. Also with the changing over to generic PHY type constants we also update this as well. Signed-off-by: Peter Griffin peter.grif...@linaro.org We seem to have a variety of ways to describe phy's with SATA controllers. Some consistency would have been nice. However, as this is a doc correction: Acked-by: Rob Herring r...@kernel.org --- Documentation/devicetree/bindings/ata/ahci-st.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt b/Documentation/devicetree/bindings/ata/ahci-st.txt index 0574a77..1331202 100644 --- a/Documentation/devicetree/bindings/ata/ahci-st.txt +++ b/Documentation/devicetree/bindings/ata/ahci-st.txt @@ -11,7 +11,7 @@ Required properties: - reset-names: Associated names must be; pwr-dwn and sw-rst - clocks : The phandle for the clock - clock-names: Associated name must be; ahci_clk - - phys : The phandle for the PHY device + - phys : The phandle for the PHY port - phy-names : Associated name must be; ahci_phy Example: @@ -21,7 +21,7 @@ Example: reg = 0xfe38 0x1000; interrupts = GIC_SPI 157 IRQ_TYPE_NONE; interrupt-names = hostc; - phys= miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA; + phys= phy_port0 PHY_TYPE_SATA; phy-names = ahci_phy; resets = powerdown STIH416_SATA0_POWERDOWN, softreset STIH416_SATA0_SOFTRESET; -- 1.9.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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] drivers: cpuidle: remove stale irq disabling call in cpuidle_enter_freeze()
On Wed, Feb 25, 2015 at 02:13:23PM +, Daniel Lezcano wrote: On 02/24/2015 06:58 PM, Lorenzo Pieralisi wrote: On return from cpuidle_enter_freeze() irqs are re-enabled by the function caller (ie cpuidle_idle_call) in the idle loop. This patch removes a stale local_irq_disable() call and its stale comment in cpuidle_enter_freeze(), since they disagree and do not serve a useful purpose. Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Daniel Lezcano daniel.lezc...@linaro.org Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- drivers/cpuidle/cpuidle.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c index 4d53458..f47edc6c 100644 --- a/drivers/cpuidle/cpuidle.c +++ b/drivers/cpuidle/cpuidle.c @@ -144,9 +144,6 @@ void cpuidle_enter_freeze(void) cpuidle_enter(drv, dev, index); else arch_cpu_idle(); - - /* Interrupts are enabled again here. */ - local_irq_disable(); } Hmm, I think Rafael added this prevent lockdep to raise a warning. Ok, so the comment is there to say at this point of execution IRQs are enabled, it does not refer to local_irq_disable() call effects, that's misleading and not necessarily nice, at least it should be explained. Otherwise, cpuidle_enter or arch_cpu_idle enables the irq again and then when exiting the cpu_idle_call, we enable them again, so leading to a lockdep WARN in trace_hardirqs_on_caller. Would not it be better to enable irqs in cpuidle_enter_freeze() on returning from enter_freeze_proper() and remove the local_irq_enable() call in the cpuidle_idle_call() before jumping to exit_idle ? That said, if we have to do this, it may reveal something is wrong in the code. I just spotted code through inspection, I have to say at the moment it is not very clear what it is meant to achieve, so I put together this patch. Lorenzo -- 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] i2c: i2c-bcm2835: match return type of wait_for_completion_timeout
On Sun, 08 Feb 2015, Nicholas Mc Guire wrote:
return type of wait_for_completion_timeout is unsigned long not int. as
time_left is used for wait_for_completion_timeout exclusively here its
type is simply changed to unsigned long.
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---
Patch was only compile tested with
Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)
drivers/i2c/busses/i2c-bcm2835.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/i2c/busses/i2c-bcm2835.c
b/drivers/i2c/busses/i2c-bcm2835.c
index 5d6feb9..c9336a3 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -147,7 +147,7 @@ static int bcm2835_i2c_xfer_msg(struct bcm2835_i2c_dev
*i2c_dev,
struct i2c_msg *msg)
{
u32 c;
- int time_left;
+ unsigned long time_left;
i2c_dev-msg_buf = msg-buf;
i2c_dev-msg_buf_remaining = msg-len;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 3/4] mm: move lazy free pages to inactive list
On Wed 25-02-15 09:27:28, Minchan Kim wrote: On Tue, Feb 24, 2015 at 05:14:08PM +0100, Michal Hocko wrote: On Tue 24-02-15 17:18:16, Minchan Kim wrote: MADV_FREE is hint that it's okay to discard pages if memory is pressure and we uses reclaimers(ie, kswapd and direct reclaim) s@if memory is pressure@if there is memory pressure@ to free them so there is no worth to remain them in active anonymous LRU list so this patch moves them to inactive LRU list. Makes sense to me. A arguable issue for the approach is whether we should put it head or tail in inactive list Is it really arguable? Why should active MADV_FREE pages appear before those which were living on the inactive list. This doesn't make any sense to me. It would be better to drop garbage pages(ie, freed from allocator) rather than swap out and now anon LRU aging is seq model so inacitve list can include a lot working set so putting hinted pages into tail of LRU could enhance reclaim efficiency. That's why I said it might be arguble. OK, maybe I misunderstood what you tried to tell. Sure we can discuss whether to put all MADV_FREE pages to the tail of inactive list. But the above wording suggested that _active_ MADV_FREE pages were discussed and treating them differently from the inactive pages simply didn't make sense to me. [...] -- Michal Hocko SUSE Labs -- 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] mfd: arizona: Move useful defines into a dt-binding include
On Wed, 25 Feb 2015, Charles Keepax wrote:
Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in
the dt-binding directory for use by device tree bindings. This also
makes gpio.h redundant so remove it in the process.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
Acked-by: Mark Brown broo...@kernel.org
---
Changes since v1:
- Removed some defines that will never be used in DT from the
dt-binding include
- Added some convience defines for the most common pin configs
(input/output/default)
- Updated the binding documentation to use the new defines to
give some context to their usage
Thanks,
Charles
Documentation/devicetree/bindings/mfd/arizona.txt | 20 ++--
include/dt-bindings/mfd/arizona.h | 93
include/linux/mfd/arizona/gpio.h | 96
-
The patch looks good, but can you use `git format-patch -M`, so we can
easily see what the differences are between these two files please?
include/linux/mfd/arizona/pdata.h | 22 +-
sound/soc/codecs/arizona.c|1 -
5 files changed, 105 insertions(+), 127 deletions(-)
create mode 100644 include/dt-bindings/mfd/arizona.h
delete mode 100644 include/linux/mfd/arizona/gpio.h
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 7bd1273..bfef000 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -36,11 +36,11 @@ Optional properties:
- wlf,reset : GPIO specifier for the GPIO controlling /RESET
- wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
- - wlf,gpio-defaults : A list of GPIO configuration register values. If
-absent, no configuration of these registers is performed. If any
-entry has a value that is out of range for a 16 bit register then
-the chip default will be used. If present exactly five values must
-be specified.
+ - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
+for the appropriate values can found in dt-bindings/mfd/arizona.txt. If
+absent, no configuration of these registers is performed. If any entry
has
+a value that is out of range for a 16 bit register then the chip default
+will be used. If present exactly five values must be specified.
- wlf,inmode : A list of INn_MODE register values, where n is the number
of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
@@ -73,10 +73,10 @@ codec: wm5102@1a {
#gpio-cells = 2;
wlf,gpio-defaults =
- 0x /* AIF1TXLRCLK */
- 0x
- 0x
- 0x
- 0x
+ ARIZONA_GP_FN_TXLRCLK
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
+ ARIZONA_GP_DEFAULT
;
};
diff --git a/include/dt-bindings/mfd/arizona.h
b/include/dt-bindings/mfd/arizona.h
new file mode 100644
index 000..c7af7c7
--- /dev/null
+++ b/include/dt-bindings/mfd/arizona.h
@@ -0,0 +1,93 @@
+/*
+ * Device Tree defines for Arizona devices
+ *
+ * Copyright 2015 Cirrus Logic Inc.
+ *
+ * Author: Charles Keepax ckee...@opensource.wolfsonmicro.com
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_MFD_ARIZONA_H
+#define _DT_BINDINGS_MFD_ARIZONA_H
+
+/* GPIO Function Definitions */
+#define ARIZONA_GP_FN_TXLRCLK0x00
+#define ARIZONA_GP_FN_GPIO 0x01
+#define ARIZONA_GP_FN_IRQ1 0x02
+#define ARIZONA_GP_FN_IRQ2 0x03
+#define ARIZONA_GP_FN_OPCLK 0x04
+#define ARIZONA_GP_FN_FLL1_OUT 0x05
+#define ARIZONA_GP_FN_FLL2_OUT 0x06
+#define ARIZONA_GP_FN_PWM1 0x08
+#define ARIZONA_GP_FN_PWM2 0x09
+#define ARIZONA_GP_FN_SYSCLK_UNDERCLOCKED0x0A
+#define ARIZONA_GP_FN_ASYNCCLK_UNDERCLOCKED 0x0B
+#define ARIZONA_GP_FN_FLL1_LOCK 0x0C
+#define ARIZONA_GP_FN_FLL2_LOCK 0x0D
+#define ARIZONA_GP_FN_FLL1_CLOCK_OK 0x0F
+#define ARIZONA_GP_FN_FLL2_CLOCK_OK 0x10
+#define ARIZONA_GP_FN_HEADPHONE_DET 0x12
+#define ARIZONA_GP_FN_MIC_DET0x13
+#define ARIZONA_GP_FN_WSEQ_STATUS0x15
+#define ARIZONA_GP_FN_CIF_ADDRESS_ERROR 0x16
+#define ARIZONA_GP_FN_ASRC1_LOCK 0x1A
+#define ARIZONA_GP_FN_ASRC2_LOCK 0x1B
+#define ARIZONA_GP_FN_ASRC_CONFIG_ERROR 0x1C
+#define
Re: [PATCH v3 8/9] mfd: rtsx: add support for rts525A
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
add support for new chip rts525A.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rts5249.c| 103
+++
drivers/mfd/rtsx_pcr.c | 13 --
drivers/mfd/rtsx_pcr.h | 1 +
include/linux/mfd/rtsx_pci.h | 15 +++
4 files changed, 129 insertions(+), 3 deletions(-)
Applied, thanks.
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 32be803..d1ff32f 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -487,3 +487,106 @@ void rts524a_init_params(struct rtsx_pcr *pcr)
pcr-ops = rts524a_pcr_ops;
}
+static int rts525a_card_power_on(struct rtsx_pcr *pcr, int card)
+{
+ rtsx_pci_write_register(pcr, LDO_VCC_CFG1,
+ LDO_VCC_TUNE_MASK, LDO_VCC_3V3);
+ return rtsx_base_card_power_on(pcr, card);
+}
+
+static int rts525a_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ switch (voltage) {
+ case OUTPUT_3V3:
+ rtsx_pci_write_register(pcr, LDO_CONFIG2,
+ LDO_D3318_MASK, LDO_D3318_33V);
+ rtsx_pci_write_register(pcr, SD_PAD_CTL, SD_IO_USING_1V8, 0);
+ break;
+ case OUTPUT_1V8:
+ rtsx_pci_write_register(pcr, LDO_CONFIG2,
+ LDO_D3318_MASK, LDO_D3318_18V);
+ rtsx_pci_write_register(pcr, SD_PAD_CTL, SD_IO_USING_1V8,
+ SD_IO_USING_1V8);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ rtsx_pci_init_cmd(pcr);
+ rts5249_fill_driving(pcr, voltage);
+ return rtsx_pci_send_cmd(pcr, 100);
+}
+
+static int rts525a_optimize_phy(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ err = rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
+ D3_DELINK_MODE_EN, 0x00);
+ if (err 0)
+ return err;
+
+ rtsx_pci_write_phy_register(pcr, _PHY_FLD0,
+ _PHY_FLD0_CLK_REQ_20C | _PHY_FLD0_RX_IDLE_EN |
+ _PHY_FLD0_BIT_ERR_RSTN | _PHY_FLD0_BER_COUNT |
+ _PHY_FLD0_BER_TIMER | _PHY_FLD0_CHECK_EN);
+
+ rtsx_pci_write_phy_register(pcr, _PHY_ANA03,
+ _PHY_ANA03_TIMER_MAX | _PHY_ANA03_OOBS_DEB_EN |
+ _PHY_CMU_DEBUG_EN);
+
+ if (is_version(pcr, 0x525A, IC_VER_A))
+ rtsx_pci_write_phy_register(pcr, _PHY_REV0,
+ _PHY_REV0_FILTER_OUT | _PHY_REV0_CDR_BYPASS_PFD |
+ _PHY_REV0_CDR_RX_IDLE_BYPASS);
+
+ return 0;
+}
+
+static int rts525a_extra_init_hw(struct rtsx_pcr *pcr)
+{
+ rts5249_extra_init_hw(pcr);
+
+ rtsx_pci_write_register(pcr, PCLK_CTL, PCLK_MODE_SEL, PCLK_MODE_SEL);
+ if (is_version(pcr, 0x525A, IC_VER_A)) {
+ rtsx_pci_write_register(pcr, L1SUB_CONFIG2,
+ L1SUB_AUTO_CFG, L1SUB_AUTO_CFG);
+ rtsx_pci_write_register(pcr, RREF_CFG,
+ RREF_VBGSEL_MASK, RREF_VBGSEL_1V25);
+ rtsx_pci_write_register(pcr, LDO_VIO_CFG,
+ LDO_VIO_TUNE_MASK, LDO_VIO_1V7);
+ rtsx_pci_write_register(pcr, LDO_DV12S_CFG,
+ LDO_D12_TUNE_MASK, LDO_D12_TUNE_DF);
+ rtsx_pci_write_register(pcr, LDO_AV12S_CFG,
+ LDO_AV12S_TUNE_MASK, LDO_AV12S_TUNE_DF);
+ rtsx_pci_write_register(pcr, LDO_VCC_CFG0,
+ LDO_VCC_LMTVTH_MASK, LDO_VCC_LMTVTH_2A);
+ rtsx_pci_write_register(pcr, OOBS_CONFIG,
+ OOBS_AUTOK_DIS | OOBS_VAL_MASK, 0x89);
+ }
+
+ return 0;
+}
+
+static const struct pcr_ops rts525a_pcr_ops = {
+ .fetch_vendor_settings = rtsx_base_fetch_vendor_settings,
+ .extra_init_hw = rts525a_extra_init_hw,
+ .optimize_phy = rts525a_optimize_phy,
+ .turn_on_led = rtsx_base_turn_on_led,
+ .turn_off_led = rtsx_base_turn_off_led,
+ .enable_auto_blink = rtsx_base_enable_auto_blink,
+ .disable_auto_blink = rtsx_base_disable_auto_blink,
+ .card_power_on = rts525a_card_power_on,
+ .card_power_off = rtsx_base_card_power_off,
+ .switch_output_voltage = rts525a_switch_output_voltage,
+ .force_power_down = rtsx_base_force_power_down,
+};
+
+void rts525a_init_params(struct rtsx_pcr *pcr)
+{
+ rts5249_init_params(pcr);
+
+ pcr-reg_pm_ctrl3 = RTS524A_PM_CTRL3;
+ pcr-ops = rts525a_pcr_ops;
+}
+
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index e6d97ad..433cb41 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -59,6 +59,7 @@ static const struct pci_device_id rtsx_pci_ids[] = {
{ PCI_DEVICE(0x10EC, 0x5287), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5286), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x524A), PCI_CLASS_OTHERS 16, 0xFF },
+ {
Re: [PATCH v3 6/9] mfd: rtsx: remove LCTLR defination
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
To enable/disable ASPM we should find LINK CONTROL register
in PCI config space. All old chip use 0x80 address, but new
chip may use another address, so we using pci_find_capability()
to get LINK CONTROL address.
rtsx_gops.c was removed, we consider to put some common operations
to this file, but the actual thing is, only a group of chips
are in common ops1, and another group of chips in common ops2,
it is hard to decide put which ops into generic ops file.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/Makefile | 2 +-
drivers/mfd/rts5227.c| 2 +-
drivers/mfd/rts5249.c| 3 +--
drivers/mfd/rtsx_gops.c | 37 -
drivers/mfd/rtsx_pcr.c | 22 +-
include/linux/mfd/rtsx_pci.h | 10 +-
6 files changed, 21 insertions(+), 55 deletions(-)
delete mode 100644 drivers/mfd/rtsx_gops.c
Applied, thanks.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..2cd7e74 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
obj-$(CONFIG_MFD_CROS_EC_I2C)+= cros_ec_i2c.o
obj-$(CONFIG_MFD_CROS_EC_SPI)+= cros_ec_spi.o
-rtsx_pci-objs:= rtsx_pcr.o rtsx_gops.o rts5209.o
rts5229.o rtl8411.o rts5227.o rts5249.o
+rtsx_pci-objs:= rtsx_pcr.o rts5209.o rts5229.o
rtl8411.o rts5227.o rts5249.o
obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
obj-$(CONFIG_MFD_RTSX_USB) += rtsx_usb.o
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 1f387d4..0c02831 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -130,7 +130,7 @@ static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
{
int err;
- err = rtsx_gops_pm_reset(pcr);
+ err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
if (err 0)
return err;
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 8de8220..3c77058 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -119,7 +119,6 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0xB0);
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0x80);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
return rtsx_pci_send_cmd(pcr, 100);
}
@@ -128,7 +127,7 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
{
int err;
- err = rtsx_gops_pm_reset(pcr);
+ err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
if (err 0)
return err;
diff --git a/drivers/mfd/rtsx_gops.c b/drivers/mfd/rtsx_gops.c
deleted file mode 100644
index b1a98c6..000
--- a/drivers/mfd/rtsx_gops.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/* Driver for Realtek PCI-Express card reader
- *
- * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
- *
- * 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, 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.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, see http://www.gnu.org/licenses/.
- *
- * Author:
- * Micky Ching micky_ch...@realsil.com.cn
- */
-
-#include linux/mfd/rtsx_pci.h
-#include rtsx_pcr.h
-
-int rtsx_gops_pm_reset(struct rtsx_pcr *pcr)
-{
- int err;
-
- /* init aspm */
- rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, 0xFF, 0x00);
- err = rtsx_pci_update_cfg_byte(pcr, LCTLR, ~LCTLR_ASPM_CTL_MASK, 0x00);
- if (err 0)
- return err;
-
- /* reset PM_CTRL3 before send buffer cmd */
- return rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
-}
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 30f7ca8..81b9c2c 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -63,6 +63,18 @@ static const struct pci_device_id rtsx_pci_ids[] = {
MODULE_DEVICE_TABLE(pci, rtsx_pci_ids);
+static inline void rtsx_pci_enable_aspm(struct rtsx_pcr *pcr)
+{
+ rtsx_pci_update_cfg_byte(pcr, pcr-pcie_cap + PCI_EXP_LNKCTL,
+ 0xFC, pcr-aspm_en);
+}
+
+static inline void rtsx_pci_disable_aspm(struct rtsx_pcr *pcr)
+{
+ rtsx_pci_update_cfg_byte(pcr, pcr-pcie_cap +
Re: [PATCH 0/7] New eFuse subsystem
Hi, On Wed, Feb 25, 2015 at 01:12:01PM +, James Hartley wrote: Hi Maxime, -Original Message- From: Ezequiel Garcia Sent: 25 February 2015 12:30 To: Maxime Ripard Cc: Thierry Reding; Stephen Warren; Arnd Bergmann; Andrew Bresticker; James Hartley; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org Subject: Re: [PATCH 0/7] New eFuse subsystem On 02/25/2015 09:02 AM, Maxime Ripard wrote: Hi Ezequiel, On Wed, Feb 25, 2015 at 08:45:12AM -0300, Ezequiel Garcia wrote: This patchset introduces a new driver subsystem, meant to support eFuse (alias OTP, one-time-programmable) devices. The motivation behind this work is to have a common place for drivers that are currently more or less scattered: the tegra efuses are in drivers/soc/ and the sunxi efuses in drivers/misc/eeprom. For now, there's no proposal for a generic efuse API. Instead, we simply group the drivers together. This patchset is the result of the initial submission for IMG Pistachio eFuse support [1]. Our first proposal was to follow the Tegra efuse, and put the Pistachio efuse in drivers/soc. After some discussion we finally agreed [2] to first create an efuse directoy, and then put all efuse drivers in it. As always, all comments are welcome! [1] http://www.spinics.net/lists/devicetree/msg59246.html [2] http://www.spinics.net/lists/arm-kernel/msg389325.html Have you looked at the EEPROM framework currently in discussions? The two seems to be covering pretty much the same use cases. Shouldn't this be a PROM framework if it is going to support both EEPROM and EFUSE/QFPROM, or am I missing something here (since an eFuse is not eraseable)? Does it really matter? I mean, it's just a name after all. But feel free to suggest alternatives on the main thread. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v3 7/9] mfd: rtsx: add support for rts524A
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
add support for new chip rts524A.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rts5249.c| 186
---
drivers/mfd/rtsx_pcr.c | 25 +-
drivers/mfd/rtsx_pcr.h | 7 ++
include/linux/mfd/rtsx_pci.h | 132 +-
4 files changed, 318 insertions(+), 32 deletions(-)
Applied, thanks.
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 3c77058..32be803 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -65,15 +65,17 @@ static void rts5249_fill_driving(struct rtsx_pcr *pcr, u8
voltage)
0xFF, driving[drive_sel][2]);
}
-static void rts5249_fetch_vendor_settings(struct rtsx_pcr *pcr)
+static void rtsx_base_fetch_vendor_settings(struct rtsx_pcr *pcr)
{
u32 reg;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
- if (!rtsx_vendor_setting_valid(reg))
+ if (!rtsx_vendor_setting_valid(reg)) {
+ pcr_dbg(pcr, skip fetch vendor setting\n);
return;
+ }
pcr-aspm_en = rtsx_reg_to_aspm(reg);
pcr-sd30_drive_sel_1v8 = rtsx_reg_to_sd30_drive_sel_1v8(reg);
@@ -87,7 +89,7 @@ static void rts5249_fetch_vendor_settings(struct rtsx_pcr
*pcr)
pcr-flags |= PCR_REVERSE_SOCKET;
}
-static void rts5249_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
+static void rtsx_base_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
{
/* Set relink_time to 0 */
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
@@ -95,7 +97,8 @@ static void rts5249_force_power_down(struct rtsx_pcr *pcr,
u8 pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
if (pm_state == HOST_ENTER_S3)
- rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+ rtsx_pci_write_register(pcr, pcr-reg_pm_ctrl3,
+ D3_DELINK_MODE_EN, D3_DELINK_MODE_EN);
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
}
@@ -104,6 +107,8 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
{
rtsx_pci_init_cmd(pcr);
+ /* Rest L1SUB Config */
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, L1SUB_CONFIG3, 0xFF, 0x00);
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
/* Reset ASPM state to default value */
@@ -189,27 +194,27 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
PHY_TUNE_TUNED12 | PHY_TUNE_TUNEA12);
}
-static int rts5249_turn_on_led(struct rtsx_pcr *pcr)
+static int rtsx_base_turn_on_led(struct rtsx_pcr *pcr)
{
return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x02);
}
-static int rts5249_turn_off_led(struct rtsx_pcr *pcr)
+static int rtsx_base_turn_off_led(struct rtsx_pcr *pcr)
{
return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x00);
}
-static int rts5249_enable_auto_blink(struct rtsx_pcr *pcr)
+static int rtsx_base_enable_auto_blink(struct rtsx_pcr *pcr)
{
return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x08);
}
-static int rts5249_disable_auto_blink(struct rtsx_pcr *pcr)
+static int rtsx_base_disable_auto_blink(struct rtsx_pcr *pcr)
{
return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x00);
}
-static int rts5249_card_power_on(struct rtsx_pcr *pcr, int card)
+static int rtsx_base_card_power_on(struct rtsx_pcr *pcr, int card)
{
int err;
@@ -236,7 +241,7 @@ static int rts5249_card_power_on(struct rtsx_pcr *pcr,
int card)
return 0;
}
-static int rts5249_card_power_off(struct rtsx_pcr *pcr, int card)
+static int rtsx_base_card_power_off(struct rtsx_pcr *pcr, int card)
{
rtsx_pci_init_cmd(pcr);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_PWR_CTL,
@@ -246,22 +251,35 @@ static int rts5249_card_power_off(struct rtsx_pcr *pcr,
int card)
return rtsx_pci_send_cmd(pcr, 100);
}
-static int rts5249_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+static int rtsx_base_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
{
int err;
+ u16 append;
- if (voltage == OUTPUT_3V3) {
- err = rtsx_pci_write_phy_register(pcr, PHY_TUNE, 0x4FC0 | 0x24);
+ switch (voltage) {
+ case OUTPUT_3V3:
+ err = rtsx_pci_update_phy(pcr, PHY_TUNE, PHY_TUNE_VOLTAGE_MASK,
+ PHY_TUNE_VOLTAGE_3V3);
if (err 0)
return err;
- } else if (voltage == OUTPUT_1V8) {
- err = rtsx_pci_write_phy_register(pcr, PHY_BACR, 0x3C02);
+ break;
+ case OUTPUT_1V8:
+ append = PHY_TUNE_D18_1V8;
+ if (CHK_PCI_PID(pcr,
Re: [PATCH v3 9/9] mfd: rtsx: using pcr_dbg replace dev_dbg
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
pcr_dbg is a wrapper of dev_dbg, which can save some code,
and help to enable/disable debug message static.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/rtl8411.c | 11 +--
drivers/mfd/rts5209.c | 4 ++--
drivers/mfd/rts5227.c | 4 ++--
drivers/mfd/rts5229.c | 4 ++--
drivers/mfd/rts5249.c | 4 ++--
drivers/mfd/rtsx_pcr.c | 49 ++---
6 files changed, 35 insertions(+), 41 deletions(-)
Applied, thanks.
diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index fdd34c8..b3ae659 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -53,7 +53,7 @@ static void rtl8411_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u8 reg3 = 0;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg1);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg1);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg1);
if (!rtsx_vendor_setting_valid(reg1))
return;
@@ -65,7 +65,7 @@ static void rtl8411_fetch_vendor_settings(struct rtsx_pcr
*pcr)
pcr-card_drive_sel |= rtsx_reg_to_card_drive_sel(reg1);
rtsx_pci_read_config_byte(pcr, PCR_SETTING_REG3, reg3);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG3, reg3);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG3, reg3);
pcr-sd30_drive_sel_3v3 = rtl8411_reg_to_sd30_drive_sel_3v3(reg3);
}
@@ -74,7 +74,7 @@ static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u32 reg = 0;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
if (!rtsx_vendor_setting_valid(reg))
return;
@@ -260,9 +260,8 @@ static unsigned int rtl8411_cd_deglitch(struct rtsx_pcr
*pcr)
rtsx_pci_write_register(pcr, CARD_PWR_CTL,
BPP_POWER_MASK, BPP_POWER_OFF);
- dev_dbg((pcr-pci-dev),
- After CD deglitch, card_exist = 0x%x\n,
- card_exist);
+ pcr_dbg(pcr, After CD deglitch, card_exist = 0x%x\n,
+ card_exist);
}
if (card_exist MS_EXIST) {
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index cb04174..373e253 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -38,7 +38,7 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u32 reg;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
if (rts5209_vendor_setting1_valid(reg)) {
if (rts5209_reg_check_ms_pmos(reg))
@@ -47,7 +47,7 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr
*pcr)
}
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG2, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG2, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG2, reg);
if (rts5209_vendor_setting2_valid(reg)) {
pcr-sd30_drive_sel_1v8 =
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 0c02831..ce012d7 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -63,7 +63,7 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u32 reg;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
if (!rtsx_vendor_setting_valid(reg))
return;
@@ -74,7 +74,7 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr
*pcr)
pcr-card_drive_sel |= rtsx_reg_to_card_drive_sel(reg);
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG2, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG2, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG2, reg);
pcr-sd30_drive_sel_3v3 = rtsx_reg_to_sd30_drive_sel_3v3(reg);
if (rtsx_reg_check_reverse_socket(reg))
pcr-flags |= PCR_REVERSE_SOCKET;
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index 6353f5d..ace4538 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -38,7 +38,7 @@ static void rts5229_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u32 reg;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
if (!rtsx_vendor_setting_valid(reg))
return;
@@ -50,7
Re: doubt about sm7xxfb
On Wed, Feb 25, 2015 at 06:00:02PM +0530, Sudip Mukherjee wrote: On Wed, Feb 11, 2015 at 02:33:51PM +0800, Greg Kroah-Hartman wrote: On Wed, Feb 11, 2015 at 11:58:18AM +0530, Sudip Mukherjee wrote: Ok, that makes sense, I was thinking this was a new driver, instead of a vendor driver crud. Hi Greg, The SM750 driver is almost ready for staging, it now compiles without any error with today's linux-next and is working properly , ok, there are lots of warning when compiling and checkpatch will give lots of complaints. But in total it is creating 34 files and the size of the patch is 360K. So should i send it with mail, just the way we send other patches or should i send you a git pull request? through email, like all other patches get sent please. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 5/6] hwmon: pwm-fan: Read PWM FAN configuration from device tree
This patch provides code for reading PWM FAN configuration data via
device tree. The pwm-fan can work with full speed when configuration
is not provided. However, errors are propagated when wrong DT bindings
are found.
Additionally the struct pwm_fan_ctx has been extended.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Rename pwm_fan_max_states to pwm_fan_cooling_levels
- Moving pwm_fan_of_get_cooling_data() call after setting end enabling PWM FAN
- pwm_fan_of_get_cooling_data() now can fail - preserving old behaviour
- Remove unnecessary dev_err() call
Changes for v3:
- Patch's headline has been reedited
- pwm_fan_of_get_cooling_data() return code is now being checked.
- of_property_count_elems_of_size() is now used instead of_find_property()
- More verbose patch description added
Changes for v4:
- dev_err() has been removed from pwm_fan_of_get_cooling_data()
- Returning -EINVAL when cooling-levels are defined in DT, but doesn't
have the value
Changes for v5:
- Use of of_find_property() to assess if cooling-levels was defined in
device tree
- Replace of_property_count_elems_of_size() with of_property_count_u32_elems()
- Remove ambiguity with returning error code from of_property_count_u32_elems()
- Return -EINVAL when cooling-levels has zero elements
---
drivers/hwmon/pwm-fan.c | 50 -
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index bd42d39..e6ed353 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -30,7 +30,10 @@
struct pwm_fan_ctx {
struct mutex lock;
struct pwm_device *pwm;
- unsigned char pwm_value;
+ unsigned int pwm_value;
+ unsigned int pwm_fan_state;
+ unsigned int pwm_fan_max_state;
+ unsigned int *pwm_fan_cooling_levels;
};
static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -100,6 +103,46 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
+{
+ struct device_node *np = dev-of_node;
+ int num, i, ret;
+
+ if (!of_find_property(np, cooling-levels, NULL))
+ return 0;
+
+ ret = of_property_count_u32_elems(np, cooling-levels);
+ if (ret = 0) {
+ dev_err(dev, Wrong data!\n);
+ return ret ? : -EINVAL;
+ }
+
+ num = ret;
+ ctx-pwm_fan_cooling_levels = devm_kzalloc(dev, num * sizeof(u32),
+ GFP_KERNEL);
+ if (!ctx-pwm_fan_cooling_levels)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(np, cooling-levels,
+ctx-pwm_fan_cooling_levels, num);
+ if (ret) {
+ dev_err(dev, Property 'cooling-levels' cannot be read!\n);
+ return ret;
+ }
+
+ for (i = 0; i num; i++) {
+ if (ctx-pwm_fan_cooling_levels[i] MAX_PWM) {
+ dev_err(dev, PWM fan state[%d]:%d %d\n, i,
+ ctx-pwm_fan_cooling_levels[i], MAX_PWM);
+ return -EINVAL;
+ }
+ }
+
+ ctx-pwm_fan_max_state = num - 1;
+
+ return 0;
+}
+
static int pwm_fan_probe(struct platform_device *pdev)
{
struct device *hwmon;
@@ -145,6 +188,11 @@ static int pwm_fan_probe(struct platform_device *pdev)
pwm_disable(ctx-pwm);
return PTR_ERR(hwmon);
}
+
+ ret = pwm_fan_of_get_cooling_data(pdev-dev, ctx);
+ if (ret)
+ return ret;
+
return 0;
}
--
2.0.0.rc2
--
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 v5 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx-pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no cooling-levels
property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
executing thermal_* specific functions
---
drivers/hwmon/pwm-fan.c | 83 -
1 file changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index e6ed353..2c1a8f0 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
#include linux/platform_device.h
#include linux/pwm.h
#include linux/sysfs.h
+#include linux/thermal.h
#define MAX_PWM 255
@@ -68,6 +69,17 @@ exit_set_pwm_err:
return ret;
}
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+ int i;
+
+ for (i = 0; i ctx-pwm_fan_max_state; ++i)
+ if (pwm ctx-pwm_fan_cooling_levels[i + 1])
+ break;
+
+ ctx-pwm_fan_state = i;
+}
+
static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -82,6 +94,7 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ pwm_fan_update_state(ctx, pwm);
return count;
}
@@ -103,6 +116,59 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev-devdata;
+
+ *state = ctx-pwm_fan_max_state;
+
+ return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev-devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx-pwm_fan_state;
+
+ return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+ struct pwm_fan_ctx *ctx = cdev-devdata;
+ int ret;
+
+ if (!ctx || (state ctx-pwm_fan_max_state))
+ return -EINVAL;
+
+ if (state == ctx-pwm_fan_state)
+ return 0;
+
+ ret = __set_pwm(ctx, ctx-pwm_fan_cooling_levels[state]);
+ if (ret) {
+ dev_err(cdev-device, Cannot set pwm!\n);
+ return ret;
+ }
+
+ ctx-pwm_fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+ .get_max_state = pwm_fan_get_max_state,
+ .get_cur_state = pwm_fan_get_cur_state,
+ .set_cur_state = pwm_fan_set_cur_state,
+};
+
int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev-of_node;
@@ -145,8 +211,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct
pwm_fan_ctx *ctx)
static int pwm_fan_probe(struct platform_device *pdev)
{
- struct device *hwmon;
+ struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct device *hwmon;
int duty_cycle;
int ret;
@@ -193,6 +260,20 @@ static int pwm_fan_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ctx-pwm_fan_state = ctx-pwm_fan_max_state;
+ if (IS_ENABLED(CONFIG_THERMAL)) {
+ cdev = thermal_of_cooling_device_register(pdev-dev.of_node,
+ pwm-fan, ctx,
+ pwm_fan_cooling_ops);
+ if (IS_ERR(cdev)) {
+ dev_err(pdev-dev,
+ Failed to register pwm-fan as cooling device);
+ pwm_disable(ctx-pwm);
+ return PTR_ERR(cdev);
+ }
+ thermal_cdev_update(cdev);
+ }
+
return 0;
}
--
2.0.0.rc2
--
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/
