[PATCH 5/5] rtc: s5m: Enable IRQ wake during suspend

[Krzysztof Kozlowski]

Add PM suspend/resume ops to rtc-s5m driver and enable IRQ wake during
suspend so the RTC would act like a wake up source. This allows waking
up from suspend to RAM on RTC alarm interrupt.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Kyungmin Park 
---
 drivers/rtc/rtc-s5m.c |   25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 51471c1..ae8119d 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -639,6 +639,30 @@ static void s5m_rtc_shutdown(struct platform_device *pdev)
s5m_rtc_enable_smpl(info, false);
 }
 
+static int s5m_rtc_resume(struct device *dev)
+{
+   struct s5m_rtc_info *info = dev_get_drvdata(dev);
+   int ret = 0;
+
+   if (device_may_wakeup(dev))
+   ret = disable_irq_wake(info->irq);
+
+   return ret;
+}
+
+static int s5m_rtc_suspend(struct device *dev)
+{
+   struct s5m_rtc_info *info = dev_get_drvdata(dev);
+   int ret = 0;
+
+   if (device_may_wakeup(dev))
+   ret = enable_irq_wake(info->irq);
+
+   return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(s5m_rtc_pm_ops, s5m_rtc_suspend, s5m_rtc_resume);
+
 static const struct platform_device_id s5m_rtc_id[] = {
{ "s5m-rtc", 0 },
 };
@@ -647,6 +671,7 @@ static struct platform_driver s5m_rtc_driver = {
.driver = {
.name   = "s5m-rtc",
.owner  = THIS_MODULE,
+   .pm = _rtc_pm_ops,
},
.probe  = s5m_rtc_probe,
.shutdown   = s5m_rtc_shutdown,
-- 
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 4/5] mfd: sec: Add PM ops and make it a wake up source

[Krzysztof Kozlowski]

Add PM suspend/resume ops to the sec MFD core driver and make it a wake
up source. This allows proper waking from suspend to RAM and also fixes
broken interrupts after resuming:
[   42.705703] sec_pmic 7-0066: Failed to read IRQ status: -5

Interrupts stop working after first resume initiated by them (e.g. by
RTC Alarm interrupt) because interrupt registers were not cleared properly.

When device is woken up from suspend by RTC Alarm, an interrupt occurs
before resuming I2C bus controller. The interrupt is handled by
regmap_irq_thread which tries to read RTC registers. This read fails
(I2C is still suspended) and RTC Alarm interrupt is disabled.

Disable the S5M8767 interrupts during suspend (disable_irq()) and enable
them during resume so the device will be still woken up but the interrupt
won't happen before resuming I2C bus.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Kyungmin Park 
---
 drivers/mfd/sec-core.c |   40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index a1a413a..8c86da4 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -323,6 +323,8 @@ static int sec_pmic_probe(struct i2c_client *i2c,
if (ret)
goto err;
 
+   device_init_wakeup(sec_pmic->dev, sec_pmic->wakeup);
+
return ret;
 
 err:
@@ -341,6 +343,43 @@ static int sec_pmic_remove(struct i2c_client *i2c)
return 0;
 }
 
+static int sec_pmic_suspend(struct device *dev)
+{
+   struct i2c_client *i2c = container_of(dev, struct i2c_client, dev);
+   struct sec_pmic_dev *sec_pmic = i2c_get_clientdata(i2c);
+
+   if (device_may_wakeup(dev)) {
+   enable_irq_wake(sec_pmic->irq);
+   /*
+* PMIC IRQ must be disabled during suspend for RTC alarm
+* to work properly.
+* When device is woken up from suspend by RTC Alarm, an
+* interrupt occurs before resuming I2C bus controller.
+* The interrupt is handled by regmap_irq_thread which tries
+* to read RTC registers. This read fails (I2C is still
+* suspended) and RTC Alarm interrupt is disabled.
+*/
+   disable_irq(sec_pmic->irq);
+   }
+
+   return 0;
+}
+
+static int sec_pmic_resume(struct device *dev)
+{
+   struct i2c_client *i2c = container_of(dev, struct i2c_client, dev);
+   struct sec_pmic_dev *sec_pmic = i2c_get_clientdata(i2c);
+
+   if (device_may_wakeup(dev)) {
+   disable_irq_wake(sec_pmic->irq);
+   enable_irq(sec_pmic->irq);
+   }
+
+   return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(sec_pmic_pm_ops, sec_pmic_suspend, sec_pmic_resume);
+
 static const struct i2c_device_id sec_pmic_id[] = {
{ "sec_pmic", 0 },
{ }
@@ -351,6 +390,7 @@ static struct i2c_driver sec_pmic_driver = {
.driver = {
   .name = "sec_pmic",
   .owner = THIS_MODULE,
+  .pm = _pmic_pm_ops,
   .of_match_table = of_match_ptr(sec_dt_match),
},
.probe = sec_pmic_probe,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] rtc: s5m: Fix unsuccesful IRQ request during probe

[Krzysztof Kozlowski]

Probe failed for rtc-s5m:
s5m-rtc s5m-rtc: Failed to request alarm IRQ: 12: -22
s5m-rtc: probe of s5m-rtc failed with error -22

Fix rtc-s5m interrupt request by using regmap_irq_get_virq() for mapping
the IRQ.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Kyungmin Park 
---
 drivers/rtc/rtc-s5m.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 088cf3a..66686d9 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -548,11 +548,13 @@ static int s5m_rtc_probe(struct platform_device *pdev)
 
switch (pdata->device_type) {
case S5M8763X:
-   info->irq = s5m87xx->irq_base + S5M8763_IRQ_ALARM0;
+   info->irq = regmap_irq_get_virq(s5m87xx->irq_data,
+   S5M8763_IRQ_ALARM0);
break;
 
case S5M8767X:
-   info->irq = s5m87xx->irq_base + S5M8767_IRQ_RTCA1;
+   info->irq = regmap_irq_get_virq(s5m87xx->irq_data,
+   S5M8767_IRQ_RTCA1);
break;
 
default:
-- 
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 0/5] rtc: s5m: Bug fixes of the driver after tests

[Krzysztof Kozlowski]

Hi,

This is a patchset of small but important fixes for rtc-s5m driver. Last
patches also add waking up on RTC alarm interrupts.

The patchset is based on v3.13-rc1-95-gb975dc3 and depends on patch from 
Geert Uytterhoeven:
 - rtc: s5m-rtc: Fix info->rtc assignment
   http://article.gmane.org/gmane.linux.kernel/1595905

Best regards,
Krzysztof

Krzysztof Kozlowski (5):
  rtc: s5m: Fix register updating by adding regmap for RTC
  rtc: s5m: Fix unsuccesful IRQ request during probe
  rtc: s5m: Limit endless loop waiting for register update
  mfd: sec: Add PM ops and make it a wake up source
  rtc: s5m: Enable IRQ wake during suspend

 drivers/mfd/sec-core.c   |   54 +
 drivers/rtc/rtc-s5m.c|   70 +-
 include/linux/mfd/samsung/core.h |1 +
 3 files changed, 116 insertions(+), 9 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/

Re: [PATCH] perf timechart: remove lock_depth from trace_entry

[Stanislav Fomichev]

> Se above, if before this patch the format_field info was obtained from
> the perf.data file, why should it now get it from the local machine?
Yes, sorry for confusion, I didn't know that we can obtain trace events
format from the perf.data. I hence have no concerns regarding your
implementation :-)

> Please try. There should be no limitations.
It does not work because lock_depth and common_pid are common fields,
while perf_evsel__field looks in non-common fields. And even if we find
lock_depth/common_pid common field we can't do field->next, because
common and non-common fields are not linked and ->next in the last common
field is NULL (this is what I got when I tried to use pevent_find_any_field
instead of pevent_find_field in perf_evsel__field).

I slightly modified timechart__set_payload_offset from you patch to look
for the first non-common field and use its offset, but it looks kinda ugly:

static int timechart__set_payload_offset(struct perf_evlist *evlist)
{
   struct perf_evsel *evsel = perf_evlist__first(evlist);
   struct format_field *field = evsel->tp_format->format.fields;

   if (!field)
   return -1;

   payload_offset = field->offset;
   return 0;
}

Maybe we can add some helper routine which returns first non-common
field, like:

struct format_field *perf_evsel__first_field(struct perf_evsel *evsel, const 
char *name)
{
return evsel->tp_format->format.fields;
}

and call it in timechart__set_payload_offset?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/11] ext4: add cross rename support

[Miklos Szeredi]

On Tue, Nov 26, 2013 at 10:51:25AM +0100, Jan Kara wrote:
> On Wed 20-11-13 14:01:52, Miklos Szeredi wrote:
> > From: Miklos Szeredi 
> > 
> > Implement RENAME_EXCHANGE flag in renameat2 syscall.
> > 
> > Signed-off-by: Miklos Szeredi 
> > ---
> >  fs/ext4/namei.c | 97 
> > -
> >  1 file changed, 69 insertions(+), 28 deletions(-)
> > 
> > diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> > index d258b354b937..5307e482f403 100644
> > --- a/fs/ext4/namei.c
> > +++ b/fs/ext4/namei.c
> ...
> > -   old.dir->i_ctime = old.dir->i_mtime = ext4_current_time(old.dir);
> > -   ext4_update_dx_flag(old.dir);
> > +   /* S_ISDIR(old.inode->i_mode */
> > if (old.dir_bh) {
> > retval = ext4_rename_dir_finish(handle, , new.dir->i_ino);
> > if (retval)
> > goto end_rename;
> >  
> > -   ext4_dec_count(handle, old.dir);
> > -   if (new.inode) {
> > -   /* checked empty_dir above, can't have another parent,
> > -* ext4_dec_count() won't work for many-linked dirs */
> > -   clear_nlink(new.inode);
> > -   } else {
> > +   if (!(flags & RENAME_EXCHANGE) || !S_ISDIR(new.inode->i_mode))
> > +   ext4_dec_count(handle, old.dir);
> > +
> > +   if (!new.inode || !S_ISDIR(new.inode->i_mode)) {
> > ext4_inc_count(handle, new.dir);
> > ext4_update_dx_flag(new.dir);
> > ext4_mark_inode_dirty(handle, new.dir);
> > }
> > }
> > +   /* (flags & RENAME_EXCHANGE) && S_ISDIR(new.inode->i_mode */
> > +   if (new.dir_bh) {
> > +   retval = ext4_rename_dir_finish(handle, , old.dir->i_ino);
> > +   if (retval)
> > +   goto end_rename;
> > +
> > +   if (!S_ISDIR(old.inode->i_mode)) {
> > +   ext4_dec_count(handle, new.dir);
> > +   ext4_inc_count(handle, old.dir);
> > +   ext4_mark_inode_dirty(handle, new.dir);
> > +   }
> > +   }
> > ext4_mark_inode_dirty(handle, old.dir);
> > -   if (new.inode) {
> > +   if (!(flags & RENAME_EXCHANGE) && new.inode) {
> > +   ext4_dec_count(handle, new.inode);
> > +   new.inode->i_ctime = ext4_current_time(new.inode);
> > +   if (S_ISDIR(old.inode->i_mode)) {
> > +   /* checked empty_dir above, can't have another parent,
> > +* ext4_dec_count() won't work for many-linked dirs */
> > +   clear_nlink(new.inode);
> > +   }
>   This hunk looks strange. Why do you check S_ISDIR(old.inode->i_mode)? I'd
> presume we need to clear nlink if new.inode is a directory...

It's confusing, that's for sure.  I think it's correct, since S_ISDIR(old) is
equivalent to S_ISDIR(new) if not cross-renaming, but that's not a lot of
consolation to someone trying to understand the code.

> 
> > ext4_mark_inode_dirty(handle, new.inode);
> > if (!new.inode->i_nlink)
> > ext4_orphan_add(handle, new.inode);
>   Generally, I'm a bit unhappy about the number of various RENAME_EXCHANGE
> checks and the asymmetry between new & old which now shouldn't needed (that
> much). Especially the link count handling looks more complex than it should
> be.
> 
> I'd hope that it should be possible to "delete new.inode iff
> !RENAME_EXCHANGE" and then the rest shouldn't need to care about
> RENAME_EXCHANGE at all and treat old & new completely symmetrically... Now I
> realize this isn't that easy because we want to do all error checks first
> before doing any changes on disk but still I hope some improvement can be
> made (maybe just zero out new.inode in our 'new' ext4_renament to allow for
> code to be symmetric and delete it on disk only when ext4_rename() is
> finishing).
> 
> If the above won't be workable, we might at least make the link count
> handling more obvious by computing "old_link_cnt_update,
> new_link_cnt_update" - how link counts of parent dirs should be updated
> (-1, 0, +1) and then do the checks and updates based on this in one place.

Okay, will try to clean this up.  I agree that it became a bit too complicated.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[Linus Walleij]

On Thu, Nov 21, 2013 at 11:34 AM, boris brezillon
 wrote:
> On 21/11/2013 10:48, Linus Walleij wrote:

>> No matter whether it's a switch or a GPIO regulator it seems we
>> are in violent agreement that it should not be controlled by the
>> pin control states at least.
>>
>> Start with making it a GPIO then you can figure out whether
>> a GPIO regulator or drivers/extcon/extcon-gpio.c should be
>> used.
>
> Thanks for pointing this out. I wasn't aware of the extcon subsystem.
>
> Actually, I think it's a little bit more tricky.

Hm, yeah extcon is for things like audio jacks on phones that
userspace need to detect.

drivers/input/keyboard/gpio_keys* is for things that actually
input characters to userspace stuff.

None of it is applicable here it seems ...

> The switch connected to gpio PB22 is used to enable one device or the other:
>  - PB22 set to high level enables slot0 of mmc0 (connect mmc signals to the
> mmc
>connector)
>  - PB22 set to low level enables the dataflash (connect to the SPI0 signals
> to the
>dataflash device)

So this is something like a "jumper" of the old type, configuring
the entire system?

Something like that:
http://www.mignonette-game.com/images/v2/21-arduino-com-jumper.jpg

But in this case it is a mechanical switch rather than a jumper?

This is not much different from the GPIOs people use to e.g. encode
the board type, just that it can change.

Do people switch this thing at runtime?

> The pinctrl approach has the benefit of providing a transparent way (no
> existing
> drivers modifications) to enable one device or the other.
>
> But if you think this is better done (or cleaner) with an extcon or a
> regulator device,
> I'll try to find a way to do it this way.

I'm uncertain. If this is something that changes at runtime, the
input from the switch should be read through GPIO and used
to select the "default" state of one device and something like
"sleep" on the other (I suspect more things than pin control
may be affected by that!)

If this is a switch that you want to take the simple shortcut
of just reading at boot, the approach would still be similar, just
less code.

So use gpio_get() to read the value, and then select which
*entire device* goes active depending on the setting would
be the right approach I guess?

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: [PATCHv1] ASoC: SGTL5000: Fix kernel failed while getting regulator consumers

[Mark Brown]

On Tue, Nov 26, 2013 at 05:55:13PM +0800, Xiubo Li wrote:

> +static int sgtl5000_external_vddd_used(struct snd_soc_codec *codec)
> +{
> + struct regulator *consumer;
> + struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec);
> +
> + consumer = regulator_get(codec->dev, sgtl5000->supplies[VDDD].supply);
> + if (IS_ERR(consumer)) {
> + return 0;
> + }
> + regulator_put(consumer);
> +
> + return 1;
> +}

This is going to fail to do what you expect if a dummy regulator is
substituted which it will almost all of the time when the supply is
genuinely absent.  It's also going to interact poorly with probe
deferral.

> - ret = regulator_bulk_get(codec->dev, ARRAY_SIZE(sgtl5000->supplies),
> - sgtl5000->supplies);
> - if (!ret)
> + if (sgtl5000_external_vddd_used(codec))
>   external_vddd = 1;
>   else {
>   ret = sgtl5000_replace_vddd_with_ldo(codec);

This looks buggy, it removes the regulator_get() for most of the
supplies for the device.

I think the driver may want to use regulator_get_optional(), though
looking at the fact that there's an external_vdd flag there already it
seems like there's already some attempt to handle these configuratins in
the driver that isn't working so perhaps that just needs to be fixed.
Or possibly DTs need to be changed to describe the supply.  

I'd expect to see a commit description that describes how the driver
currently tries to handle this, why it doesn't work and how the patch
fixes it.  Right now it seems like the change is jumping to a solution
without understanding the problem and making some already problematic
code more confused.


signature.asc
Description: Digital signature

Re: [PATCH] i2c-mux-pca954x: Disable mux after 200ms timeout

[Ulf Hansson]

On 26 November 2013 13:28, Wolfram Sang  wrote:
>
> CCing linux-pm, maybe they know more...
>
>> The extra I2C traffic consumes extra power. If the bus is terminated
>> using 2k resistors, approximately 1mA of current (assuming ~2V
>> signals) is flowing when the bus is pulled low. On low power
>> designs, this extra power consumption is noticable. There is no way
>> to turn the mux "off" from either user or kernel space. The signals
>> going through the mux to a place where no I2C device is actually
>> listening are only wasting power.
>
> I only have an overview of current linux pm mechanisms. I wonder if
> those can't be used somehow. Like if devices on the multiplexed bus are
> idle (well, only regarding transfers), then we can switch off the muxer.
>
>> The I2C signals are used to control sensitive codecs. When looking
>> at the sampled data, the I2C traffic is visible in the captured
>> analog signal. To prevent this from happening, the mux can be
>
> I wonder: Is this really a feature of sensitive codecs or an issue of
> the board design?
>
>> disabled whenever not communicating with the codec. This could be
>> accomplished with the "deselect_on_exit" boolean, but because audio
>> driver sends the codec parameters in dozens of small transactions,
>> this will result in a lot more needless I2C traffic, constantly
>> switching the mux for each codec setting.
>
> Has this been looked at? ASoC supports grouping of tranfers IIRC. Maybe
> your I2C driver is only missing I2C_M_NOSTART?.
>
>> Would it be acceptable if I made the timeout optional, by making the
>> "deselect_on_exit" boolean into a three-state value (off, on,
>> timeout)? Or, alternatively, implement "deselect_on_exit" using the
>> timeout scheme (probably with a very short timeout)?
>
> I have a number of concerns designwise. First, if we do something like
> shutting-down-a-bus-if-there-are-no-transfers-expected, it definately
> should be in the core, not the driver. As said before, I have the
> assumption it should even be connected to the runtime pm core via some
> callback. And if we have that for I2C, we surely want that for other
> buses as well, at least SPI. Also, the timeout thing sounds too
> heuristic to me. Later, people might want to change the timeout value
> depending on workloads or so, and then a governor, etc... No, thanks.

It very much sounds like runtime PM should help you here. Then you get
the reference counting and the so called runtime_autosuspend feature
for free. :-)

>
> BTW is it feasible to shut down the whole I2C bus at controller level
> after transfers? No needless transfers and maybe even more power
> savings.

For sure this should be possible. Some controller drivers have started
to adapt some runtime PM code for this is already, nomadik and omap
for example. I think typically clocks, pins and if there are a power
domain regulator for the controller, those should be handled through
runtime PM to save power at "request inactivity".

Kind regards
Ulf Hansson

>
> Anyway, thanks for letting me know about your requirements (they should
> have been in the original commit message, though ;))
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] intel_idle: Fixed C6 state on Avoton/Rangeley processors

[Bockholdt Arne]

Corrected the MWAIT flag for C-State C6 on Intel Avoton/Rangeley processors.

v1..v2: Dropped additional fixup already handled by previous patch

Signed-off-by: Arne Bockholdt 
---

diff -up linux/drivers/idle/intel_idle.c.orig linux/drivers/idle/intel_idle.c
--- linux/drivers/idle/intel_idle.c.orig2013-11-26 14:23:39.371706228 
+0100
+++ linux/drivers/idle/intel_idle.c 2013-11-26 14:24:05.399674929 +0100
@@ -340,7 +340,7 @@ static struct cpuidle_state avn_cstates[
{
.name = "C6-AVN",
.desc = "MWAIT 0x51",
-   .flags = MWAIT2flg(0x58) | CPUIDLE_FLAG_TIME_VALID | 
CPUIDLE_FLAG_TLB_FLUSHED,
+   .flags = MWAIT2flg(0x51) | CPUIDLE_FLAG_TIME_VALID | 
CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 15,
.target_residency = 45,
.enter = _idle },

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: bridge not getting ip since 3.11.5 and 3.4.66

[Mark Trompell]

Answering my own mail again and even top posting, sorry, but makes
more sense to me in that case).
I reverted bridge related patches from 3.11.5 and it boils down to
commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32
Author: Herbert Xu 
Date:   Thu Sep 12 17:12:05 2013 +1000

bridge: Clamp forward_delay when enabling STP

[ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ]

At some point limits were added to forward_delay.  However, the
limits are only enforced when STP is enabled.  This created a
scenario where you could have a value outside the allowed range
while STP is disabled, which then stuck around even after STP
is enabled.

This patch fixes this by clamping the value when we enable STP.

I had to move the locking around a bit to ensure that there is
no window where someone could insert a value outside the range
while we're in the middle of enabling STP.

Causing the issue for me. Reverting that patch and br0 comes up again
and gets an ip.

On Tue, Nov 12, 2013 at 11:57 AM, Mark Trompell  wrote:
> On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell  
> wrote:
>> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico  
>> wrote:
>>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell  
>>> wrote:
 my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66,
 What information would be helpful and required to find out what's going 
 wrong.
>>>
>>> CC netdev
>>>
>>> First thing would be to provide the network scheme. Do you use vlans?
>>> Which network
>>> cards/drivers are you using? Do you use some kind of virtualization?
>>> Is bonding involved?
>>>
>> Actually this is my desktop machine using kvm for a virtual machine
>> that uses eth0 which is connected to the bridge
>> which is used as interface for the host.
>>
>> $ ip addr
>> 2. eth0:  mtu 1500 qdisc pfifo_fast
>> master br0 qlen 1000
>> ...
>> 3. br0:  mtu 1500 qdisc noqueue
>> ...
>>
>> Anything else?
>
> Okay more about my hardware and configuration:
> from lspci:
> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
> Connection (rev 04)
>
> /etc/sysconfig/network-scripts/ifcfg-br0
> DEVICE=br0
> ONBOOT=yes
> MACADDR=00:19:99:ac:b3:24
> TYPE=Bridge
> BOOTPROTO=dhcp
> STP=on
> NM_CONTROLLED=no
> DELAY=0
>
> /etc/sysconfig/network-scripts/ifcfg-eth0
> DEVICE=eth0
> HWADDR=00:19:99:cd:a5:e6
> #BOOTPROTO=dhcp
> ONBOOT=yes
> BRIDGE=br0
> TYPE=Ethernet
> NM_CONTROLLED=no
>
>
>> Greetings
>> Mark



-- 
Mark Trompell

Foresight Linux Xfce Edition
Cause your desktop should be freaking cool
(and Xfce)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined

[Eduardo Valentin]

On 26-11-2013 02:07, Amit Kachhap wrote:
> On 10/4/13, Bartlomiej Zolnierkiewicz  wrote:
>> Menu for Samsung thermal support is visible on all Samsung
>> platforms while thermal drivers are currently available only
>> for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency
>> with ARCH_EXYNOS one.
>>
>> Signed-off-by: Bartlomiej Zolnierkiewicz 
>> Signed-off-by: Kyungmin Park 
> Looks good, so
> Acked-by: Amit Daniel Kachhap 

I will be queuing this one in my tree.

Thanks Bartlomiej.

> 
>> ---
>>  drivers/thermal/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index a709c63..05cf95c 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -198,7 +198,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig"
>>  endmenu
>>
>>  menu "Samsung thermal drivers"
>> -depends on PLAT_SAMSUNG
>> +depends on ARCH_EXYNOS
>>  source "drivers/thermal/samsung/Kconfig"
>>  endmenu
>>
>> --
>> 1.8.2.3
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/5] mm: compaction: reset cached scanner pfn's before reading them

[Rik van Riel]

On 11/25/2013 09:26 AM, Vlastimil Babka wrote:
> Compaction caches pfn's for its migrate and free scanners to avoid scanning
> the whole zone each time. In compact_zone(), the cached values are read to
> set up initial values for the scanners. There are several situations when
> these cached pfn's are reset to the first and last pfn of the zone,
> respectively. One of these situations is when a compaction has been deferred
> for a zone and is now being restarted during a direct compaction, which is 
> also
> done in compact_zone().
> 
> However, compact_zone() currently reads the cached pfn's *before* resetting
> them. This means the reset doesn't affect the compaction that performs it, and
> with good chance also subsequent compactions, as update_pageblock_skip() is
> likely to be called and update the cached pfn's to those being processed.
> Another chance for a successful reset is when a direct compaction detects that
> migration and free scanners meet (which has its own problems addressed by
> another patch) and sets update_pageblock_skip flag which kswapd uses to do the
> reset because it goes to sleep.
> 
> This is clearly a bug that results in non-deterministic behavior, so this 
> patch
> moves the cached pfn reset to be performed *before* the values are read.
> 
> Cc: Mel Gorman 
> Cc: Rik van Riel 
> Signed-off-by: Vlastimil Babka 

Acked-by: Rik van Riel 

-- 
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regmap: use IS_ERR() to check clk_get() results

[Mark Brown]

On Mon, Nov 25, 2013 at 03:12:47PM -0700, Stephen Warren wrote:
> From: Stephen Warren 
> 
> clk_get() returns an error pointer, or a valid token to pass back to the
> clock API. Hence, the result must be checked with IS_ERR(), not by
> comparison against NULL.

Applied, thanks.


signature.asc
Description: Digital signature

[PATCH] perf tools: Fix not finding kcore in buildid cache

[Adrian Hunter]

The logic was not looking in the buildid cache for kcore
if the host kernel buildid did not match the recorded
kernel buildid.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/symbol.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index ce9ce10..360eefe 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1526,14 +1526,15 @@ static char *dso__find_kallsyms(struct dso *dso, struct 
map *map)
 
build_id__sprintf(dso->build_id, sizeof(dso->build_id), sbuild_id);
 
+   scnprintf(path, sizeof(path), "%s/[kernel.kcore]/%s", buildid_dir,
+ sbuild_id);
+
/* Use /proc/kallsyms if possible */
if (is_host) {
DIR *d;
int fd;
 
/* If no cached kcore go with /proc/kallsyms */
-   scnprintf(path, sizeof(path), "%s/[kernel.kcore]/%s",
- buildid_dir, sbuild_id);
d = opendir(path);
if (!d)
goto proc_kallsyms;
@@ -1558,6 +1559,10 @@ static char *dso__find_kallsyms(struct dso *dso, struct 
map *map)
goto proc_kallsyms;
}
 
+   /* Find kallsyms in build-id cache with kcore */
+   if (!find_matching_kcore(map, path, sizeof(path)))
+   return strdup(path);
+
scnprintf(path, sizeof(path), "%s/[kernel.kallsyms]/%s",
  buildid_dir, sbuild_id);
 
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c-designware-pci: Index Haswell ULT bus names from 0

[Wolfram Sang]

On Tue, Nov 19, 2013 at 06:14:18PM -0800, Benson Leung wrote:
> Hi Wolfram,
> 
> On Thu, Nov 14, 2013 at 10:05 AM, Wolfram Sang  wrote:
> >> In the chromeos_laptop driver, I do by-name matching of i2c busses to
> >> find busses and instantiate devices, so there is value to have each
> >> named something predictable.
> >
> > Any why don't you use fixed bus numbers which you can attach the devices
> > to?
> 
> On this particular set of systems, there are two other classes of i2c
> adapters that use dynamically assigned bus numbers, specifically the
> i915 gmbus adapters, and the i801_smbus adapter. This is why
> chromeos_laptop uses the name matching, as some of the boards that it
> supports have devices on those dynamic busses.

I am not sure I get the problem. If you use i2c_register_board_info() to
register the known devices on the designware busses the dynamically
assigned numbers are guaranteed to be enumarated higer than the static
ones. Check drivers/i2c/i2c-boardinfo.c.

Regards,

   Wolfram



signature.asc
Description: Digital signature

Re: [PATCH 3/3] perf inject: Handle output file via perf_data_file object

[Jiri Olsa]

On Tue, Nov 26, 2013 at 09:42:13AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 26, 2013 at 11:03:24AM +0100, Jiri Olsa escreveu:
> > On Mon, Nov 25, 2013 at 04:40:32PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, Nov 22, 2013 at 03:24:28PM +0100, Jiri Olsa escreveu:
> > > > Using the perf_data_file object to handle output
>  
> > SNIP
>  
> > > > +   if (!perf_data_file__is_pipe(>output))
> > > > return 0;
> 
> > > > return perf_event__repipe_synth(tool, event);
> > > > @@ -351,10 +343,12 @@ static int __cmd_inject(struct perf_inject 
> > > > *inject)
> > > >  {
> > > > struct perf_session *session;
> > > > int ret = -EINVAL;
> > > > -   struct perf_data_file file = {
> > > > +   struct perf_data_file file_in = {
> > > 
> > > Why don't leave it as 'file', and on a follow up patch _then_ rename it
> > > to file_in? This way patch review gets easier, i.e. try avoiding doing
> > > multiple things per patch.
> > 
> > the input file needed to be renamed, because new 'output' file was added
> 
> Why? Is 'file' going to be reused somehow?

nope, just having file_in and file_out seemed symmetric,
but nevermind.. I can switch to file and file_out ;-)

SNIP

> > 
> > well, inject->output->fd is used on 2 places within the function,
> > so it seems logical to put it into variable and use it like that
> 
> What I'm trying to convey here is that for both this case and the other,
> having looking at these two lines:
> 
> - inject->output
> + inject->output->fd
> 
> Makes me instantaneously understand that inject->output now
> encapsulates, among other things (probably), the file descriptor that
> was called just inject->output, i.e. this patch probably isn't doing
> anything more than using a new abstraction, the code flow probably
> wasn't altered.

yes, that's what happened.. encapsulating output file processing
and getting rid of common code that's now handled by perf_data_file
object..

> 
> I.e. the smaller the patch, the better.

I dont think thats always true.. I prefer readable code
despite of 'unreadable' patches ;-)

> 
> > > > -   if (!inject->pipe_output) {
> > > > +   if (!perf_data_file__is_pipe(file_out)) {
> > > > session->header.data_size = inject->bytes_written;
> > > > -   perf_session__write_header(session, session->evlist, 
> > > > inject->output, true);
> + perf_session__write_header(session, session->evlist, 
> inject->output->fd, true);
> > > 
> > > Why a line for 'true' all by itself?
> > 
> > line was crossing 80 chars limit
> 
> [1]+  Stopped mutt
> [acme@zoo ~]$ 
> [acme@zoo ~]$ echo $COLUMNS
> 173
> [acme@zoo ~]$ 
> 
> I'm not really that strict with that old convention :-\ All in one line
> would make it ~95 columns, not a big deal, even more since it _was_
> already more than 80 columns.

I see.. I'm using checkpatch script that screams about this
so I tend to keep to that rule

> 
> I.e. your change was to replace 'inject->output' with 'out_fd', but you
> did that _and_ reflowed, i.e. two changes into one. ;-)

the smaller the patch, the better, right? :-)

> 
> Looking at this line makes me think: why do we have to pass 'session'
> _and_ 'session->evlist', i.e. the 2nd parameter can be obtained from the
> 1st. Fixing that could get us more compact code _and_ a shorter line.

we do actually, and the reason is this code, because
the session keeps the input file, while we are using
it for output file..

> 
> Will check that.
> 
> > > > -   OPT_STRING('o', "output", _name, "file",
> > > > +   OPT_STRING('o', "output", , "file",
> > > 
> > > see, here you directly access a perf_data_file member instead of having
> > > another wrapper :-)
> > 
> > yes
> > 
> > I dont have strong opinions about wrappers, sometimes it seems
> > appropriate, sometimes it does not.. tell me the guidance here
> > and I'll kick the patch to fit ;-)
> 
> Well, a wrapper like perf_data_file__is_pipe(file_out) that maps to
> file_out->is_pipe and will produce the same results at every call and
> that we don't have the slightest intention of somehow hooking, I would
> do away with it and use file_out->is_pipe directly.

ok

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] I2C: BCM2835: Linking platform nodes to adapter nodes

[Charles Keepax]

On Fri, Nov 08, 2013 at 09:59:28AM -0700, Stephen Warren wrote:
> On 11/08/2013 02:49 AM, Florian Meier wrote:
> > In order to find I2C devices in the device tree, the platform nodes
> > have to be known by the I2C core. Analogous to the i2c-omap driver
> > this requires setting the dev.of_node parameter of the adapter.
> 
> (CCing the I2C maintainers...)
> 
> > diff --git a/drivers/i2c/busses/i2c-bcm2835.c 
> > b/drivers/i2c/busses/i2c-bcm2835.c
> 
> > @@ -299,6 +299,7 @@ static int bcm2835_i2c_probe(struct platform_device 
> > *pdev)
> > strlcpy(adap->name, "bcm2835 I2C adapter", sizeof(adap->name));
> > adap->algo = _i2c_algo;
> > adap->dev.parent = >dev;
> > +   adap->dev.of_node = pdev->dev.of_node;
> 
> Ah, that makes sense. Thinking about it now, I'd only ever used i2cget
> etc. to access I2C devices, rather than instantiating drivers from DT.
> 
> That all said, I wonder if the I2C core shouldn't do something like the
> following inside i2c_add_adapter():
> 
> if (!adap->dev.of_node && adap->dev.parent)
>   adap->dev.of_node = adap->dev.parent->of_node;

Should this not also have an of_node_get to increment the ref
count on the node?

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/4] sched: remove cpu_load decay.

[Alex Shi]

On 11/26/2013 09:01 PM, Daniel Lezcano wrote:
> 
> Ok, bad copy-paste, the third test run results with the patchset is wrong.
> 
> hackbench -P -s 4096 -l 1000 -g 10 -f 40
> 38.938  39.585   
> 39.363 39.008
> 39.340 38.954
> 38.909 39.273
> 39.095 38.755
> 38.869 39.003
> 39.041 38.945
> 38.939 38.005
> 38.992 38.994
> 38.947 38.855

Oops,
Anyway, at least, no harm on hackbench process testing. :)

-- 
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/4] sched: remove cpu_load decay.

[Daniel Lezcano]

On 11/26/2013 01:52 PM, Alex Shi wrote:

On 11/26/2013 08:35 PM, Daniel Lezcano wrote:



Here the new results with your patchset + patch #5

I have some issues with perf for the moment, so I will fix it up and
send the result after.


Thanks a lot, Daniel!
The result is pretty good!, thread/pipe performance has a slight little
drop, but processes performance increase about 25%!





527d1511310a  / + patchset + #5

hackbench -T -s 4096 -l 1000 -g 10 -f 40
26.677  30.308
27.914 28.497
28.390 30.360
28.048 28.587
26.344 29.513
27.848 28.706
28.315 30.152
28.232 29.721
26.549 28.766
30.340 38.801
hackbench -p -s 4096 -l 1000 -g 10 -f 40
34.522  35.469
34.545 34.966
34.469 35.342
34.115 35.286
34.457 35.592
34.561 35.314
34.459 35.316
34.054 35.629
34.532 35.149
34.459 34.876
hackbench -P -s 4096 -l 1000 -g 10 -f 40
38.938  30.308
39.363 28.497
39.340 30.360
38.909 28.587
39.095 29.513
38.869 28.706
39.041 30.152
38.939 29.721
38.992 28.766
38.947 38.801


Ok, bad copy-paste, the third test run results with the patchset is wrong.

hackbench -P -s 4096 -l 1000 -g 10 -f 40
38.938   39.585 
39.363   39.008
39.340   38.954
38.909   39.273
39.095   38.755
38.869   39.003
39.041   38.945
38.939   38.005
38.992   38.994
38.947   38.855



--
  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 tty-next 7/7] n_tty: trace input/read flow control

[Peter Hurley]

On 11/23/2013 09:38 PM, Peter Hurley wrote:

On 11/23/2013 07:25 PM, One Thousand Gnomes wrote:

On Fri, 22 Nov 2013 10:59:25 -0500
Peter Hurley  wrote:


Instrument .receive_buf() and read() paths with trace_printk's
to aid in debugging flow control changes.


tty devices have a device, we have a dev_dbg() layer. The old tty trace
predates this but there isn't really any excuse for not using it now that
I can see ?


I was using the ftrace facility because it has significantly less performance
impact than printk (which was an important factor while debugging flow control
problems).

That said, I could further macro-ize n_tty_trace() with selectable facility
(which would be useful when debugging problems that end in cpu death).


Greg,

I don't really mind if you don't want to take this patch; it is useful but
it does clutter up the code.

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c: i2c-bcm-kona: Fix module build

[Wolfram Sang]

On Mon, Nov 25, 2013 at 12:01:18PM -0800, Tim Kryger wrote:
> Correct a typo that prevented the driver from being built as a module.
> 
> Signed-off-by: Tim Kryger 

Applied to for-current, thanks!

Have you also tried repeated module loading/unloading?



signature.asc
Description: Digital signature

Re: [BUG] 3.13-rc1 kernel crash when enable all tracepoints

[Steven Rostedt]

On Tue, 26 Nov 2013 12:38:53 +0800
Jovi Zhangwei  wrote:

> Hi,
> 
> I'm not sure this issue already be fixed or not, it can be reproduced
> permanently.
> 
> (I didn't use git-bisect yet, you guys might can understand it quickly)
> 
> #echo 1 > /sys/kernel/debug/tracing/events/enable
> 
> [  160.472176] BUG: unable to handle kernel NULL pointer dereference
> at   (null)
> [  160.472176] IP: [] strlen+0x0/0x30

I hit this bug last night when testing a fix for another bug. I have a
patch for this too, and will send it out after I put it through my
tests.

You can try it out.

-- Steve

diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 52594b2..bdac88c 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -372,7 +372,8 @@ ftrace_define_fields_##call(struct ftrace_event_call 
*event_call)   \
__data_size += (len) * sizeof(type);
 
 #undef __string
-#define __string(item, src) __dynamic_array(char, item, strlen(src) + 1)
+#define __string(item, src) __dynamic_array(char, item,
\
+   strlen((src) ? (src) : "(null)") + 1)
 
 #undef DECLARE_EVENT_CLASS
 #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print) \
@@ -501,7 +502,7 @@ static inline notrace int ftrace_get_offsets_##call(
\
 
 #undef __assign_str
 #define __assign_str(dst, src) \
-   strcpy(__get_str(dst), src);
+   strcpy(__get_str(dst), (src) ? (src) : "(null)");
 
 #undef TP_fast_assign
 #define TP_fast_assign(args...) args

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] sched/nohz_full: give correct cpu load for nohz_full cpu

[Alex Shi]

On 11/22/2013 02:37 PM, Alex Shi wrote:
> When a nohz_full cpu in tickless mode, it may update cpu_load in
> following chain:
> __tick_nohz_full_check
> tick_nohz_restart_sched_tick
> update_cpu_load_nohz
> then it will be set a incorrect cpu_load: 0.
> This patch try to fix it and give it the correct cpu_load value.

Frederic,

Would you like to give some comments on this patch?


-- 
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] I2C: BCM2835: Linking platform nodes to adapter nodes

[Wolfram Sang]

On Mon, Nov 25, 2013 at 09:01:50AM +0100, Florian Meier wrote:
> In order to find I2C devices in the device tree, the platform nodes
> have to be known by the I2C core. This requires setting the
> dev.of_node parameter of the adapter.
> 
> Signed-off-by: Florian Meier 

Malformed patch, please resend.



signature.asc
Description: Digital signature

Re: [RFC PATCH 0/4] sched: remove cpu_load decay.

[Daniel Lezcano]

On 11/26/2013 01:52 PM, Alex Shi wrote:

On 11/26/2013 08:35 PM, Daniel Lezcano wrote:



Here the new results with your patchset + patch #5

I have some issues with perf for the moment, so I will fix it up and
send the result after.


Thanks a lot, Daniel!
The result is pretty good!, thread/pipe performance has a slight little
drop, but processes performance increase about 25%!


Mmh, wait. Let me double check the results, it sounds weird we have so 
much performance increase.




527d1511310a  / + patchset + #5

hackbench -T -s 4096 -l 1000 -g 10 -f 40
26.677  30.308
27.914 28.497
28.390 30.360
28.048 28.587
26.344 29.513
27.848 28.706
28.315 30.152
28.232 29.721
26.549 28.766
30.340 38.801
hackbench -p -s 4096 -l 1000 -g 10 -f 40
34.522  35.469
34.545 34.966
34.469 35.342
34.115 35.286
34.457 35.592
34.561 35.314
34.459 35.316
34.054 35.629
34.532 35.149
34.459 34.876
hackbench -P -s 4096 -l 1000 -g 10 -f 40
38.938  30.308
39.363 28.497
39.340 30.360
38.909 28.587
39.095 29.513
38.869 28.706
39.041 30.152
38.939 29.721
38.992 28.766
38.947 38.801






--
  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: [Devel] [PATCH v11 00/15] kmemcg shrinkers

[Vladimir Davydov]

On 11/26/2013 10:47 AM, Vladimir Davydov wrote:

Hi,

Thank you for the review. I agree with all your comments and I'll 
resend the fixed version soon.


If anyone still has something to say about the patchset, I'd be glad 
to hear from them.


On 11/25/2013 09:41 PM, Johannes Weiner wrote:

I ran out of steam reviewing these because there were too many things
that should be changed in the first couple patches.

I realize this is frustrating to see these type of complaints in v11
of a patch series, but the review bandwidth was simply exceeded back
when Glauber submitted this along with the kmem accounting patches.  A
lot of the kmemcg commits themselves don't even have review tags or
acks, but it all got merged anyway, and the author has moved on to
different projects...

Too much stuff slips past the only two people that have more than one
usecase on their agenda and are willing to maintain this code base -
which is in desparate need of rework and pushback against even more
drive-by feature dumps.  I have repeatedly asked to split the memcg
tree out of the memory tree to better deal with the vastly different
developmental stages of memcg and the rest of the mm code, to no
avail.  So I don't know what to do anymore, but this is not working.

Thoughts?


That's a pity, because w/o this patchset kmemcg is in fact useless. 
Perhaps, it's worth trying to split it? (not sure if it'll help much 
though since first 11 patches are rather essential :-( )


What do you think about splitting this set into two main series as follows:

1) Prepare vmscan to kmemcg-aware shrinkers; would include patches 1-7 
of this set.

2) Make fs shrinkers memcg-aware; would include patches 9-11 of this set

and leave other patches, which are rather for optimization/extending 
functionality, for future?


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 07/12] acpi: Ignore acpi_rsdp kernel parameter when securelevel is set

[Josh Boyer]

On Mon, Sep 9, 2013 at 11:49 AM, Matthew Garrett
 wrote:
> From: Josh Boyer 
>
> This option allows userspace to pass the RSDP address to the kernel, which
> makes it possible for a user to execute arbitrary code in the kernel.
> Disable this when securelevel is set.
>
> Signed-off-by: Josh Boyer 

Dredging up an old thread in the hopes that Matthew runs sed and resubmits...

Also, FWIW, I didn't write this.  It was derived from previous
versions of something I did write, but there's really no evidence of
anything I wrote left, so it should probably be From: you.

> ---
>  drivers/acpi/osl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index e5f416c..f6d8977 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -45,6 +45,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -249,7 +250,7 @@ early_param("acpi_rsdp", setup_acpi_rsdp);
>  acpi_physical_address __init acpi_os_get_root_pointer(void)
>  {
>  #ifdef CONFIG_KEXEC
> -   if (acpi_rsdp)
> +   if (acpi_rsdp && (get_securelevel <= 0))

This is missing some ( ).  That means you're comparing the
get_securelevel function pointer to 0.  Pretty sure bad things will
happen.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2] perf tools: Fix tags/TAGS targets rebuilding

[Jiri Olsa]

On Tue, Nov 26, 2013 at 01:00:55PM +0100, Ingo Molnar wrote:
> 
> * Jiri Olsa  wrote:
> 
> > On Tue, Nov 26, 2013 at 12:31:08PM +0100, Ingo Molnar wrote:

SNIP

> > > 
> > > Also note that we have duplicate code for this in Makefile.perf 
> > > already. Would it be possible to pass through this there and keep the 
> > > main Makefile is just a thin, minimal wrapper that adds default 
> > > parallelism, etc?
> > 
> > well, thats what I actually tried to do.. pass the
> > processing to the Makefile.perf otherwise it stops
> > in Makefile
> > 
> > I guess you want some generic way of doing that
> 
> If it's just these two phony targets that need to be in the main 
> makefile then I guess your approach is the simplest one and we should 
> do it like that instead of complicating the interface. If it gets 
> messier in the future we can reconsider?
> 

sounds good, pelase check v2

thanks,
jirka


---
Once the tags/TAGS file is generated it's never rebuilt
until it's removed by hand.

The reason is that the Makefile does not treat tags/TAGS
as targets but as files and thus won't rebuilt them
once they are in place.

Adding PHONY tags/TAGS targets into Makefile.

Signed-off-by: Jiri Olsa 
Cc: Ingo Molnar 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Namhyung Kim 
Cc: Mike Galbraith 
Cc: Stephane Eranian 
Cc: David Ahern 
Cc: Adrian Hunter 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 4835618..eefb9fb 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -60,8 +60,11 @@ endef
 
 #
 # Needed if no target specified:
+# (Except for tags and TAGS targets. The reason is that the
+# Makefile does not treat tags/TAGS as targets but as files
+# and thus won't rebuilt them once they are in place.)
 #
-all:
+all tags TAGS:
$(print_msg)
$(make)
 
@@ -77,3 +80,5 @@ clean:
 %:
$(print_msg)
$(make)
+
+.PHONY: tags TAGS
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] intel_idle: Fixed C6 state on Avoton/Rangeley processors

[Bartlomiej Zolnierkiewicz]

Hi,

On Tuesday, November 26, 2013 07:13:57 AM Bockholdt Arne wrote:
> Corrected the MWAIT flag for C-State C6 on Intel Avoton/Rangeley processors.
> 
> Signed-off-by: Arne Bockholdt 
> ---
> 
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index cbd4e9a..92d1206 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@ -329,7 +329,7 @@ static struct cpuidle_state atom_cstates[] __initdata = {
>   {
>   .enter = NULL }
>  };
> -static struct cpuidle_state avn_cstates[CPUIDLE_STATE_MAX] = {
> +static struct cpuidle_state avn_cstates[] __initdata = {

The above fixup has already been submitted in a separate patch:

https://lkml.org/lkml/2013/11/21/177

and it has nothing to do with the purpose of your patch.

Thus please drop it from your patch.

>   {
>   .name = "C1-AVN",
>   .desc = "MWAIT 0x00",
> @@ -340,7 +340,7 @@ static struct cpuidle_state 
> avn_cstates[CPUIDLE_STATE_MAX] = {
>   {
>   .name = "C6-AVN",
>   .desc = "MWAIT 0x51",
> - .flags = MWAIT2flg(0x58) | CPUIDLE_FLAG_TIME_VALID | 
> CPUIDLE_FLAG_TLB_FLUSHED,
> + .flags = MWAIT2flg(0x51) | CPUIDLE_FLAG_TIME_VALID | 
> CPUIDLE_FLAG_TLB_FLUSHED,
>   .exit_latency = 15,
>   .target_residency = 45,
>   .enter = _idle },

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/4] sched: remove cpu_load decay.

[Alex Shi]

On 11/26/2013 08:35 PM, Daniel Lezcano wrote:
> 
> 
> Here the new results with your patchset + patch #5
> 
> I have some issues with perf for the moment, so I will fix it up and
> send the result after.

Thanks a lot, Daniel!
The result is pretty good!, thread/pipe performance has a slight little
drop, but processes performance increase about 25%!


> 
> 
> 527d1511310a  / + patchset + #5
> 
> hackbench -T -s 4096 -l 1000 -g 10 -f 40
> 26.677  30.308
> 27.914 28.497
> 28.390 30.360
> 28.048 28.587
> 26.344 29.513
> 27.848 28.706
> 28.315 30.152
> 28.232 29.721
> 26.549 28.766
> 30.340 38.801
> hackbench -p -s 4096 -l 1000 -g 10 -f 40
> 34.522  35.469
> 34.545 34.966
> 34.469 35.342
> 34.115 35.286
> 34.457 35.592
> 34.561 35.314
> 34.459 35.316
> 34.054 35.629
> 34.532 35.149
> 34.459 34.876
> hackbench -P -s 4096 -l 1000 -g 10 -f 40
> 38.938  30.308
> 39.363 28.497
> 39.340 30.360
> 38.909 28.587
> 39.095 29.513
> 38.869 28.706
> 39.041 30.152
> 38.939 29.721
> 38.992 28.766
> 38.947 38.801


-- 
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] msi: free msi_desc entry only after we've released the kobject

[Neil Horman]

On Mon, Nov 25, 2013 at 03:29:36PM -0800, Greg Kroah-Hartman wrote:
> On Mon, Nov 25, 2013 at 04:12:48PM -0700, Bjorn Helgaas wrote:
> > On Tue, Oct 29, 2013 at 11:30:30AM +0100, Veaceslav Falico wrote:
> > > Currently, we first do kobject_put(>kobj) and the kfree(entry),
> > > however kobject_put() doesn't guarantee us that it was the last reference
> > > and that the kobj isn't used currently by someone else, so after we
> > > kfree(entry) with the struct kobject - other users will begin using the
> > > freed memory, instead of the actual kobject.
> > > 
> > > Fix this by using the kobject->release callback, which is called last when
> > > the kobject is indeed not used and is cleaned up - it's 
> > > msi_kobj_release(),
> > > which can do the kfree(entry) safely (kobject_put/cleanup doesn't use the
> > > kobj itself after ->release() was called, so we're safe).
> > > 
> > > In case we've failed to create the sysfs directories - just kfree()
> > > it - cause we don't have the kobjects attached.
> > > 
> > > Also, remove the same functionality from populate_msi_sysfs(), cause on
> > > failure we anyway call free_msi_irqs(), which will take care of all the
> > > kobjects properly.
> > > 
> > > And add the forgotten pci_dev_put(pdev) in case of failure to register the
> > > kobject in populate_msi_sysfs().
> > > 
> > > CC: Bjorn Helgaas 
> > > CC: Neil Horman 
> > > CC: Greg Kroah-Hartman 
> > > CC: linux-...@vger.kernel.org
> > > CC: linux-kernel@vger.kernel.org
> > > Signed-off-by: Veaceslav Falico 
> > 
> > I'm still hoping that Greg (or somebody else; Greg already posted the bulk
> > of the work) will finish up the conversion to attributes, and that Neil
> > will confirm that works with no changes to irqbalance.  So I'm going to
> > drop these patches for now.  Poke me if we need to revive them.
> 
> Ah, sorry about that.  I'll redo my series, dropping the existing format
> and using the attribute-only code.  Give me a day or so, thanks for the
> reminder.
> 
> greg k-h
> 
Thank you greg, I'll make sure Irqbalance doesn't choke on the new format as
soon as you post them.

Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/23] i2c: omap: raw read and write endian fix

[Wolfram Sang]

> @@ -1142,7 +1142,7 @@ omap_i2c_probe(struct platform_device *pdev)
>* Also since the omap_i2c_read_reg uses reg_map_ip_* a
>* raw_readw is done.
>*/
> - rev = __raw_readw(dev->base + 0x04);
> + rev = readw_relaxed(dev->base + 0x04);
>  
>   dev->scheme = OMAP_I2C_SCHEME(rev);
>   switch (dev->scheme) {

Part of the comment above must be removed, too.



signature.asc
Description: Digital signature

Re: [PATCH 3/3] perf inject: Handle output file via perf_data_file object

[Arnaldo Carvalho de Melo]

Em Tue, Nov 26, 2013 at 11:03:24AM +0100, Jiri Olsa escreveu:
> On Mon, Nov 25, 2013 at 04:40:32PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Nov 22, 2013 at 03:24:28PM +0100, Jiri Olsa escreveu:
> > > Using the perf_data_file object to handle output
 
> SNIP
 
> > > + if (!perf_data_file__is_pipe(>output))
> > >   return 0;

> > >   return perf_event__repipe_synth(tool, event);
> > > @@ -351,10 +343,12 @@ static int __cmd_inject(struct perf_inject *inject)
> > >  {
> > >   struct perf_session *session;
> > >   int ret = -EINVAL;
> > > - struct perf_data_file file = {
> > > + struct perf_data_file file_in = {
> > 
> > Why don't leave it as 'file', and on a follow up patch _then_ rename it
> > to file_in? This way patch review gets easier, i.e. try avoiding doing
> > multiple things per patch.
> 
> the input file needed to be renamed, because new 'output' file was added

Why? Is 'file' going to be reused somehow?
 
> > 
> > >   .path = inject->input_name,
> > >   .mode = PERF_DATA_MODE_READ,
> > >   };
> > > + struct perf_data_file *file_out = >output;
> > > + int out_fd = perf_data_file__fd(file_out);
> > >  
> > >   signal(SIGINT, sig_handler);
> > >  
> > > @@ -365,7 +359,7 @@ static int __cmd_inject(struct perf_inject *inject)
> > >   inject->tool.tracing_data = perf_event__repipe_tracing_data;
> > >   }
> > >  
> > > - session = perf_session__new(, true, >tool);
> > > + session = perf_session__new(_in, true, >tool);
> > 
> > This hunk, for example, wouldn't be here, the this patch would be
> > shorter, easier to review.
> > 
> > >   if (session == NULL)
> > >   return -ENOMEM;
> > >  
> > > @@ -391,14 +385,15 @@ static int __cmd_inject(struct perf_inject *inject)
> > >   }
> > >   }
> > >  
> > > - if (!inject->pipe_output)
> > > - lseek(inject->output, session->header.data_offset, SEEK_SET);
> > > + if (!perf_data_file__is_pipe(file_out))
> > > + lseek(out_fd, session->header.data_offset, SEEK_SET);
> > 
> > Couldn't this be left as:
> > 
> > -   if (!inject->pipe_output)
> > -   lseek(inject->output, session->header.data_offset, SEEK_SET);
> > +   if (!perf_data_file__is_pipe(file_out))
> > +   lseek(inject->output->fd, session->header.data_offset, 
> > SEEK_SET);
> > 
> > I.e. why wrap access to the fd like that?
> 
> well, inject->output->fd is used on 2 places within the function,
> so it seems logical to put it into variable and use it like that

What I'm trying to convey here is that for both this case and the other,
having looking at these two lines:

- inject->output
+ inject->output->fd

Makes me instantaneously understand that inject->output now
encapsulates, among other things (probably), the file descriptor that
was called just inject->output, i.e. this patch probably isn't doing
anything more than using a new abstraction, the code flow probably
wasn't altered.

I.e. the smaller the patch, the better.

> > > - if (!inject->pipe_output) {
> > > + if (!perf_data_file__is_pipe(file_out)) {
> > >   session->header.data_size = inject->bytes_written;
> > > - perf_session__write_header(session, session->evlist, 
> > > inject->output, true);
+   perf_session__write_header(session, session->evlist, 
inject->output->fd, true);
> > 
> > Why a line for 'true' all by itself?
> 
> line was crossing 80 chars limit

[1]+  Stopped mutt
[acme@zoo ~]$ 
[acme@zoo ~]$ echo $COLUMNS
173
[acme@zoo ~]$ 

I'm not really that strict with that old convention :-\ All in one line
would make it ~95 columns, not a big deal, even more since it _was_
already more than 80 columns.

I.e. your change was to replace 'inject->output' with 'out_fd', but you
did that _and_ reflowed, i.e. two changes into one. ;-)

Looking at this line makes me think: why do we have to pass 'session'
_and_ 'session->evlist', i.e. the 2nd parameter can be obtained from the
1st. Fixing that could get us more compact code _and_ a shorter line.

Will check that.

> > > - OPT_STRING('o', "output", _name, "file",
> > > + OPT_STRING('o', "output", , "file",
> > 
> > see, here you directly access a perf_data_file member instead of having
> > another wrapper :-)
> 
> yes
> 
> I dont have strong opinions about wrappers, sometimes it seems
> appropriate, sometimes it does not.. tell me the guidance here
> and I'll kick the patch to fit ;-)

Well, a wrapper like perf_data_file__is_pipe(file_out) that maps to
file_out->is_pipe and will produce the same results at every call and
that we don't have the slightest intention of somehow hooking, I would
do away with it and use file_out->is_pipe directly.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c: davinci: raw read and write endian fix

[Wolfram Sang]

On Wed, Nov 20, 2013 at 08:23:44PM +0200, Taras Kondratiuk wrote:
> I2C IP block expect LE data, but CPU may operate in BE mode.
> Need to use endian neutral functions to read/write h/w registers.
> I.e instead of __raw_read[lw] and __raw_write[lw] functions code
> need to use read[lw]_relaxed and write[lw]_relaxed functions.
> If the first simply reads/writes register, the second will byteswap
> it if host operates in BE mode.
> 
> Changes are trivial sed like replacement of __raw_xxx functions
> with xxx_relaxed variant.
> 
> Signed-off-by: Taras Kondratiuk 

Applied to for-current, thanks!



signature.asc
Description: Digital signature

Re: [PATCH v6 4/6] gpio: davinci: add OF support

[Grygorii Strashko]

On 11/25/2013 01:00 PM, Sekhar Nori wrote:
> On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote:
>> From: KV Sujith 
>>
>> This patch adds OF parser support for davinci gpio
>> driver and also appropriate documentation in gpio-davinci.txt
>> located at Documentation/devicetree/bindings/gpio/.
>>
>> Acked-by: Linus Walleij 
>> Acked-by: Rob Herring 
>> Signed-off-by: KV Sujith 
>> Signed-off-by: Philip Avinash 
>> [prabhakar.cse...@gmail.com: simplified the OF code, removed
>>  unnecessary DT property and also simplified
>>  the commit message]
>> Signed-off-by: Lad, Prabhakar 
>> ---
>>   .../devicetree/bindings/gpio/gpio-davinci.txt  |   41 ++
>>   drivers/gpio/gpio-davinci.c|   57 
>> ++--
>>   2 files changed, 95 insertions(+), 3 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt 
>> b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
>> new file mode 100644
>> index 000..a2e839d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
>> @@ -0,0 +1,41 @@
>> +Davinci GPIO controller bindings
>> +
>> +Required Properties:
>> +- compatible: should be "ti,dm6441-gpio"
>> +
>> +- reg: Physical base address of the controller and the size of memory mapped
>> +   registers.
>> +
>> +- gpio-controller : Marks the device node as a gpio controller.
>> +
>> +- interrupt-parent: phandle of the parent interrupt controller.
>> +
>> +- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs 
>> are
>> +  supported at a time.
> 
> If this is true..
> 
>> +
>> +- ti,ngpio: The number of GPIO pins supported.
>> +
>> +- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual 
>> interrupt
>> + line to processor.
> 
> .. then why do you need to maintain this separately? Number of elements
> in interrupts property should give you this answer, no?
> 
> There can certainly be devices (past and future) which use a mixture of
> banked and unbanked IRQs. So a binding which does not take care of this
> is likely to change in future and that is a problem since it brings in
> backward compatibility of the binding into picture.
> 
> The right thing would be to define the DT node per-bank similar to what
> is done on OMAP rather than for all banks together. That way there can
> be a separate property which determines whether that bank supports
> direct-mapped or banked IRQs (or that could be inferred if the number of
> tuples in the interrupts property is more than one).

Number of IRQ can't be simply used to determine type of IRQ - need to handle 
IRQ names,
because each bank(32 gpios) may have up to 2 banked IRQs (one per 16 GPIO).

Few things here:
- The mixed banked/unbanked functionality has never been supported before. 
- The Davinci GPIO IP is different from OMAP and has common
  control registers for all banks.
- The proposed approach is more less easy to implement for DT case, but for 
not-DT
  case - the platform data will need to be changed significantly (.
  So, from this point of view, that would be a big change (actually the total 
driver rewriting).

Do you have any thoughts about how it can be done in a simpler way?

Actually, the same was proposed by Linus, but we've tried avoid such huge 
rework -
by switching to one irq_domain per all banks for example.

Regards,
- grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/4] sched: remove cpu_load decay.

[Daniel Lezcano]

On 11/24/2013 06:29 AM, Alex Shi wrote:

On 11/22/2013 08:13 PM, Daniel Lezcano wrote:


Hi Alex,

I tried on my Xeon server (2 x 4 cores) your patchset and got the
following result:

kernel a5d6e63323fe7799eb0e6  / + patchset

hackbench -T -s 4096 -l 1000 -g 10 -f 40
   27.604  38.556


Wondering if the following patch is helpful on your Xeon server?

Btw, you can run vmstat as background tool or use 'perf sched'
to get scheduler statistics change for this patchset.

The following are results of original kernel and all 5 patches
on pandaboard ES.

 latest kernel 527d1511310a89+ this patchset
hackbench -T -g 10 -f 40
 23.25"20.79"
 23.16"20.4"
 24.24"20.29"
hackbench -p -g 10 -f 40
 26.52"21.2"
 23.89"24.07"
 25.65"20.30"
hackbench -P -g 10 -f 40
 20.14"19.53"
 19.96"20.37"
 21.76"20.39"




Here the new results with your patchset + patch #5

I have some issues with perf for the moment, so I will fix it up and 
send the result after.



527d1511310a  / + patchset + #5

hackbench -T -s 4096 -l 1000 -g 10 -f 40
26.677   30.308
27.914   28.497
28.390   30.360
28.048   28.587
26.344   29.513
27.848   28.706
28.315   30.152
28.232   29.721
26.549   28.766
30.340   38.801
hackbench -p -s 4096 -l 1000 -g 10 -f 40
34.522   35.469
34.545   34.966
34.469   35.342
34.115   35.286
34.457   35.592
34.561   35.314
34.459   35.316
34.054   35.629
34.532   35.149
34.459   34.876
hackbench -P -s 4096 -l 1000 -g 10 -f 40
38.938   30.308
39.363   28.497
39.340   30.360
38.909   28.587
39.095   29.513
38.869   28.706
39.041   30.152
38.939   29.721
38.992   28.766
38.947   38.801



--
 From 4f5efd6c2b1e7293410ad57c3db24dcf3394c4a3 Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Sat, 23 Nov 2013 23:18:09 +0800
Subject: [PATCH] sched: aggravate target cpu load to reduce task moving

Task migration happens when target just a bit less then source cpu load
to reduce such situation happens, aggravate the target cpu with sd->
imbalance_pct.

Signed-off-by: Alex Shi 
---
  kernel/sched/fair.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bccdd89..c49b7ba 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -978,7 +978,7 @@ static inline unsigned long group_weight(struct task_struct 
*p, int nid)

  static unsigned long weighted_cpuload(const int cpu);
  static unsigned long source_load(int cpu);
-static unsigned long target_load(int cpu);
+static unsigned long target_load(int cpu, int imbalance_pct);
  static unsigned long power_of(int cpu);
  static long effective_load(struct task_group *tg, int cpu, long wl, long wg);

@@ -3809,11 +3809,17 @@ static unsigned long source_load(int cpu)
   * Return a high guess at the load of a migration-target cpu weighted
   * according to the scheduling class and "nice" value.
   */
-static unsigned long target_load(int cpu)
+static unsigned long target_load(int cpu, int imbalance_pct)
  {
struct rq *rq = cpu_rq(cpu);
unsigned long total = weighted_cpuload(cpu);

+   /*
+* without cpu_load decay, in most of time cpu_load is same as total
+* so we need to make target a bit heavier to reduce task migration
+*/
+   total = total * imbalance_pct / 100;
+
if (!sched_feat(LB_BIAS))
return total;

@@ -4033,7 +4039,7 @@ static int wake_affine(struct sched_domain *sd, struct 
task_struct *p, int sync)
this_cpu  = smp_processor_id();
prev_cpu  = task_cpu(p);
load  = source_load(prev_cpu);
-   this_load = target_load(this_cpu);
+   this_load = target_load(this_cpu, 100);

/*
 * If sync wakeup then subtract the (maximum possible)
@@ -4089,7 +4095,7 @@ static int wake_affine(struct sched_domain *sd, struct 
task_struct *p, int sync)

if (balanced ||
(this_load <= load &&
-this_load + target_load(prev_cpu) <= tl_per_task)) {
+this_load + target_load(prev_cpu, 100) <= tl_per_task)) {
/*
 * This domain has SD_WAKE_AFFINE and
 * p is cache cold in this domain, and
@@ -4135,7 +4141,7 @@ find_idlest_group(struct sched_domain *sd, struct 
task_struct *p, int this_cpu)
if (local_group)
load = source_load(i);
else
-   

Re: [RFC patch 0/5] futex: Allow lockless empty check of hashbucket plist in futex_wake()

[Thomas Gleixner]

On Tue, 26 Nov 2013, Peter Zijlstra wrote:

> On Tue, Nov 26, 2013 at 12:21:40PM +0100, Ingo Molnar wrote:
> > I'm somewhat reluctant to chalk it up to a single mfence - maybe 
> > timings/behavior changed in some substantial way?
> 
> Ah indeed! We also changed the case where an enqueueing futex sees the
> uval change and bails. It is now far more expensive due to having to
> both queue and unqueue, whereas before it wouldn't queue at all.
> 
> I suppose the idea was to offset that by not requiring locking on the
> wake side.

Aside of that I really would be interrested in an explanation for the
STDDEV going up by factor 5. That's a clear indicator for fishyness.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/6] watchdog: davinci: change driver to use WDT core

[Grygorii Strashko]

On 11/26/2013 02:10 PM, Guenter Roeck wrote:

On 11/26/2013 03:09 AM, Grygorii Strashko wrote:

On 11/25/2013 04:04 PM, Ivan Khoronzhuk wrote:

To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.

Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core tracks state with its own variable.

The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. The heartbeat is
initialized in next way. If heartbeat is not set thought module
parameter, try to read it's value from WDT node timeout-sec property.
If node has no one, use default value.

The heartbeat is hold in wdd->timeout by WDT core, so use it in
order to set timeout period.

Signed-off-by: Ivan Khoronzhuk 
Acked-by: Santosh Shilimkar 
Reviewed-by: Guenter Roeck 
---
  arch/arm/mach-davinci/da8xx-dt.c  |2 +-
  arch/arm/mach-davinci/devices-da8xx.c |4 +-
  arch/arm/mach-davinci/devices.c   |2 +-
  drivers/watchdog/Kconfig  |2 +
  drivers/watchdog/davinci_wdt.c|  151
-
  5 files changed, 43 insertions(+), 118 deletions(-)


Pls note, that this patch contains both changes in platform and driver
code to fix regression reported by Sekhar Nori on v2 of this series
and caused by driver name changing.

Is it ok?

It can be splitted, but then both patches will introduce regression by
itself and thing will work only if both of them will be applied together.


Splitting it would break bisect, even if applied together, so I don't
think this would be a good idea.


Thanks

Regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c-mux-pca954x: Disable mux after 200ms timeout

[Wolfram Sang]

CCing linux-pm, maybe they know more...

> The extra I2C traffic consumes extra power. If the bus is terminated
> using 2k resistors, approximately 1mA of current (assuming ~2V
> signals) is flowing when the bus is pulled low. On low power
> designs, this extra power consumption is noticable. There is no way
> to turn the mux "off" from either user or kernel space. The signals
> going through the mux to a place where no I2C device is actually
> listening are only wasting power.

I only have an overview of current linux pm mechanisms. I wonder if
those can't be used somehow. Like if devices on the multiplexed bus are
idle (well, only regarding transfers), then we can switch off the muxer.

> The I2C signals are used to control sensitive codecs. When looking
> at the sampled data, the I2C traffic is visible in the captured
> analog signal. To prevent this from happening, the mux can be

I wonder: Is this really a feature of sensitive codecs or an issue of
the board design?

> disabled whenever not communicating with the codec. This could be
> accomplished with the "deselect_on_exit" boolean, but because audio
> driver sends the codec parameters in dozens of small transactions,
> this will result in a lot more needless I2C traffic, constantly
> switching the mux for each codec setting.

Has this been looked at? ASoC supports grouping of tranfers IIRC. Maybe
your I2C driver is only missing I2C_M_NOSTART?.

> Would it be acceptable if I made the timeout optional, by making the
> "deselect_on_exit" boolean into a three-state value (off, on,
> timeout)? Or, alternatively, implement "deselect_on_exit" using the
> timeout scheme (probably with a very short timeout)?

I have a number of concerns designwise. First, if we do something like
shutting-down-a-bus-if-there-are-no-transfers-expected, it definately
should be in the core, not the driver. As said before, I have the
assumption it should even be connected to the runtime pm core via some
callback. And if we have that for I2C, we surely want that for other
buses as well, at least SPI. Also, the timeout thing sounds too
heuristic to me. Later, people might want to change the timeout value
depending on workloads or so, and then a governor, etc... No, thanks.

BTW is it feasible to shut down the whole I2C bus at controller level
after transfers? No needless transfers and maybe even more power
savings.

Anyway, thanks for letting me know about your requirements (they should
have been in the original commit message, though ;))



signature.asc
Description: Digital signature

Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec

[Eric W. Biederman]

Vivek Goyal  writes:

> On Fri, Nov 22, 2013 at 07:39:14PM -0800, Eric W. Biederman wrote:
>
> [..]
>> > Hmm..., I am running out of ideas here. This is what I understand.
>> >
>> > - If I sign the bzImage (using PKCS1.5 signature), and later it is signed
>> >   with authenticode format signatures, then PKCS1.5 signatures will not be
>> >   valid as PE/COFF signing will do some modification to PE/COFF header in
>> >   bzImage. And another problem is that then I don't have a way to find
>> >   PKCS1.5 signature.
>> >
>> > - If bzImage is first signed with authenticode format signature and then
>> >   signed using PKCS1.5 signature, then  authenticode format signature
>> >   will become invalid as it will also hash the data appened at the end
>> >   of file.
>> >
>> > So looks like both signatures can't co-exist on same file. That means
>> > one signature has to be detached.
>> >
>> > I am beginning to think that create a kernel option which allows to choose
>> > between attached and detached signatures. Extend kexec syscall to allow
>> > a parameter to pass in detached signatures. If detached signatures are
>> > not passed, then look for signatures at the end of file. That way, those
>> > who are signing kernels using platform specific format (authenticode) in 
>> > this case, they can generate detached signature while others can just
>> > use attached signatures.
>> >
>> > Any thoughts on how this should be handled?
>> 
>> Inside of a modern bzImage there is an embedded ELF image.  How about in
>> userspace we just strip out the embedded ELF image and write that to a
>> file.  Then we can use the same signature checking scheme as we do for
>> kernel modules.  And you only have to support one file format.
>
> I think there is a problem with that. And that we lose the additional
> metadata info present in bzImage which is important.
>
> For example, knowing how much memory kernel will consume before it
> sets up its own GDT and page tables (init_size) is very important. That
> gives image loader lot of flexibility in figuring out where to place rest
> of the components safely (initrd, GDT, page tables, ELF header segment, 
> backup region etc).

The init_size should be reflected in the .bss of the ELF segments.  If
not it is a bug when generating the kernel ELF headers and should be
fixed.

For use by kexec I don't see any issues with just signing the embedded
ELF image.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf timechart: remove lock_depth from trace_entry

[Arnaldo Carvalho de Melo]

Em Tue, Nov 26, 2013 at 03:05:36PM +0400, Stanislav Fomichev escreveu:
> > This makes the new tool stop processing old files, can you try the patch
> > attached instead?

> I see two downsides to your approach:

Huh?

> 1) with your patch I'm now required to run 'perf timechart record' and
> 'perf timechart' on the same machine (otherwise, on the 'perf timechart'

No, it should not be required to do that, when processing perf.data
files the tracepoint info should come from perf.data, recorded there at
the 'perf record' time, right? I'm assuming this, will check.

> machine we may have wrong fields definitions that don't match perf.data).
> Currently, it's possible to use 'perf timechart record' on the target and do
> 'perf timechart' on the host (at least I do it this way).

If it is, my assumption is correct, as the evlist must be populated from
perf.data, or is it this way and _only_ when it goes to look at fields
is that it looks at the local machine? Doesn't make sense.

> 2) only root can run 'perf timechart' now (because of permissions on
> /sys/kernel/debug).

Se above, if before this patch the format_field info was obtained from
the perf.data file, why should it now get it from the local machine?
 
> Maybe we can we make some simple version check against the perf.data file and
> just refuse to process the old one (not sure if it's possible)?
> 
> > Its only compile tested tho.
> Ok, I'll test it if we are fine with the new limitations.

Please try. There should be no limitations.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/6] watchdog: davinci: change driver to use WDT core

[Guenter Roeck]

On 11/26/2013 03:09 AM, Grygorii Strashko wrote:

On 11/25/2013 04:04 PM, Ivan Khoronzhuk wrote:

To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.

Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core tracks state with its own variable.

The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. The heartbeat is
initialized in next way. If heartbeat is not set thought module
parameter, try to read it's value from WDT node timeout-sec property.
If node has no one, use default value.

The heartbeat is hold in wdd->timeout by WDT core, so use it in
order to set timeout period.

Signed-off-by: Ivan Khoronzhuk 
Acked-by: Santosh Shilimkar 
Reviewed-by: Guenter Roeck 
---
  arch/arm/mach-davinci/da8xx-dt.c  |2 +-
  arch/arm/mach-davinci/devices-da8xx.c |4 +-
  arch/arm/mach-davinci/devices.c   |2 +-
  drivers/watchdog/Kconfig  |2 +
  drivers/watchdog/davinci_wdt.c|  151 -
  5 files changed, 43 insertions(+), 118 deletions(-)


Pls note, that this patch contains both changes in platform and driver code to 
fix regression reported by Sekhar Nori on v2 of this series and caused by 
driver name changing.

Is it ok?

It can be splitted, but then both patches will introduce regression by itself 
and thing will work only if both of them will be applied together.


Splitting it would break bisect, even if applied together, so I don't think 
this would be a good idea.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] extcon: gpio: Request gpio pin before modifying its state

[Guenter Roeck]

On 11/25/2013 11:55 PM, Chanwoo Choi wrote:

Hi Guenter,

On 11/23/2013 02:26 AM, Guenter Roeck wrote:

Commit 338de0ca (extcon: gpio: Use gpio driver/chip debounce if supported)
introduced a call to gpio_set_debounce() before actually requesting the
respective gpio pin from the gpio subsystem.

The gpio subsystem expects that a gpio pin was requested before modifying its
state. Not doing so results in a warning from gpiolib, and the gpio pin is
auto-requested. This in turn causes the subsequent devm_gpio_request_one()
to fail. So devm_gpio_request_one() must be called prior to calling
gpio_set_debounce().

Signed-off-by: Guenter Roeck 
---
  drivers/extcon/extcon-gpio.c |   11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)



Applid it on extcon-next branch.



As this is a bug fix, I think it would make sense to have this applied to the 
current
kernel and not wait for 3.14.

Thanks,
Guenter


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/5] perf diff: generalize hpp__color_delta for -c

[Jiri Olsa]

On Sun, Nov 24, 2013 at 11:50:23AM +0530, Ramkumar Ramachandra wrote:

SNIP

>   container_of(fmt, struct diff_hpp_fmt, fmt);
>   struct hist_entry *pair = get_pair_fmt(he, dfmt);
> - double percent;
> + double delta;
>   char pfmt[20] = " ";
>  
>   if (!pair)
>   goto dummy_print;
>   if (pair->diff.computed)
> - percent = pair->diff.period_ratio_delta;
> + switch (comparison_method) {
> + case COMPUTE_DELTA:
> + delta = pair->diff.period_ratio_delta;
> + break;
> + default:
> + BUG_ON(1);
> + }
>   else
> - percent = compute_delta(he, pair);
> + switch (comparison_method) {
> + case COMPUTE_DELTA:
> + delta = compute_delta(he, pair);
> + break;
> + default:
> + BUG_ON(1);
> + }
>  
> - if (!he->dummy && fabs(percent) >= 0.01) {
> - scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
> - return color_snprintf(hpp->buf, hpp->size,
> - percent > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
> - pfmt, percent);
> + if (!he->dummy) {
> + switch (comparison_method) {
> + case COMPUTE_DELTA:
> + if (fabs(delta) < 0.01)
> + goto dummy_print;
> + scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width 
> - 1);
> + return color_snprintf(hpp->buf, hpp->size,
> + delta > 0 ? PERF_COLOR_GREEN : 
> PERF_COLOR_RED,
> + pfmt, delta);
> + break;

I think it'd be better to have just one switch for
comparison_method and do all the processing within

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/5] perf diff: generalize hpp__color_delta for -c

[Jiri Olsa]

On Sun, Nov 24, 2013 at 11:50:23AM +0530, Ramkumar Ramachandra wrote:
> Generalize the function so that we can accommodate all three comparison
> methods: delta, ratio, and wdiff.
> 
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Cc: Arnaldo Carvalho de Melo 
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  tools/perf/builtin-diff.c | 47 
> +--
>  1 file changed, 37 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 84d5f2d..a54736c 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -769,33 +769,60 @@ static int hpp__entry_baseline(struct hist_entry *he, 
> char *buf, size_t size)
>   return ret;
>  }
>  
> -static int hpp__color_delta(struct perf_hpp_fmt *fmt,
> - struct perf_hpp *hpp, struct hist_entry *he)
> +static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
> + struct perf_hpp *hpp, struct hist_entry *he,
> + int comparison_method)
>  {
>   struct diff_hpp_fmt *dfmt =
>   container_of(fmt, struct diff_hpp_fmt, fmt);
>   struct hist_entry *pair = get_pair_fmt(he, dfmt);
> - double percent;
> + double delta;
>   char pfmt[20] = " ";
>  
>   if (!pair)
>   goto dummy_print;
>   if (pair->diff.computed)
> - percent = pair->diff.period_ratio_delta;
> + switch (comparison_method) {
> + case COMPUTE_DELTA:
> + delta = pair->diff.period_ratio_delta;
> + break;
> + default:
> + BUG_ON(1);
> + }
>   else
> - percent = compute_delta(he, pair);
> + switch (comparison_method) {
> + case COMPUTE_DELTA:
> + delta = compute_delta(he, pair);
> + break;
> + default:
> + BUG_ON(1);
> + }
>  
> - if (!he->dummy && fabs(percent) >= 0.01) {
> - scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
> - return color_snprintf(hpp->buf, hpp->size,
> - percent > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
> - pfmt, percent);
> + if (!he->dummy) {

isn't this check superfluous because of the above (!pair) check?

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf tools: Fix tags target rebuilding

[Ingo Molnar]

* Jiri Olsa  wrote:

> On Tue, Nov 26, 2013 at 12:31:08PM +0100, Ingo Molnar wrote:
> > 
> > * Jiri Olsa  wrote:
> > 
> > > Once the tags file is generated it's never rebuilt
> > > until it's removed by hand.
> > > 
> > > The reason is that the Makefile does not treat tags
> > > as a target but as a file to be rebuilt.
> > > 
> > > Adding tags as PHONY target into the Makefile.
> > > 
> > > Signed-off-by: Jiri Olsa 
> > > Cc: Ingo Molnar 
> > > Cc: Frederic Weisbecker 
> > > Cc: Peter Zijlstra 
> > > Cc: Namhyung Kim 
> > > Cc: Mike Galbraith 
> > > Cc: Stephane Eranian 
> > > Cc: David Ahern 
> > > Cc: Adrian Hunter 
> > > Cc: Arnaldo Carvalho de Melo 
> > > ---
> > >  tools/perf/Makefile | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> > > index 4835618..95f5792 100644
> > > --- a/tools/perf/Makefile
> > > +++ b/tools/perf/Makefile
> > > @@ -61,7 +61,7 @@ endef
> > >  #
> > >  # Needed if no target specified:
> > >  #
> > > -all:
> > > +all tags:
> > 
> > Obviously the change invalidates the comment above.
> 
> ugh, haven't noticed that comment ;-)
> 
> > 
> > >   $(print_msg)
> > >   $(make)
> > >  
> > > @@ -77,3 +77,5 @@ clean:
> > >  %:
> > >   $(print_msg)
> > >   $(make)
> > > +
> > > +.PHONY: tags
> > 
> > Note that there's also a TAGS file that uses etags - which probably 
> > needs similar treatment.
> 
> yes
> 
> > 
> > Also note that we have duplicate code for this in Makefile.perf 
> > already. Would it be possible to pass through this there and keep the 
> > main Makefile is just a thin, minimal wrapper that adds default 
> > parallelism, etc?
> 
> well, thats what I actually tried to do.. pass the
> processing to the Makefile.perf otherwise it stops
> in Makefile
> 
> I guess you want some generic way of doing that

If it's just these two phony targets that need to be in the main 
makefile then I guess your approach is the simplest one and we should 
do it like that instead of complicating the interface. If it gets 
messier in the future we can reconsider?

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] remove CONFIG_SCHED_HRTICK

[Ingo Molnar]

* Christoph Hellwig  wrote:

> It's equivalent to CONFIG_HIGH_RES_TIMERS now that all architectures 
> use the generic helpers it relies on.

So the SCHED_HRTICK variable documents the scheduler's dependencies 
here. It currently indeed clones CONFIG_HIGH_RES_TIMERS, but that's 
just how it's implemented today.

If we were to enable this feature more widely in the future (it's 
expensive right now so disabled by default at the moment) then it will 
be much easier to just change.

That said, while checking the background of the changes here ran 
across two ARM commits that I don't really like:

  commit c9218b163959fafa76ffbee0baa3ef269838f410
  Author: Russell King 
  Date:   Sat Apr 27 23:31:10 2013 +0100

  ARM: Allow selection HZ values

this commit introduced a nonsensical duplication:

  +config SCHED_HRTICK
  +   def_bool HIGH_RES_TIMERS
 
   config SCHED_HRTICK
  def_bool HIGH_RES_TIMERS

Plus:

  commit b28748fb5d21d5d64c9ce31579ffbbd41f317042
  Author: Russell King 
  Date:   Sun Feb 17 14:40:33 2013 +

ARM: add SCHED_HRTICK config option

As we don't include kernel/Kconfig.hz as this defines HZ values
unsuitable for ARM platforms, add the SCHED_HRTICK to properly configure
the scheduler for hrtimer operation.

Signed-off-by: Russell King 

... so if kernel/Kconfig.hz is 'unsuitable for ARM platforms' how 
about fixing it properly and making init/Kconfig.hz suitable for ARM, 
instead of duplicating its options in arch/arm/Kconfig in a messy 
fashion?

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: [GIT PULL] EFI runtime mapping work for v3.14

[Borislav Petkov]

On Tue, Nov 26, 2013 at 12:26:50PM +0100, Ingo Molnar wrote:
> Just a side note, for future reference, this title lacks a verb and is 
> thus not self-describing:
> 
>x86/efi: Runtime services virtual mapping
> 
> It should probably have been something like:
> 
>x86/efi: Implement and enable separate, stable virtual mapping for runtime 
> services
> 
> ?

My bad: it should've been "Reimplement runtime services virtual mapping"
or sth like that.

> Chances are that it will be a popular bisection target ;-)

I *so* hope your clairvoyant skills fail you this time :-)

-- 
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: [RFC patch 0/5] futex: Allow lockless empty check of hashbucket plist in futex_wake()

[Peter Zijlstra]

On Tue, Nov 26, 2013 at 12:21:40PM +0100, Ingo Molnar wrote:
> I'm somewhat reluctant to chalk it up to a single mfence - maybe 
> timings/behavior changed in some substantial way?

Ah indeed! We also changed the case where an enqueueing futex sees the
uval change and bails. It is now far more expensive due to having to
both queue and unqueue, whereas before it wouldn't queue at all.

I suppose the idea was to offset that by not requiring locking on the
wake side.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC

[Naveen Krishna Ch]

Hello Sachin,

On 26 November 2013 16:59, Sachin Kamat  wrote:
> On 26 November 2013 09:56, Naveen Krishna Chatradhi
>  wrote:
>> This patch adds new compatible to support HSI2C module on Exynos5260
>> HSI2C module on Exynos5260 needs to be reset during during initialization.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
> [snip]
>>
>>  Required properties:
>>- compatible: value should be.
>> -  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
>> +   -> "samsung,exynos5-hsi2c", for i2c compatible with HSI2C available 
>> on
>> +   Exynos5250/5420 SoCs.
The first HSI2C module is available on Exynos5 SoCs from Samsung.
Hence, "samsung,exynos5-hsi2c"
HSI2C Module on  Exynos5250 and Exynos5420 was exactly similar

HSI2C Module on Exynos5260 differs in hardware.
Hence, "samsung,exynos5260-hsi2c".

And as the new variants come we use "samsung,exynosXXX-hsi2c"
or we can go by "samsung,exynos5-hsi2c-v2"

Changing an existing compatible needs modification in the DT nodes as well.

I will change the compatible string, if anyone else also thinks its wise.
>
> This string could be made more specific ("samsung,exynos5250-hsi2c")
> now that we have variants for this.
>
>> +   -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C 
>> available
>> +   on Exynos5260 SoCs.
>> +
>>- reg: physical base address of the controller and length of memory mapped
>>  region.
>>- interrupts: interrupt number to the cpu.
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c 
>> b/drivers/i2c/busses/i2c-exynos5.c
>> index da39ff0..497ff91 100644
>> --- a/drivers/i2c/busses/i2c-exynos5.c
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -184,14 +184,35 @@ struct exynos5_i2c {
>>  * 2. Fast speed upto 1Mbps
>>  */
>> int speed_mode;
>> +
>> +   /* Version of HS-I2C Hardware */
>> +   unsigned intversion;
>> +};
>> +
>> +enum hsi2c_version {
>> +   EXYNOS_5,
>
> ditto.
>
>> +   EXYNOS_5260
>>  };
>>
>
> --
> With warm regards,
> Sachin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf tools: Fix tags target rebuilding

[Jiri Olsa]

On Tue, Nov 26, 2013 at 12:31:08PM +0100, Ingo Molnar wrote:
> 
> * Jiri Olsa  wrote:
> 
> > Once the tags file is generated it's never rebuilt
> > until it's removed by hand.
> > 
> > The reason is that the Makefile does not treat tags
> > as a target but as a file to be rebuilt.
> > 
> > Adding tags as PHONY target into the Makefile.
> > 
> > Signed-off-by: Jiri Olsa 
> > Cc: Ingo Molnar 
> > Cc: Frederic Weisbecker 
> > Cc: Peter Zijlstra 
> > Cc: Namhyung Kim 
> > Cc: Mike Galbraith 
> > Cc: Stephane Eranian 
> > Cc: David Ahern 
> > Cc: Adrian Hunter 
> > Cc: Arnaldo Carvalho de Melo 
> > ---
> >  tools/perf/Makefile | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> > index 4835618..95f5792 100644
> > --- a/tools/perf/Makefile
> > +++ b/tools/perf/Makefile
> > @@ -61,7 +61,7 @@ endef
> >  #
> >  # Needed if no target specified:
> >  #
> > -all:
> > +all tags:
> 
> Obviously the change invalidates the comment above.

ugh, haven't noticed that comment ;-)

> 
> > $(print_msg)
> > $(make)
> >  
> > @@ -77,3 +77,5 @@ clean:
> >  %:
> > $(print_msg)
> > $(make)
> > +
> > +.PHONY: tags
> 
> Note that there's also a TAGS file that uses etags - which probably 
> needs similar treatment.

yes

> 
> Also note that we have duplicate code for this in Makefile.perf 
> already. Would it be possible to pass through this there and keep the 
> main Makefile is just a thin, minimal wrapper that adds default 
> parallelism, etc?

well, thats what I actually tried to do.. pass the
processing to the Makefile.perf otherwise it stops
in Makefile

I guess you want some generic way of doing that

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:Answer back.

[Lee Hyuk]

I would like to discuss a very important crude oil project with you,kindly
revert back to me if this is your valid email address forfurther
information.
Regards,
Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] perf diff: color the Delta column

[Jiri Olsa]

On Sun, Nov 24, 2013 at 11:50:22AM +0530, Ramkumar Ramachandra wrote:
> Color the numbers in the Delta column either green or red depending on
> whether the number is positive or negative.
> 
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Cc: Arnaldo Carvalho de Melo 
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  tools/perf/builtin-diff.c | 37 -
>  1 file changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 79e0448..84d5f2d 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -769,6 +769,33 @@ static int hpp__entry_baseline(struct hist_entry *he, 
> char *buf, size_t size)
>   return ret;
>  }
>  
> +static int hpp__color_delta(struct perf_hpp_fmt *fmt,
> + struct perf_hpp *hpp, struct hist_entry *he)
> +{
> + struct diff_hpp_fmt *dfmt =
> + container_of(fmt, struct diff_hpp_fmt, fmt);
> + struct hist_entry *pair = get_pair_fmt(he, dfmt);
> + double percent;
> + char pfmt[20] = " ";
> +
> + if (!pair)
> + goto dummy_print;

same comment here ^^^ as for previous patch

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] perf diff: don't compute Delta if he->dummy

[Jiri Olsa]

On Sun, Nov 24, 2013 at 11:50:21AM +0530, Ramkumar Ramachandra wrote:
> Cc: Arnaldo Carvalho de Melo 
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  tools/perf/builtin-diff.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 3b67ea2..79e0448 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -792,6 +792,9 @@ hpp__entry_pair(struct hist_entry *he, struct hist_entry 
> *pair,
>  
>   switch (idx) {
>   case PERF_HPP_DIFF__DELTA:
> + if (he->dummy)
> + break;
> +

the reason I disabled the computation for dummy pairs was
that the number (ratio and weighted diff) would not make much
sense (to me) without the real pair

but within the dummy delta column we actually see the compared
file % overheader which is helpfull, even if there's no real pair
in the baseline

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf tools: Fix tags target rebuilding

[Ingo Molnar]

* Jiri Olsa  wrote:

> Once the tags file is generated it's never rebuilt
> until it's removed by hand.
> 
> The reason is that the Makefile does not treat tags
> as a target but as a file to be rebuilt.
> 
> Adding tags as PHONY target into the Makefile.
> 
> Signed-off-by: Jiri Olsa 
> Cc: Ingo Molnar 
> Cc: Frederic Weisbecker 
> Cc: Peter Zijlstra 
> Cc: Namhyung Kim 
> Cc: Mike Galbraith 
> Cc: Stephane Eranian 
> Cc: David Ahern 
> Cc: Adrian Hunter 
> Cc: Arnaldo Carvalho de Melo 
> ---
>  tools/perf/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index 4835618..95f5792 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -61,7 +61,7 @@ endef
>  #
>  # Needed if no target specified:
>  #
> -all:
> +all tags:

Obviously the change invalidates the comment above.

>   $(print_msg)
>   $(make)
>  
> @@ -77,3 +77,5 @@ clean:
>  %:
>   $(print_msg)
>   $(make)
> +
> +.PHONY: tags

Note that there's also a TAGS file that uses etags - which probably 
needs similar treatment.

Also note that we have duplicate code for this in Makefile.perf 
already. Would it be possible to pass through this there and keep the 
main Makefile is just a thin, minimal wrapper that adds default 
parallelism, etc?

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 1/2 v2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC

[Sachin Kamat]

On 26 November 2013 09:56, Naveen Krishna Chatradhi
 wrote:
> This patch adds new compatible to support HSI2C module on Exynos5260
> HSI2C module on Exynos5260 needs to be reset during during initialization.
>
> Signed-off-by: Naveen Krishna Chatradhi 
[snip]
>
>  Required properties:
>- compatible: value should be.
> -  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
> +   -> "samsung,exynos5-hsi2c", for i2c compatible with HSI2C available on
> +   Exynos5250/5420 SoCs.

This string could be made more specific ("samsung,exynos5250-hsi2c")
now that we have variants for this.

> +   -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available
> +   on Exynos5260 SoCs.
> +
>- reg: physical base address of the controller and length of memory mapped
>  region.
>- interrupts: interrupt number to the cpu.
> diff --git a/drivers/i2c/busses/i2c-exynos5.c 
> b/drivers/i2c/busses/i2c-exynos5.c
> index da39ff0..497ff91 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -184,14 +184,35 @@ struct exynos5_i2c {
>  * 2. Fast speed upto 1Mbps
>  */
> int speed_mode;
> +
> +   /* Version of HS-I2C Hardware */
> +   unsigned intversion;
> +};
> +
> +enum hsi2c_version {
> +   EXYNOS_5,

ditto.

> +   EXYNOS_5260
>  };
>

-- 
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EFI runtime mapping work for v3.14

[Ingo Molnar]

* Matt Fleming  wrote:

> Folks, could you queue up the following for the v3.14 merge window? It
> would be good to get these patches into linux-next for a full release
> cycle of testing. They pass all of my tests.
> 
> The following changes since commit 72548e836b0c4abbb652e791dee9c91203a9a4c6:
> 
>   x86/efi: Add EFI framebuffer earlyprintk support (2013-10-28 18:09:58 +)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next
> 
> for you to fetch changes up to ee41143027706d9f342dfe05487a00b20887fde7:
> 
>   x86/efi: Check krealloc return value (2013-11-02 11:09:36 +)
> 
> 
>  * New static EFI runtime services virtual mapping layout which is
>groundwork for kexec support on EFI - Borislav Petkov
> 
> 
> Borislav Petkov (11):
>   x86/efi: Simplify EFI_DEBUG
>   x86/mm/pageattr: Lookup address in an arbitrary PGD
>   x86/mm/pageattr: Add a PGD pagetable populating function
>   x86/mm/pageattr: Add a PUD pagetable populating function
>   x86/mm/pageattr: Add a PMD pagetable populating function
>   x86/mm/pageattr: Add a PTE pagetable populating function
>   x86/mm/pageattr: Add a PUD error unwinding path
>   x86/mm/pageattr: Add last levels of error path
>   x86/mm/cpa: Map in an arbitrary pgd
>   x86/efi: Runtime services virtual mapping
>   x86/efi: Check krealloc return value
> 
>  Documentation/kernel-parameters.txt  |   6 +
>  Documentation/x86/x86_64/mm.txt  |   7 +
>  arch/x86/include/asm/efi.h   |  64 +++--
>  arch/x86/include/asm/pgtable_types.h |   3 +-
>  arch/x86/mm/pageattr.c   | 461 
> +--
>  arch/x86/platform/efi/efi.c  | 111 ++---
>  arch/x86/platform/efi/efi_32.c   |   9 +-
>  arch/x86/platform/efi/efi_64.c   | 109 +
>  arch/x86/platform/efi/efi_stub_64.S  |  54 
>  include/linux/efi.h  |   1 +
>  10 files changed, 755 insertions(+), 70 deletions(-)
> 
> -- 
> Matt Fleming, Intel Open Source Technology Center

Pulled into tip:x86/efi, thanks a lot guys!

Just a side note, for future reference, this title lacks a verb and is 
thus not self-describing:

   x86/efi: Runtime services virtual mapping

It should probably have been something like:

   x86/efi: Implement and enable separate, stable virtual mapping for runtime 
services

?

Chances are that it will be a popular bisection target ;-)

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC patch 0/5] futex: Allow lockless empty check of hashbucket plist in futex_wake()

[Ingo Molnar]

* Peter Zijlstra  wrote:

> On Tue, Nov 26, 2013 at 12:12:31AM -0800, Davidlohr Bueso wrote:
> 
> > I am becoming hesitant about this approach. The following are some
> > results, from my quad-core laptop, measuring the latency of nthread
> > wakeups (1 at a time). In addition, failed wait calls never occur -- so
> > we don't end up including the (otherwise minimal) overhead of the list
> > queue+dequeue, only measuring the smp_mb() usage when !empty list never
> > occurs.
> > 
> > +-+++---++--+
> > | threads | baseline time (ms) | stddev | patched time (ms) | stddev | 
> > overhead |
> > +-+++---++--+
> > | 512 | 4.2410 | 0.9762 | 12.3660   | 5.1020 | 
> > +191.58% |
> > | 256 | 2.7750 | 0.3997 | 7.0220| 2.9436 | 
> > +153.04% |
> > | 128 | 1.4910 | 0.4188 | 3.7430| 0.8223 | 
> > +151.03% |
> > |  64 | 0.8970 | 0.3455 | 2.5570| 0.3710 | 
> > +185.06% |
> > |  32 | 0.3620 | 0.2242 | 1.1300| 0.4716 | 
> > +212.15% |
> > +-+++---++--+
> > 
> 
> Whee, this is far more overhead than I would have expected... pretty
> impressive really for a simple mfence ;-)

I'm somewhat reluctant to chalk it up to a single mfence - maybe 
timings/behavior changed in some substantial way?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] perf tools: Fix tags target rebuilding

[Jiri Olsa]

Once the tags file is generated it's never rebuilt
until it's removed by hand.

The reason is that the Makefile does not treat tags
as a target but as a file to be rebuilt.

Adding tags as PHONY target into the Makefile.

Signed-off-by: Jiri Olsa 
Cc: Ingo Molnar 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Namhyung Kim 
Cc: Mike Galbraith 
Cc: Stephane Eranian 
Cc: David Ahern 
Cc: Adrian Hunter 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 4835618..95f5792 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -61,7 +61,7 @@ endef
 #
 # Needed if no target specified:
 #
-all:
+all tags:
$(print_msg)
$(make)
 
@@ -77,3 +77,5 @@ clean:
 %:
$(print_msg)
$(make)
+
+.PHONY: tags
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] use -fstack-protector-strong

[Ingo Molnar]

* Nicolas Pitre  wrote:

> On Mon, 25 Nov 2013, Kees Cook wrote:
> 
> > On Mon, Nov 25, 2013 at 3:16 PM, H. Peter Anvin  wrote:
> > > On 11/25/2013 02:14 PM, Kees Cook wrote:
> > >> Build the kernel with -fstack-protector-strong when it is available
> > >> (gcc 4.9 and later). This increases the coverage of the stack protector
> > >> without the heavy performance hit of -fstack-protector-all.
> > >
> > > What is the difference between the various options?
> > 
> > -fstack-protector-all:
> > Adds the stack-canary saving prefix and stack-canary checking suffix
> > to _all_ function entry and exit. Results in substantial use of stack
> > space for saving the canary for deep stack users (e.g. historically
> > xfs), and measurable (though shockingly still low) performance hit due
> > to all the saving/checking. Really not suitable for sane systems, and
> > was entirely removed as an option from the kernel many years ago.
> > 
> > -fstack-protector:
> > Adds the canary save/check to functions that define an 8
> > (--param=ssp-buffer-size=N, N=8 by default) or more byte local char
> > array. Traditionally, stack overflows happened with string-based
> > manipulations, so this was a way to find those functions. Very few
> > total functions actually get the canary; no measurable performance or
> > size overhead.
> > 
> > -fstack-protector-strong
> > Adds the canary for a wider set of functions, since it's not just
> > those with strings that have ultimately been vulnerable to
> > stack-busting. With this superset, more functions end up with a
> > canary, but it still remains small compared to all functions with no
> > measurable change in performance. Based on the original design
> > document, a function gets the canary when it contains any of:
> > - local variable's address used as part of the RHS of an assignment or
> > function argument
> > - local variable is an array (or union containing an array),
> > regardless of array type or length
> > - uses register local variables
> > https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU
> > 
> > Chrome OS has been using -fstack-protector-strong for its kernel
> > builds for the last 8 months with no problems.
> 
> Could you get this information inside the commit log for your patch 
> please?  This is very valuable info to have right next to the change 
> in the repository without having to dig into the gcc manual or 
> finding the relevant email thread.

Another piece of information we need for the changelog is a vmlinux 
kernel size comparison, with/without the patch, for a defconfig build 
(or a Ubuntu distro config build).

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] rtc: s5m-rtc: Fix info->rtc assignment

[Krzysztof Kozlowski]

On 11/26/2013 10:17 AM, Krzysztof Kozlowski wrote:

On 11/15/2013 12:54 PM, Geert Uytterhoeven wrote:

drivers/rtc/rtc-s5m.c: In function ‘s5m_rtc_probe’:
drivers/rtc/rtc-s5m.c:545: warning: assignment from incompatible
pointer type

struct s5m_rtc_info.rtc has type "struct regmap *", while
struct sec_pmic_dev.rtc has type "struct i2c_client *".

Probably the author wanted to assign "struct sec_pmic_dev.regmap", which
has the correct type.

Also, as "rtc" doesn't make much sense as a name for a regmap, rename
it to
"regmap".

Signed-off-by: Geert Uytterhoeven 
---
I would be really surprised if this driver didn't just crash...
Please test. Thanks!

  drivers/rtc/rtc-s5m.c |   54
-
  1 file changed, 27 insertions(+), 27 deletions(-)


Seems good, tested on device with S5M8767.

Tested-by: Krzysztof Kozlowski 


Arrrg, the fix is needed but not sufficient. The chip has different I2C 
addresses for RTC and PMIC so additional regmap is needed. Currently 
this rtc-s5m driver does not work. I'll send patches fixing it.


Best regards,
Krzysztof




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3 v3] build in panic_timeout value

[Ingo Molnar]

* Jason Baron  wrote:

> Hi,
> 
> I've now separated out the arch bits into separate patches. 
> Hopefully, it makes review easier. I also didn't address moving the 
> 'panic_timeout' command-line parameter up as an 'early_param()'. I 
> think it might make sense to move it up, especially for distro 
> kernels, but its not a need here, so I didn't want to just shove it 
> in. If needed, I think it can come in separately, as it shoudn't 
> affect this series.

The series looks good to me, I've applied the patches to 
tip:core/debug.

If Felipe Contreras's fix patch looks good to you then it would also 
be nice if you could send me that as well, on top of your patches.

That fix patch had only one remaining bug/problem, last I checked: if 
panic_timeout is turned into an early_param() then pause_on_oops 
should obviously also be turned into an early param. Changing just one 
of these parameters would be inconsistent and would lead to assymetric 
behavior in the early-crash case.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5][v2] phylib: Add of_phy_attach

[shh.xie]

From: Andy Fleming 

10G PHYs don't currently support running the state machine, which
is implicitly setup via of_phy_connect(). Therefore, it is necessary
to implement an OF version of phy_attach(), which does everything
except start the state machine.

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
---
v2: no changes.

 drivers/of/of_mdio.c| 19 +++
 include/linux/of_mdio.h |  9 +
 2 files changed, 28 insertions(+)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index d5a57a9..21076ac 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -247,3 +247,22 @@ struct phy_device *of_phy_connect_fixed_link(struct 
net_device *dev,
return IS_ERR(phy) ? NULL : phy;
 }
 EXPORT_SYMBOL(of_phy_connect_fixed_link);
+
+/**
+ * of_phy_attach - Attach to a PHY without starting the state machine
+ * @dev: pointer to net_device claiming the phy
+ * @phy_np: Node pointer for the PHY
+ * @flags: flags to pass to the PHY
+ * @iface: PHY data interface type
+ */
+struct phy_device *of_phy_attach(struct net_device *dev,
+   struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+   struct phy_device *phy = of_phy_find_device(phy_np);
+
+   if (!phy)
+   return NULL;
+
+   return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
+}
+EXPORT_SYMBOL(of_phy_attach);
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 8163107..108583a 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -19,6 +19,9 @@ extern struct phy_device *of_phy_connect(struct net_device 
*dev,
 struct device_node *phy_np,
 void (*hndlr)(struct net_device *),
 u32 flags, phy_interface_t iface);
+struct phy_device *of_phy_attach(struct net_device *dev,
+struct device_node *phy_np, u32 flags,
+phy_interface_t iface);
 extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
 void (*hndlr)(struct net_device *),
 phy_interface_t iface);
@@ -44,6 +47,12 @@ static inline struct phy_device *of_phy_connect(struct 
net_device *dev,
return NULL;
 }
 
+static inline struct phy_device *of_phy_attach(struct net_device *dev,
+   struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+   return NULL;
+}
+
 static inline struct phy_device *of_phy_connect_fixed_link(struct net_device 
*dev,
   void (*hndlr)(struct 
net_device *),
   phy_interface_t 
iface)
-- 
1.8.4.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5][v2] phylib: Add generic 10G driver

[shh.xie]

From: Andy Fleming 

Very incomplete, but will allow for binding an ethernet controller
to it.

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
---
v2: turn genphy_driver to an array, add generic 10g driver to it.

 drivers/net/phy/phy_device.c | 96 
 1 file changed, 89 insertions(+), 7 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index d6447b3..96a5e03 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -53,7 +54,7 @@ static void phy_device_release(struct device *dev)
kfree(to_phy_device(dev));
 }
 
-static struct phy_driver genphy_driver;
+static struct phy_driver genphy_driver[2];
 extern int mdio_bus_init(void);
 extern void mdio_bus_exit(void);
 
@@ -539,7 +540,7 @@ static int phy_attach_direct(struct net_device *dev, struct 
phy_device *phydev,
return -ENODEV;
}
 
-   d->driver = _driver.driver;
+   d->driver = _driver[0].driver;
 
err = d->driver->probe(d);
if (err >= 0)
@@ -620,7 +621,7 @@ void phy_detach(struct phy_device *phydev)
 * was using the generic driver), we unbind the device
 * from the generic driver so that there's a chance a
 * real driver could be loaded */
-   if (phydev->dev.driver == _driver.driver)
+   if (phydev->dev.driver == _driver[0].driver)
device_release_driver(>dev);
 }
 EXPORT_SYMBOL(phy_detach);
@@ -689,6 +690,12 @@ static int genphy_config_advert(struct phy_device *phydev)
return changed;
 }
 
+int gen10g_config_advert(struct phy_device *dev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_config_advert);
+
 /**
  * genphy_setup_forced - configures/forces speed/duplex from @phydev
  * @phydev: target phy_device struct
@@ -742,6 +749,11 @@ int genphy_restart_aneg(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_restart_aneg);
 
+int gen10g_restart_aneg(struct phy_device *phydev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_restart_aneg);
 
 /**
  * genphy_config_aneg - restart auto-negotiation or write BMCR
@@ -784,6 +796,12 @@ int genphy_config_aneg(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_config_aneg);
 
+int gen10g_config_aneg(struct phy_device *phydev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_config_aneg);
+
 /**
  * genphy_update_link - update link status in @phydev
  * @phydev: target phy_device struct
@@ -913,6 +931,34 @@ int genphy_read_status(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_read_status);
 
+int gen10g_read_status(struct phy_device *phydev)
+{
+   int devad, reg;
+   u32 mmd_mask = phydev->c45_ids.devices_in_package;
+
+   phydev->link = 1;
+
+   /* For now just lie and say it's 10G all the time */
+   phydev->speed = SPEED_1;
+   phydev->duplex = DUPLEX_FULL;
+
+   for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
+   if (!(mmd_mask & 1))
+   continue;
+
+   /* Read twice because link state is latched and a
+* read moves the current state into the register
+*/
+   phy_read_mmd(phydev, devad, MDIO_STAT1);
+   reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
+   if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
+   phydev->link = 0;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_read_status);
+
 static int genphy_config_init(struct phy_device *phydev)
 {
int val;
@@ -959,6 +1005,16 @@ static int genphy_config_init(struct phy_device *phydev)
 
return 0;
 }
+
+static int gen10g_config_init(struct phy_device *phydev)
+{
+   /* Temporarily just say we support everything */
+   phydev->supported = SUPPORTED_1baseT_Full;
+   phydev->advertising = SUPPORTED_1baseT_Full;
+
+   return 0;
+}
+
 int genphy_suspend(struct phy_device *phydev)
 {
int value;
@@ -974,6 +1030,12 @@ int genphy_suspend(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_suspend);
 
+int gen10g_suspend(struct phy_device *phydev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_suspend);
+
 int genphy_resume(struct phy_device *phydev)
 {
int value;
@@ -989,6 +1051,12 @@ int genphy_resume(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_resume);
 
+int gen10g_resume(struct phy_device *phydev)
+{
+   return 0;
+}
+EXPORT_SYMBOL(gen10g_resume);
+
 /**
  * phy_probe - probe and init a PHY device
  * @dev: device to probe and init
@@ -1116,7 +1184,8 @@ void phy_drivers_unregister(struct phy_driver *drv, int n)
 }
 EXPORT_SYMBOL(phy_drivers_unregister);
 
-static struct phy_driver genphy_driver = {
+static struct phy_driver genphy_driver[] = {
+{
.phy_id = 0x,
.phy_id_mask= 0x,
.name   = "Generic PHY",
@@ -1127,7 

[PATCH 4/5] phylib: Support attaching to generic 10g driver

[shh.xie]

From: Andy Fleming 

phy_attach_direct() may now attach to a generic 10G driver. It can
also be used exactly as phy_connect_direct(), which will be useful
when using of_mdio, as phy_connect (and therefore of_phy_connect)
start the PHY state machine, which is currently irrelevant for 10G
PHYs.

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
---
v2: align with the array genphy_driver.

 drivers/net/phy/phy_device.c | 22 ++
 include/linux/phy.h  |  2 ++
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 96a5e03..a6b4ce0 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -61,9 +61,6 @@ extern void mdio_bus_exit(void);
 static LIST_HEAD(phy_fixup_list);
 static DEFINE_MUTEX(phy_fixup_lock);
 
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
-u32 flags, phy_interface_t interface);
-
 /*
  * Creates a new phy_fixup and adds it to the list
  * @bus_id: A string which matches phydev->dev.bus_id (or PHY_ANY_ID)
@@ -521,12 +518,12 @@ int phy_init_hw(struct phy_device *phydev)
  *
  * Description: Called by drivers to attach to a particular PHY
  * device. The phy_device is found, and properly hooked up
- * to the phy_driver.  If no driver is attached, then the
- * genphy_driver is used.  The phy_device is given a ptr to
+ * to the phy_driver.  If no driver is attached, then a
+ * generic driver is used.  The phy_device is given a ptr to
  * the attaching device, and given a callback for link status
  * change.  The phy_device is returned to the attaching driver.
  */
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
 u32 flags, phy_interface_t interface)
 {
struct device *d = >dev;
@@ -535,12 +532,10 @@ static int phy_attach_direct(struct net_device *dev, 
struct phy_device *phydev,
/* Assume that if there is no driver, that it doesn't
 * exist, and we should use the genphy driver. */
if (NULL == d->driver) {
-   if (phydev->is_c45) {
-   pr_err("No driver for phy %x\n", phydev->phy_id);
-   return -ENODEV;
-   }
-
-   d->driver = _driver[0].driver;
+   if (phydev->is_c45)
+   d->driver = _driver[1].driver;
+   else
+   d->driver = _driver[0].driver;
 
err = d->driver->probe(d);
if (err >= 0)
@@ -573,6 +568,7 @@ static int phy_attach_direct(struct net_device *dev, struct 
phy_device *phydev,
 
return err;
 }
+EXPORT_SYMBOL(phy_attach_direct);
 
 /**
  * phy_attach - attach a network device to a particular PHY device
@@ -623,6 +619,8 @@ void phy_detach(struct phy_device *phydev)
 * real driver could be loaded */
if (phydev->dev.driver == _driver[0].driver)
device_release_driver(>dev);
+   else if (phydev->dev.driver == _driver[1].driver)
+   device_release_driver(>dev);
 }
 EXPORT_SYMBOL(phy_detach);
 
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 2606599..00abc35 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -575,6 +575,8 @@ int phy_init_hw(struct phy_device *phydev);
 struct phy_device * phy_attach(struct net_device *dev,
const char *bus_id, phy_interface_t interface);
 struct phy_device *phy_find_first(struct mii_bus *bus);
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+u32 flags, phy_interface_t interface);
 int phy_connect_direct(struct net_device *dev, struct phy_device *phydev,
void (*handler)(struct net_device *),
phy_interface_t interface);
-- 
1.8.4.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/6] watchdog: davinci: change driver to use WDT core

[Grygorii Strashko]

On 11/25/2013 04:04 PM, Ivan Khoronzhuk wrote:

To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.

Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core tracks state with its own variable.

The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. The heartbeat is
initialized in next way. If heartbeat is not set thought module
parameter, try to read it's value from WDT node timeout-sec property.
If node has no one, use default value.

The heartbeat is hold in wdd->timeout by WDT core, so use it in
order to set timeout period.

Signed-off-by: Ivan Khoronzhuk 
Acked-by: Santosh Shilimkar 
Reviewed-by: Guenter Roeck 
---
  arch/arm/mach-davinci/da8xx-dt.c  |2 +-
  arch/arm/mach-davinci/devices-da8xx.c |4 +-
  arch/arm/mach-davinci/devices.c   |2 +-
  drivers/watchdog/Kconfig  |2 +
  drivers/watchdog/davinci_wdt.c|  151 -
  5 files changed, 43 insertions(+), 118 deletions(-)


Pls note, that this patch contains both changes in platform and driver 
code to fix regression reported by Sekhar Nori on v2 of this series and 
caused by driver name changing.


Is it ok?

It can be splitted, but then both patches will introduce regression by 
itself and thing will work only if both of them will be applied together.




diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index d2bc574..ed19287 100644

[...]

-MODULE_ALIAS("platform:watchdog");
+MODULE_ALIAS("platform:davinci-wdt");


Regards,
-Grygorii

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5][v2] phylib: introduce PHY_INTERFACE_MODE_XGMII for 10G PHY

[shh.xie]

From: Shaohui Xie 

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
---
v2: update of_net.c.

 drivers/of/of_net.c | 1 +
 include/linux/phy.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index 8f9be2e..a208a45 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -30,6 +30,7 @@ static const char *phy_modes[] = {
[PHY_INTERFACE_MODE_RGMII_TXID] = "rgmii-txid",
[PHY_INTERFACE_MODE_RTBI]   = "rtbi",
[PHY_INTERFACE_MODE_SMII]   = "smii",
+   [PHY_INTERFACE_MODE_XGMII]  = "xgmii",
 };
 
 /**
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 2549b42..2606599 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -66,6 +66,7 @@ typedef enum {
PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI,
PHY_INTERFACE_MODE_SMII,
+   PHY_INTERFACE_MODE_XGMII,
 } phy_interface_t;
 
 
-- 
1.8.4.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5][v2] phylib: Add Clause 45 read/write functions

[shh.xie]

From: Andy Fleming 

Need an extra parameter to read or write Clause 45 PHYs, so
need a different API with the extra parameter.

Signed-off-by: Andy Fleming 
Signed-off-by: Shaohui Xie 
---
v2: no change.

 include/linux/phy.h | 33 +
 1 file changed, 33 insertions(+)

diff --git a/include/linux/phy.h b/include/linux/phy.h
index 48a4dc3..2549b42 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -498,6 +498,21 @@ static inline int phy_read(struct phy_device *phydev, u32 
regnum)
 }
 
 /**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+static inline int phy_read_mmd(struct phy_device *phydev, int devad, u32 
regnum)
+{
+   return mdiobus_read(phydev->bus, phydev->addr,
+   MII_ADDR_C45 | (devad << 16) | (regnum & 0x));
+}
+
+/**
  * phy_write - Convenience function for writing a given PHY register
  * @phydev: the phy_device struct
  * @regnum: register number to write
@@ -533,6 +548,24 @@ static inline bool phy_is_internal(struct phy_device 
*phydev)
return phydev->is_internal;
 }
 
+/**
+ * phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for phy_write();
+ */
+static inline int phy_write_mmd(struct phy_device *phydev, int devad,
+   u32 regnum, u16 val)
+{
+   regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0x);
+
+   return mdiobus_write(phydev->bus, phydev->addr, regnum, val);
+}
+
 struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
bool is_c45, struct phy_c45_device_ids *c45_ids);
 struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
-- 
1.8.4.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf timechart: remove lock_depth from trace_entry

[Stanislav Fomichev]

> This makes the new tool stop processing old files, can you try the patch
> attached instead?
I see two downsides to your approach:
1) with your patch I'm now required to run 'perf timechart record' and
'perf timechart' on the same machine (otherwise, on the 'perf timechart'
machine we may have wrong fields definitions that don't match perf.data).
Currently, it's possible to use 'perf timechart record' on the target and do
'perf timechart' on the host (at least I do it this way).
2) only root can run 'perf timechart' now (because of permissions on
/sys/kernel/debug).

Maybe we can we make some simple version check against the perf.data file and
just refuse to process the old one (not sure if it's possible)?

> Its only compile tested tho.
Ok, I'll test it if we are fine with the new limitations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] mm: compaction: reset scanner positions immediately when they meet

[Mel Gorman]

On Mon, Nov 25, 2013 at 03:26:10PM +0100, Vlastimil Babka wrote:
> Compaction used to start its migrate and free page scaners at the zone's 
> lowest
> and highest pfn, respectively. Later, caching was introduced to remember the
> scanners' progress across compaction attempts so that pageblocks are not
> re-scanned uselessly. Additionally, pageblocks where isolation failed are
> marked to be quickly skipped when encountered again in future compactions.
> 
> Currently, both the reset of cached pfn's and clearing of the pageblock skip
> information for a zone is done in __reset_isolation_suitable(). This function
> gets called when:
>  - compaction is restarting after being deferred
>  - compact_blockskip_flush flag is set in compact_finished() when the scanners
>meet (and not again cleared when direct compaction succeeds in allocation)
>and kswapd acts upon this flag before going to sleep
> 
> This behavior is suboptimal for several reasons:
>  - when direct sync compaction is called after async compaction fails (in the
>allocation slowpath), it will effectively do nothing, unless kswapd
>happens to process the compact_blockskip_flush flag meanwhile. This is racy
>and goes against the purpose of sync compaction to more thoroughly retry
>the compaction of a zone where async compaction has failed.
>The restart-after-deferring path cannot help here as deferring happens only
>after the sync compaction fails. It is also done only for the preferred
>zone, while the compaction might be done for a fallback zone.
>  - the mechanism of marking pageblock to be skipped has little value since the
>cached pfn's are reset only together with the pageblock skip flags. This
>effectively limits pageblock skip usage to parallel compactions.
> 
> This patch changes compact_finished() so that cached pfn's are reset
> immediately when the scanners meet. Clearing pageblock skip flags is 
> unchanged,
> as well as the other situations where cached pfn's are reset. This allows the
> sync-after-async compaction to retry pageblocks not marked as skipped, such as
> blocks !MIGRATE_MOVABLE blocks that async compactions now skips without
> marking them.
> 
> Cc: Mel Gorman 
> Cc: Rik van Riel 
> Signed-off-by: Vlastimil Babka 

Acked-by: Mel Gorman 

-- 
Mel Gorman
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/

[PATCH] MAINTAINERS: Add an entry for the Macintosh HFSPlus Filesystem

[Geert Uytterhoeven]

Vyacheslav Dubeyko kindly offered to become the maintainer.

Signed-off-by: Geert Uytterhoeven 
---
v2: Orphan -> maintained by Vyacheslav Dubeyko

 MAINTAINERS |7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 746581df3395..a92ac8f6758c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3937,6 +3937,13 @@ S:   Orphan
 F: Documentation/filesystems/hfs.txt
 F: fs/hfs/
 
+HFSPLUS FILESYSTEM
+M: Vyacheslav Dubeyko 
+L: linux-fsde...@vger.kernel.org
+S: Maintained
+F: Documentation/filesystems/hfsplus.txt
+F: fs/hfsplus/
+
 HGA FRAMEBUFFER DRIVER
 M: Ferenc Bakonyi 
 L: linux-nvi...@lists.surfsouth.com
-- 
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: [PATCHv1] ASoC: SGTL5000: Fix kernel failed while getting regulator consumers

[Lothar Waßmann]

Hi,

Xiubo Li wrote:
> SGTL5000 codec allows to use the internal LDO instead of VDDD, if the
> internal LDO is used, this caused the following kernel failed while trying
> to get the external VDDD regulator consumer.
> 
> Adding sgtl5000_external_vddd_used() to fix it. And this has been tested on
> VF610-TWR board.
> 
> sgtl5000 0-000a: Failed to get supply 'VDDD': -19
> 
> Signed-off-by: Xiubo Li 
> ---
> 
>  sound/soc/codecs/sgtl5000.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
> index 1f4093f..1a2d35a 100644
> --- a/sound/soc/codecs/sgtl5000.c
> +++ b/sound/soc/codecs/sgtl5000.c
> @@ -1298,6 +1298,20 @@ static int sgtl5000_replace_vddd_with_ldo(struct 
> snd_soc_codec *codec)
>   return 0;
>  }
>  
> +static int sgtl5000_external_vddd_used(struct snd_soc_codec *codec)
> +{
> + struct regulator *consumer;
> + struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec);
> +
> + consumer = regulator_get(codec->dev, sgtl5000->supplies[VDDD].supply);
> + if (IS_ERR(consumer)) {
> + return 0;
> + }
> + regulator_put(consumer);
> +
> + return 1;
> +}
> +
>  static int sgtl5000_enable_regulators(struct snd_soc_codec *codec)
>  {
>   int reg;
> @@ -1310,9 +1324,7 @@ static int sgtl5000_enable_regulators(struct 
> snd_soc_codec *codec)
>   for (i = 0; i < ARRAY_SIZE(sgtl5000->supplies); i++)
>   sgtl5000->supplies[i].supply = supply_names[i];
>  
> - ret = regulator_bulk_get(codec->dev, ARRAY_SIZE(sgtl5000->supplies),
> - sgtl5000->supplies);
> - if (!ret)
> + if (sgtl5000_external_vddd_used(codec))
>   external_vddd = 1;
>   else {
>   ret = sgtl5000_replace_vddd_with_ldo(codec);
>
You could fix the coding style issue (braces on both branches
of the if clause) here too.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] mm: compaction: do not mark unmovable pageblocks as skipped in async compaction

[Mel Gorman]

On Mon, Nov 25, 2013 at 03:26:09PM +0100, Vlastimil Babka wrote:
> Compaction temporarily marks pageblocks where it fails to isolate pages as
> to-be-skipped in further compactions, in order to improve efficiency. One of
> the reasons to fail isolating pages is that isolation is not attempted in
> pageblocks that are not of MIGRATE_MOVABLE (or CMA) type.
> 
> The problem is that blocks skipped due to not being MIGRATE_MOVABLE in async
> compaction become skipped due to the temporary mark also in future sync
> compaction. Moreover, this may follow quite soon during __alloc_page_slowpath,
> without much time for kswapd to clear the pageblock skip marks. This goes
> against the idea that sync compaction should try to scan these blocks more
> thoroughly than the async compaction.
> 
> The fix is to ensure in async compaction that these !MIGRATE_MOVABLE blocks 
> are
> not marked to be skipped. Note this should not affect performance or locking
> impact of further async compactions, as skipping a block due to being
> !MIGRATE_MOVABLE is done soon after skipping a block marked to be skipped, 
> both
> without locking.
> 
> Cc: Mel Gorman 
> Cc: Rik van Riel 
> Signed-off-by: Vlastimil Babka 
> ---
>  mm/compaction.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 0702bdf..f481193 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -455,6 +455,8 @@ isolate_migratepages_range(struct zone *zone, struct 
> compact_control *cc,
>   unsigned long flags;
>   bool locked = false;
>   struct page *page = NULL, *valid_page = NULL;
> + bool skipped_unmovable = false;
> +
>  

whitespace damage.

>   /*
>* Ensure that there are not too many pages isolated from the LRU
> @@ -530,6 +532,7 @@ isolate_migratepages_range(struct zone *zone, struct 
> compact_control *cc,
>   if (!cc->sync && last_pageblock_nr != pageblock_nr &&
>   !migrate_async_suitable(get_pageblock_migratetype(page))) {
>   cc->finished_update_migrate = true;
> + skipped_unmovable = true;
>   goto next_pageblock;
>   }
>  

Minor nitpick, but it's also unreclaimable and isolate blocks that are
being skipped here. If you do another revision, consider rephrasing
s/unmovable/unsuitable/ where appropriate. It's fairly obvious from
context so if you decide not to, that's fine too.

> @@ -624,7 +627,7 @@ next_pageblock:
>   spin_unlock_irqrestore(>lru_lock, flags);
>  
>   /* Update the pageblock-skip if the whole pageblock was scanned */
> - if (low_pfn == end_pfn)
> + if (low_pfn == end_pfn && !skipped_unmovable)
>   update_pageblock_skip(cc, valid_page, nr_isolated, true);
>  

This comment is now out of date. If the comment gets updated then feel
free to add

Acked-by: Mel Gorman 

-- 
Mel Gorman
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: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()

[Boaz Harrosh]

On 11/26/2013 12:37 PM, Yuanhan Liu wrote:
> 
> If you like, I can add you into the build-notify list. Once the build
> finished, you might get an email like following:
> 
>   --yliu

Na, its fine. thanks though

Cheers
Boaz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/7] sched: Clean up preempt_enable_no_resched() abuse

[Thomas Gleixner]

On Tue, 26 Nov 2013, Eliezer Tamir wrote:

> On 22/11/2013 13:30, Peter Zijlstra wrote:
> > On Fri, Nov 22, 2013 at 08:56:00AM +0200, Eliezer Tamir wrote:
> >> On 21/11/2013 15:39, Peter Zijlstra wrote:
> >>> On Thu, Nov 21, 2013 at 03:26:17PM +0200, Eliezer Tamir wrote:
> > 
> > Please use local_clock(), yes its slightly more expensive, but I doubt
> > you can actually measure the effects on sane hardware.
> 
> If we limit the discussion to sane hardware, I should mention that on
> current Intel CPUs TSC is guaranteed to be monotonic for anything up to
> 8 sockets. Even on slightly older HS TSC skew is very small and should
> not be an issue for this use case.

> Modern sane HW does not have this issue.

That's wrong to begin with. There is no such thing which qualifies as
"sane hardware". Especially not if we are talking about timers.

> The people that do busy polling typically pin tasks to cores anyway.

This is completely irrelevant. If stuff falls apart if the task is not
pinned, then you lost nevertheless.

> You need cap_net_admin to use this setting.

And how is that relevant? cap_net_admin does not change the fact, that
you violate your constraints.

> There is no real damage if the issue happens.

You'r violating the constraints which is not fatal, but not desired
either.

> This is fast-low-latency-path so we are very sensitive to adding even
> a small cost.
> Linus really didn't like adding to the cost of poll/select when busy
> polling is not being used.
 
And that justifies exposing those who do not have access to "sane"
hardware and/or did not pin their tasks to constraint violation?

> Having said that, since we need to fix the timeout issue you pointed
> out, we will test the use of local_clock() and see if it matters or
> not.

If the hardware provides an indicator that the TSC is sane to use,
then sched_clock_stable is 1, so local_clock() will not do the slow
update dance at all. So for "sane" hardware the overhead is minimal
and on crappy hardware the correctness is still ensured with more
overhead.

If you are really concerned about the minimal overhead in the
sched_clock_stable == 1 case, then you better fix that (it's doable
with some brain) instead of hacking broken crap, based on even more
broken assumptions, into the networking code.

It's not the kernels fault, that we need to deal with
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK at all. And we have to deal with it
no matter what, so we cannot make this undone by magic assumptions.

Complain to those who forced us to do this. Hint: It's only ONE CPU
vendor who thought that providing useless timestamps is a brilliant
idea.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/12] mtd: nand: davinci: adjust DT properties to MTD generic

[ivan.khoronzhuk]

On 11/26/2013 12:30 PM, Grygorii Strashko wrote:

On 11/26/2013 09:03 AM, Sekhar Nori wrote:

On Monday 11 November 2013 10:31 PM, Khoronzhuk, Ivan wrote:

The properties davinci-ecc-mode, davinci-nand-use-bbt, davinci-nand-buswidth
are MTD generic. Correct names for them are: nand-ecc-mode, nand-on-flash-bbt,
nand-bus-width accordingly. So rename them in dts and documentation.

Signed-off-by: Ivan Khoronzhuk 
---
   .../devicetree/bindings/mtd/davinci-nand.txt   |   25 

   drivers/mtd/nand/davinci_nand.c|   11 ++---
   2 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt 
b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
index d2a3fc0..befaa5b 100644
--- a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
@@ -37,7 +37,7 @@ Recommended properties :
   - ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask
  addresses for given chipselect.

-- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode
+- nand-ecc-mode:   operation mode of the NAND ecc mode. ECC mode
  valid values for davinci driver:
  - "none"
  - "soft"
@@ -45,10 +45,25 @@ Recommended properties :

   - ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.

-- ti,davinci-nand-buswidth:buswidth 8 or 16.


Shouldn't we keep the documentation for existing bindings while just
marking them as deprecated?


I haven't found any requirements about this in doc.
It's done in both way in other drivers - some keep properties in bindings
documentation and some are not.

Regards,
-grygorii



For me this is not needed, but for example from mtd:
Documentation/devicetree/bindings/mtd/gpmc-nand.txt
,it contains deprecated properties, like a lot of others.

And this sad me I should remain deprecated properties.
Anyway if we have these properties in driver we should describe them.

--
Regards,
Ivan Khoronzhuk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] mm: compaction: detect when scanners meet in isolate_freepages

[Mel Gorman]

On Mon, Nov 25, 2013 at 03:26:08PM +0100, Vlastimil Babka wrote:
> Compaction of a zone is finished when the migrate scanner (which begins at the
> zone's lowest pfn) meets the free page scanner (which begins at the zone's
> highest pfn). This is detected in compact_zone() and in the case of direct
> compaction, the compact_blockskip_flush flag is set so that kswapd later 
> resets
> the cached scanner pfn's, and a new compaction may again start at the zone's
> borders.
> 
> The meeting of the scanners can happen during either scanner's activity.
> However, it may currently fail to be detected when it occurs in the free page
> scanner, due to two problems. First, isolate_freepages() keeps free_pfn at the
> highest block where it isolated pages from, for the purposes of not missing 
> the
> pages that are returned back to allocator when migration fails. Second, 
> failing
> to isolate enough free pages due to scanners meeting results in -ENOMEM being
> returned by migrate_pages(), which makes compact_zone() bail out immediately
> without calling compact_finished() that would detect scanners meeting.
> 
> This failure to detect scanners meeting might result in repeated attempts at
> compaction of a zone that keep starting from the cached pfn's close to the
> meeting point, and quickly failing through the -ENOMEM path, without the 
> cached
> pfns being reset, over and over. This has been observed (through additional
> tracepoints) in the third phase of the mmtests stress-highalloc benchmark, 
> where
> the allocator runs on an otherwise idle system. The problem was observed in 
> the
> DMA32 zone, which was used as a fallback to the preferred Normal zone, but on
> the 4GB system it was actually the largest zone. The problem is even amplified
> for such fallback zone - the deferred compaction logic, which could (after
> being fixed by a previous patch) reset the cached scanner pfn's, is only
> applied to the preferred zone and not for the fallbacks.
> 
> The problem in the third phase of the benchmark was further amplified by 
> commit
> 81c0a2bb ("mm: page_alloc: fair zone allocator policy") which resulted in a
> non-deterministic regression of the allocation success rate from ~85% to ~65%.
> This occurs in about half of benchmark runs, making bisection problematic.
> It is unlikely that the commit itself is buggy, but it should put more 
> pressure
> on the DMA32 zone during phases 1 and 2, which may leave it more fragmented in
> phase 3 and expose the bugs that this patch fixes.
> 
> The fix is to make scanners meeting in isolate_freepage() stay that way, and
> to check in compact_zone() for scanners meeting when migrate_pages() returns
> -ENOMEM. The result is that compact_finished() also detects scanners meeting
> and sets the compact_blockskip_flush flag to make kswapd reset the scanner
> pfn's.
> 
> The results in stress-highalloc benchmark show that the "regression" by commit
> 81c0a2bb in phase 3 no longer occurs, and phase 1 and 2 allocation success 
> rates
> are significantly improved.
> 
> Cc: Mel Gorman 
> Cc: Rik van Riel 
> Signed-off-by: Vlastimil Babka 
> ---
>  mm/compaction.c | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 6a2f0c2..0702bdf 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -656,7 +656,7 @@ static void isolate_freepages(struct zone *zone,
>* is the end of the pageblock the migration scanner is using.
>*/
>   pfn = cc->free_pfn;
> - low_pfn = cc->migrate_pfn + pageblock_nr_pages;
> + low_pfn = ALIGN(cc->migrate_pfn + 1, pageblock_nr_pages);
>  
>   /*
>* Take care that if the migration scanner is at the end of the zone
> @@ -672,7 +672,7 @@ static void isolate_freepages(struct zone *zone,
>* pages on cc->migratepages. We stop searching if the migrate
>* and free page scanners meet or enough free pages are isolated.
>*/
> - for (; pfn > low_pfn && cc->nr_migratepages > nr_freepages;
> + for (; pfn >= low_pfn && cc->nr_migratepages > nr_freepages;
>   pfn -= pageblock_nr_pages) {
>   unsigned long isolated;
>  
> @@ -734,7 +734,14 @@ static void isolate_freepages(struct zone *zone,
>   /* split_free_page does not map the pages */
>   map_pages(freelist);
>  
> - cc->free_pfn = high_pfn;
> +/*
> + * If we crossed the migrate scanner, we want to keep it that way
> +  * so that compact_finished() may detect this
> +  */

Whitespace damage.

> + if (pfn < low_pfn)
> + cc->free_pfn = max(pfn, zone->zone_start_pfn);

Is it even possible for this condition to occur? low_pfn bound is
cc->migrate_pfn and the free scanner should only start after some pages
have already been isolated for migration.

> + else
> + cc->free_pfn = high_pfn;
>   cc->nr_freepages = nr_freepages;
>  }
>  
> @@ -999,7 +1006,11 

Re: [PATCH 21/25] perf evsel: Skip ignored symbols while printing callchain

[Adrian Hunter]

On 25/11/13 16:17, Arnaldo Carvalho de Melo wrote:
> From: David Ahern 
> 
> Allows a command to have a symbol_filter controlled by the user to skip
> certain functions in a backtrace. One example is to allow the user to
> reduce repeating patterns like:
> 
> do_select  core_sys_select  sys_select
> 
> to just sys_select when dumping callchains, consuming less real estate
> on the screen while still conveying the essential message - the process
> is in a select call.
> 
> This option is leveraged by the upcoming timehist command.
> 
> Signed-off-by: David Ahern 
> Cc: Frederic Weisbecker 
> Cc: Ingo Molnar 
> Cc: Jiri Olsa 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Stephane Eranian 
> Link: 
> http://lkml.kernel.org/r/1384806771-2945-2-git-send-email-dsah...@gmail.com
> Signed-off-by: Arnaldo Carvalho de Melo 
> ---
>  tools/perf/util/session.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index f36d24a02445..948f7644b4d9 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -1522,6 +1522,9 @@ void perf_evsel__print_ip(struct perf_evsel *evsel, 
> union perf_event *event,
>   if (!node)
>   break;
>  
> + if (node->sym && node->sym->ignore)
> + goto next;
> +
>   if (print_ip)
>   printf("%c%16" PRIx64, s, node->ip);
>  
> @@ -1544,12 +1547,15 @@ void perf_evsel__print_ip(struct perf_evsel *evsel, 
> union perf_event *event,
>   if (!print_oneline)
>   printf("\n");
>  
> - callchain_cursor_advance(_cursor);
> -
>   stack_depth--;
> +next:
> + callchain_cursor_advance(_cursor);
>   }
>  
>   } else {
> + if (al.sym->ignore)

Seems to segfault here because sym is null

> + return;
> +
>   if (print_ip)
>   printf("%16" PRIx64, sample->ip);
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv1] ASoC: SGTL5000: Fix kernel failed while getting regulator consumers

[Xiubo Li]

SGTL5000 codec allows to use the internal LDO instead of VDDD, if the
internal LDO is used, this caused the following kernel failed while trying
to get the external VDDD regulator consumer.

Adding sgtl5000_external_vddd_used() to fix it. And this has been tested on
VF610-TWR board.

sgtl5000 0-000a: Failed to get supply 'VDDD': -19

Signed-off-by: Xiubo Li 
---

 sound/soc/codecs/sgtl5000.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index 1f4093f..1a2d35a 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1298,6 +1298,20 @@ static int sgtl5000_replace_vddd_with_ldo(struct 
snd_soc_codec *codec)
return 0;
 }
 
+static int sgtl5000_external_vddd_used(struct snd_soc_codec *codec)
+{
+   struct regulator *consumer;
+   struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec);
+
+   consumer = regulator_get(codec->dev, sgtl5000->supplies[VDDD].supply);
+   if (IS_ERR(consumer)) {
+   return 0;
+   }
+   regulator_put(consumer);
+
+   return 1;
+}
+
 static int sgtl5000_enable_regulators(struct snd_soc_codec *codec)
 {
int reg;
@@ -1310,9 +1324,7 @@ static int sgtl5000_enable_regulators(struct 
snd_soc_codec *codec)
for (i = 0; i < ARRAY_SIZE(sgtl5000->supplies); i++)
sgtl5000->supplies[i].supply = supply_names[i];
 
-   ret = regulator_bulk_get(codec->dev, ARRAY_SIZE(sgtl5000->supplies),
-   sgtl5000->supplies);
-   if (!ret)
+   if (sgtl5000_external_vddd_used(codec))
external_vddd = 1;
else {
ret = sgtl5000_replace_vddd_with_ldo(codec);
-- 
1.8.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: [V3 02/10] powerpc, perf: Enable conditional branch filter for POWER8

[Anshuman Khandual]

On 11/26/2013 11:36 AM, m...@ellerman.id.au wrote:
> On Wed, 2013-16-10 at 06:56:49 UTC, Anshuman Khandual wrote:
>> Enables conditional branch filter support for POWER8
>> utilizing MMCRA register based filter and also invalidates
>> a BHRB branch filter combination involving conditional
>> branches.
>>
>> Signed-off-by: Anshuman Khandual 
>> ---
>>  arch/powerpc/perf/power8-pmu.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
>> index 2ee4a70..6e28587 100644
>> --- a/arch/powerpc/perf/power8-pmu.c
>> +++ b/arch/powerpc/perf/power8-pmu.c
>> @@ -580,11 +580,21 @@ static u64 power8_bhrb_filter_map(u64 
>> branch_sample_type)
>>  if (branch_sample_type & PERF_SAMPLE_BRANCH_IND_CALL)
>>  return -1;
>>  
>> +/* Invalid branch filter combination - HW does not support */
>> +if ((branch_sample_type & PERF_SAMPLE_BRANCH_ANY_CALL) &&
>> +(branch_sample_type & PERF_SAMPLE_BRANCH_COND))
>> +return -1;
> 
> What this doesn't make obvious is that the hardware doesn't support any
> combinations. It just happens that these are the only two possibilities we
> allow, and so this is the only combination we have to disallow.
> 
>>
>>  if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY_CALL) {
>>  pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
>>  return pmu_bhrb_filter;
>>  }
>>  
>> +if (branch_sample_type & PERF_SAMPLE_BRANCH_COND) {
>> +pmu_bhrb_filter |= POWER8_MMCRA_IFM3;
>> +return pmu_bhrb_filter;
>> +}
>> +
>>  /* Every thing else is unsupported */
>>  return -1;
>>  }
> 
> I think it would be clearer if we actually checked for the possibilities we
> allow and let everything else fall through, eg:
> 
>   /* Ignore user/kernel/hv bits */
>   branch_sample_type &= ~PERF_SAMPLE_BRANCH_PLM_ALL;
> 
>   if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY)
>   return 0;
> 
>   if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY_CALL)
>   return POWER8_MMCRA_IFM1;
> 
>   if (branch_sample_type == PERF_SAMPLE_BRANCH_COND)
>   return POWER8_MMCRA_IFM3;
>   
>   return -1;
> 

Please look at the 9th patch (power8, perf: Change BHRB branch filter 
configuration).
All these issues are taken care of in this patch. It clearly indicates that any 
combination
of HW BHRB filters will not be supported in the PMU and hence zero out the HW 
filter component
and processes all of those filters in the SW.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ath6kl: sdio: fix system panic when doing wifi stress test

[Kalle Valo]

Hi Jason,

Jason Liu  writes:

> When did the wifi iperf test, meet one following kernel panic:
> command: iperf -c $TARGET_IP -i 5 -t 50 -w 1M
>
> Unable to handle kernel paging request at virtual address 1a48
> pgd = 80004000
> [1a48] *pgd=
> Internal error: Oops: 805 [#1] SMP ARM

[...]

> The kernel panic is caused by the sg_buf is not set correctly with the
> following code when compiled with Yocto GCC 4.8.1:
>
> drivers/net/wireless/ath/ath6kl/hif.h:
> struct hif_scatter_req {
> struct list_head list;
> /* address for the read/write operation */
> u32 addr;
>   ...
>
> /* bounce buffer for upper layers to copy to/from */
> u8 *virt_dma_buf;
>
> struct hif_scatter_item scat_list[1];
>
> u32 scat_q_depth;
> };
>
> (Note: the scat_req.scat_list[] will dynamiclly grow with run-time)

There's actually a major bug right there, scat_list can corrupt scat_q_depth.

> The GCC 4.8.1 compiler will not do the for-loop till scat_entries, instead,
> it only run one round loop. This may be caused by that the GCC 4.8.1 thought
> that the scat_list only have one item and then no need to do full iteration,
> but this is simply wrong by looking at the assebly code. This will cause the
> sg buffer not get set when scat_entries > 1 and thus lead to kernel panic.
>
> This patch is a workaround to the GCC 4.8.1 complier issue by passing the
> entry address of the scat_req->scat_list to the for-loop and interate it,
> then, GCC 4.8.1 will do the full for-loop correctly.
> (Note: This issue not observed with GCC 4.7.2, only found on the GCC 4.8.1)
>
> This patch does not change any function logic and no any performance 
> downgrade.

[...]

> + scat_list = _req->scat_list[0];
> +
>   /* assemble SG list */
> - for (i = 0; i < scat_req->scat_entries; i++, sg++) {
> + for (i = 0; i < scat_req->scat_entries; i++, sg++, scat_list++) {
>   ath6kl_dbg(ATH6KL_DBG_SCATTER, "%d: addr:0x%p, len:%d\n",
> -i, scat_req->scat_list[i].buf,
> -scat_req->scat_list[i].len);
> +i, scat_list->buf, scat_list->len);
>  
> - sg_set_buf(sg, scat_req->scat_list[i].buf,
> -scat_req->scat_list[i].len);
> + sg_set_buf(sg, scat_list->buf, scat_list->len);
>   }

Working around the problem by adding a temporary variable makes me a bit
worried, I would rather fix the root cause. Is the root cause by that we
define the field with scat_list[1]?

Does the patch below help? It would also fix the corruption with
scat_q_depth. Please note that I have only compile tested it. And I
might have also missed something important, so please review it
carefully.

--- a/drivers/net/wireless/ath/ath6kl/hif.h
+++ b/drivers/net/wireless/ath/ath6kl/hif.h
@@ -197,9 +197,9 @@ struct hif_scatter_req {
/* bounce buffer for upper layers to copy to/from */
u8 *virt_dma_buf;
 
-   struct hif_scatter_item scat_list[1];
-
u32 scat_q_depth;
+
+   struct hif_scatter_item scat_list[0];
 };
 
 struct ath6kl_irq_proc_registers {
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c 
b/drivers/net/wireless/ath/ath6kl/sdio.c
index 7126bdd..6bf15a3 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -348,7 +348,7 @@ static int ath6kl_sdio_alloc_prep_scat_req(struct 
ath6kl_sdio *ar_sdio,
int i, scat_req_sz, scat_list_sz, size;
u8 *virt_buf;
 
-   scat_list_sz = (n_scat_entry - 1) * sizeof(struct hif_scatter_item);
+   scat_list_sz = n_scat_entry * sizeof(struct hif_scatter_item);
scat_req_sz = sizeof(*s_req) + scat_list_sz;
 
if (!virt_scat)


-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Extended file stat functions [ver #2]

[Jan Kara]

  Hello,

On Wed 30-06-10 02:16:56, David Howells wrote:
> Implement a pair of new system calls to provide extended and further 
> extensible
> stat functions.
> 
> The third of the associated patches provides these new system calls:
> 
>   struct xstat_dev {
>   unsigned intmajor;
>   unsigned intminor;
>   };
> 
>   struct xstat_time {
>   unsigned long long  tv_sec;
>   unsigned long long  tv_nsec;
>   };
> 
>   struct xstat {
>   unsigned intstruct_version;
>   #define XSTAT_STRUCT_VERSION0
>   unsigned intst_mode;
>   unsigned intst_nlink;
>   unsigned intst_uid;
>   unsigned intst_gid;
>   unsigned intst_blksize;
>   struct xstat_devst_rdev;
>   struct xstat_devst_dev;
>   unsigned long long  st_ino;
>   unsigned long long  st_size;
>   struct xstat_time   st_atime;
>   struct xstat_time   st_mtime;
>   struct xstat_time   st_ctime;
>   struct xstat_time   st_btime;
>   unsigned long long  st_blocks;
  When we are doing this, can we please also change 'st_blocks' to
'st_bytes'? We track space usage in kernel in bytes for a long time so it
would be nice to propagate it to userspace via stat instead of a special
ioctl (at least quotacheck(8) needs to know the exact value).

Honza
  
>   unsigned long long  st_gen;
>   unsigned long long  st_data_version;
>   unsigned long long  query_flags;
>   #define XSTAT_QUERY_SIZE0x0001ULL
>   #define XSTAT_QUERY_NLINK   0x0002ULL
>   #define XSTAT_QUERY_AMC_TIMES   0x0004ULL
>   #define XSTAT_QUERY_CREATION_TIME   0x0008ULL
>   #define XSTAT_QUERY_BLOCKS  0x0010ULL
>   #define XSTAT_QUERY_INODE_GENERATION0x0020ULL
>   #define XSTAT_QUERY_DATA_VERSION0x0040ULL
>   #define XSTAT_QUERY__ORDINARY_SET   0x0017ULL
>   #define XSTAT_QUERY__GET_ANYWAY 0x007fULL
>   #define XSTAT_QUERY__DEFINED_SET0x007fULL
>   unsigned long long  extra_results[0];
>   };
> 
>   ssize_t ret = xstat(int dfd,
>   const char *filename,
>   unsigned atflag,
>   struct xstat *buffer,
>   size_t buflen);
> 
>   ssize_t ret = fxstat(int fd,
>struct xstat *buffer,
>size_t buflen);
> 
> which are more fully documented in that patch's description.
> 
> The bonuses of these new stat functions are:
> 
>  (1) The fields in the xstat struct are cleaned up.  There are no split or
>  duplicated fields.
> 
>  (2) Some extra information is made available (file creation time, inode
>  generation number and data version number) where provided by the
>  underlying filesystem.
> 
>  These are implemented here for Ext4 and AFS, but could also be provided
>  for CIFS, NTFS and BtrFS and probably others.
> 
>  (3) The structure is versioned and extensible, meaning that further new 
> system
>  calls shouldn't be required.
> 
> Note that no lstat() equivalent is required as that can be implemented through
> xstat() with atflag == 0.
> 
> 
> The first patch makes const a bunch of system call userspace string/buffer
> arguments.  I can then make sys_xstat()'s filename pointer const too (though
> the entire first patch is not required for that).
> 
> The second patch makes the AFS filesystem use i_generation for the vnode ID
> uniquifier rather than i_version, and assigns i_version to hold the AFS data
> version number, making them more logical for when I want to get at them from
> afs_getattr().
> 
> There's a test program attached to the description for patch 3.  It can be run
> as follows:
> 
>   [root@andromeda ~]# /tmp/xstat 
> /afs/archive/linuxdev/fedora9/i386/repodata/
>   xstat(/afs/archive/linuxdev/fedora9/i386/repodata/) = 152
>   sv=0 qf=77 cr=0.0 iv=7a5 dv=5
> Size: 2048Blocks: 0  IO Block: 4096directory
>   Device: 00:15   Inode: 83  Links: 2
>   Access: (0755/drwxr-xr-x)  Uid: 75338   Gid: 0
>   Access: 2008-11-05 20:00:12.0+
>   Modify: 2008-11-05 20:00:12.0+
>   Change: 2008-11-05 20:00:12.0+
>   Inode version: 7a5h
>   Data version: 5h
> 
> 
> Things that need consideration:
> 
>  (1) Is it worth retaining the ability to arbitrarily add extra bits onto the
>  end of the stat buffer?  And what's the best way to do this?
> 

Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()

[Yuanhan Liu]

On Mon, Nov 25, 2013 at 03:57:40PM +0200, Boaz Harrosh wrote:
> On 11/25/2013 03:25 PM, Yuanhan Liu wrote:
> > 
> > Hi Boaz,
> > 
> > We are running an 0day kernel testing system. We will test all developers'
> > tree we tracked in our system automatically. And obviously, linux-open-osd
> > is in that list.
> > 
> > This system can't tell whether a branch is experimental unless
> > - You put one extra line of "Dont-Auto-Build" to the head commit log.
> > 
> > - the branch name contains "experimental", say exofs_ioctl-experimental
> > 
> > If both items aren't convenient to you, you can ask us to remove your
> > tree from that list. Then you will never get report like this from us.
> > However, you may lose a chance to find build, boot and performance bug
> > automatically for you ;)
> > 
> > --yliu
> > 
> 
> 
> Ha OK very cool. I will remember to put -experimental on the branch name
> this is fine I will do it ASAP.
> 
> Thanks so much. Do you have some web based info on the build system?

Sorry, nope.

> Do you have a place I can see test results and tests summery?

If you like, I can add you into the build-notify list. Once the build
finished, you might get an email like following:

--yliu


From: kbuild test robot 
To: Yuanhan Liu 
Subject: [yuanhan:branch] a828a375f9fcc422c8d2613d774d031fa8a02a97 BUILD SUCCESS

git://bee.sh.intel.com/git/yliu/linux.git  branch
a828a375f9fcc422c8d2613d774d031fa8a02a97  branch: commit summary

elapsed time: 262m

configs tested: 189

arm   allnoconfig
arm   almodconfig
arm at91_dt_defconfig
arm   imx_v6_v7_defconfig
arm  marzen_defconfig
arm   omap2plus_defconfig
arm  prima2_defconfig
arm s3c2410_defconfig
arm   spear13xx_defconfig
arm   tegra_defconfig
avr32  atngw100_defconfig
avr32 atstk1006_defconfig
frv defconfig
m68k  amiga_defconfig
m68k   m5475evb_defconfig
m68k  multi_defconfig
microblaze  mmu_defconfig
microblazenommu_defconfig
mn10300 asb2364_defconfig
openriscor1ksim_defconfig
tile tilegx_defconfig
um  defconfig
x86_64 acpi-redef
x86_64 randconfig-a0-1105
x86_64 randconfig-a1-1105
x86_64 randconfig-a2-1105
x86_64 randconfig-a3-1105
x86_64 randconfig-a4-1105
x86_64 randconfig-a5-1105
i386   randconfig-c0-1105
i386   randconfig-c1-1105
i386   randconfig-c2-1105
i386   randconfig-c3-1105
i386   randconfig-c4-1105
i386   randconfig-c5-1105
i386   randconfig-c6-1105
i386   randconfig-c7-1105
i386   randconfig-c8-1105
i386   randconfig-c9-1105
x86_64 randconfig-c0-1105
x86_64 randconfig-c1-1105
x86_64 randconfig-c2-1105
x86_64 randconfig-c3-1105
x86_64 randconfig-c4-1105
x86_64 randconfig-c5-1105
x86_64 randconfig-c6-1105
x86_64 randconfig-c7-1105
x86_64 randconfig-c8-1105
x86_64 randconfig-c9-1105
ia64 alldefconfig
ia64 allmodconfig
ia64  allnoconfig
ia64defconfig
mips allmodconfig
mips  allnoconfig
mips  fuloong2e_defconfig
i386 randconfig-i000-1105
i386 randconfig-i001-1105
i386 randconfig-i002-1105
i386 randconfig-i003-1105
i386 randconfig-i004-1105
i386 randconfig-i005-1105
i386 randconfig-i006-1105
i386 randconfig-i007-1105
i386 randconfig-i008-1105
i386 randconfig-i009-1105
powerpc  chroma_defconfig
powerpc   corenet64_smp_defconfig
powerpcgamecube_defconfig
powerpc linkstation_defconfig
powerpc wii_defconfig
sparc   defconfig
sparc64  allmodconfig
sparc64   allnoconfig
sparc64 defconfig
x86_64   

Re: [PATCH 06/12] mtd: nand: davinci: adjust DT properties to MTD generic

[Grygorii Strashko]

On 11/26/2013 09:03 AM, Sekhar Nori wrote:
> On Monday 11 November 2013 10:31 PM, Khoronzhuk, Ivan wrote:
>> The properties davinci-ecc-mode, davinci-nand-use-bbt, davinci-nand-buswidth
>> are MTD generic. Correct names for them are: nand-ecc-mode, 
>> nand-on-flash-bbt,
>> nand-bus-width accordingly. So rename them in dts and documentation.
>>
>> Signed-off-by: Ivan Khoronzhuk 
>> ---
>>   .../devicetree/bindings/mtd/davinci-nand.txt   |   25 
>> 
>>   drivers/mtd/nand/davinci_nand.c|   11 ++---
>>   2 files changed, 28 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt 
>> b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
>> index d2a3fc0..befaa5b 100644
>> --- a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
>> @@ -37,7 +37,7 @@ Recommended properties :
>>   - ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask
>>  addresses for given chipselect.
>>
>> -- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode
>> +- nand-ecc-mode:   operation mode of the NAND ecc mode. ECC mode
>>  valid values for davinci driver:
>>  - "none"
>>  - "soft"
>> @@ -45,10 +45,25 @@ Recommended properties :
>>
>>   - ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
>>
>> -- ti,davinci-nand-buswidth:buswidth 8 or 16.
> 
> Shouldn't we keep the documentation for existing bindings while just
> marking them as deprecated?

I haven't found any requirements about this in doc. 
It's done in both way in other drivers - some keep properties in bindings
documentation and some are not.

Regards,
-grygorii

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] doc: fix generation of device-drivers

[Andy Whitcroft]

Acked-by: Andy Whitcroft 

-apw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Kishon Vijay Abraham I]

Hi,

On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
> Add a binding that describes the Broadcom Kona USB2 PHY found
> on the BCM281xx family of SoCs.
> 
> Signed-off-by: Matt Porter 
> ---
>  .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt | 15 
> +++
>  1 file changed, 15 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt 
> b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
> new file mode 100644
> index 000..3dc8b3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt

you should name this bcm-phy. Then you can add binding info of all (future) PHY
IP from broadcom here.

other than that this looks fine..
Acked-by: Kishon Vijay Abraham I 

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] gpio: introduce GPIO_DAVINCI kconfig option

[Prabhakar Lad]

On Thu, Nov 21, 2013 at 9:04 PM, Grygorii Strashko
 wrote:
> The compatible to Davinci GPIO HW block is used by other TI SoCs, like
> Keystone, where GPIO support is declared as optional.
>
> Hence, introduce GPIO_DAVINCI Kconfig option which will allow to enable
> Davinci GPIO driver for Keystone SoCs when needed. At same time, kept
> Davinci GPIO driver enabled for Davinci SoCs by default.
>
> Signed-off-by: Grygorii Strashko 

Acked-by: Lad, Prabhakar 

Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/9] usb: gadget: s3c-hsotg: get phy bus width from phy subsystem

[Kishon Vijay Abraham I]

Hi,

On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
> Adds support for querying the phy bus width from the generic phy
> subsystem. Configure UTMI bus width in GUSBCFG based on this value.
> 
> Signed-off-by: Matt Porter 
> ---
>  drivers/usb/gadget/s3c-hsotg.c | 14 +-
>  drivers/usb/gadget/s3c-hsotg.h |  1 +
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
> index 8dfe33f..be41585 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -144,6 +144,7 @@ struct s3c_hsotg_ep {
>   * @regs: The memory area mapped for accessing registers.
>   * @irq: The IRQ number we are using
>   * @supplies: Definition of USB power supplies
> + * @phyif: PHY interface width
>   * @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
>   * @num_of_eps: Number of available EPs (excluding EP0)
>   * @debug_root: root directrory for debugfs.
> @@ -171,6 +172,7 @@ struct s3c_hsotg {
>  
>   struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
>  
> + u32 phyif;
>   unsigned intdedicated_fifos:1;
>   unsigned char   num_of_eps;
>  
> @@ -2276,7 +2278,7 @@ static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg)
>*/
>  
>   /* set the PLL on, remove the HNP/SRP and set the PHY */
> - writel(GUSBCFG_PHYIf16 | GUSBCFG_TOutCal(7) |
> + writel(hsotg->phyif | GUSBCFG_TOutCal(7) |
>  (0x5 << 10), hsotg->regs + GUSBCFG);
>  
>   s3c_hsotg_init_fifo(hsotg);
> @@ -3622,6 +3624,16 @@ static int s3c_hsotg_probe(struct platform_device 
> *pdev)
>   goto err_supplies;
>   }
>  
> + /* Set default UTMI width */
> + hsotg->phyif = GUSBCFG_PHYIf16;
> +
> + /*
> +  * If using the generic PHY framework, check if the PHY bus
> +  * width is 8-bit and set the phyif appropriately.
> +  */
> + if (hsotg->phy && (phy_get_bus_width(phy) == 8))

what if the phy has error value here?

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [BUG] 3.13-rc1 kernel crash when enable all tracepoints

[Masami Hiramatsu]

(2013/11/26 17:57), Masami Hiramatsu wrote:
> (2013/11/26 16:20), Jovi Zhangwei wrote:
>> I'm not sure this relate with ftrace:function event, from the
>> crash log, it seems more like caused by lock events.
>>
>> Now I only enable lock events (lockdep compiled in my box), below
>> two commands both can crash system.
> 
> That is not the lockdep, but the lockstat. :)
> 
>>
>> #echo 1 > /sys/kernel/debug/tracing/events/lock/lock_acquire/enable
>> or.
>> #echo 1 > /sys/kernel/debug/tracing/events/lock/lock_release/enable
>>
>> According to the log, it seems like a recursion tracing bug.
>>
>> register lock event -> jump_label_update -> text_poke_bp ->
>> on_each_cpu -> local_apic_timer_interrupt -> ktime_get_update_offsets
>> -> lock_release
> 
> OK, the problem is in the lock_acquire/release events.

Hm, it seems that the bug is caused because lock->name is NULL in
ftrace_raw_event_lock(_acquire). To allocate a buffer on ring_buffer,
ftrace_raw_event_##call tries to measure the length of lock->name
but it causes a memory access violation in ftrace_get_offsets_##call
because lock->name is NULL. :(

I could fix this by checking lock->name in include/trace/events/lock.h

e.g.
TP_STRUCT__entry(
__field(unsigned int, flags)
__string(name, lock->name ?: "NULL")
__field(void *, lockdep_addr)
),

TP_fast_assign(
__entry->flags = (trylock ? 1 : 0) | (read ? 2 : 0);
__assign_str(name, lock->name ?: "NULL");
__entry->lockdep_addr = lock;
),

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] gpio: davinci: get rid of DAVINCI_N_GPIO

[Prabhakar Lad]

On Thu, Nov 21, 2013 at 9:04 PM, Grygorii Strashko
 wrote:
> Since Davinci GPIO driver is moved to support gpiolib it has to use
> ARCH_NR_GPIOS (can be configured using CONFIG_ARCH_NR_GPIO Kconfig
> option) configuration instead of any mach/platform specific options.
>
> Hence, replace private DAVINCI_N_GPIO with common ARCH_NR_GPIOS. This is
> safe because default value for ARCH_NR_GPIOS=256 and maximum number of
> supported GPIOs for Davinci is DAVINCI_N_GPIO=144.
>
> More over, this is one of steps to re-use Davinci GPIO driver by other
> mach/platform.
>
> Signed-off-by: Grygorii Strashko 

Acked-by: Lad, Prabhakar 

Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/9] usb: gadget: s3c-hsotg: use generic phy_init()/phy_exit() support

[Kishon Vijay Abraham I]

Hi,

On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
> If a generic phy is present, call phy_init()/phy_exit(). This supports
> generic phys that must be soft reset before power on.
> 
> Signed-off-by: Matt Porter 
> ---
>  drivers/usb/gadget/s3c-hsotg.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
> index da3879b..8dfe33f 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -3622,6 +3622,9 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
>   goto err_supplies;
>   }
>  
> + if (hsotg->phy)

IS_ERR? If your phy_get fails *phy* will have a error value..

> + phy_init(hsotg->phy);
> +
>   /* usb phy enable */
>   s3c_hsotg_phy_enable(hsotg);
>  
> @@ -3715,6 +3718,8 @@ static int s3c_hsotg_remove(struct platform_device 
> *pdev)
>   }
>  
>   s3c_hsotg_phy_disable(hsotg);
> + if (hsotg->phy)

same here.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] mm: compaction: reset cached scanner pfn's before reading them

[Mel Gorman]

On Mon, Nov 25, 2013 at 03:26:07PM +0100, Vlastimil Babka wrote:
> Compaction caches pfn's for its migrate and free scanners to avoid scanning
> the whole zone each time. In compact_zone(), the cached values are read to
> set up initial values for the scanners. There are several situations when
> these cached pfn's are reset to the first and last pfn of the zone,
> respectively. One of these situations is when a compaction has been deferred
> for a zone and is now being restarted during a direct compaction, which is 
> also
> done in compact_zone().
> 
> However, compact_zone() currently reads the cached pfn's *before* resetting
> them. This means the reset doesn't affect the compaction that performs it, and
> with good chance also subsequent compactions, as update_pageblock_skip() is
> likely to be called and update the cached pfn's to those being processed.
> Another chance for a successful reset is when a direct compaction detects that
> migration and free scanners meet (which has its own problems addressed by
> another patch) and sets update_pageblock_skip flag which kswapd uses to do the
> reset because it goes to sleep.
> 
> This is clearly a bug that results in non-deterministic behavior, so this 
> patch
> moves the cached pfn reset to be performed *before* the values are read.
> 
> Cc: Mel Gorman 
> Cc: Rik van Riel 
> Signed-off-by: Vlastimil Babka 

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 6/9] mm + fs: store shadow entries in page cache

[Peter Zijlstra]

On Tue, Nov 26, 2013 at 10:17:16AM +1100, Dave Chinner wrote:
> void truncate_inode_pages_final(struct address_space *mapping)
> {
>   mapping_set_exiting(mapping);
>   if (inode->i_data.nrpages || inode->i_data.nrshadows) {
>   /*
>* spinlock barrier to ensure all modifications are
>* complete before we do the final truncate
>*/
>   spin_lock_irq(>tree_lock);
>   spin_unlock_irq(>tree_lock);

spin_unlock_wait() ?

Its cheaper, but prone to starvation; its typically useful when you're
waiting for the last owner to go away and know there won't be any new
ones around.

>   truncate_inode_pages_range(mapping, 0, (loff_t)-1);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/9] staging: dwc2: update DT binding to add generic clock/phy properties

[Kishon Vijay Abraham I]

On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
> dwc2/s3c-hsotg require a single clock to be specified and optionally
> a generic phy. On the s3c-hsotg driver old style USB phy support is
> present as a fallback so the generic phy properties are optional.
> 
> Signed-off-by: Matt Porter 
> ---
>  Documentation/devicetree/bindings/staging/dwc2.txt | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt 
> b/Documentation/devicetree/bindings/staging/dwc2.txt
> index 1a1b7cf..b8b42b6 100644
> --- a/Documentation/devicetree/bindings/staging/dwc2.txt
> +++ b/Documentation/devicetree/bindings/staging/dwc2.txt
> @@ -5,6 +5,12 @@ Required properties:
>  - compatible : "snps,dwc2"
>  - reg : Should contain 1 register range (address and length)
>  - interrupts : Should contain 1 interrupt
> +- clocks: clock provider specifier
> +- clock-names: shall be "otg"
> +- phys: phy provider specifier
> +- phy-names: shall be "device"

lets mention in the Documentation too that the phy properties are optional.
apart from that..
Acked-by: Kishon Vijay Abraham I 
> +Refer to clk/clock-bindings.txt for generic clock consumer properties
> +Refer to phy/phy-bindings.txt for generic phy consumer properties
>  
>  Example:
>  
> @@ -12,4 +18,8 @@ Example:
>  compatible = "ralink,rt3050-usb, snps,dwc2";
>  reg = <0x101c 4>;
>  interrupts = <18>;
> + clocks = <_otg_ahb_clk>;
> + clock-names = "otg";
> + phys = <>;
> + phy-names = "device";
>  };
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] perf record: Use perf_data_file__write for output file

[Jiri Olsa]

On Mon, Nov 25, 2013 at 04:31:37PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 22, 2013 at 03:24:27PM +0100, Jiri Olsa escreveu:
> > Changing the file output code to use the newly
> > added perf_data_file__write interface.
> 
> So I like renaming write_output() to perf_record__write(), but then
> you're lumping together this change and the other, which is to make
> write_output, now renamed to perf_record__write() to use perf_data_file.
> 
> Can you please split it like that?
> 

ok, will do

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf tools: Add perf_data_file__write interface

[Jiri Olsa]

On Mon, Nov 25, 2013 at 04:29:09PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 22, 2013 at 03:24:26PM +0100, Jiri Olsa escreveu:
> >  }
> > +
> > +ssize_t perf_data_file__write(struct perf_data_file *file,
> > + void *buf, size_t size)
> > +{
> > +   ssize_t total = size;
> > +
> > +   while (size) {
> > +   ssize_t ret = write(file->fd, buf, size);
> > +
> > +   if (ret < 0) {
> > +   pr_err("failed to write perf data, error: %m\n");
> > +   return -1;
> > +   }
> > +
> > +   size -= ret;
> > +   buf  += ret;
> > +   }
> > +
> > +   return total;
> 
> So this is the functional equivalent of "readn", so please move it to
> just after "readn" and make this just a simple wrapper.

ok, thanks

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls

[Kishon Vijay Abraham I]

Hi,

On Monday 25 November 2013 11:45 PM, Matt Porter wrote:
> This adds a pair of APIs that allows the generic PHY subsystem to
> provide information on the PHY bus width. The PHY provider driver may
> use phy_set_bus_width() to set the bus width that the PHY supports.
> The controller driver may then use phy_get_bus_width() to fetch the
> PHY bus width in order to properly configure the controller.
> 
> Signed-off-by: Matt Porter 
> ---
>  include/linux/phy/phy.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 6d72269..6ca6c61 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -46,6 +46,7 @@ struct phy_ops {
>   * @mutex: mutex to protect phy_ops
>   * @init_count: used to protect when the PHY is used by multiple consumers
>   * @power_count: used to protect when the PHY is used by multiple consumers
> + * @bus_width: used to specify data width of the PHY bus
>   */
>  struct phy {
>   struct device   dev;
> @@ -55,6 +56,7 @@ struct phy {
>   struct mutexmutex;
>   int init_count;
>   int power_count;
> + int bus_width;

the bus_width can be part of the attrs struct which you initially proposed.
Soon there will be requests for other attributes being added (e.g., speed).
>  };
>  
>  /**
> @@ -127,6 +129,14 @@ int phy_init(struct phy *phy);
>  int phy_exit(struct phy *phy);
>  int phy_power_on(struct phy *phy);
>  int phy_power_off(struct phy *phy);
> +static inline int phy_get_bus_width(struct phy *phy)
> +{
> + return phy->bus_width;
> +}
> +static inline void phy_set_bus_width(struct phy *phy, int bus_width)

u32 bus_width?
> +{
> + phy->bus_width = bus_width;
> +}
>  struct phy *phy_get(struct device *dev, const char *string);
>  struct phy *devm_phy_get(struct device *dev, const char *string);
>  void phy_put(struct phy *phy);
> @@ -199,6 +209,16 @@ static inline int phy_power_off(struct phy *phy)
>   return -ENOSYS;
>  }
>  
> +static inline int phy_get_bus_width(struct phy *phy)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline void phy_set_bus_width(struct phy *phy, bus_width)

er.. has this been compile tested?

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 07/15] KVM: MMU: introduce nulls desc

[Gleb Natapov]

On Tue, Nov 26, 2013 at 11:10:19AM +0800, Xiao Guangrong wrote:
> On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> >> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> >>  wrote:
> >>>
> >>> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti  wrote:
> >>
> >> 
> >>
> >> I'm not really following, but note that parent_pte predates EPT (and
> >> the use of rcu in kvm), so all the complexity that is the result of
> >> trying to pack as many list entries into a cache line can be dropped.
> >> Most setups now would have exactly one list entry, which is handled
> >> specially antyway.
> >>
> >> Alternatively, the trick of storing multiple entries in one list entry
> >> can be moved to generic code, it may be useful to others.
> > 
> > Yes, can the lockless list walking code be transformed into generic
> > single-linked list walking? So the correctness can be verified
> > independently, and KVM becomes a simple user of that interface.
> 
> I'am afraid the signle-entry list is not so good as we expected. In my
> experience, there're too many entries on rmap, more than 300 sometimes.
> (consider a case that a lib shared by all processes).
> 
This is without EPT though and non EPT HW is not performance king
anyway. Nested EPT uses shadow paging too, but VMs hardly share any
pages. With KSM they may though.

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V3 01/10] perf: New conditional branch filter criteria in branch stack sampling

[Anshuman Khandual]

On 11/26/2013 11:36 AM, m...@ellerman.id.au wrote:
> Ideally your commit subject would contain a verb, preferably in the present
> tense.
> 
> I think simply "perf: Add PERF_SAMPLE_BRANCH_COND" would be clearer.


Sure, will change it.

> 
> On Wed, 2013-16-10 at 06:56:48 UTC, Anshuman Khandual wrote:
>> POWER8 PMU based BHRB supports filtering for conditional branches.
>> This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which
>> will extend the existing perf ABI. Other architectures can provide
>> this functionality with either HW filtering support (if present) or
>> with SW filtering of instructions.
>>
>> Signed-off-by: Anshuman Khandual 
>> Reviewed-by: Stephane Eranian 
>> ---
>>  include/uapi/linux/perf_event.h | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/perf_event.h 
>> b/include/uapi/linux/perf_event.h
>> index 0b1df41..5da52b6 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -160,8 +160,9 @@ enum perf_branch_sample_type {
>>  PERF_SAMPLE_BRANCH_ABORT_TX = 1U << 7, /* transaction aborts */
>>  PERF_SAMPLE_BRANCH_IN_TX= 1U << 8, /* in transaction */
>>  PERF_SAMPLE_BRANCH_NO_TX= 1U << 9, /* not in transaction */
>> +PERF_SAMPLE_BRANCH_COND = 1U << 10, /* conditional branches */
>>  
>> -PERF_SAMPLE_BRANCH_MAX  = 1U << 10, /* non-ABI */
>> +PERF_SAMPLE_BRANCH_MAX  = 1U << 11, /* non-ABI */
>>  };
> 
> This no longer applies against Linus' tree, you'll need to rebase it.

Okay

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/