Re: [ 146/184] softirq: reduce latencies
Hi Li,
I just found your mail unread in my box by pure luck, I'm sorry.
On Fri, Aug 02, 2013 at 04:14:13PM +0800, Li Zefan wrote:
> Cc: Ben Greear
> Cc: Tejun
>
> Hi Willy,
>
> This patch introduced a bug, which was then fixed by commit 34376a50fb1f
> ("Fix lockup related to stop_machine being stuck in __do_softirq."),
> do we need this fix for 2.6.32 ?
Yes, I just checked the code and in doubt I think it's safer to apply it
as well. So I'm queuing the fix for .62, thanks !
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] devtmpfs: Calling delete_path() only when necessary
The deleted variable is always 1 in current code.
Initialize deleted variable to be 0, so delete_path() will be called only when
necessary.
Signed-off-by: Axel Lin
---
drivers/base/devtmpfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index 0f38201..25798db 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -299,7 +299,7 @@ static int handle_remove(const char *nodename, struct
device *dev)
{
struct path parent;
struct dentry *dentry;
- int deleted = 1;
+ int deleted = 0;
int err;
dentry = kern_path_locked(nodename, &parent);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ARM: SoC fixes for 3.13 merge window
Hi Linus,
The following changes since commit 10d0c9705e80bbd3d587c5fad24599aabaca6688:
Merge tag 'devicetree-for-3.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux (2013-11-12 16:52:17
+0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
tags/fixes-for-linus
for you to fetch changes up to 6886059f2ef5d62c73e87a905e84fa4f87d56074:
Merge tag 'omap-for-v3.13/fixes-for-merge-window-take2' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
(2013-11-15 15:17:59 -0800)
ARM: SoC fixes for 3.13 merge window
A first set of batches of fixes for 3.13. The diffstat is large mostly
because we're adding a defconfig for a family that's been lacking it, and
there's some missing clock information added for i.MX and OMAP.
The at91 new code is around dealing with RTC/RTT reset at boot to fix possible
hangs due to pending wakeup interrupts coming in during early boot.
Alexander Shiyan (1):
ARM: dts: i.MX51: Fix OTG PHY clock
Alexandre Courbot (1):
ARM: tegra: init fuse before setting reset handler
Eric Witcher (1):
ARM: OMAP: devicetree: fix SPI node compatible property syntax items
Jiada Wang (1):
ARM: i.MX6q: fix the wrong parent of can_root clock
Joel Fernandes (1):
doc: devicetree: Add bindings documentation for omap-des driver
Johan Hovold (2):
ARM: at91: fix hanged boot due to early rtc-interrupt
ARM: at91: fix hanged boot due to early rtt-interrupt
Jonathan Austin (1):
ARM: integrator_cp: Set LCD{0,1} enable lines when turning on CLCD
Linus Walleij (1):
MAINTAINERS: drop discontinued mailing list
Lokesh Vutla (1):
ARM: dts: doc: Document missing compatible property for omap-sham driver
Lothar Waßmann (1):
ARM: imx6q: add missing sentinel to divider table
Nishanth Menon (1):
ARM: OMAP2+: omap_device: maintain sane runtime pm status around
suspend/resume
Olof Johansson (7):
Merge tag 'imx-fixes-3.13' of
git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
ARM: vt8500: add defconfig for v6/v7 chips
ARM: sti: only select errata 764369 if SMP
ARM: highbank: only select errata 764369 if SMP
video: exynos_mipi_dsim: Remove unused variable
Merge tag 'at91-fixes-non-critical' of
git://github.com/at91linux/linux-at91 into fixes
Merge tag 'omap-for-v3.13/fixes-for-merge-window-take2' of
git://git.kernel.org/.../tmlind/linux-omap into fixes
Roger Quadros (1):
pinctrl: single: call pcs_soc->rearm() whenever IRQ mask is changed
Shawn Guo (6):
ARM: imx: remove imx_src_prepare_restart() call
ARM: imx: improve mxc_restart() on the SRC bit writes
ARM: imx: v7_cpu_resume() is needed by imx6sl build
ARM: imx: add sleep for pllv3 relock
ARM: imx: pllv3 needs relock in .set_rate() call
ARM: imx: set up pllv3 POWER and BYPASS sequentially
Tomi Valkeinen (3):
ARM: OMAP4: use CLK_SET_RATE_PARENT for dss_dss_clk
ARM: OMAP3: use CLK_SET_RATE_PARENT for dss clocks
ARM: OMAP3: fix dpll4_m3_ck and dpll4_m4_ck dividers
Tony Lindgren (2):
Merge tag 'for-v3.13/clock-fixes-a' of
git://git.kernel.org/.../pjw/omap-pending into xxx-dt
ARM: OMAP2+: Fix build for dra7xx without omap4 and 5
Wei Yongjun (2):
ARM: OMAP2+: smsc911x: fix return value check in gpmc_smsc911x_init()
ARM: OMAP3: Beagle: fix return value check in beagle_opp_init()
.../devicetree/bindings/crypto/omap-des.txt| 30
.../devicetree/bindings/crypto/omap-sham.txt | 2 +-
Documentation/devicetree/bindings/spi/omap-spi.txt | 4 +-
MAINTAINERS| 1 -
arch/arm/boot/dts/imx51.dtsi | 2 +-
arch/arm/configs/vt8500_v6_v7_defconfig| 90 ++
arch/arm/mach-at91/Makefile| 2 +-
arch/arm/mach-at91/at91sam9260.c | 2 +
arch/arm/mach-at91/at91sam9261.c | 2 +
arch/arm/mach-at91/at91sam9263.c | 3 +
arch/arm/mach-at91/at91sam9g45.c | 3 +
arch/arm/mach-at91/at91sam9n12.c | 6 ++
arch/arm/mach-at91/at91sam9rl.c| 3 +
arch/arm/mach-at91/at91sam9x5.c| 6 ++
arch/arm/mach-at91/generic.h | 2 +
arch/arm/mach-at91/include/mach/at91sam9n12.h | 5 ++
arch/arm/mach-at91/include/mach/at91sam9x5.h | 5 ++
arch/arm/mach-at91/include/mach/sama5d3.h | 5 ++
arch/arm/mach-at91/sama5d3.c | 6 ++
arch/arm/mach-at91/sysirq_mask.c | 71 +
arch/arm/mach-highbank/Kconfig | 2 +-
arch/arm/mach-imx/Makefile | 4 +-
arch/arm/mach-imx/clk-im
Re: [PATCH 3/3] misc: bmp085: Add missing platform data.
Am 15.11.2013 um 14:58 schrieb Arnd Bergmann: > On Thursday 14 November 2013, Marek Belisko wrote: >> DT bindings contains more parameters to set so add them to platform data also >> to have possibility to use on arch where DT isn't available yet. >> >> Signed-off-by: Marek Belisko > > Can you give an example of a platform that uses this chip and cannot > yet use DT in the mainline kernel? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dts exists but is far from being complete, because the transition to DT is really complex. We still need some (private) board file for 3.13 and hope to have everything ready for 3.14. But that depends on speed of acceptance of other drivers because all DT things are still constantly moving. So we will have to mix DT+board file for a while. > If it's only for out-of-tree platforms, I'd prefer to leave this > patch out of tree as well and put the burden on whoever maintains > a non-DT platform in a private kernel. > > >> diff --git a/include/linux/i2c/bmp085.h b/include/linux/i2c/bmp085.h >> index b66cb98..addb972 100644 >> --- a/include/linux/i2c/bmp085.h >> +++ b/include/linux/i2c/bmp085.h > > Shouldn't this be in include/linux/platform_data? > > Arnd -- hns-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5 0/3] add wildcard support for dynamic debug
From: "Du, Changbin" These patches are to make it easier to filter kernel debug logs which we want. Whith wildcard support, below command can enable all usb debug logs: #echo "file drivers/usb/* +p" > /dynamic_debug/control This patch only enables two wildcard: '*' - matches zero or more characters '?' - matches one character Changes since v4: moved matching function to lib/parser.c Du, Changbin (3): lib/parser.c: add match_wildcard function dynamic_debug: add wildcard support to filter files/functions/modules dynamic-debug-howto.txt: update since new wildcard support Documentation/dynamic-debug-howto.txt | 9 +++ include/linux/parser.h| 1 + lib/dynamic_debug.c | 15 +++ lib/parser.c | 51 +++ 4 files changed, 71 insertions(+), 5 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/3] lib/parser.c: add match_wildcard function
From: "Du, Changbin"
match_wildcard function is a simple implementation of wildcard
matching algorithm. It only supports two usual wildcardes:
'*' - matches zero or more characters
'?' - matches one character
This algorithm is safe since it's of non-recursion.
Signed-off-by: Du, Changbin
---
include/linux/parser.h | 1 +
lib/parser.c | 51 ++
2 files changed, 52 insertions(+)
diff --git a/include/linux/parser.h b/include/linux/parser.h
index ea2281e..39d5b79 100644
--- a/include/linux/parser.h
+++ b/include/linux/parser.h
@@ -29,5 +29,6 @@ int match_token(char *, const match_table_t table,
substring_t args[]);
int match_int(substring_t *, int *result);
int match_octal(substring_t *, int *result);
int match_hex(substring_t *, int *result);
+bool match_wildcard(const char *pattern, const char *str);
size_t match_strlcpy(char *, const substring_t *, size_t);
char *match_strdup(const substring_t *);
diff --git a/lib/parser.c b/lib/parser.c
index 807b2aa..ee52955 100644
--- a/lib/parser.c
+++ b/lib/parser.c
@@ -193,6 +193,56 @@ int match_hex(substring_t *s, int *result)
}
/**
+ * match_wildcard: - parse if a string matches given wildcard pattern
+ * @pattern: wildcard pattern
+ * @str: the string to be parsed
+ *
+ * Description: Parse the string @str to check if matches wildcard
+ * pattern @pattern. The pattern may contain two type wildcardes:
+ * '*' - matches zero or more characters
+ * '?' - matches one character
+ * If it's matched, return true, else return false.
+ */
+bool match_wildcard(const char *pattern, const char *str)
+{
+ const char *s = str;
+ const char *p = pattern;
+ bool star = false;
+
+ while (*s) {
+ switch (*p) {
+ case '?':
+ s++;
+ p++;
+ break;
+ case '*':
+ star = true;
+ str = s;
+ if (!*++p)
+ return true;
+ pattern = p;
+ break;
+ default:
+ if (*s == *p) {
+ s++;
+ p++;
+ } else {
+ if (!star)
+ return false;
+ str++;
+ s = str;
+ p = pattern;
+ }
+ break;
+ }
+ }
+
+ if (*p == '*')
+ ++p;
+ return !*p;
+}
+
+/**
* match_strlcpy: - Copy the characters from a substring_t to a sized buffer
* @dest: where to copy to
* @src: &substring_t to copy
@@ -235,5 +285,6 @@ EXPORT_SYMBOL(match_token);
EXPORT_SYMBOL(match_int);
EXPORT_SYMBOL(match_octal);
EXPORT_SYMBOL(match_hex);
+EXPORT_SYMBOL(match_wildcard);
EXPORT_SYMBOL(match_strlcpy);
EXPORT_SYMBOL(match_strdup);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/3] dynamic_debug: add wildcard support to filter files/functions/modules
From: "Du, Changbin"
Add wildcard '*'(matches zero or more characters) and '?'
(matches one character) support when qurying debug flags.
Now we can open debug messages using keywords. eg:
1. open debug logs in all usb drivers
echo "file drivers/usb/* +p" > /dynamic_debug/control
2. open debug logs for usb xhci code
echo "file *xhci* +p" > /dynamic_debug/control
Signed-off-by: Du, Changbin
---
lib/dynamic_debug.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index c37aeac..600ac57 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -8,6 +8,7 @@
* By Greg Banks
* Copyright (c) 2008 Silicon Graphics Inc. All Rights Reserved.
* Copyright (C) 2011 Bart Van Assche. All Rights Reserved.
+ * Copyright (C) 2013 Du, Changbin
*/
#define pr_fmt(fmt) KBUILD_MODNAME ":%s: " fmt, __func__
@@ -24,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -147,7 +149,8 @@ static int ddebug_change(const struct ddebug_query *query,
list_for_each_entry(dt, &ddebug_tables, link) {
/* match against the module name */
- if (query->module && strcmp(query->module, dt->mod_name))
+ if (query->module &&
+ !match_wildcard(query->module, dt->mod_name))
continue;
for (i = 0; i < dt->num_ddebugs; i++) {
@@ -155,14 +158,16 @@ static int ddebug_change(const struct ddebug_query *query,
/* match against the source filename */
if (query->filename &&
- strcmp(query->filename, dp->filename) &&
- strcmp(query->filename, kbasename(dp->filename)) &&
- strcmp(query->filename, trim_prefix(dp->filename)))
+ !match_wildcard(query->filename, dp->filename) &&
+ !match_wildcard(query->filename,
+ kbasename(dp->filename)) &&
+ !match_wildcard(query->filename,
+ trim_prefix(dp->filename)))
continue;
/* match against the function */
if (query->function &&
- strcmp(query->function, dp->function))
+ !match_wildcard(query->function, dp->function))
continue;
/* match against the format */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/3] dynamic-debug-howto.txt: update since new wildcard support
From: "Du, Changbin" Add the usage of using new feature wildcard support. Signed-off-by: Du, Changbin --- Documentation/dynamic-debug-howto.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt index 1bbdcfc..46325eb 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt @@ -108,6 +108,12 @@ If your query set is big, you can batch them too: ~# cat query-batch-file > /dynamic_debug/control +A another way is to use wildcard. The match rule support '*' (matches +zero or more characters) and '?' (matches exactly one character).For +example, you can match all usb drivers: + + ~# echo "file drivers/usb/* +p" > /dynamic_debug/control + At the syntactical level, a command comprises a sequence of match specifications, followed by a flags change specification. @@ -315,6 +321,9 @@ nullarbor:~ # echo -n 'func svc_process -p' > nullarbor:~ # echo -n 'format "nfsd: READ" +p' > /dynamic_debug/control +// enable messages in files of which the pathes include string "usb" +nullarbor:~ # echo -n '*usb* +p' > /dynamic_debug/control + // enable all messages nullarbor:~ # echo -n '+p' > /dynamic_debug/control -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
> >+
> >+i2c0: ocores@a000 {
> >+#address-cells = <1>;
> >+#size-cells = <0>;
> >+compatible = "opencores,i2c-ocores";
>
> Version number needed. OpenCores wanted "projectname-rtlsvn###"
> where ### is the SVN commit number of the RTL directory in the
> project's source repository.
>
That will also require a change to the driver.
Using svn commit ids as version info seems a bit too fine grained to me,
but if that's what's agreed on, then it should be the commit id from the
projects official repository at opencores.org I think.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/4] Add request_firmware_direct() for microcode loader
At Sat, 16 Nov 2013 06:24:55 +0900, Greg Kroah-Hartman wrote: > > On Fri, Nov 15, 2013 at 04:34:09PM +0100, Takashi Iwai wrote: > > At Tue, 12 Nov 2013 13:02:12 +0100, > > Takashi Iwai wrote: > > > > > > Hi, > > > > > > this is a revised patch series to introduce request_firmware_direct() > > > helper for avoiding the lengthy udev issue on microcode loader. > > > The original problem was stated in Prarit's post: > > >https://lkml.org/lkml/2013/10/28/221 > > > > > > In short, microcode loader probes non-existing firmware files (which > > > are cases with every new chip), and each probe takes 60 seconds, > > > resulting in too long time until completed. > > > > > > This solution is simply avoiding the udev fallback in > > > request_firmware() explicitly for drivers like microcode. > > > > > > Of course, this doesn't mean to throw away further optimizations like > > > Prarit's patch. It can be implemented in parallel with this. > > > > > > > > > [PATCH v3 1/4] firmware: Introduce request_firmware_direct() > > > [PATCH v3 2/4] microcode: Use request_firmware_direct() > > > [PATCH v3 3/4] firmware: Use bit flags instead of boolean combos > > > [PATCH v3 4/4] firmware: Suppress fallback warnings when > > > CONFIG_FW_LOADER_USER_HELPER=n > > > > > > v1->v2: Rebased on linux-next, add a fix for a bogus warning message > > > v2->v3: Convert to bit flags, fix warning message differently > > > > > > > > > Greg, could you take these patches through your driver tree, as > > > most of fixes are about the firmware loader itself. > > > > Greg, any chance to take a look at these patches? > > I'm traveling at the moment, in Korea this week. I'll take a look at > them after 3.13-rc1 is out, as I can't do anything with patches until > then. Ah, I vaguely remember that. > Don't worry, they aren't lost. OK, thanks! Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Black screen with GMA500 driver on Atom E680 (invalid VBT signature)
On Thu, Nov 14, 2013 at 08:57:58PM +, One Thousand Gnomes wrote: > > but if you checkout the PCI table in the driver, there is the device > > and vendor ID mentioned, that means for me that the driver supports > > the Graphic core in E680. > > And after loading the driver, it will parse for $VBT. > > I just find a comment in the PCI table with "E620" but > > the device and vendor id is the same for E680. > > > > What do you mean with "Moorestown style" ? > > There are essentially two styles of configuration table used with PVR > graphics. One is basically the same as that used on 'real' Intel graphics > the other first introduced with one of the SoC devices is a firmware > table in a completely different format. > > The netbook and PC oriented devices use the VBT, the tablet SoC > devices and embedded ones seem to vary and have a VBT/GCT in different > form that is found via config 0xFC on the chipset - see mid_bios.c > > Alan Hi, if i dump the memory on 0xFC of the config space, there is just some from the BIOS vendor with a BIOS Version, but nothing like $GCT. In the Datasheet the 0xFC is described as "storage" does it mean there should be the settings for the Graphic like VBT? I did not find more information abaout GCT and how to implement it. The board uses sdvo->vga for the output, the second board uses sdvo->DVI and LVDS but there is always a black screen on each output interface. So i think there is wether a VBT not a GCT. Regards andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5] dmaengine: Add support for BCM2835
> On Fri, Nov 15, 2013 at 7:51 PM, Russell King - ARM Linux > wrote: >> >> On Fri, Nov 15, 2013 at 05:43:45PM +, Shevchenko, Andriy wrote: >> >> > > +module_platform_driver(bcm2835_dma_driver); >> > >> > Is it possible to get driver initialized after that one that uses it? >> >> Doesn't quite make sense. If you're asking whether other drivers can >> try to make use of this driver before it's initialised, then the answer >> is no. We have mechanisms to cope with that - see deferred probing. The reason why I was asking about I'm just wondering what we have to do with existing drivers. Shall we convert them to be initialized as normal platform drivers instead of subsys_initcall? -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] init/Kconfig: add option to disable kernel compression
On 11/15/2013 10:27 PM, Christian Ruppert wrote: > On Thu, Nov 14, 2013 at 03:51:22PM +0530, Vineet Gupta wrote: >> +CC Sam for Kconfig wisdom >> >> On 11/14/2013 02:08 PM, Christian Ruppert wrote: >>> Some ARC users say they can boot faster with without kernel compression. >>> This probably depends on things like the FLASH chip they use etc. >>> >>> Until now, kernel compression can only be disabled by removing "select >>> HAVE_" lines from the architecture Kconfig. So add the >>> Kconfig logic to permit disabling of kernel compression. >>> >>> Signed-off-by: Christian Ruppert >>> --- >>> arch/arc/Kconfig | 2 ++ >>> init/Kconfig | 12 +++- >>> 2 files changed, 13 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig >>> index 91dbb27..3991f03 100644 >>> --- a/arch/arc/Kconfig >>> +++ b/arch/arc/Kconfig >>> @@ -21,6 +21,8 @@ config ARC >>> select HAVE_ARCH_KGDB >>> select HAVE_ARCH_TRACEHOOK >>> select HAVE_IOREMAP_PROT >>> + select HAVE_KERNEL_UNCOMPRESSED >>> + select HAVE_KERNEL_GZIP >> >> Fine. >> >>> select HAVE_KPROBES >>> select HAVE_KRETPROBES >>> select HAVE_MEMBLOCK >>> diff --git a/init/Kconfig b/init/Kconfig >>> index 3ecd8a1..b1a6f92 100644 >>> --- a/init/Kconfig >>> +++ b/init/Kconfig >>> @@ -97,6 +97,9 @@ config LOCALVERSION_AUTO >>> >>> which is done within the script "scripts/setlocalversion".) >>> >>> +config HAVE_KERNEL_UNCOMPRESSED >>> +bool >>> + >> >> This is good to avoid perturbing other arches. >> >>> config HAVE_KERNEL_GZIP >>> bool >>> >>> @@ -118,7 +121,6 @@ config HAVE_KERNEL_LZ4 >>> choice >>> prompt "Kernel compression mode" >>> default KERNEL_GZIP >>> - depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || >>> HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4 >>> help >>> The linux kernel is a kind of self-extracting executable. >>> Several compression algorithms are available, which differ >>> @@ -137,6 +139,14 @@ choice >>> >>> If in doubt, select 'gzip' >>> >>> +config KERNEL_UNCOMPRESSED >>> + bool "No compression" >>> + depends on HAVE_KERNEL_UNCOMPRESSED || ! ( HAVE_KERNEL_GZIP || >>> HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || HAVE_KERNEL_XZ || HAVE_KERNEL_LZO >>> || HAVE_KERNEL_LZ4 ) >>> + help >>> + No compression at all. The kernel is huge but the compression and >>> + decompression times are zero. >>> + This is usually not what you want. >>> + >>> config KERNEL_GZIP >>> bool "Gzip" >>> depends on HAVE_KERNEL_GZIP >>> >> >> How about doing this part slightly differently (simpler IMO). >> We add uncompressed as just another category rather than being a special >> case. >> >> Indicative diff against current mainline code >> >> choice >> prompt "Kernel compression mode" >> default KERNEL_GZIP >> - depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA >> || >> HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4 >> + depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA >> || >> HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4 || >> HAVE_KERNEL_UNCOMPRESSED >> >> >> +config KERNEL_UNCOMPRESSED >> + bool "No compression" >> + depends on HAVE_KERNEL_UNCOMPRESSED >> + > > Good Idea. I fixed this and sent the updated patch directly in reply to > H. Peter's revert patch to avoid too much patch ping-pong: > http://www.spinics.net/lists/kernel/msg1636397.html I didn't see that patch in my mailbox. It needs an ACK from me anyways. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] init/Kconfig: fix option to disable kernel compression
On 11/15/2013 10:21 PM, Christian Ruppert wrote: > Some architectures with self-decompressing kernel images did not compile > with commit 69f0554ec261fd686ac7fa1c598cc9eb27b83a80 because they don't > provide a non-decompression mechanism for uncompressed kernels. > > Rectify this problem by allowing uncompressed kernels only for architectures > which explicitly state they support them. > > Signed-off-by: Christian Ruppert Acked-by: Vineet Gupta > --- > arch/arc/Kconfig | 2 ++ > init/Kconfig | 5 + > 2 files changed, 7 insertions(+) > > diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig > index 2ee0c9b..15f4c3d 100644 > --- a/arch/arc/Kconfig > +++ b/arch/arc/Kconfig > @@ -21,6 +21,8 @@ config ARC > select HAVE_ARCH_KGDB > select HAVE_ARCH_TRACEHOOK > select HAVE_IOREMAP_PROT > + select HAVE_KERNEL_UNCOMPRESSED > + select HAVE_KERNEL_GZIP > select HAVE_KPROBES > select HAVE_KRETPROBES > select HAVE_MEMBLOCK > diff --git a/init/Kconfig b/init/Kconfig > index 5496f30..d4baf2e 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -97,6 +97,9 @@ config LOCALVERSION_AUTO > > which is done within the script "scripts/setlocalversion".) > > +config HAVE_KERNEL_UNCOMPRESSED > +bool > + > config HAVE_KERNEL_GZIP > bool > > @@ -118,6 +121,7 @@ config HAVE_KERNEL_LZ4 > choice > prompt "Kernel compression mode" > default KERNEL_GZIP > + depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || > HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4 || > HAVE_KERNEL_UNCOMPRESSED > help > The linux kernel is a kind of self-extracting executable. > Several compression algorithms are available, which differ > @@ -138,6 +142,7 @@ choice > > config KERNEL_UNCOMPRESSED > bool "No compression" > + depends on HAVE_KERNEL_UNCOMPRESSED > help > No compression at all. The kernel is huge but the compression and > decompression times are zero. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] A minor amd64_edac fix for 3.13
On Fri, Nov 15, 2013 at 06:02:59PM -0800, Linus Torvalds wrote: > [ This was in my spam collection. I don't quite know why, but it might > signify problems with your email setup. Quite often, when gmail is > unhappy about kernel developer emails, it's been because their email > provider ends up doing something odd. > > But the headers actually have "spf=pass" and "dkim=pass", so it's > nothing obvious. ] Hmm, strange. Does this mean, you don't get other emails from my email address or only this pull request? Say, do you have this one, for example: http://marc.info/?l=linux-kernel&m=138442829620489&w=2 where I ask you whether you're fine with Mauro and me playing interim EDAC maintainers? > That said, I don't much like the patch either. The "fixed' version > looks worse than the original. If it's an unsigned type, no extra code > will be generated, Yes, correct, in both cases I have here: .L779: .loc 1 1579 0 cmpb$4, %r10b #, alias_channel ja .L859 #, .L847: > and if it's a signed type, it's correct. In either way, the code looks > good, and the range test means that people reading it don't even need > to worry about whether the type is signed or not. > > If this patch was written because of some f*cking broken compiler > warning, then just tell the compiler to shut the hell up about it. > This is a clear example of where compiler warnings are actually making > things worse. Yeah, no, the compiler's fine here. Dave raised the issue about not testing unsigned's for < 0: http://www.spinics.net/lists/kernel/msg1597525.html And I took it because it is less code in the .c source file to look at. But I certainly don't care all that much whether the < 0 test is there or not as long as the produced code is identical so... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 13/23] spi: omap2-mcspi: raw read and write endian fix
On Sat, Nov 16, 2013 at 02:01:16AM +0200, Taras Kondratiuk wrote: > From: Victor Kamensky > > All OMAP IP blocks expect LE data, but CPU may operate in BE mode. > Need to use endian neutral functions to read/write h/w registers. > I.e instead of __raw_read[lw] and __raw_write[lw] functions code > need to use read[lw]_relaxed and write[lw]_relaxed functions. > If the first simply reads/writes register, the second will byteswap > it if host operates in BE mode. Applied, thanks. signature.asc Description: Digital signature
Re: [GIT PULL] A minor amd64_edac fix for 3.13
And just to test whether you're getting emails from me, I'll send this one again from my other mail address to try to maximize the probability of some version actually reaching you :-) On Fri, Nov 15, 2013 at 06:02:59PM -0800, Linus Torvalds wrote: > [ This was in my spam collection. I don't quite know why, but it might > signify problems with your email setup. Quite often, when gmail is > unhappy about kernel developer emails, it's been because their email > provider ends up doing something odd. > > But the headers actually have "spf=pass" and "dkim=pass", so it's > nothing obvious. ] Hmm, strange. Does this mean, you don't get other emails from my email address or only this pull request? Say, do you have this one, for example: http://marc.info/?l=linux-kernel&m=138442829620489&w=2 where I ask you whether you're fine with Mauro and me playing interim EDAC maintainers? > That said, I don't much like the patch either. The "fixed' version > looks worse than the original. If it's an unsigned type, no extra code > will be generated, Yes, correct, in both cases I have here: .L779: .loc 1 1579 0 cmpb$4, %r10b #, alias_channel ja .L859 #, .L847: > and if it's a signed type, it's correct. In either way, the code looks > good, and the range test means that people reading it don't even need > to worry about whether the type is signed or not. > > If this patch was written because of some f*cking broken compiler > warning, then just tell the compiler to shut the hell up about it. > This is a clear example of where compiler warnings are actually making > things worse. Yeah, no, the compiler's fine here. Dave raised the issue about not testing unsigned's for < 0: http://www.spinics.net/lists/kernel/msg1597525.html And I took it because it is less code in the .c source file to look at. But I certainly don't care all that much whether the < 0 test is there or not as long as the produced code is identical so... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/40] staging/lustre/llite: Access to released file trigs a restore
On 2013/11/14 9:09 PM, "Greg Kroah-Hartman" wrote: >On Fri, Nov 15, 2013 at 12:13:06AM +0800, Peng Tao wrote: >> From: JC Lafoucriere >> >> When a client accesses data in a released file, >> or truncate it, client must trig a restore request. >> During this restore, the client must not glimpse and >> must use size from MDT. To bring the "restore is running" >> information on the client we add a new t_state bit field >> to mdt_info which will be used to carry transient file state. >> To memorise this information in the inode we add a new flag >> LLIF_FILE_RESTORING. > >This patch also does other things not mentioned here (coding style >cleanups), which isn't allowed in a single patch (only do one thing per >patch, and never not document what you are doing...) > >It also adds checkpatch warnings, which I will not accept in patches at >all here. People are spending a lot of time cleaning up the coding >style issues, please NEVER add new ones, that just causes more work to >be needed to be done, and for people to have to go back and reclean >files they have already cleaned up. I'm fine to clean up the coding style issues in these patches. >So, sorry, I have to stop here at this series. I've applied the first 3 >to the opw-next branch of staging.git so they can live somewhere until >3.13-rc1 is out. > >I know you spent a lot of time making these 120 patches to send me, but >that too is crazy. You shouldn't wait that long to get feedback and >send patches to me at all. Please send them in smaller series, with >less time between patch submissions. The reason that there are so many patches in a burst is that we are also developing new features and fixing bugs in parallel with the kernel, but they also need to be tested a lot before they are released. It's not any different from kernel patches testing on -next or -mm for a few months before they are pushed to the mainline kernel in a batch. The out-of-tree development can't really stop for a year while the kernel client code is cleaned up. If the feature patches don't land into the kernel client for a year (or however long it takes to do all the cleanup), then it will become outdated and the whole reason for adding the client into the kernel is lost. >> There are many users of the external tree so we cannot just abandon >> it, especially that the upstream client is not shipped in any >> distribution yet. Thanks for your understanding. > >What is keeping people using that tree? Support for older/distro >kernels? > Support for distro kernels is a big part of it. Most HPC sites use vendor kernels of various vintages, and we need to keep the code working for those sites. We also need to continue developing features needed by ever-larger clusters, fixing bugs, etc. Eventually, when Lustre is in the kernel proper, it will also be available in future distro kernels and we can eventually stop supporting the out-of-tree code. I expect that to be 3+ years away. >Is it the fact that the server code isn't in the kernel? Not really. Lustre servers are on separate servers with vendor kernels (ancient by your standards), and there isn't really any demand for using newer kernels on those nodes. Most importantly, the out-of-tree branch is where all of the new feature development is being done. That also means if feature patches don't land into the kernel it just makes the kernel version less attractive for users. > Should that be added now too so that we can get a proper view of what > can and can not be changed? Some of your patches are showing that things > are shared by the two chunks of code, so does that mean if I delete >things in the client code that don't look to be used by anything, you > will have problems because the server now breaks? Adding the server code to staging would mean another 150kLOC in staging. We also haven't cleaned that code up even nearly as much as the client code, so it isn't really even ready to go into staging either. I don't think you or anyone else would be happy to see that code yet, so I don't think there is a real advantage to do so. Deleting unused code in the kernel client isn't fatal, since we'll still have the out-of-tree version, but we're trying to keep the code in sync as much as possible so that it is easier to port patches in both directions. If code is deleted it means more that needs to be added back later when the server eventually does get merged, and more effort to resolve patch conflicts. >I think it's time to just merge the server and deal with the whole thing >all at once, otherwise this dependancy on your external tree, and >external code to the kernel, is going to doom the ability to ever get >this code cleaned up and merged properly. Regardless of whether the Lustre server is added to the kernel or not, we need to maintain support for the older kernels, so there will need to be an external tree for years to come until Lustre is available in vendor kernels. I'm sure we can't merge in the kern
Re: [ORLinux] [PATCH] openrisc: Add DTS and defconfig for DE0-Nano
2013/11/16 Stefan Kristiansson
>
> On Fri, Nov 15, 2013 at 10:50:18AM +0100, Jonas Bonn wrote:
> > >+
> > >+i2c0: ocores@a000 {
> > >+#address-cells = <1>;
> > >+#size-cells = <0>;
> > >+compatible = "opencores,i2c-ocores";
> >
> > Version number needed. OpenCores wanted "projectname-rtlsvn###"
> > where ### is the SVN commit number of the RTL directory in the
> > project's source repository.
> >
>
> That will also require a change to the driver.
>
> Using svn commit ids as version info seems a bit too fine grained to me,
> but if that's what's agreed on, then it should be the commit id from the
> projects official repository at opencores.org I think.
>
> Stefan
> ___
> Linux mailing list
> li...@lists.openrisc.net
> http://lists.openrisc.net/listinfo/linux
I agree. I don't like doing versioning with revision numbers. It's too
closely tied to the currently used VCS. The problem is that no one has
bothered to do proper releases of the cores for the last ten years or
so.
But since we are talking about a relatively small amount of cores
here, I think it could be worth to take a quick glance to see if the
latest SVN version is compatible with the latest tagged release. I
would suspect that is the case for the majority of the cores and the
we can just use the latest tag as version. For the other cores we
could
1. Use latest tag + 1 (a bit ugly if the maintainer wants to do a proper release
2. Take over maintainership/fork and just release what's in the trunk
(taking over maintenance is preferrable here to avoid more repo
confusion)
3. Use SVN revisions
option 2 would be my preferred choice here, given that we get someone
to do the actual work. I could probably help out with a few of the
cores
Jonas, you said that opencores wanted projectname-svnversion. Do you
know where that comes from? My proposal here would conflict with that
//Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] A minor amd64_edac fix for 3.13
On Sat, Nov 16, 2013 at 02:50:49AM -0800, Linus Torvalds wrote: > As far as I can tell, only that one email had gotten caught by the > spam filter. So it may be something in the body of the email itself, > although I don't really see what that could be either.. Right. > It happens occasionally, although it doors seem to happen much more to > certain particular people than to others. AFAIR, it had happened once before with a pull request a couple of kernel releases back. Oh well, I will start sending the pull requests from suse.de as their range is statically allocated and this should take care of the dynamic IP range issues. > The most common reason seems to be that your email provide is > associated with spam, sometimes just because of a shared ISP. Sure, it is one: https://www.hetzner.de/ > It is hard to tell with gmail, since it probably uses heuristics very > much like spamassassin, but doesn't make the internal scores available > (to avoid gaming them, I'm sure). So there are likely multiple small > triggers that combine, rather than one single reason. With "possibly > bad ISP" probably just being one of them.. Right, I'm adding Frank who takes care of it, just so he's aware. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [RFCv2] ASoC: Add support for BCM2835
On 11/12/2013 07:41 PM, Florian Meier wrote:
> This driver adds support for digital audio (I2S)
> for the BCM2835 SoC that is used by the
> Raspberry Pi. External audio codecs can be
> connected to the Raspberry Pi via P5 header.
>
> It relies on cyclic DMA engine support for BCM2835.
>
> Signed-off-by: Florian Meier
Looks mostly good in my opinion. A few comments on minor bits and pieces.
> diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
> new file mode 100644
> index 000..93619ec
> --- /dev/null
> +++ b/sound/soc/bcm/Kconfig
> @@ -0,0 +1,15 @@
> +config SND_BCM2835_SOC_I2S
> + tristate
> +
> +config SND_BCM2835_SOC
> + tristate "SoC Audio support for the Broadcom BCM2835 I2S module"
> + depends on ARCH_BCM2835
I think there is no compile time dependency on ARCH_BCM2835. Changing this
to 'depends on ARCH_BCM2835 || COMPILE_TEST' allows to archive better build
test coverage for the driver.
> + select SND_SOC_DMAENGINE_PCM
> + select DMADEVICES
> + select DMA_BCM2835
I don't think its a good idea to select DMADEVICES or DMA_BCM2835 here,
since those are user selectable symbols from another subsystem. Either
'depends on DMA_BCM2835' or nothing. Will I think nothing is better since
there is no compile time dependency.
> + select SND_SOC_GENERIC_DMAENGINE_PCM
> + select REGMAP_MMIO
> + help
> + Say Y or M if you want to add support for codecs attached to
> + the BCM2835 I2S interface. You will also need
> + to select the audio interfaces to support below.
[...]
> +static void bcm2835_i2s_clear_fifos(struct bcm2835_i2s_dev *dev,
> + bool tx, bool rx)
> +{
> + int timeout = 1000;
> + uint32_t syncval;
> + uint32_t csreg;
> + uint32_t i2s_active_state;
> + uint32_t clkreg;
> + uint32_t clk_active_state;
> + uint32_t off;
> + uint32_t clr;
> +
> + off = tx ? BCM2835_I2S_TXON : 0;
> + off |= rx ? BCM2835_I2S_RXON : 0;
> +
> + clr = tx ? BCM2835_I2S_TXCLR : 0;
> + clr |= rx ? BCM2835_I2S_RXCLR : 0;
> +
> + /* Backup the current state */
> + regmap_read(dev->i2s_regmap, BCM2835_I2S_CS_A_REG, &csreg);
> + i2s_active_state = csreg & (BCM2835_I2S_RXON | BCM2835_I2S_TXON);
> +
> + regmap_read(dev->clk_regmap, BCM2835_CLK_PCMCTL_REG, &clkreg);
> + clk_active_state = clkreg & BCM2835_CLK_ENAB;
> +
> + /* Start clock if not running */
> + if (!clk_active_state) {
> + regmap_update_bits(dev->clk_regmap, BCM2835_CLK_PCMCTL_REG,
> + BCM2835_CLK_PASSWD_MASK | BCM2835_CLK_ENAB,
> + BCM2835_CLK_PASSWD | BCM2835_CLK_ENAB);
> + }
> +
> + /* Stop I2S module */
> + regmap_update_bits(dev->i2s_regmap, BCM2835_I2S_CS_A_REG, off, 0);
> +
> + /*
> + * Clear the FIFOs
> + * Requires at least 2 PCM clock cycles to take effect
> + */
> + regmap_update_bits(dev->i2s_regmap, BCM2835_I2S_CS_A_REG, clr, -1);
I think the -1 can be confusing. Better use either clr or 0x. Same
applies to a few other places in the driver.
> +
> + /* Wait for 2 PCM clock cycles */
> +
> + /*
> + * Toggle the SYNC flag - after 2 PCM clock cycles it can be read back
> + * FIXME: This does not seem to work for slave mode!
> + */
> + regmap_read(dev->i2s_regmap, BCM2835_I2S_CS_A_REG, &syncval);
> + syncval &= BCM2835_I2S_SYNC;
> +
> + regmap_update_bits(dev->i2s_regmap, BCM2835_I2S_CS_A_REG,
> + BCM2835_I2S_SYNC, ~syncval);
> +
> + /* Wait for the SYNC flag changing it's state */
> + while (timeout > 0) {
> + timeout--;
> +
> + regmap_read(dev->i2s_regmap, BCM2835_I2S_CS_A_REG, &csreg);
> + if ((csreg & BCM2835_I2S_SYNC) != syncval)
> + break;
> + }
> +
> + if (timeout <= 0)
> + dev_err(dev->dev, "I2S SYNC error!\n");
> +
> + /* Stop clock if it was not running before */
> + if (!clk_active_state)
> + bcm2835_i2s_stop_clock(dev);
> +
> + /* Restore I2S state */
> + regmap_update_bits(dev->i2s_regmap, BCM2835_I2S_CS_A_REG,
> + BCM2835_I2S_RXON | BCM2835_I2S_TXON, i2s_active_state);
> +}
> +
[...]
> +static int bcm2835_i2s_dai_probe(struct snd_soc_dai *dai)
> +{
> + struct bcm2835_i2s_dev *dev = snd_soc_dai_get_drvdata(dai);
> +
> + dev->dma_data[SNDRV_PCM_STREAM_PLAYBACK].addr_width =
> + DMA_SLAVE_BUSWIDTH_4_BYTES;
> + dev->dma_data[SNDRV_PCM_STREAM_CAPTURE].addr_width =
> + DMA_SLAVE_BUSWIDTH_4_BYTES;
> +
> + /* TODO other burst parameters possible? */
> + dev->dma_data[SNDRV_PCM_STREAM_PLAYBACK].maxburst = 2;
> + dev->dma_data[SNDRV_PCM_STREAM_CAPTURE].maxburst = 2;
I'd move the initialization of dma_data to the driver probe() function.
> +
> + dai->playback_dma_data = &dev->dma_data[SNDRV_PCM_STREAM_PLAYBACK];
> + dai->capture_dma_data = &dev->dm
Re: [PATCH 05/40] staging/lustre: validate open handle cookies
On 2013/11/14 9:13 PM, "Greg Kroah-Hartman" wrote: >On Fri, Nov 15, 2013 at 12:13:07AM +0800, Peng Tao wrote: >> From: "John L. Hammond" >> >> Add a const void *h_owner member to struct portals_handle. Add a const >> void *owner parameter to class_handle2object() which must be matched >> by the h_owner member of the handle in addition to the cookie. > >Ick ick ick. > >NEVER use a void pointer if you can help it, and for a "handle", never. >This isn't other operating systems, sorry. We know what types our >pointers to structures are, use them, so that the compiler can catch our >problems, and don't try to cheat by using void *. The portals_handle is used as a generic type for objects referenced over the network, like a file handle. The "owner" parameter is just used as an extra check that the cookie passed from the client is actually a valid value for the code in which it is being used (e.g. metadata or data object). It isn't actually dereferenced by anything, it is just like a magic value. >> Adjust >> the callers of class_handle2object() accordingly, using NULL as the >> argument to the owner parameter, except in the case of >> mdt_handle2mfd() where we add an explicit mdt_export_data parameter >> which we use as the owner when searching for a MFD. When allocating a >> new MFD, pass a pointer to the mdt_export_data into mdt_mfd_new() and >> store it in h_owner. This allows the MDT to validate that the client >> has not sent the wrong open handle cookie, or sent the right cookie to >> the wrong MDT. > >This changelog entry doesn't even match up with the code below. ALl >callers of class_handle2object are passing NULL here, which makes this >patch pretty pointless, right? As Tao wrote, this is the patch summary that matches what was committed in our own tree and in this case mostly describes the changes made on the server. Keeping the same commits and comments in both trees makes it easier to keep the code in sync. >And that's a _very_ generic global symbol name, please don't do that, it >needs to be "lustre_*" at the front to even expect it to be acceptable. There's already something else called a "lustre_handle", so what about obdclass_handle2object(), since this is in the obdclass module? Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[V13-prerc]: REGRESSION: "*ERROR* Timed out waiting for forcewake old ack to clear"
On startup I get the following error display on the console: "*ERROR* Timed out waiting for forcewake old ack to clear" I already reported this error a year ago at the time of v3.7 ( see https://lkml.org/lkml/2012/11/27/355) which was fixed later on. Now this error is back again. Kernel 3.12.0-09888-gf63c48 Jörg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5] dmaengine: Add support for BCM2835
On Sat, Nov 16, 2013 at 11:37:54AM +0200, Andy Shevchenko wrote: > The reason why I was asking about I'm just wondering what we have to do > with existing drivers. Shall we convert them to be initialized as normal > platform drivers instead of subsys_initcall? We should in general be moving in that direction however it does need a bit of care to make sure that there aren't any dependencies which do things like discard error codes, fail to check errors or treat errors as hard failures. signature.asc Description: Digital signature
Re: [PATCH 3/4] printk: Defer printing to irq work when we printed too much
Hi! > > > > > Reviewed-by: Steven Rostedt > > > > > Signed-off-by: Jan Kara > > > > > > > > When a message takes tens of seconds to be printed, it usually means > > > > we are in trouble somehow :) > > > > I wonder what printk source can trigger such a high volume. > > > Machines with tens of processors and thousands of scsi devices. When > > > device discovery happens on boot, all processors are busily reporting new > > > scsi devices and one poor looser is bound to do the printing for ever and > > > ever until the machine dies... > > > > Dunno. In these cases, would it make sense to: > > > > 1) reduce amount of text printed > I thought about this as well. But > a) It doesn't seem practical as you would have to modify lots of drivers >and keep them rather silent. That seems rather fragile. Plus you will >not display some potentially useful information. > b) It doesn't address the real underlying problem that the way printk() is >currently implemented, there is no bound on the time CPU spends in the >loop printing from buffer to console. And the fact that this loop >sometimes happens with interrupts disabled makes the situation even >worse. > > > 2) just print [XXX characters lost] on overruns? > We don't overrun the printk buffer so no characters are lost. It just > takes too long to feed the whole printk buffer through serial console... Yes, I know. No characters are lost, but we spend seconds with interrupts disabled, breaking the system. (SCSI timeouts? We do keyboard autorepeat in software these days...) Would it be better to just drop the characters? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5] dmaengine: Add support for BCM2835
On Sat, Nov 16, 2013 at 11:27:54AM +, Mark Brown wrote: > On Sat, Nov 16, 2013 at 11:37:54AM +0200, Andy Shevchenko wrote: > > > The reason why I was asking about I'm just wondering what we have to do > > with existing drivers. Shall we convert them to be initialized as normal > > platform drivers instead of subsys_initcall? > > We should in general be moving in that direction however it does need a > bit of care to make sure that there aren't any dependencies which do > things like discard error codes, fail to check errors or treat errors as > hard failures. I don't agree: on platforms which have done this, it's very difficult to tell from reading the kernel message log whether things came up correctly because there's soo much spew from deferred probing it's virtually impossible to tell whether component X initialised or whether that error about resource Y missing was ever resolved. The only way that can be checked is when things work (or don't) from userspace. It's soo bad on some platforms that reading the kernel boot log is a total waste of time; you don't get any useful information from it. If we want kernel boot logs to be useful, we really need to shut up *all* the drivers and subsystems whinging about being deferred probing, and only have the driver model core reporting this status - maybe only allow output about why at debug level or similar. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf tip: fails to convert comm
Hi Frederic,
2013-11-16 (토), 02:02 +0100, Frederic Weisbecker:
> On Fri, Nov 15, 2013 at 09:29:51AM -0700, David Ahern wrote:
> > HI Frederic:
> >
> > On 11/13/13, 11:03 AM, Frederic Weisbecker wrote:
> > >
> > >I see. I can reproduce, I'll check and see what happens. It would be nice
> > >if
> > >we could have an option to dump internal perf events like comm events as
> > >well
> > >in the perf script stream.
> >
> > Any progress on a solution? This is a regression in 3.13.
>
> So the problem is that when a thread overrides its default ":%pid" comm, we
> forget
> to tag the thread comm as overriden. Hence, this overriden comm is not
> inherited on
> future forks.
>
> So here is a fix. Tell me if you see more issue, I'll cook a proper changelog
> and
> resend if everyting looks good.
>
> Thanks.
>
> diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> index cd8e2f5..49eaf1d 100644
> --- a/tools/perf/util/thread.c
> +++ b/tools/perf/util/thread.c
> @@ -70,14 +70,13 @@ int thread__set_comm(struct thread *thread, const char
> *str, u64 timestamp)
> /* Override latest entry if it had no specific time coverage */
> if (!curr->start) {
> comm__override(curr, str, timestamp);
> - return 0;
> + } else {
> + new = comm__new(str, timestamp);
> + if (!new)
> + return -ENOMEM;
> + list_add(&new->list, &thread->comm_list);
> }
>
> - new = comm__new(str, timestamp);
> - if (!new)
> - return -ENOMEM;
> -
> - list_add(&new->list, &thread->comm_list);
> thread->comm_set = true;
>
> return 0;
Looks good to me.
Thanks for the fix.
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/
[GIT PULL] pwm: Changes for v3.13-rc1
Hi Linus, The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f: Linux 3.12-rc1 (2013-09-16 16:17:51 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git tags/pwm/for-3.13-rc1 for you to fetch changes up to 1b3f25ce991d528bd0d825b3f14a45904037a382: Documentation/pwm: Update supported SoC name for pwm-samsung (2013-11-11 10:23:56 +0100) Thanks, Thierry pwm: Changes for v3.13-rc1 Mostly bug fixes and clean up. There is a new driver, which is actually moving a custom PWM driver from drivers/misc. The majority of the patches are enhancements to the device tree support in the pwm-backlight driver. Backlights can now additionally be powered using a regulator and enabled using a GPIO in addition to just the PWM input. Boris BREZILLON (2): pwm: atmel-tcb: add missing clk source config pwm: atmel-tcb: fix max time computation for slow clk source H Hartley Sweeten (1): pwm: add ep93xx PWM support Huayi Li (1): pwm_backlight: avoid short blank screen while doing hibernation Mike Dunn (1): pwm-backlight: Allow for non-increasing brightness levels Sachin Kamat (10): pwm: imx: Include linux/of.h header pwm: samsung: Include linux/of.h header pwm: twl-led: Include linux/of.h header pwm: twl: Include linux/of.h header pwm: mxs: Remove redundant of_match_ptr pwm: lpc32xx: Remove redundant of_match_ptr pwm: imx: Remove redundant of_match_ptr Documentation/pwm: Fix trivial typos pwm: samsung: Fix kernel warning while unexporting a channel Documentation/pwm: Update supported SoC name for pwm-samsung Thierry Reding (14): pwm-backlight: Improve readability pwm-backlight: Refactor backlight power on/off pwm-backlight: Track enable state pwm-backlight: Add optional enable GPIO ARM: OMAP: Initialize PWM backlight enable_gpio field ARM: pxa: Initialize PWM backlight enable_gpio field ARM: SAMSUNG: Initialize PWM backlight enable_gpio field ARM: shmobile: Initialize PWM backlight enable_gpio field unicore32: Initialize PWM backlight enable_gpio field pwm-backlight: Use new enable_gpio field pwm-backlight: Add power supply support pwm-backlight: Fix brightness adjustment pwm-backlight: Remove unused variable MAINTAINERS: Move PWM subsystem tree to kernel.org Wolfram Sang (1): pwm: don't use devm_pinctrl_get_select_default() in probe .../devicetree/bindings/pwm/pwm-samsung.txt| 2 +- .../bindings/video/backlight/pwm-backlight.txt | 7 + Documentation/pwm.txt | 4 +- MAINTAINERS| 3 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 1 + arch/arm/mach-pxa/cm-x300.c| 1 + arch/arm/mach-pxa/colibri-pxa270-income.c | 1 + arch/arm/mach-pxa/ezx.c| 1 + arch/arm/mach-pxa/hx4700.c | 1 + arch/arm/mach-pxa/lpd270.c | 1 + arch/arm/mach-pxa/magician.c | 1 + arch/arm/mach-pxa/mainstone.c | 1 + arch/arm/mach-pxa/mioa701.c| 1 + arch/arm/mach-pxa/palm27x.c| 1 + arch/arm/mach-pxa/palmtc.c | 35 +-- arch/arm/mach-pxa/palmte2.c| 1 + arch/arm/mach-pxa/pcm990-baseboard.c | 1 + arch/arm/mach-pxa/raumfeld.c | 1 + arch/arm/mach-pxa/tavorevb.c | 2 + arch/arm/mach-pxa/viper.c | 1 + arch/arm/mach-pxa/z2.c | 2 + arch/arm/mach-pxa/zylonite.c | 1 + arch/arm/mach-s3c24xx/mach-h1940.c | 1 + arch/arm/mach-s3c24xx/mach-rx1950.c| 1 + arch/arm/mach-s3c64xx/mach-crag6410.c | 1 + arch/arm/mach-s3c64xx/mach-hmt.c | 1 + arch/arm/mach-s3c64xx/mach-smartq.c| 1 + arch/arm/mach-s3c64xx/mach-smdk6410.c | 1 + arch/arm/mach-s5p64x0/mach-smdk6440.c | 1 + arch/arm/mach-s5p64x0/mach-smdk6450.c | 1 + arch/arm/mach-s5pc100/mach-smdkc100.c | 1 + arch/arm/mach-s5pv210/mach-smdkv210.c | 1 + arch/arm/mach-shmobile/board-armadillo800eva.c | 1 + arch/arm/plat-samsung/dev-backlight.c | 5 + arch/unicore32/kernel/puv3-nb0916.c| 1 + drivers/misc/Kconfig | 13 - drivers/misc/Makefile | 1 - drivers/misc/ep93xx_pwm.c | 286 - drivers/pwm/Kconfig
Re: [PATCH tip/core/rcu 4/4] documentation: Update circular buffer for load-acquire/store-release
Paul E. McKenney wrote: > - /* read index before reading contents at that index */ > - smp_mb(); /* finish reading descriptor before incrementing tail > */ I'd rather you didn't remove these comments (assuming they're correct) as they're pointing out the point of the example. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V13-prerc]: REGRESSION: "*ERROR* Timed out waiting for forcewake old ack to clear"
On Sat, Nov 16, 2013 at 12:28 PM, Jörg Otte wrote: > On startup I get the following error display on the console: > "*ERROR* Timed out waiting for forcewake old ack to clear" > > I already reported this error a year ago at the time of v3.7 > ( see https://lkml.org/lkml/2012/11/27/355) > which was fixed later on. > > Now this error is back again. Kernel 3.12.0-09888-gf63c48 Please boot with drm.debug=0xe, reproduce the issue and then attach the complete dmesg (including all the boot message, so if it takes a while to reproduce please grab an boot dmesg, too). Also adding the right mailing lists, see MAINTAINERS. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] OF: Introduce utility helper functions
Hi Grant,
On Nov 15, 2013, at 8:27 AM, Grant Likely wrote:
> On Thu, 14 Nov 2013 10:51:05 +0100, Pantelis Antoniou
> wrote:
>> Hi Grant,
>>
>> On Nov 14, 2013, at 2:44 AM, Grant Likely wrote:
>>
>>> On Wed, 13 Nov 2013 10:03:37 +0100, Pantelis Antoniou
>>> wrote:
On Nov 13, 2013, at 2:34 AM, Grant Likely wrote:
> On Tue, 12 Nov 2013 11:39:08 +0100, Pantelis Antoniou
> wrote:
>>> On Tue, 5 Nov 2013 19:50:16 +0200, Pantelis Antoniou
>>> wrote:
+ } else {
+ pr_warn("%s: node %p cannot be freed; memory is gone\n",
+ __func__, node);
+ }
+}
>>>
>>> All of the above is potentially dangerous. There is no way to determine
>>> if anything still holds a reference to a node. The proper way to handle
>>> removal of properties is to have a release method when the last
>>> of_node_put is called.
>>>
>>
>> This is safe, and expected to be called only on a dynamically created
>> tree,
>> that's what all the checks against OF_DYNAMIC guard against.
>>
>> It is not ever meant to be called on an arbitrary tree, created by
>> unflattening
>> a blob.
>
> I am talking about when being used on a dynamic tree. The problem is
> when a driver or other code holds a reference to a dynamic nodes, but
> doesn't release it correctly. The memory must not be freed until all of
> the references are relased. OF_DYNAMIC doesn't actually help in that
> case, and it is the reason for of_node_get()/of_node_put()
>
I know, but even that is not enough. of_node_get()/of_node_put() handles
the
case of references to the nodes, but not what happens with references to
properties. deadprops is mitigating the problem somewhat, but if we're
going
to go to all the trouble of kobjectification let's do the props as well.
of_get_property could be modified to return a devm_kmalloced copy of the
real
property and that would deal with most of the callers. Of course for
the small sized scalar data we can avoid the copy.
By using the devm_* interface we also avoid having to mess too much with
the callers.
I.e. what about something like devm_of_get_property()?
>>>
>>> Reference counting is already a horrible pain to keep correct. I don't
>>> see a better way to handle it in the dynamic case, so we're stuck with
>>> it, but I don't want to make it any harder. Adding ref counting to
>>> properties will make it harder than it already is to get the code right.
>>> I'm absolutely fine with a little bit of wasted memory in the form of
>>> deadprops when the alternative is so horrible. References at the node
>>> level is enough granularity.
>>>
>>> I don't think kduping the property is the solution either. I strongly
>>> suspect that will be far more expensive than the deadprop solution.
>>>
>>
>> As long as we can live with deadprops all is fine. Perhaps a
>> devm_of_get_property()
>> makes sense for new drivers though? What do you think? Perhaps copying to a
>> user supplied buffer as well?
>
> I still don't think it is necessary. The device lifetime should always
> be shorter than the node lifetime.
>
>> It's a kind of drag. That means you get handed a device_node pointer you are
>> not
>> able to free it without having the blob along with the container/accessor of
>> it.
>> I.e. For the normal case where the blob comes from a request_firmware() call
>> You have to keep the firmware structure around.
>>
>> Depending on what other method you're going to use tends to make the code a
>> little
>> bit messier.
>
> Understood. Stick with keeping the blob around for now. It can be
> reworkd in the future if necessary since there are no associated
> userspace ABI issues.
>
> g.
OK, will do.
Regards
-- Pantelis--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5] dmaengine: Add support for BCM2835
On Sat, Nov 16, 2013 at 11:41:34AM +, Russell King - ARM Linux wrote: > On Sat, Nov 16, 2013 at 11:27:54AM +, Mark Brown wrote: > > We should in general be moving in that direction however it does need a > > bit of care to make sure that there aren't any dependencies which do > > things like discard error codes, fail to check errors or treat errors as > > hard failures. > I don't agree: on platforms which have done this, it's very difficult to > tell from reading the kernel message log whether things came up correctly > because there's soo much spew from deferred probing it's virtually > impossible to tell whether component X initialised or whether that error > about resource Y missing was ever resolved. I do agree that deferred programming is far too chatty - there's a usability issue there. This bites me a lot on some of my systems too, I tend to read my logs with grep a lot which isn't awesome. > If we want kernel boot logs to be useful, we really need to shut up *all* > the drivers and subsystems whinging about being deferred probing, and only > have the driver model core reporting this status - maybe only allow > output about why at debug level or similar. Yes, some sort of standardisation of how this stuff gets reported would give us much better control of these things. signature.asc Description: Digital signature
Re: [PATCH v2] of: make of_get_phy_mode parse 'phy-connection-type'
On Fri, 15 Nov 2013 06:23:32 +, Florian Fainelli
wrote:
> Per the ePAPR v1.1 specification, 'phy-connection-type' is the canonical
> property name for describing an Ethernet to PHY connection type. Make
> sure that of_get_phy_mode() also attempts to parse that property and
> update the comments mentioning 'phy-mode' to also include
> 'phy-connection-type'.
>
> Acked-by: Grant Likely
> Signed-off-by: Florian Fainelli
Applied, thanks
g.
> ---
> Changes since v2:
> - reworked the error condition to look nicer per Grant's suggestion
> - added Grant's Acked-by tag
> - fixed a typo in the commit message on "mentioning"
>
> drivers/of/of_net.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
> index 8f9be2e..651e249 100644
> --- a/drivers/of/of_net.c
> +++ b/drivers/of/of_net.c
> @@ -13,8 +13,8 @@
>
> /**
> * It maps 'enum phy_interface_t' found in include/linux/phy.h
> - * into the device tree binding of 'phy-mode', so that Ethernet
> - * device driver can get phy interface from device tree.
> + * into the device tree binding of 'phy-mode' or 'phy-connection-type',
> + * so that Ethernet device driver can get phy interface from device tree.
> */
> static const char *phy_modes[] = {
> [PHY_INTERFACE_MODE_NA] = "",
> @@ -36,8 +36,9 @@ static const char *phy_modes[] = {
> * of_get_phy_mode - Get phy mode for given device_node
> * @np: Pointer to the given device_node
> *
> - * The function gets phy interface string from property 'phy-mode',
> - * and return its index in phy_modes table, or errno in error case.
> + * The function gets phy interface string from property 'phy-mode' or
> + * 'phy-connection-type', and return its index in phy_modes table, or errno
> in
> + * error case.
> */
> int of_get_phy_mode(struct device_node *np)
> {
> @@ -46,6 +47,8 @@ int of_get_phy_mode(struct device_node *np)
>
> err = of_property_read_string(np, "phy-mode", &pm);
> if (err < 0)
> + err = of_property_read_string(np, "phy-connection-type", &pm);
> + if (err < 0)
> return err;
>
> for (i = 0; i < ARRAY_SIZE(phy_modes); i++)
> --
> 1.8.3.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpiolib: fix find_chip_by_name()
find_chip_by_name() was incorrectly implemented by using
gpio_lookup_list instead of gpiod_chips to iterate through all the
registered GPIO controllers. This patch reimplements it by using
gpiochip_find() with a custom search function, which simplifies the code
on top of fixing the mistake.
Signed-off-by: Alexandre Courbot
---
drivers/gpio/gpiolib.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 9f3326b..63bbf5b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1307,6 +1307,18 @@ struct gpio_chip *gpiochip_find(void *data,
}
EXPORT_SYMBOL_GPL(gpiochip_find);
+static int gpiochip_match_name(struct gpio_chip *chip, void *data)
+{
+ const char *name = data;
+
+ return !strcmp(chip->label, name);
+}
+
+static struct gpio_chip *find_chip_by_name(const char *name)
+{
+ return gpiochip_find((void *)name, gpiochip_match_name);
+}
+
#ifdef CONFIG_PINCTRL
/**
@@ -2212,23 +2224,6 @@ void gpiod_add_table(struct gpiod_lookup *table, size_t
size)
mutex_unlock(&gpio_lookup_lock);
}
-/*
- * Caller must have a acquired gpio_lookup_lock
- */
-static struct gpio_chip *find_chip_by_name(const char *name)
-{
- struct gpio_chip *chip = NULL;
-
- list_for_each_entry(chip, &gpio_lookup_list, list) {
- if (chip->label == NULL)
- continue;
- if (!strcmp(chip->label, name))
- break;
- }
-
- return chip;
-}
-
#ifdef CONFIG_OF
static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
unsigned int idx, unsigned long *flags)
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpiolib: use dedicated flags for GPIO properties
GPIO mapping properties were defined using the GPIOF_* flags, which are
declared in linux/gpio.h. This file is not included when using the
GPIO descriptor interface.
This patch declares the flags that can be used as GPIO mappings
properties in linux/gpio/driver.h, and uses them in gpiolib, so that no
deprecated declarations are used by the GPIO descriptor interface.
This patch also allows GPIO_OPEN_DRAIN and GPIO_OPEN_SOURCE to be
specified as GPIO mapping properties.
Signed-off-by: Alexandre Courbot
--
The new GPIO interface documentation already uses these new declarations.
It would be nice to have this merged in a 3.13-rc since it is necessary
to properly declare GPIO mappings as platform data.
---
drivers/gpio/gpiolib.c | 22 +++---
include/linux/gpio/driver.h | 11 +--
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 63bbf5b..be5dbc2 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -2226,7 +2227,8 @@ void gpiod_add_table(struct gpiod_lookup *table, size_t
size)
#ifdef CONFIG_OF
static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
- unsigned int idx, unsigned long *flags)
+ unsigned int idx,
+ enum gpio_lookup_flags *flags)
{
char prop_name[32]; /* 32 is max size of property name */
enum of_gpio_flags of_flags;
@@ -2244,7 +2246,7 @@ static struct gpio_desc *of_find_gpio(struct device *dev,
const char *con_id,
return desc;
if (of_flags & OF_GPIO_ACTIVE_LOW)
- *flags |= GPIOF_ACTIVE_LOW;
+ *flags |= GPIO_ACTIVE_LOW;
return desc;
}
@@ -2257,7 +2259,8 @@ static struct gpio_desc *of_find_gpio(struct device *dev,
const char *con_id,
#endif
static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id,
- unsigned int idx, unsigned long *flags)
+ unsigned int idx,
+ enum gpio_lookup_flags *flags)
{
struct acpi_gpio_info info;
struct gpio_desc *desc;
@@ -2267,13 +2270,14 @@ static struct gpio_desc *acpi_find_gpio(struct device
*dev, const char *con_id,
return desc;
if (info.gpioint && info.active_low)
- *flags |= GPIOF_ACTIVE_LOW;
+ *flags |= GPIO_ACTIVE_LOW;
return desc;
}
static struct gpio_desc *gpiod_find(struct device *dev, const char *con_id,
- unsigned int idx, unsigned long *flags)
+ unsigned int idx,
+ enum gpio_lookup_flags *flags)
{
const char *dev_id = dev ? dev_name(dev) : NULL;
struct gpio_desc *desc = ERR_PTR(-ENODEV);
@@ -2365,7 +2369,7 @@ struct gpio_desc *__must_check gpiod_get_index(struct
device *dev,
{
struct gpio_desc *desc;
int status;
- unsigned long flags = 0;
+ enum gpio_lookup_flags flags = 0;
dev_dbg(dev, "GPIO lookup for consumer %s\n", con_id);
@@ -2391,8 +2395,12 @@ struct gpio_desc *__must_check gpiod_get_index(struct
device *dev,
if (status < 0)
return ERR_PTR(status);
- if (flags & GPIOF_ACTIVE_LOW)
+ if (flags & GPIO_ACTIVE_LOW)
set_bit(FLAG_ACTIVE_LOW, &desc->flags);
+ if (flags & GPIO_OPEN_DRAIN)
+ set_bit(FLAG_OPEN_DRAIN, &desc->flags);
+ if (flags & GPIO_OPEN_SOURCE)
+ set_bit(FLAG_OPEN_SOURCE, &desc->flags);
return desc;
}
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 656a27e..82eac61 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -125,6 +125,13 @@ extern struct gpio_chip *gpiochip_find(void *data,
int gpiod_lock_as_irq(struct gpio_desc *desc);
void gpiod_unlock_as_irq(struct gpio_desc *desc);
+enum gpio_lookup_flags {
+ GPIO_ACTIVE_HIGH = (0 << 0),
+ GPIO_ACTIVE_LOW = (1 << 0),
+ GPIO_OPEN_DRAIN = (1 << 1),
+ GPIO_OPEN_SOURCE = (1 << 2),
+};
+
/**
* Lookup table for associating GPIOs to specific devices and functions using
* platform data.
@@ -152,9 +159,9 @@ struct gpiod_lookup {
*/
unsigned int idx;
/*
-* mask of GPIOF_* values
+* mask of GPIO_* values
*/
- unsigned long flags;
+ enum gpio_lookup_flags flags;
};
/*
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] clocksource: orion: Switch to sched_clock_register()
On 11/16/2013 12:48 AM, Stephen Boyd wrote:
The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.
Cc: Sebastian Hesselbarth
Signed-off-by: Stephen Boyd
Tested-by: Sebastian Hesselbarth
Thanks!
---
drivers/clocksource/time-orion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
index 9c7f018..2006622 100644
--- a/drivers/clocksource/time-orion.c
+++ b/drivers/clocksource/time-orion.c
@@ -53,7 +53,7 @@ EXPORT_SYMBOL(orion_timer_ctrl_clrset);
/*
* Free-running clocksource handling.
*/
-static u32 notrace orion_read_sched_clock(void)
+static u64 notrace orion_read_sched_clock(void)
{
return ~readl(timer_base + TIMER0_VAL);
}
@@ -135,7 +135,7 @@ static void __init orion_timer_init(struct device_node *np)
clocksource_mmio_init(timer_base + TIMER0_VAL, "orion_clocksource",
clk_get_rate(clk), 300, 32,
clocksource_mmio_readl_down);
- setup_sched_clock(orion_read_sched_clock, 32, clk_get_rate(clk));
+ sched_clock_register(orion_read_sched_clock, 32, clk_get_rate(clk));
/* setup timer1 as clockevent timer */
if (setup_irq(irq, &orion_clkevt_irq))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools cpupower: fix wrong err msg not supported vs not available
idlestates in sysfs are counted from 0.
This fixes a wrong error message.
Current behavior on a machine with 4 sleep states is:
cpupower idle-set -e 4
Idlestate 4 enabled on CPU 0
-Wrong-
cpupower idle-set -e 5
Idlestate enabling not supported by kernel
-Must and now will be -
cpupower idle-set -e 5
Idlestate 6 not available on CPU 0
---
cpupower idle-set -e 6
Idlestate 6 not available on CPU 0
Signed-off-by: Thomas Renninger
---
tools/power/cpupower/utils/helpers/sysfs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/power/cpupower/utils/helpers/sysfs.c
b/tools/power/cpupower/utils/helpers/sysfs.c
index 5cdc600..851c7a1 100644
--- a/tools/power/cpupower/utils/helpers/sysfs.c
+++ b/tools/power/cpupower/utils/helpers/sysfs.c
@@ -278,7 +278,7 @@ static char *sysfs_idlestate_get_one_string(unsigned int
cpu,
int sysfs_is_idlestate_disabled(unsigned int cpu,
unsigned int idlestate)
{
- if (sysfs_get_idlestate_count(cpu) < idlestate)
+ if (sysfs_get_idlestate_count(cpu) <= idlestate)
return -1;
if (!sysfs_idlestate_file_exists(cpu, idlestate,
@@ -303,7 +303,7 @@ int sysfs_idlestate_disable(unsigned int cpu,
char value[SYSFS_PATH_MAX];
int bytes_written;
- if (sysfs_get_idlestate_count(cpu) < idlestate)
+ if (sysfs_get_idlestate_count(cpu) <= idlestate)
return -1;
if (!sysfs_idlestate_file_exists(cpu, idlestate,
--
1.7.6.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/
Provide cpupower-idle-set(1) manpage and a minor fix
Rafael: Could you queue these two again in your tree if they are ok, please. Sidenote: If I find the time, I like to adjust the cpuidle ladder governor: If a lighter sleep state is disabled (and in this governor deeper sleep states are not entered any more as well), I like to set the disabled flag for the deeper sleep states as well. Like that the correct kernel behavior (the disabled and all deeper sleep states are not used anymore) is shown correctly to userspace and this is not only documented deep inside the kernel sources. Thanks, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] tools cpupower: Add cpupower-idle-set(1) manpage
cpupower idle-set subcommand was introduce recently. This patch provides the missing manpage. If cpupower is properly installed it will show up automatically (similar to git), when invoking: cpupower help idle-set or cpupower idle-set --help Some parts have been taken over and adjusted from git commit 62d6ae880e3e76098 documentation submitted by Carsten Emde. Signed-off-by: Thomas Renninger CC: Carsten Emde CC: Yanmin Zhang CC: Deepthi Dharwar CC: ShuoX Liu CC: c...@linux.com --- tools/power/cpupower/man/cpupower-idle-info.1 |3 +- tools/power/cpupower/man/cpupower-idle-set.1 | 71 + 2 files changed, 73 insertions(+), 1 deletions(-) create mode 100644 tools/power/cpupower/man/cpupower-idle-set.1 diff --git a/tools/power/cpupower/man/cpupower-idle-info.1 b/tools/power/cpupower/man/cpupower-idle-info.1 index 4178eff..7b3646a 100644 --- a/tools/power/cpupower/man/cpupower-idle-info.1 +++ b/tools/power/cpupower/man/cpupower-idle-info.1 @@ -87,4 +87,5 @@ Thomas Renninger .fi .SH "SEE ALSO" .LP -cpupower(1), cpupower\-monitor(1), cpupower\-info(1), cpupower\-set(1) +cpupower(1), cpupower\-monitor(1), cpupower\-info(1), cpupower\-set(1), +cpupower\-idle\-set(1) diff --git a/tools/power/cpupower/man/cpupower-idle-set.1 b/tools/power/cpupower/man/cpupower-idle-set.1 new file mode 100644 index 000..6b16072 --- /dev/null +++ b/tools/power/cpupower/man/cpupower-idle-set.1 @@ -0,0 +1,71 @@ +.TH "CPUPOWER-IDLE-SET" "1" "0.1" "" "cpupower Manual" +.SH "NAME" +.LP +cpupower idle\-set \- Utility to set cpu idle state specific kernel options +.SH "SYNTAX" +.LP +cpupower [ \-c cpulist ] idle\-info [\fIoptions\fP] +.SH "DESCRIPTION" +.LP +The cpupower idle\-set subcommand allows to set cpu idle, also called cpu +sleep state, specific options offered by the kernel. One example is disabling +sleep states. This can be handy for power vs performance tuning. +.SH "OPTIONS" +.LP +.TP +\fB\-d\fR \fB\-\-disable\fR +Disable a specific processor sleep state. +.TP +\fB\-e\fR \fB\-\-enable\fR +Enable a specific processor sleep state. + +.SH "REMARKS" +.LP +Cpuidle Governors Policy on Disabling Sleep States + +.RS 4 +Depending on the used cpuidle governor, implementing the kernel policy +how to choose sleep states, subsequent sleep states on this core, might get +disabled as well. + +There are two cpuidle governors ladder and menu. While the ladder +governor is always available, if CONFIG_CPU_IDLE is selected, the +menu governor additionally requires CONFIG_NO_HZ. + +The behavior and the effect of the disable variable depends on the +implementation of a particular governor. In the ladder governor, for +example, it is not coherent, i.e. if one is disabling a light state, +then all deeper states are disabled as well. Likewise, if one enables a +deep state but a lighter state still is disabled, then this has no effect. +.RE +.LP +Disabling the Lightest Sleep State may not have any Affect + +.RS 4 +If criteria are not met to enter deeper sleep states and the lightest sleep +state is chosen when idle, the kernel may still enter this sleep state, +irrespective of whether it is disabled or not. This is also reflected in +the usage count of the disabled sleep state when using the cpupower idle-info +command. +.RE +.LP +Selecting specific CPU Cores + +.RS 4 +By default processor sleep states of all CPU cores are set. Please refer +to the cpupower(1) manpage in the \-\-cpu option section how to disable +C-states of specific cores. +.RE +.SH "FILES" +.nf +\fI/sys/devices/system/cpu/cpu*/cpuidle/state*\fP +\fI/sys/devices/system/cpu/cpuidle/*\fP +.fi +.SH "AUTHORS" +.nf +Thomas Renninger +.fi +.SH "SEE ALSO" +.LP +cpupower(1), cpupower\-monitor(1), cpupower\-info(1), cpupower\-set(1), +cpupower\-idle\-info(1) -- 1.7.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: cpufreq-cpu0: Use a sane boot frequency when booting with a mismatched bootloader configuration
On Fri, Nov 15, 2013 at 08:22:15PM -0600, Nishanth Menon wrote:
> On many development platforms, at boot, the bootloader configured
> frequency maynot match the valid frequencies that are stated to be
> supported in OPP table. This may occur due to various reasons:
> a) older or default bootloader in development platform without latest
> updates
> b) SoC documentation update that may have occurred in kernel
> c) kernel definitions are out of date Vs bootloader which is updated
> etc..
>
> In these cases, we should assume from a kernel perspective, the only
> safe frequency that the system can be on is the ones available in the
> OPP table. This may not handle case (c), but, that is a different
> kernel bug of it's own.
No, it's not a kernel bug.
OPP is not a definition that belongs to kernel. Instead, it's
characteristics of hardware, and that's why we can naturally put the
definition into device tree. Bear it in mind that device tree is a
hardware description and should be OS agnostic. So it shouldn't be
treated as part of Linux kernel in any case, even though the device
tree source is currently maintained in kernel tree.
Device tree is designed as a way for firmware/bootloader to describe
hardware to kernel. That said, device tree is more part of bootloader
than kernel. If bootloader runs at a frequency that does not match the
OPP in device tree, the one should be fixed is either bootloader or
device tree but never kernel.
However, I agree we should at least have a check in cpufreq-cpu0 driver
and fail out in case that a mismatch is detected.
Shawn
>
> Considering that in many existing or development platforms, (a) or
> (b) is common, enforce a sanity check and reprogram to a conservative
> start configuration at probe to allow sane operation independent of
> bootloader.
>
> Reported-by: Carlos Hernandez
> Signed-off-by: Nishanth Menon
> ---
>
> based on v3.12 tag - however, a rebase with opp function name change
> is needed for v3.13-rc1 if folks are ok, I can repost with updates.
>
> Identified when during debug of https://patchwork.kernel.org/patch/3191411/
> on TI vendor kernel based on v3.12 tag.
>
> In the case discussed, bootloader booted OMAP5uEVM at 1.1GHz when the
> available
> frequencies were 500MHz, 1GHz, 1.5GHz.
>
> To prevent system from functioning at this invalid configuration (and hence
> trigger the bug seen in stats), we should remove the dependence of the kernel
> from bootloader configuration.
> With this patch, in the mentioned boot scenario, we get the following log:
> [ 25.649736] cpufreq_cpu0: bootloader freq 11 no match to table,
> Using 10
>
> Artificially modifying the bootloader to create other boundary conditions:
> (lower bound check)
> [ 25.633535] cpufreq_cpu0: bootloader freq 3Hz no match to table,
> Using 5Hz
> (upper bound check)
> [ 27.355837] cpufreq_cpu0: bootloader freq 16Hz no match to table,
> Using 15Hz
>
> The other alternative(to reduce code churn) would be to just report a
> mismatch and continue to function at the potentially risky OPP - but
> in the cases such as using userspace governor, the system could be in
> unstable state resulting in hard to debug behavior.
>
> The last alternative is to always expect bootloader to be in sync with proper
> OPP configuration, which rarely happens correctly.
>
> drivers/cpufreq/cpufreq-cpu0.c | 84
> +++-
> 1 file changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index c522a95..9765050 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -176,7 +176,8 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
> static int cpu0_cpufreq_probe(struct platform_device *pdev)
> {
> struct device_node *np;
> - int ret;
> + int ret, i;
> + long boot_freq;
>
> cpu_dev = get_cpu_device(0);
> if (!cpu_dev) {
> @@ -232,7 +233,6 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
> if (!IS_ERR(cpu_reg)) {
> struct opp *opp;
> unsigned long min_uV, max_uV;
> - int i;
>
> /*
>* OPP is maintained in order of increasing frequency, and
> @@ -254,6 +254,86 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
> transition_latency += ret * 1000;
> }
>
> + boot_freq = clk_get_rate(cpu_clk);
> +
> + /* See if we have a perfect match */
> + for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
> + if (boot_freq == freq_table[i].frequency * 1000)
> + break;
> +
> + /* If we have a bad bootloader config, try recovery */
> + if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
> + struct opp *opp;
> + long new_freq = boot_freq, freq_exact;
> + unsigned long
congratulation
Donation to You, Contact Dave and Angela Dawe on dave_angel...@cash4u.com For More 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/
[i915] BUG: Bad page state in process Xorg
Hi, After 9 days uptime, I wanted to restart my Gnome-Session, but this fails because Xorg is hitting a kernel bug. Xorg server isn't kill-able. I see these log entries: [126489.697509] CPU: 0 PID: 690 Comm: Xorg Tainted: GB3.12.0+ #95 [126489.697511] Hardware name: Acer Aspire 1810T/JM11-MS, BIOS v1.3310 03/25/2010 [126489.697513] 88009df21cd8 81554512 88009df21cf0 [126489.697517] 81551f11 ea00022c5400 88009df21d18 810c549c [126489.697520] ea00022c5400 4008001c 88009df21d50 [126489.697524] Call Trace: [126489.697529] [] dump_stack+0x19/0x1b [126489.697533] [] bad_page+0xc9/0xe2 [126489.697537] [] free_pages_prepare+0xac/0xc0 [126489.697541] [] free_hot_cold_page+0x1d/0x120 [126489.697545] [] __put_single_page+0x1e/0x30 [126489.697549] [] put_page+0x25/0x40 [126489.697554] [] i915_gem_object_put_pages_gtt+0xc3/0x1a0 [126489.697558] [] i915_gem_object_put_pages+0x78/0xd0 [126489.697562] [] i915_gem_free_object+0xe7/0x230 [126489.697566] [] drm_gem_object_free+0x25/0x30 [126489.697570] [] drm_gem_dmabuf_release+0x4b/0x70 [126489.697574] [] dma_buf_release+0x27/0x90 [126489.697578] [] __fput+0xcb/0x250 [126489.697582] [] fput+0x9/0x10 [126489.697586] [] task_work_run+0x9c/0xc0 [126489.697590] [] do_exit+0x6f4/0xa00 [126489.697594] [] ? task_work_run+0x84/0xc0 [126489.697598] [] do_group_exit+0x31/0x90 [126489.697602] [] SyS_exit_group+0xf/0x10 [126489.697606] [] system_call_fastpath+0x16/0x1b [126489.697610] BUG: Bad page state in process Xorg pfn:8b151 [126489.699837] page:ea00022c5440 count:0 mapcount:0 mapping:88008cf63168 index:0x2b [126489.702979] page flags: 0x4008001c(referenced|uptodate|dirty|swapbacked) [126489.705295] Modules linked in: vfat fat ipt_MASQUERADE ip6t_REJECT xt_conntrack ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw tun tcp_lp loop fuse bluetooth snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_usb_audio snd_usbmidi_lib snd_hwdep snd_seq arc4 snd_pcm iwldvm snd_page_alloc snd_rawmidi snd_seq_device snd_timer snd mac80211 kvm_intel soundcore kvm asix acer_wmi usbnet acerhdf mii sparse_keymap pcspkr joydev iwlwifi atl1c wmi cfg80211 rfkill acpi_cpufreq freq_table uinput ipv6 xts gf128mul usb_storage udl syscopyarea sysfillrect sysimgblt drm_usb [last unloaded: iptable_raw] How to kill the Xorg server and restart gdm? with kind regards thomas-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 3.4.57: "tg3 0000:01:00.0: eth0: transmit timed out, resetting"
Hi, I'm running a DELL PER620 with kernel 3.4.57 an Broadcom quad-port gbit adapter BCM5720. 15min load-average is about 4-8. After 13 days of uptime today the machine becomes unresponsible. But after a couple of minutes it becomes responsible again and was rebooted (sysctl paremter for kernel.panic = 1) automatically. the machine is acting a webserver fo about 3000 virtualhosts. After searching the lofiles on remote my syslog server I found the following messages regarding eth0: 2013-11-16 11:43:38 [1505491.196172] tg3 :01:00.0: eth0: transmit timed out, resetting 2013-11-16 11:43:38 [1505491.815002] INFO: rcu_bh detected stalls on CPUs/tasks: 2013-11-16 11:43:38 [1505491.815009] 16: (1 GPs behind) idle=1fd/140/0 2013-11-16 11:43:38 [1505491.815012] (detected by 6, t=6002 jiffies) 2013-11-16 11:43:38 [1505491.815014] INFO: Stall ended before state dump start 2013-11-16 11:43:38 [1505492.450611] tg3 :01:00.0: eth0: 0x: 0x165f14e4, 0x00100406, 0x0200, 0x00800010 2013-11-16 11:43:38 [1505492.450614] tg3 :01:00.0: eth0: 0x0010: 0xd57a000c, 0x, 0xd57b000c, 0x 2013-11-16 11:43:38 [1505492.450615] tg3 :01:00.0: eth0: 0x0020: 0xd57c000c, 0x, 0x, 0x1f5b1028 2013-11-16 11:43:38 [1505492.450617] tg3 :01:00.0: eth0: 0x0030: 0xd880, 0x0048, 0x, 0x010f 2013-11-16 11:43:38 [1505492.450619] tg3 :01:00.0: eth0: 0x0040: 0x, 0x3f00, 0xc8035001, 0x64002008 2013-11-16 11:43:38 [1505492.450621] tg3 :01:00.0: eth0: 0x0050: 0x818c5803, 0x7800, 0x0086a005, 0x 2013-11-16 11:43:38 [1505492.450623] tg3 :01:00.0: eth0: 0x0060: 0x, 0x, 0xf298, 0x00380081 2013-11-16 11:43:38 [1505492.450624] tg3 :01:00.0: eth0: 0x0070: 0x000710b0, 0xffcb28fa, 0x0001421c, 0x 2013-11-16 11:43:38 [1505492.450626] tg3 :01:00.0: eth0: 0x0080: 0x0001, 0x0002, 0x, 0x01d2 2013-11-16 11:43:38 [1505492.450628] tg3 :01:00.0: eth0: 0x0090: 0x, 0x, 0x, 0x06a1 2013-11-16 11:43:38 [1505492.450629] tg3 :01:00.0: eth0: 0x00a0: 0x8010ac11, 0x0004, 0x1004, 0x00020010 2013-11-16 11:43:38 [1505492.450631] tg3 :01:00.0: eth0: 0x00b0: 0x10008d81, 0x0010242e, 0x0004cc22, 0x10120040 2013-11-16 11:43:38 [1505492.450633] tg3 :01:00.0: eth0: 0x00d0: 0x001f, 0x0006, 0x, 0x0001 2013-11-16 11:43:38 [1505492.450635] tg3 :01:00.0: eth0: 0x00f0: 0x, 0x0572, 0x, 0xbec733be 2013-11-16 11:43:38 [1505492.450637] tg3 :01:00.0: eth0: 0x0100: 0x13c10001, 0x, 0x00018000, 0x000e7030 2013-11-16 11:43:38 [1505492.450638] tg3 :01:00.0: eth0: 0x0110: 0x2000, 0x31c0, 0x00a0, 0x 2013-11-16 11:43:38 [1505492.450640] tg3 :01:00.0: eth0: 0x0130: 0x, 0x, 0x, 0x15010003 2013-11-16 11:43:38 [1505492.450642] tg3 :01:00.0: eth0: 0x0140: 0x1c3f67fa, 0x90b1, 0x, 0x 2013-11-16 11:43:38 [1505492.450643] tg3 :01:00.0: eth0: 0x0150: 0x16010004, 0x, 0x0007811b, 0x0001 2013-11-16 11:43:38 [1505492.450645] tg3 :01:00.0: eth0: 0x0160: 0x00010002, 0x, 0x, 0x 2013-11-16 11:43:38 [1505492.450647] tg3 :01:00.0: eth0: 0x0170: 0x, 0x80ff, 0x, 0x 2013-11-16 11:43:38 [1505492.450648] tg3 :01:00.0: eth0: 0x0200: 0x, 0x3f00, 0x, 0xfb00 2013-11-16 11:43:38 [1505492.450650] tg3 :01:00.0: eth0: 0x0210: 0x, 0x0d00, 0x, 0xa700 2013-11-16 11:43:38 [1505492.450652] tg3 :01:00.0: eth0: 0x0220: 0x, 0x0001, 0x, 0x 2013-11-16 11:43:38 [1505492.450653] tg3 :01:00.0: eth0: 0x0260: 0x, 0x, 0x, 0x06a1 2013-11-16 11:43:38 [1505492.450655] tg3 :01:00.0: eth0: 0x0280: 0x, 0x01d2, 0x, 0x0d73 2013-11-16 11:43:38 [1505492.450657] tg3 :01:00.0: eth0: 0x0290: 0x, 0x04df, 0x, 0x01b5 2013-11-16 11:43:38 [1505492.450659] tg3 :01:00.0: eth0: 0x0300: 0x010d, 0x01df, 0x00bb, 0x0035 2013-11-16 11:43:38 [1505492.450660] tg3 :01:00.0: eth0: 0x0400: 0x18e04808, 0x0040, 0x1000, 0x0880 2013-11-16 11:43:38 [1505492.450662] tg3 :01:00.0: eth0: 0x0410: 0x90b1, 0x1c3f67fa, 0x90b1, 0x1c3f67fa 2013-11-16 11:43:38 [1505492.450664] tg3 :01:00.0: eth0: 0x0420: 0x90b1, 0x1c3f67fa, 0x90b1, 0x1c3f67fa 2013-11-16 11:43:38 [1505492.450666] tg3 :01:00.0: eth0: 0x0430: 0x0400, 0x, 0x02f4, 0x05f2 2013-11-16 11:43:38 [1505492.450667] tg3 :01:00.0: eth0: 0x0440: 0x, 0x, 0x, 0x04384400 2013-11-16 11:43:38 [1505492.450669] tg3 :01:00.0: eth
Re: [PATCH] cpufreq: suspend/resume governors with PM notifiers
On Saturday, November 16, 2013 10:01:50 AM viresh kumar wrote: > On Saturday 16 November 2013 05:54 AM, Rafael J. Wysocki wrote: > > Will cpufreq work during system-wide power transitions (suspend/resume etc.) > > after this? In particular, what about hibernation? > > I am disabling governors as soon as we start suspend. So No, cpufreq wouldn't > work during suspend/resume. But once system is resumed we are starting it back > again. Well, disabling it for the whole duration of suspend/resume and/or hibernation may not be the right approach entirely, unless we force the pax perf of the boot CPU at least in addition to that. Otherwise the latency of suspend and the subsequent resume will depend on what perf level the CPUs where before disabling the governors, which is not desirable at al. > Hibernation is probably not supported by my code yet.. I just went through > hibernation code quickly and it looks we don't send PM_SUSPEND_PREPARE or > PM_POST_SUSPEND notifications in case of hibernation. Correct? Yes, that's correct. > And these are the notifications that we send: > - PM_HIBERNATION_PREPARE > - PM_POST_HIBERNATION > - PM_RESTORE_PREPARE > - PM_POST_RESTORE > > If I am not wrong I need to stop governors on PM_HIBERNATION_PREPARE and need > to > start them back on: PM_POST_HIBERNATION (I am a bit confused with this one. > Does > this POST_HIBERNATION one happens at the end of going into hibernation? or > after > booting back? I need a notifier at the end of restore).. You'd need both PM_POST_HIBERNATION and PM_POST_RESTORE, but I wouldn't really like cpufreq governors to be disabled throughout the whole hibernation. Actually, we use CPU offline/online during system suspend/resume to avoid having to do stuff like this from PM notifiers. So I'd like the original problem to be addressed in a different way. Thanks! PS The sisk.pl address will start bouncing shortly, so please replace it with r...@rjwysocki.net in your address book. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Drivers: staging: ft1000-usb: ft1000_proc.c: fixed a few styling issues.
Fixed a few styling issues, particularly:
Lines 36,42: Inserted a space before the open paranthesis.
Line 50: Removed space between function name and open parenthesis.
Lines 56,57: Removed trailing whitespace.
lines: 130, 133: Replaced spaces with tabs for identation.
Signed-off-by: Aldo Iljazi
---
drivers/staging/ft1000/ft1000-usb/ft1000_proc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_proc.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_proc.c
index 5ead942..2575d0d 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_proc.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_proc.c
@@ -33,13 +33,13 @@
#define seq_putx(m, message, size, var) \
seq_printf(m, message); \
- for(i = 0; i < (size - 1); i++) \
+ for (i = 0; i < (size - 1); i++) \
seq_printf(m, "%02x:", var[i]); \
seq_printf(m, "%02x\n", var[i])
#define seq_putd(m, message, size, var) \
seq_printf(m, message); \
- for(i = 0; i < (size - 1); i++) \
+ for (i = 0; i < (size - 1); i++) \
seq_printf(m, "%d.", var[i]); \
seq_printf(m, "%d\n", var[i])
@@ -47,14 +47,14 @@
#define FTNET_PROC init_net.proc_net
-int ft1000_read_dpram16 (struct ft1000_usb *ft1000dev, u16 indx,
+int ft1000_read_dpram16(struct ft1000_usb *ft1000dev, u16 indx,
u8 *buffer, u8 highlow);
static int ft1000ReadProc(struct seq_file *m, void *v)
{
- static const char *status[] = {
- "Idle (Disconnect)",
+ static const char *status[] = {
+ "Idle (Disconnect)",
"Searching",
"Active (Connected)",
"Waiting for L2",
@@ -127,10 +127,10 @@ static int ft1000ReadProc(struct seq_file *m, void *v)
}
seq_printf(m, "Connection Time: %02ld:%02ld:%02ld\n",
- ((delta / 3600) % 24), ((delta / 60) % 60), (delta % 60));
+ ((delta / 3600) % 24), ((delta / 60) % 60), (delta % 60));
seq_printf(m, "Connection Time[s]: %ld\n", delta);
seq_printf(m, "Asic ID: %s\n",
- (info->AsicID) == ELECTRABUZZ_ID ? "ELECTRABUZZ ASIC" : "MAGNEMITE
ASIC");
+ (info->AsicID) == ELECTRABUZZ_ID ? "ELECTRABUZZ ASIC" : "MAGNEMITE
ASIC");
seq_putx(m, "SKU: ", SKUSZ, info->Sku);
seq_putx(m, "EUI64: ", EUISZ, info->eui64);
seq_putd(m, "DSP version number: ", DSPVERSZ, info->DspVer);
--
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/
DRM_TEGRA not buildable as a module
Hi All, The commit below seems to have made the Tegra DRM driver a bool option instead of tristate: commit dee8268f8fb218c9e9b604a40f7dbdd395e910f9 Author: Thierry Reding Date: Wed Oct 9 10:32:49 2013 +0200 drm/tegra: Move driver to DRM tree In order to make subsystem-wide changes easier, move the Tegra DRM driver back into the DRM tree. Signed-off-by: Thierry Reding That means you can't build the driver as a module. Was this intended? The changelog doesn't mention anything about that and the existing help text on the option seems to imply it should be buildable as a module. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Update PATCH 1/1] Cpufreq: Make governor data on nonboot cpus across system suspend/resume
On Saturday, November 16, 2013 11:59:59 AM Lan Tianyu wrote:
> On 11/16/2013 08:38 AM, Rafael J. Wysocki wrote:
> > On Friday, November 15, 2013 04:15:34 PM Lan Tianyu wrote:
> >> Currently, governor of nonboot cpus will be put to EXIT when system
> >> suspend.
> >> Since all these cpus will be unplugged and the governor usage_count
> >> decreases
> >> to zero. The governor data and its sysfs interfaces will be freed or
> >> released.
> >> This makes user config of these governors loss during suspend and resume.
> >
> > First off, do we have a pointer to a bug report related to that?
> >
>
> No, I found this bug when I tried to resolve other similar bug.
> https://bugzilla.kernel.org/show_bug.cgi?id=63081. I still have no idea
> about bug 63081 and asked reporter to try this patch.
>
> > Second, what does need to be done to reproduce this problem?
> >
>
> Defaultly, all cpus use ondemand governor after bootup. Change one
> non-boot cpu's governor to conservative,
Well, why would anyone want to do that? Just out of curiosity ...
> modify conservative config via sysfs interface and then do system suspend.
> After resume, the config of conservative is reset. On my machine, all cpus
> have owen policy.
So this is acpi-cpufreq, right?
The patch looks basically OK to me, but ->
> >> This doesn't happen on the governor covering boot cpu because it isn't
> >> unplugged during system suspend.
> >>
> >> To fix this issue, skipping governor exit during system suspend and check
> >> policy governor data to determine whether the governor is really needed
> >> to be initialized when do init. If not, return EALREADY to indicate the
> >> governor has been initialized and should do nothing. __cpufreq_governor()
> >> convert EALREADY to 0 as return value for INIT event since governor is
> >> still under INIT state and can do START operation.
> >>
> >> Signed-off-by: Lan Tianyu
> >> ---
> >> Fix some typos
> >>
> >> drivers/cpufreq/cpufreq.c | 5 -
> >> drivers/cpufreq/cpufreq_governor.c | 13 -
> >> 2 files changed, 16 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >> index 02d534d..38f2e4a 100644
> >> --- a/drivers/cpufreq/cpufreq.c
> >> +++ b/drivers/cpufreq/cpufreq.c
> >> @@ -1239,7 +1239,7 @@ static int __cpufreq_remove_dev_finish(struct device
> >> *dev,
> >>
> >>/* If cpu is last user of policy, free policy */
> >>if (cpus == 1) {
> >> - if (has_target()) {
> >> + if (has_target() && !frozen) {
> >>ret = __cpufreq_governor(policy,
> >>CPUFREQ_GOV_POLICY_EXIT);
> >>if (ret) {
> >> @@ -1822,6 +1822,9 @@ static int __cpufreq_governor(struct cpufreq_policy
> >> *policy,
> >>((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
> >>module_put(policy->governor->owner);
> >>
> >> + if ((event == CPUFREQ_GOV_POLICY_INIT) && ret == -EALREADY)
> >> + ret = 0;
> >> +
-> I'd prefer this check to be combined with the one done to determine whether
or not we need to do the module_put(). Something like
if (event == CPUFREQ_GOV_POLICY_EXIT && ret) {
module_put(policy->governor->owner);
if (ret == -EALREADY)
return 0;
} else if (event == CPUFREQ_GOV_POLICY_EXIT && !ret) {
module_put(policy->governor->owner);
}
Thanks!
> >>return ret;
> >> }
> >>
> >> diff --git a/drivers/cpufreq/cpufreq_governor.c
> >> b/drivers/cpufreq/cpufreq_governor.c
> >> index 0806c31..ddb93af 100644
> >> --- a/drivers/cpufreq/cpufreq_governor.c
> >> +++ b/drivers/cpufreq/cpufreq_governor.c
> >> @@ -204,9 +204,20 @@ int cpufreq_governor_dbs(struct cpufreq_policy
> >> *policy,
> >>
> >>switch (event) {
> >>case CPUFREQ_GOV_POLICY_INIT:
> >> + /*
> >> + * In order to keep governor data across suspend/resume,
> >> + * Governor doesn't exit when suspend and will be
> >> + * reinitialized when resume. Here check policy governor
> >> + * data to determine whether the governor has been exited.
> >> + * If not, return EALREADY.
> >> + */
> >>if (have_governor_per_policy()) {
> >> - WARN_ON(dbs_data);
> >> + if (dbs_data)
> >> + return -EALREADY;
> >>} else if (dbs_data) {
> >> + if (policy->governor_data == dbs_data)
> >> + return -EALREADY;
> >> +
> >>dbs_data->usage_count++;
> >>policy->governor_data = dbs_data;
> >>return 0;
> >>
>
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
xen drivers fail to link on ARM with v3.12-9888-gf63c482
Hi All, The xen-gntalloc, xen-netfront, xen-blkfront, and xen-netback drivers fail to link on ARM today with the following error: ERROR: "phys_to_mach" [drivers/xen/xen-gntalloc.ko] undefined! ERROR: "phys_to_mach" [drivers/net/xen-netfront.ko] undefined! ERROR: "phys_to_mach" [drivers/net/xen-netback/xen-netback.ko] undefined! ERROR: "phys_to_mach" [drivers/block/xen-blkfront.ko] undefined! This is with Linus' tree as of this morning. I'm guessing this is because the mfn_to_pfn and pfn_to_mfn functions are inlined and reference phys_to_mach directly, and that isn't exported to modules. Thoughts? josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Update PATCH 1/1] Cpufreq: Make governor data on nonboot cpus across system suspend/resume
On Saturday, November 16, 2013 08:27:07 PM Viresh Kumar wrote: > On 16 November 2013 20:11, Rafael J. Wysocki wrote: > > On Saturday, November 16, 2013 11:59:59 AM Lan Tianyu wrote: > > >> Defaultly, all cpus use ondemand governor after bootup. Change one > >> non-boot cpu's governor to conservative, > > > > Well, why would anyone want to do that? Just out of curiosity ... > > People may want to use different group/cluster/socket of CPUs differently, > with different kind of policies. Maybe performance governor for boot cpu > and ondemand for others. > > This bug would also be there for big LITTLE where we want to have > separate set of tunables for big and LITTLE clusters for the same type > of governor. > > > So this is acpi-cpufreq, right? > > Probably yes, I saw something similar somewhere.. But this is driver > independent.. > > > The patch looks basically OK to me, but -> > > We wouldn't need this patch if my other patch (where I am disabling > governors in suspend/resume goes in, in any form).. Yes, I know that, but I don't think this is the right approach. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Update PATCH 1/1] Cpufreq: Make governor data on nonboot cpus across system suspend/resume
On 16 November 2013 20:11, Rafael J. Wysocki wrote: > On Saturday, November 16, 2013 11:59:59 AM Lan Tianyu wrote: >> Defaultly, all cpus use ondemand governor after bootup. Change one >> non-boot cpu's governor to conservative, > > Well, why would anyone want to do that? Just out of curiosity ... People may want to use different group/cluster/socket of CPUs differently, with different kind of policies. Maybe performance governor for boot cpu and ondemand for others. This bug would also be there for big LITTLE where we want to have separate set of tunables for big and LITTLE clusters for the same type of governor. > So this is acpi-cpufreq, right? Probably yes, I saw something similar somewhere.. But this is driver independent.. > The patch looks basically OK to me, but -> We wouldn't need this patch if my other patch (where I am disabling governors in suspend/resume goes in, in any form).. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Update PATCH 1/1] Cpufreq: Make governor data on nonboot cpus across system suspend/resume
On Saturday, November 16, 2013 03:41:10 PM Rafael J. Wysocki wrote:
[...]
> > >> @@ -1822,6 +1822,9 @@ static int __cpufreq_governor(struct
> > >> cpufreq_policy *policy,
> > >> ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
> > >> module_put(policy->governor->owner);
> > >>
> > >> +if ((event == CPUFREQ_GOV_POLICY_INIT) && ret == -EALREADY)
> > >> +ret = 0;
> > >> +
>
> -> I'd prefer this check to be combined with the one done to determine whether
> or not we need to do the module_put(). Something like
>
> if (event == CPUFREQ_GOV_POLICY_EXIT && ret) {
Obviously, that should be:
if (event == CPUFREQ_GOV_POLICY_INIT && ret) {
> module_put(policy->governor->owner);
> if (ret == -EALREADY)
> return 0;
> } else if (event == CPUFREQ_GOV_POLICY_EXIT && !ret) {
> module_put(policy->governor->owner);
> }
Sorry for the confusion.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [V13-prerc]: REGRESSION: "*ERROR* Timed out waiting for forcewake old ack to clear"
On Sat, Nov 16, 2013 at 3:39 PM, Jörg Otte wrote: > 2013/11/16 Daniel Vetter : >> On Sat, Nov 16, 2013 at 12:28 PM, Jörg Otte wrote: >>> On startup I get the following error display on the console: >>> "*ERROR* Timed out waiting for forcewake old ack to clear" >>> >>> I already reported this error a year ago at the time of v3.7 >>> ( see https://lkml.org/lkml/2012/11/27/355) >>> which was fixed later on. >>> >>> Now this error is back again. Kernel 3.12.0-09888-gf63c48 >> >> Please boot with drm.debug=0xe, reproduce the issue and then attach >> the complete dmesg (including all the boot message, so if it takes a >> while to reproduce please grab an boot dmesg, too). >> >> Also adding the right mailing lists, see MAINTAINERS. >> >> Thanks, Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > Thanks, Jörg Yeah, we've broken the early uncore sanitize stuff again :( I'll send out a patch asap. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 3.4.57: "tg3 0000:01:00.0: eth0: transmit timed out, resetting"
[+cc Nithin, Michael, netdev] On Sat, Nov 16, 2013 at 7:01 AM, Urban Loesch wrote: > Hi, > > I'm running a DELL PER620 with kernel 3.4.57 an Broadcom quad-port gbit > adapter BCM5720. 15min load-average is about 4-8. > > After 13 days of uptime today the machine becomes unresponsible. But after a > couple of minutes it becomes responsible again and was rebooted (sysctl > paremter for kernel.panic = 1) automatically. the machine is acting a > webserver fo about 3000 virtualhosts. > > After searching the lofiles on remote my syslog server I found the following > messages regarding eth0: > > 2013-11-16 11:43:38 [1505491.196172] tg3 :01:00.0: eth0: transmit timed > out, resetting > 2013-11-16 11:43:38 [1505491.815002] INFO: rcu_bh detected stalls on > CPUs/tasks: > 2013-11-16 11:43:38 [1505491.815009] 16: (1 GPs behind) > idle=1fd/140/0 > 2013-11-16 11:43:38 [1505491.815012] (detected by 6, t=6002 jiffies) > 2013-11-16 11:43:38 [1505491.815014] INFO: Stall ended before state dump > start > 2013-11-16 11:43:38 [1505492.450611] tg3 :01:00.0: eth0: 0x: > 0x165f14e4, 0x00100406, 0x0200, 0x00800010 > 2013-11-16 11:43:38 [1505492.450614] tg3 :01:00.0: eth0: 0x0010: > 0xd57a000c, 0x, 0xd57b000c, 0x > 2013-11-16 11:43:38 [1505492.450615] tg3 :01:00.0: eth0: 0x0020: > 0xd57c000c, 0x, 0x, 0x1f5b1028 > 2013-11-16 11:43:38 [1505492.450617] tg3 :01:00.0: eth0: 0x0030: > 0xd880, 0x0048, 0x, 0x010f > 2013-11-16 11:43:38 [1505492.450619] tg3 :01:00.0: eth0: 0x0040: > 0x, 0x3f00, 0xc8035001, 0x64002008 > 2013-11-16 11:43:38 [1505492.450621] tg3 :01:00.0: eth0: 0x0050: > 0x818c5803, 0x7800, 0x0086a005, 0x > 2013-11-16 11:43:38 [1505492.450623] tg3 :01:00.0: eth0: 0x0060: > 0x, 0x, 0xf298, 0x00380081 > 2013-11-16 11:43:38 [1505492.450624] tg3 :01:00.0: eth0: 0x0070: > 0x000710b0, 0xffcb28fa, 0x0001421c, 0x > 2013-11-16 11:43:38 [1505492.450626] tg3 :01:00.0: eth0: 0x0080: > 0x0001, 0x0002, 0x, 0x01d2 > 2013-11-16 11:43:38 [1505492.450628] tg3 :01:00.0: eth0: 0x0090: > 0x, 0x, 0x, 0x06a1 > 2013-11-16 11:43:38 [1505492.450629] tg3 :01:00.0: eth0: 0x00a0: > 0x8010ac11, 0x0004, 0x1004, 0x00020010 > 2013-11-16 11:43:38 [1505492.450631] tg3 :01:00.0: eth0: 0x00b0: > 0x10008d81, 0x0010242e, 0x0004cc22, 0x10120040 > 2013-11-16 11:43:38 [1505492.450633] tg3 :01:00.0: eth0: 0x00d0: > 0x001f, 0x0006, 0x, 0x0001 > 2013-11-16 11:43:38 [1505492.450635] tg3 :01:00.0: eth0: 0x00f0: > 0x, 0x0572, 0x, 0xbec733be > 2013-11-16 11:43:38 [1505492.450637] tg3 :01:00.0: eth0: 0x0100: > 0x13c10001, 0x, 0x00018000, 0x000e7030 > 2013-11-16 11:43:38 [1505492.450638] tg3 :01:00.0: eth0: 0x0110: > 0x2000, 0x31c0, 0x00a0, 0x > 2013-11-16 11:43:38 [1505492.450640] tg3 :01:00.0: eth0: 0x0130: > 0x, 0x, 0x, 0x15010003 > 2013-11-16 11:43:38 [1505492.450642] tg3 :01:00.0: eth0: 0x0140: > 0x1c3f67fa, 0x90b1, 0x, 0x > 2013-11-16 11:43:38 [1505492.450643] tg3 :01:00.0: eth0: 0x0150: > 0x16010004, 0x, 0x0007811b, 0x0001 > 2013-11-16 11:43:38 [1505492.450645] tg3 :01:00.0: eth0: 0x0160: > 0x00010002, 0x, 0x, 0x > 2013-11-16 11:43:38 [1505492.450647] tg3 :01:00.0: eth0: 0x0170: > 0x, 0x80ff, 0x, 0x > 2013-11-16 11:43:38 [1505492.450648] tg3 :01:00.0: eth0: 0x0200: > 0x, 0x3f00, 0x, 0xfb00 > 2013-11-16 11:43:38 [1505492.450650] tg3 :01:00.0: eth0: 0x0210: > 0x, 0x0d00, 0x, 0xa700 > 2013-11-16 11:43:38 [1505492.450652] tg3 :01:00.0: eth0: 0x0220: > 0x, 0x0001, 0x, 0x > 2013-11-16 11:43:38 [1505492.450653] tg3 :01:00.0: eth0: 0x0260: > 0x, 0x, 0x, 0x06a1 > 2013-11-16 11:43:38 [1505492.450655] tg3 :01:00.0: eth0: 0x0280: > 0x, 0x01d2, 0x, 0x0d73 > 2013-11-16 11:43:38 [1505492.450657] tg3 :01:00.0: eth0: 0x0290: > 0x, 0x04df, 0x, 0x01b5 > 2013-11-16 11:43:38 [1505492.450659] tg3 :01:00.0: eth0: 0x0300: > 0x010d, 0x01df, 0x00bb, 0x0035 > 2013-11-16 11:43:38 [1505492.450660] tg3 :01:00.0: eth0: 0x0400: > 0x18e04808, 0x0040, 0x1000, 0x0880 > 2013-11-16 11:43:38 [1505492.450662] tg3 :01:00.0: eth0: 0x0410: > 0x90b1, 0x1c3f67fa, 0x90b1, 0x1c3f67fa > 2013-11-16 11:43:38 [1505492.450664] tg3 :01:00.0: eth0: 0x0420: > 0x90b1, 0x1c3f67fa, 0x90b1, 0x1c3f67fa > 2013-11-16 11:43:38 [1505492.450666] tg3 :01:00.0: eth0: 0x0430: > 0x0400, 0x00
Re: [PATCH] ARM: fix /proc/$PID/stack to work on SMP
On Sat, Nov 16, 2013 at 10:58:44PM +0800, ivan lam wrote: > In arm, we can't get stack info of the other tasks via > /proc/$PID/stack file. for example: > > # sleep 1000 & > # ps -ef | grep sleep > 536 0 0:00 sleep 1000 > 538 0 0:00 grep sleep > # cat /proc/536/stack > [] 0x > > If a thread was scheduled out, this proc should provide > useful backtrace for debug. Try to unwind the stack based > on the previous scheduled out register file whatever a > thread is in Running state or not. > > After this fix, result as: > > # cat /proc/536/stack > [<8003f018>] hrtimer_nanosleep+0x8c/0x108 > [<8003f134>] SyS_nanosleep+0xa0/0xb0 > [<8000e220>] ret_fast_syscall+0x0/0x30 > [] 0x > > If a thread is Running on the oher CPUs, the result is not accurate, > but this is acceptable. This behaviors are same as x86 and arm64 arch. As we have people running around trying to add additional checks to the unwinder to stop it going wrong, I've no plans to apply any patch like this until we're more sure that it won't open up the possibility for any user process to crash the kernel. That in itself is a massive security issue because its an effective DoS attack. Moreover, your emailer has totally screwed the patch, so it's impossible to apply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] cpufreq: suspend/resume governors with PM notifiers
On 16 November 2013 19:59, Rafael J. Wysocki wrote: > Well, disabling it for the whole duration of suspend/resume and/or hibernation > may not be the right approach entirely, unless we force the pax perf of the s/pax/max ? > boot CPU at least in addition to that. Otherwise the latency of suspend and > the subsequent resume will depend on what perf level the CPUs where before > disabling the governors, which is not desirable at al. Well that is pretty much doable. >> And these are the notifications that we send: >> - PM_HIBERNATION_PREPARE >> - PM_POST_HIBERNATION >> - PM_RESTORE_PREPARE >> - PM_POST_RESTORE >> >> If I am not wrong I need to stop governors on PM_HIBERNATION_PREPARE and >> need to >> start them back on: PM_POST_HIBERNATION (I am a bit confused with this one. >> Does >> this POST_HIBERNATION one happens at the end of going into hibernation? or >> after >> booting back? I need a notifier at the end of restore).. > > You'd need both PM_POST_HIBERNATION and PM_POST_RESTORE, but I wouldn't really > like cpufreq governors to be disabled throughout the whole hibernation. So PM_POST_HIBERNATION is called just before shutting off the system? And PM_POST_RESTORE is called after system is resumed from saved image? > Actually, we use CPU offline/online during system suspend/resume to avoid > having to do stuff like this from PM notifiers. I didn't get the logic behind this one.. > So I'd like the original problem to be addressed in a different way. Hmm.. > PS > The sisk.pl address will start bouncing shortly, so please replace it with > r...@rjwysocki.net in your address book. Okay... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf tip: fails to convert comm
On 11/15/13, 6:02 PM, Frederic Weisbecker wrote: On Fri, Nov 15, 2013 at 09:29:51AM -0700, David Ahern wrote: HI Frederic: On 11/13/13, 11:03 AM, Frederic Weisbecker wrote: I see. I can reproduce, I'll check and see what happens. It would be nice if we could have an option to dump internal perf events like comm events as well in the perf script stream. Any progress on a solution? This is a regression in 3.13. So the problem is that when a thread overrides its default ":%pid" comm, we forget to tag the thread comm as overriden. Hence, this overriden comm is not inherited on future forks. So here is a fix. Tell me if you see more issue, I'll cook a proper changelog and resend if everyting looks good. That works for me. Thank you. Tested-by: David Ahern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 11/14] bonding/bond_main: Apply ACCESS_ONCE() to avoid sparse false positive
On Sat, Nov 16, 2013 at 12:32:16PM +0800, Ding Tianhong wrote:
> 于 2013/11/16 8:40, Paul E. McKenney 写道:
> > From: "Paul E. McKenney"
> >
> > The sparse checking for rcu_assign_pointer() was recently upgraded
> > to reject non-__kernel address spaces. This also rejects __rcu,
> > which is almost always the right thing to do. However, the uses in
> > bond_change_active_slave() and __bond_release_one() are legitimate:
> > They are assigning a pointer to an element from an RCU-protected list
> > (or a NULL pointer), and all elements of this list are already visible
> > to caller.
> >
> > This commit therefore silences these false positives either by laundering
> > the pointers using ACCESS_ONCE() as suggested by Eric Dumazet and Josh
> > Triplett, or by using RCU_INIT_POINTER() for NULL pointer assignments.
>
> I think it is fit for net-next.
Thank you!
If this is queued there, I would be happy to drop it from my tree.
There are no dependencies on anything in my tree.
Thanx, Paul
> > Reported-by: kbuild test robot
> > Signed-off-by: Paul E. McKenney
> > Cc: Stephen Hemminger
> > Cc: "David S. Miller"
> > Cc: bri...@lists.linux-foundation.org
> > Cc: net...@vger.kernel.org
> > ---
> > drivers/net/bonding/bond_main.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/bonding/bond_main.c
> > b/drivers/net/bonding/bond_main.c
> > index 72df399c4ab3..bbd7fd3e46fe 100644
> > --- a/drivers/net/bonding/bond_main.c
> > +++ b/drivers/net/bonding/bond_main.c
> > @@ -890,7 +890,8 @@ void bond_change_active_slave(struct bonding *bond,
> > struct slave *new_active)
> > if (new_active)
> > bond_set_slave_active_flags(new_active);
> > } else {
> > - rcu_assign_pointer(bond->curr_active_slave, new_active);
> > + /* Both --rcu and visible, so ACCESS_ONCE() is OK. */
> > + ACCESS_ONCE(bond->curr_active_slave) = new_active;
> > }
> >
> > if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) {
> > @@ -1801,7 +1802,7 @@ static int __bond_release_one(struct net_device
> > *bond_dev,
> > }
> >
> > if (all) {
> > - rcu_assign_pointer(bond->curr_active_slave, NULL);
> > + RCU_INIT_POINTER(bond->curr_active_slave, NULL);
> > } else if (oldcurrent == slave) {
> > /*
> > * Note that we hold RTNL over this sequence, so there
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Update PATCH 1/1] Cpufreq: Make governor data on nonboot cpus across system suspend/resume
On 11/16/2013 10:41 PM, Rafael J. Wysocki wrote:
On Saturday, November 16, 2013 11:59:59 AM Lan Tianyu wrote:
On 11/16/2013 08:38 AM, Rafael J. Wysocki wrote:
On Friday, November 15, 2013 04:15:34 PM Lan Tianyu wrote:
Currently, governor of nonboot cpus will be put to EXIT when system suspend.
Since all these cpus will be unplugged and the governor usage_count decreases
to zero. The governor data and its sysfs interfaces will be freed or released.
This makes user config of these governors loss during suspend and resume.
First off, do we have a pointer to a bug report related to that?
No, I found this bug when I tried to resolve other similar bug.
https://bugzilla.kernel.org/show_bug.cgi?id=63081. I still have no idea
about bug 63081 and asked reporter to try this patch.
Second, what does need to be done to reproduce this problem?
Defaultly, all cpus use ondemand governor after bootup. Change one
non-boot cpu's governor to conservative,
Well, why would anyone want to do that? Just out of curiosity ...
Just use this way to produce the issue. But on the laptop, I think
fewer people will do the same thing. Just like Viresh said, this also
will affect the systems of governor per policy.
modify conservative config via sysfs interface and then do system suspend.
After resume, the config of conservative is reset. On my machine, all cpus
have owen policy.
So this is acpi-cpufreq, right?
Yes, it's acpi-cpufreq driver.
The patch looks basically OK to me, but ->
This doesn't happen on the governor covering boot cpu because it isn't
unplugged during system suspend.
To fix this issue, skipping governor exit during system suspend and check
policy governor data to determine whether the governor is really needed
to be initialized when do init. If not, return EALREADY to indicate the
governor has been initialized and should do nothing. __cpufreq_governor()
convert EALREADY to 0 as return value for INIT event since governor is
still under INIT state and can do START operation.
Signed-off-by: Lan Tianyu
---
Fix some typos
drivers/cpufreq/cpufreq.c | 5 -
drivers/cpufreq/cpufreq_governor.c | 13 -
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..38f2e4a 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1239,7 +1239,7 @@ static int __cpufreq_remove_dev_finish(struct device *dev,
/* If cpu is last user of policy, free policy */
if (cpus == 1) {
- if (has_target()) {
+ if (has_target() && !frozen) {
ret = __cpufreq_governor(policy,
CPUFREQ_GOV_POLICY_EXIT);
if (ret) {
@@ -1822,6 +1822,9 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
module_put(policy->governor->owner);
+ if ((event == CPUFREQ_GOV_POLICY_INIT) && ret == -EALREADY)
+ ret = 0;
+
-> I'd prefer this check to be combined with the one done to determine whether
or not we need to do the module_put(). Something like
if (event == CPUFREQ_GOV_POLICY_EXIT && ret) {
module_put(policy->governor->owner);
if (ret == -EALREADY)
return 0;
} else if (event == CPUFREQ_GOV_POLICY_EXIT && !ret) {
module_put(policy->governor->owner);
}
Ok. I will update soon.
Thanks!
return ret;
}
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 0806c31..ddb93af 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -204,9 +204,20 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
switch (event) {
case CPUFREQ_GOV_POLICY_INIT:
+ /*
+* In order to keep governor data across suspend/resume,
+* Governor doesn't exit when suspend and will be
+* reinitialized when resume. Here check policy governor
+* data to determine whether the governor has been exited.
+* If not, return EALREADY.
+*/
if (have_governor_per_policy()) {
- WARN_ON(dbs_data);
+ if (dbs_data)
+ return -EALREADY;
} else if (dbs_data) {
+ if (policy->governor_data == dbs_data)
+ return -EALREADY;
+
dbs_data->usage_count++;
policy->governor_data = dbs_data;
return 0;
--
Best Regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
Re: [PATCH] power: Change device_wakeup_enable() to check for null dev_name(dev)
On 11/15/2013 05:25 PM, Greg KH wrote: On Fri, Nov 15, 2013 at 05:16:31PM -0700, Shuah Khan wrote: On 11/15/2013 05:21 PM, Rafael J. Wysocki wrote: On Friday, November 15, 2013 05:03:57 PM Shuah Khan wrote: device_wakeup_enable() uses dev_name(dev) as the wakeup source name. When it gets called with a device with its name not yet set, ws structure with ws->name = NULL gets created. When kernel is booted with wakeup_source_activate enabled, it will panic when the trace point code tries to derefernces ws->name. Change device_wakeup_enable() to check for dev_name(dev) null condition and return -EINVAL to avoid panics when device_wakeup_enable() gets called before device is fully initialized with its name. return -EINVAL; Can you please use WARN_ON(!dev_name(dev)) here? While I agree that it is a bad idea to crash the kernel because dev has no name, that indicates a driver bug that shouldn't be too easy to ignore. Thanks! Right. ok I will re-cut the patch with WARN_ON and send it. fyi I did send fix for the driver (power_supply) as well. http://www.kernelhub.org/?msg=362354&p=2 Why is a driver calling kobject_set_name() instead of device_set_name()? Yes, it's really the same thing deep down, but drivers should never care about a kobject, just 'struct device'. Well, even then it usually should care about it's type of 'struct device' but that's a different issue... Anyway, not saying your patch is wrong at all, just for the future if people are looking for code cleanups... Use of kobject_set_name() did look odd to me. I will fix that for this driver by re-doing the patch while I am it. About the power_supply patch, stable needs fixing as well, and I will have to backport once he fix goes into the mainline. http://www.kernelhub.org/?msg=362354&p=2 as is doesn't apply to 3.10 and 3.11 -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] Cpufreq: Make governor data on nonboot cpus across system suspend/resume
Currently, governor of nonboot cpus will be put to EXIT when system suspend.
Since all these cpus will be unplugged and the governor usage_count decreases
to zero. The governor data and its sysfs interfaces will be freed or released.
This makes user config of these governors loss during suspend and resume.
This doesn't happen on the governor covering boot cpu because it isn't
unplugged during system suspend.
To fix this issue, skipping governor exit during system suspend and check
policy governor data to determine whether the governor is really needed
to be initialized when do init. If not, return EALREADY to indicate the
governor has been initialized and should do nothing. __cpufreq_governor()
convert EALREADY to 0 as return value for INIT event since governor is
still under INIT state and can do START operation.
Signed-off-by: Lan Tianyu
---
Change since v1:
Change coding style.
drivers/cpufreq/cpufreq.c | 10 +++---
drivers/cpufreq/cpufreq_governor.c | 13 -
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..73ad593 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1239,7 +1239,7 @@ static int __cpufreq_remove_dev_finish(struct device *dev,
/* If cpu is last user of policy, free policy */
if (cpus == 1) {
- if (has_target()) {
+ if (has_target() && !frozen) {
ret = __cpufreq_governor(policy,
CPUFREQ_GOV_POLICY_EXIT);
if (ret) {
@@ -1818,9 +1818,13 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
mutex_unlock(&cpufreq_governor_lock);
}
- if (((event == CPUFREQ_GOV_POLICY_INIT) && ret) ||
- ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
+ if ((event == CPUFREQ_GOV_POLICY_INIT) && ret) {
+ module_put(policy->governor->owner);
+ if (ret == -EALREADY)
+ return 0;
+ } else if ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret) {
module_put(policy->governor->owner);
+ }
return ret;
}
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 0806c31..ddb93af 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -204,9 +204,20 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
switch (event) {
case CPUFREQ_GOV_POLICY_INIT:
+ /*
+* In order to keep governor data across suspend/resume,
+* Governor doesn't exit when suspend and will be
+* reinitialized when resume. Here check policy governor
+* data to determine whether the governor has been exited.
+* If not, return EALREADY.
+*/
if (have_governor_per_policy()) {
- WARN_ON(dbs_data);
+ if (dbs_data)
+ return -EALREADY;
} else if (dbs_data) {
+ if (policy->governor_data == dbs_data)
+ return -EALREADY;
+
dbs_data->usage_count++;
policy->governor_data = dbs_data;
return 0;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: Fallback to of_node of parent
Many busses (e.g. tegra, omap, bcm2835)
need to set the of_node of the adapter
device to the one of the parent device, i.e.
adap->dev.of_node = pdev->dev.of_node;
As suggested by Stephen Warren, this could also
be done in the i2c core and it is a common mistake
to forget this line:
I2C: BCM2835: Linking platform nodes to adapter nodes
i2c: Fix device tree binding for i2c-cbus-gpio
Signed-off-by: Florian Meier
Suggested-by: Stephen Warren
---
drivers/i2c/i2c-core.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 430c001..c8e33a5 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1310,6 +1310,9 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
struct device *dev = &adapter->dev;
int id;
+ if (!dev->of_node && dev->parent)
+ dev->of_node = dev->parent->of_node;
+
if (dev->of_node) {
id = of_alias_get_id(dev->of_node, "i2c");
if (id >= 0) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 4/4] documentation: Update circular buffer for load-acquire/store-release
On Sat, Nov 16, 2013 at 11:58:45AM +, David Howells wrote: > Paul E. McKenney wrote: > > > - /* read index before reading contents at that index */ > > > - smp_mb(); /* finish reading descriptor before incrementing tail > > */ > > I'd rather you didn't remove these comments (assuming they're correct) as > they're pointing out the point of the example. Ah, good point! I have added them back just before the smp_load_acquire() and smp_store_release(), as shown below. Does that work? Thanx, Paul diff --git a/Documentation/circular-buffers.txt b/Documentation/circular-buffers.txt index 15e54ff50018..88951b179262 100644 --- a/Documentation/circular-buffers.txt +++ b/Documentation/circular-buffers.txt @@ -200,6 +200,7 @@ The consumer will look something like this: spin_lock(&consumer_lock); + /* Read index before reading contents at that index. */ unsigned long head = smp_load_acquire(buffer->head); unsigned long tail = buffer->tail; @@ -210,6 +211,7 @@ The consumer will look something like this: consume_item(item); + /* Finish reading descriptor before incrementing tail. */ smp_store_release(buffer->tail, (tail + 1) & (buffer->size - 1)); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vmstat: On demand vmstat workers V3
On Thu, Oct 03, 2013 at 05:40:40PM +, Christoph Lameter wrote:
> V2->V3:
> - Introduce a new tick_get_housekeeping_cpu() function. Not sure
> if that is exactly what we want but it is a start. Thomas?
Not really. Thomas suggested an infrastructure to move CPU-local periodic
jobs handling to be offlined to set of remote housekeeping CPU.
This could be potentially useful for many kind of stats relying on
periodic updates, the scheduler tick being a candidate (I have yet to
check if we can really apply that in practice though).
Now the problem is that vmstats updates use pure local lockless
operations. It may be possible to offline this update to remote CPUs
but then we need to convert vmstats updates to use locks. Which is
potentially costly. Unless we can find some clever lockless update
scheme. Do you think this can be possible?
See below for more detailed review:
[...]
>
> /*
> @@ -1213,12 +1229,15 @@ static const struct file_operations proc
> #ifdef CONFIG_SMP
> static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
> int sysctl_stat_interval __read_mostly = HZ;
> +static struct cpumask *monitored_cpus;
>
> static void vmstat_update(struct work_struct *w)
> {
> - refresh_cpu_vm_stats();
> - schedule_delayed_work(&__get_cpu_var(vmstat_work),
> - round_jiffies_relative(sysctl_stat_interval));
> + if (refresh_cpu_vm_stats())
> + schedule_delayed_work(this_cpu_ptr(&vmstat_work),
> + round_jiffies_relative(sysctl_stat_interval));
> + else
> + cpumask_set_cpu(smp_processor_id(), monitored_cpus);
That looks racy against other CPUs that may set their own bit and also
against the shepherd that clears processed monitored CPUs.
That seem to matter because a CPU could be simply entirely forgotten
by vmstat and never processed again.
> }
>
> static void start_cpu_timer(int cpu)
> @@ -1226,7 +1245,70 @@ static void start_cpu_timer(int cpu)
> struct delayed_work *work = &per_cpu(vmstat_work, cpu);
>
> INIT_DEFERRABLE_WORK(work, vmstat_update);
> - schedule_delayed_work_on(cpu, work, __round_jiffies_relative(HZ, cpu));
> + schedule_delayed_work_on(cpu, work,
> + __round_jiffies_relative(sysctl_stat_interval, cpu));
> +}
> +
> +/*
> + * Check if the diffs for a certain cpu indicate that
> + * an update is needed.
> + */
> +static bool need_update(int cpu)
> +{
> + struct zone *zone;
> +
> + for_each_populated_zone(zone) {
> + struct per_cpu_pageset *p = per_cpu_ptr(zone->pageset, cpu);
> +
> + /*
> + * The fast way of checking if there are any vmstat diffs.
> + * This works because the diffs are byte sized items.
> + */
> + if (memchr_inv(p->vm_stat_diff, 0, NR_VM_ZONE_STAT_ITEMS))
> + return true;
> + }
> + return false;
> +}
> +
> +static void vmstat_shepherd(struct work_struct *w)
> +{
> + int cpu;
> + int s = tick_get_housekeeping_cpu();
> + struct delayed_work *d = per_cpu_ptr(&vmstat_work, s);
> +
> + refresh_cpu_vm_stats();
> +
> + for_each_cpu(cpu, monitored_cpus)
> + if (need_update(cpu)) {
> + cpumask_clear_cpu(cpu, monitored_cpus);
> + start_cpu_timer(cpu);
> + }
> +
> + if (s != smp_processor_id()) {
> + /* Timekeeping was moved. Move the shepherd worker */
> + cpumask_set_cpu(smp_processor_id(), monitored_cpus);
> + cpumask_clear_cpu(s, monitored_cpus);
> + cancel_delayed_work_sync(d);
> + INIT_DEFERRABLE_WORK(d, vmstat_shepherd);
> + }
> +
> + schedule_delayed_work_on(s, d,
> + __round_jiffies_relative(sysctl_stat_interval, s));
Note that on dynticks idle (CONFIG_NO_HZ_IDLE=y), the timekeeper CPU can change
quickly and often.
I can imagine a nasty race there: CPU 0 is the timekeeper. It schedules the
vmstat sherpherd work in 2 seconds. But CPU 0 goes to sleep for a big while
and some other CPU takes the timekeeping duty. The shepherd timer won't be
processed until CPU 0 wakes up although we may have CPUs to monitor.
CONFIG_NO_HZ_FULL may work incidentally because CPU 0 is the only timekeeper
there
but this is a temporary limitation. Expect the timekeeper to be dynamic in the
future
under that config.
> +
> +}
> +
> +static void __init start_shepherd_timer(void)
> +{
> + int cpu = tick_get_housekeeping_cpu();
> + struct delayed_work *d = per_cpu_ptr(&vmstat_work, cpu);
> +
> + INIT_DEFERRABLE_WORK(d, vmstat_shepherd);
> + monitored_cpus = kmalloc(BITS_TO_LONGS(nr_cpu_ids) * sizeof(long),
> + GFP_KERNEL);
> + cpumask_copy(monitored_cpus, cpu_online_mask);
> + cpumask_clear_cpu(cpu, monitored_cpus);
> + schedule_delayed_work_on(cpu, d,
> + __round_jiffies_relative(sysctl_stat_interval, cpu));
> }
So another issue with the whole design of t
Re: [patch 1/2] autofs4: allow autofs to work outside the initial PID namespace
On 11/15, Andrew Morton wrote:
>
> Enable autofs4 to work in a "container". oz_pgrp is converted from pid_t
> to struct pid and this is stored at mount time based on the "pgrp=" option
> or if the option is missing then the current pgrp.
I don't understand this code, so I am probably wrong. And this is minor
anyway, but...
> @@ -357,7 +358,17 @@ static int autofs_dev_ioctl_setpipefd(st
> mutex_unlock(&sbi->wq_mutex);
> return -EBUSY;
> } else {
> - struct file *pipe = fget(pipefd);
> + struct file *pipe;
> +
> + new_pid = get_task_pid(current, PIDTYPE_PGID);
> +
> + if (ns_of_pid(new_pid) != ns_of_pid(sbi->oz_pgrp)) {
> + AUTOFS_WARN("Not allowed to change PID namespace");
> + err = -EINVAL;
> + goto out;
> + }
> +
> + pipe = fget(pipefd);
> if (!pipe) {
> err = -EBADF;
> goto out;
> @@ -367,12 +378,13 @@ static int autofs_dev_ioctl_setpipefd(st
> fput(pipe);
> goto out;
> }
> - sbi->oz_pgrp = task_pgrp_nr(current);
> + swap(sbi->oz_pgrp, new_pid);
> sbi->pipefd = pipefd;
> sbi->pipe = pipe;
> sbi->catatonic = 0;
> }
> out:
> + put_pid(new_pid);
This looks suspicious, put_pid() can actually kfree the old sbi->oz_pgrp
swapped above. IOW, this assumes we can't race with any user of ->oz_pgrp.
For example,
> @@ -80,7 +83,7 @@ static int autofs4_show_options(struct s
> if (!gid_eq(root_inode->i_gid, GLOBAL_ROOT_GID))
> seq_printf(m, ",gid=%u",
> from_kgid_munged(&init_user_ns, root_inode->i_gid));
> - seq_printf(m, ",pgrp=%d", sbi->oz_pgrp);
> + seq_printf(m, ",pgrp=%d", pid_vnr(sbi->oz_pgrp));
Can't this race with autofs_dev_ioctl_setpipefd() above?
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 4/4] documentation: Update circular buffer for load-acquire/store-release
On Fri, Nov 15, 2013 at 04:10:30PM -0800, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > This commit replaces full barriers by targeted use of load-acquire and > store-release. I guess I'd better hurry up merging the patches that introduce these thingies someplace :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: Fallback to of_node of parent
> + if (!dev->of_node && dev->parent) > + dev->of_node = dev->parent->of_node; > + That is not enough. Current drivers could then have the assignment removed and even more important, this behaviour should be documented. Regards, Wolfram signature.asc Description: Digital signature
Re: [PATCH] i2c: Fallback to of_node of parent
Ok, I will try to find all relevant lines. Where is the best place to document this? Greetings, Florian 2013/11/16 Wolfram Sang : > >> + if (!dev->of_node && dev->parent) >> + dev->of_node = dev->parent->of_node; >> + > > That is not enough. Current drivers could then have the assignment > removed and even more important, this behaviour should be documented. > > Regards, > >Wolfram > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xen drivers fail to link on ARM with v3.12-9888-gf63c482
On Sat, Nov 16, 2013 at 9:56 AM, Josh Boyer wrote:
> Hi All,
>
> The xen-gntalloc, xen-netfront, xen-blkfront, and xen-netback drivers
> fail to link on ARM today with the following error:
>
> ERROR: "phys_to_mach" [drivers/xen/xen-gntalloc.ko] undefined!
> ERROR: "phys_to_mach" [drivers/net/xen-netfront.ko] undefined!
> ERROR: "phys_to_mach" [drivers/net/xen-netback/xen-netback.ko] undefined!
> ERROR: "phys_to_mach" [drivers/block/xen-blkfront.ko] undefined!
>
> This is with Linus' tree as of this morning.
>
> I'm guessing this is because the mfn_to_pfn and pfn_to_mfn functions
> are inlined and reference phys_to_mach directly, and that isn't
> exported to modules. Thoughts?
The patch below seems to fix this, but I'm not sure it's the desired
approach. I added the export for mach_to_phys just in case.
josh
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index 23732cd..7772fa8 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -27,7 +27,9 @@ struct xen_p2m_entry {
rwlock_t p2m_lock;
struct rb_root phys_to_mach = RB_ROOT;
+EXPORT_SYMBOL_GPL(phys_to_mach);
static struct rb_root mach_to_phys = RB_ROOT;
+EXPORT_SYMBOL_GPL(mach_to_phys);
static int xen_add_phys_to_mach_entry(struct xen_p2m_entry *new)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 16/23] ASoC: omap: mcbsp, mcpdm, dmic: raw read and write endian fix
On 11/16/2013 02:01 AM, Taras Kondratiuk wrote: > From: Victor Kamensky > > All OMAP IP blocks expect LE data, but CPU may operate in BE mode. > Need to use endian neutral functions to read/write h/w registers. > I.e instead of __raw_read[lw] and __raw_write[lw] functions code > need to use read[lw]_relaxed and write[lw]_relaxed functions. > If the first simply reads/writes register, the second will byteswap > it if host operates in BE mode. > > Changes are trivial sed like replacement of __raw_xxx functions > with xxx_relaxed variant. > > Signed-off-by: Victor Kamensky > Signed-off-by: Taras Kondratiuk > --- > sound/soc/omap/mcbsp.c | 12 ++-- > sound/soc/omap/omap-dmic.c |4 ++-- > sound/soc/omap/omap-mcpdm.c |4 ++-- > 3 files changed, 10 insertions(+), 10 deletions(-) > Looks ok to me by looking at the _relaxed definitions in arch/arm/include/asm/io.h. Acked-by: Jarkko Nikula -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: Fallback to of_node of parent
I have looked through all bus drivers and in most cases they have a corresponding line that could be removed. Although, this patch would break i2c-powermac, because it relies on the fact that of_node stays NULL. Any idea how to handle that? Greetings, Florian On 16.11.2013 17:11, Florian Meier wrote: > Ok, I will try to find all relevant lines. > Where is the best place to document this? > > Greetings, > Florian > > 2013/11/16 Wolfram Sang : >> >>> + if (!dev->of_node && dev->parent) >>> + dev->of_node = dev->parent->of_node; >>> + >> >> That is not enough. Current drivers could then have the assignment >> removed and even more important, this behaviour should be documented. >> >> Regards, >> >>Wolfram >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 16/23] ASoC: omap: mcbsp, mcpdm, dmic: raw read and write endian fix
At Sat, 16 Nov 2013 18:09:51 +0200, Jarkko Nikula wrote: > > On 11/16/2013 02:01 AM, Taras Kondratiuk wrote: > > From: Victor Kamensky > > > > All OMAP IP blocks expect LE data, but CPU may operate in BE mode. > > Need to use endian neutral functions to read/write h/w registers. > > I.e instead of __raw_read[lw] and __raw_write[lw] functions code > > need to use read[lw]_relaxed and write[lw]_relaxed functions. > > If the first simply reads/writes register, the second will byteswap > > it if host operates in BE mode. > > > > Changes are trivial sed like replacement of __raw_xxx functions > > with xxx_relaxed variant. > > > > Signed-off-by: Victor Kamensky > > Signed-off-by: Taras Kondratiuk > > --- > > sound/soc/omap/mcbsp.c | 12 ++-- > > sound/soc/omap/omap-dmic.c |4 ++-- > > sound/soc/omap/omap-mcpdm.c |4 ++-- > > 3 files changed, 10 insertions(+), 10 deletions(-) > > > Looks ok to me by looking at the _relaxed definitions in > arch/arm/include/asm/io.h. > > Acked-by: Jarkko Nikula > What's the reason to use _relaxed version in all places? I understand this patch is to fix the endianess, so this can be applied as is, as long as the original code works. But, still in general, I wonder how the concurrency is guaranteed by this driver code... thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sound fixes for 3.13-rc1
Linus, please pull sound fixes for v3.13-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-fix-3.13-rc1 The topmost commit is abfe69dd2e313d0c8226ca4a12329e3d829cfd7c sound fixes for 3.13-rc1 Two peaks in diffstat are for the audio EQ init of IDT codecs and the EMU2004 usb mixer addition, both of which are pretty device-specific, so safe to apply. The rest are a bunch of small fixes, most of them are regression fixes. Anssi Hannula (5): ALSA: hda - hdmi: Use TFx channel positions instead of FxH ALSA: usb: Fix wrong mapping of RLC and RRC channels ALSA: hda - hdmi: Add error-checking to some codec reads ALSA: hda - hdmi: Skip out-of-range latency values in AMD ELD generator ALSA: hda - hdmi: Fix wrong baseline length in ATI/AMD generated ELD Brian Austin (1): ASoC: cs42l52: Correct MIC CTL mask Charles Keepax (1): ASoC: wm8997: Correct typo in ISRC mux routes Dan Carpenter (2): ALSA: snd-aoa: two copy and paste bugs ALSA: isa: not allocating enough space David Henningsson (1): ALSA: hda - Fix Line Out automute on Realtek multifunction jacks Nicolin Chen (1): ASoC: wm8962: Turn on regcache_cache_only before disabling regulator Oskar Schirmer (1): ASoC: fsl: imx-pcm-fiq: omit fiq counter to avoid harm in unbalanced situations Richard Fitzgerald (2): ALSA: compress_core: don't return -EBADFD from poll if paused ASoC: arizona: Fix typo in name of EQ coefficient controls Takashi Iwai (9): ALSA: hda - Control SPDIF out pin on MacBookPro 11,2 ALSA: msnd: Avoid duplicated driver name ALSA: hda - Check keep_eapd_on before inv_eapd ALSA: hda - Don't turn off EAPD for headphone on Lenovo N100 ALSA: hda - Control EAPD for Master volume on Lenovo N100 ALSA: hda - Don't clear the power state at snd_hda_codec_reset() ASoC: blackfin: Fix missing break ALSA: pcsp: Fix the order of input device unregistration ALSA: jack: Unregister input device at disconnection Vasily Khoruzhick (1): ALSA: usb-audio: add front jack channel selector for EMU0204 Vitaliy Kulikov (1): ALSA: hda - load EQ params into IDT codec on HP bNB13 systems Wei Yongjun (1): ALSA: sparc: fix missing unlock on error in snd_cs4231_playback_prepare() --- sound/aoa/fabrics/layout.c| 4 +- sound/core/compress_offload.c | 3 +- sound/core/jack.c | 19 +- sound/drivers/pcsp/pcsp.c | 2 +- sound/isa/msnd/msnd_pinnacle.c| 4 +- sound/isa/wavefront/wavefront_synth.c | 2 +- sound/pci/hda/hda_codec.c | 3 - sound/pci/hda/hda_eld.c | 37 ++- sound/pci/hda/hda_generic.c | 4 +- sound/pci/hda/patch_analog.c | 33 ++- sound/pci/hda/patch_cirrus.c | 56 +++- sound/pci/hda/patch_hdmi.c| 11 +- sound/pci/hda/patch_realtek.c | 4 +- sound/pci/hda/patch_sigmatel.c| 532 +- sound/soc/blackfin/bf5xx-i2s.c| 1 + sound/soc/codecs/cs42l52.h| 2 +- sound/soc/codecs/wm5102.c | 8 +- sound/soc/codecs/wm5110.c | 8 +- sound/soc/codecs/wm8962.c | 2 + sound/soc/codecs/wm8997.c | 10 +- sound/soc/fsl/imx-pcm-fiq.c | 29 +- sound/sparc/cs4231.c | 11 +- sound/usb/mixer_quirks.c | 90 ++ sound/usb/stream.c| 4 +- 24 files changed, 803 insertions(+), 76 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] kstrtox: remove redundant cleanup
We can't reach the cleanup code unless the flag KSTRTOX_OVERFLOW is not set, so there's not no point in clearing a bit that we know is not set. Signed-off-by: Felipe Contreras --- lib/kstrtox.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/kstrtox.c b/lib/kstrtox.c index f78ae0c..ec8da78 100644 --- a/lib/kstrtox.c +++ b/lib/kstrtox.c @@ -92,7 +92,6 @@ static int _kstrtoull(const char *s, unsigned int base, unsigned long long *res) rv = _parse_integer(s, base, &_res); if (rv & KSTRTOX_OVERFLOW) return -ERANGE; - rv &= ~KSTRTOX_OVERFLOW; if (rv == 0) return -EINVAL; s += rv; -- 1.8.4.2+fc1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] Command line related cleanups
Hi, These became apparent in the review process of a new command line parameter. Felipe Contreras (5): kstrtox: remove redundant cleanup cmdline: fix style issues cmdline: declare exported symbols immediately kstrtox: remove redundant casts params: improve standard definitions kernel/params.c | 25 + lib/cmdline.c | 14 ++ lib/kstrtox.c | 17 - 3 files changed, 23 insertions(+), 33 deletions(-) -- 1.8.4.2+fc1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] cmdline: declare exported symbols immediately
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable +EXPORT_SYMBOL(memparse); WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable +EXPORT_SYMBOL(get_option); WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable +EXPORT_SYMBOL(get_options); Signed-off-by: Felipe Contreras --- lib/cmdline.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/lib/cmdline.c b/lib/cmdline.c index 5466333..d4932f7 100644 --- a/lib/cmdline.c +++ b/lib/cmdline.c @@ -67,6 +67,7 @@ int get_option(char **str, int *pint) return 1; } +EXPORT_SYMBOL(get_option); /** * get_options - Parse a string into a list of integers @@ -112,6 +113,7 @@ char *get_options(const char *str, int nints, int *ints) ints[0] = i - 1; return (char *)str; } +EXPORT_SYMBOL(get_options); /** * memparse - parse a string with mem suffixes into a number @@ -152,7 +154,4 @@ unsigned long long memparse(const char *ptr, char **retptr) return ret; } - EXPORT_SYMBOL(memparse); -EXPORT_SYMBOL(get_option); -EXPORT_SYMBOL(get_options); -- 1.8.4.2+fc1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] params: improve standard definitions
We are repeating the functionality of kstrtol in param_set_long, and the
same for kstrtoint. We can get rid of the extra code by using the right
functions.
Signed-off-by: Felipe Contreras
---
kernel/params.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/kernel/params.c b/kernel/params.c
index c00d5b5..48e1a81 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -227,17 +227,10 @@ int parse_args(const char *doing,
}
/* Lazy bastard, eh? */
-#define STANDARD_PARAM_DEF(name, type, format, tmptype, strtolfn)
\
+#define STANDARD_PARAM_DEF(name, type, format, strtolfn) \
int param_set_##name(const char *val, const struct kernel_param *kp) \
{ \
- tmptype l; \
- int ret;\
- \
- ret = strtolfn(val, 0, &l); \
- if (ret < 0 || ((type)l != l)) \
- return ret < 0 ? ret : -EINVAL; \
- *((type *)kp->arg) = l; \
- return 0; \
+ return strtolfn(val, 0, (type *)kp->arg); \
} \
int param_get_##name(char *buffer, const struct kernel_param *kp) \
{ \
@@ -253,13 +246,13 @@ int parse_args(const char *doing,
EXPORT_SYMBOL(param_ops_##name)
-STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", unsigned long, kstrtoul);
-STANDARD_PARAM_DEF(short, short, "%hi", long, kstrtol);
-STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", unsigned long, kstrtoul);
-STANDARD_PARAM_DEF(int, int, "%i", long, kstrtol);
-STANDARD_PARAM_DEF(uint, unsigned int, "%u", unsigned long, kstrtoul);
-STANDARD_PARAM_DEF(long, long, "%li", long, kstrtol);
-STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", unsigned long, kstrtoul);
+STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", kstrtou8);
+STANDARD_PARAM_DEF(short, short, "%hi", kstrtos16);
+STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", kstrtou16);
+STANDARD_PARAM_DEF(int, int, "%i", kstrtoint);
+STANDARD_PARAM_DEF(uint, unsigned int, "%u", kstrtouint);
+STANDARD_PARAM_DEF(long, long, "%li", kstrtol);
+STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", kstrtoul);
int param_set_charp(const char *val, const struct kernel_param *kp)
{
--
1.8.4.2+fc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] kstrtox: remove redundant casts
The temporary variable is of the same type as the cast, so it's redundant. Signed-off-by: Felipe Contreras --- lib/kstrtox.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/lib/kstrtox.c b/lib/kstrtox.c index ec8da78..649b74b 100644 --- a/lib/kstrtox.c +++ b/lib/kstrtox.c @@ -176,7 +176,7 @@ int _kstrtoul(const char *s, unsigned int base, unsigned long *res) rv = kstrtoull(s, base, &tmp); if (rv < 0) return rv; - if (tmp != (unsigned long long)(unsigned long)tmp) + if (tmp != (unsigned long)tmp) return -ERANGE; *res = tmp; return 0; @@ -192,7 +192,7 @@ int _kstrtol(const char *s, unsigned int base, long *res) rv = kstrtoll(s, base, &tmp); if (rv < 0) return rv; - if (tmp != (long long)(long)tmp) + if (tmp != (long)tmp) return -ERANGE; *res = tmp; return 0; @@ -223,7 +223,7 @@ int kstrtouint(const char *s, unsigned int base, unsigned int *res) rv = kstrtoull(s, base, &tmp); if (rv < 0) return rv; - if (tmp != (unsigned long long)(unsigned int)tmp) + if (tmp != (unsigned int)tmp) return -ERANGE; *res = tmp; return 0; @@ -254,7 +254,7 @@ int kstrtoint(const char *s, unsigned int base, int *res) rv = kstrtoll(s, base, &tmp); if (rv < 0) return rv; - if (tmp != (long long)(int)tmp) + if (tmp != (int)tmp) return -ERANGE; *res = tmp; return 0; @@ -269,7 +269,7 @@ int kstrtou16(const char *s, unsigned int base, u16 *res) rv = kstrtoull(s, base, &tmp); if (rv < 0) return rv; - if (tmp != (unsigned long long)(u16)tmp) + if (tmp != (u16)tmp) return -ERANGE; *res = tmp; return 0; @@ -284,7 +284,7 @@ int kstrtos16(const char *s, unsigned int base, s16 *res) rv = kstrtoll(s, base, &tmp); if (rv < 0) return rv; - if (tmp != (long long)(s16)tmp) + if (tmp != (s16)tmp) return -ERANGE; *res = tmp; return 0; @@ -299,7 +299,7 @@ int kstrtou8(const char *s, unsigned int base, u8 *res) rv = kstrtoull(s, base, &tmp); if (rv < 0) return rv; - if (tmp != (unsigned long long)(u8)tmp) + if (tmp != (u8)tmp) return -ERANGE; *res = tmp; return 0; @@ -314,7 +314,7 @@ int kstrtos8(const char *s, unsigned int base, s8 *res) rv = kstrtoll(s, base, &tmp); if (rv < 0) return rv; - if (tmp != (long long)(s8)tmp) + if (tmp != (s8)tmp) return -ERANGE; *res = tmp; return 0; -- 1.8.4.2+fc1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] cmdline: fix style issues
WARNING: space prohibited between function name and open parenthesis '('
+int get_option (char **str, int *pint)
WARNING: space prohibited between function name and open parenthesis '('
+ *pint = simple_strtol (cur, str, 0);
ERROR: trailing whitespace
+ $
WARNING: please, no spaces at the start of a line
+ $
WARNING: space prohibited between function name and open parenthesis '('
+ res = get_option ((char **)&str, ints + i);
Signed-off-by: Felipe Contreras
---
lib/cmdline.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index eb67911..5466333 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -49,13 +49,13 @@ static int get_range(char **str, int *pint)
* 3 - hyphen found to denote a range
*/
-int get_option (char **str, int *pint)
+int get_option(char **str, int *pint)
{
char *cur = *str;
if (!cur || !(*cur))
return 0;
- *pint = simple_strtol (cur, str, 0);
+ *pint = simple_strtol(cur, str, 0);
if (cur == *str)
return 0;
if (**str == ',') {
@@ -84,13 +84,13 @@ int get_option (char **str, int *pint)
* the parse to end (typically a null terminator, if @str is
* completely parseable).
*/
-
+
char *get_options(const char *str, int nints, int *ints)
{
int res, i = 1;
while (i < nints) {
- res = get_option ((char **)&str, ints + i);
+ res = get_option((char **)&str, ints + i);
if (res == 0)
break;
if (res == 3) {
@@ -153,7 +153,6 @@ unsigned long long memparse(const char *ptr, char **retptr)
return ret;
}
-
EXPORT_SYMBOL(memparse);
EXPORT_SYMBOL(get_option);
EXPORT_SYMBOL(get_options);
--
1.8.4.2+fc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] panic: setup panic_timeout early
* Felipe Contreras wrote: > On Fri, Nov 15, 2013 at 2:15 PM, Linus Torvalds > wrote: > > On Fri, Nov 15, 2013 at 12:10 PM, Felipe Contreras > > wrote: > >> > >> I haven't seen a single complaint about this commit message, so I > >> don't see what is your point. > > > > My point is that I have sixteen pointless messages in my mbox, > > half of which are due to just your argumentative nature. > > This is clearly not the point you were making, but I won't argue > why. That was exactly the point Linus was making. Anyway, the fact that you are argumentative even with Linus gives me little hope that you will improve your communication patterns with _me_, so I'm personally done arguing with you. > You don't want to argue? Then don't argue. Apply the patch. [...] *Plonk*. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/3] of/selftest: Add self tests for manipulation of properties
Hi Grant,
On Nov 15, 2013, at 7:46 PM, Grant Likely wrote:
> Adds a few simple test cases to ensure that addition, update and removal
> of device tree node properties works correctly.
>
> Signed-off-by: Grant Likely
> Cc: Rob Herring
> Cc: Benjamin Herrenschmidt
> Cc: David S. Miller
> Cc: Nathan Fontenot
> Cc: Pantelis Antoniou
> ---
> drivers/of/selftest.c | 62 +++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
> index e21012bde639..cb8d3e722f76 100644
> --- a/drivers/of/selftest.c
> +++ b/drivers/of/selftest.c
> @@ -30,6 +30,67 @@ static struct selftest_results {
> } \
> }
>
> +static void __init of_selftest_dynamic(void)
> +{
> + struct device_node *np;
> + struct property *prop;
> +
> + np = of_find_node_by_path("/testcase-data");
> + if (!np) {
> + pr_err("missing testcase data\n");
> + return;
> + }
> +
> + /* Array of 4 properties for the purpose of testing */
> + prop = kzalloc(sizeof(*prop) * 4, GFP_KERNEL);
> + if (!prop) {
> + selftest(0, "kzalloc() failed\n");
> + return;
> + }
> +
> + /* Add a new property - should pass*/
> + prop->name = "new-property";
> + prop->value = "new-property-data";
> + prop->length = strlen(prop->value);
> + selftest(of_add_property(np, prop) == 0, "Adding a new property
> failed\n");
> +
> + /* Try to add an existing property - should fail */
> + prop++;
> + prop->name = "new-property";
> + prop->value = "new-property-data-should-fail";
> + prop->length = strlen(prop->value);
> + selftest(of_add_property(np, prop) != 0,
> + "Adding an existing property should have failed\n");
> +
> + /* Try to modify an existing property - should pass */
> + prop->value = "modify-property-data-should-pass";
> + prop->length = strlen(prop->value);
> + selftest(of_update_property(np, prop) == 0,
> + "Updating an existing property should have passed\n");
> +
> + /* Try to modify non-existent property - should pass*/
> + prop++;
> + prop->name = "modify-property";
> + prop->value = "modify-missing-property-data-should-pass";
> + prop->length = strlen(prop->value);
> + selftest(of_update_property(np, prop) == 0,
> + "Updating a missing property should have passed\n");
> +
> + /* Remove property - should pass */
> + selftest(of_remove_property(np, prop) == 0,
> + "Removing a property should have passed\n");
> +
> + /* Adding very large property - should pass */
> + prop++;
> + prop->name = "large-property-PAGE_SIZEx8";
> + prop->length = PAGE_SIZE * 8;
> + prop->value = kzalloc(prop->length, GFP_KERNEL);
> + selftest(prop->value != NULL, "Unable to allocate large buffer\n");
> + if (prop->value)
> + selftest(of_add_property(np, prop) == 0,
> + "Adding a large property should have passed\n");
> +}
> +
> static void __init of_selftest_parse_phandle_with_args(void)
> {
> struct device_node *np;
> @@ -312,6 +373,7 @@ static int __init of_selftest(void)
> of_node_put(np);
>
> pr_info("start of selftest - you will see error messages\n");
> + of_selftest_dynamic();
> of_selftest_parse_phandle_with_args();
> of_selftest_property_match_string();
> of_selftest_parse_interrupts();
> --
> 1.8.3.2
>
I like this. I'll add my overlay test cases somewhere around here.
I might need to introduce some new helper functions in order to generate
the overlay completely programmatically.
Regards
-- Pantelis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] A minor amd64_edac fix for 3.13
On Sat, Nov 16, 2013 at 3:12 AM, Borislav Petkov wrote: > On Sat, Nov 16, 2013 at 02:50:49AM -0800, Linus Torvalds wrote: > >> The most common reason seems to be that your email provide is >> associated with spam, sometimes just because of a shared ISP. > > Sure, it is one: https://www.hetzner.de/ Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of complaints. See for example http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/ which puts it #2 _worldwide_ in September. I have no idea how accurate that is, but.. I would suggest everybody who uses hetzner actively drop them, and talk publicly about *why* they drop them. Your business may not be all that lucrative to them (compared to the spam), but still.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] A minor amd64_edac fix for 3.13
On Sat, Nov 16, 2013 at 10:10:05AM -0800, Linus Torvalds wrote: > Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of > complaints. See for example > > > http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/ Yowza, this is just great! :-( > which puts it #2 _worldwide_ in September. I have no idea how accurate > that is, but.. And they were #3 in August. So a steady rise ... > I would suggest everybody who uses hetzner actively drop them, and > talk publicly about *why* they drop them. Your business may not be all > that lucrative to them (compared to the spam), but still.. Yeah, I hear they're not that great otherwise either, regardless of how they handle (or not) spam. @Frank, we need to have a serious talk, you and I :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] panic: setup panic_timeout early
On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar wrote: > * Felipe Contreras wrote: > Anyway, the fact that you are argumentative even with Linus gives me > little hope that you will improve your communication patterns with > _me_, so I'm personally done arguing with you. How am I being argumentative? I avoided all arguments. >> You don't want to argue? Then don't argue. Apply the patch. [...] > > *Plonk*. This is exactly the opposite of what is conducive to less argumentation. If you are not going to comment on the patch, then don't say anything. The patch is good, and the fact that both you and Linus are avoiding any comments in the patch itself doesn't speak well for your intentions to avoid argumentation. So I ask you again. Do you see something wrong with the patch? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] make __get_dumpable/get_dumpable inline, kill fs/coredump.h
1. Remove fs/coredump.h. It is not clear why do we need it,
it only declares __get_dumpable(), signal.c includes it
for no reason.
2. Now that get_dumpable() and __get_dumpable() are really
trivial make them inline in linux/sched.h.
Signed-off-by: Oleg Nesterov
---
fs/coredump.c |1 -
fs/coredump.h |6 --
fs/exec.c | 18 --
include/linux/sched.h | 21 +
4 files changed, 17 insertions(+), 29 deletions(-)
delete mode 100644 fs/coredump.h
diff --git a/fs/coredump.c b/fs/coredump.c
index 9bdeca1..4bc92c7 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -40,7 +40,6 @@
#include
#include "internal.h"
-#include "coredump.h"
#include
diff --git a/fs/coredump.h b/fs/coredump.h
deleted file mode 100644
index e39ff07..000
--- a/fs/coredump.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _FS_COREDUMP_H
-#define _FS_COREDUMP_H
-
-extern int __get_dumpable(unsigned long mm_flags);
-
-#endif
diff --git a/fs/exec.c b/fs/exec.c
index 5303005..2196ef5 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -62,7 +62,6 @@
#include
#include "internal.h"
-#include "coredump.h"
#include
@@ -1616,7 +1615,6 @@ void set_binfmt(struct linux_binfmt *new)
if (new)
__module_get(new->module);
}
-
EXPORT_SYMBOL(set_binfmt);
/*
@@ -1632,22 +1630,6 @@ void set_dumpable(struct mm_struct *mm, int value)
} while (cmpxchg(&mm->flags, old, new) != old);
}
-int __get_dumpable(unsigned long mm_flags)
-{
- return mm_flags & MMF_DUMPABLE_MASK;
-}
-
-/*
- * This returns the actual value of the suid_dumpable flag. For things
- * that are using this for checking for privilege transitions, it must
- * test against SUID_DUMP_USER rather than treating it as a boolean
- * value.
- */
-int get_dumpable(struct mm_struct *mm)
-{
- return __get_dumpable(mm->flags);
-}
-
SYSCALL_DEFINE3(execve,
const char __user *, filename,
const char __user *const __user *, argv,
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 828c00d..34c1903 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -317,10 +317,6 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned
long addr,
static inline void arch_pick_mmap_layout(struct mm_struct *mm) {}
#endif
-
-extern void set_dumpable(struct mm_struct *mm, int value);
-extern int get_dumpable(struct mm_struct *mm);
-
#define SUID_DUMP_DISABLE 0 /* No setuid dumping */
#define SUID_DUMP_USER 1 /* Dump as user of process */
#define SUID_DUMP_ROOT 2 /* Dump as root */
@@ -331,6 +327,23 @@ extern int get_dumpable(struct mm_struct *mm);
#define MMF_DUMPABLE_BITS 2
#define MMF_DUMPABLE_MASK ((1 << MMF_DUMPABLE_BITS) - 1)
+extern void set_dumpable(struct mm_struct *mm, int value);
+/*
+ * This returns the actual value of the suid_dumpable flag. For things
+ * that are using this for checking for privilege transitions, it must
+ * test against SUID_DUMP_USER rather than treating it as a boolean
+ * value.
+ */
+static inline int __get_dumpable(unsigned long mm_flags)
+{
+ return mm_flags & MMF_DUMPABLE_MASK;
+}
+
+static inline int get_dumpable(struct mm_struct *mm)
+{
+ return __get_dumpable(mm->flags);
+}
+
/* coredump filter bits */
#define MMF_DUMP_ANON_PRIVATE 2
#define MMF_DUMP_ANON_SHARED 3
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] kill MMF_DUMPABLE and MMF_DUMP_SECURELY
Nobody actually needs MMF_DUMPABLE/MMF_DUMP_SECURELY, there
are only used to enforce the encoding of SUID_DUMP_* enum in
mm->flags & MMF_DUMPABLE_MASK.
Now that set_dumpable() updates both bits atomically we can
kill them and simply store the value "as is" in 2 lower bits.
Signed-off-by: Oleg Nesterov
---
fs/exec.c | 18 +++---
include/linux/sched.h |4 +---
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 613c9dc..5303005 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1620,8 +1620,7 @@ void set_binfmt(struct linux_binfmt *new)
EXPORT_SYMBOL(set_binfmt);
/*
- * set_dumpable converts traditional three-value dumpable to two flags and
- * stores them into mm->flags.
+ * set_dumpable stores three-value SUID_DUMP_* into mm->flags.
*/
void set_dumpable(struct mm_struct *mm, int value)
{
@@ -1629,24 +1628,13 @@ void set_dumpable(struct mm_struct *mm, int value)
do {
old = ACCESS_ONCE(mm->flags);
- new = old & ~MMF_DUMPABLE_MASK;
-
- switch (value) {
- case SUID_DUMP_ROOT:
- new |= (1 << MMF_DUMP_SECURELY);
- case SUID_DUMP_USER:
- new |= (1<< MMF_DUMPABLE);
- }
-
+ new = (old & ~MMF_DUMPABLE_MASK) | value;
} while (cmpxchg(&mm->flags, old, new) != old);
}
int __get_dumpable(unsigned long mm_flags)
{
- int ret;
-
- ret = mm_flags & MMF_DUMPABLE_MASK;
- return (ret > SUID_DUMP_USER) ? SUID_DUMP_ROOT : ret;
+ return mm_flags & MMF_DUMPABLE_MASK;
}
/*
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 838a3d9..828c00d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -326,10 +326,8 @@ extern int get_dumpable(struct mm_struct *mm);
#define SUID_DUMP_ROOT 2 /* Dump as root */
/* mm flags */
-/* dumpable bits */
-#define MMF_DUMPABLE 0 /* core dump is permitted */
-#define MMF_DUMP_SECURELY 1 /* core file is readable only by root */
+/* for SUID_DUMP_* above */
#define MMF_DUMPABLE_BITS 2
#define MMF_DUMPABLE_MASK ((1 << MMF_DUMPABLE_BITS) - 1)
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] set_dumpable: fix the theoretical race with itself
set_dumpable() updates MMF_DUMPABLE_MASK in a non-trivial way to
ensure that get_dumpable() can't observe the intermediate state,
but this all can't help if multiple threads call set_dumpable()
at the same time.
And in theory commit_creds()->set_dumpable(SUID_DUMP_ROOT) racing
with sys_prctl()->set_dumpable(SUID_DUMP_DISABLE) can result in
SUID_DUMP_USER.
Change this code to update both bits atomically via cmpxchg().
Note: this assumes that it is safe to mix bitops and cmpxchg. IOW,
if, say, an architecture implements cmpxchg() using the locking
(like arch/parisc/lib/bitops.c does), then it should use the same
locks for set_bit/etc.
Signed-off-by: Oleg Nesterov
---
fs/exec.c | 49 +++--
1 files changed, 15 insertions(+), 34 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index bb8afc1..613c9dc 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1621,43 +1621,24 @@ EXPORT_SYMBOL(set_binfmt);
/*
* set_dumpable converts traditional three-value dumpable to two flags and
- * stores them into mm->flags. It modifies lower two bits of mm->flags, but
- * these bits are not changed atomically. So get_dumpable can observe the
- * intermediate state. To avoid doing unexpected behavior, get get_dumpable
- * return either old dumpable or new one by paying attention to the order of
- * modifying the bits.
- *
- * dumpable | mm->flags (binary)
- * old new | initial interim final
- * -+---
- * 01 | 00 01 01
- * 02 | 00 10(*) 11
- * 10 | 01 00 00
- * 12 | 01 11 11
- * 20 | 11 10(*) 00
- * 21 | 11 11 01
- *
- * (*) get_dumpable regards interim value of 10 as 11.
+ * stores them into mm->flags.
*/
void set_dumpable(struct mm_struct *mm, int value)
{
- switch (value) {
- case SUID_DUMP_DISABLE:
- clear_bit(MMF_DUMPABLE, &mm->flags);
- smp_wmb();
- clear_bit(MMF_DUMP_SECURELY, &mm->flags);
- break;
- case SUID_DUMP_USER:
- set_bit(MMF_DUMPABLE, &mm->flags);
- smp_wmb();
- clear_bit(MMF_DUMP_SECURELY, &mm->flags);
- break;
- case SUID_DUMP_ROOT:
- set_bit(MMF_DUMP_SECURELY, &mm->flags);
- smp_wmb();
- set_bit(MMF_DUMPABLE, &mm->flags);
- break;
- }
+ unsigned long old, new;
+
+ do {
+ old = ACCESS_ONCE(mm->flags);
+ new = old & ~MMF_DUMPABLE_MASK;
+
+ switch (value) {
+ case SUID_DUMP_ROOT:
+ new |= (1 << MMF_DUMP_SECURELY);
+ case SUID_DUMP_USER:
+ new |= (1<< MMF_DUMPABLE);
+ }
+
+ } while (cmpxchg(&mm->flags, old, new) != old);
}
int __get_dumpable(unsigned long mm_flags)
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] get/set_dumpable() cleanups and theoretical fix
On 11/15, Kees Cook wrote: > > On Fri, Nov 15, 2013 at 12:36 PM, Oleg Nesterov wrote: > > > > unless I missed something, this is the fix, not cleanup ? > > > > If commit_creds()->set_dumpable(SUID_DUMP_ROOT) races with > > sys_prctl()->set_dumpable(SUID_DUMP_DISABLE), we can get > > SUID_DUMP_USER afaics. > > > > Yes, yes, even if I am right this race is very unlikely. > > Hm, yes, that is a fix then. I struggle to imagine it being > exploitable (i.e. control over both threads, one at least already with > a different cred, etc), but it certainly does look like a bug. Yes, yes, sure, this is only theoretical. OK, I am sending the patches to lkml. I didn't dare to keep your ack, please review v2 (v1 confused bit-mask with bit-number, and in theory we need ACCESS_ONCE). It would be really nice if someone can ack the "it is safe to mix bitops and cmpxchg" assumption mentioned in the changelog. Alex, Josh, this also partly reverts 179899fd5dc780fe "coredump: update coredump-related headers", I think fs/coredump.h buys nothing. Oleg. fs/coredump.c |1 - fs/coredump.h |6 - fs/exec.c | 61 + include/linux/sched.h | 25 ++- 4 files changed, 24 insertions(+), 69 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 04/40] staging/lustre/llite: Access to released file trigs a restore
On Sat, Nov 16, 2013 at 10:36:18AM +, Dilger, Andreas wrote: > >So, sorry, I have to stop here at this series. I've applied the first 3 > >to the opw-next branch of staging.git so they can live somewhere until > >3.13-rc1 is out. > > > >I know you spent a lot of time making these 120 patches to send me, but > >that too is crazy. You shouldn't wait that long to get feedback and > >send patches to me at all. Please send them in smaller series, with > >less time between patch submissions. > > The reason that there are so many patches in a burst is that we are also > developing new features and fixing bugs in parallel with the kernel, but > they also need to be tested a lot before they are released. It's not any > different from kernel patches testing on -next or -mm for a few months > before they are pushed to the mainline kernel in a batch. It's very different in that you are expecting me to suddenly accept this huge burst of patches all at once, and I can't review them properly. As this patch series shows, there was a problem in the 4rd patch in a 100+ series, which means that I couldn't take them all. So you wasted a bunch of work preparing those other 96 patches. Send them to me in short chunks, that way you don't waste time, and you don't take so long between patch acceptance. > The out-of-tree development can't really stop for a year while the kernel > client code is cleaned up. If the feature patches don't land into the > kernel client for a year (or however long it takes to do all the cleanup), > then it will become outdated and the whole reason for adding the client > into the kernel is lost. But you understand my hesitation at taking any new features when there really has not been any attempt by your team to do much cleanup and fixes of the code at all, right? It feels like I have done more cleanup personally than anyone on your teams, is this not true? So, why would I believe that you all are really going to start doing the major cleanup work on this code that is so obviously needed? Why would I take new features that you are spending your time on instead? > >> There are many users of the external tree so we cannot just abandon > >> it, especially that the upstream client is not shipped in any > >> distribution yet. Thanks for your understanding. > > > >What is keeping people using that tree? Support for older/distro > >kernels? > > > > Support for distro kernels is a big part of it. Most HPC sites use vendor > kernels of various vintages, and we need to keep the code working for those > sites. We also need to continue developing features needed by ever-larger > clusters, fixing bugs, etc. Eventually, when Lustre is in the kernel > proper, > it will also be available in future distro kernels and we can eventually > stop supporting the out-of-tree code. I expect that to be 3+ years away. So, originally you said it would take about a year to get this out of staging. It's been 6 months already with no real progress made with the exception of having interns do cleanup and me doing some basic wrapper function removals. What's the plan for the next 6 months? Based on these 100+ patches, I don't see any major changes that are happening to get this cleaned up properly (or did I miss those patches in this huge patchbomb?) > >Is it the fact that the server code isn't in the kernel? > > Not really. Lustre servers are on separate servers with vendor kernels > (ancient by your standards), and there isn't really any demand for > using newer kernels on those nodes. Most importantly, the out-of-tree > branch is where all of the new feature development is being done. That > also means if feature patches don't land into the kernel it just makes > the kernel version less attractive for users. > > > Should that be added now too so that we can get a proper view of what > > can and can not be changed? Some of your patches are showing that things > > are shared by the two chunks of code, so does that mean if I delete > >things in the client code that don't look to be used by anything, you > > will have problems because the server now breaks? > > Adding the server code to staging would mean another 150kLOC in staging. > We also haven't cleaned that code up even nearly as much as the client > code, so it isn't really even ready to go into staging either. I don't > think you or anyone else would be happy to see that code yet, so I don't > think there is a real advantage to do so. > > Deleting unused code in the kernel client isn't fatal, since we'll > still have the out-of-tree version, but we're trying to keep the code in > sync as much as possible so that it is easier to port patches in both > directions. If code is deleted it means more that needs to be added > back later when the server eventually does get merged, and more effort > to resolve patch conflicts. But look at the function that caused this original question to be asked. You want an api change that I would never accep
Re: [PATCH] aio: fix D-cache aliasing issues
On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote: > On Fri, 2013-11-15 at 23:05 +0100, Helge Deller wrote: > > When a user page mapping is released via kunmap*() functions, the D-cache > > needs > > to be flushed via flush_dcache_page() to avoid D-cache aliasing issues. > > > > This patch fixes aio on the parisc platform (and probably others). > > This should be flush_kernel_dcache_page(). flush_dcache_page() is for > full coherency but for unmap, we know the page was coherent going in and > may have been modified by the kernel, so only the kernel view needs to > be sync'd. Technically, by the kernel API, the flush should be done > *before* unmapping. This would have mattered on parisc until we did > flush via tmpalias which means we no-longer care if the mapping for the > flush exists or not because we always recreate it via the tmpalias > pages. On ARM, flush_kernel_dcache_page() actually assumes that the page is mapped. It avoids double flushing of highmem pages by not flushing in those cases where kunmap_atomic() already takes care of flushing. - Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] aio: fix D-cache aliasing issues
On Sat, Nov 16, 2013 at 09:07:18PM +0100, Simon Baatz wrote: > On Fri, Nov 15, 2013 at 02:42:05PM -0800, James Bottomley wrote: > > On Fri, 2013-11-15 at 23:05 +0100, Helge Deller wrote: > > > When a user page mapping is released via kunmap*() functions, the D-cache > > > needs > > > to be flushed via flush_dcache_page() to avoid D-cache aliasing issues. > > > > > > This patch fixes aio on the parisc platform (and probably others). > > > > This should be flush_kernel_dcache_page(). flush_dcache_page() is for > > full coherency but for unmap, we know the page was coherent going in and > > may have been modified by the kernel, so only the kernel view needs to > > be sync'd. Technically, by the kernel API, the flush should be done > > *before* unmapping. This would have mattered on parisc until we did > > flush via tmpalias which means we no-longer care if the mapping for the > > flush exists or not because we always recreate it via the tmpalias > > pages. > > On ARM, flush_kernel_dcache_page() actually assumes that the page is > mapped. It avoids double flushing of highmem pages by not flushing > in those cases where kunmap_atomic() already takes care of flushing. Helge -- are you going to resubmit a version of this patch that makes the recommended change? -ben > > > - Simon -- "Thought is the essence of where you are now." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] of: remove /proc/device-tree
On Thu, Mar 21, 2013 at 1:36 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2013-03-21 at 08:16 +, Grant Likely wrote:
>> On Thu, Mar 21, 2013 at 7:43 AM, Benjamin Herrenschmidt
>> wrote:
>> > On Thu, 2013-03-21 at 07:35 +, Grant Likely wrote:
>> >> > Shouldn't we have the symlink just be a config option itself ?
>> >> > Eventually distros might want get rid of it completely ..
>> >>
>> >> Why? It is the cheapest thing in the world and it means the ABI
>> >> doesn't change at all.
>> >
>> > It's also gross and forces sysfs to remain in /sys which isn't a kernel
>> > enforced policy afaik.
>>
>> Documentation/sysfs-rules.txt, Line 30
>
> Whatever... it's still gross :-)
Even Android mounts it there ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] panic: setup panic_timeout early
2013-11-16 19:46 keltezéssel, Felipe Contreras írta: > On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar wrote: >> * Felipe Contreras wrote: > >> Anyway, the fact that you are argumentative even with Linus gives me >> little hope that you will improve your communication patterns with >> _me_, so I'm personally done arguing with you. > > How am I being argumentative? I avoided all arguments. > >>> You don't want to argue? Then don't argue. Apply the patch. [...] >> >> *Plonk*. > > This is exactly the opposite of what is conducive to less argumentation. > > If you are not going to comment on the patch, then don't say anything. > > The patch is good, and the fact that both you and Linus are avoiding > any comments in the patch itself doesn't speak well for your > intentions to avoid argumentation. > > So I ask you again. Do you see something wrong with the patch? > Yes, you. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 4/4] documentation: Update circular buffer for load-acquire/store-release
On Sat, Nov 16, 2013 at 05:03:40PM +0100, Peter Zijlstra wrote: > On Fri, Nov 15, 2013 at 04:10:30PM -0800, Paul E. McKenney wrote: > > From: "Paul E. McKenney" > > > > This commit replaces full barriers by targeted use of load-acquire and > > store-release. > > I guess I'd better hurry up merging the patches that introduce these > thingies someplace :-) +1 to that! ;-) 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/
Re: [PATCH 1/5] kstrtox: remove redundant cleanup
2013-11-16 18:32 keltezéssel, Felipe Contreras írta: > We can't reach the cleanup code unless the flag KSTRTOX_OVERFLOW is not > set, so there's not no point in clearing a bit that we know is not set. > > Signed-off-by: Felipe Contreras Acked-by: Levente Kurusa Legit one. To be honest, I don't know who will apply it, because of the stuff discussed earlier. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] cmdline: declare exported symbols immediately
2013-11-16 18:32 keltezéssel, Felipe Contreras írta: > WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable > +EXPORT_SYMBOL(memparse); > > WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable > +EXPORT_SYMBOL(get_option); > > WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable > +EXPORT_SYMBOL(get_options); > > Signed-off-by: Felipe Contreras > --- > lib/cmdline.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/lib/cmdline.c b/lib/cmdline.c > index 5466333..d4932f7 100644 > --- a/lib/cmdline.c > +++ b/lib/cmdline.c > @@ -67,6 +67,7 @@ int get_option(char **str, int *pint) > > return 1; > } > +EXPORT_SYMBOL(get_option); > > /** > * get_options - Parse a string into a list of integers > @@ -112,6 +113,7 @@ char *get_options(const char *str, int nints, int *ints) > ints[0] = i - 1; > return (char *)str; > } > +EXPORT_SYMBOL(get_options); > > /** > * memparse - parse a string with mem suffixes into a number > @@ -152,7 +154,4 @@ unsigned long long memparse(const char *ptr, char > **retptr) > > return ret; > } > - > EXPORT_SYMBOL(memparse); > -EXPORT_SYMBOL(get_option); > -EXPORT_SYMBOL(get_options); > I don't know about this one, but I have seen lots of files where EXPORT_SYMBOLs were listed at the end of the file. To avoid misunderstanding, I still think that having the exports after the function is more appropriate. -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] panic: setup panic_timeout early
2013-11-16 19:46 keltezéssel, Felipe Contreras írta: > On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar wrote: >> * Felipe Contreras wrote: > >> Anyway, the fact that you are argumentative even with Linus gives me >> little hope that you will improve your communication patterns with >> _me_, so I'm personally done arguing with you. > > How am I being argumentative? I avoided all arguments. > >>> You don't want to argue? Then don't argue. Apply the patch. [...] >> >> *Plonk*. > > This is exactly the opposite of what is conducive to less argumentation. > > If you are not going to comment on the patch, then don't say anything. > > The patch is good, and the fact that both you and Linus are avoiding > any comments in the patch itself doesn't speak well for your > intentions to avoid argumentation. > > So I ask you again. Do you see something wrong with the patch? > Out-of-joke, the patch is now in an 'appliable' state. You can add my: Reviewed-by: Levente Kurusa -- Regards, Levente Kurusa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] cmdline: declare exported symbols immediately
On Sat, Nov 16, 2013 at 2:21 PM, Levente Kurusa wrote: > 2013-11-16 18:32 keltezéssel, Felipe Contreras írta: >> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable >> +EXPORT_SYMBOL(memparse); >> >> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable >> +EXPORT_SYMBOL(get_option); >> >> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable >> +EXPORT_SYMBOL(get_options); >> >> Signed-off-by: Felipe Contreras >> --- >> lib/cmdline.c | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/lib/cmdline.c b/lib/cmdline.c >> index 5466333..d4932f7 100644 >> --- a/lib/cmdline.c >> +++ b/lib/cmdline.c >> @@ -67,6 +67,7 @@ int get_option(char **str, int *pint) >> >> return 1; >> } >> +EXPORT_SYMBOL(get_option); >> >> /** >> * get_options - Parse a string into a list of integers >> @@ -112,6 +113,7 @@ char *get_options(const char *str, int nints, int *ints) >> ints[0] = i - 1; >> return (char *)str; >> } >> +EXPORT_SYMBOL(get_options); >> >> /** >> * memparse - parse a string with mem suffixes into a number >> @@ -152,7 +154,4 @@ unsigned long long memparse(const char *ptr, char >> **retptr) >> >> return ret; >> } >> - >> EXPORT_SYMBOL(memparse); >> -EXPORT_SYMBOL(get_option); >> -EXPORT_SYMBOL(get_options); >> > > I don't know about this one, but I have seen lots of files where > EXPORT_SYMBOLs were > listed at the end of the file. To avoid misunderstanding, I still think that > having the > exports after the function is more appropriate. If that was appropriate then checkpatch should be updated to remove that warning, but presumably it's desirable to have them one next to the other. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [PATCH 1/8] watchdog: davinci: change driver to use WDT core
On 11/06/2013 03:31 AM, ivan.khoronzhuk wrote:
To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.
Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core track state with its own variable.
The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. So set initial
heartbeat value more than max value in order to initialize heartbeat
in next way. If heartbeat is not set thought module parameter, try
to read it's value from WDT node timeout-sec property. If node has
no one, use default value.
The heartbeat is hold in wdd->timeout by WDT core, so use it in
order to set timeout period.
Signed-off-by: Ivan Khoronzhuk
---
drivers/watchdog/Kconfig |1 +
drivers/watchdog/davinci_wdt.c | 150 ++--
2 files changed, 38 insertions(+), 113 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index d1d53f3..2c954b5 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -271,6 +271,7 @@ config IOP_WATCHDOG
config DAVINCI_WATCHDOG
tristate "DaVinci watchdog"
depends on ARCH_DAVINCI
+ select WATCHDOG_CORE
help
Say Y here if to include support for the watchdog timer
in the DaVinci DM644x/DM646x processors.
diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index bead774..a6eef71 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -3,7 +3,7 @@
*
* Watchdog driver for DaVinci DM644x/DM646x processors
*
- * Copyright (C) 2006 Texas Instruments.
+ * Copyright (C) 2013 Texas Instruments.
2006-2013
*
* 2007 (c) MontaVista Software, Inc. This file is licensed under
* the terms of the GNU General Public License version 2. This program
@@ -15,18 +15,12 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include
-#include
-#include
#include
#include
#include
-#include
#include
#define MODULE_NAME "DAVINCI-WDT: "
@@ -61,31 +55,13 @@
#define WDKEY_SEQ0(0xa5c6 << 16)
#define WDKEY_SEQ1(0xda7e << 16)
-static int heartbeat = DEFAULT_HEARTBEAT;
-
-static DEFINE_SPINLOCK(io_lock);
-static unsigned long wdt_status;
-#define WDT_IN_USE0
-#define WDT_OK_TO_CLOSE 1
-#define WDT_REGION_INITED 2
-#define WDT_DEVICE_INITED 3
-
+static int heartbeat = MAX_HEARTBEAT + 1;
Initializing it with 0 (ie not at all) would be just as good. Also see below.
static void __iomem *wdt_base;
struct clk*wdt_clk;
+static struct watchdog_device wdt_wdd;
-static void wdt_service(void)
-{
- spin_lock(&io_lock);
-
- /* put watchdog in service state */
- iowrite32(WDKEY_SEQ0, wdt_base + WDTCR);
- /* put watchdog in active state */
- iowrite32(WDKEY_SEQ1, wdt_base + WDTCR);
-
- spin_unlock(&io_lock);
-}
-
-static void wdt_enable(void)
+/* davinci_wdt_start - enable watchdog */
That comment doesn't really provide much value.
+static int davinci_wdt_start(struct watchdog_device *wdd)
{
u32 tgcr;
u32 timer_margin;
@@ -93,8 +69,6 @@ static void wdt_enable(void)
wdt_freq = clk_get_rate(wdt_clk);
- spin_lock(&io_lock);
-
/* disable, internal clock source */
iowrite32(0, wdt_base + TCR);
/* reset timer, set mode to 64-bit watchdog, and unreset */
@@ -105,9 +79,9 @@ static void wdt_enable(void)
iowrite32(0, wdt_base + TIM12);
iowrite32(0, wdt_base + TIM34);
/* set timeout period */
- timer_margin = (((u64)heartbeat * wdt_freq) & 0x);
+ timer_margin = (((u64)wdd->timeout * wdt_freq) & 0x);
iowrite32(timer_margin, wdt_base + PRD12);
- timer_margin = (((u64)heartbeat * wdt_freq) >> 32);
+ timer_margin = (((u64)wdd->timeout * wdt_freq) >> 32);
iowrite32(timer_margin, wdt_base + PRD34);
/* enable run continuously */
iowrite32(ENAMODE12_PERIODIC, wdt_base + TCR);
@@ -119,84 +93,28 @@ static void wdt_enable(void)
iowrite32(WDKEY_SEQ0 | WDEN, wdt_base + WDTCR);
/* put watchdog in active state */
iowrite32(WDKEY_SEQ1 | WDEN, wdt_base + WDTCR);
-
- spin_unlock(&io_lock);
-}
-
-static int davinci_wdt_open(struct inode *inode, struct file *file)
-{
- if (test_and_set_bit(WDT_IN_USE, &wdt_status))
- return -EBUSY;
-
- wdt_enable();
-
- return nonseekable_open(inode, file);
+ return 0;
}
-static ssize_t
-davinci_wdt_write(struct file *file, const char *data, size_t len,
- loff_t *ppos)
+static int davinci_wdt_ping(struct watchdog_device *wdd)
{
- if (len)
- wdt_service();
-
- return len;
+ /* put watchdog in service state */
+ iowrite32(WDKEY_SEQ0, wdt_base + WDTCR);
+ /* put
[PATCH] Fix NX-related Oops in wistron_btns module
The attached patch fixes "kernel tried to execute NX-protected page"
Oops when loading wistron_btns module, occurring since at least 3.4.x;
still applies to Linux 3.12.
--
Jakub Boguszhttp://qboosh.pl/
This patch fixes "kernel tried to execute NX-protected page" oops when
loading winstron-btns module.
Signed-off-by: Jakub Bogusz
--- linux-3.10/drivers/input/misc/wistron_btns.c.orig 2013-11-16
09:05:55.612742472 +0100
+++ linux-3.10/drivers/input/misc/wistron_btns.c2013-11-16
09:24:37.356028732 +0100
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
/* How often we poll keys - msecs */
#define POLL_INTERVAL_DEFAULT 500 /* when idle */
@@ -124,6 +125,7 @@
if (entry_point >= 0xF) {
bios_code_map_base = base;
bios_entry_point = bios_code_map_base + (entry_point & 0x);
+ set_memory_x((unsigned long)bios_code_map_base, 0x1 >>
PAGE_SHIFT);
} else {
iounmap(base);
bios_code_map_base = ioremap(entry_point & ~0x3FFF, 0x4000);
@@ -134,6 +136,7 @@
goto err;
}
bios_entry_point = bios_code_map_base + (entry_point & 0x3FFF);
+ set_memory_x((unsigned long)bios_code_map_base, 0x4000 >>
PAGE_SHIFT);
}
/* The Windows driver maps 0x1 bytes, we keep only one page... */
bios_data_map_base = ioremap(0x400, 0xc00);
[PATCH] afs: dir: remove unused label out_skip
The out_skip label is not used, so remove it.
Signed-off-by: Levente Kurusa
---
fs/afs/dir.c |1 -
1 file changed, 1 deletion(-)
diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index 3756d4f..0e10b14 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -669,7 +669,6 @@ static int afs_d_revalidate(struct dentry *dentry, unsigned
int flags)
out_valid:
dentry->d_fsdata = dir_version;
-out_skip:
dput(parent);
key_put(key);
_leave(" = 1 [valid]");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
