[PATCH 3/6] perf trace: Free evlist resources properly on return path

[Namhyung Kim]

From: Namhyung Kim 

The trace_run() function calls several evlist functions but misses
some pair-wise cleanup routines on return path.  Fix it.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-trace.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 49fedb51d569..ab3ed4af1466 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -452,7 +452,7 @@ static int trace__run(struct trace *trace, int argc, const 
char **argv)
err = trace__symbols_init(trace, evlist);
if (err < 0) {
printf("Problems initializing symbol libraries!\n");
-   goto out_delete_evlist;
+   goto out_delete_maps;
}
 
perf_evlist__config(evlist, >opts);
@@ -465,20 +465,20 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
argv, false, false);
if (err < 0) {
printf("Couldn't run the workload!\n");
-   goto out_delete_evlist;
+   goto out_delete_maps;
}
}
 
err = perf_evlist__open(evlist);
if (err < 0) {
printf("Couldn't create the events: %s\n", strerror(errno));
-   goto out_delete_evlist;
+   goto out_delete_maps;
}
 
err = perf_evlist__mmap(evlist, UINT_MAX, false);
if (err < 0) {
printf("Couldn't mmap the events: %s\n", strerror(errno));
-   goto out_delete_evlist;
+   goto out_close_evlist;
}
 
perf_evlist__enable(evlist);
@@ -534,7 +534,7 @@ again:
 
if (trace->nr_events == before) {
if (done)
-   goto out_delete_evlist;
+   goto out_unmap_evlist;
 
poll(evlist->pollfd, evlist->nr_fds, -1);
}
@@ -544,6 +544,12 @@ again:
 
goto again;
 
+out_unmap_evlist:
+   perf_evlist__munmap(evlist);
+out_close_evlist:
+   perf_evlist__close(evlist);
+out_delete_maps:
+   perf_evlist__delete_maps(evlist);
 out_delete_evlist:
perf_evlist__delete(evlist);
 out:
-- 
1.7.11.7

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

[PATCH 1/6] perf evlist: Introduce perf_evlist__close()

[Namhyung Kim]

From: Namhyung Kim 

It's a pair of perf_evlist__open().

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/evlist.c | 19 ---
 tools/perf/util/evlist.h |  1 +
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 5b012b8d7a14..1344fbd2472e 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -721,10 +721,20 @@ void perf_evlist__set_selected(struct perf_evlist *evlist,
evlist->selected = evsel;
 }
 
+void perf_evlist__close(struct perf_evlist *evlist)
+{
+   struct perf_evsel *evsel;
+   int ncpus = cpu_map__nr(evlist->cpus);
+   int nthreads = thread_map__nr(evlist->threads);
+
+   list_for_each_entry_reverse(evsel, >entries, node)
+   perf_evsel__close(evsel, ncpus, nthreads);
+}
+
 int perf_evlist__open(struct perf_evlist *evlist)
 {
struct perf_evsel *evsel;
-   int err, ncpus, nthreads;
+   int err;
 
list_for_each_entry(evsel, >entries, node) {
err = perf_evsel__open(evsel, evlist->cpus, evlist->threads);
@@ -734,12 +744,7 @@ int perf_evlist__open(struct perf_evlist *evlist)
 
return 0;
 out_err:
-   ncpus = cpu_map__nr(evlist->cpus);
-   nthreads = thread_map__nr(evlist->threads);
-
-   list_for_each_entry_reverse(evsel, >entries, node)
-   perf_evsel__close(evsel, ncpus, nthreads);
-
+   perf_evlist__close(evlist);
errno = -err;
return err;
 }
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index c096da7d6d58..0583d36252be 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -81,6 +81,7 @@ struct perf_evsel *perf_evlist__id2evsel(struct perf_evlist 
*evlist, u64 id);
 union perf_event *perf_evlist__mmap_read(struct perf_evlist *self, int idx);
 
 int perf_evlist__open(struct perf_evlist *evlist);
+void perf_evlist__close(struct perf_evlist *evlist);
 
 void perf_evlist__config(struct perf_evlist *evlist,
 struct perf_record_opts *opts);
-- 
1.7.11.7

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

[PATCH 4/6] perf record: Fixup return path of cmd_record()

[Namhyung Kim]

From: Namhyung Kim 

The error path of calling perf_target__parse_uid wrongly went to
out_free_fd.  Also add missing evlist cleanup routines.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-record.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 80cc3ea07788..9f2344a2c506 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1028,7 +1028,7 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
ui__error("%s", errbuf);
 
err = -saved_errno;
-   goto out_free_fd;
+   goto out_symbol_exit;
}
 
err = -ENOMEM;
@@ -1059,6 +1059,9 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
}
 
err = __cmd_record(, argc, argv);
+
+   perf_evlist__munmap(evsel_list);
+   perf_evlist__close(evsel_list);
 out_free_fd:
perf_evlist__delete_maps(evsel_list);
 out_symbol_exit:
-- 
1.7.11.7

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

[PATCH 6/6] perf test: Fixup return path of perf record test case

[Namhyung Kim]

From: Namhyung Kim 

Add missing perf_evlist__close() function.

Cc: Jiri Olsa 
Signed-off-by: Namhyung Kim 
---
 tools/perf/tests/perf-record.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/perf-record.c b/tools/perf/tests/perf-record.c
index ffab5a41ff0a..72d8881873b0 100644
--- a/tools/perf/tests/perf-record.c
+++ b/tools/perf/tests/perf-record.c
@@ -143,7 +143,7 @@ int test__PERF_RECORD(void)
err = perf_evlist__mmap(evlist, opts.mmap_pages, false);
if (err < 0) {
pr_debug("perf_evlist__mmap: %s\n", strerror(errno));
-   goto out_delete_maps;
+   goto out_close_evlist;
}
 
/*
@@ -306,6 +306,8 @@ found_exit:
}
 out_err:
perf_evlist__munmap(evlist);
+out_close_evlist:
+   perf_evlist__close(evlist);
 out_delete_maps:
perf_evlist__delete_maps(evlist);
 out_delete_evlist:
-- 
1.7.11.7

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

[PATCH 2/6] perf evsel: Cleanup perf_evsel__exit()

[Namhyung Kim]

From: Namhyung Kim 

Use perf_evsel__free_* because they do the same thing and ensures the
pointer has NULL value at the end.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/evsel.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index dc16231f7a5d..7fde9fb79966 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -673,9 +673,8 @@ void perf_evsel__free_counts(struct perf_evsel *evsel)
 void perf_evsel__exit(struct perf_evsel *evsel)
 {
assert(list_empty(>node));
-   xyarray__delete(evsel->fd);
-   xyarray__delete(evsel->sample_id);
-   free(evsel->id);
+   perf_evsel__free_fd(evsel);
+   perf_evsel__free_id(evsel);
 }
 
 void perf_evsel__delete(struct perf_evsel *evsel)
-- 
1.7.11.7

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

[PATCH 5/6] perf test: Fixup return path of open-syscall-tp-fields test case

[Namhyung Kim]

From: Namhyung Kim 

Add missing evlist cleanup functions.

Cc: Jiri Olsa 
Signed-off-by: Namhyung Kim 
---
 tools/perf/tests/open-syscall-tp-fields.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/open-syscall-tp-fields.c 
b/tools/perf/tests/open-syscall-tp-fields.c
index 02cb74174e23..fc5b9fca8b47 100644
--- a/tools/perf/tests/open-syscall-tp-fields.c
+++ b/tools/perf/tests/open-syscall-tp-fields.c
@@ -48,13 +48,13 @@ int test__syscall_open_tp_fields(void)
err = perf_evlist__open(evlist);
if (err < 0) {
pr_debug("perf_evlist__open: %s\n", strerror(errno));
-   goto out_delete_evlist;
+   goto out_delete_maps;
}
 
err = perf_evlist__mmap(evlist, UINT_MAX, false);
if (err < 0) {
pr_debug("perf_evlist__mmap: %s\n", strerror(errno));
-   goto out_delete_evlist;
+   goto out_close_evlist;
}
 
perf_evlist__enable(evlist);
@@ -110,6 +110,10 @@ out_ok:
err = 0;
 out_munmap:
perf_evlist__munmap(evlist);
+out_close_evlist:
+   perf_evlist__close(evlist);
+out_delete_maps:
+   perf_evlist__delete_maps(evlist);
 out_delete_evlist:
perf_evlist__delete(evlist);
 out:
-- 
1.7.11.7

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

Re: [PATCH 1/1] mfd: palmas: Add power off control

[Bill Huang]

On Fri, 2013-03-15 at 13:19 +0800, Stephen Warren wrote:
> On 03/14/2013 04:58 AM, Bill Huang wrote:
> > Hook up "pm_power_off" to palmas power off routine if there is DT
> > property "ti,system-power-controller" defined, so platform which is
> > powered by this regulator can be powered off properly.
> 
> > diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
> 
> > +   pdata->pm_off = of_property_read_bool(node,
> > +   "ti,system-power-controller");
> 
> You would need to add that property to the DT binding documentation for
> this device.
Does it work that some time later Laxmain helps to add it when he
submits his pmic bindings for Palmas?


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

Re: [PATCH 2/3] ARM: davinci: da850: Enable EHRPWM TBCLK from CFG_CHIP1

[Sekhar Nori]

On 3/15/2013 10:51 AM, Philip, Avinash wrote:
> On Fri, Mar 15, 2013 at 10:38:58, Nori, Sekhar wrote:
>> On 3/15/2013 10:27 AM, Philip, Avinash wrote:
>>> On Thu, Mar 14, 2013 at 18:31:52, Nori, Sekhar wrote:
 On 3/14/2013 4:07 PM, Philip Avinash wrote:
> da850 platforms require TBCLK synchronization in CFG_CHIP1 register for
> TBCLK enable in EHRPWM modules. Enabling of TBCLK is done only if EHRPWM
> DT node status is set to "okay" DT blob.
> Also adds macro definitions for DA8XX_EHRPWM_TBCLKSYNC and
> DA8XX_CFGCHIP1_REG.

 So there is actually a TBCLK in DA850 - it's just not modeled as a clock
 similar to the way it is done on AM335x? If yes, then instead of adding
 a dummy clock node and doing the TBCLK enable as part of init, why not
 model TBCLK in clock tree even on DA850?
>>>
>>>
>>> TBCLK enabling should done from platform specific way. In DA850 it is done 
>>> at
>>> CFGCHIP1 register. Unfortunately Davinci clock frame work will support only
>>> clock nodes inside PLLC and PSC modules. Handling of CFGCHP1 require
>>
>> That's true at the moment, but that can be fixed.
> 
> I will check.

For an example of non-PLL non-PSC clock on davinci, you can look at cdce
clock registration in board-dm646x-evm.c

> 
>>
>>> modifications in clock frame work.
>>>
>>> Hence handling it as part of initialization.
>>
>> I am curious as to how this clock is handled in am335x. I searched for
>> tbclk in arch/arm/ of linux-next but could not find any references.
>> Where should I be looking?
> 
> Patch is submitted. This patch is not in Paul's tree.
> 
> [PATCH v2] ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK
> https://patchwork.kernel.org/patch/2127581/

Thanks!

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

Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

[Bill Huang]

On Fri, 2013-03-15 at 13:22 +0800, Stephen Warren wrote:
> On 03/14/2013 07:20 PM, Bill Huang wrote:
> > On Fri, 2013-03-15 at 01:54 +0800, Stephen Warren wrote:
> >> On 03/14/2013 03:28 AM, Bill Huang wrote:
> >>> On Thu, 2013-03-14 at 17:21 +0800, Peter De Schrijver wrote:
>  On Thu, Mar 14, 2013 at 03:15:11AM +0100, Bill Huang wrote:
> 
> > I don't think deferring will work either, considering the usage of DVFS,
> > device voltage is tightly coupled with frequency, when clock rate is
> > about to increase, we have to boost voltage first and we can lower the
> > voltage after the clock rate has decreased. All the above sequence have
> > to be guaranteed or you might crash, so deferring not only make thing
> > complicated in controlling the order but also hurt performance.
> 
>  But we could use notifiers in clk_prepare/clk_unprepare to set the 
>  voltage no?
>  As clk_prepare/clk_unprepare have to be called before clk_enable or after
>  clk_disable, the voltage can be raised to a safe level, before the clock
>  becomes active.
> >>>
> >>> Thanks Peter, actually I'm just about to propose my v2 RFC which add
> >>> notifier in clk_prepare/clk_unprepare.
> >>
> >> Can't clk_set_rate() be called while the clock is prepared, or even
> >> enabled? I don't see how your proposal would work.
> >
> > I think it works with just a little sacrifice on saving more power but
> > that's related minor. Taking clk_prepare as an indicator on that clock
> > will be enabled later, so we can raise the voltage to a safe level
> > (according to the current rate or maybe default rate when clk_prepare is
> > called, some time late when clk_set_rate() is called we can adjust again
> > according to the requested rate change)
> 
> Is clk_set_rate() only legal to call in non-atomic contexts then? The
> header file doesn't say, although I guess since many other functions
> explicitly say they can't, then by omission it can...

I think clk_set_rate can only be called in non-atomic contexts since
there are existing non-atomic clock notifier hooked in it.


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

[GIT PULL] hwmon patches for 3.9-rc3

[Guenter Roeck]

Hi Linus,

Please pull hwmon patches for Linux 3.9-rc3 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-for-linus

Thanks,
Guenter

--

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hwmon-for-linus

for you to fetch changes up to 8c958c703ef8804093437959221951eaf0e1e664:

  hwmon: (pmbus/ltc2978) Fix temperature reporting (2013-03-14 09:03:51 -0700)


Bug fixes for pmbus, ltc2978, and lineage-pem drivers
Added specific maintainer for some hwmon drivers


Axel Lin (1):
  hwmon: (lineage-pem) Add missing terminating entry for 
pem_[input|fan]_attributes

David Woodhouse (1):
  hwmon: (pmbus) Fix krealloc() misuse in pmbus_add_attribute()

Guenter Roeck (2):
  MAINTAINERS: Add maintainer for MAX6697, INA209, and INA2XX drivers
  hwmon: (pmbus/ltc2978) Fix temperature reporting

 MAINTAINERS  |   25 +
 drivers/hwmon/lineage-pem.c  |2 ++
 drivers/hwmon/pmbus/ltc2978.c|   14 --
 drivers/hwmon/pmbus/pmbus_core.c |   12 +++-
 4 files changed, 42 insertions(+), 11 deletions(-)


signature.asc
Description: Digital signature

linux-next: Tree for Mar 15

[Stephen Rothwell]

Hi all,

Changes since 20130314:

The l2-mtd tree gained conflicts against the mtd tree.

The staging tree gained a conflict against Linus' tree.

The gpio tree still had its build failure for which I reverted a commit.



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 218 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 (f4846e5 Merge branch 'rcu/urgent' of 
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu)
Merging fixes/master (d287b87 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of 
git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes)
Merging arc-current/for-curr (180d406 ARC: ABIv3: fork/vfork wrappers not 
needed in "no-legacy-syscall" ABI)
Merging arm-current/fixes (418df63a ARM: 7670/1: fix the memset fix)
Merging m68k-current/for-linus (5618395 m68k: Sort out !CONFIG_MMU_SUN3 vs. 
CONFIG_HAS_DMA)
Merging powerpc-merge/merge (54c9b225 powerpc: Set DSCR bit in FSCR setup)
Merging sparc/master (76950e6 sparc64: correctly recognize SPARC64-X chips)
Merging net/master (cca7af3 skb: Propagate pfmemalloc on skb from head page 
only)
Merging ipsec/master (85dfb74 af_key: initialize satype in 
key_notify_policy_flush())
Merging sound-current/for-linus (303985f ALSA: hda - Disable IDT eapd_switch if 
there are no internal speakers)
Merging pci-current/for-linus (249bfb8 PCI/PM: Clean up PME state when removing 
a device)
Merging wireless/master (9437a24 rtlwifi: rtl8192cu: Fix problem that prevents 
reassociation)
Merging driver-core.current/driver-core-linus (f6161aa Linux 3.9-rc2)
Merging tty.current/tty-linus (c51d41a tty: serial: fix typo "SERIAL_S3C2412")
Merging usb.current/usb-linus (40e4591 Merge branch 'for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging staging.current/staging-linus (564c526 staging: comedi: dt9812: use 
CR_CHAN() for channel number)
Merging char-misc.current/char-misc-linus (3d374d0 final removal of 
CONFIG_EXPERIMENTAL)
Merging input-current/for-linus (4b7d293 Input: mms114 - Fix regulator enable 
and disable paths)
Merging md-current/for-linus (f3378b4 md: expedite metadata update when 
switching  read-auto -> active)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (8fd61d3 crypto: user - ensure user supplied 
strings are nul-terminated)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option)
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 (ab28698 of: define struct device 
in of_platform.h if !OF_DEVICE and !OF_ADDRESS)
Merging spi-current/spi/merge (d3601e5 spi/sh-hspi: fix return value check in 
hspi_probe()

Re: [PATCH 1/1] amba: tegra-ahb: Fix build error w/ PM_SLEEP w/o PM_RUNTIME

[Stephen Warren]

On 03/14/2013 03:08 AM, Hiroshi Doyu wrote:
> Make this depend on CONFIG_PM. This protection is necessary to not
> cause any build errors with any combination of PM features especially
> when supporting a new SoC where each PM features are being enabled
> one-by-one during its depelopment.

Looks fine to me.

Acked-by: Stephen Warren 

I assume Russell will want this to go through his patch tracker.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

[Stephen Warren]

On 03/14/2013 07:20 PM, Bill Huang wrote:
> On Fri, 2013-03-15 at 01:54 +0800, Stephen Warren wrote:
>> On 03/14/2013 03:28 AM, Bill Huang wrote:
>>> On Thu, 2013-03-14 at 17:21 +0800, Peter De Schrijver wrote:
 On Thu, Mar 14, 2013 at 03:15:11AM +0100, Bill Huang wrote:

> I don't think deferring will work either, considering the usage of DVFS,
> device voltage is tightly coupled with frequency, when clock rate is
> about to increase, we have to boost voltage first and we can lower the
> voltage after the clock rate has decreased. All the above sequence have
> to be guaranteed or you might crash, so deferring not only make thing
> complicated in controlling the order but also hurt performance.

 But we could use notifiers in clk_prepare/clk_unprepare to set the voltage 
 no?
 As clk_prepare/clk_unprepare have to be called before clk_enable or after
 clk_disable, the voltage can be raised to a safe level, before the clock
 becomes active.
>>>
>>> Thanks Peter, actually I'm just about to propose my v2 RFC which add
>>> notifier in clk_prepare/clk_unprepare.
>>
>> Can't clk_set_rate() be called while the clock is prepared, or even
>> enabled? I don't see how your proposal would work.
>
> I think it works with just a little sacrifice on saving more power but
> that's related minor. Taking clk_prepare as an indicator on that clock
> will be enabled later, so we can raise the voltage to a safe level
> (according to the current rate or maybe default rate when clk_prepare is
> called, some time late when clk_set_rate() is called we can adjust again
> according to the requested rate change)

Is clk_set_rate() only legal to call in non-atomic contexts then? The
header file doesn't say, although I guess since many other functions
explicitly say they can't, then by omission it can...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/3] ARM: davinci: da850: Enable EHRPWM TBCLK from CFG_CHIP1

[Philip, Avinash]

On Fri, Mar 15, 2013 at 10:38:58, Nori, Sekhar wrote:
> On 3/15/2013 10:27 AM, Philip, Avinash wrote:
> > On Thu, Mar 14, 2013 at 18:31:52, Nori, Sekhar wrote:
> >> On 3/14/2013 4:07 PM, Philip Avinash wrote:
> >>> da850 platforms require TBCLK synchronization in CFG_CHIP1 register for
> >>> TBCLK enable in EHRPWM modules. Enabling of TBCLK is done only if EHRPWM
> >>> DT node status is set to "okay" DT blob.
> >>> Also adds macro definitions for DA8XX_EHRPWM_TBCLKSYNC and
> >>> DA8XX_CFGCHIP1_REG.
> >>
> >> So there is actually a TBCLK in DA850 - it's just not modeled as a clock
> >> similar to the way it is done on AM335x? If yes, then instead of adding
> >> a dummy clock node and doing the TBCLK enable as part of init, why not
> >> model TBCLK in clock tree even on DA850?
> > 
> > 
> > TBCLK enabling should done from platform specific way. In DA850 it is done 
> > at
> > CFGCHIP1 register. Unfortunately Davinci clock frame work will support only
> > clock nodes inside PLLC and PSC modules. Handling of CFGCHP1 require
> 
> That's true at the moment, but that can be fixed.

I will check.

> 
> > modifications in clock frame work.
> > 
> > Hence handling it as part of initialization.
> 
> I am curious as to how this clock is handled in am335x. I searched for
> tbclk in arch/arm/ of linux-next but could not find any references.
> Where should I be looking?

Patch is submitted. This patch is not in Paul's tree.

[PATCH v2] ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK
https://patchwork.kernel.org/patch/2127581/

Paul,
Can you accept the above patch.

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 

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

[PATCH 3/3 v2] tracing: Prevent buffer overwrite disabled for latency tracers

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

The latency tracers require the buffers to be in overwrite mode,
otherwise they get screwed up. Force the buffers to stay in overwrite
mode when latency tracers are enabled.

Added a flag_changed() method to the tracer structure to allow
the tracers to see what flags are being changed, and also be able
to prevent the change from happing.

Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c  |   38 +++--
 kernel/trace/trace.h  |6 ++
 kernel/trace/trace_irqsoff.c  |   19 ++-
 kernel/trace/trace_sched_wakeup.c |   18 +-
 4 files changed, 65 insertions(+), 16 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 02debab..4f1dade 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2881,11 +2881,25 @@ static int set_tracer_option(struct tracer *trace, char 
*cmp, int neg)
return -EINVAL;
 }
 
-static void set_tracer_flags(unsigned int mask, int enabled)
+/* Some tracers require overwrite to stay enabled */
+int trace_keep_overwrite(struct tracer *tracer, u32 mask, int set)
+{
+   if (tracer->enabled && (mask & TRACE_ITER_OVERWRITE) && !set)
+   return -1;
+
+   return 0;
+}
+
+int set_tracer_flag(unsigned int mask, int enabled)
 {
/* do nothing if flag is already set */
if (!!(trace_flags & mask) == !!enabled)
-   return;
+   return 0;
+
+   /* Give the tracer a chance to approve the change */
+   if (current_trace->flag_changed)
+   if (current_trace->flag_changed(current_trace, mask, !!enabled))
+   return -EINVAL;
 
if (enabled)
trace_flags |= mask;
@@ -2904,13 +2918,15 @@ static void set_tracer_flags(unsigned int mask, int 
enabled)
 
if (mask == TRACE_ITER_PRINTK)
trace_printk_start_stop_comm(enabled);
+
+   return 0;
 }
 
 static int trace_set_options(char *option)
 {
char *cmp;
int neg = 0;
-   int ret = 0;
+   int ret = -ENODEV;
int i;
 
cmp = strstrip(option);
@@ -2924,7 +2940,7 @@ static int trace_set_options(char *option)
 
for (i = 0; trace_options[i]; i++) {
if (strcmp(cmp, trace_options[i]) == 0) {
-   set_tracer_flags(1 << i, !neg);
+   ret = set_tracer_flag(1 << i, !neg);
break;
}
}
@@ -2943,6 +2959,7 @@ tracing_trace_options_write(struct file *filp, const char 
__user *ubuf,
size_t cnt, loff_t *ppos)
 {
char buf[64];
+   int ret;
 
if (cnt >= sizeof(buf))
return -EINVAL;
@@ -2952,7 +2969,9 @@ tracing_trace_options_write(struct file *filp, const char 
__user *ubuf,
 
buf[cnt] = 0;
 
-   trace_set_options(buf);
+   ret = trace_set_options(buf);
+   if (ret < 0)
+   return ret;
 
*ppos += cnt;
 
@@ -3256,6 +3275,9 @@ static int tracing_set_tracer(const char *buf)
goto out;
 
trace_branch_disable();
+
+   current_trace->enabled = false;
+
if (current_trace->reset)
current_trace->reset(tr);
 
@@ -3300,6 +3322,7 @@ static int tracing_set_tracer(const char *buf)
}
 
current_trace = t;
+   current_trace->enabled = true;
trace_branch_enable(tr);
  out:
mutex_unlock(_types_lock);
@@ -4788,9 +4811,12 @@ trace_options_core_write(struct file *filp, const char 
__user *ubuf, size_t cnt,
return -EINVAL;
 
mutex_lock(_types_lock);
-   set_tracer_flags(1 << index, val);
+   ret = set_tracer_flag(1 << index, val);
mutex_unlock(_types_lock);
 
+   if (ret < 0)
+   return ret;
+
*ppos += cnt;
 
return cnt;
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 57d7e53..2081971 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -283,11 +283,15 @@ struct tracer {
enum print_line_t   (*print_line)(struct trace_iterator *iter);
/* If you handled the flag setting, return 0 */
int (*set_flag)(u32 old_flags, u32 bit, int set);
+   /* Return 0 if OK with change, else return non-zero */
+   int (*flag_changed)(struct tracer *tracer,
+   u32 mask, int set);
struct tracer   *next;
struct tracer_flags *flags;
boolprint_max;
booluse_max_tr;
boolallocated_snapshot;
+   boolenabled;
 };
 
 
@@ -943,6 +947,8 @@ extern const char *__stop___trace_bprintk_fmt[];
 
 void trace_printk_init_buffers(void);
 void trace_printk_start_comm(void);
+int trace_keep_overwrite(struct tracer *tracer, u32 mask, int 

[PATCH 0/3 v2] [GIT PULL][3.9] tracing: Fixes with flags and latency tracers

[Steven Rostedt]

Ingo,

Here's take two of the last patch series I sent. The only difference
with this series is that I encapsulate the max_tr reference with
the #ifdef CONFIG_TRACER_MAX_TRACE. Other than that, it's the same.

Here's the recap:

The first patch fixes a long standing bug where the changing of
the trace options has absolutely no protection against multiple
changers. Luckily, this is something that requires human (root)
action, and is usually performed by a single individual. But as
scripts are starting to become more active, this bug is bound to
be triggered.

The second patch is a bug where the setting of the overwrite flag
can cause the max and normal buffers to get out of sync. This
is more predomitinant with the 3.9 snapshot feature, but still
has an affect on the latency tracers. Which bring us to the third
patch.

The third patch I found out that disabling overwrite to the buffers
screws with the latency tracers. If the buffer is in produce consumer
mode, the irqsoff tracer and friends wont show any output at all.
This was a bit frustrating to figure out.

Hopefully this time it's good.

Thanks,

-- Steve

Please pull the latest tip/perf/urgent-2 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/perf/urgent-2

Head SHA1: 613f04a0f51e6e68ac6fe571ab79da3c0a5eb4da


Steven Rostedt (Red Hat) (3):
  tracing: Protect tracer flags with trace_types_lock
  tracing: Keep overwrite in sync between regular and snapshot buffers
  tracing: Prevent buffer overwrite disabled for latency tracers


 kernel/trace/trace.c  |   56 +
 kernel/trace/trace.h  |6 
 kernel/trace/trace_irqsoff.c  |   19 +
 kernel/trace/trace_sched_wakeup.c |   18 
 4 files changed, 78 insertions(+), 21 deletions(-)



signature.asc
Description: This is a digitally signed message part

[PATCH 1/3 v2] tracing: Protect tracer flags with trace_types_lock

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

Seems that the tracer flags have never been protected from
synchronous writes. Luckily, admins don't usually modify the
tracing flags via two different tasks. But if scripts were to
be used to modify them, then they could get corrupted.

Move the trace_types_lock that protects against tracers changing
to also protect the flags being set.

Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 53df283..00daf5f 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2916,6 +2916,8 @@ static int trace_set_options(char *option)
cmp += 2;
}
 
+   mutex_lock(_types_lock);
+
for (i = 0; trace_options[i]; i++) {
if (strcmp(cmp, trace_options[i]) == 0) {
set_tracer_flags(1 << i, !neg);
@@ -2924,11 +2926,10 @@ static int trace_set_options(char *option)
}
 
/* If no option could be set, test the specific tracer options */
-   if (!trace_options[i]) {
-   mutex_lock(_types_lock);
+   if (!trace_options[i])
ret = set_tracer_option(current_trace, cmp, neg);
-   mutex_unlock(_types_lock);
-   }
+
+   mutex_unlock(_types_lock);
 
return ret;
 }
@@ -4781,7 +4782,10 @@ trace_options_core_write(struct file *filp, const char 
__user *ubuf, size_t cnt,
 
if (val != 0 && val != 1)
return -EINVAL;
+
+   mutex_lock(_types_lock);
set_tracer_flags(1 << index, val);
+   mutex_unlock(_types_lock);
 
*ppos += cnt;
 
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

[PATCH 1/1] pinctrl: coh901: Fix checkpatch error

[Sachin Kamat]

Fixes the following checkpatch error:
ERROR: space required before the open parenthesis '('

Signed-off-by: Sachin Kamat 
---
 drivers/pinctrl/pinctrl-coh901.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-coh901.c b/drivers/pinctrl/pinctrl-coh901.c
index 8b7e7bc..86887850 100644
--- a/drivers/pinctrl/pinctrl-coh901.c
+++ b/drivers/pinctrl/pinctrl-coh901.c
@@ -359,7 +359,7 @@ int u300_gpio_config_get(struct gpio_chip *chip,
drmode &= (U300_GPIO_PXPCR_PIN_MODE_MASK << ((offset & 0x07) << 1));
drmode >>= ((offset & 0x07) << 1);
 
-   switch(param) {
+   switch (param) {
case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
*config = 0;
if (biasmode)
-- 
1.7.4.1

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

[PATCH 2/3 v2] tracing: Keep overwrite in sync between regular and snapshot buffers

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

Changing the overwrite mode for the ring buffer via the trace
option only sets the normal buffer. But the snapshot buffer could
swap with it, and then the snapshot would be in non overwrite mode
and the normal buffer would be in overwrite mode, even though the
option flag states otherwise.

Keep the two buffers overwrite modes in sync.

Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 00daf5f..02debab 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2895,8 +2895,12 @@ static void set_tracer_flags(unsigned int mask, int 
enabled)
if (mask == TRACE_ITER_RECORD_CMD)
trace_event_enable_cmd_record(enabled);
 
-   if (mask == TRACE_ITER_OVERWRITE)
+   if (mask == TRACE_ITER_OVERWRITE) {
ring_buffer_change_overwrite(global_trace.buffer, enabled);
+#ifdef CONFIG_TRACER_MAX_TRACE
+   ring_buffer_change_overwrite(max_tr.buffer, enabled);
+#endif
+   }
 
if (mask == TRACE_ITER_PRINTK)
trace_printk_start_stop_comm(enabled);
-- 
1.7.10.4




signature.asc
Description: This is a digitally signed message part

Re: [PATCH 1/1] mfd: palmas: Add power off control

[Stephen Warren]

On 03/14/2013 04:58 AM, Bill Huang wrote:
> Hook up "pm_power_off" to palmas power off routine if there is DT
> property "ti,system-power-controller" defined, so platform which is
> powered by this regulator can be powered off properly.

> diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c

> + pdata->pm_off = of_property_read_bool(node,
> + "ti,system-power-controller");

You would need to add that property to the DT binding documentation for
this device.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig

[Chen Gang]

于 2013年03月15日 12:52, Michael Neuling 写道:
> Yep it's a known problem but no one has bothered to fix it since it
> doesn't happen in a config that anyone cares about like
> pseries_defconfig and ppc64_defconfig.  We've been moving code around in
> this area a lot recently hence the breakage.
> 
> It should be fixed though.  Patches welcome. :-)

  thanks, and I should try, and very glad to try.

  :-)  :-)

  excuse me, I try to provide related patch within this month (2013-03-31), is 
it ok ?
  the reason is:
I am not familiar with ppc assembly code, neither ppc kernel,
so need additional time resource.
  (originally, I worked for x86(_64) core dump analysing for kernel and 
user programs)

  thanks.

-- 
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 0/9] overlay filesystem: request for inclusion (v17)

[Al Viro]

On Fri, Mar 15, 2013 at 02:09:14PM +0900, J. R. Okajima wrote:

> If so, it has a big disadvantage for the layer-fs (or branch-fs) to have
> to implement a new method for whiteout.
> 
> Overlayfs implements whiteout as symlink+xattr which consumes an
> inode. And you don't like it, right?
> What I showed is another generic approach without xattr where the new
> method to whiteout is unnecessary.

I'm yet to see the reason that would make implementing that method a big
disadvantage, TBH...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] pinctrl: generic: Fix checkpatch errors

[Sachin Kamat]

Fixes the following type of checkpatch errors:
ERROR: space required before the open parenthesis '('

Signed-off-by: Sachin Kamat 
---
 drivers/pinctrl/pinconf-generic.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinconf-generic.c 
b/drivers/pinctrl/pinconf-generic.c
index 791e6a3..2ad5a8d 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -60,7 +60,7 @@ void pinconf_generic_dump_pin(struct pinctrl_dev *pctldev,
if (!ops->is_generic)
return;
 
-   for(i = 0; i < ARRAY_SIZE(conf_items); i++) {
+   for (i = 0; i < ARRAY_SIZE(conf_items); i++) {
unsigned long config;
int ret;
 
@@ -95,7 +95,7 @@ void pinconf_generic_dump_group(struct pinctrl_dev *pctldev,
if (!ops->is_generic)
return;
 
-   for(i = 0; i < ARRAY_SIZE(conf_items); i++) {
+   for (i = 0; i < ARRAY_SIZE(conf_items); i++) {
unsigned long config;
int ret;
 
@@ -126,7 +126,7 @@ void pinconf_generic_dump_config(struct pinctrl_dev 
*pctldev,
 {
int i;
 
-   for(i = 0; i < ARRAY_SIZE(conf_items); i++) {
+   for (i = 0; i < ARRAY_SIZE(conf_items); i++) {
if (pinconf_to_config_param(config) != conf_items[i].param)
continue;
seq_printf(s, "%s: 0x%x", conf_items[i].display,
-- 
1.7.4.1

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

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[J. R. Okajima]

Al Viro:
> > +- whiteout is hardlinked in order to reduce the consumption of inodes
> > +  on branch
>
> *blink* Whiteouts have no inodes at all.  Filesystem has an additional
> kind of directory entries, recognizable as whiteouts.  How they are
> done is up to filesystem in question.

"no inodes at all"?
Are you assuming the implementation in dcache only (with a new d_type
flag)? And it is up to the real fs (layer or branch) whether it consumes
inode or not?
If so, it has a big disadvantage for the layer-fs (or branch-fs) to have
to implement a new method for whiteout.

Overlayfs implements whiteout as symlink+xattr which consumes an
inode. And you don't like it, right?
What I showed is another generic approach without xattr where the new
method to whiteout is unnecessary.


> > +The whiteout in aufs is very similar to Unionfs's. That is represented
> > +by its filename. UnionMount takes an approach of a file mode, but I am
> > +afraid several utilities (find(1) or something) will have to support it.
>
> Why the devil should find(1) even see them?

It is the case when find(1) for the layer-fs/branch-fs directly.


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

Re: [PATCH 2/3] ARM: davinci: da850: Enable EHRPWM TBCLK from CFG_CHIP1

[Sekhar Nori]

On 3/15/2013 10:27 AM, Philip, Avinash wrote:
> On Thu, Mar 14, 2013 at 18:31:52, Nori, Sekhar wrote:
>> On 3/14/2013 4:07 PM, Philip Avinash wrote:
>>> da850 platforms require TBCLK synchronization in CFG_CHIP1 register for
>>> TBCLK enable in EHRPWM modules. Enabling of TBCLK is done only if EHRPWM
>>> DT node status is set to "okay" DT blob.
>>> Also adds macro definitions for DA8XX_EHRPWM_TBCLKSYNC and
>>> DA8XX_CFGCHIP1_REG.
>>
>> So there is actually a TBCLK in DA850 - it's just not modeled as a clock
>> similar to the way it is done on AM335x? If yes, then instead of adding
>> a dummy clock node and doing the TBCLK enable as part of init, why not
>> model TBCLK in clock tree even on DA850?
> 
> 
> TBCLK enabling should done from platform specific way. In DA850 it is done at
> CFGCHIP1 register. Unfortunately Davinci clock frame work will support only
> clock nodes inside PLLC and PSC modules. Handling of CFGCHP1 require

That's true at the moment, but that can be fixed.

> modifications in clock frame work.
> 
> Hence handling it as part of initialization.

I am curious as to how this clock is handled in am335x. I searched for
tbclk in arch/arm/ of linux-next but could not find any references.
Where should I be looking?

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] hw_random: free rng_buffer at module exit

[Rusty Russell]

Satoru Takeuchi  writes:
> At Thu, 14 Mar 2013 17:11:21 +1030,
> Rusty Russell wrote:
>> 
>> Satoru Takeuchi  writes:
>> > Hi Rusty,
>> >
>> > At Tue, 12 Mar 2013 15:43:33 -0700,
>> > Greg Kroah-Hartman wrote:
>> >> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
>> >>  
>> >>   mutex_lock(_mutex);
>> >>  
>> >> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
>> >> + err = -ENOMEM;
>> >> + if (!rng_buffer) {
>> >> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
>> >
>> > rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
>> > at hwrng_unregister()? If my suspect is correct, the same problem is
>> > in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
>> > some hours.
>> >
>> > Corecct me if I'm wrong.
>> 
>> Yes, it would be nice to free it, but it really makes sense to free it
>> in module_cleanup() (which would have to be written, as the module
>> currently doesn't have one).
>> 
>> Cheers,
>> Rusty.
>
> From: Satoru Takeuchi 
>
> rng-core module allocates rng_buffer by kmalloc() since commit
> f7f154f1246ccc5a0a7e9ce50932627d60a0c878. But this buffer won't be
> freed and there is a memory leak possibility at module exit.
>
> Signed-off-by: Satoru Takeuchi 
> Cc: Rusty Russell 
> Cc: Matt Mackall 
> Cc: Herbert Xu 
> Cc: Aurelien Jarno 
> Cc: Greg Kroah-Hartman 
> Cc: sta...@vger.kernel.org

Cc: stable might be overkill, but I've tested it and put it in my patch
queue, and will push it to Linus once it's survived linux-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/

[PATCH 1/2] pinctrl: generic: Make 'conf_items' static

[Sachin Kamat]

'conf_items' is used only in this file. Silences the below
sparse warning:
drivers/pinctrl/pinconf-generic.c:37:24: warning:
symbol 'conf_items' was not declared. Should it be static?

Signed-off-by: Sachin Kamat 
---
 drivers/pinctrl/pinconf-generic.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/pinctrl/pinconf-generic.c 
b/drivers/pinctrl/pinconf-generic.c
index 9c43685..791e6a3 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -34,7 +34,7 @@ struct pin_config_item {
 
 #define PCONFDUMP(a, b, c) { .param = a, .display = b, .format = c }
 
-struct pin_config_item conf_items[] = {
+static struct pin_config_item conf_items[] = {
PCONFDUMP(PIN_CONFIG_BIAS_DISABLE, "input bias disabled", NULL),
PCONFDUMP(PIN_CONFIG_BIAS_HIGH_IMPEDANCE, "input bias high impedance", 
NULL),
PCONFDUMP(PIN_CONFIG_BIAS_PULL_UP, "input bias pull up", NULL),
-- 
1.7.4.1

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

Re: [RFC -next] linux/linkage.h: fix symbol prefix handling

[Rusty Russell]

James Hogan  writes:
> On 14/03/13 04:00, Rusty Russell wrote:
>> From: Rusty Russell 
>> Subject: CONFIG_SYMBOL_PREFIX: cleanup.
...
> Reviewed-by: James Hogan 
> Tested-by: James Hogan  (metag)

Thanks.

> The only other special case of symbol prefixing I'm aware of is in
> scripts/genksyms/genksyms.c. It makes the decision at runtime based
> on the --arch=$ARCH argument, and is the only use of the arch argument:
>
>>  if ((strcmp(arch, "h8300") == 0) || (strcmp(arch, "blackfin") == 0) ||
>>  (strcmp(arch, "metag") == 0))
>>  mod_prefix = "_";
>
> Does the patch below look reasonable in addition to your patch?
> (Note: I'm not sure if genksyms is only used internally or whether
> it's API should be kept stable?).
>
> Thanks
> James
>
> Subject: [PATCH] genksyms: pass symbol-prefix instead of arch

Agreed, I've applied this.

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: [RFC PATCH] Allow optional module parameters

[Rusty Russell]

Andy Lutomirski  writes:
> Current parameter behavior is odd.  Boot parameters that have values
> and don't match anything become environment variables, with no
> warning.  Boot parameters without values that don't match anything
> go into argv_init.  Everything goes into /proc/cmdline.
>
> The init_module and finit_module syscalls, however, are strict:
> parameters that don't match result in -ENOENT.
>
> kmod (and hence modprobe), when loading a module called foo, look in
> /proc/cmdline for foo.x or foo.x=y, strip off the foo., and pass the
> rest to init_module.
>
> The upshot is that booting with module.nonexistent_parameter=1 is
> okay if module is built in or missing entirely but prevents module
> from loading if it's an actual module.  Similarly, option module
> nonexistent_parameter=1 in /etc/modprobe.d prevents the module from
> loading the parameter goes away.  This means that removing module
> parameters unnecessarily breaks things.

Err, yes.  Don't remove module parameters, they're part of the API.  Do
you have a particular example?

> With this patch, module parameters can be made explicitly optional.
> This approach is IMO silly, but it's unlikely to break anything,
> since I doubt that anyone needs init parameters or init environment
> variables that end in a tilde.

It's silly for the removal problem: that should be handled in the
kernel.  How would the poor user know that the option is going away?
So how about we add a module_param_obsolete(name) macro?

If a parameter were introduced, and the user wanted to specify it *if*
it was supported, that might justify this approach rather than using
complex install commands.  But I don't believe that's common, is it?

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: linux-next: manual merge of the signal tree with the modules tree

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Al,
>
> Today's linux-next merge of the signal tree got a conflict in
> include/asm-generic/unistd.h between commit 837718bfd28b
> ("CONFIG_SYMBOL_PREFIX: cleanup") from the modules tree and commit
> e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations")
> from the signal tree.
>
> The latter moved the cond_syscall stuff to linkage.h, so I applied the
> following patch as a merge fixup and can carry the fix as necessary (no
> action is required).  I am not sure if this is completely correct or all
> that is needed.

Your fix looks correct, thanks.

I've been forced to update that patch after another round of
improvements, so you may need to re-do the merge.

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

Re: use after free in sysfs_find_dirent

[Sasha Levin]

On 03/15/2013 12:03 AM, Sasha Levin wrote:
> On 03/07/2013 01:26 AM, Dave Jones wrote:
>> On Thu, Mar 07, 2013 at 02:02:30PM +0800, Greg Kroah-Hartman wrote:
>>  > On Thu, Mar 07, 2013 at 12:28:54AM -0500, Dave Jones wrote:
>>  > > general protection fault:  [#1] PREEMPT SMP 
>>  > > Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock bnep fuse 
>> rfcomm hidp l2tp_ppp l2tp_core 8021q garp mrp dlci pppoe pppox ppp_generic 
>> slhc scsi_transport_iscsi rose caif_socket caif can_raw bridge af_key 
>> can_bcm llc2 stp can netrom phonet af_rxrpc nfnetlink ipt_ULOG x25 rds irda 
>> crc_ccitt ax25 ipx p8023 p8022 decnet atm appletalk psnap llc nfc lockd 
>> sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack 
>> nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel 
>> snd_hda_codec snd_pcm btusb snd_page_alloc bluetooth snd_timer snd microcode 
>> rfkill usb_debug serio_raw pcspkr edac_core soundcore vhost_net tun r8169 
>> macvtap macvlan mii kvm_amd kvm
>>  > > CPU 0 
>>  > > Pid: 23476, comm: trinity-child1 Not tainted 3.9.0-rc1+ #69 Gigabyte 
>> Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
>>  > > RIP: 0010:[]  [] 
>> sysfs_find_dirent+0x47/0xf0
>>  > > RSP: 0018:88000585bd68  EFLAGS: 00010202
>>  > > RAX: 94be55f6 RBX: 6b6b6b6b6b6b6b6b RCX: 6b6b6b6b
>>  > > RDX:  RSI:  RDI: 
>>  > > RBP: 88000585bd88 R08:  R09: 
>>  > > R10:  R11:  R12: 0029c161
>>  > > R13: 8800a8918288 R14:  R15: 0009
>>  > > FS:  7fa12651e740() GS:88012ae0() 
>> knlGS:
>>  > > CS:  0010 DS:  ES:  CR0: 80050033
>>  > > CR2: 0010 CR3: 1a128000 CR4: 07f0
>>  > > DR0:  DR1:  DR2: 
>>  > > DR3:  DR6: 0ff0 DR7: 0400
>>  > > Process trinity-child1 (pid: 23476, threadinfo 88000585a000, task 
>> 8800cd454920)
>>  > > Stack:
>>  > >  880128edc1e8 8800a8918250 fffe 88012265f430
>>  > >  88000585bdb8 812357cd 8800a8918250 8801226514d0
>>  > >  88000585bf38  88000585bde8 811bb30d
>>  > > Call Trace:
>>  > >  [] sysfs_lookup+0x6d/0xe0
>>  > >  [] lookup_real+0x1d/0x60
>>  > >  [] __lookup_hash+0x38/0x50
>>  > >  [] lookup_hash+0x19/0x20
>>  > >  [] kern_path_create+0x93/0x170
>>  > >  [] ? getname_flags.part.32+0x86/0x150
>>  > >  [] user_path_create+0x4a/0x70
>>  > >  [] sys_mkdirat+0x39/0xe0
>>  > >  [] system_call_fastpath+0x16/0x1b
>>  > > Code: 00 48 8b 9f 88 00 00 00 f6 c4 0f 0f 95 c0 48 85 f6 0f 95 c2 38 d0 
>> 75 79 4c 89 ee 4c 89 f7 e8 91 ef ff ff 41 89 c4 48 85 db 74 1d <8b> 4b 28 41 
>> 39 cc 74 21 44 89 e0 29 c8 83 f8 00 7c 2c 74 45 48 
>>  > > RIP  [] sysfs_find_dirent+0x47/0xf0
>>  > >  RSP 
>>  > > ---[ end trace 4ba97703eaafbb8b ]---
>>  > 
>>  > Any hint as to what was happening here when this crashed?
>>
>> Given I haven't seen this (or the other sysfs bug) before today, I'm going
>> to assume it's due to one of the features I added to trinity today.
>>
>> 1. Instead of just relying on filenames it gathers from sysfs on startup,
>>it now also generates mangled variants of them.
>>(Appending a / followed by garbage for eg)
>>
>> 2. When a syscall wants a page of memory, it now sometimes hands it one
>>filled with malformed UTF-8 characters.
>>
>> 3. A combo of the above, that garbage appended to a pathname may be unicode 
>> junk.
>>
>> Could be some of those that caused these bugs.
>>
>> I just retried rerunning the test a few times.  Every time I run for a while
>> I end up with different crashes.  It's raining bugs over here.
>> (Here's another sysfs one below)
>>
>> Running 'trinity -c mkdirat -V /sys' doesn't seem to trigger it, so it's an
>> interaction with something else maybe.
>>
>> The one common thing here is that 6b6b6b6b6b6b6b6b showing up in every trace,
>> suggesting a use-after-free bugs. They may all be different manifestations
>> of the same underlying bug if there's some kind of refcounting bug perhaps.
>> (This may also be why

Re: [PATCH] export.h: clarify comment in relation to avoiding includes

[Rusty Russell]

Paul Gortmaker  writes:

> The existing comment indicated what was desired, but it didn't
> necessarily convey the reasoning behind it in an effective way.
>
> Cc: Rusty Russell 
> Signed-off-by: Paul Gortmaker 
> ---
>  include/linux/export.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/export.h b/include/linux/export.h
> index 696c0f4..d14cf26 100644
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -5,8 +5,9 @@
>   * to reduce the amount of pointless cruft we feed to gcc when only
>   * exporting a simple symbol or two.
>   *
> - * If you feel the need to add #include  to this file
> - * then you are doing something wrong and should go away silently.
> + * More specifically, it was all the #include  lines in
> + * module.h that we wanted to avoid, so please avoid adding any such
> + * similar include lines here, if at all possible.
>   */
>  
>  /* Some toolchains use a `_' prefix for all user symbols. */
> -- 
> 1.8.1.2

I prefer that :)

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

Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'

[Will Deacon]

On Thu, Mar 14, 2013 at 01:08:00PM +0530, Santosh Shilimkar wrote:
> Will,

Hi guys,

I'm out of the office at the moment and have really terrible connectivity,
so I can't do too much until next week. However, I don't think adding the
has_ossr check is the right fix for this problem.

> On Wednesday 13 March 2013 05:59 PM, Lokesh Vutla wrote:
> > Hi Dietmar,
> > On Wednesday 13 March 2013 05:35 PM, Dietmar Eggemann wrote:
> >> On 13/03/13 06:52, Lokesh Vutla wrote:
> >>> Commit {9a6eb31 ARM: hw_breakpoint: Debug powerdown support for
> >>> self-hosted
> >>> debug} introduces debug powerdown support for self-hosted debug.
> >>> While merging the patch 'has_ossr' check was removed which
> >>> was needed for hardwares which doesn't support self-hosted debug.
> >>> Pandaboard (A9) is one such hardware and Dietmar's orginial
> >>> patch did mention this issue.
> >>> Without that check on Panda with CPUIDLE enabled, a flood of
> >>> below messages thrown.
> >>>
> >>> [ 3.597930] hw-breakpoint: CPU 0 failed to disable vector catch
> >>> [ 3.597991] hw-breakpoint: CPU 1 failed to disable vector catch

Ok, so this means that we've taken an undefined instruction exception while
trying to reset the debug registers on the PM_EXIT path. Now, the code there
deals with CPUs that don't have the save/restore registers just fine, so
that shouldn't have anything to do with this problem, particularly if the
bit that is tripping us up is related to clearing vector catch.

Furthermore, I was under the impression that hw_breakpoint did actually
work on panda, which implies that a cold boot *does* manage to reset the
registers (can you please confirm this by looking in your dmesg during
boot?). In that case, it seems as though a PM cycle is powering down a
bunch of debug logic that was powered up during boot, and then we trip over
because we can't access the register bank.

The proper solution to this problem requires us to establish exactly what is
turning off the debug registers, and then having an OMAP PM notifier to
enable it again. Assuming this has always been the case, I expect hardware
debug across PM fails silently with older kernels.

> I was also wondering whether we should just warn once rather
> than continuous warnings in the notifier. Patch is end of the
> email.

Could do, but I'd like to see a fix for the real issue before we simply hide
the warnings :)

Cheers,

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

RE: [PATCH 2/3] ARM: davinci: da850: Enable EHRPWM TBCLK from CFG_CHIP1

[Philip, Avinash]

On Thu, Mar 14, 2013 at 18:31:52, Nori, Sekhar wrote:
> On 3/14/2013 4:07 PM, Philip Avinash wrote:
> > da850 platforms require TBCLK synchronization in CFG_CHIP1 register for
> > TBCLK enable in EHRPWM modules. Enabling of TBCLK is done only if EHRPWM
> > DT node status is set to "okay" DT blob.
> > Also adds macro definitions for DA8XX_EHRPWM_TBCLKSYNC and
> > DA8XX_CFGCHIP1_REG.
> 
> So there is actually a TBCLK in DA850 - it's just not modeled as a clock
> similar to the way it is done on AM335x? If yes, then instead of adding
> a dummy clock node and doing the TBCLK enable as part of init, why not
> model TBCLK in clock tree even on DA850?


TBCLK enabling should done from platform specific way. In DA850 it is done at
CFGCHIP1 register. Unfortunately Davinci clock frame work will support only
clock nodes inside PLLC and PSC modules. Handling of CFGCHP1 require
modifications in clock frame work.

Hence handling it as part of initialization.

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 

Re: [Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig

[Michael Neuling]

>   do next-* tree support powerpc POWER7 with allmodconfig ?
> 
>   I met an issue, can we bear it (or I need additional trying) ?
> 
> 
> Compiling:
>   make V=1 EXTRA_CFLAGS=-W ARCH=powerpc allmodconfig
> set cpu type POWER7 in menuconfig.
> set cross-compiler in menuconfig.
>   under Fedora 16 x86_64 laptop
>   /usr/bin/powerpc64-linux-gnu-gcc -v
> gcc version 4.7.1 20120606 (Red Hat 4.7.1-0.1.20120606) (GCC)
> 
> Issue:
>   error:
> /android/public-kernel/linux-next/arch/powerpc/kernel/exceptions-64s.S: 
> Assembler messages:
> 
> /android/public-kernel/linux-next/arch/powerpc/kernel/exceptions-64s.S:1304: 
> Error: attempt to move .org backwards
> 
>   command:
> powerpc64-linux-gnu-gcc -m64 -Wp,-MD,arch/powerpc/kernel/.head_64.o.d  
> -nostdinc -isystem /usr/lib/gcc/powerpc64-linux-gnu/4.7.1/include 
> -I/android/public-kernel/linux-next/arch/powerpc/include 
> -Iarch/powerpc/include/generated  -I/android/public-kernel/linux-next/include 
> -Iinclude -I/android/public-kernel/linux-next/arch/powerpc/include/uapi 
> -Iarch/powerpc/include/generated/uapi 
> -I/android/public-kernel/linux-next/include/uapi -Iinclude/generated/uapi 
> -include /android/public-kernel/linux-next/include/linux/kconfig.h 
> -D__KERNEL__  -I/android/public-kernel/linux-next/arch/powerpc -Iarch/powerpc 
> -D__ASSEMBLY__  -I/android/public-kernel/linux-next/arch/powerpc 
> -Iarch/powerpc -Wa,-maltivec -gdwarf-2   -c -o arch/powerpc/kernel/head_64.o 
> /android/public-kernel/linux-next/arch/powerpc/kernel/head_64.S
> 
>   (head_64.S includes exceptions-64.S)

Yep it's a known problem but no one has bothered to fix it since it
doesn't happen in a config that anyone cares about like
pseries_defconfig and ppc64_defconfig.  We've been moving code around in
this area a lot recently hence the breakage.

It should be fixed though.  Patches welcome. :-)

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

Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Ben Widawsky]

On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> In order to prevent a potential NULL deference with hostile userspace,
> we need to check whether the ioctl was passed an invalid args pointer.
> 
> Reported-by: Tommi Rantala 
> Link: 
> http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 365e41a..9f5602e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
>   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
>   int ret, i;
>  
> - if (args->buffer_count < 1) {
> + if (args == NULL)
> + return -EINVAL;
> +
> + if (args->buffer_count < 1 ||
> + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
>   DRM_DEBUG("execbuf with %d buffers\n", args->buffer_count);
>   return -EINVAL;
>   }
> @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void 
> *data,
>   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
>   int ret;
>  
> + if (args == NULL)
> + return -EINVAL;
> +
>   if (args->buffer_count < 1 ||
> - args->buffer_count > UINT_MAX / sizeof(*exec2_list)) {
> + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
>   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
>   return -EINVAL;
>   }

Why did you change UINT_MAX to INT_MAX? TBH, I'm confused what we're
trying to achieve, and why we need anything other than:
if (!args->buffer_count)

I'm also not seeing how the NULL checks are needed since at least it
seems to be for execbuffer (IOW) we could never have NULL args.

if (cmd & (IOC_IN | IOC_OUT)) {
if (asize <= sizeof(stack_kdata)) {
kdata = stack_kdata;
} else {
kdata = kmalloc(asize, GFP_KERNEL);
if (!kdata) {
retcode = -ENOMEM;
goto err_i1;
}
}
if (asize > usize)
memset(kdata + usize, 0, asize - usize);
}

Sorry if these are stupid questions.

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

[PATCH 2/2] pinctrl: at91: Fix checkpatch errors

[Sachin Kamat]

Fixes the following types of checkpatch errors:
ERROR: "foo * bar" should be "foo *bar"
ERROR: "foo* bar" should be "foo *bar"
ERROR: space required before the open parenthesis '('
ERROR: "(foo*)" should be "(foo *)"
ERROR: space required after that ',' (ctx:WxV)
ERROR: "(foo*const*)" should be "(foo *const*)"
ERROR: space required before that '*' (ctx:VxB)

Signed-off-by: Sachin Kamat 
---
 drivers/pinctrl/pinctrl-at91.c |   17 +
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 353c7bf..03d8bed 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -303,7 +303,7 @@ static const struct pinctrl_ops at91_pctrl_ops = {
.dt_free_map= at91_dt_free_map,
 };
 
-static void __iomem * pin_to_controller(struct at91_pinctrl *info,
+static void __iomem *pin_to_controller(struct at91_pinctrl *info,
 unsigned int bank)
 {
return gpio_chips[bank]->regbase;
@@ -501,7 +501,7 @@ static void at91_pin_dbg(const struct device *dev, const 
struct at91_pmx_pin *pi
}
 }
 
-static int pin_check_config(struct at91_pinctrl *info, const char* name,
+static int pin_check_config(struct at91_pinctrl *info, const char *name,
int index, const struct at91_pmx_pin *pin)
 {
int mux;
@@ -579,7 +579,7 @@ static int at91_pmx_enable(struct pinctrl_dev *pctldev, 
unsigned selector,
pio = pin_to_controller(info, pin->bank);
mask = pin_to_mask(pin->pin);
at91_mux_disable_interrupt(pio, mask);
-   switch(pin->mux) {
+   switch (pin->mux) {
case AT91_MUX_GPIO:
at91_mux_gpio_enable(pio, mask, 1);
break;
@@ -944,7 +944,7 @@ static int at91_pinctrl_probe_dt(struct platform_device 
*pdev,
return -ENODEV;
 
info->dev = >dev;
-   info->ops = (struct at91_pinctrl_mux_ops*)
+   info->ops = (struct at91_pinctrl_mux_ops *)
of_match_device(at91_pinctrl_of_match, >dev)->data;
at91_pinctrl_child_count(info, np);
 
@@ -1002,7 +1002,7 @@ static int at91_pinctrl_probe(struct platform_device 
*pdev)
 {
struct at91_pinctrl *info;
struct pinctrl_pin_desc *pdesc;
-   int ret, i, j ,k;
+   int ret, i, j, k;
 
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
if (!info)
@@ -1509,7 +1509,7 @@ static int at91_gpio_probe(struct platform_device *pdev)
goto err;
}
 
-   at91_chip->ops = (struct at91_pinctrl_mux_ops*)
+   at91_chip->ops = (struct at91_pinctrl_mux_ops *)
of_match_device(at91_gpio_of_match, >dev)->data;
at91_chip->pioc_virq = irq;
at91_chip->pioc_idx = alias_idx;
@@ -1546,7 +1546,8 @@ static int at91_gpio_probe(struct platform_device *pdev)
chip->ngpio = ngpio;
}
 
-   names = devm_kzalloc(>dev, sizeof(char*) * chip->ngpio, 
GFP_KERNEL);
+   names = devm_kzalloc(>dev, sizeof(char *) * chip->ngpio,
+GFP_KERNEL);
 
if (!names) {
ret = -ENOMEM;
@@ -1556,7 +1557,7 @@ static int at91_gpio_probe(struct platform_device *pdev)
for (i = 0; i < chip->ngpio; i++)
names[i] = kasprintf(GFP_KERNEL, "pio%c%d", alias_idx + 'A', i);
 
-   chip->names = (const char*const*)names;
+   chip->names = (const char *const *)names;
 
range = _chip->range;
range->name = chip->label;
-- 
1.7.4.1

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

[PATCH 1/2] pinctrl: at91: Remove duplicate const

[Sachin Kamat]

const declared twice. Fixes the following sparse warning:
drivers/pinctrl/pinctrl-at91.c:815:21: warning: duplicate const
drivers/pinctrl/pinctrl-at91.c:849:21: warning: duplicate const

Signed-off-by: Sachin Kamat 
---
 drivers/pinctrl/pinctrl-at91.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index e50fa5f..353c7bf 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -812,7 +812,7 @@ static int at91_pinctrl_mux_mask(struct at91_pinctrl *info,
 {
int ret = 0;
int size;
-   const const __be32 *list;
+   const __be32 *list;
 
list = of_get_property(np, "atmel,mux-mask", );
if (!list) {
@@ -846,7 +846,7 @@ static int at91_pinctrl_parse_groups(struct device_node *np,
 {
struct at91_pmx_pin *pin;
int size;
-   const const __be32 *list;
+   const __be32 *list;
int i, j;
 
dev_dbg(info->dev, "group(%d): %s\n", index, np->name);
-- 
1.7.4.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Ben Widawsky]

On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> In order to prevent a potential NULL deference with hostile userspace,
> we need to check whether the ioctl was passed an invalid args pointer.
> 
> Reported-by: Tommi Rantala 
> Link: 
> http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 365e41a..9f5602e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
>   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
>   int ret, i;
>  
> - if (args->buffer_count < 1) {
> + if (args == NULL)
> + return -EINVAL;
> +
> + if (args->buffer_count < 1 ||
> + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
>   DRM_DEBUG("execbuf with %d buffers\n", args->buffer_count);
>   return -EINVAL;
>   }
> @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void 
> *data,
>   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
>   int ret;
>  
> + if (args == NULL)
> + return -EINVAL;
> +
>   if (args->buffer_count < 1 ||
> - args->buffer_count > UINT_MAX / sizeof(*exec2_list)) {
> + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
>   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
>   return -EINVAL;
>   }

Why did you change UINT_MAX to INT_MAX? TBH, I'm confused what we're
trying to achieve, and why we need anything other than:
if (!args->buffer_count)

I'm also not seeing how the NULL checks are needed since at least it
seems to be for execbuffer (IOW) we could never have NULL args.

if (cmd & (IOC_IN | IOC_OUT)) {
if (asize <= sizeof(stack_kdata)) {
kdata = stack_kdata;
} else {
kdata = kmalloc(asize, GFP_KERNEL);
if (!kdata) {
retcode = -ENOMEM;
goto err_i1;
}
}
if (asize > usize)
memset(kdata + usize, 0, asize - usize);
}

Sorry if these are stupid questions.

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

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Al Viro]

On Fri, Mar 15, 2013 at 01:15:36PM +0900, J. R. Okajima wrote:

> +- whiteout is hardlinked in order to reduce the consumption of inodes
> +  on branch

*blink* Whiteouts have no inodes at all.  Filesystem has an additional
kind of directory entries, recognizable as whiteouts.  How they are
done is up to filesystem in question.

> +- kernel thread for removing the dir who has a plenty of whiteouts

Again, implementation detail for individual filesystem.

> +The whiteout in aufs is very similar to Unionfs's. That is represented
> +by its filename. UnionMount takes an approach of a file mode, but I am
> +afraid several utilities (find(1) or something) will have to support it.

Why the devil should find(1) even see them?

I really don't believe that it's a good idea to try making them fs-agnostic;
it's an implementation detail of filesystem, with things like "is this
directory empty?" very much belonging to the fs in question...

I don't know; maybe it's my experience of dealing with umsdos that has badly
soured me on that kind of approach, but IME this kind of schemes tend to
be brittle as hell ;-/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 -tip v2 2/2] [BUGFIX] kprobes/x86: Check Interrupt Flag modifier when registering probe

[Ananth N Mavinakayanahalli]

On Thu, Mar 14, 2013 at 08:52:43PM +0900, Masami Hiramatsu wrote:
> Currently kprobes check whether the copied instruction modifies
> IF (interrupt flag) on each probe hit. This means not only
> introducing overhead but also involving inat_get_opcode_attribute
> into kprobes hot path, and it can cause an infinit recursive
> call (and kernel panic in the end).
> 
> Actually, since the copied instruction itself never be modified
> on the buffer, it is needless to analyze the instruction every
> probe hit.
> 
> To fix this issue, we checks it only once when registering probe
> and store the result on ainsn->if_modifier.
> 
> Signed-off-by: Masami Hiramatsu 
> Reported-by: Timo Juhani Lindfors 
> Cc: "David S. Miller" 
> Cc: Ananth N Mavinakayanahalli 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Steven Rostedt 
> Cc: Linus Torvalds 

Acked-by: Ananth N Mavinakayanahalli 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 -tip v2 1/2] [BUGFIX] kprobes: make hash_64() as always inlined

[Ananth N Mavinakayanahalli]

On Thu, Mar 14, 2013 at 08:52:30PM +0900, Masami Hiramatsu wrote:
> Because hash_64() is called from the get_kprobe() inside
> int3 handler, kernel causes int3 recursion and crashes if
> kprobes user puts a probe on it.
> 
> Usually hash_64() is inlined into caller function, but in
> some cases, it has instances by gcc's interprocedural
> constant propagation.
> 
> This patch uses __always_inline instead of inline to
> prevent gcc from doing such things.
> 
> Changes in v2:
>  - Use __always_inline instead of using __kprobes
> 
> Signed-off-by: Masami Hiramatsu 
> Reported-by: Timo Juhani Lindfors 
> Cc: "David S. Miller" 
> Cc: Nadia Yvette Chambers 
> Cc: Pavel Emelyanov 
> Cc: Jiri Kosina 
> Cc: Ananth N Mavinakayanahalli 
> Cc: Ingo Molnar 
> Cc: Linus Torvalds 

Acked-by: Ananth N Mavinakayanahalli 

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

Re[2]: [PATCH v7 2/2] mfd: syscon: Add non-DT support

[Alexander Shiyan]

> On 14 March 2013 01:34, Alexander Shiyan  wrote:
> > This patch allow using syscon driver from the platform data, i.e.
> > possibility using driver on systems without oftree support.
> > For search syscon device from the client drivers,
> > "syscon_regmap_lookup_by_pdevname" function was added.
> >
> > Signed-off-by: Alexander Shiyan 
> 
> Actually i've acked this series before, usually you can send out the
> updated series
> with my tag if no other big changes except the minor comments fix i pointed 
> out.
> Here again, for this series:
> Acked-by: Dong Aisheng 
...

There remains only one question. Who can commit the patch to the kernel...

---

Re: vfs: lockdep splat with prepare_bprm_creds

[Al Viro]

On Fri, Mar 15, 2013 at 12:07:14AM -0400, Sasha Levin wrote:
> Hi all,
> 
> While fuzzing with trinity inside a KVM tools guest running latest -next 
> kernel
> I've stumbled on the following.
> 
> Dave Jones reported something similar, but that seemed to involve cgroup's 
> mutex
> and didn't seem like it was the same issue as this one.

Lovely...  It's an execve() attempt on a "binary" that is, in fact, a procfs
file (/proc//stack), with its ->read() trying to grab ->cred_guard_mutex.
The fact that it's seq_file-based is irrelevant here - all that matters is
that we have ->read() for some file trying to grab ->cred_guard_mutex.

It's not *quite* a deadlock, though - all these guys are using
mutex_lock_killable()...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] pwm: pwm-tiecap: Add device-tree binding support for da850 SOC

[Sekhar Nori]

On 3/14/2013 9:14 PM, Peter Korsgaard wrote:
>> "Sekhar" == Sekhar Nori  writes:
> 
>  >> Required properties:
>  >> -- compatible: Must be "ti,am33xx-ecap"
>  >> +- compatible: Must be "ti,am33xx-ecap" or "ti,da850-ecap"
>  >> - #pwm-cells: Should be 3. Number of cells being used to specify PWM 
> property.
>  >> First cell specifies the per-chip index of the PWM to use, the second
>  >> cell is the period in nanoseconds and bit 0 in the third cell is used to
>  >> diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
>  >> index 22e96e2..e0d96c8 100644
>  >> --- a/drivers/pwm/pwm-tiecap.c
>  >> +++ b/drivers/pwm/pwm-tiecap.c
>  >> @@ -197,6 +197,7 @@ static const struct pwm_ops ecap_pwm_ops = {
>  >> 
>  >> static const struct of_device_id ecap_of_match[] = {
>  >> { .compatible = "ti,am33xx-ecap" },
>  >> + { .compatible   = "ti,da850-ecap" },
>  >> {},
> 
>  Sekhar> You add a new compatible, but don't really show any changes in
>  Sekhar> driver in this series. So why can't we simply use
>  Sekhar> ti,am33xx-ecap on DA850 too?
> 
> Indeed, if the hardware block is identical the dts should simply list:
> 
> compatible = "ti,da850-ecap", "ti,am33xx-ecap"
> 
> And the driver only bind to ti,am33xx-ecap (unless there ever needs to
> be a da850 specific workarounde.

Okay, so this is to future proof the DA850 DT blob. Makes sense. Thanks!

~Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/9] overlay filesystem: request for inclusion (v17)

[J. R. Okajima]

Al Viro:
> Umm...  I would prefer it to go through vfs.git, with serious modifications.
> I really don't like the idea of xattr-based whiteouts, for example.

I'd ask you how do you think another whiteout approach?
Here is a part of a posts which describes about aufs2 in 2009


:::
+- whiteout is hardlinked in order to reduce the consumption of inodes
+  on branch
:::
+- kernel thread for removing the dir who has a plenty of whiteouts
:::
+The whiteout is for hiding files on lower branches. Also it is applied
+to stop readdir going lower branches.
+The latter case is called \[oq]opaque directory.\[cq] Any
+whiteout is an empty file, it means whiteout is just an mark.
+In the case of hiding lower files, the name of whiteout is
+\[oq]\*[AUFS_WH_PFX].\[cq]
+And in the case of stopping readdir, the name is
+\[oq]\*[AUFS_WH_PFX]\*[AUFS_WH_PFX].opq\[cq] or
+\[oq]\*[AUFS_WH_PFX]__dir_opaque.\[cq] The name depends upon your compile
+configuration
+CONFIG_AUFS_COMPAT.
+.\" All of newly created or renamed directory will be opaque.
+All whiteouts are hardlinked,
+including \[oq]/\*[AUFS_WH_BASE].\[cq]
:::
+The whiteout in aufs is very similar to Unionfs's. That is represented
+by its filename. UnionMount takes an approach of a file mode, but I am
+afraid several utilities (find(1) or something) will have to support it.
+
+Basically the whiteout represents "logical deletion" which stops aufs to
+lookup further, but also it represents "dir is opaque" which also stop
+lookup.
+
+In aufs, rmdir(2) and rename(2) for dir uses whiteout alternatively.
+In order to make several functions in a single systemcall to be
+revertible, aufs adopts an approach to rename a directory to a temporary
+unique whiteouted name.
+For example, in rename(2) dir where the target dir already existed, aufs
+renames the target dir to a temporary unique whiteouted name before the
+actual rename on a branch and then handles other actions (make it opaque,
+update the attributes, etc). If an error happens in these actions, aufs
+simply renames the whiteouted name back and returns an error. If all are
+succeeded, aufs registers a function to remove the whiteouted unique
+temporary name completely and asynchronously to the system global
+workqueue.
:::

Latest version is aufs3 (for linux-3.x series), there is no essential
changes about whiteout since aufs2.


J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: manual merge of the staging tree with Linus' tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/ccg/f_fs.c between commit 7f78e0351394 ("fs: Limit
sys_mount to only request filesystem modules") from Linus' tree and
commit 515e6dd20b3f ("Staging: ccg: delete it from the tree") from the
staging tree.

The latter deleted the file, so I did that and can carry the fix as
necessary (no action is required).

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


pgp1RXubjgH6I.pgp
Description: PGP signature

vfs: lockdep splat with prepare_bprm_creds

[Sasha Levin]

Hi all,

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

Dave Jones reported something similar, but that seemed to involve cgroup's mutex
and didn't seem like it was the same issue as this one.


[  549.400084] ==
[  549.400084] [ INFO: possible circular locking dependency detected ]
[  549.400084] 3.9.0-rc2-next-20130314-sasha-00046-g3897511 #295 Tainted: G 
   W
[  549.400084] ---
[  549.420729] can: request_module (can-proto-0) failed.
[  549.400084] trinity-child20/12048 is trying to acquire lock:
[  549.400084]  (>lock){+.+.+.}, at: [] seq_read+0x3a/0x3d0
[  549.400084]
[  549.400084] but task is already holding lock:
[  549.400084]  (>cred_guard_mutex){+.+.+.}, at: [] 
prepare_bprm_creds+0x31/0x80
[  549.400084]
[  549.400084] which lock already depends on the new lock.
[  549.400084]
[  549.400084]
[  549.400084] the existing dependency chain (in reverse order) is:
[  549.400084]
-> #1 (>cred_guard_mutex){+.+.+.}:
[  549.400084][] check_prevs_add+0xba/0x1a0
[  549.400084][] validate_chain.isra.21+0x6d0/0x800
[  549.400084][] __lock_acquire+0xa23/0xb10
[  549.400084][] lock_acquire+0x1ca/0x270
[  549.400084][] __mutex_lock_common+0x5a/0x5a0
[  549.400084][] mutex_lock_killable_nested+0x3f/0x50
[  549.400084][] lock_trace+0x28/0x70
[  549.400084][] proc_pid_stack+0x65/0xf0
[  549.400084][] proc_single_show+0x5a/0xa0
[  549.400084][] seq_read+0x1af/0x3d0
[  549.400084][] do_loop_readv_writev+0x4b/0x90
[  549.400084][] do_readv_writev+0xf6/0x1d0
[  549.400084][] vfs_readv+0x3e/0x60
[  549.400084][] SyS_readv+0x50/0xd0
[  549.400084][] tracesys+0xe1/0xe6
[  549.400084]
-> #0 (>lock){+.+.+.}:
[  549.400084][] check_prev_add+0x145/0x710
[  549.400084][] check_prevs_add+0xba/0x1a0
[  549.400084][] validate_chain.isra.21+0x6d0/0x800
[  549.400084][] __lock_acquire+0xa23/0xb10
[  549.400084][] lock_acquire+0x1ca/0x270
[  549.400084][] __mutex_lock_common+0x5a/0x5a0
[  549.400084][] mutex_lock_nested+0x3f/0x50
[  549.400084][] seq_read+0x3a/0x3d0
[  549.400084][] proc_reg_read+0x201/0x230
[  549.400084][] vfs_read+0xb5/0x180
[  549.400084][] kernel_read+0x41/0x60
[  549.400084][] prepare_binprm+0x18d/0x1b0
[  549.400084][] do_execve_common.isra.21+0x1b6/0x380
[  549.400084][] do_execve+0x13/0x20
[  549.400084][] SyS_execve+0x3e/0x60
[  549.400084][] stub_execve+0x69/0xa0
[  549.400084]
[  549.400084] other info that might help us debug this:
[  549.400084]
[  549.400084]  Possible unsafe locking scenario:
[  549.400084]
[  549.400084]CPU0CPU1
[  549.400084]
[  549.400084]   lock(>cred_guard_mutex);
[  549.400084]lock(>lock);
[  549.400084]lock(>cred_guard_mutex);
[  549.400084]   lock(>lock);
[  549.400084]
[  549.400084]  *** DEADLOCK ***
[  549.400084]
[  549.400084] 1 lock held by trinity-child20/12048:
[  549.400084]  #0:  (>cred_guard_mutex){+.+.+.}, at: [] 
prepare_bprm_creds+0x31/0x80
[  549.400084]
[  549.400084] stack backtrace:
[  549.400084] Pid: 12048, comm: trinity-child20 Tainted: GW
3.9.0-rc2-next-20130314-sasha-00046-g3897511 #295
[  549.400084] Call Trace:
[  549.400084]  [] print_circular_bug+0xd3/0xe4
[  549.400084]  [] check_prev_add+0x145/0x710
[  549.400084]  [] check_prevs_add+0xba/0x1a0
[  549.400084]  [] ? sched_clock+0x15/0x20
[  549.400084]  [] validate_chain.isra.21+0x6d0/0x800
[  549.400084]  [] __lock_acquire+0xa23/0xb10
[  549.400084]  [] ? kvm_clock_read+0x38/0x70
[  549.400084]  [] ? lock_release_holdtime+0x12e/0x140
[  549.400084]  [] ? sched_clock+0x15/0x20
[  549.400084]  [] ? sched_clock_local+0x25/0x90
[  549.400084]  [] ? deactivate_slab+0x7d6/0x820
[  549.400084]  [] lock_acquire+0x1ca/0x270
[  549.400084]  [] ? seq_read+0x3a/0x3d0
[  549.400084]  [] ? sched_clock_local+0x25/0x90
[  549.400084]  [] ? seq_lseek+0x110/0x110
[  549.400084]  [] __mutex_lock_common+0x5a/0x5a0
[  549.400084]  [] ? seq_read+0x3a/0x3d0
[  549.400084]  [] ? __lock_is_held+0x52/0x80
[  549.400084]  [] ? seq_read+0x3a/0x3d0
[  549.400084]  [] ? seq_lseek+0x110/0x110
[  549.400084]  [] mutex_lock_nested+0x3f/0x50
[  549.400084]  [] seq_read+0x3a/0x3d0
[  549.400084]  [] ? delay_tsc+0xdd/0x110
[  549.400084]  [] ? seq_lseek+0x110/0x110
[  549.400084]  [] ? seq_lseek+0x110/0x110
[  549.400084]  [] proc_reg_read+0x201/0x230
[  549.400084]  [] ? proc_reg_write+0x230/0x230
[  549.400084]  [] vfs_read+0xb5/0x180
[  549.400084]  [] kernel_read+0x41/0x60
[  549.400084]  [] prepare_binprm+0x18d/0x1b0
[  549.400084]  [] do_

retreive /proc/acpi/processor?

[Kevin Qiu]

Hi,
I am a newbie on Linux.
I am trying to read the CPU information through "acpitool -c". And 
I get a message as: "  Function Show_CPU_Info : could not read directory 
/proc/acpi/processor/ Make sure your kernel has ACPI processor support 
enabled.

"
I went to the kernel configuration, it appears to me it's already 
enabled. And there're two tick box stating "deprecated /proc/acpi files, 
deprecated power /proc/acpi directories". Whether I tick it or not 
doesn't couldn't generate a new /proc/acpi/processor/

So is there a way to bring this functionality back?
P.S. I am using linux 3.2.0-23-generic kernel.
Kevin Qiu

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

Re: use after free in sysfs_find_dirent

[Sasha Levin]

On 03/07/2013 01:26 AM, Dave Jones wrote:
> On Thu, Mar 07, 2013 at 02:02:30PM +0800, Greg Kroah-Hartman wrote:
>  > On Thu, Mar 07, 2013 at 12:28:54AM -0500, Dave Jones wrote:
>  > > general protection fault:  [#1] PREEMPT SMP 
>  > > Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock bnep fuse 
> rfcomm hidp l2tp_ppp l2tp_core 8021q garp mrp dlci pppoe pppox ppp_generic 
> slhc scsi_transport_iscsi rose caif_socket caif can_raw bridge af_key can_bcm 
> llc2 stp can netrom phonet af_rxrpc nfnetlink ipt_ULOG x25 rds irda crc_ccitt 
> ax25 ipx p8023 p8022 decnet atm appletalk psnap llc nfc lockd sunrpc 
> ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack 
> ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec 
> snd_pcm btusb snd_page_alloc bluetooth snd_timer snd microcode rfkill 
> usb_debug serio_raw pcspkr edac_core soundcore vhost_net tun r8169 macvtap 
> macvlan mii kvm_amd kvm
>  > > CPU 0 
>  > > Pid: 23476, comm: trinity-child1 Not tainted 3.9.0-rc1+ #69 Gigabyte 
> Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
>  > > RIP: 0010:[]  [] 
> sysfs_find_dirent+0x47/0xf0
>  > > RSP: 0018:88000585bd68  EFLAGS: 00010202
>  > > RAX: 94be55f6 RBX: 6b6b6b6b6b6b6b6b RCX: 6b6b6b6b
>  > > RDX:  RSI:  RDI: 
>  > > RBP: 88000585bd88 R08:  R09: 
>  > > R10:  R11:  R12: 0029c161
>  > > R13: 8800a8918288 R14:  R15: 0009
>  > > FS:  7fa12651e740() GS:88012ae0() 
> knlGS:
>  > > CS:  0010 DS:  ES:  CR0: 80050033
>  > > CR2: 0010 CR3: 1a128000 CR4: 07f0
>  > > DR0:  DR1:  DR2: 
>  > > DR3:  DR6: 0ff0 DR7: 0400
>  > > Process trinity-child1 (pid: 23476, threadinfo 88000585a000, task 
> 8800cd454920)
>  > > Stack:
>  > >  880128edc1e8 8800a8918250 fffe 88012265f430
>  > >  88000585bdb8 812357cd 8800a8918250 8801226514d0
>  > >  88000585bf38  88000585bde8 811bb30d
>  > > Call Trace:
>  > >  [] sysfs_lookup+0x6d/0xe0
>  > >  [] lookup_real+0x1d/0x60
>  > >  [] __lookup_hash+0x38/0x50
>  > >  [] lookup_hash+0x19/0x20
>  > >  [] kern_path_create+0x93/0x170
>  > >  [] ? getname_flags.part.32+0x86/0x150
>  > >  [] user_path_create+0x4a/0x70
>  > >  [] sys_mkdirat+0x39/0xe0
>  > >  [] system_call_fastpath+0x16/0x1b
>  > > Code: 00 48 8b 9f 88 00 00 00 f6 c4 0f 0f 95 c0 48 85 f6 0f 95 c2 38 d0 
> 75 79 4c 89 ee 4c 89 f7 e8 91 ef ff ff 41 89 c4 48 85 db 74 1d <8b> 4b 28 41 
> 39 cc 74 21 44 89 e0 29 c8 83 f8 00 7c 2c 74 45 48 
>  > > RIP  [] sysfs_find_dirent+0x47/0xf0
>  > >  RSP 
>  > > ---[ end trace 4ba97703eaafbb8b ]---
>  > 
>  > Any hint as to what was happening here when this crashed?
> 
> Given I haven't seen this (or the other sysfs bug) before today, I'm going
> to assume it's due to one of the features I added to trinity today.
> 
> 1. Instead of just relying on filenames it gathers from sysfs on startup,
>it now also generates mangled variants of them.
>(Appending a / followed by garbage for eg)
> 
> 2. When a syscall wants a page of memory, it now sometimes hands it one
>filled with malformed UTF-8 characters.
> 
> 3. A combo of the above, that garbage appended to a pathname may be unicode 
> junk.
> 
> Could be some of those that caused these bugs.
> 
> I just retried rerunning the test a few times.  Every time I run for a while
> I end up with different crashes.  It's raining bugs over here.
> (Here's another sysfs one below)
> 
> Running 'trinity -c mkdirat -V /sys' doesn't seem to trigger it, so it's an
> interaction with something else maybe.
> 
> The one common thing here is that 6b6b6b6b6b6b6b6b showing up in every trace,
> suggesting a use-after-free bugs. They may all be different manifestations
> of the same underlying bug if there's some kind of refcounting bug perhaps.
> (This may also be why telling it to do just mkdirat isn't triggering it,
>  if it's racing with some other operation)
> 
> Getting this stuff easily reproducable is pretty hard. The best I can offer
> right now is that it seems to trigger *something* bad quickly, even if it's
> not necessarily the exact same trace.

I've hit something similar, but I suspect it'

Re: + atomic-improve-atomic_inc_unless_negative-atomic_dec_unless_positive .patch added to -mm tree

[Ming Lei]

On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov  wrote:
>> From: Ming Lei 
>> Subject: atomic: improve 
>> atomic_inc_unless_negative/atomic_dec_unless_positive
>>
>> Generally, both atomic_inc_unless_negative() and
>> atomic_dec_unless_positive() need at least two atomic_cmpxchg() to
>> complete the atomic operation.  In fact, the 1st atomic_cmpxchg() is just
>> used to read current value of the atomic variable at most times.
>
> Agreed, this looks ugly...
>
> But can't we make a simpler patch and keep the code simple/readable ?
>
> Oleg.
>
> --- x/include/linux/atomic.h
> +++ x/include/linux/atomic.h
> @@ -64,7 +64,7 @@ static inline int atomic_inc_not_zero_hi
>  static inline int atomic_inc_unless_negative(atomic_t *p)
>  {
> int v, v1;
> -   for (v = 0; v >= 0; v = v1) {
> +   for (v = atomic_read(p); v >= 0; v = v1) {
> v1 = atomic_cmpxchg(p, v, v + 1);

Unfortunately, the above will exchange the current value even though
it is negative, so it isn't correct.

> if (likely(v1 == v))
> return 1;
> @@ -77,7 +77,7 @@ static inline int atomic_inc_unless_nega
>  static inline int atomic_dec_unless_positive(atomic_t *p)
>  {
> int v, v1;
> -   for (v = 0; v <= 0; v = v1) {
> +   for (v = atomic_read(p); v <= 0; v = v1) {
> v1 = atomic_cmpxchg(p, v, v - 1);

Similar with above.

> if (likely(v1 == v))
> return 1;
>


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

Re: [PATCH 0/3] [GIT PULL][3.9] tracing: Fixes with flags and latency tracers

[Steven Rostedt]

On Thu, 2013-03-14 at 17:33 -0400, Steven Rostedt wrote:

> Anyway, here's hopefully my final series of changes for 3.9.
> (Famous last words)

And there's a bug in this patch set. Thanks to Fangguang's auto tests,
it showed a bug in my new work, which points out a bug in this patch
set. The following change is needed to patch 2:

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index eaaccd8..02debab 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2897,7 +2897,9 @@ static void set_tracer_flags(unsigned int mask, int 
enabled)
 
if (mask == TRACE_ITER_OVERWRITE) {
ring_buffer_change_overwrite(global_trace.buffer, enabled);
+#ifdef CONFIG_TRACER_MAX_TRACE
ring_buffer_change_overwrite(max_tr.buffer, enabled);
+#endif
}
 
if (mask == TRACE_ITER_PRINTK)


But this bug is worse than the one in my new code. As the new code wont
compile here, this code will, but "max_tr.buffer" will be NULL if
CONFIG_MAX_TRACER_MAX_TRACE is not defined and will cause a NULL pointer
dereference.

I'll update the patch series, test it and push it out again.

Thanks!

-- Steve


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

[PATCH 2/3] ARM: msm: Rework timer binding to be more general

[Stephen Boyd]

The msm timer binding I wrote is bad. First off, the clock
frequency in the binding for the dgt is wrong. Software divides
down the input rate by 4 to achieve the rate listed in the
binding. We also treat each individual timer as a separate
hardware component, when in reality there is one timer block
(that may be duplicated per cpu) with multiple timers within it.
Depending on the version of the hardware there can be one or two
general purpose timers, status and divider control registers, and
an entirely different register layout.

In the next patch we'll need to know about the different register
layouts so that we can properly check the status register after
clearing the count. The current binding makes this complicated
because the general purpose timer's reg property doesn't indicate
where that status register is, and in fact it is beyond the size
of the reg property.

Clean all this up by just having one node for the timer hardware,
and describe all the interrupts and clock frequencies supported
while having one reg property that covers the entire timer
register region. We'll use the compatible field in the future to
determine different register layouts and if we should read the
status registers, etc.

Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/arm/msm/timer.txt  | 41 ++-
 arch/arm/boot/dts/msm8660-surf.dts | 20 ++
 arch/arm/boot/dts/msm8960-cdp.dts  | 22 +++---
 arch/arm/mach-msm/timer.c  | 79 +-
 4 files changed, 68 insertions(+), 94 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/msm/timer.txt 
b/Documentation/devicetree/bindings/arm/msm/timer.txt
index 8c5907b..c6ef8f1 100644
--- a/Documentation/devicetree/bindings/arm/msm/timer.txt
+++ b/Documentation/devicetree/bindings/arm/msm/timer.txt
@@ -3,36 +3,35 @@
 Properties:
 
 - compatible : Should at least contain "qcom,msm-timer". More specific
-  properties such as "qcom,msm-gpt" and "qcom,msm-dgt" specify a general
-  purpose timer and a debug timer respectively.
+   properties specify which subsystem the timers are paired with.
 
-- interrupts : Interrupt indicating a match event.
+   "qcom,kpss-timer" - krait subsystem
+   "qcom,scss-timer" - scorpion subsystem
 
-- reg : Specifies the base address of the timer registers. The second region
-  specifies an optional register used to configure the clock divider.
+- interrupts : Interrupts for the the debug timer, the first general purpose
+   timer, and optionally a second general purpose timer in that
+   order.
 
-- clock-frequency : The frequency of the timer in Hz.
+- reg : Specifies the base address of the timer registers.
+
+- clock-frequency : The frequency of the debug timer and the general purpose
+timer(s) in Hz in that order.
 
 Optional:
 
 - cpu-offset : per-cpu offset used when the timer is accessed without the
-  CPU remapping facilities. The offset is cpu-offset * cpu-nr.
+   CPU remapping facilities. The offset is
+   cpu-offset + (0x1 * cpu-nr).
 
 Example:
 
-   timer@200a004 {
-   compatible = "qcom,msm-gpt", "qcom,msm-timer";
-   interrupts = <1 2 0x301>;
-   reg = <0x0200a004 0x10>;
-   clock-frequency = <32768>;
-   cpu-offset = <0x4>;
-   };
-
-   timer@200a024 {
-   compatible = "qcom,msm-dgt", "qcom,msm-timer";
-   interrupts = <1 3 0x301>;
-   reg = <0x0200a024 0x10>,
- <0x0200a034 0x4>;
-   clock-frequency = <675>;
+   timer@200a000 {
+   compatible = "qcom,scss-timer", "qcom,msm-timer";
+   interrupts = <1 1 0x301>,
+<1 2 0x301>,
+<1 3 0x301>;
+   reg = <0x0200a000 0x100>;
+   clock-frequency = <1920>,
+ <32768>;
cpu-offset = <0x4>;
};
diff --git a/arch/arm/boot/dts/msm8660-surf.dts 
b/arch/arm/boot/dts/msm8660-surf.dts
index 31f2157..743ef42 100644
--- a/arch/arm/boot/dts/msm8660-surf.dts
+++ b/arch/arm/boot/dts/msm8660-surf.dts
@@ -16,19 +16,13 @@
};
 
timer@204 {
-   compatible = "qcom,msm-gpt", "qcom,msm-timer";
-   interrupts = <1 1 0x301>;
-   reg = <0x0204 0x10>;
-   clock-frequency = <32768>;
-   cpu-offset = <0x4>;
-   };
-
-   timer@224 {
-   compatible = "qcom,msm-dgt", "qcom,msm-timer";
-   interrupts = <1 0 0x301>;
-   reg = <0x0224 0x10>,
- <0x0234 0x4>;
-   clock-frequency = <675>;
+   compatible = "qcom,scss-timer", "qcom,msm-timer";
+   interrupts = <1 0 0x301>,
+<1 1 0x301>,
+ 

[PATCH 0/3] Fix msm timer clearing bugs

[Stephen Boyd]

This patchset cleans up some bugs in the msm timer code and overhauls
the DT binding. I don't think we'll need to radically change it again,
and we haven't shipped any devices with these bindings so we should
be ok. The important thing is that the binding is consolidated and
more clearly describes the hardware. We can use the compatible field to
determine which timers are present and what the register layout is,
so we may need to add more compatible fields in the future.

Patches are based on v3.9-rc2. These patches will conflict with
my other patch series to remove the local timer API, but the
conflict isn't impossible to resolve and we can figure out how to
deal with that after review.

Patch 1 is a bug fix which could probably go into 3.9 if desired.
Patch 2 overhauls the DT binding to be cleaner, and patch 3 fixes
a bug where we don't wait for the timer to be clear before
programming it leading to no more ticks.

Stephen Boyd (3):
  ARM: msm: Stop counting before reprogramming clockevent
  ARM: msm: Rework timer binding to be more general
  ARM: msm: Wait for timer clear to complete

 .../devicetree/bindings/arm/msm/timer.txt  |  41 
 arch/arm/boot/dts/msm8660-surf.dts |  20 ++--
 arch/arm/boot/dts/msm8960-cdp.dts  |  22 ++--
 arch/arm/mach-msm/timer.c  | 115 ++---
 4 files changed, 90 insertions(+), 108 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 1/3] ARM: msm: Stop counting before reprogramming clockevent

[Stephen Boyd]

If the clockevent is forcibly reprogrammed to have a different
match value we mistakenly assume the timer is not ticking and
program a new match value while the timer is running. Although we
clear the timer before programming a new match, it's better to
stop the timer before clearing it so that we're sure the proper
amount of ticks are counted. Failure to do so can lead to missed
ticks and system hangs.

Signed-off-by: Stephen Boyd 
---
 arch/arm/mach-msm/timer.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 2969027..f9fd77e 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -62,7 +62,10 @@ static int msm_timer_set_next_event(unsigned long cycles,
 {
u32 ctrl = readl_relaxed(event_base + TIMER_ENABLE);
 
-   writel_relaxed(0, event_base + TIMER_CLEAR);
+   ctrl &= ~TIMER_ENABLE_EN;
+   writel_relaxed(ctrl, event_base + TIMER_ENABLE);
+
+   writel_relaxed(ctrl, event_base + TIMER_CLEAR);
writel_relaxed(cycles, event_base + TIMER_MATCH_VAL);
writel_relaxed(ctrl | TIMER_ENABLE_EN, event_base + TIMER_ENABLE);
return 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 3/3] ARM: msm: Wait for timer clear to complete

[Stephen Boyd]

Without looping on the status bit, there is no way to guarantee
that a clear of the timer has actually completed. This can cause
us to enable the timer before the count has cleared and miss a
timer interrupt. To simplify this patch, remove the timer
register setup done during timer init, since it's duplicate work
that is eventually done in the set_next_event() callback.

Signed-off-by: Stephen Boyd 
---
 arch/arm/mach-msm/timer.c | 41 +++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 9f033c3..284313f 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -30,20 +30,22 @@
 
 #include "common.h"
 
-#define TIMER_MATCH_VAL 0x
-#define TIMER_COUNT_VAL 0x0004
-#define TIMER_ENABLE0x0008
-#define TIMER_ENABLE_CLR_ON_MATCH_ENBIT(1)
-#define TIMER_ENABLE_EN BIT(0)
-#define TIMER_CLEAR 0x000C
-#define DGT_CLK_CTL0x10
-#define DGT_CLK_CTL_DIV_4  0x3
+#define TIMER_MATCH_VAL0x
+#define TIMER_COUNT_VAL0x0004
+#define TIMER_ENABLE   0x0008
+#define TIMER_ENABLE_CLR_ON_MATCH_EN   BIT(1)
+#define TIMER_ENABLE_ENBIT(0)
+#define TIMER_CLEAR0x000C
+#define DGT_CLK_CTL0x10
+#define DGT_CLK_CTL_DIV_4  0x3
+#define TIMER_STS_GPT0_CLR_PENDBIT(10)
 
 #define GPT_HZ 32768
 
 #define MSM_DGT_SHIFT 5
 
 static void __iomem *event_base;
+static void __iomem *sts_base;
 
 static irqreturn_t msm_timer_interrupt(int irq, void *dev_id)
 {
@@ -68,6 +70,11 @@ static int msm_timer_set_next_event(unsigned long cycles,
 
writel_relaxed(ctrl, event_base + TIMER_CLEAR);
writel_relaxed(cycles, event_base + TIMER_MATCH_VAL);
+
+   if (sts_base)
+   while (readl_relaxed(sts_base) & TIMER_STS_GPT0_CLR_PEND)
+   cpu_relax();
+
writel_relaxed(ctrl | TIMER_ENABLE_EN, event_base + TIMER_ENABLE);
return 0;
 }
@@ -138,9 +145,6 @@ static int __cpuinit msm_local_timer_setup(struct 
clock_event_device *evt)
if (!smp_processor_id())
return 0;
 
-   writel_relaxed(0, event_base + TIMER_ENABLE);
-   writel_relaxed(0, event_base + TIMER_CLEAR);
-   writel_relaxed(~0, event_base + TIMER_MATCH_VAL);
evt->irq = msm_clockevent.irq;
evt->name = "local_timer";
evt->features = msm_clockevent.features;
@@ -178,9 +182,6 @@ static void __init msm_timer_init(u32 dgt_hz, int 
sched_bits, int irq,
struct clocksource *cs = _clocksource;
int res;
 
-   writel_relaxed(0, event_base + TIMER_ENABLE);
-   writel_relaxed(0, event_base + TIMER_CLEAR);
-   writel_relaxed(~0, event_base + TIMER_MATCH_VAL);
ce->cpumask = cpumask_of(0);
ce->irq = irq;
 
@@ -275,6 +276,7 @@ void __init msm_dt_timer_init(void)
of_node_put(np);
 
event_base = base + 0x4;
+   sts_base = base + 0x88;
source_base = cpu0_base + 0x24;
freq /= 4;
writel_relaxed(DGT_CLK_CTL_DIV_4, source_base + DGT_CLK_CTL);
@@ -283,7 +285,8 @@ void __init msm_dt_timer_init(void)
 }
 #endif
 
-static int __init msm_timer_map(phys_addr_t addr, u32 event, u32 source)
+static int __init msm_timer_map(phys_addr_t addr, u32 event, u32 source,
+   u32 sts)
 {
void __iomem *base;
 
@@ -294,6 +297,8 @@ static int __init msm_timer_map(phys_addr_t addr, u32 
event, u32 source)
}
event_base = base + event;
source_base = base + source;
+   if (sts)
+   sts_base = base + sts;
 
return 0;
 }
@@ -302,7 +307,7 @@ void __init msm7x01_timer_init(void)
 {
struct clocksource *cs = _clocksource;
 
-   if (msm_timer_map(0xc010, 0x0, 0x10))
+   if (msm_timer_map(0xc010, 0x0, 0x10, 0x0))
return;
cs->read = msm_read_timer_count_shift;
cs->mask = CLOCKSOURCE_MASK((32 - MSM_DGT_SHIFT));
@@ -313,14 +318,14 @@ void __init msm7x01_timer_init(void)
 
 void __init msm7x30_timer_init(void)
 {
-   if (msm_timer_map(0xc010, 0x4, 0x24))
+   if (msm_timer_map(0xc010, 0x4, 0x24, 0x80))
return;
msm_timer_init(24576000 / 4, 32, 1, false);
 }
 
 void __init qsd8x50_timer_init(void)
 {
-   if (msm_timer_map(0xAC10, 0x0, 0x10))
+   if (msm_timer_map(0xAC10, 0x0, 0x10, 0x34))
return;
msm_timer_init(1920 / 4, 32, 7, false);
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [PATCH v2] usb: ehci-s5p: Use devm for requesting ehci_vbus_gpio

[Jingoo Han]

On Friday, March 15, 2013 12:16 PM, Doug Anderson wrote:
> 
> The ehci_vbus_gpio is requested but never freed.  This can cause
> problems with deferred probes and would cause problems if
> s5p_ehci_remove was ever called.  Use devm to fix this.
> 
> Signed-off-by: Doug Anderson 

Acked-by: Jingoo Han 


Best regards,
Jingoo Han

> ---
> Changes in v2:
> - >dev => dev elsewhere in s5p_setup_vbus_gpio()
> 
>  drivers/usb/host/ehci-s5p.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index 20ebf6a..738490e 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -92,20 +92,21 @@ static void s5p_ehci_phy_disable(struct s5p_ehci_hcd 
> *s5p_ehci)
> 
>  static void s5p_setup_vbus_gpio(struct platform_device *pdev)
>  {
> + struct device *dev = >dev;
>   int err;
>   int gpio;
> 
> - if (!pdev->dev.of_node)
> + if (!dev->of_node)
>   return;
> 
> - gpio = of_get_named_gpio(pdev->dev.of_node,
> - "samsung,vbus-gpio", 0);
> + gpio = of_get_named_gpio(dev->of_node, "samsung,vbus-gpio", 0);
>   if (!gpio_is_valid(gpio))
>   return;
> 
> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
> + err = devm_gpio_request_one(dev, gpio, GPIOF_OUT_INIT_HIGH,
> + "ehci_vbus_gpio");
>   if (err)
> - dev_err(>dev, "can't request ehci vbus gpio %d", gpio);
> + dev_err(dev, "can't request ehci vbus gpio %d", gpio);
>  }
> 
>  static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
> --
> 1.8.1.3
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�:+v돣�쳭喩zZ+€�+zf＂톒쉱�~넮녬i鎬z�췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝

[RFC PATCH 1/2] fs: sysfs: Add support for devm_ functions

[Guenter Roeck]

Add support for
devm_sysfs_create_file
devm_sysfs_remove_file
devm_sysfs_create_group
devm_sysfs_remove_group

Signed-off-by: Guenter Roeck 
---
 fs/sysfs/file.c   |   51 +++
 fs/sysfs/group.c  |   53 +
 include/linux/sysfs.h |   30 
 3 files changed, 134 insertions(+)

diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 602f56d..d8f4631 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "sysfs.h"
@@ -589,6 +590,40 @@ int sysfs_create_files(struct kobject *kobj, const struct 
attribute **ptr)
return err;
 }
 
+struct sysfs_devres {
+   struct list_head node;
+   const struct attribute *attr;
+};
+
+static void devm_sysfs_file_release(struct device *dev, void *res)
+{
+   struct sysfs_devres *devres = res;
+
+   sysfs_remove_file(>kobj, devres->attr);
+}
+
+int devm_sysfs_create_file(struct device *dev, const struct attribute *attr)
+{
+   struct sysfs_devres *devres;
+   int ret;
+
+   devres = devres_alloc(devm_sysfs_file_release, sizeof(*devres),
+ GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
+
+   devres->attr = attr;
+
+   ret = sysfs_create_file(>kobj, attr);
+   if (!ret)
+   devres_add(dev, devres);
+   else
+   devres_free(devres);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_create_file);
+
 /**
  * sysfs_add_file_to_group - add an attribute file to a pre-existing group.
  * @kobj: object we're acting for.
@@ -678,6 +713,22 @@ void sysfs_remove_files(struct kobject * kobj, const 
struct attribute **ptr)
sysfs_remove_file(kobj, ptr[i]);
 }
 
+static int devm_sysfs_device_match(struct device *dev, void *res, void *data)
+{
+   struct sysfs_devres *devres = res;
+
+   return devres->attr == data;
+}
+
+void devm_sysfs_remove_file(struct device *dev, const struct attribute *attr)
+{
+   WARN_ON(devres_destroy(dev, devm_sysfs_file_release,
+  devm_sysfs_device_match, (void *)attr));
+
+   sysfs_remove_file(>kobj, attr);
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_remove_file);
+
 /**
  * sysfs_remove_file_from_group - remove an attribute file from a group.
  * @kobj: object we're acting for.
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index aec3d5c..a0b8f95 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "sysfs.h"
 
 
@@ -104,6 +105,41 @@ int sysfs_create_group(struct kobject *kobj,
return internal_create_group(kobj, 0, grp);
 }
 
+struct sysfs_devres {
+   struct list_head node;
+   const struct attribute_group *grp;
+};
+
+static void devm_sysfs_group_release(struct device *dev, void *res)
+{
+   struct sysfs_devres *devres = res;
+
+   sysfs_remove_group(>kobj, devres->grp);
+}
+
+int devm_sysfs_create_group(struct device *dev,
+   const struct attribute_group *grp)
+{
+   struct sysfs_devres *devres;
+   int ret;
+
+   devres = devres_alloc(devm_sysfs_group_release, sizeof(*devres),
+ GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
+
+   devres->grp = grp;
+
+   ret = sysfs_create_group(>kobj, grp);
+   if (!ret)
+   devres_add(dev, devres);
+   else
+   devres_free(devres);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_create_group);
+
 /**
  * sysfs_update_group - given a directory kobject, update an attribute group
  * @kobj:  The kobject to update the group on
@@ -152,6 +188,23 @@ void sysfs_remove_group(struct kobject * kobj,
sysfs_put(sd);
 }
 
+static int devm_sysfs_device_match(struct device *dev, void *res, void *data)
+{
+   struct sysfs_devres *devres = res;
+
+   return devres->grp == data;
+}
+
+void devm_sysfs_remove_group(struct device *dev,
+const struct attribute_group *grp)
+{
+   WARN_ON(devres_destroy(dev, devm_sysfs_group_release,
+  devm_sysfs_device_match, (void *)grp));
+
+   sysfs_remove_group(>kobj, grp);
+}
+EXPORT_SYMBOL_GPL(devm_sysfs_remove_group);
+
 /**
  * sysfs_merge_group - merge files into a pre-existing attribute group.
  * @kobj:  The kobject containing the group.
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index e2cee22..df0fa5a 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -20,6 +20,7 @@
 #include 
 
 struct kobject;
+struct device;
 struct module;
 enum kobj_ns_type;
 
@@ -142,11 +143,14 @@ int __must_check sysfs_move_dir(struct kobject *kobj,
 
 int __must_check sysfs_create_file(struct kobject *kobj,
   const struct attribute *attr);
+int __must_check devm_sysfs_create_file(struct 

[RFC PATCH 2/2] drivers/core: Add support for devm_ functions

[Guenter Roeck]

Add support for devm_device_create_file and devm_device_remove_file.

Signed-off-by: Guenter Roeck 
---
 drivers/base/core.c|   18 ++
 include/linux/device.h |4 
 2 files changed, 22 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 56536f4b0..76ff488 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -568,6 +568,16 @@ int device_create_file(struct device *dev,
return error;
 }
 
+int devm_device_create_file(struct device *dev,
+   const struct device_attribute *attr)
+{
+   int error = 0;
+   if (dev)
+   error = devm_sysfs_create_file(dev, >attr);
+   return error;
+}
+EXPORT_SYMBOL_GPL(devm_device_create_file);
+
 /**
  * device_remove_file - remove sysfs attribute file.
  * @dev: device.
@@ -580,6 +590,14 @@ void device_remove_file(struct device *dev,
sysfs_remove_file(>kobj, >attr);
 }
 
+void devm_device_remove_file(struct device *dev,
+const struct device_attribute *attr)
+{
+   if (dev)
+   devm_sysfs_remove_file(dev, >attr);
+}
+EXPORT_SYMBOL_GPL(devm_device_remove_file);
+
 /**
  * device_create_bin_file - create sysfs binary attribute file for device.
  * @dev: device.
diff --git a/include/linux/device.h b/include/linux/device.h
index 9d6464e..1c56fb7 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -521,8 +521,12 @@ ssize_t device_store_bool(struct device *dev, struct 
device_attribute *attr,
 
 extern int device_create_file(struct device *device,
  const struct device_attribute *entry);
+extern int devm_device_create_file(struct device *device,
+  const struct device_attribute *entry);
 extern void device_remove_file(struct device *dev,
   const struct device_attribute *attr);
+extern void devm_device_remove_file(struct device *dev,
+   const struct device_attribute *attr);
 extern int __must_check device_create_bin_file(struct device *dev,
const struct bin_attribute *attr);
 extern void device_remove_bin_file(struct device *dev,
-- 
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/

[RFC PATCH 0/2] fs: sysfs: Add devres support

[Guenter Roeck]

Provide devres functions for device_create_file, sysfs_create_file,
and sysfs_create_group plus the respective remove functions.

Idea is to be able to drop calls to the remove functions from the various
drivers using those calls.

Potential savings are substantial. There are more than 700 calls to
device_remove_file in the kernel, more than 500 calls to sysfs_remove_group,
and some 50 calls to sysfs_remove_file (though not all of those use dev->kobj
as parameter). Expanding the API to sysfs_create_bin_file would add another 80+
opportunities, and adding sysfs_create_link would create another 100 or so.

The approach used in this patch set is one possible solution.
Another possibility would be to not bother with sysfs and provide
devm_device_create_file, devm_device_create_group, and its remove functions
in drivers/base/core.c instead.

I am not sure which approach is better. The solution presented here is more
aligned with other devm_ functions (I think) and does not require changing
function parameters besides the first one. Providing functions in the driver
core code would mean parameter changes [sysfs_create_file(dev, attr) ->
devm_device_create_file(dev, device_attr)] and thus be more invasive and thus a
bit more risky. It would also create devres data entries even if sysfs
is not configured (if that is even possible nowadays).

One question with the presented API is how the API should look like.
Should it be

int devm_sysfs_create_file(struct device *dev, const struct attribute *attr)

or

int devm_sysfs_create_file(struct device *dev,
   struct kobject *kobj,
   const struct attribute *attr)

The latter would be more consistent with other devm_ functions, but the
additional parameter seems like a waste, as the kobj would presumably
always be >kobj anyway.

Before I go much further with this, I would like to get some feedback from the
community if this all makes sense or not.

Note that the code is compile tested only at this time - I don't want to spend
too much time on it if turns out to be a bad idea.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 3/3] mtd: add 4 Toshiba nand chips for the full-id case

[Huang Shijie]

I have 4 Toshiba nand chips which can not be parsed out by the
id data. We can not get the oob size from the id data. So add them
as the full-id nand chips in the first of nand_flash_ids.

The comment for the full-id items is from Brian.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/nand_ids.c |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 625bc89..1c242cc 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -10,6 +10,7 @@
  */
 #include 
 #include 
+#include 
 
 #define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
 #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16)
@@ -22,6 +23,24 @@
  * extended chip ID.
  */
 struct nand_flash_dev nand_flash_ids[] = {
+   /*
+* Some incompatible NAND chips share device ID's and so must be
+* listed by full ID. We list them first so that we can easily identify
+* the most specific match.
+*/
+   {"TC58NVG2S0F 4G 3.3V 8-bit",
+   { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
+   SZ_4K, SZ_512, SZ_256K, 0, 8, 224},
+   {"TC58NVG3S0F 8G 3.3V 8-bit",
+   { .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
+   SZ_4K, SZ_1K, SZ_256K, 0, 8, 232},
+   {"TC58NVG5D2 32G 3.3V 8-bit",
+   { .id = {0x98, 0xd7, 0x94, 0x32, 0x76, 0x56, 0x09, 0x00} },
+   SZ_8K, SZ_4K, SZ_1M, 0, 8, 640},
+   {"TC58NVG6D2 64G 3.3V 8-bit",
+   { .id = {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20} },
+   SZ_8K, SZ_8K, SZ_2M, 0, 8, 640},
+
LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 512, 4, 0x2000, 0),
LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 512, 4, 0x2000, 0),
LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE5, 512, 4, 0x2000, 0),
-- 
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 v6 1/3] mtd: add new fields to nand_flash_dev{}

[Huang Shijie]

As time goes on, we begin to meet the situation that we can not get enough
information from some nand chips's id data. Take some Toshiba's nand chips
for example. I have 4 Toshiba's nand chips in my hand:
TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2

When we read these chips' datasheets, we will get the geometry of these chips:
TC58NVG2S0F : 4096 + 224
TC58NVG3S0F : 4096 + 232
TC58NVG5D2  : 8192 + 640
TC58NVG6D2  : 8192 + 640

But we can not parse out the correct oob size for these chips from the id data.

This patch adds some new fields to the nand_flash_dev{}:
  @id_len: the valid length of the id data. See the comments in
   nand_id_has_period()
  @oobsize: the oob size.

Signed-off-by: Huang Shijie 
---
 include/linux/mtd/nand.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 33516eb..4b87815 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -584,6 +584,8 @@ struct nand_chip {
  * @chipsize: total chip size in MiB
  * @erasesize: eraseblock size in bytes (determined from the extended ID if 0)
  * @options: stores various chip bit options
+ * @id_len: The valid length of the @id.
+ * @oobsize: OOB size
  */
 struct nand_flash_dev {
char *name;
@@ -598,6 +600,8 @@ struct nand_flash_dev {
unsigned int chipsize;
unsigned int erasesize;
unsigned int options;
+   uint16_t id_len;
+   uint16_t oobsize;
 };
 
 /**
-- 
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 v6 2/3] mtd: add the support to parse out the full-id nand type

[Huang Shijie]

When we meet a full-id nand type whose @id_len is not zero, we can use
the find_full_id_nand() to parse out the necessary information for a
nand chip.

If we meet a non full-id nand type, we can handle it in the legacy way.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/nand/nand_base.c |   35 ---
 1 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 72eada2..49de9da 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3123,6 +3123,30 @@ static void nand_decode_bbm_options(struct mtd_info *mtd,
chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
 }
 
+static inline bool is_full_id_nand(struct nand_flash_dev *type)
+{
+   return type->id_len;
+}
+
+static bool find_full_id_nand(struct mtd_info *mtd, struct nand_chip *chip,
+  struct nand_flash_dev *type, u8 *id_data, int *busw)
+{
+   if (!strncmp(type->id, id_data, type->id_len)) {
+   mtd->writesize = type->pagesize;
+   mtd->erasesize = type->erasesize;
+   mtd->oobsize = type->oobsize;
+
+   chip->cellinfo = id_data[2];
+   chip->chipsize = (uint64_t)type->chipsize << 20;
+   chip->options |= type->options;
+
+   *busw = type->options & NAND_BUSWIDTH_16;
+
+   return true;
+   }
+   return false;
+}
+
 /*
  * Get the flash and manufacturer id and lookup if the type is supported.
  */
@@ -3174,9 +3198,14 @@ static struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
if (!type)
type = nand_flash_ids;
 
-   for (; type->name != NULL; type++)
-   if (*dev_id == type->dev_id)
-   break;
+   for (; type->name != NULL; type++) {
+   if (is_full_id_nand(type)) {
+   if (find_full_id_nand(mtd, chip, type, id_data, ))
+   goto ident_done;
+   } else if (*dev_id == type->dev_id) {
+   break;
+   }
+   }
 
chip->onfi_version = 0;
if (!type->name || !type->pagesize) {
-- 
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 v2] usb: ehci-s5p: Use devm for requesting ehci_vbus_gpio

[Doug Anderson]

The ehci_vbus_gpio is requested but never freed.  This can cause
problems with deferred probes and would cause problems if
s5p_ehci_remove was ever called.  Use devm to fix this.

Signed-off-by: Doug Anderson 
---
Changes in v2:
- >dev => dev elsewhere in s5p_setup_vbus_gpio()

 drivers/usb/host/ehci-s5p.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 20ebf6a..738490e 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -92,20 +92,21 @@ static void s5p_ehci_phy_disable(struct s5p_ehci_hcd 
*s5p_ehci)
 
 static void s5p_setup_vbus_gpio(struct platform_device *pdev)
 {
+   struct device *dev = >dev;
int err;
int gpio;
 
-   if (!pdev->dev.of_node)
+   if (!dev->of_node)
return;
 
-   gpio = of_get_named_gpio(pdev->dev.of_node,
-   "samsung,vbus-gpio", 0);
+   gpio = of_get_named_gpio(dev->of_node, "samsung,vbus-gpio", 0);
if (!gpio_is_valid(gpio))
return;
 
-   err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
+   err = devm_gpio_request_one(dev, gpio, GPIOF_OUT_INIT_HIGH,
+   "ehci_vbus_gpio");
if (err)
-   dev_err(>dev, "can't request ehci vbus gpio %d", gpio);
+   dev_err(dev, "can't request ehci vbus gpio %d", gpio);
 }
 
 static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
-- 
1.8.1.3

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

Re: [PATCH] usb: ehci-s5p: Use devm for requesting ehci_vbus_gpio

[Doug Anderson]

Jingoo,

On Thu, Mar 14, 2013 at 5:30 PM, Jingoo Han  wrote:
> Would you replace other '>dev' with 'dev' in s5p_setup_vbus_gpio()
> as below? It seems to be better for readability.

Yes, of course.  That was silly of me not to add the "dev" local and
not update the other places...  Thanks for your review!

-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: [PATCHv2, RFC 14/30] thp, mm: naive support of thp in generic read/write routines

[Hillf Danton]

On Fri, Mar 15, 2013 at 1:50 AM, Kirill A. Shutemov
 wrote:
> +   if (PageTransTail(page)) {
> +   page_cache_release(page);
> +   page = find_get_page(mapping,
> +   index & ~HPAGE_CACHE_INDEX_MASK);
check page is valid, please.

> +   if (!PageTransHuge(page)) {
> +   page_cache_release(page);
> +   goto find_page;
> +   }
> +   }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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: Document clocks in samsung,exynos4210-ehci/ohci bindings

[Jingoo Han]

On Friday, March 15, 2013 8:01 AM, Doug Anderson wrote:
> 
> The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
> using the common clock framework.  Document it.
> 
> Signed-off-by: Doug Anderson 

It looks good.
Acked-by: Jingoo Han 


Best regards,
Jingoo Han

> ---
> Changes in v2:
> - Fixed embarrassing typo adc=>usb.  Thanks Jingoo!
> 
>  Documentation/devicetree/bindings/usb/exynos-usb.txt | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> index f66fcdd..b3abde7 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -10,6 +10,8 @@ Required properties:
>   - reg: physical base address of the controller and length of memory mapped
> region.
>   - interrupts: interrupt number to the cpu.
> + - clocks: from common clock binding: handle to usb clock.
> + - clock-names: from common clock binding: Shall be "usbhost".
> 
>  Optional properties:
>   - samsung,vbus-gpio:  if present, specifies the GPIO that
> @@ -22,6 +24,9 @@ Example:
>   reg = <0x1211 0x100>;
>   interrupts = <0 71 0>;
>   samsung,vbus-gpio = < 6 1 3 3>;
> +
> + clocks = < 285>;
> + clock-names = "usbhost";
>   };
> 
>  OHCI
> @@ -31,10 +36,15 @@ Required properties:
>   - reg: physical base address of the controller and length of memory mapped
> region.
>   - interrupts: interrupt number to the cpu.
> + - clocks: from common clock binding: handle to usb clock.
> + - clock-names: from common clock binding: Shall be "usbhost".
> 
>  Example:
>   usb@1212 {
>   compatible = "samsung,exynos4210-ohci";
>   reg = <0x1212 0x100>;
>   interrupts = <0 71 0>;
> +
> + clocks = < 285>;
> + clock-names = "usbhost";
>   };
> --
> 1.8.1.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/

[PATCH v6 0/3] mtd: use the full-id as the keyword for some nand chips

[Huang Shijie]

As time goes on, we begin to meet the situation that we can not
get enough information from some nand chips's id data.
Take some Toshiba's nand chips for example.
I have 4 Toshiba's nand chips in my hand:
TC58NVG2S0F, TC58NVG3S0F, TC58NVG5D2, TC58NVG6D2

When we read these chips' datasheets, we will get the geometry of these chips:
TC58NVG2S0F : 4096 + 224
TC58NVG3S0F : 4096 + 232
TC58NVG5D2  : 8192 + 640
TC58NVG6D2  : 8192 + 640

But we can not parse out the correct oob size for these chips from the id data.
So it is time to add some new fields to the nand_flash_dev{},
and update the detection mechanisms.

v5 --> v6:
[1] add back the id_len as Brian's suggest.
[2] use id_len to check the full id nand or not.
[3] change the new fields oob_size/id_len to "uint16_t" type.
[4] misc

v4 --> v5:
[1] remove the id_len field.
[2] based on Artem "mtd: nand: use more reasonable integer types"
[3] add more comments.

v3 --> v4:
[1] rewrite the code based on the latest l2-mtd.
[2] add the full-id nand in the nand_flash_lds.

v2 --> v3:
[1] remove the duplicated header.
[2] remove the field "ecc_len" in nand_flash_dev{}.
[3] fix some coding style warnings.
[4] add more comments

Huang Shijie (3):
  mtd: add new fields to nand_flash_dev{}
  mtd: add the support to parse out the full-id nand type
  mtd: add 4 Toshiba nand chips for the full-id case

 drivers/mtd/nand/nand_base.c |   35 ---
 drivers/mtd/nand/nand_ids.c  |   19 +++
 include/linux/mtd/nand.h |4 
 3 files changed, 55 insertions(+), 3 deletions(-)


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

Re: [PATCH] xtensa: net: fix invalid use of sizeof in iss_net_setup()

[Max Filippov]

On Thu, Mar 14, 2013 at 6:06 PM, Wei Yongjun  wrote:
> From: Wei Yongjun 
>
> sizeof() when applied to a pointer typed expression gives the
> size of the pointer, not that of the pointed data.
>
> Signed-off-by: Wei Yongjun 
> ---
>  arch/xtensa/platforms/iss/network.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Max Filippov 

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

[PATCH v2] usb: Document clocks in samsung,exynos4210-ehci/ohci bindings

[Doug Anderson]

The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
using the common clock framework.  Document it.

Signed-off-by: Doug Anderson 
---
Changes in v2:
- Fixed embarrassing typo adc=>usb.  Thanks Jingoo!

 Documentation/devicetree/bindings/usb/exynos-usb.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index f66fcdd..b3abde7 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -10,6 +10,8 @@ Required properties:
  - reg: physical base address of the controller and length of memory mapped
region.
  - interrupts: interrupt number to the cpu.
+ - clocks: from common clock binding: handle to usb clock.
+ - clock-names: from common clock binding: Shall be "usbhost".
 
 Optional properties:
  - samsung,vbus-gpio:  if present, specifies the GPIO that
@@ -22,6 +24,9 @@ Example:
reg = <0x1211 0x100>;
interrupts = <0 71 0>;
samsung,vbus-gpio = < 6 1 3 3>;
+
+   clocks = < 285>;
+   clock-names = "usbhost";
};
 
 OHCI
@@ -31,10 +36,15 @@ Required properties:
  - reg: physical base address of the controller and length of memory mapped
region.
  - interrupts: interrupt number to the cpu.
+ - clocks: from common clock binding: handle to usb clock.
+ - clock-names: from common clock binding: Shall be "usbhost".
 
 Example:
usb@1212 {
compatible = "samsung,exynos4210-ohci";
reg = <0x1212 0x100>;
interrupts = <0 71 0>;
+
+   clocks = < 285>;
+   clock-names = "usbhost";
};
-- 
1.8.1.3

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

Re: [PATCH v2] wait while adding MMC host to ensure root mounts

[Jaehoon Chung]

On 03/14/2013 01:08 PM, Namjae Jeon wrote:
> 2013/3/14, Sergey Yanovich :
>> MMC hosts are added asynchronously. We need to wait until detect returns to
>> avoid failed root filesystem mounts.
>> ---8<---
>> VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
>> Please append a correct "root=" boot option; here are the available
>> partitions:
>> mmc0: host does not support reading read-only switch. assuming
>> write-enable.
>> 1f00 256 mtdblock0  (driver?)
>> 1f01 256 mtdblock1  (driver?)
>> 1f022560 mtdblock2 mmc0: new SDHC card at address b368
>>  (driver?)
>> 1f03   29696 mtdblock3  (driver?)
>> 1f04   16384 mtdblock4 mmcblk0: mmc0:b368 USD   3.72 GiB
>>  (driver?)
>>  mmcblk0: p1
>> b300 3910656 mmcblk0  driver: mmcblk
>>   b301 3906560 mmcblk0p1 -01
>> Kernel panic - not syncing: VFS: Unable to mount root fs on
>> unknown-block(0,0)
>> ---8<---
>>
>> Signed-off-by: Sergey Yanovich 
>> ---
> Hi.
> Have you ever tried to use rootwait or rootdelay on command line ?
> If no, You can use them.
I agreed the Namjae's suggestion..if you use the rootwait or rootdelay, it's 
waiting for mounting rootfs.

Best Regards,
Jaehoon Chung
> 
> 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/

[Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig

[Chen Gang]

Hello Maintainers:

  do next-* tree support powerpc POWER7 with allmodconfig ?

  I met an issue, can we bear it (or I need additional trying) ?


Compiling:
  make V=1 EXTRA_CFLAGS=-W ARCH=powerpc allmodconfig
set cpu type POWER7 in menuconfig.
set cross-compiler in menuconfig.
  under Fedora 16 x86_64 laptop
  /usr/bin/powerpc64-linux-gnu-gcc -v
gcc version 4.7.1 20120606 (Red Hat 4.7.1-0.1.20120606) (GCC)

Issue:
  error:
/android/public-kernel/linux-next/arch/powerpc/kernel/exceptions-64s.S: 
Assembler messages:

/android/public-kernel/linux-next/arch/powerpc/kernel/exceptions-64s.S:1304: 
Error: attempt to move .org backwards

  command:
powerpc64-linux-gnu-gcc -m64 -Wp,-MD,arch/powerpc/kernel/.head_64.o.d  
-nostdinc -isystem /usr/lib/gcc/powerpc64-linux-gnu/4.7.1/include 
-I/android/public-kernel/linux-next/arch/powerpc/include 
-Iarch/powerpc/include/generated  -I/android/public-kernel/linux-next/include 
-Iinclude -I/android/public-kernel/linux-next/arch/powerpc/include/uapi 
-Iarch/powerpc/include/generated/uapi 
-I/android/public-kernel/linux-next/include/uapi -Iinclude/generated/uapi 
-include /android/public-kernel/linux-next/include/linux/kconfig.h -D__KERNEL__ 
 -I/android/public-kernel/linux-next/arch/powerpc -Iarch/powerpc -D__ASSEMBLY__ 
 -I/android/public-kernel/linux-next/arch/powerpc -Iarch/powerpc -Wa,-maltivec 
-gdwarf-2   -c -o arch/powerpc/kernel/head_64.o 
/android/public-kernel/linux-next/arch/powerpc/kernel/head_64.S

  (head_64.S includes exceptions-64.S)


  thanks.

-- 
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: [RFC PATCH] Linux kernel Wait-Free Concurrent Queue Implementation

[Mathieu Desnoyers]

* Eric Wong (normalper...@yhbt.net) wrote:
> Mathieu Desnoyers  wrote:
> > * Eric Wong (normalper...@yhbt.net) wrote:
> > > Mathieu Desnoyers  wrote:
> > > > The advantage of using splice() over dequeue() is that you will reduce
> > > > the amount of interactions between concurrent enqueue and dequeue
> > > > operations on the head and tail of the same queue.
> > > 
> > > I wanted to use splice here originally, but epoll_wait(2) may not
> > > consume the entire queue, as it's limited to maxevents specified by the
> > > user calling epoll_wait.
> > 
> > I see,
> > 
> > > 
> > > With unconsumed elements, I need to preserve ordering of the queue to
> > > avoid starvation.  So I would either need to:
> > > 
> > > a) splice the unconsumed portion back to the head of the shared queue.
> > >I'm not sure if this is possible while elements are being enqueued...
> > 
> > That would be a double-ended queue. I haven't thought this problem
> > through yet.
> > 
> > >Using a mutex for splicing back to unconsumed elements is OK, and
> > >probably required anyways since we need to keep EPOLLONESHOT
> > >unmasking synced with dequeue.
> > > 
> > > b) preserve the unconsumed spliced queue across epoll_wait invocations
> > >but that requires checking both queues for event availability...
> > 
> > I think b) should be preferred over a).
> > 
> > Basically, instead of having the "unconsumed element" queue on the stack
> > as I suggested, you might want to keep it across epoll_wait invocations.
> > 
> > Before you start digging in the unconsumed element queue, you just start
> > by splicing the content of the shared queue into the tail of unconsumed
> > queue. Then, you simply dequeue the unconsumed queue elements until you
> > either reach the end or the max nr.
> > 
> > You should note that with this scheme, you'll have to dequeue items from
> > the unconsumed queue rather than just iterating over the elements. The
> > nice side of consuming all the elements (in the temp queue on the local
> > stack) is that you don't care about dequeuing, since the entire queue
> > will vanish. However, in this case, since you care about keeping the
> > queue after a partial iteration, you need to dequeue from it.
> > 
> > And yes, this approach involves checking both queues for event
> > availability. Hopefully none of this will be too much of an issue
> > performance-wise.
> 
> Right.  I will try this, I don't think the check will be too expensive.
> 
> When dequeuing from the unconsumed queue, perhaps there should be a
> "dequeue_local" function which omits the normal barriers required
> for the shared queue.
> 
> With a splice and without needing barriers for iteration, this sounds good.

Well actually, __wfcq_dequeue() is really not that expensive. In terms
of synchronization, here is what it typically does:

node = ___wfcq_node_sync_next(>node);
  -> busy wait if node->next is NULL. This check is needed even if we
 work on a "local" queue, because the O(1) splice operation does not
 walk over every node to check for NULL next pointer: this is left
 to the dequeue/iteration operations.
if ((next = CMM_LOAD_SHARED(node->next)) == NULL) {
  -> only taken if we are getting the last node of the queue. Happens
 at most once per batch.
}

head->node.next = next;
  -> a simple store.

smp_read_barrier_depends();
  -> no-op on everything but Alpha.

return node;

So my recommendation would be to be careful before trying to come up
with flavors that remove barriers if those are not actually hurting the
fast-path significantly. By dequeue fast-path, I mean what needs to be
executed for dequeue of each node.

> 
> > Another approach could be to let you work directly on the shared queue:
> > 
> > I could possibly implement a
> > 
> > void __wfcq_snapshot(struct wfcq_head *head,
> > struct wfcq_tail *tail);
> > 
> > That would save a tail shapshot that would then be used to stop
> > iteration, dequeue and splice at the location of the tail snapshot. And
> > 
> > void __wfcq_snapshot_reset(struct wfcq_head *head,
> > struct wfcq_tail *tail);
> > 
> > would set the tail snapshot pointer back to NULL.
> > 
> > This would require a few extra checks, but nothing very expensive I
> > expect.
> > 
> > Thoughts ?
> 
> I'm not sure I follow, would using it be something like this?
> 
>   snapshot
>   iterate (read-only, no dequeue)
>   splice(discard_head, discard_tail, shared_head, iter_stop_point)
>   snapshot_reset

My idea was more like:

snapshot
__wfcq_dequeue until returns NULL or reach max
snapshot_reset

But I would really prefer the splice approach unless there is a very
significant performance gain to do otherwise, because I don't want to
clutter the API with various ways of performing the same thing
needlessly.

> 
> I also use an atomic state variable to prevent an item from being queued
> twice, and I unset that while iterating+dequeueing.
> 
> I change the 

[PATCH v3 0/5] zcache: Support zero-filled pages more efficiently

[Wanpeng Li]

Changelog:
 v2 -> v3:
  * increment/decrement zcache_[eph|pers]_zpages for zero-filled pages, spotted 
by Dan 
  * replace "zero" or "zero page" by "zero_filled_page", spotted by Dan
 v1 -> v2:
  * avoid changing tmem.[ch] entirely, spotted by Dan.
  * don't accumulate [eph|pers]pageframe and [eph|pers]zpages for 
zero-filled pages, spotted by Dan
  * cleanup TODO list
  * add Dan Acked-by.

Motivation:

- Seth Jennings points out compress zero-filled pages with LZO(a lossless 
  data compression algorithm) will waste memory and result in fragmentation.
  https://lkml.org/lkml/2012/8/14/347
- Dan Magenheimer add "Support zero-filled pages more efficiently" feature 
  in zcache TODO list https://lkml.org/lkml/2013/2/13/503

Design:

- For store page, capture zero-filled pages(evicted clean page cache pages and 
  swap pages), but don't compress them, set pampd which store zpage address to
  0x2(since 0x0 and 0x1 has already been ocuppied) to mark special zero-filled
  case and take advantage of tmem infrastructure to transform handle-tuple(pool
  id, object id, and an index) to a pampd. Twice compress zero-filled pages will
  contribute to one zcache_[eph|pers]_pageframes count accumulated.
- For load page, traverse tmem hierachical to transform handle-tuple to pampd 
  and identify zero-filled case by pampd equal to 0x2 when filesystem reads
  file pages or a page needs to be swapped in, then refill the page to zero
  and return.

Test:

dd if=/dev/zero of=zerofile bs=1MB count=500
vmtouch -t zerofile
vmtouch -e zerofile

formula:
- fragmentation level = (zcache_[eph|pers]_pageframes * PAGE_SIZE - 
zcache_[eph|pers]_zbytes) 
  * 100 / (zcache_[eph|pers]_pageframes * PAGE_SIZE)
- memory zcache occupy = zcache_[eph|pers]_zbytes 

Result:

without zero-filled awareness:
- fragmentation level: 98%
- memory zcache occupy: 238MB
with zero-filled awareness:
- fragmentation level: 0%
- memory zcache occupy: 0MB

Wanpeng Li (5):
  introduce zero-filled pages handler
  zero-filled pages awareness
  handle zcache_[eph|pers]_zpages for zero-filled page
  introduce zero-filled page stat count
  clean TODO list

 drivers/staging/zcache/TODO  |3 +-
 drivers/staging/zcache/zcache-main.c |  119 --
 2 files changed, 114 insertions(+), 8 deletions(-)

-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/5] handle zcache_[eph|pers]_zpages for zero-filled page

[Wanpeng Li]

Increment/decrement zcache_[eph|pers]_zpages for zero-filled pages,
the main point of the counters for zpages and pageframes is to be 
able to calculate density == zpages/pageframes. A zero-filled page 
becomes a zpage that "compresses" to zero bytes and, as a result, 
requires zero pageframes for storage. So the zpages counter should 
be increased but the pageframes counter should not.

[Dan Magenheimer : patch description]
Acked-by: Dan Magenheimer 
Signed-off-by: Wanpeng Li 
---
 drivers/staging/zcache/zcache-main.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/zcache/zcache-main.c 
b/drivers/staging/zcache/zcache-main.c
index 6c35c7d..ef8c960 100644
--- a/drivers/staging/zcache/zcache-main.c
+++ b/drivers/staging/zcache/zcache-main.c
@@ -863,6 +863,8 @@ static int zcache_pampd_get_data_and_free(char *data, 
size_t *sizep, bool raw,
if (pampd == (void *)ZERO_FILLED) {
handle_zero_filled_page(data);
zero_filled = true;
+   zsize = 0;
+   zpages = 1;
if (!raw)
*sizep = PAGE_SIZE;
goto zero_fill;
@@ -917,8 +919,11 @@ static void zcache_pampd_free(void *pampd, struct 
tmem_pool *pool,
 
BUG_ON(preemptible());
 
-   if (pampd == (void *)ZERO_FILLED)
+   if (pampd == (void *)ZERO_FILLED) {
zero_filled = true;
+   zsize = 0;
+   zpages = 1;
+   }
 
if (pampd_is_remote(pampd) && !zero_filled) {
 
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/5] zero-filled pages awareness

[Wanpeng Li]

Compression of zero-filled pages can unneccessarily cause internal
fragmentation, and thus waste memory. This special case can be
optimized.

This patch captures zero-filled pages, and marks their corresponding
zcache backing page entry as zero-filled. Whenever such zero-filled
page is retrieved, we fill the page frame with zero.

Acked-by: Dan Magenheimer 
Signed-off-by: Wanpeng Li 
---
 drivers/staging/zcache/zcache-main.c |   81 +++---
 1 files changed, 75 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/zcache/zcache-main.c 
b/drivers/staging/zcache/zcache-main.c
index d73dd4b..6c35c7d 100644
--- a/drivers/staging/zcache/zcache-main.c
+++ b/drivers/staging/zcache/zcache-main.c
@@ -59,6 +59,12 @@ static inline void frontswap_tmem_exclusive_gets(bool b)
 }
 #endif
 
+/*
+ * mark pampd to special value in order that later
+ * retrieve will identify zero-filled pages
+ */
+#define ZERO_FILLED 0x2
+
 /* enable (or fix code) when Seth's patches are accepted upstream */
 #define zcache_writeback_enabled 0
 
@@ -543,7 +549,23 @@ static void *zcache_pampd_eph_create(char *data, size_t 
size, bool raw,
 {
void *pampd = NULL, *cdata = data;
unsigned clen = size;
+   bool zero_filled = false;
struct page *page = (struct page *)(data), *newpage;
+   char *user_mem;
+
+   user_mem = kmap_atomic(page);
+
+   /*
+* Compressing zero-filled pages will waste memory and introduce
+* serious fragmentation, skip it to avoid overhead
+*/
+   if (page_is_zero_filled(user_mem)) {
+   kunmap_atomic(user_mem);
+   clen = 0;
+   zero_filled = true;
+   goto got_pampd;
+   }
+   kunmap_atomic(user_mem);
 
if (!raw) {
zcache_compress(page, , );
@@ -592,6 +614,8 @@ got_pampd:
zcache_eph_zpages_max = zcache_eph_zpages;
if (ramster_enabled && raw)
ramster_count_foreign_pages(true, 1);
+   if (zero_filled)
+   pampd = (void *)ZERO_FILLED;
 out:
return pampd;
 }
@@ -601,14 +625,31 @@ static void *zcache_pampd_pers_create(char *data, size_t 
size, bool raw,
 {
void *pampd = NULL, *cdata = data;
unsigned clen = size;
+   bool zero_filled = false;
struct page *page = (struct page *)(data), *newpage;
unsigned long zbud_mean_zsize;
unsigned long curr_pers_zpages, total_zsize;
+   char *user_mem;
 
if (data == NULL) {
BUG_ON(!ramster_enabled);
goto create_pampd;
}
+
+   user_mem = kmap_atomic(page);
+
+   /*
+* Compressing zero-filled pages will waste memory and introduce
+* serious fragmentation, skip it to avoid overhead
+*/
+   if (page_is_zero_filled(page)) {
+   kunmap_atomic(user_mem);
+   clen = 0;
+   zero_filled = true;
+   goto got_pampd;
+   }
+   kunmap_atomic(user_mem);
+
curr_pers_zpages = zcache_pers_zpages;
 /* FIXME CONFIG_RAMSTER... subtract atomic remote_pers_pages here? */
if (!raw)
@@ -674,6 +715,8 @@ got_pampd:
zcache_pers_zbytes_max = zcache_pers_zbytes;
if (ramster_enabled && raw)
ramster_count_foreign_pages(false, 1);
+   if (zero_filled)
+   pampd = (void *)ZERO_FILLED;
 out:
return pampd;
 }
@@ -735,7 +778,8 @@ out:
  */
 void zcache_pampd_create_finish(void *pampd, bool eph)
 {
-   zbud_create_finish((struct zbudref *)pampd, eph);
+   if (pampd != (void *)ZERO_FILLED)
+   zbud_create_finish((struct zbudref *)pampd, eph);
 }
 
 /*
@@ -780,6 +824,14 @@ static int zcache_pampd_get_data(char *data, size_t 
*sizep, bool raw,
BUG_ON(preemptible());
BUG_ON(eph);/* fix later if shared pools get implemented */
BUG_ON(pampd_is_remote(pampd));
+
+   if (pampd == (void *)ZERO_FILLED) {
+   handle_zero_filled_page(data);
+   if (!raw)
+   *sizep = PAGE_SIZE;
+   return 0;
+   }
+
if (raw)
ret = zbud_copy_from_zbud(data, (struct zbudref *)pampd,
sizep, eph);
@@ -801,12 +853,21 @@ static int zcache_pampd_get_data_and_free(char *data, 
size_t *sizep, bool raw,
struct tmem_oid *oid, uint32_t index)
 {
int ret;
-   bool eph = !is_persistent(pool);
+   bool eph = !is_persistent(pool), zero_filled = false;
struct page *page = NULL;
unsigned int zsize, zpages;
 
BUG_ON(preemptible());
BUG_ON(pampd_is_remote(pampd));
+
+   if (pampd == (void *)ZERO_FILLED) {
+   handle_zero_filled_page(data);
+   zero_filled = true;
+   if (!raw)
+   *sizep = PAGE_SIZE;
+   goto zero_fill;
+   }
+
 

[PATCH v3 4/5] introduce zero-filled page stat count

[Wanpeng Li]

Introduce zero-filled page statistics to monitor the number of
zero-filled pages.

Acked-by: Dan Magenheimer 
Signed-off-by: Wanpeng Li 
---
 drivers/staging/zcache/zcache-main.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/zcache/zcache-main.c 
b/drivers/staging/zcache/zcache-main.c
index ef8c960..bc7ccbb 100644
--- a/drivers/staging/zcache/zcache-main.c
+++ b/drivers/staging/zcache/zcache-main.c
@@ -197,6 +197,7 @@ static ssize_t zcache_eph_nonactive_puts_ignored;
 static ssize_t zcache_pers_nonactive_puts_ignored;
 static ssize_t zcache_writtenback_pages;
 static ssize_t zcache_outstanding_writeback_pages;
+static ssize_t zcache_zero_filled_pages;
 
 #ifdef CONFIG_DEBUG_FS
 #include 
@@ -258,6 +259,7 @@ static int zcache_debugfs_init(void)
zdfs("outstanding_writeback_pages", S_IRUGO, root,
_outstanding_writeback_pages);
zdfs("writtenback_pages", S_IRUGO, root, _writtenback_pages);
+   zdfs("zero_filled_pages", S_IRUGO, root, _zero_filled_pages);
return 0;
 }
 #undef zdebugfs
@@ -327,6 +329,7 @@ void zcache_dump(void)
pr_info("zcache: outstanding_writeback_pages=%zd\n",
zcache_outstanding_writeback_pages);
pr_info("zcache: writtenback_pages=%zd\n", zcache_writtenback_pages);
+   pr_info("zcache: zero_filled_pages=%zd\n", zcache_zero_filled_pages);
 }
 #endif
 
@@ -563,6 +566,7 @@ static void *zcache_pampd_eph_create(char *data, size_t 
size, bool raw,
kunmap_atomic(user_mem);
clen = 0;
zero_filled = true;
+   zcache_zero_filled_pages++;
goto got_pampd;
}
kunmap_atomic(user_mem);
@@ -646,6 +650,7 @@ static void *zcache_pampd_pers_create(char *data, size_t 
size, bool raw,
kunmap_atomic(user_mem);
clen = 0;
zero_filled = true;
+   zcache_zero_filled_pages++;
goto got_pampd;
}
kunmap_atomic(user_mem);
@@ -867,6 +872,7 @@ static int zcache_pampd_get_data_and_free(char *data, 
size_t *sizep, bool raw,
zpages = 1;
if (!raw)
*sizep = PAGE_SIZE;
+   zcache_zero_filled_pages--;
goto zero_fill;
}
 
@@ -923,6 +929,7 @@ static void zcache_pampd_free(void *pampd, struct tmem_pool 
*pool,
zero_filled = true;
zsize = 0;
zpages = 1;
+   zcache_zero_filled_pages--;
}
 
if (pampd_is_remote(pampd) && !zero_filled) {
-- 
1.7.7.6

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

[Wanpeng Li]

Cleanup TODO list since support zero-filled pages more efficiently has 
already done by this patchset.

Acked-by: Dan Magenheimer 
Signed-off-by: Wanpeng Li 
---
 drivers/staging/zcache/TODO |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/zcache/TODO b/drivers/staging/zcache/TODO
index c1e26d4..9e755d3 100644
--- a/drivers/staging/zcache/TODO
+++ b/drivers/staging/zcache/TODO
@@ -65,5 +65,4 @@ ZCACHE FUTURE NEW FUNCTIONALITY
 
 A. Support zsmalloc as an alternative high-density allocator
 (See https://lkml.org/lkml/2013/1/23/511)
-B. Support zero-filled pages more efficiently
-C. Possibly support three zbuds per pageframe when space allows
+B. Possibly support three zbuds per pageframe when space allows
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/5] introduce zero filled pages handler

[Wanpeng Li]

Introduce zero-filled pages handler to capture and handle zero pages.

Acked-by: Dan Magenheimer 
Signed-off-by: Wanpeng Li 
---
 drivers/staging/zcache/zcache-main.c |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/zcache/zcache-main.c 
b/drivers/staging/zcache/zcache-main.c
index 328898e..d73dd4b 100644
--- a/drivers/staging/zcache/zcache-main.c
+++ b/drivers/staging/zcache/zcache-main.c
@@ -460,6 +460,32 @@ static void zcache_obj_free(struct tmem_obj *obj, struct 
tmem_pool *pool)
kmem_cache_free(zcache_obj_cache, obj);
 }
 
+static bool page_is_zero_filled(void *ptr)
+{
+   unsigned int pos;
+   unsigned long *page;
+
+   page = (unsigned long *)ptr;
+
+   for (pos = 0; pos < PAGE_SIZE / sizeof(*page); pos++) {
+   if (page[pos])
+   return false;
+   }
+
+   return true;
+}
+
+static void handle_zero_filled_page(void *page)
+{
+   void *user_mem;
+
+   user_mem = kmap_atomic(page);
+   memset(user_mem, 0, PAGE_SIZE);
+   kunmap_atomic(user_mem);
+
+   flush_dcache_page(page);
+}
+
 static struct tmem_hostops zcache_hostops = {
.obj_alloc = zcache_obj_alloc,
.obj_free = zcache_obj_free,
-- 
1.7.7.6

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

Re: [PATCHv2, RFC 13/30] thp, mm: implement grab_cache_huge_page_write_begin()

[Hillf Danton]

On Fri, Mar 15, 2013 at 1:50 AM, Kirill A. Shutemov
 wrote:
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +struct page *grab_cache_huge_page_write_begin(struct address_space *mapping,
> +   pgoff_t index, unsigned flags);
> +#else
> +static inline struct page *grab_cache_huge_page_write_begin(
> +   struct address_space *mapping, pgoff_t index, unsigned flags)
> +{
build bug?

> +   return NULL;
> +}
> +#endif
>
btw, how about grab_thp_write_begin?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] task_work: check callback if it's NULL

[li guang]

在 2013-03-15五的 09:43 +0800，Li Zefan写道：
> On 2013/3/15 9:26, li guang wrote:
> > 在 2013-03-15五的 09:01 +0800，Li Zefan写道：
> >> On 2013/3/15 8:20, li guang wrote:
> >>> 在 2013-03-14四的 15:43 +0100，Oleg Nesterov写道：
>  On 03/14, liguang wrote:
> >
> > Signed-off-by: liguang 
> > ---
> >  kernel/task_work.c |3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/task_work.c b/kernel/task_work.c
> > index 0bf4258..f458b08 100644
> > --- a/kernel/task_work.c
> > +++ b/kernel/task_work.c
> > @@ -75,7 +75,8 @@ void task_work_run(void)
> >
> > do {
> > next = work->next;
> > -   work->func(work);
> > +   if (unlikely(work->func))
> > +   work->func(work);
> 
>  Why?
> 
>  Oleg.
> 
> >>>
> >>> can we believe a callback always be call-able?
> >>> can it happened to be 0? e.g. wrong initialized.
> >>> of course, we can complain the caller, be why don't
> >>> we easily make it more safer?
> >>>
> >>
> >> Because you're not making things safer, but your're trying
> >> to cover up bugs...
> >>
> > 
> > Oh, that's a little harsh to a normal programmer like me :-)
> > for it seems you are asking me to be coding without any bug.
> > are you? or it is the theory of kernel coding?
> > 
> 
> And you make a bug, and you want the kernel to cover up the bug
> instead of crash on a null pointer deref so you'll know you've
> made a bug?
> 
> Why we check if a callback is NULL before calling it? Because
> it's allowed to be. Why we don't check if a callback is NULL?
> Because it's not supposed to be.
> 

OK, Thanks for your reminder.


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

Re: [PATCHv2, RFC 09/30] thp, mm: rewrite delete_from_page_cache() to support huge pages

[Hillf Danton]

On Fri, Mar 15, 2013 at 1:50 AM, Kirill A. Shutemov
 wrote:
> +   if (PageTransHuge(page)) {
> +   int i;
> +
> +   for (i = 0; i < HPAGE_CACHE_NR; i++)
> +   radix_tree_delete(>page_tree, page->index + 
> i);

Move the below page_cache_release for tail page here, please.

> +   nr = HPAGE_CACHE_NR;
[...]
> +   if (PageTransHuge(page))
> +   for (i = 1; i < HPAGE_CACHE_NR; i++)
> +   page_cache_release(page + i);
> page_cache_release(page);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] drm-intel-next

[Stéphane Marchesin]

On Thu, Sep 13, 2012 at 7:18 AM, Daniel Vetter  wrote:
> Hi Dave,
>
> The big ticket item here is the new i915 modeset infrastructure.
> Shockingly it didn't not blow up all over the place (i.e. I've managed to
> fix the ugly issues before merging). 1-2 smaller corner cases broke, but
> we have patches. Also, there's tons of patches on top of this that clean
> out cruft and fix a few bugs that couldn't be fixed with the crtc helper
> based stuff. So more stuff to come ;-)
>
> Also a few other things:
> - Tiny fix in the fb helper to go through the official dpms interface
>   instead of calling the crtc helper code.
> - forcewake code frobbery from Ben, code should be more in-line with
>   what Windows does now.
> - fixes for the render ring flush on hsw (Paulo)
> - gpu frequency tracepoint
> - vlv forcewake changes to better align it with our understanding of the
>   forcewake magic.
> - a few smaller cleanups
>
> Cheers, Daniel
>
>
> The following changes since commit d7c3b937bdf45f0b844400b7bf6fd3ed50bac604:
>
>   drm/i915: Remove __GFP_NO_KSWAPD (2012-08-27 17:11:38 +0200)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~danvet/drm-intel 
> tags/drm-intel-next-2012-09-09
>
> for you to fetch changes up to e04190e0ecb236c51af181c18c545ea076fb9cca:
>
>   drm/fb helper: don't call drm_helper_connector_dpms directly (2012-09-08 
> 00:51:15 +0200)
>
> 
>
> Ben Widawsky (5):
>   drm/i915: Extract forcewake ack timeout
>   drm/i915: use cpu_relax() in wait_for_atomic
>   drm/i915: Change forcewake timeout to 2ms
>   drm/i915: Never read FORCEWAKE
>   drm/i915: Enable some sysfs stuff without CONFIG_PM
>
> Chris Wilson (1):
>   drm/i915: Convert remaining debugfs iterators over rings to 
> for_each_ring()
>
> Daniel Vetter (66):
>   drm/ips: move drps/ips/ilk related variables into dev_priv->ips
>   drm/i915: add a tracepoint for gpu frequency changes
>   drm/i915: align vlv forcewake with common lore
>   drm/i915: differ error message between forcwake timeouts
>   drm/i915: add crtc->enable/disable vfuncs insted of dpms
>   drm/i915: rip out crtc prepare/commit indirection
>   drm/i915: add direct encoder disable/enable infrastructure
>   drm/i915/hdmi: convert to encoder->disable/enable
>   drm/i915/tv: convert to encoder enable/disable
>   drm/i915/lvds: convert to encoder disable/enable
>   drm/i915/dp: convert to encoder disable/enable
>   drm/i915/crt: convert to encoder disable/enable
>   drm/i915/sdvo: convert to encoder disable/enable
>   drm/i915/dvo: convert to encoder disable/enable
>   drm/i915: convert dpms functions of dvo/sdvo/crt
>   drm/i915: rip out encoder->disable/enable checks
>   drm/i915: clean up encoder_prepare/commit
>   drm/i915: copy drm_crtc_helper_set_config
>   drm/i915: call set_base directly
>   drm/i915: inline intel_best_encoder
>   drm/i915: copy drm_crtc_helper_set_mode
>   drm/i915: simplify intel_crtc_prepare_encoders
>   drm/i915: rip out encoder->prepare/commit
>   drm/i915: call crtc functions directly
>   drm/i915: WARN when trying to enabled an unused crtc
>   drm/i915: Add interfaces to read out encoder/connector hw state
>   drm/i915/dp: implement get_hw_state
>   drm/i915/hdmi: implement get_hw_state
>   drm/i915/tv: implement get_hw_state
>   drm/i915/lvds: implement get_hw_state
>   drm/i915/crt: implement get_hw_state
>   drm/i915/sdvo: implement get_hw_state
>   drm/i915/dvo: implement get_hw_state
>   drm/i915: read out the modeset hw state at load and resume time

Hi Daniel,

This commit regresses modeset on the samsung series 5 chromebook (it
is basically a pineview machine with an lvds panel). I don't seem to
be able to set any mode on it any longer.

Any idea?

Stéphane

>   drm/i915: check connector hw/sw state
>   drm/i915: rip out intel_crtc->dpms_mode
>   drm/i915: rip out intel_dp->dpms_mode
>   drm/i915: ensure the force pipe A quirk is actually followed
>   drm/i915: introduce struct intel_set_config
>   drm/i915: extract modeset config save/restore code
>   drm/i915: extract intel_set_config_compute_mode_changes
>   drm/i915: extract intel_set_config_update_output_state
>   drm/i915: implement crtc helper semantics relied upon by the fb helper
>   drm/i915: don't update the fb base if there is no fb
>   drm/i915: convert pointless error checks in set_config to BUGs
>   drm/i915: don't save all the encoder/crtc state in set_config
>   drm/i915: stage modeset output changes
>   drm/i915: push crtc->fb update into pipe_set_base
>   drm/i915: remove crtc disabling special case
>   drm/i915: move output commit and crtc disabling into set_mode
>   drm/i915: extract adjusted mode computation
>   drm/i915: use staged outuput config 

Re: [RFC PATCH] Linux kernel Wait-Free Concurrent Queue Implementation

[Mathieu Desnoyers]

* Peter Hurley (pe...@hurleysoftware.com) wrote:
> On Mon, 2013-03-11 at 17:36 -0400, Mathieu Desnoyers wrote:
> > +/*
> > + * Do not put head and tail on the same cache-line if concurrent
> > + * enqueue/dequeue are expected from many CPUs. This eliminates
> > + * false-sharing between enqueue and dequeue.
> > + */
> > +struct wfcq_head {
> > +   struct wfcq_node node;
> > +   struct mutex lock;
> > +};
> > +
> > +struct wfcq_tail {
> > +   struct wfcq_node *p;
> > +};
> 
> 
> If you want to force separate cachelines for SMP, this would be
> 
> struct wfcq_head {
>   struct wfcq_node node;
>   struct mutex lock;
> } cacheline_aligned_in_smp;
> 
> struct wfcq_tail {
>   struct wfcq_node *p;
> } cacheline_aligned_in_smp;

Well, the thing is: I don't want to force it. The queue head and tail
can be used in a few ways:

1) tail used by frequent enqueue on one CPU, head used for frequent
   dequeues on another CPU. In this case, we want head/tail on different
   cache lines.
2) same scenario as 1), but head and tail are placed in per-cpu data
   of the two CPUs. We don't need to align each structure explicitly.
3) tail and head used locally, e.g. on the stack, as splice destination
   followed by iteration or dequeue from the same CPU. We don't want to
   waste precious memory space in this case, so no alignment.

So as you see, only (1) actually requires explicit alignment of head and
tail.

Thanks,

Mathieu

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

Re: [PATCH] loop: cleanup partitions when detaching loop device

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/14/2013 06:07 PM, Andrew Morton wrote:
> huh.  What is the user-visible effect of this bug?  Just a memory
> leak or something more serious?

Not serious, but user-visible in that the partition devnodes still
show up after detaching the backing file, and I think the partitions
remained in place after attaching a new file even though it had
different or no partitions at all.

> scripts/checkpatch.pl is your friend.

Oops.  I see you pushed a patch fixing up the brace position and
breaking the long line.  Did you want me to squash it and resubmit, or
just sign off on it?  If the latter, consider it signed off.

> Can you please suggest a code comment which we can slip in here to
> tell readers what's going on and why we're doing this?

How about "Remove all partitions, since BLKRRPART won't remove user
added partitions when max_part=0"?

>> +struct disk_part_iter piter; +  struct hd_struct *part; 
>> + +
>> mutex_lock_nested(>bd_mutex, 1); +
>> invalidate_partition(bdev->bd_disk, 0); +
>> disk_part_iter_init(, bdev->bd_disk,
>> DISK_PITER_INCL_EMPTY); +while ((part =
>> disk_part_iter_next())) +  
>> delete_partition(bdev->bd_disk,
>> part->partno); + disk_part_iter_exit(); +
>> mutex_unlock(>bd_mutex); + }
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQn1XAAoJEJrBOlT6nu75QIEIAIM4skpZoKWYzAYXCK84JjP2
7Z0toyWfpQ63ku7grFPMST8wpGrsq31zcwa7zvya2Tg0ivi0vHOZmw0QBVic3mw0
Ce88iVkCDQSoASwPdHRLwNLj7Lj/cvHkwqZIHbDXR5u15v1sr3NTrCDMP33kZlPi
Z8TbX+3fTTMYriYXUOI8fmqnC+d1gj8w+fsNNAB23/mVgN6ed9uGMQqEQjXGQOnQ
By9R7dD5SZ9hqstLBSCvochBVfNjWm2rMtKTnixcY1qTDGCLWZ2sUpxns6WTjAZl
lWL/S80kt+sbpkQorXWWDZJAvyRhQny4703rwPRhzgMWPDY7qJkn465tDT4S/ic=
=3/XD
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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: Scorpion is a v7 architecture, not v6

[Stephen Boyd]

On 03/05/13 00:31, Arnd Bergmann wrote:
> On Monday 04 March 2013, Stephen Boyd wrote:
>> Scorpion processors have always been v7 CPUs. Fix the Kconfig
>> text to reflect this.
>>
>> Reported-by: Stepan Moskovchenko 
>> Signed-off-by: Stephen Boyd 
>> ---
>>  arch/arm/Kconfig |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index dedf02b..dc3bbbc 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1006,12 +1006,12 @@ config ARCH_MULTI_V4_V5
>> bool
>>  
>>  config ARCH_MULTI_V6
>> -   bool "ARMv6 based platforms (ARM11, Scorpion, ...)"
>> +   bool "ARMv6 based platforms (ARM11)"
>> select ARCH_MULTI_V6_V7
>> select CPU_V6
> Sorry about that, my fault.

Can you pick this patch up from the mailing list? Otherwise I can try to
route it through David's msm tree.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [PATCH 2/2] task_work: check callback if it's NULL

[Li Zefan]

On 2013/3/15 9:26, li guang wrote:
> 在 2013-03-15五的 09:01 +0800，Li Zefan写道：
>> On 2013/3/15 8:20, li guang wrote:
>>> 在 2013-03-14四的 15:43 +0100，Oleg Nesterov写道：
 On 03/14, liguang wrote:
>
> Signed-off-by: liguang 
> ---
>  kernel/task_work.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/task_work.c b/kernel/task_work.c
> index 0bf4258..f458b08 100644
> --- a/kernel/task_work.c
> +++ b/kernel/task_work.c
> @@ -75,7 +75,8 @@ void task_work_run(void)
>
>   do {
>   next = work->next;
> - work->func(work);
> + if (unlikely(work->func))
> + work->func(work);

 Why?

 Oleg.

>>>
>>> can we believe a callback always be call-able?
>>> can it happened to be 0? e.g. wrong initialized.
>>> of course, we can complain the caller, be why don't
>>> we easily make it more safer?
>>>
>>
>> Because you're not making things safer, but your're trying
>> to cover up bugs...
>>
> 
> Oh, that's a little harsh to a normal programmer like me :-)
> for it seems you are asking me to be coding without any bug.
> are you? or it is the theory of kernel coding?
> 

And you make a bug, and you want the kernel to cover up the bug
instead of crash on a null pointer deref so you'll know you've
made a bug?

Why we check if a callback is NULL before calling it? Because
it's allowed to be. Why we don't check if a callback is NULL?
Because it's not supposed to be.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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: dts: add usb 2.0 clock references to exynos5250 device tree

[Jingoo Han]

On Thursday, March 14, 2013 2:18 AM, Doug Anderson wrote:
> 
> This is a fixup to two device tree nodes that have already landed but
> without clock nodes since the transition to common clock happened at
> the same time.
> 
> Signed-off-by: Doug Anderson 

The clock number and name are right.

Reviewed-by: Jingoo Han 


Best regards,
Jingoo Han

> ---
>  arch/arm/boot/dts/exynos5250.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 24c52e6..59be603 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -402,12 +402,18 @@
>   compatible = "samsung,exynos4210-ehci";
>   reg = <0x1211 0x100>;
>   interrupts = <0 71 0>;
> +
> + clocks = < 285>;
> + clock-names = "usbhost";
>   };
> 
>   usb@1212 {
>   compatible = "samsung,exynos4210-ohci";
>   reg = <0x1212 0x100>;
>   interrupts = <0 71 0>;
> +
> + clocks = < 285>;
> + clock-names = "usbhost";
>   };
> 
>   amba {
> --
> 1.8.1.3

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

Re: [PATCH] regmap: Remove __attribute__ ((packed))

[Mark Brown]

On Thu, Mar 14, 2013 at 03:26:19PM +, Dimitris Papastamos wrote:
> There is no point having this.  The space gains are trivial if there
> are any at all.

Applied, but numbers would have been nice and...

> Change-Id: Ib4b1320420f780dcf5b9a1e4b05f5805691c4d9f

...this shouldn't be in upstream submissions.


signature.asc
Description: Digital signature

Re: [PATCH v2] regmap: Cut down on the average # of nodes in the rbtree cache

[Mark Brown]

On Thu, Mar 14, 2013 at 02:52:35PM +, Dimitris Papastamos wrote:

>   if (rbnode) {
>   reg_tmp = (reg - rbnode->base_reg) / map->reg_stride;
> + /* Does this register exist?  If not bail out. */
> + if (!(rbtree_ctx->reg_present[BIT_WORD(reg)] & BIT_MASK(reg)))
> + return -ENOENT;
>   *value = regcache_rbtree_get_register(map, rbnode, reg_tmp);

This means that every caller is going to need to have a check added to
see if the register is present which doesn't seem great, we should at
least have a function to do the check.  The check is fiddly enough.


signature.asc
Description: Digital signature

Re: [BUG]: when printk too more through serial, cpu up is failed.

[Shuge]

于 2013年03月14日 22:05, Greg KH 写道:

On Thu, Mar 14, 2013 at 09:51:34PM +0800, Shuge wrote:

Hi all,
 When the kernel printk too many log, the cpu is failed to come online.
The problem is this:
For example, cpu0 bring up cpu1:

   a. cpu0 call cpu_up:
  cpu_up()
  ->_cpu_up()
 ->__cpu_notify(CPU_UP_PREPARE)
 ->__cpu_up()
->boot_secondary()
#   ->wait_for_completion_timeout(_running, msecs_to_jiffires(1000))
  -> if (!cpu_online(cpu)) {
   pr_crit("CPU%u: failed to come online\n", cpu);
   ret = -EIO;
   }
  ->cpu_notify(CPU_ONLINE)

   b. cpu1 enter kernel:
   secondary_start_kernel()
@   ->printk("CPU%u: Booted secondary processor\n", cpu)
*   ->calibrate_delay()
   ->set_cpu_online()
   ->complete(cpu_running)
 ->cpumask_set_cpu()

While cpu0 run to mark #,  which wait that cpu1 complete
cpu_running, and set online.
Generally, cpu0 can get it. But if the __log_buf is too large or
other threads write
it unceasing, then cpu1 come to mark @ or * in this moment. Cpu1 is
busy outputing
buffer, which cost time more than 1s, and cpu1 have not join in
sched, so cpu0 wait it timeout.
By reading printk.c, I found that can_use_console() always return
true, which be called by
console_trylock_for_printk(). Because, have_callable_console()
return ture always, if the console
driver set CON_ANYTIME flag. I think that cpu should not output the
__log_buf in coming online,
even though have_callable_console() is true.

/*
  * Can we actually use the console at this time on this cpu?
  *
  * Console drivers may assume that per-cpu resources have
  * been allocated. So unless they're explicitly marked as
  * being able to cope (CON_ANYTIME) don't call them until
  * this CPU is officially up.
  */
static inline int can_use_console(unsigned int cpu)
{
 return cpu_online(cpu) || have_callable_console();
}

In can_use_console, why not is &&, but ||?

Kernel Version: 3.3.0

Why such an old and obsolete kernel version?  Please try this on 3.8,
lots of work have gone into the printk area that should have solved this
issue.

greg k-h


I saw the printk.c in version 3.9, it still check 
console_trylock_for_printk() to decide to call console_unlock. In 
vprintk_emit(), cpu1 also have the opportunity to execute 
console_unlock() at coming online time.
Once cpu which is coming online can output buffer, nothing can interrupt 
it until buffer is empty.But we can't ensure that none always write the 
__log_buf. It is danger! I think, the solution is that we should prevent 
to use console at coming online.

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

Re: [PATCHv2, RFC 08/30] thp, mm: rewrite add_to_page_cache_locked() to support huge pages

[Hillf Danton]

On Fri, Mar 15, 2013 at 1:50 AM, Kirill A. Shutemov
 wrote:
> +   page_cache_get(page);
> +   spin_lock_irq(>tree_lock);
> +   page->mapping = mapping;
> +   page->index = offset;
> +   error = radix_tree_insert(>page_tree, offset, page);
> +   if (unlikely(error))
> +   goto err;
> +   if (PageTransHuge(page)) {
> +   int i;
> +   for (i = 1; i < HPAGE_CACHE_NR; i++) {
struct page *tail = page + i; to easy reader

> +   page_cache_get(page + i);
s/page_cache_get/get_page_foll/ ?

> +   page[i].index = offset + i;
> +   error = radix_tree_insert(>page_tree,
> +   offset + i, page + i);
> +   if (error) {
> +   page_cache_release(page + i);
> +   break;
> +   }
> }
> -   radix_tree_preload_end();
> -   } else
> -   mem_cgroup_uncharge_cache_page(page);
> -out:
> +   if (error) {
> +   error = ENOSPC; /* no space for a huge page */
s/E/-E/

> +   for (i--; i > 0; i--) {
> +   radix_tree_delete(>page_tree,
> +   offset + i);
> +   page_cache_release(page + i);
> +   }
> +   radix_tree_delete(>page_tree, offset);
> +   goto err;
> +   }
> +   }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: Document clocks in samsung,exynos4210-ehci/ohci bindings

[Jingoo Han]

On Friday, March 15, 2013 8:01 AM, Doug Anderson wrote:
> 
> The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
> using the common clock framework.  Document it.
> 
> Signed-off-by: Doug Anderson 
> ---
>  Documentation/devicetree/bindings/usb/exynos-usb.txt | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> index f66fcdd..d557cf7 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -10,6 +10,8 @@ Required properties:
>   - reg: physical base address of the controller and length of memory mapped
> region.
>   - interrupts: interrupt number to the cpu.
> + - clocks: from common clock binding: handle to adc clock.
^^^
Is it right? I think that 'adc' can be changed to 'usb host'.


Best regards,
Jingoo Han

> + - clock-names: from common clock binding: Shall be "usbhost".
> 
>  Optional properties:
>   - samsung,vbus-gpio:  if present, specifies the GPIO that
> @@ -22,6 +24,9 @@ Example:
>   reg = <0x1211 0x100>;
>   interrupts = <0 71 0>;
>   samsung,vbus-gpio = < 6 1 3 3>;
> +
> + clocks = < 285>;
> + clock-names = "usbhost";
>   };


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

Re: [PATCH 2/2] task_work: check callback if it's NULL

[li guang]

在 2013-03-15五的 09:01 +0800，Li Zefan写道：
> On 2013/3/15 8:20, li guang wrote:
> > 在 2013-03-14四的 15:43 +0100，Oleg Nesterov写道：
> >> On 03/14, liguang wrote:
> >>>
> >>> Signed-off-by: liguang 
> >>> ---
> >>>  kernel/task_work.c |3 ++-
> >>>  1 files changed, 2 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/kernel/task_work.c b/kernel/task_work.c
> >>> index 0bf4258..f458b08 100644
> >>> --- a/kernel/task_work.c
> >>> +++ b/kernel/task_work.c
> >>> @@ -75,7 +75,8 @@ void task_work_run(void)
> >>>
> >>>   do {
> >>>   next = work->next;
> >>> - work->func(work);
> >>> + if (unlikely(work->func))
> >>> + work->func(work);
> >>
> >> Why?
> >>
> >> Oleg.
> >>
> > 
> > can we believe a callback always be call-able?
> > can it happened to be 0? e.g. wrong initialized.
> > of course, we can complain the caller, be why don't
> > we easily make it more safer?
> > 
> 
> Because you're not making things safer, but your're trying
> to cover up bugs...
> 

Oh, that's a little harsh to a normal programmer like me :-)
for it seems you are asking me to be coding without any bug.
are you? or it is the theory of kernel coding?



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

[PATCH V2 1/1] Drivers: hv: Add a new driver to support host initiated backup

[K. Y. Srinivasan]

This driver supports host initiated backup of the guest. On Windows guests,
the host can generate application consistent backups using the Windows VSS
framework. On Linux, we ensure that the backup will be file system consistent.
This driver allows the host to initiate a  "Freeze" operation on all the mounted
file systems in the guest. Once the mounted file systems in the guest are 
frozen,
the host snapshots the guest's file systems. Once this is done, the guest's file
systems are "thawed".

This driver has a user-level component (daemon) that invokes the appropriate
operation on all the mounted file systems in response to the requests from
the host. The duration for which the guest is frozen is very short - a few 
seconds.
During this interval, the diff disk is comitted.

In this version of the patch I have addressed the feedback from Olaf Herring.
Also, some of the connector related issues have been fixed.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
Cc: Evgeniy Polyakov 
---
 drivers/hv/Makefile|2 +-
 drivers/hv/hv_snapshot.c   |  287 
 drivers/hv/hv_util.c   |   10 ++
 include/linux/hyperv.h |   69 ++
 include/uapi/linux/connector.h |5 +-
 tools/hv/hv_vss_daemon.c   |  220 ++
 6 files changed, 591 insertions(+), 2 deletions(-)
 create mode 100644 drivers/hv/hv_snapshot.c
 create mode 100644 tools/hv/hv_vss_daemon.c

diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index e6abfa0..0a74b56 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -5,4 +5,4 @@ obj-$(CONFIG_HYPERV_BALLOON)+= hv_balloon.o
 hv_vmbus-y := vmbus_drv.o \
 hv.o connection.o channel.o \
 channel_mgmt.o ring_buffer.o
-hv_utils-y := hv_util.o hv_kvp.o
+hv_utils-y := hv_util.o hv_kvp.o hv_snapshot.o
diff --git a/drivers/hv/hv_snapshot.c b/drivers/hv/hv_snapshot.c
new file mode 100644
index 000..8ad5653
--- /dev/null
+++ b/drivers/hv/hv_snapshot.c
@@ -0,0 +1,287 @@
+/*
+ * An implementation of host initiated guest snapshot.
+ *
+ *
+ * Copyright (C) 2013, Microsoft, Inc.
+ * Author : K. Y. Srinivasan 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+
+/*
+ * Global state maintained for transaction that is being processed.
+ * Note that only one transaction can be active at any point in time.
+ *
+ * This state is set when we receive a request from the host; we
+ * cleanup this state when the transaction is completed - when we respond
+ * to the host with the key value.
+ */
+
+static struct {
+   bool active; /* transaction status - active or not */
+   int recv_len; /* number of bytes received. */
+   struct vmbus_channel *recv_channel; /* chn we got the request */
+   u64 recv_req_id; /* request ID. */
+   struct hv_vss_msg  *msg; /* current message */
+} vss_transaction;
+
+
+static void vss_respond_to_host(int error);
+
+static struct cb_id vss_id = { CN_VSS_IDX, CN_VSS_VAL };
+static const char vss_name[] = "vss_kernel_module";
+static __u8 *recv_buffer;
+
+static void vss_send_op(struct work_struct *dummy);
+static DECLARE_WORK(vss_send_op_work, vss_send_op);
+
+/*
+ * Callback when data is received from user mode.
+ */
+
+static void
+vss_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp)
+{
+   struct hv_vss_msg *vss_msg;
+
+   vss_msg = (struct hv_vss_msg *)msg->data;
+
+   if (vss_msg->vss_hdr.operation == VSS_OP_REGISTER) {
+   pr_info("VSS daemon registered\n");
+   vss_transaction.active = false;
+   if (vss_transaction.recv_channel != NULL)
+   hv_vss_onchannelcallback(vss_transaction.recv_channel);
+   return;
+
+   }
+   vss_respond_to_host(vss_msg->error);
+}
+
+
+static void vss_send_op(struct work_struct *dummy)
+{
+   int op = vss_transaction.msg->vss_hdr.operation;
+   struct cn_msg *msg;
+   struct hv_vss_msg *vss_msg;
+
+   msg = kzalloc(sizeof(*msg) + sizeof(*vss_msg), GFP_ATOMIC);
+   if (!msg)
+   return;
+
+   vss_msg = (struct hv_vss_msg *)msg->data;
+
+   msg->id.idx =  CN_VSS_IDX;
+   msg->id.val = CN_VSS_VAL;
+
+   vss_msg->vss_hdr.operation = op;
+   msg->len = sizeof(struct hv_vss_msg);
+
+   cn_netlink_send(msg, 0, GFP_ATOMIC);
+   kfree(msg);
+
+   return;
+}
+
+/*
+ * Send a response back to 

Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

[Al Viro]

On Thu, Mar 14, 2013 at 02:43:32PM +0100, Miklos Szeredi wrote:

> > Either way, I suggest the next step is to ask Stephen to line this up
> > in linux-next.
> 
> Al, are you okay with that?  Or do you want it to go though -vfs?

Umm...  I would prefer it to go through vfs.git, with serious modifications.
I really don't like the idea of xattr-based whiteouts, for example.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

[Bill Huang]

On Fri, 2013-03-15 at 01:54 +0800, Stephen Warren wrote:
> On 03/14/2013 03:28 AM, Bill Huang wrote:
> > On Thu, 2013-03-14 at 17:21 +0800, Peter De Schrijver wrote:
> >> On Thu, Mar 14, 2013 at 03:15:11AM +0100, Bill Huang wrote:
> >>
> >>> I don't think deferring will work either, considering the usage of DVFS,
> >>> device voltage is tightly coupled with frequency, when clock rate is
> >>> about to increase, we have to boost voltage first and we can lower the
> >>> voltage after the clock rate has decreased. All the above sequence have
> >>> to be guaranteed or you might crash, so deferring not only make thing
> >>> complicated in controlling the order but also hurt performance.
> >>
> >> But we could use notifiers in clk_prepare/clk_unprepare to set the voltage 
> >> no?
> >> As clk_prepare/clk_unprepare have to be called before clk_enable or after
> >> clk_disable, the voltage can be raised to a safe level, before the clock
> >> becomes active.
> > 
> > Thanks Peter, actually I'm just about to propose my v2 RFC which add
> > notifier in clk_prepare/clk_unprepare.
> 
> Can't clk_set_rate() be called while the clock is prepared, or even
> enabled? I don't see how your proposal would work.
> 
I think it works with just a little sacrifice on saving more power but
that's related minor. Taking clk_prepare as an indicator on that clock
will be enabled later, so we can raise the voltage to a safe level
(according to the current rate or maybe default rate when clk_prepare is
called, some time late when clk_set_rate() is called we can adjust again
according to the requested rate change) but there should be case that
clock will not be enabled after clk_prepare (I'm not sure is normal
though), that the case power might be wasted. Similarly, taking
clk_unprepare as an indicator on clock has been disabled but there might
be case clock is disabled but do not call clk_unprepare any time soon,
this is another case power is wasted but this should not be normal case.
So the point is, we can get notified on runtime clock change events (no
matter it is clock enable/disable or clock rate change) and act (get
best balance on power saving and system stability) accordingly.

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

Re: [GIT PULL] perf fixes

[Linus Torvalds]

On Thu, Mar 14, 2013 at 5:24 PM, Stephane Eranian  wrote:
>
> I bet if you force the affinity of your perf record to be on
> a CPU other than CPU0, you will not get the crash.
>
> This is what I am seeing now. I appears on resume,
> CPU0 hotplug callbacks for perf_events are not invoked
> leaving DS_AREA MSR to 0.
>
> Can you confirm on your machine?

I'm not even going to bother confirming it, because I think you're
right, and I think the reason is clear: the DS initialization code
uses the CPU_UP notifiers.

And that's sufficient for CPU hotplug, which is what suspend/resume
ends up doing for all but the boot CPU. But the boot CPU is not
hotplugged.

Using CPU_UP notifiers is wrong, and they get called too late anyway.

The code should use a real resume method. Or, better yet, just do it
right, and do it from __restore_processor_state().

Those f*cking CPU notifiers are a pain in the ass, and the tend to be
invariably broken, and they have their own idiotic hacks that are
equally broken (ie that x86_pmu_notifier() thing seems to make up its
own suspend/resume with
"x86_pmu.cpu_prepare/cpu_starting/cpu_dying/cpu_dead" things.

I guess we could make the BP do a fake cpu notifier thing around the
suspend of the boot processor as well, but most of the per-CPU stuff
seems to be perfectly fine without it (ie mtrr, apic, etc etc all use
the suspend/resume infrastructure) and doesn't need that kind of
stuff.

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

Re: [PATCH 2/2] task_work: check callback if it's NULL

[Li Zefan]

On 2013/3/15 8:20, li guang wrote:
> 在 2013-03-14四的 15:43 +0100，Oleg Nesterov写道：
>> On 03/14, liguang wrote:
>>>
>>> Signed-off-by: liguang 
>>> ---
>>>  kernel/task_work.c |3 ++-
>>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/kernel/task_work.c b/kernel/task_work.c
>>> index 0bf4258..f458b08 100644
>>> --- a/kernel/task_work.c
>>> +++ b/kernel/task_work.c
>>> @@ -75,7 +75,8 @@ void task_work_run(void)
>>>
>>> do {
>>> next = work->next;
>>> -   work->func(work);
>>> +   if (unlikely(work->func))
>>> +   work->func(work);
>>
>> Why?
>>
>> Oleg.
>>
> 
> can we believe a callback always be call-able?
> can it happened to be 0? e.g. wrong initialized.
> of course, we can complain the caller, be why don't
> we easily make it more safer?
> 

Because you're not making things safer, but your're trying
to cover up bugs...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: manual merge of the l2-mtd tree with the mtd tree

[Stephen Rothwell]

Hi Artem,

Today's linux-next merge of the l2-mtd tree got a conflict in
include/linux/mtd/nand.h between commit 5bc7c33ca93a ("mtd: nand:
reintroduce NAND_NO_READRDY as NAND_NEED_READRDY") from the mtd tree and
commit edac3311879c ("mtd: nand: remove AG-AND support") from the l2-mtd
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc include/linux/mtd/nand.h
index ef52d9c,33516eb..000
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@@ -165,35 -145,8 +145,15 @@@ typedef enum 
   */
  /* Buswidth is 16 bit */
  #define NAND_BUSWIDTH_16  0x0002
- /* Device supports partial programming without padding */
- #define NAND_NO_PADDING   0x0004
  /* Chip has cache program function */
  #define NAND_CACHEPRG 0x0008
- /* Chip has copy back function */
- #define NAND_COPYBACK 0x0010
- /*
-  * AND Chip which has 4 banks and a confusing page / block
-  * assignment. See Renesas datasheet for further information.
-  */
- #define NAND_IS_AND   0x0020
- /*
-  * Chip has a array of 4 pages which can be read without
-  * additional ready /busy waits.
-  */
- #define NAND_4PAGE_ARRAY  0x0040
- /*
-  * Chip requires that BBT is periodically rewritten to prevent
-  * bits from adjacent blocks from 'leaking' in altering data.
-  * This happens with the Renesas AG-AND chips, possibly others.
-  */
- #define BBT_AUTO_REFRESH  0x0080
 +/*
 + * Chip requires ready check on read (for auto-incremented sequential read).
 + * True only for small page devices; large page devices do not support
 + * autoincrement.
 + */
 +#define NAND_NEED_READRDY 0x0100
 +
  /* Chip does not allow subpage writes */
  #define NAND_NO_SUBPAGE_WRITE 0x0200
  


pgpJyWa9VNGMS.pgp
Description: PGP signature