Re: [rtc-linux] [PATCH] rtc: recycle id when unloading a rtc driver

[Alexander Holler]

Am 19.12.2012 08:45, schrieb Andrew Morton:

On Wed, 19 Dec 2012 08:37:07 +0100 Alexander Holler  
wrote:


Am 19.12.2012 01:46, schrieb Andrew Morton:

On Thu,  2 Aug 2012 16:53:25 -0700
Vincent Palatin  wrote:


When calling rtc_device_unregister, we are not freeing the id used by the
driver.
So when doing a unload/load cycle for a RTC driver (e.g. rmmod rtc_cmos
&& modprobe rtc_cmos), its id is incremented by one. As a consequence,
we no longer have neither an rtc0 driver nor a /proc/driver/rtc (as it
only exists for the first driver).

Signed-off-by: Vincent Palatin 
---
   drivers/rtc/class.c |1 +
   1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index dc4c274..37b1d82 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -238,6 +238,7 @@ void rtc_device_unregister(struct rtc_device *rtc)
rtc_proc_del_device(rtc);
device_unregister(>dev);
rtc->ops = NULL;
+   ida_simple_remove(_ida, rtc->id);
mutex_unlock(>ops_lock);
put_device(>dev);
}


Now I think about it, this shouldn't have been needed?

That put_device() should call rtc_device_release(), which does the
ida_simple_remove().  Isn't that working?


It is, see the mini-thread, patch and my comment here:

https://lkml.org/lkml/2012/12/6/152

Maybe it would be better to move the ida_simple_remove from the
rtc_device_release to rt_device_unregister as I've hinted in the above
comment. That would make it easier to spot the ida_simple_remove().


I'm all confused.

Lothar's patch simply reverts Vincent's patch.  And that appears to be
the correct thing to so, as the ida_simple_remove() in
rtc_device_release() should be sufficient.

But apparently that doesn't work, because Vincent was seeing the RTC
ID's increment rather than getting reused.

Is it the case that rtc_device_release() is not being called sometimes?
If so, under what circumstances?


Maybe something (sysfs or whatever) still has a reference to it. Vincent 
should check that.


But I'm sure the ID will be recycled with that put_device() in 
unregister because I've got the same warning as Lothar did when 
(porperly) removing an RTC (with kernel 3.7).


Regards,

Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] mmc: sdio: Removing the unnecessary runtime_get/put in sdio_bus_remove()

[Ohad Ben-Cohen]

On Wed, Dec 19, 2012 at 4:51 PM, Chuansheng Liu
 wrote:
>
> The runtime_get_sync() is called during sdio_bus_probe(), then the device
> will be kept in active runtime state

Unless, of course, the driver powered it down.

>, so not neccessary to call
> runtime_get_sync/put_noidle() again in sdio_bus_remove().

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

Re: [rtc-linux] [PATCH] rtc: recycle id when unloading a rtc driver

[Andrew Morton]

On Wed, 19 Dec 2012 08:37:07 +0100 Alexander Holler  
wrote:

> Am 19.12.2012 01:46, schrieb Andrew Morton:
> > On Thu,  2 Aug 2012 16:53:25 -0700
> > Vincent Palatin  wrote:
> >
> >> When calling rtc_device_unregister, we are not freeing the id used by the
> >> driver.
> >> So when doing a unload/load cycle for a RTC driver (e.g. rmmod rtc_cmos
> >> && modprobe rtc_cmos), its id is incremented by one. As a consequence,
> >> we no longer have neither an rtc0 driver nor a /proc/driver/rtc (as it
> >> only exists for the first driver).
> >>
> >> Signed-off-by: Vincent Palatin 
> >> ---
> >>   drivers/rtc/class.c |1 +
> >>   1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
> >> index dc4c274..37b1d82 100644
> >> --- a/drivers/rtc/class.c
> >> +++ b/drivers/rtc/class.c
> >> @@ -238,6 +238,7 @@ void rtc_device_unregister(struct rtc_device *rtc)
> >>rtc_proc_del_device(rtc);
> >>device_unregister(>dev);
> >>rtc->ops = NULL;
> >> +  ida_simple_remove(_ida, rtc->id);
> >>mutex_unlock(>ops_lock);
> >>put_device(>dev);
> >>}
> >
> > Now I think about it, this shouldn't have been needed?
> >
> > That put_device() should call rtc_device_release(), which does the
> > ida_simple_remove().  Isn't that working?
> 
> It is, see the mini-thread, patch and my comment here:
> 
> https://lkml.org/lkml/2012/12/6/152
> 
> Maybe it would be better to move the ida_simple_remove from the 
> rtc_device_release to rt_device_unregister as I've hinted in the above 
> comment. That would make it easier to spot the ida_simple_remove().

I'm all confused.

Lothar's patch simply reverts Vincent's patch.  And that appears to be
the correct thing to so, as the ida_simple_remove() in
rtc_device_release() should be sufficient.  

But apparently that doesn't work, because Vincent was seeing the RTC
ID's increment rather than getting reused.

Is it the case that rtc_device_release() is not being called sometimes?
If so, under what circumstances?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 7/7] mm: reduce rmap overhead for ex-KSM page copies created on swap faults

[Simon Jeons]

On Mon, 2012-12-17 at 13:12 -0500, Johannes Weiner wrote:
> When ex-KSM pages are faulted from swap cache, the fault handler is
> not capable of re-establishing anon_vma-spanning KSM pages.  In this
> case, a copy of the page is created instead, just like during a COW
> break.
> 
> These freshly made copies are known to be exclusive to the faulting
> VMA and there is no reason to go look for this page in parent and
> sibling processes during rmap operations.
> 
> Use page_add_new_anon_rmap() for these copies.  This also puts them on
> the proper LRU lists and marks them SwapBacked, so we can get rid of
> doing this ad-hoc in the KSM copy code.

Is it just a code cleanup instead of reduce rmap overhead?

> 
> Signed-off-by: Johannes Weiner 
> Reviewed-by: Rik van Riel 
> ---
>  mm/ksm.c| 6 --
>  mm/memory.c | 5 -
>  2 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 382d930..7275c74 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -1590,13 +1590,7 @@ struct page *ksm_does_need_to_copy(struct page *page,
>  
>   SetPageDirty(new_page);
>   __SetPageUptodate(new_page);
> - SetPageSwapBacked(new_page);
>   __set_page_locked(new_page);
> -
> - if (!mlocked_vma_newpage(vma, new_page))
> - lru_cache_add_lru(new_page, LRU_ACTIVE_ANON);
> - else
> - add_page_to_unevictable_list(new_page);
>   }
>  
>   return new_page;
> diff --git a/mm/memory.c b/mm/memory.c
> index db2e9e7..7e17eb0 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3020,7 +3020,10 @@ static int do_swap_page(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>   }
>   flush_icache_page(vma, page);
>   set_pte_at(mm, address, page_table, pte);
> - do_page_add_anon_rmap(page, vma, address, exclusive);
> + if (swapcache) /* ksm created a completely new copy */
> + page_add_new_anon_rmap(page, vma, address);
> + else
> + do_page_add_anon_rmap(page, vma, address, exclusive);
>   /* It's better to call commit-charge after rmap is established */
>   mem_cgroup_commit_charge_swapin(page, ptr);
>  


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

Re: [rtc-linux] [PATCH] rtc: recycle id when unloading a rtc driver

[Alexander Holler]

Am 19.12.2012 01:46, schrieb Andrew Morton:

On Thu,  2 Aug 2012 16:53:25 -0700
Vincent Palatin  wrote:


When calling rtc_device_unregister, we are not freeing the id used by the
driver.
So when doing a unload/load cycle for a RTC driver (e.g. rmmod rtc_cmos
&& modprobe rtc_cmos), its id is incremented by one. As a consequence,
we no longer have neither an rtc0 driver nor a /proc/driver/rtc (as it
only exists for the first driver).

Signed-off-by: Vincent Palatin 
---
  drivers/rtc/class.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index dc4c274..37b1d82 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -238,6 +238,7 @@ void rtc_device_unregister(struct rtc_device *rtc)
rtc_proc_del_device(rtc);
device_unregister(>dev);
rtc->ops = NULL;
+   ida_simple_remove(_ida, rtc->id);
mutex_unlock(>ops_lock);
put_device(>dev);
}


Now I think about it, this shouldn't have been needed?

That put_device() should call rtc_device_release(), which does the
ida_simple_remove().  Isn't that working?


It is, see the mini-thread, patch and my comment here:

https://lkml.org/lkml/2012/12/6/152

Maybe it would be better to move the ida_simple_remove from the 
rtc_device_release to rt_device_unregister as I've hinted in the above 
comment. That would make it easier to spot the ida_simple_remove().


Regards,

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

Re: Strange results of DIV_ROUND_CLOSEST

[Juergen Beisert]

Hi Guenter,

Guenter Roeck wrote:
> On Tue, Dec 18, 2012 at 10:04:56PM +0100, Juergen Beisert wrote:
> > Guenter Roeck wrote:
> > > On Tue, Dec 18, 2012 at 04:03:41PM +0100, Juergen Beisert wrote:
> > > > commit 263a523d18bca306016d75f5c8d5c57c37fe52fb changes the code of
> > > > DIV_ROUND_CLOSEST in include/linux/kernel.h to fix a compile time
> > > > warning.
> > > >
> > > > But now feeding in a zero into this macro results into 4198403.
> > > > Tested with gcc 4.4.3 and 4.7.2, on arch x86 and ARM.
> > > >
> > > > I can reproduce this behaviour, when my ADC delivers a '0' value in
> > > > the driver drivers/hwmon/s3c-hwmon.c in function s3c_hwmon_ch_show()
> > > > with a current 3.7.1 kernel. The value is correct again, when the ADC
> > > > delivers at least a '1'.
> > > >
> > > > Any ideas how to fix it correctly?
> > >
> > > Odd one. I ran the macro through a large number of values and divisors
> > > as well as various optimization options, with different compilers, and
> > > always get correct results.
> > >
> > > What are your compile options, and what are the channel multiplier and
> > > dividers set to ?
> >
> > Refer the lines 177 to 182 in drivers/hwmon/s3c-hwmon.c. "cfg->mult" is
> > '3300' in my case, and "cfg->div" is '1023'. And whenever
> > s3c_hwmon_read_ch() returns '0' line 184 returns '4198403' since
> > Linux-3.6. checked with my gcc-4.6.2 cross compiler for Linux-3.6 and
> > with gcc-4.6.2 for Linux-3.7.
> >
> > I did a quick test with this macro on my host with gcc-4.4.3 and a simple
> > userland program and surprise, surprise:
> >
> > result = DIV_ROUND_CLOSEST(0, 1023);
> >
> > works as expected (result is 0), but
> >
> > int x = 0;
> > unsigned y = 1023;
> > result = DIV_ROUND_CLOSEST(x, y);
> >
> > gives me result = 4198403!
>
> Can you test the following patch ?
>
> From d4a639c6ace7cb0de247f59c38abac72d671f135 Mon Sep 17 00:00:00 2001
> From: Guenter Roeck 
> Date: Tue, 18 Dec 2012 15:48:44 -0800
> Subject: [PATCH] linux/kernel.h: Fix DIV_ROUND_CLOSEST for unsigned
> divisors
>
> Commit 263a523 fixes a warning seen with W=1 due to change in
> DIV_ROUND_CLOSEST. Unfortunately, the C compiler converts divide operations
> with unsigned divisors to unsigned, even if the dividend is signed and
> negative (-10 / 5U = 858993457). As a result, DIV_ROUND_CLOSEST(0, 2U)
> and similar operations now return bad data.
>
> Fix by checking for the divisor variable type when deciding which operation
> to perform. This fixes DIV_ROUND_CLOSEST(0, 2U), but still returns bad data
> for negative dividends divided by unsigned divisors. Mark the latter case
> as unsupported.
>
> Reported-by: Juergen Beisert 
> Signed-off-by: Guenter Roeck 
> ---
> An alternative would be to always convert divisors to signed:
>   int __d = (int)divisor; \
> Not sure if that would be better.
>
>  include/linux/kernel.h |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index d97ed58..45726dc 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -77,13 +77,15 @@
>
>  /*
>   * Divide positive or negative dividend by positive divisor and round
> - * to closest integer. Result is undefined for negative divisors.
> + * to closest integer. Result is undefined for negative divisors and
> + * for negative dividends if the divisor variable type is unsigned.
>   */
>  #define DIV_ROUND_CLOSEST(x, divisor)(   \
>  {\
>   typeof(x) __x = x;  \
>   typeof(divisor) __d = divisor;  \
> - (((typeof(x))-1) > 0 || (__x) > 0) ?\
> + (((typeof(x))-1) > 0 || \
> +  ((typeof(divisor))-1) > 0 || (__x) > 0) ?  \
>   (((__x) + ((__d) / 2)) / (__d)) :   \
>   (((__x) - ((__d) / 2)) / (__d));\
>  }\

You can add my "tested-by: Juergen Beisert ". With this 
patch at least my S3C2440 ADC driver reports correct values again. Keep in 
mind it should also be fixed in the stable 3.6/3.7 kernel.

Regards,
Juergen
-- 
Pengutronix e.K.  | Juergen Beisert |
Linux Solutions for Science and Industry  | http://www.pengutronix.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/

[PATCH 5/5] perf: Create a sysfs entry for Power event format

[Sukadev Bhattiprolu]

Create a sysfs entry, '/sys/bus/event_source/devices/cpu/format/event'
which describes the format of a POWER cpu.

The format of the event is the same for all POWER cpus at least in
(Power6, Power7), so bulk of this change is common in the code common
to POWER cpus.

This code is based on corresponding code in x86.

Changelog[v2]: [Jiri Osla] Use PMU_FORMAT_ATTR() rather than duplicating it.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/include/asm/perf_event_server.h |6 ++
 arch/powerpc/perf/core-book3s.c  |   12 
 arch/powerpc/perf/power7-pmu.c   |1 +
 3 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/perf_event_server.h 
b/arch/powerpc/include/asm/perf_event_server.h
index 4315bc9..f8f7240 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -136,3 +136,9 @@ extern ssize_t power_events_sysfs_show(struct device *dev,
 
 #definePOWER_EVENT_ATTR(_name, _id)EVENT_ATTR(PM_##_name, _id, _p)
 #definePOWER_EVENT_PTR(_id)EVENT_PTR(_id, _p)
+
+/*
+ * Format of a perf event is the same on all POWER cpus. Declare a
+ * common sysfs attribute group that individual POWER cpus can share.
+ */
+extern struct attribute_group power_pmu_format_group;
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index fa476d5..4ae044b 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1315,6 +1315,18 @@ ssize_t power_events_sysfs_show(struct device *dev,
return sprintf(page, "event=0x%02llx\n", pmu_attr->id);
 }
 
+PMU_FORMAT_ATTR(event, "config:0-20");
+
+static struct attribute *power_pmu_format_attr[] = {
+   _attr_event.attr,
+   NULL,
+};
+
+struct attribute_group power_pmu_format_group = {
+   .name = "format",
+   .attrs = power_pmu_format_attr,
+};
+
 struct pmu power_pmu = {
.pmu_enable = power_pmu_enable,
.pmu_disable= power_pmu_disable,
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 5627940..5fb3c9b 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -410,6 +410,7 @@ static struct attribute_group power7_pmu_events_group = {
 };
 
 static const struct attribute_group *power7_pmu_attr_groups[] = {
+   _pmu_format_group,
_pmu_events_group,
NULL,
 };
-- 
1.7.1

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

[PATCH 4/5] perf/POWER7: Make some POWER7 events available in sysfs

[Sukadev Bhattiprolu]

Make some POWER7-specific perf events available in sysfs.

$ /bin/ls -1 /sys/bus/event_source/devices/cpu/events/
branch-instructions
branch-misses
cache-misses
cache-references
cpu-cycles
instructions
PM_BRU_FIN
PM_BRU_MPRED
PM_CMPLU_STALL
PM_CYC
PM_GCT_NOSLOT_CYC
PM_INST_CMPL
PM_LD_MISS_L1
PM_LD_REF_L1
stalled-cycles-backend
stalled-cycles-frontend

where the 'PM_*' events are POWER specific and the others are the
generic events.

This will enable users to specify these events with their symbolic
names rather than with their raw code.

perf stat -e 'cpu/PM_CYC' ...

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/include/asm/perf_event_server.h |2 ++
 arch/powerpc/perf/power7-pmu.c   |   18 ++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/perf_event_server.h 
b/arch/powerpc/include/asm/perf_event_server.h
index 20ca90f..4315bc9 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -134,3 +134,5 @@ extern ssize_t power_events_sysfs_show(struct device *dev,
 #defineGENERIC_EVENT_ATTR(_name, _id)  EVENT_ATTR(_name, _id, _g)
 #defineGENERIC_EVENT_PTR(_id)  EVENT_PTR(_id, _g)
 
+#definePOWER_EVENT_ATTR(_name, _id)EVENT_ATTR(PM_##_name, _id, _p)
+#definePOWER_EVENT_PTR(_id)EVENT_PTR(_id, _p)
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index ae5d757..5627940 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -373,6 +373,15 @@ GENERIC_EVENT_ATTR(cache-misses,   LD_MISS_L1);
 GENERIC_EVENT_ATTR(branch-instructions,BRU_FIN);
 GENERIC_EVENT_ATTR(branch-misses,  BRU_MPRED);
 
+POWER_EVENT_ATTR(CYC,  CYC);
+POWER_EVENT_ATTR(GCT_NOSLOT_CYC,   GCT_NOSLOT_CYC);
+POWER_EVENT_ATTR(CMPLU_STALL,  CMPLU_STALL);
+POWER_EVENT_ATTR(INST_CMPL,INST_CMPL);
+POWER_EVENT_ATTR(LD_REF_L1,LD_REF_L1);
+POWER_EVENT_ATTR(LD_MISS_L1,   LD_MISS_L1);
+POWER_EVENT_ATTR(BRU_FIN,  BRU_FIN)
+POWER_EVENT_ATTR(BRU_MPRED,BRU_MPRED);
+
 static struct attribute *power7_events_attr[] = {
GENERIC_EVENT_PTR(CYC),
GENERIC_EVENT_PTR(GCT_NOSLOT_CYC),
@@ -382,6 +391,15 @@ static struct attribute *power7_events_attr[] = {
GENERIC_EVENT_PTR(LD_MISS_L1),
GENERIC_EVENT_PTR(BRU_FIN),
GENERIC_EVENT_PTR(BRU_MPRED),
+
+   POWER_EVENT_PTR(CYC),
+   POWER_EVENT_PTR(GCT_NOSLOT_CYC),
+   POWER_EVENT_PTR(CMPLU_STALL),
+   POWER_EVENT_PTR(INST_CMPL),
+   POWER_EVENT_PTR(LD_REF_L1),
+   POWER_EVENT_PTR(LD_MISS_L1),
+   POWER_EVENT_PTR(BRU_FIN),
+   POWER_EVENT_PTR(BRU_MPRED),
NULL
 };
 
-- 
1.7.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] perf/POWER7: Make generic event translations available in sysfs

[Sukadev Bhattiprolu]

[PATCH 3/5] perf/POWER7: Make generic event translations available in sysfs

Make the generic perf events in POWER7 available via sysfs.

$ ls /sys/bus/event_source/devices/cpu/events
branch-instructions
branch-misses
cache-misses
cache-references
cpu-cycles
instructions
stalled-cycles-backend
stalled-cycles-frontend

$ cat /sys/bus/event_source/devices/cpu/events/cache-misses
event=0x400f0

This patch is based on commits that implement this functionality on x86.
Eg:
commit a47473939db20e3961b200eb00acf5fcf084d755
Author: Jiri Olsa 
Date:   Wed Oct 10 14:53:11 2012 +0200

perf/x86: Make hardware event translations available in sysfs

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/include/asm/perf_event_server.h |   25 +++
 arch/powerpc/perf/core-book3s.c  |   12 +
 arch/powerpc/perf/power7-pmu.c   |   34 ++
 3 files changed, 71 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/perf_event_server.h 
b/arch/powerpc/include/asm/perf_event_server.h
index 9710be3..20ca90f 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 
 #define MAX_HWEVENTS   8
 #define MAX_EVENT_ALTERNATIVES 8
@@ -35,6 +36,7 @@ struct power_pmu {
void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
int (*limited_pmc_event)(u64 event_id);
u32 flags;
+   const struct attribute_group**attr_groups;
int n_generic;
int *generic_events;
int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
@@ -109,3 +111,26 @@ extern unsigned long perf_instruction_pointer(struct 
pt_regs *regs);
  * If an event_id is not subject to the constraint expressed by a particular
  * field, then it will have 0 in both the mask and value for that field.
  */
+
+extern ssize_t power_events_sysfs_show(struct device *dev,
+   struct device_attribute *attr, char *page);
+
+/*
+ * EVENT_VAR() is same as PMU_EVENT_VAR with a suffix.
+ *
+ * Having a suffix allows us to have aliases in sysfs - eg: the generic
+ * event 'cpu-cycles' can have two entries in sysfs: 'cpu-cycles' and
+ * 'PM_CYC' where the latter is the name by which the event is known in
+ * POWER CPU specification.
+ */
+#defineEVENT_VAR(_id, _suffix) event_attr_##_id##_suffix
+#defineEVENT_PTR(_id, _suffix) PMU_EVENT_PTR(EVENT_VAR(_id, 
_suffix))
+#defineEVENT_ID(_id)   PME_PM_##_id
+
+#defineEVENT_ATTR(_name, _id, _suffix) 
\
+   PMU_EVENT_ATTR(_name, EVENT_VAR(_id, _suffix), EVENT_ID(_id),   \
+   power_events_sysfs_show)
+
+#defineGENERIC_EVENT_ATTR(_name, _id)  EVENT_ATTR(_name, _id, _g)
+#defineGENERIC_EVENT_PTR(_id)  EVENT_PTR(_id, _g)
+
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index aa2465e..fa476d5 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1305,6 +1305,16 @@ static int power_pmu_event_idx(struct perf_event *event)
return event->hw.idx;
 }
 
+ssize_t power_events_sysfs_show(struct device *dev,
+   struct device_attribute *attr, char *page)
+{
+   struct perf_pmu_events_attr *pmu_attr;
+
+   pmu_attr = container_of(attr, struct perf_pmu_events_attr, attr);
+
+   return sprintf(page, "event=0x%02llx\n", pmu_attr->id);
+}
+
 struct pmu power_pmu = {
.pmu_enable = power_pmu_enable,
.pmu_disable= power_pmu_disable,
@@ -1537,6 +1547,8 @@ int __cpuinit register_power_pmu(struct power_pmu *pmu)
pr_info("%s performance monitor hardware support registered\n",
pmu->name);
 
+   power_pmu.attr_groups = ppmu->attr_groups;
+
 #ifdef MSR_HV
/*
 * Use FCHV to ignore kernel events if MSR.HV is set.
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 44e70d2..ae5d757 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -363,6 +363,39 @@ static int 
power7_cache_events[C(MAX)][C(OP_MAX)][C(RESULT_MAX)] = {
},
 };
 
+
+GENERIC_EVENT_ATTR(cpu-cycles, CYC);
+GENERIC_EVENT_ATTR(stalled-cycles-frontend,GCT_NOSLOT_CYC);
+GENERIC_EVENT_ATTR(stalled-cycles-backend, CMPLU_STALL);
+GENERIC_EVENT_ATTR(instructions,   INST_CMPL);
+GENERIC_EVENT_ATTR(cache-references,   LD_REF_L1);
+GENERIC_EVENT_ATTR(cache-misses,   LD_MISS_L1);
+GENERIC_EVENT_ATTR(branch-instructions,BRU_FIN);
+GENERIC_EVENT_ATTR(branch-misses,  BRU_MPRED);
+
+static struct attribute 

[PATCH 2/5] perf: Make EVENT_ATTR and EVENT_PTR global

[Sukadev Bhattiprolu]

Rename EVENT_ATTR() and EVENT_PTR() PMU_EVENT_ATTR() and PMU_EVENT_PTR().
Make them global so they are available to all architectures.

Further to allow architectures flexibility, have PMU_EVENT_PTR() pass in the
variable name as a parameter.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/x86/kernel/cpu/perf_event.c |   17 +
 include/linux/perf_event.h   |   13 +
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 4428fd1..24bc505 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1316,11 +1316,6 @@ static struct attribute_group x86_pmu_format_group = {
.attrs = NULL,
 };
 
-struct perf_pmu_events_attr {
-   struct device_attribute attr;
-   u64 id;
-};
-
 /*
  * Remove all undefined events (x86_pmu.event_map(id) == 0)
  * out of events_attr attributes.
@@ -1351,14 +1346,12 @@ static ssize_t events_sysfs_show(struct device *dev, 
struct device_attribute *at
return x86_pmu.events_sysfs_show(page, config);
 }
 
-#define EVENT_VAR(_id)  event_attr_##_id
-#define EVENT_PTR(_id) _attr_##_id.attr.attr
+#define EVENT_VAR(_id) event_attr_##_id
+#define EVENT_ID(_id)  PERF_COUNT_HW_##_id
+#define EVENT_PTR(_id) PMU_EVENT_PTR(EVENT_VAR(_id))
 
-#define EVENT_ATTR(_name, _id) \
-static struct perf_pmu_events_attr EVENT_VAR(_id) = {  \
-   .attr = __ATTR(_name, 0444, events_sysfs_show, NULL),   \
-   .id   =  PERF_COUNT_HW_##_id,   \
-};
+#define EVENT_ATTR(_name, _id) \
+   PMU_EVENT_ATTR(_name, EVENT_VAR(_id), EVENT_ID(_id), events_sysfs_show)
 
 EVENT_ATTR(cpu-cycles, CPU_CYCLES  );
 EVENT_ATTR(instructions,   INSTRUCTIONS);
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 6bfb2fa..31692cb 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -817,6 +817,19 @@ do {   
\
 } while (0)
 
 
+struct perf_pmu_events_attr {
+   struct device_attribute attr;
+   u64 id;
+};
+
+#define PMU_EVENT_PTR(_var)&_var.attr.attr
+
+#define PMU_EVENT_ATTR(_name, _var, _id, _show)
\
+static struct perf_pmu_events_attr _var = {\
+   .attr = __ATTR(_name, 0444, _show, NULL),   \
+   .id   =  _id,   \
+};
+
 #define PMU_FORMAT_ATTR(_name, _format)
\
 static ssize_t \
 _name##_show(struct device *dev,   \
-- 
1.7.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: zram: fix invalid memory references during disk write

[Nitin Gupta]

On 12/18/2012 07:49 PM, Greg KH wrote:
> On Tue, Dec 18, 2012 at 01:12:05PM -0800, Nitin Gupta wrote:
>> On Tue, Dec 11, 2012 at 10:27 AM, Greg KH  wrote:
>>> On Thu, Nov 29, 2012 at 10:45:09PM -0800, Nitin Gupta wrote:
 Fixes a bug introduced by commit c8f2f0db1 ("zram: Fix handling
 of incompressible pages") which caused invalid memory references
 during disk write. Invalid references could occur in two cases:
  - Incoming data expands on compression: In this case, reference was
 made to kunmap()'ed bio page.
  - Partial (non PAGE_SIZE) write with incompressible data: In this
 case, reference was made to a kfree()'ed buffer.

 Fixes bug 50081:
 https://bugzilla.kernel.org/show_bug.cgi?id=50081

 Upstream commit ID: c8f2f0d: zram: Fix handling of incompressible pages
 Apply to versions: 3.6.5, 3.6.6, 3.6.7, 3.6.8

 Cc:  # staging-next: 37b51fd: zram: factor-out
   # zram_decompress_page() function
 Signed-off-by: Nitin Gupta 
 Reported-by: Mihail Kasadjikov 
 Reported-by: Tomas M 
 Reviewed-by: Minchan Kim 
 ---
  drivers/staging/zram/zram_drv.c |   39 
 ---
  1 file changed, 24 insertions(+), 15 deletions(-)
>>>
>>> This patch fails to apply to 3.6.10:
>>>
>>> patching file drivers/staging/zram/zram_drv.c
>>> Hunk #1 succeeded at 282 (offset 17 lines).
>>> Hunk #2 FAILED at 286.
>>> Hunk #3 succeeded at 319 (offset 17 lines).
>>> Hunk #4 succeeded at 340 (offset 17 lines).
>>> Hunk #5 succeeded at 353 (offset 17 lines).
>>> Hunk #6 succeeded at 368 (offset 17 lines).
>>> Hunk #7 succeeded at 385 (offset 17 lines).
>>> 1 out of 7 hunks FAILED -- saving rejects to file 
>>> drivers/staging/zram/zram_drv.c.rej
>>>
>>> Please redo this patch and resend it if you wish for it to be applied to
>>> the 3.6-stable tree.
>>>
>>>
>>
>> Please apply this patch to stable tree asap.
> 
> 3.6 is now end-of-life, there will not be any more releases for that
> kernel series anymore, sorry.
> 

Then please apply to 3.7.

Nitin


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf/Power7: Use macros to identify perf events

[Sukadev Bhattiprolu]

Define and use macros to identify perf events codes This would make it
easier and more readable when these event codes need to be used in more
than one place.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/power7-pmu.c |   28 
 1 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 441af08..44e70d2 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -51,6 +51,18 @@
 #define MMCR1_PMCSEL_MSK   0xff
 
 /*
+ * Power7 event codes.
+ */
+#definePME_PM_CYC  0x1e
+#definePME_PM_GCT_NOSLOT_CYC   0x100f8
+#definePME_PM_CMPLU_STALL  0x4000a
+#definePME_PM_INST_CMPL0x2
+#definePME_PM_LD_REF_L10xc880
+#definePME_PM_LD_MISS_L1   0x400f0
+#definePME_PM_BRU_FIN  0x10068
+#definePME_PM_BRU_MPRED0x400f6
+
+/*
  * Layout of constraint bits:
  * 554433221100
  * 3210987654321098765432109876543210987654321098765432109876543210
@@ -296,14 +308,14 @@ static void power7_disable_pmc(unsigned int pmc, unsigned 
long mmcr[])
 }
 
 static int power7_generic_events[] = {
-   [PERF_COUNT_HW_CPU_CYCLES] = 0x1e,
-   [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x100f8, /* GCT_NOSLOT_CYC */
-   [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x4000a,  /* CMPLU_STALL */
-   [PERF_COUNT_HW_INSTRUCTIONS] = 2,
-   [PERF_COUNT_HW_CACHE_REFERENCES] = 0xc880,  /* LD_REF_L1_LSU*/
-   [PERF_COUNT_HW_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1   */
-   [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x10068,  /* BRU_FIN  */
-   [PERF_COUNT_HW_BRANCH_MISSES] = 0x400f6,/* BR_MPRED */
+   [PERF_COUNT_HW_CPU_CYCLES] =PME_PM_CYC,
+   [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] =   PME_PM_GCT_NOSLOT_CYC,
+   [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] =PME_PM_CMPLU_STALL,
+   [PERF_COUNT_HW_INSTRUCTIONS] =  PME_PM_INST_CMPL,
+   [PERF_COUNT_HW_CACHE_REFERENCES] =  PME_PM_LD_REF_L1,
+   [PERF_COUNT_HW_CACHE_MISSES] =  PME_PM_LD_MISS_L1,
+   [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] =   PME_PM_BRU_FIN,
+   [PERF_COUNT_HW_BRANCH_MISSES] = PME_PM_BRU_MPRED,
 };
 
 #define C(x)   PERF_COUNT_HW_CACHE_##x
-- 
1.7.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/

SPARSE_IRQ

[Paul Thompson]

Hi;

Perhaps Im being an idiot, but it looks to me like the
menu-item for SPARSE_IRQ (under General setup -> IRQ subsystem)
depends solely on MAY_HAVE_SPARSE_IRQ, but I only see *one* user
for that in the kernel now, the SuperH arch (arch/sh/Kconfig). It
looks like everyone else explicitly sets SPARSE_IRQ. However the
menu-items description implies it is a more generic option...
It seems like this menu item used to appear, in a forced
on state, then this condition made it disapear, leaving a blank
IRQ subsystem menu for me. I was trying to work around that, but
now, I am not sure exactly what is supposed to be going on here...

Paul

(from kernel/irq/Kconfig)
config SPARSE_IRQ
bool "Support sparse irq numbering" if MAY_HAVE_SPARSE_IRQ
---help---

  Sparse irq numbering is useful for distro kernels that want
  to define a high CONFIG_NR_CPUS value but still want to have
  low kernel memory footprint on smaller machines.

  ( Sparse irqs can also be beneficial on NUMA boxes, as they spread
out the interrupt descriptors in a more NUMA-friendly way. )

  If you don't know what to do here, say N.

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

Re: [PATCH] staging: iio: cleanup ring_sw.c

[Joe Perches]

On Wed, 2012-12-19 at 07:13 +, Jonathan Cameron wrote:
> Err. This whole file is going away in the coming cycle anyway so I am
> not going to take cleanup patches for it.

That's the best kind of staging cleanup.


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

[PATCH v3 -tip 4/4] tracing: add description of snapshot to Documentation/trace/ftrace.txt

[Hiraku Toyooka]

This patch adds snapshot description in ftrace documentation.
This description includes what the snapshot is and how to use it.

Signed-off-by: Hiraku Toyooka 
Cc: Steven Rostedt 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Rob Landley 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/trace/ftrace.txt |   83 
 1 file changed, 83 insertions(+)

diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index 6f51fed..53d6a3c 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -1842,6 +1842,89 @@ an error.
  # cat buffer_size_kb
 85
 
+Snapshot
+
+CONFIG_TRACER_SNAPSHOT makes a generic snapshot feature
+available to all non latency tracers. (Latency tracers which
+record max latency, such as "irqsoff" or "wakeup", can't use
+this feature, since those are already using the snapshot
+mechanism internally.)
+
+Snapshot preserves a current trace buffer at a particular point
+in time without stopping tracing. Ftrace swaps the current
+buffer with a spare buffer, and tracing continues in the new
+current (=previous spare) buffer.
+
+The following debugfs files in "tracing" are related to this
+feature:
+
+  snapshot:
+
+   This is used to take a snapshot and to read the output
+   of the snapshot. Echo 1 into this file to allocate a
+   spare buffer and to take a snapshot (swap), then read
+   the snapshot from this file in the same format as
+   "trace" (described above in the section "The File
+   System"). Both reads snapshot and tracing are executable
+   in parallel. When the spare buffer is allocated, echoing
+   0 frees it, and echoing else (positive) values clear the
+   snapshot contents.
+   More details are shown in the table below.
+
+   status\input  | 0  | 1  |else|
+   --++++
+   not allocated |(do nothing)| alloc+swap |   EINVAL   |
+   --++++
+   allocated |free|swap|   clear|
+   --++++
+
+Here is an example of using the snapshot feature.
+
+ # echo 1 > events/sched/enable
+ # echo 1 > snapshot
+ # cat snapshot
+# tracer: nop
+#
+# entries-in-buffer/entries-written: 71/71   #P:8
+#
+#  _-=> irqs-off
+# / _=> need-resched
+#| / _---=> hardirq/softirq
+#|| / _--=> preempt-depth
+#||| / delay
+#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
+#  | |   |      | |
+  -0 [005] d...  2440.603828: sched_switch: 
prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=R ==> 
next_comm=snapshot-test-2 next_pid=2242 next_prio=120
+   sleep-2242  [005] d...  2440.603846: sched_switch: 
prev_comm=snapshot-test-2 prev_pid=2242 prev_prio=120 prev_state=R ==> 
next_comm=kworker/5:1 next_pid=60 next_prio=120
+[...]
+  -0 [002] d...  2440.707230: sched_switch: 
prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> 
next_comm=snapshot-test-2 next_pid=2229 next_prio=120
+
+ # cat trace
+# tracer: nop
+#
+# entries-in-buffer/entries-written: 77/77   #P:8
+#
+#  _-=> irqs-off
+# / _=> need-resched
+#| / _---=> hardirq/softirq
+#|| / _--=> preempt-depth
+#||| / delay
+#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
+#  | |   |      | |
+  -0 [007] d...  2440.707395: sched_switch: 
prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> 
next_comm=snapshot-test-2 next_pid=2243 next_prio=120
+ snapshot-test-2-2229  [002] d...  2440.707438: sched_switch: 
prev_comm=snapshot-test-2 prev_pid=2229 prev_prio=120 prev_state=S ==> 
next_comm=swapper/2 next_pid=0 next_prio=120
+[...]
+
+
+If you try to use this snapshot feature when current tracer is
+one of the latency tracers, you will get the following results.
+
+ # echo wakeup > current_tracer
+ # echo 1 > snapshot
+bash: echo: write error: Device or resource busy
+ # cat snapshot
+cat: snapshot: Device or resource busy
+
 ---
 
 More details can be found in the source code, in the

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

[PATCH v3 -tip 2/4] tracing: replace static old_tracer with strcmp

[Hiraku Toyooka]

Currently, read functions for trace buffer use static "old_tracer"
for detecting changes of current tracer. This is because we can
assume that these functions are used from only one file ("trace").

But we are adding snapshot feature for ftrace, then those functions
are called from two files. So we remove all static "old_tracer", and
replace those with string comparison between current and previous
tracers.

Signed-off-by: Hiraku Toyooka 
Cc: Steven Rostedt 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
---
 kernel/trace/trace.c |   18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index a8ce008..8d05a44 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1948,7 +1948,6 @@ void tracing_iter_reset(struct trace_iterator *iter, int 
cpu)
 static void *s_start(struct seq_file *m, loff_t *pos)
 {
struct trace_iterator *iter = m->private;
-   static struct tracer *old_tracer;
int cpu_file = iter->cpu_file;
void *p = NULL;
loff_t l = 0;
@@ -1956,10 +1955,9 @@ static void *s_start(struct seq_file *m, loff_t *pos)
 
/* copy the tracer to avoid using a global lock all around */
mutex_lock(_types_lock);
-   if (unlikely(old_tracer != current_trace && current_trace)) {
-   old_tracer = current_trace;
+   if (unlikely(current_trace &&
+strcmp(iter->trace->name, current_trace->name) != 0))
*iter->trace = *current_trace;
-   }
mutex_unlock(_types_lock);
 
atomic_inc(_record_cmdline_disabled);
@@ -3481,7 +3479,6 @@ tracing_read_pipe(struct file *filp, char __user *ubuf,
  size_t cnt, loff_t *ppos)
 {
struct trace_iterator *iter = filp->private_data;
-   static struct tracer *old_tracer;
ssize_t sret;
 
/* return any leftover data */
@@ -3493,10 +3490,9 @@ tracing_read_pipe(struct file *filp, char __user *ubuf,
 
/* copy the tracer to avoid using a global lock all around */
mutex_lock(_types_lock);
-   if (unlikely(old_tracer != current_trace && current_trace)) {
-   old_tracer = current_trace;
+   if (unlikely(current_trace &&
+strcmp(iter->trace->name, current_trace->name) != 0))
*iter->trace = *current_trace;
-   }
mutex_unlock(_types_lock);
 
/*
@@ -3652,7 +3648,6 @@ static ssize_t tracing_splice_read_pipe(struct file *filp,
.ops= _pipe_buf_ops,
.spd_release= tracing_spd_release_pipe,
};
-   static struct tracer *old_tracer;
ssize_t ret;
size_t rem;
unsigned int i;
@@ -3662,10 +3657,9 @@ static ssize_t tracing_splice_read_pipe(struct file 
*filp,
 
/* copy the tracer to avoid using a global lock all around */
mutex_lock(_types_lock);
-   if (unlikely(old_tracer != current_trace && current_trace)) {
-   old_tracer = current_trace;
+   if (unlikely(current_trace &&
+strcmp(iter->trace->name, current_trace->name) != 0))
*iter->trace = *current_trace;
-   }
mutex_unlock(_types_lock);
 
mutex_lock(>mutex);

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

[PATCH v3 -tip 3/4] tracing: make a snapshot feature available from userspace

[Hiraku Toyooka]

Ftrace has a snapshot feature available from kernel space and
latency tracers (e.g. irqsoff) are using it. This patch enables
user applictions to take a snapshot via debugfs.

Add "snapshot" debugfs file in "tracing" directory.

  snapshot:
This is used to take a snapshot and to read the output of the
snapshot.

 # echo 1 > snapshot

This will allocate the spare buffer for snapshot (if it is
not allocated), and take a snapshot.

 # cat snapshot

This will show contents of the snapshot.

 # echo 0 > snapshot

This will free the snapshot if it is allocated.

Any other positive values will clear the snapshot contents if
the snapshot is allocated, or return EINVAL if it is not allocated.

Signed-off-by: Hiraku Toyooka 
Cc: Steven Rostedt 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: David Sharp 
Cc: linux-kernel@vger.kernel.org
---
 include/linux/ftrace_event.h |3 +
 kernel/trace/Kconfig |   10 +++
 kernel/trace/trace.c |  134 ++
 kernel/trace/trace.h |1 
 4 files changed, 136 insertions(+), 12 deletions(-)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index a3d4895..9bebadd 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -84,6 +84,9 @@ struct trace_iterator {
longidx;
 
cpumask_var_t   started;
+
+   /* it's true when current open file is snapshot */
+   boolsnapshot;
 };
 
 enum trace_iter_flags {
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 5d89335..82a8ff5 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -250,6 +250,16 @@ config FTRACE_SYSCALLS
help
  Basic tracer to catch the syscall entry and exit events.
 
+config TRACER_SNAPSHOT
+   bool "Create a snapshot trace buffer"
+   select TRACER_MAX_TRACE
+   help
+ Allow tracing users to take snapshot of the current buffer using the
+ ftrace interface, e.g.:
+
+ echo 1 > /sys/kernel/debug/tracing/snapshot
+ cat snapshot
+
 config TRACE_BRANCH_PROFILING
bool
select GENERIC_TRACER
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8d05a44..0e5abce 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -709,7 +709,7 @@ update_max_tr(struct trace_array *tr, struct task_struct 
*tsk, int cpu)
return;
 
WARN_ON_ONCE(!irqs_disabled());
-   if (!current_trace->use_max_tr) {
+   if (!current_trace->allocated_snapshot) {
WARN_ON_ONCE(1);
return;
}
@@ -739,7 +739,7 @@ update_max_tr_single(struct trace_array *tr, struct 
task_struct *tsk, int cpu)
return;
 
WARN_ON_ONCE(!irqs_disabled());
-   if (!current_trace->use_max_tr) {
+   if (!current_trace->allocated_snapshot) {
WARN_ON_ONCE(1);
return;
}
@@ -1960,7 +1960,11 @@ static void *s_start(struct seq_file *m, loff_t *pos)
*iter->trace = *current_trace;
mutex_unlock(_types_lock);
 
-   atomic_inc(_record_cmdline_disabled);
+   if (iter->snapshot && iter->trace->use_max_tr)
+   return ERR_PTR(-EBUSY);
+
+   if (!iter->snapshot)
+   atomic_inc(_record_cmdline_disabled);
 
if (*pos != iter->pos) {
iter->ent = NULL;
@@ -1999,7 +2003,11 @@ static void s_stop(struct seq_file *m, void *p)
 {
struct trace_iterator *iter = m->private;
 
-   atomic_dec(_record_cmdline_disabled);
+   if (iter->snapshot && iter->trace->use_max_tr)
+   return;
+
+   if (!iter->snapshot)
+   atomic_dec(_record_cmdline_disabled);
trace_access_unlock(iter->cpu_file);
trace_event_read_unlock();
 }
@@ -2434,7 +2442,7 @@ static const struct seq_operations tracer_seq_ops = {
 };
 
 static struct trace_iterator *
-__tracing_open(struct inode *inode, struct file *file)
+__tracing_open(struct inode *inode, struct file *file, bool snapshot)
 {
long cpu_file = (long) inode->i_private;
struct trace_iterator *iter;
@@ -2467,10 +2475,11 @@ __tracing_open(struct inode *inode, struct file *file)
if (!zalloc_cpumask_var(>started, GFP_KERNEL))
goto fail;
 
-   if (current_trace && current_trace->print_max)
+   if ((current_trace && current_trace->print_max) || snapshot)
iter->tr = _tr;
else
iter->tr = _trace;
+   iter->snapshot = snapshot;
iter->pos = -1;
mutex_init(>mutex);
iter->cpu_file = cpu_file;
@@ -2487,8 +2496,9 @@ __tracing_open(struct inode *inode, struct file *file)
if (trace_clocks[trace_clock_id].in_ns)
iter->iter_flags |= TRACE_FILE_TIME_IN_NS;
 
-   /* stop the trace while dumping */
-   tracing_stop();
+   /* stop the trace 

[PATCH v3 -tip 1/4] tracing: add checks if tr->buffer is NULL in tracing_reset{_online_cpus}

[Hiraku Toyooka]

max_tr->buffer could be NULL in the tracing_reset{_online_cpus}. In this
case, a NULL pointer dereference happens, so we should return immediately
from these functions.

Signed-off-by: Hiraku Toyooka 
Cc: Steven Rostedt 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
---
 kernel/trace/trace.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index c705c7a..a8ce008 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -922,6 +922,9 @@ void tracing_reset(struct trace_array *tr, int cpu)
 {
struct ring_buffer *buffer = tr->buffer;
 
+   if (!buffer)
+   return;
+
ring_buffer_record_disable(buffer);
 
/* Make sure all commits have finished */
@@ -936,6 +939,9 @@ void tracing_reset_online_cpus(struct trace_array *tr)
struct ring_buffer *buffer = tr->buffer;
int cpu;
 
+   if (!buffer)
+   return;
+
ring_buffer_record_disable(buffer);
 
/* Make sure all commits have finished */

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

[PATCH v3 -tip 0/4] tracing: make a snapshot feature available from userspace

[Hiraku Toyooka]

Hi, Steven,

Thank you for your review.
I applied your review comments.

These patches depend on the next patch.

tracing: Add a resize function to make one buffer equivalent to another buffer
http://lkml.kernel.org/r/20121017025616.2627.91226.stgit@falsita

v2->v3:
 [1/4] tracing: add checks if tr->buffer is NULL in tracing_reset{_online_cpus}
- (new patch)
 [2/4] tracing: replace static old_tracer with strcmp
- (new patch)
 [3/4] tracing: make a snapshot feature available from userspace
- changed snapshot file I/F (removed "snapshot_allocate")
- changed CONFIG_TRACER_SNAPSHOT's location and description
- changed an integer flag of __tracing_open() to bool
- switched to use seq_read() directly for reading snapshot
 [4/4] tracing: add description of snapshot to Documentation/trace/ftrace.txt
- updated documentation of the snapshot

ToDo:
 - adding "trace_snapshot" kernel parameter to allocate spare buffer on boot. 

(v1: https://lkml.org/lkml/2012/10/2/67)
(v2: https://lkml.org/lkml/2012/10/16/585)

---

Hiraku Toyooka (4):
  tracing: add checks if tr->buffer is NULL in tracing_reset{_online_cpus}
  tracing: replace static old_tracer with strcmp
  tracing: make a snapshot feature available from userspace
  tracing: add description of snapshot to Documentation/trace/ftrace.txt


 Documentation/trace/ftrace.txt |   83 +
 include/linux/ftrace_event.h   |3 +
 kernel/trace/Kconfig   |   10 +++
 kernel/trace/trace.c   |  158 ++--
 kernel/trace/trace.h   |1 
 5 files changed, 231 insertions(+), 24 deletions(-)

-- 
Hiraku TOYOOKA
Linux Technology Center
Yokohama Research Laboratory
Hitachi Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: iio: cleanup ring_sw.c

[Joe Perches]

On Wed, 2012-12-19 at 09:42 +0300, Dan Carpenter wrote:
> On Wed, Dec 19, 2012 at 12:39:59AM +0100, Cong Ding wrote:
> > clean the checkpatch warnings in ring_sw.c. mostly are 80 characters per 
> > line
> > issue.
[]
> > diff --git a/drivers/staging/iio/ring_sw.c b/drivers/staging/iio/ring_sw.c
[]
> > @@ -77,7 +77,8 @@ static int iio_store_to_sw_ring(struct iio_sw_ring_buffer 
> > *ring,
> >  * as long as the read pointer is valid before this
> >  * passes it - guaranteed as set later in this function.
> >  */
> > -   ring->half_p = ring->data - 
> > ring->buf.length*ring->buf.bytes_per_datum/2;
> > +   ring->half_p = ring->data -
> > +   ring->buf.length*ring->buf.bytes_per_datum/2;
> 
> Please put spaces around the '*' and '/' characters.
>   ring->buf.length * ring->buf.bytes_per_datum / 2;

or maybe add a helper like ring_datum_size(ring):

size_t ring_datum_size(const struct iio_sw_ring_buffer *ring)
{
return ring->buf.length * ring->buf.bytes_per_datum;
}

so this becomes

ring->half_p = ring->data - ring_datum_size(ring) / 2;

> > @@ -112,8 +113,8 @@ static int iio_store_to_sw_ring(struct 
> > iio_sw_ring_buffer *ring,
> > else if (ring->write_p == ring->read_p) {
> > change_test_ptr = ring->read_p;
> > temp_ptr = change_test_ptr + ring->buf.bytes_per_datum;
> > -   if (temp_ptr
> > -   == ring->data + ring->buf.length*ring->buf.bytes_per_datum) 
> > {
> > +   if (temp_ptr == ring->data +
> > +   ring->buf.length*ring->buf.bytes_per_datum) {

> 
> This needs spaces as well.  It might look cleaner if you broke it
> up like this:
>   if (temp_ptr == ring->data + ring->buf.length *
>   ring->buf.bytes_per_datum) {

or
if (temp_ptr == ring->data + ring_datum_size(ring)) {

etc...

> > @@ -153,7 +155,8 @@ static int iio_read_first_n_sw_rb(struct iio_buffer *r,
> > if (n % ring->buf.bytes_per_datum) {
> > ret = -EINVAL;
> > printk(KERN_INFO "Ring buffer read request not whole number of"
> > -  "samples: Request bytes %zd, Current bytes per datum 
> > %d\n",
> > +  "samples: Request bytes %zd, Current bytes per"
> > +  "datum %d\n",
> 
> No space between "of" and "samples" and also "per" and "datum".
> 
> The warning here is that the print should be on one line instead of
> two.  But actually that is a decision for the maintainer.
> Checkpatch.pl is not the king of us, we do not have to do what it
> says.

Yup.

It is nicer though to coalesce formats so that it's easier to
grep for strings and substrings.

> > @@ -201,7 +205,8 @@ static int iio_read_first_n_sw_rb(struct iio_buffer *r,
> > if (initial_read_p + bytes_to_rip >= ring->data + buffer_size) {
> > max_copied = ring->data + buffer_size - initial_read_p;
> > memcpy(data, initial_read_p, max_copied);
> > -   memcpy(data + max_copied, ring->data, bytes_to_rip - 
> > max_copied);
> > +   memcpy(data + max_copied,
> > +   ring->data, bytes_to_rip - max_copied);
> 
> Line it up like this:
>   memcpy(data + max_copied, ring->data,
>  bytes_to_rip - max_copied);
> 
> 
> [tab][tab][space][space][space][space][space][space][space]bytes_

checkpatch --strict emits alignment messages

or not worry about 80 columns in this case.


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

Re: [PATCH 00/26] AIO performance improvements/cleanups, v2

[Kent Overstreet]

On Tue, Dec 18, 2012 at 11:16 AM, Kent Overstreet
 wrote:
> Or maybe just getting rid of the ringbuffer is that awesome. Gonna try
> and work on combining our optimizations so I can see what that looks
> like :)


Yes, yes it is. Combined our aio/dio patches and got 50% better
throughput than I'd seen before.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 'omap_pm_set_max_mpu_wakeup_lat'

[Bedia, Vaibhav]

On Wed, Dec 19, 2012 at 07:52:47, Fengguang Wu wrote:
> [add more CC]
> 
> On Wed, Dec 19, 2012 at 10:11:02AM +0800, Fengguang Wu wrote:
> > Hi Linus, Wolfram,
> > 
> > FYI, kernel build failed on
> > 
> > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux master
> > head:   752451f01c4567b506bf4343082682dbb8fb30dd
> > commit: 752451f01c4567b506bf4343082682dbb8fb30dd Merge branch 
> > 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux
> > date:   56 minutes ago
> > config: make ARCH=arm omap2plus_defconfig
> > 
> > All error/warnings:
> > 
> > arch/arm/mach-omap2/i2c.c: In function 
> > 'omap_pm_set_max_mpu_wakeup_lat_compat':
> > arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 
> > 'omap_pm_set_max_mpu_wakeup_lat' [-Werror=implicit-function-declaration]
> > cc1: some warnings being treated as errors
> > 
> > The root cause is, i2c.c (which is always compiled in 
> > arch/arm/mach-omap2/Makefile)
> > uses omap_pm_set_max_mpu_wakeup_lat() which is defined in omap-pm-noop.c 
> > (which
> > is compiled only on CONFIG_OMAP_PM_NOOP).

CONFIG_OMAP_PM_NOOP is defined. The build breakage is due to a missing header 
inclusion.
I just sent a patch for this [1]

There are still a couple of patches missing before omap2plus_defconfig compiles
https://patchwork.kernel.org/patch/1810481/
https://patchwork.kernel.org/patch/1810441/

I guess they are on the way from some other tree.

Regards,
Vaibhav

[1] http://marc.info/?l=linux-arm-kernel=135589966017628=2

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

Re: common clock framwork: clk_set_rate issue

[Chao Xie]

On Tue, Dec 18, 2012 at 3:47 PM, Sascha Hauer  wrote:
> On Tue, Dec 18, 2012 at 10:19:21AM +0800, Chao Xie wrote:
>> On Tue, Dec 18, 2012 at 4:19 AM, Sascha Hauer  wrote:
>> > On Thu, Dec 06, 2012 at 10:52:03AM +0800, Chao Xie wrote:
>> >> hi
>> >> When develop the clk drivers for SOCs based on common clock framework.
>> >> I met a issue.
>> >> For example there is a uart device, it's function clock comes from a
>> >> divider, and the divider's parent is a mux. It means
>> >>
>> >> MUX --> DIV --> UART
>> >>
>> >> As we know that UART can work at low baudrate for a terminal, while it
>> >> can also connect to GPS module which needs a high rate. So the MUX
>> >> will provide two clock source, a low clock rate and high clock rate.
>> >>
>> >> The MUX clk driver clk-mux.c does not implement a ->round_rate callbacks.
>> >> It means that when uart driver is used for a GPS and it want to change
>> >> it clock, the driver will call clk_set_rate(); clk_set_rate will loop
>> >> upward to DIV, and DIV will try to set its divider, and it need loop
>> >> upward to MUX.
>> >> In fact the current clk drivers have some issue.
>> >> MUX clk driver should provide the round_rate callback, it then can
>> >> provide a new_rate. It means that in clk_calc_subtree MUX can switch
>> >> the clock source.
>> >
>> > It's not that simple. The input clocks to a mux may not only differ in
>> > their rate but can also have other different properties, like for
>> > example one input may be always present whereas another input only runs
>> > when the CPU is in run mode.
>> >
>> > It may be a possibility to add a flag to the mux to explicitely
>> > allow reparenting on a rate change.
>> >
>> There is already a flag to do it.
>> CLK_SET_RATE_PARENT
>
> That flag has another meaning. It means that a clock is allowed to
> change the parents rate when a rate change is requested. What I meant
> is a flag that allows a mux to change its parent when a rate change is
> requested.
>
another flag can help it. what i mean is that i can clear the flag
CLK_SET_RATE_PARENT of MUX's children, so when clock changing will not
impact the MUX.

>> if the mux does not want to changes the input for clk_set_rate called
>> by its child, it can clear this flag.
>> The question is whether we need add the round_rate/recalc_rate for MUX
>> type of clock? Is there any special issue about it that why current
>> MUX implementation does not have these callbacks?
>
> They currently do not need these callbacks. When a clock does not have
> round_rate propagates up to the parent if CLK_SET_RATE_PARENT is set or
> it returns the parents rate if this flag is not set. The situation with
> set_rate is similar.
>
So it means that for a uart clock  that get its clock from
MUX --> DIV --> UART
when uart want to change its rate, the driver has to know the topology
of clock tree. It can not directly clk_set_rate(uart), because it only
change the DIV settings, and if we want to change the MUX input, we
have to invoke clk_set_parent(MUX). So the uart driver need to know
the clock tree topology, and it is not good for sharing a driver
between mutiple SOCs that has same UART controller IP.
That is what i am confused about.

> Sascha
>
> --
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: iio: cleanup ring_sw.c

[Dan Carpenter]

On Wed, Dec 19, 2012 at 12:39:59AM +0100, Cong Ding wrote:
> clean the checkpatch warnings in ring_sw.c. mostly are 80 characters per line
> issue.
> 
> Signed-off-by: Cong Ding 
> ---
>  drivers/staging/iio/ring_sw.c |   25 ++---
>  1 file changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/staging/iio/ring_sw.c b/drivers/staging/iio/ring_sw.c
> index 3a45f9a..4db1cc3 100644
> --- a/drivers/staging/iio/ring_sw.c
> +++ b/drivers/staging/iio/ring_sw.c
> @@ -77,7 +77,8 @@ static int iio_store_to_sw_ring(struct iio_sw_ring_buffer 
> *ring,
>* as long as the read pointer is valid before this
>* passes it - guaranteed as set later in this function.
>*/
> - ring->half_p = ring->data - 
> ring->buf.length*ring->buf.bytes_per_datum/2;
> + ring->half_p = ring->data -
> + ring->buf.length*ring->buf.bytes_per_datum/2;

Please put spaces around the '*' and '/' characters.
ring->buf.length * ring->buf.bytes_per_datum / 2;

>   }
>   /* Copy data to where ever the current write pointer says */
>   memcpy(ring->write_p, data, ring->buf.bytes_per_datum);
> @@ -112,8 +113,8 @@ static int iio_store_to_sw_ring(struct iio_sw_ring_buffer 
> *ring,
>   else if (ring->write_p == ring->read_p) {
>   change_test_ptr = ring->read_p;
>   temp_ptr = change_test_ptr + ring->buf.bytes_per_datum;
> - if (temp_ptr
> - == ring->data + ring->buf.length*ring->buf.bytes_per_datum) 
> {
> + if (temp_ptr == ring->data +
> + ring->buf.length*ring->buf.bytes_per_datum) {

This needs spaces as well.  It might look cleaner if you broke it
up like this:
if (temp_ptr == ring->data + ring->buf.length *
ring->buf.bytes_per_datum) {


>   temp_ptr = ring->data;
>   }
>   /* We are moving pointer on one because the ring is full.  Any
> @@ -127,7 +128,8 @@ static int iio_store_to_sw_ring(struct iio_sw_ring_buffer 
> *ring,
>* simultaneous read */
>   /* Also need to use loop count to ensure this only happens once */
>   ring->half_p += ring->buf.bytes_per_datum;
> - if (ring->half_p == ring->data + 
> ring->buf.length*ring->buf.bytes_per_datum)
> + if (ring->half_p == ring->data +
> + ring->buf.length*ring->buf.bytes_per_datum)

Same.

>   ring->half_p = ring->data;
>   if (ring->half_p == ring->read_p) {
>   ring->buf.stufftoread = true;
> @@ -153,7 +155,8 @@ static int iio_read_first_n_sw_rb(struct iio_buffer *r,
>   if (n % ring->buf.bytes_per_datum) {
>   ret = -EINVAL;
>   printk(KERN_INFO "Ring buffer read request not whole number of"
> -"samples: Request bytes %zd, Current bytes per datum 
> %d\n",
> +"samples: Request bytes %zd, Current bytes per"
> +"datum %d\n",

No space between "of" and "samples" and also "per" and "datum".

The warning here is that the print should be on one line instead of
two.  But actually that is a decision for the maintainer.
Checkpatch.pl is not the king of us, we do not have to do what it
says.

>  n, ring->buf.bytes_per_datum);
>   goto error_ret;
>   }
> @@ -193,7 +196,8 @@ static int iio_read_first_n_sw_rb(struct iio_buffer *r,
>   if (initial_write_p >= initial_read_p)
>   data_available = initial_write_p - initial_read_p;
>   else
> - data_available = buffer_size - (initial_read_p - 
> initial_write_p);
> + data_available = buffer_size -
> + (initial_read_p - initial_write_p);
>  
>   if (data_available < bytes_to_rip)
>   bytes_to_rip = data_available;
> @@ -201,7 +205,8 @@ static int iio_read_first_n_sw_rb(struct iio_buffer *r,
>   if (initial_read_p + bytes_to_rip >= ring->data + buffer_size) {
>   max_copied = ring->data + buffer_size - initial_read_p;
>   memcpy(data, initial_read_p, max_copied);
> - memcpy(data + max_copied, ring->data, bytes_to_rip - 
> max_copied);
> + memcpy(data + max_copied,
> + ring->data, bytes_to_rip - max_copied);

Line it up like this:
memcpy(data + max_copied, ring->data,
   bytes_to_rip - max_copied);


[tab][tab][space][space][space][space][space][space][space]bytes_

regards,
dan carpenter

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

Re: [PATCH] timekeeping: avoid adjust kernel time once hwclock kept in UTC time

[John Stultz]

On 12/18/2012 09:15 PM, Dong Zhu wrote:

On Thu, Dec 06, 2012 at 10:03:34PM +0800, Dong Zhu wrote:

 From c126376cf1837b0956e0268056db61870fbbc1d4 Mon Sep 17 00:00:00 2001
From: Dong Zhu 
Date: Thu, 6 Dec 2012 21:45:00 +0800
Subject: [PATCH] timekeeping: avoid adjust kernel time once hwclock kept in
  UTC time

If the Hardware Clock kept in local time,kernel will adjust the time
to be UTC time.But if Hardware Clock kept in UTC time,system will make
a dummy settimeofday call first (sys_tz.tz_minuteswest = 0) to make sure
the time is not shifted,so at this point I think maybe it is not necessary
to set the kernel time once the sys_tz.tz_minuteswest is zero.

Signed-off-by: Dong Zhu 
---
  kernel/time.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/kernel/time.c b/kernel/time.c
index d226c6a..0b592ce 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -134,9 +134,11 @@ static inline void warp_clock(void)
  {
struct timespec adjust;
  
-	adjust = current_kernel_time();

-   adjust.tv_sec += sys_tz.tz_minuteswest * 60;
-   do_settimeofday();
+   if (sys_tz.tz_minuteswest) {
+   adjust = current_kernel_time();
+   adjust.tv_sec += sys_tz.tz_minuteswest * 60;
+   do_settimeofday();
+   }
  }
  
  /*

--
1.7.11.7


Hi,

Any comments ?
Sorry for the slow response, been a little busy.   Honestly the 
warp_clock() code path is always been a bit odd to me, so I've not 
really been able to get my head around the implications of this change.


Really, I'm not sure if I'll get to this before the new year.
Its on my list, but don't be afraid to ping me early Jan if I haven't 
queued it for 3.9 by then.


thanks
-john

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

[PATCH] ARM: tegra: dts: add aliases and DMA requestor for serial controller

[Laxman Dewangan]

Add APB DMA requestor and serial aliases for serial controller.
There will be two serial driver i.e. 8250 based simple serial driver
and APB DMA based serial driver for higher baudrate and performace.

The simple serial driver get enabled with compatible nvidia,tegra20-uart
and APB DMA based driver will get enabled with compatible
nvidia,tegra20-hsuart.

Signed-off-by: Laxman Dewangan 
---
 arch/arm/boot/dts/tegra20.dtsi |   30 +-
 arch/arm/boot/dts/tegra30.dtsi |   31 ++-
 2 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index b8effa1..fe35c72 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -4,6 +4,14 @@
compatible = "nvidia,tegra20";
interrupt-parent = <>;
 
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
host1x {
compatible = "nvidia,tegra20-host1x", "simple-bus";
reg = <0x5000 0x00024000>;
@@ -194,43 +202,55 @@
status = "disabled";
};
 
-   serial@70006000 {
+   /*
+* There are two serial driver i.e. 8250 based simple serial
+* driver and APB DMA based serial driver for higher baudrate
+* and performace. To enable the 8250 based driver, the compatible
+* is "nvidia,tegra20-uart" and to enable the APB DMA based serial
+* driver, the comptible is "nvidia,tegra20-hsuart".
+*/
+   uarta: serial@70006000 {
compatible = "nvidia,tegra20-uart";
reg = <0x70006000 0x40>;
reg-shift = <2>;
interrupts = <0 36 0x04>;
+   nvidia,dma-request-selector = < 8>;
status = "disabled";
};
 
-   serial@70006040 {
+   uartb: serial@70006040 {
compatible = "nvidia,tegra20-uart";
reg = <0x70006040 0x40>;
reg-shift = <2>;
interrupts = <0 37 0x04>;
+   nvidia,dma-request-selector = < 9>;
status = "disabled";
};
 
-   serial@70006200 {
+   uartc: serial@70006200 {
compatible = "nvidia,tegra20-uart";
reg = <0x70006200 0x100>;
reg-shift = <2>;
interrupts = <0 46 0x04>;
+   nvidia,dma-request-selector = < 10>;
status = "disabled";
};
 
-   serial@70006300 {
+   uartd: serial@70006300 {
compatible = "nvidia,tegra20-uart";
reg = <0x70006300 0x100>;
reg-shift = <2>;
interrupts = <0 90 0x04>;
+   nvidia,dma-request-selector = < 19>;
status = "disabled";
};
 
-   serial@70006400 {
+   uarte: serial@70006400 {
compatible = "nvidia,tegra20-uart";
reg = <0x70006400 0x100>;
reg-shift = <2>;
interrupts = <0 91 0x04>;
+   nvidia,dma-request-selector = < 20>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 529fdb8..80a0edf 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -4,6 +4,14 @@
compatible = "nvidia,tegra30";
interrupt-parent = <>;
 
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
host1x {
compatible = "nvidia,tegra30-host1x", "simple-bus";
reg = <0x5000 0x00024000>;
@@ -190,43 +198,56 @@
   0x70003000 0x3e4>; /* Mux registers */
};
 
-   serial@70006000 {
+   /*
+* There are two serial driver i.e. 8250 based simple serial
+* driver and APB DMA based serial driver for higher baudrate
+* and performace. To enable the 8250 based driver, the compatible
+* is "nvidia,tegra30-uart", "nvidia,tegra20-uart" and to enable
+* the APB DMA based serial driver, the comptible is
+* "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart".
+*/
+   uarta: serial@70006000 {
compatible = "nvidia,tegra30-uart", "nvidia,tegra20-uart";
reg = <0x70006000 0x40>;
reg-shift = <2>;
interrupts = <0 36 0x04>;
+   nvidia,dma-request-selector = < 8>;
status = "disabled";
};
 
-   serial@70006040 {
+   uartb: serial@70006040 {
compatible = "nvidia,tegra30-uart", "nvidia,tegra20-uart";
reg = <0x70006040 0x40>;
reg-shift = <2>;
interrupts = <0 37 0x04>;
+   nvidia,dma-request-selector = < 

[PATCH V3] serial: tegra: add serial driver

[Laxman Dewangan]

NVIDIA's Tegra has multiple UART controller which supports:
- APB DMA based controller fifo read/write.
- End Of Data interrupt in incoming data to know whether end
  of frame achieve or not.
- HW controlled RTS and CTS flow control to reduce SW overhead.

Add serial driver to use all above feature.

Signed-off-by: Laxman Dewangan 
Acked-by: Alan Cox 
---
Changes from V1:
- Remove port-number parameter and use the of_alias_get().
- put the ref count for the tty.
- rename the binding document file to serial-tegra.txt to match with
  driver name.
- Remove falsy introduced line from Kconfig.
- Move platform data file to linux/platfor_data. Not removing the
  platform datacompletely now. if it is requie to remove the will
  be remove later along with other tegra driver also.
- Simplify tegra_uart_set_mctrl
- Clear flag for CMSPAR as driver dose not support this.
- Modify uart_get_baud_rate() to use actual baudrate.
- reorder compatibles in documentation file.
- used of_property_read_bool for modem interrupt.
- remove check if (pdev->dev.of_node) as it si always true.
- Drop devinit and devexit compiler option.
- nit cleanups for moving struture to the usage area.

Changes from V2:
- Rename the binding document to nvidia,tegra20-hsuart.txt
- Some nit cleanups and use Caps for aliases like APB, DMA, UART.
- Adding Alan's ack.

 .../bindings/serial/nvidia,tegra20-hsuart.txt  |   24 +
 drivers/tty/serial/Kconfig |   11 +
 drivers/tty/serial/Makefile|1 +
 drivers/tty/serial/serial-tegra.c  | 1407 
 include/linux/platform_data/serial-tegra.h |   36 +
 5 files changed, 1479 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
 create mode 100644 drivers/tty/serial/serial-tegra.c
 create mode 100644 include/linux/platform_data/serial-tegra.h

diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt 
b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
new file mode 100644
index 000..392a449
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
@@ -0,0 +1,24 @@
+NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver.
+
+Required properties:
+- compatible : should be "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart".
+- reg: Should contain UART controller registers location and length.
+- interrupts: Should contain UART controller interrupts.
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+  request selector for this UART controller.
+
+Optional properties:
+- nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable
+   only if all 8 lines of UART controller are pinmuxed.
+
+Example:
+
+serial@70006000 {
+   compatible = "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart";
+   reg = <0x70006000 0x40>;
+   reg-shift = <2>;
+   interrupts = <0 36 0x04>;
+   nvidia,dma-request-selector = < 8>;
+   nvidia,enable-modem-interrupt;
+   status = "disabled";
+};
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 59c23d0..aff3cd3 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -269,6 +269,17 @@ config SERIAL_SIRFSOC_CONSOLE
   your boot loader about how to pass options to the kernel at
   boot time.)
 
+config SERIAL_TEGRA
+   tristate "NVIDIA Tegra20/30 SoC serial controller"
+   depends on ARCH_TEGRA && TEGRA20_APB_DMA
+   select SERIAL_CORE
+   help
+ Support for the on-chip UARTs on the NVIDIA Tegra series SOCs
+ providing /dev/ttyHS0, 1, 2, 3 and 4 (note, some machines may not
+ provide all of these ports, depending on how the serial port
+ are enabled). This driver uses the APB DMA to achieve higher baudrate
+ and better performance.
+
 config SERIAL_MAX3100
tristate "MAX3100 support"
depends on SPI
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index df1b998..82e4306 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_SERIAL_MXS_AUART) += mxs-auart.o
 obj-$(CONFIG_SERIAL_LANTIQ)+= lantiq.o
 obj-$(CONFIG_SERIAL_XILINX_PS_UART) += xilinx_uartps.o
 obj-$(CONFIG_SERIAL_SIRFSOC) += sirfsoc_uart.o
+obj-$(CONFIG_SERIAL_TEGRA) += serial-tegra.o
 obj-$(CONFIG_SERIAL_AR933X)   += ar933x_uart.o
 obj-$(CONFIG_SERIAL_EFM32_UART) += efm32-uart.o
 obj-$(CONFIG_SERIAL_ARC)   += arc_uart.o
diff --git a/drivers/tty/serial/serial-tegra.c 
b/drivers/tty/serial/serial-tegra.c
new file mode 100644
index 000..0b7efb3
--- /dev/null
+++ b/drivers/tty/serial/serial-tegra.c
@@ -0,0 +1,1407 @@
+/*
+ * serial_tegra.c
+ *
+ * High-speed serial driver for NVIDIA Tegra SoCs
+ *
+ * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Author: Laxman Dewangan 
+ *
+ * This program is 

Re: [PATCH] usb: phy: samsung: Add support for USB 3.0 phy for exynos5250

[Vivek Gautam]

Hi Felipe,


On Wed, Dec 19, 2012 at 11:14 AM, Vivek Gautam
 wrote:
> CC: Doug Anderson
>
>
> On Tue, Dec 18, 2012 at 8:43 PM, Felipe Balbi  wrote:
>> On Tue, Dec 18, 2012 at 08:40:26PM +0530, Vivek Gautam wrote:
>>> Adding support for USB3.0 phy for dwc3 controller on
>>> exynos5250 SOC.
>>>
>>> Signed-off-by: Vivek Gautam 
>>> ---
>>>  drivers/usb/phy/samsung-usbphy.c |  339 
>>> +-
>>
>> let's make the phy names standard from now on and call this
>> phy-samsung.c :-)
>>
>>>  1 files changed, 337 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/phy/samsung-usbphy.c 
>>> b/drivers/usb/phy/samsung-usbphy.c
>>> index 621348a..246eb28 100644
>>> --- a/drivers/usb/phy/samsung-usbphy.c
>>> +++ b/drivers/usb/phy/samsung-usbphy.c
>>> @@ -154,6 +154,86 @@
>>>
>>>  #define EXYNOS5_PHY_OTG_TUNE (0x40)
>>>
>>> +/* EXYNOS5: USB 3.0 DRD */
>>> +#define EXYNOS5_DRD_LINKSYSTEM   (0x04)
>>> +
>>> +#define LINKSYSTEM_FLADJ_MASK(0x3f << 1)
>>> +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1)
>>> +#define LINKSYSTEM_XHCI_VERSION_CONTROL  (0x1 << 27)
>>> +
>>> +#define EXYNOS5_DRD_PHYUTMI  (0x08)
>>> +
>>> +#define PHYUTMI_OTGDISABLE   (0x1 << 6)
>>> +#define PHYUTMI_FORCESUSPEND (0x1 << 1)
>>> +#define PHYUTMI_FORCESLEEP   (0x1 << 0)
>>> +
>>> +#define EXYNOS5_DRD_PHYPIPE  (0x0c)
>>> +
>>> +#define EXYNOS5_DRD_PHYCLKRST(0x10)
>>> +
>>> +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23)
>>> +#define PHYCLKRST_SSC_REFCLKSEL(_x)  ((_x) << 23)
>>> +
>>> +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21)
>>> +#define PHYCLKRST_SSC_RANGE(_x)  ((_x) << 21)
>>> +
>>> +#define PHYCLKRST_SSC_EN (0x1 << 20)
>>> +#define PHYCLKRST_REF_SSP_EN (0x1 << 19)
>>> +#define PHYCLKRST_REF_CLKDIV2(0x1 << 18)
>>> +
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_MASK   (0x7f << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x02 << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF  (0x68 << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF  (0x7d << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF   (0x02 << 11)
>>> +
>>> +#define PHYCLKRST_FSEL_MASK  (0x3f << 5)
>>> +#define PHYCLKRST_FSEL(_x)   ((_x) << 5)
>>> +#define PHYCLKRST_FSEL_PAD_100MHZ(0x27 << 5)
>>> +#define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5)
>>> +#define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5)
>>> +#define PHYCLKRST_FSEL_PAD_19_2MHZ   (0x38 << 5)
>>> +
>>> +#define PHYCLKRST_RETENABLEN (0x1 << 4)
>>> +
>>> +#define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2)
>>> +#define PHYCLKRST_REFCLKSEL_PAD_REFCLK   (0x2 << 2)
>>> +#define PHYCLKRST_REFCLKSEL_EXT_REFCLK   (0x3 << 2)
>>> +
>>> +#define PHYCLKRST_PORTRESET  (0x1 << 1)
>>> +#define PHYCLKRST_COMMONONN  (0x1 << 0)
>>> +
>>> +#define EXYNOS5_DRD_PHYREG0  (0x14)
>>> +#define EXYNOS5_DRD_PHYREG1  (0x18)
>>> +
>>> +#define EXYNOS5_DRD_PHYPARAM0(0x1c)
>>> +
>>> +#define PHYPARAM0_REF_USE_PAD(0x1 << 31)
>>> +#define PHYPARAM0_REF_LOSLEVEL_MASK  (0x1f << 26)
>>> +#define PHYPARAM0_REF_LOSLEVEL   (0x9 << 26)
>>> +
>>> +#define EXYNOS5_DRD_PHYPARAM1(0x20)
>>> +
>>> +#define PHYPARAM1_PCS_TXDEEMPH_MASK  (0x1f << 0)
>>> +#define PHYPARAM1_PCS_TXDEEMPH   (0x1c)
>>> +
>>> +#define EXYNOS5_DRD_PHYTERM  (0x24)
>>> +
>>> +#define EXYNOS5_DRD_PHYTEST  (0x28)
>>> +
>>> +#define PHYTEST_POWERDOWN_SSP(0x1 << 3)
>>> +#define PHYTEST_POWERDOWN_HSP(0x1 << 2)
>>> +
>>> +#define EXYNOS5_DRD_PHYADP   (0x2c)
>>> +
>>> +#define EXYNOS5_DRD_PHYBATCHG(0x30)
>>> +
>>> +#define PHYBATCHG_UTMI_CLKSEL(0x1 << 2)
>>> +
>>> +#define EXYNOS5_DRD_PHYRESUME(0x34)
>>> +#define EXYNOS5_DRD_LINKPORT (0x44)
>>> +
>>>  #ifndef MHZ
>>>  #define MHZ (1000*1000)
>>>  #endif
>>> @@ -164,6 +244,15 @@ enum samsung_cpu_type {
>>>   TYPE_EXYNOS5250,
>>>  };
>>>
>>> +/* structure usb3 - usb3.0 phy trasceiver state
>>> + * @phy: transceiver structure for USB 3.0
>>> + * @regs_phy: usb 3.0 phy register memory base
>>> + */
>>> +struct usb3 {
>>> + struct usb_phy  phy;
>>> + void __iomem*regs_phy;
>>> +};
>>> +
>>>  /*
>>>   * struct samsung_usbphy - transceiver driver state
>>>   * @phy: transceiver structure
>>> @@ -192,11 +281,15 @@ struct samsung_usbphy {
>>>   

Re: linux-next: manual merge of the modules tree with Linus' tree

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Rusty,
>
> Today's linux-next merge of the modules tree got a conflict in
> kernel/modsign_pubkey.c between commit 84ecfd15f554 ("modsign: add symbol
> prefix to certificate list") from Linus' tree and commit bb8f5966421d
> ("MODSIGN: Avoid using .incbin in C source") from the modules tree.

Gah, I had a brainfart reading gitk and thought commit was not upstream
:(

(Paul Mackerras points out that gitk shows you what branches a commit is
in, so I now have no excuse.  He also offered to colour-code it for me
RSN, which would make it inescapable).

> I fixed it up (I just used the modules tree version as it removed the
> section of code modified by the former) and can carry the fix as
> necessary (no action is required).

Yes, but that leaves this turd in linux/kernel.h from
cbdbf2abb7844548a7d7a6a2ae7af6b6fbcea401:

+/* This helps us to avoid #ifdef CONFIG_SYMBOL_PREFIX */
+#ifdef CONFIG_SYMBOL_PREFIX
+#define SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
+#else
+#define SYMBOL_PREFIX ""
+#endif

I have reverted to the previous modules-next.

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

Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang

[Joe Jin]

Hi Yijing,

Thanks for your reference, the patch looks good for me, but I have no chance
to test it on customer's env.

Best Regards,
Joe

On 12/19/12 13:52, Yijing Wang wrote:
> On 2012/12/19 11:04, Joe Jin wrote:
>> Hi all,
>>
>> I backported mps commits and ask customer pass "pci=pcie_bus_peer2pee" to 
>> kernel
>> to limited MPS to 128 and issue disappeared, sound like this is a BIOS bug.
>>
> 
> Hi Joe,
>I found similar problem when I do pci hotplug, discussion is 
> here:http://marc.info/?l=linux-pci=134810569924220=2.
> We try to improve Linux kernel to debug this problem easily based Bjorn's 
> suggestion. Jon sent out the first version patch 
> http://marc.info/?l=linux-pci=135002016005274=2.
> I think we can do further here, 
> http://marc.info/?l=linux-pci=135115581307869=2. I hope this information 
> can help you.
> 
> Thanks!
> Yijing.
> 
>> Thanks all of your help.
>>
>> Best Regards,
>> Joe
>>
>> On 11/29/12 23:52, Fujinaka, Todd wrote:
>>> Someone else pointed this out to me locally. If you have a non-client BIOS, 
>>> you should be able to set the MaxPayloadSize using setpci. You have to make 
>>> sure that you're being consistent throughout all the associated links.
>>>
>>> Todd Fujinaka
>>> Technical Marketing Engineer
>>> LAN Access Division (LAD)
>>> Intel Corporation
>>> todd.fujin...@intel.com
>>> (503) 712-4565
>>>
>>>
>>> -Original Message-
>>> From: Ethan Zhao [mailto:ethan.ker...@gmail.com] 
>>> Sent: Wednesday, November 28, 2012 7:10 PM
>>> To: Fujinaka, Todd
>>> Cc: Joe Jin; Ben Hutchings; Mary Mcgrath; net...@vger.kernel.org; 
>>> e1000-de...@lists.sf.net; linux-kernel@vger.kernel.org; linux-pci
>>> Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
>>>
>>> Joe,
>>> Possibly your customer is running a kernel without source code on a 
>>> platform whose vendor wouldn't like to fix BIOS issue( Is that a HP/Dell 
>>> server ?).
>>> Anyway, to see if is a payload issue or,  you could change the payload 
>>> size with setpci tool to those devices and set the link retrain bit to 
>>> trigger the link retraining to debug the issue and identity the root cause. 
>>>  I thinks it is much easier than modify the BIOS or  eeprom of NIC.
>>>
>>> e.g.
>>>set device control register to 0f 00   (128 bytes payload size)
>>>#   setpci -v -s 00:02.0 98.w=000f
>>>set device link control register to 60h (retrain the link)
>>>#  setpci -v -s 00:02.0 a0.b=60
>>>
>>>   Hope it works,  Just my 2 cents.
>>>
>>> ethan.z...@oracle.com
>>>
>>> On Wed, Nov 28, 2012 at 11:53 PM, Fujinaka, Todd  
>>> wrote:
 The only EEPROM I know about or can speak to is the one attached to the 
 82571 and it doesn't set the MaxPayloadSize. That's done by the BIOS.

 Todd Fujinaka
 Technical Marketing Engineer
 LAN Access Division (LAD)
 Intel Corporation
 todd.fujin...@intel.com
 (503) 712-4565


 -Original Message-
 From: Joe Jin [mailto:joe@oracle.com]
 Sent: Wednesday, November 28, 2012 12:31 AM
 To: Ben Hutchings
 Cc: Fujinaka, Todd; Mary Mcgrath; net...@vger.kernel.org; 
 e1000-de...@lists.sf.net; linux-kernel@vger.kernel.org; linux-pci
 Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang

 On 11/28/12 02:10, Ben Hutchings wrote:
> On Tue, 2012-11-27 at 17:32 +, Fujinaka, Todd wrote:
>> Forgive me if I'm being too repetitious as I think some of this has 
>> been mentioned in the past.
>>
>> We (and by we I mean the Ethernet part and driver) can only change 
>> the advertised availability of a larger MaxPayloadSize. The size is 
>> negotiated by both sides of the link when the link is established.
>> The driver should not change the size of the link as it would be 
>> poking at registers outside of its scope and is controlled by the 
>> upstream bridge (not us).
> [...]
>
> MaxPayloadSize (MPS) is not negotiated between devices but is 
> programmed by the system firmware (at least for devices present at 
> boot - the kernel may be responsible in case of hotplug).  You can 
> use the kernel parameter 'pci=pcie_bus_perf' (or one of several 
> others) to set a policy that overrides this, but no policy will allow 
> setting MPS above the device's MaxPayloadSizeSupported (MPSS).
>

 Ben,

 Unfortunately I'm using 3.0.x kernel and this is not included in the 
 kernel.
 So I'm trying to use ethtool modify it from eeprom to see if help or no.


 Todd, I'll review all MaxPayload for all devices, but need to say if it 
 mismatch, customer could not modify it from BIOS for there was not entry 
 at there, to test it, we have to find how to verify if this is the root 
 cause, so still need to find the offset in eeprom.

 Thanks in advance,
 Joe

>>
>>
> 
> 


-- 
Oracle 
Joe Jin | Software Development Senior 

Re: [PATCH v5 0/4] Adding usb2.0 host-phy support for exynos5250

[Vivek Gautam]

CC: Doug Anderson


On Tue, Dec 18, 2012 at 8:13 PM, Vivek Gautam  wrote:
> Changes from v4:
>  - Moved architecture side changes out of this patch-set.
>  - Added support for multiple usbphy phandle parsing and
>doing all pmu_isolation() and phy_cfg_sel() related changes
>in samsung-usbphy driver only instead of architecture
>as in v4 patch-set.
>  - Removed unnecessary multi line definitions for macros.
>
> Changes from v3:
>  - Moved enums S5P_USB_PHY_DEVICE, S5P_USB_PHY_HOST from machine to file
>include/linux/usb/samsung_usb_phy.h as USB_PHY_TYPE_DEVICE and
>USB_PHY_TYPE_HOST to make it more generic. Further resolve its
>dependencies.
>  - Introduced a function 'samsung_usbphy_set_type()' which takes
>care of setting up the phy_type: HOST/DEVICE. This function
>can be called by host/otg drivers to setup phy_type prior to
>handling the respective PHYs.
>  - Added an error-path for HOST type phy in s5p_usb_phy_pmu_isolation()
>for 'mach-s3c64xx'.
>  - Moving to PHY driver as default for ehci-s5p and ohci-exynos, and only
>when failed fall back to plat-data.
>  - Added samsung_usbphy_set_type() prior to doing usb_phy_init() or
>usb_phy_shutdown() so that appropriate PHY gets init or shutdown.
>
> Based on patches for samsung-usbphy driver:
>  
> 1)http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/134476.html
>  2)https://lkml.org/lkml/2012/12/18/187
>
> Vivek Gautam (4):
>   ARM: EXYNOS: Update & move usb-phy types to generic include layer
>   usb: phy: samsung: Add host phy support to samsung-phy driver
>   USB: ehci-s5p: Add phy driver support
>   USB: ohci-exynos: Add phy driver support
>
>  .../devicetree/bindings/usb/samsung-usbphy.txt |   25 +-
>  drivers/usb/host/ehci-s5p.c|   71 +++-
>  drivers/usb/host/ohci-exynos.c |   71 +++-
>  drivers/usb/phy/Kconfig|2 +-
>  drivers/usb/phy/samsung-usbphy.c   |  465 
> ++--
>  include/linux/usb/samsung_usb_phy.h|   29 ++
>  6 files changed, 570 insertions(+), 93 deletions(-)
>  create mode 100644 include/linux/usb/samsung_usb_phy.h
>
> --
> 1.7.6.5
>
> --
> 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



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

Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang

[Yijing Wang]

On 2012/12/19 11:04, Joe Jin wrote:
> Hi all,
> 
> I backported mps commits and ask customer pass "pci=pcie_bus_peer2pee" to 
> kernel
> to limited MPS to 128 and issue disappeared, sound like this is a BIOS bug.
> 

Hi Joe,
   I found similar problem when I do pci hotplug, discussion is 
here:http://marc.info/?l=linux-pci=134810569924220=2.
We try to improve Linux kernel to debug this problem easily based Bjorn's 
suggestion. Jon sent out the first version patch 
http://marc.info/?l=linux-pci=135002016005274=2.
I think we can do further here, 
http://marc.info/?l=linux-pci=135115581307869=2. I hope this information 
can help you.

Thanks!
Yijing.

> Thanks all of your help.
> 
> Best Regards,
> Joe
> 
> On 11/29/12 23:52, Fujinaka, Todd wrote:
>> Someone else pointed this out to me locally. If you have a non-client BIOS, 
>> you should be able to set the MaxPayloadSize using setpci. You have to make 
>> sure that you're being consistent throughout all the associated links.
>>
>> Todd Fujinaka
>> Technical Marketing Engineer
>> LAN Access Division (LAD)
>> Intel Corporation
>> todd.fujin...@intel.com
>> (503) 712-4565
>>
>>
>> -Original Message-
>> From: Ethan Zhao [mailto:ethan.ker...@gmail.com] 
>> Sent: Wednesday, November 28, 2012 7:10 PM
>> To: Fujinaka, Todd
>> Cc: Joe Jin; Ben Hutchings; Mary Mcgrath; net...@vger.kernel.org; 
>> e1000-de...@lists.sf.net; linux-kernel@vger.kernel.org; linux-pci
>> Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
>>
>> Joe,
>> Possibly your customer is running a kernel without source code on a 
>> platform whose vendor wouldn't like to fix BIOS issue( Is that a HP/Dell 
>> server ?).
>> Anyway, to see if is a payload issue or,  you could change the payload 
>> size with setpci tool to those devices and set the link retrain bit to 
>> trigger the link retraining to debug the issue and identity the root cause.  
>> I thinks it is much easier than modify the BIOS or  eeprom of NIC.
>>
>> e.g.
>>set device control register to 0f 00   (128 bytes payload size)
>>#   setpci -v -s 00:02.0 98.w=000f
>>set device link control register to 60h (retrain the link)
>>#  setpci -v -s 00:02.0 a0.b=60
>>
>>   Hope it works,  Just my 2 cents.
>>
>> ethan.z...@oracle.com
>>
>> On Wed, Nov 28, 2012 at 11:53 PM, Fujinaka, Todd  
>> wrote:
>>> The only EEPROM I know about or can speak to is the one attached to the 
>>> 82571 and it doesn't set the MaxPayloadSize. That's done by the BIOS.
>>>
>>> Todd Fujinaka
>>> Technical Marketing Engineer
>>> LAN Access Division (LAD)
>>> Intel Corporation
>>> todd.fujin...@intel.com
>>> (503) 712-4565
>>>
>>>
>>> -Original Message-
>>> From: Joe Jin [mailto:joe@oracle.com]
>>> Sent: Wednesday, November 28, 2012 12:31 AM
>>> To: Ben Hutchings
>>> Cc: Fujinaka, Todd; Mary Mcgrath; net...@vger.kernel.org; 
>>> e1000-de...@lists.sf.net; linux-kernel@vger.kernel.org; linux-pci
>>> Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
>>>
>>> On 11/28/12 02:10, Ben Hutchings wrote:
 On Tue, 2012-11-27 at 17:32 +, Fujinaka, Todd wrote:
> Forgive me if I'm being too repetitious as I think some of this has 
> been mentioned in the past.
>
> We (and by we I mean the Ethernet part and driver) can only change 
> the advertised availability of a larger MaxPayloadSize. The size is 
> negotiated by both sides of the link when the link is established.
> The driver should not change the size of the link as it would be 
> poking at registers outside of its scope and is controlled by the 
> upstream bridge (not us).
 [...]

 MaxPayloadSize (MPS) is not negotiated between devices but is 
 programmed by the system firmware (at least for devices present at 
 boot - the kernel may be responsible in case of hotplug).  You can 
 use the kernel parameter 'pci=pcie_bus_perf' (or one of several 
 others) to set a policy that overrides this, but no policy will allow 
 setting MPS above the device's MaxPayloadSizeSupported (MPSS).

>>>
>>> Ben,
>>>
>>> Unfortunately I'm using 3.0.x kernel and this is not included in the kernel.
>>> So I'm trying to use ethtool modify it from eeprom to see if help or no.
>>>
>>>
>>> Todd, I'll review all MaxPayload for all devices, but need to say if it 
>>> mismatch, customer could not modify it from BIOS for there was not entry at 
>>> there, to test it, we have to find how to verify if this is the root cause, 
>>> so still need to find the offset in eeprom.
>>>
>>> Thanks in advance,
>>> Joe
>>>
> 
> 


-- 
Thanks!
Yijing

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

Re: [PATCH v5 4/4] USB: ohci-exynos: Add phy driver support

[Vivek Gautam]

CC: Doug Anderson.


On Tue, Dec 18, 2012 at 8:13 PM, Vivek Gautam  wrote:
> Adding the phy-driver to ohci-exynos. Keeping the platform data
> for continuing the smooth operation for boards which still uses it
>
> Signed-off-by: Vivek Gautam 
> Acked-by: Jingoo Han 
> ---
>  drivers/usb/host/ohci-exynos.c |   70 
> 
>  1 files changed, 49 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index 804fb62..c92ab7b 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -22,8 +23,34 @@ struct exynos_ohci_hcd {
> struct device *dev;
> struct usb_hcd *hcd;
> struct clk *clk;
> +   struct usb_phy *phy;
> +   struct exynos4_ohci_platdata *pdata;
>  };
>
> +static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
> +{
> +   struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
> +
> +   if (exynos_ohci->phy) {
> +   samsung_usbphy_set_type(exynos_ohci->phy, USB_PHY_TYPE_HOST);
> +   usb_phy_init(exynos_ohci->phy);
> +   } else if (exynos_ohci->pdata->phy_init) {
> +   exynos_ohci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
> +   }
> +}
> +
> +static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
> +{
> +   struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
> +
> +   if (exynos_ohci->phy) {
> +   samsung_usbphy_set_type(exynos_ohci->phy, USB_PHY_TYPE_HOST);
> +   usb_phy_shutdown(exynos_ohci->phy);
> +   } else if (exynos_ohci->pdata->phy_exit) {
> +   exynos_ohci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
> +   }
> +}
> +
>  static int ohci_exynos_reset(struct usb_hcd *hcd)
>  {
> return ohci_init(hcd_to_ohci(hcd));
> @@ -79,20 +106,15 @@ static u64 ohci_exynos_dma_mask = DMA_BIT_MASK(32);
>
>  static int exynos_ohci_probe(struct platform_device *pdev)
>  {
> -   struct exynos4_ohci_platdata *pdata;
> +   struct exynos4_ohci_platdata *pdata = pdev->dev.platform_data;
> struct exynos_ohci_hcd *exynos_ohci;
> struct usb_hcd *hcd;
> struct ohci_hcd *ohci;
> struct resource *res;
> +   struct usb_phy *phy;
> int irq;
> int err;
>
> -   pdata = pdev->dev.platform_data;
> -   if (!pdata) {
> -   dev_err(>dev, "No platform data defined\n");
> -   return -EINVAL;
> -   }
> -
> /*
>  * Right now device-tree probed devices don't get dma_mask set.
>  * Since shared usb code relies on it, set it here for now.
> @@ -108,6 +130,19 @@ static int exynos_ohci_probe(struct platform_device 
> *pdev)
> if (!exynos_ohci)
> return -ENOMEM;
>
> +   phy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
> +   if (IS_ERR_OR_NULL(phy)) {
> +   /* Fallback to pdata */
> +   if (!pdata) {
> +   dev_err(>dev, "no platform data or transceiver 
> defined\n");
> +   return -EPROBE_DEFER;
> +   } else {
> +   exynos_ohci->pdata = pdata;
> +   }
> +   } else {
> +   exynos_ohci->phy = phy;
> +   }
> +
> exynos_ohci->dev = >dev;
>
> hcd = usb_create_hcd(_ohci_hc_driver, >dev,
> @@ -153,8 +188,7 @@ static int exynos_ohci_probe(struct platform_device *pdev)
> goto fail_io;
> }
>
> -   if (pdata->phy_init)
> -   pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
> +   exynos_ohci_phy_enable(exynos_ohci);
>
> ohci = hcd_to_ohci(hcd);
> ohci_hcd_init(ohci);
> @@ -162,13 +196,15 @@ static int exynos_ohci_probe(struct platform_device 
> *pdev)
> err = usb_add_hcd(hcd, irq, IRQF_SHARED);
> if (err) {
> dev_err(>dev, "Failed to add USB HCD\n");
> -   goto fail_io;
> +   goto fail_add_hcd;
> }
>
> platform_set_drvdata(pdev, exynos_ohci);
>
> return 0;
>
> +fail_add_hcd:
> +   exynos_ohci_phy_disable(exynos_ohci);
>  fail_io:
> clk_disable_unprepare(exynos_ohci->clk);
>  fail_clk:
> @@ -178,14 +214,12 @@ fail_clk:
>
>  static int exynos_ohci_remove(struct platform_device *pdev)
>  {
> -   struct exynos4_ohci_platdata *pdata = pdev->dev.platform_data;
> struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
> struct usb_hcd *hcd = exynos_ohci->hcd;
>
> usb_remove_hcd(hcd);
>
> -   if (pdata && pdata->phy_exit)
> -   pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
> +   exynos_ohci_phy_disable(exynos_ohci);
>
> clk_disable_unprepare(exynos_ohci->clk);
>
> @@ -209,8 +243,6 @@ static int exynos_ohci_suspend(struct device *dev)
> 

Re: [PATCH 2/2] ARM: Exynos5250: Enabling USB 3.0 phy for samsung-usbphy driver

[Vivek Gautam]

CC: Doug Anderson.


On Wed, Dec 19, 2012 at 5:02 AM, Sylwester Nawrocki
 wrote:
> On 12/18/2012 04:39 PM, Vivek Gautam wrote:
>>
>> Adding base address information required for enabling
>> USB 3.0 DRD phy on exynos5250 SOC.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>>   arch/arm/boot/dts/exynos5250.dtsi |3 ++-
>>   1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index bbdb2c2..07b7477 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -316,7 +316,8 @@
>>
>> usbphy@1213 {
>> compatible = "samsung,exynos5250-usbphy";
>> -   reg =<0x1213 0x100>;
>> +   reg =<0x1213 0x100>,
>> +   <0x1210 0x100>;
>
>
> Doesn't this second memory region mean distinct PHY controller device ?
> Why separate usbphy node can't/shouldn't be created for it ?
>
>> samsung,usb-phyhandle =<_h0_h1_h2>;
>> samsung,enable-mask =<1>;
>> };
>
> --
> 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



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

Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver

[Vivek Gautam]

CC: Doug Anderson.


On Tue, Dec 18, 2012 at 8:13 PM, Vivek Gautam  wrote:
> This patch adds host phy support to samsung-usbphy.c and
> further adds support for samsung's exynos5250 usb-phy.
>
> Signed-off-by: Praveen Paneri 
> Signed-off-by: Vivek Gautam 
> ---
>  .../devicetree/bindings/usb/samsung-usbphy.txt |   25 +-
>  drivers/usb/phy/Kconfig|2 +-
>  drivers/usb/phy/samsung-usbphy.c   |  465 
> ++--
>  include/linux/usb/samsung_usb_phy.h|   13 +
>  4 files changed, 454 insertions(+), 51 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt 
> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> index a7b28b2..2ec5400 100644
> --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> @@ -1,23 +1,38 @@
>  * Samsung's usb phy transceiver
>
> -The Samsung's phy transceiver is used for controlling usb otg phy for
> -s3c-hsotg usb device controller.
> +The Samsung's phy transceiver is used for controlling usb phy for
> +s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers
> +across Samsung SOCs.
>  TODO: Adding the PHY binding with controller(s) according to the under
>  developement generic PHY driver.
>
>  Required properties:
> +
> +Exynos4210:
>  - compatible : should be "samsung,exynos4210-usbphy"
>  - reg : base physical address of the phy registers and length of memory 
> mapped
> region.
>
> +Exynos5250:
> +- compatible : should be "samsung,exynos5250-usbphy"
> +- reg : base physical address of the phy registers and length of memory 
> mapped
> +   region.
> +
>  Optional properties:
>  - samsung,usb-phyhandle : should point to usb-phyhandle sub-node which 
> provides
> binding data to enable/disable device PHY handled by
> -   PMU register.
> +   PMU register; or to configure usb2.0 phy handled by
> +   SYSREG.
>
> Required properties:
> - compatible : should be "samsung,usbdev-phyctrl" for
> -   DEVICE type phy.
> +  DEVICE type phy; or
> +  should be "samsung,usbhost-phyctrl" for
> +  HOST type phy; or
> +  should be "samsung,usb-phycfg" for
> +  USB2.0 PHY_CFG.
> - samsung,phyhandle-reg: base physical address of
> -   PHY_CONTROL register in PMU.
> +PHY_CONTROL register in PMU;
> +or USB2.0 PHY_CFG register
> +in SYSREG.
>  - samsung,enable-mask : should be '1'
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 17ad743..13c0eaf 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -47,7 +47,7 @@ config USB_RCAR_PHY
>
>  config SAMSUNG_USBPHY
> bool "Samsung USB PHY controller Driver"
> -   depends on USB_S3C_HSOTG
> +   depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS
> select USB_OTG_UTILS
> help
>   Enable this to support Samsung USB phy controller for samsung
> diff --git a/drivers/usb/phy/samsung-usbphy.c 
> b/drivers/usb/phy/samsung-usbphy.c
> index 4ceabe3..621348a 100644
> --- a/drivers/usb/phy/samsung-usbphy.c
> +++ b/drivers/usb/phy/samsung-usbphy.c
> @@ -5,7 +5,8 @@
>   *
>   * Author: Praveen Paneri 
>   *
> - * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller
> + * Samsung USB-PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and
> + * OHCI-EXYNOS controllers.
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 as
> @@ -24,7 +25,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>
>  /* Register definitions */
> @@ -56,6 +57,103 @@
>  #define RSTCON_HLINK_SWRST (0x1 << 1)
>  #define RSTCON_SWRST   (0x1 << 0)
>
> +/* EXYNOS5 */
> +#define EXYNOS5_PHY_HOST_CTRL0 (0x00)
> +
> +#define HOST_CTRL0_PHYSWRSTALL (0x1 << 31)
> +
> +#define HOST_CTRL0_REFCLKSEL_MASK  (0x3)
> +#define HOST_CTRL0_REFCLKSEL_XTAL  (0x0 << 19)
> +#define HOST_CTRL0_REFCLKSEL_EXTL  (0x1 << 19)
> +#define HOST_CTRL0_REFCLKSEL_CLKCORE   (0x2 << 19)
> +
> +#define HOST_CTRL0_FSEL_MASK   (0x7 << 16)
> +#define HOST_CTRL0_FSEL(_x)((_x) << 16)
> +#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7)
> +#define HOST_CTRL0_FSEL_CLKSEL_24M 

Re: [PATCH 1/2] ARM: Exynos5250: Enabling samsung-usbphy driver

[Vivek Gautam]

CC: Doug Anderson.


On Tue, Dec 18, 2012 at 9:09 PM, Vivek Gautam  wrote:
> Adding usbphy node for Exynos5250 along with the
> necessary device data to be parsed.
>
> Signed-off-by: Vivek Gautam 
> ---
>  arch/arm/boot/dts/exynos5250.dtsi   |   22 ++
>  arch/arm/mach-exynos/include/mach/map.h |1 +
>  arch/arm/mach-exynos/mach-exynos5-dt.c  |2 ++
>  3 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 581e57a..bbdb2c2 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -299,6 +299,28 @@
> rx-dma-channel = < 11>; /* preliminary */
> };
>
> +   phy_h0: usbdev_phyctrl@10040704 {
> +   compatible = "samsung,usbdev-phyctrl";
> +   samsung,phyhandle-reg = <0x10040704>;
> +   };
> +
> +   phy_h1: usbhost_phyctrl@10040708 {
> +   compatible = "samsung,usbhost-phyctrl";
> +   samsung,phyhandle-reg = <0x10040708>;
> +   };
> +
> +   phy_h2: usbhost_phycfg@10050230 {
> +   compatible = "samsung,usb-phycfg";
> +   samsung,phyhandle-reg = <0x10050230>;
> +   };
> +
> +   usbphy@1213 {
> +   compatible = "samsung,exynos5250-usbphy";
> +   reg = <0x1213 0x100>;
> +   samsung,usb-phyhandle = <_h0 _h1 _h2>;
> +   samsung,enable-mask = <1>;
> +   };
> +
> amba {
> #address-cells = <1>;
> #size-cells = <1>;
> diff --git a/arch/arm/mach-exynos/include/mach/map.h 
> b/arch/arm/mach-exynos/include/mach/map.h
> index cbb2852..778348e 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -201,6 +201,7 @@
>  #define EXYNOS4_PA_EHCI0x1258
>  #define EXYNOS4_PA_OHCI0x1259
>  #define EXYNOS4_PA_HSPHY   0x125B
> +#define EXYNOS5_PA_HSPHY   0x1213
>  #define EXYNOS4_PA_MFC 0x1340
>
>  #define EXYNOS4_PA_UART0x1380
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c 
> b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index 462e5ac..24e7529 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -110,6 +110,8 @@ static const struct of_dev_auxdata 
> exynos5250_auxdata_lookup[] __initconst = {
> "samsung-i2s.1", NULL),
> OF_DEV_AUXDATA("samsung,samsung-i2s", 0x12D7,
> "samsung-i2s.2", NULL),
> +   OF_DEV_AUXDATA("samsung,exynos5250-usbphy", EXYNOS5_PA_HSPHY,
> +   "s3c-usbphy", NULL),
> {},
>  };
>
> --
> 1.7.6.5
>
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss



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

Re: [PATCH v5 1/4] ARM: EXYNOS: Update & move usb-phy types to generic include layer

[Vivek Gautam]

CC: Doug Anderson.


On Tue, Dec 18, 2012 at 8:13 PM, Vivek Gautam  wrote:
> Updating the names of usb-phy types to more generic names:
> USB_PHY_TYPE_DEIVCE & USB_PHY_TYPE_HOST; and further update
> its dependencies.
>
> Signed-off-by: Praveen Paneri 
> Signed-off-by: Vivek Gautam 
> ---
>  drivers/usb/host/ehci-s5p.c |9 +
>  drivers/usb/host/ohci-exynos.c  |9 +
>  include/linux/usb/samsung_usb_phy.h |   16 
>  3 files changed, 26 insertions(+), 8 deletions(-)
>  create mode 100644 include/linux/usb/samsung_usb_phy.h
>
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index 319dcfa..46ca5ef 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #define EHCI_INSNREG00(base)   (base + 0x90)
> @@ -164,7 +165,7 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> }
>
> if (pdata->phy_init)
> -   pdata->phy_init(pdev, S5P_USB_PHY_HOST);
> +   pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
>
> ehci = hcd_to_ehci(hcd);
> ehci->caps = hcd->regs;
> @@ -198,7 +199,7 @@ static int s5p_ehci_remove(struct platform_device *pdev)
> usb_remove_hcd(hcd);
>
> if (pdata && pdata->phy_exit)
> -   pdata->phy_exit(pdev, S5P_USB_PHY_HOST);
> +   pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
>
> clk_disable_unprepare(s5p_ehci->clk);
>
> @@ -229,7 +230,7 @@ static int s5p_ehci_suspend(struct device *dev)
> rc = ehci_suspend(hcd, do_wakeup);
>
> if (pdata && pdata->phy_exit)
> -   pdata->phy_exit(pdev, S5P_USB_PHY_HOST);
> +   pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
>
> clk_disable_unprepare(s5p_ehci->clk);
>
> @@ -246,7 +247,7 @@ static int s5p_ehci_resume(struct device *dev)
> clk_prepare_enable(s5p_ehci->clk);
>
> if (pdata && pdata->phy_init)
> -   pdata->phy_init(pdev, S5P_USB_PHY_HOST);
> +   pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
>
> /* DMA burst Enable */
> writel(EHCI_INSNREG00_ENABLE_DMA_BURST, EHCI_INSNREG00(hcd->regs));
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index aa3b884..804fb62 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  struct exynos_ohci_hcd {
> @@ -153,7 +154,7 @@ static int exynos_ohci_probe(struct platform_device *pdev)
> }
>
> if (pdata->phy_init)
> -   pdata->phy_init(pdev, S5P_USB_PHY_HOST);
> +   pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
>
> ohci = hcd_to_ohci(hcd);
> ohci_hcd_init(ohci);
> @@ -184,7 +185,7 @@ static int exynos_ohci_remove(struct platform_device 
> *pdev)
> usb_remove_hcd(hcd);
>
> if (pdata && pdata->phy_exit)
> -   pdata->phy_exit(pdev, S5P_USB_PHY_HOST);
> +   pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
>
> clk_disable_unprepare(exynos_ohci->clk);
>
> @@ -229,7 +230,7 @@ static int exynos_ohci_suspend(struct device *dev)
> clear_bit(HCD_FLAG_HW_ACCESSIBLE, >flags);
>
> if (pdata && pdata->phy_exit)
> -   pdata->phy_exit(pdev, S5P_USB_PHY_HOST);
> +   pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
>
> clk_disable_unprepare(exynos_ohci->clk);
>
> @@ -249,7 +250,7 @@ static int exynos_ohci_resume(struct device *dev)
> clk_prepare_enable(exynos_ohci->clk);
>
> if (pdata && pdata->phy_init)
> -   pdata->phy_init(pdev, S5P_USB_PHY_HOST);
> +   pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
>
> ohci_resume(hcd, false);
>
> diff --git a/include/linux/usb/samsung_usb_phy.h 
> b/include/linux/usb/samsung_usb_phy.h
> new file mode 100644
> index 000..9167826
> --- /dev/null
> +++ b/include/linux/usb/samsung_usb_phy.h
> @@ -0,0 +1,16 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics Co.Ltd
> + * http://www.samsung.com/
> + *
> + * Defines phy types for samsung usb phy controllers - HOST or DEIVCE.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +enum samsung_usb_phy_type {
> +   USB_PHY_TYPE_DEVICE,
> +   USB_PHY_TYPE_HOST,
> +};
> --
> 1.7.6.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a 

Re: [PATCH] [RFC] cpufreq: can't raise max frequency with cpu_thermal

[Doug Anderson]

Amit,

On Tue, Dec 18, 2012 at 8:17 PM, amit daniel kachhap
 wrote:
> On Tue, Dec 18, 2012 at 12:29 AM, Sonny Rao  wrote:
>> The cpu_thermal generic thermal management code has a bug where once
>> max cpu frequency has been lowered in sysfs (scaling_max_freq) it is
>> not possible to raise the max back up later.  The bug is that the
>> notifer gets called by __cpufreq_set_policy() before the user policy
>> max is raised, and is incorrectly trying to enforce the max frequency
>> policy even when we are trying to change the policy.  It is also not
>> clear why this driver is looking at the user policy since it is
>> primarily supposed to enforce thermal policy, not user set policy.
>
> Hi Sunny,
>
> I am not sure if this change is needed.

Do you have a machine that's running with your code?  Can you go into
sysfs (/sys/devices/system/cpu/cpu0/cpufreq/) and try lowering then
raising the max frequency by doing something like this (assumes that
you can scale down to 200MHz):

  cd /sys/devices/system/cpu/cpu0/cpufreq/
  OLD_VAL=$(cat scaling_max_freq)
  cat scaling_min_freq > scaling_max_freq
  echo ${OLD_VAL} > scaling_max_freq

  echo "$(cat scaling_max_freq) should be ${OLD_VAL}.  Is it?"

...when I run the above without Sonny's patch on my system I see:
  20 should be 170. Is it?

...after Sonny's patch then the above works.

> There is a check in cpufreq_thermal_notifier function to return 0 if
> notify_device == NOTIFY_INVALID. So the user will be always able to
> change the max frequency in normal situation. Did you tested this for
> some corner cases?
> The reason behind putting this check is that I don't want to override
> the user constraints.
>
> Thanks,
> Amit Daniel
>
>>
>> Signed-off-by: Sonny Rao 
>> ---
>>  drivers/thermal/cpu_cooling.c |4 
>>  1 files changed, 0 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index 836828e..63bc708 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -219,10 +219,6 @@ static int cpufreq_thermal_notifier(struct 
>> notifier_block *nb,
>> if (cpumask_test_cpu(policy->cpu, _device->allowed_cpus))
>> max_freq = notify_device->cpufreq_val;
>>
>> -   /* Never exceed user_policy.max*/
>> -   if (max_freq > policy->user_policy.max)
>> -   max_freq = policy->user_policy.max;
>> -
>> if (policy->max != max_freq)
>> cpufreq_verify_within_limits(policy, 0, max_freq);
>>
>> --
>> 1.7.7.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [PATCH 0/2] ARM: Exynos5250: Enabling samsung usb phy

[Vivek Gautam]

CC: Doug Anderson.


On Tue, Dec 18, 2012 at 9:09 PM, Vivek Gautam  wrote:
> This patch-set enables the samsung-usbphy driver on exynos5250,
> which enables the support for USB2 type and USB3 type phys.
> The corresponding phy driver patches are available at:
>  1) https://lkml.org/lkml/2012/12/18/201
>  2) 
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-December/024559.html
>
> Tested this patch-set on exynos5250 with following patch-sets for
> USB 2.0 and USB 3.0:
>  - https://patchwork.kernel.org/patch/1794651/
>  - https://lkml.org/lkml/2012/12/18/201
>  - 
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-December/024559.html
>  - http://comments.gmane.org/gmane.linux.usb.general/76352
>  - https://lkml.org/lkml/2012/12/13/492
>
> Vivek Gautam (2):
>   ARM: Exynos5250: Enabling samsung-usbphy driver
>   ARM: Exynos5250: Enabling USB 3.0 phy for samsung-usbphy driver
>
>  arch/arm/boot/dts/exynos5250.dtsi   |   23 +++
>  arch/arm/mach-exynos/include/mach/map.h |1 +
>  arch/arm/mach-exynos/mach-exynos5-dt.c  |2 ++
>  3 files changed, 26 insertions(+), 0 deletions(-)
>
> --
> 1.7.6.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: sdio: Removing the unnecessary runtime_get/put in sdio_bus_remove()

[Chuansheng Liu]

The runtime_get_sync() is called during sdio_bus_probe(), then the device
will be kept in active runtime state, so not neccessary to call
runtime_get_sync/put_noidle() again in sdio_bus_remove().

Signed-off-by: liu chuansheng 
---
 drivers/mmc/core/sdio_bus.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index 5e57048..b576b70 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -167,10 +167,6 @@ static int sdio_bus_remove(struct device *dev)
struct sdio_func *func = dev_to_sdio_func(dev);
int ret = 0;
 
-   /* Make sure card is powered before invoking ->remove() */
-   if (func->card->host->caps & MMC_CAP_POWER_OFF_CARD)
-   pm_runtime_get_sync(dev);
-
drv->remove(func);
 
if (func->irq_handler) {
@@ -181,10 +177,6 @@ static int sdio_bus_remove(struct device *dev)
sdio_release_host(func);
}
 
-   /* First, undo the increment made directly above */
-   if (func->card->host->caps & MMC_CAP_POWER_OFF_CARD)
-   pm_runtime_put_noidle(dev);
-
/* Then undo the runtime PM settings in sdio_bus_probe() */
if (func->card->host->caps & MMC_CAP_POWER_OFF_CARD)
pm_runtime_put_sync(dev);
-- 
1.7.0.4



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

Re: [PATCH] usb: phy: samsung: Add support for USB 3.0 phy for exynos5250

[Vivek Gautam]

CC: Doug Anderson


On Tue, Dec 18, 2012 at 8:43 PM, Felipe Balbi  wrote:
> On Tue, Dec 18, 2012 at 08:40:26PM +0530, Vivek Gautam wrote:
>> Adding support for USB3.0 phy for dwc3 controller on
>> exynos5250 SOC.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>  drivers/usb/phy/samsung-usbphy.c |  339 
>> +-
>
> let's make the phy names standard from now on and call this
> phy-samsung.c :-)
>
>>  1 files changed, 337 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/phy/samsung-usbphy.c 
>> b/drivers/usb/phy/samsung-usbphy.c
>> index 621348a..246eb28 100644
>> --- a/drivers/usb/phy/samsung-usbphy.c
>> +++ b/drivers/usb/phy/samsung-usbphy.c
>> @@ -154,6 +154,86 @@
>>
>>  #define EXYNOS5_PHY_OTG_TUNE (0x40)
>>
>> +/* EXYNOS5: USB 3.0 DRD */
>> +#define EXYNOS5_DRD_LINKSYSTEM   (0x04)
>> +
>> +#define LINKSYSTEM_FLADJ_MASK(0x3f << 1)
>> +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1)
>> +#define LINKSYSTEM_XHCI_VERSION_CONTROL  (0x1 << 27)
>> +
>> +#define EXYNOS5_DRD_PHYUTMI  (0x08)
>> +
>> +#define PHYUTMI_OTGDISABLE   (0x1 << 6)
>> +#define PHYUTMI_FORCESUSPEND (0x1 << 1)
>> +#define PHYUTMI_FORCESLEEP   (0x1 << 0)
>> +
>> +#define EXYNOS5_DRD_PHYPIPE  (0x0c)
>> +
>> +#define EXYNOS5_DRD_PHYCLKRST(0x10)
>> +
>> +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23)
>> +#define PHYCLKRST_SSC_REFCLKSEL(_x)  ((_x) << 23)
>> +
>> +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21)
>> +#define PHYCLKRST_SSC_RANGE(_x)  ((_x) << 21)
>> +
>> +#define PHYCLKRST_SSC_EN (0x1 << 20)
>> +#define PHYCLKRST_REF_SSP_EN (0x1 << 19)
>> +#define PHYCLKRST_REF_CLKDIV2(0x1 << 18)
>> +
>> +#define PHYCLKRST_MPLL_MULTIPLIER_MASK   (0x7f << 11)
>> +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11)
>> +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x02 << 11)
>> +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF  (0x68 << 11)
>> +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF  (0x7d << 11)
>> +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF   (0x02 << 11)
>> +
>> +#define PHYCLKRST_FSEL_MASK  (0x3f << 5)
>> +#define PHYCLKRST_FSEL(_x)   ((_x) << 5)
>> +#define PHYCLKRST_FSEL_PAD_100MHZ(0x27 << 5)
>> +#define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5)
>> +#define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5)
>> +#define PHYCLKRST_FSEL_PAD_19_2MHZ   (0x38 << 5)
>> +
>> +#define PHYCLKRST_RETENABLEN (0x1 << 4)
>> +
>> +#define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2)
>> +#define PHYCLKRST_REFCLKSEL_PAD_REFCLK   (0x2 << 2)
>> +#define PHYCLKRST_REFCLKSEL_EXT_REFCLK   (0x3 << 2)
>> +
>> +#define PHYCLKRST_PORTRESET  (0x1 << 1)
>> +#define PHYCLKRST_COMMONONN  (0x1 << 0)
>> +
>> +#define EXYNOS5_DRD_PHYREG0  (0x14)
>> +#define EXYNOS5_DRD_PHYREG1  (0x18)
>> +
>> +#define EXYNOS5_DRD_PHYPARAM0(0x1c)
>> +
>> +#define PHYPARAM0_REF_USE_PAD(0x1 << 31)
>> +#define PHYPARAM0_REF_LOSLEVEL_MASK  (0x1f << 26)
>> +#define PHYPARAM0_REF_LOSLEVEL   (0x9 << 26)
>> +
>> +#define EXYNOS5_DRD_PHYPARAM1(0x20)
>> +
>> +#define PHYPARAM1_PCS_TXDEEMPH_MASK  (0x1f << 0)
>> +#define PHYPARAM1_PCS_TXDEEMPH   (0x1c)
>> +
>> +#define EXYNOS5_DRD_PHYTERM  (0x24)
>> +
>> +#define EXYNOS5_DRD_PHYTEST  (0x28)
>> +
>> +#define PHYTEST_POWERDOWN_SSP(0x1 << 3)
>> +#define PHYTEST_POWERDOWN_HSP(0x1 << 2)
>> +
>> +#define EXYNOS5_DRD_PHYADP   (0x2c)
>> +
>> +#define EXYNOS5_DRD_PHYBATCHG(0x30)
>> +
>> +#define PHYBATCHG_UTMI_CLKSEL(0x1 << 2)
>> +
>> +#define EXYNOS5_DRD_PHYRESUME(0x34)
>> +#define EXYNOS5_DRD_LINKPORT (0x44)
>> +
>>  #ifndef MHZ
>>  #define MHZ (1000*1000)
>>  #endif
>> @@ -164,6 +244,15 @@ enum samsung_cpu_type {
>>   TYPE_EXYNOS5250,
>>  };
>>
>> +/* structure usb3 - usb3.0 phy trasceiver state
>> + * @phy: transceiver structure for USB 3.0
>> + * @regs_phy: usb 3.0 phy register memory base
>> + */
>> +struct usb3 {
>> + struct usb_phy  phy;
>> + void __iomem*regs_phy;
>> +};
>> +
>>  /*
>>   * struct samsung_usbphy - transceiver driver state
>>   * @phy: transceiver structure
>> @@ -192,11 +281,15 @@ struct samsung_usbphy {
>>   u32 en_mask;
>>   int ref_clk_freq;
>>   int cpu_type;
>> + struct usb3 usb3phy;
>> + int has_usb3;
>>   enum 

Re: [PATCH v2] Adding USB 3.0 DRD-phy support for exynos5250

[Vivek Gautam]

CC: Doug Anderson.


On Tue, Dec 18, 2012 at 8:40 PM, Vivek Gautam  wrote:
> Changes form v1:
>  - Moved architecture related patch out of this patch-set.
>  - Replaced unnecessary multi-line macro definitions by
>single line definitions.
>  - Creating new data structure for USB 3.0 phy type and embedding
>it in 'samsung_usbphy' structure.
>  - Adding a flag in 'samsung_usbphy' structure to check if device
>has usb 3.0 type phy or not.
>  - Restructuring probe sequence for USB 3.0 phy, such that we are
>initializing only when device has usb3.0 type phy.
>
> This patchset is based on the following patch-sets:
>  - https://lkml.org/lkml/2012/12/18/201
>  - 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/134476.html
>  - https://lkml.org/lkml/2012/12/18/187
>
> Vivek Gautam (1):
>   usb: phy: samsung: Add support for USB 3.0 phy for exynos5250
>
>  drivers/usb/phy/samsung-usbphy.c |  339 
> +-
>  1 files changed, 337 insertions(+), 2 deletions(-)
>
> --
> 1.7.6.5
>
> --
> 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



-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] usb: phy: samsung: Add support to set pmu isolation

[Vivek Gautam]

CC: Doug Anderson


On Wed, Dec 19, 2012 at 4:49 AM, Sylwester Nawrocki
 wrote:
> Hi Vivek,
>
>
> On 12/18/2012 02:56 PM, Vivek Gautam wrote:
>>
>> Adding support to parse device node data in order to get
>> required properties to set pmu isolation for usb-phy.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>>
>> Changes from v1:
>>   - Changed the name of property for phy handler from'samsung,usb-phyctrl'
>> to 'samsung,usb-phyhandle' to make it look more generic.
>>   - Similarly 'samsung,phyctrl-reg' is changed to 'samsung,phyhandle-reg'
>>   - Added a check for 'samsung,usb-phyhandle' before getting node from
>> phandle.
>>   - Putting the node using 'of_node_put()' which had been missed.
>>   - Adding necessary check for the pointer in
>> 'samsung_usbphy_set_isolation()'
>> to avoid any NULL pointer dereferencing.
>>   - Unmapping the register ioremapped in
>> 'samsung_usbphy_parse_dt_param()'.
>>
>>
>>   .../devicetree/bindings/usb/samsung-usbphy.txt |   12 +++
>>   drivers/usb/phy/samsung-usbphy.c   |   94
>> ++--
>>   2 files changed, 98 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> index 7b26e2d..a7b28b2 100644
>> --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> @@ -9,3 +9,15 @@ Required properties:
>>   - compatible : should be "samsung,exynos4210-usbphy"
>>   - reg : base physical address of the phy registers and length of memory
>> mapped
>> region.
>> +
>> +Optional properties:
>> +- samsung,usb-phyhandle : should point to usb-phyhandle sub-node which
>> provides
>> +   binding data to enable/disable device PHY handled
>> by
>> +   PMU register.
>> +
>> +   Required properties:
>> +   - compatible : should be "samsung,usbdev-phyctrl"
>> for
>> +   DEVICE type phy.
>> +   - samsung,phyhandle-reg: base physical address of
>> +   PHY_CONTROL register in
>> PMU.
>> +- samsung,enable-mask : should be '1'
>
>
> This should only be 1 for Exynos4210+ SoCs, right ?
> S5PV210 uses bit 0 for OTG and bit1 for USB host, doesn't it ? And for
> s3c64xx
> it seems to be bit 16.
>
> How about deriving this information from 'compatible' property instead ?
>
> Maybe you could just encode the USB PMU registers (I assume those aren't
> touched by anything but the usb drivers) in a regular 'reg' property in
> an usbphy subnode. Then the driver could interpret it also with help
> of 'compatible' property. And you could just use of_iomap(). E.g.
>
>  usbphy@1213 {
> compatible = "samsung,exynos5250-usbphy";
> reg = <0x1213 0x100>, <0x1210 0x100>;
> usbphy-pmu {
> /* USB device and host PHY_CONTROL registers */
> reg = <0x10040704 8>;
> };
>  };
>
> Your "samsung,usb-phyhandle" approach seems over-engineered to me.
> I might be missing something though.
>
>
>> diff --git a/drivers/usb/phy/samsung-usbphy.c
>> b/drivers/usb/phy/samsung-usbphy.c
>> index 5c5e1bb5..4ceabe3 100644
>> --- a/drivers/usb/phy/samsung-usbphy.c
>> +++ b/drivers/usb/phy/samsung-usbphy.c
>> @@ -72,6 +72,8 @@ enum samsung_cpu_type {
>>* @dev: The parent device supplied to the probe function
>>* @clk: usb phy clock
>>* @regs: usb phy register memory base
>> + * @devctrl_reg: usb device phy-control pmu register memory base
>
>
> hum, this name is not really helpful in understanding what's going
> on here.
>
> Looking at arch/arm/mach-s5pv210/setup-usb-phy.c, there is only one
> PHY_CONTROL (Power Management Unit) register for both OTG and USB host
> PHYs. So are you really taking care of that case as well ?
>
>
>> + * @en_mask: enable mask
>>* @ref_clk_freq: reference clock frequency selection
>>* @cpu_type: machine identifier
>>*/
>> @@ -81,12 +83,73 @@ struct samsung_usbphy {
>> struct device   *dev;
>> struct clk  *clk;
>> void __iomem*regs;
>> +   void __iomem*devctrl_reg;
>> +   u32 en_mask;
>> int ref_clk_freq;
>> int cpu_type;
>>   };
>>
>>   #define phy_to_sphy(x)container_of((x), struct
>> samsung_usbphy, phy)
>>
>> +static int samsung_usbphy_parse_dt_param(struct samsung_usbphy *sphy)
>> +{
>> +   struct device_node *usb_phyctrl;
>> +   u32 reg;
>> +   int lenp;
>> +
>> +   if (!sphy->dev->of_node) {
>> +   sphy->devctrl_reg = NULL;
>> +   return -ENODEV;
>> +   }
>> +
>> +   if (of_get_property(sphy->dev->of_node,
>> "samsung,usb-phyhandle",)) {
>> +   usb_phyctrl = of_parse_phandle(sphy->dev->of_node,
>> + 

[RFC PATCH] Scripts: Add binary diff utility.

[Lv Zheng]

This utility is used as part of Linux ACPICA release process. It may be a
good idea to add it to kernel scripts, since it may be generally usefull for
verifying small kernel changes, like coding style cleanups etc.

Signed-off-by: Lv Zheng 
---
 scripts/diffvmlinux.sh |  227 
 1 file changed, 227 insertions(+)
 create mode 100755 scripts/diffvmlinux.sh

Index: linux-pm/scripts/diffvmlinux.sh
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-pm/scripts/diffvmlinux.sh 2012-12-19 13:40:21.0 +0800
@@ -0,0 +1,226 @@
+#!/bin/sh
+#
+# Copyright (c) 2012, Intel Corporation
+# Author: Lv Zheng 
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation; version 2 of the License.
+#
+# NAME
+#   diffvmlinux.sh - Generating vmlinux assembly differences before/after
+#applying a quilt patch
+# SYNOPSIS
+#   diffvmlinux.sh [-f assembly-diff] [-p patch-file] [-o object-file]
+#  
+
+
+# FIXME: More Useless Sections
+#
+# Please add other sections that would appear as executable but should get
+# removed for the comparision.
+USELESS_SECTIONS=".notes"
+
+fulldir() {
+   lpath=$1
+   (
+   cd $lpath; pwd
+   )
+}
+
+getdir() {
+   lpath=`dirname $1`
+   fulldir $lpath
+}
+
+fatal() {
+   echo $1
+   exit -1
+}
+
+usage() {
+   echo "Usage: `basename $0` [-p patch] "
+   echo "Where:"
+   echo " linux: Specify the linux source tree."
+   echo " patch: Specify the patch file name."
+}
+
+fatal_usage() {
+   usage
+   exit -1
+}
+
+quilt_applied() {
+   c=$1
+   applied_patches=`quilt applied 2>/dev/null`
+
+   for a in $applied_patches; do
+   if [ "x$a" = "x$c" ]; then
+   return 0
+   fi
+   done
+   return -1
+}
+
+remove_sections() {
+   binary2=$1
+   binary3=$2
+
+   for section in $USELESS_SECTIONS; do
+   echo "Removing $section section..."
+   objcopy -R $section $binary2 $binary3
+   mv $binary3 $binary2
+   done
+}
+
+quilt_push() {
+   quilt push > /dev/null || fatal "failed to push quilt stack"
+}
+
+quilt_pop() {
+   quilt pop > /dev/null || fatal "failed to pop quilt stack"
+}
+
+detect_patch() {
+   quilt_push
+   detected_patches=`quilt applied 2>/dev/null`
+   quilt_pop
+   for d in $detected_patches; do
+   quilt_applied $d || echo $d
+   done
+}
+
+quilt_forward() {
+   l=$1
+   patches=`quilt unapplied 2>/dev/null`
+   for i in $patches; do
+   quilt_push
+   quilt_applied $l
+   if [ $? -eq 0 ]; then
+   quilt_pop
+   return 0;
+   fi
+   done
+   fatal "Cannot find $locate in the unapplied patches."
+}
+
+quilt_backward() {
+   l=$1
+   patches=`quilt applied 2>/dev/null`
+   for i in $patches; do
+   quilt_pop
+   quilt_applied $l || return 0
+   done
+   fatal "Cannot find $locate in the applied patches."
+}
+
+locate_patch() {
+   t=$1
+   quilt_applied $t
+   if [ $? -eq 0 ]; then
+   echo "Locating $t in the applied patches..."
+   quilt_backward $t
+   else
+   echo "Locating $t in the unapplied patches..."
+   quilt_forward $t
+   fi
+}
+
+while getopts "f:p:o:" opt
+do
+   case $opt in
+   f) ASMDIFF=$OPTARG;;
+   o) BINARY=$OPTARG;;
+   p) PATCH=$OPTARG;;
+   ?) echo "Invalid argument $opt"
+  fatal_usage;;
+   esac
+done
+shift $(($OPTIND - 1))
+
+if [ "x$1" = "x" ]; then
+   echo "Missing  paraemter."
+   fatal_usage
+fi
+
+CURDIR=`pwd`
+LINUX=`getdir $1`
+LINUX_BASE=`basename $LINUX`/vmlinux
+AFTER=$CURDIR/after.dump
+BEFORE=$CURDIR/before.dump
+
+if [ "x$BINARY" = "x" ]; then
+   BINARY=vmlinux
+fi
+echo "Diffing $BINARY..."
+BINARY0=$LINUX/$BINARY
+BINARY1=$LINUX/diffvmlinux
+BINARY2=$LINUX/diffvmlinux-nosections
+BINARY3=$LINUX/diffvmlinux-nosection
+
+# Prepare quilt stack
+if [ "x$PATCH" != "x" ]; then
+   echo "Locating patch $PATCH..."
+   locate_patch $PATCH
+else
+   PATCH=`detect_patch`
+   echo "Detected patch $PATCH."
+fi
+if [ "x$PATCH" = "x" ]; then
+   echo "Missing patch file"
+   fatal_usage
+fi
+
+# Allow overloading of ASMDIFF
+if [ "x$ASMDIFF" = "x" ]; then
+   ASMDIFF=$CURDIR/bin.diff
+fi
+
+(
+   cd $LINUX
+
+   # Assertion in case the above locating/detecting failed.
+   quilt_applied $PATCH && fatal "patch $PATCH should not be applied"
+   quilt_push
+   quilt_applied $PATCH || fatal "patch $PATCH should be the next patch"
+   quilt_pop
+
+   

Re: [PATCH v5 3/4] USB: ehci-s5p: Add phy driver support

[Vivek Gautam]

CC: Doug Anderson.


On Tue, Dec 18, 2012 at 8:13 PM, Vivek Gautam  wrote:
> Adding the phy driver to ehci-s5p. Keeping the platform data
> for continuing the smooth operation for boards which still uses it
>
> Signed-off-by: Vivek Gautam 
> Acked-by: Jingoo Han 
> ---
>  drivers/usb/host/ehci-s5p.c |   70 
> ++-
>  1 files changed, 49 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index 46ca5ef..50c93af 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -33,6 +34,8 @@ struct s5p_ehci_hcd {
> struct device *dev;
> struct usb_hcd *hcd;
> struct clk *clk;
> +   struct usb_phy *phy;
> +   struct s5p_ehci_platdata *pdata;
>  };
>
>  static const struct hc_driver s5p_ehci_hc_driver = {
> @@ -66,6 +69,30 @@ static const struct hc_driver s5p_ehci_hc_driver = {
> .clear_tt_buffer_complete   = ehci_clear_tt_buffer_complete,
>  };
>
> +static void s5p_ehci_phy_enable(struct s5p_ehci_hcd *s5p_ehci)
> +{
> +   struct platform_device *pdev = to_platform_device(s5p_ehci->dev);
> +
> +   if (s5p_ehci->phy) {
> +   samsung_usbphy_set_type(s5p_ehci->phy, USB_PHY_TYPE_HOST);
> +   usb_phy_init(s5p_ehci->phy);
> +   } else if (s5p_ehci->pdata->phy_init) {
> +   s5p_ehci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
> +   }
> +}
> +
> +static void s5p_ehci_phy_disable(struct s5p_ehci_hcd *s5p_ehci)
> +{
> +   struct platform_device *pdev = to_platform_device(s5p_ehci->dev);
> +
> +   if (s5p_ehci->phy) {
> +   samsung_usbphy_set_type(s5p_ehci->phy, USB_PHY_TYPE_HOST);
> +   usb_phy_shutdown(s5p_ehci->phy);
> +   } else if (s5p_ehci->pdata->phy_exit) {
> +   s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
> +   }
> +}
> +
>  static void s5p_setup_vbus_gpio(struct platform_device *pdev)
>  {
> int err;
> @@ -88,20 +115,15 @@ static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
>
>  static int s5p_ehci_probe(struct platform_device *pdev)
>  {
> -   struct s5p_ehci_platdata *pdata;
> +   struct s5p_ehci_platdata *pdata = pdev->dev.platform_data;
> struct s5p_ehci_hcd *s5p_ehci;
> struct usb_hcd *hcd;
> struct ehci_hcd *ehci;
> struct resource *res;
> +   struct usb_phy *phy;
> int irq;
> int err;
>
> -   pdata = pdev->dev.platform_data;
> -   if (!pdata) {
> -   dev_err(>dev, "No platform data defined\n");
> -   return -EINVAL;
> -   }
> -
> /*
>  * Right now device-tree probed devices don't get dma_mask set.
>  * Since shared usb code relies on it, set it here for now.
> @@ -119,6 +141,19 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> if (!s5p_ehci)
> return -ENOMEM;
>
> +   phy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
> +   if (IS_ERR_OR_NULL(phy)) {
> +   /* Fallback to pdata */
> +   if (!pdata) {
> +   dev_err(>dev, "no platform data or transceiver 
> defined\n");
> +   return -EPROBE_DEFER;
> +   } else {
> +   s5p_ehci->pdata = pdata;
> +   }
> +   } else {
> +   s5p_ehci->phy = phy;
> +   }
> +
> s5p_ehci->dev = >dev;
>
> hcd = usb_create_hcd(_ehci_hc_driver, >dev,
> @@ -164,8 +199,7 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> goto fail_io;
> }
>
> -   if (pdata->phy_init)
> -   pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
> +   s5p_ehci_phy_enable(s5p_ehci);
>
> ehci = hcd_to_ehci(hcd);
> ehci->caps = hcd->regs;
> @@ -176,13 +210,15 @@ static int s5p_ehci_probe(struct platform_device *pdev)
> err = usb_add_hcd(hcd, irq, IRQF_SHARED);
> if (err) {
> dev_err(>dev, "Failed to add USB HCD\n");
> -   goto fail_io;
> +   goto fail_add_hcd;
> }
>
> platform_set_drvdata(pdev, s5p_ehci);
>
> return 0;
>
> +fail_add_hcd:
> +   s5p_ehci_phy_disable(s5p_ehci);
>  fail_io:
> clk_disable_unprepare(s5p_ehci->clk);
>  fail_clk:
> @@ -192,14 +228,12 @@ fail_clk:
>
>  static int s5p_ehci_remove(struct platform_device *pdev)
>  {
> -   struct s5p_ehci_platdata *pdata = pdev->dev.platform_data;
> struct s5p_ehci_hcd *s5p_ehci = platform_get_drvdata(pdev);
> struct usb_hcd *hcd = s5p_ehci->hcd;
>
> usb_remove_hcd(hcd);
>
> -   if (pdata && pdata->phy_exit)
> -   pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
> +   s5p_ehci_phy_disable(s5p_ehci);
>
> clk_disable_unprepare(s5p_ehci->clk);
>
> @@ -223,14 +257,11 @@ static int 

RE: [PATCH] usb: phy: tegra: Using devm API for memory allocation

[Venu Byravarasu]

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Tuesday, December 18, 2012 10:03 PM
> To: Venu Byravarasu
> Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] usb: phy: tegra: Using devm API for memory allocation
> 
> On 12/17/2012 11:21 PM, Venu Byravarasu wrote:
> > Using devm_kzalloc for allocating memory needed for PHY
> > pointer and hence removing kfree calls to PHY pointer.
> 
> Since the kfree() here used to be in tegra_usb_phy_close() rather than
> any remove() function, does it actually make sense to use
> devm_kzalloc(); would plain using kzalloc() instead, and not removing
> the kfree() calls, be better?
> 
 
Stephen,
As you mentioned I can replace kmalloc with kzalloc in the original code 
and push an updated patch.
However, I just wanted to understand if there exists any issue
in using devm_kzalloc instead of kzalloc?

> When the PHY code gets converted to be an actual probed driver, then
> perhaps using devm will make sense.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 RFC 1/2] sched: Bail out of yield_to when source and target runqueue has one task

[Raghavendra K T]

[I forgot to do TO to Ingo last time]

Ingo,
 Could you please take this into x86 tree.
This is
Acked-by: Andrew Jones 
Tested-by: Chegu Vinod 

Marcelo, do you want to add your Acked-by/Reviewed-by?

On 12/14/2012 09:10 PM, Raghavendra K T wrote:

Hi Ingo,

Could you please take this into x86 tree?

Thanks,
On 12/14/2012 05:59 AM, Marcelo Tosatti wrote:

Raghavendra,

Please get this integrate through x86 tree (Ingo CC'ed).

On Mon, Nov 26, 2012 at 05:37:54PM +0530, Raghavendra K T wrote:

From: Peter Zijlstra 

In case of undercomitted scenarios, especially in large guests
yield_to overhead is significantly high. when run queue length of
source and target is one, take an opportunity to bail out and return
-ESRCH. This return condition can be further exploited to quickly come
out of PLE handler.

(History: Raghavendra initially worked on break out of kvm ple
handler upon
  seeing source runqueue length = 1, but it had to export rq length).
  Peter came up with the elegant idea of return -ESRCH in scheduler
core.

Signed-off-by: Peter Zijlstra 
Raghavendra, Checking the rq length of target vcpu condition
added.(thanks Avi)
Reviewed-by: Srikar Dronamraju 
Signed-off-by: Raghavendra K T 
---

  kernel/sched/core.c |   25 +++--
  1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2d8927f..fc219a5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4289,7 +4289,10 @@ EXPORT_SYMBOL(yield);
   * It's the caller's job to ensure that the target task struct
   * can't go away on us before we can do any checks.
   *
- * Returns true if we indeed boosted the target task.
+ * Returns:
+ *true (>0) if we indeed boosted the target task.
+ *false (0) if we failed to boost the target.
+ *-ESRCH if there's no task to yield to.
   */
  bool __sched yield_to(struct task_struct *p, bool preempt)
  {
@@ -4303,6 +4306,15 @@ bool __sched yield_to(struct task_struct *p,
bool preempt)

  again:
  p_rq = task_rq(p);
+/*
+ * If we're the only runnable task on the rq and target rq also
+ * has only one task, there's absolutely no point in yielding.
+ */
+if (rq->nr_running == 1 && p_rq->nr_running == 1) {
+yielded = -ESRCH;
+goto out_irq;
+}
+
  double_rq_lock(rq, p_rq);
  while (task_rq(p) != p_rq) {
  double_rq_unlock(rq, p_rq);
@@ -4310,13 +4322,13 @@ again:
  }

  if (!curr->sched_class->yield_to_task)
-goto out;
+goto out_unlock;

  if (curr->sched_class != p->sched_class)
-goto out;
+goto out_unlock;

  if (task_running(p_rq, p) || p->state)
-goto out;
+goto out_unlock;

  yielded = curr->sched_class->yield_to_task(rq, p, preempt);
  if (yielded) {
@@ -4329,11 +4341,12 @@ again:
  resched_task(p_rq->curr);
  }

-out:
+out_unlock:
  double_rq_unlock(rq, p_rq);
+out_irq:
  local_irq_restore(flags);

-if (yielded)
+if (yielded > 0)
  schedule();

  return yielded;

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html








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

Re: [patch 1/8] mm: memcg: only evict file pages when we have plenty

[Simon Jeons]

On Mon, 2012-12-17 at 16:54 +0100, Michal Hocko wrote:
> On Sun 16-12-12 09:21:54, Simon Jeons wrote:
> > On 12/13/2012 10:55 PM, Michal Hocko wrote:
> > >On Wed 12-12-12 17:28:44, Johannes Weiner wrote:
> > >>On Wed, Dec 12, 2012 at 04:53:36PM -0500, Rik van Riel wrote:
> > >>>On 12/12/2012 04:43 PM, Johannes Weiner wrote:
> > dc0422c "mm: vmscan: only evict file pages when we have plenty" makes
> > a point of not going for anonymous memory while there is still enough
> > inactive cache around.
> > 
> > The check was added only for global reclaim, but it is just as useful
> > for memory cgroup reclaim.
> > 
> > Signed-off-by: Johannes Weiner 
> > ---
> >   mm/vmscan.c | 19 ++-
> >   1 file changed, 10 insertions(+), 9 deletions(-)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 157bb11..3874dcb 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1671,6 +1671,16 @@ static void get_scan_count(struct lruvec 
> > *lruvec, struct scan_control *sc,
> > denominator = 1;
> > goto out;
> > }
> > +   /*
> > +* There is enough inactive page cache, do not reclaim
> > +* anything from the anonymous working set right now.
> > +*/
> > +   if (!inactive_file_is_low(lruvec)) {
> > +   fraction[0] = 0;
> > +   fraction[1] = 1;
> > +   denominator = 1;
> > +   goto out;
> > +   }
> > 
> > anon  = get_lru_size(lruvec, LRU_ACTIVE_ANON) +
> > get_lru_size(lruvec, LRU_INACTIVE_ANON);
> > @@ -1688,15 +1698,6 @@ static void get_scan_count(struct lruvec 
> > *lruvec, struct scan_control *sc,
> > fraction[1] = 0;
> > denominator = 1;
> > goto out;
> > -   } else if (!inactive_file_is_low_global(zone)) {
> > -   /*
> > -* There is enough inactive page cache, do not
> > -* reclaim anything from the working set right 
> > now.
> > -*/
> > -   fraction[0] = 0;
> > -   fraction[1] = 1;
> > -   denominator = 1;
> > -   goto out;
> > }
> > }
> > 
> > 
> > >>>I believe the if() block should be moved to AFTER
> > >>>the check where we make sure we actually have enough
> > >>>file pages.
> > >>You are absolutely right, this makes more sense.  Although I'd figure
> > >>the impact would be small because if there actually is that little
> > >>file cache, it won't be there for long with force-file scanning... :-)
> > >Yes, I think that the result would be worse (more swapping) so the
> > >change can only help.
> > >
> > >>I moved the condition, but it throws conflicts in the rest of the
> > >>series.  Will re-run tests, wait for Michal and Mel, then resend.
> > >Yes the patch makes sense for memcg as well. I guess you have tested
> > >this primarily with memcg. Do you have any numbers? Would be nice to put
> > >them into the changelog if you have (it should help to reduce swapping
> > >with heavy streaming IO load).
> > >
> > >Acked-by: Michal Hocko 
> > 
> > Hi Michal,
> > 
> > I still can't understand why "The goto out means that it should be
> > fine either way.",
> 
> Not sure I understand your question. goto out just says that either page
> cache is low or inactive file LRU is too small. And it works for both
> memcg and global because the page cache is low condition is evaluated
> only for the global reclaim and always before inactive file is small.
> Makes more sense?

Hi Michal,

I confuse of Gorman's comments below, why the logic change still fine.  

Current
  low_file  inactive_is_highforce reclaim anon
  low_file  !inactive_is_high   force reclaim anon
  !low_file inactive_is_highforce reclaim file
  !low_file !inactive_is_high   normal split

Your patch

  low_file  inactive_is_highforce reclaim anon
  low_file  !inactive_is_high   force reclaim anon
  !low_file inactive_is_highforce reclaim file
  !low_file !inactive_is_high   normal split

However, if you move the inactive_file_is_low check down you get

Moving the check
  low_file  inactive_is_highforce reclaim file
  low_file  !inactive_is_high   force reclaim anon
  !low_file inactive_is_highforce reclaim file
  !low_file !inactive_is_high   normal split

> 
> > could you explain to me, sorry for my stupid. :-)
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH] timekeeping: avoid adjust kernel time once hwclock kept in UTC time

[Dong Zhu]

On Thu, Dec 06, 2012 at 10:03:34PM +0800, Dong Zhu wrote:
> From c126376cf1837b0956e0268056db61870fbbc1d4 Mon Sep 17 00:00:00 2001
> From: Dong Zhu 
> Date: Thu, 6 Dec 2012 21:45:00 +0800
> Subject: [PATCH] timekeeping: avoid adjust kernel time once hwclock kept in
>  UTC time
> 
> If the Hardware Clock kept in local time,kernel will adjust the time
> to be UTC time.But if Hardware Clock kept in UTC time,system will make
> a dummy settimeofday call first (sys_tz.tz_minuteswest = 0) to make sure
> the time is not shifted,so at this point I think maybe it is not necessary
> to set the kernel time once the sys_tz.tz_minuteswest is zero.
> 
> Signed-off-by: Dong Zhu 
> ---
>  kernel/time.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/time.c b/kernel/time.c
> index d226c6a..0b592ce 100644
> --- a/kernel/time.c
> +++ b/kernel/time.c
> @@ -134,9 +134,11 @@ static inline void warp_clock(void)
>  {
>   struct timespec adjust;
>  
> - adjust = current_kernel_time();
> - adjust.tv_sec += sys_tz.tz_minuteswest * 60;
> - do_settimeofday();
> + if (sys_tz.tz_minuteswest) {
> + adjust = current_kernel_time();
> + adjust.tv_sec += sys_tz.tz_minuteswest * 60;
> + do_settimeofday();
> + }
>  }
>  
>  /*
> -- 
> 1.7.11.7
> 

Hi,

Any comments ? 

-- 
Best Regards,
Dong Zhu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 4/4] uprobes/powerpc: Make use of generic routines to enable single step

[Ananth N Mavinakayanahalli]

On Tue, Dec 18, 2012 at 08:10:13PM +0100, Oleg Nesterov wrote:
> On 12/18, Ananth N Mavinakayanahalli wrote:
> >
> > On Fri, Dec 14, 2012 at 09:02:41PM +0100, Oleg Nesterov wrote:
> > > >
> > > > -   uprobe_restore_context_sstep(>autask);
> > > > +   uprobe_restore_context_sstep(>autask, regs);
> > >
> > > I am not sure ppc needs this, but note that x86 does a bit more.
> > >
> > > Not only we need to restore the "single-step" state, we need to
> > > send SIGTRAP if it was not set by us. The same for _skip_sstep.
> >
> > Do you mean restoring the TF equivalent on powerpc to what it was before?
> >
> > If so, powerpc has always been unique in this aspect -- the single-step
> > exception handler *always* resets the sstep bit in MSR. Any user needing
> > to continue single-stepping has to explicitly set it again.
> 
> I meant another thing.
> 
> Suppose that, say, gdb tries to single-step over the probed insn.
> In this case we need to send SIGTRAP after xol/emulate. Please look at
> send_sig(SIGTRAP) in arch/x86/kernel/uprobes.c:arch_uprobe_post_xol()
> and arch_uprobe_skip_sstep().

Agreed. Thanks for the clarification Oleg.

Ananth

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

Re: + core_pattern-set-core-helpers-root-and-namespace-to-crashing-process .patch added to -mm tree

[Eric W. Biederman]

Neil Horman  writes:

> On Tue, Dec 18, 2012 at 12:45:18PM -0800, Eric W. Biederman wrote:

>> The code for setns to change the pid namespace just merged.
>> 
> Can you post a link to the merge commit for reference so I can take a look at
> it?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6a2b60b17b3e48a418695a94bd2420f6ab32e519

>> If we just want one pattern we should be able to to robustly implement
>> this in userspace with the existing functionality.  With the caveat that
>> we need to get some pid namespace and user namespace bugs in the core
>> pattern generation fixed.  But we need to fix those bugs anyway.
>> 
> Then perhaps the right thing to do here is in fact just make core_pattern a
> per-namespace sysctl.  I only took a brief look, but I was unable to find an
> example of such a per-namespace systctl.  Do we already have the 
> infrastructure
> to do such a thing?  I didn't think we did.

We do have the infrastructure for a per namespace sysctls.  Right now we
only have per network namespace sysctls.  It is on my wish list to use
the infrastructure a little more extensively and convert /proc/sys into
a symlink to /proc//sys and reduce the amount of magic in /proc for
sysctls.

We also have per namespace sysctls that do magic based upon current.
Since that pattern is has more magic I don't recommend it over the long
term.

Of course there is the question which namespace the sysctl should be
tied to, and what the other namespaces should be set to.  Shrug.

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 0/7] Updates for Zynq's timer driver

[Soren Brinkmann]

Hi Josh,

On Tue, Dec 18, 2012 at 08:59:45PM -0600, Josh Cartwright wrote:
> On Tue, Dec 18, 2012 at 04:16:32PM -0800, Soren Brinkmann wrote:
> > I started to put some effort on syncing the Xilinx Linux tree with mainline 
> > and
> > the timer driver is my first victim.
> > Most commits are fixing style issues or clean up. Functionality is touched 
> > only
> > in patches #2 and #7.
> > 
> > Some patches are present in almost identically in the Xilinx Linux tree and 
> > I
> > took over 'Ackec-by' lines from those commits.
> > 
> > Soren
> > 
> > Soren Brinkmann (7):
> >   arm: zynq: timer: Replace PSS through PS
> >   arm: zynq: timer: Remove unnecessary register write
> >   arm: zynq: timer: Remove unused #defines
> >   arm: zynq: timer: Align columns
> >   arm: zynq: timer: Remove redundant #includes
> >   arm: zynq: timer: Fix comment style
> >   arm: zynq: timer: Set clock_event cpumask
> 
> Hey Soren-
> 
> I had a look through this patchset and besides the stylistic nit in
> patch 1, everything looks good to me.  Feel free to add my Reviewed-by.
> 
> Also, you seem to have neglected linux-arm-kernel from CC, you'll likely
> want to repost there.
Thanks, for reviewing and the heads up. I'll add the reviewed-by lines and
repost including linux-arm-kernel.

Soren


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

Re: [PATCH 1/7] arm: zynq: timer: Replace PSS through PS

[Soren Brinkmann]

Hi Josh,

On Tue, Dec 18, 2012 at 08:31:20PM -0600, Josh Cartwright wrote:
> On Tue, Dec 18, 2012 at 04:16:33PM -0800, Soren Brinkmann wrote:
> > The acronym PSS is deprecated by Xilinx. The correct term, which is
> > also used in Xilinx documentation is PS (processing system).
> > This is just a search and replace:
> >  - s/PSS/PS/g
> >  - s/pss/ps/g
> > 
> > Signed-off-by: Soren Brinkmann 
> [..]
> > --- a/arch/arm/mach-zynq/timer.c
> > +++ b/arch/arm/mach-zynq/timer.c
> > @@ -35,17 +35,17 @@
> >   * Timer Register Offset Definitions of Timer 1, Increment base address by 
> > 4
> >   * and use same offsets for Timer 2
> >   */
> > -#define XTTCPSS_CLK_CNTRL_OFFSET   0x00 /* Clock Control Reg, RW */
> > -#define XTTCPSS_CNT_CNTRL_OFFSET   0x0C /* Counter Control Reg, RW */
> > -#define XTTCPSS_COUNT_VAL_OFFSET   0x18 /* Counter Value Reg, RO */
> > -#define XTTCPSS_INTR_VAL_OFFSET0x24 /* Interval Count Reg, RW 
> > */
> > -#define XTTCPSS_MATCH_1_OFFSET 0x30 /* Match 1 Value Reg, RW */
> > -#define XTTCPSS_MATCH_2_OFFSET 0x3C /* Match 2 Value Reg, RW */
> > -#define XTTCPSS_MATCH_3_OFFSET 0x48 /* Match 3 Value Reg, RW */
> > -#define XTTCPSS_ISR_OFFSET 0x54 /* Interrupt Status Reg, RO */
> > -#define XTTCPSS_IER_OFFSET 0x60 /* Interrupt Enable Reg, RW */
> > -
> > -#define XTTCPSS_CNT_CNTRL_DISABLE_MASK 0x1
> > +#define XTTCPS_CLK_CNTRL_OFFSET0x00 /* Clock Control Reg, RW */
> > +#define XTTCPS_CNT_CNTRL_OFFSET0x0C /* Counter Control Reg, RW */
> > +#define XTTCPS_COUNT_VAL_OFFSET0x18 /* Counter Value Reg, RO */
> > +#define XTTCPS_INTR_VAL_OFFSET 0x24 /* Interval Count Reg, RW 
> > */
> > +#define XTTCPS_MATCH_1_OFFSET  0x30 /* Match 1 Value Reg, RW */
> > +#define XTTCPS_MATCH_2_OFFSET  0x3C /* Match 2 Value Reg, RW */
> > +#define XTTCPS_MATCH_3_OFFSET  0x48 /* Match 3 Value Reg, RW */
> > +#define XTTCPS_ISR_OFFSET  0x54 /* Interrupt Status Reg, RO */
> > +#define XTTCPS_IER_OFFSET  0x60 /* Interrupt Enable Reg, RW */
> > +
> > +#define XTTCPS_CNT_CNTRL_DISABLE_MASK  0x1
> >  
> >  /* Setup the timers to use pre-scaling, using a fixed value for now that 
> > will
> >   * work across most input frequency, but it may need to be more dynamic
> > @@ -57,72 +57,72 @@
> >  #define CNT_CNTRL_RESET(1<<4)
> >  
> >  /**
> > - * struct xttcpss_timer - This definition defines local timer structure
> > + * struct xttcps_timer - This definition defines local timer structure
> >   *
> >   * @base_addr: Base address of timer
> >   **/
> > -struct xttcpss_timer {
> > +struct xttcps_timer {
> > void __iomem*base_addr;
> >  };
> >  
> > -struct xttcpss_timer_clocksource {
> > -   struct xttcpss_timerxttc;
> > +struct xttcps_timer_clocksource {
> > +   struct xttcps_timer xttc;
> > struct clocksource  cs;
> >  };
> >  
> > -#define to_xttcpss_timer_clksrc(x) \
> > -   container_of(x, struct xttcpss_timer_clocksource, cs)
> > +#define to_xttcps_timer_clksrc(x) \
> > +   container_of(x, struct xttcps_timer_clocksource, cs)
> >  
> > -struct xttcpss_timer_clockevent {
> > -   struct xttcpss_timerxttc;
> > +struct xttcps_timer_clockevent {
> > +   struct xttcps_timer xttc;
> > struct clock_event_device   ce;
> > struct clk  *clk;
> >  };
> >  
> > -#define to_xttcpss_timer_clkevent(x) \
> > -   container_of(x, struct xttcpss_timer_clockevent, ce)
> > +#define to_xttcps_timer_clkevent(x) \
> > +   container_of(x, struct xttcps_timer_clockevent, ce)
> >  
> >  /**
> > - * xttcpss_set_interval - Set the timer interval value
> > + * xttcps_set_interval - Set the timer interval value
> >   *
> >   * @timer: Pointer to the timer instance
> >   * @cycles:Timer interval ticks
> >   **/
> > -static void xttcpss_set_interval(struct xttcpss_timer *timer,
> > +static void xttcps_set_interval(struct xttcps_timer *timer,
> > unsigned long cycles)
> 
> Stylistic nit, but if we're going to be making cosmetic changes of this
> sort, I'd personally like to see the arguments lined up properly:
> 
> static void xttcps_set_interval(struct xttcps_timer *timer,
>   unsigned long cycles)
I actually don't like that because it's rather high maintenance to align
arguments like this - and keeping them that way. I usually rely on vim with
smartindent set to produce reasonable indent levels.

And reviewing the coding guideline, I'd even say it's not encouraged:
"Descendants are always substantially shorter than the parent and
are placed substantially to the right. The same applies to function
headers with a long argument list."

Thanks,
Soren


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org

Re: [PATCH] [RFC] cpufreq: can't raise max frequency with cpu_thermal

[amit daniel kachhap]

On Tue, Dec 18, 2012 at 12:29 AM, Sonny Rao  wrote:
> The cpu_thermal generic thermal management code has a bug where once
> max cpu frequency has been lowered in sysfs (scaling_max_freq) it is
> not possible to raise the max back up later.  The bug is that the
> notifer gets called by __cpufreq_set_policy() before the user policy
> max is raised, and is incorrectly trying to enforce the max frequency
> policy even when we are trying to change the policy.  It is also not
> clear why this driver is looking at the user policy since it is
> primarily supposed to enforce thermal policy, not user set policy.

Hi Sunny,

I am not sure if this change is needed.
There is a check in cpufreq_thermal_notifier function to return 0 if
notify_device == NOTIFY_INVALID. So the user will be always able to
change the max frequency in normal situation. Did you tested this for
some corner cases?
The reason behind putting this check is that I don't want to override
the user constraints.

Thanks,
Amit Daniel

>
> Signed-off-by: Sonny Rao 
> ---
>  drivers/thermal/cpu_cooling.c |4 
>  1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 836828e..63bc708 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -219,10 +219,6 @@ static int cpufreq_thermal_notifier(struct 
> notifier_block *nb,
> if (cpumask_test_cpu(policy->cpu, _device->allowed_cpus))
> max_freq = notify_device->cpufreq_val;
>
> -   /* Never exceed user_policy.max*/
> -   if (max_freq > policy->user_policy.max)
> -   max_freq = policy->user_policy.max;
> -
> if (policy->max != max_freq)
> cpufreq_verify_within_limits(policy, 0, max_freq);
>
> --
> 1.7.7.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v5 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

[Kukjin Kim]

Cho KyoungHo wrote:
> 
> The current exynos-iommu(System MMU) driver does not work
> autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is
> disabled
> before MFC block is power-down not to invalidate IOTLB in the System MMU
> when I/O memory mapping is changed. Because A System MMU is resides in
> the
> same H/W block, access to control registers of System MMU while the H/W
> block is turned off must be prohibited.
> 
> This set of changes solves the above problem with setting each System
> MMUs
> as the parent of the device which owns the System MMU to receive the
> information when the device is turned off or turned on.
> 
> Another big change to the driver is the support for devicetree.
> The bindings for System MMU is described in
> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
> 
> In addition, this patchset also includes several bug fixes and
enhancements
> of the current driver.
> 
> Change log:
> v5:
> - new bugfix: patch 01
> - Reordered patches
>   * patch 01 ~ 05: Bugfix and enhancements of the existing driver
>   * patch 06 ~ 10: Device Tree support and callbacks for power management
>   * patch 11 : System MMU 3.2 and 3.3 support
>   * patch 12 ~ 14: Debugging features
> - Additional code compaction
> 
> v4:
> - Remove Change-Id from v3 patches
> - Change the order of the third and the first patch
>   Thanks to Kukjin Kim.
> - Fix memory leak when allocating and assigning exynos_iommu_owner to
> client
>   device if the client device has multiple System MMUs.
>   Thanks to Rahul Sharma.
> 
> v3:
> - Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
> - Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
>   Thanks to Prathyush.
> 
> v2:
> - Split the patch to iommu/exynos into 9 patches
> - Support for System MMU 3.3
> - Some code compaction
> 
> Patch summary:
> [PATCH v5 01/14] iommu/exynos: add missing cache flush for removed
> pagetable entries
> [PATCH v5 02/14] iommu/exynos: always use iommu fault handler
> [PATCH v5 03/14] iommu/exynos: allocate lv2 page table from own slab
> [PATCH v5 04/14] iommu/exynos: change rwlock to spinlock
> [PATCH v5 05/14] ARM: EXYNOS: Add clk_ops for gating clocks of System
> MMU
> [PATCH v5 06/14] ARM: EXYNOS: add System MMU definition to DT
> [PATCH v5 07/14] iommu/exynos: support for device tree
> [PATCH v5 08/14] iommu/exynos: set System MMU as the parent of client
> device
> [PATCH v5 09/14] ARM: EXYNOS: remove system mmu initialization from
> exynos tree
> [PATCH v5 10/14] iommu/exynos: add support for runtime pm and
> suspend/resume
> [PATCH v5 11/14] iommu/exynos: add support for System MMU 3.2 and 3.3
> [PATCH v5 12/14] iommu/exynos: pass version information from DT
> [PATCH v5 13/14] iommu/exynos: add literal name of System MMU for
> debugging
> [PATCH v5 14/14] iommu/exynos: add debugfs entries for System MMU
> 
> Diffstats:
>  .../devicetree/bindings/arm/exynos/system-mmu.txt  |   86 ++
>  arch/arm/boot/dts/exynos4210.dtsi  |   96 ++
>  arch/arm/boot/dts/exynos4x12.dtsi  |  124 ++
>  arch/arm/boot/dts/exynos5250.dtsi  |  154 +-
>  arch/arm/mach-exynos/Kconfig   |5 -
>  arch/arm/mach-exynos/Makefile  |1 -
>  arch/arm/mach-exynos/clock-exynos4.c   |   41 +-
>  arch/arm/mach-exynos/clock-exynos4210.c|9 +-
>  arch/arm/mach-exynos/clock-exynos4212.c|   23 +-
>  arch/arm/mach-exynos/clock-exynos5.c   |   86 +-
>  arch/arm/mach-exynos/dev-sysmmu.c  |  274 
>  arch/arm/mach-exynos/include/mach/sysmmu.h |   66 -
>  arch/arm/mach-exynos/mach-exynos4-dt.c |   34 +
>  arch/arm/mach-exynos/mach-exynos5-dt.c |   30 +
>  drivers/iommu/Kconfig  |2 +-
>  drivers/iommu/Makefile |2 +-
>  drivers/iommu/exynos-iommu.c   | 1477
+++-
>  17 files changed, 1745 insertions(+), 765 deletions(-)

Hmm, the 5th and 6th patches which were 1st and 2nd patches in previous
version are not merged into mainline via Samsung tree yet. Just merged into
Samsung tree. But if Joerg is ok on this series, this series should be
merged into both tree...Joerg, how do you think?

- Kukjin

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

Inconsistency in clk framework

[Tony Prisk]

Hi Mike,

In attempting to remove some IS_ERR_OR_NULL references, it was pointed
out that clk_get() can return NULL if CONFIG_HAVE_CLK is not defined.

This seems to contradict the kernel docs associated with the normal
clk_get (when HAVE_CLK is defined) which states:

* Returns a struct clk corresponding to the clock producer, or
* valid IS_ERR() condition containing errno.

Wouldn't a return code of ERR_PTR(-ENOENT) make more sense and be inline
with the empty of_ versions as well (which return -ENOENT when CONFIG_OF
is undefined).

Also, I noticed that clk_get_sys() doesn't appear to be defined in clk.h
when HAVE_CLK is undefined - is this correct?

Regards
Tony Prisk

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] synclink fix ldisc buffer argument

[Chen Gang]

于 2012年12月19日 12:09, Greg KH 写道:
> On Wed, Dec 19, 2012 at 10:23:29AM +0800, Chen Gang wrote:
>> Hello Paul Fulghum:
>>
>> it seems you are very busy,
>>   and can not get your reply for "checking length in function rx_get_buf".
> 
> You should always send patches, long emails like this about "potential"
> issues are hard to handle, patches are best.
> 
> greg k-h
> 
> 

  ok, I will send patch after unit test.


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] synclink fix ldisc buffer argument

[Greg KH]

On Wed, Dec 19, 2012 at 10:23:29AM +0800, Chen Gang wrote:
> Hello Paul Fulghum:
> 
> it seems you are very busy,
>   and can not get your reply for "checking length in function rx_get_buf".

You should always send patches, long emails like this about "potential"
issues are hard to handle, patches are best.

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

Re: [PATCH v6 05/27] x86, 64bit: clear ident mapping when kernel is above 512G

[Yinghai Lu]

On Sun, Dec 16, 2012 at 9:49 AM, Borislav Petkov  wrote:
> On Thu, Dec 13, 2012 at 02:01:59PM -0800, Yinghai Lu wrote:
>> After following patch:
>>   x86, 64bit: Set extra ident mapping for whole kernel range
>>
>> We have extra ident mapping for kernel that is loaded above 1G.
>
> What?
>
> /me looks at next patch
>
> Aaah, the *next* patch adds an extra ident mapping. Why don't you say
> so?
>
>> So need to clear extra pgd entry when kernel is loaded above 512g.
>
> Why then isn't that patch following the next patch instead of coming
> before it?

make the transition smooth.

zap_ident is after setting in head_64.S

anyway the whole zap_ident get deleted and we don't need this patch anymore.

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

Re: [PATCH v6 04/27] x86, boot: Move lldt/ltr out of 64bit code section

[Yinghai Lu]

On Sat, Dec 15, 2012 at 9:28 AM, Borislav Petkov  wrote:
> On Thu, Dec 13, 2012 at 02:01:58PM -0800, Yinghai Lu wrote:
>> commit 08da5a2ca
>>
>> x86_64: Early segment setup for VT
>>
>> add lldt/ltr to clean more segments.
>>
>> Those code are put in code64, and it is using gdt that is only
>> loaded from code32 path.
>>
>> That breaks booting with 64bit bootloader that does not go through
>> code32 path. It get at startup_64 directly,  and it has different
>> gdt.
>>
>> Move those lines into code32 after their gdt is loaded.
>
> Let me rewrite that commit message for ya, you tell me whether I got it
> right:
>
> "08da5a2ca479 ("x86_64: Early segment setup for VT") sets up LDT and TR
> into a valid state in order to speed up boot decompression under VT. The
> code which loads the GDT is executed in the 32-bit startup code while
> the above change in the 64-bit part.
>
> However, this breaks 64-bit bootloaders which jump straight to the
> 64-bit startup entry point and thus skip LDR and TR setup because they
> use a different GDT.
>
> Fix this by moving the LDT and TR setup to the 32-bit section."
>
> Is that correct?
yes

update to:

---
Subject: [PATCH] x86, boot: Move lldt/ltr out of 64bit code section

commit 08da5a2ca

x86_64: Early segment setup for VT

sets up LDT and TR into a valid state in order to speed up boot
decompression under VT.

Those code are put in code64, and it is using GDT that is only
loaded from code32 path.

That breaks booting with 64bit bootloader that does not go through
code32 path and jump to startup_64 directly, and it has different
GDT.

Move those lines into code32 after their GDT is loaded.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: zram: fix invalid memory references during disk write

[Greg KH]

On Tue, Dec 18, 2012 at 01:12:05PM -0800, Nitin Gupta wrote:
> On Tue, Dec 11, 2012 at 10:27 AM, Greg KH  wrote:
> > On Thu, Nov 29, 2012 at 10:45:09PM -0800, Nitin Gupta wrote:
> >> Fixes a bug introduced by commit c8f2f0db1 ("zram: Fix handling
> >> of incompressible pages") which caused invalid memory references
> >> during disk write. Invalid references could occur in two cases:
> >>  - Incoming data expands on compression: In this case, reference was
> >> made to kunmap()'ed bio page.
> >>  - Partial (non PAGE_SIZE) write with incompressible data: In this
> >> case, reference was made to a kfree()'ed buffer.
> >>
> >> Fixes bug 50081:
> >> https://bugzilla.kernel.org/show_bug.cgi?id=50081
> >>
> >> Upstream commit ID: c8f2f0d: zram: Fix handling of incompressible pages
> >> Apply to versions: 3.6.5, 3.6.6, 3.6.7, 3.6.8
> >>
> >> Cc:  # staging-next: 37b51fd: zram: factor-out
> >>   # zram_decompress_page() function
> >> Signed-off-by: Nitin Gupta 
> >> Reported-by: Mihail Kasadjikov 
> >> Reported-by: Tomas M 
> >> Reviewed-by: Minchan Kim 
> >> ---
> >>  drivers/staging/zram/zram_drv.c |   39 
> >> ---
> >>  1 file changed, 24 insertions(+), 15 deletions(-)
> >
> > This patch fails to apply to 3.6.10:
> >
> > patching file drivers/staging/zram/zram_drv.c
> > Hunk #1 succeeded at 282 (offset 17 lines).
> > Hunk #2 FAILED at 286.
> > Hunk #3 succeeded at 319 (offset 17 lines).
> > Hunk #4 succeeded at 340 (offset 17 lines).
> > Hunk #5 succeeded at 353 (offset 17 lines).
> > Hunk #6 succeeded at 368 (offset 17 lines).
> > Hunk #7 succeeded at 385 (offset 17 lines).
> > 1 out of 7 hunks FAILED -- saving rejects to file 
> > drivers/staging/zram/zram_drv.c.rej
> >
> > Please redo this patch and resend it if you wish for it to be applied to
> > the 3.6-stable tree.
> >
> >
> 
> Please apply this patch to stable tree asap.

3.6 is now end-of-life, there will not be any more releases for that
kernel series anymore, sorry.

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

Re: [PATCH v6 03/27] x86, boot: move verify_cpu.S and no_longmode after 0x200

[Yinghai Lu]

On Sat, Dec 15, 2012 at 9:06 AM, Borislav Petkov  wrote:
> On Thu, Dec 13, 2012 at 02:01:57PM -0800, Yinghai Lu wrote:
>> We are short of space before 0x200 that is entry for startup_64.
>
> And you're moving this down because of the couple of bytes the next
> patch is adding? If so, then explain that here.

better?

---
Subject: [PATCH] x86, boot: move verify_cpu.S and no_longmode down

We need to move some code with 32bit section in following patch:

   x86, boot: Move lldt/ltr out of 64bit code section

but that will push startup_64 down from 0x200.

According to hpa, we can not change startup_64 to other offset and
that become ABI now.

We could move function verify_cpu and no_longmode down, because
verify_cpu is used via function call and no_longmode will not
return.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] ARM: EXYNOS: Fix MSHC clocks instance names

[Kukjin Kim]

Thomas Abraham wrote:
> 
> On 14 December 2012 21:43, Dongjin Kim  wrote:
> > Replace clock instance name of MSHC controller for BIC and CIU of
> Exynos4412.
> >
> > Signed-off-by: Dongjin Kim 
> > ---
> >  arch/arm/mach-exynos/clock-exynos4.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/clock-exynos4.c b/arch/arm/mach-
> exynos/clock-exynos4.c
> > index efead60..bbcb3de 100644
> > --- a/arch/arm/mach-exynos/clock-exynos4.c
> > +++ b/arch/arm/mach-exynos/clock-exynos4.c
> > @@ -529,7 +529,7 @@ static struct clk exynos4_init_clocks_off[] = {
> > .enable = exynos4_clk_ip_fsys_ctrl,
> > .ctrlbit= (1 << 8),
> > }, {
> > -   .name   = "dwmmc",
> > +   .name   = "biu",
> > .parent = _clk_aclk_133.clk,
> > .enable = exynos4_clk_ip_fsys_ctrl,
> > .ctrlbit= (1 << 9),
> > @@ -1134,7 +1134,7 @@ static struct clksrc_clk exynos4_clksrcs[] = {
> > .reg_div = { .reg = EXYNOS4_CLKDIV_MFC, .shift = 0,
.size = 4 },
> > }, {
> > .clk= {
> > -   .name   = "sclk_dwmmc",
> > +   .name   = "ciu",
> > .parent = _clk_dout_mmc4.clk,
> > .enable = exynos4_clksrc_mask_fsys_ctrl,
> > .ctrlbit= (1 << 16),
> > --
> 
> Acked-by: Thomas Abraham 
> 
Thanks, applied.

- Kukjin

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

Re: [PATCH v6 02/27] x86, mm: make pgd next calculation consistent with pud/pmd

[Yinghai Lu]

On Fri, Dec 14, 2012 at 6:34 AM, Borislav Petkov  wrote:
> On Thu, Dec 13, 2012 at 02:01:56PM -0800, Yinghai Lu wrote:
>> Just like PUD_SIZE, and PMD_SIZE next calculation, aka
>> round down and add size.
>
> Why? Please explain more verbosely.
>
>> also remove not need next checking, just pass end instead.
>> later phys_pud_init uses PTRS_PER_PUD checking to exit early
>> if end is too big.
>
> Where? In the for-loop? Where does it check 'end'?
>

update to :

---
Subject: [PATCH] x86, mm: make pgd next calculation consistent with pud/pmd

Just like the way we calculate next for pud and pmd, aka
round down and add size.

also remove not needed next checking, just pass end with phys_pud_init.

pyhs_pud_init() uses PTRS_PER_PUD to stop its loop early so it could handle
big end properly.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 01/27] x86, mm: Fix page table early allocation offset checking

[Yinghai Lu]

On Fri, Dec 14, 2012 at 2:53 AM, Borislav Petkov  wrote:
> On Thu, Dec 13, 2012 at 02:01:55PM -0800, Yinghai Lu wrote:
>> During debug load kernel above 4G, found one page if is not used in BRK
>> and it should be with early page allocation.
>
> What does that mean?
>
> I see that this patch adds a change to not use the page at pgt_buf_top
> anymore but why? Is pgt_buf_top the first invalid address we cannot
> reserve anymore?
>
> Generally, can we get this whole deal described in a bit more detail for
> the mere mortals among us, maybe a short ascii art thing showing what
> all those pgt_buf_{start,end,top} mean.
>

change that too:
---
Subject: [PATCH] x86, mm: Fix page table early allocation offset checking

During debug load kernel above 4G, found one page if is not used in BRK
and it should be with early page allocation.

pgt_buf_top is address that can not be used, so should check if then new
end is above than that top, otherwise last page will not used.

Fix that checking and also add print out for every allocation from BRK
---

>>  arch/x86/mm/init.c |4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>> index 6f85de8..c4293cf 100644
>> --- a/arch/x86/mm/init.c
>> +++ b/arch/x86/mm/init.c
>> @@ -47,7 +47,7 @@ __ref void *alloc_low_pages(unsigned int num)
>>   __GFP_ZERO, order);
>>   }
>>
>> - if ((pgt_buf_end + num) >= pgt_buf_top) {
>> + if ((pgt_buf_end + num) > pgt_buf_top) {
>>   unsigned long ret;
>>   if (min_pfn_mapped >= max_pfn_mapped)
>>   panic("alloc_low_page: ran out of memory");
>> @@ -61,6 +61,8 @@ __ref void *alloc_low_pages(unsigned int num)
>>   } else {
>>   pfn = pgt_buf_end;
>>   pgt_buf_end += num;
>> + printk(KERN_DEBUG "BRK [%#010lx, %#010lx] PGTABLE\n",
>
> pr_debug
>

I really hate pr_debug.

pr_debug is useless. it will not print out anything.

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

linux-next: Tree for Dec 19

[Stephen Rothwell]

Hi all,

Changes since 20121218:

Removed tree: i2c (new maintainer)

Lots of conflicts are migrating between trees.

The slave-dma tree gained a conflict against Linus' tree.

The modules tree gained a conflict against Linus' tree.

The fsnotify tree gained a build failure for which I applied a merge fix
patch.

The akpm tree lost its build failure and lots of patches that turned up
in Linus' tree.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 214 trees (counting Linus' and 28 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (31564cb Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging fixes/master (791cb02 OMAP: common.c: remove init call to vram fixup)
Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by 
list_head-style lists.)
Merging arm-current/fixes (dad5451 ARM: 7605/1: vmlinux.lds: Move .notes 
section next to the rodata)
Merging m68k-current/for-linus (5fec45a m68k/sun3: Fix instruction faults)
Merging powerpc-merge/merge (e716e01 powerpc/eeh: Do not invalidate PE properly)
Merging sparc/master (66cdd0c Merge tag 'kvm-3.8-1' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging net/master (c39ba1c cdc_ether: cleanup: use 
USB_DEVICE_AND_INTERFACE_INFO for Novatel 551/E362)
Merging sound-current/for-linus (d846b17 ALSA: hda - Fix build without 
CONFIG_PM)
Merging pci-current/for-linus (ff8e59b PCI/portdrv: Don't create hotplug slots 
unless port supports hotplug)
Merging wireless/master (009b969 wireless: fix Atheros drivers compilation)
Merging driver-core.current/driver-core-linus (9360b53 Revert "bdi: add a 
user-tunable cpu_list for the bdi flusher threads")
Merging tty.current/tty-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb.current/usb-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging staging.current/staging-linus (1ebaf4f Merge branch 
'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging char-misc.current/char-misc-linus (1ebaf4f Merge branch 
'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging input-current/for-linus (022573c Merge branch 'next' into for-linus)
Merging md-current/for-linus (a9add5d md/raid5: add blktrace calls)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (a2c0911 crypto: caam - Updated SEC-4.0 device 
tree binding for ERA information.)
Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
Merging dwmw2/master (03a0b4c solos-pci: fix double-free of TX skb in DMA mode)
CONFLICT (content): Merge conflict in arch/x86/Kconfig.cpu
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/powerpc/Kconfig
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (0e622d3 of/address: sparc: 

RE: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command

[Fangxiaozhi (Franko)]

Dear Sebastian:
Please see the comments follows yours.

By the way, I found the kernel is updated to 3.7.1 today. So I have to 
update my patch based on 3.7.1, and resubmit it?
Right?

Best Regards,
Franko Fang

> -Original Message-
> From: Sebastian Andrzej Siewior [mailto:sebast...@breakpoint.cc]
> Sent: Tuesday, December 18, 2012 10:10 PM
> To: Fangxiaozhi (Franko)
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Xueguiying
> (Zihan); Linlei (Lei Lin); g...@kroah.com; Yili (Neil); Wangyuhua (Roger,
> Credit); Huqiao; ba...@ti.com
> Subject: Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB
> storage devices and support new switch command
> 
> On Tue, Dec 18, 2012 at 10:44:19AM +0800, fangxiaozhi 00110321 wrote:
> > diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c
> linux-3.7/drivers/usb/storage/initializers.c
> > --- linux-3.7_bak/drivers/usb/storage/initializers.c2012-12-11
> 09:56:11.0 +0800
> > +++ linux-3.7/drivers/usb/storage/initializers.c2012-12-17
> 11:12:12.0 +0800
> > US_DEBUGP("Huawei mode set result is %d\n", result);
> > return 0;
> >  }
> > +
> > +/* Find the supported Huawei USB dongles */ static int
> > +usb_stor_huawei_dongles_pid(struct us_data *us) {
> > +   struct usb_interface_descriptor *idesc;
> > +   int idProduct;
> > +
> > +   idesc = >pusb_intf->cur_altsetting->desc;
> > +   idProduct = us->pusb_dev->descriptor.idProduct;
> > +   if (idesc && idesc->bInterfaceNumber == 0) {
> > +   if ((idProduct == 0x1001)
> > +   || (idProduct == 0x1003)
> > +   || (idProduct == 0x1004)
> > +   || (idProduct >= 0x1401 && idProduct < 0x1501)
> > +   || (idProduct > 0x1504 && idProduct <= 0x1600)
> > +   || (idProduct >= 0x1c02 && idProduct <= 0x2202)) {
> > +   return 1;
> > +   }
> > +   }
> > +   return 0;
> > +}
> > +
> > +static int usb_stor_huawei_scsi_init(struct us_data *us) {
> > +   int result = 0;
> > +   int act_len = 0;
> > +   char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
> > +   0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
> 
> Has this something to do with the SPACE command as defined in SSC-2? I
> don't see the code (0x6 here) to be defined. But then you name is rewind.

Yes, we redefine the SPACE based on our need, and named it "rewind"

> 
> > +   struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
> > +
> > +   memset(bcbw, 0, sizeof(struct bulk_cb_wrap));
> > +   bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
> > +   bcbw->Tag = 0;
> > +   bcbw->DataTransferLength = 0;
> > +   bcbw->Flags = bcbw->Lun = 0;
> 
> A memset() followed by an init of each member of the struct. Could please
> chose one side?
> 
> > +   bcbw->Length = sizeof(rewind_cmd);
> > +   memcpy(bcbw->CDB, rewind_cmd, sizeof(rewind_cmd));
> > +
> > +   result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, ,
> > +   US_BULK_CS_WRAP_LEN, _len);
> 
> I am a little confused here. Shouldn't this be bcbw aka us->iobuf and not
>  ?
Yes, you are right.
> 
> And shouldn't you read something from the us->recv_bulk_pipe after
> that?
Well, because our device will re-connect to switch the ports if it 
receives the command.
So it is not necessary to read the response of the command.
> 
> > +   US_DEBUGP("transfer actual length=%d, result=%d\n", act_len,
> result);
> > +   return result;
> > +}
> > +
> 
> Sebastian
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: [PATCH v2 1/6] Add header files and Kbuild plumbing for SI476x MFD core

[Andrey Smirnov]

On 12-12-18 11:37 AM, Mauro Carvalho Chehab wrote:

Em Mon, 8 Oct 2012 11:38:01 -0700
Andrey Smirnov  escreveu:


On 10/08/2012 01:43 AM, Hans Verkuil wrote:

On Sat October 6 2012 03:54:57 Andrey Smirnov wrote:

This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.

The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
functionality to the two other drivers that represent radio and audio
codec subsystems of the chip.

Signed-off-by: Andrey Smirnov 
---
  drivers/mfd/Kconfig |   14 ++
  drivers/mfd/Makefile|3 +
  include/linux/mfd/si476x-core.h |  529 +++
  include/media/si476x.h  |  449 +
  4 files changed, 995 insertions(+)
  create mode 100644 include/linux/mfd/si476x-core.h
  create mode 100644 include/media/si476x.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..3fab06d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -895,6 +895,20 @@ config MFD_WL1273_CORE
  driver connects the radio-wl1273 V4L2 module and the wl1273
  audio codec.
  
+config MFD_SI476X_CORE

+   tristate "Support for Silicon Laboratories 4761/64/68 AM/FM radio."
+   depends on I2C
+   select MFD_CORE
+   default n
+   help
+ This is the core driver for the SI476x series of AM/FM radio. This MFD
+ driver connects the radio-si476x V4L2 module and the si476x
+ audio codec.
+
+ To compile this driver as a module, choose M here: the
+ module will be called si476x-core.
+
+
  config MFD_OMAP_USB_HOST
bool "Support OMAP USBHS core driver"
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..942257b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -132,3 +132,6 @@ obj-$(CONFIG_MFD_RC5T583)   += rc5t583.o rc5t583-irq.o
  obj-$(CONFIG_MFD_SEC_CORE)+= sec-core.o sec-irq.o
  obj-$(CONFIG_MFD_ANATOP)  += anatop-mfd.o
  obj-$(CONFIG_MFD_LM3533)  += lm3533-core.o lm3533-ctrlbank.o
+
+si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
+obj-$(CONFIG_MFD_SI476X_CORE)  += si476x-core.o
diff --git a/include/linux/mfd/si476x-core.h b/include/linux/mfd/si476x-core.h
new file mode 100644
index 000..eb6f52a
--- /dev/null
+++ b/include/linux/mfd/si476x-core.h
@@ -0,0 +1,529 @@
+/*
+ * include/media/si476x-core.h -- Common definitions for si476x core
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef SI476X_CORE_H
+#define SI476X_CORE_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#ifdef DEBUG
+#define DBG_BUFFER(device, header, buffer, bcount) \
+   do {\
+   dev_info((device), header); \
+   print_hex_dump_bytes("",  \
+DUMP_PREFIX_OFFSET,\
+buffer, bcount);   \
+   } while (0)
+#else
+#define DBG_BUFFER(device, header, buffer, bcount) \
+   do {} while (0)
+#endif
+
+enum si476x_freq_suppoted_chips {

typo: suppoted -> supported


+   SI476X_CHIP_SI4761 = 1,
+   SI476X_CHIP_SI4762,
+   SI476X_CHIP_SI4763,
+   SI476X_CHIP_SI4764,
+   SI476X_CHIP_SI4768,
+   SI476X_CHIP_SI4769,
+};
+
+enum si476x_mfd_cells {
+   SI476X_RADIO_CELL = 0,
+   SI476X_CODEC_CELL,
+   SI476X_MFD_CELLS,
+};
+
+
+/**
+ * enum si476x_power_state - possible power state of the si476x
+ * device.
+ *
+ * @SI476X_POWER_DOWN: In this state all regulators are turned off
+ * and the reset line is pulled low. The device is completely
+ * inactive.
+ * @SI476X_POWER_UP_FULL: In this state all the power regualtors are
+ * turned on, reset line pulled high, IRQ line is enabled(polling is
+ * active for polling use scenario) and device is turned on with
+ * POWER_UP command. The device is ready to be used.
+ * @SI476X_POWER_INCONSISTENT: This state indicates that previous
+ * power down was inconsisten meaning some of he regulators wer not
+ * turned down and thus the consequent use of the device, without

Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang

[Joe Jin]

Hi all,

I backported mps commits and ask customer pass "pci=pcie_bus_peer2pee" to kernel
to limited MPS to 128 and issue disappeared, sound like this is a BIOS bug.

Thanks all of your help.

Best Regards,
Joe

On 11/29/12 23:52, Fujinaka, Todd wrote:
> Someone else pointed this out to me locally. If you have a non-client BIOS, 
> you should be able to set the MaxPayloadSize using setpci. You have to make 
> sure that you're being consistent throughout all the associated links.
> 
> Todd Fujinaka
> Technical Marketing Engineer
> LAN Access Division (LAD)
> Intel Corporation
> todd.fujin...@intel.com
> (503) 712-4565
> 
> 
> -Original Message-
> From: Ethan Zhao [mailto:ethan.ker...@gmail.com] 
> Sent: Wednesday, November 28, 2012 7:10 PM
> To: Fujinaka, Todd
> Cc: Joe Jin; Ben Hutchings; Mary Mcgrath; net...@vger.kernel.org; 
> e1000-de...@lists.sf.net; linux-kernel@vger.kernel.org; linux-pci
> Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
> 
> Joe,
> Possibly your customer is running a kernel without source code on a 
> platform whose vendor wouldn't like to fix BIOS issue( Is that a HP/Dell 
> server ?).
> Anyway, to see if is a payload issue or,  you could change the payload 
> size with setpci tool to those devices and set the link retrain bit to 
> trigger the link retraining to debug the issue and identity the root cause.  
> I thinks it is much easier than modify the BIOS or  eeprom of NIC.
> 
> e.g.
>set device control register to 0f 00   (128 bytes payload size)
>#   setpci -v -s 00:02.0 98.w=000f
>set device link control register to 60h (retrain the link)
>#  setpci -v -s 00:02.0 a0.b=60
> 
>   Hope it works,  Just my 2 cents.
> 
> ethan.z...@oracle.com
> 
> On Wed, Nov 28, 2012 at 11:53 PM, Fujinaka, Todd  
> wrote:
>> The only EEPROM I know about or can speak to is the one attached to the 
>> 82571 and it doesn't set the MaxPayloadSize. That's done by the BIOS.
>>
>> Todd Fujinaka
>> Technical Marketing Engineer
>> LAN Access Division (LAD)
>> Intel Corporation
>> todd.fujin...@intel.com
>> (503) 712-4565
>>
>>
>> -Original Message-
>> From: Joe Jin [mailto:joe@oracle.com]
>> Sent: Wednesday, November 28, 2012 12:31 AM
>> To: Ben Hutchings
>> Cc: Fujinaka, Todd; Mary Mcgrath; net...@vger.kernel.org; 
>> e1000-de...@lists.sf.net; linux-kernel@vger.kernel.org; linux-pci
>> Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
>>
>> On 11/28/12 02:10, Ben Hutchings wrote:
>>> On Tue, 2012-11-27 at 17:32 +, Fujinaka, Todd wrote:
 Forgive me if I'm being too repetitious as I think some of this has 
 been mentioned in the past.

 We (and by we I mean the Ethernet part and driver) can only change 
 the advertised availability of a larger MaxPayloadSize. The size is 
 negotiated by both sides of the link when the link is established.
 The driver should not change the size of the link as it would be 
 poking at registers outside of its scope and is controlled by the 
 upstream bridge (not us).
>>> [...]
>>>
>>> MaxPayloadSize (MPS) is not negotiated between devices but is 
>>> programmed by the system firmware (at least for devices present at 
>>> boot - the kernel may be responsible in case of hotplug).  You can 
>>> use the kernel parameter 'pci=pcie_bus_perf' (or one of several 
>>> others) to set a policy that overrides this, but no policy will allow 
>>> setting MPS above the device's MaxPayloadSizeSupported (MPSS).
>>>
>>
>> Ben,
>>
>> Unfortunately I'm using 3.0.x kernel and this is not included in the kernel.
>> So I'm trying to use ethtool modify it from eeprom to see if help or no.
>>
>>
>> Todd, I'll review all MaxPayload for all devices, but need to say if it 
>> mismatch, customer could not modify it from BIOS for there was not entry at 
>> there, to test it, we have to find how to verify if this is the root cause, 
>> so still need to find the offset in eeprom.
>>
>> Thanks in advance,
>> Joe
>>


-- 
Oracle 
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualization
No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] Updates for Zynq's timer driver

[Josh Cartwright]

On Tue, Dec 18, 2012 at 04:16:32PM -0800, Soren Brinkmann wrote:
> I started to put some effort on syncing the Xilinx Linux tree with mainline 
> and
> the timer driver is my first victim.
> Most commits are fixing style issues or clean up. Functionality is touched 
> only
> in patches #2 and #7.
> 
> Some patches are present in almost identically in the Xilinx Linux tree and I
> took over 'Ackec-by' lines from those commits.
> 
>   Soren
> 
> Soren Brinkmann (7):
>   arm: zynq: timer: Replace PSS through PS
>   arm: zynq: timer: Remove unnecessary register write
>   arm: zynq: timer: Remove unused #defines
>   arm: zynq: timer: Align columns
>   arm: zynq: timer: Remove redundant #includes
>   arm: zynq: timer: Fix comment style
>   arm: zynq: timer: Set clock_event cpumask

Hey Soren-

I had a look through this patchset and besides the stylistic nit in
patch 1, everything looks good to me.  Feel free to add my Reviewed-by.

Also, you seem to have neglected linux-arm-kernel from CC, you'll likely
want to repost there.

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

Re: [PATCH 1/7] arm: zynq: timer: Replace PSS through PS

[Josh Cartwright]

On Tue, Dec 18, 2012 at 04:16:33PM -0800, Soren Brinkmann wrote:
> The acronym PSS is deprecated by Xilinx. The correct term, which is
> also used in Xilinx documentation is PS (processing system).
> This is just a search and replace:
>  - s/PSS/PS/g
>  - s/pss/ps/g
> 
> Signed-off-by: Soren Brinkmann 
[..]
> --- a/arch/arm/mach-zynq/timer.c
> +++ b/arch/arm/mach-zynq/timer.c
> @@ -35,17 +35,17 @@
>   * Timer Register Offset Definitions of Timer 1, Increment base address by 4
>   * and use same offsets for Timer 2
>   */
> -#define XTTCPSS_CLK_CNTRL_OFFSET 0x00 /* Clock Control Reg, RW */
> -#define XTTCPSS_CNT_CNTRL_OFFSET 0x0C /* Counter Control Reg, RW */
> -#define XTTCPSS_COUNT_VAL_OFFSET 0x18 /* Counter Value Reg, RO */
> -#define XTTCPSS_INTR_VAL_OFFSET  0x24 /* Interval Count Reg, RW 
> */
> -#define XTTCPSS_MATCH_1_OFFSET   0x30 /* Match 1 Value Reg, RW */
> -#define XTTCPSS_MATCH_2_OFFSET   0x3C /* Match 2 Value Reg, RW */
> -#define XTTCPSS_MATCH_3_OFFSET   0x48 /* Match 3 Value Reg, RW */
> -#define XTTCPSS_ISR_OFFSET   0x54 /* Interrupt Status Reg, RO */
> -#define XTTCPSS_IER_OFFSET   0x60 /* Interrupt Enable Reg, RW */
> -
> -#define XTTCPSS_CNT_CNTRL_DISABLE_MASK   0x1
> +#define XTTCPS_CLK_CNTRL_OFFSET  0x00 /* Clock Control Reg, RW */
> +#define XTTCPS_CNT_CNTRL_OFFSET  0x0C /* Counter Control Reg, RW */
> +#define XTTCPS_COUNT_VAL_OFFSET  0x18 /* Counter Value Reg, RO */
> +#define XTTCPS_INTR_VAL_OFFSET   0x24 /* Interval Count Reg, RW 
> */
> +#define XTTCPS_MATCH_1_OFFSET0x30 /* Match 1 Value Reg, RW */
> +#define XTTCPS_MATCH_2_OFFSET0x3C /* Match 2 Value Reg, RW */
> +#define XTTCPS_MATCH_3_OFFSET0x48 /* Match 3 Value Reg, RW */
> +#define XTTCPS_ISR_OFFSET0x54 /* Interrupt Status Reg, RO */
> +#define XTTCPS_IER_OFFSET0x60 /* Interrupt Enable Reg, RW */
> +
> +#define XTTCPS_CNT_CNTRL_DISABLE_MASK0x1
>  
>  /* Setup the timers to use pre-scaling, using a fixed value for now that will
>   * work across most input frequency, but it may need to be more dynamic
> @@ -57,72 +57,72 @@
>  #define CNT_CNTRL_RESET  (1<<4)
>  
>  /**
> - * struct xttcpss_timer - This definition defines local timer structure
> + * struct xttcps_timer - This definition defines local timer structure
>   *
>   * @base_addr:   Base address of timer
>   **/
> -struct xttcpss_timer {
> +struct xttcps_timer {
>   void __iomem*base_addr;
>  };
>  
> -struct xttcpss_timer_clocksource {
> - struct xttcpss_timerxttc;
> +struct xttcps_timer_clocksource {
> + struct xttcps_timer xttc;
>   struct clocksource  cs;
>  };
>  
> -#define to_xttcpss_timer_clksrc(x) \
> - container_of(x, struct xttcpss_timer_clocksource, cs)
> +#define to_xttcps_timer_clksrc(x) \
> + container_of(x, struct xttcps_timer_clocksource, cs)
>  
> -struct xttcpss_timer_clockevent {
> - struct xttcpss_timerxttc;
> +struct xttcps_timer_clockevent {
> + struct xttcps_timer xttc;
>   struct clock_event_device   ce;
>   struct clk  *clk;
>  };
>  
> -#define to_xttcpss_timer_clkevent(x) \
> - container_of(x, struct xttcpss_timer_clockevent, ce)
> +#define to_xttcps_timer_clkevent(x) \
> + container_of(x, struct xttcps_timer_clockevent, ce)
>  
>  /**
> - * xttcpss_set_interval - Set the timer interval value
> + * xttcps_set_interval - Set the timer interval value
>   *
>   * @timer:   Pointer to the timer instance
>   * @cycles:  Timer interval ticks
>   **/
> -static void xttcpss_set_interval(struct xttcpss_timer *timer,
> +static void xttcps_set_interval(struct xttcps_timer *timer,
>   unsigned long cycles)

Stylistic nit, but if we're going to be making cosmetic changes of this
sort, I'd personally like to see the arguments lined up properly:

static void xttcps_set_interval(struct xttcps_timer *timer,
unsigned long cycles)

>  {
[..]
> @@ -136,46 +136,46 @@ static irqreturn_t xttcpss_clock_event_interrupt(int 
> irq, void *dev_id)
>   **/
>  static cycle_t __xttc_clocksource_read(struct clocksource *cs)
>  {
> - struct xttcpss_timer *timer = _xttcpss_timer_clksrc(cs)->xttc;
> + struct xttcps_timer *timer = _xttcps_timer_clksrc(cs)->xttc;
>  
>   return (cycle_t)__raw_readl(timer->base_addr +
> - XTTCPSS_COUNT_VAL_OFFSET);
> + XTTCPS_COUNT_VAL_OFFSET);
>  }
>  
>  /**
> - * xttcpss_set_next_event - Sets the time interval for next event
> + * xttcps_set_next_event - Sets the time interval for next event
>   *
>   * @cycles:  Timer interval ticks
>   * @evt: Address of clock event instance
>   *
>   * returns: Always 0 - success
>   **/
> -static int 

Re: [PATCH] synclink fix ldisc buffer argument

[Chen Gang]

Hello Paul Fulghum:

it seems you are very busy,
  and can not get your reply for "checking length in function rx_get_buf".

so I suggest:
  design:
to give it additional length checking in function rx_get_buf.
if realy > max_frame_size, will return false (also need call free_rbufs).
  unit test plan:
write a simple driver to integrate relative functions (already modified as 
design).
pass compiling, and can succeed loading.
and then
  call the relative function (rx_get_buf) with intended values
  check the work flow of our modification whether as expected.

at last, I still suggestion Paul Fulghum to provide the patch when he has free 
time.
  for synclink, he is more expert than me.
  for synclink, he can give better test.

  if still get no reply within an additonal week:
I should provide the patch, it is my duty.
I will be according to the patch which Paul Fulghum has already provided.
and then add the "checking length in function rx_get_buf".


  Regards

gchen.

于 2012年12月05日 09:57, Chen Gang 写道:
> by the way:
>   does it also need check the length in function rx_get_buf ? 
>   (it seems not, but I am not quite sure, can you give a confirm ?)
> 
> 4779 /*
> 4780  * pass receive buffer (RAW synchronous mode) to tty layer
> 4781  * return true if buffer available, otherwise false
> 4782  */
> 4783 static bool rx_get_buf(struct slgt_info *info)
> 4784 {
> 4785 unsigned int i = info->rbuf_current;
> 4786 unsigned int count;
> 4787 
> 4788 if (!desc_complete(info->rbufs[i]))
> 4789 return false;
> 4790 count = desc_count(info->rbufs[i]);
> 4791 switch(info->params.mode) {
> 4792 case MGSL_MODE_MONOSYNC:
> 4793 case MGSL_MODE_BISYNC:
> 4794 case MGSL_MODE_XSYNC:
> 4795 /* ignore residue in byte synchronous modes */
> 4796 if (desc_residue(info->rbufs[i]))
> 4797 count--;
> 4798 break;
> 4799 }
> 4800 DBGDATA(info, info->rbufs[i].buf, count, "rx");
> 4801 DBGINFO(("rx_get_buf size=%d\n", count));
> 4802 if (count)
> 4803 ldisc_receive_buf(info->port.tty, info->rbufs[i].buf,
> 4804   info->flag_buf, count);
> 4805 free_rbufs(info, i, i);
> 4806 return true;
> 4807 }


-- 
Chen Gang

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

Re: arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 'omap_pm_set_max_mpu_wakeup_lat'

[Fengguang Wu]

[add more CC]

On Wed, Dec 19, 2012 at 10:11:02AM +0800, Fengguang Wu wrote:
> Hi Linus, Wolfram,
> 
> FYI, kernel build failed on
> 
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux master
> head:   752451f01c4567b506bf4343082682dbb8fb30dd
> commit: 752451f01c4567b506bf4343082682dbb8fb30dd Merge branch 
> 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux
> date:   56 minutes ago
> config: make ARCH=arm omap2plus_defconfig
> 
> All error/warnings:
> 
> arch/arm/mach-omap2/i2c.c: In function 
> 'omap_pm_set_max_mpu_wakeup_lat_compat':
> arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 
> 'omap_pm_set_max_mpu_wakeup_lat' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> 
> The root cause is, i2c.c (which is always compiled in 
> arch/arm/mach-omap2/Makefile)
> uses omap_pm_set_max_mpu_wakeup_lat() which is defined in omap-pm-noop.c 
> (which
> is compiled only on CONFIG_OMAP_PM_NOOP).
> 
> 
> vim +/omap_pm_set_max_mpu_wakeup_lat +130 arch/arm/mach-omap2/i2c.c
> 
> 752451f0 Linus Torvalds 2012-12-18  124   * XXX This function is a temporary 
> compatibility wrapper - only
> 752451f0 Linus Torvalds 2012-12-18  125   * needed until the I2C driver can 
> be converted to call
> 752451f0 Linus Torvalds 2012-12-18  126   * omap_pm_set_max_dev_wakeup_lat() 
> and handle a return code.
> 752451f0 Linus Torvalds 2012-12-18  127   */
> 752451f0 Linus Torvalds 2012-12-18  128  static void 
> omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
> 752451f0 Linus Torvalds 2012-12-18  129  {
> 752451f0 Linus Torvalds 2012-12-18 @130   
> omap_pm_set_max_mpu_wakeup_lat(dev, t);
> 752451f0 Linus Torvalds 2012-12-18  131  }
> 752451f0 Linus Torvalds 2012-12-18  132  
> 3a8761c0 Tony Lindgren  2012-10-08  133  static const char name[] = 
> "omap_i2c";
> 
> ---
> 0-DAY kernel build testing backend Open Source Technology Center
> Fengguang Wu, Yuanhan Liu  Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 'omap_pm_set_max_mpu_wakeup_lat'

[Fengguang Wu]

Hi Linus, Wolfram,

FYI, kernel build failed on

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux master
head:   752451f01c4567b506bf4343082682dbb8fb30dd
commit: 752451f01c4567b506bf4343082682dbb8fb30dd Merge branch 
'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux
date:   56 minutes ago
config: make ARCH=arm omap2plus_defconfig

All error/warnings:

arch/arm/mach-omap2/i2c.c: In function 'omap_pm_set_max_mpu_wakeup_lat_compat':
arch/arm/mach-omap2/i2c.c:130:2: error: implicit declaration of function 
'omap_pm_set_max_mpu_wakeup_lat' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

The root cause is, i2c.c (which is always compiled in 
arch/arm/mach-omap2/Makefile)
uses omap_pm_set_max_mpu_wakeup_lat() which is defined in omap-pm-noop.c (which
is compiled only on CONFIG_OMAP_PM_NOOP).


vim +/omap_pm_set_max_mpu_wakeup_lat +130 arch/arm/mach-omap2/i2c.c

752451f0 Linus Torvalds 2012-12-18  124   * XXX This function is a temporary 
compatibility wrapper - only
752451f0 Linus Torvalds 2012-12-18  125   * needed until the I2C driver can be 
converted to call
752451f0 Linus Torvalds 2012-12-18  126   * omap_pm_set_max_dev_wakeup_lat() 
and handle a return code.
752451f0 Linus Torvalds 2012-12-18  127   */
752451f0 Linus Torvalds 2012-12-18  128  static void 
omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
752451f0 Linus Torvalds 2012-12-18  129  {
752451f0 Linus Torvalds 2012-12-18 @130 
omap_pm_set_max_mpu_wakeup_lat(dev, t);
752451f0 Linus Torvalds 2012-12-18  131  }
752451f0 Linus Torvalds 2012-12-18  132  
3a8761c0 Tony Lindgren  2012-10-08  133  static const char name[] = "omap_i2c";

---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu  Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] spi-dw: delete cur_msg when pump message and transfer has finished

[Xiao Jin]

From: xiao jin 
Date: Tue, 20 Nov 2012 13:45:47 +0800
Subject: [PATCH] spi-dw: delete cur_msg when pump message and transfer
has finished

We see DPM device timeout happened in spi_max3111 when system suspend.

The root cause is related to the time we delete msg from dw_spi queue.

Below is the scenario how timeout happened.
step1, max3110_main_thread pump the dw_spi msg and transfer it. And
the msg is deleted from dw_spi queue right now.
step2, runtime suspend happened, there is no msg in the dw_spi queue,
it's permitted to enter into D0i3.
step3, After resume from D0i3, irq will not come for ever,
max3110_main_thread still wait for the completion of last pump message
transfer.
step4, system suspend, serial_m3110_shutdown call max3110_out and
try to lock the mutex, but it has been hold and cannot be released
by max3110_main_thread for ever.
step5, DPM device timer timeout.

This patch is to delete the cur msg when msg complete.

Signed-off-by: xiao jin 
---
 drivers/spi/spi-dw.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index d1a495f..f6bf693 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -268,6 +268,7 @@ static void giveback(struct dw_spi *dws)
 
spin_lock_irqsave(>lock, flags);
msg = dws->cur_msg;
+   list_del_init(>cur_msg->queue);
dws->cur_msg = NULL;
dws->cur_transfer = NULL;
dws->prev_chip = dws->cur_chip;
@@ -571,7 +572,6 @@ static void pump_messages(struct work_struct *work)
 
/* Extract head of queue */
dws->cur_msg = list_entry(dws->queue.next, struct spi_message, queue);
-   list_del_init(>cur_msg->queue);
 
/* Initial message state*/
dws->cur_msg->state = START_STATE;
-- 
1.7.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 RESEND 1/2 v3] menuconfig: Add Save/Load buttons

[Wang YanQing]

If menuconfig have Save/Load button like alternative
.config editors, xconfig, nconfig, etc.We will have
a obvious benefit when use menuconfig just like
when we use others, we can Save/Load our .config quickly
and conveniently.

This patch add the Save/Load button for menuconfig.

[remove trailing space while at it for below line:
"*)  Formerly when I used Page Down and Page Up, the cursor would be set"
]

Changes:
V1-V2:
1:use PATH_MAX instead of hard code suggested by Yann E. MORIN
2:drop the spurious empty-line removal suggested by Yann E. MORIN
V2-V3:
1:ajust buttons position well centered reported by Yann E. MORIN

Signed-off-by: Wang YanQing 
---
 Hi Yann E. MORIN, can you give your Rev'ed-by and Tested-by to this patch,
 Thanks very much for your help, I just don't know how to computer out the
 right position :)

 The Changes appear in commit log is ok, I found I am not the first guy
 do it, it maybe useful in some case :)

 scripts/kconfig/lxdialog/menubox.c | 20 +++-
 scripts/kconfig/mconf.c| 30 +-
 2 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/scripts/kconfig/lxdialog/menubox.c 
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..8b534d5 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
  *
  **)  A bugfix for the Page-Down problem
  *
- **)  Formerly when I used Page Down and Page Up, the cursor would be set 
+ **)  Formerly when I used Page Down and Page Up, the cursor would be set
  *to the first position in the menu box.  Now lxdialog is a bit
  *smarter and works more like other menu systems (just have a look at
  *it).
@@ -154,12 +154,14 @@ static void print_arrows(WINDOW * win, int item_no, int 
scroll, int y, int x,
  */
 static void print_buttons(WINDOW * win, int height, int width, int selected)
 {
-   int x = width / 2 - 16;
+   int x = width / 2 - 28;
int y = height - 2;
 
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+   print_button(win, gettext(" Save "), y, x + 36, selected == 3);
+   print_button(win, gettext(" Load "), y, x + 48, selected == 4);
 
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +374,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
-   ? 2 : (button > 2 ? 0 : button);
+   ? 4 : (button > 4 ? 0 : button);
 
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +401,17 @@ do_resize:
return 2;
case 's':
case 'y':
-   return 3;
+   return 5;
case 'n':
-   return 4;
+   return 6;
case 'm':
-   return 5;
+   return 7;
case ' ':
-   return 6;
+   return 8;
case '/':
-   return 7;
+   return 9;
case 'z':
-   return 8;
+   return 10;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 53975cf..9fb90f0 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -280,6 +280,7 @@ static struct menu *current_menu;
 static int child_count;
 static int single_menu_mode;
 static int show_all_options;
+static int save_and_exit;
 
 static void conf(struct menu *menu, struct menu *active_menu);
 static void conf_choice(struct menu *menu);
@@ -651,6 +652,12 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
show_helptext(_("README"), _(mconf_readme));
break;
case 3:
+   conf_save();
+   break;
+   case 4:
+   conf_load();
+   break;
+   case 5:
if (item_is_tag('t')) {
if (sym_set_tristate_value(sym, yes))
break;
@@ -658,24 +665,24 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
show_textbox(NULL, setmod_text, 6, 74);
}
break;
-   

Re: [PATCH rev.2 1/6] ACPI: Separate adding ACPI device objects from probing ACPI drivers

[Yinghai Lu]

On Tue, Dec 18, 2012 at 2:05 PM, Rafael J. Wysocki  wrote:
>>
>> i think we should put jiang four patches before Rafael's patches.
>>
>> http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=shortlog;h=refs/heads/for-pci-jiang-hotplug
>
> Actually, I have something more radical than that in mind. :-)
>
> Namely, we don't need to call the wakeup-related stuff from acpi_pci_bind() 
> and
> acpi_pci_unbind().  It's only there, because I did't find a better place for 
> it
> when I added it.
>
> If we can set the ACPI handles of PCI devices in pci_scan_device(), which 
> isn't
> too difficult to do (I actually have a patch for that and it's not too 
> invasive),
> we can easily move the wakeup enabling stuff to pci_pm_init() and wakeup
> disabling somewhere near pci_release_capabilities().

good, let's see how acpi handles could be be passed to pci devices.

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

[PATCH 2/3] gpio-langwell: update pci device table

[David Cohen]

This patch adds Cloverview ids to pci device table.

Signed-off-by: David Cohen 
---
 drivers/gpio/gpio-langwell.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-langwell.c b/drivers/gpio/gpio-langwell.c
index 8220c04..dc534a9 100644
--- a/drivers/gpio/gpio-langwell.c
+++ b/drivers/gpio/gpio-langwell.c
@@ -231,6 +231,8 @@ static DEFINE_PCI_DEVICE_TABLE(lnw_gpio_ids) = {   /* pin 
number */
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x080f), .driver_data = 64 },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x081f), .driver_data = 96 },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x081a), .driver_data = 96 },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x08eb), .driver_data = 96 },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x08f7), .driver_data = 96 },
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, lnw_gpio_ids);
-- 
1.7.10.4

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

[PATCH 1/3] gpio-langwell: cleanup driver

[David Cohen]

This patch cleans up cosmetic issues, remove useless functions and add
to_lnw_priv() macro to replace many usages of container_of().

Change-Id: I70a8fadd20a42493271d91633739bdddff19c8d8
Signed-off-by: David Cohen 
---
 drivers/gpio/gpio-langwell.c |   64 ++
 1 file changed, 21 insertions(+), 43 deletions(-)

diff --git a/drivers/gpio/gpio-langwell.c b/drivers/gpio/gpio-langwell.c
index 202a992..8220c04 100644
--- a/drivers/gpio/gpio-langwell.c
+++ b/drivers/gpio/gpio-langwell.c
@@ -71,10 +71,12 @@ struct lnw_gpio {
struct irq_domain   *domain;
 };
 
+#define to_lnw_priv(chip)  container_of(chip, struct lnw_gpio, chip)
+
 static void __iomem *gpio_reg(struct gpio_chip *chip, unsigned offset,
enum GPIO_REG reg_type)
 {
-   struct lnw_gpio *lnw = container_of(chip, struct lnw_gpio, chip);
+   struct lnw_gpio *lnw = to_lnw_priv(chip);
unsigned nreg = chip->ngpio / 32;
u8 reg = offset / 32;
void __iomem *ptr;
@@ -86,7 +88,7 @@ static void __iomem *gpio_reg(struct gpio_chip *chip, 
unsigned offset,
 static void __iomem *gpio_reg_2bit(struct gpio_chip *chip, unsigned offset,
   enum GPIO_REG reg_type)
 {
-   struct lnw_gpio *lnw = container_of(chip, struct lnw_gpio, chip);
+   struct lnw_gpio *lnw = to_lnw_priv(chip);
unsigned nreg = chip->ngpio / 32;
u8 reg = offset / 16;
void __iomem *ptr;
@@ -130,7 +132,7 @@ static void lnw_gpio_set(struct gpio_chip *chip, unsigned 
offset, int value)
 
 static int lnw_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
 {
-   struct lnw_gpio *lnw = container_of(chip, struct lnw_gpio, chip);
+   struct lnw_gpio *lnw = to_lnw_priv(chip);
void __iomem *gpdr = gpio_reg(chip, offset, GPDR);
u32 value;
unsigned long flags;
@@ -153,7 +155,7 @@ static int lnw_gpio_direction_input(struct gpio_chip *chip, 
unsigned offset)
 static int lnw_gpio_direction_output(struct gpio_chip *chip,
unsigned offset, int value)
 {
-   struct lnw_gpio *lnw = container_of(chip, struct lnw_gpio, chip);
+   struct lnw_gpio *lnw = to_lnw_priv(chip);
void __iomem *gpdr = gpio_reg(chip, offset, GPDR);
unsigned long flags;
 
@@ -176,7 +178,7 @@ static int lnw_gpio_direction_output(struct gpio_chip *chip,
 
 static int lnw_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
 {
-   struct lnw_gpio *lnw = container_of(chip, struct lnw_gpio, chip);
+   struct lnw_gpio *lnw = to_lnw_priv(chip);
return irq_create_mapping(lnw->domain, offset);
 }
 
@@ -215,19 +217,14 @@ static int lnw_irq_type(struct irq_data *d, unsigned type)
return 0;
 }
 
-static void lnw_irq_unmask(struct irq_data *d)
-{
-}
-
-static void lnw_irq_mask(struct irq_data *d)
-{
-}
+static void lnw_irq_noop(struct irq_data *d) {}
 
 static struct irq_chip lnw_irqchip = {
.name   = "LNW-GPIO",
-   .irq_mask   = lnw_irq_mask,
-   .irq_unmask = lnw_irq_unmask,
+   .irq_mask   = lnw_irq_noop,
+   .irq_unmask = lnw_irq_noop,
.irq_set_type   = lnw_irq_type,
+   .irq_ack= lnw_irq_noop,
 };
 
 static DEFINE_PCI_DEVICE_TABLE(lnw_gpio_ids) = {   /* pin number */
@@ -299,17 +296,6 @@ static const struct irq_domain_ops lnw_gpio_irq_ops = {
.xlate = irq_domain_xlate_twocell,
 };
 
-#ifdef CONFIG_PM
-static int lnw_gpio_runtime_resume(struct device *dev)
-{
-   return 0;
-}
-
-static int lnw_gpio_runtime_suspend(struct device *dev)
-{
-   return 0;
-}
-
 static int lnw_gpio_runtime_idle(struct device *dev)
 {
int err = pm_schedule_suspend(dev, 500);
@@ -320,16 +306,8 @@ static int lnw_gpio_runtime_idle(struct device *dev)
return -EBUSY;
 }
 
-#else
-#define lnw_gpio_runtime_suspend   NULL
-#define lnw_gpio_runtime_resumeNULL
-#define lnw_gpio_runtime_idle  NULL
-#endif
-
 static const struct dev_pm_ops lnw_gpio_pm_ops = {
-   .runtime_suspend = lnw_gpio_runtime_suspend,
-   .runtime_resume = lnw_gpio_runtime_resume,
-   .runtime_idle = lnw_gpio_runtime_idle,
+   SET_RUNTIME_PM_OPS(NULL, NULL, lnw_gpio_runtime_idle)
 };
 
 static int __devinit lnw_gpio_probe(struct pci_dev *pdev,
@@ -349,7 +327,7 @@ static int __devinit lnw_gpio_probe(struct pci_dev *pdev,
retval = pci_request_regions(pdev, "langwell_gpio");
if (retval) {
dev_err(>dev, "error requesting resources\n");
-   goto err2;
+   goto err;
}
/* get the gpio_base from bar1 */
start = pci_resource_start(pdev, 1);
@@ -358,7 +336,7 @@ static int __devinit lnw_gpio_probe(struct pci_dev *pdev,
if (!base) {
dev_err(>dev, "error mapping bar1\n");
retval = -EFAULT;
-   goto err3;
+   goto err2;
}
gpio_base = *((u32 *)base + 

[PATCH 3/3] gpio-langwell: implement irq shutdown interface

[David Cohen]

From: "Li, Ning" 

Signed-off-by: David Cohen 
Signed-off-by: Li, Ning 
---
 drivers/gpio/gpio-langwell.c |   18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpio/gpio-langwell.c b/drivers/gpio/gpio-langwell.c
index dc534a9..c702d3d 100644
--- a/drivers/gpio/gpio-langwell.c
+++ b/drivers/gpio/gpio-langwell.c
@@ -219,12 +219,30 @@ static int lnw_irq_type(struct irq_data *d, unsigned type)
 
 static void lnw_irq_noop(struct irq_data *d) {}
 
+static void lnw_irq_shutdown(struct irq_data *d)
+{
+   struct lnw_gpio *lnw = irq_data_get_irq_chip_data(d);
+   u32 gpio = irqd_to_hwirq(d);
+   unsigned long flags;
+   u32 value;
+   void __iomem *grer = gpio_reg(>chip, gpio, GRER);
+   void __iomem *gfer = gpio_reg(>chip, gpio, GFER);
+
+   spin_lock_irqsave(>lock, flags);
+   value = readl(grer) & ~BIT(gpio % 32);
+   writel(value, grer);
+   value = readl(gfer) & ~BIT(gpio % 32);
+   writel(value, gfer);
+   spin_unlock_irqrestore(>lock, flags);
+};
+
 static struct irq_chip lnw_irqchip = {
.name   = "LNW-GPIO",
.irq_mask   = lnw_irq_noop,
.irq_unmask = lnw_irq_noop,
.irq_set_type   = lnw_irq_type,
.irq_ack= lnw_irq_noop,
+   .irq_shutdown   = lnw_irq_shutdown,
 };
 
 static DEFINE_PCI_DEVICE_TABLE(lnw_gpio_ids) = {   /* pin number */
-- 
1.7.10.4

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

[PATCH 0/3] gpio-langwell updates

[David Cohen]

Hi,

Here goes some Intel updates done on gpio-langwell driver.

Kind regards,

David
---

David Cohen (2):
  gpio-langwell: cleanup driver
  gpio-langwell: update pci device table

Li, Ning (1):
  gpio-langwell: implement irq shutdown interface

 drivers/gpio/gpio-langwell.c |   80 --
 1 file changed, 39 insertions(+), 41 deletions(-)

-- 
1.7.10.4

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

Re: Strange results of DIV_ROUND_CLOSEST

[Guenter Roeck]

On Tue, Dec 18, 2012 at 10:04:56PM +0100, Juergen Beisert wrote:
> Hi Guenter,
> 
> Guenter Roeck wrote:
> > On Tue, Dec 18, 2012 at 04:03:41PM +0100, Juergen Beisert wrote:
> > > commit 263a523d18bca306016d75f5c8d5c57c37fe52fb changes the code of
> > > DIV_ROUND_CLOSEST in include/linux/kernel.h to fix a compile time
> > > warning.
> > >
> > > But now feeding in a zero into this macro results into 4198403. Tested
> > > with gcc 4.4.3 and 4.7.2, on arch x86 and ARM.
> > >
> > > I can reproduce this behaviour, when my ADC delivers a '0' value in the
> > > driver drivers/hwmon/s3c-hwmon.c in function s3c_hwmon_ch_show() with a
> > > current 3.7.1 kernel. The value is correct again, when the ADC delivers
> > > at least a '1'.
> > >
> > > Any ideas how to fix it correctly?
> >
> > Odd one. I ran the macro through a large number of values and divisors as
> > well as various optimization options, with different compilers, and always
> > get correct results.
> >
> > What are your compile options, and what are the channel multiplier and
> > dividers set to ?
> 
> Refer the lines 177 to 182 in drivers/hwmon/s3c-hwmon.c. "cfg->mult" is 
> '3300' 
> in my case, and "cfg->div" is '1023'. And whenever s3c_hwmon_read_ch() 
> returns '0' line 184 returns '4198403' since Linux-3.6. checked with my 
> gcc-4.6.2 cross compiler for Linux-3.6 and with gcc-4.6.2 for Linux-3.7.
> 
> I did a quick test with this macro on my host with gcc-4.4.3 and a simple 
> userland program and surprise, surprise:
> 
> result = DIV_ROUND_CLOSEST(0, 1023);
> 
> works as expected (result is 0), but
> 
> int x = 0;
> unsigned y = 1023;
> result = DIV_ROUND_CLOSEST(x, y);
> 
> gives me result = 4198403!
> 

Juergen,

Can you test the following patch ?

Thanks,
Guenter

>From d4a639c6ace7cb0de247f59c38abac72d671f135 Mon Sep 17 00:00:00 2001
From: Guenter Roeck 
Date: Tue, 18 Dec 2012 15:48:44 -0800
Subject: [PATCH] linux/kernel.h: Fix DIV_ROUND_CLOSEST for unsigned divisors

Commit 263a523 fixes a warning seen with W=1 due to change in
DIV_ROUND_CLOSEST. Unfortunately, the C compiler converts divide operations
with unsigned divisors to unsigned, even if the dividend is signed and
negative (-10 / 5U = 858993457). As a result, DIV_ROUND_CLOSEST(0, 2U)
and similar operations now return bad data.

Fix by checking for the divisor variable type when deciding which operation
to perform. This fixes DIV_ROUND_CLOSEST(0, 2U), but still returns bad data
for negative dividends divided by unsigned divisors. Mark the latter case as
unsupported.

Reported-by: Juergen Beisert 
Signed-off-by: Guenter Roeck 
---
An alternative would be to always convert divisors to signed:
int __d = (int)divisor; \
Not sure if that would be better.

 include/linux/kernel.h |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d97ed58..45726dc 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -77,13 +77,15 @@
 
 /*
  * Divide positive or negative dividend by positive divisor and round
- * to closest integer. Result is undefined for negative divisors.
+ * to closest integer. Result is undefined for negative divisors and
+ * for negative dividends if the divisor variable type is unsigned.
  */
 #define DIV_ROUND_CLOSEST(x, divisor)( \
 {  \
typeof(x) __x = x;  \
typeof(divisor) __d = divisor;  \
-   (((typeof(x))-1) > 0 || (__x) > 0) ?\
+   (((typeof(x))-1) > 0 || \
+((typeof(divisor))-1) > 0 || (__x) > 0) ?  \
(((__x) + ((__d) / 2)) / (__d)) :   \
(((__x) - ((__d) / 2)) / (__d));\
 }  \
-- 
1.7.9.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] spi: Add the flag indicate to registe new device as children of master or not.

[Jun Chen]

On Tue, 2012-12-18 at 15:26 +, Mark Brown wrote:
> On Tue, Dec 18, 2012 at 11:29:34AM -0500, Jun Chen wrote:
> 
> >   * @master: Controller to which device is connected
> > + * device_was_children_of_master is flag which the device is registed
> > + * as the children of the bus
> 
> This isn't a kerneldoc style comment (it needs the @XXX: format).  The
> name is also extremely long, can't we think of something more concise?
> 
Thank for your suggestion, I will correct this comment and use concise
flag.

> > -   spi->dev.parent = >dev;
> > +   if (device_was_children_of_master == true)
> > +   spi->dev.parent = >dev;
> > +   else
> > +   spi->dev.parent = dev;
> 
> Can you provide an example of where this is useful?  Your changelog
> didn't make it clear and the code doesn't make it obvious either.

This spi_alloc_device function will be called in the spi_new_device
function to alloc new device as the master. But other way, it is called
by the of_register_spi_devices function to register new device as the
children of the master. I will update changlog to add it. 

@@ -434,7 +440,7 @@ struct spi_device *spi_new_device(struct spi_master
*master,
 * suggests syslogged diagnostics are best here (ugh).
 */
 
-   proxy = spi_alloc_device(master);
+   proxy = spi_alloc_device(master, false);
if (!proxy)
return NULL;
 
@@ -827,7 +833,7 @@ static void of_register_spi_devices(struct
spi_master *master)
 
for_each_available_child_of_node(master->dev.of_node, nc) {
/* Alloc an spi_device */
-   spi = spi_alloc_device(master);
+   spi = spi_alloc_device(master, true);


If I have mistake, pls correct me, 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: mm, ksm: NULL ptr deref in unstable_tree_search_insert

[Hugh Dickins]

On Tue, 18 Dec 2012, Sasha Levin wrote:

> Hi all,
> 
> While fuzzing with trinity inside a KVM tools guest, running latest 
> linux-next kernel, I've
> stumbled on the following:
> 
> [  127.959264] BUG: unable to handle kernel NULL pointer dereference at 
> 0110
> [  127.960379] IP: [] __lock_acquire+0xb0/0xa90
> [  127.960379] PGD cc54067 PUD cc55067 PMD 0
> [  127.960379] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [  127.960379] Dumping ftrace buffer:
> [  127.960379](ftrace buffer empty)
> [  127.960379] CPU 0
> [  127.960379] Pid: 3174, comm: ksmd Tainted: GW
> 3.7.0-next-20121218-sasha-00023-g8e46e86 #220
> [  127.978032] RIP: 0010:[]  [] 
> __lock_acquire+0xb0/0xa90
> [  127.978032] RSP: 0018:8800137abb78  EFLAGS: 00010046
> [  127.978032] RAX: 0086 RBX: 0110 RCX: 
> 0001
> [  127.978032] RDX:  RSI:  RDI: 
> 0110
> [  127.978032] RBP: 8800137abc18 R08: 0002 R09: 
> 
> [  127.978032] R10:  R11: 0001 R12: 
> 
> [  127.978032] R13: 0002 R14: 8800137b R15: 
> 
> [  127.978032] FS:  () GS:8800bfc0() 
> knlGS:
> [  127.978032] CS:  0010 DS:  ES:  CR0: 80050033
> [  127.978032] CR2: 0110 CR3: 0cc51000 CR4: 
> 000406f0
> [  127.978032] DR0:  DR1:  DR2: 
> 
> [  127.978032] DR3:  DR6: 0ff0 DR7: 
> 0400
> [  127.978032] Process ksmd (pid: 3174, threadinfo 8800137aa000, task 
> 8800137b)
> [  127.978032] Stack:
> [  127.978032]  8800137abba8 863d8b50 8800137b0948 
> 863d8b50
> [  127.978032]  8800137abbb8 81180a12 8800137abbb8 
> 81180a9e
> [  127.978032]  8800137abbe8 8118108e 8800137abc18 
> 
> [  127.978032] Call Trace:
> [  127.978032]  [] ? get_lock_stats+0x22/0x70
> [  127.978032]  [] ? put_lock_stats.isra.16+0xe/0x40
> [  127.978032]  [] ? lock_release_holdtime+0x11e/0x130
> [  127.978032]  [] lock_acquire+0x1ca/0x270
> [  127.978032]  [] ? unstable_tree_search_insert+0x9f/0x260
> [  127.978032]  [] down_read+0x47/0x90
> [  127.978032]  [] ? unstable_tree_search_insert+0x9f/0x260
> [  127.978032]  [] unstable_tree_search_insert+0x9f/0x260
> [  127.978032]  [] cmp_and_merge_page+0xe7/0x1e0
> [  127.978032]  [] ksm_do_scan+0x65/0xa0
> [  127.978032]  [] ksm_scan_thread+0x6f/0x2d0
> [  127.978032]  [] ? abort_exclusive_wait+0xb0/0xb0
> [  127.978032]  [] ? ksm_do_scan+0xa0/0xa0
> [  127.978032]  [] kthread+0xe3/0xf0
> [  127.978032]  [] ? __kthread_bind+0x40/0x40
> [  127.978032]  [] ret_from_fork+0x7c/0xb0
> [  127.978032]  [] ? __kthread_bind+0x40/0x40
> [  127.978032] Code: 00 83 3d c3 2b b0 05 00 0f 85 d5 09 00 00 be f9 0b 00 00 
> 48 c7 c7 1c d0 b2 84 89 55 88 e8 89 82 f8 ff 8b 55
> 88 e9 b9 09 00 00 90 <48> 81 3b 60 59 22 86 b8 01 00 00 00 44 0f 44 e8 41 83 
> fc 01 77
> [  127.978032] RIP  [] __lock_acquire+0xb0/0xa90
> [  127.978032]  RSP 
> [  127.978032] CR2: 0110
> [  127.978032] ---[ end trace 3dc1b0c5db8c1230 ]---
> 
> The relevant piece of code is:
> 
>   static struct page *get_mergeable_page(struct rmap_item *rmap_item)
>   {
>   struct mm_struct *mm = rmap_item->mm;
>   unsigned long addr = rmap_item->address;
>   struct vm_area_struct *vma;
>   struct page *page;
>   
>   down_read(>mmap_sem);
> 
> Where 'mm' is NULL. I'm not really sure how it happens though.

Thanks, yes, I got that, and it's not peculiar to fuzzing at all:
I'm testing the fix at the moment, but just hit something else too
(ksmd oops on NULL p->mm in task_numa_fault i.e. task_numa_placement).

For the moment, you're safer not to run KSM: configure it out or don't
set it to run.  Fixes to follow later, I'll try to remember to Cc you.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] block: Avoid divide by 0 when max_discard_sectors is 0

[Doug Anderson]

David,

On Tue, Dec 18, 2012 at 4:42 PM, David Rientjes  wrote:
> On Tue, 18 Dec 2012, Doug Anderson wrote:
>
>> The recent commit "block: discard granularity might not be power of 2"
>> introduced a divide by 0 in the kernel.  Previously the code didn't
>> try to divide by discard_granularity when max_discard_sectors was 0.
>>
>> Fix the code to only do the division if max_discard_sectors is
>> specified.
>>
>
> Could you try Linus' patch at
> http://marc.info/?l=linux-kernel=135584941732572 and give your Tested-by
> if it solves your issue?

Hoo boy.  Thanks for the pointer.  I missed that when searching to see
if this had already been fixed.  :(

I'm pretty sure Linus's patch will fix my problem since I think my
system has "max_discard_sectors" as 0 and his patch has the same
effect as mine: avoid the divide by 0.  Someone else will need to test
his patch on a system that actually uses discard.  In any case, I will
test and send a Tested-by as soon as I'm able.

Please consider my patch abandoned.

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

[PATCH 1/2 v3] menuconfig: Add Save/Load buttons

[Wang YanQing]

If menuconfig have Save/Load button like alternative
.config editors, xconfig, nconfig, etc.We will have
a obvious benefit when use menuconfig just like
when we use others, we can Save/Load our .config quickly
and conveniently.

This patch add the Save/Load button for menuconfig.

[remove trailing space while at it for below line:
"*)  Formerly when I used Page Down and Page Up, the cursor would be set"
]

Changes:
V1-V2:
1:use PATH_MAX instead of hard code suggested by Yann E. MORIN
2:drop the spurious empty-line removal suggested by Yann E. MORIN
V2-V3:
1:ajust buttons position well centered reported by Yann E. MORIN

Signed-off-by: Wang YanQing 
---
 Hi Yann E. MORIN, can you give your Rev'ed-by and Tested-by to his patch,
 Thanks very much for your help, I just don't know how to computer out the
 right position :)

 The Changes appear in commit log is ok, I found I am not the first guy
 do it, it maybe useful in some case :)

 scripts/kconfig/lxdialog/menubox.c | 20 +++-
 scripts/kconfig/mconf.c| 30 +-
 2 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/scripts/kconfig/lxdialog/menubox.c 
b/scripts/kconfig/lxdialog/menubox.c
index 1d60473..8b534d5 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -26,7 +26,7 @@
  *
  **)  A bugfix for the Page-Down problem
  *
- **)  Formerly when I used Page Down and Page Up, the cursor would be set 
+ **)  Formerly when I used Page Down and Page Up, the cursor would be set
  *to the first position in the menu box.  Now lxdialog is a bit
  *smarter and works more like other menu systems (just have a look at
  *it).
@@ -154,12 +154,14 @@ static void print_arrows(WINDOW * win, int item_no, int 
scroll, int y, int x,
  */
 static void print_buttons(WINDOW * win, int height, int width, int selected)
 {
-   int x = width / 2 - 16;
+   int x = width / 2 - 26;
int y = height - 2;
 
print_button(win, gettext("Select"), y, x, selected == 0);
print_button(win, gettext(" Exit "), y, x + 12, selected == 1);
print_button(win, gettext(" Help "), y, x + 24, selected == 2);
+   print_button(win, gettext(" Save "), y, x + 36, selected == 3);
+   print_button(win, gettext(" Load "), y, x + 48, selected == 4);
 
wmove(win, y, x + 1 + 12 * selected);
wrefresh(win);
@@ -372,7 +374,7 @@ do_resize:
case TAB:
case KEY_RIGHT:
button = ((key == KEY_LEFT ? --button : ++button) < 0)
-   ? 2 : (button > 2 ? 0 : button);
+   ? 4 : (button > 4 ? 0 : button);
 
print_buttons(dialog, height, width, button);
wrefresh(menu);
@@ -399,17 +401,17 @@ do_resize:
return 2;
case 's':
case 'y':
-   return 3;
+   return 5;
case 'n':
-   return 4;
+   return 6;
case 'm':
-   return 5;
+   return 7;
case ' ':
-   return 6;
+   return 8;
case '/':
-   return 7;
+   return 9;
case 'z':
-   return 8;
+   return 10;
case '\n':
return button;
}
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 53975cf..9fb90f0 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -280,6 +280,7 @@ static struct menu *current_menu;
 static int child_count;
 static int single_menu_mode;
 static int show_all_options;
+static int save_and_exit;
 
 static void conf(struct menu *menu, struct menu *active_menu);
 static void conf_choice(struct menu *menu);
@@ -651,6 +652,12 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
show_helptext(_("README"), _(mconf_readme));
break;
case 3:
+   conf_save();
+   break;
+   case 4:
+   conf_load();
+   break;
+   case 5:
if (item_is_tag('t')) {
if (sym_set_tristate_value(sym, yes))
break;
@@ -658,24 +665,24 @@ static void conf(struct menu *menu, struct menu 
*active_menu)
show_textbox(NULL, setmod_text, 6, 74);
}
break;
-   

[PATCH V2] checkpatch: Warn on uapi #includes that #include

[Joe Perches]

Avoid specifying internal uapi #include paths with uapi/...
as userspace should not use and never see that.

Neaten message line wrapping above.

Signed-off-by: Joe Perches 
cc: David Howells 
---
 scripts/checkpatch.pl |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 054a293..5eab67e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2238,8 +2238,11 @@ sub process {
my $path = $1;
if ($path =~ m{//}) {
ERROR("MALFORMED_INCLUDE",
- "malformed #include filename\n" .
-   $herecurr);
+ "malformed #include filename\n" . 
$herecurr);
+   }
+   if ($path =~ "^uapi/" && $realfile =~ 
m@\binclude/uapi/@) {
+   ERROR("UAPI_INCLUDE",
+ "No #include in ...include/uapi/... 
should use a uapi/ path prefix\n" . $herecurr);
}
}
 
-- 
1.7.8.112.g3fd21

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: dapm: Fix the unpaired runtime_get/put cases

[Chuansheng Liu]

Commit f1aac484f7(Take a pm_runtime reference on DAPM devices that are enabled)
introduced runtime_get/put calling when devices are in off/non-off bias.

It is based on:
1/ device from off to non-off bias is called thru dapm_pre_sequence_async;
2/ device from non-off to off bias is called thru dapm_post_sequence_async;

There are the above conditions which then make sure runtime_get/put() are pairs.

But some devices has been set to STANDY bias directly during device probing,
such as cs42l73_probe():
cs42l73_set_bias_level(codec, SND_SOC_BIAS_STANDBY);

Then it will cause runtime_get() not be called but laterly runtime_put() will
be called. Also found some other uppaired cases.

So here add new flag get_runtime, and the logic will be:
1/ when device is from off to non-off bias, runtime_get() will be called if not 
yet;
2/ When device is off bias, runtime_put() will be called if runtime_get() has
   been called;

Signed-off-by: liu chuansheng 
---
 include/sound/soc-dapm.h |1 +
 sound/soc/soc-dapm.c |   18 --
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index e1ef63d..e52fdcc 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -586,6 +586,7 @@ struct snd_soc_dapm_context {
struct list_head list;
 
int (*stream_event)(struct snd_soc_dapm_context *dapm, int event);
+   bool get_runtime;
 
 #ifdef CONFIG_DEBUG_FS
struct dentry *debugfs_dapm;
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 1e36bc8..e6d030a 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -1460,12 +1460,15 @@ static void dapm_pre_sequence_async(void *data, 
async_cookie_t cookie)
struct snd_soc_dapm_context *d = data;
int ret;
 
+   if ((d->target_bias_level != SND_SOC_BIAS_OFF) &&
+   (d->dev) && !(d->get_runtime)) {
+   pm_runtime_get_sync(d->dev);
+   d->get_runtime = true;
+   }
+
/* If we're off and we're not supposed to be go into STANDBY */
if (d->bias_level == SND_SOC_BIAS_OFF &&
d->target_bias_level != SND_SOC_BIAS_OFF) {
-   if (d->dev)
-   pm_runtime_get_sync(d->dev);
-
ret = snd_soc_dapm_set_bias_level(d, SND_SOC_BIAS_STANDBY);
if (ret != 0)
dev_err(d->dev,
@@ -1506,9 +1509,6 @@ static void dapm_post_sequence_async(void *data, 
async_cookie_t cookie)
if (ret != 0)
dev_err(d->dev, "ASoC: Failed to turn off bias: %d\n",
ret);
-
-   if (d->dev)
-   pm_runtime_put(d->dev);
}
 
/* If we just powered up then move to active bias */
@@ -1519,6 +1519,12 @@ static void dapm_post_sequence_async(void *data, 
async_cookie_t cookie)
dev_err(d->dev, "ASoC: Failed to apply active bias: 
%d\n",
ret);
}
+
+   if ((d->bias_level == SND_SOC_BIAS_OFF) &&
+   (d->dev) && (d->get_runtime)) {
+   pm_runtime_put(d->dev);
+   d->get_runtime = false;
+   }
 }
 
 static void dapm_widget_set_peer_power(struct snd_soc_dapm_widget *peer,
-- 
1.7.0.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/

mm, ksm: NULL ptr deref in unstable_tree_search_insert

[Sasha Levin]

Hi all,

While fuzzing with trinity inside a KVM tools guest, running latest linux-next 
kernel, I've
stumbled on the following:

[  127.959264] BUG: unable to handle kernel NULL pointer dereference at 
0110
[  127.960379] IP: [] __lock_acquire+0xb0/0xa90
[  127.960379] PGD cc54067 PUD cc55067 PMD 0
[  127.960379] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  127.960379] Dumping ftrace buffer:
[  127.960379](ftrace buffer empty)
[  127.960379] CPU 0
[  127.960379] Pid: 3174, comm: ksmd Tainted: GW
3.7.0-next-20121218-sasha-00023-g8e46e86 #220
[  127.978032] RIP: 0010:[]  [] 
__lock_acquire+0xb0/0xa90
[  127.978032] RSP: 0018:8800137abb78  EFLAGS: 00010046
[  127.978032] RAX: 0086 RBX: 0110 RCX: 0001
[  127.978032] RDX:  RSI:  RDI: 0110
[  127.978032] RBP: 8800137abc18 R08: 0002 R09: 
[  127.978032] R10:  R11: 0001 R12: 
[  127.978032] R13: 0002 R14: 8800137b R15: 
[  127.978032] FS:  () GS:8800bfc0() 
knlGS:
[  127.978032] CS:  0010 DS:  ES:  CR0: 80050033
[  127.978032] CR2: 0110 CR3: 0cc51000 CR4: 000406f0
[  127.978032] DR0:  DR1:  DR2: 
[  127.978032] DR3:  DR6: 0ff0 DR7: 0400
[  127.978032] Process ksmd (pid: 3174, threadinfo 8800137aa000, task 
8800137b)
[  127.978032] Stack:
[  127.978032]  8800137abba8 863d8b50 8800137b0948 
863d8b50
[  127.978032]  8800137abbb8 81180a12 8800137abbb8 
81180a9e
[  127.978032]  8800137abbe8 8118108e 8800137abc18 

[  127.978032] Call Trace:
[  127.978032]  [] ? get_lock_stats+0x22/0x70
[  127.978032]  [] ? put_lock_stats.isra.16+0xe/0x40
[  127.978032]  [] ? lock_release_holdtime+0x11e/0x130
[  127.978032]  [] lock_acquire+0x1ca/0x270
[  127.978032]  [] ? unstable_tree_search_insert+0x9f/0x260
[  127.978032]  [] down_read+0x47/0x90
[  127.978032]  [] ? unstable_tree_search_insert+0x9f/0x260
[  127.978032]  [] unstable_tree_search_insert+0x9f/0x260
[  127.978032]  [] cmp_and_merge_page+0xe7/0x1e0
[  127.978032]  [] ksm_do_scan+0x65/0xa0
[  127.978032]  [] ksm_scan_thread+0x6f/0x2d0
[  127.978032]  [] ? abort_exclusive_wait+0xb0/0xb0
[  127.978032]  [] ? ksm_do_scan+0xa0/0xa0
[  127.978032]  [] kthread+0xe3/0xf0
[  127.978032]  [] ? __kthread_bind+0x40/0x40
[  127.978032]  [] ret_from_fork+0x7c/0xb0
[  127.978032]  [] ? __kthread_bind+0x40/0x40
[  127.978032] Code: 00 83 3d c3 2b b0 05 00 0f 85 d5 09 00 00 be f9 0b 00 00 
48 c7 c7 1c d0 b2 84 89 55 88 e8 89 82 f8 ff 8b 55
88 e9 b9 09 00 00 90 <48> 81 3b 60 59 22 86 b8 01 00 00 00 44 0f 44 e8 41 83 fc 
01 77
[  127.978032] RIP  [] __lock_acquire+0xb0/0xa90
[  127.978032]  RSP 
[  127.978032] CR2: 0110
[  127.978032] ---[ end trace 3dc1b0c5db8c1230 ]---

The relevant piece of code is:

static struct page *get_mergeable_page(struct rmap_item *rmap_item)
{
struct mm_struct *mm = rmap_item->mm;
unsigned long addr = rmap_item->address;
struct vm_area_struct *vma;
struct page *page;

down_read(>mmap_sem);

Where 'mm' is NULL. I'm not really sure how it happens though.


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

Re: [PULL REQUEST] i2c-embedded for 3.8

[Linus Torvalds]

Ugh, guys. Please check this out.

On Tue, Dec 18, 2012 at 3:41 PM, Wolfram Sang  wrote:
>
> please pull the i2c-embedded changes for 3.8 which include:
>
> * CBUS driver (an I2C variant)
> * continued rework of the omap driver
> * s3c2410 gets lots of fixes and gains pinctrl support
> * at91 gains DMA support
> * the GPIO muxer gains devicetree probing
> * typical fixes and additions all over
>
> All patches have been in linux-next before. Please pull.

I get a conflict because both sides have this:

   Revert "ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints"

which re-introduced the omap-specific ->set_mpu_wkup_lat() thing.

But in mainline the only *user* of that has gone away. And the call
location where it originally existed has moved.

It originally existed in

  arch/arm/plat-omap/i2c.c

but looking at the history, the omap i2c code first got split into
omap1 and omap2, and at that point the call-site got moved to

  arch/arm/mach-omap2/i2c.c

but then the code that the revert re-introduced got lost.

Now, in the merge I just did, I *reinstated* that
->set_mpu_wkup_lat() code that had gotten lost in mainline. But quite
frankly, the thing is ugly as heck, and I hope it could just be
deleted. Clearly nobody had noticed yet that it got lost in some merge
(possibly an earlier one of mine, but considering that I usually
notice things like this, I suspect it's one of the internal ARM ones).

I'm adding Arnd, Tony and Olof to the participants list, since they
are the main suspects.

And guys, if you decide to remove the  ->set_mpu_wkup_lat() from
arch/arm/mach-omap2/i2c.c again, please make sure that you remove the
whole infrastructure too:

  include/linux/i2c-omap.h
  drivers/i2c/busses/i2c-omap.c

Hmm? Somebody *really* needs to double-check my merge, it's possibly
quite broken, since I have in no way tested it, and I did this by
looking at some *very* messy history with code being moved across
different files etc etc.

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

Re: [rtc-linux] [RESEND PATCH] RTC: MAX77686: Add Maxim 77686 driver

[Joe Perches]

On Tue, 2012-12-18 at 16:30 -0800, Andrew Morton wrote:
> On Wed, 28 Nov 2012 15:50:57 +0900
> Jonghwa Lee  wrote:
> 
> > Add driver for support max77686 rtc.
> > MAX77686 rtc support smpl and wtsr mode. It has two alarm register
> > which can be used for alarming to wake system up. This drvier uses regmap
> > to access its register.
> > 
> > ...
> >
> > +static inline int max77686_rtc_calculate_wday(u8 shifted)
> > +{
> > +   int counter = -1;
> > +   while (shifted) {
> > +   shifted >>= 1;
> > +   counter++;
> > +   }
> > +   return counter;
> > +}
> 
> We should be able to use log2() in here?

fls(shifted) - 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/

linux-next: build failure after merge of the fsnotify tree

[Stephen Rothwell]

Hi Eric,

After merging the fsnotify tree, today's linux-next build
(powerpc_ppc64_defconfig) failed like this:

fs/notify/fdinfo.c: In function 'show_fdinfo':
fs/notify/fdinfo.c:30:18: error: 'struct fsnotify_group' has no member named 
'mark_lock'
fs/notify/fdinfo.c:36:20: error: 'struct fsnotify_group' has no member named 
'mark_lock'

Caused by commit 986ab09807ca ("fsnotify: use a mutex instead of a
spinlock to protect a groups mark list") interacting with commit
be77196b809c ("fs, notify: add procfs fdinfo helper") from Linus' tree
(via Andrew' tree).

I added the following merge fix patch:

From: Stephen Rothwell 
Date: Wed, 19 Dec 2012 11:53:20 +1100
Subject: [PATCH] fsnotify: cope with change from spinlock to mutex

Signed-off-by: Stephen Rothwell 
---
 fs/notify/fdinfo.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index 514c4b8..238a593 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -27,13 +27,13 @@ static int show_fdinfo(struct seq_file *m, struct file *f,
struct fsnotify_mark *mark;
int ret = 0;
 
-   spin_lock(>mark_lock);
+   mutex_lock(>mark_mutex);
list_for_each_entry(mark, >marks_list, g_list) {
ret = show(m, mark);
if (ret)
break;
}
-   spin_unlock(>mark_lock);
+   mutex_unlock(>mark_mutex);
return ret;
 }
 
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpCuVo2HalrI.pgp
Description: PGP signature

[PATCH 02/05] input: Core files

[Christopher Heiny]

In addition to the changes described in 0/0 of this patch set, these files
are updated as follows:

* initialization sequence rearranged to support the merging of rmi_f01 and
rmi_driver into the RMI4 core.

* the initial reset and firmware update PDT scans are split into their own
functions in order to account for the fact that the PDT may change after
the initial reset.

* Problems with release_rmidev_device() identified by Greg KH are fixed and
tested.

* EXPORT_SYMBOL() changed to EXPORT_SYMBOL_GPL(), per Greg KH input.

Signed-off-by: Christopher Heiny 
Cc: Greg Kroah-Hartman 
Cc: Dmitry Torokhov 
Cc: Linus Walleij 
Cc: Joeri de Gram 
Acked-by: Jean Delvare 

---

 drivers/input/rmi4/rmi_bus.c|  232 ---
 drivers/input/rmi4/rmi_driver.c |  655 ---
 drivers/input/rmi4/rmi_driver.h |   32 +--
 3 files changed, 468 insertions(+), 451 deletions(-)

diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index acbfd3d..71bc201 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -2,19 +2,9 @@
  * Copyright (c) 2011, 2012 Synaptics Incorporated
  * Copyright (c) 2011 Unixphere
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
  */

 #include 
@@ -75,7 +65,8 @@ static struct dentry *rmi_debugfs_root;

 static void release_rmidev_device(struct device *dev)
 {
-   device_unregister(dev);
+   struct rmi_device *rmi_dev = to_rmi_device(dev);
+   kfree(rmi_dev);
 }

 /**
@@ -110,17 +101,19 @@ int rmi_register_phys_device(struct rmi_phys_device *phys)
dev_dbg(phys->dev, "%s: Registered %s as %s.\n", __func__,
pdata->sensor_name, dev_name(_dev->dev));

-   if (IS_ENABLED(CONFIG_RMI4_DEBUG) && rmi_debugfs_root) {
+#ifdef CONFIG_RMI4_DEBUG
+   if (rmi_debugfs_root) {
rmi_dev->debugfs_root = debugfs_create_dir(
dev_name(_dev->dev), rmi_debugfs_root);
if (!rmi_dev->debugfs_root)
dev_err(_dev->dev, "Failed to create debugfs 
root.\n");
}
+#endif

phys->rmi_dev = rmi_dev;
return device_register(_dev->dev);
 }
-EXPORT_SYMBOL(rmi_register_phys_device);
+EXPORT_SYMBOL_GPL(rmi_register_phys_device);

 /**
  * rmi_unregister_phys_device - unregister a physical device connection
@@ -131,102 +124,84 @@ void rmi_unregister_phys_device(struct rmi_phys_device 
*phys)
 {
struct rmi_device *rmi_dev = phys->rmi_dev;

-   if (IS_ENABLED(CONFIG_RMI4_DEBUG) && rmi_dev->debugfs_root)
+#ifdef CONFIG_RMI4_DEBUG
+   if (rmi_dev->debugfs_root)
debugfs_remove(rmi_dev->debugfs_root);
+#endif

-   kfree(rmi_dev);
+   device_unregister(_dev->dev);
 }
-EXPORT_SYMBOL(rmi_unregister_phys_device);
+EXPORT_SYMBOL_GPL(rmi_unregister_phys_device);

-/**
- * rmi_register_function_handler - register a handler for an RMI function
- * @handler: RMI handler that should be registered.
- * @module: pointer to module that implements the handler
- * @mod_name: name of the module implementing the handler
- *
- * This function performs additional setup of RMI function handler and
- * registers it with the RMI core so that it can be bound to
- * RMI function devices.
- */
-int __rmi_register_function_handler(struct rmi_function_handler *handler,
-struct module *owner,
-const char *mod_name)
+static int rmi_bus_match(struct device *dev, struct device_driver *drv)
 {
-   int error;
+   struct rmi_function_driver *fn_drv;
+   struct rmi_function_dev *fn;

-   handler->driver.bus = _bus_type;
-   handler->driver.owner = owner;
-   handler->driver.mod_name = mod_name;
+   /*
+* This seems a little broken to me.  It  means a system can only ever
+* have one kind of sensor driver.  It'll work for now, but I think in
+* the long run we need to revisit this.
+*/
+   if (dev->type == _sensor_type && drv == _sensor_driver.driver)
+   return 1;

-   error = driver_register(>driver);
-   if (error) {
-

[PATCH 04/05] input: F01 Device control

[Christopher Heiny]

In addition to the changes described in 0/0 of this patchset, this patch
includes:

* changes to the handling of sysfs as requested in feedback to our
previous patch.

* device serialization updated to conform to the latest specification.

Signed-off-by: Christopher Heiny 
Cc: Dmitry Torokhov 
Cc: Linus Walleij 
Cc: Joeri de Gram 
Acked-by: Jean Delvare 

---

 drivers/input/rmi4/rmi_f01.c |  733 --
 drivers/input/rmi4/rmi_f01.h |   29 +--
 2 files changed, 425 insertions(+), 337 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index d7461d7..d33fa16 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -2,19 +2,9 @@
  * Copyright (c) 2011-2012 Synaptics Incorporated
  * Copyright (c) 2011 Unixphere
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
  */

 #include 
@@ -26,6 +16,8 @@
 #include "rmi_driver.h"
 #include "rmi_f01.h"

+#define FUNCTION_NUMBER 0x01
+
 /**
  * @reset - set this bit to force a firmware reset of the sensor.
  */
@@ -109,11 +101,17 @@ struct f01_ds4_queries {
u8 reset_pin_number:4;
 } __attribute__((__packed__));

+/*
+ *
+ * @serialization - 7 bytes of device serialization data.  The meaning of
+ * these bytes varies from product to product, consult your product spec sheet.
+ */
 struct f01_data {
struct f01_device_control device_control;
struct f01_basic_queries basic_queries;
struct f01_device_status device_status;
-   u8 product_id[RMI_PRODUCT_ID_LENGTH + 1];
+   u8 serialization[F01_SERIALIZATION_SIZE];
+   u8 product_id[RMI_PRODUCT_ID_LENGTH+1];

u16 interrupt_enable_addr;
u16 doze_interval_addr;
@@ -136,19 +134,19 @@ struct f01_data {
 #ifdef CONFIG_RMI4_DEBUG
 struct f01_debugfs_data {
bool done;
-   struct rmi_function *fn;
+   struct rmi_function_dev *fn_dev;
 };

 static int f01_debug_open(struct inode *inodep, struct file *filp)
 {
struct f01_debugfs_data *data;
-   struct rmi_function *fn = inodep->i_private;
+   struct rmi_function_dev *fn_dev = inodep->i_private;

data = kzalloc(sizeof(struct f01_debugfs_data), GFP_KERNEL);
if (!data)
return -ENOMEM;

-   data->fn = fn;
+   data->fn_dev = fn_dev;
filp->private_data = data;
return 0;
 }
@@ -167,7 +165,7 @@ static ssize_t interrupt_enable_read(struct file *filp, 
char __user *buffer,
char local_buf[size];
char *current_buf = local_buf;
struct f01_debugfs_data *data = filp->private_data;
-   struct f01_data *f01 = data->fn->data;
+   struct f01_data *f01 = data->fn_dev->data;

if (data->done)
return 0;
@@ -197,7 +195,7 @@ static ssize_t interrupt_enable_read(struct file *filp, 
char __user *buffer,
current_buf += len;
total_len += len;
} else {
-   dev_err(>fn->dev, "Failed to build 
interrupt_enable buffer, code = %d.\n",
+   dev_err(>fn_dev->dev, "Failed to build 
interrupt_enable buffer, code = %d.\n",
len);
return snprintf(local_buf, size, "unknown\n");
}
@@ -206,7 +204,7 @@ static ssize_t interrupt_enable_read(struct file *filp, 
char __user *buffer,
if (len > 0)
total_len += len;
else
-   dev_warn(>fn->dev, "%s: Failed to append carriage 
return.\n",
+   dev_warn(>fn_dev->dev, "%s: Failed to append carriage 
return.\n",
 __func__);

if (copy_to_user(buffer, local_buf, total_len))
@@ -224,7 +222,7 @@ static ssize_t interrupt_enable_write(struct file *filp,
int irq_count = 0;
int irq_reg = 0;
struct f01_debugfs_data *data = filp->private_data;
-   struct f01_data *f01 = data->fn->data;
+   struct f01_data *f01 = data->fn_dev->data;

retval = copy_from_user(buf, buffer, size);
if (retval)
@@ -244,7 +242,7 @@ static ssize_t interrupt_enable_write(struct 

[PATCH 01/05] input: RMI4 header file

[Christopher Heiny]

In addition to the changes described in part 0/5, this fixes some cut
issues in the comments for module_rmi_function_driver.

Signed-off-by: Christopher Heiny 
Cc: Dmitry Torokhov 
Cc: Linus Walleij 
Cc: Joeri de Gram 
Acked-by: Jean Delvare 

---

 include/linux/rmi.h |   95 +++
 1 files changed, 43 insertions(+), 52 deletions(-)

diff --git a/include/linux/rmi.h b/include/linux/rmi.h
index daca41b..eec926f 100644
--- a/include/linux/rmi.h
+++ b/include/linux/rmi.h
@@ -2,25 +2,16 @@
  * Copyright (c) 2011, 2012 Synaptics Incorporated
  * Copyright (c) 2011 Unixphere
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
  */

 #ifndef _RMI_H
 #define _RMI_H
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 

 extern struct bus_type rmi_bus_type;

@@ -73,7 +63,7 @@ enum rmi_attn_polarity {
  *   automatically enabled for this sensor.
  */
 struct rmi_f11_2d_axis_alignment {
-   bool swap_axes;
+   u32 swap_axes;
bool flip_x;
bool flip_y;
int clip_X_low;
@@ -82,7 +72,6 @@ struct rmi_f11_2d_axis_alignment {
int clip_Y_high;
int offset_X;
int offset_Y;
-   int rel_report_enabled;
u8 delta_x_threshold;
u8 delta_y_threshold;
 };
@@ -105,6 +94,7 @@ enum rmi_f11_sensor_type {

 /**
  * struct rmi_f11_sensor_data - overrides defaults for a single F11 2D sensor.
+ *
  * @axis_align - provides axis alignment overrides (see above).
  * @type_a - all modern RMI F11 firmwares implement Multifinger Type B
  * protocol.  Set this to true to force MF Type A behavior, in case you find
@@ -338,13 +328,14 @@ struct rmi_function_descriptor {
u8 function_version;
 };

-struct rmi_function;
+struct rmi_function_dev;
 struct rmi_device;

 /**
- * struct rmi_function_handler - driver routines for a particular RMI function.
+ * struct rmi_function_driver - driver routines for a particular RMI function.
  *
  * @func: The RMI function number
+ * @probe: Called when the handler is successfully matched to a function 
device.
  * @reset: Called when a reset of the touch sensor is detected.  The routine
  * should perform any out-of-the-ordinary reset handling that might be
  * necessary.  Restoring of touch sensor configuration registers should be
@@ -361,37 +352,31 @@ struct rmi_device;
  *
  * All callbacks are expected to return 0 on success, error code on failure.
  */
-struct rmi_function_handler {
+struct rmi_function_driver {
struct device_driver driver;

u8 func;
-   int (*probe)(struct rmi_function *fn);
-   void (*remove)(struct rmi_function *fn);
-   int (*config)(struct rmi_function *fn);
-   int (*reset)(struct rmi_function *fn);
-   int (*attention)(struct rmi_function *fn, unsigned long *irq_bits);
+   int (*probe)(struct rmi_function_dev *fc);
+   int (*remove)(struct rmi_function_dev *fc);
+   int (*config)(struct rmi_function_dev *fc);
+   int (*reset)(struct rmi_function_dev *fc);
+   int (*attention)(struct rmi_function_dev *fc,
+   unsigned long *irq_bits);
 #ifdef CONFIG_PM
-   int (*suspend)(struct rmi_function *fn);
-   int (*resume)(struct rmi_function *fn);
+   int (*suspend)(struct rmi_function_dev *fc);
+   int (*resume)(struct rmi_function_dev *fc);
 #endif
 };

-#define to_rmi_function_handler(d) \
-   container_of(d, struct rmi_function_handler, driver)
-
-int __must_check __rmi_register_function_handler(struct rmi_function_handler *,
-struct module *, const char *);
-#define rmi_register_function_handler(handler) \
-   __rmi_register_function_handler(handler, THIS_MODULE, KBUILD_MODNAME)
-
-void rmi_unregister_function_handler(struct rmi_function_handler *);
+#define to_rmi_function_driver(d) \
+   container_of(d, struct rmi_function_driver, driver);

 /**
- * struct rmi_function - represents the implementation of an RMI4
- * function for a particular device (basically, a driver 

[PATCH 03/05] input: I2C physical layer

[Christopher Heiny]

Changes here are limited to those described in the 0/0 of this patchset, plus
some tweaks to debugging output.

Signed-off-by: Christopher Heiny 
Cc: Dmitry Torokhov 
Cc: Linus Walleij 
Cc: Joeri de Gram 
Acked-by: Jean Delvare 

---

 drivers/input/rmi4/rmi_i2c.c |  141 ++
 1 files changed, 20 insertions(+), 121 deletions(-)

diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index ca32101..513791c 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -2,19 +2,9 @@
  * Copyright (c) 2011, 2012 Synaptics Incorporated
  * Copyright (c) 2011 Unixphere
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
  */

 #include 
@@ -58,7 +48,7 @@ struct rmi_i2c_data {
u8 *debug_buf;
int debug_buf_size;

-   bool comms_debug;
+   u32 comms_debug;
 #ifdef CONFIG_RMI4_DEBUG
struct dentry *debugfs_comms;
 #endif
@@ -66,107 +56,13 @@ struct rmi_i2c_data {

 #ifdef CONFIG_RMI4_DEBUG

-
-/**
- * struct i2c_debugfs_data - stores information for debugfs
- *
- * @done: Indicates that we are done reading debug data. Subsequent reads
- * will return EOF.
- * @i2c_data: Pointer to the i2c data
- *
- */
-struct i2c_debugfs_data {
-   bool done;
-   struct rmi_i2c_data *i2c_data;
-};
-
-static int debug_open(struct inode *inodep, struct file *filp)
-{
-   struct i2c_debugfs_data *data;
-
-   data = kzalloc(sizeof(struct i2c_debugfs_data), GFP_KERNEL);
-   if (!data)
-   return -ENOMEM;
-
-   data->i2c_data = inodep->i_private;
-   filp->private_data = data;
-   return 0;
-}
-
-static int debug_release(struct inode *inodep, struct file *filp)
-{
-   kfree(filp->private_data);
-   return 0;
-}
-
-static ssize_t comms_debug_read(struct file *filp, char __user *buffer,
-   size_t size, loff_t *offset) {
-   int retval;
-   char *local_buf;
-   struct i2c_debugfs_data *dfs = filp->private_data;
-   struct rmi_i2c_data *data = dfs->i2c_data;
-
-   if (dfs->done)
-   return 0;
-
-   local_buf = kcalloc(size, sizeof(u8), GFP_KERNEL);
-   if (!local_buf)
-   return -ENOMEM;
-
-   dfs->done = 1;
-
-   retval = snprintf(local_buf, PAGE_SIZE, "%u\n", data->comms_debug);
-
-   if (retval <= 0 || copy_to_user(buffer, local_buf, retval))
-   retval = -EFAULT;
-   kfree(local_buf);
-
-   return retval;
-}
-
-static ssize_t comms_debug_write(struct file *filp, const char __user *buffer,
-  size_t size, loff_t *offset) {
-   int retval;
-   char *local_buf;
-   unsigned int new_value;
-   struct i2c_debugfs_data *dfs = filp->private_data;
-   struct rmi_i2c_data *data = dfs->i2c_data;
-
-   local_buf = kcalloc(size, sizeof(u8), GFP_KERNEL);
-   if (!local_buf)
-   return -ENOMEM;
-   retval = copy_from_user(local_buf, buffer, size);
-   if (retval) {
-   kfree(local_buf);
-   return -EFAULT;
-   }
-
-   retval = sscanf(local_buf, "%u", _value);
-   kfree(local_buf);
-   if (retval != 1 || new_value > 1)
-   return -EINVAL;
-
-   data->comms_debug = new_value;
-
-   return size;
-}
-
-
-static const struct file_operations comms_debug_fops = {
-   .owner = THIS_MODULE,
-   .open = debug_open,
-   .release = debug_release,
-   .read = comms_debug_read,
-   .write = comms_debug_write,
-};
-
 static int setup_debugfs(struct rmi_device *rmi_dev, struct rmi_i2c_data *data)
 {
if (!rmi_dev->debugfs_root)
return -ENODEV;

-   data->debugfs_comms = debugfs_create_file("comms_debug", RMI_RW_ATTR,
-   rmi_dev->debugfs_root, data, _debug_fops);
+   data->debugfs_comms = debugfs_create_bool("comms_debug", RMI_RW_ATTR,
+   rmi_dev->debugfs_root, >comms_debug);
if (!data->debugfs_comms || IS_ERR(data->debugfs_comms)) {
dev_warn(_dev->dev, "Failed to create debugfs 
comms_debug.\n");
data->debugfs_comms = 

[PATCH 05/05] input: F11 2D input

[Christopher Heiny]

In addition to the changes described in 0/0 of this patchset, this patch
includes:

* elimination of unused sysfs and debugfs parameters.

* some fixes to the input device parameters.

* removal of some stray Android stuff.

Signed-off-by: Christopher Heiny 
To: Henrik Rydberg 
Cc: Dmitry Torokhov 
Cc: Linus Walleij 
Cc: Joeri de Gram 
Acked-by: Jean Delvare 

---

 drivers/input/rmi4/rmi_f11.c | 1187 +++---
 1 files changed, 197 insertions(+), 990 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 8457ab4..7a8b806 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -2,38 +2,26 @@
  * Copyright (c) 2011,2012 Synaptics Incorporated
  * Copyright (c) 2011 Unixphere
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
  */

 #define FUNCTION_DATA f11_data
+#define FUNCTION_NUMBER 0x11

 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include "rmi_driver.h"
-
-#ifdef CONFIG_RMI4_DEBUG
-#include 
-#include 
 #include 
-#endif
+#include "rmi_driver.h"

 #define F11_MAX_NUM_OF_SENSORS 8
 #define F11_MAX_NUM_OF_FINGERS 10
@@ -54,7 +42,6 @@
 #define DEFAULT_MIN_ABS_MT_TRACKING_ID 1
 #define DEFAULT_MAX_ABS_MT_TRACKING_ID 10
 #define NAME_BUFFER_SIZE 256
-#define FUNCTION_NUMBER 0x11

 /** A note about RMI4 F11 register structure.
  *
@@ -439,195 +426,9 @@ struct f11_2d_ctrl0_9 {
u8 ctrl9_reserved:4;
 } __attribute__((__packed__));

-/**
- * @single_tap_int_enable - enable tap gesture recognition.
- * @tap_n_hold_int_enable - enable tap-and-hold gesture recognition.
- * @double_tap_int_enable - enable double-tap gesture recognition.
- * @early_tap_int_enable - enable early tap notification.
- * @flick_int_enable - enable flick detection.
- * @press_int_enable - enable press gesture recognition.
- * @pinch_int_enable - enable pinch detection.
- */
-struct f11_2d_ctrl10 {
-   u8 single_tap_int_enable:1;
-   u8 tap_n_hold_int_enable:1;
-   u8 double_tap_int_enable:1;
-   u8 early_tap_int_enable:1;
-   u8 flick_int_enable:1;
-   u8 press_int_enable:1;
-   u8 pinch_int_enable:1;
-   u8 reserved:1;
-} __attribute__((__packed__));
-
-/**
- * @palm_detect_int_enable - enable palm detection feature.
- * @rotate_int_enable - enable rotate gesture detection.
- * @touch_shape_int_enable - enable the TouchShape feature.
- * @scroll_zone_int_enable - enable scroll zone reporting.
- * @multi_finger_scroll_int_enable - enable the multfinger scroll feature.
- */
-struct f11_2d_ctrl11 {
-   u8 palm_detect_int_enable:1;
-   u8 rotate_int_enable:1;
-   u8 touch_shape_int_enable:1;
-   u8 scroll_zone_int_enable:1;
-   u8 multi_finger_scroll_int_enable:1;
-   u8 reserved:3;
-} __attribute__((__packed__));
-
-/**
- * @sens_adjustment - allows a host to alter the overall sensitivity of a
- * 2-D sensor. A positive value in this register will make the sensor more
- * sensitive than the factory defaults, and a negative value will make it
- * less sensitive.
- * @hyst_adjustment - increase the touch/no-touch hysteresis by 2 Z-units for
- * each one unit increment in this setting.
- */
-struct f11_2d_ctrl14 {
-   s8 sens_adjustment:5;
-   u8 hyst_adjustment:3;
-} __attribute__((__packed__));
-
-/**
- * @max_tap_time - the maximum duration of a tap, in 10-millisecond units.
- */
-struct f11_2d_ctrl15 {
-   u8 max_tap_time:8;
-} __attribute__((__packed__));
-
-/**
- * @min_press_time - The minimum duration required for stationary finger(s) to
- * generate a press gesture, in 10-millisecond units.
- */
-struct f11_2d_ctrl16 {
-   u8 min_press_time:8;
-} __attribute__((__packed__));
-
-/**
- * @max_tap_distance - Determines the maximum finger movement allowed during
- * a tap, in 0.1-millimeter units.
- */
-struct f11_2d_ctrl17 {
-   u8 max_tap_distance:8;
-} __attribute__((__packed__));
-
-/**
- * @min_flick_distance - the minimum finger movement for a flick gesture,
- * in 1-millimeter units.
- * @min_flick_speed - the minimum finger speed for a 

[RFC PATCH 00/05] input: Synaptics RMI4 Touchscreen Driver

[Christopher Heiny]

This patchset implements changes based on the synaptics-rmi4 branch of
Dmitry's input tree.  The base for the patchset is Dmitry's commit
0af25383d395fb5ece54b79d12d06138bf8b9836 from 2012-11-28.

Overall this patchset implements the following changes:

* updates to Dmitry's RMI4_CORE structure from his 2012-11-28 patches.
This tries to maintain the same approach as Dmitry's implementation, but
we had to move away from using the bus probe() routine, since it wasn't
possible for that routine to readily determine if it had a struct driver() for
an RMI4 sensor or an RMI4 device.  Otherwise, we've stuck close to Dmitry's
work, which has tidied things up nicely.

* We've renamed the structures rmi_function_handler to rmi_function_driver and
rmi_device to rmi_function_dev, mainly because they actually were being treated
as drivers and devices for individual RMI4 functions, and the previous
terminology was somewhat confusing.

* Moved much of the debugfs stuff to use standard macros.  This required
changing a bunch of bools to u32s.  Debugfs interfaces that handled multiple
values in a single file were NOT changed, because some debug tools depend on
that format.  Once we've udpate those tools, we'll change or remove the
remaining interfaces.

* Many other bools were changed to u8, per Dmitry's request.

* Trivial - file copyright header is updated to be more in line with the rest
of the files under ./input.


We've broken this patch into 6 parts, as follows:
01 - public header file
02 - core sensor and bus implementation
03 - I2C physical layer driver
04.05 - drivers for individual RMI functions


Hopefully this is the last time we'll have wide-ranging structural changes in
the driver code, and future patchsets can be much smaller and confined to
one or two areas of interest.


Comments and other feedback on this driver are welcomed.

Christopher Heiny and the Synaptics RMI4 driver team

Signed-off-by: Christopher Heiny 
Cc: Dmitry Torokhov 
Cc: Jean Delvare 
Cc: Linus Walleij 
Cc: Joeri de Gram 

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

Re: [rtc-linux] [PATCH] rtc: recycle id when unloading a rtc driver

[Andrew Morton]

On Thu,  2 Aug 2012 16:53:25 -0700
Vincent Palatin  wrote:

> When calling rtc_device_unregister, we are not freeing the id used by the
> driver.
> So when doing a unload/load cycle for a RTC driver (e.g. rmmod rtc_cmos
> && modprobe rtc_cmos), its id is incremented by one. As a consequence,
> we no longer have neither an rtc0 driver nor a /proc/driver/rtc (as it
> only exists for the first driver).
> 
> Signed-off-by: Vincent Palatin 
> ---
>  drivers/rtc/class.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
> index dc4c274..37b1d82 100644
> --- a/drivers/rtc/class.c
> +++ b/drivers/rtc/class.c
> @@ -238,6 +238,7 @@ void rtc_device_unregister(struct rtc_device *rtc)
>   rtc_proc_del_device(rtc);
>   device_unregister(>dev);
>   rtc->ops = NULL;
> + ida_simple_remove(_ida, rtc->id);
>   mutex_unlock(>ops_lock);
>   put_device(>dev);
>   }

Now I think about it, this shouldn't have been needed?

That put_device() should call rtc_device_release(), which does the
ida_simple_remove().  Isn't that working?

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

Re: [PATCH 3/3] perf tests: Add event parsing test for '*:*' tracepoints

[Jiri Olsa]

On Tue, Dec 18, 2012 at 02:35:50PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 17, 2012 at 02:08:38PM +0100, Jiri Olsa escreveu:
> > Adding event parsing test for '*:*' tracepoints. Checking the
> > count matches all the tracepoints available plus current
> > standard tracepoint perf_event_attr check.
> > 
> > This test exposes warnings from traceevent lib about not being
> > able to parse some tracepoints' format data. Exposing these
> > messages in the automated test suite will probably speed up
> > the fix ;-)
> 
> Ok, merged, now where is that speedup? ;-)

well.. I did say 'probably' ;-)

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/