Re: [RESEND PATCH 2/4] ARM: msm: Re-organize platsmp to make it extensible
On Mon, 12 Aug 2013, Mark Rutland wrote:
> > static void __init msm_smp_prepare_cpus(unsigned int max_cpus)
> > {
> > + int cpu, map;
> > + unsigned int flags = 0;
> > +
> > + for_each_present_cpu(cpu) {
> > + map = cpu_logical_map(cpu);
> > + if (map > ARRAY_SIZE(cold_boot_flags)) {
> > + set_cpu_present(cpu, false);
> > + __WARN();
> > + continue;
> > + }
> > + flags |= cold_boot_flags[map];
__WARN() can't be used in generic code because it's possible to have
CONFIG_BUG=n, you probably want something like WARN_ON(1) instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Revert "Revert "math64: New div64_u64_rem helper""
On Fri, Aug 09, 2013 at 03:56:03PM -0400, Mike Snitzer wrote: > This reverts commit f3002134158092178be81339ec5a22ff80e6c308. > > div64_u64_rem was removed because there were no other users. > > But Device Mapper's I/O statistics support has a need for > div64_u64_rem; reintroduce this helper. This slows down div64_u64 operation, especially on 32-bit systems. Since dm statistic code is possibly not performance critical perhaps you could use something like below instead to calculate remainder: res = div64_u64(a, b); rem = a - b*res; Stanislaw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] nohz: Synchronize sleep time stats with seqlock
(2013年08月19日 20:10), Peter Zijlstra wrote: On Fri, Aug 16, 2013 at 06:46:28PM +0200, Frederic Weisbecker wrote: Option A: Should we flush that iowait to the src CPU? But then it means we must handle concurrent updates to iowait_sleeptime, idle_sleeptime from the migration code and from idle enter / exit. So I fear we need a seqlock. Option B: Or we can live with that and still account the whole idle time slept until tick_nohz_stop_idle() to iowait if we called tick_nohz_start_idle() with nr_iowait > 0. All we need is just a new field in ts-> that records on which state we entered idle. What do you think? I think option B is unworkable. Afaict it could basically caused unlimited iowait time. Suppose we have a load-balancer that tries it bestestest to sort-left (ie. run a task on the lowest 'free' cpu possible) -- the power aware folks are pondering such schemes. Now suppose we have a small burst of activity and the rightmost cpu gets to run something that goes to sleep on iowait. We'd accrue iowait on that cpu until it wakes up, which could be days from now if the load stays low enough, even though the task got to run almost instantly on another cpu. So no, if we need per-cpu iowait time we have to do A. Since we already have atomics in the io_schedule*() paths, please replace those with (seq)locks. Also see if you can place the entire iowait accounting thing in a separate cacheline. I considered option A for a while but, fearing it would be considered overkill, took a different approach: create a shadow copy of ->iowait_sleeptime that is always kept monotonic (artificially in some cases) and use that to compute the values exported through /proc. That said, if deemed acceptable, option A is the one I would choose. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: pm8921: include missing linux/module.h
Include in order to fix the following errors. drivers/mfd/pm8921-core.c:209:16: error: expected declaration specifiers or '...' before string constant drivers/mfd/pm8921-core.c:210:20: error: expected declaration specifiers or '...' before string constant drivers/mfd/pm8921-core.c:211:16: error: expected declaration specifiers or '...' before string constant drivers/mfd/pm8921-core.c:212:14: error: expected declaration specifiers or '...' before string constant Signed-off-by: Jingoo Han --- drivers/mfd/pm8921-core.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c index 9be6840..bd4b37c 100644 --- a/drivers/mfd/pm8921-core.c +++ b/drivers/mfd/pm8921-core.c @@ -14,6 +14,7 @@ #define pr_fmt(fmt) "%s: " fmt, __func__ #include +#include #include #include #include -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] nohz: Synchronize sleep time stats with seqlock
(2013年08月17日 01:46), Frederic Weisbecker wrote:
On Fri, Aug 16, 2013 at 06:26:54PM +0200, Oleg Nesterov wrote:
On 08/16, Frederic Weisbecker wrote:
On Fri, Aug 16, 2013 at 06:02:01PM +0200, Oleg Nesterov wrote:
+ do {
+ seq = read_seqcount_begin(&ts->sleeptime_seq);
+ if (ts->idle_active && nr_iowait_cpu(cpu) > 0) {
+ ktime_t delta = ktime_sub(now, ts->idle_entrytime);
+ iowait = ktime_add(ts->iowait_sleeptime, delta);
+ } else {
+ iowait = ts->iowait_sleeptime;
+ }
+ } while (read_seqcount_retry(&ts->sleeptime_seq, seq));
Unless I missread this patch, this is still racy a bit.
Suppose it is called on CPU_0 and cpu == 1. Suppose that
ts->idle_active == T and nr_iowait_cpu(cpu) == 1.
So we return iowait_sleeptime + delta.
Suppose that we call get_cpu_iowait_time_us() again. By this time
the task which incremented ->nr_iowait can be woken up on another
CPU, and it can do atomic_dec(rq->nr_iowait). So the next time
we return iowait_sleeptime, and this is not monotonic again.
Hmm, by the time it decrements nr_iowait, it returned from schedule() and
so idle had flushed the pending iowait sleeptime.
Suppose a task does io_schedule() on CPU_0, and increments the counter.
This CPU becomes idle and nr_iowait_cpu(0) == 1.
Then this task is woken up, but try_to_wake_up() selects another CPU != 0.
It returns from schedule() and decrements the same counter, it doesn't
do raw_rq/etc again. nr_iowait_cpu(0) becomes 0.
In fact the task can even migrate to another CPU right after raw_rq().
Ah I see now. So that indeed yet another race.
I am sorry for chiming in late.
That precisely the race I described here:
https://lkml.org/lkml/2013/7/2/3
I should have been more concise in my explanation. I apologize.
Should we flush that iowait to the src CPU? But then it means we must handle
concurrent updates to iowait_sleeptime, idle_sleeptime from the migration
code and from idle enter / exit.
So I fear we need a seqlock.
Or we can live with that and still account the whole idle time slept until
tick_nohz_stop_idle() to iowait if we called tick_nohz_start_idle() with nr_iowait
> 0.
All we need is just a new field in ts-> that records on which state we entered
idle.
Another approach could be to shadow ->iowait_sleeptime as
suggested here: https://lkml.org/lkml/2013/7/2/165
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: pm8921: use devm_*() functions
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/mfd/pm8921-core.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c
index 9a7c991..a6841f7 100644
--- a/drivers/mfd/pm8921-core.c
+++ b/drivers/mfd/pm8921-core.c
@@ -118,7 +118,7 @@ static int pm8921_probe(struct platform_device *pdev)
return -EINVAL;
}
- pmic = kzalloc(sizeof(struct pm8921), GFP_KERNEL);
+ pmic = devm_kzalloc(&pdev->dev, sizeof(struct pm8921), GFP_KERNEL);
if (!pmic) {
pr_err("Cannot alloc pm8921 struct\n");
return -ENOMEM;
@@ -128,7 +128,7 @@ static int pm8921_probe(struct platform_device *pdev)
rc = ssbi_read(pdev->dev.parent, REG_HWREV, &val, sizeof(val));
if (rc) {
pr_err("Failed to read hw rev reg %d:rc=%d\n", REG_HWREV, rc);
- goto err_read_rev;
+ return rc;
}
pr_info("PMIC revision 1: %02X\n", val);
rev = val;
@@ -138,7 +138,7 @@ static int pm8921_probe(struct platform_device *pdev)
if (rc) {
pr_err("Failed to read hw rev 2 reg %d:rc=%d\n",
REG_HWREV_2, rc);
- goto err_read_rev;
+ return rc;
}
pr_info("PMIC revision 2: %02X\n", val);
rev |= val << BITS_PER_BYTE;
@@ -160,8 +160,6 @@ static int pm8921_probe(struct platform_device *pdev)
err:
mfd_remove_devices(pmic->dev);
-err_read_rev:
- kfree(pmic);
return rc;
}
@@ -179,7 +177,6 @@ static int pm8921_remove(struct platform_device *pdev)
pm8xxx_irq_exit(pmic->irq_chip);
pmic->irq_chip = NULL;
}
- kfree(pmic);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mfd: pm8921: remove unnecessary platform_set_drvdata()
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han --- drivers/mfd/pm8921-core.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c index bd4b37c..9a7c991 100644 --- a/drivers/mfd/pm8921-core.c +++ b/drivers/mfd/pm8921-core.c @@ -160,7 +160,6 @@ static int pm8921_probe(struct platform_device *pdev) err: mfd_remove_devices(pmic->dev); - platform_set_drvdata(pdev, NULL); err_read_rev: kfree(pmic); return rc; @@ -180,7 +179,6 @@ static int pm8921_remove(struct platform_device *pdev) pm8xxx_irq_exit(pmic->irq_chip); pmic->irq_chip = NULL; } - platform_set_drvdata(pdev, NULL); kfree(pmic); return 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] mfd: max8997: use devm_*() functions
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/mfd/max8997.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/max8997.c b/drivers/mfd/max8997.c
index 1523047..cee098c 100644
--- a/drivers/mfd/max8997.c
+++ b/drivers/mfd/max8997.c
@@ -191,7 +191,8 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
struct max8997_platform_data *pdata = dev_get_platdata(&i2c->dev);
int ret = 0;
- max8997 = kzalloc(sizeof(struct max8997_dev), GFP_KERNEL);
+ max8997 = devm_kzalloc(&i2c->dev, sizeof(struct max8997_dev),
+ GFP_KERNEL);
if (max8997 == NULL)
return -ENOMEM;
@@ -203,14 +204,12 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
if (max8997->dev->of_node) {
pdata = max8997_i2c_parse_dt_pdata(max8997->dev);
- if (IS_ERR(pdata)) {
- ret = PTR_ERR(pdata);
- goto err;
- }
+ if (IS_ERR(pdata))
+ return PTR_ERR(pdata);
}
if (!pdata)
- goto err;
+ return ret;
max8997->pdata = pdata;
max8997->ono = pdata->ono;
@@ -250,8 +249,6 @@ err_mfd:
i2c_unregister_device(max8997->muic);
i2c_unregister_device(max8997->haptic);
i2c_unregister_device(max8997->rtc);
-err:
- kfree(max8997);
return ret;
}
@@ -263,7 +260,6 @@ static int max8997_i2c_remove(struct i2c_client *i2c)
i2c_unregister_device(max8997->muic);
i2c_unregister_device(max8997->haptic);
i2c_unregister_device(max8997->rtc);
- kfree(max8997);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] mfd: max8998: use devm_*() functions
Use devm_*() functions to make cleanup paths simpler. Signed-off-by: Jingoo Han --- drivers/mfd/max8998.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/mfd/max8998.c b/drivers/mfd/max8998.c index 45bffb8..fe6332d 100644 --- a/drivers/mfd/max8998.c +++ b/drivers/mfd/max8998.c @@ -188,7 +188,8 @@ static int max8998_i2c_probe(struct i2c_client *i2c, struct max8998_dev *max8998; int ret = 0; - max8998 = kzalloc(sizeof(struct max8998_dev), GFP_KERNEL); + max8998 = devm_kzalloc(&i2c->dev, sizeof(struct max8998_dev), + GFP_KERNEL); if (max8998 == NULL) return -ENOMEM; @@ -246,7 +247,6 @@ err: mfd_remove_devices(max8998->dev); max8998_irq_exit(max8998); i2c_unregister_device(max8998->rtc); - kfree(max8998); return ret; } @@ -257,7 +257,6 @@ static int max8998_i2c_remove(struct i2c_client *i2c) mfd_remove_devices(max8998->dev); max8998_irq_exit(max8998); i2c_unregister_device(max8998->rtc); - kfree(max8998); return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] mfd: menelaus: use devm_*() functions
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/mfd/menelaus.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index f24df8c..ad25bfa 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1197,7 +1197,7 @@ static int menelaus_probe(struct i2c_client *client,
return -ENODEV;
}
- menelaus = kzalloc(sizeof *menelaus, GFP_KERNEL);
+ menelaus = devm_kzalloc(&client->dev, sizeof(*menelaus), GFP_KERNEL);
if (!menelaus)
return -ENOMEM;
@@ -1210,8 +1210,7 @@ static int menelaus_probe(struct i2c_client *client,
rev = menelaus_read_reg(MENELAUS_REV);
if (rev < 0) {
pr_err(DRIVER_NAME ": device not found");
- err = -ENODEV;
- goto fail1;
+ return -ENODEV;
}
/* Ack and disable all Menelaus interrupts */
@@ -1231,7 +1230,7 @@ static int menelaus_probe(struct i2c_client *client,
if (err) {
dev_dbg(&client->dev, "can't get IRQ %d, err %d\n",
client->irq, err);
- goto fail1;
+ return err;
}
}
@@ -1242,7 +1241,7 @@ static int menelaus_probe(struct i2c_client *client,
val = menelaus_read_reg(MENELAUS_VCORE_CTRL1);
if (val < 0)
- goto fail2;
+ goto fail;
if (val & (1 << 7))
menelaus->vcore_hw_mode = 1;
else
@@ -1251,17 +1250,15 @@ static int menelaus_probe(struct i2c_client *client,
if (menelaus_pdata != NULL && menelaus_pdata->late_init != NULL) {
err = menelaus_pdata->late_init(&client->dev);
if (err < 0)
- goto fail2;
+ goto fail;
}
menelaus_rtc_init(menelaus);
return 0;
-fail2:
+fail:
free_irq(client->irq, menelaus);
flush_work(&menelaus->work);
-fail1:
- kfree(menelaus);
return err;
}
@@ -1271,7 +1268,6 @@ static int __exit menelaus_remove(struct i2c_client
*client)
free_irq(client->irq, menelaus);
flush_work(&menelaus->work);
- kfree(menelaus);
the_menelaus = NULL;
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] mfd: pcf50633-adc: use devm_*() functions
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/mfd/pcf50633-adc.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mfd/pcf50633-adc.c b/drivers/mfd/pcf50633-adc.c
index 18b53cb..b8941a5 100644
--- a/drivers/mfd/pcf50633-adc.c
+++ b/drivers/mfd/pcf50633-adc.c
@@ -203,7 +203,7 @@ static int pcf50633_adc_probe(struct platform_device *pdev)
{
struct pcf50633_adc *adc;
- adc = kzalloc(sizeof(*adc), GFP_KERNEL);
+ adc = devm_kzalloc(&pdev->dev, sizeof(*adc), GFP_KERNEL);
if (!adc)
return -ENOMEM;
@@ -236,7 +236,6 @@ static int pcf50633_adc_remove(struct platform_device *pdev)
kfree(adc->queue[i]);
mutex_unlock(&adc->queue_mutex);
- kfree(adc);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] mfd: tps65010: use devm_*() functions
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/mfd/tps65010.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/tps65010.c b/drivers/mfd/tps65010.c
index 8114567..743fb52 100644
--- a/drivers/mfd/tps65010.c
+++ b/drivers/mfd/tps65010.c
@@ -530,7 +530,6 @@ static int __exit tps65010_remove(struct i2c_client *client)
free_irq(client->irq, tps);
cancel_delayed_work_sync(&tps->work);
debugfs_remove(tps->file);
- kfree(tps);
the_tps = NULL;
return 0;
}
@@ -550,7 +549,7 @@ static int tps65010_probe(struct i2c_client *client,
if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -EINVAL;
- tps = kzalloc(sizeof *tps, GFP_KERNEL);
+ tps = devm_kzalloc(&client->dev, sizeof(*tps), GFP_KERNEL);
if (!tps)
return -ENOMEM;
@@ -568,7 +567,7 @@ static int tps65010_probe(struct i2c_client *client,
if (status < 0) {
dev_dbg(&client->dev, "can't get IRQ %d, err %d\n",
client->irq, status);
- goto fail1;
+ return status;
}
/* annoying race here, ideally we'd have an option
* to claim the irq now and enable it later.
@@ -668,9 +667,6 @@ static int tps65010_probe(struct i2c_client *client,
}
return 0;
-fail1:
- kfree(tps);
- return status;
}
static const struct i2c_device_id tps65010_id[] = {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] mfd: wl1273: use devm_*() functions
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/mfd/wl1273-core.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
index 1288e99..f7c52d9 100644
--- a/drivers/mfd/wl1273-core.c
+++ b/drivers/mfd/wl1273-core.c
@@ -172,12 +172,9 @@ static int wl1273_fm_set_volume(struct wl1273_core *core,
unsigned int volume)
static int wl1273_core_remove(struct i2c_client *client)
{
- struct wl1273_core *core = i2c_get_clientdata(client);
-
dev_dbg(&client->dev, "%s\n", __func__);
mfd_remove_devices(&client->dev);
- kfree(core);
return 0;
}
@@ -203,7 +200,7 @@ static int wl1273_core_probe(struct i2c_client *client,
return -EINVAL;
}
- core = kzalloc(sizeof(*core), GFP_KERNEL);
+ core = devm_kzalloc(&client->dev, sizeof(*core), GFP_KERNEL);
if (!core)
return -ENOMEM;
@@ -249,7 +246,6 @@ static int wl1273_core_probe(struct i2c_client *client,
err:
pdata->free_resources();
- kfree(core);
dev_dbg(&client->dev, "%s\n", __func__);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.11.0-rc6+: INFO: possible circular locking dependency detected
Miles Lane writes:
> [ 24.990076] [ INFO: possible circular locking dependency detected ]
> [ 24.990086] 3.11.0-rc6+ #154 Not tainted
> [ 24.990094] ---
> [ 24.990103] crda/1159 is trying to acquire lock:
> [ 24.990111] (genl_mutex){+.+.+.}, at: []
> genl_lock+0x12/0x14
> [ 24.990134]
> [ 24.990134] but task is already holding lock:
> [ 24.990144] (nlk->cb_mutex){+.+.+.}, at: []
> netlink_dump+0x1c/0x1da
Yes, me too... This is already discussed on netdev:
http://www.spinics.net/lists/stable/msg18179.html
But the fix is still out in the blue as far as I understand. Reverting
58ad436fc will fix it, but leave the original problem (missing locking)
unfixed.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/7] r8152: remove clearing the memory to zero for netdev priv
Series applied, thanks. Please, in the future, provide an initial "[PATCH 0/N] " posting which gives a general overview to the series, and to which I can apply when I have something to say about the series as a whole. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] mfd: twl6030-irq: rework and add twl6032 support
On 20/08/13 02:01, Samuel Ortiz wrote: Hi Grygorii, On Thu, Jul 25, 2013 at 04:15:46PM +0300, Grygorii Strashko wrote: This patch series intorduces twl6030-irq module rework to use Threaded IRQ and linear irq_domain, and adds support for PMIC TWL6032 IRQs. After this patch series TWL6030/6032 IRQs will be supported only for DT boot mode. Changes since v1: - Added new patch "mfd: twl6030-irq: create struct twl6030_irq" which introduces "struct twl6030_irq" to store all local variables inside it. - Patch "mfd: twl6030-irq: migrate to IRQ threaded handler": Minor comments applied; fixed twl6030_exit_irq(); The Parent IRQ has been set for each nested IRQ. - Patch "mfd: twl6030-irq: convert to use linear irq_domain": The irq_find_mapping() is used in twl6030_mmc_card_detect_config() to get virtual IRQ number. This looks good to me. Kevin, Graeme, any further comments/ACKs ? Cheers, Samuel. Yes, it looked good to me as well. Acked-by: Graeme Gregory 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 v2] max77693: added device tree support
On Mon, 19 Aug 2013, Stephen Warren wrote: > On 08/19/2013 05:40 AM, Andrzej Hajda wrote: > > max77693 mfd main device uses only wakeup field > > from max77693_platform_data. This field is mapped > > to wakeup-source common property in device tree. > > > diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt > > b/Documentation/devicetree/bindings/mfd/max77693.txt > > > Optional properties: > > - regulators : The regulators of max77693 have to be instantiated under > > subnod > >named "regulators" using the following format. > > +- wakeup-source : Indicates if the device can wakeup the system from the > > sleep > > + state. > > Does the property mean "can" or "should"? > > "Can" implies that the property means something about the HW. What > exactly does it mean; perhaps that some specific output pin of the chip > has been wired to an input IRQ/GPIO of the SoC or PMIC that (can) wake > up the system? If so, which pin, signal, ...? Also, doesn't this also > depend on the SoC itself supporting its input IRQ/GPIO as a wakeup > source, so isn't some co-ordination required between the SoC and chip, > such that this property doesn't mean "can wakeup the system", but simply > "a signal is routed to the SoC, so perhaps it can wakeup the system". > > "Should" implies policy, which probably shouldn't be represented in > device tree, since DT should describe the HW and not how it should be used. > > Finally, if there was already a binding for max77693.txt, I don't think > the patch subject "added device tree support" is entirely accurate; this > change to the binding document seems to be more about adding a new > feature than adding DT support to the driver... I'm taking this as a NACK. Once Stephen is happy I'll reapply any RESEND with his Ack. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.10.6-rt3
On 08/20/2013 03:02 AM, Steven Rostedt wrote: > Looking at it more, I can now see why they did what they did. He is the only user in the whole kernel. It is somehow hard to believe that it can't be solved differently. > -- Steve Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop
(2013/08/19 23:30), James Bottomley wrote: On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote: Hello, This patch adds scsi device failfast mode to avoid infinite retry loop. Currently, scsi error handling in scsi_decide_disposition() and scsi_io_completion() unconditionally retries on some errors. This is because retryable errors are thought to be temporary and the scsi device will soon recover from those errors. Normally, such retry policy is appropriate because the device will soon recover from temporary error state. But there is no guarantee that device is able to recover from error state immediately. Some hardware error may prevent device from recovering. Therefore hardware error can results in infinite command retry loop. In fact, CHECK_CONDITION error with the sense-key = UNIT_ATTENTION caused infinite retry loop in our environment. As the comments in kernel source code says, UNIT_ATTENTION means the device must have been a power glitch and expected to immediately recover from the state. But it seems that hardware error caused permanent UNIT_ATTENTION error. To solve the above problem, this patch introduces scsi device "failfast mode". If failfast mode is enabled, retry counts of all scsi commands are limited to scsi->allowed(== SD_MAX_RETRIES == 5). All commands are prohibited to retry infinitely, and immediately fails when the retry count exceeds upper limit. Failfast mode is useful on mission critical systems which are required to keep running flawlessly because they need to failover to the secondary system once they detect failures. On default, failfast mode is disabled because failfast policy is not suitable for most use cases which can accept I/O latency due to device hardware error. To enable failfast mode(default disabled): # echo 1> /sys/bus/scsi/devices/X:X:X:X/failfast To disable: # echo 0> /sys/bus/scsi/devices/X:X:X:X/failfast Furthermore, I'm planning to make the upper limit count configurable. Currently, I have two plans to implement it: (1) set same upper limit count on all errors. (2) set upper limit count on each error. The first implementation is simple and easy to implement but not flexible. Someone wants to set different upper limit count on each errors depends on the scsi device they use. The second implementation satisfies such requirement but can be too fine-grained and annoying to configure because scsi error codes are so much. The default 5 times retry may too much on some errors but too few on other errors. Which would be the appropriate implementation? Any comments or suggestions are welcome as usual. I'm afraid you'll need to propose another solution. We have a large selection of commands which, by design, retry until the command exceeds it's timeout. UA is one of those (as are most of the others you're limiting). How do you kick this device out of its UA return (because that's the recovery that needs to happen)? James Thanks for reviewing, James. Originally, I planned that once the retry count exceeds its limit, a monitoring tool stops the server with the scsi prink error message as a trigger. Current failfast mode implementation is that the command fails when retry command exceeds its limit. However, I noticed that only printing error messages on retry counts excess without changing retry logic will be enough to stop the server and take fail over. Though there is no guarantee that userspace application can work properly on disk failure condition. So, now I'm considering that just calling panic() on retry excess is better. For that reason, I propose the solution that adding "panic_on_error" option to sysfs parameter and if panic_on_error mode is enabled the server panics immediately once it detects retry excess. Of course, it is disabled on default. I would appreciate it if you could give me some comments. Eiichi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [3.10] Oopses in kmem_cache_allocate() via prepare_creds()
We are also seeing this or a similar issue. On a fairly widespread deployment of 3.10.1 & 3.10.6 this occurred fairly consistently on the order of 36 days (combined MTBF.) [28974.739774] [ cut here ] [28974.744980] kernel BUG at mm/slub.c:3352! [28974.749502] invalid opcode: [#1] SMP [28974.754143] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler dm_mod md_mod nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6table_raw ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack iptable_filter xt_tcpudp xt_CT nf_conntrack xt_multiport iptable_raw ip_tables x_tables rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 fuse nfsv3 nfs_acl nfs fscache lockd sunrpc bonding tcp_cubic sg sfc(O) mtd mdio igb dca i2c_algo_bit i2c_core ptp pps_core coretemp kvm_intel kvm crc32c_intel aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 acpi_cpufreq evdev sd_mod crc_t10dif snd_pcm tpm_tis microcode tpm snd_timer tpm_bios snd soundcore snd_page_alloc pcspkr ahci libahci uhci_hcd ehci_pci ehci_hcd lpc_ich libata mfd_core usbcore usb_common hpsa scsi_mod mperf button processor thermal_sys [28974.835407] CPU: 17 PID: 21400 Comm: nginx-fl Tainted: G O 3.10.1-cloudflare-trace+ #2 [28974.845307] Hardware name: HP ProLiant DL180 G6 , BIOS O20 01/24/2011 [28974.852653] task: 8805bea7b390 ti: 8809a5f0e000 task.ti: 8809a5f0e000 [28974.861095] RIP: 0010:[] [] kfree+0x59/0xe7 [28974.869453] RSP: 0018:8809a5f0fe30 EFLAGS: 00010246 [28974.875434] RAX: RBX: 880b21e79d40 RCX: 0028 [28974.883458] RDX: 006ffc080068 RSI: 0001183c RDI: ea002c879e40 [28974.891483] RBP: ea002c879e40 R08: 00017100 R09: ea0009ea0480 [28974.899507] R10: 880ae9746250 R11: R12: 81119456 [28974.907533] R13: 000a R14: 8809a5f0ff48 R15: 00013b80 [28974.915558] FS: 7fb36c115710() GS:880627d6() knlGS: [28974.924681] CS: 0010 DS: ES: CR0: 80050033 [28974.931149] CR2: ff600400 CR3: 000761b93000 CR4: 07e0 [28974.939173] DR0: DR1: DR2: [28974.947190] DR3: DR6: 0ff0 DR7: 0400 [28974.955205] Stack: [28974.957486] 880a3e72a700 0001183c 81119456 [28974.965873] 8809a5f0fe48 880b21e79d40 c350 [28974.974253] 8809a5f0fec0 8802b4781bc0 0200 811d96eb [28974.982646] Call Trace: [28974.985419] [] ? do_readv_writev+0xfc/0x135 [28974.991987] [] ? ep_poll+0x215/0x286 [28974.997875] [] ? fget_light+0x2e/0x7c [28975.003861] [] ? fdget+0x16/0x1c [28975.009359] [] ? SyS_readv+0x5a/0xb0 [28975.015245] [] ? SyS_epoll_wait+0x86/0xc1 [28975.021622] [] ? system_call_fastpath+0x16/0x1b [28975.028578] Code: 48 83 fb 10 0f 86 aa 00 00 00 48 89 df e8 8c de ff ff 48 89 c7 48 89 c5 e8 b5 d7 ff ff 85 c0 75 22 48 f7 45 00 00 c0 00 00 75 02 <0f> 0b 48 89 ef e8 a8 d7 ff ff 5b 48 89 ef 89 c6 5d 41 5c e9 9a [28975.050651] RIP [] kfree+0x59/0xe7 [28975.056354] RSP [28975.062479] ---[ end trace 29f90372a2c3b0ac ]--- The machine hobbles along until all processes crash at this point. [14064.855658] = [14064.864884] BUG kmalloc-192 (Tainted: GW ): Poison overwritten [14064.872424] - [14064.872424] [14064.883322] Disabling lock debugging due to kernel taint [14064.889304] INFO: 0x880930a54824-0x880930a54824. First byte 0x6c instead of 0x6b [14064.898433] INFO: Allocated in alloc_pipe_info+0x17/0x94 age=80 cpu=8 pid=28897 [14064.906684] set_track+0x5c/0xd7 [14064.910332] alloc_debug_processing+0x76/0xfd [14064.915250] __slab_alloc+0x3e0/0x417 [14064.919386] alloc_inode+0x26/0x6c [14064.923232] alloc_pipe_info+0x17/0x94 [14064.927467] kmem_cache_alloc_trace+0xbe/0x14e [14064.932486] alloc_pipe_info+0x17/0x94 [14064.936721] alloc_pipe_info+0x17/0x94 [14064.940956] create_pipe_files+0x3c/0x1e5 [14064.945481] __do_pipe_flags+0x23/0xa7 [14064.949718] SyS_pipe2+0x18/0x86 [14064.953374] system_call_fastpath+0x16/0x1b [14064.958098] INFO: Freed in pipe_release+0xc4/0xcd age=76 cpu=23 pid=28897 [14064.965740] set_track+0x5c/0xd7 [14064.969389] free_debug_processing+0x11d/0x1a9 [14064.974391] __slab_free+0x32/0x30a [14064.978334] free_pages_prepare+0x104/0x128 [14064.983053] pipe_release+0xc4/0xcd [14064.986991] __fput+0xe1/0x1e4 [14064.990443] task_work_run+0x7b/0x8f [14064.994482] do_notify_resume+0x59/0x68 [14064.998816] int_signal+0x12/0x17 [14065.002561] INFO: Slab 0xea0024c29500 objects=31 used=28 fp=0x880930a570c0 flags=0x6ffc004080 [14065.013341] INFO: Object 0x880930a54820 @offset=2080 fp=0x880930a55040 [14065.023177] Bytes b4 880930a54810:
linux-next: build failure after merge of the final tree
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_parse_options':
arch/powerpc/platforms/cell/spufs/inode.c:623:16: error: incompatible types
when assigning to type 'kuid_t' from type 'int'
root->i_uid = option;
^
arch/powerpc/platforms/cell/spufs/inode.c:628:16: error: incompatible types
when assigning to type 'kgid_t' from type 'int'
root->i_gid = option;
^
Caused by commit d6970d4b726c ("enable building user namespace with xfs")
from the xfs tree (that was fun to find :-)).
I have reverted that commit for today. It could probably be replaced
with a patch that just changed XFS_FS to SPU_FS in the UIDGID_CONVERTED
config dependency - or someone could fix up SPU_FS.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp76bN7QaNKk.pgp
Description: PGP signature
Re: [3.10] Oopses in kmem_cache_allocate() via prepare_creds()
On Tue, Aug 20, 2013 at 12:17:52AM -0700, Ian Applegate wrote: > We are also seeing this or a similar issue. On a fairly widespread > deployment of 3.10.1 & 3.10.6 this occurred fairly consistently on the > order of 36 days (combined MTBF.) Do you have any boxen with CONFIG_DEBUG_MUTEXES among those? What kind of setup do you have on those, BTW? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] seq_file: Fix overflow condition in seq_commit
Hi Al Viro,
On Tue, Aug 20, 2013 at 11:21 AM, Al Viro wrote:
> On Tue, Aug 20, 2013 at 10:55:40AM +0530, Arun KS wrote:
>> >From 932a134abeac597f18c86c513704709ad154994b Mon Sep 17 00:00:00 2001
>> From: Arun KS
>> Date: Mon, 19 Aug 2013 12:06:33 +0530
>> Subject: seq_file: Fix overflow condition in seq_commit
>>
>> seq_path()/seq_commit() is treating a d_path() failure as an overflow
>> condition, but it isn't.
>>
>> seq_read handles overflow by reallocating more buffer. And this
>> continues in a loop utill we increase the size of seq buf beyond
>> KMALLOC_MAX_SIZE and hence a WARN_ON.
>>
>> [ 363.192565] [ cut here ]
>> [ 363.199462] WARNING: at mm/slab_common.c:377 kmalloc_slab+0x34/0x9c()
>> [ 363.208557] Modules linked in:
>> [ 363.212219] CPU: 1 PID: 1742 Comm: Binder_2 Tainted: GW3.10.0+ #17
>> [ 363.222930] [] (unwind_backtrace+0x0/0x11c)
>> from[] (show_stack+0x10/0x14)
>> [ 363.235229] [] (show_stack+0x10/0x14) from
>> [](warn_slowpath_common+0x4c/0x68)
>> [ 363.247253] [] (warn_slowpath_common+0x4c/0x68)
>> from[] (warn_slowpath_null+0x18/0x1c)
>> [ 363.259307] [] (warn_slowpath_null+0x18/0x1c)
>> from[] (kmalloc_slab+0x34/0x9c)
>> [ 363.270812] [] (kmalloc_slab+0x34/0x9c) from
>> [](__kmalloc+0x14/0x1fc)
>> [ 363.281433] [] (__kmalloc+0x14/0x1fc) from
>> [](seq_read+0x24c/0x438)
>> [ 363.291992] [] (seq_read+0x24c/0x438) from
>> [](vfs_read+0xac/0x124)
>> [ 363.302398] [] (vfs_read+0xac/0x124) from
>> [](SyS_read+0x3c/0x60)
>> [ 363.312591] [] (SyS_read+0x3c/0x60) from
>> [](ret_fast_syscall+0x0/0x48)
>> [ 363.323303] ---[ end trace 46c6467e2db7bcd4 ]---
>>
>> Pass -ENOBUFS to seq_commit to signal an overflow condition and a
>> negative value for all other errors.
>
> Excuse me, _what_ other errors? Please, explain what errors can
> be returned by d_path/__d_path/dentry_path. Normally all of those
> return ERR_PTR(-ENAMETOOLONG) if the pathname to be generated would
> not fit into a buffer. In which case the only sane behaviour is
> to use a bigger buffer.
d_path expects the pathname to be less than 64 bytes. If its more than
64, it returns -ENAMETOOLONG.
File:fs/dcache.c
char *dynamic_dname(struct dentry *dentry, char *buffer, int buflen,
const char *fmt, ...)
{
va_list args;
char temp[64];
int sz;
va_start(args, fmt);
sz = vsnprintf(temp, sizeof(temp), fmt, args) + 1;
va_end(args);
if (sz > sizeof(temp) || sz > buflen)
return ERR_PTR(-ENAMETOOLONG);
buffer += buflen - sz;
return memcpy(buffer, temp, sz);
}
The string name which give error is,
"dev/ashmem/CursorWindow:
/data/data/com.android.providers.settings/databases/settings.db"
when sz>sizeof(temp), dynamic_dname returns -ENAMETOOLONG.
In this instance, sz is coming as 100.
This always happens from shared mem, after shmem_dname function was
added by the following commit.
commit 3451538a114d738a6528b1da58e19e7d8964c647
Author: Al Viro
Date: Thu Feb 14 22:38:02 2013 -0500
shmem_setup_file(): use d_alloc_pseudo() instead of d_alloc()
Note that provided ->d_dname() reproduces what we used to get for
those guys in e.g. /proc/self/maps; it might be a good idea to change
that to something less ugly, but for now let's keep the existing
user-visible behaviour
Signed-off-by: Al Viro
Thanks,
Arun
>
> Could you please post the reproducer for that trace of yours?
> I might be missing something obvious, of course, but AFAICS you
> are just papering over a bug somewhere else. If you really
> manage to get d_path() with output that wouldn't fit into 128Mb,
> you have a whole lot of unpleasant problems beyond a warning in
> seq_read(). And silent truncation of pathnames that don't happen
> to fit into what's left of the default buffer is simply wrong -
> 4095-byte pathnames are perfectly fine.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acpi_i2c: set MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION
On Mon, Aug 19, 2013 at 08:34:03PM -0700, Jerry Snitselaar wrote: > On Tue Aug 20 13, Rafael J. Wysocki wrote: > > On Monday, August 19, 2013 04:35:29 PM Jerry Snitselaar wrote: > > > On Tue Aug 20 13, Rafael J. Wysocki wrote: > > > > On Monday, August 19, 2013 09:16:14 AM Mika Westerberg wrote: > > > > > On Fri, Aug 16, 2013 at 06:26:35PM -0700, Jerry Snitselaar wrote: > > > > > > Without MODULE_LICENSE set, I get the following with modprobe: > > > > > > > > > > > > acpi_i2c: module license 'unspecified' taints kernel. > > > > > > acpi_i2c: Unknown symbol i2c_new_device (err 0) > > > > > > acpi_i2c: Unknown symbol acpi_dev_get_resources (err 0) > > > > > > acpi_i2c: Unknown symbol acpi_dev_resource_interrupt (err 0) > > > > > > acpi_i2c: Unknown symbol acpi_dev_free_resource_list (err 0) > > > > > > > > > > > > Signed-off-by: Jerry Snitselaar > > > > > > > > > > Looks good to me. > > > > > > > > > > Acked-by: Mika Westerbeg > > > > > > > > Well, OK, but do we need to be able to build that as a module? > > > > > > > > Maybe it should just be yes or no? > > > > > > > > Rafael > > > > > > > > > > Perhaps have depends on I2C=y and be a bool instead of tristate? > > > > Yes, that's the idea. > > > Does this look okay Mika? > > [PATCH] acpi_i2c: do not build as loadable module > > Change from tristate to bool, and depend on I2C=y I'm not sure about this. Does the below mean that we can't build the ACPI I2C enumeration at all if I2C core is compiled as module? > > Signed-off-by: Jerry Snitselaar > --- > drivers/acpi/Kconfig | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index 100bd72..183a309 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -181,8 +181,9 @@ config ACPI_DOCK > drive bays such as the IBM Ultrabay and the Dell Module Bay. > > config ACPI_I2C > - def_tristate I2C > - depends on I2C > + bool "I2C" > + depends on I2C=y > + default n > help > ACPI I2C enumeration support. > > -- > 1.8.4.rc3.2.g2c2b664 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/17] ARM: imx: remove custom .init_time hook
On Tue, Aug 20, 2013 at 04:04:20AM +0200, Sebastian Hesselbarth wrote:
> With arch/arm calling of_clk_init(NULL) from time_init(), we can now
> remove custom .init_time hooks.
>
> Signed-off-by: Sebastian Hesselbarth
> ---
> Notes:
> - Although mx5_clocks_common_init() is shared with non-DT, removing
> of_clk_init(NULL) should be fine, as it only registers DT clk providers.
> - For imx6q, printing of silicon revision has been moved from .init_time
> to .init_machine hook.
>
> Cc: Russell King
> Cc: Arnd Bergmann
> Cc: Sascha Hauer
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/mach-imx/clk-imx51-imx53.c | 12
> arch/arm/mach-imx/common.h |2 --
> arch/arm/mach-imx/imx51-dt.c|6 --
> arch/arm/mach-imx/mach-imx53.c |6 --
> arch/arm/mach-imx/mach-imx6q.c | 14 +++---
> arch/arm/mach-imx/mach-imx6sl.c |7 ---
> arch/arm/mach-imx/mach-vf610.c |9 -
> 7 files changed, 3 insertions(+), 53 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c
> b/arch/arm/mach-imx/clk-imx51-imx53.c
> index 1a56a33..5955a54 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -131,8 +131,6 @@ static void __init mx5_clocks_common_init(unsigned long
> rate_ckil,
> {
> int i;
>
> - of_clk_init(NULL);
> -
> clk[dummy] = imx_clk_fixed("dummy", 0);
> clk[ckil] = imx_obtain_fixed_clock("ckil", rate_ckil);
> clk[osc] = imx_obtain_fixed_clock("osc", rate_osc);
> @@ -569,13 +567,3 @@ int __init mx53_clocks_init(unsigned long rate_ckil,
> unsigned long rate_osc,
>
> return 0;
> }
> -
> -int __init mx51_clocks_init_dt(void)
> -{
> - return mx51_clocks_init(0, 0, 0, 0);
> -}
> -
> -int __init mx53_clocks_init_dt(void)
> -{
> - return mx53_clocks_init(0, 0, 0, 0);
> -}
> diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
> index 4517fd7..0ce8313 100644
> --- a/arch/arm/mach-imx/common.h
> +++ b/arch/arm/mach-imx/common.h
> @@ -68,8 +68,6 @@ extern int mx53_clocks_init(unsigned long ckil, unsigned
> long osc,
> extern int mx25_clocks_init_dt(void);
> extern int mx27_clocks_init_dt(void);
> extern int mx31_clocks_init_dt(void);
> -extern int mx51_clocks_init_dt(void);
> -extern int mx53_clocks_init_dt(void);
> extern struct platform_device *mxc_register_gpio(char *name, int id,
> resource_size_t iobase, resource_size_t iosize, int irq, int irq_high);
> extern void mxc_set_cpu_type(unsigned int type);
> diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
> index 53e43e5..bece8a6 100644
> --- a/arch/arm/mach-imx/imx51-dt.c
> +++ b/arch/arm/mach-imx/imx51-dt.c
> @@ -34,17 +34,11 @@ static const char *imx51_dt_board_compat[] __initdata = {
> NULL
> };
>
> -static void __init imx51_timer_init(void)
> -{
> - mx51_clocks_init_dt();
> -}
> -
> DT_MACHINE_START(IMX51_DT, "Freescale i.MX51 (Device Tree Support)")
> .map_io = mx51_map_io,
> .init_early = imx51_init_early,
> .init_irq = mx51_init_irq,
> .handle_irq = imx51_handle_irq,
> - .init_time = imx51_timer_init,
On i.MX5 the init_time hook calls mx5x_clocks_init_dt which calls
mx5x_clocks_init which not only calls of_clk_init() but also registers
all clocks in the system. You can't remove it.
I am missing some
CLK_OF_DECLARE(imx51, "fsl,imx51-ccm", imx51_clocks_init);
CLK_OF_DECLARE(imx53, "fsl,imx53-ccm", imx53_clocks_init);
Somewhere.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: pm8921: include missing linux/module.h
On Tue, 20 Aug 2013, Jingoo Han wrote: > Include in order to fix the following errors. > > drivers/mfd/pm8921-core.c:209:16: error: expected declaration specifiers or > '...' before string constant > drivers/mfd/pm8921-core.c:210:20: error: expected declaration specifiers or > '...' before string constant > drivers/mfd/pm8921-core.c:211:16: error: expected declaration specifiers or > '...' before string constant > drivers/mfd/pm8921-core.c:212:14: error: expected declaration specifiers or > '...' before string constant > > Signed-off-by: Jingoo Han Patches look good to me 1-3 applied. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 94fc5d9: chromium-sandbox core dumped
Hi Linus, On Tue, Aug 20, 2013 at 1:26 AM, Linus Torvalds wrote: > On Mon, Aug 19, 2013 at 1:25 PM, Linus Torvalds > wrote: >> >> I suspect that last "return 0" at the end should be "return 1". Does >> that fix things for you? Untested. > > Ok. Confirmed. I reproduced the bug that Richard Genoud fixed, and > also verified that yes, changing that last "return 0" in > proc_readdir_de() to "return 1" fixes the bug that Emmanuel reported. > Although I just did it with a special test-program using different > getdents buffer sizes, so I didn't verify the particular Chromium > breakage, but that does look like it's the same issue. Just to confirm it does fix the chromium issue as well. Thanks. -- Emmanuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/34] 3.4.59-stable review
> > [ 26/34] genetlink: fix family dump race > > Johannes, another strike against this patch :( > > Any chance on fixing it upstream and me sucking that fix in? Yeah, I'm trying to get that, but it's not clear to me how to fix it. Where did you apply it? It was going to need some fixes but when the first objection was raised I figured you were going to drop it for now completely? Sorry for the mess :-( johannes -- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
linux-next: Tree for Aug 20
Hi all, Changes since 20130819: The xfs tree gained a build failure for which I reverted a commit. The libata tree lost its build failure. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 222 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (fd3930f proc: more readdir conversion bug-fixes) Merging fixes/master (b3a3a9c Merge tag 'trace-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1) Merging arc-current/for-curr (c095ba7 Linux 3.11-rc4) Merging arm-current/fixes (e1f0203 Merge branch 'security-fixes' into fixes) Merging m68k-current/for-linus (ea077b1 m68k: Truncate base in do_div()) Merging metag-fixes/fixes (dfe248b MAINTAINERS: add linux-metag mailing list) Merging powerpc-merge/merge (28e61cc powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs) Merging sparc/master (1c2696c sparc64: Fix ITLB handler of null page) Merging net/master (0f7dd1a Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux) Merging ipsec/master (844d487 xfrm: choose protocol family by skb protocol) Merging sound-current/for-linus (d3d3835 ALSA: hda - Add inverted digital mic fixup for Acer Aspire One) Merging pci-current/for-linus (36dd1f3 PCI: mvebu: Disable prefetchable memory support in PCI-to-PCI bridge) Merging wireless/master (48c3e37 Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (5ae90d8 Linux 3.11-rc3) Merging tty.current/tty-linus (c095ba7 Linux 3.11-rc4) Merging usb.current/usb-linus (b36f4be Linux 3.11-rc6) Merging staging.current/staging-linus (d4e4ab8 Linux 3.11-rc5) Merging char-misc.current/char-misc-linus (b36f4be Linux 3.11-rc6) Merging input-current/for-linus (88ce3c3 Merge branch 'next' into for-linus) Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' and 'recovery'.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (e70308e Revert "crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform framework") Merging ide/master (6d128e1 Revert "Makefile: Fix install error with make -j option") Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct resource to 0 in of_irq_to_resource()) Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32) Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work without pdata) Merging vfio-fixes/for-linus (d24cdbf vfio-pci: Avoid deadlock on remove) Merging drm-intel-fixes/drm-intel-fixes (884020b drm/i915: Invalidate TLBs for the rings after a reset) Merging asm-generic/master (fb9de7e xtensa: Use generic asm/mmu.h for nommu) Merging arc/for-next (a00b92e ARC: [ASID] Optimize the threads-of-process switching case) Merging arm/for-next (2c5d489 Merge branch '
Re: [PATCH v1] seq_file: Fix overflow condition in seq_commit
On Tue, Aug 20, 2013 at 12:51:56PM +0530, Arun KS wrote:
> d_path expects the pathname to be less than 64 bytes. If its more than
> 64, it returns -ENAMETOOLONG.
?!?!? d_path() does not expect anything of that sort - it can very
well produce names much longer, without ENAMETOOLONG.
> char *dynamic_dname(struct dentry *dentry, char *buffer, int buflen,
> const char *fmt, ...)
> {
> va_list args;
> char temp[64];
> int sz;
>
> va_start(args, fmt);
> sz = vsnprintf(temp, sizeof(temp), fmt, args) + 1;
> va_end(args);
>
> if (sz > sizeof(temp) || sz > buflen)
> return ERR_PTR(-ENAMETOOLONG);
>
> buffer += buflen - sz;
> return memcpy(buffer, temp, sz);
> }
Aha. _That_ is a bug, all right - dynamic_dname() is simply not suitable
for that kind of uses. ashmem.c is certainly abusing shmem_file_setup();
feeding that kind of mess as dentry name is a Bad Idea(tm). Anyway,
I'd suggest this for a fix:
va_list args;
size_t sz;
va_start(args, fmt);
sz = vsnprintf(NULL, 0, fmt, args) + 1;
va_end(args);
if (sz > buflen)
return ERR_PTR(-ENAMETOOLONG);
va_start(args, fmt);
buffer += buflen - sz;
vsprintf(buffer, fmt, args);
va_end(args);
return buffer;
Either right in dynamic_dname(), or as possibly_fucking_long_dname(),
to be used by shmem.c...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] mfd: max8997: use devm_*() functions
> Use devm_*() functions to make cleanup paths simpler. > > Signed-off-by: Jingoo Han Patches look good to me 1-6 applied. By the way, when you're sending patch-sets would you mind adding a cover letter? Or at least thread patches 2-n on to patch 1. It just makes them easier to track if they receive comments. If you don't already, send your patches with `git send-mail` and try playing around with: --thread (turns on threading) and --[no-]chain-reply-to (controlls shallow and deep threading) to find your preference. Cover letters are added with --compose and for convenience you can annotate them with, surprise surprise --annotate. :) -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()
On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
> On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
>>
>>> sure you'll have to change shmem_show_mpol statement to return int code.
>>> Won't this be more short and convenient?
>>>
>>>
>>
>> Hmm... if return -ENOSPC, in common processing, it still need continue
>> (but need let outside know about the string truncation).
>>
>> So I still suggest to give more check for it.
>
> I still don't like adding additional code like
>
> + ret = mpol_to_str(buffer, sizeof(buffer), mpol);
> + if (ret < 0)
> + switch (ret) {
> + case -ENOSPC:
> + printk(KERN_WARNING
> + "in %s: string is truncated in
> mpol_to_str().\n",
> + __func__);
> + default:
> + printk(KERN_ERR
> + "in %s: call mpol_to_str() fail, errcode: %d.
> buffer: %p, size: %zu, pol: %p\n",
> + __func__, ret, buffer, sizeof(buffer), mpol);
> + return;
> + }
>
> this code is pretty neat for debugging purpose I think but in most case (if
> only I've not missed something obvious) it simply won't be the case.
>
For mpol_to_str(), it is for printing string, I suggest to fill buffer
as full as possible like another printing string functions, -ENOSPC is
not critical error, callers may can bear it, and still want to continue.
For 2 callers, I still suggest to process '-ENOSPC' and continue, it is
really not a critical error, they can continue.
For the 'default' error processing:
I still suggest to 'printk' in shmem_show_mpol(), because when failure
occurs, it has no return value to mark the failure to upper caller.
Hmm... but for show_numa_map(), may remove the 'printk', only return the
error code is OK. :-)
Thanks.
> Won't somthing like below do the same but with smaller code change?
> Note I've not even compiled it but it shows the idea.
> ---
> fs/proc/task_mmu.c |4 +++-
> mm/shmem.c | 17 +
> 2 files changed, 12 insertions(+), 9 deletions(-)
>
> Index: linux-2.6.git/fs/proc/task_mmu.c
> ===
> --- linux-2.6.git.orig/fs/proc/task_mmu.c
> +++ linux-2.6.git/fs/proc/task_mmu.c
> @@ -1402,8 +1402,10 @@ static int show_numa_map(struct seq_file
> walk.mm = mm;
>
> pol = get_vma_policy(task, vma, vma->vm_start);
> - mpol_to_str(buffer, sizeof(buffer), pol);
> + n = mpol_to_str(buffer, sizeof(buffer), pol);
> mpol_cond_put(pol);
> + if (n < 0)
> + return n;
>
> seq_printf(m, "%08lx %s", vma->vm_start, buffer);
>
> Index: linux-2.6.git/mm/shmem.c
> ===
> --- linux-2.6.git.orig/mm/shmem.c
> +++ linux-2.6.git/mm/shmem.c
> @@ -883,16 +883,20 @@ redirty:
>
> #ifdef CONFIG_NUMA
> #ifdef CONFIG_TMPFS
> -static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
> +static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
> {
> char buffer[64];
> + int ret;
>
> if (!mpol || mpol->mode == MPOL_DEFAULT)
> - return; /* show nothing */
> + return 0; /* show nothing */
>
> - mpol_to_str(buffer, sizeof(buffer), mpol);
> + ret = mpol_to_str(buffer, sizeof(buffer), mpol);
> + if (ret < 0)
> + return ret;
>
> seq_printf(seq, ",mpol=%s", buffer);
> + return 0;
> }
>
> static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
> @@ -951,9 +955,7 @@ static struct page *shmem_alloc_page(gfp
> }
> #else /* !CONFIG_NUMA */
> #ifdef CONFIG_TMPFS
> -static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy
> *mpol)
> -{
> -}
> +static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy
> *mpol) { return 0; }
> #endif /* CONFIG_TMPFS */
>
> static inline struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp,
> @@ -2577,8 +2579,7 @@ static int shmem_show_options(struct seq
> if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
> seq_printf(seq, ",gid=%u",
> from_kgid_munged(&init_user_ns, sbinfo->gid));
> - shmem_show_mpol(seq, sbinfo->mpol);
> - return 0;
> + return shmem_show_mpol(seq, sbinfo->mpol);
> }
> #endif /* CONFIG_TMPFS */
>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [3.10] Oopses in kmem_cache_allocate() via prepare_creds()
Unfortunately no boxen with CONFIG_DEBUG_MUTEXES among them. I can enable on a few and should have some results within the day. These mainly serve (quite a bit of) HTTP/S cache traffic. On Tue, Aug 20, 2013 at 12:21 AM, Al Viro wrote: > On Tue, Aug 20, 2013 at 12:17:52AM -0700, Ian Applegate wrote: >> We are also seeing this or a similar issue. On a fairly widespread >> deployment of 3.10.1 & 3.10.6 this occurred fairly consistently on the >> order of 36 days (combined MTBF.) > > Do you have any boxen with CONFIG_DEBUG_MUTEXES among those? What > kind of setup do you have on those, BTW? > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()
On 08/20/2013 03:48 PM, Chen Gang wrote:
> On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
>> On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
>>>
sure you'll have to change shmem_show_mpol statement to return int code.
Won't this be more short and convenient?
>>>
>>> Hmm... if return -ENOSPC, in common processing, it still need continue
>>> (but need let outside know about the string truncation).
>>>
>>> So I still suggest to give more check for it.
>>
>> I still don't like adding additional code like
>>
>> +ret = mpol_to_str(buffer, sizeof(buffer), mpol);
>> +if (ret < 0)
>> + switch (ret) {
>> + case -ENOSPC:
>> + printk(KERN_WARNING
>> + "in %s: string is truncated in
>> mpol_to_str().\n",
>> + __func__);
Oh, that need 'break' in my original patch. :-)
>> + default:
>> + printk(KERN_ERR
>> + "in %s: call mpol_to_str() fail, errcode:
>> %d. buffer: %p, size: %zu, pol: %p\n",
>> + __func__, ret, buffer, sizeof(buffer), mpol);
>> + return;
>> + }
>>
>> this code is pretty neat for debugging purpose I think but in most case (if
>> only I've not missed something obvious) it simply won't be the case.
>>
>
> For mpol_to_str(), it is for printing string, I suggest to fill buffer
> as full as possible like another printing string functions, -ENOSPC is
> not critical error, callers may can bear it, and still want to continue.
>
> For 2 callers, I still suggest to process '-ENOSPC' and continue, it is
> really not a critical error, they can continue.
>
> For the 'default' error processing:
>
> I still suggest to 'printk' in shmem_show_mpol(), because when failure
> occurs, it has no return value to mark the failure to upper caller.
> Hmm... but for show_numa_map(), may remove the 'printk', only return the
> error code is OK. :-)
>
>
> Thanks.
>
>> Won't somthing like below do the same but with smaller code change?
>> Note I've not even compiled it but it shows the idea.
>> ---
>> fs/proc/task_mmu.c |4 +++-
>> mm/shmem.c | 17 +
>> 2 files changed, 12 insertions(+), 9 deletions(-)
>>
>> Index: linux-2.6.git/fs/proc/task_mmu.c
>> ===
>> --- linux-2.6.git.orig/fs/proc/task_mmu.c
>> +++ linux-2.6.git/fs/proc/task_mmu.c
>> @@ -1402,8 +1402,10 @@ static int show_numa_map(struct seq_file
>> walk.mm = mm;
>>
>> pol = get_vma_policy(task, vma, vma->vm_start);
>> -mpol_to_str(buffer, sizeof(buffer), pol);
>> +n = mpol_to_str(buffer, sizeof(buffer), pol);
>> mpol_cond_put(pol);
>> +if (n < 0)
>> +return n;
>>
>> seq_printf(m, "%08lx %s", vma->vm_start, buffer);
>>
>> Index: linux-2.6.git/mm/shmem.c
>> ===
>> --- linux-2.6.git.orig/mm/shmem.c
>> +++ linux-2.6.git/mm/shmem.c
>> @@ -883,16 +883,20 @@ redirty:
>>
>> #ifdef CONFIG_NUMA
>> #ifdef CONFIG_TMPFS
>> -static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
>> +static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
>> {
>> char buffer[64];
>> +int ret;
>>
>> if (!mpol || mpol->mode == MPOL_DEFAULT)
>> -return; /* show nothing */
>> +return 0; /* show nothing */
>>
>> -mpol_to_str(buffer, sizeof(buffer), mpol);
>> +ret = mpol_to_str(buffer, sizeof(buffer), mpol);
>> +if (ret < 0)
>> +return ret;
>>
>> seq_printf(seq, ",mpol=%s", buffer);
>> +return 0;
>> }
>>
>> static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
>> @@ -951,9 +955,7 @@ static struct page *shmem_alloc_page(gfp
>> }
>> #else /* !CONFIG_NUMA */
>> #ifdef CONFIG_TMPFS
>> -static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy
>> *mpol)
>> -{
>> -}
>> +static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy
>> *mpol) { return 0; }
>> #endif /* CONFIG_TMPFS */
>>
>> static inline struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp,
>> @@ -2577,8 +2579,7 @@ static int shmem_show_options(struct seq
>> if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
>> seq_printf(seq, ",gid=%u",
>> from_kgid_munged(&init_user_ns, sbinfo->gid));
>> -shmem_show_mpol(seq, sbinfo->mpol);
>> -return 0;
>> +return shmem_show_mpol(seq, sbinfo->mpol);
>> }
>> #endif /* CONFIG_TMPFS */
>>
>>
>>
>
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: m25p80: add support for mr25h10
From: Markus Niebel
This adds support for the Everspin mr25h10 MRAM chip to the m25p80
driver.
Signed-off-by: Sascha Hauer
---
drivers/mtd/devices/m25p80.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 6f93d32..a48f152 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -743,6 +743,7 @@ static const struct spi_device_id m25p_ids[] = {
/* Everspin */
{ "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, M25P_NO_ERASE |
M25P_NO_FR) },
+ { "mr25h10", CAT25_INFO(128 * 1024, 1, 256, 3, M25P_NO_ERASE |
M25P_NO_FR) },
/* GigaDevice */
{ "gd25q32", INFO(0xc84016, 0, 64 * 1024, 64, SECT_4K) },
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] m25p80 / fast read
Changes since v1: - rebase on git.infradead.org/l2-mtd.git - improve description for patch 2/3 Sascha Markus Niebel (1): mtd: m25p80: add support for mr25h10 Sascha Hauer (2): mtd: m25p80: Pass flags through CAT25_INFO macro mtd: m25p80: make CONFIG_M25PXX_USE_FAST_READ safe to enable drivers/mtd/devices/m25p80.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mtd: m25p80: make CONFIG_M25PXX_USE_FAST_READ safe to enable
This patch adds a flag to struct flash_info indicating that
fast_read is not supported. This now gives the following logic
when determing whether to enable fastread:
If the flash chip does not support fast_read, then disable it.
Otherwise:
1) enable fast_read if device node contains m25p,fast-read
2) enable fast_read if forced in Kconfig
This makes enabling CONFIG_M25PXX_USE_FAST_READ a safe option
since we no longer enable the fast_read option unconditionally.
For now fast_read is disabled for the everspin mr25h256 and the
catalyst devices. Others may need the flag aswell.
Signed-off-by: Sascha Hauer
---
drivers/mtd/devices/m25p80.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 0b8672b..6f93d32 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -691,6 +691,7 @@ struct flash_info {
#defineSECT_4K 0x01/* OPCODE_BE_4K works uniformly
*/
#defineM25P_NO_ERASE 0x02/* No erase command needed */
#defineSST_WRITE 0x04/* use SST byte programming */
+#defineM25P_NO_FR 0x08/* Can't do fastread */
};
#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
@@ -741,7 +742,7 @@ static const struct spi_device_id m25p_ids[] = {
{ "en25qh256", INFO(0x1c7019, 0, 64 * 1024, 512, 0) },
/* Everspin */
- { "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, M25P_NO_ERASE) },
+ { "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, M25P_NO_ERASE |
M25P_NO_FR) },
/* GigaDevice */
{ "gd25q32", INFO(0xc84016, 0, 64 * 1024, 64, SECT_4K) },
@@ -856,11 +857,11 @@ static const struct spi_device_id m25p_ids[] = {
{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K) },
/* Catalyst / On Semiconductor -- non-JEDEC */
- { "cat25c11", CAT25_INFO( 16, 8, 16, 1, M25P_NO_ERASE) },
- { "cat25c03", CAT25_INFO( 32, 8, 16, 2, M25P_NO_ERASE) },
- { "cat25c09", CAT25_INFO( 128, 8, 32, 2, M25P_NO_ERASE) },
- { "cat25c17", CAT25_INFO( 256, 8, 32, 2, M25P_NO_ERASE) },
- { "cat25128", CAT25_INFO(2048, 8, 64, 2, M25P_NO_ERASE) },
+ { "cat25c11", CAT25_INFO( 16, 8, 16, 1, M25P_NO_ERASE | M25P_NO_FR) },
+ { "cat25c03", CAT25_INFO( 32, 8, 16, 2, M25P_NO_ERASE | M25P_NO_FR) },
+ { "cat25c09", CAT25_INFO( 128, 8, 32, 2, M25P_NO_ERASE | M25P_NO_FR) },
+ { "cat25c17", CAT25_INFO( 256, 8, 32, 2, M25P_NO_ERASE | M25P_NO_FR) },
+ { "cat25128", CAT25_INFO(2048, 8, 64, 2, M25P_NO_ERASE | M25P_NO_FR) },
{ },
};
MODULE_DEVICE_TABLE(spi, m25p_ids);
@@ -1044,6 +1045,8 @@ static int m25p_probe(struct spi_device *spi)
#ifdef CONFIG_M25PXX_USE_FAST_READ
flash->fast_read = true;
#endif
+ if (info->flags & M25P_NO_FR)
+ flash->fast_read = false;
/* Default commands */
if (flash->fast_read)
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: m25p80: Pass flags through CAT25_INFO macro
The flags may have to be overwritten, so add them to the CAT25_INFO
macro.
Signed-off-by: Sascha Hauer
---
drivers/mtd/devices/m25p80.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 35d5851..0b8672b 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -703,13 +703,13 @@ struct flash_info {
.flags = (_flags), \
})
-#define CAT25_INFO(_sector_size, _n_sectors, _page_size, _addr_width) \
+#define CAT25_INFO(_sector_size, _n_sectors, _page_size, _addr_width, _flags)
\
((kernel_ulong_t)&(struct flash_info) { \
.sector_size = (_sector_size), \
.n_sectors = (_n_sectors), \
.page_size = (_page_size), \
.addr_width = (_addr_width),\
- .flags = M25P_NO_ERASE, \
+ .flags = (_flags), \
})
/* NOTE: double check command sets and memory organization when you add
@@ -741,7 +741,7 @@ static const struct spi_device_id m25p_ids[] = {
{ "en25qh256", INFO(0x1c7019, 0, 64 * 1024, 512, 0) },
/* Everspin */
- { "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2) },
+ { "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, M25P_NO_ERASE) },
/* GigaDevice */
{ "gd25q32", INFO(0xc84016, 0, 64 * 1024, 64, SECT_4K) },
@@ -856,11 +856,11 @@ static const struct spi_device_id m25p_ids[] = {
{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K) },
/* Catalyst / On Semiconductor -- non-JEDEC */
- { "cat25c11", CAT25_INFO( 16, 8, 16, 1) },
- { "cat25c03", CAT25_INFO( 32, 8, 16, 2) },
- { "cat25c09", CAT25_INFO( 128, 8, 32, 2) },
- { "cat25c17", CAT25_INFO( 256, 8, 32, 2) },
- { "cat25128", CAT25_INFO(2048, 8, 64, 2) },
+ { "cat25c11", CAT25_INFO( 16, 8, 16, 1, M25P_NO_ERASE) },
+ { "cat25c03", CAT25_INFO( 32, 8, 16, 2, M25P_NO_ERASE) },
+ { "cat25c09", CAT25_INFO( 128, 8, 32, 2, M25P_NO_ERASE) },
+ { "cat25c17", CAT25_INFO( 256, 8, 32, 2, M25P_NO_ERASE) },
+ { "cat25128", CAT25_INFO(2048, 8, 64, 2, M25P_NO_ERASE) },
{ },
};
MODULE_DEVICE_TABLE(spi, m25p_ids);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] acpi_i2c: set MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION
On Tue Aug 20 13, Mika Westerberg wrote: > On Mon, Aug 19, 2013 at 08:34:03PM -0700, Jerry Snitselaar wrote: > > On Tue Aug 20 13, Rafael J. Wysocki wrote: > > > On Monday, August 19, 2013 04:35:29 PM Jerry Snitselaar wrote: > > > > On Tue Aug 20 13, Rafael J. Wysocki wrote: > > > > > On Monday, August 19, 2013 09:16:14 AM Mika Westerberg wrote: > > > > > > On Fri, Aug 16, 2013 at 06:26:35PM -0700, Jerry Snitselaar wrote: > > > > > > > Without MODULE_LICENSE set, I get the following with modprobe: > > > > > > > > > > > > > > acpi_i2c: module license 'unspecified' taints kernel. > > > > > > > acpi_i2c: Unknown symbol i2c_new_device (err 0) > > > > > > > acpi_i2c: Unknown symbol acpi_dev_get_resources (err 0) > > > > > > > acpi_i2c: Unknown symbol acpi_dev_resource_interrupt (err 0) > > > > > > > acpi_i2c: Unknown symbol acpi_dev_free_resource_list (err 0) > > > > > > > > > > > > > > Signed-off-by: Jerry Snitselaar > > > > > > > > > > > > Looks good to me. > > > > > > > > > > > > Acked-by: Mika Westerbeg > > > > > > > > > > Well, OK, but do we need to be able to build that as a module? > > > > > > > > > > Maybe it should just be yes or no? > > > > > > > > > > Rafael > > > > > > > > > > > > > Perhaps have depends on I2C=y and be a bool instead of tristate? > > > > > > Yes, that's the idea. > > > > > Does this look okay Mika? > > > > [PATCH] acpi_i2c: do not build as loadable module > > > > Change from tristate to bool, and depend on I2C=y > > I'm not sure about this. Does the below mean that we can't build the ACPI > I2C enumeration at all if I2C core is compiled as module? Yes, that was what Rafael was suggesting. If the ability to compile as a module if I2C is a module is needed, then we need the 1st patch. Jerry > > > > > Signed-off-by: Jerry Snitselaar > > --- > > drivers/acpi/Kconfig | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > > index 100bd72..183a309 100644 > > --- a/drivers/acpi/Kconfig > > +++ b/drivers/acpi/Kconfig > > @@ -181,8 +181,9 @@ config ACPI_DOCK > > drive bays such as the IBM Ultrabay and the Dell Module Bay. > > > > config ACPI_I2C > > - def_tristate I2C > > - depends on I2C > > + bool "I2C" > > + depends on I2C=y > > + default n > > help > > ACPI I2C enumeration support. > > > > -- > > 1.8.4.rc3.2.g2c2b664 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: bcache: Fix a writeback performance regression
Am 20.08.2013 00:27, schrieb Kent Overstreet: > On Mon, Aug 19, 2013 at 12:09:24AM +0200, Stefan Priebe wrote: >> >> Vanilla 3.10.7 + bcache: Fix a writeback performance regression >> >> http://pastebin.com/raw.php?i=LXZk4cMH > > Whoops, at first I thought this was the same bug as one I'd already been > chasing down that had been a harmless bug - turns out I didn't look > closely enough at the backtrace. > > What happened is background writeback is deadlocking, because for some > reason the workqueue it's running out of is a singlethreaded workqueue, > so as soon as it decides to queue enough writeback bios that it has to > sleep on that semaphore (which often won't happen due to the PD > controller based ratelimiting) - boom, deadlock. > > Here's the fixup patch I just tested and am applying: thanks, this works fine. The only issue i still have, is that the dirty_date value starts at 0 and goes to a negative value after reboot. Greets, Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ATTEND] oops.kernel.org prospect
On Mon, Aug 19, 2013 at 05:25:12PM -0400, Dave Jones wrote: > On Mon, Aug 19, 2013 at 05:52:02PM +0200, Anton Arapov wrote: > > On Mon, Aug 19, 2013 at 11:39:39AM -0400, Theodore Ts'o wrote: > > > On Mon, Aug 19, 2013 at 05:16:43PM +0200, Anton Arapov wrote: > > > > > Why not just do that through email? You'll reach a much wider group > of > > > > > people than the tiny 80 developers at the conference. > > > > > > > > Ouch! Someone to take it as replacement of email - the least I wanted. > It will > > > > go email-way in either case. > > > > > > > > These tiny 80 may give the most valuable feedback on the topic. And > often > > > > it is the most difficult to get attention of them, especially via > email. > > > > In case it fits the conference, it could dilute the heavy topics. > > > > > > Usyually the best thing to do is to start the discussion on the > > > mailing list (and we can do that on ksummit-2013-discuss, but this is > > > always why it's sometimes useful to cc lkml on topic proposals, so we > > > can jump start the discussion), and see if it's controversial or not. > > > > Oh well,... I didn't have a time for this right now, nor project is > > not exactly in the state I'm willing to show (mostly webui) > > > > // CC'd: lkml (please don't complain on styles yet, focus on functionality) > > I stumbled across this a week or so ago, and had some thoughts back then, > but didn't mail them anywhere because I wasn't sure who ran it, and couldn't > tell how far along it was. > > Quick brain dump > > * Visiting it with chromium gets an annoying warning about the https server > ... [snip] > ... > Dave Thanks, Dave! Will be fixed and improved. Anton. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] seq_file: Fix overflow condition in seq_commit
Hi Al Viro,
On Tue, Aug 20, 2013 at 1:06 PM, Al Viro wrote:
> On Tue, Aug 20, 2013 at 12:51:56PM +0530, Arun KS wrote:
>
>> d_path expects the pathname to be less than 64 bytes. If its more than
>> 64, it returns -ENAMETOOLONG.
>
> ?!?!? d_path() does not expect anything of that sort - it can very
> well produce names much longer, without ENAMETOOLONG.
>
>> char *dynamic_dname(struct dentry *dentry, char *buffer, int buflen,
>> const char *fmt, ...)
>> {
>> va_list args;
>> char temp[64];
>> int sz;
>>
>> va_start(args, fmt);
>> sz = vsnprintf(temp, sizeof(temp), fmt, args) + 1;
>> va_end(args);
>>
>> if (sz > sizeof(temp) || sz > buflen)
>> return ERR_PTR(-ENAMETOOLONG);
>>
>> buffer += buflen - sz;
>> return memcpy(buffer, temp, sz);
>> }
>
> Aha. _That_ is a bug, all right - dynamic_dname() is simply not suitable
> for that kind of uses. ashmem.c is certainly abusing shmem_file_setup();
> feeding that kind of mess as dentry name is a Bad Idea(tm). Anyway,
> I'd suggest this for a fix:
>
> va_list args;
> size_t sz;
> va_start(args, fmt);
> sz = vsnprintf(NULL, 0, fmt, args) + 1;
> va_end(args);
> if (sz > buflen)
> return ERR_PTR(-ENAMETOOLONG);
> va_start(args, fmt);
> buffer += buflen - sz;
> vsprintf(buffer, fmt, args);
> va_end(args);
> return buffer;
>
> Either right in dynamic_dname(), or as possibly_fucking_long_dname(),
> to be used by shmem.c...
This fixes the problem.
Thanks,
Arun
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAX7301 GPIO: Reverting "Do not force SPI speed when using OF Platform"
On 08/20/2013 08:29 AM, Christophe Leroy wrote: > This patch reverts commit 047b93a35961f7a6561e6f5dcb040738f822b892 which > breaks > MAX7301 GPIO driver because that commit was dependant on a rejected patch that > was implementing selection of SPI speed from the Device Tree. > > Signed-off-by: Christophe Leroy Acked-by: Roland Stigge Good, thanks! > > --- linux-3.11-rc6/drivers/gpio/gpio-max7301.c2013-08-17 > 21:09:17.0 +0200 > +++ linux/drivers/gpio/gpio-max7301.c 2013-08-18 06:31:52.0 +0200 > @@ -56,8 +56,7 @@ > int ret; > > /* bits_per_word cannot be configured in platform data */ > - if (spi->dev.platform_data) > - spi->bits_per_word = 16; > + spi->bits_per_word = 16; > ret = spi_setup(spi); > if (ret < 0) > 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: bcache: Fix a writeback performance regression
Am 20.08.2013 10:01, schrieb Stefan Priebe - Profihost AG: > Am 20.08.2013 00:27, schrieb Kent Overstreet: >> On Mon, Aug 19, 2013 at 12:09:24AM +0200, Stefan Priebe wrote: >>> >>> Vanilla 3.10.7 + bcache: Fix a writeback performance regression >>> >>> http://pastebin.com/raw.php?i=LXZk4cMH >> >> Whoops, at first I thought this was the same bug as one I'd already been >> chasing down that had been a harmless bug - turns out I didn't look >> closely enough at the backtrace. >> >> What happened is background writeback is deadlocking, because for some >> reason the workqueue it's running out of is a singlethreaded workqueue, >> so as soon as it decides to queue enough writeback bios that it has to >> sleep on that semaphore (which often won't happen due to the PD >> controller based ratelimiting) - boom, deadlock. >> >> Here's the fixup patch I just tested and am applying: Oh i'm now seeing very high CPU spikes of kworker... i don't see if i remove bcache: Fix a writeback performance regression. Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] ARC fixes for 3.9/3.10 stable backport
Hi, Please apply the following 2 patches to 3.9/3.10 series. They have been extracted out of mainline patches which can't be individually backported due to other dependencies (please see respective changelogs for references). Thx, -Vineet Vineet Gupta (2): ARC: gdbserver breakage in Big-Endian configuration #1 ARC: gdbserver breakage in Big-Endian configuration #2 arch/arc/include/asm/ptrace.h | 2 ++ arch/arc/include/asm/syscall.h | 5 ++--- arch/arc/kernel/entry.S| 4 ++-- 3 files changed, 6 insertions(+), 5 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acpi_i2c: set MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION
On Tue, Aug 20, 2013 at 01:00:08AM -0700, Jerry Snitselaar wrote: > On Tue Aug 20 13, Mika Westerberg wrote: > > On Mon, Aug 19, 2013 at 08:34:03PM -0700, Jerry Snitselaar wrote: > > > On Tue Aug 20 13, Rafael J. Wysocki wrote: > > > > On Monday, August 19, 2013 04:35:29 PM Jerry Snitselaar wrote: > > > > > On Tue Aug 20 13, Rafael J. Wysocki wrote: > > > > > > On Monday, August 19, 2013 09:16:14 AM Mika Westerberg wrote: > > > > > > > On Fri, Aug 16, 2013 at 06:26:35PM -0700, Jerry Snitselaar wrote: > > > > > > > > Without MODULE_LICENSE set, I get the following with modprobe: > > > > > > > > > > > > > > > > acpi_i2c: module license 'unspecified' taints kernel. > > > > > > > > acpi_i2c: Unknown symbol i2c_new_device (err 0) > > > > > > > > acpi_i2c: Unknown symbol acpi_dev_get_resources (err 0) > > > > > > > > acpi_i2c: Unknown symbol acpi_dev_resource_interrupt (err 0) > > > > > > > > acpi_i2c: Unknown symbol acpi_dev_free_resource_list (err 0) > > > > > > > > > > > > > > > > Signed-off-by: Jerry Snitselaar > > > > > > > > > > > > > > Looks good to me. > > > > > > > > > > > > > > Acked-by: Mika Westerbeg > > > > > > > > > > > > Well, OK, but do we need to be able to build that as a module? > > > > > > > > > > > > Maybe it should just be yes or no? > > > > > > > > > > > > Rafael > > > > > > > > > > > > > > > > Perhaps have depends on I2C=y and be a bool instead of tristate? > > > > > > > > Yes, that's the idea. > > > > > > > Does this look okay Mika? > > > > > > [PATCH] acpi_i2c: do not build as loadable module > > > > > > Change from tristate to bool, and depend on I2C=y > > > > I'm not sure about this. Does the below mean that we can't build the ACPI > > I2C enumeration at all if I2C core is compiled as module? > > Yes, that was what Rafael was suggesting. If the ability to compile as > a module if I2C is a module is needed, then we need the 1st patch. In that case I would prefer the first patch. Otherwise we lose the ability to enumerate I2C devices from ACPI namespace on some distros (at least Debian builds I2C core as a module). Rafael? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARC: gdbserver breakage in Big-Endian configuration #1
[Based on mainline commit 502a0c775c7f0a: "ARC: pt_regs update #5"]
gdbserver needs @stop_pc, served by ptrace, but fetched from pt_regs
differently, based on in_brkpt_traps(), which in turn relies on
additional machine state in pt_regs->event bitfield.
unsigned long orig_r8:16, event:16;
For big endian config, this macro was returning false, despite being in
breakpoint Trap exception, causing wrong @stop_pc to be returned to gdb.
Issue #1: In BE, @event above is at offset 2 in word, while a STW insn
at offset 0 was used to update it. Resort to using ST insn
which updates the half-word at right location.
Issue #2: The union involving bitfields causes all the members to be
laid out at offset 0. So with fix #1 above, ASM was now
updating at offset 2, "C" code was still referencing at
offset 0. Fixed by wrapping bitfield in a struct.
Reported-by: Noam Camus
Cc: # [3.9 and 3.10 only]
Tested-by: Anton Kolesov
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/ptrace.h | 2 ++
arch/arc/kernel/entry.S | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
index 6179de7..2046a89 100644
--- a/arch/arc/include/asm/ptrace.h
+++ b/arch/arc/include/asm/ptrace.h
@@ -52,12 +52,14 @@ struct pt_regs {
/*to distinguish bet excp, syscall, irq */
union {
+ struct {
#ifdef CONFIG_CPU_BIG_ENDIAN
/* so that assembly code is same for LE/BE */
unsigned long orig_r8:16, event:16;
#else
unsigned long event:16, orig_r8:16;
#endif
+ };
long orig_r8_word;
};
};
diff --git a/arch/arc/kernel/entry.S b/arch/arc/kernel/entry.S
index 7b5f3ec..724de08 100644
--- a/arch/arc/kernel/entry.S
+++ b/arch/arc/kernel/entry.S
@@ -498,7 +498,7 @@ tracesys_exit:
trap_with_param:
; stop_pc info by gdb needs this info
- stw orig_r8_IS_BRKPT, [sp, PT_orig_r8]
+ st orig_r8_IS_BRKPT, [sp, PT_orig_r8]
mov r0, r12
lr r1, [efa]
@@ -727,7 +727,7 @@ not_exception:
; things to what they were, before returning from L2 context
;
- ldw r9, [sp, PT_orig_r8] ; get orig_r8 to make sure it is
+ ld r9, [sp, PT_orig_r8] ; get orig_r8 to make sure it is
brne r9, orig_r8_IS_IRQ2, 149f ; infact a L2 ISR ret path
ld r9, [sp, PT_status32] ; get statu32_l2 (saved in pt_regs)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARC: gdbserver breakage in Big-Endian configuration #2
[Based on mainline commit 352c1d95e3220d0: "ARC: stop using
pt_regs->orig_r8"]
Stop using orig_r8 as it could get clobbered by ST in trap_with_param,
and further it is semantically not needed either.
Signed-off-by: Vineet Gupta
---
arch/arc/include/asm/syscall.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arc/include/asm/syscall.h b/arch/arc/include/asm/syscall.h
index 33ab304..29de098 100644
--- a/arch/arc/include/asm/syscall.h
+++ b/arch/arc/include/asm/syscall.h
@@ -18,7 +18,7 @@ static inline long
syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
{
if (user_mode(regs) && in_syscall(regs))
- return regs->orig_r8;
+ return regs->r8;
else
return -1;
}
@@ -26,8 +26,7 @@ syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
static inline void
syscall_rollback(struct task_struct *task, struct pt_regs *regs)
{
- /* XXX: I can't fathom how pt_regs->r8 will be clobbered ? */
- regs->r8 = regs->orig_r8;
+ regs->r0 = regs->orig_r0;
}
static inline long
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()
On 08/20/2013 03:51 PM, Chen Gang wrote:
> On 08/20/2013 03:48 PM, Chen Gang wrote:
>> On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
>>> On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
> sure you'll have to change shmem_show_mpol statement to return int code.
> Won't this be more short and convenient?
>
>
Hmm... if return -ENOSPC, in common processing, it still need continue
(but need let outside know about the string truncation).
So I still suggest to give more check for it.
>>>
>>> I still don't like adding additional code like
>>>
>>> + ret = mpol_to_str(buffer, sizeof(buffer), mpol);
>>> + if (ret < 0)
>>> + switch (ret) {
>>> + case -ENOSPC:
>>> + printk(KERN_WARNING
>>> + "in %s: string is truncated in
>>> mpol_to_str().\n",
>>> + __func__);
>
> Oh, that need 'break' in my original patch. :-)
>
>>> + default:
>>> + printk(KERN_ERR
>>> + "in %s: call mpol_to_str() fail, errcode:
>>> %d. buffer: %p, size: %zu, pol: %p\n",
>>> + __func__, ret, buffer, sizeof(buffer),
>>> mpol);
>>> + return;
>>> + }
>>>
>>> this code is pretty neat for debugging purpose I think but in most case (if
>>> only I've not missed something obvious) it simply won't be the case.
>>>
>>
>> For mpol_to_str(), it is for printing string, I suggest to fill buffer
>> as full as possible like another printing string functions, -ENOSPC is
>> not critical error, callers may can bear it, and still want to continue.
>>
>> For 2 callers, I still suggest to process '-ENOSPC' and continue, it is
>> really not a critical error, they can continue.
>>
>> For the 'default' error processing:
>>
>> I still suggest to 'printk' in shmem_show_mpol(), because when failure
>> occurs, it has no return value to mark the failure to upper caller.
>> Hmm... but for show_numa_map(), may remove the 'printk', only return the
>> error code is OK. :-)
>>
>>
>> Thanks.
>>
Oh, for '-ENOSPC', it means critical error, it is my fault.
So, for simplify thinking and implementation, use your patch below is OK
to me (but I suggest to print error information in the none return value
function).
:-)
>>> Won't somthing like below do the same but with smaller code change?
>>> Note I've not even compiled it but it shows the idea.
>>> ---
>>> fs/proc/task_mmu.c |4 +++-
>>> mm/shmem.c | 17 +
>>> 2 files changed, 12 insertions(+), 9 deletions(-)
>>>
>>> Index: linux-2.6.git/fs/proc/task_mmu.c
>>> ===
>>> --- linux-2.6.git.orig/fs/proc/task_mmu.c
>>> +++ linux-2.6.git/fs/proc/task_mmu.c
>>> @@ -1402,8 +1402,10 @@ static int show_numa_map(struct seq_file
>>> walk.mm = mm;
>>>
>>> pol = get_vma_policy(task, vma, vma->vm_start);
>>> - mpol_to_str(buffer, sizeof(buffer), pol);
>>> + n = mpol_to_str(buffer, sizeof(buffer), pol);
>>> mpol_cond_put(pol);
>>> + if (n < 0)
>>> + return n;
>>>
>>> seq_printf(m, "%08lx %s", vma->vm_start, buffer);
>>>
>>> Index: linux-2.6.git/mm/shmem.c
>>> ===
>>> --- linux-2.6.git.orig/mm/shmem.c
>>> +++ linux-2.6.git/mm/shmem.c
>>> @@ -883,16 +883,20 @@ redirty:
>>>
>>> #ifdef CONFIG_NUMA
>>> #ifdef CONFIG_TMPFS
>>> -static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
>>> +static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
>>> {
>>> char buffer[64];
>>> + int ret;
>>>
>>> if (!mpol || mpol->mode == MPOL_DEFAULT)
>>> - return; /* show nothing */
>>> + return 0; /* show nothing */
>>>
>>> - mpol_to_str(buffer, sizeof(buffer), mpol);
>>> + ret = mpol_to_str(buffer, sizeof(buffer), mpol);
>>> + if (ret < 0)
>>> + return ret;
>>>
>>> seq_printf(seq, ",mpol=%s", buffer);
>>> + return 0;
>>> }
>>>
>>> static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
>>> @@ -951,9 +955,7 @@ static struct page *shmem_alloc_page(gfp
>>> }
>>> #else /* !CONFIG_NUMA */
>>> #ifdef CONFIG_TMPFS
>>> -static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy
>>> *mpol)
>>> -{
>>> -}
>>> +static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy
>>> *mpol) { return 0; }
>>> #endif /* CONFIG_TMPFS */
>>>
>>> static inline struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp,
>>> @@ -2577,8 +2579,7 @@ static int shmem_show_options(struct seq
>>> if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
>>> seq_printf(seq, ",gid=%u",
>>> from_kgid_munged(&init_user_ns, sbinfo->gid));
>>> - shmem_show_mpol(seq, sbinfo->mpol);
>>> - return 0;
>>> + return shmem_show_
Re: [PATCH 1/2] Revert "Revert "math64: New div64_u64_rem helper""
* Stanislaw Gruszka wrote: > On Fri, Aug 09, 2013 at 03:56:03PM -0400, Mike Snitzer wrote: > > This reverts commit f3002134158092178be81339ec5a22ff80e6c308. > > > > div64_u64_rem was removed because there were no other users. > > > > But Device Mapper's I/O statistics support has a need for > > div64_u64_rem; reintroduce this helper. > > This slows down div64_u64 operation, especially on 32-bit > systems. > > Since dm statistic code is possibly not performance > critical perhaps you could use something like below > instead to calculate remainder: > > res = div64_u64(a, b); > rem = a - b*res; Or introduce a separately named helper without touching the existing methods. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/7] cpufreq:boost: CPU Boost mode support
On Tue, 20 Aug 2013 01:29:20 +0200 Rafael J. Wysocki r...@sisk.pl wrote, > On Monday, August 19, 2013 08:50:37 AM Lukasz Majewski wrote: > > On Mon, 19 Aug 2013 12:08:26 +0530 Viresh Kumar > > viresh.ku...@linaro.org wrote, > > > On 13 August 2013 15:38, Lukasz Majewski > > > wrote: > > > > This patch series introduces support for CPU overclocking > > > > technique called Boost. > > > > > > > > It is a follow up of a LAB governor proposal. Boost is a LAB > > > > component: > > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > > > > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > > > > software oriented one (like the one done at Exynos). > > > > For this reason cpufreq/freq_table code has been reorganized to > > > > include common code. > > > > > > > > Important design decisions: > > > > - Boost related code is compiled-in unconditionally to cpufreq > > > > core and disabled by default. The cpufreq_driver is > > > > responsibile for setting boost_supported flag and providing > > > > set_boost callback(if HW support is needed). For software > > > > managed boost, special Kconfig flag - CONFIG_CPU_FREQ_BOOST_SW > > > > has been defined. It will be selected only when a target > > > > platform has thermal framework properly configured. > > > > > > > > - struct cpufreq_driver has been extended with boost related > > > > fields: -- boost_supported - when driver supports boosting > > > > -- boost_enabled - boost state > > > > -- set_boost - callback to function, which is necessary > > > > to enable/disable boost > > > > > > > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) > > > > is visible _only_ when cpufreq driver supports Boost. > > > > > > > > - No special spin_lock for Boost was created. The one from > > > > cpufreq core was reused. > > > > > > > > - The Boost code doesn't rely on any policy. When boost state is > > > > changed, then the policy list is iterated and proper > > > > adjustements are done. > > > > > > > > - To improve safety level, the thermal framework is also > > > > extended to disable software boosting, when thermal trip point > > > > is reached. Then it starts monitoring target temperature to > > > > evaluate if boost can be enabled again. This emulates behaviour > > > > similar to HW managed boost (like x86) > > > > > > > > Tested at HW: > > > >Exynos 4412 3.11-rc4 Linux > > > >Intel Core i7-3770 3.11-rc4 Linux > > > > > > > > Above patches were posted on top of linux_pm/linux-next with > > > > following patches applied: > > > > > > > > cpufreq: exynos5440: Fix to skip when new frequency same as > > > > current cpufreq: fix EXYNOS drivers selection > > > > > > > > Lukasz Majewski (7): > > > > cpufreq: Add boost frequency support in core > > > > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with > > > > common boost solution > > > > thermal:boost: Automatic enable/disable of BOOST feature > > > > cpufreq:boost:Kconfig: Provide support for software managed > > > > BOOST cpufreq:exynos:Extend Exynos cpufreq driver to support > > > > boost framework > > > > Documentation:cpufreq:boost: Update BOOST documentation > > > > cpufreq:exynos4x12: Change L0 driver data to > > > > CPUFREQ_BOOST_FREQ > > > > > > Hi Lukasz, > > > > > > > Hi Viresh, > > > > > I haven't found time yet to go through this series.. > > > > I've just started wondering if I had send those patches > > correctly :-). > > > > > I want to do a > > > deep/careful review this time as these are almost the final > > > patches. > > > > Ok. > > > > > > > > Will try to get over them by the end of this week.. > > > > Ok, I understand. > > Do I assume correctly that this stuff has been tested on > ACPI-compatible x86 with acpi-cpufreq and everything has worked > correctly there? > > Rafael > Hi Rafael, Following test configuration/test case (x86): - DELL OptiPlex 9010 Intel Core i7-3770 - Linux repo: [kernel_pm_http/bleeding-edge] [kernel_pm_http/linux-next] SHA1: a238ea5e20be7bea2b1fc951a024ecce770306b5 with v7 applied on top - Linux version: 3.11-rc4 (patches v7) and 3.11-rc1 (v6) - Ubuntu 11.10 (make bzImage + make all when module was needed) - config_ubuntu_3_11 (the default one for ubuntu) - KConfig: 1. Disabled intel_pstate driver 2. Enabled ACPI-Prosessor P state driver 3. Legacy cpb sysfs knob support for AMD CPUs ON/OFF (which is a part of acpi-cpufreq.c driver). - acpi-cpufreq driver was build as a module or was embedded in kernel (tested with modprobe -i / -r => no dmesg error|warning output) - I was able to read/write (echo 0/1 > /sys/devices/system/cpu/cpufreq/boost) => no output at dmesg - system was working stable. Toolchain: gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) Since I'm mostly working with ARM (exynos4412) and major work was done with cpufreq core (and x86 related work was to move common code to cpufreq core
Re: [PATCH] acpi_i2c: set MODULE_LICENSE, MODULE_AUTHOR, and MODULE_DESCRIPTION
On Tue, Aug 20, 2013 at 11:14:42AM +0300, Mika Westerberg wrote: > On Tue, Aug 20, 2013 at 01:00:08AM -0700, Jerry Snitselaar wrote: > > On Tue Aug 20 13, Mika Westerberg wrote: > > > On Mon, Aug 19, 2013 at 08:34:03PM -0700, Jerry Snitselaar wrote: > > > > On Tue Aug 20 13, Rafael J. Wysocki wrote: > > > > > On Monday, August 19, 2013 04:35:29 PM Jerry Snitselaar wrote: > > > > > > On Tue Aug 20 13, Rafael J. Wysocki wrote: > > > > > > > On Monday, August 19, 2013 09:16:14 AM Mika Westerberg wrote: > > > > > > > > On Fri, Aug 16, 2013 at 06:26:35PM -0700, Jerry Snitselaar > > > > > > > > wrote: > > > > > > > > > Without MODULE_LICENSE set, I get the following with modprobe: > > > > > > > > > > > > > > > > > > acpi_i2c: module license 'unspecified' taints kernel. > > > > > > > > > acpi_i2c: Unknown symbol i2c_new_device (err 0) > > > > > > > > > acpi_i2c: Unknown symbol acpi_dev_get_resources (err 0) > > > > > > > > > acpi_i2c: Unknown symbol acpi_dev_resource_interrupt (err 0) > > > > > > > > > acpi_i2c: Unknown symbol acpi_dev_free_resource_list (err 0) > > > > > > > > > > > > > > > > > > Signed-off-by: Jerry Snitselaar > > > > > > > > > > > > > > > > Looks good to me. > > > > > > > > > > > > > > > > Acked-by: Mika Westerbeg > > > > > > > > > > > > > > Well, OK, but do we need to be able to build that as a module? > > > > > > > > > > > > > > Maybe it should just be yes or no? > > > > > > > > > > > > > > Rafael > > > > > > > > > > > > > > > > > > > Perhaps have depends on I2C=y and be a bool instead of tristate? > > > > > > > > > > Yes, that's the idea. > > > > > > > > > Does this look okay Mika? > > > > > > > > [PATCH] acpi_i2c: do not build as loadable module > > > > > > > > Change from tristate to bool, and depend on I2C=y > > > > > > I'm not sure about this. Does the below mean that we can't build the ACPI > > > I2C enumeration at all if I2C core is compiled as module? > > > > Yes, that was what Rafael was suggesting. If the ability to compile as > > a module if I2C is a module is needed, then we need the 1st patch. > > In that case I would prefer the first patch. Otherwise we lose the ability > to enumerate I2C devices from ACPI namespace on some distros (at least > Debian builds I2C core as a module). > > Rafael? Actually there's a patch that moves DT I2C helpers to the I2C core here: https://lkml.org/lkml/2013/8/19/349 we should probably do the same for the ACPI case. Doing that solves this problem as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[v2 PATCH] PWM: atmel-pwm: add PWM controller driver
Add Atmel PWM controller driver based on PWM framework.
This is the basic function implementation of Atmel PWM controller.
It can work with PWM based led and backlight.
Signed-off-by: Bo Shen
---
This patch is based on the for-next branch on Linux pwm tree
Test on at91sam9m10g45ek board with pwm led
Test on sama5d31ek board with pwm backlight
Changes in v2:
- Address the comments from Thierry Reding
.../devicetree/bindings/pwm/atmel-pwm.txt | 17 +
drivers/pwm/Kconfig|9 +
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-atmel.c| 328
4 files changed, 355 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/atmel-pwm.txt
create mode 100644 drivers/pwm/pwm-atmel.c
diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
new file mode 100644
index 000..f7b04f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
@@ -0,0 +1,17 @@
+Atmel PWM controller
+
+Required properties:
+ - compatible: should be one of:
+- "atmel,at91sam9rl-pwm"
+- "atmel,sama5-pwm"
+ - reg: physical base address and length of the controller's registers
+ - #pwm-cells: Should be 3. See pwm.txt in this directory for a
+description of the cells format
+
+Example:
+
+ pwm0: pwm@f8034000 {
+ compatible = "atmel,at91sam9rl-pwm";
+ reg = <0xf8034000 0x400>;
+ #pwm-cells = <3>;
+ };
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 75840b5..54237b9 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -41,6 +41,15 @@ config PWM_AB8500
To compile this driver as a module, choose M here: the module
will be called pwm-ab8500.
+config PWM_ATMEL
+ tristate "Atmel PWM support"
+ depends on ARCH_AT91
+ help
+ Generic PWM framework driver for Atmel SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-atmel.
+
config PWM_ATMEL_TCB
tristate "Atmel TC Block PWM support"
depends on ATMEL_TCLIB && OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 77a8c18..5b193f8 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_PWM) += core.o
obj-$(CONFIG_PWM_SYSFS)+= sysfs.o
obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
+obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
new file mode 100644
index 000..a9af974
--- /dev/null
+++ b/drivers/pwm/pwm-atmel.c
@@ -0,0 +1,328 @@
+/*
+ * Driver for Atmel Pulse Width Modulation Controller
+ *
+ * Copyright (C) 2013 Atmel Semiconductor Technology Ltd.
+ * Bo Shen
+ *
+ * GPL v2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* The following is global registers for PWM controller */
+#define PWM_ENA0x04
+#define PWM_DIS0x08
+#define PWM_SR 0x0C
+/* bit field in SR */
+#define PWM_SR_ALL_CH_ON 0x0F
+
+/* The following register is PWM channel related registers */
+#define PWM_CMR0x00
+/* bit field in CMR */
+#define PWM_CMR_CPOL (1 << 9)
+#define PWM_CMR_UPD_CDTY (1 << 10)
+
+/* The following registers for PWM v1 */
+#define PWMv1_CDTY 0x04
+#define PWMv1_CPRD 0x08
+#define PWMv1_CUPD 0x10
+
+/* The following registers for PWM v2 */
+#define PWMv2_CDTY 0x04
+#define PWMv2_CDTYUPD 0x08
+#define PWMv2_CPRD 0x0C
+#define PWMv2_CPRDUPD 0x10
+
+struct atmel_pwm_chip {
+ struct pwm_chip chip;
+ struct clk *clk;
+ void __iomem *base;
+
+ void (*config)(struct pwm_chip *chip, struct pwm_device *pwm,
+ int dty, int prd);
+};
+
+static inline struct atmel_pwm_chip *to_atmel_pwm_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct atmel_pwm_chip, chip);
+}
+
+static inline u32 atmel_pwm_readl(struct atmel_pwm_chip *chip,
+ unsigned long offset)
+{
+ return readl(chip->base + offset);
+}
+
+static inline void atmel_pwm_writel(struct atmel_pwm_chip *chip,
+ unsigned long offset, unsigned long val)
+{
+ writel(val, chip->base + offset);
+}
+
+static inline u32 atmel_pwm_ch_readl(struct atmel_pwm_chip *chip,
+unsigned int ch, unsigned long offset)
+{
+ return readl(chip->base + 0x200 + ch * 0x20 + offset);
+}
+
+static inline void atmel_pwm_ch_writel(struct atmel_pwm_chip *chip,
+ unsigned int ch, unsigned long offset,
+
Re: [REGRESSION] 3.10.{6,7} crashes on network activity
On 08/20/2013 06:56 AM, Felix Fietkau wrote:
On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
wrote:
On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
Hi guys,
Starting with 3.10.6 (and still present in .7) I get an oops on
connecting to the network.
The attached picture shows the oops. In case it does not reach the ML,
the top of the call trace reads:
brcms_c_compute_rtscts_dur
brcms_c_ampdu_finalize
ampdu_finalize
dma_txfast
brcms_c_txfifo
brcms_c_sendpkt_mac80211
brcms_ops_tx
__ieee80211_tx
I bisected the problem and the first bad commit is
commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
Author: Felix Fietkau
Date: Fri Jun 28 21:04:35 2013 +0200
mac80211/minstrel_ht: fix cck rate sampling
commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
Reverting it on top of .7 fixes the problem.
I had the same (I suppose) problem on mainline some time ago, but I
have not bisected it, verified that the problem still occurs there, or
checked if reverting the upstream patch fixes it. I'd be happy to do
that if it would help though.
Let me know if you need any more information.
Do you have this same problem with 3.11-rc6 as well?
Yes, I just confirmed. I also confirmed that reverting the mainline
commit on top of -rc6 fixes the problem.
Great, thanks.
Felix and Johannes, any chance we can get this reverted in Linus tree
soon, and push that revert back to the 3.10 stable tree as well?
I'd like to avoid a revert, since that will simply replace one set of
issues with another. Let's limit the use of the feature that brcmsmac
can't handle to drivers that are known to work with it. Tom, Please
test this patch to see if it fixes your issue.
Hi Felix,
I have been diving into root causing why brcmsmac can not handle cck
fallback rates, because it should. Maybe it is better to flag no cck
support and only change brcmsmac.
Regards,
Arend
- Felix
---
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1501,6 +1501,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_RC_TABLE = 1<<24,
IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF = 1<<25,
IEEE80211_HW_TIMING_BEACON_ONLY = 1<<26,
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES = 1<<27,
};
/**
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_p
if (sband->band != IEEE80211_BAND_2GHZ)
return;
+ if (!(mp->hw->flags & IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
+ return;
+
mi->cck_supported = 0;
mi->cck_supported_short = 0;
for (i = 0; i < 4; i++) {
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -807,7 +807,8 @@ void ath9k_set_hw_capab(struct ath_softc
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_SPECTRUM_MGMT |
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
- IEEE80211_HW_SUPPORTS_RC_TABLE;
+ IEEE80211_HW_SUPPORTS_RC_TABLE |
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -1878,7 +1878,8 @@ void *carl9170_alloc(size_t priv_size)
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
IEEE80211_HW_SUPPORTS_RC_TABLE |
-IEEE80211_HW_SIGNAL_DBM;
+IEEE80211_HW_SIGNAL_DBM |
+IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
if (!modparam_noht) {
/*
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6327,7 +6327,8 @@ static int rt2800_probe_hw_mode(struct r
IEEE80211_HW_SUPPORTS_PS |
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_AMPDU_AGGREGATION |
- IEEE80211_HW_REPORTS_TX_ACK_STATUS;
+ IEEE80211_HW_REPORTS_TX_ACK_STATUS |
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
/*
* Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()
On 08/20/2013 04:09 PM, Chen Gang wrote:
> On 08/20/2013 03:51 PM, Chen Gang wrote:
>> On 08/20/2013 03:48 PM, Chen Gang wrote:
>>> On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
>
>> sure you'll have to change shmem_show_mpol statement to return int code.
>> Won't this be more short and convenient?
>>
>>
>
> Hmm... if return -ENOSPC, in common processing, it still need continue
> (but need let outside know about the string truncation).
>
> So I still suggest to give more check for it.
I still don't like adding additional code like
+ ret = mpol_to_str(buffer, sizeof(buffer), mpol);
+ if (ret < 0)
+ switch (ret) {
+ case -ENOSPC:
+ printk(KERN_WARNING
+ "in %s: string is truncated in
mpol_to_str().\n",
+ __func__);
>>
>> Oh, that need 'break' in my original patch. :-)
>>
+ default:
+ printk(KERN_ERR
+ "in %s: call mpol_to_str() fail, errcode:
%d. buffer: %p, size: %zu, pol: %p\n",
+ __func__, ret, buffer, sizeof(buffer),
mpol);
+ return;
+ }
this code is pretty neat for debugging purpose I think but in most case (if
only I've not missed something obvious) it simply won't be the case.
>>>
>>> For mpol_to_str(), it is for printing string, I suggest to fill buffer
>>> as full as possible like another printing string functions, -ENOSPC is
>>> not critical error, callers may can bear it, and still want to continue.
>>>
>>> For 2 callers, I still suggest to process '-ENOSPC' and continue, it is
>>> really not a critical error, they can continue.
>>>
>>> For the 'default' error processing:
>>>
>>> I still suggest to 'printk' in shmem_show_mpol(), because when failure
>>> occurs, it has no return value to mark the failure to upper caller.
>>> Hmm... but for show_numa_map(), may remove the 'printk', only return the
>>> error code is OK. :-)
>>>
>>>
>>> Thanks.
>>>
>
> Oh, for '-ENOSPC', it means critical error, it is my fault.
>
> So, for simplify thinking and implementation, use your patch below is OK
> to me (but I suggest to print error information in the none return value
> function).
>
> :-)
>
Won't somthing like below do the same but with smaller code change?
Note I've not even compiled it but it shows the idea.
---
fs/proc/task_mmu.c |4 +++-
mm/shmem.c | 17 +
2 files changed, 12 insertions(+), 9 deletions(-)
Index: linux-2.6.git/fs/proc/task_mmu.c
===
--- linux-2.6.git.orig/fs/proc/task_mmu.c
+++ linux-2.6.git/fs/proc/task_mmu.c
@@ -1402,8 +1402,10 @@ static int show_numa_map(struct seq_file
walk.mm = mm;
pol = get_vma_policy(task, vma, vma->vm_start);
- mpol_to_str(buffer, sizeof(buffer), pol);
+ n = mpol_to_str(buffer, sizeof(buffer), pol);
mpol_cond_put(pol);
+ if (n < 0)
+ return n;
seq_printf(m, "%08lx %s", vma->vm_start, buffer);
Index: linux-2.6.git/mm/shmem.c
===
--- linux-2.6.git.orig/mm/shmem.c
+++ linux-2.6.git/mm/shmem.c
@@ -883,16 +883,20 @@ redirty:
#ifdef CONFIG_NUMA
#ifdef CONFIG_TMPFS
-static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
+static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
{
char buffer[64];
+ int ret;
if (!mpol || mpol->mode == MPOL_DEFAULT)
- return; /* show nothing */
+ return 0; /* show nothing */
- mpol_to_str(buffer, sizeof(buffer), mpol);
+ ret = mpol_to_str(buffer, sizeof(buffer), mpol);
+ if (ret < 0)
+ return ret;
seq_printf(seq, ",mpol=%s", buffer);
+ return 0;
}
static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
@@ -951,9 +955,7 @@ static struct page *shmem_alloc_page(gfp
}
#else /* !CONFIG_NUMA */
#ifdef CONFIG_TMPFS
-static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy
*mpol)
-{
-}
+static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy
*mpol) { return 0; }
#endif /* CONFIG_TMPFS */
static inline struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp,
@@ -2577,8 +2579,7 @@ static int shmem_show_options(struct seq
if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
seq_printf(seq, ",gid=%u",
[RESEND PATCH] ARM: OMAP: TI81XX: add always-on powerdomain for TI81XX
This patch adds alwon powerdomain support for TI81XX, which is required
for stable functioning of a big number of TI81XX subsystems.
Signed-off-by: Aida Mynzhasova
---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 8
arch/arm/mach-omap2/prcm-common.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index e2d4bd8..328c103 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -336,6 +336,13 @@ static struct powerdomain dpll5_pwrdm = {
.voltdm = { .name = "core" },
};
+static struct powerdomain alwon_81xx_pwrdm = {
+ .name = "alwon_pwrdm",
+ .prcm_offs= TI81XX_PRM_ALWON_MOD,
+ .pwrsts = PWRSTS_OFF_ON,
+ .voltdm = { .name = "core" },
+};
+
static struct powerdomain device_81xx_pwrdm = {
.name = "device_pwrdm",
.prcm_offs= TI81XX_PRM_DEVICE_MOD,
@@ -442,6 +449,7 @@ static struct powerdomain *powerdomains_am35x[] __initdata
= {
};
static struct powerdomain *powerdomains_ti81xx[] __initdata = {
+ &alwon_81xx_pwrdm,
&device_81xx_pwrdm,
&active_816x_pwrdm,
&default_816x_pwrdm,
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index ff1ac4a..0e841fd 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -58,6 +58,7 @@
#define TI816X_PRM_IVAHD1_MOD 0x0d00
#define TI816X_PRM_IVAHD2_MOD 0x0e00
#define TI816X_PRM_SGX_MOD 0x0f00
+#define TI81XX_PRM_ALWON_MOD 0x1800
/* 24XX register bits shared between CM & PRM registers */
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] mfd: twl6030-irq: rework and add twl6032 support
On Tue, Aug 20, 2013 at 08:13:54AM +0100, Graeme Gregory wrote: > On 20/08/13 02:01, Samuel Ortiz wrote: > >Hi Grygorii, > > > >On Thu, Jul 25, 2013 at 04:15:46PM +0300, Grygorii Strashko wrote: > >>This patch series intorduces twl6030-irq module rework to use Threaded IRQ > >>and > >>linear irq_domain, and adds support for PMIC TWL6032 IRQs. > >> > >>After this patch series TWL6030/6032 IRQs will be supported only for DT > >>boot mode. > >> > >>Changes since v1: > >>- Added new patch "mfd: twl6030-irq: create struct twl6030_irq" > >> which introduces "struct twl6030_irq" to store all local variables > >> inside it. > >>- Patch "mfd: twl6030-irq: migrate to IRQ threaded handler": > >> Minor comments applied; fixed twl6030_exit_irq(); > >> The Parent IRQ has been set for each nested IRQ. > >>- Patch "mfd: twl6030-irq: convert to use linear irq_domain": > >> The irq_find_mapping() is used in twl6030_mmc_card_detect_config() > >> to get virtual IRQ number. > >This looks good to me. Kevin, Graeme, any further comments/ACKs ? > > > >Cheers, > >Samuel. > > > Yes, it looked good to me as well. > > Acked-by: Graeme Gregory Thanks. All 5 patches applied to mfd-next. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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/
ATTN:HI----supply 2-ethyl anthraquinone----menjie chemicals
Dear Sir or Madam: Good Day! Glad to learn you`re on the market of hydrogen peroxide(H2O2) products. We are a professional manufacturers of organic intermediate for 17years , as well as the supplier for ARKEMA, FMC ,now we specialized in the products: the working carrier for hydrogen peroxide: 2-Ethylanthraquinone(2-EAQ) If you are interesting in any of our products, pls contact me, i will send you more details of the products for your reference! Best regards David tan Sales?Depart. Manager skype:tjyf512 tel/fax:86 536 8980651 company: Weifang Menjie Chemical Co.,Ltd Website: http://menjie.en.alibaba.com/ www.menjiechem.com
Re: [PATCH] x86, mm: Add comments for step_size shift
* Yinghai Lu wrote:
> As request by hpa, add comments for why we choose 5 for
> step size shift.
>
> Signed-off-by: Yinghai Lu
> Reviewed-by: Tang Chen
> Tested-by: Tang Chen
>
> ---
> arch/x86/mm/init.c | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/arch/x86/mm/init.c
> ===
> --- linux-2.6.orig/arch/x86/mm/init.c
> +++ linux-2.6/arch/x86/mm/init.c
> @@ -395,8 +395,23 @@ static unsigned long __init init_range_m
> return mapped_ram_size;
> }
>
> -/* (PUD_SHIFT-PMD_SHIFT)/2 */
> -#define STEP_SIZE_SHIFT 5
> +static unsigned long __init get_new_step_size(unsigned long step_size)
> +{
> + /*
> + * initial mapped size is PMD_SIZE, aka 2M.
> + * We can not set step_size to be PUD_SIZE aka 1G yet.
> + * In worse case, when 1G is cross the 1G boundary, and
> + * PG_LEVEL_2M is not set, we will need 1+1+512 pages (aka 2M + 8k)
> + * to map 1G range with PTE. Use 5 as shift for now.
> + */
This is much more readable:
+ /*
+* initial mapped size is PMD_SIZE (2M).
+* We can not set step_size to be PUD_SIZE (1G) yet.
+* In the worst case, when we cross the 1G boundary, and
+* PG_LEVEL_2M is not set, we will need 1+1+512 pages (2M+8k)
+* to map 1G range with PTE. Use 5 as shift for now.
+*/
> + unsigned long new_step_size = step_size << 5;
> +
> + if (new_step_size > step_size)
> + step_size = new_step_size;
> +
> + return step_size;
> +}
> +
> void __init init_mem_mapping(void)
> {
> unsigned long end, real_end, start, last_start;
> @@ -445,7 +460,7 @@ void __init init_mem_mapping(void)
> min_pfn_mapped = last_start >> PAGE_SHIFT;
> /* only increase step_size after big range get mapped */
> if (new_mapped_ram_size > mapped_ram_size)
> - step_size <<= STEP_SIZE_SHIFT;
> + step_size = get_new_step_size(step_size);
> mapped_ram_size += new_mapped_ram_size;
> }
As-is the changelog claims it only adds comments - but it
obviously does more than that ...
Yinghai, for the 1001st time, please use the customary
changelog style we use in the kernel:
" Current code does (A), this has a problem when (B).
We can improve this doing (C), because (D)."
I'm also going to suggest something radical: how about you
keep this sugestion of mine in mind for _all_ future
patches so I don't have to repeat it for every 3rd patch
like I had to for the past 4 years, non-stop? Okay?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()
Sorry for reply multiple times to bother many members.
It seems, I am tired, and need have a rest today. :-(
On 08/20/2013 04:13 PM, Chen Gang F T wrote:
> On 08/20/2013 04:09 PM, Chen Gang wrote:
>> On 08/20/2013 03:51 PM, Chen Gang wrote:
>>> On 08/20/2013 03:48 PM, Chen Gang wrote:
On 08/20/2013 02:47 PM, Cyrill Gorcunov wrote:
> On Tue, Aug 20, 2013 at 01:41:40PM +0800, Chen Gang wrote:
>>
>>> sure you'll have to change shmem_show_mpol statement to return int code.
>>> Won't this be more short and convenient?
>>>
>>>
>>
>> Hmm... if return -ENOSPC, in common processing, it still need continue
>> (but need let outside know about the string truncation).
>>
>> So I still suggest to give more check for it.
>
> I still don't like adding additional code like
>
> + ret = mpol_to_str(buffer, sizeof(buffer), mpol);
> + if (ret < 0)
> + switch (ret) {
> + case -ENOSPC:
> + printk(KERN_WARNING
> + "in %s: string is truncated in
> mpol_to_str().\n",
> + __func__);
>>>
>>> Oh, that need 'break' in my original patch. :-)
>>>
> + default:
> + printk(KERN_ERR
> + "in %s: call mpol_to_str() fail, errcode:
> %d. buffer: %p, size: %zu, pol: %p\n",
> + __func__, ret, buffer, sizeof(buffer),
> mpol);
> + return;
> + }
>
> this code is pretty neat for debugging purpose I think but in most case
> (if
> only I've not missed something obvious) it simply won't be the case.
>
For mpol_to_str(), it is for printing string, I suggest to fill buffer
as full as possible like another printing string functions, -ENOSPC is
not critical error, callers may can bear it, and still want to continue.
For 2 callers, I still suggest to process '-ENOSPC' and continue, it is
really not a critical error, they can continue.
For the 'default' error processing:
I still suggest to 'printk' in shmem_show_mpol(), because when failure
occurs, it has no return value to mark the failure to upper caller.
Hmm... but for show_numa_map(), may remove the 'printk', only return the
error code is OK. :-)
Thanks.
>>
>> Oh, for '-ENOSPC', it means critical error, it is my fault.
>>
>> So, for simplify thinking and implementation, use your patch below is OK
>> to me (but I suggest to print error information in the none return value
>> function).
>>
>> :-)
>>
> Won't somthing like below do the same but with smaller code change?
> Note I've not even compiled it but it shows the idea.
> ---
> fs/proc/task_mmu.c |4 +++-
> mm/shmem.c | 17 +
> 2 files changed, 12 insertions(+), 9 deletions(-)
>
> Index: linux-2.6.git/fs/proc/task_mmu.c
> ===
> --- linux-2.6.git.orig/fs/proc/task_mmu.c
> +++ linux-2.6.git/fs/proc/task_mmu.c
> @@ -1402,8 +1402,10 @@ static int show_numa_map(struct seq_file
> walk.mm = mm;
>
> pol = get_vma_policy(task, vma, vma->vm_start);
> - mpol_to_str(buffer, sizeof(buffer), pol);
> + n = mpol_to_str(buffer, sizeof(buffer), pol);
> mpol_cond_put(pol);
> + if (n < 0)
> + return n;
>
> seq_printf(m, "%08lx %s", vma->vm_start, buffer);
>
> Index: linux-2.6.git/mm/shmem.c
> ===
> --- linux-2.6.git.orig/mm/shmem.c
> +++ linux-2.6.git/mm/shmem.c
> @@ -883,16 +883,20 @@ redirty:
>
> #ifdef CONFIG_NUMA
> #ifdef CONFIG_TMPFS
> -static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
> +static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
> {
> char buffer[64];
> + int ret;
>
> if (!mpol || mpol->mode == MPOL_DEFAULT)
> - return; /* show nothing */
> + return 0; /* show nothing */
>
> - mpol_to_str(buffer, sizeof(buffer), mpol);
> + ret = mpol_to_str(buffer, sizeof(buffer), mpol);
> + if (ret < 0)
> + return ret;
>
> seq_printf(seq, ",mpol=%s", buffer);
> + return 0;
> }
>
> static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
> @@ -951,9 +955,7 @@ static struct page *shmem_alloc_page(gfp
> }
> #else /* !CONFIG_NUMA */
> #ifdef CONFIG_TMPFS
> -static inline void shmem_show_mpol(struct seq_file *seq, struct
> mempolicy *mpol)
> -{
> -}
> +static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy
> *mpol) { return 0; }
> #endif
Re: [ATTEND] oops.kernel.org prospect
On Tue, Aug 20, 2013 at 10:02:43AM +0200, Anton Arapov wrote: > > * Visiting it with chromium gets an annoying warning about the https server > > ... > [snip] > > ... > > Dave > > Thanks, Dave! Will be fixed and improved. Yeah, collecting oopses is a good idea, so +1. However, we probably want to think about what exactly we're going to do with that information. For example, if I want to address an issue, I probably want to know how I can reproduce the oops - maybe something like allowing the reporter to add free text note to the oops. And yes, as tytso already said, we are very often going to need more info about a system causing the oops (dmesg, lspci, dmidecode, etc, etc). I'm not sure how we're going to collect that without sacrificing some privacy. Or maybe, we could be able to ask people to open a bug on bugzilla.kernel.org where further debugging can take place... Which reminds me: maybe connecting bug reports on bugzilla.kernel.org with your stats could also be a way to connect bug reports with reporters... Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is 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/
[tip:x86/urgent] x86/mm: Fix boot crash with DEBUG_PAGE_ALLOC= y and more than 512G RAM
Commit-ID: 527bf129f9a780e11b251cf2467dc30118a57d16
Gitweb: http://git.kernel.org/tip/527bf129f9a780e11b251cf2467dc30118a57d16
Author: Yinghai Lu
AuthorDate: Mon, 12 Aug 2013 16:43:24 -0700
Committer: Ingo Molnar
CommitDate: Tue, 20 Aug 2013 10:06:50 +0200
x86/mm: Fix boot crash with DEBUG_PAGE_ALLOC=y and more than 512G RAM
Dave Hansen reported that systems between 500G and 600G RAM
crash early if DEBUG_PAGEALLOC is selected.
> [0.00] init_memory_mapping: [mem 0x-0x000f]
> [0.00] [mem 0x-0x000f] page 4k
> [0.00] BRK [0x02086000, 0x02086fff] PGTABLE
> [0.00] BRK [0x02087000, 0x02087fff] PGTABLE
> [0.00] BRK [0x02088000, 0x02088fff] PGTABLE
> [0.00] init_memory_mapping: [mem 0xe80ee0-0xe80eff]
> [0.00] [mem 0xe80ee0-0xe80eff] page 4k
> [0.00] BRK [0x02089000, 0x02089fff] PGTABLE
> [0.00] BRK [0x0208a000, 0x0208afff] PGTABLE
> [0.00] Kernel panic - not syncing: alloc_low_page: ran out of memory
It turns out that we missed increasing needed pages in BRK to
mapping initial 2M and [0,1M) when we switched to use the #PF
handler to set memory mappings:
> commit 8170e6bed465b4b0c7687f93e9948aca4358a33b
> Author: H. Peter Anvin
> Date: Thu Jan 24 12:19:52 2013 -0800
>
> x86, 64bit: Use a #PF handler to materialize early mappings on demand
Before that, we had the maping from [0,512M) in head_64.S, and we
can spare two pages [0-1M). After that change, we can not reuse
pages anymore.
When we have more than 512M ram, we need an extra page for pgd page
with [512G, 1024g).
Increase pages in BRK for page table to solve the boot crash.
Reported-by: Dave Hansen
Bisected-by: Dave Hansen
Tested-by: Dave Hansen
Signed-off-by: Yinghai Lu
Cc: # v3.9 and later
Link:
http://lkml.kernel.org/r/1376351004-4015-1-git-send-email-ying...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/mm/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 2ec29ac..04664cd 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -78,8 +78,8 @@ __ref void *alloc_low_pages(unsigned int num)
return __va(pfn << PAGE_SHIFT);
}
-/* need 4 4k for initial PMD_SIZE, 4k for 0-ISA_END_ADDRESS */
-#define INIT_PGT_BUF_SIZE (5 * PAGE_SIZE)
+/* need 3 4k for initial PMD_SIZE, 3 4k for 0-ISA_END_ADDRESS */
+#define INIT_PGT_BUF_SIZE (6 * PAGE_SIZE)
RESERVE_BRK(early_pgt_alloc, INIT_PGT_BUF_SIZE);
void __init early_alloc_pgt_buf(void)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] MFD patches for Realtek cardreader
Hi Wei, On Tue, Aug 20, 2013 at 02:18:50PM +0800, wei_w...@realsil.com.cn wrote: > From: Wei WANG > > v3: > Seperate copyright changes to a distinct patch > Modify some coding style and naming style > Fix a bug that sd30_drive_sel would be assigned a wrong value, in rts5227 and > rts5249 > > v2: > Use macro when initializing vendor settings > > Wei WANG (6): > mfd:rtsx: Read vendor setting from config space > mfd:rtsx: Add shutdown callback in rtsx_pci_driver > mfd:rtsx: Move some actions from rtsx_pci_init_hw to individual > extra_init_hw > mfd:rtsx: Clear hardware PFM mode in rtl8411b > mfd:rtsx: Configure to enter a deeper power-saving mode in S3 > mfd:rtsx: Modify copyright comments All 6 patches applied now, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] dmaengine: add driver for Samsung s3c24xx SoCs
Hi Vinod,
Am Montag, 19. August 2013, 06:48:12 schrieb Vinod Koul:
> On Wed, Aug 14, 2013 at 02:00:25PM +0200, Heiko Stübner wrote:
> > This adds a new driver to support the s3c24xx dma using the dmaengine
> > and makes the old one in mach-s3c24xx obsolete in the long run.
> >
> > Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
> > with numerous virtual channels being mapped to a lot less physical ones.
> > The driver therefore borrows a lot from the amba-pl08x driver in this
> > regard. Functionality-wise the driver gains a memcpy ability in addition
> > to the slave_sg one.
>
> If that is the case why cant we have this driver supported from pl08x
> driver? If the delta is only mapping then can that be seprated or both
> mapping hanlded? Maybe you and Linus have already though about that?
Yes we have ... As Tomasz has already written the hardware itself is very much
different. It's only the concept of mapping virtual channels to physical
channels that is somehow similar.
It seems my patch message is lacking in making this clearer ;-) .
> > The driver supports both the method for requesting the peripheral used
> > by SoCs before the S3C2443 and the different method for S3C2443 and
> > later.
> >
> > On earlier SoCs the hardware channels usable for specific peripherals is
> > constrainted while on later SoCs all channels can be used for any
> > peripheral.
> >
> > Tested on a s3c2416-based board, memcpy using the dmatest module and
> > slave_sg partially using the spi-s3c64xx driver.
> >
> > Signed-off-by: Heiko Stuebner
> >
> > +#define DISRC (0x00)
> > +#define DISRCC (0x04)
> > +#define DISRCC_INC_INCREMENT (0 << 0)
> > +#define DISRCC_INC_FIXED (1 << 0)
> > +#define DISRCC_LOC_AHB (0 << 1)
> > +#define DISRCC_LOC_APB (1 << 1)
> > +
> > +#define DIDST (0x08)
> > +#define DIDSTC (0x0C)
> > +#define DIDSTC_INC_INCREMENT (0 << 0)
> > +#define DIDSTC_INC_FIXED (1 << 0)
> > +#define DIDSTC_LOC_AHB (0 << 1)
> > +#define DIDSTC_LOC_APB (1 << 1)
> > +#define DIDSTC_INT_TC0 (0 << 2)
> > +#define DIDSTC_INT_RELOAD (1 << 2)
> > +
> > +#define DCON (0x10)
> > +
> > +#define DCON_TC_MASK 0xf
> > +#define DCON_DSZ_BYTE (0 << 20)
> > +#define DCON_DSZ_HALFWORD (1 << 20)
> > +#define DCON_DSZ_WORD (2 << 20)
> > +#define DCON_DSZ_MASK (3 << 20)
> > +#define DCON_DSZ_SHIFT 20
> > +#define DCON_AUTORELOAD(0 << 22)
> > +#define DCON_NORELOAD (1 << 22)
> > +#define DCON_HWTRIG(1 << 23)
> > +#define DCON_HWSRC_SHIFT 24
> > +#define DCON_SERV_SINGLE (0 << 27)
> > +#define DCON_SERV_WHOLE(1 << 27)
> > +#define DCON_TSZ_UNIT (0 << 28)
> > +#define DCON_TSZ_BURST4(1 << 28)
> > +#define DCON_INT (1 << 29)
> > +#define DCON_SYNC_PCLK (0 << 30)
> > +#define DCON_SYNC_HCLK (1 << 30)
> > +#define DCON_DEMAND(0 << 31)
> > +#define DCON_HANDSHAKE (1 << 31)
> > +
> > +#define DSTAT (0x14)
> > +#define DSTAT_STAT_BUSY(1 << 20)
> > +#define DSTAT_CURRTC_MASK 0xf
> > +
> > +#define DMASKTRIG (0x20)
> > +#define DMASKTRIG_STOP (1 << 2)
> > +#define DMASKTRIG_ON (1 << 1)
> > +#define DMASKTRIG_SWTRIG (1 << 0)
> > +
> > +#define DMAREQSEL (0x24)
> > +#define DMAREQSEL_HW (1 << 0)
>
> This is proper namespacing...
Hmm, I don't understand meaning of this sentence. Is it a suggestion to change
anything?
> > +static int s3c24xx_dma_set_runtime_config(struct s3c24xx_dma_chan
> > *s3cchan, + struct dma_slave_config *config)
> > +{
> > + if (!s3cchan->slave)
> > + return -EINVAL;
> > +
> > + /* Reject definitely invalid configurations */
> > + if (config->src_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES ||
> > + config->dst_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES)
> > + return -EINVAL;
> > +
> > + s3cchan->cfg = *config;
>
> you are takinga ref to client pointer without a clue on when that would be
> freed. I dont think its a good idea!
hmm, the config pointer is dereferenced here and its data thus copyied into
s3cchan->cfg, so no reference to the origial config pointer is kept.
> > +static irqreturn_t s3c24xx_dma_irq(int irq, void *data)
> > +{
> > + struct s3c24xx_dma_phy *phy = data;
> > + struct s3c24xx_dma_chan *s3cchan = phy->serving;
> > + struct s3c24xx_txd *txd;
> > +
> > + dev_dbg(&phy->host->pdev->dev, "interrupt on channel %d\n", phy->id);
> > +
> > + if (!s3cchan) {
> > + dev_err(&phy->host->pdev->dev, "interrupt on unused channel
%d\n",
> > + phy->id);
> > + return IRQ_NONE;
>
> hmmm, these channles
[tip:x86/apic] x86/ioapic/kcrash: Prevent crash_kexec() from deadlocking on ioapic_lock
Commit-ID: 17405453f4ad0220721a29978692081be6392b8f
Gitweb: http://git.kernel.org/tip/17405453f4ad0220721a29978692081be6392b8f
Author: Yoshihiro YUNOMAE
AuthorDate: Tue, 20 Aug 2013 16:01:07 +0900
Committer: Ingo Molnar
CommitDate: Tue, 20 Aug 2013 09:26:33 +0200
x86/ioapic/kcrash: Prevent crash_kexec() from deadlocking on ioapic_lock
Prevent crash_kexec() from deadlocking on ioapic_lock. When
crash_kexec() is executed on a CPU, the CPU will take ioapic_lock
in disable_IO_APIC(). So if the cpu gets an NMI while locking
ioapic_lock, a deadlock will happen.
In this patch, ioapic_lock is zapped/initialized before disable_IO_APIC().
You can reproduce this deadlock the following way:
1. Add mdelay(1000) after raw_spin_lock_irqsave() in
native_ioapic_set_affinity()@arch/x86/kernel/apic/io_apic.c
Although the deadlock can occur without this modification, it will increase
the potential of the deadlock problem.
2. Build and install the kernel
3. Set up the OS which will run panic() and kexec when NMI is injected
# echo "kernel.unknown_nmi_panic=1" >> /etc/sysctl.conf
# vim /etc/default/grub
add "nmi_watchdog=0 crashkernel=256M" in GRUB_CMDLINE_LINUX line
# grub2-mkconfig
4. Reboot the OS
5. Run following command for each vcpu on the guest
# while true; do echo > /proc/irq//smp_affinitity; done;
By running this command, cpus will get ioapic_lock for setting affinity.
6. Inject NMI (push a dump button or execute 'virsh inject-nmi ' if you
use VM). After injecting NMI, panic() is called in an nmi-handler context.
Then, kexec will normally run in panic(), but the operation will be stopped
by deadlock on ioapic_lock in crash_kexec()->machine_crash_shutdown()->
native_machine_crash_shutdown()->disable_IO_APIC()->clear_IO_APIC()->
clear_IO_APIC_pin()->ioapic_read_entry().
Signed-off-by: Yoshihiro YUNOMAE
Cc: Andi Kleen
Cc: Gleb Natapov
Cc: Konrad Rzeszutek Wilk
Cc: Joerg Roedel
Cc: Marcelo Tosatti
Cc: Hidehiro Kawai
Cc: Sebastian Andrzej Siewior
Cc: Zhang Yanfei
Cc: Eric W. Biederman
Cc: yrl.pp-manager...@hitachi.com
Cc: Masami Hiramatsu
Cc: Seiji Aguchi
Link: http://lkml.kernel.org/r/20130820070107.28245.83806.stgit@yunodevel
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/apic.h| 2 ++
arch/x86/kernel/apic/io_apic.c | 5 +
arch/x86/kernel/crash.c| 4 +++-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f8119b5..1d2091a 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -715,4 +715,6 @@ static inline void exiting_ack_irq(void)
ack_APIC_irq();
}
+extern void ioapic_zap_locks(void);
+
#endif /* _ASM_X86_APIC_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9ed796c..260abc2 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1534,6 +1534,11 @@ void intel_ir_io_apic_print_entries(unsigned int apic,
}
}
+void ioapic_zap_locks(void)
+{
+ raw_spin_lock_init(&ioapic_lock);
+}
+
__apicdebuginit(void) print_IO_APIC(int ioapic_idx)
{
union IO_APIC_reg_00 reg_00;
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 74467fe..e0e0841 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -128,7 +128,9 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
cpu_emergency_svm_disable();
lapic_shutdown();
-#if defined(CONFIG_X86_IO_APIC)
+#ifdef CONFIG_X86_IO_APIC
+ /* Prevent crash_kexec() from deadlocking on ioapic_lock. */
+ ioapic_zap_locks();
disable_IO_APIC();
#endif
#ifdef CONFIG_HPET_TIMER
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] mm: mempolicy: the failure processing about mpol_to_str()
On Tue, Aug 20, 2013 at 04:09:22PM +0800, Chen Gang wrote: > So, for simplify thinking and implementation, use your patch below is OK > to me (but I suggest to print error information in the none return value > function). Chen, I'm not going to dive into this area now, too busy with other stuff sorry, so if you consider my preliminary draft patch useful -- pick it up, modify it, test it and send to lkml then (just CC me). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: mc13xxx: make it possible to use the codec without pdata
On Tue, 13 Aug 2013, Michael Grzeschik wrote:
> In case of devicetree, we currently don't have a way to append pdata for
> the codec. This patch makes it possible to probe the codec without pdata
> for that case.
>
> Signed-off-by: Michael Grzeschik
> ---
> drivers/mfd/mc13xxx-core.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
This patch doesn't apply. What tree is it based on?
> diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
> index 278601f..e1b89e6 100644
> --- a/drivers/mfd/mc13xxx-core.c
> +++ b/drivers/mfd/mc13xxx-core.c
> @@ -687,10 +687,6 @@ err_revision:
> if (mc13xxx->flags & MC13XXX_USE_ADC)
> mc13xxx_add_subdevice(mc13xxx, "%s-adc");
>
> - if (mc13xxx->flags & MC13XXX_USE_CODEC)
> - mc13xxx_add_subdevice_pdata(mc13xxx, "%s-codec",
> - pdata->codec, sizeof(*pdata->codec));
> -
> if (mc13xxx->flags & MC13XXX_USE_RTC)
> mc13xxx_add_subdevice(mc13xxx, "%s-rtc");
>
> @@ -705,6 +701,10 @@ err_revision:
> if (mc13xxx->flags & MC13XXX_USE_TOUCHSCREEN)
> mc13xxx_add_subdevice_pdata(mc13xxx, "%s-ts",
> &pdata->touch, sizeof(pdata->touch));
> +
> + if (mc13xxx->flags & MC13XXX_USE_CODEC)
> + mc13xxx_add_subdevice_pdata(mc13xxx, "%s-codec",
> + pdata->codec, sizeof(*pdata->codec));
> } else {
> mc13xxx_add_subdevice(mc13xxx, "%s-regulator");
> mc13xxx_add_subdevice(mc13xxx, "%s-led");
> @@ -712,6 +712,9 @@ err_revision:
>
> if (mc13xxx->flags & MC13XXX_USE_TOUCHSCREEN)
> mc13xxx_add_subdevice(mc13xxx, "%s-ts");
> +
> + if (mc13xxx->flags & MC13XXX_USE_CODEC)
> + mc13xxx_add_subdevice(mc13xxx, "%s-codec");
> }
>
> return 0;
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.11-rc6 genetlink locking fix offends lockdep
On Mon, 2013-08-19 at 11:52 -0700, Hugh Dickins wrote:
> > > > We could use the semaphore instead, I believe, but I don't really
> > > > understand the mutex vs. semaphore well enough to be sure that's
> > > > correct.
> > I don't believe so, the semaphore and cb_mutex don't have a dependency
> > yet, afaict.
>
> The down_read(&cb_lock) patch you suggested gives the lockdep trace below.
Clearly I was wrong then, not sure what I missed in the code though.
>From the lockdep trace it looks like the dependency comes via the
genl_lock, I didn't consider that.
David, can you please just revert it for now and tag the revert for
stable as well, in case Greg already took it somewhere? I think that
some stable trees may need a different fix anyway since they don't have
parallel_ops.
We never saw a problem due to this, and though it's probably fairly easy
to trigger by hand-rolling the dump loop in userspace, one does need to
be able to rmmod to crash the kernel with it.
The only way to fix this that I see right now (that doesn't rewrite the
locking completely) would be to make genetlink use parallel_ops itself,
thereby removing the genl_lock() in genl_rcv_msg() and breaking all
those lock chains that lockdep reported. After that, it should be safe
to use genl_lock() inside all the operations. Something like the patch
below, perhaps? Completely untested so far.
johannes
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..dea9586 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -665,6 +665,7 @@ static struct genl_family genl_ctrl = {
.version = 0x2,
.maxattr = CTRL_ATTR_MAX,
.netnsok = true,
+ .parallel_ops = true,
};
static int ctrl_fill_info(struct genl_family *family, u32 portid, u32 seq,
@@ -789,10 +790,8 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct
netlink_callback *cb)
struct net *net = sock_net(skb->sk);
int chains_to_skip = cb->args[0];
int fams_to_skip = cb->args[1];
- bool need_locking = chains_to_skip || fams_to_skip;
- if (need_locking)
- genl_lock();
+ genl_lock();
for (i = chains_to_skip; i < GENL_FAM_TAB_SIZE; i++) {
n = 0;
@@ -814,8 +813,7 @@ errout:
cb->args[0] = i;
cb->args[1] = n;
- if (need_locking)
- genl_unlock();
+ genl_unlock();
return skb->len;
}
@@ -870,6 +868,8 @@ static int ctrl_getfamily(struct sk_buff *skb, struct
genl_info *info)
struct genl_family *res = NULL;
int err = -EINVAL;
+ genl_lock();
+
if (info->attrs[CTRL_ATTR_FAMILY_ID]) {
u16 id = nla_get_u16(info->attrs[CTRL_ATTR_FAMILY_ID]);
res = genl_family_find_byid(id);
@@ -896,19 +896,25 @@ static int ctrl_getfamily(struct sk_buff *skb, struct
genl_info *info)
}
if (res == NULL)
- return err;
+ goto out_unlock;
if (!res->netnsok && !net_eq(genl_info_net(info), &init_net)) {
/* family doesn't exist here */
- return -ENOENT;
+ err = -ENOENT;
+ goto out_unlock;
}
msg = ctrl_build_family_msg(res, info->snd_portid, info->snd_seq,
CTRL_CMD_NEWFAMILY);
- if (IS_ERR(msg))
- return PTR_ERR(msg);
+ if (IS_ERR(msg)) {
+ err = PTR_ERR(msg);
+ goto out_unlock;
+ }
- return genlmsg_reply(msg, info);
+ err = genlmsg_reply(msg, info);
+out_unlock:
+ genl_unlock();
+ return err;
}
static int genl_ctrl_event(int event, void *data)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] LMK: Optimize lowmem_shrink
On Tue, Aug 20, 2013 at 09:16:33AM +0800, Leon Ma wrote: > From: Leon Ma > Date: Mon, 19 Aug 2013 14:22:38 +0800 > Subject: [PATCH] LMK: Optimize lowmem_shrink. > > By comparing with selected_oom_score_adj instead of min_score_adj, > we may do less calculation. > The patch is line wrapped and doesn't apply. Read Documentation/email-clients.txt. Send it to yourself first. Save the whole email as raw text (including headers and everything). cat email.txt | git am. When that works, then resend. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pwm: atmel-pwm: add pwm controller driver
On 19/08/2013 05:11, Bo Shen :
add atmel pwm controller driver based on PWM framework
this is basic function implementation of pwm controller
it can work with pwm based led and backlight
Signed-off-by: Bo Shen
---
This patch is based on Linux v3.11 rc6
Tested on sama5d31ek and at91sam9m10g45ek board
---
.../devicetree/bindings/pwm/atmel-pwm.txt | 19 ++
drivers/pwm/Kconfig|9 +
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-atmel.c| 327
4 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/atmel-pwm.txt
create mode 100644 drivers/pwm/pwm-atmel.c
diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
new file mode 100644
index 000..127fcdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
@@ -0,0 +1,19 @@
+Atmel PWM controller
+
+Required properties:
+ - compatible: should be one of:
+- "atmel,at91sam9rl-pwm"
+- "atmel,sama5-pwm"
No, the compatibility string should be: "atmel,sama5d3-pwm"
+ - reg: physical base address and length of the controller's registers
+ - #pwm-cells: Should be 3.
+- The first cell specifies the per-chip index of the PWM to use
+- The second cell is the period in nanoseconds
+- The third cell is used to encode the polarity of PWM output
+
+Example:
+
+ pwm0: pwm@f8034000 {
+ compatible = "atmel,at91sam9rl-pwm";
+ reg = <0xf8034000 0x400>;
+ #pwm-cells = <3>;
+ };
Can you add an example of consumer: it would make the example much more
understandable.
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 75840b5..54237b9 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -41,6 +41,15 @@ config PWM_AB8500
To compile this driver as a module, choose M here: the module
will be called pwm-ab8500.
+config PWM_ATMEL
+ tristate "Atmel PWM support"
+ depends on ARCH_AT91
+ help
+ Generic PWM framework driver for Atmel SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-atmel.
+
config PWM_ATMEL_TCB
tristate "Atmel TC Block PWM support"
depends on ATMEL_TCLIB && OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 77a8c18..5b193f8 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_PWM) += core.o
obj-$(CONFIG_PWM_SYSFS) += sysfs.o
obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
+obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
obj-$(CONFIG_PWM_BFIN)+= pwm-bfin.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
new file mode 100644
index 000..b83d68e
--- /dev/null
+++ b/drivers/pwm/pwm-atmel.c
@@ -0,0 +1,327 @@
+/*
+ * Driver for Atmel Pulse Width Modulation Controller
+ *
+ * Copyright (C) 2013 Atmel Semiconductor Technology Ltd.
use "Atmel Corporation" in copyright.
+ * Bo Shen
+ *
+ * GPL v2 or later
+ */
A general remark also pointed out by Thierry: please use more defined
constants in your code: it makes the code more readable and avoid this
black magic feeling when we read it.
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PWM_MR 0x00
+#define PWM_ENA0x04
+#define PWM_DIS0x08
+#define PWM_SR 0x0C
+
+#define PWM_CMR0x00
+
+/* The following register for PWM v1 */
+#define PWMv1_CDTY 0x04
+#define PWMv1_CPRD 0x08
+#define PWMv1_CUPD 0x10
+
+/* The following register for PWM v2 */
+#define PWMv2_CDTY 0x04
+#define PWMv2_CDTYUPD 0x08
+#define PWMv2_CPRD 0x0C
+#define PWMv2_CPRDUPD 0x10
+
+#define PWM_NUM4
+
+struct atmel_pwm_chip {
+ struct pwm_chip chip;
+ struct clk *clk;
+ void __iomem *base;
+
+ void (*config)(struct atmel_pwm_chip *chip, struct pwm_device *pwm,
+ unsigned int dty, unsigned int prd);
+};
+
+#define to_atmel_pwm_chip(chip) container_of(chip, struct atmel_pwm_chip, chip)
+
+static inline u32 atmel_pwm_readl(struct atmel_pwm_chip *chip, int offset)
+{
+ return readl(chip->base + offset);
+}
+
+static inline void atmel_pwm_writel(struct atmel_pwm_chip *chip, int offset,
+ u32 val)
+{
+ writel(val, chip->base + offset);
+}
+
+static inline u32 atmel_pwm_ch_readl(struct atmel_pwm_chip *chip, int ch,
+ int offset)
+{
+ return readl(chip->base + 0x200 + ch * 0x20 + offset);
Maybe a constant for this 0x200 value...
+}
+
+static inline void atmel_pwm_ch_writel(struct atmel_pwm_chip *chip,
Re: [PATCH 0/3] mm: mempolicy: the failure processing about mpol_to_str()
On 08/20/2013 04:25 PM, Cyrill Gorcunov wrote: > On Tue, Aug 20, 2013 at 04:09:22PM +0800, Chen Gang wrote: >> So, for simplify thinking and implementation, use your patch below is OK >> to me (but I suggest to print error information in the none return value >> function). > > Chen, I'm not going to dive into this area now, too busy with other stuff > sorry, so if you consider my preliminary draft patch useful -- pick it up, > modify it, test it and send to lkml then (just CC me). > > OK, I will do tomorrow. :-) Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] DMA: Freescale: Add support for 8-channel DMA engine
On 07/29/2013 06:59 PM, Vinod Koul wrote: On Mon, Jul 29, 2013 at 06:49:01PM +0800, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches. The dma relates changes look okay to me. I need someone to review and ACK the DT bindings. ~Vinod Vinod, Are you using this tree? http://git.infradead.org/users/vkoul/slave-dma.git Did you merge these patches? Thanks. Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set adds support this DMA engine. V6->V7 changes: - only remove unnecessary "CHIP-dma" explanations in [1/3] V5->V6 changes: - minor updates of descriptions in binding document and Kconfig - remove [4/4], that should be another patch in future V4->V5 changes: - update description in the dt binding document, to make it more resonable - add new patch [4/4] to eliminate a compiling warning which already exists for a long time V3->V4 changes: - introduce new patch [1/3] to revise the legacy dma binding document - and then add new paragraph to describe new dt node binding in [2/3] - rebase to latest kernel v3.11-rc1 V2->V3 changes: - edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt - edit text string in Kconfig and the driver files, using "elo series" to mention all the current "elo*" V1->V2 changes: - removed the codes handling the register dgsr1, since it isn't used currently - renamed the DMA DT compatible to "fsl,elo3-dma" - renamed the new dts files to "elo3-dma-.dtsi" Hongbo Zhang (3): DMA: Freescale: revise device tree binding document DMA: Freescale: Add new 8-channel DMA engine device tree nodes DMA: Freescale: update driver to support 8-channel DMA engine .../devicetree/bindings/powerpc/fsl/dma.txt| 114 +++- arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- drivers/dma/Kconfig|9 +- drivers/dma/fsldma.c |9 +- drivers/dma/fsldma.h |2 +- 8 files changed, 264 insertions(+), 40 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi -- 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/
Re: [REGRESSION] 3.10.{6,7} crashes on network activity
On Tue, Aug 20, 2013 at 12:56 PM, Felix Fietkau wrote:
> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
>>> On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
>>> wrote:
>>> > On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
>>> >> Hi guys,
>>> >>
>>> >> Starting with 3.10.6 (and still present in .7) I get an oops on
>>> >> connecting to the network.
>>> >>
>>> >> The attached picture shows the oops. In case it does not reach the ML,
>>> >> the top of the call trace reads:
>>> >>
>>> >> brcms_c_compute_rtscts_dur
>>> >> brcms_c_ampdu_finalize
>>> >> ampdu_finalize
>>> >> dma_txfast
>>> >> brcms_c_txfifo
>>> >> brcms_c_sendpkt_mac80211
>>> >> brcms_ops_tx
>>> >> __ieee80211_tx
>>> >>
>>> >> I bisected the problem and the first bad commit is
>>> >>
>>> >> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
>>> >> Author: Felix Fietkau
>>> >> Date: Fri Jun 28 21:04:35 2013 +0200
>>> >>
>>> >> mac80211/minstrel_ht: fix cck rate sampling
>>> >>
>>> >> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
>>> >>
>>> >> Reverting it on top of .7 fixes the problem.
>>> >>
>>> >> I had the same (I suppose) problem on mainline some time ago, but I
>>> >> have not bisected it, verified that the problem still occurs there, or
>>> >> checked if reverting the upstream patch fixes it. I'd be happy to do
>>> >> that if it would help though.
>>> >>
>>> >> Let me know if you need any more information.
>>> >
>>> > Do you have this same problem with 3.11-rc6 as well?
>>>
>>> Yes, I just confirmed. I also confirmed that reverting the mainline
>>> commit on top of -rc6 fixes the problem.
>>
>> Great, thanks.
>>
>> Felix and Johannes, any chance we can get this reverted in Linus tree
>> soon, and push that revert back to the 3.10 stable tree as well?
> I'd like to avoid a revert, since that will simply replace one set of
> issues with another. Let's limit the use of the feature that brcmsmac
> can't handle to drivers that are known to work with it. Tom, Please
> test this patch to see if it fixes your issue.
The patch (on top of -rc6) fixes it for me. Thanks.
-t
> ---
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -1501,6 +1501,7 @@ enum ieee80211_hw_flags {
> IEEE80211_HW_SUPPORTS_RC_TABLE = 1<<24,
> IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF = 1<<25,
> IEEE80211_HW_TIMING_BEACON_ONLY = 1<<26,
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES = 1<<27,
> };
>
> /**
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_p
> if (sband->band != IEEE80211_BAND_2GHZ)
> return;
>
> + if (!(mp->hw->flags & IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
> + return;
> +
> mi->cck_supported = 0;
> mi->cck_supported_short = 0;
> for (i = 0; i < 4; i++) {
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -807,7 +807,8 @@ void ath9k_set_hw_capab(struct ath_softc
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_SPECTRUM_MGMT |
> IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> - IEEE80211_HW_SUPPORTS_RC_TABLE;
> + IEEE80211_HW_SUPPORTS_RC_TABLE |
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
>
> if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
> hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> --- a/drivers/net/wireless/ath/carl9170/main.c
> +++ b/drivers/net/wireless/ath/carl9170/main.c
> @@ -1878,7 +1878,8 @@ void *carl9170_alloc(size_t priv_size)
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
> IEEE80211_HW_SUPPORTS_RC_TABLE |
> -IEEE80211_HW_SIGNAL_DBM;
> +IEEE80211_HW_SIGNAL_DBM |
> +IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
>
> if (!modparam_noht) {
> /*
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -6327,7 +6327,8 @@ static int rt2800_probe_hw_mode(struct r
> IEEE80211_HW_SUPPORTS_PS |
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_AMPDU_AGGREGATION |
> - IEEE80211_HW_REPORTS_TX_ACK_STATUS;
> + IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> + IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
>
> /*
> * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [REGRESSION] 3.10.{6,7} crashes on network activity
On Tue, Aug 20, 2013 at 4:15 PM, Arend van Spriel wrote: > On 08/20/2013 06:56 AM, Felix Fietkau wrote: >> >> On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote: >>> >>> On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote: On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman wrote: > > On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote: >> >> Hi guys, >> >> Starting with 3.10.6 (and still present in .7) I get an oops on >> connecting to the network. >> >> The attached picture shows the oops. In case it does not reach the ML, >> the top of the call trace reads: >> >> brcms_c_compute_rtscts_dur >> brcms_c_ampdu_finalize >> ampdu_finalize >> dma_txfast >> brcms_c_txfifo >> brcms_c_sendpkt_mac80211 >> brcms_ops_tx >> __ieee80211_tx >> >> I bisected the problem and the first bad commit is >> >> commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6 >> Author: Felix Fietkau >> Date: Fri Jun 28 21:04:35 2013 +0200 >> >> mac80211/minstrel_ht: fix cck rate sampling >> >> commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream. >> >> Reverting it on top of .7 fixes the problem. >> >> I had the same (I suppose) problem on mainline some time ago, but I >> have not bisected it, verified that the problem still occurs there, or >> checked if reverting the upstream patch fixes it. I'd be happy to do >> that if it would help though. >> >> Let me know if you need any more information. > > > Do you have this same problem with 3.11-rc6 as well? Yes, I just confirmed. I also confirmed that reverting the mainline commit on top of -rc6 fixes the problem. >>> >>> >>> Great, thanks. >>> >>> Felix and Johannes, any chance we can get this reverted in Linus tree >>> soon, and push that revert back to the 3.10 stable tree as well? >> >> I'd like to avoid a revert, since that will simply replace one set of >> issues with another. Let's limit the use of the feature that brcmsmac >> can't handle to drivers that are known to work with it. Tom, Please >> test this patch to see if it fixes your issue. > > > Hi Felix, > > I have been diving into root causing why brcmsmac can not handle cck > fallback rates, because it should. Maybe it is better to flag no cck support > and only change brcmsmac. Hi Arend, In case you cannot reproduce, let me know if I can help with testing patches. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drm/radeon: rework to new fence interface
Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
Op 19-08-13 14:35, Christian König schreef:
Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
-if (wake) {
+if (wake)
rdev->fence_drv[ring].last_activity = jiffies;
-wake_up_all(&rdev->fence_queue);
-}
+return wake;
}
Very bad idea, when sequence numbers change, you always want to wake up the
whole fence queue here.
Yes, and the callers of this function call wake_up_all or wake_up_all_locked
themselves, based on the return value..
And as I said that's a very bad idea. The fence processing shouldn't be
called with any locks held and should be self responsible for activating
any waiters.
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!fence->rdev->ddev->irq_enabled)
+return false;
+
Do I get that right that you rely on IRQs to be enabled and working here? Cause
that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage it's
no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as
far as I can see you just leave them enabled by decrementing the atomic
from IRQ context. Additional to that we need allot of special handling
in case of a hardware lockup here, which isn't done if you abuse the
fence interface like this.
Also your approach of leaking the IRQ context outside of the driver is a
very bad idea from the conceptual side. Please don't modify the fence
interface at all and instead use the wait functions already exposed by
radeon_fence.c. If you need some kind of signaling mechanism then wait
inside a workqueue instead.
Christian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: mc13xxx: make it possible to use the codec without pdata
Hi Lee, On Tue, Aug 20, 2013 at 09:26:36AM +0100, Lee Jones wrote: > On Tue, 13 Aug 2013, Michael Grzeschik wrote: > > > In case of devicetree, we currently don't have a way to append pdata for > > the codec. This patch makes it possible to probe the codec without pdata > > for that case. > > > > Signed-off-by: Michael Grzeschik > > --- > > drivers/mfd/mc13xxx-core.c | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > This patch doesn't apply. What tree is it based on? Please wait a bit before applying this one. I'd like to get Dmitry's feedback on the input one first. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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/
[PATCH 2/3] ARM: dts: imx6q/imx6dl: add necessary clocks for ldb node
This patch adds di[0/1]_div_3_5, di[0/1]_div_7 and di[0/1]_div_sel
clocks to the ldb nodes so that the ldb driver may use them to
setup the display clock trees.
Signed-off-by: Liu Ying
---
arch/arm/boot/dts/imx6dl.dtsi |8 ++--
arch/arm/boot/dts/imx6q.dtsi |8 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 9e8ae11..ff0d743 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -75,10 +75,14 @@
&ldb {
clocks = <&clks 33>, <&clks 34>,
<&clks 39>, <&clks 40>,
-<&clks 135>, <&clks 136>;
+<&clks 135>, <&clks 136>,
+<&clks 184>, <&clks 185>, <&clks 203>, <&clks 204>,
+<&clks 205>, <&clks 206>;
clock-names = "di0_pll", "di1_pll",
"di0_sel", "di1_sel",
- "di0", "di1";
+ "di0", "di1",
+ "di0_div_3_5", "di1_div_3_5", "di0_div_7", "di1_div_7",
+ "di0_div_sel", "di1_div_sel";
lvds-channel@0 {
crtcs = <&ipu1 0>, <&ipu1 1>;
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f024ef2..b078a42 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -146,10 +146,14 @@
&ldb {
clocks = <&clks 33>, <&clks 34>,
<&clks 39>, <&clks 40>, <&clks 41>, <&clks 42>,
-<&clks 135>, <&clks 136>;
+<&clks 135>, <&clks 136>,
+<&clks 184>, <&clks 185>, <&clks 203>, <&clks 204>,
+<&clks 205>, <&clks 206>;
clock-names = "di0_pll", "di1_pll",
"di0_sel", "di1_sel", "di2_sel", "di3_sel",
- "di0", "di1";
+ "di0", "di1",
+ "di0_div_3_5", "di1_div_3_5", "di0_div_7", "di1_div_7",
+ "di0_div_sel", "di1_div_sel";
lvds-channel@0 {
crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
The ldb_di[0/1]_ipu_div dividers may divide their parent clock
frequencies by either 3.5 or 7. The non-integral dividers cannot
be dealt with the common clock framework directly, so they cannot
be registered as common clock dividers. So this patch adds a fixed
factor clock of 1/7 and introduces ldb_di[0/1]_div_sel multiplexers
so that the fixed factor clocks of 1/3.5 and 1/7 can be set to be
the parents of ldb_di[0/1]_div_sel multiplexers. The ldb_di[0/1]_podf
dividers are no longer used then.
Signed-off-by: Liu Ying
---
.../devicetree/bindings/clock/imx6q-clock.txt |6 +++--
arch/arm/mach-imx/clk-imx6q.c | 25
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 5a90a72..90e923e 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -89,8 +89,6 @@ clocks and IDs.
gpu3d_shader74
ipu1_podf 75
ipu2_podf 76
- ldb_di0_podf77
- ldb_di1_podf78
ipu1_di0_pre79
ipu1_di1_pre80
ipu2_di0_pre81
@@ -215,6 +213,10 @@ clocks and IDs.
cko2200
cko 201
vdoa202
+ ldb_di0_div_7 203
+ ldb_di1_div_7 204
+ ldb_di0_div_sel 205
+ ldb_di1_div_sel 206
Examples:
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 9181a24..2b5be96 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -189,6 +189,8 @@ static const char *gpu3d_core_sels[]= {
"mmdc_ch0_axi", "pll3_usb_otg", "pll2_p
static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg",
"pll2_pfd1_594m", "pll3_pfd0_720m", };
static const char *ipu_sels[] = { "mmdc_ch0_axi", "pll2_pfd2_396m",
"pll3_120m", "pll3_pfd1_540m", };
static const char *ldb_di_sels[] = { "pll5_video_div", "pll2_pfd0_352m",
"pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_usb_otg", };
+static const char *ldb_di0_div_sels[] = { "ldb_di0_div_3_5", "ldb_di0_div_7",
};
+static const char *ldb_di1_div_sels[] = { "ldb_di1_div_3_5", "ldb_di1_div_7",
};
static const char *ipu_di_pre_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg",
"pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
static const char *ipu1_di0_sels[] = { "ipu1_di0_pre", "dummy", "dummy",
"ldb_di0", "ldb_di1", };
static const char *ipu1_di1_sels[] = { "ipu1_di1_pre", "dummy", "dummy",
"ldb_di0", "ldb_di1", };
@@ -233,11 +235,11 @@ enum mx6q_clks {
periph_clk2, periph2_clk2, ipg, ipg_per, esai_pred, esai_podf,
asrc_pred, asrc_podf, spdif_pred, spdif_podf, can_root, ecspi_root,
gpu2d_core_podf, gpu3d_core_podf, gpu3d_shader, ipu1_podf, ipu2_podf,
- ldb_di0_podf, ldb_di1_podf, ipu1_di0_pre, ipu1_di1_pre, ipu2_di0_pre,
- ipu2_di1_pre, hsi_tx_podf, ssi1_pred, ssi1_podf, ssi2_pred, ssi2_podf,
- ssi3_pred, ssi3_podf, uart_serial_podf, usdhc1_podf, usdhc2_podf,
- usdhc3_podf, usdhc4_podf, enfc_pred, enfc_podf, emi_podf,
- emi_slow_podf, vpu_axi_podf, cko1_podf, axi, mmdc_ch0_axi_podf,
+ ldb_di0_podf_unused, ldb_di1_podf_unused, ipu1_di0_pre, ipu1_di1_pre,
+ ipu2_di0_pre, ipu2_di1_pre, hsi_tx_podf, ssi1_pred, ssi1_podf,
+ ssi2_pred, ssi2_podf, ssi3_pred, ssi3_podf, uart_serial_podf,
+ usdhc1_podf, usdhc2_podf, usdhc3_podf, usdhc4_podf, enfc_pred,
enfc_podf,
+ emi_podf, emi_slow_podf, vpu_axi_podf, cko1_podf, axi,
mmdc_ch0_axi_podf,
mmdc_ch1_axi_podf, arm, ahb, apbh_dma, asrc, can1_ipg, can1_serial,
can2_ipg, can2_serial, ecspi1, ecspi2, ecspi3, ecspi4, ecspi5, enet,
esai, gpt_ipg, gpt_ipg_per, gpu2d_core, gpu3d_core, hdmi_iahb,
@@ -251,7 +253,8 @@ enum mx6q_clks {
ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5,
ldb_di1_div_3_5,
sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
usbphy1_gate,
usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
- spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, clk_max
+ spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, ldb_di0_div_7,
ldb_di1_div_7,
+ ldb_di0_div_sel, ldb_di1_div_sel, clk_max
};
static struct clk *clk[clk_max];
@@ -387,6 +390,8 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[ipu2_sel] = imx_clk_mux("ipu2_sel", base + 0x3c,
14, 2, ipu_sels, ARRAY_SIZE(ipu_sels));
clk[ldb_di0_sel] = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c,
9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
clk[ldb_di1_sel] = imx_clk_mux_flags("ldb_di1_sel", bas
Re: [PATCH 2/4] nohz: Synchronize sleep time stats with seqlock
On Tue, Aug 20, 2013 at 03:59:36PM +0900, Fernando Luis Vázquez Cao wrote: > That said, if deemed acceptable, option A is the one I would > choose. Right, so I think we can do A without much extra cost mostly because we already have 2 atomics in the io_schedule() path. If we replace those two atomic operations with locks and modify nr_iowait and the other stats under the same lock, and ensure all those variables (including the lock) live in the same cacheline we should have the same cost we have now. Of course, if we can get away with completely removing all of that (which I think Arjan suggested was a real possibility) then that would be ever so much better still :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3.5.y.z extended stable] Linux 3.5.7.19
I am announcing the release of the Linux 3.5.7.19 kernel. The updated 3.5.y tree can be found at: git://kernel.ubuntu.com/ubuntu/linux.git linux-3.5.y and can be browsed at: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.5.y;a=shortlog The diff from v3.5.7.18 is posted as a follow-up to this email. The 3.5.y extended stable tree is maintained by the Ubuntu Kernel Team. For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable -Luis -- Makefile | 2 +- arch/arm/Kconfig | 3 +- arch/arm/kernel/entry-armv.S | 103 +++-- arch/arm/kernel/fiq.c | 19 +++- arch/arm/kernel/traps.c| 37 +--- arch/arm/kernel/vmlinux.lds.S | 17 arch/arm/mm/Kconfig| 34 +++ arch/arm/mm/mmu.c | 10 +- arch/x86/kernel/i387.c | 2 +- drivers/acpi/battery.c | 2 + drivers/ata/Kconfig| 2 +- drivers/ata/sata_inic162x.c| 14 +++ drivers/block/xen-blkback/blkback.c| 13 ++- drivers/block/xen-blkback/common.h | 2 + drivers/block/xen-blkback/xenbus.c | 2 + drivers/char/virtio_console.c | 47 ++ drivers/firewire/core-cdev.c | 3 + drivers/firewire/ohci.c| 10 +- drivers/gpu/drm/ast/ast_ttm.c | 1 + drivers/gpu/drm/cirrus/cirrus_ttm.c| 1 + drivers/gpu/drm/i915/i915_drv.h| 1 + drivers/gpu/drm/i915/intel_display.c | 16 drivers/gpu/drm/i915/intel_lvds.c | 3 +- drivers/gpu/drm/i915/intel_panel.c | 11 +++ drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 + drivers/gpu/drm/radeon/atom.c | 5 + drivers/gpu/drm/radeon/evergreen.c | 3 +- drivers/gpu/drm/radeon/ni.c| 3 +- drivers/gpu/drm/radeon/r600.c | 3 +- drivers/gpu/drm/radeon/rv770.c | 3 +- drivers/gpu/drm/radeon/si.c| 3 +- drivers/hwmon/adt7470.c| 2 +- drivers/input/mouse/elantech.c | 17 ++-- drivers/macintosh/windfarm_rm31.c | 18 ++-- drivers/net/arcnet/arcnet.c| 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c | 3 +- drivers/net/ethernet/realtek/8139cp.c | 48 +- drivers/net/usb/smsc75xx.c | 12 +-- drivers/net/virtio_net.c | 5 +- drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 + drivers/net/wireless/iwlwifi/iwl-mac80211.c| 19 +++- drivers/net/wireless/iwlwifi/iwl-pci.c | 1 + drivers/net/wireless/mwifiex/sdio.c| 4 +- drivers/net/wireless/rt2x00/rt2x00queue.c | 18 ++-- drivers/scsi/megaraid/megaraid_sas_base.c | 20 +++- drivers/scsi/nsp32.c | 2 +- drivers/scsi/scsi.c| 3 + drivers/staging/zram/zram_drv.c| 2 +- drivers/tty/serial/mxs-auart.c | 38 drivers/usb/core/hub.c | 5 +- drivers/usb/serial/ftdi_sio.c | 31 ++- drivers/usb/serial/ftdi_sio_ids.h | 34 ++- drivers/usb/serial/mos7840.c | 91 ++ drivers/virtio/virtio_ring.c | 54 --- drivers/xen/evtchn.c | 21 + fs/btrfs/extent-tree.c | 11 +++ fs/cifs/cifsencrypt.c | 2 +- fs/cifs/cifsglob.h | 1 + fs/cifs/connect.c | 7 +- fs/cifs/sess.c | 6 +- fs/debugfs/inode.c | 69 +- fs/ext4/ialloc.c | 10 +- fs/ext4/super.c| 19 +++- fs/super.c | 25 ++--- include/linux/firewire-cdev.h | 4 +- include/linux/firewire.h | 1 + include/linux/ftrace_event.h | 4 +- include/linux/hugetlb.h| 16 include/linux/regmap.h | 1 + include/linux/virtio.h | 4 + include/xen/interface/io/ring.h| 5 + kernel/events/core.c | 20 +++- kernel
Re: [RFC 06/17] ARM: imx: remove custom .init_time hook
On 08/20/2013 09:26 AM, Sascha Hauer wrote:
On Tue, Aug 20, 2013 at 04:04:20AM +0200, Sebastian Hesselbarth wrote:
With arch/arm calling of_clk_init(NULL) from time_init(), we can now
remove custom .init_time hooks.
Signed-off-by: Sebastian Hesselbarth
---
Notes:
- Although mx5_clocks_common_init() is shared with non-DT, removing
of_clk_init(NULL) should be fine, as it only registers DT clk providers.
- For imx6q, printing of silicon revision has been moved from .init_time
to .init_machine hook.
Cc: Russell King
Cc: Arnd Bergmann
Cc: Sascha Hauer
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-imx/clk-imx51-imx53.c | 12
arch/arm/mach-imx/common.h |2 --
arch/arm/mach-imx/imx51-dt.c|6 --
arch/arm/mach-imx/mach-imx53.c |6 --
arch/arm/mach-imx/mach-imx6q.c | 14 +++---
arch/arm/mach-imx/mach-imx6sl.c |7 ---
arch/arm/mach-imx/mach-vf610.c |9 -
7 files changed, 3 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c
b/arch/arm/mach-imx/clk-imx51-imx53.c
index 1a56a33..5955a54 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -131,8 +131,6 @@ static void __init mx5_clocks_common_init(unsigned long
rate_ckil,
{
int i;
- of_clk_init(NULL);
-
clk[dummy] = imx_clk_fixed("dummy", 0);
clk[ckil] = imx_obtain_fixed_clock("ckil", rate_ckil);
clk[osc] = imx_obtain_fixed_clock("osc", rate_osc);
@@ -569,13 +567,3 @@ int __init mx53_clocks_init(unsigned long rate_ckil,
unsigned long rate_osc,
return 0;
}
-
-int __init mx51_clocks_init_dt(void)
-{
- return mx51_clocks_init(0, 0, 0, 0);
-}
-
-int __init mx53_clocks_init_dt(void)
-{
- return mx53_clocks_init(0, 0, 0, 0);
-}
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 4517fd7..0ce8313 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -68,8 +68,6 @@ extern int mx53_clocks_init(unsigned long ckil, unsigned long
osc,
extern int mx25_clocks_init_dt(void);
extern int mx27_clocks_init_dt(void);
extern int mx31_clocks_init_dt(void);
-extern int mx51_clocks_init_dt(void);
-extern int mx53_clocks_init_dt(void);
extern struct platform_device *mxc_register_gpio(char *name, int id,
resource_size_t iobase, resource_size_t iosize, int irq, int irq_high);
extern void mxc_set_cpu_type(unsigned int type);
diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
index 53e43e5..bece8a6 100644
--- a/arch/arm/mach-imx/imx51-dt.c
+++ b/arch/arm/mach-imx/imx51-dt.c
@@ -34,17 +34,11 @@ static const char *imx51_dt_board_compat[] __initdata = {
NULL
};
-static void __init imx51_timer_init(void)
-{
- mx51_clocks_init_dt();
-}
-
DT_MACHINE_START(IMX51_DT, "Freescale i.MX51 (Device Tree Support)")
.map_io = mx51_map_io,
.init_early = imx51_init_early,
.init_irq = mx51_init_irq,
.handle_irq = imx51_handle_irq,
- .init_time = imx51_timer_init,
On i.MX5 the init_time hook calls mx5x_clocks_init_dt which calls
mx5x_clocks_init which not only calls of_clk_init() but also registers
all clocks in the system. You can't remove it.
I am missing some
CLK_OF_DECLARE(imx51, "fsl,imx51-ccm", imx51_clocks_init);
CLK_OF_DECLARE(imx53, "fsl,imx53-ccm", imx53_clocks_init);
Somewhere.
Sascha,
you are right, I forgot to add the two lines above as replacement for
the now removed direct call. If the general approach is accepted, I'll
add them for sure.
Do imx51/imx53 still boot with CLK_OF_DECLARE added?
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] refactor some ldb related clocks
The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 drivider or a 1/7 divider. The common clock framework cannot deal with the two dividers directly even with the divider table which only supports integral dividers. So, the idea is to take the 1/3.5 and 1/7 dividers as separate fixed factor dividers and introduce a new multiplexer clock to be derived from the them. Then, the ldb display clock trees can be setup correctly. This series contains the necessary clock driver changes, dts code changes and imx-drm/ldb driver changes to fullfill the task. Liu Ying (3): ARM: imx6q: refactor some ldb related clocks ARM: dts: imx6q/imx6dl: add necessary clocks for ldb node staging: drm/imx: ldb: correct the ldb di clock trees .../devicetree/bindings/clock/imx6q-clock.txt |6 ++-- arch/arm/boot/dts/imx6dl.dtsi |8 +++-- arch/arm/boot/dts/imx6q.dtsi |8 +++-- arch/arm/mach-imx/clk-imx6q.c | 25 +++-- drivers/staging/imx-drm/imx-ldb.c | 38 +++- 5 files changed, 61 insertions(+), 24 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] staging: drm/imx: ldb: correct the ldb di clock trees
In ldb split mode, the ldb_di[0/1]_ipu_div dividers should
be configured as clock dividers of 1/3.5, while in others
ldb modes of 1/7. This patch gets the di[0/1]_div_3_5,
di[0/1]_div_7 and di[0/1]_div_sel clocks and sets the
di[0/1]_div_3_5 or di[0/1]_div_7 clocks to be the parents of
di[0/1]_div_sel clocks according to the ldb mode. The real
dividers are the two fixed factors bewteen the ldb_di[0/1] and
the pll clocks, so it's unnecessary to set the frequency for
the ldb_di[0/1] clocks again after pll clock frequency is set.
This patch removes the redundant clock frequency setting code
as well.
Signed-off-by: Liu Ying
---
drivers/staging/imx-drm/imx-ldb.c | 38 +
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index 8af7f3b..7c553b8 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -81,6 +81,9 @@ struct imx_ldb {
struct clk *clk[2]; /* our own clock */
struct clk *clk_sel[4]; /* parent of display clock */
struct clk *clk_pll[2]; /* upstream clock we can adjust */
+ struct clk *clk_div_3_5[2]; /* fixed factor of 1/3.5 */
+ struct clk *clk_div_7[2]; /* fixed factor of 1/7 */
+ struct clk *clk_div_sel[2]; /* 1/3.5 or 1/7 */
u32 ldb_ctrl;
const struct bus_mux *lvds_mux;
};
@@ -150,6 +153,18 @@ static void imx_ldb_set_clock(struct imx_ldb *ldb, int
mux, int chno,
{
int ret;
+ if (ldb->ldb_ctrl & LDB_SPLIT_MODE_EN) {
+ ret = clk_set_parent(ldb->clk_div_sel[chno],
ldb->clk_div_3_5[chno]);
+ if (ret)
+ dev_err(ldb->dev, "unable to set di%d_div_sel parent
clock "
+ "to di%d_div_3_5\n", chno, chno);
+ } else {
+ ret = clk_set_parent(ldb->clk_div_sel[chno],
ldb->clk_div_7[chno]);
+ if (ret)
+ dev_err(ldb->dev, "unable to set di%d_div_sel parent
clock "
+ "to di%d_div_7\n", chno, chno);
+ }
+
dev_dbg(ldb->dev, "%s: now: %ld want: %ld\n", __func__,
clk_get_rate(ldb->clk_pll[chno]), serial_clk);
clk_set_rate(ldb->clk_pll[chno], serial_clk);
@@ -157,14 +172,6 @@ static void imx_ldb_set_clock(struct imx_ldb *ldb, int
mux, int chno,
dev_dbg(ldb->dev, "%s after: %ld\n", __func__,
clk_get_rate(ldb->clk_pll[chno]));
- dev_dbg(ldb->dev, "%s: now: %ld want: %ld\n", __func__,
- clk_get_rate(ldb->clk[chno]),
- (long int)di_clk);
- clk_set_rate(ldb->clk[chno], di_clk);
-
- dev_dbg(ldb->dev, "%s after: %ld\n", __func__,
- clk_get_rate(ldb->clk[chno]));
-
/* set display clock mux to LDB input clock */
ret = clk_set_parent(ldb->clk_sel[mux], ldb->clk[chno]);
if (ret) {
@@ -362,6 +369,21 @@ static int imx_ldb_get_clk(struct imx_ldb *ldb, int chno)
if (IS_ERR(ldb->clk_pll[chno]))
return PTR_ERR(ldb->clk_pll[chno]);
+ sprintf(clkname, "di%d_div_3_5", chno);
+ ldb->clk_div_3_5[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_3_5[chno]))
+ return PTR_ERR(ldb->clk_div_3_5[chno]);
+
+ sprintf(clkname, "di%d_div_7", chno);
+ ldb->clk_div_7[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_7[chno]))
+ return PTR_ERR(ldb->clk_div_7[chno]);
+
+ sprintf(clkname, "di%d_div_sel", chno);
+ ldb->clk_div_sel[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_sel[chno]))
+ return PTR_ERR(ldb->clk_div_sel[chno]);
+
return 0;
}
--
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/
Re: [PATCH 2/2] mm: add overcommit_kbytes sysctl variable
On 08/19/2013 06:55 PM, Dave Hansen wrote: > On 08/19/2013 08:17 AM, Jerome Marchand wrote: >> Some applications that run on HPC clusters are designed around the >> availability of RAM and the overcommit ratio is fine tuned to get the >> maximum usage of memory without swapping. With growing memory, the >> 1%-of-all-RAM grain provided by overcommit_ratio has become too coarse >> for these workload (on a 2TB machine it represents no less than >> 20GB). >> >> This patch adds the new overcommit_kbytes sysctl variable that allow a >> much finer grain. > > Instead of introducing yet another tunable, why don't we just make the > ratio that comes in from the user more fine-grained? > > sysctl overcommit_ratio=0.2 > > We change the internal 'sysctl_overcommit_ratio' to store tenths or > hundreths of a percent (or whatever), then parse the input as two > integers. I don't think we need fully correct floating point parsing > and rounding here, so it shouldn't be too much of a chore. It'd > probably end up being less code than you have as it stands. > Whatever works for me. I did it in that way to be more consistent with what has already been done for dirty*_ratio/bytes. Thanks, Jerome -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] DMA: Freescale: Add support for 8-channel DMA engine
On Tue, Aug 20, 2013 at 04:33:46PM +0800, Hongbo Zhang wrote: > On 07/29/2013 06:59 PM, Vinod Koul wrote: > >On Mon, Jul 29, 2013 at 06:49:01PM +0800, hongbo.zh...@freescale.com wrote: > >>From: Hongbo Zhang > >> > >>Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches. > >The dma relates changes look okay to me. > > > >I need someone to review and ACK the DT bindings. > > > >~Vinod > Vinod, > Are you using this tree? > http://git.infradead.org/users/vkoul/slave-dma.git Yes > Did you merge these patches? No As I said I would like someone who know DT and dma binding to ack them. I see devicetree ML has been cced, can Arnd or someone else review these... ~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: [RFC PATCH] pwm: atmel-pwm: add pwm controller driver
Hi Nicolas,
On 8/20/2013 16:33, Nicolas Ferre wrote:
On 19/08/2013 05:11, Bo Shen :
add atmel pwm controller driver based on PWM framework
this is basic function implementation of pwm controller
it can work with pwm based led and backlight
Signed-off-by: Bo Shen
---
This patch is based on Linux v3.11 rc6
Tested on sama5d31ek and at91sam9m10g45ek board
---
.../devicetree/bindings/pwm/atmel-pwm.txt | 19 ++
drivers/pwm/Kconfig|9 +
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-atmel.c| 327
4 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/atmel-pwm.txt
create mode 100644 drivers/pwm/pwm-atmel.c
diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
new file mode 100644
index 000..127fcdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
@@ -0,0 +1,19 @@
+Atmel PWM controller
+
+Required properties:
+ - compatible: should be one of:
+- "atmel,at91sam9rl-pwm"
+- "atmel,sama5-pwm"
No, the compatibility string should be: "atmel,sama5d3-pwm"
OK, I will change it in next version.
+ - reg: physical base address and length of the controller's registers
+ - #pwm-cells: Should be 3.
+- The first cell specifies the per-chip index of the PWM to use
+- The second cell is the period in nanoseconds
+- The third cell is used to encode the polarity of PWM output
+
+Example:
+
+pwm0: pwm@f8034000 {
+compatible = "atmel,at91sam9rl-pwm";
+reg = <0xf8034000 0x400>;
+#pwm-cells = <3>;
+};
Can you add an example of consumer: it would make the example much more
understandable.
I will add an example of consumer.
[...]
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
new file mode 100644
index 000..b83d68e
--- /dev/null
+++ b/drivers/pwm/pwm-atmel.c
@@ -0,0 +1,327 @@
+/*
+ * Driver for Atmel Pulse Width Modulation Controller
+ *
+ * Copyright (C) 2013 Atmel Semiconductor Technology Ltd.
use "Atmel Corporation" in copyright.
+ * Bo Shen
+ *
+ * GPL v2 or later
+ */
A general remark also pointed out by Thierry: please use more defined
constants in your code: it makes the code more readable and avoid this
black magic feeling when we read it.
Please help review v2.
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PWM_MR0x00
+#define PWM_ENA0x04
+#define PWM_DIS0x08
+#define PWM_SR0x0C
+
+#define PWM_CMR0x00
+
+/* The following register for PWM v1 */
+#define PWMv1_CDTY0x04
+#define PWMv1_CPRD0x08
+#define PWMv1_CUPD0x10
+
+/* The following register for PWM v2 */
+#define PWMv2_CDTY0x04
+#define PWMv2_CDTYUPD0x08
+#define PWMv2_CPRD0x0C
+#define PWMv2_CPRDUPD0x10
+
+#define PWM_NUM4
+
+struct atmel_pwm_chip {
+struct pwm_chip chip;
+struct clk *clk;
+void __iomem *base;
+
+void (*config)(struct atmel_pwm_chip *chip, struct pwm_device *pwm,
+unsigned int dty, unsigned int prd);
+};
+
+#define to_atmel_pwm_chip(chip) container_of(chip, struct
atmel_pwm_chip, chip)
+
+static inline u32 atmel_pwm_readl(struct atmel_pwm_chip *chip, int
offset)
+{
+return readl(chip->base + offset);
+}
+
+static inline void atmel_pwm_writel(struct atmel_pwm_chip *chip, int
offset,
+u32 val)
+{
+writel(val, chip->base + offset);
+}
+
+static inline u32 atmel_pwm_ch_readl(struct atmel_pwm_chip *chip, int
ch,
+int offset)
+{
+return readl(chip->base + 0x200 + ch * 0x20 + offset);
Maybe a constant for this 0x200 value...
OK. I will fix it in net version.
+}
+
+static inline void atmel_pwm_ch_writel(struct atmel_pwm_chip *chip,
int ch,
+int offset, u32 val)
+{
+writel(val, chip->base + 0x200 + ch * 0x20 + offset);
+}
+
+static int atmel_pwm_config(struct pwm_chip *chip, struct pwm_device
*pwm,
+int duty_ns, int period_ns)
+{
+struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
+unsigned long long val, prd, dty;
+unsigned long long div, clk_rate;
+int ret, pres = 0;
+
+clk_rate = clk_get_rate(atmel_pwm->clk);
+
+while (1) {
Why not use a proper loop condition here instead of a frightening
while (true) loop? Is it really making the code less readable?
OK, I will try to use the proper loop condition here.
+div = 10;
use a constant or at least a comment for this initialization.
I will add comment in next version.
+div *= 1 << pres;
+val = clk_rate * period_ns;
+prd = div_u64(val, div);
+val = clk_rate * duty_ns;
+dty = div_u64(val, div);
+
+if (prd < 0x0001 || dty < 0x0)
+return -EINVAL;
+
+if (prd > 0x || dty > 0x) {
Yes, here d
Re: [PATCH v2 2/4] dmaengine: add driver for Samsung s3c24xx SoCs
On Tue, Aug 20, 2013 at 10:23:49AM +0200, Heiko Stübner wrote:
> Hi Vinod,
>
> Am Montag, 19. August 2013, 06:48:12 schrieb Vinod Koul:
> > On Wed, Aug 14, 2013 at 02:00:25PM +0200, Heiko Stübner wrote:
> > > This adds a new driver to support the s3c24xx dma using the dmaengine
> > > and makes the old one in mach-s3c24xx obsolete in the long run.
> > >
> > > Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
> > > with numerous virtual channels being mapped to a lot less physical ones.
> > > The driver therefore borrows a lot from the amba-pl08x driver in this
> > > regard. Functionality-wise the driver gains a memcpy ability in addition
> > > to the slave_sg one.
> >
> > If that is the case why cant we have this driver supported from pl08x
> > driver? If the delta is only mapping then can that be seprated or both
> > mapping hanlded? Maybe you and Linus have already though about that?
>
> Yes we have ... As Tomasz has already written the hardware itself is very
> much
> different. It's only the concept of mapping virtual channels to physical
> channels that is somehow similar.
>
> It seems my patch message is lacking in making this clearer ;-) .
The above made me believ they are similar contrlllers with differnt mapping!,
hence the question...
> > > +#define DMASKTRIG_STOP (1 << 2)
> > > +#define DMASKTRIG_ON (1 << 1)
> > > +#define DMASKTRIG_SWTRIG (1 << 0)
> > > +
> > > +#define DMAREQSEL(0x24)
> > > +#define DMAREQSEL_HW (1 << 0)
> >
> > This is proper namespacing...
>
> Hmm, I don't understand meaning of this sentence. Is it a suggestion to
> change
> anything?
Sorry above should be read as "this need proper namespacing". The macros like
DMAREQSEL asre farliy egneric and can collide with others. SO the recommendation
is to use something like S3_DMAREQSEL etc
> > > +static irqreturn_t s3c24xx_dma_irq(int irq, void *data)
> > > +{
> > > + struct s3c24xx_dma_phy *phy = data;
> > > + struct s3c24xx_dma_chan *s3cchan = phy->serving;
> > > + struct s3c24xx_txd *txd;
> > > +
> > > + dev_dbg(&phy->host->pdev->dev, "interrupt on channel %d\n", phy->id);
> > > +
> > > + if (!s3cchan) {
> > > + dev_err(&phy->host->pdev->dev, "interrupt on unused channel
> %d\n",
> > > + phy->id);
> > > + return IRQ_NONE;
> >
> > hmmm, these channles belong to you. So if one of them is behvaing badly,
> > then not handling the interrupt will make things worse...
>
> hmm ... I'm not sure what a valid handling would be for this.
>
> The interrupt is only asserted when a transfer is completed - there are no
> other interrupt-triggers. But when phy->serving is NULL, this also means that
> the clock of the channel is disabled at this time. So this _should_ never
> happen.
if that is the case we dont need above, but you added that just for the small
iota of if
> And as written above, the interrupt is only triggered when a transfer was
> completed and the channel is idle again, so if there is no virtual channel
> being served, there is nothing else to do.
But if we do get such an interrupt, it means:
a) bug in SW
b) erratic hw behaviour
if you handle and dump the issue at least you have recovered. Rather than
returning and controller asserting interrupt again and again as it is not
cleared.
~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: 3.11-rc6 genetlink locking fix offends lockdep
On Tue, Aug 20, 2013 at 10:28:58AM +0200, Johannes Berg wrote: > Something like the patch below, perhaps? Completely untested so far. Yeah, this one seems to fix it here (I was seeing the same lockdep splat as Hugh). Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is 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: [PATCH] mfd: mc13xxx: make it possible to use the codec without pdata
> > > In case of devicetree, we currently don't have a way to append pdata for > > > the codec. This patch makes it possible to probe the codec without pdata > > > for that case. > > > > > > Signed-off-by: Michael Grzeschik > > > --- > > > drivers/mfd/mc13xxx-core.c | 11 +++ > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > This patch doesn't apply. What tree is it based on? > Please wait a bit before applying this one. I'd like to get Dmitry's > feedback on the input one first. It's okay, I didn't intend on actually applying it. I just wanted to see the full file changes. I usually apply it, then do a `git log -p -U1000` to get the full picture. However, I can't even do that yet, which suggests it's based on some non-upstream tree. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 06/17] ARM: imx: remove custom .init_time hook
On Tue, Aug 20, 2013 at 10:48:44AM +0200, Sebastian Hesselbarth wrote: > On 08/20/2013 09:26 AM, Sascha Hauer wrote: > >On i.MX5 the init_time hook calls mx5x_clocks_init_dt which calls > >mx5x_clocks_init which not only calls of_clk_init() but also registers > >all clocks in the system. You can't remove it. > > > >I am missing some > > > >CLK_OF_DECLARE(imx51, "fsl,imx51-ccm", imx51_clocks_init); > >CLK_OF_DECLARE(imx53, "fsl,imx53-ccm", imx53_clocks_init); > > > >Somewhere. > > Sascha, > > you are right, I forgot to add the two lines above as replacement for > the now removed direct call. If the general approach is accepted, I'll > add them for sure. > > Do imx51/imx53 still boot with CLK_OF_DECLARE added? I can test this once the whole series arrived here. So far I only have 6/16 and 10/17. I probably need at least 1/17. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/33] ARM: ux500: Supply the I2C clocks lookup to the DBX500 DT
On Thu, Jun 6, 2013 at 2:16 PM, Lee Jones wrote: > +++ b/arch/arm/boot/dts/dbx5x0.dtsi > @@ -572,6 +572,8 @@ > v-i2c-supply = <&db8500_vape_reg>; > > clock-frequency = <40>; > + clocks = <&prcc_kclk 3 3>, <&prcc_pclk 3 3>; > + clock-names = "nmk-i2c.0", "apb_pclk"; To avoid confusing the clock name "nmk-i2c.0" with the device name in Linux of that device instance, can we use a name such that it is clear that this is not a dev_name match? "i2c0" works just fine as name I think? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: adc: Add bindigs documentation for twl6030 GPADC
Hi Oleksandr,
[Adding Jonathan Cameron and Guenter Roeck to Cc]
Apologies for the delay replying to this. In attempting to verify this
made sense I went and read the IIO bindings documentation, and I'm
somewhat confused by the model.
As far as I can see, the only consumer of IIO channels is the
"iio-hwmon" binding, which seems to be a binding for Linux-specific
infrastructure rather than any actual device. This runs counter to the
way DT is supposed to function (describing the hardware rather than how
it's used). As far as I can see, this linkage is described because only
a subset of the ADCs on the device are actually wired to something?
I also see a couple of IIO bindings ("adi,adf435x*, and "adi,ad7303")
which don't describe any iio channel cells at all, so I'm somewhat
confused by what the IIO channels actually represent, and why they must
be consumed elsewhere. As far as I can see, an IIO channel represents a
single ADC's registers in an IIO device, so I'm not sure why this must
be exported via the channel concept -- it's not physically wired.
Have I misunderstood something here?
Thanks,
Mark.
On Mon, Aug 19, 2013 at 12:29:25PM +0100, Oleksandr Kozaruk wrote:
> Add required documentation for twl6030 GPADC device tree
> bindings.
>
> Signed-off-by: Oleksandr Kozaruk
> ---
> .../devicetree/bindings/iio/adc/twl6030-gpadc.txt | 45
> ++
> 1 file changed, 45 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
> b/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
> new file mode 100644
> index 000..6cd3ef3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/twl6030-gpadc.txt
> @@ -0,0 +1,45 @@
> +Texas Instruments twl6030/twl6032 GPADC device driver
> +
> +Required properties:
> + - compatible: must be "ti,twl6030-gpadc" for TWL6030 or
> + "ti,twl6032-gpadc" for TWL6032
> + - interrupts: interrupt number associated with it
> + - #io-channel-cells: must be <1> - multiple IIO outputs are present
> + iio consumers can use following io-channels:
> + twl6030:
> + 0 - battery type
> + 1 - battery temperature resistor value
> + 2 - audio accessory/general purpose
> + 3 - general purpose
> + 4 - temperature/general purpose
> + 5 - general purpose
> + 6 - general purpose
> + 7 - main battery
> + 8 - backup battery
> + 9 - charger input
> + 10 - VBUS
> + 11 - VBUS charging current
> + 14 - USB ID
> + twl6032:
> + 0 - battery type
> + 1 - battery temperature resistor value
> + 2 - audio accessory/general purpose
> + 3 - temperature with external diode/general purpose
> + 4 - temperature/general purpose
> + 5 - general purpose
> + 6 - general purpose
> + 7 - system supply
> + 8 - backup battery
> + 9 - charger input
> + 10 - VBUS
> + 11 - VBUS charging current
> + 14 - USB ID
> + 17 - battery charging current
> + 18 - battery voltage
> +
> +Example:
> + adc {
> + compatible = "ti,twl6030-gpadc";
> + interrupts = <3>;
> + #io-channel-cells = <1>;
> + };
> --
> 1.8.1.2
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] PCI: tegra: replace devm_request_and_ioremap by devm_ioremap_resource
From: Julia Lawall
Use devm_ioremap_resource instead of devm_request_and_ioremap.
This was done using the semantic patch
scripts/coccinelle/api/devm_ioremap_resource.cocci
Error-handling code was manually removed from the associated calls to
platform_get_resource.
Adjust the comment at the third platform_get_resource_byname to make clear
why ioremap is not done at this point.
Signed-off-by: Julia Lawall
Acked-by: Thierry Reding
Tested-by: Thierry Reding
---
v2: add the change to the comment
drivers/pci/host/pci-tegra.c | 31 ++-
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 7356741..2e9888a 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1031,32 +1031,21 @@ static int tegra_pcie_get_resources(struct tegra_pcie
*pcie)
return err;
}
- /* request and remap controller registers */
pads = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pads");
- if (!pads) {
- err = -EADDRNOTAVAIL;
+ pcie->pads = devm_ioremap_resource(&pdev->dev, pads);
+ if (IS_ERR(pcie->pads)) {
+ err = PTR_ERR(pcie->pads);
goto poweroff;
}
afi = platform_get_resource_byname(pdev, IORESOURCE_MEM, "afi");
- if (!afi) {
- err = -EADDRNOTAVAIL;
- goto poweroff;
- }
-
- pcie->pads = devm_request_and_ioremap(&pdev->dev, pads);
- if (!pcie->pads) {
- err = -EADDRNOTAVAIL;
- goto poweroff;
- }
-
- pcie->afi = devm_request_and_ioremap(&pdev->dev, afi);
- if (!pcie->afi) {
- err = -EADDRNOTAVAIL;
+ pcie->afi = devm_ioremap_resource(&pdev->dev, afi);
+ if (IS_ERR(pcie->afi)) {
+ err = PTR_ERR(pcie->afi);
goto poweroff;
}
- /* request and remap configuration space */
+ /* request configuration space, but remap later, on demand */
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cs");
if (!res) {
err = -EADDRNOTAVAIL;
@@ -1492,9 +1481,9 @@ static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
rp->lanes = value;
rp->pcie = pcie;
- rp->base = devm_request_and_ioremap(pcie->dev, &rp->regs);
- if (!rp->base)
- return -EADDRNOTAVAIL;
+ rp->base = devm_ioremap_resource(pcie->dev, &rp->regs);
+ if (IS_ERR(rp->base))
+ return PTR_ERR(rp->base);
list_add_tail(&rp->list, &pcie->ports);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/16] arch/arm/mach-ux500/cpu-db8500.c: Avoid using ARRAY_AND_SIZE(e) as a function argument
On Sun, Aug 11, 2013 at 6:51 PM, Julia Lawall wrote: > From: Julia Lawall > > Replace ARRAY_AND_SIZE(e) in function argument position to avoid hiding the > arity of the called function. Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] Soft limit rework
On Mon 19-08-13 12:35:12, Johannes Weiner wrote: > On Tue, Jun 18, 2013 at 02:09:39PM +0200, Michal Hocko wrote: > > Hi, > > > > This is the fifth version of the patchset. > > > > Summary of versions: > > The first version has been posted here: > > http://permalink.gmane.org/gmane.linux.kernel.mm/97973 > > (lkml wasn't CCed at the time so I cannot find it in lwn.net > > archives). There were no major objections. > > Except there are. Good to know that late... It would have been much more helpful to have such a principal feedback few months ago (this work is here since early Jun). > > My primary test case was a parallel kernel build with 2 groups (make > > is running with -j4 with a distribution .config in a separate cgroup > > without any hard limit) on a 8 CPU machine booted with 1GB memory. I > > was mostly interested in 2 setups. Default - no soft limit set and - and > > 0 soft limit set to both groups. > > The first one should tell us whether the rework regresses the default > > behavior while the second one should show us improvements in an extreme > > case where both workloads are always over the soft limit. > > Two kernel builds with 1G of memory means that reclaim is purely > trimming the cache every once in a while. Changes in memory pressure > are not measurable up to a certain point, because whether you trim old > cache or not does not affect the build jobs. > > Also you tested the no-softlimit case and an extreme soft limit case. > Where are the common soft limit cases? v5.1 had some more tests. I have added soft limitted stream IO resp. kbuild vs unlimitted mem_eater loads. Have you checked those? [...] > > So to wrap this up. The series is still doing good and improves the soft > > limit. > > The soft limit tree is a bunch of isolated code that's completely > straight-forward. This is replaced by convoluted memcg iterators, > convoluted lruvec shrinkers, spreading even more memcg callbacks with > questionable semantics into already complicated generic reclaim code. I was trying to keep the convolution into vmscan as small as possible. Maybe it can get reduced even more. I will think about it. Predicate for memcg iterator has been added to address your concern about a potential regression with too many groups. And that looked like the least convoluting solution. > This series considerably worsens readability and maintainability of > both the generic reclaim code as well as the memcg counterpart of it. I am really surprised that you are coming with this concerns that late. This code has been posted quite some ago, hasn't it? We have even had that "calm" discussion with Tejun about predicates and you were silent at the time. > The point of naturalizing the memcg code is to reduce data structures > and redundancy and to break open opaque interfaces like "do soft > reclaim and report back". But you didn't actually reduce complexity, > you added even more opaque callbacks (should_soft_reclaim? > soft_reclaim_eligible?). You didn't integrate soft limit into generic > reclaim code, you just made the soft limit API more complicated. I can certainly think about simplifications. But it would be nicer if you were more specific on the "more complicated" part. The soft reclaim is a natural part of the reclaim now. Which I find as an improvement. "Do some memcg magic and get back was" a bad idea IMO. Hiding the soft limit decisions into the iterators as a searching criteria doesn't sound as a totally bad idea to me. Soft limit is an additional criteria who to reclaim, isn't it? Well, I could have open coded it but that would mean a more code into vmscan or getting back to "call some memcg magic and get back to me". > And, as I mentioned repeatedly in previous submissions, your benchmark > numbers don't actually say anything useful about this change. I would really welcome suggestions for improvements. I have tried "The most interesting test case would be how it behaves if some groups are over the soft limits while others are not." with v5.1 where I had memeater unlimited and kbuild resp. stream IO being limited. > I'm against merging this upstream at this point. Can we at least find some middle ground here? The way how the current soft limit is done is a disaster. Ditching the whole series sounds like a step back to me. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 06/17] ARM: imx: remove custom .init_time hook
On 08/20/2013 11:10 AM, Sascha Hauer wrote: On Tue, Aug 20, 2013 at 10:48:44AM +0200, Sebastian Hesselbarth wrote: On 08/20/2013 09:26 AM, Sascha Hauer wrote: On i.MX5 the init_time hook calls mx5x_clocks_init_dt which calls mx5x_clocks_init which not only calls of_clk_init() but also registers all clocks in the system. You can't remove it. I am missing some CLK_OF_DECLARE(imx51, "fsl,imx51-ccm", imx51_clocks_init); CLK_OF_DECLARE(imx53, "fsl,imx53-ccm", imx53_clocks_init); Somewhere. Sascha, you are right, I forgot to add the two lines above as replacement for the now removed direct call. If the general approach is accepted, I'll add them for sure. Do imx51/imx53 still boot with CLK_OF_DECLARE added? I can test this once the whole series arrived here. So far I only have 6/16 and 10/17. I probably need at least 1/17. Yeah, I am having troubles with linux-arm-kernel rejecting my mails because of a suspicious header. I have no clue, what has changed lately with my mails sent by git send-email to make them get stuck. I didn't add all sub-arch maintainers to the whole set, that would have been simply too many. You need patches [1], [2], and 6 for imx which I will send a v2 in a second. Ok for you to get them from lkml? Sebastian [1] https://lkml.org/lkml/2013/8/19/591 [2] https://lkml.org/lkml/2013/8/19/592 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] ARM: at91: move peripheral id definitions to dt-bindings include dir
2013/8/19 Nicolas Ferre : > On 08/08/2013 06:09, boris brezillon : > >> Hello Arnd, >> >> On 07/08/2013 22:24, Arnd Bergmann wrote: >>> >>> On Thursday 01 August 2013, Boris BREZILLON wrote: This patch moves peripheral id definitions from machine specific include dir (arch/arm/mach-at91/include/mach/'soc-name'.h) to dt-bindinds include dir (include/dt-bindings/at91/'soc-name'/peripherals.h). These definitions will be used inside dt to define interrupt ids and peripheral clk ids. Signed-off-by: Boris BREZILLON >>> >>> This seems counterproductive, why would you do that? >> >> >> This was requested by Jean-Christophe Plagniol-Villard (and proposed by >> Richard Genoud) >> for the 3rd version of the "ARM: at91: move to common clk framework" >> patch series (see >> https://lkml.org/lkml/2013/7/29/361) and thought it was a good idea too >> (even if I didn't know >> where to put the macro files as there are no soc specific macro files in >> dt-bindings include >> dir). >> >> Indeed I found it much easier to detect bugs in dt definition using >> macros because >> the macro names and dt node names are the same (it does not protect >> against errors >> in the macro definitions). >> >> If you think these macro definitions should be dropped, I won't argue >> against this. >> But please, have a talk with Jean-Christophe first. > > > [..] > > >>> There is no sharing of identifiers across SoCs here, you just move the >>> data around, and changing the .dts files to use the abstract macros would >>> just end up making them harder to understand, not easier, since you then >>> have to look up the numbers in another file. > > > Boris, Jean-Christophe and Richard, > > Well, I must say that I do agree with Arnd on this point. > > I think that a simple numeric field in a cell has to be represented as a > number and even if this simple information is used twice (interrupt number > and clock bit position in PMC). The possibility of error is very low > compared to the big amount of unneeded definitions added by this solution. Well, maybe the use of macro there is a bit overkill... But after reviewing the patches (and found an error), I thought it was useful to use macros, because verifying each number according to the SoC manual is a pain ! It's way easier to check the header once for all, then there's no possible error in the dtsi (or at least, we can see it from far far away...) On the downside, I agree, it adds a lot of defines. (and once it has been validated, the dtsi should not change) my 2 cents... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC v2] ARM: imx: remove custom .init_time hook
With arch/arm calling of_clk_init(NULL) from time_init(), we can now
remove custom .init_time hooks.
Signed-off-by: Sebastian Hesselbarth
---
Notes:
- Although mx5_clocks_common_init() is shared with non-DT, removing
of_clk_init(NULL) should be fine, as it only registers DT clk providers.
- For imx6q, printing of silicon revision has been moved from .init_time
to .init_machine hook.
Changelog:
v1->v2:
- added missing CLK_OF_DECLARE for imx51 and imx53 (Reported by Sascha Hauer)
mx53_clocks_init can be converted as it is used DT only, mx51_clocks_init
still is used by non-DT.
Cc: Russell King
Cc: Arnd Bergmann
Cc: Sascha Hauer
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-imx/clk-imx51-imx53.c | 29 ++---
arch/arm/mach-imx/common.h |4
arch/arm/mach-imx/imx51-dt.c|6 --
arch/arm/mach-imx/mach-imx53.c |6 --
arch/arm/mach-imx/mach-imx6q.c | 14 +++---
arch/arm/mach-imx/mach-imx6sl.c |7 ---
arch/arm/mach-imx/mach-vf610.c |9 -
7 files changed, 13 insertions(+), 62 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c
b/arch/arm/mach-imx/clk-imx51-imx53.c
index 1a56a33..1b796db 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -131,8 +132,6 @@ static void __init mx5_clocks_common_init(unsigned long
rate_ckil,
{
int i;
- of_clk_init(NULL);
-
clk[dummy] = imx_clk_fixed("dummy", 0);
clk[ckil] = imx_obtain_fixed_clock("ckil", rate_ckil);
clk[osc] = imx_obtain_fixed_clock("osc", rate_osc);
@@ -465,12 +464,16 @@ int __init mx51_clocks_init(unsigned long rate_ckil,
unsigned long rate_osc,
return 0;
}
-int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
- unsigned long rate_ckih1, unsigned long rate_ckih2)
+static void __init mx51_clocks_init_dt(struct device_node *np)
+{
+ mx51_clocks_init(0, 0, 0, 0);
+}
+CLK_OF_DECLARE(imx51_ccm, "fsl,imx51-ccm", mx51_clocks_init_dt);
+
+static void __init mx53_clocks_init(struct device_node *np)
{
int i;
unsigned long r;
- struct device_node *np;
clk[pll1_sw] = imx_clk_pllv2("pll1_sw", "osc", MX53_DPLL1_BASE);
clk[pll2_sw] = imx_clk_pllv2("pll2_sw", "osc", MX53_DPLL2_BASE);
@@ -529,12 +532,11 @@ int __init mx53_clocks_init(unsigned long rate_ckil,
unsigned long rate_osc,
pr_err("i.MX53 clk %d: register failed with %ld\n",
i, PTR_ERR(clk[i]));
- np = of_find_compatible_node(NULL, NULL, "fsl,imx53-ccm");
clk_data.clks = clk;
clk_data.clk_num = ARRAY_SIZE(clk);
of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
- mx5_clocks_common_init(rate_ckil, rate_osc, rate_ckih1, rate_ckih2);
+ mx5_clocks_common_init(0, 0, 0, 0);
clk_register_clkdev(clk[vpu_gate], NULL, "imx53-vpu.0");
clk_register_clkdev(clk[i2c3_gate], NULL, "imx21-i2c.2");
@@ -566,16 +568,5 @@ int __init mx53_clocks_init(unsigned long rate_ckil,
unsigned long rate_osc,
r = clk_round_rate(clk[usboh3_per_gate], 5400);
clk_set_rate(clk[usboh3_per_gate], r);
-
- return 0;
-}
-
-int __init mx51_clocks_init_dt(void)
-{
- return mx51_clocks_init(0, 0, 0, 0);
-}
-
-int __init mx53_clocks_init_dt(void)
-{
- return mx53_clocks_init(0, 0, 0, 0);
}
+CLK_OF_DECLARE(imx53_ccm, "fsl,imx53-ccm", mx53_clocks_init);
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 4517fd7..28e8ca0 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -63,13 +63,9 @@ extern int mx31_clocks_init(unsigned long fref);
extern int mx35_clocks_init(void);
extern int mx51_clocks_init(unsigned long ckil, unsigned long osc,
unsigned long ckih1, unsigned long ckih2);
-extern int mx53_clocks_init(unsigned long ckil, unsigned long osc,
- unsigned long ckih1, unsigned long ckih2);
extern int mx25_clocks_init_dt(void);
extern int mx27_clocks_init_dt(void);
extern int mx31_clocks_init_dt(void);
-extern int mx51_clocks_init_dt(void);
-extern int mx53_clocks_init_dt(void);
extern struct platform_device *mxc_register_gpio(char *name, int id,
resource_size_t iobase, resource_size_t iosize, int irq, int irq_high);
extern void mxc_set_cpu_type(unsigned int type);
diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
index 53e43e5..bece8a6 100644
--- a/arch/arm/mach-imx/imx51-dt.c
+++ b/arch/arm/mach-imx/imx51-dt.c
@@ -34,17 +34,11 @@ static const char *imx51_dt_board_compat[] __initdata = {
NULL
};
-static void __init imx51_timer_init(void)
-{
- mx51_clocks_init_dt();
-}
-
DT_MACHINE_START(IMX51_DT, "Freescale
Re: [PATCH] i2c: move of helpers into the core
[Added Jerry as he found out a problem when acpi_i2c is being build as a
module, this should solve it as well.]
On Tue, Aug 20, 2013 at 01:25:27AM +0200, Rafael J. Wysocki wrote:
> On Monday, August 19, 2013 04:56:19 PM Stephen Warren wrote:
> > On 08/19/2013 05:04 PM, Rafael J. Wysocki wrote:
> > > On Monday, August 19, 2013 03:19:18 PM Wolfram Sang wrote:
> > >> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> > >> that it is much cleaner to have this in the core. This also removes a
> > >> circular dependency between the helpers and the core, and so we can
> > >> finally register child nodes in the core instead of doing this manually
> > >> in each driver. So, fix the drivers and documentation, too.
> > >
> > > Perhaps we should do the analogous for ACPI then?
Here is the ACPI version based on the current patch from Wolfram (there is
a compile error because of missing dummy implementation of
of_i2c_register_devices())
From: Mika Westerberg
Subject: [PATCH] i2c: move ACPI helpers into the core
This follows what has already been done for the DeviceTree helpers. Move
the ACPI helpers from drivers/acpi/acpi_i2c.c to the I2C core and update
documentation accordingly.
This also solves a problem reported by Jerry Snitselaar that we can't build
the ACPI I2C helpers as a module.
Signed-off-by: Mika Westerberg
---
Documentation/acpi/enumeration.txt | 15 +---
drivers/acpi/Kconfig| 6 --
drivers/acpi/Makefile | 1 -
drivers/acpi/acpi_i2c.c | 103
drivers/i2c/busses/i2c-designware-platdrv.c | 1 -
drivers/i2c/i2c-core.c | 91
include/linux/i2c.h | 6 --
7 files changed, 94 insertions(+), 129 deletions(-)
delete mode 100644 drivers/acpi/acpi_i2c.c
diff --git a/Documentation/acpi/enumeration.txt
b/Documentation/acpi/enumeration.txt
index 958266e..d98 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -228,18 +228,9 @@ ACPI handle like:
I2C serial bus support
~~
The slaves behind I2C bus controller only need to add the ACPI IDs like
-with the platform and SPI drivers. However the I2C bus controller driver
-needs to call acpi_i2c_register_devices() after it has added the adapter.
-
-An I2C bus (controller) driver does:
-
- ...
- ret = i2c_add_numbered_adapter(adapter);
- if (ret)
- /* handle error */
-
- /* Enumerate the slave devices behind this bus via ACPI */
- acpi_i2c_register_devices(adapter);
+with the platform and SPI drivers. The I2C core automatically enumerates
+any slave devices behind the controller device once the adapter is
+registered.
Below is an example of how to add ACPI support to the existing mpu3050
input driver:
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 100bd72..4e0162f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -180,12 +180,6 @@ config ACPI_DOCK
This driver supports ACPI-controlled docking stations and removable
drive bays such as the IBM Ultrabay and the Dell Module Bay.
-config ACPI_I2C
- def_tristate I2C
- depends on I2C
- help
- ACPI I2C enumeration support.
-
config ACPI_PROCESSOR
tristate "Processor"
select THERMAL
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 81dbeb8..cdaf68b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -73,7 +73,6 @@ obj-$(CONFIG_ACPI_HED)+= hed.o
obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
obj-$(CONFIG_ACPI_BGRT)+= bgrt.o
-obj-$(CONFIG_ACPI_I2C) += acpi_i2c.o
# processor has its own "processor." module_param namespace
processor-y:= processor_driver.o processor_throttling.o
diff --git a/drivers/acpi/acpi_i2c.c b/drivers/acpi/acpi_i2c.c
deleted file mode 100644
index a82c762..000
--- a/drivers/acpi/acpi_i2c.c
+++ /dev/null
@@ -1,103 +0,0 @@
-/*
- * ACPI I2C enumeration support
- *
- * Copyright (C) 2012, Intel Corporation
- * Author: Mika Westerberg
- *
- * 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
-
-ACPI_MODULE_NAME("i2c");
-
-static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
-{
- struct i2c_board_info *info = data;
-
- if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
- struct acpi_resource_i2c_serialbus *sb;
-
- sb = &ares->data.i2c_serial_bus;
- if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
- info->addr = sb->slave_address;
- if (sb->access_mode =
Re: Build regressions/improvements in v3.11-rc6
On Tue, 20 Aug 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.11-rc6 to v3.11-rc5[3], the summaries are:
> - build errors: +6/-9
+ arch/powerpc/kvm/book3s_xics.c: error: implicit declaration of function
'get_tb' [-Werror=implicit-function-declaration]: => 812:3
powerpc-randconfig
+ error: No rule to make target /etc/sound/dsp001.ld: => N/A
i386-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/6556/ (all 120 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/6532/ (all 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
