Re: [PATCH v2 6/6] MAINTAINERS: Add phy-miphy28lp.c to ARCH/STI architecture
Hi, On Tuesday 31 March 2015 11:10 PM, Peter Griffin wrote: Hi Kishon, On Tue, 31 Mar 2015, Kishon Vijay Abraham I wrote: diff --git a/MAINTAINERS b/MAINTAINERS index 1de6afa..fa1bb4f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1469,6 +1469,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 add for miphy365x.c as well? Yes we should also be adding miphy365x.c as well. Would you like me to send a seperate patch for that? you can send an update to this patch. Haven't merged this one yet. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] rtc: omap: Unlock and Lock rtc registers before and after register writes
RTC module contains a kicker mechanism to prevent any spurious writes
from changing the register values. This mechanism requires two MMR
writes to the KICK0 and KICK1 registers with exact data values
before the kicker lock mechanism is released.
Currently the driver release the lock in the probe and leaves it enabled
until the rtc driver removal. This eliminates the idea of preventing
spurious writes when RTC driver is loaded.
So implement rtc lock and unlock functions before and after register writes.
Signed-off-by: Lokesh Vutla
---
- This is as advised by Paul to implement lock and unlock functions in
the driver and not to unlock and leave it in probe.
The same discussion can be seen here:
http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg111588.html
drivers/rtc/rtc-omap.c | 46 ++
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 8e5851a..96cc613 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -156,6 +156,22 @@ static inline void rtc_writel(struct omap_rtc *rtc,
unsigned int reg, u32 val)
writel(val, rtc->base + reg);
}
+static void rtc_unlock(struct omap_rtc *rtc)
+{
+ if (rtc->type->has_kicker) {
+ rtc_writel(rtc, OMAP_RTC_KICK0_REG, KICK0_VALUE);
+ rtc_writel(rtc, OMAP_RTC_KICK1_REG, KICK1_VALUE);
+ }
+}
+
+static void rtc_lock(struct omap_rtc *rtc)
+{
+ if (rtc->type->has_kicker) {
+ rtc_writel(rtc, OMAP_RTC_KICK0_REG, 0);
+ rtc_writel(rtc, OMAP_RTC_KICK1_REG, 0);
+ }
+}
+
/*
* We rely on the rtc framework to handle locking (rtc->ops_lock),
* so the only other requirement is that register accesses which
@@ -186,7 +202,9 @@ static irqreturn_t rtc_irq(int irq, void *dev_id)
/* alarm irq? */
if (irq_data & OMAP_RTC_STATUS_ALARM) {
+ rtc_unlock(rtc);
rtc_write(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_ALARM);
+ rtc_lock(rtc);
events |= RTC_IRQF | RTC_AF;
}
@@ -218,9 +236,11 @@ static int omap_rtc_alarm_irq_enable(struct device *dev,
unsigned int enabled)
irqwake_reg &= ~OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
}
rtc_wait_not_busy(rtc);
+ rtc_unlock(rtc);
rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, reg);
if (rtc->type->has_irqwakeen)
rtc_write(rtc, OMAP_RTC_IRQWAKEEN, irqwake_reg);
+ rtc_lock(rtc);
local_irq_enable();
return 0;
@@ -293,12 +313,14 @@ static int omap_rtc_set_time(struct device *dev, struct
rtc_time *tm)
local_irq_disable();
rtc_wait_not_busy(rtc);
+ rtc_unlock(rtc);
rtc_write(rtc, OMAP_RTC_YEARS_REG, tm->tm_year);
rtc_write(rtc, OMAP_RTC_MONTHS_REG, tm->tm_mon);
rtc_write(rtc, OMAP_RTC_DAYS_REG, tm->tm_mday);
rtc_write(rtc, OMAP_RTC_HOURS_REG, tm->tm_hour);
rtc_write(rtc, OMAP_RTC_MINUTES_REG, tm->tm_min);
rtc_write(rtc, OMAP_RTC_SECONDS_REG, tm->tm_sec);
+ rtc_lock(rtc);
local_irq_enable();
@@ -341,6 +363,7 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
local_irq_disable();
rtc_wait_not_busy(rtc);
+ rtc_unlock(rtc);
rtc_write(rtc, OMAP_RTC_ALARM_YEARS_REG, alm->time.tm_year);
rtc_write(rtc, OMAP_RTC_ALARM_MONTHS_REG, alm->time.tm_mon);
rtc_write(rtc, OMAP_RTC_ALARM_DAYS_REG, alm->time.tm_mday);
@@ -362,6 +385,7 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, reg);
if (rtc->type->has_irqwakeen)
rtc_write(rtc, OMAP_RTC_IRQWAKEEN, irqwake_reg);
+ rtc_lock(rtc);
local_irq_enable();
@@ -391,6 +415,7 @@ static void omap_rtc_power_off(void)
unsigned long now;
u32 val;
+ rtc_unlock(rtc);
/* enable pmic_power_en control */
val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
@@ -423,6 +448,7 @@ static void omap_rtc_power_off(void)
val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
+ rtc_lock(rtc);
/*
* Wait for alarm to trigger (within two seconds) and external PMIC to
@@ -527,10 +553,7 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
pm_runtime_enable(>dev);
pm_runtime_get_sync(>dev);
- if (rtc->type->has_kicker) {
- rtc_writel(rtc, OMAP_RTC_KICK0_REG, KICK0_VALUE);
- rtc_writel(rtc, OMAP_RTC_KICK1_REG, KICK1_VALUE);
- }
+ rtc_unlock(rtc);
/*
* disable interrupts
@@ -593,6 +616,8 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
if (reg
[PATCH 0/3] rtc: omap: Fix misc bugs
This patch series fixes miscellaneous bugs in OMAP RTC driver. Tested on DRA72-evm with an out of tree patch for RTC hwmod. Logs: http://pastebin.ubuntu.com/10716566/ Lokesh Vutla (3): rtc: omap: Unlock and Lock rtc registers before and after register writes rtc: omap: Update Kconfig for OMAP RTC rtc: omap: use module_platform_driver drivers/rtc/Kconfig| 6 +++--- drivers/rtc/rtc-omap.c | 51 -- 2 files changed, 44 insertions(+), 13 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] rtc: omap: use module_platform_driver
module_platform_driver_probe() prevents driver from requesting probe deferral.
So using module_platform_drive() to support probe deferral.
Signed-off-by: Lokesh Vutla
---
drivers/rtc/rtc-omap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 96cc613..a4965a0 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -510,7 +510,7 @@ static const struct of_device_id omap_rtc_of_match[] = {
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
-static int __init omap_rtc_probe(struct platform_device *pdev)
+static int omap_rtc_probe(struct platform_device *pdev)
{
struct omap_rtc *rtc;
struct resource *res;
@@ -745,6 +745,7 @@ static void omap_rtc_shutdown(struct platform_device *pdev)
}
static struct platform_driver omap_rtc_driver = {
+ .probe = omap_rtc_probe,
.remove = __exit_p(omap_rtc_remove),
.shutdown = omap_rtc_shutdown,
.driver = {
@@ -755,7 +756,7 @@ static struct platform_driver omap_rtc_driver = {
.id_table = omap_rtc_id_table,
};
-module_platform_driver_probe(omap_rtc_driver, omap_rtc_probe);
+module_platform_driver(omap_rtc_driver);
MODULE_ALIAS("platform:omap_rtc");
MODULE_AUTHOR("George G. Davis (and others)");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] rtc: omap: Update Kconfig for OMAP RTC
RTC is present in AM43xx and DRA7xx also. Updating the Kconfig to depend on ARCH_OMAP or ARCH_DAVINCI Signed-off-by: Lokesh Vutla --- drivers/rtc/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index b5b5c3d..40faf56 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -1121,11 +1121,11 @@ config RTC_DRV_IMXDI will be called "rtc-imxdi". config RTC_DRV_OMAP - tristate "TI OMAP1" - depends on ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_DAVINCI_DA8XX || SOC_AM33XX + tristate "TI OMAP Real Time Clock" + depends on ARCH_OMAP || ARCH_DAVINCI help Say "yes" here to support the on chip real time clock - present on TI OMAP1, AM33xx and DA8xx/OMAP-L13x. + present on TI OMAP1, AM33xx, DA8xx/OMAP-L13x, AM43xx and DRA7xx. This driver can also be built as a module, if so, module will be called rtc-omap. -- 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] drm/rockchip: vop: add vop power domain support
From: Mark Yao
Reference the power domain incase vop power down when
in use.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d041921..7a61c8e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -421,6 +421,12 @@ static void vop_enable(struct drm_crtc *crtc)
if (vop->is_enabled)
return;
+ ret = pm_runtime_get_sync(vop->dev);
+ if (ret < 0) {
+ dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
+ return;
+ }
+
ret = clk_enable(vop->hclk);
if (ret < 0) {
dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
@@ -517,6 +523,7 @@ static void vop_disable(struct drm_crtc *crtc)
clk_disable(vop->dclk);
clk_disable(vop->aclk);
clk_disable(vop->hclk);
+ pm_runtime_put(vop->dev);
}
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 19/25] sched: Use bool function return values of true/false not 1/0
Use the normal return values for bool functions
Update the other sets of ret in try_wait_for_completion.
Signed-off-by: Joe Perches
---
On Tue, 2015-03-31 at 22:17 -0700, Jason Low wrote:
> On Mon, Mar 30, 2015 at 4:46 PM, Joe Perches wrote:
>
> > * try_wait_for_completion - try to decrement a completion without
> > blocking
> > * @x: completion structure
> > *
> > - * Return: 0 if a decrement cannot be done without blocking
> > - * 1 if a decrement succeeded.
> > + * Return: true if a decrement cannot be done without blocking
> > + * false if a decrement succeeded.
> The boolean logic was reversed in this comment. The function should be
> returning false if a decrement cannot be done without blocking, and
> true if a decrement succeeded.
Hi Jason, right, my typo, thanks for noticing.
kernel/sched/auto_group.h | 2 +-
kernel/sched/completion.c | 16 +---
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/auto_group.h b/kernel/sched/auto_group.h
index 8bd0471..309b6f2 100644
--- a/kernel/sched/auto_group.h
+++ b/kernel/sched/auto_group.h
@@ -45,7 +45,7 @@ static inline void autogroup_init(struct task_struct
*init_task) { }
static inline void autogroup_free(struct task_group *tg) { }
static inline bool task_group_is_autogroup(struct task_group *tg)
{
- return 0;
+ return false;
}
static inline struct task_group *
diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
index 8d0f35d..cbccaa0 100644
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -255,8 +255,8 @@ EXPORT_SYMBOL(wait_for_completion_killable_timeout);
* try_wait_for_completion - try to decrement a completion without blocking
* @x: completion structure
*
- * Return: 0 if a decrement cannot be done without blocking
- * 1 if a decrement succeeded.
+ * Return: false if a decrement cannot be done without blocking
+ * true if a decrement succeeded.
*
* If a completion is being used as a counting completion,
* attempt to decrement the counter without blocking. This
@@ -266,7 +266,7 @@ EXPORT_SYMBOL(wait_for_completion_killable_timeout);
bool try_wait_for_completion(struct completion *x)
{
unsigned long flags;
- int ret = 1;
+ bool ret;
/*
* Since x->done will need to be locked only
@@ -275,13 +275,15 @@ bool try_wait_for_completion(struct completion *x)
* return early in the blocking case.
*/
if (!READ_ONCE(x->done))
- return 0;
+ return false;
spin_lock_irqsave(>wait.lock, flags);
- if (!x->done)
- ret = 0;
- else
+ if (!x->done) {
+ ret = false;
+ } else {
x->done--;
+ ret = true;
+ }
spin_unlock_irqrestore(>wait.lock, flags);
return ret;
}
--
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] kernel/reboot.c: Add orderly_reboot for graceful reboot
On Wed, Apr 1, 2015 at 3:22 PM, Anshuman Khandual
wrote:
>> +static int __orderly_poweroff(bool force)
>> +{
>> + int ret;
>> +
>> + ret = run_cmd(reboot_cmd);
>
> Would it be poweroff_cmd instead of reboot_cmd ? Dont see poweroff_cmd
> getting used.
Yes, good catch. Thanks.
Joel
--
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 v6 1/3] dt-bindings: Add I2C bindings for mt65xx/mt81xx.
From: Xudong Chen
Add devicetree bindings for Mediatek Soc I2C driver.
Signed-off-by: Xudong Chen
Signed-off-by: Eddie Huang
---
.../devicetree/bindings/i2c/i2c-mt6577.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
new file mode 100644
index 000..0ce6fa3
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
@@ -0,0 +1,41 @@
+* Mediatek's I2C controller
+
+The Mediatek's I2C controller is used to interface with I2C devices.
+
+Required properties:
+ - compatible: value should be either of the following.
+ (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
+ (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
+ (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
+ (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
+ (e) "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
+ - reg: physical base address of the controller and dma base, length of memory
+mapped region.
+ - interrupts: interrupt number to the cpu.
+ - clock-div: the fixed value for frequency divider of clock source in i2c
+module. Each IC may be different.
+ - clocks: clock name from clock manager
+ - clock-names: Must include "main" and "dma", if enable have-pmic need
include
+"pmic" extra.
+
+Optional properties:
+ - clock-frequency: Frequency in Hz of the bus when transfer, the default
value
+is 10.
+ - mediatek,have-pmic: platform can control i2c form special pmic side.
+Only mt6589 and mt8135 support this feature.
+ - mediatek,use-push-pull: IO config use push-pull mode.
+
+Example:
+
+ i2c0: i2c@1100d000 {
+ compatible = "mediatek,mt6577-i2c";
+ reg = <0x1100d000 0x70>,
+ <0x11000300 0x80>;
+ interrupts = ;
+ clock-frequency = <40>;
+ mediatek,have-pmic;
+ clock-div = <16>;
+ clocks = <_ck>, <_dma_ck>;
+ clock-names = "main", "dma";
+ };
+
--
1.8.1.1.dirty
--
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 v6 3/3] I2C: mediatek: Add driver for MediaTek MT8173 I2C controller
Add mediatek MT8173 I2C controller driver. Compare to I2C controller
of earlier mediatek SoC, MT8173 fix write-then-read limitation, and
also increase message size to 64kb.
Signed-off-by: Xudong Chen
Signed-off-by: Liguo Zhang
Signed-off-by: Eddie Huang
---
drivers/i2c/busses/i2c-mt65xx.c | 104 +---
1 file changed, 76 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 2ecf0d1..80df0df 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -33,10 +33,13 @@
#include
#include
+#define I2C_RS_TRANSFER(1 << 4)
#define I2C_HS_NACKERR (1 << 2)
#define I2C_ACKERR (1 << 1)
#define I2C_TRANSAC_COMP (1 << 0)
#define I2C_TRANSAC_START (1 << 0)
+#define I2C_RS_MUL_CNFG(1 << 15)
+#define I2C_RS_MUL_TRIG(1 << 14)
#define I2C_TIMING_STEP_DIV_MASK (0x3f << 0)
#define I2C_TIMING_SAMPLE_COUNT_MASK (0x7 << 0)
#define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8)
@@ -67,6 +70,9 @@
#define MAX_MSG_NUM_MT6577 1
#define MAX_DMA_TRANS_SIZE_MT6577 255
#define MAX_WRRD_TRANS_SIZE_MT6577 31
+#define MAX_MSG_NUM_MT8173 65535
+#define MAX_DMA_TRANS_SIZE_MT8173 65535
+#define MAX_WRRD_TRANS_SIZE_MT8173 65535
#define MAX_SAMPLE_CNT_DIV 8
#define MAX_STEP_CNT_DIV 64
#define MAX_HS_STEP_CNT_DIV8
@@ -139,6 +145,7 @@ struct mtk_i2c_compatible {
const struct i2c_adapter_quirks *quirks;
unsigned char pmic_i2c;
unsigned char dcm;
+ unsigned char auto_restart;
};
struct mtk_i2c {
@@ -172,21 +179,39 @@ static const struct i2c_adapter_quirks mt6577_i2c_quirks
= {
.max_comb_2nd_msg_len = MAX_WRRD_TRANS_SIZE_MT6577,
};
+static const struct i2c_adapter_quirks mt8173_i2c_quirks = {
+ .max_num_msgs = MAX_MSG_NUM_MT8173,
+ .max_write_len = MAX_DMA_TRANS_SIZE_MT8173,
+ .max_read_len = MAX_DMA_TRANS_SIZE_MT8173,
+ .max_comb_1st_msg_len = MAX_DMA_TRANS_SIZE_MT8173,
+ .max_comb_2nd_msg_len = MAX_WRRD_TRANS_SIZE_MT8173,
+};
+
static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = _i2c_quirks,
.pmic_i2c = 0,
.dcm = 1,
+ .auto_restart = 0,
};
static const struct mtk_i2c_compatible mt6589_compat = {
.quirks = _i2c_quirks,
.pmic_i2c = 1,
.dcm = 0,
+ .auto_restart = 0,
+};
+
+static const struct mtk_i2c_compatible mt8173_compat = {
+ .quirks = _i2c_quirks,
+ .pmic_i2c = 0,
+ .dcm = 1,
+ .auto_restart = 1,
};
static const struct of_device_id mtk_i2c_of_match[] = {
{ .compatible = "mediatek,mt6577-i2c", .data = (void *)_compat },
{ .compatible = "mediatek,mt6589-i2c", .data = (void *)_compat },
+ { .compatible = "mediatek,mt8173-i2c", .data = (void *)_compat },
{}
};
MODULE_DEVICE_TABLE(of, mtk_i2c_match);
@@ -343,9 +368,11 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned
int clk_src_in_hz)
return 0;
}
-static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs)
+static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
+ int num, int left_num)
{
u16 addr_reg;
+ u16 start_reg;
u16 control_reg;
dma_addr_t rpaddr = 0;
dma_addr_t wpaddr = 0;
@@ -361,6 +388,8 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct
i2c_msg *msgs)
control_reg |= I2C_CONTROL_RS;
if (i2c->op == I2C_MASTER_WRRD)
control_reg |= I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS;
+ if (left_num >= 1)
+ control_reg |= I2C_CONTROL_RS;
mtk_i2c_writew(control_reg, i2c, OFFSET_CONTROL);
/* set start condition */
@@ -375,13 +404,13 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
struct i2c_msg *msgs)
mtk_i2c_writew(addr_reg, i2c, OFFSET_SLAVE_ADDR);
/* Clear interrupt status */
- mtk_i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP,
- i2c, OFFSET_INTR_STAT);
+ mtk_i2c_writew(I2C_RS_TRANSFER | I2C_HS_NACKERR | I2C_ACKERR
+ | I2C_TRANSAC_COMP, i2c, OFFSET_INTR_STAT);
mtk_i2c_writew(I2C_FIFO_ADDR_CLR, i2c, OFFSET_FIFO_ADDR_CLR);
/* Enable interrupt */
- mtk_i2c_writew(I2C_HS_NACKERR | I2C_ACKERR | I2C_TRANSAC_COMP,
- i2c, OFFSET_INTR_MASK);
+ mtk_i2c_writew(I2C_RS_TRANSFER | I2C_HS_NACKERR | I2C_ACKERR
+ | I2C_TRANSAC_COMP, i2c, OFFSET_INTR_MASK);
/* Set transfer and transaction len */
if (i2c->op == I2C_MASTER_WRRD) {
@@ -390,7 +419,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct
i2c_msg *msgs)
[PATCH v6 2/3] I2C: mediatek: Add driver for MediaTek I2C controller
From: Xudong Chen
The mediatek SoCs have I2C controller that handle I2C transfer.
This patch include common I2C bus driver.
This driver is compatible with I2C controller on mt65xx/mt81xx.
Signed-off-by: Xudong Chen
Signed-off-by: Liguo Zhang
Signed-off-by: Eddie Huang
---
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-mt65xx.c | 700
3 files changed, 710 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-mt65xx.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2..243c4ec 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -602,6 +602,15 @@ config I2C_MPC
This driver can also be built as a module. If so, the module
will be called i2c-mpc.
+config I2C_MT65XX
+ tristate "MediaTek I2C adapter"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ help
+ This selects the MediaTek(R) Integrated Inter Circuit bus driver
+ for MT65xx and MT81xx.
+ If you want to use MediaTek(R) I2C interface, say Y or M here.
+ If unsure, say N.
+
config I2C_MV64XXX
tristate "Marvell mv64xxx I2C Controller"
depends on MV64X60 || PLAT_ORION || ARCH_SUNXI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 3638feb..372a711 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
obj-$(CONFIG_I2C_KEMPLD) += i2c-kempld.o
obj-$(CONFIG_I2C_MESON)+= i2c-meson.o
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
+obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o
obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_MXS) += i2c-mxs.o
obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
new file mode 100644
index 000..2ecf0d1
--- /dev/null
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -0,0 +1,700 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Xudong.chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define I2C_HS_NACKERR (1 << 2)
+#define I2C_ACKERR (1 << 1)
+#define I2C_TRANSAC_COMP (1 << 0)
+#define I2C_TRANSAC_START (1 << 0)
+#define I2C_TIMING_STEP_DIV_MASK (0x3f << 0)
+#define I2C_TIMING_SAMPLE_COUNT_MASK (0x7 << 0)
+#define I2C_TIMING_SAMPLE_DIV_MASK (0x7 << 8)
+#define I2C_TIMING_DATA_READ_MASK (0x7 << 12)
+#define I2C_DCM_DISABLE0x
+#define I2C_IO_CONFIG_OPEN_DRAIN 0x0003
+#define I2C_IO_CONFIG_PUSH_PULL0x
+#define I2C_SOFT_RST 0x0001
+#define I2C_FIFO_ADDR_CLR 0x0001
+#define I2C_DELAY_LEN 0x0002
+#define I2C_ST_START_CON 0x8001
+#define I2C_FS_START_CON 0x1800
+#define I2C_TIME_CLR_VALUE 0x
+#define I2C_TIME_DEFAULT_VALUE 0x0003
+#define I2C_FS_TIME_INIT_VALUE 0x1303
+#define I2C_WRRD_TRANAC_VALUE 0x0002
+#define I2C_RD_TRANAC_VALUE0x0001
+
+#define I2C_DMA_CON_TX 0x
+#define I2C_DMA_CON_RX 0x0001
+#define I2C_DMA_START_EN 0x0001
+#define I2C_DMA_INT_FLAG_NONE 0x
+#define I2C_DMA_CLR_FLAG 0x
+
+#define I2C_DEFAUT_SPEED 10 /* hz */
+#define MAX_FS_MODE_SPEED 40
+#define MAX_HS_MODE_SPEED 340
+#define MAX_MSG_NUM_MT6577 1
+#define MAX_DMA_TRANS_SIZE_MT6577 255
+#define MAX_WRRD_TRANS_SIZE_MT6577 31
+#define MAX_SAMPLE_CNT_DIV 8
+#define MAX_STEP_CNT_DIV 64
+#define MAX_HS_STEP_CNT_DIV8
+
+#define I2C_CONTROL_RS (0x1 << 1)
+#define I2C_CONTROL_DMA_EN (0x1 << 2)
+#define I2C_CONTROL_CLK_EXT_EN (0x1 << 3)
+#define I2C_CONTROL_DIR_CHANGE (0x1 << 4)
+#define I2C_CONTROL_ACKERR_DET_EN (0x1 << 5)
+#define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6)
+#define I2C_CONTROL_WRAPPER (0x1 << 0)
+
+#define I2C_DRV_NAME "mt-i2c"
+
+enum DMA_REGS_OFFSET {
+ OFFSET_INT_FLAG = 0x0,
+ OFFSET_INT_EN = 0x04,
+ OFFSET_EN =
[tip:timers/core] clocksource/drivers/sun5i: Refactor the current code
Commit-ID: 4a59058f0b09682200c04b1db236b4a3b92128d7
Gitweb: http://git.kernel.org/tip/4a59058f0b09682200c04b1db236b4a3b92128d7
Author: Maxime Ripard
AuthorDate: Tue, 31 Mar 2015 12:12:25 +0200
Committer: Ingo Molnar
CommitDate: Tue, 31 Mar 2015 17:53:58 +0200
clocksource/drivers/sun5i: Refactor the current code
Refactor the code in order to remove the global variables and
split the clock source and clock events registration in order to
ease the addition of the clock notifiers needed to handle the
parent clock rate changes.
Signed-off-by: Maxime Ripard
Signed-off-by: Daniel Lezcano
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/1427796746-373-4-git-send-email-daniel.lezc...@linaro.org
Signed-off-by: Ingo Molnar
---
drivers/clocksource/timer-sun5i.c | 231 +++---
1 file changed, 166 insertions(+), 65 deletions(-)
diff --git a/drivers/clocksource/timer-sun5i.c
b/drivers/clocksource/timer-sun5i.c
index 87f7b81..2330090 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,8 +37,27 @@
#define TIMER_SYNC_TICKS 3
-static void __iomem *timer_base;
-static u32 ticks_per_jiffy;
+struct sun5i_timer {
+ void __iomem*base;
+ struct clk *clk;
+ u32 ticks_per_jiffy;
+};
+
+struct sun5i_timer_clksrc {
+ struct sun5i_timer timer;
+ struct clocksource clksrc;
+};
+
+#define to_sun5i_timer_clksrc(x) \
+ container_of(x, struct sun5i_timer_clksrc, clksrc)
+
+struct sun5i_timer_clkevt {
+ struct sun5i_timer timer;
+ struct clock_event_device clkevt;
+};
+
+#define to_sun5i_timer_clkevt(x) \
+ container_of(x, struct sun5i_timer_clkevt, clkevt)
/*
* When we disable a timer, we need to wait at least for 2 cycles of
@@ -45,30 +65,30 @@ static u32 ticks_per_jiffy;
* that is already setup and runs at the same frequency than the other
* timers, and we never will be disabled.
*/
-static void sun5i_clkevt_sync(void)
+static void sun5i_clkevt_sync(struct sun5i_timer_clkevt *ce)
{
- u32 old = readl(timer_base + TIMER_CNTVAL_LO_REG(1));
+ u32 old = readl(ce->timer.base + TIMER_CNTVAL_LO_REG(1));
- while ((old - readl(timer_base + TIMER_CNTVAL_LO_REG(1))) <
TIMER_SYNC_TICKS)
+ while ((old - readl(ce->timer.base + TIMER_CNTVAL_LO_REG(1))) <
TIMER_SYNC_TICKS)
cpu_relax();
}
-static void sun5i_clkevt_time_stop(u8 timer)
+static void sun5i_clkevt_time_stop(struct sun5i_timer_clkevt *ce, u8 timer)
{
- u32 val = readl(timer_base + TIMER_CTL_REG(timer));
- writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+ u32 val = readl(ce->timer.base + TIMER_CTL_REG(timer));
+ writel(val & ~TIMER_CTL_ENABLE, ce->timer.base + TIMER_CTL_REG(timer));
- sun5i_clkevt_sync();
+ sun5i_clkevt_sync(ce);
}
-static void sun5i_clkevt_time_setup(u8 timer, u32 delay)
+static void sun5i_clkevt_time_setup(struct sun5i_timer_clkevt *ce, u8 timer,
u32 delay)
{
- writel(delay, timer_base + TIMER_INTVAL_LO_REG(timer));
+ writel(delay, ce->timer.base + TIMER_INTVAL_LO_REG(timer));
}
-static void sun5i_clkevt_time_start(u8 timer, bool periodic)
+static void sun5i_clkevt_time_start(struct sun5i_timer_clkevt *ce, u8 timer,
bool periodic)
{
- u32 val = readl(timer_base + TIMER_CTL_REG(timer));
+ u32 val = readl(ce->timer.base + TIMER_CTL_REG(timer));
if (periodic)
val &= ~TIMER_CTL_ONESHOT;
@@ -76,66 +96,170 @@ static void sun5i_clkevt_time_start(u8 timer, bool
periodic)
val |= TIMER_CTL_ONESHOT;
writel(val | TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
- timer_base + TIMER_CTL_REG(timer));
+ ce->timer.base + TIMER_CTL_REG(timer));
}
static void sun5i_clkevt_mode(enum clock_event_mode mode,
- struct clock_event_device *clk)
+ struct clock_event_device *clkevt)
{
+ struct sun5i_timer_clkevt *ce = to_sun5i_timer_clkevt(clkevt);
+
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
- sun5i_clkevt_time_stop(0);
- sun5i_clkevt_time_setup(0, ticks_per_jiffy);
- sun5i_clkevt_time_start(0, true);
+ sun5i_clkevt_time_stop(ce, 0);
+ sun5i_clkevt_time_setup(ce, 0, ce->timer.ticks_per_jiffy);
+ sun5i_clkevt_time_start(ce, 0, true);
break;
case CLOCK_EVT_MODE_ONESHOT:
- sun5i_clkevt_time_stop(0);
- sun5i_clkevt_time_start(0, false);
+ sun5i_clkevt_time_stop(ce, 0);
+ sun5i_clkevt_time_start(ce, 0, false);
break;
case CLOCK_EVT_MODE_UNUSED:
case
[PATCH v6 0/3] ARM: mediatek: Add driver for Mediatek I2C controller
This series is for Mediatek SoCs I2C controller common bus driver. Earlier MTK SoC (for example, MT6589, MT8135) I2C HW has some limitationes. New generation SoC like MT8173 fix these limitations. 1. Only support one i2c_msg number. One exception is WRRD (write then read) mode. WRRD can have two i2c_msg numbers. 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD mode the Repeat Start will be issued between 2 messages. In this driver if 2 messages is first write then read, the driver will combine 2 messages using Write-Read mode so the RS will be issued between the 2 messages. 3. The max transfer data length is 255 in one message. In WRRD mode, the max data length of second msg is 31. MT8135 and MT6589 can control I2C pins on PMIC(MT6397) by setting the i2c registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR bit first, the operation on other registers are still the same. For now MT6589/MT8135 support this, MT6577/MT6595/MT8127 do not support. For example, If want to use I2C4/5/6 pins on MT8135 just need to enable the pinmux, else if want to use I2C pins on PMIC(MT6397) need to add "mediatek,have-pmic" property in the .dts file of each platform. This driver is based on 4.0-rc1. Change in v6: Add mtk_i2c_compatible struct to set driver capability, and pass by of_device_id. Change to use completion API instead of waitqueue. Remove unnecessary spinlock. Fix get default speed error bug. Fix Sascha's review comment. Change in v5: Apply new i2c_adapter_quirks patch [2]. Change to use dam_map_single to map dma buffer. Add spinlock to fix race condition. Check of_property_read_u32 return value. Remove I2C_FUNC_10BIT_ADDR capability due to driver not implement. Add MT8173 I2C driver. Change in v4: Modify to support i2c_adapter_quirks base on Wolfram's patch [1]. Remove check transfer size and WRRD combine code. Instead, fill quirk property and let i2c_check_for_quirks to do the filter. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314804.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325744.html Eddie Huang (1): I2C: mediatek: Add driver for MediaTek MT8173 I2C controller Xudong Chen (2): dt-bindings: Add I2C bindings for mt65xx/mt81xx. I2C: mediatek: Add driver for MediaTek I2C controller .../devicetree/bindings/i2c/i2c-mt6577.txt | 41 ++ drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-mt65xx.c| 748 + 4 files changed, 799 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt create mode 100644 drivers/i2c/busses/i2c-mt65xx.c -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:timers/core] clocksource/drivers/arm_arch_timer: Rename ' arch_timer_probed()' to 'arch_timer_needs_probing()' to reflect behaviour
Commit-ID: 566e6dfad580a55084c29fe3e887c7273b16fc6a
Gitweb: http://git.kernel.org/tip/566e6dfad580a55084c29fe3e887c7273b16fc6a
Author: Laurent Pinchart
AuthorDate: Tue, 31 Mar 2015 12:12:22 +0200
Committer: Ingo Molnar
CommitDate: Tue, 31 Mar 2015 17:53:57 +0200
clocksource/drivers/arm_arch_timer: Rename 'arch_timer_probed()' to
'arch_timer_needs_probing()' to reflect behaviour
The arch_timer_probed() function returns whether the given time
doesn't need to be probed. This can be the case when the timer
has been probed already, but also when it has no corresponding
enabled node in DT.
Rename the function to arch_timer_needs_probing() and invert its
return value to better reflect the function's purpose and
behaviour.
Signed-off-by: Laurent Pinchart
Signed-off-by: Daniel Lezcano
Acked-by: Sudeep Holla
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/1427796746-373-1-git-send-email-daniel.lezc...@linaro.org
Signed-off-by: Ingo Molnar
---
drivers/clocksource/arm_arch_timer.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index a3025e7..2664696 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -661,17 +661,17 @@ static const struct of_device_id
arch_timer_mem_of_match[] __initconst = {
};
static bool __init
-arch_timer_probed(int type, const struct of_device_id *matches)
+arch_timer_needs_probing(int type, const struct of_device_id *matches)
{
struct device_node *dn;
- bool probed = true;
+ bool needs_probing = false;
dn = of_find_matching_node(NULL, matches);
if (dn && of_device_is_available(dn) && !(arch_timers_present & type))
- probed = false;
+ needs_probing = true;
of_node_put(dn);
- return probed;
+ return needs_probing;
}
static void __init arch_timer_common_init(void)
@@ -680,9 +680,9 @@ static void __init arch_timer_common_init(void)
/* Wait until both nodes are probed if we have two timers */
if ((arch_timers_present & mask) != mask) {
- if (!arch_timer_probed(ARCH_MEM_TIMER, arch_timer_mem_of_match))
+ if (arch_timer_needs_probing(ARCH_MEM_TIMER,
arch_timer_mem_of_match))
return;
- if (!arch_timer_probed(ARCH_CP15_TIMER, arch_timer_of_match))
+ if (arch_timer_needs_probing(ARCH_CP15_TIMER,
arch_timer_of_match))
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/
[tip:timers/core] clocksource/drivers/sun5i: Add clock notifiers
Commit-ID: 3071efa466b30636bf958f3d13bc808e03105cd8
Gitweb: http://git.kernel.org/tip/3071efa466b30636bf958f3d13bc808e03105cd8
Author: Maxime Ripard
AuthorDate: Tue, 31 Mar 2015 12:12:26 +0200
Committer: Ingo Molnar
CommitDate: Tue, 31 Mar 2015 17:53:58 +0200
clocksource/drivers/sun5i: Add clock notifiers
The parent clock of the sun5i timer is the AHB clock, which rate
might change because of other devices requirements.
This is for example the case on the Allwinner A31, where the DMA
controller needs a minimum rate higher than the default, that is
enforced after the timer driver has probed.
Add clock notifiers to make sure we reflect the clock rate
changes in the timer rates.
Signed-off-by: Maxime Ripard
Signed-off-by: Daniel Lezcano
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/1427796746-373-5-git-send-email-daniel.lezc...@linaro.org
Signed-off-by: Ingo Molnar
---
drivers/clocksource/timer-sun5i.c | 66 +--
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/timer-sun5i.c
b/drivers/clocksource/timer-sun5i.c
index 2330090..28aa4b7 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -40,9 +40,13 @@
struct sun5i_timer {
void __iomem*base;
struct clk *clk;
+ struct notifier_block clk_rate_cb;
u32 ticks_per_jiffy;
};
+#define to_sun5i_timer(x) \
+ container_of(x, struct sun5i_timer, clk_rate_cb)
+
struct sun5i_timer_clksrc {
struct sun5i_timer timer;
struct clocksource clksrc;
@@ -151,6 +155,29 @@ static cycle_t sun5i_clksrc_read(struct clocksource
*clksrc)
return ~readl(cs->timer.base + TIMER_CNTVAL_LO_REG(1));
}
+static int sun5i_rate_cb_clksrc(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct clk_notifier_data *ndata = data;
+ struct sun5i_timer *timer = to_sun5i_timer(nb);
+ struct sun5i_timer_clksrc *cs = container_of(timer, struct
sun5i_timer_clksrc, timer);
+
+ switch (event) {
+ case PRE_RATE_CHANGE:
+ clocksource_unregister(>clksrc);
+ break;
+
+ case POST_RATE_CHANGE:
+ clocksource_register_hz(>clksrc, ndata->new_rate);
+ break;
+
+ default:
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
static int __init sun5i_setup_clocksource(struct device_node *node,
void __iomem *base,
struct clk *clk, int irq)
@@ -173,6 +200,14 @@ static int __init sun5i_setup_clocksource(struct
device_node *node,
cs->timer.base = base;
cs->timer.clk = clk;
+ cs->timer.clk_rate_cb.notifier_call = sun5i_rate_cb_clksrc;
+ cs->timer.clk_rate_cb.next = NULL;
+
+ ret = clk_notifier_register(clk, >timer.clk_rate_cb);
+ if (ret) {
+ pr_err("Unable to register clock notifier.\n");
+ goto err_disable_clk;
+ }
writel(~0, base + TIMER_INTVAL_LO_REG(1));
writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
@@ -187,11 +222,13 @@ static int __init sun5i_setup_clocksource(struct
device_node *node,
ret = clocksource_register_hz(>clksrc, rate);
if (ret) {
pr_err("Couldn't register clock source.\n");
- goto err_disable_clk;
+ goto err_remove_notifier;
}
return 0;
+err_remove_notifier:
+ clk_notifier_unregister(clk, >timer.clk_rate_cb);
err_disable_clk:
clk_disable_unprepare(clk);
err_free:
@@ -199,6 +236,21 @@ err_free:
return ret;
}
+static int sun5i_rate_cb_clkevt(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct clk_notifier_data *ndata = data;
+ struct sun5i_timer *timer = to_sun5i_timer(nb);
+ struct sun5i_timer_clkevt *ce = container_of(timer, struct
sun5i_timer_clkevt, timer);
+
+ if (event == POST_RATE_CHANGE) {
+ clockevents_update_freq(>clkevt, ndata->new_rate);
+ ce->timer.ticks_per_jiffy = DIV_ROUND_UP(ndata->new_rate, HZ);
+ }
+
+ return NOTIFY_DONE;
+}
+
static int __init sun5i_setup_clockevent(struct device_node *node, void
__iomem *base,
struct clk *clk, int irq)
{
@@ -222,6 +274,14 @@ static int __init sun5i_setup_clockevent(struct
device_node *node, void __iomem
ce->timer.base = base;
ce->timer.ticks_per_jiffy = DIV_ROUND_UP(rate, HZ);
ce->timer.clk = clk;
+ ce->timer.clk_rate_cb.notifier_call = sun5i_rate_cb_clkevt;
+ ce->timer.clk_rate_cb.next = NULL;
+
+ ret = clk_notifier_register(clk, >timer.clk_rate_cb);
+ if (ret) {
+ pr_err("Unable to register clock notifier.\n");
+
[tip:timers/core] clocksource/drivers/sun5i: Switch to request_irq()
Commit-ID: 5673bc5a863bd4391eab5bb85277f0f1dd1dca50
Gitweb: http://git.kernel.org/tip/5673bc5a863bd4391eab5bb85277f0f1dd1dca50
Author: Maxime Ripard
AuthorDate: Tue, 31 Mar 2015 12:12:23 +0200
Committer: Ingo Molnar
CommitDate: Tue, 31 Mar 2015 17:53:57 +0200
clocksource/drivers/sun5i: Switch to request_irq()
The current code uses setup_irq(), while it could perfectly use
the much simpler request_irq(). Switch to that.
Signed-off-by: Maxime Ripard
Signed-off-by: Daniel Lezcano
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/1427796746-373-2-git-send-email-daniel.lezc...@linaro.org
Signed-off-by: Ingo Molnar
---
drivers/clocksource/timer-sun5i.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/clocksource/timer-sun5i.c
b/drivers/clocksource/timer-sun5i.c
index 58597fb..03f04d8 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -129,13 +129,6 @@ static irqreturn_t sun5i_timer_interrupt(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static struct irqaction sun5i_timer_irq = {
- .name = "sun5i_timer0",
- .flags = IRQF_TIMER | IRQF_IRQPOLL,
- .handler = sun5i_timer_interrupt,
- .dev_id = _clockevent,
-};
-
static void __init sun5i_timer_init(struct device_node *node)
{
struct reset_control *rstc;
@@ -181,7 +174,8 @@ static void __init sun5i_timer_init(struct device_node
*node)
clockevents_config_and_register(_clockevent, rate,
TIMER_SYNC_TICKS, 0x);
- ret = setup_irq(irq, _timer_irq);
+ ret = request_irq(irq, sun5i_timer_interrupt, IRQF_TIMER | IRQF_IRQPOLL,
+ "sun5i_timer0", _clockevent);
if (ret)
pr_warn("failed to setup irq %d\n", irq);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:timers/core] clocksource/drivers/sun5i: Use of_io_request_and_map()
Commit-ID: a45860d0ba433c217d359fa2cc2a4984d18ce263
Gitweb: http://git.kernel.org/tip/a45860d0ba433c217d359fa2cc2a4984d18ce263
Author: Maxime Ripard
AuthorDate: Tue, 31 Mar 2015 12:12:24 +0200
Committer: Ingo Molnar
CommitDate: Tue, 31 Mar 2015 17:53:58 +0200
clocksource/drivers/sun5i: Use of_io_request_and_map()
of_iomap doesn't do a request_mem_region() on the memory area
defined in the DT it maps. Switch to of_io_request_and_map() to
make sure we're the only users.
Signed-off-by: Maxime Ripard
Signed-off-by: Daniel Lezcano
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/1427796746-373-3-git-send-email-daniel.lezc...@linaro.org
Signed-off-by: Ingo Molnar
---
drivers/clocksource/timer-sun5i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-sun5i.c
b/drivers/clocksource/timer-sun5i.c
index 03f04d8..87f7b81 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -137,7 +137,7 @@ static void __init sun5i_timer_init(struct device_node
*node)
int ret, irq;
u32 val;
- timer_base = of_iomap(node, 0);
+ timer_base = of_io_request_and_map(node, 0, of_node_full_name(node));
if (!timer_base)
panic("Can't map registers");
--
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: msgrcv: use freezable blocking call
Hi Andrew, Thanks for making new patch, Actually there is some problem with our mail editor. It changes tabs with spaces and corrupts the patch, we are solving the same at our end. Thats why i am sending you signed -off by only for both patches. 1. For msgrcv: use freezable blocking call Signed-off-by: Yogesh Gaur Signed-off-by: Maninder Singh Signed-off-by: Manjeet Pawar Reviewed-by : Ajeet Yadav Cc: Peter Zijlstra Cc: Tejun Heo Signed-off-by: Andrew Morton 2. For restart_syscall: use freezable blocking call Signed-off-by: Yogesh Gaur Signed-off-by: Maninder Singh Signed-off-by: Amit Arora Reviewed-by : Ajeet Yadav Cc: Peter Zijlstra Cc: Tejun Heo Signed-off-by: Andrew Morton > For Peter's Review comment:- This is what, no why mentioned This call was selected to be converted to a freezable call because it doesn't hold any locks or release any resources when interrupted that might be needed by another freezing task or a kernel driver during suspend, and is a common site where idle userspace tasks are blocked. Thanks Maninder Singh Presumably Peter's review comments for "restart_syscall: use freezable blocking call" also apply here. Please send your signed-off-by: for both patches, as detailed in Documentation/SubmittingPatches section 11, thanks. From: Yogesh Gaur Subject: ipc/msg.c: use freezable blocking call Avoid waking up every thread sleeping in a msgrcv call during suspend and resume by calling a freezable blocking call. Previous patches modified the freezer to avoid sending wakeups to threads that are blocked in freezable blocking calls. Ref: https://lkml.org/lkml/2013/5/1/424 Backtrace: [] (__schedule+0x0/0x5d8) from [] (schedule+0x8c/0x90) [] (schedule+0x0/0x90) from [] (do_msgrcv+0x2e0/0x368) [] (do_msgrcv+0x0/0x368) from [] (SyS_msgrcv+0x2c/0x38) [] (SyS_msgrcv+0x0/0x38) from [] (ret_fast_syscall+0x0/0x48) tPlay0Cb2 R running 0 297204 0x0001 Signed-off-by: Yogesh Gaur Signed-off-by: Manjeet Pawar Reviewed-by : Ajeet Yadav Cc: Peter Zijlstra Cc: Tejun Heo Signed-off-by: Andrew Morton --- ipc/msg.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN ipc/msg.c~msgrcv-use-freezable-blocking-call ipc/msg.c --- a/ipc/msg.c~msgrcv-use-freezable-blocking-call +++ a/ipc/msg.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include @@ -915,7 +916,7 @@ long do_msgrcv(int msqid, void __user *b ipc_unlock_object(>q_perm); rcu_read_unlock(); - schedule(); + freezable_schedule(); /* Lockless receive, part 1: * Disable preemption. We don't hold a reference to the queue _
Re: [PATCH 19/25] sched: Use bool function return values of true/false not 1/0
On Mon, Mar 30, 2015 at 4:46 PM, Joe Perches wrote: > * try_wait_for_completion - try to decrement a completion without > blocking > * @x: completion structure > * > - * Return: 0 if a decrement cannot be done without blocking > - * 1 if a decrement succeeded. > + * Return: true if a decrement cannot be done without blocking > + * false if a decrement succeeded. Hi Joe, The boolean logic was reversed in this comment. The function should be returning false if a decrement cannot be done without blocking, and true if a decrement succeeded. -- 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] x86/numa: kernel stack corruption fix
Ccing Xishi Qiu who wrote the clear_kernel_node_hotplug code. On 04/01/15 at 12:53pm, Dave Young wrote: > I got below kernel panic during kdump test on Thinkpad T420 laptop: > > [0.00] No NUMA configuration found > > [0.00] Faking a node at [mem 0x-0x37ba4fff] > > [0.00] Kernel panic - not syncing: stack-protector: Kernel stack is > cor > upted in: 81d21910 > r > [0.00] > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0-rc6+ #44 > > [0.00] Hardware name: LENOVO 4236NUC/4236NUC, BIOS 83ET76WW (1.46 ) > 07/ > 5/2013 > 0 > [0.00] c70296ddd809e4f6 81b67ce8 > 817c > a26 > 2 > [0.00] 81a61c90 81b67d68 > 817b > 8d2 > c > [0.00] 0010 81b67d78 81b67d18 > c70296ddd809 > 4f6 > e > [0.00] Call Trace: > > [0.00] [] dump_stack+0x45/0x57 > > [0.00] [] panic+0xd0/0x204 > > [0.00] [] ? > numa_clear_kernel_node_hotplug+0xe6/0xf2 > [0.00] [] __stack_chk_fail+0x1b/0x20 > > [0.00] [] numa_clear_kernel_node_hotplug+0xe6/0xf2 > > [0.00] [] numa_init+0x1a5/0x520 > > [0.00] [] x86_numa_init+0x19/0x3d > > [0.00] [] initmem_init+0x9/0xb > > [0.00] [] setup_arch+0x94f/0xc82 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] ? printk+0x55/0x6b > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] start_kernel+0xe8/0x4d6 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] x86_64_start_reservations+0x2a/0x2c > > [0.00] [] x86_64_start_kernel+0x161/0x184 > > [0.00] ---[ end Kernel panic - not syncing: stack-protector: Kernel > sta > k is corrupted in: 81d21910 > c > [0.00] > > PANIC: early exception 0d rip 10:8105d2a6 error 7eb cr2 > 8800371dd00 > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0-rc6+ #44 > 0 > [0.00] Hardware name: LENOVO 4236NUC/4236NUC, BIOS 83ET76WW (1.46 ) > 07/ > 5/2013 > 0 > [0.00] c70296ddd809e4f6 81b67c60 > 817c > a26 > 2 > [0.00] 0096 81a61c90 81b67d68 > fff0 > 084 0a0d 0a00 > 0 > [0.00] Call Trace: > > [0.00] [] dump_stack+0x45/0x57 > > [0.00] [] early_idt_handler+0x90/0xb7 > > [0.00] [] ? native_irq_enable+0x6/0x10 > > [0.00] [] ? panic+0x1c3/0x204 > > [0.00] [] ? > numa_clear_kernel_node_hotplug+0xe6/0xf2 > [0.00] [] __stack_chk_fail+0x1b/0x20 > > [0.00] [] numa_clear_kernel_node_hotplug+0xe6/0xf2 > > [0.00] [] numa_init+0x1a5/0x520 > > [0.00] [] x86_numa_init+0x19/0x3d > > [0.00] [] initmem_init+0x9/0xb > > [0.00] [] setup_arch+0x94f/0xc82 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] ? printk+0x55/0x6b > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] start_kernel+0xe8/0x4d6 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] x86_64_start_reservations+0x2a/0x2c > > [0.00] [] x86_64_start_kernel+0x161/0x184 > > [0.00] RIP 0x46
Re: [E1000-devel] [net] Intel Wired LAN Driver Updates
From: Jeff Kirsher Date: Tue, 31 Mar 2015 21:27:53 -0700 > On Tue, 2015-03-31 at 19:19 -0700, Jeff Kirsher wrote: >> On Tue, 2015-03-31 at 13:22 -0400, David Miller wrote: >> > From: Jeff Kirsher >> > Date: Fri, 27 Mar 2015 16:04:10 -0700 >> > >> > > The following are changes since commit >> > dde93dfea53c72b07907d9e44a6e4b1545f6bdc4: >> > > cxgb4: Fix frame size warning for 32 bit arch >> > > and are available in the git repository at: >> > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue >> > master >> > > >> > > Jeff Kirsher (1): >> > > MAINTAINERS: Update Intel Wired Ethernet Driver info >> > >> > Looks great but it looks like nothing is pushed there? >> > >> > [davem@localhost net]$ git pull >> > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue >> > master >> > From git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue >> > * branchmaster -> FETCH_HEAD >> > Already up-to-date. >> > [davem@localhost net]$ >> >> Sorry, I forgot to scrub the cover letter to remove the "pull" info, >> since it was a single patch, I did not think it would require a >> "pull". :-) >> >> I can apply it to my net-queue tree, master branch if you need or want. > > I have gone ahead and pushed the patch to my net-queue tree for you to > pull. Pulled, thanks Jeff. -- 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] of: Custom printk format specifier for device node
On Tue, 2015-03-31 at 21:52 -0700, Grant Likely wrote: > Thinking about this more, I'd like to suggest a different format that > gives us a nice hack on the name that makes it easy to remember: > '%pOF[...]' > 'O' still means 'object', but it is also overloaded for Open Firmware. > That still leaves %pO? for other object types. What do you think? I think that's fine. -- 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 v2 0/5] arm64: kvm: reset hyp context for kexec
Marc On 03/31/2015 04:31 PM, Marc Zyngier wrote: On Tue, 31 Mar 2015 07:04:44 +0100 AKASHI Takahiro wrote: Hi Takahiro, Marc, On 03/30/2015 05:54 PM, AKASHI Takahiro wrote: On 03/30/2015 04:16 PM, Marc Zyngier wrote: On Mon, 30 Mar 2015 02:39:53 +0100 AKASHI Takahiro wrote: On 03/28/2015 02:40 AM, Kyle McMartin wrote: On Fri, Mar 27, 2015 at 03:37:04PM +, Marc Zyngier wrote: [ 236.260863] Kernel panic - not syncing: HYP panic: [ 236.260863] PS:63c9 PC:03ff0830 ESR:9606 It would be interesting if you could find out what you have at offset 0x830 of hyp-init.o (the stack trace is for EL1, and is not going to help much). Given the alignment, i'm going to assume i'm looking at the right thing: 0820 <__kvm_hyp_reset>: 820: d51c2000msr ttbr0_el2, x0 824: d5033fdfisb 828: d50c871ftlbialle2 82c: d5033f9fdsb sy 830: 1060adr x0, 83c <__kvm_hyp_reset+0x1c> 834: b3403c01bfxil x1, x0, #0, #16 838: d61f0020br x1 83c: d53c1000mrs x0, sctlr_el2 but it seems fairly implausible to be trapping on ADR x0, 1f... I've never seen this panic on fast model... ESR shows that - Exception class: Data abort taken without a change in Exception level - Data fault status code: Translation fault at EL2 and FAR seems not to be a proper address. ... which is consistent with what we're seeing here (data fault on something that doesn't generate a load/store). I'm pretty sure the page tables are screwed. Have you tested it with 64k pages? Hmm... It seems that I was able to reproduce the problem if 64k pages enabled. The entry address in trampoline code calc'ed by kvm_virt_to_trampoline(__kvm_hyp_reset) seems to be wrong due to improper page-alignment in hyp-init.S. The following patch fixed this problem, at least, in my environment(fast model). (I don't know why it's PAGE_SHIFT - 1, not PAGE_SHIFT.) >diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S >index d212990..45b8d98 100644 >--- a/arch/arm64/kvm/hyp-init.S >+++ b/arch/arm64/kvm/hyp-init.S >@@ -24,7 +24,7 @@ >.text >.pushsection.hyp.idmap.text, "ax" > >- .align 11 >+ .align (PAGE_SHIFT - 1) I'm afraid this is wrong. This alignment is for the vectors (which have to be aligned on a 2kB boundary, hence the ".align 11"), not for the code. Aligning it on a 32kB boundary doesn't make any sense, and just hides the bug. I bet that without this hack, the hyp-init code is spread across two 64kB pages, and the kernel generates a bounce page for this code. By changing the alignment, you just end up having the code to fit in a single page, and no bounce page gets generated. There seem to be two scenarios that make things go wrong: 1) As you mentioned above, trampoline code is spread across page boundary even though the whole size is less than a page. 2) The whole trampoline code fits into a single page, but the physical start address of this region (that is, __hyp_idmap_text_start) is not page-aligned. In this case, pa of __kvm_hyp_reset should also be offset. Given any combinations of #1 and #2, __kvm_virt_to_trampoline() would get a bit complicated. If I'm right above the above, it means that you're computing something against the wrong base. Can you please verify this scenario? Now, the good news is that Ard is removing the bounce page from the KVM code (for unrelated reasons), and this may just be the saving grace. Ard's patch will fix #1, but not #2. So I modified __kvm_virt_to_trampoline as followed and it seems to work well both on 4k-page kernel and 64k-page kernel (in addition to Ard's patch). But please note that Ard's patch already makes __hyp_idmap_text_start 4kb-aligned. So why not PAGE_SIZE-aligned as my previous patch does? >diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h >index c191432..facfd6d 100644 >--- a/arch/arm64/include/asm/kvm_mmu.h >+++ b/arch/arm64/include/asm/kvm_mmu.h >@@ -308,7 +308,9 @@ void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled); > > extern char __hyp_idmap_text_start[]; > #define kvm_virt_to_trampoline(x) \ >- (TRAMPOLINE_VA + ((x) - __hyp_idmap_text_start)) >+ (TRAMPOLINE_VA \ >+ + ((unsigned long)(x) \ >+ - ((unsigned long)__hyp_idmap_text_start & PAGE_MASK))) > > #endif /* __ASSEMBLY__ */ > #endif /* __ARM64_KVM_MMU_H__ */ > > ENTRY(__kvm_hyp_init) >ventry __invalid // Synchronous EL2t After applying this patch, I got another problem with kexec-tools on 64k page kernel, but I've already modified kexec-tools. The idea that userspace behavior is dependent on the kernel page size is deeply worrying... The logic is
Re: [PATCH 1/2] kernel/reboot.c: Add orderly_reboot for graceful reboot
On 04/01/2015 08:47 AM, Joel Stanley wrote: > Hi Andrew, > > On Wed, Apr 1, 2015 at 9:09 AM, Andrew Morton > wrote: >> > On Mon, 30 Mar 2015 12:45:32 +1030 Joel Stanley wrote: >> > >>> >> The kernel has orderly_poweroff which allows the kernel to initiate a >>> >> graceful shutdown of userspace, by running /sbin/poweroff. This adds >>> >> orderly_reboot that will cause userspace to shut itself down by calling >>> >> /sbin/reboot. >>> >> >>> >> This will be used for shutdown initiated by a system controller on >>> >> platforms that do not use ACPI. >> > >> > gee. There are a lot of callers of emergency_restart(). Why is the >> > BMC reboot special, and how many of the emergency_restart() callers >> > really be using orderly_reboot()? > The BMC reboot is intended to be a graceful shutdown - let userspace > do it's thing before the system goes down. > > Userspace may chose to stop and perform some long, slow teardown > before it gets around to shutting down. We don't want to move callers > over orderly_reboot() if they're shutting the system down due to a > critical failure, eg. printer on fire. > > I had a read of the emergency_restart() callers and I didn't see any > obvious cases for moving over to orderly_reboot(). > >> > We have /proc/sys/kernel/poweroff_cmd. Should we have >> > /proc/sys/kernel/reboot_cmd as well? If not, >> > kernel/reboot.c:reboot_cmd[] can be made static ;) > I don't think we need it. I'll make reboot_cmd[] static. Just to have parity with power off command, /proc/sys/kernel/reboot_cmd would be nice to have. -- 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] kernel/reboot.c: Add orderly_reboot for graceful reboot
On Tue, 31 Mar 2015 22:03:26 -0700 Andrew Morton wrote: > static char reboot_cmd[] = "/sbin/reboot"; static const char, actually. -- 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] kernel/reboot.c: Add orderly_reboot for graceful reboot
On Wed, 01 Apr 2015 10:22:08 +0530 Anshuman Khandual wrote: > > char poweroff_cmd[POWEROFF_CMD_PATH_LEN] = "/sbin/poweroff"; > > +char reboot_cmd[POWEROFF_CMD_PATH_LEN] = "/sbin/reboot"; > > Should not we declare one more REBOOT_CMD_PATH_LEN to make it cleaner. It doesn't really seem necessary - they'll have the same value anyway. But if you aren't going to implement the sysctl it isn't needed at all - just do static char reboot_cmd[] = "/sbin/reboot"; -- 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] of: Custom printk format specifier for device node
On Tue, 31 Mar 2015 13:03:05 +0300 , Pantelis Antoniou wrote: > > +Device tree nodes: > > + > > + %pOn[fnpPcCFr] > > + > > + For printing device tree nodes. The optional arguments are: > > + f device node full_name > > + n device node name > > + p device node phandle > > + P device node path spec (name + @unit) > > + F device node flags > > + c major compatible string > > + C full compatible string > > + Without any arguments prints full_name (same as %pOnf) > > + The separator when using multiple arguments is â:â > ^ separator is â.' > > + > > > + Examples: > > + > > + %pOn/foo/bar@0 - Node full name > > + %pOnf /foo/bar@0 - Same as above > > + %pOnfp /foo/bar@0:10 - Node full name + phandle > > + %pOnfcF /foo/bar@0:foo,device:--P- - Node full name + > > + major compatible string + > > + node flags > > + D - dynamic > > + d - detached > > + P - Populated > > + B - Populated bus > > + Thinking about this more, I'd like to suggest a different format that gives us a nice hack on the name that makes it easy to remember: '%pOF[...]' 'O' still means 'object', but it is also overloaded for Open Firmware. That still leaves %pO? for other object types. What do you think? g. -- 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] [SMB3] Fix dereference before null check warning
On Tue, Mar 31, 2015 at 7:46 PM, Jeff Layton wrote:
> On Fri, 27 Mar 2015 00:28:01 -0500
> Steve French wrote:
>
>> null tcon is not likely in these paths in current
>> code, but obviously it does clarify the code to
>> check for null (if at all) before derefrencing
>> rather than after.
>>
>> Reported by Coverity (CID 1042666)
>>
>> Signed-off-by: Steve French
>
> I don't get it. Under what circumstances would the tcon ever be NULL
> here? If there aren't any then this is just confusing. It would be
> better to just remove the bogus checks for a NULL tcon instead.
I don't think it really matters much one way or another but I agree it
would be a bug to pass in a null tcon to SMB2_ioctl.
On the other hand ... if there are any paths where tcon might be null
(other than SessionSetup and NegProt and TCon itself) due to bug,
SMB2/SMB3 ioctl/fsctl would be the one since there are various strange
operations (such as security related calls such as validate negotiate
for example) that either call it now or will need to call it as
additional SMB2/SMB3 ioctls are added. I didn't see any harm in
checking for null tcon, although clearly passing in a null tcon would
be a bug - this is one code path where I don't mind checking since
there are some counterintuitive things which SMB2 ioctl/fsctl protocol
operations do.
>> ---
>> fs/cifs/smb2pdu.c | 13 -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
>> index 1b906de..78b329f 100644
>> --- a/fs/cifs/smb2pdu.c
>> +++ b/fs/cifs/smb2pdu.c
>> @@ -1218,7 +1218,7 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon
>> *tcon, u64 persistent_fid,
>> struct smb2_ioctl_req *req;
>> struct smb2_ioctl_rsp *rsp;
>> struct TCP_Server_Info *server;
>> - struct cifs_ses *ses = tcon->ses;
>> + struct cifs_ses *ses;
>> struct kvec iov[2];
>> int resp_buftype;
>> int num_iovecs;
>> @@ -1233,6 +1233,11 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon
>> *tcon, u64 persistent_fid,
>> if (plen)
>> *plen = 0;
>>
>> + if (tcon)
>> + ses = tcon->ses;
>> + else
>> + return -EIO;
>> +
>> if (ses && (ses->server))
>> server = ses->server;
>> else
>> @@ -1296,14 +1301,12 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon
>> *tcon, u64 persistent_fid,
>> rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
>>
>> if ((rc != 0) && (rc != -EINVAL)) {
>> - if (tcon)
>> - cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
>> + cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
>> goto ioctl_exit;
>> } else if (rc == -EINVAL) {
>> if ((opcode != FSCTL_SRV_COPYCHUNK_WRITE) &&
>> (opcode != FSCTL_SRV_COPYCHUNK)) {
>> - if (tcon)
>> - cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
>> + cifs_stats_fail_inc(tcon, SMB2_IOCTL_HE);
>> goto ioctl_exit;
>> }
>> }
>
>
--
Thanks,
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: [LKP] [Btrfs] 3a8b36f3780: -62.6% fileio.requests_per_sec
On Tue, 2015-03-31 at 15:59 +0100, Filipe Manana wrote:
[snip]
> From: Filipe Manana
> Date: Tue, 31 Mar 2015 14:16:52 +0100
> Subject: [PATCH] Btrfs: avoid syncing log in the fast fsync path when not
> necessary
>
> Commit 3a8b36f37806 ("Btrfs: fix data loss in the fast fsync path") added
> a performance regression for that causes an unnecessary sync of the log
> trees (fs/subvol and root log trees) when 2 consecutive fsyncs are done
> against a file, without no writes or any metadata updates to the inode in
> between them and if a transaction is committed before the second fsync is
> called.
>
> Huang Ying reported this to lkml after a test sysbench test that measured
> a -62% decrease of file io requests for that tests' workload.
>
> The test is:
>
> echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
> echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
> mkfs -t btrfs /dev/sda2
> mount -t btrfs /dev/sda2 /fs/sda2
> cd /fs/sda2
> for ((i = 0; i < 1024; i++)); do fallocate -l 67108864 testfile.$i; done
> sysbench --test=fileio --max-requests=0 --num-threads=4 --max-time=600 \
> --file-test-mode=rndwr --file-total-size=68719476736 --file-io-mode=sync \
> --file-num=1024 run
>
> A test on kvm guest, running a debug kernel gave me the following results:
>
> Without 3a8b36f378060d: 16.01 reqs/sec
> With 3a8b36f378060d: 3.39 reqs/sec
> With 3a8b36f378060d and this patch: 16.04 reqs/sec
>
> Reported-by: Huang Ying
I have tested your patch, the regression restored in our test. Thanks!
Tested-by: Huang, Ying
Best Regards,
Huang, Ying
[snip]
--
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] MIPS: IP32: Add platform data hooks to use DS1685 driver
On 03/31/2015 06:56, Ralf Baechle wrote:
> On Thu, Feb 26, 2015 at 09:23:50PM -0500, Joshua Kinard wrote:
>
>> This modifies the IP32 (SGI O2) platform and reset code to utilize the new
>> rtc-ds1685 driver. The old mc146818rtc.h header is removed and
>> ip32_defconfig
>> is updated as well.
>
> In general - good cleanup. But:
>
>> index 511e9ff..ec9eb7f 100644
>> --- a/arch/mips/sgi-ip32/ip32-platform.c
>> +++ b/arch/mips/sgi-ip32/ip32-platform.c
> [...]
>> MODULE_AUTHOR("Ralf Baechle ");
>> MODULE_LICENSE("GPL");
>> -MODULE_DESCRIPTION("8250 UART probe driver for SGI IP32 aka O2");
>> +MODULE_DESCRIPTION("IP32 platform setup for SGI IP32 aka O2");
>
> This isn't even a kernel module so I've just nuked all these MODULE_*
> calls.
Works for me, thanks!
>> diff --git a/arch/mips/sgi-ip32/ip32-reset.c
>> b/arch/mips/sgi-ip32/ip32-reset.c
>> index 44b3470..ef21706 100644
>> --- a/arch/mips/sgi-ip32/ip32-reset.c
>> +++ b/arch/mips/sgi-ip32/ip32-reset.c
> [...]
>> -static void ip32_machine_restart(char *cmd)
>> +static __noreturn void ip32_poweroff(void *data)
>> {
>> -crime->control = CRIME_CONTROL_HARD_RESET;
>> -while (1);
>> -}
>> +void (*poweroff_func)(struct platform_device *) =
>> +symbol_get(ds1685_rtc_poweroff);
>> +
>> +#ifdef CONFIG_MODULES
>> +/* If the first __symbol_get failed, our module wasn't loaded. */
>> +if (!poweroff_func) {
>> +request_module("rtc-ds1685");
>> +poweroff_func = symbol_get(ds1685_rtc_poweroff);
>> +}
>> +#endif
>
> symbol_get() calls are high on my list of items that indicate a piece of
> code is probably ill-structured.
That was the only function I could find that would attempt to fetch the
ds1685_rtc_poweroff() function from kernel memory and return an indication of
success or failure that could be checked. If there's a better way to do that,
I'll be happy to re-write that section. I looked through the docs back then
and couldn't find another way that worked with and without modules.
> While RTCs often deal with power the RTC really only wants to deal with
> time and so power stuff should rather go elsewhere. I suggest to take a
> look at drivers/power/reset/. A small driver there could set pm_power_off
> approriately. drivers/power/reset/restart-poweroff.c is a very compact
> example.
Except this code is in a file called "ip32-reset.c", and the original code
there did the exact same thing -- powered off the machine. The
ds1685_rtc_poweroff() function is defined in the core DS1685 driver
(drivers/rtc/rtc-ds1685.c) that got added to linux-next a few weeks ago (no one
had any complaints about that). This code just checks to see if the RTC driver
is loaded and then calls that function to power the machine down.
IP30 uses a similar setup as well, since both machines share the same RTC
chip/family.
>> @@ -190,15 +141,12 @@ static __init int ip32_reboot_setup(void)
>>
>> _machine_restart = ip32_machine_restart;
>> _machine_halt = ip32_machine_halt;
>> -pm_power_off = ip32_machine_power_off;
>> +pm_power_off = ip32_machine_halt;
>
> So halt and power_off no do the same?
>
They always did. This is the original ip32_machine_halt function:
static inline void ip32_machine_halt(void)
{
ip32_machine_power_off();
}
I just got rid of the added level of misdirection and set both _machine_halt
and pm_power_off to call the same function (especially since there's no
sleeping these kinds of machines -- maybe hibernate, but that'll still properly
poweroff). Seemed the logical thing to do. In either case, it'll lead to the
RTC driver handling the poweroff routine, which seems to be the only way SGI
designed these machines to power off. I'll wager the ARCS firmware internally
does the same thing.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
--
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] x86/numa: kernel stack corruption fix
I got below kernel panic during kdump test on Thinkpad T420 laptop: [0.00] No NUMA configuration found [0.00] Faking a node at [mem 0x-0x37ba4fff] [0.00] Kernel panic - not syncing: stack-protector: Kernel stack is cor upted in: 81d21910 r [0.00] [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0-rc6+ #44 [0.00] Hardware name: LENOVO 4236NUC/4236NUC, BIOS 83ET76WW (1.46 ) 07/ 5/2013 0 [0.00] c70296ddd809e4f6 81b67ce8 817c a262 [0.00] 81a61c90 81b67d68 817b 8d2c [0.00] 0010 81b67d78 81b67d18 c70296ddd809 4f6e [0.00] Call Trace: [0.00] [] dump_stack+0x45/0x57 [0.00] [] panic+0xd0/0x204 [0.00] [] ? numa_clear_kernel_node_hotplug+0xe6/0xf2 [0.00] [] __stack_chk_fail+0x1b/0x20 [0.00] [] numa_clear_kernel_node_hotplug+0xe6/0xf2 [0.00] [] numa_init+0x1a5/0x520 [0.00] [] x86_numa_init+0x19/0x3d [0.00] [] initmem_init+0x9/0xb [0.00] [] setup_arch+0x94f/0xc82 [0.00] [] ? early_idt_handlers+0x120/0x120 [0.00] [] ? printk+0x55/0x6b [0.00] [] ? early_idt_handlers+0x120/0x120 [0.00] [] start_kernel+0xe8/0x4d6 [0.00] [] ? early_idt_handlers+0x120/0x120 [0.00] [] ? early_idt_handlers+0x120/0x120 [0.00] [] x86_64_start_reservations+0x2a/0x2c [0.00] [] x86_64_start_kernel+0x161/0x184 [0.00] ---[ end Kernel panic - not syncing: stack-protector: Kernel sta k is corrupted in: 81d21910c [0.00] PANIC: early exception 0d rip 10:8105d2a6 error 7eb cr2 8800371dd00 [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0-rc6+ #44 0 [0.00] Hardware name: LENOVO 4236NUC/4236NUC, BIOS 83ET76WW (1.46 ) 07/ 5/2013 0 [0.00] c70296ddd809e4f6 81b67c60 817c a262 [0.00] 0096 81a61c90 81b67d68 fff0 084 0a0d 0a00 0 [0.00] Call Trace: [0.00] [] dump_stack+0x45/0x57 [0.00] [] early_idt_handler+0x90/0xb7 [0.00] [] ? native_irq_enable+0x6/0x10 [0.00] [] ? panic+0x1c3/0x204 [0.00] [] ? numa_clear_kernel_node_hotplug+0xe6/0xf2 [0.00] [] __stack_chk_fail+0x1b/0x20 [0.00] [] numa_clear_kernel_node_hotplug+0xe6/0xf2 [0.00] [] numa_init+0x1a5/0x520 [0.00] [] x86_numa_init+0x19/0x3d [0.00] [] initmem_init+0x9/0xb [0.00] [] setup_arch+0x94f/0xc82 [0.00] [] ? early_idt_handlers+0x120/0x120 [0.00] [] ? printk+0x55/0x6b [0.00] [] ? early_idt_handlers+0x120/0x120 [0.00] [] start_kernel+0xe8/0x4d6 [0.00] [] ? early_idt_handlers+0x120/0x120 [0.00] [] ? early_idt_handlers+0x120/0x120 [0.00] [] x86_64_start_reservations+0x2a/0x2c [0.00] [] x86_64_start_kernel+0x161/0x184 [0.00] RIP 0x46 This is caused by writing over end of numa mask bitmap. numa_clear_kernel_node try to set node id in a mask bitmap, it iterating all reserved region and assume every regions have valid nid. It is not true because There's an exception for graphic memory quirks. see function trim_snb_memory in arch/x86/kernel/setup.c It is easily to reproduce the bug in kdump kernel because kdump kernel
Re: [PATCH 1/2] kernel/reboot.c: Add orderly_reboot for graceful reboot
On 03/30/2015 07:45 AM, Joel Stanley wrote:
> The kernel has orderly_poweroff which allows the kernel to initiate a
> graceful shutdown of userspace, by running /sbin/poweroff. This adds
> orderly_reboot that will cause userspace to shut itself down by calling
> /sbin/reboot.
>
> This will be used for shutdown initiated by a system controller on
> platforms that do not use ACPI.
>
> Signed-off-by: Joel Stanley
> ---
> include/linux/reboot.h | 1 +
> kernel/reboot.c| 51
> +++---
> 2 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/reboot.h b/include/linux/reboot.h
> index 48bf152..a4ffcd9 100644
> --- a/include/linux/reboot.h
> +++ b/include/linux/reboot.h
> @@ -68,6 +68,7 @@ void ctrl_alt_del(void);
> extern char poweroff_cmd[POWEROFF_CMD_PATH_LEN];
>
> extern int orderly_poweroff(bool force);
> +extern int orderly_reboot(void);
>
> /*
> * Emergency restart, callable from an interrupt handler.
> diff --git a/kernel/reboot.c b/kernel/reboot.c
> index a3a9e24..d0aa1ec 100644
> --- a/kernel/reboot.c
> +++ b/kernel/reboot.c
> @@ -306,8 +306,9 @@ void ctrl_alt_del(void)
> }
>
> char poweroff_cmd[POWEROFF_CMD_PATH_LEN] = "/sbin/poweroff";
> +char reboot_cmd[POWEROFF_CMD_PATH_LEN] = "/sbin/reboot";
Should not we declare one more REBOOT_CMD_PATH_LEN to make it cleaner.
>
> -static int __orderly_poweroff(bool force)
> +static int run_cmd(const char *cmd)
> {
> char **argv;
> static char *envp[] = {
> @@ -316,8 +317,7 @@ static int __orderly_poweroff(bool force)
> NULL
> };
> int ret;
> -
> - argv = argv_split(GFP_KERNEL, poweroff_cmd, NULL);
> + argv = argv_split(GFP_KERNEL, cmd, NULL);
> if (argv) {
> ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
> argv_free(argv);
> @@ -325,8 +325,33 @@ static int __orderly_poweroff(bool force)
> ret = -ENOMEM;
> }
>
> + return ret;
> +}
> +
> +static int __orderly_reboot(void)
> +{
> + int ret;
> +
> + ret = run_cmd(reboot_cmd);
> +
> + if (ret) {
> + pr_warn("Failed to start orderly reboot: forcing the issue\n");
> + emergency_sync();
> + kernel_restart(NULL);
> + }
> +
> + return ret;
> +}
> +
> +static int __orderly_poweroff(bool force)
> +{
> + int ret;
> +
> + ret = run_cmd(reboot_cmd);
Would it be poweroff_cmd instead of reboot_cmd ? Dont see poweroff_cmd getting
used.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [net][resubmit] MAINTAINERS: Update Intel Wired Ethernet Driver info
On Tue, 2015-03-31 at 21:42 -0700, Jeff Kirsher wrote: > Update the git tree info with a recent change in tree names. Also > add our new mailing list created solely for Linux kernel patches > and kernel development, as well as the new patchwork project for > tracking patches. Lastly update the list of "reviewers" since a > couple of developers have moved on to different projects. > > Made an update to the section header so that it is more manageable > going forward as we add new drivers. > > Signed-off-by: Jeff Kirsher > --- > MAINTAINERS | 25 - > 1 file changed, 12 insertions(+), 13 deletions(-) This time I have also pushed this to my net-queue kernel.org tree, if you want to do a pull of this patch. :-) signature.asc Description: This is a digitally signed message part
[net][resubmit] MAINTAINERS: Update Intel Wired Ethernet Driver info
Update the git tree info with a recent change in tree names. Also add our new mailing list created solely for Linux kernel patches and kernel development, as well as the new patchwork project for tracking patches. Lastly update the list of "reviewers" since a couple of developers have moved on to different projects. Made an update to the section header so that it is more manageable going forward as we add new drivers. Signed-off-by: Jeff Kirsher --- MAINTAINERS | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 358eb01..9508870 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5128,22 +5128,21 @@ M: Deepak Saxena S: Maintained F: drivers/char/hw_random/ixp4xx-rng.c -INTEL ETHERNET DRIVERS (e100/e1000/e1000e/fm10k/igb/igbvf/ixgb/ixgbe/ixgbevf/i40e/i40evf) +INTEL ETHERNET DRIVERS M: Jeff Kirsher -M: Jesse Brandeburg -M: Bruce Allan -M: Carolyn Wyborny -M: Don Skidmore -M: Greg Rose -M: Matthew Vick -M: John Ronciak -M: Mitch Williams -M: Linux NICS -L: e1000-de...@lists.sourceforge.net +R: Jesse Brandeburg +R: Shannon Nelson +R: Carolyn Wyborny +R: Don Skidmore +R: Matthew Vick +R: John Ronciak +R: Mitch Williams +L: intel-wired-...@lists.osuosl.org W: http://www.intel.com/support/feedback.htm W: http://e1000.sourceforge.net/ -T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git -T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git +Q: http://patchwork.ozlabs.org/project/intel-wired-lan/list/ +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git S: Supported F: Documentation/networking/e100.txt F: Documentation/networking/e1000.txt -- 1.9.3 -- 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/RFT, RESEND] powerpc: move cacheinfo sysfs to generic cacheinfo infrastructure
On Tue, 2015-03-31 at 18:14 +0100, Sudeep Holla wrote:
>
> On 31/03/15 11:56, Michael Ellerman wrote:
> > On Mon, 2015-23-02 at 18:18:20 UTC, Sudeep Holla wrote:
> >> This patch removes the redundant sysfs cacheinfo code by reusing
> >> the newly introduced generic cacheinfo infrastructure through the
> >> commit 246246cbde5e ("drivers: base: support cpu cache information
> >> interface to userspace via sysfs")
>
> > Removing the include doesn't fix it, it needs cacheinfo_cpu_on/offline().
> >
>
> I agree, had a quick look at that, and it requires some rework not sure
> if that should be in generic code or ppc specific.
Yeah OK.
Also if I just remove the references from the suspend code, it still causes
changes to the result, some of which look wrong:
--- cpu0.before 2015-04-01 15:34:58.985470973 +1100
+++ cpu0.after-no-power 2015-04-01 15:36:31.313435304 +1100
@@ -3,22 +3,24 @@
./cpu0/cache/index0/level:1
./cpu0/cache/index0/number_of_sets:8
./cpu0/cache/index0/shared_cpu_map:,00ff
+./cpu0/cache/index0/shared_cpu_list:0-7<- additional, OK
./cpu0/cache/index0/coherency_line_size:128
./cpu0/cache/index0/ways_of_associativity:64
-./cpu0/cache/index1/size:32K <- we lost the size of
the Icache?
./cpu0/cache/index1/type:Instruction
./cpu0/cache/index1/level:1
-./cpu0/cache/index1/number_of_sets:4 }-.
-./cpu0/cache/index1/shared_cpu_map:,00ff .
-./cpu0/cache/index1/coherency_line_size:128 . These changes are
no good
-./cpu0/cache/index1/ways_of_associativity:64 .
+./cpu0/cache/index1/shared_cpu_map:, .
+./cpu0/cache/index1/shared_cpu_list:0-47 }-
./cpu0/cache/index2/size:512K
./cpu0/cache/index2/type:Unified
./cpu0/cache/index2/level:2
./cpu0/cache/index2/number_of_sets:8
./cpu0/cache/index2/shared_cpu_map:,00ff
+./cpu0/cache/index2/shared_cpu_list:0-7<- additional, OK
+./cpu0/cache/index2/ways_of_associativity:0<- this is new but
wrong I think
./cpu0/cache/index3/size:8192K
./cpu0/cache/index3/type:Unified
./cpu0/cache/index3/level:3
./cpu0/cache/index3/number_of_sets:8
./cpu0/cache/index3/shared_cpu_map:,00ff
+./cpu0/cache/index3/shared_cpu_list:0-7
+./cpu0/cache/index3/ways_of_associativity:0<- ditto
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Enhancements to twl4030 phy to support better charging - V2
On Thu, 26 Mar 2015 05:29:42 +0530 Kishon Vijay Abraham I wrote: > Hi NeilBrown, > > On Thursday 26 March 2015 02:52 AM, NeilBrown wrote: > > On Thu, 26 Mar 2015 02:46:32 +0530 Kishon Vijay Abraham I > > wrote: > > > >> Hi, > >> > >> On Monday 23 March 2015 04:05 AM, NeilBrown wrote: > >>> Hi Kishon, > >>> I wonder if you could queue the following for the next merge window. > >>> They allow the twl4030 phy to provide more information to the > >>> twl4030 battery charger. > >>> There are only minimal changes since the first version, particularly > >>> documentation has been improved. > >> > >> There are quite a few things in this series which use the USB PHY library > >> interface which is kindof deprecated. We should try and use the Generic PHY > >> library for all of them. It would also be better to add features to the > >> PHY framework if the we can't achieve something with the existing PHY > >> framework. > > > > Hi, > > are you able to more specific at all? What is the "USB PHY library"? > > Where exactly is the "PHY framework"? > > There is a USB PHY library that exists in drivers/usb/phy/phy.c and there is > a Generic PHY framework that is present in drivers/phy/phy-core.c. twl4030 > actually supports both the framework. > > In your patch whatever uses struct usb_phy uses the old USB PHY library and > whatever uses struct phy uses the generic PHY framework. (Actually your patch > does not use the PHY framework at all). We want to deprecate using the USB PHY > library and make everyone use the generic PHY framework. Adding features > to a driver using the USB PHY library will make the transition to generic PHY > framework a bit more difficult. > > Now all the features that is supported in the USB PHY library may not be > supported by the PHY framework. So we should start extending the PHY framework > instead of using the USB PHY library. > > One think I noticed in your driver is using atomic notifier chain. IMO extcon > framework should be used in twl4030 USB driver to notify the controller driver > instead of using USB PHY notifier. For all other things we have to see if it > can be added in the PHY framework. I've had a look at the code with these issues in mind, and there is one issue that I'm not sure about. In phy-twl4030-usb, the usb_phy is used to hold a reference to the 'struct otg', and for passing cable state changes to the notifier. The former probably has to stay until musb can keep a reference to the otg, separate form the usb_phy. The latter can be changed to use extcon - to some extent. I actually have patches to do that from a couple of years back, but I never proceeded with them. The problem is that one thing that needs to be communicated to the charger is the max current that was negotiated by a "Standard Downstream Port". This could be 500mA from a powered hum, or much less from an unpowered hub. (Currently the usb gadget code does negotiated between different possibilities, but it could and hopefully will one day). With the notifier chain there is an easy way to communicate the allowed current once it is negotiated. e.g. ab8500_usb_set_power() does this. 'struct phy' has no equivalent of the 'set_power' callback which 'struct usb_phy' provides, and extcon has no mechanism (that I can see) for communicating a number - just binary cable states. Presumably a 'set_power' method could be added to 'struct phy' so the usb-core can communicate the number to the phy, but it is not clear to me how the 'phy' can communicate it to the charger. The 'phy' could provide an API to request the current negotiated max current, but there still needs to be a way to let the charger know that this has changed. That could in theory be done via extcon, by having a secondary 'USB_connected' cable type, but it isn't really a cable type and pretending that it is seems wrong. Any suggestions? Thanks, NeilBrown pgpt3D7bQI9Wv.pgp Description: OpenPGP digital signature
Re: [PATCH] Revert "drm/i915: Performed deferred clflush inside set-cache-level"
On Tue, Mar 31, 2015 at 04:35:49PM +0100, Chris Wilson wrote: > On Tue, Mar 31, 2015 at 08:40:12PM +0530, Sudip Mukherjee wrote: > > This reverts commit <0f71979ab7fbd0c71c41c2798de3d33937915434>. > > > > my display was getting garbled for a moment very frequently. it looked > > like when the screen was getting refreshed then something was going > > wrong. > > git bisect gave this as the first bad commit, and after reverting it > > now display is not having that problem. > > Hmm, I fear you would be just papering over a bug. Could you please file > a bug on bugs.freedesktop.org so that we can root cause this? > -Chris filed at https://bugs.freedesktop.org/show_bug.cgi?id=89857 since this patch workes perfectly for me, i guess i need to apply it to every new release till you are able to root cause and fix it. regards sudip > > -- > Chris Wilson, Intel Open Source Technology Centre -- 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] Staging: rtl8192u Make function static
On Wed, Apr 01, 2015 at 09:09:26AM +0530, Sudip Mukherjee wrote: > On Tue, Mar 31, 2015 at 05:51:19PM -0600, Eddie Kovsky wrote: > > Changing function definition to static fixes the > > following warning generated by sparse: > > > > drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:1924:6: warning: > > symbol 'ieee80211_check_auth_response' was not declared. Should it be > > static? > > some one has already done this and it has been already applied to > staging-testing. > > regards > sudip > Yes, I see that now. I thought I was already tracking that branch. I'm sorry for the noise. Eddie -- 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: [E1000-devel] [net] Intel Wired LAN Driver Updates
On Tue, 2015-03-31 at 19:19 -0700, Jeff Kirsher wrote: > On Tue, 2015-03-31 at 13:22 -0400, David Miller wrote: > > From: Jeff Kirsher > > Date: Fri, 27 Mar 2015 16:04:10 -0700 > > > > > The following are changes since commit > > dde93dfea53c72b07907d9e44a6e4b1545f6bdc4: > > > cxgb4: Fix frame size warning for 32 bit arch > > > and are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue > > master > > > > > > Jeff Kirsher (1): > > > MAINTAINERS: Update Intel Wired Ethernet Driver info > > > > Looks great but it looks like nothing is pushed there? > > > > [davem@localhost net]$ git pull > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue > > master > > From git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue > > * branchmaster -> FETCH_HEAD > > Already up-to-date. > > [davem@localhost net]$ > > Sorry, I forgot to scrub the cover letter to remove the "pull" info, > since it was a single patch, I did not think it would require a > "pull". :-) > > I can apply it to my net-queue tree, master branch if you need or want. I have gone ahead and pushed the patch to my net-queue tree for you to pull. signature.asc Description: This is a digitally signed message part
Re: [PATCH] add generic callbacks into compaction
2015-04-01 오후 12:46에 Hillf Danton 이(가) 쓴 글:
I sent a patch about page allocation for less fragmentation.
http://permalink.gmane.org/gmane.linux.kernel.mm/130599
It proposes a page allocator allocates pages in the same pageblock
for the drivers to move their unmovable pages. Some drivers which comsumes many
pages
and increases system fragmentation use the allocator to move their pages to
decrease fragmentation.
I think I can try another approach.
There is a compaction code for balloon pages.
But the compaction code cannot migrate pages of other drivers.
If there is a generic migration framework applicable to any drivers,
drivers can register their migration functions.
And the compaction can migrate movable pages and also driver's pages.
I'm not familiar with virtualization so I couldn't test this patch yet.
A RFC, no?
YES, this is a RFC. It's my fault. I'm sorry.
But if mm developers agree with this approach, I will complete this patch.
I would do appreciate any feedback.
Signed-off-by: Gioh Kim
---
drivers/virtio/virtio_balloon.c|2 ++
include/linux/balloon_compaction.h | 23 +---
include/linux/fs.h |3 ++
include/linux/pagemap.h| 26 ++
mm/balloon_compaction.c| 68 ++--
mm/compaction.c|7 ++--
mm/migrate.c | 24 ++---
7 files changed, 129 insertions(+), 24 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 0413157..cd9b8e4 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -486,6 +486,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
balloon_devinfo_init(>vb_dev_info);
#ifdef CONFIG_BALLOON_COMPACTION
+ vb->vb_dev_info.mapping = balloon_mapping_alloc(>vb_dev_info,
+ _aops);
vb->vb_dev_info.migratepage = virtballoon_migratepage;
#endif
diff --git a/include/linux/balloon_compaction.h
b/include/linux/balloon_compaction.h
index 9b0a15d..0af32b3 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -62,6 +62,7 @@ struct balloon_dev_info {
struct list_head pages; /* Pages enqueued & handled to Host */
int (*migratepage)(struct balloon_dev_info *, struct page *newpage,
struct page *page, enum migrate_mode mode);
+ struct address_space *mapping;
Better if a comment line is added.
I got it.
};
extern struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info);
@@ -76,10 +77,22 @@ static inline void balloon_devinfo_init(struct
balloon_dev_info *balloon)
}
#ifdef CONFIG_BALLOON_COMPACTION
-extern bool balloon_page_isolate(struct page *page);
-extern void balloon_page_putback(struct page *page);
-extern int balloon_page_migrate(struct page *newpage,
- struct page *page, enum migrate_mode mode);
+extern const struct address_space_operations balloon_aops;
+extern int balloon_page_isolate(struct page *page);
+extern int balloon_page_putback(struct page *page);
+extern int balloon_page_migrate(struct address_space *mapping,
+ struct page *newpage,
+ struct page *page,
+ enum migrate_mode mode);
+
+extern struct address_space
+*balloon_mapping_alloc(struct balloon_dev_info *b_dev_info,
+ const struct address_space_operations *a_ops);
+
+static inline void balloon_mapping_free(struct address_space *balloon_mapping)
+{
+ kfree(balloon_mapping);
+}
/*
* __is_movable_balloon_page - helper to perform @page PageBalloon tests
@@ -123,6 +136,7 @@ static inline bool isolated_balloon_page(struct page *page)
static inline void balloon_page_insert(struct balloon_dev_info *balloon,
struct page *page)
{
+ page->mapping = balloon->mapping;
__SetPageBalloon(page);
SetPagePrivate(page);
set_page_private(page, (unsigned long)balloon);
@@ -139,6 +153,7 @@ static inline void balloon_page_insert(struct
balloon_dev_info *balloon,
*/
static inline void balloon_page_delete(struct page *page)
{
+ page->mapping = NULL;
__ClearPageBalloon(page);
set_page_private(page, 0);
if (PagePrivate(page)) {
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b4d71b5..de463b9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -368,6 +368,9 @@ struct address_space_operations {
*/
int (*migratepage) (struct address_space *,
struct page *, struct page *, enum migrate_mode);
+ int (*isolatepage)(struct page *);
+ int (*putbackpage)(struct page *);
+
int (*launder_page) (struct page *);
int (*is_partially_uptodate) (struct page *, unsigned
Re: [PATCH v2 1/6] virtio_balloon: transitional interface
"Michael S. Tsirkin" writes:
> Virtio 1.0 doesn't include a modern balloon device.
> But it's not a big change to support a transitional
> balloon device: this has the advantage of supporting
> existing drivers, transparently.
You decided to fix the packed struct...
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 6a356e3..574267f 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -77,7 +77,7 @@ struct virtio_balloon {
>
> /* Memory statistics */
> int need_stats_update;
> - struct virtio_balloon_stat stats[VIRTIO_BALLOON_S_NR];
> + struct virtio_balloon_stat_modern stats[VIRTIO_BALLOON_S_NR];
>
> /* To register callback in oom notifier call chain */
> struct notifier_block nb;
> @@ -269,7 +269,11 @@ static void stats_handle_request(struct virtio_balloon
> *vb)
> vq = vb->stats_vq;
> if (!virtqueue_get_buf(vq, ))
> return;
> - sg_init_one(, vb->stats, sizeof(vb->stats));
> + if (virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
> + sg_init_one(, vb->stats, sizeof(vb->stats));
> + else
> + sg_init_one(, >stats->tag, sizeof(vb->stats) -
> + offsetof(typeof(*vb->stats, tag);
This makes it compile, but definitely won't work.
> virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL);
> virtqueue_kick(vq);
> }
> @@ -283,21 +287,30 @@ static void virtballoon_changed(struct virtio_device
> *vdev)
>
> static inline s64 towards_target(struct virtio_balloon *vb)
> {
> - __le32 v;
> s64 target;
> + u32 num_pages;
>
> - virtio_cread(vb->vdev, struct virtio_balloon_config, num_pages, );
> + virtio_cread(vb->vdev, struct virtio_balloon_config,
> + num_pages, _pages);
>
> - target = le32_to_cpu(v);
> + /* Legacy balloon config space is LE, unlike all other devices. */
> + if (!virtio_has_feature(vb->vdev, VIRTIO_F_VERSION_1))
> + num_pages = le32_to_cpu((__force le32)num_pages);
> +
> + target = num_pages;
> return target - vb->num_pages;
> }
>
> static void update_balloon_size(struct virtio_balloon *vb)
> {
> - __le32 actual = cpu_to_le32(vb->num_pages);
> + u32 actual = vb->num_pages;
> +
> + /* Legacy balloon config space is LE, unlike all other devices. */
> + if (!virtio_has_feature(vb->vdev, VIRTIO_F_VERSION_1))
> + actual = (__force u32)cpu_to_le32(num_pages);
>
> - virtio_cwrite(vb->vdev, struct virtio_balloon_config, actual,
> - );
> + virtio_cwrite(vb->vdev, struct virtio_balloon_config,
> + actual, );
> }
Final line is gratitous reformatting.
I would leave the device *exactly* as is, ugly structure packing and
all.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] mm: hugetlb: cleanup using PageHugeActive flag
On Tue, Mar 31, 2015 at 02:08:14PM -0700, Andrew Morton wrote: > On Tue, 31 Mar 2015 08:50:46 + Naoya Horiguchi > wrote: > > > Now we have an easy access to hugepages' activeness, so existing helpers to > > get the information can be cleaned up. > > Similarly. Also I adapted the code to fit in with > http://ozlabs.org/~akpm/mmots/broken-out/mm-consolidate-all-page-flags-helpers-in-linux-page-flagsh.patch Thanks, moving the declaration/definition to include/linux/page-flags.h is OK.
Re: [PATCH v5 3/3] leds: Add ktd2692 flash LED driver
On Wed, 2015-04-01 at 12:58 +0900, Ingi Kim wrote:
> This patch adds a driver to support the ktd2692 flash LEDs.
> ktd2692 can control flash current by ExpressWire interface.
trivia:
> diff --git a/drivers/leds/leds-ktd2692.c b/drivers/leds/leds-ktd2692.c
[]
> +static void ktd2692_brightness_set(struct ktd2692_context *led,
> + enum led_brightness brightness)
> +{
> + mutex_lock(>lock);
> +
> + if (brightness == LED_OFF) {
> + led->mode = KTD2692_MODE_DISABLE;
> + gpio_set_value(led->aux_gpio, KTD2692_LOW);
> + goto out;
> + }
> +
> + ktd2692_expresswire_write(led, KTD2692_REG_MOVIE_CURRENT_BASE |
> + KTD2692_BRIGHTNESS_RANGE_255_TO_8(brightness));
> + led->mode = KTD2692_MODE_MOVIE;
> +
> +out:
> + ktd2692_expresswire_write(led, led->mode | KTD2692_REG_MODE_BASE);
> + mutex_unlock(>lock);
> +}
Perhaps this function would be better with if/else
without the out: label
> +static int ktd2692_led_flash_strobe_set(struct led_classdev_flash *fled_cdev,
> + bool state)
> +{
> + struct ktd2692_context *led = fled_cdev_to_led(fled_cdev);
> + struct led_flash_setting *timeout = _cdev->timeout;
> + u32 flash_tm_reg;
> +
> + mutex_lock(>lock);
> +
> + if (state == 0) {
> + led->mode = KTD2692_MODE_DISABLE;
> + gpio_set_value(led->aux_gpio, KTD2692_LOW);
> + goto done;
> + }
> +
> + flash_tm_reg = GET_TIMEOUT_OFFSET(timeout->val, timeout->step);
> + ktd2692_expresswire_write(led, flash_tm_reg
> + | KTD2692_REG_FLASH_TIMEOUT_BASE);
> +
> + led->mode = KTD2692_MODE_FLASH;
> + gpio_set_value(led->aux_gpio, KTD2692_HIGH);
> +
> +done:
> + ktd2692_expresswire_write(led, led->mode | KTD2692_REG_MODE_BASE);
Same if/else with the done: label?
--
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 v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Abhilash Kesavan writes: > On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman wrote: >> Javier Martinez Canillas writes: >> >> [...] >> >>> Unfortunately I don't fully understand why this clock needs to be >>> enabled. It would be good if someone at Samsung can explain in more >>> detail what the real problem really is. >> >> +1 >> >> Maybe Abhilash can shed some light here? >> >> We really should know *why* this is needed because having the fix in the >> clock driver just doesn't seem right. It seems like the DMA driver >> should be managing this clock. > > I think my last mail might not have reached you (was accidentally sent > as html). Yeah, I saw it a bit later in Javier's reply. Thanks for doing the research and reporting back. > We are gating the aclk266_g2d clock without checking the > CG_STATUS0 register bits as specified in the UM. It looks like we need > to keep several clocks alive or gate them only after checking the > CG_STATUSx register bits. I dont' know much about this clock hardware, but to me it sounds like a clock driver bug. The suspend fix Javier is proposing would fix it, but to me it sounds like the clock driver needs to actually start checking these CG_STATUSx bits before gating clocks. Otherwise, we might fix this current bug but a similar one will come and bite us another day. Kevin -- 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 3/3] leds: Add ktd2692 flash LED driver
This patch adds a driver to support the ktd2692 flash LEDs.
ktd2692 can control flash current by ExpressWire interface.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-ktd2692.c | 405
3 files changed, 415 insertions(+)
create mode 100644 drivers/leds/leds-ktd2692.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 25b320d..c32e73e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -498,6 +498,15 @@ config LEDS_MENF21BMC
This driver can also be built as a module. If so the module
will be called leds-menf21bmc.
+config LEDS_KTD2692
+ tristate "KTD2692 LED flash support"
+ depends on LEDS_CLASS_FLASH && GPIOLIB
+ help
+ This option enables support for KTD2692 LED flash connected
+ through ExpressWire interface.
+
+ Say Y to enable this driver.
+
comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index cbba921..289513b 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-ktd2692.c b/drivers/leds/leds-ktd2692.c
new file mode 100644
index 000..558e2b9
--- /dev/null
+++ b/drivers/leds/leds-ktd2692.c
@@ -0,0 +1,405 @@
+/*
+ * LED driver : leds-ktd2692.c
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Ingi Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Value related the flash mode */
+#define KTD2692_FLASH_MODE_TIMEOUT_LEVELS 8
+#define KTD2692_FLASH_MODE_TIMEOUT_DISABLE 0
+#define KTD2692_FLASH_MODE_TIMEOUT_DEFAULT_US 1049000
+#define KTD2692_FLASH_MODE_TIMEOUT_MAX_US 1835000
+#define KTD2692_FLASH_MODE_CURR_PERCENT(x) (((x) * 16) / 100)
+
+/* Macro for getting offset of flash timeout */
+#define GET_TIMEOUT_OFFSET(timeout, step) ((timeout) / (step))
+
+/* Adjust a multiple of brightness */
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_16(x) (((x) >> 4) & 0x0F)
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_8(x) (((x) >> 5) & 0x0F)
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_4(x) (((x) >> 6) & 0x0F)
+
+/* Base register address */
+#define KTD2692_REG_LVP_BASE 0x00
+#define KTD2692_REG_FLASH_TIMEOUT_BASE 0x20
+#define KTD2692_REG_MIN_CURRENT_SET_BASE 0x40
+#define KTD2692_REG_MOVIE_CURRENT_BASE 0x60
+#define KTD2692_REG_FLASH_CURRENT_BASE 0x80
+#define KTD2692_REG_MODE_BASE 0xA0
+
+/* Set bit coding time for expresswire interface */
+#define KTD2692_TIME_RESET_US 700
+#define KTD2692_TIME_DATA_START_TIME_US10
+#define KTD2692_TIME_HIGH_END_OF_DATA_US 350
+#define KTD2692_TIME_LOW_END_OF_DATA_US10
+#define KTD2692_TIME_SHORT_BITSET_US 4
+#define KTD2692_TIME_LONG_BITSET_US12
+
+/* KTD2692 default length of name */
+#define KTD2692_NAME_LENGTH20
+
+/* KTD2692 default name */
+#define KTD2692_DEFAULT_NAME "ktd2692"
+
+enum ktd2692_bitset {
+ KTD2692_LOW = 0,
+ KTD2692_HIGH,
+};
+
+/* Movie / Flash Mode Control */
+enum ktd2692_led_mode {
+ KTD2692_MODE_DISABLE = 0, /* default */
+ KTD2692_MODE_MOVIE,
+ KTD2692_MODE_FLASH,
+};
+
+struct ktd2692_context {
+ /* Related LED Flash class device */
+ struct led_classdev_flash fled_cdev;
+
+ struct mutex lock;
+ struct regulator *regulator;
+ struct work_struct work_brightness_set;
+
+ int aux_gpio;
+ int ctrl_gpio;
+
+ enum ktd2692_led_mode mode;
+ enum led_brightness torch_brightness;
+};
+
+static struct ktd2692_context *fled_cdev_to_led(
+ struct led_classdev_flash *fled_cdev)
+{
+ return container_of(fled_cdev, struct ktd2692_context, fled_cdev);
+}
+
+static void ktd2692_expresswire_start(struct ktd2692_context *led)
+{
+ gpio_set_value(led->ctrl_gpio, KTD2692_HIGH);
+ udelay(KTD2692_TIME_DATA_START_TIME_US);
+}
+
+static void ktd2692_expresswire_reset(struct ktd2692_context *led)
+{
+ gpio_set_value(led->ctrl_gpio, KTD2692_LOW);
+ udelay(KTD2692_TIME_RESET_US);
+}
+
+static void ktd2692_expresswire_end(struct
[PATCH v5 1/3] of: Add vendor prefix for Kinetic technologies
This patch adds vendor prefix for Kinetic technologies Signed-off-by: Ingi Kim Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..de9e126 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -98,6 +98,7 @@ isee ISEE 2007 S.L. isil Intersil karo Ka-Ro electronics GmbH keymileKeymile GmbH +kinetic Kinetic Technologies lacie LaCie lantiq Lantiq Semiconductor lenovo Lenovo Group Ltd. -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Btrfs: prevent deletion of mounted subvolumes
Omar Sandoval writes:
> On Mon, Mar 30, 2015 at 02:30:34PM +0200, David Sterba wrote:
>> On Mon, Mar 30, 2015 at 02:02:17AM -0700, Omar Sandoval wrote:
>> > Before commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"),
>> > d_invalidate() could return -EBUSY when a dentry for a directory had
>> > more than one reference to it. This is what prevented a mounted
>> > subvolume from being deleted, as struct vfsmount holds a reference to
>> > the subvolume dentry. However, that commit removed that case, and later
>> > commits in that patch series removed the return code from d_invalidate()
>> > completely, so we don't get that check for free anymore. So, reintroduce
>> > it in btrfs_ioctl_snap_destroy().
>>
>> > This applies to 4.0-rc6. To be honest, I'm not sure that this is the most
>> > correct fix for this bug, but it's equivalent to the pre-3.18 behavior and
>> > it's
>> > the best that I could come up with. Thoughts?
>>
>> > + spin_lock(>d_lock);
>> > + err = dentry->d_lockref.count > 1 ? -EBUSY : 0;
>> > + spin_unlock(>d_lock);
>>
>> The fix restores the original behaviour, but I don't think opencoding and
>> using internals is fine. Either there should be a vfs api for that or
>> there's an existing one that can be used instead.
I have a problem with restoring the original behavior as is.
In some sense it re-introduces the security issue that the d_invalidate
changes were built to fix.
Any user in the system can create a user namespace, create a mount
namespace and keep any subvolume pinned forever. Which at the very
least could make a very nice DOS attack. I am not familiar enough with
how people use subvolumes and
So let me ask. How can userspace not know that a subvolume that they
want to delete is already mounted?
I can see having something like is_local_mount_root and denying the
subvolume destruction if the mount that is pinning it is in your local
mount namespace.
>> The bug here seems defined up to the point that we're trying to delete a
>> subvolume that's a mountpoint. My next guess is that a check
>>
>> if (d_mountpoint()) { ... }
>>
>> could work.
>
> That was my first instinct as well, but d_mountpoint() is true for
> dentries that have a filesystem mounted on them (e.g., after mount
> /dev/sda1 /mnt, the dentry for "/mnt"), not the dentry that is mounted.
>
> I poked around the mount code for awhile and couldn't come up with
> anything using the existing interface. Mounting subvolumes bubbles down
> to mount_subtree(), which doesn't really leave any traces of which
> subvolume is mounted except for the dentry in struct vfsmount.
>
> (As far as I can tell, under the covers subvolume deletion is more or
> less equivalent to an rm -rf, and we obviously don't do anything to stop
> users from doing that on the root of their mounted filesystem, but it
> appears that users expect the original behavior.)
>
> Here's an idea: mark mount root dentries as such in the VFS and check it
> in the Btrfs code. Adding fsdevel ML for comments
> (https://lkml.org/lkml/2015/3/30/125 is the original message).
Marking root dentries is needed to fix the bug that you can escape
the limitations of loopback mounts with a carefully placed rename.
I have a patch cooking that marks mountpoints and tracks all of the
mounts on a dentry. So except for the possibility of stepping on each
others toes I have no objections.
Eric
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 74609b9..8a0933d 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2384,6 +2384,11 @@ static noinline int btrfs_ioctl_snap_destroy(struct
> file *file,
> goto out_dput;
> }
>
> + if (d_is_mount_root(dentry)) {
> + err = -EBUSY;
> + goto out_dput;
> + }
> +
> mutex_lock(>i_mutex);
>
> /*
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 82ef140..a28ca15 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -920,6 +920,10 @@ vfs_kern_mount(struct file_system_type *type, int flags,
> const char *name, void
> return ERR_CAST(root);
> }
>
> + spin_lock(>d_lock);
> + root->d_flags |= DCACHE_MOUNT_ROOT;
> + spin_unlock(>d_lock);
> +
> mnt->mnt.mnt_root = root;
> mnt->mnt.mnt_sb = root->d_sb;
> mnt->mnt_mountpoint = mnt->mnt.mnt_root;
> @@ -1017,6 +1021,8 @@ static struct mount *clone_mnt(struct mount *old,
> struct dentry *root,
>
> static void cleanup_mnt(struct mount *mnt)
> {
> + struct dentry *root = mnt->mnt.mnt_root;
> +
> /*
>* This probably indicates that somebody messed
>* up a mnt_want/drop_write() pair. If this
> @@ -1031,7 +1037,10 @@ static void cleanup_mnt(struct mount *mnt)
> if (unlikely(mnt->mnt_pins.first))
> mnt_pin_kill(mnt);
> fsnotify_vfsmount_delete(>mnt);
> - dput(mnt->mnt.mnt_root);
> + spin_lock(>d_lock);
> + root->d_flags &= ~DCACHE_MOUNT_ROOT;
> +
[PATCH v5 0/3] Add ktd2692 Flash LED driver using LED Flash class
This patch adds ktd2692 Flash LED driver with LED Flash class Change in v5: - Clean up the code - Fix help message of Kconfig - Fix issue related with regulator and mutex usage - Remove tab spaces in bindings Change in v4: - Clean up the code - Modify binding documentation of ktd2692 Change in v3: - Clean up the code - Add aux gpio pin to control Flash LED Change in v2: - Introduction of LED Flash class as Jacek's comment - Supplement of binding documentation - Rename gpio control pin and remove unused pin - Add regulator for the Flash LED Ingi Kim (3): of: Add vendor prefix for Kinetic technologies leds: ktd2692: add device tree bindings for ktd2692 leds: Add ktd2692 flash LED driver .../devicetree/bindings/leds/leds-ktd2692.txt | 32 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/leds/Kconfig | 9 + drivers/leds/Makefile | 1 + drivers/leds/leds-ktd2692.c| 405 + 5 files changed, 448 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt create mode 100644 drivers/leds/leds-ktd2692.c -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/3] leds: ktd2692: add device tree bindings for ktd2692
This patch adds the device tree bindings for ktd2692 flash LEDs.
Add optional properties 'flash-timeout-us' to control flash timeout
and 'vin-supply' for flash-led regulator
Signed-off-by: Ingi Kim
---
.../devicetree/bindings/leds/leds-ktd2692.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
new file mode 100644
index 000..3f121ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
@@ -0,0 +1,32 @@
+* Kinetic Technologies - KTD2692 Flash LED Driver
+
+KTD2692 is the ideal power solution for high-power flash LEDs.
+It uses ExpressWire single-wire programming for maximum flexibility.
+
+The ExpressWire interface through CTRL pin can control LED on/off and
+enable/disable the IC, Movie(max 1/3 of Flash current) / Flash mode current,
+Flash timeout, LVP(low voltage protection).
+
+Also, When the AUX pin is pulled high while CTRL pin is high,
+LED current will be ramped up to the flash-mode current level.
+
+Required properties:
+- compatible: "kinetic,ktd2692"
+- ctrl-gpio : gpio pin in order control CTRL pin
+- aux-gpio : gpio pin in order control AUX pin
+- vin-supply : "vin" LED supply (2.7V to 5.5V)
+ See Documentation/devicetree/bindings/regulator/regulator.txt
+
+Optional property:
+- flash-timeout-us : Maximum flash timeout in microseconds.
+ flash timeout ranges from 0 to 1835000us and default is 1049000us.
+
+Example:
+
+flash-led {
+ compatible = "kinetic,ktd2692";
+ ctrl-gpio = < 1 0>;
+ aux-gpio = < 2 0>;
+ flash-timeout-us = <1835000>;
+ vin-supply = <>;
+};
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/3] drm: rockchip/dw_hdmi-rockchip: improve for HDMI electrical test
When pixel clock less than 148.5MHz, make sloopboost=2 tklvl=20
cklvl=13 increase rasing/falling time and increase data & clock
voltage driver.
When pixel clock less than 74.25MHz, make sloopboost=0 tklvl=19
cklvl=18, increase data and clock voltage driver.
Signed-off-by: Yakir Yang
---
Changes in v4:
- combine the modification of electrical parameter for eye-diagram
& single-ended test to an separate patch.
Changes in v3:
- for pixel clock less than 148.5MHz, set txlvl to 20.
Changes in v2:
- set slopeboost back to 10%-20%, then rasing/falling time would pass.
- for pixel clock less then 74.25MHz, set txlvl to 19 and cklvl to 18.
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 65b0f7b..80d6fc8 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -135,9 +135,9 @@ static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = {
static const struct dw_hdmi_phy_config rockchip_phy_config[] = {
/*pixelclk symbol term vlev*/
- { 7425, 0x8009, 0x0004, 0x01ad},
- { 14850, 0x8029, 0x0004, 0x01ad},
- { 29700, 0x8039, 0x0005, 0x01ad},
+ { 7425, 0x8009, 0x0004, 0x0272},
+ { 14850, 0x802b, 0x0004, 0x028d},
+ { 29700, 0x8039, 0x0005, 0x028d},
{ ~0UL, 0x, 0x, 0x}
};
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] drm: bridge/dw_hdmi: separate VLEVCTRL settting into platform driver
Because of iMX6 & Rockchip have differnet mpll config parameter,
the VLEVCTRL parameter would be different. In this case we should
separate VLEVCTRL setting from the common dw_hdmi driver, config
this parameter in platform driver(dw_hdmi-imx and dw_hdmi-rockchip)
Signed-off-by: Yakir Yang
---
Changes in v4:
- separate VLEVCTRL setting into platform driver
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/dw_hdmi.c| 14 +++---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 12 ++--
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++---
include/drm/bridge/dw_hdmi.h| 5 +++--
4 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 7b61ae8..bf0c570 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -756,7 +756,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
const struct dw_hdmi_plat_data *plat_data = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = plat_data->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = plat_data->cur_ctr;
- const struct dw_hdmi_sym_term *sym_term = plat_data->sym_term;
+ const struct dw_hdmi_phy_config *phy_config = plat_data->phy_config;
if (prep)
return -EINVAL;
@@ -827,18 +827,18 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
hdmi_phy_i2c_write(hdmi, 0x, 0x13); /* PLLPHBYCTRL */
hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
- for (i = 0; sym_term[i].mpixelclock != (~0UL); i++)
+ for (i = 0; phy_config[i].mpixelclock != (~0UL); i++)
if (hdmi->hdmi_data.video_mode.mpixelclock <=
- sym_term[i].mpixelclock)
+ phy_config[i].mpixelclock)
break;
/* RESISTANCE TERM 133Ohm Cfg */
- hdmi_phy_i2c_write(hdmi, sym_term[i].term, 0x19); /* TXTERM */
+ hdmi_phy_i2c_write(hdmi, phy_config[i].term, 0x19); /* TXTERM */
/* PREEMP Cgf 0.00 */
- hdmi_phy_i2c_write(hdmi, sym_term[i].sym_ctr, 0x09); /* CKSYMTXCTRL */
-
+ hdmi_phy_i2c_write(hdmi, phy_config[i].sym_ctr, 0x09); /* CKSYMTXCTRL */
/* TX/CK LVL 10 */
- hdmi_phy_i2c_write(hdmi, 0x01ad, 0x0E); /* VLEVCTRL */
+ hdmi_phy_i2c_write(hdmi, phy_config[i].vlev_ctr, 0x0E); /* VLEVCTRL */
+
/* REMOVE CLK TERM */
hdmi_phy_i2c_write(hdmi, 0x8000, 0x05); /* CKCALCTRL */
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 87fe8ed..2c99474 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -75,10 +75,10 @@ static const struct dw_hdmi_curr_ctrl imx_cur_ctr[] = {
},
};
-static const struct dw_hdmi_sym_term imx_sym_term[] = {
- /*pixelclk symbol term*/
- { 14850, 0x800d, 0x0005 },
- { ~0UL, 0x, 0x }
+static const struct dw_hdmi_phy_config imx_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 14850, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
};
static int dw_hdmi_imx_parse_dt(struct imx_hdmi *hdmi)
@@ -163,7 +163,7 @@ static enum drm_mode_status imx6dl_hdmi_mode_valid(struct
drm_connector *con,
static struct dw_hdmi_plat_data imx6q_hdmi_drv_data = {
.mpll_cfg = imx_mpll_cfg,
.cur_ctr= imx_cur_ctr,
- .sym_term = imx_sym_term,
+ .phy_config = imx_phy_config,
.dev_type = IMX6Q_HDMI,
.mode_valid = imx6q_hdmi_mode_valid,
};
@@ -171,7 +171,7 @@ static struct dw_hdmi_plat_data imx6q_hdmi_drv_data = {
static struct dw_hdmi_plat_data imx6dl_hdmi_drv_data = {
.mpll_cfg = imx_mpll_cfg,
.cur_ctr = imx_cur_ctr,
- .sym_term = imx_sym_term,
+ .phy_config = imx_phy_config,
.dev_type = IMX6DL_HDMI,
.mode_valid = imx6dl_hdmi_mode_valid,
};
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index d236faa..65b0f7b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -133,12 +133,12 @@ static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[]
= {
}
};
-static const struct dw_hdmi_sym_term rockchip_sym_term[] = {
- /*pixelclk symbol term*/
- { 7425, 0x8009, 0x0004 },
- { 14850, 0x8029, 0x0004 },
- { 29700, 0x8039, 0x0005 },
- { ~0UL, 0x, 0x }
+static const struct dw_hdmi_phy_config rockchip_phy_config[] = {
+ /*pixelclk symbol term vlev*/
+ { 7425, 0x8009, 0x0004, 0x01ad},
+ { 14850, 0x8029, 0x0004, 0x01ad},
+ { 29700, 0x8039, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
};
static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
@@ -230,7 +230,7
[PATCH v4 1/3] drm: bridge/dw_hdmi: fixed codec style
Using a local struct pointer to reduce one level of indirection
makes the code slightly more readable.
Signed-off-by: Yakir Yang
Reviewed-by: Daniel Kurtz
---
Changes in v4: None
Changes in v3:
- make commit message more readable
Changes in v2: None
drivers/gpu/drm/bridge/dw_hdmi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index cd6a706..7b61ae8 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -753,10 +753,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
{
unsigned res_idx, i;
u8 val, msec;
- const struct dw_hdmi_mpll_config *mpll_config =
- hdmi->plat_data->mpll_cfg;
- const struct dw_hdmi_curr_ctrl *curr_ctrl = hdmi->plat_data->cur_ctr;
- const struct dw_hdmi_sym_term *sym_term = hdmi->plat_data->sym_term;
+ const struct dw_hdmi_plat_data *plat_data = hdmi->plat_data;
+ const struct dw_hdmi_mpll_config *mpll_config = plat_data->mpll_cfg;
+ const struct dw_hdmi_curr_ctrl *curr_ctrl = plat_data->cur_ctr;
+ const struct dw_hdmi_sym_term *sym_term = plat_data->sym_term;
if (prep)
return -EINVAL;
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] EDMA: TI: fixed wrongly initialized data parameter to the edma callback
On Mon, Mar 23, 2015 at 09:35:01PM +0100, Petr Kulhavy wrote: > The "data" parameter passed indirectly to the edma_callback() should be > edma_chan and not the dma_chan. > > This bug was so far harmless since the offset of struct dma_chan within struct > edma_chan is 0. However as soon as someone changes struct edma_chan this would > cause troubles. Applied now, but do ensure you are using right subsystem anmes for patches. I have fixed up now -- ~Vinod -- 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/4] watchdog: imgpdc: Add reboot support
On 03/31/2015 11:49 AM, Andrew Bresticker wrote: Register a restart handler that will restart the system by writing to the watchdog's SOFT_RESET register. Signed-off-by: Andrew Bresticker Cc: Ezequiel Garcia Reviewed-by: Guenter Roeck -- 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] watchdog: imgpdc: Set timeout before starting watchdog
On 03/31/2015 11:49 AM, Andrew Bresticker wrote: From: Naidu Tellapati Set up the watchdog for the specified timeout before attempting to start it. Signed-off-by: Naidu Tellapati Signed-off-by: Andrew Bresticker Cc: Ezequiel Garcia --- drivers/watchdog/imgpdc_wdt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/watchdog/imgpdc_wdt.c b/drivers/watchdog/imgpdc_wdt.c index f3f65ac..aef3596 100644 --- a/drivers/watchdog/imgpdc_wdt.c +++ b/drivers/watchdog/imgpdc_wdt.c @@ -106,6 +106,8 @@ static int pdc_wdt_start(struct watchdog_device *wdt_dev) unsigned int val; struct pdc_wdt_dev *wdt = watchdog_get_drvdata(wdt_dev); + pdc_wdt_set_timeout(>wdt_dev, wdt->wdt_dev.timeout); + val = readl(wdt->base + PDC_WDT_CONFIG); val |= PDC_WDT_CONFIG_ENABLE; writel(val, wdt->base + PDC_WDT_CONFIG); It might be better to provide a helper function that doesn't set wdt->wdt_dev.timeout again, or to just set the timeout with the write to PDC_WDT_CONFIG when starting the watchdog. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/3] Improve eys-diagram & single-ended electric test for rk3288 HDMI
Dear all, RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz, and single-ended test would failed when display mode is 74.25MHz. To fix such problems, we make those patch set: - Fix some code style, leave space for next patches. - Separate VLEVLCTRL setting into platform driver. - Improve the electrical parameter that relate to eye-diagram test & signel-ended test. Turn on the Transmitter Trailer-B and improve slopeboost to 10%-20% decrease. Set CKLVL to 18 and TXLVL to 19 if pixel clock is 74.25MHz. Set CKLVL to 13 and TXLVL to 20 if pixel clock is 148.5MHz. Changes in v4: - separate VLEVCTRL setting into platform driver - combine the modification of electrical parameter for eye-diagram & single-ended test to an separate patch. Changes in v3: - make commit message more readable - for pixel clock less than 148.5MHz, set txlvl to 20. Changes in v2: - set slopeboost back to 10%-20%, then rasing/falling time would pass. - for pixel clock less then 74.25MHz, set txlvl to 19 and cklvl to 18. Yakir Yang (3): drm: bridge/dw_hdmi: fixed codec style drm: bridge/dw_hdmi: separate VLEVCTRL settting into platform driver drm: rockchip/dw_hdmi-rockchip: improve for HDMI electrical test drivers/gpu/drm/bridge/dw_hdmi.c| 20 ++-- drivers/gpu/drm/imx/dw_hdmi-imx.c | 12 ++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++--- include/drm/bridge/dw_hdmi.h| 5 +++-- 4 files changed, 26 insertions(+), 25 deletions(-) -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add generic callbacks into compaction
>
> I sent a patch about page allocation for less fragmentation.
> http://permalink.gmane.org/gmane.linux.kernel.mm/130599
>
> It proposes a page allocator allocates pages in the same pageblock
> for the drivers to move their unmovable pages. Some drivers which comsumes
> many pages
> and increases system fragmentation use the allocator to move their pages to
> decrease fragmentation.
>
> I think I can try another approach.
> There is a compaction code for balloon pages.
> But the compaction code cannot migrate pages of other drivers.
> If there is a generic migration framework applicable to any drivers,
> drivers can register their migration functions.
> And the compaction can migrate movable pages and also driver's pages.
>
> I'm not familiar with virtualization so I couldn't test this patch yet.
A RFC, no?
> But if mm developers agree with this approach, I will complete this patch.
>
> I would do appreciate any feedback.
>
> Signed-off-by: Gioh Kim
> ---
> drivers/virtio/virtio_balloon.c|2 ++
> include/linux/balloon_compaction.h | 23 +---
> include/linux/fs.h |3 ++
> include/linux/pagemap.h| 26 ++
> mm/balloon_compaction.c| 68
> ++--
> mm/compaction.c|7 ++--
> mm/migrate.c | 24 ++---
> 7 files changed, 129 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 0413157..cd9b8e4 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -486,6 +486,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
>
> balloon_devinfo_init(>vb_dev_info);
> #ifdef CONFIG_BALLOON_COMPACTION
> + vb->vb_dev_info.mapping = balloon_mapping_alloc(>vb_dev_info,
> + _aops);
> vb->vb_dev_info.migratepage = virtballoon_migratepage;
> #endif
>
> diff --git a/include/linux/balloon_compaction.h
> b/include/linux/balloon_compaction.h
> index 9b0a15d..0af32b3 100644
> --- a/include/linux/balloon_compaction.h
> +++ b/include/linux/balloon_compaction.h
> @@ -62,6 +62,7 @@ struct balloon_dev_info {
> struct list_head pages; /* Pages enqueued & handled to Host */
> int (*migratepage)(struct balloon_dev_info *, struct page *newpage,
> struct page *page, enum migrate_mode mode);
> + struct address_space *mapping;
Better if a comment line is added.
> };
>
> extern struct page *balloon_page_enqueue(struct balloon_dev_info
> *b_dev_info);
> @@ -76,10 +77,22 @@ static inline void balloon_devinfo_init(struct
> balloon_dev_info *balloon)
> }
>
> #ifdef CONFIG_BALLOON_COMPACTION
> -extern bool balloon_page_isolate(struct page *page);
> -extern void balloon_page_putback(struct page *page);
> -extern int balloon_page_migrate(struct page *newpage,
> - struct page *page, enum migrate_mode mode);
> +extern const struct address_space_operations balloon_aops;
> +extern int balloon_page_isolate(struct page *page);
> +extern int balloon_page_putback(struct page *page);
> +extern int balloon_page_migrate(struct address_space *mapping,
> + struct page *newpage,
> + struct page *page,
> + enum migrate_mode mode);
> +
> +extern struct address_space
> +*balloon_mapping_alloc(struct balloon_dev_info *b_dev_info,
> +const struct address_space_operations *a_ops);
> +
> +static inline void balloon_mapping_free(struct address_space
> *balloon_mapping)
> +{
> + kfree(balloon_mapping);
> +}
>
> /*
> * __is_movable_balloon_page - helper to perform @page PageBalloon tests
> @@ -123,6 +136,7 @@ static inline bool isolated_balloon_page(struct page
> *page)
> static inline void balloon_page_insert(struct balloon_dev_info *balloon,
> struct page *page)
> {
> + page->mapping = balloon->mapping;
> __SetPageBalloon(page);
> SetPagePrivate(page);
> set_page_private(page, (unsigned long)balloon);
> @@ -139,6 +153,7 @@ static inline void balloon_page_insert(struct
> balloon_dev_info *balloon,
> */
> static inline void balloon_page_delete(struct page *page)
> {
> + page->mapping = NULL;
> __ClearPageBalloon(page);
> set_page_private(page, 0);
> if (PagePrivate(page)) {
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index b4d71b5..de463b9 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -368,6 +368,9 @@ struct address_space_operations {
>*/
> int (*migratepage) (struct address_space *,
> struct page *, struct page *, enum migrate_mode);
> + int (*isolatepage)(struct page *);
> + int (*putbackpage)(struct page *);
> +
> int (*launder_page) (struct page *);
> int
Re: [PATCH] dmaengine: ste_dma40: fix implicit conversion
On Sun, Mar 22, 2015 at 12:51:08AM +0100, Stefan Agner wrote: > The function d40_prep_sg takes the type enum dma_transfer_direction > as second last parameter. However, the memcpy calls pass DMA_NONE > which is of type enum dma_data_direction. Fix this by passing the > actual transfer direction DMA_MEM_TO_MEM. > > This does not change the actual code flow since only the transfer > direction DMA_MEM_TO_DEV and DMA_DEV_TO_MEM are actually used in the > function d40_prep_sg. Applied, now -- ~Vinod -- 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] Staging: rtl8192u Make function static
On Tue, Mar 31, 2015 at 05:51:19PM -0600, Eddie Kovsky wrote: > Changing function definition to static fixes the > following warning generated by sparse: > > drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:1924:6: warning: > symbol 'ieee80211_check_auth_response' was not declared. Should it be static? some one has already done this and it has been already applied to staging-testing. regards sudip > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build regression in next-20150331
Hi Rafael,
On 31 March 2015 at 16:27, Rafael J. Wysocki wrote:
> On Wednesday, April 01, 2015 01:03:52 AM Rafael J. Wysocki wrote:
>> On Tuesday, March 31, 2015 11:39:37 AM Tyler Baker wrote:
>> > Hi Thomas, Rafael,
>> >
>> > I was notified this morning by the kernelci.org system that a new
>> > build error has been detected in next-20150331[0][1][2]. It seems that
>> > "clockevents: Remove CONFIG_GENERIC_CLOCKEVENTS_BUILD"
>> > c9439b1d6eb4ada5c2faf3970ac0d2bc4bd20e14 is the culprit.
>> >
>> > Initially, I reported these failures to John Stultz and his response is
>> > below.
>> >
>> > *snip*
>> >
>> > I suspect we either need to enable GENERIC_CLOCKEVENTS on those three
>> > hardware types, or if that's not possible, rework the definitions.
>> >
>> > Or something like (copy-paste whitespace corruption below.. only for
>> > reference, don't apply):
>> >
>> > diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
>> > index 2a1563a..6da40c0 100644
>> > --- a/kernel/time/tick-internal.h
>> > +++ b/kernel/time/tick-internal.h
>> > @@ -107,12 +107,13 @@ static inline void tick_resume_broadcast(void) { }
>> > static inline bool tick_resume_check_broadcast(void) { return false; }
>> > static inline void tick_broadcast_init(void) { }
>> > static inline int tick_broadcast_update_freq(struct
>> > clock_event_device *dev, u32 freq) { return -ENODEV; }
>> > -
>> > +#ifdef CONFIG_GENERIC_CLOCKEVENTS
>> > /* Set the periodic handler in non broadcast mode */
>> > static inline void tick_set_periodic_handler(struct
>> > clock_event_device *dev, int broadcast)
>> > {
>> > dev->event_handler = tick_handle_periodic;
>> > }
>> > +#endif
>> > #endif /* !BROADCAST */
>> >
>> > *snip*
>> >
>> > Any chance either of you can reproduce this issue on your end?
>>
>> Can you please tell me if the appended patch helps?
>
> Scratch that, wrong patch.
>
> Please try the one below instead.
>
> Rafael
>
>
> ---
> kernel/time/tick-internal.h |2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-pm/kernel/time/tick-internal.h
> ===
> --- linux-pm.orig/kernel/time/tick-internal.h
> +++ linux-pm/kernel/time/tick-internal.h
> @@ -110,7 +110,9 @@ static inline int tick_broadcast_update_
> /* Set the periodic handler in non broadcast mode */
> static inline void tick_set_periodic_handler(struct clock_event_device *dev,
> int broadcast)
> {
> +#ifdef CONFIG_GENERIC_CLOCKEVENTS
> dev->event_handler = tick_handle_periodic;
> +#endif
> }
> #endif /* !BROADCAST */
Thanks for the quick response. I've applied this patch on top of
next-20150331 and I can confirm this fixes the build error reported in
this thread. The test results can be found here[0].
>
>
Cheers,
Tyler
[0]
http://kernelci.org/build/tbaker/kernel/v4.0-rc6-7993-gb448f49+gcc-linaro-4.9-2015.02/
--
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 v10 08/11] sched: replace capacity_factor by usage
Hi Vincent,
On 27 March 2015 at 23:59, Vincent Guittot wrote:
> On 27 March 2015 at 15:52, Xunlei Pang wrote:
>> Hi Vincent,
>>
>> On 27 February 2015 at 23:54, Vincent Guittot
>> wrote:
>>> /**
>>> @@ -6432,18 +6435,19 @@ static inline void update_sd_lb_stats(struct lb_env
>>> *env, struct sd_lb_stats *sd
>>>
>>> /*
>>> * In case the child domain prefers tasks go to siblings
>>> -* first, lower the sg capacity factor to one so that we'll
>>> try
>>> +* first, lower the sg capacity so that we'll try
>>> * and move all the excess tasks away. We lower the capacity
>>> * of a group only if the local group has the capacity to
>>> fit
>>> -* these excess tasks, i.e. nr_running <
>>> group_capacity_factor. The
>>> -* extra check prevents the case where you always pull from
>>> the
>>> -* heaviest group when it is already under-utilized
>>> (possible
>>> -* with a large weight task outweighs the tasks on the
>>> system).
>>> +* these excess tasks. The extra check prevents the case
>>> where
>>> +* you always pull from the heaviest group when it is
>>> already
>>> +* under-utilized (possible with a large weight task
>>> outweighs
>>> +* the tasks on the system).
>>> */
>>> if (prefer_sibling && sds->local &&
>>> - sds->local_stat.group_has_free_capacity) {
>>> - sgs->group_capacity_factor =
>>> min(sgs->group_capacity_factor, 1U);
>>> - sgs->group_type = group_classify(sg, sgs);
>>> + group_has_capacity(env, >local_stat) &&
>>> + (sgs->sum_nr_running > 1)) {
>>> + sgs->group_no_capacity = 1;
>>> + sgs->group_type = group_overloaded;
>>> }
>>>
>>
>> For SD_PREFER_SIBLING, if local has 1 task and group_has_capacity()
>> returns true(but not overloaded) for it, and assume sgs group has 2
>> tasks, should we still mark this group overloaded?
>
> yes, the load balance will then choose if it's worth pulling it or not
> depending of the load of each groups
Maybe I didn't make it clearly.
For example, CPU0~1 are SMT siblings, CPU2~CPU3 are another pair.
CPU0 is idle, others each has 1 task. Then according to this patch,
CPU2~CPU3(as one group) will be viewed as overloaded(CPU0~CPU1 as
local group, and group_has_capacity() returns true here), so the
balancer may initiate an active task moving. This is different from
the current code as SD_PREFER_SIBLING logic does. Is this problematic?
>
>>
>> -Xunlei
--
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 v6 2/2] dmaengine: Add ADM driver
On Tue, Mar 17, 2015 at 12:46:12AM -0500, Andy Gross wrote:
> +static enum dma_status adm_tx_status(struct dma_chan *chan, dma_cookie_t
> cookie,
> + struct dma_tx_state *txstate)
> +{
> + struct adm_chan *achan = to_adm_chan(chan);
> + struct virt_dma_desc *vd;
> + enum dma_status ret;
> + unsigned long flags;
> + size_t residue = 0;
> +
> + ret = dma_cookie_status(chan, cookie, txstate);
> + if (ret == DMA_COMPLETE || !txstate)
> + return ret;
> +
> + spin_lock_irqsave(>vc.lock, flags);
> +
> + vd = vchan_find_desc(>vc, cookie);
> + if (vd)
> + residue = container_of(vd, struct adm_async_desc, vd)->length;
> +
> + spin_unlock_irqrestore(>vc.lock, flags);
> +
> + /*
> + * residue is either the full length if it is in the issued list, or 0
> + * if it is in progress. We have no reliable way of determining
> + * anything inbetween
> + */
> + dma_set_residue(txstate, residue);
> +
> + if (achan->error)
> + return DMA_ERROR;
but this may not be for the current descriptor right, which is queued?
--
~Vinod
--
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] dma: Add Freescale qDMA engine driver support
On Tue, Mar 17, 2015 at 01:28:38PM +0800, Yuan Yao wrote:
> +static int fsl_qdma_alloc_chan_resources(struct dma_chan *chan)
> +{
> + /*
> + * In QDMA mode, We don't need to do anything.
> + */
> + return 0;
> +}
Pls remove this
> +static struct fsl_qdma_comp *fsl_qdma_request_enqueue_desc(
> + struct fsl_qdma_chan *fsl_chan)
> +{
> + struct fsl_qdma_comp *comp_temp;
> + struct fsl_qdma_queue *queue = fsl_chan->queue;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>queue_lock, flags);
> + if (list_empty(>comp_free)) {
> + spin_unlock_irqrestore(>queue_lock, flags);
> + comp_temp = kzalloc(sizeof(*comp_temp), GFP_KERNEL);
this is called by prep_ APIs so should be atomic so GFP_KERNEL is wrong, you
should use GFP_NOWAIT like you did for below..
> +static int fsl_qdma_halt(struct fsl_qdma_engine *fsl_qdma)
> +{
> + void __iomem *addr = fsl_qdma->membase;
> + int i, count = 5;
> + u32 reg;
> +
> + /* Disable the command queue and wait for idle state. */
no locks held while you do this ?
> +static struct dma_async_tx_descriptor *fsl_qdma_prep_dma_sg(
> + struct dma_chan *chan,
> + struct scatterlist *dst_sg, unsigned int dst_nents,
> + struct scatterlist *src_sg, unsigned int src_nents,
> + unsigned long flags)
> +{
> + return NULL;
> +}
why is this empty?
> + dma_cap_set(DMA_PRIVATE, fsl_qdma->dma_dev.cap_mask);
> + dma_cap_set(DMA_SLAVE, fsl_qdma->dma_dev.cap_mask);
> + dma_cap_set(DMA_MEMCPY, fsl_qdma->dma_dev.cap_mask);
> +
> + fsl_qdma->dma_dev.dev = >dev;
> + fsl_qdma->dma_dev.device_alloc_chan_resources
> + = fsl_qdma_alloc_chan_resources;
> + fsl_qdma->dma_dev.device_free_chan_resources
> + = fsl_qdma_free_chan_resources;
> + fsl_qdma->dma_dev.device_tx_status = fsl_qdma_tx_status;
> + fsl_qdma->dma_dev.device_prep_dma_memcpy = fsl_qdma_prep_memcpy;
> + fsl_qdma->dma_dev.device_prep_dma_sg = fsl_qdma_prep_dma_sg;
> + fsl_qdma->dma_dev.device_issue_pending = fsl_qdma_issue_pending;
pls set direction etc fields as well
> +
> + /* Free descriptor areas */
> + for (i = 0; i < fsl_qdma->n_queues; i++) {
> + queue_temp = fsl_qdma->queue + i;
> + list_for_each_entry_safe(comp_temp, _comp_temp,
> + _temp->comp_used, list) {
> + dma_pool_free(queue_temp->comp_pool,
> + comp_temp->virt_addr,
> + comp_temp->bus_addr);
> + list_del(_temp->list);
> + kfree(comp_temp);
> + }
> + list_for_each_entry_safe(comp_temp, _comp_temp,
> + _temp->comp_free, list) {
> + dma_pool_free(queue_temp->comp_pool,
> + comp_temp->virt_addr,
> + comp_temp->bus_addr);
> + list_del(_temp->list);
> + kfree(comp_temp);
> + }
> + dma_free_coherent(>dev, sizeof(struct fsl_qdma_ccdf) *
> + queue_temp->n_cq, queue_temp->cq,
> + queue_temp->bus_addr);
> + dma_pool_destroy(queue_temp->comp_pool);
> + }
> +
> + dma_free_coherent(>dev, sizeof(struct fsl_qdma_ccdf) *
> + status->n_cq, status->cq, status->bus_addr);
and at this point you still have irq registered and enabled, so can be
invoked!
--
~Vinod
--
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 21/25] slub: Use bool function return values of true/false not 1/0
On Mon, 30 Mar 2015, Joe Perches wrote: > Use the normal return values for bool functions > > Signed-off-by: Joe Perches Acked-by: David Rientjes -- 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: drop a useless config read
Cornelia Huck writes: > On Tue, 31 Mar 2015 13:55:42 +0200 > "Michael S. Tsirkin" wrote: > >> commit d71de9ec6ba806104439d3a669befda84757b5af >> "virtio: core support for config generation" >> fixed reading up 64 bit values, adding generation >> checks for such reads. >> >> By mistake, it left an explicit get call in place >> as well. the result is that the value is read twice, >> the first result is discarded. >> >> Not a big deal since this only happens with virtio >> blk and only on boot ATM, so performance isn't >> affected, but let's clean it up. >> >> Signed-off-by: Michael S. Tsirkin >> --- >> include/linux/virtio_config.h | 1 - >> 1 file changed, 1 deletion(-) > > Reviewed-by: Cornelia Huck Applied. Thanks! Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] rtc: __rtc_read_time: reduce log level
On Wed, 2015-04-01 at 05:21 +0200, Alexandre Belloni wrote:
> On 28/03/2015 at 23:09:35 +0200, Aaro Koskinen wrote :
> > __rtc_read_time logs should be debug logs instead of error logs.
> >
> > For example, when the RTC clock is not set, it's not really useful
> > to print a kernel error log every time someone tries to read the clock:
> >
> > ~ # hwclock -r
> > [ 604.508263] rtc rtc0: read_time: fail to read
> > hwclock: RTC_RD_TIME: Invalid argument
> >
> > If there's a real error, it's likely that lower level or higher level
> > code will tell it anyway. Make these logs debug logs, and also print
> > the error code for the read failure.
> >
>
> That actually may be the only error message printed for some failures.
> Some RTCs don't print anything in case of error in their .read_time()
> and there are in-kernel users of rtc_read_time that simply bail out
> without printing anything or have a trace that is already at the debug
> level.
>
> I would agree that this would need a better harmonization and I guess we
> can do that for now. I'll try to fix the in-kernel cases.
Maybe these should use dev_err_once().
> > diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
[]
> > @@ -31,13 +31,14 @@ static int __rtc_read_time(struct rtc_device *rtc,
> > struct rtc_time *tm)
> > memset(tm, 0, sizeof(struct rtc_time));
> > err = rtc->ops->read_time(rtc->dev.parent, tm);
> > if (err < 0) {
> > - dev_err(>dev, "read_time: fail to read\n");
> > + dev_dbg(>dev, "read_time: fail to read: %d\n",
> > + err);
> > return err;
> > }
> >
> > err = rtc_valid_tm(tm);
> > if (err < 0)
> > - dev_err(>dev, "read_time: rtc_time isn't valid\n");
> > + dev_dbg(>dev, "read_time: rtc_time isn't valid\n");
> > }
> > return err;
> > }
--
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/
[LKP] [mm] b191f9b106e: -8.8% netperf.time.minor_page_faults
esult/lkp-ne02/netperf/performance-300s-200%-TCP_SENDFILE/debian-x86_64-2015-02-07.cgz/x86_64-rhel/e42391cd048809d903291d07f86ed3934ce138e9/0" node_roles: server client job_file: "/lkp/scheduled/lkp-ne02/cyclic_netperf-performance-300s-200%-TCP_SENDFILE-x86_64-rhel-BASE-e42391cd048809d903291d07f86ed3934ce138e9-0-20150331-32956-1uhguoe.yaml" dequeue_time: 2015-03-31 12:29:34.133136287 +08:00 nr_cpu: "$(nproc)" max_uptime: 1500 modules_initrd: "/kernel/x86_64-rhel/e42391cd048809d903291d07f86ed3934ce138e9/modules.cgz" bm_initrd: "/lkp/benchmarks/turbostat.cgz,/lkp/benchmarks/netperf-debian.cgz,/lkp/benchmarks/netperf.cgz" job_state: finished loadavg: 34.91 29.35 13.49 1/214 9318 start_time: '1427776206' end_time: '1427776507' version: "/lkp/lkp/.src-20150331-104755" echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu10/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu11/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu12/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu13/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu14/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu15/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu7/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu8/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu9/cpufreq/scaling_governor netserver netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 netperf -t TCP_SENDFILE -c -C -l 300 ___ LKP mailing list l...@linux.intel.com
Re: [PATCH v10 07/11] sched: get CPU's usage statistic
Vincent,
On 27 March 2015 at 23:37, Vincent Guittot wrote:
> On 27 March 2015 at 16:12, Xunlei Pang wrote:
>>> +static int get_cpu_usage(int cpu)
>>> +{
>>> + unsigned long usage = cpu_rq(cpu)->cfs.utilization_load_avg;
>>> + unsigned long capacity = capacity_orig_of(cpu);
>>> +
>>> + if (usage >= SCHED_LOAD_SCALE)
>>> + return capacity;
>>
>> Can "capacity" be greater than SCHED_LOAD_SCALE?
>> Why use SCHED_LOAD_SCALE instead of "capacity" in this judgement?
>
> Yes, SCHED_LOAD_SCALE is the default value but the capacity can be in
> the range [1536:512] for arm as an example
Right, I was confused between cpu capacity and
arch_scale_freq_capacity() in "Patch 04" then. Thanks.
-Xunlei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] rtc: __rtc_read_time: reduce log level
On 28/03/2015 at 23:09:35 +0200, Aaro Koskinen wrote :
> __rtc_read_time logs should be debug logs instead of error logs.
>
> For example, when the RTC clock is not set, it's not really useful
> to print a kernel error log every time someone tries to read the clock:
>
> ~ # hwclock -r
> [ 604.508263] rtc rtc0: read_time: fail to read
> hwclock: RTC_RD_TIME: Invalid argument
>
> If there's a real error, it's likely that lower level or higher level
> code will tell it anyway. Make these logs debug logs, and also print
> the error code for the read failure.
>
That actually may be the only error message printed for some failures.
Some RTCs don't print anything in case of error in their .read_time()
and there are in-kernel users of rtc_read_time that simply bail out
without printing anything or have a trace that is already at the debug
level.
I would agree that this would need a better harmonization and I guess we
can do that for now. I'll try to fix the in-kernel cases.
> Signed-off-by: Aaro Koskinen
Acked-by: Alexandre Belloni
> ---
> drivers/rtc/interface.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> index 37215cf..c786818 100644
> --- a/drivers/rtc/interface.c
> +++ b/drivers/rtc/interface.c
> @@ -31,13 +31,14 @@ static int __rtc_read_time(struct rtc_device *rtc, struct
> rtc_time *tm)
> memset(tm, 0, sizeof(struct rtc_time));
> err = rtc->ops->read_time(rtc->dev.parent, tm);
> if (err < 0) {
> - dev_err(>dev, "read_time: fail to read\n");
> + dev_dbg(>dev, "read_time: fail to read: %d\n",
> + err);
> return err;
> }
>
> err = rtc_valid_tm(tm);
> if (err < 0)
> - dev_err(>dev, "read_time: rtc_time isn't valid\n");
> + dev_dbg(>dev, "read_time: rtc_time isn't valid\n");
> }
> return err;
> }
> --
> 2.2.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hi Kevin, On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman wrote: > Javier Martinez Canillas writes: > > [...] > >> Unfortunately I don't fully understand why this clock needs to be >> enabled. It would be good if someone at Samsung can explain in more >> detail what the real problem really is. > > +1 > > Maybe Abhilash can shed some light here? > > We really should know *why* this is needed because having the fix in the > clock driver just doesn't seem right. It seems like the DMA driver > should be managing this clock. I think my last mail might not have reached you (was accidentally sent as html). We are gating the aclk266_g2d clock without checking the CG_STATUS0 register bits as specified in the UM. It looks like we need to keep several clocks alive or gate them only after checking the CG_STATUSx register bits. Regards, Abhilash -- 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 0/3] dma: dt: Add DMA driver for jz4780
On Wed, Mar 18, 2015 at 04:16:34PM +, Zubair Lutfullah Kakakhel wrote: > Hi, > > Here we have three patches that add a DMA driver for the Ingenic JZ4780 SoC. > > JZ4780 support is still in-flight. > > These are based on 4.0-rc4. Applied, thanks Please ensure you use the right subsystem name in your patches, I have fixed it up now -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] rtc: hctosys: use function name in the error log
On Wed, 2015-04-01 at 05:01 +0200, Alexandre Belloni wrote:
> On 28/03/2015 at 23:09:36 +0200, Aaro Koskinen wrote :
> > Use function name in the error log instead of __FILE__.
> > Signed-off-by: Aaro Koskinen
> Acked-by: Alexandre Belloni
Hello.
> > diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
[]
> @@ -33,7 +33,7 @@ static int __init rtc_hctosys(void)
> >
> > if (rtc == NULL) {
> > pr_err("%s: unable to open rtc device (%s)\n",
> > - __FILE__, CONFIG_RTC_HCTOSYS_DEVICE);
> > + __func__, CONFIG_RTC_HCTOSYS_DEVICE);
> > goto err_open;
> > }
Neither __func__ or __FILE__ is really useful here.
The message is already specific enough without it.
If anything, it'd probably be better to add
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
to the various files in drivers/rtc that don't
already have it and remove most all of these
logging __func__ uses.
Something like:
drivers/rtc/hctosys.c | 6 --
drivers/rtc/rtc-cmos.c | 6 --
drivers/rtc/rtc-ds1374.c | 8 +---
drivers/rtc/rtc-ds1685.c | 4 +++-
drivers/rtc/rtc-ds3232.c | 6 --
drivers/rtc/rtc-efi-platform.c | 3 +++
drivers/rtc/rtc-m41t80.c | 6 --
drivers/rtc/rtc-max77686.c | 6 --
drivers/rtc/rtc-max8997.c | 8 +---
drivers/rtc/rtc-msm6242.c | 4 +++-
drivers/rtc/rtc-opal.c | 3 ++-
drivers/rtc/rtc-s5m.c | 4 +++-
drivers/rtc/rtc-twl.c | 9 +
13 files changed, 49 insertions(+), 24 deletions(-)
diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
index fb4251d..e1cfa06 100644
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -9,6 +9,8 @@
* published by the Free Software Foundation.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
/* IMPORTANT: the RTC only stores whole seconds. It is arbitrary
@@ -32,8 +34,8 @@ static int __init rtc_hctosys(void)
struct rtc_device *rtc = rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
if (rtc == NULL) {
- pr_info("%s: unable to open rtc device (%s)\n",
- __FILE__, CONFIG_RTC_HCTOSYS_DEVICE);
+ pr_info("unable to open rtc device (%s)\n",
+ CONFIG_RTC_HCTOSYS_DEVICE);
goto err_open;
}
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 87647f4..a82556a 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -28,6 +28,9 @@
* interrupts disabled, holding the global rtc_lock, to exclude those
* other drivers and utilities on correctly configured systems.
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -385,8 +388,7 @@ static bool alarm_disable_quirk;
static int __init set_alarm_disable_quirk(const struct dmi_system_id *id)
{
alarm_disable_quirk = true;
- pr_info("rtc-cmos: BIOS has alarm-disable quirk. ");
- pr_info("RTC alarms disabled\n");
+ pr_info("BIOS has alarm-disable quirk - RTC alarms disabled\n");
return 0;
}
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 8605fde..167783f 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -18,6 +18,8 @@
* "Sending and receiving", using SMBus level communication is preferred.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -406,7 +408,7 @@ static int ds1374_wdt_settimeout(unsigned int timeout)
/* Set new watchdog time */
ret = ds1374_write_rtc(save_client, timeout, DS1374_REG_WDALM0, 3);
if (ret) {
- pr_info("rtc-ds1374 - couldn't set new watchdog time\n");
+ pr_info("couldn't set new watchdog time\n");
goto out;
}
@@ -539,12 +541,12 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned
int cmd,
return -EFAULT;
if (options & WDIOS_DISABLECARD) {
- pr_info("rtc-ds1374: disable watchdog\n");
+ pr_info("disable watchdog\n");
ds1374_wdt_disable();
}
if (options & WDIOS_ENABLECARD) {
- pr_info("rtc-ds1374: enable watchdog\n");
+ pr_info("enable watchdog\n");
ds1374_wdt_settimeout(wdt_margin);
ds1374_wdt_ping();
}
diff --git a/drivers/rtc/rtc-ds1685.c b/drivers/rtc/rtc-ds1685.c
index 7020209..818a363 100644
--- a/drivers/rtc/rtc-ds1685.c
+++ b/drivers/rtc/rtc-ds1685.c
@@ -16,6 +16,8 @@
* published by the Free Software Foundation.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -2182,7 +2184,7 @@ ds1685_rtc_poweroff(struct platform_device *pdev)
/* Check for valid RTC data, else, spin forever. */
if (unlikely(!pdev)) {
- pr_emerg("rtc-ds1685:
[RFC][PATCH] tracing: Replace '-' with '_' in event system names
There's a change I want to make to the tracing infrastructure that may require TRACE_SYSTEM be a valid variable name. As '-' can not be used in a variable, and I found only three cases that it is a TRACE_SYSTEM name, I want to ask those that are responsible if it is OK to change them? The three systems are: #define TRACE_SYSTEM kvm-s390 #define TRACE_SYSTEM xhci-hcd #define TRACE_SYSTEM intel-sst I want to replace the '-' with '_'. But this will have a user space visible affect, which is why I'm inquiring with you. If this will break any scripts or annoy any users that you know of, I'll need to make a work around (which would not be hard to do). But if I don't need to do that, I prefer to just use TRACE_SYSTEM as is. I'll just do the work around if there is any user space tool that you know of that will break with this change. The effect is that the directories in /sys/kernel/debug/tracing/events/ will be different. That is, /sys/kernel/debug/tracing/events/kvm-s390/ will become /sys/kernel/debug/tracing/events/kvm_s390/ And the same for the other two. Is this a problem? Thanks! -- Steve Tentatively-signed-off-by: Steven Rostedt --- arch/s390/kvm/trace-s390.h | 2 +- drivers/usb/host/xhci-trace.h| 2 +- include/trace/events/intel-sst.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/s390/kvm/trace-s390.h b/arch/s390/kvm/trace-s390.h index 653a7ec09ef5..bf02effdf535 100644 --- a/arch/s390/kvm/trace-s390.h +++ b/arch/s390/kvm/trace-s390.h @@ -4,7 +4,7 @@ #include #undef TRACE_SYSTEM -#define TRACE_SYSTEM kvm-s390 +#define TRACE_SYSTEM kvm_s390 #define TRACE_INCLUDE_PATH . #undef TRACE_INCLUDE_FILE #define TRACE_INCLUDE_FILE trace-s390 diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h index dde3959b7a33..b610374b6f36 100644 --- a/drivers/usb/host/xhci-trace.h +++ b/drivers/usb/host/xhci-trace.h @@ -12,7 +12,7 @@ */ #undef TRACE_SYSTEM -#define TRACE_SYSTEM xhci-hcd +#define TRACE_SYSTEM xhci_hcd #if !defined(__XHCI_TRACE_H) || defined(TRACE_HEADER_MULTI_READ) #define __XHCI_TRACE_H diff --git a/include/trace/events/intel-sst.h b/include/trace/events/intel-sst.h index 76c72d3f1902..11bb4ca0fac7 100644 --- a/include/trace/events/intel-sst.h +++ b/include/trace/events/intel-sst.h @@ -1,5 +1,5 @@ #undef TRACE_SYSTEM -#define TRACE_SYSTEM intel-sst +#define TRACE_SYSTEM intel_sst #if !defined(_TRACE_INTEL_SST_H) || defined(TRACE_HEADER_MULTI_READ) #define _TRACE_INTEL_SST_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: linux-next: Tree for Mar 31 (build failures and culprits)
On Tue, Mar 31, 2015 at 7:16 PM, Guenter Roeck wrote:
>
> xtensa
>
> Lots of 'dangerous relocation: l32r: literal placed after use' all over the
> place, causing all xtensa builds to fail.
>
> Introduced by commit 779c88c94c34 ("ARM: 8321/1: asm-generic: introduce
> .text.fixup input section").
I'm looking at it.
--
Thanks.
-- Max
--
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] kernel/reboot.c: Add orderly_reboot for graceful reboot
Hi Andrew, On Wed, Apr 1, 2015 at 9:09 AM, Andrew Morton wrote: > On Mon, 30 Mar 2015 12:45:32 +1030 Joel Stanley wrote: > >> The kernel has orderly_poweroff which allows the kernel to initiate a >> graceful shutdown of userspace, by running /sbin/poweroff. This adds >> orderly_reboot that will cause userspace to shut itself down by calling >> /sbin/reboot. >> >> This will be used for shutdown initiated by a system controller on >> platforms that do not use ACPI. > > gee. There are a lot of callers of emergency_restart(). Why is the > BMC reboot special, and how many of the emergency_restart() callers > really be using orderly_reboot()? The BMC reboot is intended to be a graceful shutdown - let userspace do it's thing before the system goes down. Userspace may chose to stop and perform some long, slow teardown before it gets around to shutting down. We don't want to move callers over orderly_reboot() if they're shutting the system down due to a critical failure, eg. printer on fire. I had a read of the emergency_restart() callers and I didn't see any obvious cases for moving over to orderly_reboot(). > We have /proc/sys/kernel/poweroff_cmd. Should we have > /proc/sys/kernel/reboot_cmd as well? If not, > kernel/reboot.c:reboot_cmd[] can be made static ;) I don't think we need it. I'll make reboot_cmd[] static. Cheers, Joel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Mar 31 (build failures and culprits)
On 03/31/2015 08:01 PM, Michael Ellerman wrote: On Tue, 2015-03-31 at 19:18 -0700, Guenter Roeck wrote: On 03/31/2015 04:24 PM, Michael Ellerman wrote: On Wed, 2015-04-01 at 01:07 +0200, Greg Kroah-Hartman wrote: On Tue, Mar 31, 2015 at 09:16:40AM -0700, Guenter Roeck wrote: alpha:allmodconfig mips:allmodconfig samples/kdbus/kdbus-workers.c: In function ‘prime_new’: samples/kdbus/kdbus-workers.c:930:18: error: ‘__NR_memfd_create’ undeclared (first use in this function) p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC); Looks like the kdbus example never worked for the affected architectures. I don't build allmodconfig for all architectures, so other architectures may be affected as well. You need 3.17 kernel headers to have memfd_create, not much the kdbus test code can do about that. You might want to update the kernel headers for these build boxes. Or just 'make headers_install' before building the samples should do it. Sure, that works so well in a cross build environment. Well yeah it does, I do it all the time. But what you mean is that the samples are built with HOSTCC, so having the cross headers doesn't help. The real problem here is samples, they shouldn't be built with the kernel, they should be a separate thing, like the selftests. I "solved" the problem by disabling CONFIG_SAMPLES in my alpha and mips builds. FWIW, I think (suspect) that the samples builder does the equivalent of "make headers_install" as part of the build process, but I don't have time to track it down. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/platform, acpi: Statically assign IRQ numbers in ACPI, hardware reduced mode
We have to be conservative to dynamically assign IRQ number on the platform in ACPI Hardware-reduced mode. On the Bay Trail-T(ASUS-T100) platform, there is a RTC device still using the legacy hardcoded IRQ8, which could cause the following error if RTC is configured: 7486341a98f: genirq: Flags mismatch irq 8. 0080 (mmc0) vs. (rtc0) So we want to statically assign IRQ numbers in ACPI hardware reduced mode to fix this error, this also matches with the original IRQ assignment policy. Signed-off-by: Li Aubrey Cc: Alan Cox Cc: Len Brown Cc: Rafael J. Wysocki Cc: Arjan van de Ven --- arch/x86/kernel/acpi/boot.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 803b684..4cd0761 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -460,8 +460,12 @@ acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end) acpi_table_print_madt_entry(header); - /* Statically assign IRQ numbers for IOAPICs hosting legacy IRQs */ - if (ioapic->global_irq_base < nr_legacy_irqs()) + /* +* Statically assign IRQ numbers for IOAPICs hosting legacy IRQs, +* Or for the platform in Hardware-reduced ACPI model +*/ + if (ioapic->global_irq_base < nr_legacy_irqs() || + acpi_gbl_reduced_hardware) cfg.type = IOAPIC_DOMAIN_LEGACY; mp_register_ioapic(ioapic->id, ioapic->address, ioapic->global_irq_base, -- 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 0/2] workqueue: fix a bug when numa mapping is changed
On Tue, Mar 31, 2015 at 11:02:42PM -0400, Tejun Heo wrote: > Ugh... so, cpu number allocation on hot-add is part of userland > interface that we're locked into? Tying hotplug and id allocation > order together usually isn't a good idea. What if the cpu up fails > while running the notifiers? The ID is already allocated and the next > cpu being brought up will be after a hole anyway. Is this even > actually gonna affect userland? At any rate, this isn't big a deal. If the mapping has to be dynamic, it'd be great to move the mapping code from workqueue to cpu hotplug proper tho. Thanks. -- tejun -- 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/2] workqueue: fix a bug when numa mapping is changed
On Wed, Apr 01, 2015 at 11:55:11AM +0900, Kamezawa Hiroyuki wrote: > Now, hot-added cpus will have the lowest free cpu id. > > Because of this, in most of systems which has only cpu-hot-add, cpu-ids are > always > contiguous even after cpu hot add. > In enterprise, this would be considered as imcompatibility. > > determining cpuid <-> lapicid at boot will make cpuids sparse. That may > corrupt > exisiting script or configuration/resource management software. Ugh... so, cpu number allocation on hot-add is part of userland interface that we're locked into? Tying hotplug and id allocation order together usually isn't a good idea. What if the cpu up fails while running the notifiers? The ID is already allocated and the next cpu being brought up will be after a hole anyway. Is this even actually gonna affect userland? -- tejun -- 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] lib: bitmap_[empty,full]: remove code duplication
On 01.04.2015 02:06, Andrew Morton wrote: On Sun, 29 Mar 2015 05:03:55 +0300 Yury Norov wrote: Function 'bitmap_empty' has it's own implementation. But it's clearly as simple as: "find_first_bit(src, nbits) == nbits" The same is true for 'bitmap_full'. Looks OK. Please send a Signed-off-by: for this patch. Hello Andrew, Is it enough? Signed-off-by: Yury Norov BR, Yury Norov -- 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] rtc: initialize rtc name early
On 28/03/2015 at 23:09:34 +0200, Aaro Koskinen wrote : > In some error cases RTC name is used before it is initialized: > > rtc-rs5c372 0-0032: clock needs to be set > rtc-rs5c372 0-0032: rs5c372b found, 24hr, driver version 0.6 > rtc (null): read_time: fail to read > rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0 > > Fix by initializing the name early. > > Signed-off-by: Aaro Koskinen Acked-by: Alexandre Belloni > --- > drivers/rtc/class.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c > index 472a5ad..014ecbc 100644 > --- a/drivers/rtc/class.c > +++ b/drivers/rtc/class.c > @@ -225,15 +225,15 @@ struct rtc_device *rtc_device_register(const char > *name, struct device *dev, > rtc->pie_timer.function = rtc_pie_update_irq; > rtc->pie_enabled = 0; > > + strlcpy(rtc->name, name, RTC_DEVICE_NAME_SIZE); > + dev_set_name(>dev, "rtc%d", id); > + > /* Check to see if there is an ALARM already set in hw */ > err = __rtc_read_alarm(rtc, ); > > if (!err && !rtc_valid_tm()) > rtc_initialize_alarm(rtc, ); > > - strlcpy(rtc->name, name, RTC_DEVICE_NAME_SIZE); > - dev_set_name(>dev, "rtc%d", id); > - > rtc_dev_prepare(rtc); > > err = device_register(>dev); > -- > 2.2.0 > -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Mar 31 (build failures and culprits)
On Tue, 2015-03-31 at 19:18 -0700, Guenter Roeck wrote: > On 03/31/2015 04:24 PM, Michael Ellerman wrote: > > On Wed, 2015-04-01 at 01:07 +0200, Greg Kroah-Hartman wrote: > >> On Tue, Mar 31, 2015 at 09:16:40AM -0700, Guenter Roeck wrote: > >>> alpha:allmodconfig > >>> mips:allmodconfig > >>> > >>> samples/kdbus/kdbus-workers.c: In function ‘prime_new’: > >>> samples/kdbus/kdbus-workers.c:930:18: error: ‘__NR_memfd_create’ > >>> undeclared > >>> (first use in this function) > >>>p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC); > >>> > >>> Looks like the kdbus example never worked for the affected architectures. > >>> I don't build allmodconfig for all architectures, so other architectures > >>> may be affected as well. > >> > >> You need 3.17 kernel headers to have memfd_create, not much the kdbus > >> test code can do about that. You might want to update the kernel > >> headers for these build boxes. > > > > Or just 'make headers_install' before building the samples should do it. > > > > Sure, that works so well in a cross build environment. Well yeah it does, I do it all the time. But what you mean is that the samples are built with HOSTCC, so having the cross headers doesn't help. The real problem here is samples, they shouldn't be built with the kernel, they should be a separate thing, like the selftests. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] rtc: hctosys: use function name in the error log
On 28/03/2015 at 23:09:36 +0200, Aaro Koskinen wrote :
> Use function name in the error log instead of __FILE__.
>
> Signed-off-by: Aaro Koskinen
Acked-by: Alexandre Belloni
> ---
> drivers/rtc/hctosys.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
> index 6c719f2..7748a61 100644
> --- a/drivers/rtc/hctosys.c
> +++ b/drivers/rtc/hctosys.c
> @@ -33,7 +33,7 @@ static int __init rtc_hctosys(void)
>
> if (rtc == NULL) {
> pr_err("%s: unable to open rtc device (%s)\n",
> - __FILE__, CONFIG_RTC_HCTOSYS_DEVICE);
> + __func__, CONFIG_RTC_HCTOSYS_DEVICE);
> goto err_open;
> }
>
> --
> 2.2.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86/cpu hotplug: make apicid <--> cpuid mapping persistent
On 2015/03/30 18:58, Gu Zheng wrote:
> Hi Kame-san,
>
> On 03/27/2015 12:31 AM, Kamezawa Hiroyuki wrote:
>
>> On 2015/03/26 13:55, Gu Zheng wrote:
>>> Hi Kame-san,
>>> On 03/26/2015 11:19 AM, Kamezawa Hiroyuki wrote:
>>>
On 2015/03/26 11:17, Gu Zheng wrote:
> Previously, we build the apicid <--> cpuid mapping when the cpu is
> present, but
> the relationship will be changed if the cpu/node hotplug happenned,
> because we
> always choose the first free cpuid for the hot added cpu (whether it is
> new-add
> or re-add), so this the cpuid <--> node mapping changed if node hot plug
> occurred, and it causes the wq sub-system allocation failture:
> ==
> SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
> cache: kmalloc-192, object size: 192, buffer size: 192, default
> order:
>1, min order: 0
> node 0: slabs: 6172, objs: 259224, free: 245741
> node 1: slabs: 3261, objs: 136962, free: 127656
> ==
> So here we build the persistent [lapic id] <--> cpuid mapping when the
> cpu first
> present, and never change it.
>
> Suggested-by: KAMEZAWA Hiroyuki
> Signed-off-by: Gu Zheng
> ---
> arch/x86/kernel/apic/apic.c | 31 ++-
> 1 files changed, 30 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index ad3639a..d539ebc 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2038,6 +2038,30 @@ void disconnect_bsp_APIC(int virt_wire_setup)
> apic_write(APIC_LVT1, value);
> }
>
> +/*
> + * Logic cpu number(cpuid) to local APIC id persistent mappings.
> + * Do not clear the mapping even if cpu hot removed.
> + * */
> +static int apicid_to_x86_cpu[MAX_LOCAL_APIC] = {
> + [0 ... MAX_LOCAL_APIC - 1] = -1,
> +};
This patch cannot handle x2apic, which is 32bit.
>>>
>>> IMO, if the apicid is too big (larger than MAX_LOCAL_APIC), we will skip
>>> generating a logic cpu number for it, so it seems no problem here.
>>>
>> you mean MAX_LOCAL_APIC=32768 ? isn't it too wasting ?
>
> I use the big array here to keep the same format with the existed ones:
> int apic_version[MAX_LOCAL_APIC];
>
> s16 __apicid_to_node[MAX_LOCAL_APIC] = {
> [0 ... MAX_LOCAL_APIC-1] = NUMA_NO_NODE
> };
> Or we should also say "NO" to them?
This will not survive when someone try to enlarge MAX_LOCAL_APIC for
introdcing new cpu model because x2apic is 32bit by definition.
Please create long surviving infrastructure.
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] sparc/PCI: Add mem64 resource parsing for root bus
Found "no compatible bridge window" warning in boot log from T5-8.
pci :00:01.0: can't claim BAR 15 [mem 0x1-0x4afff pref]: no
compatible bridge window
That resource is above 4G, but does not get offset correctly as
root bus only report io and mem32.
pci_sun4v f02dbcfc: PCI host bridge to bus :00
pci_bus :00: root bus resource [io 0x8040-0x80400fff] (bus
address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x8000-0x80007eff] (bus
address [0x-0x7eff])
pci_bus :00: root bus resource [bus 00-77]
Add mem64 handling in pci_common for sparc, so we can have 64bit resource
registered for root bus at first.
After patch, will have:
pci_sun4v f02dbcfc: PCI host bridge to bus :00
pci_bus :00: root bus resource [io 0x8040-0x80400fff] (bus
address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x8000-0x80007eff] (bus
address [0x-0x7eff])
pci_bus :00: root bus resource [mem 0x8001-0x8007] (bus
address [0x1-0x7])
pci_bus :00: root bus resource [bus 00-77]
Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream
windows")
Link:
http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
Reported-by: David Ahern
Tested-by: David Ahern
Signed-off-by: Yinghai Lu
Cc: #3.19
---
arch/sparc/kernel/pci.c| 7 ++-
arch/sparc/kernel/pci_common.c | 15 +--
arch/sparc/kernel/pci_impl.h | 1 +
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 9ce5afe..04ce3ac 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -185,8 +185,10 @@ static unsigned long pci_parse_of_flags(u32 addr0)
if (addr0 & 0x0200) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
- flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
+ if (addr0 & 0x0100)
+ flags |= IORESOURCE_MEM_64
+| PCI_BASE_ADDRESS_MEM_TYPE_64;
if (addr0 & 0x4000)
flags |= IORESOURCE_PREFETCH
| PCI_BASE_ADDRESS_MEM_PREFETCH;
@@ -663,6 +665,9 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
pbm->io_space.start);
pci_add_resource_offset(, >mem_space,
pbm->mem_space.start);
+ if (pbm->mem64_space.flags)
+ pci_add_resource_offset(, >mem64_space,
+ pbm->mem_space.start);
pbm->busn.start = pbm->pci_first_busno;
pbm->busn.end = pbm->pci_last_busno;
pbm->busn.flags = IORESOURCE_BUS;
diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 944a065..a859a86 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -406,6 +406,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
}
num_pbm_ranges = i / sizeof(*pbm_ranges);
+ memset(>mem64_space, 0, sizeof(struct resource));
for (i = 0; i < num_pbm_ranges; i++) {
const struct linux_prom_pci_ranges *pr = _ranges[i];
@@ -451,7 +452,11 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
break;
case 3:
- /* XXX 64-bit MEM handling XXX */
+ /* 64-bit MEM handling */
+ pbm->mem64_space.start = a;
+ pbm->mem64_space.end = a + size - 1UL;
+ pbm->mem64_space.flags = IORESOURCE_MEM;
+ break;
default:
break;
@@ -465,15 +470,21 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
prom_halt();
}
- printk("%s: PCI IO[%llx] MEM[%llx]\n",
+ printk("%s: PCI IO[%llx] MEM[%llx]",
pbm->name,
pbm->io_space.start,
pbm->mem_space.start);
+ if (pbm->mem64_space.flags)
+ printk(" MEM64[%llx]",
+ pbm->mem64_space.start);
+ printk("\n");
pbm->io_space.name = pbm->mem_space.name = pbm->name;
request_resource(_resource, >io_space);
request_resource(_resource, >mem_space);
+ if (pbm->mem64_space.flags)
+ request_resource(_resource, >mem64_space);
pci_register_legacy_regions(>io_space,
>mem_space);
diff --git a/arch/sparc/kernel/pci_impl.h b/arch/sparc/kernel/pci_impl.h
index 75803c7..37222ca 100644
--- a/arch/sparc/kernel/pci_impl.h
+++ b/arch/sparc/kernel/pci_impl.h
@@ -97,6 +97,7 @@ struct pci_pbm_info {
/* PBM I/O and Memory
[PATCH 3/3] PCI: Set pref for mem64 resource of pcie device
We still get "no compatible bridge window" warning on sparc T5-8
after we add support for 64bit resource parsing for root bus.
PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
PCI: Claiming :00:01.0: Resource 15: 8001..8004afff
[220c]
PCI: Claiming :01:00.0: Resource 15: 8001..8004afff
[220c]
PCI: Claiming :02:04.0: Resource 15: 8001..80012fff
[220c]
PCI: Claiming :03:00.0: Resource 15: 8001..80012fff
[220c]
PCI: Claiming :04:06.0: Resource 14: 8001..80010fff
[220c]
PCI: Claiming :05:00.0: Resource 0: 8001..80011fff
[204]
pci :05:00.0: can't claim BAR 0 [mem 0x8001-0x80011fff]: no
compatible bridge window
All the bridges 64-bit resource have pref bit, but the device resource does not
have pref set, then we can not find parent for the device resource,
as we can not put non-pref mem under pref mem.
According to pcie spec errta
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13, in some case it is ok to mark some as pref.
Only set pref for 64bit mmio when the entire path from the host to the adapter
is
over PCI Express.
Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream
windows")
Link:
http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
Reported-by: David Ahern
Tested-by: David Ahern
Signed-off-by: Yinghai Lu
Cc: #3.19
---
drivers/pci/probe.c | 50 ++
1 file changed, 50 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index f71cb7c..4e0cd46 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1507,6 +1507,53 @@ static void pci_init_capabilities(struct pci_dev *dev)
pci_enable_acs(dev);
}
+static bool pci_up_path_over_pcie(struct pci_bus *bus)
+{
+ if (!bus)
+ return true;
+
+ if (bus->self && !pci_is_pcie(bus->self))
+ return false;
+
+ return pci_up_path_over_pcie(bus->parent);
+}
+
+/*
+ * According to
+ *
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
+ * page 13, system firmware could put some 64bit non-pref under 64bit pref,
+ * on some cases.
+ * Let's set pref bit for 64bit mmio when entire path from the host to
+ * the adapter is over PCI Express.
+ */
+static void set_pcie_64bit_pref(struct pci_dev *dev)
+{
+ int i;
+
+ if (!pci_is_pcie(dev))
+ return;
+
+ if (!pci_up_path_over_pcie(dev->bus))
+ return;
+
+ for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
+ struct resource *res = >resource[i];
+ enum pci_bar_type type;
+ int reg;
+
+ if (!(res->flags & IORESOURCE_MEM_64))
+ continue;
+
+ if (res->flags & IORESOURCE_PREFETCH)
+ continue;
+
+ reg = pci_resource_bar(dev, i, );
+ dev_printk(KERN_DEBUG, >dev, "reg 0x%x %pR + pref\n",
+ reg, res);
+ res->flags |= IORESOURCE_PREFETCH;
+ }
+}
+
void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
{
int ret;
@@ -1536,6 +1583,9 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus
*bus)
/* Initialize various capabilities */
pci_init_capabilities(dev);
+ /* After pcie_cap is assigned and sriov bar is probed */
+ set_pcie_64bit_pref(dev);
+
/*
* Add the device to our list of discovered devices
* and the bus list for fixup functions, etc.
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] PCI/sparc: Fix booting with T5-8
Fix regression by commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to
fit in upstream windows").
That cause bridge bar get clipped wrongly.
The sparc64 dma_addr_t is 32-bit, we can not use it to check if we can
use 64bit bar, introduce pci_bus_addr_t.
sparc ofpci does not parse 64bit mem for root bus, add code to
make sure that we get correct resource for root.
Also there are device 64-bit res does not have pref bit flag, but bridges
do have pref bit set, that cause extra "no compatible window".
Set pref bit for them according to the errata.
Thanks
Yinghai
Yinghai Lu (3):
PCI: Introduce pci_bus_addr_t
sparc/PCI: Add mem64 resource parsing for root bus
PCI: Set pref for mem64 resource of pcie device
arch/sparc/kernel/pci.c| 7 -
arch/sparc/kernel/pci_common.c | 15 --
arch/sparc/kernel/pci_impl.h | 1 +
drivers/pci/Kconfig| 4 +++
drivers/pci/bus.c | 10 +++
drivers/pci/probe.c| 62 ++
include/linux/pci.h| 12 ++--
7 files changed, 94 insertions(+), 17 deletions(-)
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] PCI: Introduce pci_bus_addr_t
David Ahern found commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
to fit in upstream windows") broke booting on sparc/T5-8.
In the boot log, there is
pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address
0x110204000)
but that only could happen when dma_addr_t is 32-bit.
According to David Miller, all DMA occurs behind an IOMMU and these
IOMMUs only support 32-bit addressing, therefore dma_addr_t is
32-bit on sparc64.
Let's introduce pci_bus_addr_t instead of using dma_addr_t,
and pci_bus_addr_t will be 64-bit on 64-bit platform or X86_PAE.
Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream
windows")
Fixes: commit 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger
than 4GB")
Link:
http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
Reported-by: David Ahern
Tested-by: David Ahern
Signed-off-by: Yinghai Lu
Cc: #3.19
---
drivers/pci/Kconfig | 4
drivers/pci/bus.c | 10 +-
drivers/pci/probe.c | 12 ++--
include/linux/pci.h | 12 +---
4 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 7a8f1c5..6a5a269 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -1,6 +1,10 @@
#
# PCI configuration
#
+config PCI_BUS_ADDR_T_64BIT
+ def_bool y if (64BIT || X86_PAE)
+ depends on PCI
+
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 90fa3a7..6fbd3f2 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -92,11 +92,11 @@ void pci_bus_remove_resources(struct pci_bus *bus)
}
static struct pci_bus_region pci_32_bit = {0, 0xULL};
-#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+#ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
static struct pci_bus_region pci_64_bit = {0,
- (dma_addr_t) 0xULL};
-static struct pci_bus_region pci_high = {(dma_addr_t) 0x1ULL,
- (dma_addr_t) 0xULL};
+ (pci_bus_addr_t) 0xULL};
+static struct pci_bus_region pci_high = {(pci_bus_addr_t) 0x1ULL,
+ (pci_bus_addr_t) 0xULL};
#endif
/*
@@ -200,7 +200,7 @@ int pci_bus_alloc_resource(struct pci_bus *bus, struct
resource *res,
resource_size_t),
void *alignf_data)
{
-#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+#ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
int rc;
if (res->flags & IORESOURCE_MEM_64) {
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 8d2f400..f71cb7c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -253,8 +253,8 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type
type,
}
if (res->flags & IORESOURCE_MEM_64) {
- if ((sizeof(dma_addr_t) < 8 || sizeof(resource_size_t) < 8) &&
- sz64 > 0x1ULL) {
+ if ((sizeof(pci_bus_addr_t) < 8 || sizeof(resource_size_t) < 8)
+ && sz64 > 0x1ULL) {
res->flags |= IORESOURCE_UNSET | IORESOURCE_DISABLED;
res->start = 0;
res->end = 0;
@@ -263,7 +263,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type
type,
goto out;
}
- if ((sizeof(dma_addr_t) < 8) && l) {
+ if ((sizeof(pci_bus_addr_t) < 8) && l) {
/* Above 32-bit boundary; try to reallocate */
res->flags |= IORESOURCE_UNSET;
res->start = 0;
@@ -398,7 +398,7 @@ static void pci_read_bridge_mmio_pref(struct pci_bus *child)
struct pci_dev *dev = child->self;
u16 mem_base_lo, mem_limit_lo;
u64 base64, limit64;
- dma_addr_t base, limit;
+ pci_bus_addr_t base, limit;
struct pci_bus_region region;
struct resource *res;
@@ -425,8 +425,8 @@ static void pci_read_bridge_mmio_pref(struct pci_bus *child)
}
}
- base = (dma_addr_t) base64;
- limit = (dma_addr_t) limit64;
+ base = (pci_bus_addr_t) base64;
+ limit = (pci_bus_addr_t) limit64;
if (base != base64) {
dev_err(>dev, "can't handle bridge window above 4GB (bus
address %#010llx)\n",
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 211e9da..6021bbe 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -573,9 +573,15 @@ int raw_pci_read(unsigned int domain, unsigned int bus,
unsigned int devfn,
int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 val);
+#ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
+typedef u64 pci_bus_addr_t;
+#else
+typedef u32 pci_bus_addr_t;
+#endif
+
struct
Re: [PATCH 0/2] workqueue: fix a bug when numa mapping is changed
On 2015/04/01 0:28, Tejun Heo wrote: Hello, Kamezawa. On Tue, Mar 31, 2015 at 03:09:05PM +0900, Kamezawa Hiroyuki wrote: But this may be considered as API change for most hot-add users. Hmm... Why would it be? What can that possibly break? Now, hot-added cpus will have the lowest free cpu id. Because of this, in most of systems which has only cpu-hot-add, cpu-ids are always contiguous even after cpu hot add. In enterprise, this would be considered as imcompatibility. determining cpuid <-> lapicid at boot will make cpuids sparse. That may corrupt exisiting script or configuration/resource management software. So, for now, I vote for detemining ids at online but record it is a good way. If we know the information during boot, let's please do it at boot time by all means. I basically agree. Just thinking influence of this small imcompatibility of forcing ideal way because of my standing point. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] Documentation: bindings: add abracon,abx80x
Document the bindings for abracon,abx80x and related compatibles. Cc: devicetree-disc...@lists.ozlabs.org Signed-off-by: Alexandre Belloni --- .../devicetree/bindings/rtc/abracon,abx80x.txt | 32 ++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/abracon,abx80x.txt diff --git a/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt b/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt new file mode 100644 index ..6f0d3b2cdd89 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt @@ -0,0 +1,32 @@ +Abracon ABX80X I2C ultra low power RTC/Alarm chip + +The Abracon ABX80X family consist of the ab0801, ab0803, ab0804, ab0805, ab1801, +ab1803, ab1804 and ab1805. The ab0805 is the superset of ab080x and the ab1805 +is the superset of ab180x. + +Required properties: + + - "compatible": should one of: +"abracon,abx80x" +"abracon,ab0801" +"abracon,ab0803" +"abracon,ab0804" +"abracon,ab0805" +"abracon,ab1801" +"abracon,ab1803" +"abracon,ab1804" +"abracon,ab1805" + Using "abracon,abx80x" will enable chip autodetection. + - "reg": I2C bus address of the device + +Optional properties: + +The abx804 and abx805 have a trickle charger that is able to charge the +connected battery or supercap. Both the following properties have to be defined +and valid to enable charging: + + - "abracon,tc-diode": should be "standard" (0.6V) or "schottky" (0.3V) + - "abracon,tc-resistor": should be <0>, <3>, <6> or <11>. 0 disables the output + resistor, the other values are in ohm. + + -- 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/
[PATCH v2 0/2] rtc: add Abracon ABx80x
Hi, As discussed, I reworked the abracon abx80x driver, merging Philippe's and mine. I have added the Device Tree properties to enable the trickle charger and the driver will detect the partnumber before doing that so that it won't try to enable the charger when it is not available. Andrew, when taking this series, you can drop: rtc-add-rtc-abx805-a-driver-for-the-abracon-ab-1805-i2c-rtc.patch rtc-add-abracon-abx80x-driver.patch rtc-add-abracon-abx80x-driver-fix.patch Changes in v2: - corrected MODULE_LICENSE - enforce ABX8XX_CTRL_WRITE at probe time instead of at write time - changed the range of supported dates to be 2000-2099 - reworked the write function to be clearer Alexandre Belloni (1): Documentation: bindings: add abracon,abx80x Philippe De Muyter (1): rtc: add rtc-abx80x, a driver for the Abracon AB x80x i2c rtc .../devicetree/bindings/rtc/abracon,abx80x.txt | 32 +++ drivers/rtc/Kconfig| 10 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-abx80x.c | 307 + 4 files changed, 350 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/abracon,abx80x.txt create mode 100644 drivers/rtc/rtc-abx80x.c -- 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/
[PATCH v2 2/2] rtc: add rtc-abx80x, a driver for the Abracon AB x80x i2c rtc
From: Philippe De Muyter
This is a basic driver for the ultra-low-power Abracon AB x80x series of RTC
chips. It supports in particular, the supersets AB0805 and AB1805.
It allows reading and writing the time, and enables the supercapacitor/
battery charger.
[a...@arndb.de: abx805 depends on i2c]
Signed-off-by: Philippe De Muyter
Cc: Alessandro Zummo
Signed-off-by: Alexandre Belloni
Signed-off-by: Arnd Bergmann
Signed-off-by: Andrew Morton
---
drivers/rtc/Kconfig | 10 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-abx80x.c | 307 +++
3 files changed, 318 insertions(+)
create mode 100644 drivers/rtc/rtc-abx80x.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b5b5c3d485d6..89507c1858ec 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -164,6 +164,16 @@ config RTC_DRV_ABB5ZES3
This driver can also be built as a module. If so, the module
will be called rtc-ab-b5ze-s3.
+config RTC_DRV_ABX80X
+ tristate "Abracon ABx80x"
+ help
+ If you say yes here you get support for Abracon AB080X and AB180X
+ families of ultra-low-power battery- and capacitor-backed real-time
+ clock chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-abx80x.
+
config RTC_DRV_AS3722
tristate "ams AS3722 RTC driver"
depends on MFD_AS3722
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 69c87062b098..7b20b0462cb6 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_RTC_DRV_88PM80X) += rtc-88pm80x.o
obj-$(CONFIG_RTC_DRV_AB3100) += rtc-ab3100.o
obj-$(CONFIG_RTC_DRV_AB8500) += rtc-ab8500.o
obj-$(CONFIG_RTC_DRV_ABB5ZES3) += rtc-ab-b5ze-s3.o
+obj-$(CONFIG_RTC_DRV_ABX80X) += rtc-abx80x.o
obj-$(CONFIG_RTC_DRV_ARMADA38X)+= rtc-armada38x.o
obj-$(CONFIG_RTC_DRV_AS3722) += rtc-as3722.o
obj-$(CONFIG_RTC_DRV_AT32AP700X)+= rtc-at32ap700x.o
diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
new file mode 100644
index ..3d627f16cbac
--- /dev/null
+++ b/drivers/rtc/rtc-abx80x.c
@@ -0,0 +1,307 @@
+/*
+ * A driver for the I2C members of the Abracon AB x8xx RTC family,
+ * and compatible: AB 1805 and AB 0805
+ *
+ * Copyright 2014-2015 Macq S.A.
+ *
+ * Author: Philippe De Muyter
+ * Author: Alexandre Belloni
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#define ABX8XX_REG_HTH 0x00
+#define ABX8XX_REG_SC 0x01
+#define ABX8XX_REG_MN 0x02
+#define ABX8XX_REG_HR 0x03
+#define ABX8XX_REG_DA 0x04
+#define ABX8XX_REG_MO 0x05
+#define ABX8XX_REG_YR 0x06
+#define ABX8XX_REG_WD 0x07
+
+#define ABX8XX_REG_CTRL1 0x10
+#define ABX8XX_CTRL_WRITE BIT(1)
+#define ABX8XX_CTRL_12_24 BIT(6)
+
+#define ABX8XX_REG_CFG_KEY 0x1f
+#define ABX8XX_CFG_KEY_MISC0x9d
+
+#define ABX8XX_REG_ID0 0x28
+
+#define ABX8XX_REG_TRICKLE 0x20
+#define ABX8XX_TRICKLE_CHARGE_ENABLE 0xa0
+#define ABX8XX_TRICKLE_STANDARD_DIODE 0x8
+#define ABX8XX_TRICKLE_SCHOTTKY_DIODE 0x4
+
+static u8 trickle_resistors[] = {0, 3, 6, 11};
+
+enum abx80x_chip {AB0801, AB0803, AB0804, AB0805,
+ AB1801, AB1803, AB1804, AB1805, ABX80X};
+
+struct abx80x_cap {
+ u16 pn;
+ bool has_tc;
+};
+
+static struct abx80x_cap abx80x_caps[] = {
+ [AB0801] = {.pn = 0x0801},
+ [AB0803] = {.pn = 0x0803},
+ [AB0804] = {.pn = 0x0804, .has_tc = true},
+ [AB0805] = {.pn = 0x0805, .has_tc = true},
+ [AB1801] = {.pn = 0x1801},
+ [AB1803] = {.pn = 0x1803},
+ [AB1804] = {.pn = 0x1804, .has_tc = true},
+ [AB1805] = {.pn = 0x1805, .has_tc = true},
+ [ABX80X] = {.pn = 0}
+};
+
+static struct i2c_driver abx80x_driver;
+
+static int abx80x_enable_trickle_charger(struct i2c_client *client,
+u8 trickle_cfg)
+{
+ int err;
+
+ /*
+* Write the configuration key register to enable access to the Trickle
+* register
+*/
+ err = i2c_smbus_write_byte_data(client, ABX8XX_REG_CFG_KEY,
+ ABX8XX_CFG_KEY_MISC);
+ if (err < 0) {
+ dev_err(>dev, "Unable to write configuration key\n");
+ return -EIO;
+ }
+
+ err = i2c_smbus_write_byte_data(client, ABX8XX_REG_TRICKLE,
+ ABX8XX_TRICKLE_CHARGE_ENABLE |
+ trickle_cfg);
+ if (err < 0) {
+ dev_err(>dev, "Unable to write trickle register\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int abx80x_rtc_read_time(struct device *dev, struct
Re: [PATCH] sched/fair: Restore env status before goto redo in load_balance()
On 27 March 2015 at 23:30, Peter Zijlstra wrote:
> On Wed, Mar 18, 2015 at 02:31:02PM +0800, Xunlei Pang wrote:
>> From: Xunlei Pang
>>
>> In load_balance(), some members of lb_env will be assigned with
>> new values in LBF_DST_PINNED case. But lb_env::flags may still
>> retain LBF_ALL_PINNED if no proper tasks were found afterwards
>> due to another balance, task affinity changing, etc, which can
>> really happen because busiest rq lock has already been released.
>
> Sure..
>
>> This is wrong, for example with env.dst_cpu assigned new_dst_cpu
>> when going back to "redo" label, it may cause should_we_balance()
>> to return false which is unreasonable.
>
> Why? You've got a very unlikely, very hard case, its unlikely that
> anything we do will substantially improve the situation, but you make
> the code uglier for it.
>
>> This patch restores proper status of env before "goto redo", and
>> improves "out_all_pinned" and "out_one_pinned" labels.
>
> That doesn't even begin to explain half of what the patch does.
>
>> @@ -6977,12 +6978,19 @@ more_balance:
>> /* All tasks on this runqueue were pinned by CPU affinity */
>> if (unlikely(env.flags & LBF_ALL_PINNED)) {
>> cpumask_clear_cpu(cpu_of(busiest), cpus);
>> - if (!cpumask_empty(cpus)) {
>> - env.loop = 0;
>> - env.loop_break = sched_nr_migrate_break;
>> - goto redo;
>> + if (env.new_dst_cpu != -1) {
>
> I really don't get this, how can this not be?
>
>> + env.new_dst_cpu = -1;
>> + cpumask_or(cpus, cpus,
>> + sched_group_cpus(sd->groups));
>> + cpumask_and(cpus, cpus, cpu_active_mask);
>
> More unexplained magic, why is this right?
When LBF_DST_PINNED was set, after going back to "more_balance",
things may change as the changelog describes, so it can hit
LBF_ALL_PINNED afterwards. Then env.cpus, env.dst_rq, env.dst_cpu held
the values assigned in the LBF_DST_PINNED case which is unreasonable.
When we want to redo, we must reset those values.
>
> The rest of the patch isn't much better.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Mar 31 (build failures and culprits)
On 03/31/2015 07:24 PM, Guenter Roeck wrote: On 03/31/2015 04:42 PM, Stephen Rothwell wrote: Hi Greg, On Wed, 1 Apr 2015 01:07:49 +0200 Greg Kroah-Hartman wrote: On Tue, Mar 31, 2015 at 09:16:40AM -0700, Guenter Roeck wrote: alpha:allmodconfig mips:allmodconfig samples/kdbus/kdbus-workers.c: In function ‘prime_new’: samples/kdbus/kdbus-workers.c:930:18: error: ‘__NR_memfd_create’ undeclared (first use in this function) p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC); Looks like the kdbus example never worked for the affected architectures. I don't build allmodconfig for all architectures, so other architectures may be affected as well. You need 3.17 kernel headers to have memfd_create, not much the kdbus test code can do about that. You might want to update the kernel headers for these build boxes. Or have we not hooked up memfd for alpha and mips? alpha has no definition for __NR_memfd_create and doesn't use asm-generic/unistd.h. mips has a definition for __NR_memfd_create if _MIPS_SIM == _MIPS_SIM_ABI32, _MIPS_SIM_ABI64 or _MIPS_SIM_NABI32 (is there any other alternative?). Guess you are saying that those examples won't build even with a newer toolchain. Good that I already decided not to re-build my toolchains ;-). Now I am left with the question if the samples build should be masked for alpha and mips, or if I should drop building samples from my 'allmodconfig' builds. I think I'll do the latter; there seems to be an expectation that samples are built with a recent toolchain, and I can not keep rebuilding toolchains for the rest of my life. Weird - the kdbus sample doesn't have its own configuration option, unlike other samples. So it's all or nothing for alpha and mips. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/4] cgroups: add pids subsystem
On Wed, Apr 01, 2015 at 01:36:06PM +1100, Aleksa Sarai wrote: > Hi Tejun, > > I decided to send out this version of the patchset (that has the additional > callback, and passes around an opaque "fork state" inside the copy_process() > callback), because I personally prefer this version of the patchset (it's much > cleaner and doesn't mess around with the fork() callback for no good reason). > If you *really* want the other one, I can send it. Yes, please. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v4 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases
On 27 March 2015 at 23:28, Steven Rostedt wrote:
> On Mon, 9 Mar 2015 15:32:27 +0800
> Xunlei Pang wrote:
>
>> From: Xunlei Pang
>>
>> Currently, SMP RT scheduler has some trouble in dealing with
>> equal prio cases.
>>
>> For example, in check_preempt_equal_prio():
>> When RT1(current task) gets preempted by RT2, if there is a
>> migratable RT3 with same prio, RT3 will be pushed away instead
>> of RT1 afterwards, because RT1 will be enqueued to the tail of
>> the pushable list when going through succeeding put_prev_task_rt()
>> triggered by resched. This broke FIFO.
>>
>> Furthermore, this is also problematic for normal preempted cases
>> if there're some rt tasks queued with the same prio as current.
>> Because current will be put behind these tasks in the pushable
>> queue.
>>
>> So, if a task is running and gets preempted by a higher priority
>> task (or even with same priority for migrating), this patch ensures
>> that it is put ahead of any existing task with the same priority in
>> the pushable queue.
>>
>> Signed-off-by: Xunlei Pang
>> ---
>> kernel/sched/rt.c | 23 ---
>> 1 file changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
>> index f4d4b07..86cd79f 100644
>> --- a/kernel/sched/rt.c
>> +++ b/kernel/sched/rt.c
>> @@ -347,11 +347,15 @@ static inline void set_post_schedule(struct rq *rq)
>> rq->post_schedule = has_pushable_tasks(rq);
>> }
>>
>> -static void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
>> +static void enqueue_pushable_task(struct rq *rq,
>> + struct task_struct *p, bool head)
>
> Nit.
>
> static void
> enqueue_pushable_task(struct rq *rq, struct task_struct *p, bool head)
>
> Is a better breaking of the line.
I'll adjust it to be one line.
>
>> {
>> plist_del(>pushable_tasks, >rt.pushable_tasks);
>> plist_node_init(>pushable_tasks, p->prio);
>> - plist_add(>pushable_tasks, >rt.pushable_tasks);
>> + if (head)
>> + plist_add_head(>pushable_tasks, >rt.pushable_tasks);
>> + else
>> + plist_add_tail(>pushable_tasks, >rt.pushable_tasks);
>>
>> /* Update the highest prio pushable task */
>> if (p->prio < rq->rt.highest_prio.next)
>> @@ -373,7 +377,8 @@ static void dequeue_pushable_task(struct rq *rq, struct
>> task_struct *p)
>>
>> #else
>>
>> -static inline void enqueue_pushable_task(struct rq *rq, struct task_struct
>> *p)
>> +static inline void enqueue_pushable_task(struct rq *rq,
>> + struct task_struct *p, bool head)
>
> Same here.
>
>> {
>> }
>>
>> @@ -1248,7 +1253,7 @@ enqueue_task_rt(struct rq *rq, struct task_struct *p,
>> int flags)
>> enqueue_rt_entity(rt_se, flags & ENQUEUE_HEAD);
>>
>> if (!task_current(rq, p) && p->nr_cpus_allowed > 1)
>> - enqueue_pushable_task(rq, p);
>> + enqueue_pushable_task(rq, p, false);
>> }
>>
>> static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)
>> @@ -1494,8 +1499,12 @@ static void put_prev_task_rt(struct rq *rq, struct
>> task_struct *p)
>>* The previous task needs to be made eligible for pushing
>>* if it is still active
>>*/
>> - if (on_rt_rq(>rt) && p->nr_cpus_allowed > 1)
>> - enqueue_pushable_task(rq, p);
>> + if (on_rt_rq(>rt) && p->nr_cpus_allowed > 1) {
>> + if (task_running(rq, p) && (preempt_count() & PREEMPT_ACTIVE))
>
> put_prev_task_rt() is called by put_prev_task() which is called by
> several functions: rt_mutex_setprio(), __sched_setscheduler(),
> sched_setnuma(), migrate_tasks(), and sched_move_task(). It's not part
> of being preempted.
>
> Now it is also called by pick_next_task_rt() which I'm assuming is what
> you want it to affect.
>
> The above definitely needs a comment about what it is doing. Also, I'm
> not so sure we care about testing task_running(). I'm thinking the
> check for PREEMPT_ACTIVE is good enough, as that would only be set from
> being called within preempt_schedule().
Indeed.
>
> Also, we could get rid of the if statement and do:
>
> enqueue_pushable_task(rq, p, !!(preempt_count() & PREEMPT_ACTIVE));
Agree, will do. Thanks.
>
>
> -- Steve
>
>> + enqueue_pushable_task(rq, p, true);
>> + else
>> + enqueue_pushable_task(rq, p, false);
>> + }
>> }
>>
>> #ifdef CONFIG_SMP
>> @@ -1914,7 +1923,7 @@ static void set_cpus_allowed_rt(struct task_struct *p,
>> rq->rt.rt_nr_migratory--;
>> } else {
>> if (!task_current(rq, p))
>> - enqueue_pushable_task(rq, p);
>> + enqueue_pushable_task(rq, p, false);
>> rq->rt.rt_nr_migratory++;
>> }
>>
>
--
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
Re: [PATCH] powerpc: fix memory corruption by pnv_alloc_idle_core_states
On Tue, 2015-03-31 at 18:11 +0200, Jan Stancek wrote: > Space allocated for paca is based off nr_cpu_ids, > but pnv_alloc_idle_core_states() iterates paca with > cpu_nr_cores()*threads_per_core, which is using NR_CPUS. > > This causes pnv_alloc_idle_core_states() to write over memory, > which is outside of paca array and may later lead to various panics. > > Fixes: 7cba160ad789 (powernv/cpuidle: Redesign idle states management) > Signed-off-by: Jan Stancek Thanks. I'll send that to Linus in the next day or two and mark it for stable as well. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] Improve eye-diagram & single-ended test for rk3288 hdmi
Hi Russell, 在 2015/4/1 0:25, Russell King - ARM Linux 写道: On Mon, Mar 09, 2015 at 05:42:21PM +0800, Yakir Yang wrote: RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz, and single-ended test would failed when display mode is 74.25MHz. Has anyone reviewed these changes yet? I don't see any replies, nor are they in David's git tree. To me, they look mostly fine - the only issue I get is that the final patch doesn't apply cleanly to dw_hdmi.h since they're generated against a tree which has audio support merged. I also see no regressions on iMX6, so I think they can be merged. Unless anyone has any objections, I'll add these to my queue for David. Thanks. Wooh, thanks, I will send v4 now to improve the "drm: dw_hdmi/dw_hdmi-rockchip". Best regards, Yakir Yang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] drm: bridge/dw_hdmi_rockchip: improve hdmi eye-diagram test
Hi Russell, 在 2015/4/1 0:57, Russell King - ARM Linux 写道: On Mon, Mar 09, 2015 at 05:43:19PM +0800, Yakir Yang wrote: As for 1920x1080 display resolution, we should turn on the Transmitter Trailer-B. Signed-off-by: Yakir Yang --- BTW, one of: drm/rockchip: dw_hdmi-rockchip: ... drm/rockchip: dw_hdmi: ... drm: rockchip: dw_hdmi-rockchip: ... drm: rockchip: dw_hdmi: ... drm: rockchip/dw_hdmi-rockchip: ... drm: rockchip/dw_hdmi: ... might be a better subject line for patches which only touch the rockchip part of this driver. I'd also suggest one of: Okay, I choose the "drm: rockchip/dw_hdmi-rockchip: ...", improve in v4 Thanks Yakir Yang drm/imx: dw_hdmi-imx: ... drm/imx: dw_hdmi: ... drm: imx: dw_hdmi-imx: ... drm: imx: dw_hdmi: ... drm: imx/dw_hdmi-imx: ... drm: imx/dw_hdmi: ... for iMX-only patches. It doesn't really mater which as we already have a mixture of these formats already. -- 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 v7 0/4] cgroups: add pids subsystem
Hi Tejun, I decided to send out this version of the patchset (that has the additional callback, and passes around an opaque "fork state" inside the copy_process() callback), because I personally prefer this version of the patchset (it's much cleaner and doesn't mess around with the fork() callback for no good reason). If you *really* want the other one, I can send it. -- Aleksa Sarai (cyphar) www.cyphar.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/
