Re: [PATCH] ACPI / PM: Infer parent power state from child if unknown, v2

[Aaron Lu]

On Tue, Sep 11, 2012 at 10:38:06PM +0200, Rafael J. Wysocki wrote:
> It turns out that there are ACPI BIOSes defining device objects with
> _PSx and without either _PSC or _PRx.  For devices corresponding to
> those ACPI objetcs __acpi_bus_get_power() returns ACPI_STATE_UNKNOWN
> and their initial power states are regarded as unknown as a result.
> If such a device is a parent of another power-manageable device, the
> child cannot be put into a low-power state through ACPI, because
> __acpi_bus_set_power() refuses to change power states of devices
> whose parents' power states are unknown.
> 
> To work around this problem, observe that the ACPI power state of
> a device cannot be higher-power (lower-number) than the power state
> of its parent.  Thus, if the device's _PSC method or the
> configuration of its power resources indicates that the device is
> in D0, the device's parent has to be in D0 as well.  Consequently,
> if the parent's power state is unknown when we've just learned that
> its child's power state is D0, we can safely set the parent's
> power.state field to ACPI_STATE_D0.
> 
> Signed-off-by: Rafael J. Wysocki 

Tested-by: Aaron Lu 

-Aaron

> ---
>  drivers/acpi/bus.c |   10 ++
>  1 file changed, 10 insertions(+)
> 
> Index: linux/drivers/acpi/bus.c
> ===
> --- linux.orig/drivers/acpi/bus.c
> +++ linux/drivers/acpi/bus.c
> @@ -237,6 +237,16 @@ static int __acpi_bus_get_power(struct a
>   } else if (result == ACPI_STATE_D3_HOT) {
>   result = ACPI_STATE_D3;
>   }
> +
> + /*
> +  * If we were unsure about the device parent's power state up to this
> +  * point, the fact that the device is in D0 implies that the parent has
> +  * to be in D0 too.
> +  */
> + if (device->parent && device->parent->power.state == ACPI_STATE_UNKNOWN
> + && result == ACPI_STATE_D0)
> + device->parent->power.state = ACPI_STATE_D0;
> +
>   *state = result;
>  
>   out:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 6/9] ARM: mvebu: add pinctrl device in DT for Armada 370/XP SoCs

[Thomas Petazzoni]

Le Tue, 11 Sep 2012 16:23:19 -0600,
Stephen Warren  a écrit :

> On 09/10/2012 02:39 AM, Sebastian Hesselbarth wrote:
> > From: Thomas Petazzoni 
> > 
> > The Armada 370 and XP SoCs have configurable muxing for a certain
> > number of their pins, controlled through a pinctrl driver.
> 
> Hmmm. I'd be tempted just to put the entire node definition there;
> putting in a .dtsi file just to share the reg property doesn't seem
> especially useful.

When you say "here" you're mentioning the SoC-specific .dtsi files (i.e
the ones in PATCH 7/9 and PATCH 8/9), correct?

> > The 'compatible' property is defined in the SoC-specific .dtsi files,
> > since the compatible string identifies the number of pins and other
> > SoC-specific properties.
> 
> > diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
> > b/arch/arm/boot/dts/armada-370-xp.dtsi
> 
> > +   pinctrl@d0018000 {
> 
> If this is the only pinctrl instance, you'd typically name the node just
> "pinctrl", since the "@d0018000" isn't needed to get unique node names.

Ack.

> > +   reg = <0xd0018000 0x38>;
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges;
> 
> What is "ranges" for; this isn't a memory-mapped bus, right?

Ack.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/9] pinctrl: mvebu: pinctrl driver core

[Thomas Petazzoni]

Le Tue, 11 Sep 2012 16:17:13 -0600,
Stephen Warren  a écrit :

> 
> +static struct mvebu_mpp_mode dove_mpp_modes[] = {
> + MPP_MODE(0,
> + MPP_FUNCTION(0x00, "gpio", NULL),
> + MPP_FUNCTION(0x02, "uart2", "rts"),
> + MPP_FUNCTION(0x03, "sdio0", "cd"),
> + MPP_FUNCTION(0x0f, "lcd0", "pwm"),
> + MPP_FUNCTION(0x10, "pmu", NULL)),
> 
> it's defining the functions within the context of a particular group
> ("mode" in the drivers terminology, I think...) rather than defining
> functions and groups as separate top-level tables.

This data structure really reflects what the datasheet says. Typically,
for SoCs where each pin is independently muxable (AT91, i.MX23/28,
Marvell, and probably many more), the datasheet has a big array, with
one line per pin, and then several columns which tell for a given pin,
what is "function 0", "function 1", "function 2", "function 3", etc.

So the data structure that Sebastian has implemented in the mvebu
driver immediately reflects this. In fact, the pinctrl table code for
Armada 370 and Armada XP was semi-automatically generated from CSV data
of the pinmux functions, directly coming from the datasheets. Having to
create a global list of all possible functions seems useless and
painful, since the functions only make sense in the context of one
particular pin.

Could you be more specific as to what representation you're looking
after? You're proposing to "define functions and groups as separate
top-level tables", but then how to you map which functions are
available for which group, and what is the number of that function is
this group (which we need to actually configure the mapping). I'd
really like to see (with a short code example) what is your view of how
pinmux should be handled for SoCs having independently muxable pins.

I really don't understand how a global list of functions make sense:
the functions make sense on a per-group basis, and this is how the
hardwaredatasheet defines them. If we could keep this representation,
it would really be useful.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: iwl3945: order 5 allocation during ifconfig up; vm problem?

[Johannes Berg]

On Tue, 2012-09-11 at 22:57 -0700, Marc MERLIN wrote:
> On Wed, Sep 12, 2012 at 07:16:28AM +0200, Eric Dumazet wrote:
> > On Tue, 2012-09-11 at 16:25 -0700, Andrew Morton wrote:
> > 
> > > Asking for a 256k allocation is pretty crazy - this is an operating
> > > system kernel, not a userspace application.
> > > 
> > > I'm wondering if this is due to a recent change, but I'm having trouble
> > > working out where the allocation call site is.
> > > --
> > 
> > (Adding Marc Merlin to CC, since he reported same problem)
> > 
> > Thats the firmware loading in iwlwifi driver. Not sure if it can use SG.
> > 
> > drivers/net/wireless/iwlwifi/iwl-drv.c
> > 
> > iwl_alloc_ucode() -> iwl_alloc_fw_desc() -> dma_alloc_coherent()
> > 
> > It seems some sections of /lib/firmware/iwlwifi*.ucode files are above
> > 128 Kbytes, so dma_alloc_coherent() try order-5 allocations
> 
> Thanks for looping me in, yes, this looks very familiar to me :)
> 
> In the other thread, Johannes Berg gave me this patch which is supposed to
> help: http://p.sipsolutions.net/11ea33b376a5bac5.txt

Yes, but that patch won't apply to iwlegacy as is. However, I'm pretty
sure that it should be possible to solve the issue in the same way in
iwlegacy.

johannes

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

Re: [ 92/95] NFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate

[Suresh Jayaraman]

On 09/10/2012 04:13 AM, Ben Hutchings wrote:
> 3.2-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Trond Myklebust 
> 
> Fix the following Oops in 3.5.1:
> 
>  BUG: unable to handle kernel NULL pointer dereference at 0038
>  IP: [] nfs_lookup_revalidate+0x2d/0x480 [nfs]
>  PGD 337c63067 PUD 0
>  Oops:  [#1] SMP
>  CPU 5
>  Modules linked in: nfs fscache nfsd lockd nfs_acl auth_rpcgss sunrpc 
> af_packet binfmt_misc cpufreq_conservative cpufreq_userspace 
> cpufreq_powersave dm_mod acpi_cpufreq mperf coretemp gpio_ich kvm_intel 
> joydev kvm ioatdma hid_generic igb lpc_ich i7core_edac edac_core ptp 
> serio_raw dca pcspkr i2c_i801 mfd_core sg pps_core usbhid crc32c_intel 
> microcode button autofs4 uhci_hcd ttm drm_kms_helper drm i2c_algo_bit 
> sysimgblt sysfillrect syscopyarea ehci_hcd usbcore usb_common scsi_dh_rdac 
> scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh edd fan ata_piix thermal 
> processor thermal_sys
> 
>  Pid: 30431, comm: java Not tainted 3.5.1-2-default #1 Supermicro X8DTT/X8DTT
>  RIP: 0010:[]  [] 
> nfs_lookup_revalidate+0x2d/0x480 [nfs]
>  RSP: 0018:8801b418bd38  EFLAGS: 00010292
>  RAX: fff6 RBX: 88032016d800 RCX: 0020
>  RDX:  RSI:  RDI: 8801824a7b00
>  RBP: 8801b418bdf8 R08: 7f0034323030 R09: f04c03ed
>  R10: 8801824a7b00 R11: 0002 R12: 8801824a7b00
>  R13: 8801824a7b00 R14:  R15: 8803201725d0
>  FS:  2b53a46cb700() GS:88033fc2() knlGS:
>  CS:  0010 DS:  ES:  CR0: 80050033
>  CR2: 0038 CR3: 00020a426000 CR4: 07e0
>  DR0:  DR1:  DR2: 
>  DR3:  DR6: 0ff0 DR7: 0400
>  Process java (pid: 30431, threadinfo 8801b418a000, task 8801b5d20600)
>  Stack:
>   8801b418be44 88032016d800 8801b418bdf8 
>   8801824a7b00 8801b418bdd7 8803201725d0 8116a9c0
>   8801b5c38dc0 0007 88032016d800 
>  Call Trace:
>   [] lookup_dcache+0x80/0xe0
>   [] __lookup_hash+0x23/0x90
>   [] lookup_one_len+0xc5/0x100
>   [] nfs_sillyrename+0xe3/0x210 [nfs]
>   [] vfs_unlink.part.25+0x7f/0xe0
>   [] do_unlinkat+0x1ac/0x1d0
>   [] system_call_fastpath+0x16/0x1b
>   [<2b5348b5f527>] 0x2b5348b5f526
>  Code: ec 38 b8 f6 ff ff ff 4c 89 64 24 18 4c 89 74 24 28 49 89 fc 48 89 5c 
> 24 08 48 89 6c 24 10 49 89 f6 4c 89 6c 24 20 4c 89 7c 24 30  46 38 40 0f 
> 85 d1 00 00 00 e8 c4 c4 df e0 48 8b 58 30 49 89
>  RIP  [] nfs_lookup_revalidate+0x2d/0x480 [nfs]
>   RSP 
>  CR2: 0038
>  ---[ end trace 845113ed191985dd ]---
> 
> This Oops affects 3.5 kernels and older, and is due to lookup_one_len()
> calling down to the dentry revalidation code with a NULL pointer
> to struct nameidata.

Hmm.. in this case which filesystem is calling nfs_lookup_revalidate()
with NULL nd?

A similar patch has already been NACKed by Trond as it could break NFS
exclusive creates. The discussion thread can be found here

   http://www.spinics.net/lists/linux-nfs/msg20932.html



Thanks
Suresh

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tegra tree got a conflict in
arch/arm/mach-tegra/devices.c arch/arm/mach-tegra/devices.h between
commits 2db4ddfe6e23 ("ARM: pmu: remove arm_pmu_type enumeration") from
the arm-perf tree and 1ba8216f0bc0 ("usb: move phy driver from mach-tegra
to drivers/usb") from the usb tree and commit ba07ee57d4bc ("ARM: tegra:
remove dead code") from the tegra tree.

The latter removed the files, so I did that (no action is required).

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


pgpCyd9nKJcut.pgp
Description: PGP signature

[PATCH 2/2] perf ui/browser: Fix first column printing

[Namhyung Kim]

From: Namhyung Kim 

As a side effect of commit f5951d56a2ab ("perf hists browser: Use
perf_hpp__format functions") perf report TUI got a problem of not
refreshing the first character.

Since the previous patch restores the column width of "overhead" to 7
we can start at column 0 now.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 11783170ac62..a21f40bebbac 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -605,7 +605,7 @@ static int hist_browser__show_entry(struct hist_browser 
*browser,
char s[256];
double percent;
int i, printed = 0;
-   int width = browser->b.width - 1;
+   int width = browser->b.width;
char folded_sign = ' ';
bool current_entry = ui_browser__is_current_entry(&browser->b, row);
off_t row_offset = entry->row_offset;
@@ -627,7 +627,7 @@ static int hist_browser__show_entry(struct hist_browser 
*browser,
.total_period   = browser->hists->stats.total_period,
};
 
-   ui_browser__gotorc(&browser->b, row, 1);
+   ui_browser__gotorc(&browser->b, row, 0);
 
for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
if (!perf_hpp__format[i].cond)
-- 
1.7.11.4

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

[PATCH 1/2] perf ui/hist: Fix output for 100.00%

[Namhyung Kim]

From: Namhyung Kim 

Current hpp format functions assume that the output will fit to 6
character including % sign (XX.YY%) so used "%5.2f%%" as a format
string.  However it might be the case if collapsing resulted in a
single entry which has 100.00% (7 character) of period. In this case
the output will be shifted by 1 character.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c |  2 +-
 tools/perf/ui/gtk/browser.c|  2 +-
 tools/perf/ui/hist.c   | 28 ++--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 5a5739bbe6ac..11783170ac62 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -571,7 +571,7 @@ static int hist_browser__hpp_color_ ## _name(struct 
perf_hpp *hpp,  \
 {  \
double percent = 100.0 * he->_field / hpp->total_period;\
*(double *)hpp->ptr = percent;  \
-   return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);  \
+   return scnprintf(hpp->buf, hpp->size, "%6.2f%%", percent);  \
 }
 
 HPP__COLOR_FN(overhead, period)
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 55acba6e0df4..7ff99ec1d95e 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -56,7 +56,7 @@ static int perf_gtk__hpp_color_ ## _name(struct perf_hpp 
*hpp,\
markup = perf_gtk__get_percent_color(percent);  
\
if (markup) 
\
ret += scnprintf(hpp->buf, hpp->size, "%s", markup);
\
-   ret += scnprintf(hpp->buf + ret, hpp->size - ret, "%5.2f%%", percent);  
\
+   ret += scnprintf(hpp->buf + ret, hpp->size - ret, "%6.2f%%", percent);  
\
if (markup) 
\
ret += scnprintf(hpp->buf + ret, hpp->size - ret, "");   
\

\
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 407e855cccb8..e3f8cd46e7d7 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -33,13 +33,13 @@ static int hpp__color_overhead(struct perf_hpp *hpp, struct 
hist_entry *he)
percent = 0.0;
}
 
-   return percent_color_snprintf(hpp->buf, hpp->size, "  %5.2f%%", 
percent);
+   return percent_color_snprintf(hpp->buf, hpp->size, " %6.2f%%", percent);
 }
 
 static int hpp__entry_overhead(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period / hpp->total_period;
-   const char *fmt = symbol_conf.field_sep ? "%.2f" : "  %5.2f%%";
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : " %6.2f%%";
 
if (hpp->ptr) {
struct hists *old_hists = hpp->ptr;
@@ -57,52 +57,52 @@ static int hpp__entry_overhead(struct perf_hpp *hpp, struct 
hist_entry *he)
 
 static int hpp__header_overhead_sys(struct perf_hpp *hpp)
 {
-   const char *fmt = symbol_conf.field_sep ? "%s" : "%6s";
+   const char *fmt = symbol_conf.field_sep ? "%s" : "%7s";
 
return scnprintf(hpp->buf, hpp->size, fmt, "sys");
 }
 
 static int hpp__width_overhead_sys(struct perf_hpp *hpp __maybe_unused)
 {
-   return 6;
+   return 7;
 }
 
 static int hpp__color_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period_sys / hpp->total_period;
-   return percent_color_snprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+   return percent_color_snprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
 }
 
 static int hpp__entry_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period_sys / hpp->total_period;
-   const char *fmt = symbol_conf.field_sep ? "%.2f" : "%5.2f%%";
+   const char *fmt = symbol_conf.field_sep ? "%.2f" : "%6.2f%%";
 
return scnprintf(hpp->buf, hpp->size, fmt, percent);
 }
 
 static int hpp__header_overhead_us(struct perf_hpp *hpp)
 {
-   const char *fmt = symbol_conf.field_sep ? "%s" : "%6s";
+   const char *fmt = symbol_conf.field_sep ? "%s" : "%7s";
 
return scnprintf(hpp->buf, hpp->size, fmt, "user");
 }
 
 static int hpp__width_overhead_us(struct perf_hpp *hpp __maybe_unused)
 {
-   return 6;
+   return 7;
 }
 
 static int hpp__color_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period_us / hpp->total_period;
-   return percent_color_snprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+   return percent_color_snprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
 }
 
 static int hpp__entry_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
 {
double percent = 100.0 * he->period_us

linux-next: manual merge of the tegra tree with the usb tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tegra tree got a conflict in
drivers/usb/phy/tegra_usb_phy.c between commit 1ba8216f0bc0 ("usb: move
phy driver from mach-tegra to drivers/usb") from the usb tree and commit
b0e51927b1e5 ("ARM: tegra: remove useless includes of ") from
the tegra 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 drivers/usb/phy/tegra_usb_phy.c
index 4739903,34ffebb..000
--- a/drivers/usb/phy/tegra_usb_phy.c
+++ b/drivers/usb/phy/tegra_usb_phy.c
@@@ -28,8 -30,7 +28,7 @@@
  #include 
  #include 
  #include 
- #include 
 -#include 
 +#include 
  #include 
  
  #define ULPI_VIEWPORT 0x170


pgpwoYQsrkwxm.pgp
Description: PGP signature

Re: [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp

[ABRAHAM, KISHON VIJAY]

Hi,

On Wed, Sep 12, 2012 at 3:58 AM, Paul Walmsley  wrote:
> Hi Kishon, Benoît,
>
> On Fri, 7 Sep 2012, Kishon Vijay Abraham I wrote:
>
>> Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp. Since this
>> ocp2scp module does not have any fck but does have a single opt_clock,
>> it is added as the main_clk for ocp2scp. Also removed phy_48m as the
>> optional clock since it is now made as the main clock. By this the
>> driver need not enable/disable phy_48m clk separately and
>> runtime_get/runtime_put will take care of that.
>
> Looking at this patch, it doesn't seem to make sense from a hardware point
> of view.  If you look at the OMAP4430 TRM Rev. AE, Table 23-1166 "Clocks
> and Resets", the 48MHz clock input is listed as an "Optional functional
> clock".  The main functional clock is listed as "INIT_960M_FCLK", which
> according to the same TRM, Section 3.6.3.9.1 "Overview", is an alias for
> the clock we call "dpll_usb_clkdcoldo_ck".
>
> So if any clock should be the main functional clock in the hwmod data,
> shouldn't it be dpll_usb_clkdcoldo_ck?  The goal with the hwmod data
> is/was to have it match the hardware.
>
> ...
>
> More to the point, I guess I don't see what the problem is with
> adding a few lines to the ocp2scp driver to control the "phy_48m" optional

It should be added in omap-usb2 driver rather.
> clock via the clock framework.  Is there some reason why you
> couldn't prepare & enable it after the pm_runtime_get_*(),
> and disable and unprepare it before the pm_runtime_put_*() ?

We have omap-usb2 driver that is used for both omap4 and omap5. But
this 48m clock is used only in omap4. And we dint have any *main_clk*
in the ocp2scp_usb_phy_hwmod. So in order avoid some checks in the
omap-usb2 driver, we added 48m clk as the main clock of
ocp2scp_usb_phy_hwmod.

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

Re: [PATCH] Add a page cache-backed balloon device driver.

[Rusty Russell]

Mike Waychison  writes:
> On Mon, Sep 10, 2012 at 3:59 PM, Michael S. Tsirkin  wrote:
>> On Mon, Sep 10, 2012 at 01:37:06PM -0400, Mike Waychison wrote:
>>> On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin  wrote:
>>> > On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote:
>>> >> This implementation of a virtio balloon driver uses the page cache to
>>> >> "store" pages that have been released to the host.  The communication
>>> >> (outside of target counts) is one way--the guest notifies the host when
>>> >> it adds a page to the page cache, allowing the host to madvise(2) with
>>> >> MADV_DONTNEED.  Reclaim in the guest is therefore automatic and implicit
>>> >> (via the regular page reclaim).  This means that inflating the balloon
>>> >> is similar to the existing balloon mechanism, but the deflate is
>>> >> different--it re-uses existing Linux kernel functionality to
>>> >> automatically reclaim.
>>> >>
>>> >> Signed-off-by: Frank Swiderski 
>>>
>>> Hi Michael,
>>>
>>> I'm very sorry that Frank and I have been silent on these threads.
>>> I've been out of the office and Frank has been been swamped :)
>>>
>>> I'll take a stab at answering some of your questions below, and
>>> hopefully we can end up on the same page.

Hi Mike, Frank, Michael,

Thanks for the explanation and discussion.  I like that this
implementation is more dynamic: the guest can use more pages for a while
(and the balloon kthread will furiously start trying to grab more pages
to give back).  This part is a completely reasonable implementation, and
more sophisticated that what we have.

It doesn't *quite* meet the spec, because we don't notify the host when
we pull a page from the balloon, but I think that is quite possible.  If
this is a performance waster, we should add a "SILENT_DEFLATE" feature
to tell the driver that it doesn't need to, though we should stll
support the !SILENT_DEFLATE case.

And Michael: thanks again for doing the heavy lifting on this!

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: [RFCv3] virtio_console: Add support for virtio remoteproc serial

[Rusty Russell]

sjur.brandel...@stericsson.com writes:
> I actually like this new approach better.
> It solves the issues Michael has pointed out, and we don't have to
> think through side effects of weired combination of feature bits.

Agreed.

Just one thing, should it depend on CONFIG_REMOTEPROC?  And have
OMAP_REMOTEPROC depend on CONFIG_HAS_DMA (if it doesn't already).

Thanks,
Rusty.
PS.  I've reserved 11 for you in the latest virtio spec draft.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/2] virtio_console: Add support for DMA memory allocation

[Rusty Russell]

"Michael S. Tsirkin"  writes:
>> virtio: don't crash when device is buggy
>> 
>> Because of a sanity check in virtio_dev_remove, a buggy device can crash
>> kernel.  And in case of rproc it's userspace so it's not a good idea.
>> We are unloading a driver so how bad can it be?
>> Be less aggressive in handling this error: if it's a driver bug,
>> warning once should be enough.
>> 
>> Signed-off-by: Michael S. Tsirkin 
>
> Rusty?

Thanks, applied.

I really want to implement CONFIG_VIRTIO_DEVEL_DEBUG which would
incorporate the checks in virtio_ring.c as well as this.  Then I could
also reshuffle descriptors (eg. split them) to find buggy devices like
qemu which assume the first descriptor is the struct virtio_net_hdr...

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

Re: [PATCH v2 2/2] virtio-ring: Allocate indirect buffers from cache when possible

[Rusty Russell]

Thomas Lendacky  writes:
> I ran some TCP_RR and TCP_STREAM sessions, both host-to-guest and
> guest-to-host, with a form of the histogram patch applied against a
> RHEL6.3 kernel. The histogram values were reset after each test.

Hey, thanks!  This is exactly what I wanted to see...

> 60 session TCP_RR from host-to-guest with 256 byte request and 256 byte
> response for 60 seconds:
>
> Queue histogram for virtio1:
> Size distribution for input (max=7818456):
>  1: 7818456 

These are always 1, so we don't indirect them anyway, so no cache required.

> Size distribution for output (max=7816698):
>  2: 149 
>  3: 7816698 
>  4: 2   
>  5: 1   
> Size distribution for control (max=1):
>  0: 0

OK, tiny TCP data, but latency sensitive.

> Queue histogram for virtio1:
> Size distribution for input (max=16050941):
>  1: 16050941 
> Size distribution for output (max=1877796):
>  2: 1877796 
>  3: 5   
> Size distribution for control (max=1):
>  0: 0

Acks.  Not that many, not that latency sensitive.

> 4 session TCP_STREAM from guest-to-host with 4K message size for 60 seconds:
>
> Queue histogram for virtio1:
> Size distribution for input (max=1316069):
>  1: 1316069 
> Size distribution for output (max=879213):
>  2: 24  
>  3: 24097   #
>  4: 23176   #
>  5: 3412
>  6: 4446
>  7: 4663
>  8: 4195
>  9: 3772
> 10: 3388
> 11: 3666
> 12: 2885
> 13: 2759
> 14: 2997
> 15: 3060
> 16: 2651
> 17: 2235
> 18: 92721   ##  
> 19: 879213  

Hey, that +1 is there in MAX_SKB_FRAGS for a reason!  Who knew?

This looks like we could really use a:

int vq_set_indirect_cache(struct virtqueue *vq, unsigned num);

Which networking would set on the xmit queue(s) if we have GSO.

The real question is now whether we'd want a separate indirect cache for
the 3 case (so num above should be a bitmap?), or reuse the same one, or
not use it at all?

Benchmarking will tell...

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] virtio-balloon spec: provide a version of the "silent deflate" feature that works

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> We have several options:
> 1. No memory overcommit feature. This is always the case ATM!
> 2. Do not hot-plug assigned device.
> 3. Hot-unplug assigned device.
> 4. Some assigned devices can be able to handle memory errors
>e.g. using ATS. Limit hotplug to these.

OK, let's leave it alone, and the first person to try to implement it in
a device can figure out how to fall back.

I replied on the other thread: I think a SILENT_DEFLATE option is
a future optimization.

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

Re: [PATCH 4/5] perf ui/browser: Use perf_hpp__format functions

[Namhyung Kim]

On Sat, 08 Sep 2012 23:05:43 +0900, Namhyung Kim wrote:
> On Fri, 7 Sep 2012 17:32:18 -0700, Arnaldo Carvalho de Melo wrote:
>> I folded the patch below so that we have the lines starting at column 1
>> like before, i.e. we were using " %5.2f" for the overhead and now you
>> changed it to "%5.2f".
>
> Looks good to me.

It wasn't good actually :-/  Simply because it cannot refresh the
character at column 0 anymore.  I will send a fix soon.

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

Re: [PATCH v4 00/21] OMAP UART Patches

[Felipe Balbi]

Hi,

On Tue, Sep 11, 2012 at 10:02:48PM +, Paul Walmsley wrote:
> 
> Hi Felipe
> 
> Just tested these OMAP serial changes at commit 
> e36851d0fa94b0f7802b3cc80406dbd3ef4f2f16 ("serial: omap: fix compile 
> breakage").  There's good news and bad news...
> 
> The good news is that after applying this series, the 'OMAP4 UART garbage 
> on long transmit buffers when PM is enabled' bug:
> 
> http://www.pwsan.com/omap/testlogs/test_v3.6-rc5/20120908202511/pm/4430es2panda/4430es2panda_log.txt
> 
> ... goes away.  (Unclear if it's because the underlying bug was fixed, or 
> if unrelated changes are masking it.)  Not sure what caused the problem to 
> go away exactly, but it's one of the changes between d37c6ceb and bf63a08.  
> So that's good!

I'd point the finger at sticking to put_autosuspend() as that would give
HW enough time to actually unload all bytes from its FIFO through the
UART lines. can you check if forcing the autosuspend_delay to -1
triggers the issue again ? If it does, it's some help from autosuspend,
which would mean we still have the problem and needs to be properly
fixed.

> The bad news is that N800 no longer boots -- or the UART dies during 
> serial init:
> 
> http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
> 
> The problem doesn't seem to affect the 2430SDP.
> 
> Could you put together a patch to fix N800?

I'll see what I can do. BTW, is that log with DEBUG_LL enabled ?

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory

[Minchan Kim]

On Tue, Sep 11, 2012 at 01:18:24PM +0800, Jerry wrote:
> Hi Kim,
> 
> Thank you for your kindness. Let me clarify this:
> 
> On ARM architecture, there are 32 bits physical addresses space. However,
> the addresses space is divided into 8 banks normally. Each bank
> disabled/enabled by a chip selector signal. In my platform, bank0 connects
> a DDR chip, and bank1 also connects another DDR chip. And each DDR chip
> whose capability is 512MB is integrated into the main board. So, it could
> not be removed by hand. We can disable/enable each bank by peripheral
> device controller registers.
> 
> When system enter suspend state, if all the pages allocated could be
> migrated to one bank, there are no valid data in the another bank. In this
> time, I could disable the free bank. It isn't necessary to provided power
> to this chip in the suspend state. When system resume, I just need to
> enable it again.
> 

Yes. I already know it and other trials for that a few years ago[1].
A few years ago, I investigated the benefit between power consumption
benefit during suspend VS start-up latency of resume and
power consumption cost of migration(page migration and IO write for
migration) and concluded normally the gain is not big. :)
The situation could be changed these days as workload are changing
but I'm skeptical about that approach, still.

Anyway, it's my private thought so you don't need to care about that.
If you are ready to submit the patchset, please send out.

1. http://lwn.net/Articles/478049/

Thanks.

- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] gpio: pcf857x: fixup smatch WARNING

[Linus Walleij]

On Wed, Sep 12, 2012 at 7:19 AM, Kuninori Morimoto
 wrote:

> This patch fixes it
>
> Reported-by: Fengguang Wu 
> Signed-off-by: Kuninori Morimoto 

Hey you fix things quicker than I can read my mail :-) :-)

Thanks!

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

Re: [PATCH] spi: omap2-mcspi: Cleanup the omap2_mcspi_txrx_dma function

[Shubhrajyoti]

On Wednesday 12 September 2012 08:51 AM, Mark Brown wrote:
> On Tue, Sep 11, 2012 at 12:13:20PM +0530, Shubhrajyoti D wrote:
>> > Currently in omap2_mcspi_txrx_dma the tx and the rx support is
>> > interleaved. Make the rx related code in omap2_mcspi_rx_dma
>> > and the tx related code omap2_mcspi_tx_dma and call the functions.
> I'd ideally like some testing from the OMAP side before applying this -
> is there someone who can give a Tested-by?
I have tested this patch with nfs boot with ethernet being on spi on
omap4sdp and spidev.
On omap3 sdp tested the touchscreen.

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

Re: [PATCH 1/2] writeback: add dirty_background_time per bdi variable

[Fengguang Wu]

> I will update simple table for this result in changelog in patch.

That would be good, thanks a lot for the testing!

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

Re: runtime PM and special power switches

[Dave Airlie]

On Wed, Sep 12, 2012 at 3:13 PM, Dave Airlie  wrote:
> On Wed, Sep 12, 2012 at 8:58 AM, Rafael J. Wysocki  wrote:
>> On Wednesday, September 12, 2012, Dave Airlie wrote:
>>> On Wed, Sep 12, 2012 at 7:32 AM, Alan Stern  
>>> wrote:
>>> > On Tue, 11 Sep 2012, Rafael J. Wysocki wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> On Tuesday, September 11, 2012, Dave Airlie wrote:
>>> >> > Hi Rafael,
>>> >> >
>>> >> > I've been investigating runtime PM support for some use-cases on GPUs.
>>> >> >
>>> >> > In some laptops we have a secondary GPU (optimus) that can be powered
>>> >> > up for certain 3D tasks and then turned off when finished with. Now I
>>> >> > did an initial pass on supporting it without using the kernel runtime
>>> >> > PM stuff, but Alan said I should take a look so here I am.
>>> >>
>>> >> Alan Stern or Alan Cox? :-)
>>> >>
>>> >> > While I've started to get a handle on things, we have a bit of an
>>> >> > extra that I'm not sure we cater for.
>>> >> >
>>> >> > Currently we get called from the PCI layer which after we are finished
>>> >> > with our runtime suspend callback, will go put the device into the
>>> >> > correct state etc, however on these optimus/powerxpress laptops we
>>> >> > have a separate ACPI or platform driver controlled power switch that
>>> >> > we need to call once the PCI layer is finished the job. This switch
>>> >> > effectively turns the power to the card completely off leaving it
>>> >> > drawing no power.
>>> >> >
>>> >> > No we can't hit the switch from the driver callback as the PCI layer
>>> >> > will get lost, so I'm wondering how you'd envisage we could plug this
>>> >> > in.
>>> >>
>>> >> Hmm.  In principle we might modify pci_pm_runtime_suspend() so that it
>>> >> doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is
>>> >> set.  That would actually make it work in analogy with 
>>> >> pci_pm_suspend_noirq(),
>>> >> so perhaps it's not even too dangerous.
>>> >
>>> > This sounds more like a job for a power domain.  Unless the power
>>> > switch is already in the device hierarchy as a parent to the PCI
>>> > device.
>>>
>>> I'll have to investigate power domains then,
>>>
>>> The switch is hidden in many different places, one some laptops its in
>>> a ACPI _DSM on one GPU, on others its in an ACPI _DSM on the other
>>> one, in some its in a different ACPI _DSM, then we have it in the ACPI
>>> ATPX method on others, and finally Apple have it in a piece of hw that
>>> isn't just on the LPC bus or somewhere like that.
>>>
>>> Currently we just hide it all inside vga_switcheroo and I'd just need
>>> an interface to call that once the layers have stopped poking
>>> registers in PCI config space, if we could fix PCI runtime suspend so
>>> the driver was the last to g 2et called then that would also not suck.
>>
>> Well, as I said, we may try to change the PCI layer so that it doesn't
>> access the device any more in pci_pm_runtime_suspend() if it sees that
>> pci_dev->state_saved has been set by the driver's callback.  Then,
>> your drivers would only need to set pci_dev->state_saved in their
>> .runtime_suspend() callbacks.
>>
>
> Actually it appears I'll need this, I'd forgotten things are a bit
> messier than I thought
>
> So there are two variants on the _DSM for nvidia dual-gpu machines,
> the older pre-optimus _DSM requires
> an explicit power off call post-D3, however for optimus _DSM the D3
> transition will flick the power switch, however
> the pci code then goes and seem to turn the device back to D0 for some
> reason. So yes after save state,
> I'd really appreciate if it the pci layer would stop poking my device.
>
>> Alternatively, which may be less hackish but more work, you can set the
>> pm_domain pointer in the device structure to a struct dev_pm_domain whose
>> ops will just call the corresponding bus type's ops except for
>> .runtime_suspend() that will execute the additional ACPI stuff after calling
>> the bus type's method.
>
> I've mostly written this, and it seems to work, I've jsut set a
> pm_domain in the vga switcheroo code that copies the dev->bus->pm
> into a private structure. I'll need this for the old nvidia and radeon
> poweroffs.
>


http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-opt-pwr
is my current WIP branch

http://cgit.freedesktop.org/~airlied/linux/diff/drivers/gpu/vga/vga_switcheroo.c?h=drm-opt-pwr&id=8952007a8799a5b096d64a8217e3001e2ebed2ab
contains what I've done to override the 2 pms ops we need to override
for older GPUs

http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-opt-pwr&id=005fdf5c184f9b857cbd8cb7195898d776f68670
is my current PCI workaround.

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

[PATCH] perf, tools: Stop perf stat -p when profiled process exits

[Andi Kleen]

From: Andi Kleen 

When counting a process with perf stat -p check if the process died
and exit collection if yes.

Signed-off-by: Andi Kleen 
---
 tools/perf/builtin-stat.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 861f0ae..1313bb5 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -536,7 +536,14 @@ static int run_perf_stat(int argc __used, const char 
**argv)
if (WIFSIGNALED(status))
psignal(WTERMSIG(status), argv[0]);
} else {
-   while(!done) sleep(1);
+   char piddir[40];
+   snprintf(piddir, sizeof piddir, "/proc/%d", atoi(target.pid));
+
+   while(!done) {
+   sleep(1);
+   if (target.pid && access(piddir, X_OK) < 0 && errno == 
ENOENT)
+   break;
+   }
}
 
t1 = rdclock();
-- 
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/

[v2 PATCH 2/2] netprio_cgroup: Use memcpy instead of the for-loop to copy priomap

[Srivatsa S. Bhat]

Replace the current (inefficient) for-loop with memcpy, to copy priomap.

Signed-off-by: Srivatsa S. Bhat 
---

 net/core/netprio_cgroup.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index fd339bb0..83bbd0e 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -73,7 +73,6 @@ static int extend_netdev_table(struct net_device *dev, u32 
new_len)
   ((sizeof(u32) * new_len));
struct netprio_map *new_priomap = kzalloc(new_size, GFP_KERNEL);
struct netprio_map *old_priomap;
-   int i;
 
old_priomap  = rtnl_dereference(dev->priomap);
 
@@ -82,10 +81,10 @@ static int extend_netdev_table(struct net_device *dev, u32 
new_len)
return -ENOMEM;
}
 
-   for (i = 0;
-old_priomap && (i < old_priomap->priomap_len);
-i++)
-   new_priomap->priomap[i] = old_priomap->priomap[i];
+   if (old_priomap)
+   memcpy(new_priomap->priomap, old_priomap->priomap,
+   old_priomap->priomap_len *
+   sizeof(old_priomap->priomap[0]));
 
new_priomap->priomap_len = new_len;
 

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

[v2 PATCH 1/2] netprio_cgroup: Remove update_netdev_tables() since it is unnecessary

[Srivatsa S. Bhat]

The update_netdev_tables() function appears to be unnecessary, since the
write_update_netdev_table() function will adjust the priomaps as and when
required anyway. So drop the usage of update_netdev_tables() entirely.

Signed-off-by: Srivatsa S. Bhat 
---

 net/core/netprio_cgroup.c |   32 
 1 files changed, 0 insertions(+), 32 deletions(-)

diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index c75e3f9..fd339bb0 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -109,32 +109,6 @@ static int write_update_netdev_table(struct net_device 
*dev)
return ret;
 }
 
-static int update_netdev_tables(void)
-{
-   int ret = 0;
-   struct net_device *dev;
-   u32 max_len;
-   struct netprio_map *map;
-
-   rtnl_lock();
-   max_len = atomic_read(&max_prioidx) + 1;
-   for_each_netdev(&init_net, dev) {
-   map = rtnl_dereference(dev->priomap);
-   /*
-* don't allocate priomap if we didn't
-* change net_prio.ifpriomap (map == NULL),
-* this will speed up skb_update_prio.
-*/
-   if (map && map->priomap_len < max_len) {
-   ret = extend_netdev_table(dev, max_len);
-   if (ret < 0)
-   break;
-   }
-   }
-   rtnl_unlock();
-   return ret;
-}
-
 static struct cgroup_subsys_state *cgrp_create(struct cgroup *cgrp)
 {
struct cgroup_netprio_state *cs;
@@ -153,12 +127,6 @@ static struct cgroup_subsys_state *cgrp_create(struct 
cgroup *cgrp)
goto out;
}
 
-   ret = update_netdev_tables();
-   if (ret < 0) {
-   put_prioidx(cs->prioidx);
-   goto out;
-   }
-
return &cs->css;
 out:
kfree(cs);

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

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

[Stephen Rothwell]

Hi Greg,

After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/hid/hid-sensor-hub.c: In function 'sensor_hub_probe':
drivers/hid/hid-sensor-hub.c:599:3: error: too few arguments to function 
'mfd_add_devices'

Caused by commit 401ca24fb34a ("HID: sensors: introduce sensor
framework") interacting with commit 6607bad3d763 ("mfd: core: Push
irqdomain mapping out into devices") from the mfd tree.

I have added the following merge fix patch and can carry it as necessary
(no action is required).

From: Stephen Rothwell 
Date: Wed, 12 Sep 2012 16:03:55 +1000
Subject: [PATCH] HID: sensors: fix up for mfd_add_devices() API change

Signed-off-by: Stephen Rothwell 
---
 drivers/hid/hid-sensor-hub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 34a35ba..4ac759c 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -596,7 +596,7 @@ static int sensor_hub_probe(struct hid_device *hdev,
}
}
ret = mfd_add_devices(&hdev->dev, 0, sd->hid_sensor_hub_client_devs,
-   sd->hid_sensor_client_cnt, NULL, 0);
+   sd->hid_sensor_client_cnt, NULL, 0, NULL);
if (ret < 0)
goto err_free_names;
 
-- 
1.7.10.280.gaa39

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


pgpFGpmbovyyZ.pgp
Description: PGP signature

Re: [PATCH 2/2] netprio_cgroup: Optimize the priomap copy loop slightly

[Srivatsa S. Bhat]

On 09/11/2012 05:12 PM, David Laight wrote:
>> -for (i = 0;
>> - old_priomap && (i < old_priomap->priomap_len);
>> - i++)
>> -new_priomap->priomap[i] = old_priomap->priomap[i];
>> +if (old_priomap) {
>> +old_len = old_priomap->priomap_len;
>> +
>> +for (i = 0; i < old_len; i++)
>> +new_priomap->priomap[i] = old_priomap->priomap[i];
>> +}
> 
> Or:
>   memcpy(new_priomap->priomap, old_priomap->priomap,
>   old_priomap->priomap_len * sizeof old_priomap->priomap[0]);
> 

Ah, indeed that would be better. I'll send out an updated version of the
patches. Thanks!

Regards,
Srivatsa S. Bhat

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

Re: [PATCH v3 1/9] pinctrl: mvebu: pinctrl driver core

[Linus Walleij]

On Wed, Sep 12, 2012 at 12:17 AM, Stephen Warren  wrote:

> the drivers in this patch seem to invert the data-structures a
> little - in other words, instead of defining a global list of functions,
> they define a list of groups, and for each group, list the functions
> that can be selected on to it.
>
> In turn, that probably requires the core mvebu driver to invert these
> data-structures at run-time in order to provide the data the pinctrl
> core needs. I think it'd be better to just have each SoC-specific driver
> store the data tables in the same format that the pinctrl core needs it,
> so that the mvebu pinctrl core won't have to process the data-structures
> at all.

I sort of agree, not a blocker from my side but it'll surely make the
code easier to maintain.

Else I think the culprit function needs some commenting to be
readable, and writing in plaintext what can be explained by
simpler code is not good...

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

Re: [PATCH 1/2] writeback: add dirty_background_time per bdi variable

[Namjae Jeon]

2012/9/12, Namjae Jeon :
> 2012/9/12, Fengguang Wu :
>> On Wed, Sep 12, 2012 at 08:12:40AM +0900, Namjae Jeon wrote:
>>> >>
>>> >> To be frank, no realistic NFS servers will use USB disk as backing
>>> >> storage. So that rational for reducing "initial" delays is weak.
>>> >> Continuous write performance to HDD is much more important. Do you
>>> >> have numbers for that?
>>> >
>>> > Actually, we use USB HDD and USB Flash devices at NFS server.
>>> > There can be other similar users as well. So it might be useful to
>>> > provide this tuning feature other.
>>> > As default value is zero, it is disabled by default and it should not
>>> > impact normal writeback.
>>> >
>>> > I will share large file writes test result on NFS client on USB HDD
>>> > with/without tuning with patch.
>>> Hi. Wu.
>>> I share 1GB continous write test result.
>>>
>>> -> create a 1000 MB file
>>> For continuous write - create 1 GB file
>>>
>>>  RecSize   WriteSpeed
>>> 10485760   10.47MB/sec
>>>  1048576   10.35MB/sec
>>>   524288   10.48MB/sec
>>>   262144   10.48MB/sec
>>>   131072   10.52MB/sec
>>>65536   10.56MB/sec
>>>32768   10.64MB/sec
>>>16384   10.31MB/sec
>>> 8192   10.52MB/sec
>>> 4096   10.45MB/sec
>>>
>>> I will update changelog in patch.
>>
>> Thanks! What's the server side setting
> I missed server side setting.. I set dirty_background_centisecs to 1 sec.
>> and can you give a comparison of different background writeback
>> thresholds?
> Okay, I will measure peformance per setting value of
> dirty_background_centisecs in nfs server.
>
> This is this patch's
>> target use cases, after all.
> Sure.
> Thanks.

Hi. Wu.

I shared write performance result as your suggestion.

---
dirty_background_centisecs = 0, default value
---
[NFS Server]
$ cat /sys/block/sda/bdi/dirty_background_centisecs
0
[NFS Client]
$ ./performancetest_arm 1GB_file
WRT_SZ = 1000 MB
 RecSizeWriteSpeed
104857608.44MB/sec
 10485768.48MB/sec
  5242888.37MB/sec
  2621448.16MB/sec
  1310728.48MB/sec
   655368.38MB/sec
   327688.65MB/sec
   163848.27MB/sec
81928.52MB/sec
40968.20MB/sec

---
dirty_background_centisecs = 300, i.e. 3 seconds
---
 [NFS Server]
$ echo 300 > /sys/block/sda/bdi/dirty_background_centisecs
$ cat /sys/block/sda/bdi/dirty_background_centisecs
300
[NFS Client]
$ ./performancetest_arm 1GB_file
RecSize  WriteSpeed
104857608.60MB/sec
 10485768.87MB/sec
  5242888.42MB/sec
  2621448.51MB/sec
  1310728.81MB/sec
   655369.09MB/sec
   327689.00MB/sec
   163848.80MB/sec
81928.70MB/sec
40968.63MB/sec

---
dirty_background_centisecs = 200, i.e. 2 seconds
---
[NFS Server]
$ echo 200 > /sys/block/sda/bdi/dirty_background_centisecs
$ cat /sys/block/sda/bdi/dirty_background_centisecs
200
[NFS Client]
$ ./performancetest_arm 1GB_file
RecSizeWriteSpeed
104857609.30MB/sec
 10485769.31MB/sec
  5242889.84MB/sec
  2621449.52MB/sec
  1310729.42MB/sec
   655369.76MB/sec
   327689.57MB/sec
   163849.39MB/sec
81929.40MB/sec
40969.80MB/sec

---
dirty_background_centisecs = 100, i.e. 1 second
---
[NFS Server]
$ echo 100 > /sys/block/sda/bdi/dirty_background_centisecs
$ cat /sys/block/sda/bdi/dirty_background_centisecs
100
[NFS Client]
$ ./performancetest_arm 1GB_file
RecSizeWriteSpeed
10485760   10.27MB/sec
 1048576   10.34MB/sec
  524288   10.47MB/sec
  262144   10.62MB/sec
  131072   10.55MB/sec
   65536   10.53MB/sec
   32768   10.54MB/sec
   16384   10.43MB/sec
8192   10.50MB/sec
4096   10.35MB/sec

I will update simple table for this result in changelog in patch.

Thanks.

>>
>> Thanks,
>> Fengguang
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] HID: picolcd_fb: Use flush_delayed_work instead of flush_delayed_work_sync

[Bruno Prémont]

Hi Axel,

On Wed, 12 Sep 2012 13:39:09 Axel Lin  wrote:
> Seems this is a left over of commit 4382973
> "workqueue: deprecate flush[_delayed]_work_sync()"

It is, see https://lkml.org/lkml/2012/9/6/297 for a previous patch.
This should fix itself when Linus merges Tejun's workqueue changes and
picolcd changes.

Bruno


> This fixes below build warning:
> 
>   CC [M]  drivers/hid/hid-picolcd_fb.o
> drivers/hid/hid-picolcd_fb.c: In function 'picolcd_exit_framebuffer':
> drivers/hid/hid-picolcd_fb.c:611:2: warning: 'flush_delayed_work_sync' is 
> deprecated (declared at include/linux/workqueue.h:454) 
> [-Wdeprecated-declarations]
> 
> Signed-off-by: Axel Lin 
> Cc: Tejun Heo 
> ---
>  drivers/hid/hid-picolcd_fb.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
> index 0008a51..eb00357 100644
> --- a/drivers/hid/hid-picolcd_fb.c
> +++ b/drivers/hid/hid-picolcd_fb.c
> @@ -608,7 +608,7 @@ void picolcd_exit_framebuffer(struct picolcd_data *data)
>   /* make sure there is no running update - thus that fbdata->picolcd
>* once obtained under lock is guaranteed not to get free() under
>* the feet of the deferred work */
> - flush_delayed_work_sync(&info->deferred_work);
> + flush_delayed_work(&info->deferred_work);
>  
>   data->fb_info = NULL;
>   unregister_framebuffer(info);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: iwl3945: order 5 allocation during ifconfig up; vm problem?

[Marc MERLIN]

On Wed, Sep 12, 2012 at 07:16:28AM +0200, Eric Dumazet wrote:
> On Tue, 2012-09-11 at 16:25 -0700, Andrew Morton wrote:
> 
> > Asking for a 256k allocation is pretty crazy - this is an operating
> > system kernel, not a userspace application.
> > 
> > I'm wondering if this is due to a recent change, but I'm having trouble
> > working out where the allocation call site is.
> > --
> 
> (Adding Marc Merlin to CC, since he reported same problem)
> 
> Thats the firmware loading in iwlwifi driver. Not sure if it can use SG.
> 
> drivers/net/wireless/iwlwifi/iwl-drv.c
> 
> iwl_alloc_ucode() -> iwl_alloc_fw_desc() -> dma_alloc_coherent()
> 
> It seems some sections of /lib/firmware/iwlwifi*.ucode files are above
> 128 Kbytes, so dma_alloc_coherent() try order-5 allocations

Thanks for looping me in, yes, this looks very familiar to me :)

In the other thread, Johannes Berg gave me this patch which is supposed to
help: http://p.sipsolutions.net/11ea33b376a5bac5.txt

Unfortunately due to very long work days, I haven't had the time to try it
out yet, but I will soon.

Would that help in this case too?

And to answer David Rientjes, I also have compaction on:
gandalfthegreat:~# zgrep CONFIG_COMPACTION /proc/config.gz 
CONFIG_COMPACTION=y

Full config:
http://marc.merlins.org/tmp/config-3.5.2-amd64-preempt-noide-20120731

If that helps for comparison, my thread is here:
http://www.spinics.net/lists/linux-wireless/msg96438.html

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 the thermal tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/omap-thermal/omap-thermal-common.c between commit
76f726fb24bd ("Thermal: Remove tc1/tc2 in generic thermal layer") from
the thermal tree and commit 765a1939a364 ("staging: omap-thermal: fix
polling period settings") from the staging tree.

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

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

diff --cc drivers/staging/omap-thermal/omap-thermal-common.c
index b4cd6cc,46ee0a9..000
--- a/drivers/staging/omap-thermal/omap-thermal-common.c
+++ b/drivers/staging/omap-thermal/omap-thermal-common.c
@@@ -248,7 -268,9 +270,8 @@@ int omap_thermal_expose_sensor(struct o
/* Create thermal zone */
data->omap_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, &omap_thermal_ops,
-   0, FAST_TEMP_MONITORING_RATE);
 -  1, 2, /*TODO: remove this when FW allows */
+   FAST_TEMP_MONITORING_RATE,
+   FAST_TEMP_MONITORING_RATE);
if (IS_ERR_OR_NULL(data->omap_thermal)) {
dev_err(bg_ptr->dev, "thermal zone device is NULL\n");
return PTR_ERR(data->omap_thermal);


pgpeAeqMCSxxW.pgp
Description: PGP signature

Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory

[Wen Congyang]

At 09/10/2012 09:52 PM, Vasilis Liaskovitis Wrote:
> Hi,
> 
> On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote:
>> At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote:
>>> Hi Wen,
>>>
>>> 2012/09/01 5:49, Andrew Morton wrote:
 On Tue, 28 Aug 2012 18:00:07 +0800
 we...@cn.fujitsu.com wrote:

> This patch series aims to support physical memory hot-remove.

 I doubt if many people have hardware which permits physical memory
 removal?  How would you suggest that people with regular hardware can
 test these chagnes?
>>>
>>> How do you test the patch? As Andrew says, for hot-removing memory,
>>> we need a particular hardware. I think so too. So many people may want
>>> to know how to test the patch.
>>> If we apply following patch to kvm guest, can we hot-remove memory on
>>> kvm guest?
>>>
>>> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html
>>
>> Yes, if we apply this patchset, we can test hot-remove memory on kvm guest.
>> But that patchset doesn't implement _PS3, so there is some restriction.
> 
> the following repos contain the patchset above, plus 2 more patches that add
> PS3 support to the dimm devices in qemu/seabios:
> 
> https://github.com/vliaskov/seabios/commits/memhp-v2
> https://github.com/vliaskov/qemu-kvm/commits/memhp-v2
> 
> I have not posted the PS3 patches yet in the qemu list, but will post them
> soon for v3 of the memory hotplug series. If you have issues testing, let me
> know.

Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm
device, so I think we should support SLIT in seabios. Otherwise we may meet
the following kernel messages:
[  325.016769] init_memory_mapping: [mem 0x4000-0x5fff]
[  325.018060]  [mem 0x4000-0x5fff] page 2M
[  325.019168] [ea000100-ea00011f] potential offnode 
page_structs
[  325.024172] [ea000120-ea00013f] potential offnode 
page_structs
[  325.028596]  [ea000140-ea00017f] PMD -> 
[88003500-8800353f] on node 1
[  325.031775] [ea000160-ea00017f] potential offnode 
page_structs

Do you have plan to do it?

Thanks
Wen Congyang

> 
> thanks,
> 
> - Vasilis
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: picolcd_fb: Use flush_delayed_work instead of flush_delayed_work_sync

[Axel Lin]

Seems this is a left over of commit 4382973
"workqueue: deprecate flush[_delayed]_work_sync()"

This fixes below build warning:

  CC [M]  drivers/hid/hid-picolcd_fb.o
drivers/hid/hid-picolcd_fb.c: In function 'picolcd_exit_framebuffer':
drivers/hid/hid-picolcd_fb.c:611:2: warning: 'flush_delayed_work_sync' is 
deprecated (declared at include/linux/workqueue.h:454) 
[-Wdeprecated-declarations]

Signed-off-by: Axel Lin 
Cc: Tejun Heo 
---
 drivers/hid/hid-picolcd_fb.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
index 0008a51..eb00357 100644
--- a/drivers/hid/hid-picolcd_fb.c
+++ b/drivers/hid/hid-picolcd_fb.c
@@ -608,7 +608,7 @@ void picolcd_exit_framebuffer(struct picolcd_data *data)
/* make sure there is no running update - thus that fbdata->picolcd
 * once obtained under lock is guaranteed not to get free() under
 * the feet of the deferred work */
-   flush_delayed_work_sync(&info->deferred_work);
+   flush_delayed_work(&info->deferred_work);
 
data->fb_info = NULL;
unregister_framebuffer(info);
-- 
1.7.9.5



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

Re: [GIT] Digital signature library bugfix

[Linus Torvalds]

On Wed, Sep 12, 2012 at 11:34 AM, James Morris  wrote:
>
> -   if (!err && len == hlen)
> -   err = memcmp(out2, h, hlen);
> +   if (err || len != hlen) {
> +   err = -EINVAL;
> +   goto err;
> +   }
> +
> +   err = memcmp(out2, h, hlen);
>
>  err:

Hmm. I'll pull, but this seems to drop the error return from
pkcs_1_v1_5_decode_emsa() and always replace it with -EINVAL.

Now, I didn't look, and maybe that's the only error that the decode
thing can return, but still, it looks bad.

Wouldn't it have been better to do instead

   if (err)
  goto err;
   err = -EINVAL;
   if (len != hlen)
  goto err;

and not overwrite the 'err' return with EINVAL?

 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/

linux-next: manual merge of the usb tree with the usb.current tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
drivers/usb/dwc3/gadget.c between commit f4a53c55117b ("usb: dwc3:
gadget: fix pending isoc handling") from the usb.current tree and commit
348e026fafe2 ("usb: dwc3: gadget: Fix sparse warnings") from the usb 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 drivers/usb/dwc3/gadget.c
index c2813c2b,ba444e7..000
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@@ -1091,26 -1078,10 +1082,21 @@@ static int __dwc3_gadget_ep_queue(struc
 *
 */
if (dep->flags & DWC3_EP_PENDING_REQUEST) {
-   int ret;
- 
 +  /*
 +   * If xfernotready is already elapsed and it is a case
 +   * of isoc transfer, then issue END TRANSFER, so that
 +   * you can receive xfernotready again and can have
 +   * notion of current microframe.
 +   */
 +  if (usb_endpoint_xfer_isoc(dep->endpoint.desc)) {
 +  dwc3_stop_active_transfer(dwc, dep->number);
 +  return 0;
 +  }
 +
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
-   if (ret && ret != -EBUSY) {
-   struct dwc3 *dwc = dep->dwc;
- 
+   if (ret && ret != -EBUSY)
dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
dep->name);
-   }
}
  
/*


pgpsr2z9NzNBl.pgp
Description: PGP signature

linux-next: manual merge of the usb tree with the usb.current tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
drivers/usb/musb/tusb6010.c between commit ff41aaa3b6c1 ("usb: musb:
tusb6010: fix error path in tusb_probe()") from the usb.current tree and
commit 65b3d52d02a5 ("usb: musb: add musb_ida for multi instance
support") from the usb tree.

They both updated the same goto - I used the latter (no action is
required).

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


pgpZ212e2Ga20.pgp
Description: PGP signature

hot-added cpu is not asiggned to the correct node

[Yasuaki Ishimatsu]

When I hot-added CPUs and memories simultaneously using container driver,
all the hot-added CPUs were mistakenly assigned to node0.

Accoding to my DSDT, hot-added CPUs and memorys have PXM#1. So in my system,
these devices should be assigned to node1 as follows:

--- Expected result
ls /sys/devices/system/node/node1/:
cpu16 cpu17 cpu18 cpu19 cpu20 cpu21 cpu22 cpu23 cpu24 cpu25 cpu26 cpu27
cpu28 cpu29 cpu30 cpu31 cpulist ... memory512 memory513 - 767 meminfo ...

=> hot-added CPUs and memorys are assigned to same node.
---

But in actuality, the CPUs were assigned to node0 and the memorys were assigned
to node1 as follows:

--- Actual result
ls /sys/devices/system/node/node0/:
cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13
cpu14 cpu15 cpu16 cpu17 cpu18 cpu19 cpu20 cpu21 cpu22 cpu23 cpu24 cpu25 cpu26
cpu27 cpu28 cpu29 cpu30 cpu31 cpulist ... memory1 memory2 - 255 meminfo ...

ls /sys/devices/system/node/node1/:
cpulist memory512 memory513 - 767 meminfo ...

=> hot-added CPUs are assinged to node0 and hot-added memorys are assigned to
   node1. CPUs and memorys has same PXM#. But assigned node is different.
---

In my investigation, "acpi_map_cpu2node()" causes the problem.

---
#arch/x86/kernel/acpi/boot.c"
static void __cpuinit acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
 {
 #ifdef CONFIG_ACPI_NUMA
   int nid;

   nid = acpi_get_node(handle);
   if (nid == -1 || !node_online(nid))
   return;
   set_apicid_to_node(physid, nid);
   numa_set_node(cpu, nid);
 #endif
 }
---

In my DSDT, CPUs were written ahead of memories, so CPUs were hot-added
before memories. Thus the system has memory-less-node temporarily .
In this case, "node_online()" fails. So the CPU is assigned to node 0.

When I wrote memories ahead of CPUs in DSDT, the CPUs were assigned to the
correct node. In current Linux, the CPUs were assigned to the correct node
or not depends on the order of hot-added resources in DSDT.

ACPI specification doesn't define the order of hot-added resources. So I think
the kernel should properly handle any DSDT conformable to its specification.

I'm thinking a solution about the problem, but I don't have any good idea...
Does anyone has opinion how we should treat 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/

[RFC PATCH 0/2] Add UIO device supporting dynamic memory allocation

[Damian Hobson-Garcia]

Reposting: I realized that this series should have gone out to a broader list.
My apologies to those who those who will recieve a duplicate post. 

Hello all,

I've been using this UIO driver for allocation/deallocation
of memory regions through an IOMMU via the dma-mapping API, but
it seems that it would be more generally useful for userspace drivers
to access CMA memory regions. I don't know if it's useful to try to add
this functionality into the core uio driver or not, so for now I've kept
all dynamic memory handling in the specific device driver.

The number and size of the dynamically allocatable regions is defined
statically in the device platform data, and the actually memory is
allocated and deallocated when the device is opened/closed.

Details of the dynamically allocated regions are available from sysfs in
exactly the same was as for static regions. The total number of
dynamic and static regions combined cannot exceed MAX_UIO_MAPS.

Any comments, especially with regard to exposing the dma-mapping API to
userspace in this way, would be greatly appreciated.

Damian Hobson-Garcia (2):
  Add new uio device for dynamic memory allocation
  ARM: shmobile: sh7372: Change VPU UIO to uio_dmem_genirq

 arch/arm/mach-shmobile/setup-sh7372.c |   19 +-
 drivers/uio/Kconfig   |   16 ++
 drivers/uio/Makefile  |1 +
 drivers/uio/uio_dmem_genirq.c |  356 +
 include/linux/platform_data/uio_dmem_genirq.h |   26 ++
 5 files changed, 413 insertions(+), 5 deletions(-)
 create mode 100644 drivers/uio/uio_dmem_genirq.c
 create mode 100644 include/linux/platform_data/uio_dmem_genirq.h

-- 
1.7.5.4

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

[RFC PATCH 1/2] Add new uio device for dynamic memory allocation

[Damian Hobson-Garcia]

This device extends the uio_pdrv_genirq driver to provide limited
dynamic memory allocation for UIO devices.  This allows UIO devices
to use CMA and IOMMU allocated memory regions. This driver is based
on the uio_pdrv_genirq driver and provides the same generic interrupt
handling capabilities.  Like uio_prdv_genirq,
a fixed number of memory regions, defined in the platform device's
.resources field are exported to userpace. This driver adds the ability
to export additional regions whose number and size are known at boot time,
but whose memory is not allocated until the uio device file is opened for
the first time.  When the device file is closed, the allocated memory block
is freed.  Physical (DMA) addresses for the dynamic regions are provided to
the userspace via /sys/class/uio/uioN/maps/mapM/addr in the same way as
static addresses are when the uio device file is open, when no processes
are holding the device file open, the address returned to userspace is
DMA_ERROR_CODE.

Signed-off-by: Damian Hobson-Garcia 
---
 drivers/uio/Kconfig   |   16 ++
 drivers/uio/Makefile  |1 +
 drivers/uio/uio_dmem_genirq.c |  356 +
 include/linux/platform_data/uio_dmem_genirq.h |   26 ++
 4 files changed, 399 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_dmem_genirq.c
 create mode 100644 include/linux/platform_data/uio_dmem_genirq.h

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 6f3ea9b..ee4226b 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -44,6 +44,22 @@ config UIO_PDRV_GENIRQ
 
  If you don't know what to do here, say N.
 
+config UIO_DMEM_GENIRQ
+   tristate "Userspace platform driver with generic irq and dynamic memory"
+   help
+ Platform driver for Userspace I/O devices, including generic
+ interrupt handling code. Shared interrupts are not supported.
+
+ Memory regions can be specified with the same platform device
+ resources as the UIO_PDRV drivers, but dynamic regions can also
+ be specified.
+ The number and size of these regions is static,
+ but the memory allocation is not performed until
+ the associated device file is opened. The
+ memory is freed once the uio device is closed.
+
+ If you don't know what to do here, say N.
+
 config UIO_AEC
tristate "AEC video timestamp device"
depends on PCI
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index d4dd9a5..b354c53 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_UIO)   += uio.o
 obj-$(CONFIG_UIO_CIF)  += uio_cif.o
 obj-$(CONFIG_UIO_PDRV) += uio_pdrv.o
 obj-$(CONFIG_UIO_PDRV_GENIRQ)  += uio_pdrv_genirq.o
+obj-$(CONFIG_UIO_DMEM_GENIRQ)  += uio_dmem_genirq.o
 obj-$(CONFIG_UIO_AEC)  += uio_aec.o
 obj-$(CONFIG_UIO_SERCOS3)  += uio_sercos3.o
 obj-$(CONFIG_UIO_PCI_GENERIC)  += uio_pci_generic.o
diff --git a/drivers/uio/uio_dmem_genirq.c b/drivers/uio/uio_dmem_genirq.c
new file mode 100644
index 000..ef3e0fd
--- /dev/null
+++ b/drivers/uio/uio_dmem_genirq.c
@@ -0,0 +1,354 @@
+/*
+ * drivers/uio/uio_dmem_genirq.c
+ *
+ * Userspace I/O platform driver with generic IRQ handling code.
+ *
+ * Copyright (C) 2012 Damian Hobson-Garcia
+ *
+ * Based on uio_pdrv_genirq.c by Magnus Damm
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "uio_dmem_genirq"
+
+struct uio_dmem_genirq_platdata {
+   struct uio_info *uioinfo;
+   spinlock_t lock;
+   unsigned long flags;
+   struct platform_device *pdev;
+   unsigned int dmem_region_start;
+   unsigned int num_dmem_regions;
+   struct mutex alloc_lock;
+   unsigned int refcnt;
+};
+
+static int uio_dmem_genirq_open(struct uio_info *info, struct inode *inode)
+{
+   struct uio_dmem_genirq_platdata *priv = info->priv;
+   struct uio_mem *uiomem;
+   int ret = 0;
+
+   uiomem = &priv->uioinfo->mem[priv->dmem_region_start];
+
+   mutex_lock(&priv->alloc_lock);
+   while (!priv->refcnt && uiomem < &priv->uioinfo->mem[MAX_UIO_MAPS]) {
+   void *addr;
+   if (!uiomem->size)
+   break;
+
+   addr = dma_alloc_coherent(&priv->pdev->dev, uiomem->size,
+   (dma_addr_t *)&uiomem->addr, GFP_KERNEL);
+   if (!addr) {
+   ret = -ENOMEM;
+   break;
+   }
+
+   uiomem->internal_addr = addr;
+   ++uiomem;
+   }
+   priv->refcnt++;
+
+   mutex_unlock(&priv->alloc_lock);
+   /* Wa

[RFC PATCH 2/2] ARM: shmobile: sh7372: Change VPU UIO to uio_dmem_genirq

[Damian Hobson-Garcia]

This allows the VPU memory to be allocated dynamically only when it
is needed.

Signed-off-by: Damian Hobson-Garcia 
---
 arch/arm/mach-shmobile/setup-sh7372.c |   19 ++-
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-sh7372.c 
b/arch/arm/mach-shmobile/setup-sh7372.c
index 1106b4f..fe75701 100644
--- a/arch/arm/mach-shmobile/setup-sh7372.c
+++ b/arch/arm/mach-shmobile/setup-sh7372.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -761,11 +762,19 @@ static struct platform_device usb_dma1_device = {
},
 };
 
+static unsigned int region_sizes[] = {
+   (32 << 20),
+};
+
 /* VPU */
-static struct uio_info vpu_platform_data = {
-   .name = "VPU5HG",
-   .version = "0",
-   .irq = intcs_evt2irq(0x980),
+static struct uio_dmem_genirq_pdata vpu_platform_data = {
+   .uioinfo = {
+   .name = "VPU5HG",
+   .version = "0",
+   .irq = intcs_evt2irq(0x980),
+   },
+   .dynamic_region_sizes   = region_sizes,
+   .num_dynamic_regions= ARRAY_SIZE(region_sizes),
 };
 
 static struct resource vpu_resources[] = {
@@ -778,7 +787,7 @@ static struct resource vpu_resources[] = {
 };
 
 static struct platform_device vpu_device = {
-   .name   = "uio_pdrv_genirq",
+   .name   = "uio_dmem_genirq",
.id = 0,
.dev = {
.platform_data  = &vpu_platform_data,
-- 
1.7.5.4

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

Iptables log-level does not work with kernel 3.6-rc

[auto75914331]

This rule

$IPTABLES -A RULE_0_in  -j LOG  --log-level notice --log-prefix "DENY  in: "


result with linux 3.6-rc5

Sep 12 06:37:29 x kernel: <5>DENY  in: IN=eth0 OUT= MAC=...


result with linux 3.5.3 and older:

Sep  9 10:43:01 x kernel: DENY  in: IN=eth0 OUT= MAC..


Thanks

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

[PATCH] gpio: pcf857x: fixup smatch WARNING

[Kuninori Morimoto]

6e20a0a429bd4dc07d6de16d9c247270e04e4aa0
(gpio: pcf857x: enable gpio_to_irq() support)
added new smatch warnings

drivers/gpio/gpio-pcf857x.c:288 pcf857x_probe() error: we previously \
assumed 'pdata' could be null (see line 277)
drivers/gpio/gpio-pcf857x.c:364 pcf857x_probe() warn: variable dereferenced\
 before check 'pdata' (see line 292)
drivers/gpio/gpio-pcf857x.c:421 pcf857x_remove() error: we previously\
 assumed 'pdata' could be null (see line 410)

This patch fixes it

Reported-by: Fengguang Wu 
Signed-off-by: Kuninori Morimoto 
---
 drivers/gpio/gpio-pcf857x.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 12e3e48..16af35c 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -285,7 +285,7 @@ static int pcf857x_probe(struct i2c_client *client,
gpio->chip.ngpio= id->driver_data;
 
/* enable gpio_to_irq() if platform has settings */
-   if (pdata->irq) {
+   if (pdata && pdata->irq) {
status = pcf857x_irq_domain_init(gpio, pdata, &client->dev);
if (status < 0) {
dev_err(&client->dev, "irq_domain init failed\n");
@@ -394,7 +394,7 @@ fail:
dev_dbg(&client->dev, "probe error %d for '%s'\n",
status, client->name);
 
-   if (pdata->irq)
+   if (pdata && pdata->irq)
pcf857x_irq_domain_cleanup(gpio);
 
kfree(gpio);
@@ -418,7 +418,7 @@ static int pcf857x_remove(struct i2c_client *client)
}
}
 
-   if (pdata->irq)
+   if (pdata && pdata->irq)
pcf857x_irq_domain_cleanup(gpio);
 
status = gpiochip_remove(&gpio->chip);
-- 
1.7.9.5

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

Re: iwl3945: order 5 allocation during ifconfig up; vm problem?

[Eric Dumazet]

On Tue, 2012-09-11 at 16:25 -0700, Andrew Morton wrote:

> Asking for a 256k allocation is pretty crazy - this is an operating
> system kernel, not a userspace application.
> 
> I'm wondering if this is due to a recent change, but I'm having trouble
> working out where the allocation call site is.
> --

(Adding Marc Merlin to CC, since he reported same problem)

Thats the firmware loading in iwlwifi driver. Not sure if it can use SG.

drivers/net/wireless/iwlwifi/iwl-drv.c

iwl_alloc_ucode() -> iwl_alloc_fw_desc() -> dma_alloc_coherent()

It seems some sections of /lib/firmware/iwlwifi*.ucode files are above
128 Kbytes, so dma_alloc_coherent() try order-5 allocations


# ls -l /lib/firmware/iwlwifi*.ucode
-rw-r--r-- 1 root root 335056 2012-01-23 18:20 
/lib/firmware/iwlwifi-1000-3.ucode
-rw-r--r-- 1 root root 337520 2012-01-23 18:20 
/lib/firmware/iwlwifi-1000-5.ucode
-rw-r--r-- 1 root root 689680 2012-01-24 19:18 /lib/firmware/iwlwifi-105-6.ucode
-rw-r--r-- 1 root root 701228 2012-01-24 19:18 /lib/firmware/iwlwifi-135-6.ucode
-rw-r--r-- 1 root root 695876 2012-01-24 19:19 
/lib/firmware/iwlwifi-2000-6.ucode
-rw-r--r-- 1 root root 707392 2012-01-24 19:19 
/lib/firmware/iwlwifi-2030-6.ucode
-rw-r--r-- 1 root root 150100 2012-01-23 18:20 
/lib/firmware/iwlwifi-3945-2.ucode
-rw-r--r-- 1 root root 187972 2012-01-23 18:20 
/lib/firmware/iwlwifi-4965-2.ucode
-rw-r--r-- 1 root root 345008 2012-01-23 18:20 
/lib/firmware/iwlwifi-5000-1.ucode
-rw-r--r-- 1 root root 353240 2012-01-23 18:20 
/lib/firmware/iwlwifi-5000-2.ucode
-rw-r--r-- 1 root root 340696 2012-01-23 18:21 
/lib/firmware/iwlwifi-5000-5.ucode
-rw-r--r-- 1 root root 337400 2012-01-23 18:20 
/lib/firmware/iwlwifi-5150-2.ucode
-rw-r--r-- 1 root root 462280 2012-01-24 19:20 
/lib/firmware/iwlwifi-6000-4.ucode
-rw-r--r-- 1 root root 444128 2012-01-24 19:20 
/lib/firmware/iwlwifi-6000g2a-5.ucode
-rw-r--r-- 1 root root 460912 2012-01-24 19:20 
/lib/firmware/iwlwifi-6000g2b-5.ucode
-rw-r--r-- 1 root root 679436 2012-01-24 19:19 
/lib/firmware/iwlwifi-6000g2b-6.ucode
-rw-r--r-- 1 root root 463692 2012-01-23 18:20 
/lib/firmware/iwlwifi-6050-4.ucode
-rw-r--r-- 1 root root 469780 2012-01-23 18:20 
/lib/firmware/iwlwifi-6050-5.ucode


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

Re: runtime PM and special power switches

[Dave Airlie]

On Wed, Sep 12, 2012 at 8:58 AM, Rafael J. Wysocki  wrote:
> On Wednesday, September 12, 2012, Dave Airlie wrote:
>> On Wed, Sep 12, 2012 at 7:32 AM, Alan Stern  
>> wrote:
>> > On Tue, 11 Sep 2012, Rafael J. Wysocki wrote:
>> >
>> >> Hi,
>> >>
>> >> On Tuesday, September 11, 2012, Dave Airlie wrote:
>> >> > Hi Rafael,
>> >> >
>> >> > I've been investigating runtime PM support for some use-cases on GPUs.
>> >> >
>> >> > In some laptops we have a secondary GPU (optimus) that can be powered
>> >> > up for certain 3D tasks and then turned off when finished with. Now I
>> >> > did an initial pass on supporting it without using the kernel runtime
>> >> > PM stuff, but Alan said I should take a look so here I am.
>> >>
>> >> Alan Stern or Alan Cox? :-)
>> >>
>> >> > While I've started to get a handle on things, we have a bit of an
>> >> > extra that I'm not sure we cater for.
>> >> >
>> >> > Currently we get called from the PCI layer which after we are finished
>> >> > with our runtime suspend callback, will go put the device into the
>> >> > correct state etc, however on these optimus/powerxpress laptops we
>> >> > have a separate ACPI or platform driver controlled power switch that
>> >> > we need to call once the PCI layer is finished the job. This switch
>> >> > effectively turns the power to the card completely off leaving it
>> >> > drawing no power.
>> >> >
>> >> > No we can't hit the switch from the driver callback as the PCI layer
>> >> > will get lost, so I'm wondering how you'd envisage we could plug this
>> >> > in.
>> >>
>> >> Hmm.  In principle we might modify pci_pm_runtime_suspend() so that it
>> >> doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is
>> >> set.  That would actually make it work in analogy with 
>> >> pci_pm_suspend_noirq(),
>> >> so perhaps it's not even too dangerous.
>> >
>> > This sounds more like a job for a power domain.  Unless the power
>> > switch is already in the device hierarchy as a parent to the PCI
>> > device.
>>
>> I'll have to investigate power domains then,
>>
>> The switch is hidden in many different places, one some laptops its in
>> a ACPI _DSM on one GPU, on others its in an ACPI _DSM on the other
>> one, in some its in a different ACPI _DSM, then we have it in the ACPI
>> ATPX method on others, and finally Apple have it in a piece of hw that
>> isn't just on the LPC bus or somewhere like that.
>>
>> Currently we just hide it all inside vga_switcheroo and I'd just need
>> an interface to call that once the layers have stopped poking
>> registers in PCI config space, if we could fix PCI runtime suspend so
>> the driver was the last to g 2et called then that would also not suck.
>
> Well, as I said, we may try to change the PCI layer so that it doesn't
> access the device any more in pci_pm_runtime_suspend() if it sees that
> pci_dev->state_saved has been set by the driver's callback.  Then,
> your drivers would only need to set pci_dev->state_saved in their
> .runtime_suspend() callbacks.
>

Actually it appears I'll need this, I'd forgotten things are a bit
messier than I thought

So there are two variants on the _DSM for nvidia dual-gpu machines,
the older pre-optimus _DSM requires
an explicit power off call post-D3, however for optimus _DSM the D3
transition will flick the power switch, however
the pci code then goes and seem to turn the device back to D0 for some
reason. So yes after save state,
I'd really appreciate if it the pci layer would stop poking my device.

> Alternatively, which may be less hackish but more work, you can set the
> pm_domain pointer in the device structure to a struct dev_pm_domain whose
> ops will just call the corresponding bus type's ops except for
> .runtime_suspend() that will execute the additional ACPI stuff after calling
> the bus type's method.

I've mostly written this, and it seems to work, I've jsut set a
pm_domain in the vga switcheroo code that copies the dev->bus->pm
into a private structure. I'll need this for the old nvidia and radeon
poweroffs.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] fs: prevent double-free on an error path in core dumper

[Cong Wang]

On Tue, 2012-09-11 at 17:59 +0200, Oleg Nesterov wrote:
> But, again, the caller does free_note_info(), so why
> elf_note_info_init()
> tries to handle the kmalloc failures? Afaics, we can simplify the code
> and fix the bug.
> 
> What do you think about the patch below? 

Looks reasonable and neat. :)


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

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
drivers/video/omap2/displays/panel-taal.c between commit 5e56ad44b4d2
("OMAPDSS: Taal: use devm_* functions") from the omap_dss2 tree and
commit 203b42f73174 ("workqueue: make deferrable delayed_work initializer
names consistent") from the workqueues 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 drivers/video/omap2/displays/panel-taal.c
index 4cf9416,6b5e6e0..000
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@@ -925,50 -900,29 +925,50 @@@ static int taal_probe(struct omap_dss_d
  
atomic_set(&td->do_update, 0);
  
 -  td->workqueue = create_singlethread_workqueue("taal_esd");
 -  if (td->workqueue == NULL) {
 -  dev_err(&dssdev->dev, "can't create ESD workqueue\n");
 -  r = -ENOMEM;
 -  goto err_wq;
 +  if (gpio_is_valid(td->reset_gpio)) {
 +  r = devm_gpio_request_one(&dssdev->dev, td->reset_gpio,
 +  GPIOF_OUT_INIT_LOW, "taal rst");
 +  if (r) {
 +  dev_err(&dssdev->dev, "failed to request reset gpio\n");
 +  return r;
 +  }
}
 -  INIT_DEFERRABLE_WORK(&td->esd_work, taal_esd_work);
 -  INIT_DELAYED_WORK(&td->ulps_work, taal_ulps_work);
  
 -  dev_set_drvdata(&dssdev->dev, td);
 +  if (gpio_is_valid(td->ext_te_gpio)) {
 +  r = devm_gpio_request_one(&dssdev->dev, td->ext_te_gpio,
 +  GPIOF_IN, "taal irq");
 +  if (r) {
 +  dev_err(&dssdev->dev, "GPIO request failed\n");
 +  return r;
 +  }
 +
 +  r = devm_request_irq(&dssdev->dev, gpio_to_irq(td->ext_te_gpio),
 +  taal_te_isr,
 +  IRQF_TRIGGER_RISING,
 +  "taal vsync", dssdev);
  
 -  if (gpio_is_valid(panel_data->reset_gpio)) {
 -  r = gpio_request_one(panel_data->reset_gpio, GPIOF_OUT_INIT_LOW,
 -  "taal rst");
if (r) {
 -  dev_err(&dssdev->dev, "failed to request reset gpio\n");
 -  goto err_rst_gpio;
 +  dev_err(&dssdev->dev, "IRQ request failed\n");
 +  return r;
}
 +
-   INIT_DELAYED_WORK_DEFERRABLE(&td->te_timeout_work,
++  INIT_DEFERRABLE_WORK(&td->te_timeout_work,
 +  taal_te_timeout_work_callback);
 +
 +  dev_dbg(&dssdev->dev, "Using GPIO TE\n");
}
  
 +  td->workqueue = create_singlethread_workqueue("taal_esd");
 +  if (td->workqueue == NULL) {
 +  dev_err(&dssdev->dev, "can't create ESD workqueue\n");
 +  return -ENOMEM;
 +  }
-   INIT_DELAYED_WORK_DEFERRABLE(&td->esd_work, taal_esd_work);
++  INIT_DEFERRABLE_WORK(&td->esd_work, taal_esd_work);
 +  INIT_DELAYED_WORK(&td->ulps_work, taal_ulps_work);
 +
taal_hw_reset(dssdev);
  
 -  if (panel_data->use_dsi_backlight) {
 +  if (td->use_dsi_backlight) {
memset(&props, 0, sizeof(struct backlight_properties));
props.max_brightness = 255;
  


pgpxXH3esAERV.pgp
Description: PGP signature

[PATCH] kbuild: setlocalversion: ignore private tags while reporting local version

[Tushar Behera]

The output 'git describe' is relative to the immediate preceding tag.
When the immediate tag preceding the HEAD is a private tag,
setlocalversion extracts information with respect to the private tag and
wrongly reports them with respect to Linux tag.

Fixing this to extract information with respect to Linux tags.

CC: Michal Marek 
Signed-off-by: Tushar Behera 
---
 scripts/setlocalversion |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index bd6dca8..d2c857c 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -57,7 +57,8 @@ scm_version()
fi
# If we are past a tagged commit (like
# "v2.6.30-rc5-302-g72357d5"), we pretty print it.
-   if atag="`git describe 2>/dev/null`"; then
+   # Also match linux tags pattern to discard private tags
+   if atag="`git describe --match v[2-9].* 2>/dev/null`"; 
then
echo "$atag" | awk -F- '{printf("-%05d-%s", 
$(NF-1),$(NF))}'
 
# If we don't have a tag at all we print -g{commitish}.
-- 
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/

[3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e)

[Fengguang Wu]

Hi,

3 of my test boxes running v3.5 kernel become unaccessible and I find
two of them kept emitting this dmesg:

vmx_handle_exit: unexpected, valid vectoring info (0x8b0e) and exit reason 
is 0x31

The other one has froze and the above lines are the last dmesg.
Any ideas?

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] tty/serial/kgdboc: Add and wire up clear_irqs callback

[Colin Cross]

On Tue, Sep 11, 2012 at 9:06 PM, Anton Vorontsov
 wrote:
> On Tue, Sep 11, 2012 at 08:42:46PM -0700, Colin Cross wrote:
> [...]
>> > The "problem" is in the last step. If we exit NMI without making UART
>> > know that we're done with the interrupt, we will reenter the NMI
>> > immediately, even without any new characters from the UART.
>>
>> The UART irq line should go low when you read the character out of the
>
> Probably some controllers may lower the line by themselves, but not
> all, and probably most of them need an explicit clear.

Anything 8250-based will clear the interrupt automatically, assuming
you read the status registers as well as the character register.

>> receive buffer, or the polling rx function should clear the interrupt
>> for you.
>
> Yes, that's an option. But that way we add a new semantic for the
> polling routines, and effecitvely we just merge the two callbacks.
>
> Of course, if Alan is OK with this, I'm more than OK too. :-)
>
> (But the polling routines would need to clear all interrupts, not
> just rx/tx. For example, if the controller indicated some error, and
> nobody clears it, then we'll start reentering infinitely.)

For exynos5, the only non-8250 based serial port I've come across, we
clear all interrupts in the rx poll function (see
https://android.googlesource.com/kernel/exynos/+/ef427aafffb7153dde59745e440fd7ec41ea969d/arch/arm/mach-exynos/exynos_fiq_debugger.c).

>> If you use a clear_irqs callback, you can drop characters if
>> one arrives between the last character buffer read and calling
>> clear_irqs.
>
> Only if we call clear_irqs() after reading the characters, but we do
> it before. So if new characters are available, we will reenter NMI,
> which is OK.
>
> But if used incorrectly, it truly can cause dropping (or staling) of
> characters, so I'd better add some comments about this.

What does clear_irqs() mean for a status or tx interrupt?  The tx
interrupt will generally re-assert as long as the tx fifo is empty,
which would require disabling it.  On 8250 ports, status interrupts
will re-assert until the corresponding status register is read.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kvm/i8259.c between commit 749c59fd15b2 ("KVM: PIC: fix use of
uninitialised variable") from Linus' tree and commit ec798660cf72 ("KVM:
cleanup pic reset") from the kvm tree.

The latter removed the code fixed by the former, so I just did that (no
action is required).

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


pgpYQdfTy9k4Z.pgp
Description: PGP signature

Re: Storage related regression in linux-next 20120824

[Zheng Liu]

On Sun, Sep 09, 2012 at 04:50:47PM -0400, Jeff Garzik wrote:
> On 09/09/2012 04:36 PM, Hugh Dickins wrote:
> >On Sun, Sep 9, 2012 at 1:28 PM, Jeff Garzik  wrote:
> >>I'll send Linus a patch to disable.
> >
> >Thanks, but no, the change in question hasn't reached Linus yet, it's
> >just a linux-next or mmotm thing - isn't it?
> 
> Yep, libata-dev#upstream.  Sorry, got my own branches confused for a
> second there.

Sorry for delay reply.  In our product system, we tested a lot of
different brands of SATA disks, and it is OK after fua is enabled on
default.  Certainly we can't test all disks. :-(

So I think we quite have to revert my patch now, and try to fix the
current problem.

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

Re: [Resend][PATCH V3] trace,x86: add x86 irq vector tracepoints

[H. Peter Anvin]

On 09/11/2012 05:00 PM, Seiji Aguchi wrote:

Thomas,

Please review my patch as we talked in Plumbers.



Is there any measurable latency added here?  These are some of the most 
performance- (or at least latency-)critical paths in the kernel.


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

Re: [PATCH 1/2] module: add syscall to load module from fd

[H. Peter Anvin]

On 09/06/2012 11:13 AM, Kees Cook wrote:

Instead of (or in addition to) kernel module signing, being able to reason
about the origin of a kernel module would be valuable in situations
where an OS already trusts a specific file system, file, etc, due to
things like security labels or an existing root of trust to a partition
through things like dm-verity.

This introduces a new syscall (currently only on x86), similar to
init_module, that has only two arguments. The first argument is used as
a file descriptor to the module and the second argument is a pointer to
the NULL terminated string of module arguments.



Please use the standard naming convention, which is an f- prefix (i.e. 
finit_module()).


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] tty/serial/kgdboc: Add and wire up clear_irqs callback

[Anton Vorontsov]

On Tue, Sep 11, 2012 at 08:42:46PM -0700, Colin Cross wrote:
[...]
> > The "problem" is in the last step. If we exit NMI without making UART
> > know that we're done with the interrupt, we will reenter the NMI
> > immediately, even without any new characters from the UART.
> 
> The UART irq line should go low when you read the character out of the

Probably some controllers may lower the line by themselves, but not
all, and probably most of them need an explicit clear.

> receive buffer, or the polling rx function should clear the interrupt
> for you.

Yes, that's an option. But that way we add a new semantic for the
polling routines, and effecitvely we just merge the two callbacks.

Of course, if Alan is OK with this, I'm more than OK too. :-)

(But the polling routines would need to clear all interrupts, not
just rx/tx. For example, if the controller indicated some error, and
nobody clears it, then we'll start reentering infinitely.)

> If you use a clear_irqs callback, you can drop characters if
> one arrives between the last character buffer read and calling
> clear_irqs.

Only if we call clear_irqs() after reading the characters, but we do
it before. So if new characters are available, we will reenter NMI,
which is OK.

But if used incorrectly, it truly can cause dropping (or staling) of
characters, so I'd better add some comments about this.

Thanks!

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

Re: [PATCH 1/3] tracing,x86: add a TSC trace_clock; reset buffer on clock change

[Steven Rostedt]

On Tue, 2012-09-11 at 19:41 -0700, David Sharp wrote:
> In order to promote interoperability between userspace tracers and ftrace,
> add a trace_clock that reports raw TSC values which will then be recorded
> in the ring buffer. Userspace tracers that also record TSCs are then on
> exactly the same time base as the kernel and events can be unambiguously
> interlaced.
> 
> Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large
> timestamp values.
> 
> Google-Bug-Id: 6980623
> Signed-off-by: David Sharp 
> ---
>  include/linux/trace_clock.h |3 +++
>  kernel/trace/trace.c|3 +++
>  kernel/trace/trace_clock.c  |   16 
>  3 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/trace_clock.h b/include/linux/trace_clock.h
> index 4eb4902..b86c7363 100644
> --- a/include/linux/trace_clock.h
> +++ b/include/linux/trace_clock.h
> @@ -16,5 +16,8 @@ extern u64 notrace trace_clock_local(void);
>  extern u64 notrace trace_clock(void);
>  extern u64 notrace trace_clock_global(void);
>  extern u64 notrace trace_clock_counter(void);
> +#ifdef CONFIG_X86_TSC
> +extern u64 notrace trace_clock_tsc(void);
> +#endif
>  
>  #endif /* _LINUX_TRACE_CLOCK_H */
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 5c38c81..dc1f1fa 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -480,6 +480,9 @@ static struct {
>   { trace_clock_local,"local" },
>   { trace_clock_global,   "global" },
>   { trace_clock_counter,  "counter" },
> +#ifdef CONFIG_X86_TSC
> + { trace_clock_tsc,  "tsc" },
> +#endif
>  };

I really hate adding arch defs in generic code. Perhaps what we could do
is add a define here. Something like:

#ifndef ARCH_TRACE_CLOCKS
# define ARCH_TRACE_CLOCKS
#endif

[...]
{ trace_clock_counter, "counter" },
ARCH_TRACE_CLOCKS
};

and have ARCH_TRACE_CLOCKS defined somewhere in an arch specific header.
Not sure what header we could use though :-/

That is, in a header have:

#define ARCH_TRACE_CLOCKS \
{ trace_clock_x86_tsc,  "tsc" },

and also define trace_clock_x86_tsc in arch/x86/kernel...

-- Steve


>  
>  int trace_clock_id;
> diff --git a/kernel/trace/trace_clock.c b/kernel/trace/trace_clock.c
> index 3947835..1770737 100644
> --- a/kernel/trace/trace_clock.c
> +++ b/kernel/trace/trace_clock.c
> @@ -125,3 +125,19 @@ u64 notrace trace_clock_counter(void)
>  {
>   return atomic64_add_return(1, &trace_counter);
>  }
> +
> +#ifdef CONFIG_X86_TSC
> +/*
> + * trace_clock_tsc(): A clock that is just the cycle counter.
> + *
> + * Unlike the other clocks, this is not in nanoseconds.
> + */
> +u64 notrace trace_clock_tsc(void)
> +{
> + u64 ret;
> + rdtsc_barrier();
> + rdtscll(ret);
> +
> + return ret;
> +}
> +#endif


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

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
drivers/video/backlight/88pm860x_bl.c between commit a6ccdcd98c39 ("mfd:
88pm860x: Use REG resource for backlight") from the mfd tree and commit
e1c9ac420ef1 ("Revert "backlight: fix memory leak on obscure error
path"") from the trivial tree.

I just used the version from the mfd tree and can carry the fix as
necessary (no action is required).

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


pgpBi7ZQl3ix5.pgp
Description: PGP signature

Re: [RFC] tty/serial/kgdboc: Add and wire up clear_irqs callback

[Colin Cross]

On Tue, Sep 11, 2012 at 8:32 PM, Anton Vorontsov
 wrote:
> On Tue, Sep 11, 2012 at 03:15:40PM +0100, Alan Cox wrote:
>> Anton Vorontsov  wrote:
>> > This patch implements a new callback: clear_irqs. It is used for the
>>
>> This bit I still really don't like. I would like to know what the generic
>> IRQ folks thing about it and if Thomas Gleixner has any brilliant ideas
>> here. I don't think its a show stopper it would just be nice if there was
>> a better solution first.
>
> Yup, good idea, Cc'ing.
>
> Hello Thomas,
>
> We're dissussing a patch that adds a clear_irq callback into UART
> drivers. For convenience, the particular patch is inlined at the end of
> this email. The rationale and the background for the whole thing can be
> found here: http://lkml.org/lkml/2012/9/10/2
>
> So, just for visual clearness, and for the fun of it, here is some
> glorious ascii art of what we have:
>
>  ,---NMI-|`|
> UART_IRQ---INT_controller| CPU |
>  `---IRQ-|,|
>
> Pretty much standard scheme. That is, on the interrupt controller level
> we can reroute any IRQ to NMI, and back in 2008 folks at Google found
> that rerouting the UART IRQ to NMI brings some really cool features: we
> can have a very reliable and powerful debugger pretty much on every
> embedded machine, and without loosing the UART/console port itself.
>
> So, it works like this:
>
> - At boot time, Linux arch/ code reroutes UART IRQ to NMI, we connect
>   the port to the KGDBoC, and so forth...;
> - User starts typing on the serial port;
> - UART raises its IRQ line;
> - Through the controller, one of CPUs gets an NMI;
> - In NMI context, CPU reads a character from UART;
> - Then it checks if the character resulted into the special 'enter
>   KGDB' magic sequence:
> - If yes, then the CPU invites other CPUs into the KGDB, and thus
>   kernel enters the debugger;
> - If the character wasn't part of the magic command (or the sequence is
>   yet incomplete), then CPU exits NMI and continues as normal.
>
> The "problem" is in the last step. If we exit NMI without making UART
> know that we're done with the interrupt, we will reenter the NMI
> immediately, even without any new characters from the UART.

The UART irq line should go low when you read the character out of the
receive buffer, or the polling rx function should clear the interrupt
for you.  If you use a clear_irqs callback, you can drop characters if
one arrives between the last character buffer read and calling
clear_irqs.

> The obvious solution would be to "mask/reroute NMI at INT_controller
> level or queue serial port's IRQ routine from somewhere, e.g. a tasklet
> or software raised IRQ". Unfortunately, this means that we have to keep
> NMI disabled for this long:
>
> 1. We exit the NMI context with NMI source disabled/rerouted;
> 2. CPU continues to execute the kernel;
> 3. Kernel receives a timer interrupt, or software-raised interrupt, or
>UART IRQ, which was temporary rerouted back to normal interrupts;
> 4. It executes normal IRQ-entry, tracing, lots of other stuff,
>interrupt handlers, softirq handlers, and thus we clear the UART
>interrupt;
> 5. Once the UART is cleared, we reenable NMI (in the arch-code, we can
>do that in our do_IRQ());
>
> As you can see, with this solution the NMI debugger will be effectively
> disabled from 1. to 5., thus shall the hang happen in this sensitive
> code, we would no longer able to debug it.
>
> And this defeats the main purpose of the NMI debugger: we must keep NMI
> enabled all the time when we're not in the debugger, the NMI debugger
> is always available (unless the debugger crashed :-)
>
> That's why I came with the clear_irq callback in the serial drivers
> that we call from the NMI context, it's much simpler and keeps the
> debugger robust. So, personally I too can't think of any other
> plausible solution that would keep all the features intact.
>
>
> Thanks,
>
> Anton.
>
>
> - - - -
> [PATCH] tty/serial/kgdboc: Add and wire up clear_irqs callback
>
> This patch implements a new callback: clear_irqs. It is used for the
> cases when KDB-entry (e.g. NMI) and KDB IO (e.g. serial port) shares the
> same interrupt. To get the idea, let's take some real example (ARM
> machine): we have a serial port which interrupt is routed to an NMI, and
> the interrupt is used to enter KDB. Once there is some activity on the
> serial port, the CPU receives NMI exception, and we fall into KDB shell.
> So, it is our "debug console", and it is able to interrupt (and thus
> debug) even IRQ handlers themselves.
>
> When used that way, the interrupt never reaches serial driver's IRQ
> handler routine, which means that serial driver will not silence the
> interrupt. NMIs behaviour are quite arch-specific, and we can't assume
> that we can use them as ordinary IRQs, e.g. on some arches (like ARM) we
> can't handle data aborts, the behaviour is undefined then. So we can't
> just handle execu

[GIT] Digital signature library bugfix

[James Morris]

Please apply for v3.6.

The following changes since commit 0bd1189e239c76eb3a50e458548fbe7e4a5dfff1:
  Linus Torvalds (1):
Merge branch 'for-3.6-fixes' of git://git.kernel.org/.../tj/wq

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
for-linus

Dmitry Kasatkin (1):
  digsig: add hash size comparision on signature verification

 lib/digsig.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

commit 83e7c8fb4347186f6723f4c7d176999becbb3830
Author: Dmitry Kasatkin 
Date:   Thu Sep 6 01:06:49 2012 +0300

digsig: add hash size comparision on signature verification

Commit b35e286a640f31d619a637332972498b51f3fd90 introduced the bug.

When pkcs_1_v1_5_decode_emsa() returns without error and hash sizes do not
match, hash comparision is not done and digsig_verify_rsa() returns no 
error.
This is a bug and this patch fixes it.

Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Kasatkin 
Signed-off-by: James Morris 

diff --git a/lib/digsig.c b/lib/digsig.c
index 286d558..77b1848 100644
--- a/lib/digsig.c
+++ b/lib/digsig.c
@@ -164,8 +164,12 @@ static int digsig_verify_rsa(struct key *key,
 
err = pkcs_1_v1_5_decode_emsa(out1, len, mblen, out2, &len);
 
-   if (!err && len == hlen)
-   err = memcmp(out2, h, hlen);
+   if (err || len != hlen) {
+   err = -EINVAL;
+   goto err;
+   }
+
+   err = memcmp(out2, h, hlen);
 
 err:
mpi_free(in);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] trace: Move trace event enable from fs_initcall to core_initcall

[Ezequiel Garcia]

On Tue, Sep 11, 2012 at 9:34 PM, Steven Rostedt  wrote:
> On Sat, 2012-09-08 at 17:01 -0300, Ezequiel Garcia wrote:
>> This patch splits trace event initialization in two stages:
>>  * ftrace enable
>>  * sysfs event entry creation
>>
>> This allows to capture trace events from an earlier point
>> by using 'trace_event' kernel parameter and is important
>> to trace boot-up allocations.
>>
>> Note that, in order to enable events at core_initcall,
>> it's necessary to move init_ftrace_syscalls() from
>> core_initcall to early_initcall.
>
> Found another issue...
>
>>
>> Cc: Steven Rostedt 
>> Signed-off-by: Ezequiel Garcia 
>> ---
>> Changes from v1:
>>   * Rework code as requested by Steven.
>>
>> Changes from v2:
>>   * Move init_ftrace_syscalls() to early_initcall,
>> so syscalls self-test pass.
>>
>>  kernel/trace/trace_events.c   |  104 
>> +++-
>>  kernel/trace/trace_syscalls.c |2 +-
>>  2 files changed, 71 insertions(+), 35 deletions(-)
>>
>> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
>> index 29111da..4eaf86e 100644
>> --- a/kernel/trace/trace_events.c
>> +++ b/kernel/trace/trace_events.c
>> @@ -1199,6 +1199,31 @@ event_create_dir(struct ftrace_event_call *call, 
>> struct dentry *d_events,
>>   return 0;
>>  }
>>
>> +static void event_remove(struct ftrace_event_call *call)
>> +{
>> + ftrace_event_enable_disable(call, 0);
>> + if (call->event.funcs)
>> + __unregister_ftrace_event(&call->event);
>> + list_del(&call->list);
>> +}
>> +
>> +static int event_init(struct ftrace_event_call *call)
>> +{
>> + int ret = 0;
>> +
>> + if (WARN_ON(!call->name))
>> + return -EINVAL;
>> +
>> + if (call->class->raw_init) {
>> + ret = call->class->raw_init(call);
>
> If raw_init() returns a failure, we skip this event.
>
>> + if (ret < 0 && ret != -ENOSYS)
>> + pr_warn("Could not initialize trace events/%s\n",
>> + call->name);
>> + }
>> +
>> + return ret;
>> +}
>> +
>>  static int
>>  __trace_add_event_call(struct ftrace_event_call *call, struct module *mod,
>>  const struct file_operations *id,
>> @@ -1209,19 +1234,9 @@ __trace_add_event_call(struct ftrace_event_call 
>> *call, struct module *mod,
>>   struct dentry *d_events;
>>   int ret;
>>
>> - /* The linker may leave blanks */
>> - if (!call->name)
>> - return -EINVAL;
>> -
>> - if (call->class->raw_init) {
>> - ret = call->class->raw_init(call);
>> - if (ret < 0) {
>> - if (ret != -ENOSYS)
>> - pr_warning("Could not initialize trace 
>> events/%s\n",
>> -call->name);
>> - return ret;
>> - }
>> - }
>> + ret = event_init(call);
>> + if (ret < 0)
>> + return ret;
>>
>>   d_events = event_trace_events_dir();
>>   if (!d_events)
>> @@ -1272,13 +1287,10 @@ static void remove_subsystem_dir(const char *name)
>>   */
>>  static void __trace_remove_event_call(struct ftrace_event_call *call)
>>  {
>> - ftrace_event_enable_disable(call, 0);
>> - if (call->event.funcs)
>> - __unregister_ftrace_event(&call->event);
>> - debugfs_remove_recursive(call->dir);
>> - list_del(&call->list);
>> + event_remove(call);
>>   trace_destroy_fields(call);
>>   destroy_preds(call);
>> + debugfs_remove_recursive(call->dir);
>>   remove_subsystem_dir(call->class->system);
>>  }
>>
>> @@ -1450,6 +1462,36 @@ static __init int setup_trace_event(char *str)
>>  }
>>  __setup("trace_event=", setup_trace_event);
>>
>> +static __init int event_trace_enable(void)
>> +{
>> + struct ftrace_event_call **iter, *call;
>> + char *buf = bootup_event_buf;
>> + char *token;
>> + int ret;
>> +
>> + for_each_event(iter, __start_ftrace_events, __stop_ftrace_events) {
>> +
>> + call = *iter;
>> + ret = event_init(call);
>> + if (!ret)
>> + list_add(&call->list, &ftrace_events);
>> + }
>> +
>> + while (true) {
>> + token = strsep(&buf, ",");
>> +
>> + if (!token)
>> + break;
>> + if (!*token)
>> + continue;
>> +
>> + ret = ftrace_set_clr_event(token, 1);
>> + if (ret)
>> + pr_warn("Failed to enable trace event: %s\n", token);
>> + }
>> + return 0;
>> +}
>> +
>>  static __init int event_trace_init(void)
>>  {
>>   struct ftrace_event_call **call;
>> @@ -1457,8 +1499,6 @@ static __init int event_trace_init(void)
>>   struct dentry *entry;
>>   struct dentry *d_events;
>>   int ret;
>> - char *buf = bootup_event_buf;
>> - char *token;
>>
>>   d_tracer = tracing_init_dentry();
>>   if (!d_tracer)
>> @@ -149

Re: [PATCH 09/12] thp: introduce khugepaged_prealloc_page and khugepaged_alloc_page

[Xiao Guangrong]

On 09/12/2012 10:03 AM, Hugh Dickins wrote:

> What brought me to look at it was hitting "BUG at mm/huge_memory.c:1842!"
> running tmpfs kbuild swapping load (with memcg's memory.limit_in_bytes
> forcing out to swap), while I happened to have CONFIG_NUMA=y.
> 
> That's the VM_BUG_ON(*hpage) on entry to khugepaged_alloc_page().

> 
> So maybe 9/12 is just obscuring what was already a BUG, either earlier
> in your series or elsewhere in mmotm (I've never seen it on 3.6-rc or
> earlier releases, nor without CONFIG_NUMA).  I've not spent any time
> looking for it, maybe it's obvious - can you spot and fix it?

Hugh,

I think i have already found the reason, if i am correct, the bug was existing
before my patch.

Could you please try below patch? And, could please allow me to fix the bug 
first,
then post another patch to improve the things you dislike?


Subject: [PATCH] thp: fix forgetting to reset the page alloc indicator

If NUMA is enabled, the indicator is not reset if the previous page
request is failed, then it will trigger the BUG_ON in khugepaged_alloc_page

Signed-off-by: Xiao Guangrong 
---
 mm/huge_memory.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index e366ca5..66d2bc6 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1825,6 +1825,7 @@ static bool khugepaged_prealloc_page(struct page **hpage, 
bool *wait)
return false;

*wait = false;
+   *hpage = NULL;
khugepaged_alloc_sleep();
} else if (*hpage) {
put_page(*hpage);
-- 
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/

[RFC] tty/serial/kgdboc: Add and wire up clear_irqs callback

[Anton Vorontsov]

On Tue, Sep 11, 2012 at 03:15:40PM +0100, Alan Cox wrote:
> Anton Vorontsov  wrote:
> > This patch implements a new callback: clear_irqs. It is used for the
> 
> This bit I still really don't like. I would like to know what the generic
> IRQ folks thing about it and if Thomas Gleixner has any brilliant ideas
> here. I don't think its a show stopper it would just be nice if there was
> a better solution first.

Yup, good idea, Cc'ing.

Hello Thomas,

We're dissussing a patch that adds a clear_irq callback into UART
drivers. For convenience, the particular patch is inlined at the end of
this email. The rationale and the background for the whole thing can be
found here: http://lkml.org/lkml/2012/9/10/2

So, just for visual clearness, and for the fun of it, here is some
glorious ascii art of what we have:

 ,---NMI-|`|
UART_IRQ---INT_controller| CPU |
 `---IRQ-|,|

Pretty much standard scheme. That is, on the interrupt controller level
we can reroute any IRQ to NMI, and back in 2008 folks at Google found
that rerouting the UART IRQ to NMI brings some really cool features: we
can have a very reliable and powerful debugger pretty much on every
embedded machine, and without loosing the UART/console port itself.

So, it works like this:

- At boot time, Linux arch/ code reroutes UART IRQ to NMI, we connect
  the port to the KGDBoC, and so forth...;
- User starts typing on the serial port;
- UART raises its IRQ line;
- Through the controller, one of CPUs gets an NMI;
- In NMI context, CPU reads a character from UART;
- Then it checks if the character resulted into the special 'enter
  KGDB' magic sequence:
- If yes, then the CPU invites other CPUs into the KGDB, and thus
  kernel enters the debugger;
- If the character wasn't part of the magic command (or the sequence is
  yet incomplete), then CPU exits NMI and continues as normal.

The "problem" is in the last step. If we exit NMI without making UART
know that we're done with the interrupt, we will reenter the NMI
immediately, even without any new characters from the UART.

The obvious solution would be to "mask/reroute NMI at INT_controller
level or queue serial port's IRQ routine from somewhere, e.g. a tasklet
or software raised IRQ". Unfortunately, this means that we have to keep
NMI disabled for this long:

1. We exit the NMI context with NMI source disabled/rerouted;
2. CPU continues to execute the kernel;
3. Kernel receives a timer interrupt, or software-raised interrupt, or
   UART IRQ, which was temporary rerouted back to normal interrupts;
4. It executes normal IRQ-entry, tracing, lots of other stuff,
   interrupt handlers, softirq handlers, and thus we clear the UART
   interrupt;
5. Once the UART is cleared, we reenable NMI (in the arch-code, we can
   do that in our do_IRQ());

As you can see, with this solution the NMI debugger will be effectively
disabled from 1. to 5., thus shall the hang happen in this sensitive
code, we would no longer able to debug it.

And this defeats the main purpose of the NMI debugger: we must keep NMI
enabled all the time when we're not in the debugger, the NMI debugger
is always available (unless the debugger crashed :-)

That's why I came with the clear_irq callback in the serial drivers
that we call from the NMI context, it's much simpler and keeps the
debugger robust. So, personally I too can't think of any other
plausible solution that would keep all the features intact.


Thanks,

Anton.


- - - -
[PATCH] tty/serial/kgdboc: Add and wire up clear_irqs callback

This patch implements a new callback: clear_irqs. It is used for the
cases when KDB-entry (e.g. NMI) and KDB IO (e.g. serial port) shares the
same interrupt. To get the idea, let's take some real example (ARM
machine): we have a serial port which interrupt is routed to an NMI, and
the interrupt is used to enter KDB. Once there is some activity on the
serial port, the CPU receives NMI exception, and we fall into KDB shell.
So, it is our "debug console", and it is able to interrupt (and thus
debug) even IRQ handlers themselves.

When used that way, the interrupt never reaches serial driver's IRQ
handler routine, which means that serial driver will not silence the
interrupt. NMIs behaviour are quite arch-specific, and we can't assume
that we can use them as ordinary IRQs, e.g. on some arches (like ARM) we
can't handle data aborts, the behaviour is undefined then. So we can't
just handle execution to serial driver's IRQ handler from the NMI
context once we're done with KDB (plus this would defeat the debugger's
purpose: we want the NMI handler be as simple as possible, so it will
have less chances to hang).

So, given that have to deal with it somehow, we have two options:

1. Implement something that clears the interrupt; 2. Implement a whole
new concept of grabbing tty for exclusive KDB use, plus implement
mask/unmask callbacks, i.e.:
   - Since consoles might use ttys w/o opending them, we would hav

Re: [PATCH V3 1/3] drivers/char/tpm: Add new device driver to support IBM vTPM

[James Morris]

On Fri, 7 Sep 2012, Kent Yoder wrote:

> > >   James did accept my pull request, so these are already in
> > > security-next...
> > 
> > For the driver itself, it's not a big issue (though I did found issue
> > while reviewing it so it will need another round of updates). For the
> > code that changes arch/powerpc, especially prom_init.c, that stuff must
> > at the very least be acked by me (or the acting powerpc person if I'm
> > away) if it's going to go via a different tree.
> 
>   Sorry about that.  Hopefully there won't be any changes there and we
> can amend with your ack.
> 
>   As for the driver updates, I'd hate to see everyone else's code in the
> pull request get delayed yet again.  James, will it be ok to apply the
> update on top of security-next?

I guess?

-- 
James Morris

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

Re: [PATCH 1/3] Add ratelimited printk for different alert levels

[Joe Perches]

On Wed, 2012-09-12 at 03:43 +0530, raghu.prabh...@gmail.com wrote:
> Ratelimited printk will be useful in printing xfs messages which are otherwise
> not required to be printed always due to their high rate (to prevent kernel 
> ring
> buffer from overflowing), while at the same time required to be printed.
[]
> diff --git a/fs/xfs/xfs_message.h b/fs/xfs/xfs_message.h
[]
> @@ -30,6 +32,32 @@ void xfs_debug(const struct xfs_mount *mp, const char 
> *fmt, ...)
>  }
>  #endif
>  
> +#define xfs_printk_ratelimited(xfs_printk, dev, fmt, ...)\
> +do { \
> + static DEFINE_RATELIMIT_STATE(_rs,  \
> +   DEFAULT_RATELIMIT_INTERVAL,   \
> +   DEFAULT_RATELIMIT_BURST); \
> + if (__ratelimit(&_rs))  \
> + xfs_printk(dev, fmt, ##__VA_ARGS__);\
> +} while (0)

It might be better to use an xfs singleton RATELIMIT_STATE

DEFINE_RATELIMIT_STATE(xfs_rs);
...
#define xfs_printk_ratelimited(xfs_printk, dev, fmt, ...)   \
do {\
if (__ratelimit(&xfs_rs))   \
xfs_printk(dev, fmt, ##__VA_ARGS__);\
} while (0)


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

Re: [PATCH] spi: omap2-mcspi: Cleanup the omap2_mcspi_txrx_dma function

[Mark Brown]

On Tue, Sep 11, 2012 at 12:13:20PM +0530, Shubhrajyoti D wrote:
> Currently in omap2_mcspi_txrx_dma the tx and the rx support is
> interleaved. Make the rx related code in omap2_mcspi_rx_dma
> and the tx related code omap2_mcspi_tx_dma and call the functions.

I'd ideally like some testing from the OMAP side before applying this -
is there someone who can give a Tested-by?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] tpm: fix tpm_acpi sparse warning on different address spaces

[James Morris]

On Tue, 4 Sep 2012, Kent Yoder wrote:

> acpi_os_map_memory expects its return value to be in the __iomem address
> space. Tag the variable we're using as such and use memcpy_fromio to
> avoid further sparse warnings.
> 
> Signed-off-by: Kent Yoder 

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next


-- 
James Morris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 16/16] ARM: spear: move platform_data definitions

[viresh kumar]

On Tue, Sep 11, 2012 at 6:32 PM, Arnd Bergmann  wrote:
> Platform data for device drivers should be defined in
> include/linux/platform_data/*.h, not in the architecture
> and platform specific directories.
>
> This moves such data out of the spear include directories
>
> Signed-off-by: Arnd Bergmann 
>
> Cc: Viresh Kumar 
> Cc: Shiraz Hashim 
> Cc: spear-de...@list.st.com
> Cc: Dmitry Torokhov 

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

make tar*-pkg considered dangerous

[Andi Kleen]

Hi,

We've had some incidents with people destroying Fedore 17 installs
(to the point of reinstall) by installing a kernel tarball generated with 
make tar*-pkg

The problem is that the tarball includes /lib/{modules,firmware},
but on FC17 /lib is a symlink. tar when it unpacks the tarball
replaces the symlink with the directory. So they end up
with a /lib which only contains the new kernel files, but nothing else,

And then the system doesn't boot anymore.

I'm not sure there is a good fix for this. I don't know of a way to
convince tar to not do that. And putting everything into /usr 
would be very incompatible.

Disable these make targets or add warnings?  If disabling people should
use rpms or dpkgs instead?

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CodingStyle: Add networking specific block comment style

[Joe Perches]

The block comment style in net/ and drivers/net is non-standard.
Document it.

Signed-off-by: Joe Perches 
---
> This conflicts with the preferred style for long (multi-line) comments 
> documented in
> ./Documentation/CodingStyle.  If this is the way comments should be done in 
> the
> networking code this patch should also include an update to Chapter 8 in 
> CodingStyle
> documenting the networking specific style to avoid confusion.

 Documentation/CodingStyle |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index cb9258b..495e5ba 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -454,6 +454,16 @@ The preferred style for long (multi-line) comments is:
 * with beginning and ending almost-blank lines.
 */
 
+For files in net/ and drivers/net/ the preferred style for long (multi-line)
+comments is a little different.
+
+   /* The preferred comment style for files in net/ and drivers/net
+* looks like this.
+*
+* It is nearly the same as the generally preferred comment style,
+* but there is no initial almost-blank line.
+*/
+
 It's also important to comment data, whether they are basic types or derived
 types.  To this end, use just one data declaration per line (no commas for
 multiple data declarations).  This leaves you room for a small comment on each




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

Re: [PATCH 1/2] module: add syscall to load module from fd

[James Morris]

On Mon, 10 Sep 2012, Rusty Russell wrote:

> Kees Cook  writes:
> > On Fri, Sep 7, 2012 at 10:12 AM, Mimi Zohar  
> > wrote:
> >> This method is a consistent and extensible approach to verifying the
> >> integrity of file data/metadata, including kernel modules. The only
> >> downside to this approach, I think, is that it requires changes to the
> >> userspace tool.
> >
> > I'm fine with this -- it's an expected change that I'll pursue with
> > glibc, kmod, etc. Without the userspace changes, nothing will use the
> > new syscall. :) I've already got kmod (and older module-init-tools)
> > patched to do this locally.
> 
> A syscall is the right way to do this.  But does it need to be done?
> 
> 1) Do the LSM guys really want this hook?

Yes.

Acked-by: James Morris 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] samples/seccomp: fix 31 bit build on s390

[James Morris]

On Sat, 8 Sep 2012, Heiko Carstens wrote:

> >From cea999ef4e68e23c70e64baf054768bdebe15e1b Mon Sep 17 00:00:00 2001
> From: Heiko Carstens 
> Date: Sat, 8 Sep 2012 10:23:42 +0200
> Subject: [PATCH] samples/seccomp: fix 31 bit build on s390
> 
> On s390 the flag to force 31 builds is -m31 instead of -m32 unlike
> on all (?) other architectures.
> 
> Fixes this compile error:
> 
>   HOSTCC  samples/seccomp/bpf-direct.o
> cc1: error: unrecognized command line option "-m32"
> make[2]: *** [samples/seccomp/bpf-direct.o] Error 1
> 
> Signed-off-by: Heiko Carstens 

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

Re: [alsa-devel] [PATCH] ASoC: codecs: Add DA9055 codec driver

[Mark Brown]

On Tue, Sep 11, 2012 at 08:33:43PM +0530, Ashish Chavan wrote:

> +/* LDO voltage level value */
> +static const char * const da9055_ldo_lvl_select_txt[] = {
> + "1.05V", "1.1V", "1.2V", "1.4V"
> +};

> +static const struct soc_enum da9055_ldo_lvl_select =
> + SOC_ENUM_SINGLE(DA9055_LDO_CTRL, 4, 4, da9055_ldo_lvl_select_txt);

There's a regulator API, if configuration is required we should be using
that.

> +/* Digital MIC clock rate select */
> +static const char * const da9055_dmic_clk_rate_txt[] = {
> + "3MHz", "1.5MHz"
> +};
> +
> +static const struct soc_enum da9055_dmic_clk_rate =
> + SOC_ENUM_SINGLE(DA9055_MIC_CONFIG, 2, 2, da9055_dmic_clk_rate_txt);
> +
> +/* Digital MIC sample phase select */
> +static const char * const da9055_dmic_phase_txt[] = {
> + "Sample on DMICCLK edges", "Sample between DMICCLK edges"
> +};
> +
> +static const struct soc_enum da9055_dmic_phase =
> + SOC_ENUM_SINGLE(DA9055_MIC_CONFIG, 1, 2, da9055_dmic_phase_txt);
> +
> +/* Digital MIC channel select */
> +static const char * const da9055_dmic_channel_select_txt[] = {
> + "Rising Left Falling Right", "Falling Left Rising Right"
> +};

Why is any of this being exposed to userspace?  If this should be
configured I'd expect it to be static platform data, not something that
gets changed at runtime.

> +/* MIC bias voltage level select */
> +static const char * const da9055_mic_bias_level_txt[] = {
> + "1.6V", "1.8V", "2.1V", "2.2V"
> +};

Again, why is this being exposed to userspace/  I'm fairly sure we went
through similar stuff with your last driver...

> + SOC_DOUBLE_R_TLV("HeadPhone Volume",
> +  DA9055_HP_L_GAIN, DA9055_HP_R_GAIN,
> +  0, 0x3f, 0, hp_vol_tlv),

Headphone.

> + /* Mute controls */
> + SOC_DOUBLE_R("Mic Mute Switch", DA9055_MIC_L_CTRL,
> +  DA9055_MIC_R_CTRL, 6, 1, 0),
> + SOC_DOUBLE_R("Aux Mute Switch", DA9055_AUX_L_CTRL,
> +  DA9055_AUX_R_CTRL, 6, 1, 0),
> + SOC_DOUBLE_R("Mixin PGA Mute Switch", DA9055_MIXIN_L_CTRL,
> +  DA9055_MIXIN_R_CTRL, 6, 1, 0),
> + SOC_DOUBLE_R("ADC Mute Switch", DA9055_ADC_L_CTRL,
> +  DA9055_ADC_R_CTRL, 6, 1, 0),
> + SOC_DOUBLE_R("HeadPhone Mute Switch", DA9055_HP_L_CTRL,
> +  DA9055_HP_R_CTRL, 6, 1, 0),
> + SOC_SINGLE("Lineout Mute Switch", DA9055_LINE_CTRL, 6, 1, 0),
> + SOC_SINGLE("DAC Soft Mute Switch", DA9055_DAC_FILTERS5, 7, 1, 0),

No "Mute".  Again, I'm fairly sure we had the same issue last time.

> + /* LDO control */
> + SOC_SINGLE("LDO Enable", DA9055_LDO_CTRL, 7, 1, 0),
> + SOC_ENUM("LDO Level Select", da9055_ldo_lvl_select),

The LDO enable should absolutely not be being exposed to userspace!

> + /* DMIC controls */
> + SOC_DOUBLE_R("DMIC Enable", DA9055_MIXIN_L_SELECT,
> +  DA9055_MIXIN_R_SELECT, 7, 1, 0),

Switch if this is a mute.

> + /* MIC PGA input selection controls */
> + SOC_ENUM("Mic Left Input Select", da9055_mic_l_select),
> + SOC_ENUM("Mic Right Input Select", da9055_mic_r_select),

DAPM.

> +
> + /* ALC Controls */
> + SOC_DOUBLE_EXT("ALC Enable", DA9055_ALC_CTRL1, 3, 7, 1, 0,
> +snd_soc_get_volsw, da9055_put_alc_sw),

ALC Switch.  All enable controls should be switches.

> +static int da9055_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *dai)
> +{
> + struct snd_soc_codec *codec = dai->codec;
> + struct da9055_priv *da9055 = snd_soc_codec_get_drvdata(codec);
> + u8 aif_ctrl, fs;
> + u32 sysclk;
> +
> + /* Set AIF source to Left and Right ADC */
> + snd_soc_write(codec, DA9055_DIG_ROUTING_AIF,
> +   DA9055_AIF_L_SRC | DA9055_AIF_R_SRC);

This should be in DAPM.

> + aif_ctrl = snd_soc_read(codec, DA9055_AIF_CTRL) & 0xf3;

Use snd_soc_update_bits() later on.

> + aif_ctrl |= (DA9055_AIF_OE | DA9055_AIF_EN);

DAPM.

> + /* In slave mode, there is only one set of divisors */
> + if (!da9055->master)
> + fout = 2822400;

Should check the user supplied this value - also, what happens if the
user sets the device to slave mode after setting up the PLL?

> + /* Enable VMID reference & master bias */
> + snd_soc_write(codec, DA9055_REFERENCES,
> +   DA9055_VMID_EN | DA9055_BIAS_EN);

set_bias_level()

> + /* Enable Mic Bias */
> + snd_soc_write(codec, DA9055_MIC_BIAS_CTRL, DA9055_MIC_BIAS_EN);

DAPM for this and most of the rest of this funciton.

> + da9055->regmap = regmap_init_i2c(i2c, &da9055_regmap_config);

devm_regmap_init_i2c()
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 mfd tree with Linus' tree

[Stephen Rothwell]

Hi Samuel,

Today's linux-next merge of the mfd tree got a conflict in
Documentation/devicetree/bindings/regulator/tps6586x.txt between commit
7f852e0584f6 ("regulator: tps6586x: correct vin pin for sm0/sm1/sm2")
from Linus' tree and commit 566a725dff0d ("mfd: dt: tps6586x: Add power
off control") from the mfd tree.

Just context changes.  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 Documentation/devicetree/bindings/regulator/tps6586x.txt
index da80c2a,03dfa4e..000
--- a/Documentation/devicetree/bindings/regulator/tps6586x.txt
+++ b/Documentation/devicetree/bindings/regulator/tps6586x.txt
@@@ -30,9 -34,11 +34,11 @@@ Example
#gpio-cells = <2>;
gpio-controller;
  
+   ti,system-power-controller;
+ 
 -  sm0-supply = <&some_reg>;
 -  sm1-supply = <&some_reg>;
 -  sm2-supply = <&some_reg>;
 +  vin-sm0-supply = <&some_reg>;
 +  vin-sm1-supply = <&some_reg>;
 +  vin-sm2-supply = <&some_reg>;
vinldo01-supply = <...>;
vinldo23-supply = <...>;
vinldo4-supply = <...>;


pgpznAX2203ZO.pgp
Description: PGP signature

[PATCH 2/3] tracing: reset ring buffer when changing trace_clocks

[David Sharp]

Because the "tsc" clock isn't in nanoseconds, the ring buffer must be
reset when changing clocks so that incomparable timestamps don't end up
in the same trace.

Tested: Confirmed switching clocks resets the trace buffer.
Signed-off-by: David Sharp 
---
 kernel/trace/trace.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index dc1f1fa..6911f35 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4014,6 +4014,14 @@ static ssize_t tracing_clock_write(struct file *filp, 
const char __user *ubuf,
if (max_tr.buffer)
ring_buffer_set_clock(max_tr.buffer, trace_clocks[i].func);
 
+   /*
+* New clock may not be consistent with the previous clock.
+* Reset the buffer so that it doesn't have incomparable timestamps.
+*/
+   tracing_reset_online_cpus(&global_trace);
+   if (max_tr.buffer)
+   tracing_reset_online_cpus(&max_tr);
+
mutex_unlock(&trace_types_lock);
 
*fpos += cnt;
-- 
1.7.7.3

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

Re: [PATCH] Fix queueing work if !bdi_cap_writeback_dirty()

[Fengguang Wu]

On Wed, Sep 12, 2012 at 03:28:42AM +0900, OGAWA Hirofumi wrote:
> 
> If bdi has BDI_CAP_NO_WRITEBACK, bdi_forker_thread() doesn't start
> writeback thread. This means there is no consumer of work item made
> by bdi_queue_work().
> 
> This adds to checking of !bdi_cap_writeback_dirty(sb->s_bdi) before
> calling bdi_queue_work(), otherwise queued work never be consumed.

Thanks for catching this! Does this bug have any side effects other
than memory leaking? It may be possible for some caller that actually
expect it to do some work to make progress, otherwise will eventually
block.  If so, we'll need to fix the caller.

Thanks,
Fengguang

> Signed-off-by: OGAWA Hirofumi 
> ---
> 
>  fs/fs-writeback.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff -puN fs/fs-writeback.c~noop_backing_dev_info-check-fix fs/fs-writeback.c
> --- linux/fs/fs-writeback.c~noop_backing_dev_info-check-fix   2012-09-11 
> 06:12:30.0 +0900
> +++ linux-hirofumi/fs/fs-writeback.c  2012-09-11 06:12:30.0 +0900
> @@ -120,6 +120,9 @@ __bdi_start_writeback(struct backing_dev
>  {
>   struct wb_writeback_work *work;
>  
> + if (!bdi_cap_writeback_dirty(bdi))
> + return;
> +
>   /*
>* This is WB_SYNC_NONE writeback, so if allocation fails just
>* wakeup the thread for old dirty data writeback
> @@ -1310,7 +1313,7 @@ void writeback_inodes_sb_nr(struct super
>   .reason = reason,
>   };
>  
> - if (sb->s_bdi == &noop_backing_dev_info)
> + if (!bdi_cap_writeback_dirty(sb->s_bdi))
>   return;
>   WARN_ON(!rwsem_is_locked(&sb->s_umount));
>   bdi_queue_work(sb->s_bdi, &work);
> @@ -1396,7 +1399,7 @@ void sync_inodes_sb(struct super_block *
>   };
>  
>   /* Nothing to do? */
> - if (sb->s_bdi == &noop_backing_dev_info)
> + if (!bdi_cap_writeback_dirty(sb->s_bdi))
>   return;
>   WARN_ON(!rwsem_is_locked(&sb->s_umount));
>  
> _
> 
> -- 
> OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tracing: format non-nanosec times from tsc clock without a decimal point.

[David Sharp]

With the addition of the "tsc" clock, formatting timestamps to look like
fractional seconds is misleading. Mark clocks as either in nanoseconds or
not, and format non-nanosecond timestamps as decimal integers.

Tested:
$ cd /sys/kernel/debug/tracing/
$ cat trace_clock
[local] global tsc
$ echo sched_switch > set_event
$ echo 1 > tracing_enabled ; sleep 0.0005 ; echo 0 > tracing_enabled
$ cat trace
  -0 [000]  6330.52: sched_switch: prev_comm=swapper 
prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=bash next_pid=29964 
next_prio=120
   sleep-29964 [000]  6330.555628: sched_switch: prev_comm=bash 
prev_pid=29964 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 
next_prio=120
  ...
$ echo 1 > options/latency-format
$ cat trace
  -0   0 4104553247us+: sched_switch: prev_comm=swapper prev_pid=0 
prev_prio=120 prev_state=R ==> next_comm=bash next_pid=29964 next_prio=120
   sleep-29964   0 4104553322us+: sched_switch: prev_comm=bash prev_pid=29964 
prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120
  ...
$ echo tsc > trace_clock
$ cat trace
$ echo 1 > tracing_enabled ; sleep 0.0005 ; echo 0 > tracing_enabled
$ echo 0 > options/latency-format
$ cat trace
  -0 [000] 16490053398357: sched_switch: prev_comm=swapper 
prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=bash next_pid=31128 
next_prio=120
   sleep-31128 [000] 16490053588518: sched_switch: prev_comm=bash 
prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 
next_prio=120
  ...
echo 1 > options/latency-format
$ cat trace
  -0   0 91557653238+: sched_switch: prev_comm=swapper prev_pid=0 
prev_prio=120 prev_state=R ==> next_comm=bash next_pid=31128 next_prio=120
   sleep-31128   0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128 
prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120
  ...

Google-Bug-Id: 6980623
Signed-off-by: David Sharp 
---
 include/linux/ftrace_event.h |6 +++
 kernel/trace/trace.c |   17 +++--
 kernel/trace/trace.h |4 --
 kernel/trace/trace_output.c  |   82 +-
 4 files changed, 76 insertions(+), 33 deletions(-)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 642928c..c760670 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -86,6 +86,12 @@ struct trace_iterator {
cpumask_var_t   started;
 };
 
+enum trace_iter_flags {
+   TRACE_FILE_LAT_FMT  = 1,
+   TRACE_FILE_ANNOTATE = 2,
+   TRACE_FILE_TIME_IN_NS   = 4,
+};
+
 
 struct trace_event;
 
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 6911f35..4b78ce2 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -476,12 +476,13 @@ static const char *trace_options[] = {
 static struct {
u64 (*func)(void);
const char *name;
+   int in_ns; /* is this clock in nanoseconds? */
 } trace_clocks[] = {
-   { trace_clock_local,"local" },
-   { trace_clock_global,   "global" },
-   { trace_clock_counter,  "counter" },
+   { trace_clock_local,"local",1 },
+   { trace_clock_global,   "global",   1 },
+   { trace_clock_counter,  "counter",  0 },
 #ifdef CONFIG_X86_TSC
-   { trace_clock_tsc,  "tsc" },
+   { trace_clock_tsc,  "tsc",  0 },
 #endif
 };
 
@@ -2427,6 +2428,10 @@ __tracing_open(struct inode *inode, struct file *file)
if (ring_buffer_overruns(iter->tr->buffer))
iter->iter_flags |= TRACE_FILE_ANNOTATE;
 
+   /* Output in nanoseconds only if we are using a clock in nanoseconds. */
+   if (trace_clocks[trace_clock_id].in_ns)
+   iter->iter_flags |= TRACE_FILE_TIME_IN_NS;
+
/* stop the trace while dumping */
tracing_stop();
 
@@ -3326,6 +3331,10 @@ static int tracing_open_pipe(struct inode *inode, struct 
file *filp)
if (trace_flags & TRACE_ITER_LATENCY_FMT)
iter->iter_flags |= TRACE_FILE_LAT_FMT;
 
+   /* Output in nanoseconds only if we are using a clock in nanoseconds. */
+   if (trace_clocks[trace_clock_id].in_ns)
+   iter->iter_flags |= TRACE_FILE_TIME_IN_NS;
+
iter->cpu_file = cpu_file;
iter->tr = &global_trace;
mutex_init(&iter->mutex);
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 55e1f7f..84fefed 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -409,10 +409,6 @@ void tracing_start_sched_switch_record(void);
 int register_tracer(struct tracer *type);
 void unregister_tracer(struct tracer *type);
 int is_tracing_stopped(void);
-enum trace_file_type {
-   TRACE_FILE_LAT_FMT  = 1,
-   TRACE_FILE_ANNOTATE = 2,
-};
 
 extern cpumask_var_t __read_mostly tracing_buffer_mask;
 
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 123b189..c86d62a 100644
--- a/kernel/trace/trace_output.c
+++ 

[PATCH 1/3] tracing,x86: add a TSC trace_clock; reset buffer on clock change

[David Sharp]

In order to promote interoperability between userspace tracers and ftrace,
add a trace_clock that reports raw TSC values which will then be recorded
in the ring buffer. Userspace tracers that also record TSCs are then on
exactly the same time base as the kernel and events can be unambiguously
interlaced.

Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large
timestamp values.

Google-Bug-Id: 6980623
Signed-off-by: David Sharp 
---
 include/linux/trace_clock.h |3 +++
 kernel/trace/trace.c|3 +++
 kernel/trace/trace_clock.c  |   16 
 3 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/include/linux/trace_clock.h b/include/linux/trace_clock.h
index 4eb4902..b86c7363 100644
--- a/include/linux/trace_clock.h
+++ b/include/linux/trace_clock.h
@@ -16,5 +16,8 @@ extern u64 notrace trace_clock_local(void);
 extern u64 notrace trace_clock(void);
 extern u64 notrace trace_clock_global(void);
 extern u64 notrace trace_clock_counter(void);
+#ifdef CONFIG_X86_TSC
+extern u64 notrace trace_clock_tsc(void);
+#endif
 
 #endif /* _LINUX_TRACE_CLOCK_H */
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 5c38c81..dc1f1fa 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -480,6 +480,9 @@ static struct {
{ trace_clock_local,"local" },
{ trace_clock_global,   "global" },
{ trace_clock_counter,  "counter" },
+#ifdef CONFIG_X86_TSC
+   { trace_clock_tsc,  "tsc" },
+#endif
 };
 
 int trace_clock_id;
diff --git a/kernel/trace/trace_clock.c b/kernel/trace/trace_clock.c
index 3947835..1770737 100644
--- a/kernel/trace/trace_clock.c
+++ b/kernel/trace/trace_clock.c
@@ -125,3 +125,19 @@ u64 notrace trace_clock_counter(void)
 {
return atomic64_add_return(1, &trace_counter);
 }
+
+#ifdef CONFIG_X86_TSC
+/*
+ * trace_clock_tsc(): A clock that is just the cycle counter.
+ *
+ * Unlike the other clocks, this is not in nanoseconds.
+ */
+u64 notrace trace_clock_tsc(void)
+{
+   u64 ret;
+   rdtsc_barrier();
+   rdtscll(ret);
+
+   return ret;
+}
+#endif
-- 
1.7.7.3

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

[PATCH 0/3] TSC trace_clock

[David Sharp]

As discussed at Plumbers, here are my patches to add a TSC clock to ftrace.
Also noticeable is that the formatting patch improves the output of the
"counter" clock.

David Sharp (3):
  tracing,x86: add a TSC trace_clock; reset buffer on clock change
  tracing: reset ring buffer when changing trace_clocks
  tracing: format non-nanosec times from tsc clock without a decimal
point.

 include/linux/ftrace_event.h |6 +++
 include/linux/trace_clock.h  |3 ++
 kernel/trace/trace.c |   26 --
 kernel/trace/trace.h |4 --
 kernel/trace/trace_clock.c   |   16 
 kernel/trace/trace_output.c  |   82 +-
 6 files changed, 105 insertions(+), 32 deletions(-)

-- 
1.7.7.3

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

Query of zram/zsmalloc promotion

[Minchan Kim]

Hi all,

I would like to promote zram/zsmalloc from staging tree.
I already tried it https://lkml.org/lkml/2012/8/8/37 but I didn't get
any response from you guys.

I think zram/zsmalloc's code qulity is good and they
are used for many embedded vendors for a long time.
So it's proper time to promote them.

The zram should put on under driver/block/. I think it's not
arguable but the issue is which directory we should keep *zsmalloc*.

Now Nitin want to keep it with zram so it would be in driver/blocks/zram/
But I don't like it because zsmalloc touches several fields of struct page
freely(and AFAIRC, Andrew had a same concern with me) so I want to put
it under mm/.

In addtion, now zcache use it, too so it's rather awkward if we put it
under dirver/blocks/zram/.

So questions.

To Andrew:
Is it okay to put it under mm/ ? Or /lib?

To Jens:
Is it okay to put zram under drvier/block/ If you are okay, I will start sending
patchset after I sort out zsmalloc's location issue.

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

Re: [PATCH 09/12] thp: introduce khugepaged_prealloc_page and khugepaged_alloc_page

[Xiao Guangrong]

On 09/12/2012 10:03 AM, Hugh Dickins wrote:
> On Mon, 13 Aug 2012, Xiao Guangrong wrote:
> 
>> They are used to abstract the difference between NUMA enabled and NUMA 
>> disabled
>> to make the code more readable
>>
>> Signed-off-by: Xiao Guangrong 
>> ---
>>  mm/huge_memory.c |  166 
>> --
>>  1 files changed, 98 insertions(+), 68 deletions(-)
> 
> Hmm, that in itself is not necessarily an improvement.
> 
> I'm a bit sceptical about this patch,
> thp-introduce-khugepaged_prealloc_page-and-khugepaged_alloc_page.patch
> in last Thursday's mmotm 2012-09-06-16-46.
> 
> What brought me to look at it was hitting "BUG at mm/huge_memory.c:1842!"
> running tmpfs kbuild swapping load (with memcg's memory.limit_in_bytes
> forcing out to swap), while I happened to have CONFIG_NUMA=y.
> 
> That's the VM_BUG_ON(*hpage) on entry to khugepaged_alloc_page().

I will look into it, thanks for your point it out.

> 
> (If I'm honest, I'll admit I have Michel's "interval trees for anon rmap"
> patches in on top, and so the line number was actually shifted to 1839:
> but I don't believe his patches were in any way involved here, and
> indeed I've not yet found a problem with them: they look very good.)
> 
> I expect the BUG could quite easily be fixed up by making another call
> to khugepaged_prealloc_page() from somewhere to free up the hpage;
> but forgive me if I dislike using "prealloc" to free.
> 
> I do agree with you that the several CONFIG_NUMA ifdefs dotted around
> mm/huge_memory.c are regrettable, but I'm not at all sure that you're
> improving the situation with this patch, which gives misleading names
> to functions and moves the mmap_sem upping out of line.
> 
> I think you need to revisit it: maybe not go so far (leaving a few
> CONFIG_NUMAs behind, if they're not too bad), or maybe go further
> (add a separate function for freeing in the NUMA case, instead of
> using "prealloc").  I don't know what's best: have a play and see.

Sorry for that, i will find a better way to do this.

> 
> That's what I was intending to write yesterday.  But overnight I
> was running with this 9/12 backed out (I think 10,11,12 should be
> independent), and found "BUG at mm/huge_memory.c:1835!" this morning.
> 
> That's the VM_BUG_ON(*hpage) below #else in collapse_huge_page()
> when 9/12 is reverted.
> 
> So maybe 9/12 is just obscuring what was already a BUG, either earlier
> in your series or elsewhere in mmotm (I've never seen it on 3.6-rc or
> earlier releases, nor without CONFIG_NUMA).  I've not spent any time
> looking for it, maybe it's obvious - can you spot and fix it?

Sure, will fix it as soon as possible. Thanks!


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

Re: [ 34/95] USB: option: add ZTE K5006-Z

[Ben Hutchings]

On Tue, 2012-09-11 at 09:43 +0200, Bjørn Mork wrote:
> Thomas Schäfer  writes:
> 
> > Am Montag, 10. September 2012 um 00:42:24 schrieb Ben Hutchings:
> >> 3.2-stable review patch.  If anyone has any objections, please let me know.
> >
> >
> >
> > referring to
> >
> > http://www.spinics.net/lists/linux-usb/msg70131.html
> >
> > it should not be done with ff ff ff
> 
> 
> Yes, sorry about not getting around to fixing that in time.  I've just
> submitted a proposed fix.  But as my fix removes the bogus entry, you
> may just as well go ahead and add this patch to stable so that the fixup
> applies cleanly later. If accepted...
[...]

If this addition is 'bogus' then I'll defer it.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.


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

Re: [PATCH 16/18] perf evsel: Introduce perf_evsel__{str,int}val methods

[Namhyung Kim]

On Tue, 11 Sep 2012 20:53:08 -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo 
>
> Wrappers to the libtraceevent routines, so that we can further reduce
> the surface contact perf builtins have with it.

I just realized that this breaks the python extension:

namhyung@sejong:perf$ python/twatch.py 
Traceback (most recent call last):
  File "python/twatch.py", line 16, in 
import perf
ImportError: /home/namhyung/project/linux/tools/perf/python/perf.so: undefined 
symbol: pevent_find_field


Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 15/16] ARM: samsung: move platform_data definitions

[Kukjin Kim]

Arnd Bergmann wrote:
> 
> Platform data for device drivers should be defined in
> include/linux/platform_data/*.h, not in the architecture
> and platform specific directories.
> 
> This moves such data out of the samsung include directories
> 
> Signed-off-by: Arnd Bergmann 
> Cc: Kukjin Kim 

Yeah, basically looks OK on this.

Acked-by: Kukjin Kim 

BTW, how about re-ordering inclusion  after
 rather than just replacing like following?

---
#include 
...
#include 
...
#include 
...
#include 
...
---

And there are small comments...

> Cc: Kyungmin Park 
> Cc: Ben Dooks 
> Cc: Mark Brown 
> Cc: Jeff Garzik 
> Cc: Guenter Roeck 
> Cc: "Wolfram Sang (embedded platforms)" 
> Cc: Dmitry Torokhov 
> Cc: Bryan Wu 
> Cc: Richard Purdie 
> Cc: Sylwester Nawrocki 
> Cc: Mauro Carvalho Chehab 
> Cc: Chris Ball 
> Cc: David Woodhouse 
> Cc: Grant Likely 
> Cc: Felipe Balbi 
> Cc: Greg Kroah-Hartman 
> Cc: Alan Stern 
> Cc: Sangbeom Kim 
> Cc: Liam Girdwood 
> Cc: linux-samsung-...@vger.kernel.org
> ---
>  arch/arm/mach-exynos/dev-audio.c   |2 +-
>  arch/arm/mach-exynos/dev-ohci.c|2 +-
>  arch/arm/mach-exynos/mach-nuri.c   |6 +++---
>  arch/arm/mach-exynos/mach-origen.c |6 +++---
>  arch/arm/mach-exynos/mach-smdk4x12.c   |2 +-
>  arch/arm/mach-exynos/mach-smdkv310.c   |6 +++---
>  arch/arm/mach-exynos/mach-universal_c210.c |4 ++--
>  arch/arm/mach-exynos/setup-i2c0.c  |2 +-
>  arch/arm/mach-exynos/setup-i2c1.c  |2 +-
>  arch/arm/mach-exynos/setup-i2c2.c  |2 +-
>  arch/arm/mach-exynos/setup-i2c3.c  |2 +-
>  arch/arm/mach-exynos/setup-i2c4.c  |2 +-
>  arch/arm/mach-exynos/setup-i2c5.c  |2 +-
>  arch/arm/mach-exynos/setup-i2c6.c  |2 +-
>  arch/arm/mach-exynos/setup-i2c7.c  |2 +-
>  arch/arm/mach-s3c24xx/common-smdk.c|4 ++--
>  arch/arm/mach-s3c24xx/mach-amlm5900.c  |2 +-
>  arch/arm/mach-s3c24xx/mach-anubis.c|6 +++---
>  arch/arm/mach-s3c24xx/mach-at2440evb.c |6 +++---
>  arch/arm/mach-s3c24xx/mach-bast.c  |8 
>  arch/arm/mach-s3c24xx/mach-gta02.c |   10 +-
>  arch/arm/mach-s3c24xx/mach-h1940.c |8 
>  arch/arm/mach-s3c24xx/mach-jive.c  |6 +++---
>  arch/arm/mach-s3c24xx/mach-mini2440.c  |   10 +-
>  arch/arm/mach-s3c24xx/mach-n30.c   |8 
>  arch/arm/mach-s3c24xx/mach-nexcoder.c  |2 +-
>  arch/arm/mach-s3c24xx/mach-osiris.c|4 ++--
>  arch/arm/mach-s3c24xx/mach-otom.c  |2 +-
>  arch/arm/mach-s3c24xx/mach-qt2410.c|8 
>  arch/arm/mach-s3c24xx/mach-rx1950.c|   10 +-
>  arch/arm/mach-s3c24xx/mach-rx3715.c|2 +-
>  arch/arm/mach-s3c24xx/mach-smdk2410.c  |2 +-
>  arch/arm/mach-s3c24xx/mach-smdk2413.c  |4 ++--
>  arch/arm/mach-s3c24xx/mach-smdk2416.c  |8 
>  arch/arm/mach-s3c24xx/mach-smdk2440.c  |2 +-
>  arch/arm/mach-s3c24xx/mach-smdk2443.c  |2 +-
>  arch/arm/mach-s3c24xx/mach-tct_hammer.c|2 +-
>  arch/arm/mach-s3c24xx/mach-vr1000.c|6 +++---
>  arch/arm/mach-s3c24xx/mach-vstms.c |4 ++--
>  arch/arm/mach-s3c24xx/setup-i2c.c  |2 +-
>  arch/arm/mach-s3c24xx/simtec-audio.c   |2 +-
>  arch/arm/mach-s3c24xx/simtec-usb.c |2 +-
>  arch/arm/mach-s3c64xx/dev-audio.c  |2 +-
>  arch/arm/mach-s3c64xx/mach-anw6410.c   |2 +-
>  arch/arm/mach-s3c64xx/mach-crag6410-module.c   |2 +-
>  arch/arm/mach-s3c64xx/mach-crag6410.c  |4 ++--
>  arch/arm/mach-s3c64xx/mach-hmt.c   |4 ++--
>  arch/arm/mach-s3c64xx/mach-mini6410.c  |4 ++--
>  arch/arm/mach-s3c64xx/mach-ncp.c   |2 +-
>  arch/arm/mach-s3c64xx/mach-real6410.c  |4 ++--
>  arch/arm/mach-s3c64xx/mach-smartq.c|8 
>  arch/arm/mach-s3c64xx/mach-smdk6400.c  |2 +-
>  arch/arm/mach-s3c64xx/mach-smdk6410.c  |6 +++---
>  arch/arm/mach-s3c64xx/setup-i2c0.c |2 +-
>  arch/arm/mach-s3c64xx/setup-i2c1.c |2 +-
>  arch/arm/mach-s3c64xx/setup-ide.c  |2 +-
>  arch/arm/mach-s5p64x0/dev-audio.c  |2 +-
>  arch/arm/mach-s5p64x0/mach-smdk6440.c  |4 ++--
>  arch/arm/mach-s5p64x0/mach-smdk6450.c  |4 ++--
>  arch/arm/mach-s5p64x0/setup-i2c0.c |2 +-
>  arch/arm/mach-s5p64x0/setup-i2c1.c 

[PATCH 2/2] perf sched: Fixup for the die() removal

[Namhyung Kim]

From: Namhyung Kim 

The commit a116e05dcf61 ("perf sched: Remove die() calls") replaced
die() call to pr_debug + return -1, but it should be pr_err otherwise
it'll not show up unless -v option is given.  Fix it.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-sched.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index af305f57bd22..9b9e32eaa805 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -438,8 +438,8 @@ static int self_open_counters(void)
fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
 
if (fd < 0)
-   pr_debug("Error: sys_perf_event_open() syscall returned"
-"with %d (%s)\n", fd, strerror(errno));
+   pr_err("Error: sys_perf_event_open() syscall returned "
+  "with %d (%s)\n", fd, strerror(errno));
return fd;
 }
 
@@ -700,7 +700,7 @@ static int replay_switch_event(struct perf_sched *sched,
delta = 0;
 
if (delta < 0) {
-   pr_debug("hm, delta: %" PRIu64 " < 0 ?\n", delta);
+   pr_err("hm, delta: %" PRIu64 " < 0 ?\n", delta);
return -1;
}
 
@@ -990,7 +990,7 @@ static int latency_runtime_event(struct perf_sched *sched,
return -1;
atoms = thread_atoms_search(&sched->atom_root, thread, 
&sched->cmp_pid);
if (!atoms) {
-   pr_debug("in-event: Internal tree error");
+   pr_err("in-event: Internal tree error");
return -1;
}
if (add_sched_out_event(atoms, 'R', timestamp))
@@ -1024,7 +1024,7 @@ static int latency_wakeup_event(struct perf_sched *sched,
return -1;
atoms = thread_atoms_search(&sched->atom_root, wakee, 
&sched->cmp_pid);
if (!atoms) {
-   pr_debug("wakeup-event: Internal tree error");
+   pr_err("wakeup-event: Internal tree error");
return -1;
}
if (add_sched_out_event(atoms, 'S', timestamp))
@@ -1079,7 +1079,7 @@ static int latency_migrate_task_event(struct perf_sched 
*sched,
register_pid(sched, migrant->pid, migrant->comm);
atoms = thread_atoms_search(&sched->atom_root, migrant, 
&sched->cmp_pid);
if (!atoms) {
-   pr_debug("migration-event: Internal tree error");
+   pr_err("migration-event: Internal tree error");
return -1;
}
if (add_sched_out_event(atoms, 'R', timestamp))
@@ -1286,7 +1286,7 @@ static int map_switch_event(struct perf_sched *sched, 
struct perf_evsel *evsel,
delta = 0;
 
if (delta < 0) {
-   pr_debug("hm, delta: %" PRIu64 " < 0 ?\n", delta);
+   pr_err("hm, delta: %" PRIu64 " < 0 ?\n", delta);
return -1;
}
 
-- 
1.7.11.4

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

[PATCH 1/2] perf test: Fixup for the die() removal

[Namhyung Kim]

From: Namhyung Kim 

The commit 32c7f7383a09 ("perf test: Remove die() calls") replaced
die() call to pr_debug + return -1, but it should be pr_err otherwise
it'll not show up unless -v option is given.  Fix it.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-test.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-test.c b/tools/perf/builtin-test.c
index d33143efefce..4aed1553db56 100644
--- a/tools/perf/builtin-test.c
+++ b/tools/perf/builtin-test.c
@@ -1026,15 +1026,15 @@ static int __test__rdpmc(void)
 
fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
if (fd < 0) {
-   pr_debug("Error: sys_perf_event_open() syscall returned "
-"with %d (%s)\n", fd, strerror(errno));
+   pr_err("Error: sys_perf_event_open() syscall returned "
+  "with %d (%s)\n", fd, strerror(errno));
return -1;
}
 
addr = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, 0);
if (addr == (void *)(-1)) {
-   pr_debug("Error: mmap() syscall returned with (%s)\n",
-strerror(errno));
+   pr_err("Error: mmap() syscall returned with (%s)\n",
+  strerror(errno));
goto out_close;
}
 
-- 
1.7.11.4

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

Re: [PATCH 09/12] thp: introduce khugepaged_prealloc_page and khugepaged_alloc_page

[Hugh Dickins]

On Mon, 13 Aug 2012, Xiao Guangrong wrote:

> They are used to abstract the difference between NUMA enabled and NUMA 
> disabled
> to make the code more readable
> 
> Signed-off-by: Xiao Guangrong 
> ---
>  mm/huge_memory.c |  166 
> --
>  1 files changed, 98 insertions(+), 68 deletions(-)

Hmm, that in itself is not necessarily an improvement.

I'm a bit sceptical about this patch,
thp-introduce-khugepaged_prealloc_page-and-khugepaged_alloc_page.patch
in last Thursday's mmotm 2012-09-06-16-46.

What brought me to look at it was hitting "BUG at mm/huge_memory.c:1842!"
running tmpfs kbuild swapping load (with memcg's memory.limit_in_bytes
forcing out to swap), while I happened to have CONFIG_NUMA=y.

That's the VM_BUG_ON(*hpage) on entry to khugepaged_alloc_page().

(If I'm honest, I'll admit I have Michel's "interval trees for anon rmap"
patches in on top, and so the line number was actually shifted to 1839:
but I don't believe his patches were in any way involved here, and
indeed I've not yet found a problem with them: they look very good.)

I expect the BUG could quite easily be fixed up by making another call
to khugepaged_prealloc_page() from somewhere to free up the hpage;
but forgive me if I dislike using "prealloc" to free.

I do agree with you that the several CONFIG_NUMA ifdefs dotted around
mm/huge_memory.c are regrettable, but I'm not at all sure that you're
improving the situation with this patch, which gives misleading names
to functions and moves the mmap_sem upping out of line.

I think you need to revisit it: maybe not go so far (leaving a few
CONFIG_NUMAs behind, if they're not too bad), or maybe go further
(add a separate function for freeing in the NUMA case, instead of
using "prealloc").  I don't know what's best: have a play and see.

That's what I was intending to write yesterday.  But overnight I
was running with this 9/12 backed out (I think 10,11,12 should be
independent), and found "BUG at mm/huge_memory.c:1835!" this morning.

That's the VM_BUG_ON(*hpage) below #else in collapse_huge_page()
when 9/12 is reverted.

So maybe 9/12 is just obscuring what was already a BUG, either earlier
in your series or elsewhere in mmotm (I've never seen it on 3.6-rc or
earlier releases, nor without CONFIG_NUMA).  I've not spent any time
looking for it, maybe it's obvious - can you spot and fix it?

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

Re: [PATCH 16/18] perf evsel: Introduce perf_evsel__{str,int}val methods

[Namhyung Kim]

On Tue, 11 Sep 2012 20:53:08 -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo 
>
> Wrappers to the libtraceevent routines, so that we can further reduce
> the surface contact perf builtins have with it.
[snip]
> +char *perf_evsel__strval(struct perf_evsel *evsel, struct perf_sample 
> *sample,
> +  const char *name)
> +{
> + struct format_field *field = pevent_find_field(evsel->tp_format, name);
> + int offset;
> +
> +if (!field)
> +return NULL;

Whitespace problem?

Btw, as a generic wrapper shouldn't it handle common fields also?  If
you care about performance, how about switching the order of finding
fields in question, i.e.:

struct format_field *field = pevent_find_field(evsel->tp_format, name);

if (!field) {
field = pevent_find_common_field(evsel->tp_format, name);
if (!field)
return NULL;
}

> +
> + offset = field->offset;
> +
> + if (field->flags & FIELD_IS_DYNAMIC) {
> + offset = *(int *)(sample->raw_data + field->offset);
> + offset &= 0x;
> + }
> +
> + return sample->raw_data + offset;
> +}
> +
> +u64 perf_evsel__intval(struct perf_evsel *evsel, struct perf_sample *sample,
> +const char *name)
> +{
> + struct format_field *field = pevent_find_field(evsel->tp_format, name);
> + u64 val;
> +
> +if (!field)
> +return 0;

Ditto.

Thanks,
Namhyung

> +
> + val = pevent_read_number(evsel->tp_format->pevent,
> +  sample->raw_data + field->offset, field->size);
> + return val;
> +
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [V4 PATCH 27/27] memory,hotplug: Don't modify the zone_start_pfn outside of zone_span_writelock()

[Lai Jiangshan]

On 09/11/2012 06:18 PM, Yasuaki Ishimatsu wrote:
> Hi Lai,
> 
> 2012/09/11 18:44, Lai Jiangshan wrote:
>> On 09/11/2012 08:40 AM, Yasuaki Ishimatsu wrote:
>>> Hi Lai,
>>>
>>> Using memory_online to hot-added node's memory, the following kernel 
>>> messages
>>> were shown. Is this a known issue?
>>
>> Fixed.
>>
>> Subject: Don't modify the zone_start_pfn outside of zone_span_writelock()
>>
>> Original __add_zone() and new online_movable/online_kernel
>> maybe call sleep-able init_currently_empty_zone() to init wait_table,
>>
>> but this function also modifies the zone_start_pfn without lock.
>> so we move this code out, and ensure the modification of zone_start_pfn is 
>> done
>> with zone_span_writelock() held or booting.
>>
>> Since zone_start_pfn is not modified by init_currently_empty_zone()
>> grow_zone_span() needs to be updated to be aware of empty zone.
>>
>> Signed-off-by: Lai Jiangshan 
>> Reported-by: Yasuaki ISIMATU 
>> Tested-by: Wen Congyang 
> 
> Applying the patch, the kernel messages disappeared. Thanks.
> But I have a question. Using online_movable, the following messages are shown.
> 
> [  608.314608] Built 3 zonelists in Node order, mobility grouping on.  Total 
> pages: 7844412
> [  608.411478] Policy zone: Normal
> 
> I think memory is allocated to ZONE_MOVABLE by using online_movable.
> So why is "Policy zone: Normal" shown? It should be "Policy zone: Movable"
> 
>


I don't know the mean of "Policy zone" of here. but:

-
/* Highest zone. An specific allocation for a zone below that is not
   policied. */
enum zone_type policy_zone = 0;



extern enum zone_type policy_zone;

static inline void check_highest_zone(enum zone_type k)
{
if (k > policy_zone && k != ZONE_MOVABLE)
policy_zone = k;
}

--

so I think the output is correct.

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

Re: + mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links.patch added to -mm tree

[David Rientjes]

On Tue, 11 Sep 2012, Hugh Dickins wrote:

> > > This does revert 2.6.27's dfe195fb79e88 ("mm: fix uninitialized variables
> > > for find_vma_prepare callers"), but it looks like gcc 4.3.0 was one of
> > > those releases too eager to shout about uninitialized variables: only
> > > copy_vma() warns with 4.5.1 and 4.7.1, which a BUG on error silences.
> > > 
> > 
> > That trick doesn't work if CONFIG_BUG=n.
> > 
> > mm/mmap.c: In function 'copy_vma':
> > mm/mmap.c:2344: warning: 'prev' may be used uninitialized in this function
> > mm/mmap.c:2345: warning: 'rb_link' may be used uninitialized in this 
> > function
> > mm/mmap.c:2345: warning: 'rb_parent' may be used uninitialized in this 
> > function
> 
> Hmm, right: not an option I ever choose, and I hadn't given it a thought.
> 
> But do we care?  If this introduced the only such warning, I would care.

It now has the distinction of being the only warning for CONFIG_BUG=n in 
mm/*.

> But that seems to be far from the case - building my usual config without
> CONFIG_BUG gives me 36 warnings, of uninitialized and unused and
> control reaches end of non-void varieties.
> 

What's so special about copy_vma() that we can't fix it all up to use 
uninitialized_var() so this is handled the proper way?  If CONFIG_BUG 
exists, then we should support it, right?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] memory-hotplug: don't replace lowmem pages with highmem

[Minchan Kim]

[1] reporeted that lowmem pages could be replaced by
highmem pages during migration of CMA and fixed.

Quote from [1]'s description
"
The filesystem layer expects pages in the block device's mapping to not
be in highmem (the mapping's gfp mask is set in bdget()), but CMA can
currently replace lowmem pages with highmem pages, leading to crashes in
filesystem code such as the one below:

  Unable to handle kernel NULL pointer dereference at virtual address 
0400
  pgd = c0c98000
  [0400] *pgd=00c91831, *pte=, *ppte=
  Internal error: Oops: 817 [#1] PREEMPT SMP ARM
  CPU: 0Not tainted  (3.5.0-rc5+ #80)
  PC is at __memzero+0x24/0x80
  ...
  Process fsstress (pid: 323, stack limit = 0xc0cbc2f0)
  Backtrace:
  [] (ext4_getblk+0x0/0x180) from [] 
(ext4_bread+0x1c/0x98)
  [] (ext4_bread+0x0/0x98) from [] 
(ext4_mkdir+0x160/0x3bc)
   r4:c15337f0
  [] (ext4_mkdir+0x0/0x3bc) from [] 
(vfs_mkdir+0x8c/0x98)
  [] (vfs_mkdir+0x0/0x98) from [] 
(sys_mkdirat+0x74/0xac)
   r6: r5:c152eb40 r4:01ff r3:c14b43f0
  [] (sys_mkdirat+0x0/0xac) from [] 
(sys_mkdir+0x20/0x24)
   r6:beccdcf0 r5:00074000 r4:beccdbbc
  [] (sys_mkdir+0x0/0x24) from [] 
(ret_fast_syscall+0x0/0x30)
"

Memory-hotplug has same problem with CMA so [1]'s fix could be applied
with memory-hotplug, too.

Fix it by reusing.

[1] 6a6dccba2, mm: cma: don't replace lowmem pages with highmem

Cc: Kamezawa Hiroyuki 
Cc: Yasuaki Ishimatsu 
Cc: Michal Nazarewicz 
Cc: Marek Szyprowski 
Cc: Wen Congyang 
Signed-off-by: Minchan Kim 
---
 mm/memory_hotplug.c |   15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 4491a6b..fb71e5c 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -752,13 +752,6 @@ static unsigned long scan_lru_pages(unsigned long start, 
unsigned long end)
return 0;
 }
 
-static struct page *
-hotremove_migrate_alloc(struct page *page, unsigned long private, int **x)
-{
-   /* This should be improved!! */
-   return alloc_page(GFP_HIGHUSER_MOVABLE);
-}
-
 #define NR_OFFLINE_AT_ONCE_PAGES   (256)
 static int
 do_migrate_range(unsigned long start_pfn, unsigned long end_pfn)
@@ -809,8 +802,12 @@ do_migrate_range(unsigned long start_pfn, unsigned long 
end_pfn)
putback_lru_pages(&source);
goto out;
}
-   /* this function returns # of failed pages */
-   ret = migrate_pages(&source, hotremove_migrate_alloc, 0,
+
+   /*
+* alloc_migrate_target should be improved!!
+* migrate_pages returns # of failed pages.
+*/
+   ret = migrate_pages(&source, alloc_migrate_target, 0,
true, MIGRATE_SYNC);
if (ret)
putback_lru_pages(&source);
-- 
1.7.9.5

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

[PATCH 1/2] mm: refactor out __alloc_contig_migrate_alloc

[Minchan Kim]

__alloc_contig_migrate_alloc can be used by memory-hotplug so
refactor out(move + rename as a common name) it into
page_isolation.c.

Cc: Kamezawa Hiroyuki 
Cc: Yasuaki Ishimatsu 
Cc: Michal Nazarewicz 
Cc: Marek Szyprowski 
Cc: Wen Congyang 
Signed-off-by: Minchan Kim 
---

This patch is intended for preparing next bug fix patch.

 include/linux/page-isolation.h |3 ++-
 mm/page_alloc.c|   14 +-
 mm/page_isolation.c|   11 +++
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 105077a..1c82261 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -37,6 +37,7 @@ int test_pages_isolated(unsigned long start_pfn, unsigned 
long end_pfn);
  */
 int set_migratetype_isolate(struct page *page);
 void unset_migratetype_isolate(struct page *page, unsigned migratetype);
-
+struct page *alloc_migrate_target(struct page *page, unsigned long private,
+   int **resultp);
 
 #endif
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a4ff74e..6716023 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5648,18 +5648,6 @@ static unsigned long pfn_max_align_up(unsigned long pfn)
pageblock_nr_pages));
 }
 
-static struct page *
-__alloc_contig_migrate_alloc(struct page *page, unsigned long private,
-int **resultp)
-{
-   gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE;
-
-   if (PageHighMem(page))
-   gfp_mask |= __GFP_HIGHMEM;
-
-   return alloc_page(gfp_mask);
-}
-
 /* [start, end) must belong to a single zone. */
 static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
 {
@@ -5700,7 +5688,7 @@ static int __alloc_contig_migrate_range(unsigned long 
start, unsigned long end)
}
 
ret = migrate_pages(&cc.migratepages,
-   __alloc_contig_migrate_alloc,
+   alloc_migrate_target,
0, false, MIGRATE_SYNC);
}
 
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index 247d1f1..6936545 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -233,3 +233,14 @@ int test_pages_isolated(unsigned long start_pfn, unsigned 
long end_pfn)
spin_unlock_irqrestore(&zone->lock, flags);
return ret ? 0 : -EBUSY;
 }
+
+struct page *alloc_migrate_target(struct page *page, unsigned long private,
+ int **resultp)
+{
+gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE;
+
+if (PageHighMem(page))
+gfp_mask |= __GFP_HIGHMEM;
+
+return alloc_page(gfp_mask);
+}
-- 
1.7.9.5

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

Re: [PATCH] clk: Make the managed clk functions generically available

[Greg Ungerer]

On 12/09/12 00:50, Artem Bityutskiy wrote:

On Tue, 2012-09-11 at 16:44 +0200, Lars-Peter Clausen wrote:

On 09/10/2012 02:39 AM, Russell King - ARM Linux wrote:

On Mon, Sep 10, 2012 at 08:20:21AM +0800, Mark Brown wrote:

[...]
OK, that's what I'd thought was going on - it was the fact that you'd
just acked the patch rather than asked for it to go to the patch tracker
or something which made me wonder if things had changed.


I kind'a forgot because it's been soo long since I took any of those
patches...


Ok, what's the plan? Should I add this patch to the patch tracker?


I'd propose to send it to Linus for v3.6 even.


If we do this can we make a decision quickly on it.

I need to fix a regression on some ColdFire parts for 3.6. I either need
to use this clk patch, which fixes my problem, or a specific patch for the
ColdFire clk code http://marc.info/?l=linux-m68k&m=134725225823437&w=2

Regards
Greg


--

Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/3] perf tool: Allow wildcard in PMU name

[Yan, Zheng]

On 09/11/2012 10:05 PM, Jiri Olsa wrote:
> On Mon, Sep 10, 2012 at 03:53:51PM +0800, Yan, Zheng wrote:
>> From: "Yan, Zheng" 
>>
> 
> SNIP
> 
>> +int parse_events_add_pmu(struct list_head **_list, int *idx,
>>   char *name, struct list_head *head_config)
>>  {
>>  struct perf_event_attr attr;
>> -struct perf_pmu *pmu;
>> +struct list_head *list;
>> +struct perf_pmu *pmu = NULL;
>> +struct perf_evsel *evsel, *first = NULL;
>> +int orig_idx = *idx;
>>  
>> -pmu = perf_pmu__find(name);
>> -if (!pmu)
>> -return -EINVAL;
>> +list = malloc(sizeof(*list));
>> +if (!list)
>> +return -ENOMEM;
>> +INIT_LIST_HEAD(list);
> 
> list should be allocated only if (!*_list)) same as in add_event function
> 
> I haven't test, but I think you'll leak/loose events if there's another pmu
> event defined after ','
> 

I think *_list is always NULL, because the code in parse-event.y is:

---
PE_NAME '/' event_config '/'
{
struct parse_events_data__events *data = _data;
struct list_head *list = NULL;

ABORT_ON(parse_events_add_pmu(&list, &data->idx, $1, $3));
parse_events__free_terms($3);
$$ = list;
}

---

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

Re: [PATCH v2 1/2] cgroups: add documentation on extended attributes usage

[Li Zefan]

> v2: update cgroups.txt instead of creating a new file
> 
> Cc: Li Zefan 
> Cc: Tejun Heo 
> Cc: Hugh Dickins 
> Cc: Hillf Danton 
> Cc: Lennart Poettering 
> Signed-off-by: Aristeu Rozanski 
> 

Acked-by: Li Zefan 

> ---
>  Documentation/cgroups/cgroups.txt |   24 ++--
>  1 file changed, 22 insertions(+), 2 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 01/18] perf test: Remove die() calls

[Namhyung Kim]

On Tue, 11 Sep 2012 18:03:10 -0700, Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 12, 2012 at 09:24:33AM +0900, Namhyung Kim escreveu:
>> Hi, Arnaldo
>> 
>> On Tue, 11 Sep 2012 20:52:53 -0300, Arnaldo Carvalho de Melo wrote:
>> > From: Arnaldo Carvalho de Melo 
>> >
>> > Just use pr_err() + return -1 and let the other tests run as well and
>> > then the perf's main() exit doing whatever it needs.
>> [snip]
>> > diff --git a/tools/perf/builtin-test.c b/tools/perf/builtin-test.c
>> > index cf33e50..6ae102e 100644
>> > --- a/tools/perf/builtin-test.c
>> > +++ b/tools/perf/builtin-test.c
>> > @@ -1023,14 +1023,16 @@ static int __test__rdpmc(void)
>> >  
>> >fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
>> >if (fd < 0) {
>> > -  die("Error: sys_perf_event_open() syscall returned "
>> > -  "with %d (%s)\n", fd, strerror(errno));
>> > +  pr_debug("Error: sys_perf_event_open() syscall returned "
>> > +   "with %d (%s)\n", fd, strerror(errno));
>> 
>> s/pr_debug/pr_err/ ?
>> 
>> Otherwise the message will not be shown unless -v option is given
>> - and it's not sync with the changelog ;-)
>
> Oops :-\ Can you sent a fixup patch for this and the other case?

Will send it right soon.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] checkpatch: Check networking specific block comment style

[Allan, Bruce W]

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Joe Perches
> Sent: Tuesday, September 11, 2012 5:48 PM
> To: Andrew Morton
> Cc: Andy Whitcroft; David Miller; LKML; netdev
> Subject: [PATCH] checkpatch: Check networking specific block comment
> style
> 
> In an effort to get fewer checkpatch reviewer corrections,
> add a networking specific style test for the preferred
> networking comment style.
> 
>   /* The preferred style for block comments in
>* drivers/net/... and net/... is like this
>*/
> 
> These tests are only used in net/ and drivers/net/
> 
> Tested with:
> 
> $ cat drivers/net/t.c
> 
> /* foo */
> 
> /*
>  * foo
>  */
> 
> /* foo
>  */
> 
> /* foo
>  * bar */
> $ ./scripts/checkpatch.pl -f drivers/net/t.c
> WARNING: networking block comments don't use an empty /* line, use /* 
> Comment...

This conflicts with the preferred style for long (multi-line) comments 
documented in
./Documentation/CodingStyle.  If this is the way comments should be done in the
networking code this patch should also include an update to Chapter 8 in 
CodingStyle
documenting the networking specific style to avoid confusion.

Re: [PATCH signal#execve2] syscalls,x86: Add execveat() system call (v3)

[Al Viro]

On Wed, Sep 12, 2012 at 01:55:52AM +0100, Meredydd Luff wrote:
> Al (in particular): I've reworked this on top of your generic
> execve() changes, as well as incorporating feedback from HPA.
> Could you take another look please (and merge if all is well)?
> 
> [v3: now rebased onto signal.git#execve2, and takes a flags
> parameter which understands AT_SYMLINK_NOFOLLOW; all thanks to
> feedback from https://lkml.org/lkml/2012/8/1/418]
> 
> HPA is already on record calling for an execveat() which also does
> fexecve()'s job: https://lkml.org/lkml/2006/7/11/556.
> And the current glibc hack for fexecve() is already causing problems
> in the wild. Eg: https://bugzilla.redhat.com/show_bug.cgi?id=241609,
> https://lkml.org/lkml/2006/12/27/123, and as recounted at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514043.

Please, declare open_execat(), leaving open_exec() as it is (i.e. a
trivial wrapper for open_execat()).  Would cut down on the patch
footprint a bit...

> + bprm->filename = filename ?:
> + (const char *) file->f_path.dentry->d_name.name;

Absolutely not.  If nothing else, ->d_name can change on rename() *and*
get underlying memory freed.  At zero notice.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] pci-iov: Fix warnings when CONFIG_PCI_IOV is enabled

[Jiang Wang]

-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com] 
Sent: Tuesday, September 11, 2012 4:35 PM
To: Jiang Wang
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Chaitanya Lala; 
Francis St. Amant; Jiang Wang
Subject: Re: [PATCH 1/1] pci-iov: Fix warnings when CONFIG_PCI_IOV is enabled

On Tue, Sep 4, 2012 at 5:11 PM, Jiang Wang  wrote:
> When CONFIG_PCI_IOV is enabled, the kernel will call sriov_init().
> This function tries to allocate virtual resources even if the virtual 
> function of a PCI devive is not enabled by the BIOS.
>
> This sometimes causes following warning messages during boot up:
> pci :02:00.0: BAR 9: can't allocate mem resource 
> [0x00-0x3f] pci :02:00.0: BAR 7: can't allocate mem 
> resource [0x00-0x03]
>
> Tested on three Mitac motherboards.
>
> Signed-off-by: Jiang Wang 
> ---
>  drivers/pci/iov.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index 
> 6554e1a..0ca8cb2 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -441,7 +441,8 @@ static int sriov_init(struct pci_dev *dev, int pos)
> if (ctrl & PCI_SRIOV_CTRL_VFE) {
> pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, 0);
> ssleep(1);
> -   }
> +   } else
> +   return 0;

But this would mean that Linux can't *ever* enable VFs unless the BIOS enabled 
them, right?  I don't think that's what we want -- there's code in 
sriov_enable() to turn on VFE, assuming we have enough resources for the VFs.

--- I see. I didn't find the code in sriov_enable() before I send out the 
patch. Thanks for the info.

It's certainly possible that the BIOS didn't allocate large enough apertures in 
the bridges leading to the SR-IOV device to accommodate all the VFs, and Linux 
may not be smart enough to enlarge them.  And probably our warning messages in 
that case are not very enlightening.

 My purpose here is to remove those warnings. I also tried to disable 
CONFIG_PCI_IOV, but that causes another strange problem on one of machines. The 
LSI controller cannot get memory resources and 32 LSI controllers shown up even 
though only one actually exist.
I will drop this patch and do more debug to see what that problem is. Thanks.
 
Bjorn

> pci_read_config_word(dev, pos + PCI_SRIOV_TOTAL_VF, &total);
> if (!total)
> --
> 1.7.1
>

Regards,

Jiang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 15/18] perf sched: Use perf_tool as ancestor

[Namhyung Kim]

On Tue, 11 Sep 2012 20:53:07 -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo 
>
> So that we can remove all the globals.
>
> Before:
>
>text  data bss dec hex filename
> 1586833110368 1438600 3135801  2fd939 /tmp/oldperf
>
> After:
>
>text  data bss dec hex filename
> 1629329 93568  848328 2571225  273bd9 /root/bin/perf
>

Just a nitpick below.

[snip]
> -static void print_bad_events(void)
> +static void print_bad_events(struct perf_sched *sched)
>  {
> - if (nr_unordered_timestamps && nr_timestamps) {
> + if (sched->nr_unordered_timestamps && sched->nr_timestamps) {
>   printf("  INFO: %.3f%% unordered timestamps (%ld out of %ld)\n",
> - 
> (double)nr_unordered_timestamps/(double)nr_timestamps*100.0,
> - nr_unordered_timestamps, nr_timestamps);
> + 
> (double)sched->nr_unordered_timestamps/(double)sched->nr_timestamps*100.0,

Isn't it sufficient to use this?

100.0 * sched->nr_unordered_timestamps / 
sched->nr_timestamps;

Ditto for belows.

Thanks,
Namhyung


> + sched->nr_unordered_timestamps, sched->nr_timestamps);
>   }
> - if (nr_lost_events && nr_events) {
> + if (sched->nr_lost_events && sched->nr_events) {
>   printf("  INFO: %.3f%% lost events (%ld out of %ld, in %ld 
> chunks)\n",
> - (double)nr_lost_events/(double)nr_events*100.0,
> - nr_lost_events, nr_events, nr_lost_chunks);
> + (double)sched->nr_lost_events/(double)sched->nr_events 
> * 100.0,
> + sched->nr_lost_events, sched->nr_events, 
> sched->nr_lost_chunks);
>   }
> - if (nr_state_machine_bugs && nr_timestamps) {
> + if (sched->nr_state_machine_bugs && sched->nr_timestamps) {
>   printf("  INFO: %.3f%% state machine bugs (%ld out of %ld)",
> - 
> (double)nr_state_machine_bugs/(double)nr_timestamps*100.0,
> - nr_state_machine_bugs, nr_timestamps);
> - if (nr_lost_events)
> + 
> (double)sched->nr_state_machine_bugs/(double)sched->nr_timestamps*100.0,
> + sched->nr_state_machine_bugs, sched->nr_timestamps);
> + if (sched->nr_lost_events)
>   printf(" (due to lost events?)");
>   printf("\n");
>   }
> - if (nr_context_switch_bugs && nr_timestamps) {
> + if (sched->nr_context_switch_bugs && sched->nr_timestamps) {
>   printf("  INFO: %.3f%% context switch bugs (%ld out of %ld)",
> - 
> (double)nr_context_switch_bugs/(double)nr_timestamps*100.0,
> - nr_context_switch_bugs, nr_timestamps);
> - if (nr_lost_events)
> + 
> (double)sched->nr_context_switch_bugs/(double)sched->nr_timestamps*100.0,
> + sched->nr_context_switch_bugs, sched->nr_timestamps);
> + if (sched->nr_lost_events)
>   printf(" (due to lost events?)");
>   printf("\n");
>   }
>  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH tip/core/rcu 04/15] rcu: Permit RCU_NONIDLE() to be used from interrupt context

[Paul E. McKenney]

On Fri, Sep 07, 2012 at 11:16:07AM -0400, Steven Rostedt wrote:
> On Fri, 2012-09-07 at 07:47 -0700, Josh Triplett wrote:
> > On Fri, Sep 07, 2012 at 07:24:41AM -0700, Paul E. McKenney wrote:
> > > On Thu, Sep 06, 2012 at 11:09:40PM -0700, Josh Triplett wrote:
> > > > On Thu, Sep 06, 2012 at 03:54:04PM -0400, Steven Rostedt wrote:
> > > > > On Thu, 2012-09-06 at 11:54 -0700, Josh Triplett wrote:
> > > > > > Not sure I see much difference in aesthetics between the three 
> > > > > > approaches,
> > > > > > > but am willing to switch over to a generally agreed-upon scheme.
> > > > > > 
> > > > > > Steve, could I get an ack from you on the patch I sent?
> > > > > 
> > > > > I acked it, but do you just want me to take the patch? I'm getting 
> > > > > ready
> > > > > for another 3.7 push to tip.
> > > > 
> > > > Up to Paul.  What would make it easiest to coordinate that patch and the
> > > > corresponding bits in the RCU patch series?
> > > 
> > > All I need to do is to eventually remove the exports, correct?
> > > If so, full speed ahead!
> > 
> > Sounds like you could go ahead and remove the exports now, and just make
> > sure Steve's push goes in before yours.
> > 
> 
> Is there any rush to do this? I just plan on pushing it for 3.7.
> 
> Paul, you just push your changes through tip, right? Then we can just
> let Ingo know. I could even make the patch a separate branch, that Ingo
> can pull into the RCU branch too.

Yep!  But we also need to worry about -next and -fengguang.

How about if you push your change into 3.7 and I push mine into 3.8?

Thanx, Paul

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