Re: [PATCH net,1/1] hyperv: Add support for setting MAC from within guests
From: Haiyang Zhang Date: Tue, 10 Jul 2012 10:19:22 -0700 > This adds support for setting synthetic NIC MAC address from within Linux > guests. Before using this feature, the option "spoofing of MAC address" > should be enabled at the Hyper-V manager / Settings of the synthetic > NIC. > > Thanks to Kin Cho for the initial implementation and > tests. And, thanks to Long Li for the debugging > works. > > Reported-and-tested-by: Kin Cho > Reported-by: Long Li > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ALSA: hda - Add new GPU codec ID to snd-hda
At Mon, 16 Jul 2012 17:10:04 -0700,
Aaron Plattner wrote:
>
> Vendor ID 0x10de0051 is used by a yet-to-be-named GPU chip.
>
> Signed-off-by: Aaron Plattner
> Acked-by: Andy Ritger
> Reviewed-by: Daniel Dadap
Applied now. Thanks.
Takashi
> ---
> sound/pci/hda/patch_hdmi.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index ad319d4..4efe741 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -1902,6 +1902,7 @@ static const struct hda_codec_preset
> snd_hda_preset_hdmi[] = {
> { .id = 0x10de0042, .name = "GPU 42 HDMI/DP",.patch =
> patch_generic_hdmi },
> { .id = 0x10de0043, .name = "GPU 43 HDMI/DP",.patch =
> patch_generic_hdmi },
> { .id = 0x10de0044, .name = "GPU 44 HDMI/DP",.patch =
> patch_generic_hdmi },
> +{ .id = 0x10de0051, .name = "GPU 51 HDMI/DP",.patch =
> patch_generic_hdmi },
> { .id = 0x10de0067, .name = "MCP67 HDMI",.patch = patch_nvhdmi_2ch },
> { .id = 0x10de8001, .name = "MCP73 HDMI",.patch = patch_nvhdmi_2ch },
> { .id = 0x80860054, .name = "IbexPeak HDMI", .patch = patch_generic_hdmi },
> @@ -1948,6 +1949,7 @@ MODULE_ALIAS("snd-hda-codec-id:10de0041");
> MODULE_ALIAS("snd-hda-codec-id:10de0042");
> MODULE_ALIAS("snd-hda-codec-id:10de0043");
> MODULE_ALIAS("snd-hda-codec-id:10de0044");
> +MODULE_ALIAS("snd-hda-codec-id:10de0051");
> MODULE_ALIAS("snd-hda-codec-id:10de0067");
> MODULE_ALIAS("snd-hda-codec-id:10de8001");
> MODULE_ALIAS("snd-hda-codec-id:17e80047");
> --
> 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/
linux-next: Tree for July 17
Hi all, Changes since 20120716: The vfs tree lost its build failure. The l2-mtd tree gained a conflict against the mtd tree. The battery tree tree lost its build failure. The regulator tree gained conflicts against the mfd tree. The tty tree lost its build failure but gained another, so I used the version from next-20120712. I have still reverted 3 commits from the signal tree at the request of the arm maintainer. The akpm tree lost a few patches that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 197 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (e5254a6 Merge branch 'gma500' (Alan's GMA patches)) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1) Merging arm-current/fixes (ff081e0 ARM: 7457/1: smp: Fix suspicious RCU originating from cpu_die()) Merging m68k-current/for-linus (d8ce726 m68k: Use generic strncpy_from_user(), strlen_user(), and strnlen_user()) Merging powerpc-merge/merge (50fb31c tty/hvc_opal: Fix debug function name) Merging sparc/master (d55de60 sparc64: remove unused function straddles_64bit_va_hole()) Merging net/master (310e158 net: respect GFP_DMA in __netdev_alloc_skb()) Merging sound-current/for-linus (68e67f4 ALSA: snd-usb: move calls to usb_set_interface) Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging wireless/master (8a70e7f NFC: NCI module license 'unspecified' taints kernel) Merging driver-core.current/driver-core-linus (5becfb1 kmsg: merge continuation records while printing) Merging tty.current/tty-linus (84a1caf Linux 3.5-rc7) Merging usb.current/usb-linus (84a1caf Linux 3.5-rc7) Merging staging.current/staging-linus (6887a41 Linux 3.5-rc5) Merging char-misc.current/char-misc-linus (84a1caf Linux 3.5-rc7) Merging input-current/for-linus (e76b8ee Input: xpad - add Andamiro Pump It Up pad) Merging md-current/for-linus (2d4f4f3 md/raid1: fix use-after-free bug in RAID1 data-check code.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (c475c06 hwrng: atmel-rng - fix data valid check) Merging ide/master (39a50b4 Merge branch 'hfsplus') Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging arm/for-next (dea2ea3 Merge branches 'audit', 'delay', 'dmaengine', 'fixes', 'misc' and 'sta2x11' into for-next) Merging arm-perf/for-next/perf (dee8c1b ARM: perf: remove arm_pe
Re: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: Joe Perches
Date: Thu, 12 Jul 2012 22:33:04 -0700
> net-next commit ad7eee98be ("etherdevice: introduce eth_broadcast_addr")
> added a new style API. Rename random_ether_addr to eth_random_addr to
> create some API symmetry.
Series applied, thanks Joe.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 13:32 +0800, Jovi Zhang wrote: > On Tue, Jul 17, 2012 at 1:07 PM, Joe Perches wrote: > > On Tue, 2012-07-17 at 00:25 -0400, Steven Rostedt wrote: [] > >> Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is > >> not a module. > > > > It depends on the Makefile. > > > > scripts/Makefile.lib:# $(modname_flags) #defines KBUILD_MODNAME as the name > > of the module it will > > scripts/Makefile.lib-# end up in (or would, if it gets compiled in) > > scripts/Makefile.lib-# Note: Files that end up in two or more modules are > > compiled without the > > scripts/Makefile.lib:# KBUILD_MODNAME definition. The reason is that > > any made-up name would > > scripts/Makefile.lib-# differ in different configs. > > scripts/Makefile.lib-name-fix = $(subst $(comma),_,$(subst -,_,$1)) > > scripts/Makefile.lib-basename_flags = -D"KBUILD_BASENAME=KBUILD_STR($(call > > name-fix,$(basetarget)))" > > scripts/Makefile.lib-modname_flags = $(if $(filter 1,$(words $(modname))),\ > > scripts/Makefile.lib: -D"KBUILD_MODNAME=KBUILD_STR($(call > > name-fix,$(modname)))") > > > Hmm, that would make sense, get subsystem name from Makefile. > > Joe, there will delete all this pr_fmt definition in .c file in 3.8(or > 3.7) as you metioned, so we can ingnore this patch. Not quite. The uses that have embedded prefixes need updating. You've done that in bits of this patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] ftrace: using pr_fmt for better printk output
On Tue, Jul 17, 2012 at 1:07 PM, Joe Perches wrote: > On Tue, 2012-07-17 at 00:25 -0400, Steven Rostedt wrote: >> On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: >> >> > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c >> > [] >> > > @@ -13,6 +13,8 @@ >> > > * Copyright (C) 2004 William Lee Irwin III >> > > */ >> > > >> > > +#define pr_fmt(fmt) "ftrace: " fmt >> > >> > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt >> >> Wouldn't a nicer patch be to move this into a header file and then >> remove all the defines throughout the kernel tree? > > Maybe. There are modules that use common header files > like you suggest. It does mean that header must be the > #included before any other #include that might > #include or printk.h. > > Right now, if pr_fmt isn't #defined, printk.h > has a default definition of: > > #ifndef pr_fmt > #define pr_fmt(fmt) fmt > #endif > > My goal is to change that to: > > #ifndef pr_fmt > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > #endif > > in 3.8 (maybe 3.7) and remove all of these then > useless, duplicate #defines shortly afterward. > > https://lkml.org/lkml/2012/3/27/247 > >> Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is >> not a module. > > It depends on the Makefile. > > scripts/Makefile.lib:# $(modname_flags) #defines KBUILD_MODNAME as the name > of the module it will > scripts/Makefile.lib-# end up in (or would, if it gets compiled in) > scripts/Makefile.lib-# Note: Files that end up in two or more modules are > compiled without the > scripts/Makefile.lib:# KBUILD_MODNAME definition. The reason is that > any made-up name would > scripts/Makefile.lib-# differ in different configs. > scripts/Makefile.lib-name-fix = $(subst $(comma),_,$(subst -,_,$1)) > scripts/Makefile.lib-basename_flags = -D"KBUILD_BASENAME=KBUILD_STR($(call > name-fix,$(basetarget)))" > scripts/Makefile.lib-modname_flags = $(if $(filter 1,$(words $(modname))),\ > scripts/Makefile.lib: -D"KBUILD_MODNAME=KBUILD_STR($(call > name-fix,$(modname)))") > Hmm, that would make sense, get subsystem name from Makefile. Joe, there will delete all this pr_fmt definition in .c file in 3.8(or 3.7) as you metioned, so we can ingnore this patch. .Jovi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging/gdm72xx: use kthread APIs
From: Devendra Naga
This patch modifies the kthread usage in the gdm_usb code, and tries to
use the kthread APIs better.
Actually the task_struct is taken as global as the limitation of priv.
we run the kthread before we allocate the priv.
did only compilation test, but not the insmod, check ps ax for kthread and
rmmod and see the thread is killed kind of tests.
There were no checks while kthread_run may fail, returing some error which can
be seen by using PTR_ERR.
Signed-off-by: Devendra Naga
---
Sorry Greg sir, i didn't actually used the checkpatch tool, mea maxima clupa :(.
changes since V2:
removed the following checkpatch error
./scripts/checkpatch.pl 0001-staging-gdm72xx-use-kthread-APIs.patch
ERROR: trailing whitespace
#38: FILE: drivers/staging/gdm72xx/gdm_usb.c:57:
+static struct task_struct *kthread; $
NOTE: whitespace errors detected, you may wish to use
scripts/cleanpatch or
scripts/cleanfile
but didn't solved the below warning, as it needed a new patch
to remove all
printk's and convert them to pr_err, and this patch intended to
do only one
specific change.
WARNING: Prefer pr_err(... to printk(KERN_ERR, ...
#58: FILE: drivers/staging/gdm72xx/gdm_usb.c:786:
+ printk(KERN_ERR "%s: can't create kernel thread\n",
__func__);
drivers/staging/gdm72xx/gdm_usb.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/gdm72xx/gdm_usb.c
b/drivers/staging/gdm72xx/gdm_usb.c
index d48d49c..5aab7eb 100644
--- a/drivers/staging/gdm72xx/gdm_usb.c
+++ b/drivers/staging/gdm72xx/gdm_usb.c
@@ -46,7 +46,6 @@ MODULE_DEVICE_TABLE(usb, id_table);
static DECLARE_WAIT_QUEUE_HEAD(k_wait);
static LIST_HEAD(k_list);
static DEFINE_SPINLOCK(k_lock);
-static int k_mode_stop;
#define K_WAIT_TIME(2 * HZ / 100)
@@ -55,6 +54,7 @@ static int k_mode_stop;
static int init_usb(struct usbwm_dev *udev);
static void release_usb(struct usbwm_dev *udev);
+static struct task_struct *kthread;
/*#define DEBUG */
#ifdef DEBUG
static void hexdump(char *title, u8 *data, int len)
@@ -717,7 +717,7 @@ static int k_mode_thread(void *arg)
daemonize("k_mode_wimax");
- while (!k_mode_stop) {
+ while (!kthread_should_stop()) {
spin_lock_irqsave(_lock, flags2);
while (!list_empty(_list)) {
@@ -778,7 +778,11 @@ static struct usb_driver gdm_usb_driver = {
static int __init usb_gdm_wimax_init(void)
{
#ifdef CONFIG_WIMAX_GDM72XX_K_MODE
- kthread_run(k_mode_thread, NULL, "WiMax_thread");
+ kthread = kthread_run(k_mode_thread, NULL, "WiMax_thread");
+ if (IS_ERR(kthread)) {
+ printk(KERN_ERR "%s: can't create kernel thread\n", __func__);
+ return PTR_ERR(kthread);
+ }
#endif /* CONFIG_WIMAX_GDM72XX_K_MODE */
return usb_register(_usb_driver);
}
@@ -786,7 +790,8 @@ static int __init usb_gdm_wimax_init(void)
static void __exit usb_gdm_wimax_exit(void)
{
#ifdef CONFIG_WIMAX_GDM72XX_K_MODE
- k_mode_stop = 1;
+ if (kthread)
+ kthread_stop(kthread);
wake_up(_wait);
#endif
usb_deregister(_usb_driver);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 13:23 +0800, Jovi Zhang wrote: > I don't make sure if there have some method or skill to let GCC knows > subsystem name automatically, > use built-in macro __FILE__? but this need condition of subsystem name > is same as file name, > not so easily to guarantee that. You could use KBUILD_BASENAME instead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 13:23 +0800, Jovi Zhang wrote: > On Tue, Jul 17, 2012 at 12:25 PM, Steven Rostedt wrote: > > On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: > > > >> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > >> [] > >> > @@ -13,6 +13,8 @@ > >> > * Copyright (C) 2004 William Lee Irwin III > >> > */ > >> > > >> > +#define pr_fmt(fmt) "ftrace: " fmt > >> > >> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > > > Wouldn't a nicer patch be to move this into a header file and then > > remove all the defines throughout the kernel tree? > > Maybe it's hard to achieve that. > subsystem name is unique with each other, it should be visible in source file, > if include into header file, then each .c file might need a own header > file for include pr_fmt > definition, then that header file cannot be reusable(avoid subsystem > name conflicts). > > > > > Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is > > not a module. > Yes, that's why I cannot use KBUILD_MODNAME in patch. Incorrect, try it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Adding support for configuring polarity in PWM framework.
On Mon, Jul 16, 2012 at 18:16:13, Lars-Peter Clausen wrote: > On 07/16/2012 02:23 PM, Philip, Avinash wrote: > > > > > 1. PWM framework API addition. > > PWM frame work API support. > > /** > > * pwm_setpolarity() - change a PWM device Polarity > > * @pwm: PWM device > > * @polarity: Configure polarity of PWM > > * > > * polarity - false -> "on" time defined by duty ns > > * - true -> "off' time defined by duty ns. > > */ > > Isn't this more about whether we start with a low or a high signal? No, it is more about the average on time. On time determines the on duration of the panel power and there by brightness. On one custom board, backlight power booster gives power output on the OFF time of PWM (hardware connection). > If it is > just about the duty time you can easily achieve the same effect by setting > it to (period_ns - duty_ns). Yes this is possible. But the PWM hardware we uses supports configuration of polarity. So I prefer PWM polarity configuration. Also with polarity configuration support, we can achieve (period_ns - duty_ns), for PWM devices don't have hardware support. Polarity configuration support can be used for setting flags, duty cycle can be configured from config depending on flag. Thanks Avinash > > - Lars > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] net-next: make sock diag per-namespace (v2)
From: Andrew Vagin Date: Mon, 16 Jul 2012 18:28:49 +0400 > Before this patch sock_diag works for init_net only and dumps > information about sockets from all namespaces. > > This patch expands sock_diag for all name-spaces. > It creates a netlink kernel socket for each netns and filters > data during dumping. > > v2: filter accoding with netns in all places > remove an unused variable. > > Signed-off-by: Andrew Vagin Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, Jul 17, 2012 at 12:25 PM, Steven Rostedt wrote: > On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: > >> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c >> [] >> > @@ -13,6 +13,8 @@ >> > * Copyright (C) 2004 William Lee Irwin III >> > */ >> > >> > +#define pr_fmt(fmt) "ftrace: " fmt >> >> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > Wouldn't a nicer patch be to move this into a header file and then > remove all the defines throughout the kernel tree? Maybe it's hard to achieve that. subsystem name is unique with each other, it should be visible in source file, if include into header file, then each .c file might need a own header file for include pr_fmt definition, then that header file cannot be reusable(avoid subsystem name conflicts). > > Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is > not a module. Yes, that's why I cannot use KBUILD_MODNAME in patch. > > -- Steve I don't make sure if there have some method or skill to let GCC knows subsystem name automatically, use built-in macro __FILE__? but this need condition of subsystem name is same as file name, not so easily to guarantee that. .jovi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] [RFC] cpufreq: omap: scale regulator from clk notifier
On Saturday 14 July 2012 05:46 AM, Mike Turquette wrote:
This patch moves direct control of the MPU voltage regulator out of the
cpufreq driver .target callback and instead puts that logic into a clock
rate change notifier callback.
The same frequency/voltage lookup via the OPP library is present, except
that the calls to regulator_set_voltage are done from the clock
framework instead of cpufreq.
Ideally it would be nice to reduce the .target callback for OMAP's
cpufreq driver to a simple call to clk_set_rate. For now there is still
some other stuff needed there (jiffies per loop, rounding the rate, etc
etc).
Not-signed-off-by: Mike Turquette
---
drivers/cpufreq/omap-cpufreq.c | 154 +---
1 file changed, 96 insertions(+), 58 deletions(-)
-static int __init omap_cpufreq_init(void)
+static int mpu_clk_volt_scale_handler(struct notifier_block *nb,
+ unsigned long flags, void *data)
{
- if (cpu_is_omap24xx())
- mpu_clk_name = "virt_prcm_set";
- else if (cpu_is_omap34xx())
- mpu_clk_name = "dpll1_ck";
- else if (cpu_is_omap44xx())
- mpu_clk_name = "dpll_mpu_ck";
+ struct clk_notifier_data *cnd = data;
+ unsigned long tol;
+ int ret, volt_new, volt_old;
+ struct opp *opp;
- if (!mpu_clk_name) {
- pr_err("%s: unsupported Silicon?\n", __func__);
- return -EINVAL;
+ volt_old = regulator_get_voltage(mpu_reg);
+ opp = opp_find_freq_exact(mpu_dev, cnd->new_rate, true);
+ volt_new = opp_get_voltage(opp);
+
+ tol = volt_new * OPP_TOLERANCE / 100;
+
+ /* scaling up? scale voltage before frequency */
+ if (cnd->new_rate> cnd->old_rate) {
+ dev_dbg(mpu_dev, "cpufreq-omap: %d mV --> %d mV\n",
+ volt_old, volt_new);
+
+ ret = regulator_set_voltage(mpu_reg, volt_new - tol, volt_new +
tol);
+
+ if (ret< 0) {
+ dev_warn(mpu_dev, "%s: unable to scale voltage up.\n",
+__func__);
+ return NOTIFY_BAD;
+ }
+ }
+
+ /* scaling down? scale voltage after frequency */
+ if (cnd->new_rate< cnd->old_rate) {
+ dev_dbg(mpu_dev, "cpufreq-omap: %d mV --> %d mV\n",
+ volt_old, volt_new);
+
+ ret = regulator_set_voltage(mpu_reg, volt_new - tol, volt_new +
tol);
+
+ if (ret< 0) {
+ dev_warn(mpu_dev, "%s: unable to scale voltage down.\n",
+__func__);
+ return NOTIFY_BAD;
+ }
}
How are you checking pre and post rate change condition here? Need
switch case for event?
+ return NOTIFY_OK;
+}
+
+static struct notifier_block mpu_clk_volt_scale_nb = {
+ .notifier_call = mpu_clk_volt_scale_handler,
+};
+
+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
Hi Wen,
2012/07/17 14:17, Wen Congyang wrote:
> At 07/17/2012 12:51 PM, Yasuaki Ishimatsu Wrote:
>> Hi Wen,
>>
>> 2012/07/17 12:32, Wen Congyang wrote:
>>> At 07/17/2012 11:08 AM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/07/17 11:32, Wen Congyang wrote:
> At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
>> Hi Wen,
>>
>> 2012/07/17 10:44, Yasuaki Ishimatsu wrote:
>>> Hi Wen,
>>>
>>> 2012/07/13 12:35, Wen Congyang wrote:
At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
> acpi_memory_device_remove() has been prepared to remove physical
> memory.
> But, the function only frees acpi_memory_device currentlry.
>
> The patch adds following functions into acpi_memory_device_remove():
>- offline memory
>- remove physical memory (only return -EBUSY)
>- free acpi_memory_device
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/acpi/acpi_memhotplug.c | 26 +-
> drivers/base/memory.c | 39
> +++
> include/linux/memory.h |5 +
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c|8
> 5 files changed, 78 insertions(+), 1 deletion(-)
>
> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
> ===
> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:29.946888653 +0900
> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:43.470719531 +0900
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
> static int acpi_memory_device_remove(struct acpi_device
> *device, int type)
> {
> struct acpi_memory_device *mem_device = NULL;
> -
> + struct acpi_memory_info *info, *tmp;
> + int result;
> + int node;
>
> if (!device || !acpi_driver_data(device))
> return -EINVAL;
>
> mem_device = acpi_driver_data(device);
> +
> + node = acpi_get_node(mem_device->device->handle);
> +
> + list_for_each_entry_safe(info, tmp, _device->res_list,
> list) {
> + if (!info->enabled)
> + continue;
> +
> + if (!is_memblk_offline(info->start_addr, info->length))
> {
> + result = offline_memory(info->start_addr,
> info->length);
> + if (result)
> + return result;
> + }
> +
> + result = remove_memory(node, info->start_addr,
> info->length);
The user may online the memory between offline_memory() and
remove_memory().
So I think we should lock memory hotplug before check the memory's
status
and release it after remove_memory().
>>>
>>> How about get "mem_block->state_mutex" of removed memory? When offlining
>>> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
>>> In this case, we get mem_block->state_mutex. So I think the mutex lock
>>> is beneficial.
>>
>> It is not good idea since remove_memory frees mem_block structure...
>> Do you have any ideas?
>
> Hmm, split offline_memory() to 2 functions: offline_pages() and
> __offline_pages()
>
> offline_pages()
> lock_memory_hotplug();
> __offline_pages();
> unlock_memory_hotplug();
>
> and implement remove_memory() like this:
> remove_memory()
> lock_memory_hotplug()
> if (!is_memblk_offline()) {
> __offline_pages();
> }
> // cleanup
> unlock_memory_hotplug();
>
> What about this?
I also thought about it once. But a problem remains. Current
offilne_pages()
cannot realize the memory has been removed by remove_memory(). So even if
protecting the race by lock_memory_hotplug(), offline_pages() can offline
the removed memory. offline_pages() should have
Re: [PATCH] epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll events are ready
On Tue, Jul 17, 2012 at 12:04 AM, Arve Hjønnevåg wrote: > On Mon, Jul 16, 2012 at 4:00 AM, Rafael J. Wysocki wrote: >> On Monday, July 16, 2012, Michael Kerrisk wrote: >>> Arve, Rafael, >>> >>> On Tue, May 1, 2012 at 7:33 AM, Arve Hjønnevåg wrote: >>> > When an epoll_event, that has the EPOLLWAKEUP flag set, is ready, a >>> > wakeup_source will be active to prevent suspend. This can be used to >>> > handle wakeup events from a driver that support poll, e.g. input, if >>> > that driver wakes up the waitqueue passed to epoll before allowing >>> > suspend. >>> >>> It's late it the -rc series, >> >> Well, exactly. :-) If someone had CCed linux-api@ along the way (as per Documentation/SubmitChecklist), it might have helped ;-) >> >>> but it strikes me that CAP_EPOLLWAKEUP is >>> a poor name for the capability that governs the use of EPOLLWAKEUP. >>> While on the one hand some capabilities are overloaded >>> (https://lwn.net/Articles/486306/), on the other hand we should avoid >>> adding individual capabilities for each new API feature (otherwise >>> capabilities become administratively unwieldy). >>> >>> This capability is not really about "EPOLL". It's about the ability to >>> block system suspend. Therefore, IMO, a better name would be something >>> like: CAP_BLOCK_SUSPEND. This name is better because there might be >>> some other API feature that is later added that also has the effect of >>> preventing system suspends, and we could reasonably govern that >>> feature with the same capability. > > We already have another api, "/sys/power/wake_lock", that allow > user-space to block suspend. Do we want to apply this capability that > api as well, or only to apis that do not have other ways to restrict > access? Well, the question is: is there a governor on the use of /sys/power/wake_lock? It makes sense either they are both governed (preferably by the same mechanism, I would have thought), or neither is. >>> Does that seem sensible to you? I can send a patch for the name change. >> >> I'm not sure what Arve thinks about that, but I'd be fine with that. >> >> Arve, what do you think? >> > > CAP_BLOCK_SUSPEND is fine with me, but if it does not apply to the > sysfs interface, then the comment should probably mention this. I've sent a patch, but omitted mention of API details in the comments. Maybe that can be changed afterward, when a decision has been reached about governing /sys/power/wake_lock. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers: bus: add a new driver for omap-ocp2scp
+Arnd Bergmann
On Mon, Jul 16, 2012 at 7:43 PM, Kishon Vijay Abraham I wrote:
> Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of
> creating all the devices that is connected to OCP2SCP. In the case of OMAP4,
> USB2PHY is connected to ocp2scp.
>
> This also includes device tree support for ocp2scp driver and
> the documentation with device tree binding information is updated.
>
> Cc: Felipe Balbi
> Cc: Arnd Bergmann
> Signed-off-by: Kishon Vijay Abraham I
> ---
> .../devicetree/bindings/bus/omap-ocp2scp.txt | 10 ++
> drivers/Kconfig|2 +
> drivers/Makefile |2 +
> drivers/bus/Kconfig| 15 +++
> drivers/bus/Makefile |5 +
> drivers/bus/omap-ocp2scp.c | 98
>
> 6 files changed, 132 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> create mode 100644 drivers/bus/Kconfig
> create mode 100644 drivers/bus/Makefile
> create mode 100644 drivers/bus/omap-ocp2scp.c
>
> diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> new file mode 100644
> index 000..d2fe064
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
> @@ -0,0 +1,10 @@
> +* OMAP OCP2SCP - ocp interface to scp interface
> +
> +properties:
> +- compatible : Should be "ti,omap-ocp2scp"
> +- #address-cells, #size-cells : Must be present if the device has sub-nodes
> +- ranges : the child address space are mapped 1:1 onto the parent address
> space
> +- ti,hwmods : must be "ocp2scp_usb_phy"
> +
> +Sub-nodes:
> +All the devices connected to ocp2scp are described using sub-node to ocp2scp
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index bfc9186..4fe1e4c 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -2,6 +2,8 @@ menu "Device Drivers"
>
> source "drivers/base/Kconfig"
>
> +source "drivers/bus/Kconfig"
> +
> source "drivers/connector/Kconfig"
>
> source "drivers/mtd/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 2ba29ff..cac3819 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -5,6 +5,8 @@
> # Rewritten to use lists instead of if-statements.
> #
>
> +obj-y += bus/
> +
> # GPIO must come after pinctrl as gpios may need to mux pins etc
> obj-y += pinctrl/
> obj-y += gpio/
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> new file mode 100644
> index 000..6270415
> --- /dev/null
> +++ b/drivers/bus/Kconfig
> @@ -0,0 +1,15 @@
> +#
> +# Bus Devices
> +#
> +
> +menu "Bus devices"
> +
> +config OMAP_OCP2SCP
> + tristate "OMAP OCP2SCP DRIVER"
> + help
> + Driver to enable ocp2scp module which transforms ocp interface
> + protocol to scp protocol. In OMAP4, USB PHY is connected via
> + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
> + OCP2SCP.
> +
> +endmenu
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> new file mode 100644
> index 000..0ec50bc
> --- /dev/null
> +++ b/drivers/bus/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the bus drivers.
> +#
> +
> +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
> diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
> new file mode 100644
> index 000..8c3db3a
> --- /dev/null
> +++ b/drivers/bus/omap-ocp2scp.c
> @@ -0,0 +1,98 @@
> +/*
> + * omap-ocp2scp.c - transform ocp interface protocol to scp protocol
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Author: Kishon Vijay Abraham I
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int ocp2scp_remove_devices(struct device *dev, void *c)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> +
> + platform_device_unregister(pdev);
> +
> + return 0;
> +}
> +
> +static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
> +{
> + int ret;
> + struct device_node *np = pdev->dev.of_node;
> +
> + if (np) {
> + ret = of_platform_populate(np, NULL, NULL, >dev);
> + if (ret) {
> +
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
At 07/17/2012 12:51 PM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/07/17 12:32, Wen Congyang wrote:
>> At 07/17/2012 11:08 AM, Yasuaki Ishimatsu Wrote:
>>> Hi Wen,
>>>
>>> 2012/07/17 11:32, Wen Congyang wrote:
At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/07/17 10:44, Yasuaki Ishimatsu wrote:
>> Hi Wen,
>>
>> 2012/07/13 12:35, Wen Congyang wrote:
>>> At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
acpi_memory_device_remove() has been prepared to remove physical
memory.
But, the function only frees acpi_memory_device currentlry.
The patch adds following functions into acpi_memory_device_remove():
- offline memory
- remove physical memory (only return -EBUSY)
- free acpi_memory_device
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/acpi_memhotplug.c | 26 +-
drivers/base/memory.c | 39
+++
include/linux/memory.h |5 +
include/linux/memory_hotplug.h |1 +
mm/memory_hotplug.c|8
5 files changed, 78 insertions(+), 1 deletion(-)
Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
===
--- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
18:08:29.946888653 +0900
+++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
18:08:43.470719531 +0900
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
static int acpi_memory_device_remove(struct acpi_device *device,
int type)
{
struct acpi_memory_device *mem_device = NULL;
-
+ struct acpi_memory_info *info, *tmp;
+ int result;
+ int node;
if (!device || !acpi_driver_data(device))
return -EINVAL;
mem_device = acpi_driver_data(device);
+
+ node = acpi_get_node(mem_device->device->handle);
+
+ list_for_each_entry_safe(info, tmp, _device->res_list,
list) {
+ if (!info->enabled)
+ continue;
+
+ if (!is_memblk_offline(info->start_addr, info->length))
{
+ result = offline_memory(info->start_addr,
info->length);
+ if (result)
+ return result;
+ }
+
+ result = remove_memory(node, info->start_addr,
info->length);
>>>
>>> The user may online the memory between offline_memory() and
>>> remove_memory().
>>> So I think we should lock memory hotplug before check the memory's
>>> status
>>> and release it after remove_memory().
>>
>> How about get "mem_block->state_mutex" of removed memory? When offlining
>> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
>> In this case, we get mem_block->state_mutex. So I think the mutex lock
>> is beneficial.
>
> It is not good idea since remove_memory frees mem_block structure...
> Do you have any ideas?
Hmm, split offline_memory() to 2 functions: offline_pages() and
__offline_pages()
offline_pages()
lock_memory_hotplug();
__offline_pages();
unlock_memory_hotplug();
and implement remove_memory() like this:
remove_memory()
lock_memory_hotplug()
if (!is_memblk_offline()) {
__offline_pages();
}
// cleanup
unlock_memory_hotplug();
What about this?
>>>
>>> I also thought about it once. But a problem remains. Current offilne_pages()
>>> cannot realize the memory has been removed by remove_memory(). So even if
>>> protecting the race by lock_memory_hotplug(), offline_pages() can offline
>>> the removed memory. offline_pages() should have the means to know the memory
>>> was removed. But I don't have good idea.
>>
>> We can not online/offline part of memory block, so what about this?
>
> It seems you do not understand my concern.
> When
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 00:25 -0400, Steven Rostedt wrote: > On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: > > > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > > [] > > > @@ -13,6 +13,8 @@ > > > * Copyright (C) 2004 William Lee Irwin III > > > */ > > > > > > +#define pr_fmt(fmt) "ftrace: " fmt > > > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > Wouldn't a nicer patch be to move this into a header file and then > remove all the defines throughout the kernel tree? Maybe. There are modules that use common header files like you suggest. It does mean that header must be the #included before any other #include that might #include or printk.h. Right now, if pr_fmt isn't #defined, printk.h has a default definition of: #ifndef pr_fmt #define pr_fmt(fmt) fmt #endif My goal is to change that to: #ifndef pr_fmt #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #endif in 3.8 (maybe 3.7) and remove all of these then useless, duplicate #defines shortly afterward. https://lkml.org/lkml/2012/3/27/247 > Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is > not a module. It depends on the Makefile. scripts/Makefile.lib:# $(modname_flags) #defines KBUILD_MODNAME as the name of the module it will scripts/Makefile.lib-# end up in (or would, if it gets compiled in) scripts/Makefile.lib-# Note: Files that end up in two or more modules are compiled without the scripts/Makefile.lib:# KBUILD_MODNAME definition. The reason is that any made-up name would scripts/Makefile.lib-# differ in different configs. scripts/Makefile.lib-name-fix = $(subst $(comma),_,$(subst -,_,$1)) scripts/Makefile.lib-basename_flags = -D"KBUILD_BASENAME=KBUILD_STR($(call name-fix,$(basetarget)))" scripts/Makefile.lib-modname_flags = $(if $(filter 1,$(words $(modname))),\ scripts/Makefile.lib: -D"KBUILD_MODNAME=KBUILD_STR($(call name-fix,$(modname)))") -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 on 3.5-rc6
Hi Dave, On Tue, Jul 17, 2012 at 12:16 AM, Dave Jones wrote: > > Check the bugs-found.txt file in trinity.git before reporting bugs found with > it. > This one already got reported.. https://lkml.org/lkml/2012/7/13/328 > I try to keep that file up to date to reduce multiple reports of the same bug. > (also, for that reason, please cc me on bugs you find with it!) > > thanks, > > Dave Thanks, Sorry for not seeing the bug-list. I will cc you in every bug reported from trinity. Devendra -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/10] kvm tools, powerpc: Use mmap_anon_or_hugetblfs() in kvm__arch_init()
It implements essentially the same logic. The one difference is it sets
MAP_NORESERVE when using anonymous mmap, but I think that is OK.
Reword the comment about hugetblfs, we are no longer required to use
hugepages to back the guest.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/kvm.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index cbc0d8f..0d8a9da 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -97,20 +97,12 @@ void kvm__arch_init(struct kvm *kvm, const char
*hugetlbfs_path, u64 ram_size)
kvm->ram_size = ram_size;
- /*
-* Currently, HV-mode PPC64 SPAPR requires that we map from hugetlfs.
-* Allow a 'default' option to assist.
-* PR-mode does not require this.
-*/
- if (hugetlbfs_path) {
- if (!strcmp(hugetlbfs_path, "default"))
- hugetlbfs_path = HUGETLBFS_PATH;
- kvm->ram_start = mmap_hugetlbfs(hugetlbfs_path, kvm->ram_size);
- } else {
- kvm->ram_start = mmap(0, kvm->ram_size, PROT_READ | PROT_WRITE,
- MAP_ANON | MAP_PRIVATE,
- -1, 0);
- }
+ /* Map "default" hugetblfs path to the standard 16M mount point */
+ if (hugetlbfs_path && !strcmp(hugetlbfs_path, "default"))
+ hugetlbfs_path = HUGETLBFS_PATH;
+
+ kvm->ram_start = mmap_anon_or_hugetlbfs(hugetlbfs_path, kvm->ram_size);
+
if (kvm->ram_start == MAP_FAILED)
die("Couldn't map %lld bytes for RAM (%d)\n",
kvm->ram_size, errno);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] kvm tools, powerpc: Use designated initializers for struct cpu_info
Using designated initializers for structs is preferable because it
is self documenting, and more robust against changes to the structure
layout.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c | 38 +-
tools/kvm/powerpc/cpu_info.h |6 +++---
2 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index c364b74..ad27451 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -30,14 +30,16 @@ static u32 power7_page_sizes_prop[] = {0xc, 0x0, 0x1, 0xc,
0x0, 0x18, 0x100, 0x1
static u32 power7_segment_sizes_prop[] = {0x1c, 0x28, 0x, 0x};
static struct cpu_info cpu_power7_info = {
- "POWER7",
- power7_page_sizes_prop, sizeof(power7_page_sizes_prop),
- power7_segment_sizes_prop, sizeof(power7_segment_sizes_prop),
- 32, /* SLB size */
- 51200, /* TB frequency */
- 128,/* d-cache block size */
- 128,/* i-cache block size */
- CPUINFO_FLAG_DFP | CPUINFO_FLAG_VSX | CPUINFO_FLAG_VMX
+ .name = "POWER7",
+ .page_sizes_prop = power7_page_sizes_prop,
+ .page_sizes_prop_len = sizeof(power7_segment_sizes_prop),
+ .segment_sizes_prop = power7_segment_sizes_prop,
+ .segment_sizes_prop_len = sizeof(power7_segment_sizes_prop),
+ .slb_size = 32,
+ .tb_freq = 51200,
+ .d_bsize = 128,
+ .i_bsize = 128,
+ .flags = CPUINFO_FLAG_DFP | CPUINFO_FLAG_VSX | CPUINFO_FLAG_VMX,
};
/* PPC970/G5 */
@@ -45,18 +47,20 @@ static struct cpu_info cpu_power7_info = {
static u32 g5_page_sizes_prop[] = {0xc, 0x0, 0x1, 0xc, 0x0, 0x18, 0x100, 0x1,
0x18, 0x0};
static struct cpu_info cpu_970_info = {
- "G5",
- g5_page_sizes_prop, sizeof(g5_page_sizes_prop),
- 0 /* Null = no segment sizes prop, use defaults */, 0,
- 0, /* SLB size default */
- , /* TB frequency */
- 128,/* d-cache block size */
- 128,/* i-cache block size */
- CPUINFO_FLAG_VMX
+ .name = "G5",
+ .page_sizes_prop = g5_page_sizes_prop,
+ .page_sizes_prop_len = sizeof(g5_page_sizes_prop),
+ .segment_sizes_prop = NULL /* no segment sizes prop, use defaults */,
+ .segment_sizes_prop_len = 0,
+ .slb_size = 0,
+ .tb_freq = ,
+ .d_bsize = 128,
+ .i_bsize = 128,
+ .flags = CPUINFO_FLAG_VMX,
};
/* This is a default catchall for 'no match' on PVR: */
-static struct cpu_info cpu_dummy_info = { "unknown", 0, 0, 0, 0, 0, 0, 0, 0 };
+static struct cpu_info cpu_dummy_info = { .name = "unknown" };
static struct pvr_info host_pvr_info[] = {
{ 0x, 0x0f03, _power7_info },
diff --git a/tools/kvm/powerpc/cpu_info.h b/tools/kvm/powerpc/cpu_info.h
index 4a43ed5..2115c7f 100644
--- a/tools/kvm/powerpc/cpu_info.h
+++ b/tools/kvm/powerpc/cpu_info.h
@@ -21,9 +21,9 @@ struct cpu_info {
u32 *segment_sizes_prop;
u32 segment_sizes_prop_len;
u32 slb_size;
- u32 tb_freq;
- u32 d_bsize;
- u32 i_bsize;
+ u32 tb_freq; /* timebase frequency */
+ u32 d_bsize; /* d-cache block size */
+ u32 i_bsize; /* i-cache block size */
u32 flags;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] kvm tools, powerpc: Reformatting in find_cpu_info()
Matt's enter key was broken when he wrote this ;)
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 7326f5b..586b232 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -75,13 +75,15 @@ static struct pvr_info host_pvr_info[] = {
struct cpu_info *find_cpu_info(u32 pvr)
{
unsigned int i;
+
for (i = 0; i < ARRAY_SIZE(host_pvr_info); i++) {
- if ((pvr & host_pvr_info[i].pvr_mask) ==
- host_pvr_info[i].pvr) {
+ if ((pvr & host_pvr_info[i].pvr_mask) == host_pvr_info[i].pvr) {
return host_pvr_info[i].cpu_info;
}
}
+
/* Didn't find anything? Rut-ro. */
pr_warning("Host CPU unsupported by kvmtool\n");
+
return _dummy_info;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/10] kvm tools, powerpc: Restructure find_cpu_info()
We are about to add more logic to find_cpu_info(). To support this we
need to pass kvm through to it, and also restructure the return flow
so we can operate on info before it is returned.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c | 16 +++-
tools/kvm/powerpc/cpu_info.h |4 +++-
tools/kvm/powerpc/kvm.c |2 +-
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 586b232..5015a4b 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -72,18 +72,24 @@ static struct pvr_info host_pvr_info[] = {
{ 0x, 0x0045, _970_info },
};
-struct cpu_info *find_cpu_info(u32 pvr)
+struct cpu_info *find_cpu_info(struct kvm *kvm)
{
+ struct cpu_info *info;
unsigned int i;
+ u32 pvr = kvm->pvr;
- for (i = 0; i < ARRAY_SIZE(host_pvr_info); i++) {
+ for (info = NULL, i = 0; i < ARRAY_SIZE(host_pvr_info); i++) {
if ((pvr & host_pvr_info[i].pvr_mask) == host_pvr_info[i].pvr) {
- return host_pvr_info[i].cpu_info;
+ info = host_pvr_info[i].cpu_info;
+ break;
}
}
/* Didn't find anything? Rut-ro. */
- pr_warning("Host CPU unsupported by kvmtool\n");
+ if (!info) {
+ pr_warning("Host CPU unsupported by kvmtool\n");
+ info = _dummy_info;
+ }
- return _dummy_info;
+ return info;
}
diff --git a/tools/kvm/powerpc/cpu_info.h b/tools/kvm/powerpc/cpu_info.h
index 2115c7f..439f3940 100644
--- a/tools/kvm/powerpc/cpu_info.h
+++ b/tools/kvm/powerpc/cpu_info.h
@@ -11,6 +11,8 @@
#ifndef CPU_INFO_H
#define CPU_INFO_H
+#include
+
#include
#include
@@ -38,6 +40,6 @@ struct pvr_info {
#define CPUINFO_FLAG_VMX 0x0002
#define CPUINFO_FLAG_VSX 0x0004
-struct cpu_info *find_cpu_info(u32 pvr);
+struct cpu_info *find_cpu_info(struct kvm *kvm);
#endif
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index e3a7e52..dbfea3e 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -229,7 +229,7 @@ static void setup_fdt(struct kvm *kvm)
int i, j;
charcpu_name[30];
u8 staging_fdt[FDT_MAX_SIZE];
- struct cpu_info *cpu_info = find_cpu_info(kvm->pvr);
+ struct cpu_info *cpu_info = find_cpu_info(kvm);
/* Generate an appropriate DT at kvm->fdt_gra */
void *fdt_dest = guest_flat_to_host(kvm, kvm->fdt_gra);
--
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/
[RFC/PATCH] Use kernel supplied MMU info for kvm tool
Hi all, This is a series for kvmtool that uses a newish kernel API to get MMU info, which is then fed to the guest. Currently we just make a good guess based on the PVR, but that is potentially flakey in a few ways. The most notable is that if you don't specify hugepages we don't boot - because the guest is told we support 16M pages, but we don't really (on HV). I've tested this with 4K/64K host page size, and with hugepages, on both 3.4 and 3.5 based host kernels. I've also given it a quick smoke test with PR KVM, and it seems to work. I'm seeing a guest crash with a 4K host kernel, but I think that is unrelated, and happens with or without this patch series. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/10] kvm tools, powerpc: Use MMU info for ibm,slb-size
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c |3 +--
tools/kvm/powerpc/cpu_info.h |1 -
tools/kvm/powerpc/kvm.c |5 +++--
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 82a9d4f..1f440a5 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -25,13 +25,13 @@
static struct cpu_info cpu_power7_info = {
.name = "POWER7",
- .slb_size = 32,
.tb_freq = 51200,
.d_bsize = 128,
.i_bsize = 128,
.flags = CPUINFO_FLAG_DFP | CPUINFO_FLAG_VSX | CPUINFO_FLAG_VMX,
.mmu_info = {
.flags = KVM_PPC_PAGE_SIZES_REAL | KVM_PPC_1T_SEGMENTS,
+ .slb_size = 32,
},
};
@@ -39,7 +39,6 @@ static struct cpu_info cpu_power7_info = {
static struct cpu_info cpu_970_info = {
.name = "G5",
- .slb_size = 0,
.tb_freq = ,
.d_bsize = 128,
.i_bsize = 128,
diff --git a/tools/kvm/powerpc/cpu_info.h b/tools/kvm/powerpc/cpu_info.h
index 00b9436b..f61707a 100644
--- a/tools/kvm/powerpc/cpu_info.h
+++ b/tools/kvm/powerpc/cpu_info.h
@@ -19,7 +19,6 @@
struct cpu_info {
const char *name;
- u32 slb_size;
u32 tb_freq; /* timebase frequency */
u32 d_bsize; /* d-cache block size */
u32 i_bsize; /* i-cache block size */
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index 8353355..83b8edd 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -393,8 +393,9 @@ static void setup_fdt(struct kvm *kvm)
/* Lies, but safeish lies! */
_FDT(fdt_property_cell(fdt, "clock-frequency", 0xddbab200));
- if (cpu_info->slb_size)
- _FDT(fdt_property_cell(fdt, "ibm,slb-size",
cpu_info->slb_size));
+ if (cpu_info->mmu_info.slb_size)
+ _FDT(fdt_property_cell(fdt, "ibm,slb-size",
cpu_info->mmu_info.slb_size));
+
/*
* HPT size is hardwired; KVM currently fixes it at 16MB but the
* moment that changes we'll need to read it out of the kernel.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10] kvm tools, powerpc: Use MMU info for ibm,processor-segment-sizes
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c |7 ---
tools/kvm/powerpc/cpu_info.h |2 --
tools/kvm/powerpc/kvm.c |7 ---
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 1cfb50d..82a9d4f 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -23,13 +23,8 @@
/* POWER7 */
-/* POWER7 has 1T segments, so advertise these */
-static u32 power7_segment_sizes_prop[] = {0x1c, 0x28, 0x, 0x};
-
static struct cpu_info cpu_power7_info = {
.name = "POWER7",
- .segment_sizes_prop = power7_segment_sizes_prop,
- .segment_sizes_prop_len = sizeof(power7_segment_sizes_prop),
.slb_size = 32,
.tb_freq = 51200,
.d_bsize = 128,
@@ -44,8 +39,6 @@ static struct cpu_info cpu_power7_info = {
static struct cpu_info cpu_970_info = {
.name = "G5",
- .segment_sizes_prop = NULL /* no segment sizes prop, use defaults */,
- .segment_sizes_prop_len = 0,
.slb_size = 0,
.tb_freq = ,
.d_bsize = 128,
diff --git a/tools/kvm/powerpc/cpu_info.h b/tools/kvm/powerpc/cpu_info.h
index 9da6afe..00b9436b 100644
--- a/tools/kvm/powerpc/cpu_info.h
+++ b/tools/kvm/powerpc/cpu_info.h
@@ -19,8 +19,6 @@
struct cpu_info {
const char *name;
- u32 *segment_sizes_prop;
- u32 segment_sizes_prop_len;
u32 slb_size;
u32 tb_freq; /* timebase frequency */
u32 d_bsize; /* d-cache block size */
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index 293812a..8353355 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -299,6 +299,7 @@ static void setup_fdt(struct kvm *kvm)
u8 staging_fdt[FDT_MAX_SIZE];
struct cpu_info *cpu_info = find_cpu_info(kvm);
struct fdt_prop segment_page_sizes;
+ u32 segment_sizes_1T[] = {0x1c, 0x28, 0x, 0x};
/* Generate an appropriate DT at kvm->fdt_gra */
void *fdt_dest = guest_flat_to_host(kvm, kvm->fdt_gra);
@@ -424,10 +425,10 @@ static void setup_fdt(struct kvm *kvm)
segment_page_sizes.value,
segment_page_sizes.size));
- if (cpu_info->segment_sizes_prop)
+ if (cpu_info->mmu_info.flags & KVM_PPC_1T_SEGMENTS)
_FDT(fdt_property(fdt, "ibm,processor-segment-sizes",
- cpu_info->segment_sizes_prop,
- cpu_info->segment_sizes_prop_len));
+ segment_sizes_1T,
sizeof(segment_sizes_1T)));
+
/* VSX / DFP options: */
if (cpu_info->flags & CPUINFO_FLAG_VMX)
_FDT(fdt_property_cell(fdt, "ibm,vmx",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] kvm tools, powerpc: Use MMU info from the kernel for ibm,segment-page-sizes
Recent kernels (>= v3.5-rc1) have an ioctl which allows us to retrieve the
list of page sizes supported for the guest.
So rework the cpu info code to use that ioctl when available, falling
back to the same values we used previously if the ioctl is not present.
We may also need to filter the list of page sizes against the page size
of the memory backing guest RAM - this accounts for the unfortunate amount
of code in setup_mmu_info().
Finally we need to turn the structure as returned by the kernel into the
format expected in the device tree.
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c | 132 ++
tools/kvm/powerpc/cpu_info.h |4 +-
tools/kvm/powerpc/kvm.c | 81 +-
3 files changed, 200 insertions(+), 17 deletions(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index 5015a4b..1cfb50d 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -15,24 +15,19 @@
* by the Free Software Foundation.
*/
+#include
+#include
+
#include "cpu_info.h"
#include "kvm/util.h"
/* POWER7 */
-/*
- * Basic set of pages for POWER7. It actually supports more but there were
some
- * limitations as to which may be advertised to the guest. FIXME when this
- * settles down -- for now use basic set:
- */
-static u32 power7_page_sizes_prop[] = {0xc, 0x0, 0x1, 0xc, 0x0, 0x18, 0x100,
0x1, 0x18, 0x0};
/* POWER7 has 1T segments, so advertise these */
static u32 power7_segment_sizes_prop[] = {0x1c, 0x28, 0x, 0x};
static struct cpu_info cpu_power7_info = {
.name = "POWER7",
- .page_sizes_prop = power7_page_sizes_prop,
- .page_sizes_prop_len = sizeof(power7_segment_sizes_prop),
.segment_sizes_prop = power7_segment_sizes_prop,
.segment_sizes_prop_len = sizeof(power7_segment_sizes_prop),
.slb_size = 32,
@@ -40,16 +35,15 @@ static struct cpu_info cpu_power7_info = {
.d_bsize = 128,
.i_bsize = 128,
.flags = CPUINFO_FLAG_DFP | CPUINFO_FLAG_VSX | CPUINFO_FLAG_VMX,
+ .mmu_info = {
+ .flags = KVM_PPC_PAGE_SIZES_REAL | KVM_PPC_1T_SEGMENTS,
+ },
};
/* PPC970/G5 */
-static u32 g5_page_sizes_prop[] = {0xc, 0x0, 0x1, 0xc, 0x0, 0x18, 0x100, 0x1,
0x18, 0x0};
-
static struct cpu_info cpu_970_info = {
.name = "G5",
- .page_sizes_prop = g5_page_sizes_prop,
- .page_sizes_prop_len = sizeof(g5_page_sizes_prop),
.segment_sizes_prop = NULL /* no segment sizes prop, use defaults */,
.segment_sizes_prop_len = 0,
.slb_size = 0,
@@ -72,6 +66,118 @@ static struct pvr_info host_pvr_info[] = {
{ 0x, 0x0045, _970_info },
};
+/* If we can't query the kernel for supported page sizes assume 4K and 16M */
+static struct kvm_ppc_one_seg_page_size fallback_sps[] = {
+ [0] = {
+ .page_shift = 12,
+ .slb_enc= 0,
+ .enc = {
+ [0] = {
+ .page_shift = 12,
+ .pte_enc= 0,
+ },
+ },
+ },
+ [1] = {
+ .page_shift = 24,
+ .slb_enc= 0x100,
+ .enc = {
+ [0] = {
+ .page_shift = 24,
+ .pte_enc= 0,
+ },
+ },
+ },
+};
+
+
+static void setup_mmu_info(struct kvm *kvm, struct cpu_info *cpu_info)
+{
+ static struct kvm_ppc_smmu_info *mmu_info;
+ struct kvm_ppc_one_seg_page_size *sps;
+ int i, j, k, valid;
+
+ if (!kvm__supports_extension(kvm, KVM_CAP_PPC_GET_SMMU_INFO)) {
+ memcpy(_info->mmu_info.sps, fallback_sps,
sizeof(fallback_sps));
+ } else if (ioctl(kvm->vm_fd, KVM_PPC_GET_SMMU_INFO,
_info->mmu_info) < 0) {
+ die_perror("KVM_PPC_GET_SMMU_INFO failed");
+ }
+
+ mmu_info = _info->mmu_info;
+
+ if (!(mmu_info->flags & KVM_PPC_PAGE_SIZES_REAL))
+ /* Guest pages are not restricted by the backing page size */
+ return;
+
+ /* Filter based on backing page size */
+
+ for (i = 0; i < KVM_PPC_PAGE_SIZES_MAX_SZ; i++) {
+ sps = _info->sps[i];
+
+ if (!sps->page_shift)
+ break;
+
+ if (kvm->ram_pagesize < (1ul << sps->page_shift)) {
+ /* Mark the whole segment size invalid */
+ sps->page_shift = 0;
+ continue;
+ }
+
+ /* Check each page size for the segment */
+ for (j = 0, valid = 0; j < KVM_PPC_PAGE_SIZES_MAX_SZ; j++) {
+ if (!sps->enc[j].page_shift)
+ break;
+
+ if (kvm->ram_pagesize < (1ul << sps->enc[j].page_shift))
+
[PATCH 05/10] kvm tools, powerpc: Use ARRAY_SIZE() in find_cpu_info()
Signed-off-by: Michael Ellerman
---
tools/kvm/powerpc/cpu_info.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kvm/powerpc/cpu_info.c b/tools/kvm/powerpc/cpu_info.c
index ad27451..7326f5b 100644
--- a/tools/kvm/powerpc/cpu_info.c
+++ b/tools/kvm/powerpc/cpu_info.c
@@ -75,7 +75,7 @@ static struct pvr_info host_pvr_info[] = {
struct cpu_info *find_cpu_info(u32 pvr)
{
unsigned int i;
- for (i = 0; i < sizeof(host_pvr_info)/sizeof(struct pvr_info); i++) {
+ for (i = 0; i < ARRAY_SIZE(host_pvr_info); i++) {
if ((pvr & host_pvr_info[i].pvr_mask) ==
host_pvr_info[i].pvr) {
return host_pvr_info[i].cpu_info;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] kvm tools: Remember page size as kvm->ram_pagesize
On some powerpc platforms we need to make sure we only advertise page
sizes to the guest which are <= the size of the pages backing guest RAM.
So have mmap_hugetblfs() save the hugetblfs page size for us, and also
teach mmap_anon_or_hugetblfs() to set the page size for anonymous mmap.
Signed-off-by: Michael Ellerman
---
tools/kvm/include/kvm/util.h |4 +++-
tools/kvm/powerpc/include/kvm/kvm-arch.h |1 +
tools/kvm/powerpc/kvm.c |2 +-
tools/kvm/util/util.c| 13 +
tools/kvm/x86/include/kvm/kvm-arch.h |1 +
tools/kvm/x86/kvm.c |4 ++--
6 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/tools/kvm/include/kvm/util.h b/tools/kvm/include/kvm/util.h
index 3d1d987..0df9f0d 100644
--- a/tools/kvm/include/kvm/util.h
+++ b/tools/kvm/include/kvm/util.h
@@ -90,6 +90,8 @@ static inline void msleep(unsigned int msecs)
usleep(MSECS_TO_USECS(msecs));
}
-void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size);
+struct kvm;
+void *mmap_hugetlbfs(struct kvm *kvm, const char *htlbfs_path, u64 size);
+void *mmap_anon_or_hugetlbfs(struct kvm *kvm, const char *hugetlbfs_path, u64
size);
#endif /* KVM__UTIL_H */
diff --git a/tools/kvm/powerpc/include/kvm/kvm-arch.h
b/tools/kvm/powerpc/include/kvm/kvm-arch.h
index 404e33e..316fe79 100644
--- a/tools/kvm/powerpc/include/kvm/kvm-arch.h
+++ b/tools/kvm/powerpc/include/kvm/kvm-arch.h
@@ -54,6 +54,7 @@ struct kvm {
u64 ram_size;
void*ram_start;
+ u64 ram_pagesize;
u64 sdr1;
u32 pvr;
diff --git a/tools/kvm/powerpc/kvm.c b/tools/kvm/powerpc/kvm.c
index 0d8a9da..e3a7e52 100644
--- a/tools/kvm/powerpc/kvm.c
+++ b/tools/kvm/powerpc/kvm.c
@@ -101,7 +101,7 @@ void kvm__arch_init(struct kvm *kvm, const char
*hugetlbfs_path, u64 ram_size)
if (hugetlbfs_path && !strcmp(hugetlbfs_path, "default"))
hugetlbfs_path = HUGETLBFS_PATH;
- kvm->ram_start = mmap_anon_or_hugetlbfs(hugetlbfs_path, kvm->ram_size);
+ kvm->ram_start = mmap_anon_or_hugetlbfs(kvm, hugetlbfs_path,
kvm->ram_size);
if (kvm->ram_start == MAP_FAILED)
die("Couldn't map %lld bytes for RAM (%d)\n",
diff --git a/tools/kvm/util/util.c b/tools/kvm/util/util.c
index a80cf86..c11a15a 100644
--- a/tools/kvm/util/util.c
+++ b/tools/kvm/util/util.c
@@ -4,6 +4,7 @@
#include "kvm/util.h"
+#include
#include/* For HUGETLBFS_MAGIC */
#include
#include
@@ -80,7 +81,7 @@ void die_perror(const char *s)
exit(1);
}
-void *mmap_hugetlbfs(const char *htlbfs_path, u64 size)
+void *mmap_hugetlbfs(struct kvm *kvm, const char *htlbfs_path, u64 size)
{
char mpath[PATH_MAX];
int fd;
@@ -100,6 +101,8 @@ void *mmap_hugetlbfs(const char *htlbfs_path, u64 size)
blk_size, size);
}
+ kvm->ram_pagesize = blk_size;
+
snprintf(mpath, PATH_MAX, "%s/kvmtoolXX", htlbfs_path);
fd = mkstemp(mpath);
if (fd < 0)
@@ -115,14 +118,16 @@ void *mmap_hugetlbfs(const char *htlbfs_path, u64 size)
}
/* This function wraps the decision between hugetlbfs map (if requested) or
normal mmap */
-void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size)
+void *mmap_anon_or_hugetlbfs(struct kvm *kvm, const char *hugetlbfs_path, u64
size)
{
if (hugetlbfs_path)
/*
* We don't /need/ to map guest RAM from hugetlbfs, but we do so
* if the user specifies a hugetlbfs path.
*/
- return mmap_hugetlbfs(hugetlbfs_path, size);
- else
+ return mmap_hugetlbfs(kvm, hugetlbfs_path, size);
+ else {
+ kvm->ram_pagesize = getpagesize();
return mmap(NULL, size, PROT_RW, MAP_ANON_NORESERVE, -1, 0);
+ }
}
diff --git a/tools/kvm/x86/include/kvm/kvm-arch.h
b/tools/kvm/x86/include/kvm/kvm-arch.h
index 551c8b4..dd385d4 100644
--- a/tools/kvm/x86/include/kvm/kvm-arch.h
+++ b/tools/kvm/x86/include/kvm/kvm-arch.h
@@ -34,6 +34,7 @@ struct kvm {
u64 ram_size;
void*ram_start;
+ u64 ram_pagesize;
boolnmi_disabled;
diff --git a/tools/kvm/x86/kvm.c b/tools/kvm/x86/kvm.c
index 8931639..0a40fd5 100644
--- a/tools/kvm/x86/kvm.c
+++ b/tools/kvm/x86/kvm.c
@@ -144,9 +144,9 @@ void kvm__arch_init(struct kvm *kvm, const char
*hugetlbfs_path, u64 ram_size)
if (ram_size < KVM_32BIT_GAP_START) {
kvm->ram_size = ram_size;
- kvm->ram_start = mmap_anon_or_hugetlbfs(hugetlbfs_path,
ram_size);
+ kvm->ram_start = mmap_anon_or_hugetlbfs(kvm, hugetlbfs_path,
ram_size);
} else {
- kvm->ram_start =
[PATCH 01/10] kvm tools: Move mmap_anon_or_hugetblfs() into util
So we can use it on powerpc.
Signed-off-by: Michael Ellerman
---
tools/kvm/include/kvm/util.h |2 +-
tools/kvm/util/util.c| 13 +
tools/kvm/x86/kvm.c | 13 -
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/kvm/include/kvm/util.h b/tools/kvm/include/kvm/util.h
index dabf544..3d1d987 100644
--- a/tools/kvm/include/kvm/util.h
+++ b/tools/kvm/include/kvm/util.h
@@ -90,6 +90,6 @@ static inline void msleep(unsigned int msecs)
usleep(MSECS_TO_USECS(msecs));
}
-void *mmap_hugetlbfs(const char *htlbfs_path, u64 size);
+void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size);
#endif /* KVM__UTIL_H */
diff --git a/tools/kvm/util/util.c b/tools/kvm/util/util.c
index e7feebc..a80cf86 100644
--- a/tools/kvm/util/util.c
+++ b/tools/kvm/util/util.c
@@ -113,3 +113,16 @@ void *mmap_hugetlbfs(const char *htlbfs_path, u64 size)
return addr;
}
+
+/* This function wraps the decision between hugetlbfs map (if requested) or
normal mmap */
+void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size)
+{
+ if (hugetlbfs_path)
+ /*
+* We don't /need/ to map guest RAM from hugetlbfs, but we do so
+* if the user specifies a hugetlbfs path.
+*/
+ return mmap_hugetlbfs(hugetlbfs_path, size);
+ else
+ return mmap(NULL, size, PROT_RW, MAP_ANON_NORESERVE, -1, 0);
+}
diff --git a/tools/kvm/x86/kvm.c b/tools/kvm/x86/kvm.c
index 10a1212..8931639 100644
--- a/tools/kvm/x86/kvm.c
+++ b/tools/kvm/x86/kvm.c
@@ -128,19 +128,6 @@ void kvm__arch_set_cmdline(char *cmdline, bool video)
strcat(cmdline, " console=ttyS0 earlyprintk=serial
i8042.noaux=1");
}
-/* This function wraps the decision between hugetlbfs map (if requested) or
normal mmap */
-static void *mmap_anon_or_hugetlbfs(const char *hugetlbfs_path, u64 size)
-{
- if (hugetlbfs_path)
- /*
-* We don't /need/ to map guest RAM from hugetlbfs, but we do so
-* if the user specifies a hugetlbfs path.
-*/
- return mmap_hugetlbfs(hugetlbfs_path, size);
- else
- return mmap(NULL, size, PROT_RW, MAP_ANON_NORESERVE, -1, 0);
-}
-
/* Architecture-specific KVM init */
void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: fix compile for OF && !COMMON_CLK
On Tuesday 17 July 2012 03:16 AM, Rob Herring wrote:
From: Rob Herring
With commit 766e6a4ec602d0c107 (clk: add DT clock binding support),
compiling with OF&& !COMMON_CLK is broken.
Thanks Rob!!
This patch fixed the build failure for Tegra.
Reported-by: Alexandre Pereira da Silva
Reported-by: Prashant Gaikwad
Signed-off-by: Rob Herring
---
drivers/clk/clkdev.c |2 +-
include/linux/clk.h |7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 20649b3..8f87b0f 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -24,7 +24,7 @@
static LIST_HEAD(clocks);
static DEFINE_MUTEX(clocks_mutex);
-#ifdef CONFIG_OF
+#if defined(CONFIG_OF)&& defined(CONFIG_COMMON_CLK)
struct clk *of_clk_get(struct device_node *np, int index)
{
struct of_phandle_args clkspec;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 8b70342..35f7492 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -12,6 +12,7 @@
#ifndef __LINUX_CLK_H
#define __LINUX_CLK_H
+#include
#include
#include
@@ -313,19 +314,19 @@ int clk_add_alias(const char *alias, const char
*alias_dev_name, char *id,
struct device_node;
struct of_phandle_args;
-#ifdef CONFIG_OF
+#if defined(CONFIG_OF)&& defined(CONFIG_COMMON_CLK)
struct clk *of_clk_get(struct device_node *np, int index);
struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
#else
static inline struct clk *of_clk_get(struct device_node *np, int index)
{
- return NULL;
+ return ERR_PTR(-EINVAL);
}
static inline struct clk *of_clk_get_by_name(struct device_node *np,
const char *name)
{
- return NULL;
+ return ERR_PTR(-EINVAL);
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xhci: EHCI/xHCI ports switching on Intense-PC.
On Mon, Jul 16, 2012 at 07:46:06PM +0300, Denis Turischev wrote:
> Intense-PC is Compulab's mini-desktop with Intel Panther Point
> chipset.
>
> Unconditional ports switching provided by function
> usb_enable_xhci_ports() leads to surprising results, after shutdown
> system powered-on again after a few seconds. On Windows power
> related problems were not observed.
Do you have wake on lan enabled in the BIOS? I have heard reports from
other users that this is a BIOS bug triggered by WOL.
> The patch avoids ports switching for Intense-PC.
>
> Signed-off-by: Denis Turischev
> ---
> drivers/usb/host/pci-quirks.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index df0828c..6f72593 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -759,6 +759,13 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
> {
> u32 ports_available;
>
> + const char *brd_name;
> + brd_name = dmi_get_system_info(DMI_BOARD_NAME);
> +
> + /* quirk for Compulab's Intense-PC board */
> + if (brd_name && strstr(brd_name, "Intense-PC"))
> + return;
> +
No, this fix is not acceptable. You won't get USB 3.0 speeds if the
ports are not switched over. Now, we can add a quirk to the xHCI
shutdown function to switch the ports back to EHCI on shutdown. That
might not trigger the BIOS bug.
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 mmotm] memcg: further prevent OOM with too many dirty pages
On Mon, 16 Jul 2012, Michal Hocko wrote: > On Mon 16-07-12 01:35:34, Hugh Dickins wrote: > > But even so, the test still OOMs sometimes: when originally testing > > on 3.5-rc6, it OOMed about one time in five or ten; when testing > > just now on 3.5-rc6-mm1, it OOMed on the first iteration. > > > > This residual problem comes from an accumulation of pages under > > ordinary writeback, not marked PageReclaim, so rightly not causing > > the memcg check to wait on their writeback: these too can prevent > > shrink_page_list() from freeing any pages, so many times that memcg > > reclaim fails and OOMs. > > I guess you managed to trigger this with 20M limit, right? That's right. > I have tested > with different group sizes but the writeback didn't trigger for most of > them and all the dirty data were flushed from the reclaim. I didn't examine writeback stats to confirm, but I guess that just occasionally it managed to come in and do enough work to confound us. > Have you used any special setting the dirty ratio? No, I wasn't imaginative enough to try that. > Or was it with xfs (IIUC that one > does ignore writeback from the direct reclaim completely). No, just ext4 at that point. I have since tested the final patch with ext4, ext3 (by ext3 driver and by ext4 driver), ext2 (by ext2 driver and by ext4 driver), xfs, btrfs, vfat, tmpfs (with swap on the USB stick) and block device: about an hour on each, no surprises, all okay. But I didn't experiment beyond the 20M memcg. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
Hi Wen,
2012/07/17 12:32, Wen Congyang wrote:
> At 07/17/2012 11:08 AM, Yasuaki Ishimatsu Wrote:
>> Hi Wen,
>>
>> 2012/07/17 11:32, Wen Congyang wrote:
>>> At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/07/17 10:44, Yasuaki Ishimatsu wrote:
> Hi Wen,
>
> 2012/07/13 12:35, Wen Congyang wrote:
>> At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
>>> acpi_memory_device_remove() has been prepared to remove physical memory.
>>> But, the function only frees acpi_memory_device currentlry.
>>>
>>> The patch adds following functions into acpi_memory_device_remove():
>>> - offline memory
>>> - remove physical memory (only return -EBUSY)
>>> - free acpi_memory_device
>>>
>>> CC: David Rientjes
>>> CC: Jiang Liu
>>> CC: Len Brown
>>> CC: Benjamin Herrenschmidt
>>> CC: Paul Mackerras
>>> CC: Christoph Lameter
>>> Cc: Minchan Kim
>>> CC: Andrew Morton
>>> CC: KOSAKI Motohiro
>>> CC: Wen Congyang
>>> Signed-off-by: Yasuaki Ishimatsu
>>>
>>> ---
>>> drivers/acpi/acpi_memhotplug.c | 26 +-
>>> drivers/base/memory.c | 39
>>> +++
>>> include/linux/memory.h |5 +
>>> include/linux/memory_hotplug.h |1 +
>>> mm/memory_hotplug.c|8
>>> 5 files changed, 78 insertions(+), 1 deletion(-)
>>>
>>> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
>>> ===
>>> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
>>> 18:08:29.946888653 +0900
>>> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c2012-07-09
>>> 18:08:43.470719531 +0900
>>> @@ -29,6 +29,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
>>> static int acpi_memory_device_remove(struct acpi_device *device,
>>> int type)
>>> {
>>> struct acpi_memory_device *mem_device = NULL;
>>> -
>>> + struct acpi_memory_info *info, *tmp;
>>> + int result;
>>> + int node;
>>>
>>> if (!device || !acpi_driver_data(device))
>>> return -EINVAL;
>>>
>>> mem_device = acpi_driver_data(device);
>>> +
>>> + node = acpi_get_node(mem_device->device->handle);
>>> +
>>> + list_for_each_entry_safe(info, tmp, _device->res_list,
>>> list) {
>>> + if (!info->enabled)
>>> + continue;
>>> +
>>> + if (!is_memblk_offline(info->start_addr, info->length))
>>> {
>>> + result = offline_memory(info->start_addr,
>>> info->length);
>>> + if (result)
>>> + return result;
>>> + }
>>> +
>>> + result = remove_memory(node, info->start_addr,
>>> info->length);
>>
>> The user may online the memory between offline_memory() and
>> remove_memory().
>> So I think we should lock memory hotplug before check the memory's status
>> and release it after remove_memory().
>
> How about get "mem_block->state_mutex" of removed memory? When offlining
> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
> In this case, we get mem_block->state_mutex. So I think the mutex lock
> is beneficial.
It is not good idea since remove_memory frees mem_block structure...
Do you have any ideas?
>>>
>>> Hmm, split offline_memory() to 2 functions: offline_pages() and
>>> __offline_pages()
>>>
>>> offline_pages()
>>> lock_memory_hotplug();
>>> __offline_pages();
>>> unlock_memory_hotplug();
>>>
>>> and implement remove_memory() like this:
>>> remove_memory()
>>> lock_memory_hotplug()
>>> if (!is_memblk_offline()) {
>>> __offline_pages();
>>> }
>>> // cleanup
>>> unlock_memory_hotplug();
>>>
>>> What about this?
>>
>> I also thought about it once. But a problem remains. Current offilne_pages()
>> cannot realize the memory has been removed by remove_memory(). So even if
>> protecting the race by lock_memory_hotplug(), offline_pages() can offline
>> the removed memory. offline_pages() should have the means to know the memory
>> was removed. But I don't have good idea.
>
> We can not online/offline part of memory block, so what about this?
It seems you do not understand my concern.
When memory_remove() and offline_pages() run to same memory simultaneously,
offline_pages runs to removed memory.
memory_remove() | offline_pages()
Re: [PATCH V2 1/6] mfd: tps6586x:use devm managed resources
On Tuesday 17 July 2012 01:31 AM, Mark Brown wrote: On Mon, Jul 16, 2012 at 12:21:45PM +0530, Laxman Dewangan wrote: - ret = request_threaded_irq(irq, NULL, tps6586x_irq, IRQF_ONESHOT, - "tps6586x", tps6586x); + ret = devm_request_threaded_irq(tps6586x->dev, irq, NULL, tps6586x_irq, + IRQF_ONESHOT, "tps6586x", tps6586x); Are you sure this is safe - what guarantees that we can't get an interrupt while tearing the device down? I think device_remove will get called before the managed resource get freed. So do we need to call disable_irq() in remove() to avoid any interrupts? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Commit 6016af "[media] v4l2: use __u32 rather than enums in ioctl() structs" breaks C++ users of V4L2
Le lundi 16 juillet 2012 23:40:01 Jason L Tibbitts III, vous avez écrit :
> I ran into problems compiling the program ZoneMinder on Fedora rawhide
> (currently using something around 3.5rc6) which do not appear with 3.4
> kernels. With help this was traced to commit
> 6016af82eafcb6e086a8f2a2197b46029a843d68, "[media] v4l2: use __u32
> rather than enums in ioctl() structs" which changed videodev2.h in a way
> which appears to be incompatible with C++.
>
> This results in code such as the following:
> enum v4l2_buf_type type = v4l2_data.fmt.type;
That code is dangerous, probably even more so in C++. If the running kernel
version is more recent than the kernel header version that userland was
compiled with, the field value could be outside the range of the enumeration.
> failing to compile with:
> zm_local_camera.cpp:1523:49: error: invalid conversion from '__u32
> {aka unsigned int}' to 'v4l2_buf_type' [-fpermissive]
> but only when compiled with the headers from a 3.5 kernel.
>
> I'm very far from a C++ expert. I talked with some people who do grok
> it and the issue comes down to restrictions on assignments of ints to
> enums
> and additionally that enums in C++ don't have defined size.
That cannot be true. Your C++ compiler must agree with the kernel's C compiler
on the size of enum. If they did not, V4L2 would not have ever worked from C++
code in previous kernel versions.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 82571EB: Detected Hardware Unit Hang
On Mon, Jul 16, 2012 at 9:08 AM, Henrique de Moraes Holschuh wrote: > On Mon, 16 Jul 2012, Ben Hutchings wrote: >> On Sun, 2012-07-15 at 10:35 -0300, Henrique de Moraes Holschuh wrote: >> > On Sun, 15 Jul 2012, Dave, Tushar N wrote: >> > > Somehow setting max payload to 256 from BIOS does not set this value for >> > > all devices. I believe this is a BIOS bug. >> > >> > And preferably, Linux should complain about it. Since we know it is going >> > to cause problems, and since we know it does happen, we should be raising a >> > ruckus about it in the kernel log (and probably fixing it to min(path) >> > while >> > at it)... >> > >> > Is this something that should be raised as a feature request with the >> > PCI/PCIe subsystem? >> >> The feature is there, but we ended up with: >> >> commit 5f39e6705faade2e89d119958a8c51b9b6e2c53c >> Author: Jon Mason >> Date: Mon Oct 3 09:50:20 2011 -0500 >> >> PCI: Disable MPS configuration by default >> >> But you are welcome to share use of the fixup_mpss_256() quirk. > > Meh. I'd be happy with a warning if MPSS decreases when walking up to > the tree root... i.e. a warning if any child has a MPSS larger than the > parent. You can add "pci=pcie_bus_safe" to the kernel params and it should resolve your issue. > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Tue, 2012-07-17 at 00:34 -0400, Steven Rostedt wrote: > On Tue, 2012-07-17 at 00:27 -0400, Steven Rostedt wrote: > > > Actually, I was mistaken. I forgot that we defined 'cpu_chill()' as > > msleep(1) on RT, which would keep a deadlock from happening. > > Perhaps cpu_chill() isn't a good name, as it doesn't really explain what > is happening. Perhaps one of the following? > > cpu_rest() > cpu_sleep() > cpu_deep_relax() > cpu_dream() > cpu_hypnotize() ( cpu_waste_truckloads_of_time();) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 82571EB: Detected Hardware Unit Hang
On Mon, Jul 16, 2012 at 8:47 AM, Ben Hutchings wrote: > On Sun, 2012-07-15 at 10:35 -0300, Henrique de Moraes Holschuh wrote: >> On Sun, 15 Jul 2012, Dave, Tushar N wrote: >> > Somehow setting max payload to 256 from BIOS does not set this value for >> > all devices. I believe this is a BIOS bug. >> >> And preferably, Linux should complain about it. Since we know it is going >> to cause problems, and since we know it does happen, we should be raising a >> ruckus about it in the kernel log (and probably fixing it to min(path) while >> at it)... >> >> Is this something that should be raised as a feature request with the >> PCI/PCIe subsystem? > > The feature is there, but we ended up with: > > commit 5f39e6705faade2e89d119958a8c51b9b6e2c53c > Author: Jon Mason > Date: Mon Oct 3 09:50:20 2011 -0500 > > PCI: Disable MPS configuration by default With the quirk, it should work now if pcie_bus_config is set to PCIE_BUS_SAFE. With that patch was pushed it was too late in the release to fix it and see if there were any other ones out there (or incur the wrath of Linus). If you are brave enough, you can enable it by default again and see if there are any other quirks out there. ;-) > But you are welcome to share use of the fixup_mpss_256() quirk. > > Ben. > > -- > Ben Hutchings, Staff Engineer, Solarflare > Not speaking for my employer; that's the marketing department's job. > They asked us to note that Solarflare product names are trademarked. > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Tue, 2012-07-17 at 00:27 -0400, Steven Rostedt wrote: > On Tue, 2012-07-17 at 06:18 +0200, Mike Galbraith wrote: > > > > > There's that too. But the issue I was talking about is with all trylock > > > loops. As holding an rt-mutex now disables migration, if a high priority > > > process preempts a task that holds the lock, and then the high prio task > > > starts spinning waiting for that lock to release, the lower priority > > > process will never get to run to release it. The cpu_chill() doesn't > > > help. > > > > Hrm. I better go make a testcase, this one definitely wants pounding > > through thick skull. > > Actually, I was mistaken. I forgot that we defined 'cpu_chill()' as > msleep(1) on RT, which would keep a deadlock from happening. Whew! There are no stars and moons on my pointy hat, just plain white cone, so you had me worried I was missing something critical there. > It doesn't explain the performance enhancement you get :-/ No, it doesn't. The only thing I can think of is that while folks are timed sleeping, they aren't preempting and interleaving IO as much, but I'm pulling that out of thin air. Timed sleep should be a lot longer than regular wakeup, so to my mind, there should be less interleave due to more thumb twiddling. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Rename CAP_EPOLLWAKEUP to CAL_BLOCK_SUSPEND
Rafael,
As discussed in
http://thread.gmane.org/gmane.linux.kernel/1249726/focus=1288990,
the capability introduced in 4d7e30d98939a0340022ccd49325a3d70f7e0238
to govern EPOLLWAKEUP seems misnamed: this capability is about governing
the ability to suspend the system, not using a particular API flag
(EPOLLWAKEUP). We should make the name of the capability more general
to encourage reuse in related cases. (Whether or not this capability
should also be used to govern the use of /sys/power/wake_lock is a
question that needs to be separately resolved.)
This patch renames the capability to CAP_BLOCK_SUSPEND. In order to ensure
that the old capability name doesn't make it out into the wild, could you
please apply and push up the tree to ensure that it is incorporated
for the 3.5 release.
Thanks,
Michael
Signed-off-by: Michael Kerrisk
---
fs/eventpoll.c |2 +-
include/linux/capability.h |6 +++---
include/linux/eventpoll.h |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 74598f6..1c8b556 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1710,7 +1710,7 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
goto error_tgt_fput;
/* Check if EPOLLWAKEUP is allowed */
- if ((epds.events & EPOLLWAKEUP) && !capable(CAP_EPOLLWAKEUP))
+ if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
epds.events &= ~EPOLLWAKEUP;
/*
diff --git a/include/linux/capability.h b/include/linux/capability.h
index 68d56ef..d10b7ed 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -360,11 +360,11 @@ struct cpu_vfs_cap_data {
#define CAP_WAKE_ALARM35
-/* Allow preventing system suspends while epoll events are pending */
+/* Allow preventing system suspends */
-#define CAP_EPOLLWAKEUP 36
+#define CAP_BLOCK_SUSPEND36
-#define CAP_LAST_CAP CAP_EPOLLWAKEUP
+#define CAP_LAST_CAP CAP_BLOCK_SUSPEND
#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
index 6f8be32..f4bb378 100644
--- a/include/linux/eventpoll.h
+++ b/include/linux/eventpoll.h
@@ -34,7 +34,7 @@
* re-allowed until epoll_wait is called again after consuming the wakeup
* event(s).
*
- * Requires CAP_EPOLLWAKEUP
+ * Requires CAP_BLOCK_SUSPEND
*/
#define EPOLLWAKEUP (1 << 29)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/6] mfd: tps6586x: cache register through regmap
On Tuesday 17 July 2012 01:33 AM, Mark Brown wrote: * PGP Signed by an unknown key On Mon, Jul 16, 2012 at 12:21:47PM +0530, Laxman Dewangan wrote: To cache the interrupt mask register, use the regmap RB_TREE cache-ing mechanism in place of implementing it locally. Reviewed-by: Mark Brown Can you use regmap-irq? Sure, I will convert it to regmap_irq and will send new patch after this series in linux-next. Thanks, Laxman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extcon: MAX77693: Add extcon-max77693 driver to support Maxim MAX77693 MUIC device
This patch support Maxim MAX77693 MUIC device by using EXTCON Subsystem to handle various external connector. The extcon-max77693 use regmap method for i2c communication and support irq domain instead of previous method of irq base. Signed-off-by: Chanwoo Choi Signed-off-by: Myungjoo Ham Signed-off-by: Kyungmin Park --- drivers/extcon/Kconfig | 10 + drivers/extcon/Makefile |1 + drivers/extcon/extcon-max77693.c | 779 ++ 3 files changed, 790 insertions(+), 0 deletions(-) create mode 100644 drivers/extcon/extcon-max77693.c diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index bb385ac..1671635 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -21,6 +21,16 @@ config EXTCON_GPIO Say Y here to enable GPIO based extcon support. Note that GPIO extcon supports single state per extcon instance. +config EXTCON_MAX77693 + tristate "MAX77693 EXTCON Support" + depends on MFD_MAX77693 + select IRQ_DOMAIN + select REGMAP_I2C + help + If you say yes here you get support for the MUIC device of + Maxim MAX77693 PMIC. The MAX77693 MUIC is a USB port accessory + detector and switch. + config EXTCON_MAX8997 tristate "MAX8997 EXTCON Support" depends on MFD_MAX8997 diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile index e932caa..88961b3 100644 --- a/drivers/extcon/Makefile +++ b/drivers/extcon/Makefile @@ -4,5 +4,6 @@ obj-$(CONFIG_EXTCON) += extcon_class.o obj-$(CONFIG_EXTCON_GPIO) += extcon_gpio.o +obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c new file mode 100644 index 000..920a609 --- /dev/null +++ b/drivers/extcon/extcon-max77693.c @@ -0,0 +1,779 @@ +/* + * extcon-max77693.c - MAX77693 extcon driver to support MAX77693 MUIC + * + * Copyright (C) 2012 Samsung Electrnoics + * Chanwoo Choi + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#defineDEV_NAME"max77693-muic" + +/* MAX77693 MUIC - STATUS1~3 Register */ +#define STATUS1_ADC_SHIFT (0) +#define STATUS1_ADCLOW_SHIFT (5) +#define STATUS1_ADCERR_SHIFT (6) +#define STATUS1_ADC1K_SHIFT(7) +#define STATUS1_ADC_MASK (0x1f << STATUS1_ADC_SHIFT) +#define STATUS1_ADCLOW_MASK(0x1 << STATUS1_ADCLOW_SHIFT) +#define STATUS1_ADCERR_MASK(0x1 << STATUS1_ADCERR_SHIFT) +#define STATUS1_ADC1K_MASK (0x1 << STATUS1_ADC1K_SHIFT) + +#define STATUS2_CHGTYP_SHIFT (0) +#define STATUS2_CHGDETRUN_SHIFT(3) +#define STATUS2_DCDTMR_SHIFT (4) +#define STATUS2_DXOVP_SHIFT(5) +#define STATUS2_VBVOLT_SHIFT (6) +#define STATUS2_VIDRM_SHIFT(7) +#define STATUS2_CHGTYP_MASK(0x7 << STATUS2_CHGTYP_SHIFT) +#define STATUS2_CHGDETRUN_MASK (0x1 << STATUS2_CHGDETRUN_SHIFT) +#define STATUS2_DCDTMR_MASK(0x1 << STATUS2_DCDTMR_SHIFT) +#define STATUS2_DXOVP_MASK (0x1 << STATUS2_DXOVP_SHIFT) +#define STATUS2_VBVOLT_MASK(0x1 << STATUS2_VBVOLT_SHIFT) +#define STATUS2_VIDRM_MASK (0x1 << STATUS2_VIDRM_SHIFT) + +#define STATUS3_OVP_SHIFT (2) +#define STATUS3_OVP_MASK (0x1 << STATUS3_OVP_SHIFT) + +/* MAX77693 CDETCTRL1~2 register */ +#define CDETCTRL1_CHGDETEN_SHIFT (0) +#define CDETCTRL1_CHGTYPMAN_SHIFT (1) +#define CDETCTRL1_DCDEN_SHIFT (2) +#define CDETCTRL1_DCD2SCT_SHIFT(3) +#define CDETCTRL1_CDDELAY_SHIFT(4) +#define CDETCTRL1_DCDCPL_SHIFT (5) +#define CDETCTRL1_CDPDET_SHIFT (7) +#define CDETCTRL1_CHGDETEN_MASK(0x1 << CDETCTRL1_CHGDETEN_SHIFT) +#define CDETCTRL1_CHGTYPMAN_MASK (0x1 << CDETCTRL1_CHGTYPMAN_SHIFT) +#define CDETCTRL1_DCDEN_MASK (0x1 << CDETCTRL1_DCDEN_SHIFT) +#define CDETCTRL1_DCD2SCT_MASK (0x1 << CDETCTRL1_DCD2SCT_SHIFT) +#define CDETCTRL1_CDDELAY_MASK (0x1 << CDETCTRL1_CDDELAY_SHIFT) +#define CDETCTRL1_DCDCPL_MASK (0x1 << CDETCTRL1_DCDCPL_SHIFT) +#define CDETCTRL1_CDPDET_MASK (0x1
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Tue, 2012-07-17 at 06:18 +0200, Mike Galbraith wrote: > > > There's that too. But the issue I was talking about is with all trylock > > loops. As holding an rt-mutex now disables migration, if a high priority > > process preempts a task that holds the lock, and then the high prio task > > starts spinning waiting for that lock to release, the lower priority > > process will never get to run to release it. The cpu_chill() doesn't > > help. > > Hrm. I better go make a testcase, this one definitely wants pounding > through thick skull. Actually, I was mistaken. I forgot that we defined 'cpu_chill()' as msleep(1) on RT, which would keep a deadlock from happening. It doesn't explain the performance enhancement you get :-/ -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] USB: ehci-s5p: Add vbus setup function to the s5p ehci glue layer
This patch retrieves and configures the vbus control gpio via
the device tree. The suspend/resume callbacks will be later
modified for vbus control.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Vivek Gautam
---
drivers/usb/host/ehci-s5p.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 37d84cf..9d8f1dd 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -64,6 +65,24 @@ static const struct hc_driver s5p_ehci_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
+static void s5p_setup_vbus_gpio(struct platform_device *pdev)
+{
+ int err;
+ int gpio;
+
+ if (!pdev->dev.of_node)
+ return;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node,
+ "samsung,vbus-gpio", 0);
+ if (!gpio_is_valid(gpio))
+ return;
+
+ err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
+ if (err)
+ dev_err(>dev, "can't request ehci vbus gpio %d", gpio);
+}
+
static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
static int __devinit s5p_ehci_probe(struct platform_device *pdev)
@@ -92,6 +111,8 @@ static int __devinit s5p_ehci_probe(struct platform_device
*pdev)
if (!pdev->dev.coherent_dma_mask)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ s5p_setup_vbus_gpio(pdev);
+
s5p_ehci = devm_kzalloc(>dev, sizeof(struct s5p_ehci_hcd),
GFP_KERNEL);
if (!s5p_ehci)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] USB: host: Add Device tree support for ohci-exynos & ehci-s5p
Reworked third patch; other two got applied to 'usb-next' branch. Changes from v3: 1) Change the function name from s5p_ehci_setup_gpio() to s5p_setup_vbus_gpio(). 2) Make s5p_setup_vbus_gpio() function to return void instead of int. 3) Return void in case of failures. Vivek Gautam (1): USB: ehci-s5p: Add vbus setup function to the s5p ehci glue layer drivers/usb/host/ehci-s5p.c | 21 + 1 files changed, 21 insertions(+), 0 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] ftrace: using pr_fmt for better printk output
On Mon, 2012-07-16 at 20:42 -0700, Joe Perches wrote: > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > [] > > @@ -13,6 +13,8 @@ > > * Copyright (C) 2004 William Lee Irwin III > > */ > > > > +#define pr_fmt(fmt) "ftrace: " fmt > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt Wouldn't a nicer patch be to move this into a header file and then remove all the defines throughout the kernel tree? Also, what is KBUILD_MODNAME defined as for non-modules? As ftrace is not a module. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Mon, 2012-07-16 at 13:03 -0400, Steven Rostedt wrote: > On Mon, 2012-07-16 at 18:36 +0200, Mike Galbraith wrote: > > > > > > Ouch, you just turned the rt_read_lock() into a spin lock. If a higher > > > > priority process preempted a lower priority process that holds the same > > > > lock, it will deadlock. > > > > > > Hm, how, it's doing cpu_chill()? > > > > 'course PI is toast, so *poof*. Since just enabling the lockdep bits > > seems to fix it up, maybe that's the patchlet to submit (less is more). > > There's that too. But the issue I was talking about is with all trylock > loops. As holding an rt-mutex now disables migration, if a high priority > process preempts a task that holds the lock, and then the high prio task > starts spinning waiting for that lock to release, the lower priority > process will never get to run to release it. The cpu_chill() doesn't > help. Hrm. I better go make a testcase, this one definitely wants pounding through thick skull. I think all of the chilling in patchlet is really ugly anyway, so would prefer to trash it all, just enable the lockdep bits. If it turns out we really do need to bounce off of counts, go get a bigger hammer when the need arises. For the nonce, the pre-installed hammer _seemed_ big enough for the job. What's a good way to beat living hell out of btrfs? I've never been into destructive fs testing, since they usually lived on my one and only disk. x3550 has two, and OS clone has already been sacrificed. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] mmc: block: Add write packing control
On Mon, Jul 16, 2012 at 8:16 AM, Chris Ball wrote: > Hi, > > On Sun, Jul 15 2012, Muthu Kumar wrote: >>> I've already replied to a later version of the patch, but just to get >>> this comment in at the appropriate point of the discussion as well: >>> >>> Even though it would result in a cleaner sysfs, I don't want to do >>> this now because it will break userspace scripts that are depending >>> on the current locations of these attributes. >> >> Maya is adding a new sysfs attribute with that patch. So, there should >> not be any user space stuff that depends on it. > > In the later patchset, Maya's "[PATCH v4 1/2] mmc: card: Move MMC > specific attributes to mmc sub-directory" moves the existing attributes > into the mmc/ directory. > > It's that move that I'm objecting to, rather than the creation of a new > directory -- although since we're going to leave the current attributes > where they are, it might not make sense to add the new directory. > > We'd be creating two places that people have to look for mmc-related > attributes, which is arguably less clean than having one place to look > even though it's mixed in with the other block device attributes. > It's better to normalise this eventually. It would be better if we create a duplicate sysfs entry within MMC, which is identical to the current block layer attribute. Then schedule the block layer attribute to be removed by, say, 3.9. [Add it to Documentation/feature-removal-schedule.txt] Since it is a MMC specific attribute, generic tools wouldn't depend on it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/15] Drivers: hv: Add KVP definitions for IP address injection
On Sat, Jul 14, K. Y. Srinivasan wrote:
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 68ed7f7..38b561a 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -127,6 +127,8 @@ enum hv_kvp_exchg_op {
> KVP_OP_SET,
> KVP_OP_DELETE,
> KVP_OP_ENUMERATE,
> + KVP_OP_GET_IP_INFO,
> + KVP_OP_SET_IP_INFO,
> KVP_OP_REGISTER,
> KVP_OP_COUNT /* Number of operations, must be last. */
> };
I think this will break the kernel/daemon API for existing binaries.
Perhaps a forward/backwards compatible API where an older binary
continues to work with a newer kernel should be added.
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/13] USB:support the new interfaces of Huawei Data Card devices in option driver
Dear bjorn:
"Fangxiaozhi (Franko)" writes:
> From: fangxiaozhi
> 1. This patch is based on the kernel of 3.5-rc6
> 2. In this patch, we add new micro for matching the series USB devices with
> vendor ID and interface information.
> 3. In this patch, we add new declarations into option.c to support the new
> interfaces of Huawei Data Card devices.
> Signed-off-by: fangxiaozhi
> ---
> --- ../test/linux-3.5-rc6/include/linux/usb.h 2012-07-08 08:23:56.0
> +0800
> +++ include/linux/usb.h 2012-07-13 17:45:59.0 +0800
> @@ -828,6 +828,27 @@ static inline int usb_make_path(struct u
> .bInterfaceClass = (cl), \
> .bInterfaceSubClass = (sc), \
> .bInterfaceProtocol = (pr)
> +/**
> + * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a
> class of usb interfaces, but independent of product ID
This chunk seems like a copy of the patch Gustavo Padovan just
submitted? Should really be listed as a precondition instead of
included here, should it not?
-In your opinions, it is better to declare this defining in the option.c
file, but not usb.h file, right?
> --- ../test/linux-3.5-rc6/drivers/usb/serial/option.c 2012-07-13
> 14:22:52.0 +0800
> +++ drivers/usb/serial/option.c 2012-07-13 17:38:38.0 +0800
> @@ -572,6 +572,115 @@ static const struct option_blacklist_inf
> };
>
> static const struct usb_device_id option_ids[] = {
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x01) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x02) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x03) },
I guess this means that the device specific entries matching this could
and should be removed, does it not? All these seem redundant with your
patch:
--The new matching rule is independent of the special product ID, so it can
support a series products of Huawei Data Card.
-The following matching rule is only for the specific product, and it is
covered by the new matching rule, so I think that we can remove the following
matching sentences.
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x33) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770,
0xff, 0x02, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770,
0xff, 0x02, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771,
0xff, 0x02, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771,
0xff, 0x02, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x02) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x03) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x10) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x12) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x13) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x01) }, /* E398 3G Modem */
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x02) }, /* E398 3G PC UI Interface */
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x03) }, /* E398 3G Application Interface */
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x04) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x05) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x06) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0A) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0B) },
> + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0D) },
> + {
[PATCH 2/2] staging: rts5139: rts51x_card: fixed brace coding style issue
Fixed a coding style issue. An else statement was
not on the same line as the preceding if statement's
closing brace.
Signed-off-by: Erik Jones
---
drivers/staging/rts5139/rts51x_card.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rts5139/rts51x_card.c
b/drivers/staging/rts5139/rts51x_card.c
index a3cb559..50be42a 100644
--- a/drivers/staging/rts5139/rts51x_card.c
+++ b/drivers/staging/rts5139/rts51x_card.c
@@ -826,8 +826,7 @@ int card_power_on(struct rts51x_chip *chip, u8 card)
if ((card == SD_CARD) || (card == XD_CARD)) {
RTS51X_WRITE_REG(chip, CARD_PWR_CTL, mask | LDO3318_PWR_MASK,
val1 | LDO_SUSPEND);
- }
- else {
+ } else {
#endif
RTS51X_WRITE_REG(chip, CARD_PWR_CTL, mask, val1);
#ifdef SD_XD_IO_FOLLOW_PWR
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: rts5139: rts51x_card: fixed brace coding style issue
Fixed a coding style issue.
Signed-off-by: Erik Jones
---
drivers/staging/rts5139/rts51x_card.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rts5139/rts51x_card.c
b/drivers/staging/rts5139/rts51x_card.c
index 4192c3b..a3cb559 100644
--- a/drivers/staging/rts5139/rts51x_card.c
+++ b/drivers/staging/rts5139/rts51x_card.c
@@ -211,13 +211,12 @@ static void card_cd_debounce(struct rts51x_chip *chip, u8
*need_reset,
release_map |= MS_CARD;
}
} else {
- if (chip->card_status & XD_CD) {
+ if (chip->card_status & XD_CD)
reset_map |= XD_CARD;
- } else if (chip->card_status & SD_CD) {
+ else if (chip->card_status & SD_CD)
reset_map |= SD_CARD;
- } else if (chip->card_status & MS_CD) {
+ else if (chip->card_status & MS_CD)
reset_map |= MS_CARD;
- }
}
if (CHECK_PKG(chip, QFN24) && reset_map) {
--
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/
[RESEND PATCH 0] staging: rts5139: rts51x_card: coding style fix
I am resending this patch-set because the initial version's subject didn't include [PATCH 0]. This patch-set fixes coding style issues in rts51x_card driver. Issues were found with scripts/checkpatch.pl tool. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/tty/tty_ioctl.c: In function 'set_sgflags':
drivers/tty/tty_ioctl.c:741:9: error: request for member 'c_iflag' in something
not a structure or union
drivers/tty/tty_ioctl.c:742:9: error: request for member 'c_oflag' in something
not a structure or union
drivers/tty/tty_ioctl.c:743:9: error: request for member 'c_lflag' in something
not a structure or union
drivers/tty/tty_ioctl.c:745:10: error: request for member 'c_iflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:746:10: error: request for member 'c_lflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:749:10: error: request for member 'c_lflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:753:10: error: request for member 'c_oflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:756:10: error: request for member 'c_iflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:757:10: error: request for member 'c_lflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:759:15: error: request for member 'c_lflag' in
something not a structure or union
drivers/tty/tty_ioctl.c:760:10: error: request for member 'c_cc' in something
not a structure or union
drivers/tty/tty_ioctl.c:761:10: error: request for member 'c_cc' in something
not a structure or union
Caused by commit adc8d746caa6 ("tty: move the termios object into the
tty"). Did anyone build test this? :-(
I have used the tty tree from next-20120712 again for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpY6lJ3X1WnY.pgp
Description: PGP signature
Re: [PATCH] ftrace: using pr_fmt for better printk output
On Tue, 2012-07-17 at 09:15 +0800, Jovi Zhang wrote:
> >From fe42b2f29e5968482b3129c71f81a58a0559cf04 Mon Sep 17 00:00:00 2001
[]
> There don't have subsystem name output in front ot ftrace related log entry,
> so use pr_fmt to enable better printk output, for output subsystem name in
> log entry.
Hi Jovi. A few things:
Your patch has 80 column wrapping issues and doesn't
apply cleanly.
This sort of patch, because it's trivial and not really
important to apply this close to an actual release, should
be done against linux-next not current mainline.
The #define pr_fmt(fmt) should probably use KBUILD_MODNAME.
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Please coalesce formats even though they then may exceed
80 columns and compress multiple lines that fit in 80 too.
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
[]
> @@ -13,6 +13,8 @@
> * Copyright (C) 2004 William Lee Irwin III
> */
>
> +#define pr_fmt(fmt) "ftrace: " fmt
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
[]
> @@ -2187,12 +2189,12 @@ static int __init
> ftrace_dyn_table_alloc(unsigned long num_to_init)
wrapped
> int cnt;
>
> if (!num_to_init) {
> - pr_info("ftrace: No functions to be traced?\n");
> + pr_info("No functions to be traced?\n");
> return -1;
> }
>
> cnt = num_to_init / ENTRIES_PER_PAGE;
> - pr_info("ftrace: allocating %ld entries in %d pages\n",
> + pr_info("allocating %ld entries in %d pages\n",
> num_to_init, cnt + 1);
Single line:
pr_info("allocating %ld entries in %d pages\n", num_to_init, cnt + 1);
> @@ -4495,7 +4497,7 @@ static int start_graph_tracing(void)
> if (!ret) {
> ret =
> register_trace_sched_switch(ftrace_graph_probe_sched_switch, NULL);
> if (ret)
> - pr_info("ftrace_graph: Couldn't activate tracepoint"
> + pr_info("Couldn't activate tracepoint"
> " probe to kernel_sched_switch\n");
Coalesce format:
pr_info("Couldn't activate tracepoint probe to
kernel_sched_switch\n");
etc...
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: staging: rts5139: rts51x_card: coding style fix
On 07/16/2012 10:52 PM, Erik Jones wrote: This patch-set fixes coding style issues in rts51x_card driver. Issues were found with scripts/checkpatch.pl tool. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Resubmitting with a [PATCH 0] in initial Reply-to message's subject. Please ignore this patch-set. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] xfs: fix comment typo of struct xfs_da_blkinfo.
Hi Ben, On Jul 16, 2012, at 11:10 PM, Ben Myers wrote: > Hey Chen, > > On Sat, Jul 14, 2012 at 03:38:13AM +0800, Chen Baozi wrote: >> Fix trivial typo error that has written "It" to "Is". >> >> Signed-off-by: Chen Baozi > > Reviewed-by: Ben Myers > > Thanks for the patch! I'm happy you're working on XFS. Do you have any > time/interest in taking on a work item or two? I have a few would-be-nices > which I've made notes of, and I'm sure that Dave or Christoph could also think > of a few if you're interested. I'd really love to. Right now, I am working on syslinux to support booting on xfs partition (under pcacjr's mentoring)， which I thought would be a nice start to get familiar with xfs (and I did learn a lot from it). So I think there would be more time (and experience on xfs) after I finish the xfs support on syslinux. And I'm really looking forward to your ideas. So do please tell me what I can help, I'll try my best to do it. Thanks a lot. Baozi > > Thanks again, > -Ben > >> --- >> fs/xfs/xfs_da_btree.h |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/fs/xfs/xfs_da_btree.h b/fs/xfs/xfs_da_btree.h >> index dbf7c07..be30bd4 100644 >> --- a/fs/xfs/xfs_da_btree.h >> +++ b/fs/xfs/xfs_da_btree.h >> @@ -32,7 +32,7 @@ struct zone; >> /* >> * This structure is common to both leaf nodes and non-leaf nodes in the >> Btree. >> * >> - * Is is used to manage a doubly linked list of all blocks at the same >> + * It is used to manage a doubly linked list of all blocks at the same >> * level in the Btree, and to identify which type of block this is. >> */ >> #define XFS_DA_NODE_MAGIC0xfebe /* magic number: non-leaf blocks */ >> -- >> 1.7.1 >> >> ___ >> xfs mailing list >> x...@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFT] regulator: palmas: Fix calcuating selector in palmas_map_voltage_smps
The logic of calculating selector in palmas_map_voltage_smps() does not match
the logic to list voltage in palmas_list_voltage_smps().
We use below equation to calculate voltage when selector > 0:
voltage = (0.49V + (selector * 0.01V)) * RANGE
RANGE is either x1 or x2
So we need to take into account with the multiplier set in VSEL register when
calculating selector in palmas_map_voltage_smps()
Signed-off-by: Axel Lin
---
drivers/regulator/palmas-regulator.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 7540c95..17d19fb 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -373,11 +373,22 @@ static int palmas_set_voltage_smps_sel(struct
regulator_dev *dev,
static int palmas_map_voltage_smps(struct regulator_dev *rdev,
int min_uV, int max_uV)
{
+ struct palmas_pmic *pmic = rdev_get_drvdata(rdev);
+ int id = rdev_get_id(rdev);
int ret, voltage;
- ret = ((min_uV - 50) / 1) + 1;
- if (ret < 0)
- return ret;
+ if (min_uV == 0)
+ return 0;
+
+ if (pmic->range[id]) { /* RANGE is x2 */
+ if (min_uV < 100)
+ min_uV = 100;
+ ret = DIV_ROUND_UP(min_uV - 100, 2) + 1;
+ } else {/* RANGE is x1 */
+ if (min_uV < 50)
+ min_uV = 50;
+ ret = DIV_ROUND_UP(min_uV - 50, 1) + 1;
+ }
/* Map back into a voltage to verify we're still in bounds */
voltage = palmas_list_voltage_smps(rdev, ret);
--
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: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
At 07/17/2012 11:08 AM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/07/17 11:32, Wen Congyang wrote:
>> At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
>>> Hi Wen,
>>>
>>> 2012/07/17 10:44, Yasuaki Ishimatsu wrote:
Hi Wen,
2012/07/13 12:35, Wen Congyang wrote:
> At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
>> acpi_memory_device_remove() has been prepared to remove physical memory.
>> But, the function only frees acpi_memory_device currentlry.
>>
>> The patch adds following functions into acpi_memory_device_remove():
>> - offline memory
>> - remove physical memory (only return -EBUSY)
>> - free acpi_memory_device
>>
>> CC: David Rientjes
>> CC: Jiang Liu
>> CC: Len Brown
>> CC: Benjamin Herrenschmidt
>> CC: Paul Mackerras
>> CC: Christoph Lameter
>> Cc: Minchan Kim
>> CC: Andrew Morton
>> CC: KOSAKI Motohiro
>> CC: Wen Congyang
>> Signed-off-by: Yasuaki Ishimatsu
>>
>> ---
>> drivers/acpi/acpi_memhotplug.c | 26 +-
>> drivers/base/memory.c | 39
>> +++
>> include/linux/memory.h |5 +
>> include/linux/memory_hotplug.h |1 +
>> mm/memory_hotplug.c|8
>> 5 files changed, 78 insertions(+), 1 deletion(-)
>>
>> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
>> ===
>> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c2012-07-09
>> 18:08:29.946888653 +0900
>> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
>> 18:08:43.470719531 +0900
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
>> static int acpi_memory_device_remove(struct acpi_device *device, int
>> type)
>> {
>> struct acpi_memory_device *mem_device = NULL;
>> -
>> +struct acpi_memory_info *info, *tmp;
>> +int result;
>> +int node;
>>
>> if (!device || !acpi_driver_data(device))
>> return -EINVAL;
>>
>> mem_device = acpi_driver_data(device);
>> +
>> +node = acpi_get_node(mem_device->device->handle);
>> +
>> +list_for_each_entry_safe(info, tmp, _device->res_list,
>> list) {
>> +if (!info->enabled)
>> +continue;
>> +
>> +if (!is_memblk_offline(info->start_addr, info->length))
>> {
>> +result = offline_memory(info->start_addr,
>> info->length);
>> +if (result)
>> +return result;
>> +}
>> +
>> +result = remove_memory(node, info->start_addr,
>> info->length);
>
> The user may online the memory between offline_memory() and
> remove_memory().
> So I think we should lock memory hotplug before check the memory's status
> and release it after remove_memory().
How about get "mem_block->state_mutex" of removed memory? When offlining
memory, we need to change "memory_block->state" into "MEM_OFFLINE".
In this case, we get mem_block->state_mutex. So I think the mutex lock
is beneficial.
>>>
>>> It is not good idea since remove_memory frees mem_block structure...
>>> Do you have any ideas?
>>
>> Hmm, split offline_memory() to 2 functions: offline_pages() and
>> __offline_pages()
>>
>> offline_pages()
>> lock_memory_hotplug();
>> __offline_pages();
>> unlock_memory_hotplug();
>>
>> and implement remove_memory() like this:
>> remove_memory()
>> lock_memory_hotplug()
>> if (!is_memblk_offline()) {
>> __offline_pages();
>> }
>> // cleanup
>> unlock_memory_hotplug();
>>
>> What about this?
>
> I also thought about it once. But a problem remains. Current offilne_pages()
> cannot realize the memory has been removed by remove_memory(). So even if
> protecting the race by lock_memory_hotplug(), offline_pages() can offline
> the removed memory. offline_pages() should have the means to know the memory
> was removed. But I don't have good idea.
We can not online/offline part of memory block, so what about this?
remove_memory()
lock_memory_hotplug()
for each memory block:
if (!is_memblk_offline()) {
__offline_pages();
}
// cleanup
unlock_memory_hotplug();
Thanks
Wen Congyang
>
> Thanks,
> Yasuaki Ishimatsu
>
>>
>> Thanks
>> Wen Congyang
>>>
>>> Thanks,
>>> Yasuaki Ishimatsu
>>>
Thanks,
Yasuaki Ishimatsu
Re: [PATCH] x86: revert "x86: Fix S4 regression"
Hi Cong,
When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump
kernel's panic in find_early_table_space().
init_memory_mapping: [mem 0x-0x36ffafff]
Kernel panic - not syncing: Cannot find space for the kernel page tables
Pid: 0, comm: swapper Not tainted 3.5.0-rc6 #17
Call Trace:
[] panic+0xb8/0x1c8
[] ? printk+0x48/0x4a
[] init_memory_mapping+0x46c/0x530
[] setup_arch+0x669/0xb0e
[] ? printk+0x48/0x4a
[] start_kernel+0x9b/0x34a
[] x86_64_start_reservations+0x131/0x136
[] x86_64_start_kernel+0xed/0xf4
In find_early_table_space(), a kernel tries to find free area below 512M
for pgtable using memblock_find_in_range, but it fails because kdump
kernel does not have enough free space below 512M due to the memmap
restriction. This is the memmap option specified against kdump kernel
when crashkernel=128M.
memmap=560K@64K memmap=130492K@770608K
Only 560KB area is available and it is not sufficient for pgtable (it
seems that about 1.8MB area is needed for pgtable). This problem is
fixed by your revert patch. I hope this patch gets merged.
Thanks,
Takao Indoh
(2012/06/12 14:21), Cong Wang wrote:
> From: Cong Wang
>
> This reverts the following commit:
>
> commit 8548c84da2f47e71bbbe300f55edb768492575f7
> Author: Takashi Iwai
> Date: Sun Oct 23 23:19:12 2011 +0200
>
> x86: Fix S4 regression
>
> Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a
> S4
> regression since 2.6.39, namely the machine reboots occasionally at
> S4
> resume. It doesn't happen always, overall rate is about 1/20. But,
> like other bugs, once when this happens, it continues to happen.
>
> This patch fixes the problem by essentially reverting the memory
> assignment in the older way.
>
> According to the previous discussion:
> http://marc.info/?l=linux-kernel=133161674120253=2
> it seems that so far the best solution is just reverting it.
>
> Takashi, could you help to test if the S4 regression is still
> there after this patch?
>
> Reported-by: CAI Qian
> Cc: Dave Young
> Cc: "H. Peter Anvin"
> Cc: Rafael J. Wysocki
> Cc: Yinghai Lu
> Cc: Takashi Iwai
> Signed-off-by: Cong Wang
>
> ---
> arch/x86/mm/init.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index bc4e9d8..7ab7975 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -74,8 +74,9 @@ static void __init find_early_table_space(struct map_range
> *mr, unsigned long en
> #ifdef CONFIG_X86_32
> /* for fixmap */
> tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE);
> -#endif
> +
> good_end = max_pfn_mapped << PAGE_SHIFT;
> +#endif
>
> base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE);
> if (!base)
>
[0.00] Linux version 3.5.0-rc6 (root@localhost) (gcc version 4.4.6
20120305 (Red Hat 4.4.6-4) (GCC) ) #17 SMP Thu Jul 12 13:49:46 JST 2012
[0.00] Command line: ro root=UUID=1893a13e-19af-439b-9d39-0a42260f3eaa
rd_NO_LUKS rd_NO_MD KEYBOARDTYPE=pc KEYTABLE=jp106 LANG=ja_JP.UTF-8 rd_NO_LVM
rd_NO_DM loglevel=7 earlyprintk=serial,ttyS0,19200n8 irqpoll nr_cpus=1
reset_devices cgroup_disable=memory mce=off memmap=exactmap memmap=560K@64K
memmap=130492K@770608K elfcorehdr=901100K memmap=64K$0K memmap=16K$624K
memmap=112K$912K memmap=32832K$3103360K memmap=40K#3136192K memmap=4K#3136232K
memmap=9492K$3136236K memmap=262144K$3670016K memmap=1024K$4173824K
memmap=4K$4175872K memmap=17408K$4176896K
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x0100-0x0009bfff] usable
[0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbd69] usable
[0.00] BIOS-e820: [mem 0xbd6a-0xbf6a] reserved
[0.00] BIOS-e820: [mem 0xbf6b-0xbf6b9fff] ACPI data
[0.00] BIOS-e820: [mem 0xbf6ba000-0xbf6bafff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbf6bb000-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfecf] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffa0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00043fff] usable
[0.00] bootconsole [earlyser0] enabled
[0.00] e820: last_pfn = 0x44 max_arch_pfn = 0x4
[0.00] NX (Execute Disable) protection: active
[0.00] e820: user-defined physical RAM map:
[0.00] user: [mem 0x-0x] reserved
[
Re: [patch RT 1/3] cpu/rt: Rework cpu down for PREEMPT_RT
On Mon, 2012-07-16 at 08:07 +, Thomas Gleixner wrote:
I know you are on vacation (hope you are enjoying yourself ;-)
> ---
> include/linux/sched.h |7 ++
> kernel/cpu.c | 236
> +
> kernel/sched/core.c | 82 +-
> 3 files changed, 285 insertions(+), 40 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 7fc8321..777f7bb 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1973,6 +1973,10 @@ extern void do_set_cpus_allowed(struct task_struct *p,
>
> extern int set_cpus_allowed_ptr(struct task_struct *p,
> const struct cpumask *new_mask);
> +int migrate_me(void);
> +void tell_sched_cpu_down_begin(int cpu);
> +void tell_sched_cpu_down_done(int cpu);
> +
> #else
> static inline void do_set_cpus_allowed(struct task_struct *p,
> const struct cpumask *new_mask)
> @@ -1985,6 +1989,9 @@ static inline int set_cpus_allowed_ptr(struct
> task_struct *p,
> return -EINVAL;
> return 0;
> }
> +static inline int migrate_me(void) { return 0; }
> +static inline void tell_sched_cpu_down_begin(int cpu) { }
> +static inline void tell_sched_cpu_down_done(int cpu) { }
> #endif
>
> #ifndef CONFIG_CPUMASK_OFFSTACK
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index d79d33a..c5b3273 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -46,12 +46,7 @@ static int cpu_hotplug_disabled;
>
> static struct {
> struct task_struct *active_writer;
> -#ifdef CONFIG_PREEMPT_RT_FULL
> - /* Makes the lock keep the task's state */
> - spinlock_t lock;
> -#else
> struct mutex lock; /* Synchronizes accesses to refcount, */
> -#endif
> /*
>* Also blocks the new readers during
>* an ongoing cpu hotplug operation.
> @@ -67,20 +62,42 @@ static struct {
As I was backporting this to 3.0-rt, I noticed that the following is
needed too:
diff --git a/kernel/cpu.c b/kernel/cpu.c
index c5b3273..3e722c0 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -54,11 +54,7 @@ static struct {
int refcount;
} cpu_hotplug = {
.active_writer = NULL,
-#ifdef CONFIG_PREEMPT_RT_FULL
- .lock = __SPIN_LOCK_UNLOCKED(cpu_hotplug.lock),
-#else
.lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
-#endif
.refcount = 0,
};
As this goes with part of the applied patch above.
I'll add this on top, if no one objects.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
(2012/07/17 12:05), Steven Rostedt wrote: > On Tue, 2012-07-17 at 11:08 +0900, Masami Hiramatsu wrote: > >>> I found that regs_get_register() doesn't honor this either. Thus, >>> kprobes in tracing gets this: >>> >>> # echo 'p:ftrace sys_read+4 s=%sp' > /debug/tracing/kprobe_events >>> # echo 1 > /debug/tracing/events/kprobes/enable >>> # cat trace >>> sshd-1345 [000] d... 489.117168: ftrace: (sys_read+0x4/0x70) >>> s=b7e96768 >>> sshd-1345 [000] d... 489.117191: ftrace: (sys_read+0x4/0x70) >>> s=b7e96768 >>> cat-1447 [000] d... 489.117392: ftrace: (sys_read+0x4/0x70) >>> s=5a7 >>> cat-1447 [001] d... 489.118023: ftrace: (sys_read+0x4/0x70) >>> s=b77ad05f >>> less-1448 [000] d... 489.118079: ftrace: (sys_read+0x4/0x70) >>> s=b7762e06 >>> less-1448 [000] d... 489.118117: ftrace: (sys_read+0x4/0x70) >>> s=b7764970 >>> >> >> Yes, that is by design, since I made it so. :) >> Instead of %sp, kprobe tracer provides $stack special argument >> for stack address, because "sp" is not always means the stack >> address on every arch. > > But is that useful? Wouldn't the actual stack pointer be more > informative? It is just FYI :). I rather like your "%sp" enhancement than current meaningless "%sp" on i386... However, I think "$stack" is more general and informative for users, thus, at least perf probe uses it for getting variables from stack. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
Hi Wen,
2012/07/17 11:32, Wen Congyang wrote:
> At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
>> Hi Wen,
>>
>> 2012/07/17 10:44, Yasuaki Ishimatsu wrote:
>>> Hi Wen,
>>>
>>> 2012/07/13 12:35, Wen Congyang wrote:
At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
> acpi_memory_device_remove() has been prepared to remove physical memory.
> But, the function only frees acpi_memory_device currentlry.
>
> The patch adds following functions into acpi_memory_device_remove():
> - offline memory
> - remove physical memory (only return -EBUSY)
> - free acpi_memory_device
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/acpi/acpi_memhotplug.c | 26 +-
> drivers/base/memory.c | 39
> +++
> include/linux/memory.h |5 +
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c|8
> 5 files changed, 78 insertions(+), 1 deletion(-)
>
> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
> ===
> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:29.946888653 +0900
> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:43.470719531 +0900
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
> static int acpi_memory_device_remove(struct acpi_device *device, int
> type)
> {
> struct acpi_memory_device *mem_device = NULL;
> -
> + struct acpi_memory_info *info, *tmp;
> + int result;
> + int node;
>
> if (!device || !acpi_driver_data(device))
> return -EINVAL;
>
> mem_device = acpi_driver_data(device);
> +
> + node = acpi_get_node(mem_device->device->handle);
> +
> + list_for_each_entry_safe(info, tmp, _device->res_list, list) {
> + if (!info->enabled)
> + continue;
> +
> + if (!is_memblk_offline(info->start_addr, info->length)) {
> + result = offline_memory(info->start_addr, info->length);
> + if (result)
> + return result;
> + }
> +
> + result = remove_memory(node, info->start_addr, info->length);
The user may online the memory between offline_memory() and
remove_memory().
So I think we should lock memory hotplug before check the memory's status
and release it after remove_memory().
>>>
>>> How about get "mem_block->state_mutex" of removed memory? When offlining
>>> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
>>> In this case, we get mem_block->state_mutex. So I think the mutex lock
>>> is beneficial.
>>
>> It is not good idea since remove_memory frees mem_block structure...
>> Do you have any ideas?
>
> Hmm, split offline_memory() to 2 functions: offline_pages() and
> __offline_pages()
>
> offline_pages()
> lock_memory_hotplug();
> __offline_pages();
> unlock_memory_hotplug();
>
> and implement remove_memory() like this:
> remove_memory()
> lock_memory_hotplug()
> if (!is_memblk_offline()) {
> __offline_pages();
> }
> // cleanup
> unlock_memory_hotplug();
>
> What about this?
I also thought about it once. But a problem remains. Current offilne_pages()
cannot realize the memory has been removed by remove_memory(). So even if
protecting the race by lock_memory_hotplug(), offline_pages() can offline
the removed memory. offline_pages() should have the means to know the memory
was removed. But I don't have good idea.
Thanks,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>>
>> Thanks,
>> Yasuaki Ishimatsu
>>
>>> Thanks,
>>> Yasuaki Ishimatsu
>>>
Thanks
Wen Congyang
> + if (result)
> + return result;
> +
> + list_del(>list);
> + kfree(info);
> + }
> +
> kfree(mem_device);
>
> return 0;
> Index: linux-3.5-rc6/include/linux/memory_hotplug.h
> ===
> --- linux-3.5-rc6.orig/include/linux/memory_hotplug.h 2012-07-09
> 18:08:29.955888542 +0900
> +++ linux-3.5-rc6/include/linux/memory_hotplug.h 2012-07-09
> 18:08:43.471719518 +0900
> @@ -233,6 +233,7
[PATCH 2/2] staging: rts5139: rts51x_card: fixed brace coding style issue
Fixed a coding style issue. An else statement was
not on the same line as the preceding if statement's
closing brace.
Signed-off-by: Erik Jones
---
drivers/staging/rts5139/rts51x_card.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rts5139/rts51x_card.c
b/drivers/staging/rts5139/rts51x_card.c
index a3cb559..50be42a 100644
--- a/drivers/staging/rts5139/rts51x_card.c
+++ b/drivers/staging/rts5139/rts51x_card.c
@@ -826,8 +826,7 @@ int card_power_on(struct rts51x_chip *chip, u8 card)
if ((card == SD_CARD) || (card == XD_CARD)) {
RTS51X_WRITE_REG(chip, CARD_PWR_CTL, mask | LDO3318_PWR_MASK,
val1 | LDO_SUSPEND);
- }
- else {
+ } else {
#endif
RTS51X_WRITE_REG(chip, CARD_PWR_CTL, mask, val1);
#ifdef SD_XD_IO_FOLLOW_PWR
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: rts5139: rts51x_card: fixed brace coding style issue
Fixed a coding style issue.
Signed-off-by: Erik Jones
---
drivers/staging/rts5139/rts51x_card.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rts5139/rts51x_card.c
b/drivers/staging/rts5139/rts51x_card.c
index 4192c3b..a3cb559 100644
--- a/drivers/staging/rts5139/rts51x_card.c
+++ b/drivers/staging/rts5139/rts51x_card.c
@@ -211,13 +211,12 @@ static void card_cd_debounce(struct rts51x_chip *chip, u8
*need_reset,
release_map |= MS_CARD;
}
} else {
- if (chip->card_status & XD_CD) {
+ if (chip->card_status & XD_CD)
reset_map |= XD_CARD;
- } else if (chip->card_status & SD_CD) {
+ else if (chip->card_status & SD_CD)
reset_map |= SD_CARD;
- } else if (chip->card_status & MS_CD) {
+ else if (chip->card_status & MS_CD)
reset_map |= MS_CARD;
- }
}
if (CHECK_PKG(chip, QFN24) && reset_map) {
--
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/
staging: rts5139: rts51x_card: coding style fix
This patch-set fixes coding style issues in rts51x_card driver. Issues were found with scripts/checkpatch.pl tool. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
On Tue, 2012-07-17 at 11:08 +0900, Masami Hiramatsu wrote: > > I found that regs_get_register() doesn't honor this either. Thus, > > kprobes in tracing gets this: > > > > # echo 'p:ftrace sys_read+4 s=%sp' > /debug/tracing/kprobe_events > > # echo 1 > /debug/tracing/events/kprobes/enable > > # cat trace > > sshd-1345 [000] d... 489.117168: ftrace: (sys_read+0x4/0x70) > > s=b7e96768 > > sshd-1345 [000] d... 489.117191: ftrace: (sys_read+0x4/0x70) > > s=b7e96768 > > cat-1447 [000] d... 489.117392: ftrace: (sys_read+0x4/0x70) > > s=5a7 > > cat-1447 [001] d... 489.118023: ftrace: (sys_read+0x4/0x70) > > s=b77ad05f > > less-1448 [000] d... 489.118079: ftrace: (sys_read+0x4/0x70) > > s=b7762e06 > > less-1448 [000] d... 489.118117: ftrace: (sys_read+0x4/0x70) > > s=b7764970 > > > > Yes, that is by design, since I made it so. :) > Instead of %sp, kprobe tracer provides $stack special argument > for stack address, because "sp" is not always means the stack > address on every arch. But is that useful? Wouldn't the actual stack pointer be more informative? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] sched: dynamically schedule domain configuration
Add the missing cc list.
On 07/16/2012 05:16 PM, Michael Wang wrote:
> From: Michael Wang
>
> This patch is trying to provide a way for user to dynamically change
> the behaviour of load balance by setting flags of schedule domain.
>
> Currently it's rely on cpu cgroup and only SD_LOAD_BALANCE was
> implemented, usage:
>
> 1. /sys/fs/cgroup/domain/domain.config_level
> the default config_level is 0, which means we currenlty configure
> the sibling domain for all cpus, we can use:
> echo 'number' > /sys/fs/cgroup/domain/domain.config_level
> to change the level.
>
> 2. /sys/fs/cgroup/domain/domain.topology
> this will help to show the SD_LOAD_BALANCE status of all the cpu's
> all domain level, we can use:
> cat /sys/fs/cgroup/domain/domain.topology
>
> 3. /sys/fs/cgroup/domain/domain.SD_LOAD_BALANCE
> this will help us to change the bit SD_LOAD_BALANCE in the flag of
> schedule domain on level 'config_level', we can use:
> echo 1 > /sys/fs/cgroup/domain/domain.SD_LOAD_BALANCE
> to enable this bit, and:
> echo 0 > /sys/fs/cgroup/domain/domain.SD_LOAD_BALANCE
> to disable it.
>
> It may not works well now(may be even not work at all as I can't see any
> changes on my server even after disabled SD_LOAD_BALANCE on all domains),
> but it is interesting and should be liked by some people who desire a
> way to 'kill' the load balance by their own hands if we can implement it.
>
> Comments and questions are very welcomed ;-)
>
> Signed-off-by: Michael Wang
> ---
> include/linux/cgroup_subsys.h |1 +
> kernel/sched/core.c | 143
> +
> 2 files changed, 144 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
> index 0bd390c..25eb842 100644
> --- a/include/linux/cgroup_subsys.h
> +++ b/include/linux/cgroup_subsys.h
> @@ -21,6 +21,7 @@ SUBSYS(debug)
>
> #ifdef CONFIG_CGROUP_SCHED
> SUBSYS(cpu_cgroup)
> +SUBSYS(domain_cgroup)
> #endif
>
> /* */
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3987b9d..544bf78 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -8423,6 +8423,149 @@ struct cgroup_subsys cpu_cgroup_subsys = {
> .early_init = 1,
> };
>
> +static struct cgroup_subsys_state domain_cgroup_css;
> +static struct cgroup_subsys_state *domain_cgroup_create(struct cgroup *cgrp)
> +{
> + if (!cgrp->parent) {
> + /* This is early initialization for the top cgroup */
> + return _cgroup_css;
> + }
> +
> + return ERR_PTR(-EPERM);
> +}
> +
> +static void domain_cgroup_destroy(struct cgroup *cgrp)
> +{
> + return;
> +}
> +
> +static int domain_cgroup_can_attach(struct cgroup *cgrp,
> + struct cgroup_taskset *tset)
> +{
> + return -EINVAL;
> +}
> +
> +static void domain_cgroup_attach(struct cgroup *cgrp,
> + struct cgroup_taskset *tset)
> +{
> + return;
> +}
> +
> +static void domain_cgroup_exit(struct cgroup *cgrp,
> +struct cgroup *old_cgrp,
> +struct task_struct *task)
> +{
> + return;
> +}
> +
> +static int domain_config_level;
> +
> +static int domain_cl_write_u64(struct cgroup *cgrp,
> +struct cftype *cftype,
> +u64 shareval)
> +{
> + domain_config_level = shareval;
> + return 0;
> +}
> +
> +static u64 domain_cl_read_u64(struct cgroup *cgrp, struct cftype *cft)
> +{
> + return (u64)domain_config_level;
> +}
> +
> +static int domain_slb_write_u64(struct cgroup *cgrp,
> + struct cftype *cftype,
> + u64 shareval)
> +{
> + int cpu;
> + struct sched_domain *sd;
> + if (shareval != 0 && shareval != 1)
> + return -EINVAL;
> +
> + mutex_lock(_domains_mutex);
> + for_each_cpu(cpu, cpu_active_mask) {
> + for (sd = cpu_rq(cpu)->sd; sd; sd = sd->parent) {
> + if (sd->level == domain_config_level) {
> + if (shareval)
> + sd->flags |= SD_LOAD_BALANCE;
> + else
> + sd->flags &= ~SD_LOAD_BALANCE;
> + }
> + }
> + }
> + mutex_unlock(_domains_mutex);
> + return 0;
> +}
> +
> +static u64 domain_slb_read_u64(struct cgroup *cgrp, struct cftype *cft)
> +{
> + int cpu, ret = 0;
> + struct sched_domain *sd;
> + mutex_lock(_domains_mutex);
> + for_each_cpu(cpu, cpu_active_mask) {
> + for (sd = cpu_rq(cpu)->sd; sd; sd = sd->parent) {
> + if (sd->level == domain_config_level) {
> + if (sd->flags & SD_LOAD_BALANCE)
> + ret = 1;
> +
[PATCH RESEND] Fix a dead loop in async_synchronize_full()
resend it again with the email client fixed... in case it is needed
This patch tries to fix a dead loop in async_synchronize_full(), which
could be seen when preemption is disabled on a single cpu machine.
void async_synchronize_full(void)
{
do {
async_synchronize_cookie(next_cookie);
} while (!list_empty(_running) || !
list_empty(_pending));
}
async_synchronize_cookie() calls async_synchronize_cookie_domain() with
_running as the default domain to synchronize.
However, there might be some works in the async_pending list from other
domains. On a single cpu system, without preemption, there is no chance
for the other works to finish, so async_synchronize_full() enters a dead
loop.
It seems async_synchronize_full() wants to synchronize all entries in
all running lists(domains), so maybe we could just check the entry_count
to know whether all works are finished.
Currently, async_synchronize_cookie_domain() expects a non-NULL running
list ( if NULL, there would be NULL pointer dereference ), so maybe a
NULL pointer could be used as an indication for the functions to
synchronize all works in all domains.
Reported-by: Paul E. McKenney
Signed-off-by: Li Zhong
Tested-by: Paul E. McKenney
Tested-by: Christian Kujau
---
kernel/async.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/kernel/async.c b/kernel/async.c
index bd0c168..32d8dc9 100644
--- a/kernel/async.c
+++ b/kernel/async.c
@@ -86,6 +86,13 @@ static async_cookie_t __lowest_in_progress(struct list_head
*running)
{
struct async_entry *entry;
+ if (!running) { /* just check the entry count */
+ if (atomic_read(_count))
+ return 0; /* smaller than any cookie */
+ else
+ return next_cookie;
+ }
+
if (!list_empty(running)) {
entry = list_first_entry(running,
struct async_entry, list);
@@ -236,9 +243,7 @@ EXPORT_SYMBOL_GPL(async_schedule_domain);
*/
void async_synchronize_full(void)
{
- do {
- async_synchronize_cookie(next_cookie);
- } while (!list_empty(_running) || !list_empty(_pending));
+ async_synchronize_cookie_domain(next_cookie, NULL);
}
EXPORT_SYMBOL_GPL(async_synchronize_full);
@@ -258,7 +263,7 @@ EXPORT_SYMBOL_GPL(async_synchronize_full_domain);
/**
* async_synchronize_cookie_domain - synchronize asynchronous function calls
within a certain domain with cookie checkpointing
* @cookie: async_cookie_t to use as checkpoint
- * @running: running list to synchronize on
+ * @running: running list to synchronize on, NULL indicates all lists
*
* This function waits until all asynchronous function calls for the
* synchronization domain specified by the running list @list submitted
--
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 v5 3/4] kvm: Create kvm_clear_irq()
On Tue, 2012-07-17 at 03:51 +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 16, 2012 at 02:34:03PM -0600, Alex Williamson wrote:
> > This is an alternative to kvm_set_irq(,,,0) which returns the previous
> > assertion state of the interrupt and does nothing if it isn't changed.
> >
> > Signed-off-by: Alex Williamson
> > ---
> >
> > include/linux/kvm_host.h |3 ++
> > virt/kvm/irq_comm.c | 78
> > ++
> > 2 files changed, 81 insertions(+)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index a7661c0..6c168f1 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -219,6 +219,8 @@ struct kvm_kernel_irq_routing_entry {
> > u32 type;
> > int (*set)(struct kvm_kernel_irq_routing_entry *e,
> >struct kvm *kvm, int irq_source_id, int level);
> > + int (*clear)(struct kvm_kernel_irq_routing_entry *e,
> > +struct kvm *kvm, int irq_source_id);
> > union {
> > struct {
> > unsigned irqchip;
> > @@ -629,6 +631,7 @@ void kvm_get_intr_delivery_bitmask(struct kvm_ioapic
> > *ioapic,
> >unsigned long *deliver_bitmask);
> > #endif
> > int kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 irq, int level);
> > +int kvm_clear_irq(struct kvm *kvm, int irq_source_id, u32 irq);
> > int kvm_set_msi(struct kvm_kernel_irq_routing_entry *irq_entry, struct kvm
> > *kvm,
> > int irq_source_id, int level);
> > void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin);
> > diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
> > index 5afb431..76e8f22 100644
> > --- a/virt/kvm/irq_comm.c
> > +++ b/virt/kvm/irq_comm.c
> > @@ -68,6 +68,42 @@ static int kvm_set_ioapic_irq(struct
> > kvm_kernel_irq_routing_entry *e,
> > return kvm_ioapic_set_irq(ioapic, e->irqchip.pin, level);
> > }
> >
> > +static inline int kvm_clear_irq_line_state(unsigned long *irq_state,
> > + int irq_source_id)
> > +{
> > + return !!test_and_clear_bit(irq_source_id, irq_state);
> > +}
> > +
> > +static int kvm_clear_pic_irq(struct kvm_kernel_irq_routing_entry *e,
> > +struct kvm *kvm, int irq_source_id)
> > +{
> > +#ifdef CONFIG_X86
> > + struct kvm_pic *pic = pic_irqchip(kvm);
> > + int level = kvm_clear_irq_line_state(>irq_states[e->irqchip.pin],
> > +irq_source_id);
> > + if (level)
> > + kvm_pic_set_irq(pic, e->irqchip.pin,
> > + !!pic->irq_states[e->irqchip.pin]);
> > + return level;
> > +#else
> > + return -1;
> > +#endif
>
> What does this ifdef exclude exactly?
No pic on ia64. Not that it works, but I figured the consistency with
kvm_set_pic_irq would make more sense whenever someone goes through and
cleans out the code. Thanks,
Alex
> > +}
> > +
> > +static int kvm_clear_ioapic_irq(struct kvm_kernel_irq_routing_entry *e,
> > + struct kvm *kvm, int irq_source_id)
> > +{
> > + struct kvm_ioapic *ioapic = kvm->arch.vioapic;
> > + int level;
> > +
> > + level = kvm_clear_irq_line_state(>irq_states[e->irqchip.pin],
> > +irq_source_id);
> > + if (level)
> > + kvm_ioapic_set_irq(ioapic, e->irqchip.pin,
> > + !!ioapic->irq_states[e->irqchip.pin]);
> > + return level;
> > +}
> > +
> > inline static bool kvm_is_dm_lowest_prio(struct kvm_lapic_irq *irq)
> > {
> > #ifdef CONFIG_IA64
> > @@ -190,6 +226,45 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id,
> > u32 irq, int level)
> > return ret;
> > }
> >
> > +/*
> > + * Return value:
> > + * < 0 Error
> > + * = 0 Interrupt was not set, did nothing
> > + * > 0 Interrupt was pending, cleared
> > + */
> > +int kvm_clear_irq(struct kvm *kvm, int irq_source_id, u32 irq)
> > +{
> > + struct kvm_kernel_irq_routing_entry *e, irq_set[KVM_NR_IRQCHIPS];
> > + int ret = -EINVAL, i = 0;
> > + struct kvm_irq_routing_table *irq_rt;
> > + struct hlist_node *n;
> > +
> > + /* Not possible to detect if the guest uses the PIC or the
> > +* IOAPIC. So clear the bit in both. The guest will ignore
> > +* writes to the unused one.
> > +*/
> > + rcu_read_lock();
> > + irq_rt = rcu_dereference(kvm->irq_routing);
> > + if (irq < irq_rt->nr_rt_entries)
> > + hlist_for_each_entry(e, n, _rt->map[irq], link)
> > + irq_set[i++] = *e;
> > + rcu_read_unlock();
> > +
> > + while (i--) {
> > + int r = -EINVAL;
> > +
> > + if (irq_set[i].clear)
> > + r = irq_set[i].clear(_set[i], kvm, irq_source_id);
> > +
> > + if (r < 0)
> > + continue;
> > +
> > + ret = r + ((ret < 0) ? 0 : ret);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > void kvm_notify_acked_irq(struct
Re: [PATCH] net-next: make sock diag per-namespace (v2)
On 07/16/2012 06:28 PM, Andrew Vagin wrote: > Before this patch sock_diag works for init_net only and dumps > information about sockets from all namespaces. > > This patch expands sock_diag for all name-spaces. > It creates a netlink kernel socket for each netns and filters > data during dumping. > > v2: filter accoding with netns in all places > remove an unused variable. > > Cc: "David S. Miller" > Cc: Alexey Kuznetsov > Cc: James Morris > Cc: Hideaki YOSHIFUJI > Cc: Patrick McHardy > Cc: Pavel Emelyanov > CC: Eric Dumazet > Cc: linux-kernel@vger.kernel.org > Cc: net...@vger.kernel.org > Signed-off-by: Andrew Vagin Acked-by: Pavel Emelyanov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] staging: comedi: adl_pci6208: use the comedi_device hw_dev to hold the pci_dev
On Monday, July 16, 2012 7:31 PM, Greg KH wrote: > On Mon, Jul 16, 2012 at 07:26:22PM -0700, H Hartley Sweeten wrote: >> Use the 'struct device *hw_dev' variable in the comedi_device struct >> to hold the pci_dev instead of carrying it in the private data. >> >> Signed-off-by: H Hartley Sweeten >> Cc: Ian Abbott >> Cc: Greg Kroah-Hartman >> --- >> drivers/staging/comedi/drivers/adl_pci6208.c | 19 ++- >> 1 file changed, 10 insertions(+), 9 deletions(-) > > Looks good to me, I forgot we had the to_pci_dev() macro in pci.h. Want > to redo all of these and resend this one with the larger series? Will do. Should be able to get it out tomorrow. Regards, Hartley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: comedi: adl_pci6208: use the comedi_device hw_dev to hold the pci_dev
On Mon, Jul 16, 2012 at 07:26:22PM -0700, H Hartley Sweeten wrote: > Use the 'struct device *hw_dev' variable in the comedi_device struct > to hold the pci_dev instead of carrying it in the private data. > > Signed-off-by: H Hartley Sweeten > Cc: Ian Abbott > Cc: Greg Kroah-Hartman > --- > drivers/staging/comedi/drivers/adl_pci6208.c | 19 ++- > 1 file changed, 10 insertions(+), 9 deletions(-) Looks good to me, I forgot we had the to_pci_dev() macro in pci.h. Want to redo all of these and resend this one with the larger series? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the regulator tree with the mfd tree
Hi all,
Today's linux-next merge of the regulator tree got a conflict in
include/linux/mfd/s5m87xx/s5m-core.h between commits from the mfd tree
and commit c848bc8538cd ("regulator: s5m8767a: Support AP watchdog reset
operation") from the regulator tree.
This file was renamed (twice) in the mfd tree, so I removed the version
in the regulator tree. The changes from the regulator tree turned up in
an mfd tree commit as well.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpG31vXf1PnZ.pgp
Description: PGP signature
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
At 07/17/2012 09:54 AM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/07/17 10:44, Yasuaki Ishimatsu wrote:
>> Hi Wen,
>>
>> 2012/07/13 12:35, Wen Congyang wrote:
>>> At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
acpi_memory_device_remove() has been prepared to remove physical memory.
But, the function only frees acpi_memory_device currentlry.
The patch adds following functions into acpi_memory_device_remove():
- offline memory
- remove physical memory (only return -EBUSY)
- free acpi_memory_device
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/acpi_memhotplug.c | 26 +-
drivers/base/memory.c | 39
+++
include/linux/memory.h |5 +
include/linux/memory_hotplug.h |1 +
mm/memory_hotplug.c|8
5 files changed, 78 insertions(+), 1 deletion(-)
Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
===
--- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
18:08:29.946888653 +0900
+++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
18:08:43.470719531 +0900
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
static int acpi_memory_device_remove(struct acpi_device *device, int
type)
{
struct acpi_memory_device *mem_device = NULL;
-
+ struct acpi_memory_info *info, *tmp;
+ int result;
+ int node;
if (!device || !acpi_driver_data(device))
return -EINVAL;
mem_device = acpi_driver_data(device);
+
+ node = acpi_get_node(mem_device->device->handle);
+
+ list_for_each_entry_safe(info, tmp, _device->res_list, list) {
+ if (!info->enabled)
+ continue;
+
+ if (!is_memblk_offline(info->start_addr, info->length)) {
+ result = offline_memory(info->start_addr, info->length);
+ if (result)
+ return result;
+ }
+
+ result = remove_memory(node, info->start_addr, info->length);
>>>
>>> The user may online the memory between offline_memory() and remove_memory().
>>> So I think we should lock memory hotplug before check the memory's status
>>> and release it after remove_memory().
>>
>> How about get "mem_block->state_mutex" of removed memory? When offlining
>> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
>> In this case, we get mem_block->state_mutex. So I think the mutex lock
>> is beneficial.
>
> It is not good idea since remove_memory frees mem_block structure...
> Do you have any ideas?
Hmm, split offline_memory() to 2 functions: offline_pages() and
__offline_pages()
offline_pages()
lock_memory_hotplug();
__offline_pages();
unlock_memory_hotplug();
and implement remove_memory() like this:
remove_memory()
lock_memory_hotplug()
if (!is_memblk_offline()) {
__offline_pages();
}
// cleanup
unlock_memory_hotplug();
What about this?
Thanks
Wen Congyang
>
> Thanks,
> Yasuaki Ishimatsu
>
>> Thanks,
>> Yasuaki Ishimatsu
>>
>>>
>>> Thanks
>>> Wen Congyang
>>>
+ if (result)
+ return result;
+
+ list_del(>list);
+ kfree(info);
+ }
+
kfree(mem_device);
return 0;
Index: linux-3.5-rc6/include/linux/memory_hotplug.h
===
--- linux-3.5-rc6.orig/include/linux/memory_hotplug.h 2012-07-09
18:08:29.955888542 +0900
+++ linux-3.5-rc6/include/linux/memory_hotplug.h 2012-07-09
18:08:43.471719518 +0900
@@ -233,6 +233,7 @@ static inline int is_mem_section_removab
extern int mem_online_node(int nid);
extern int add_memory(int nid, u64 start, u64 size);
extern int arch_add_memory(int nid, u64 start, u64 size);
+extern int remove_memory(int nid, u64 start, u64 size);
extern int offline_memory(u64 start, u64 size);
extern int sparse_add_one_section(struct zone *zone, unsigned long
start_pfn,
int
nr_pages);
Index:
[PATCH] staging: comedi: adl_pci6208: use the comedi_device hw_dev to hold the pci_dev
Use the 'struct device *hw_dev' variable in the comedi_device struct
to hold the pci_dev instead of carrying it in the private data.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adl_pci6208.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci6208.c
b/drivers/staging/comedi/drivers/adl_pci6208.c
index 487fd4a..ffecbe7 100644
--- a/drivers/staging/comedi/drivers/adl_pci6208.c
+++ b/drivers/staging/comedi/drivers/adl_pci6208.c
@@ -73,7 +73,6 @@ static const struct pci6208_board pci6208_boards[] = {
};
struct pci6208_private {
- struct pci_dev *pci_dev;
unsigned int ao_readback[PCI6208_MAX_AO_CHANNELS];
};
@@ -200,6 +199,7 @@ static int pci6208_attach(struct comedi_device *dev,
{
const struct pci6208_board *thisboard;
struct pci6208_private *devpriv;
+ struct pci_dev *pcidev;
struct comedi_subdevice *s;
int ret;
@@ -208,20 +208,21 @@ static int pci6208_attach(struct comedi_device *dev,
return ret;
devpriv = dev->private;
- devpriv->pci_dev = pci6208_find_device(dev, it);
- if (!devpriv->pci_dev)
+ pcidev = pci6208_find_device(dev, it);
+ if (!pcidev)
return -EIO;
+ comedi_set_hw_dev(dev, >dev);
thisboard = comedi_board(dev);
dev->board_name = thisboard->name;
- ret = comedi_pci_enable(devpriv->pci_dev, dev->driver->driver_name);
+ ret = comedi_pci_enable(pcidev, dev->driver->driver_name);
if (ret) {
dev_err(dev->class_dev,
"Failed to enable PCI device and request regions\n");
return ret;
}
- dev->iobase = pci_resource_start(devpriv->pci_dev, 2);
+ dev->iobase = pci_resource_start(pcidev, 2);
ret = comedi_alloc_subdevices(dev, 2);
if (ret)
@@ -258,12 +259,12 @@ static int pci6208_attach(struct comedi_device *dev,
static void pci6208_detach(struct comedi_device *dev)
{
- struct pci6208_private *devpriv = dev->private;
+ struct pci_dev *pcidev = to_pci_dev(dev->hw_dev);
- if (devpriv && devpriv->pci_dev) {
+ if (pcidev) {
if (dev->iobase)
- comedi_pci_disable(devpriv->pci_dev);
- pci_dev_put(devpriv->pci_dev);
+ comedi_pci_disable(pcidev);
+ pci_dev_put(pcidev);
}
}
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 01/30] staging: comedi: add pci_dev pointer to comedi_device
On Monday, July 16, 2012 7:01 PM, Greg KH wrote: > On Mon, Jul 16, 2012 at 08:55:47PM -0500, H Hartley Sweeten wrote: >> On Monday, July 16, 2012 6:52 PM, Greg KH wrote: >>> No, the field above this, hw_dev, should be used instead here, as that's >>> what it is there for, right? >> >> The hw_dev pointer is currently only used for something dealing with dma. >> I have not dug into it yet to see what exactly it's used for. The comment >> says: >> >> /* hw_dev is passed to dma_alloc_coherent when allocating async buffers >> * for subdevices that have async_dma_dir set to something other than >> * DMA_NONE */ > > Which is exactly what the pci device should be used for, it knows this > information :) > >>> Care to rework this series with that change instead? >> >> It could probably be used with some sort of container_of but I'm not sure. > > Yes it can. > > To set the field: > > hw_dev = _dev->dev; > > to get it back: > pci_dev = container_of(hw_dev, struct pci_device, struct device); > > I think. That's off the top of my head, please try it out first. > > And use a macro for the container_of stuff, that makes it easier to > understand. Greg, I'm posting a patch to the adl_pci6208 driver right now. It compiles fine but could you look it over and see if it looks right. Thanks, Hartley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for July 12 (v4l2-ioctl.c)
On Thu, Jul 12, 2012 at 11:49 PM, Randy Dunlap wrote: > On 07/11/2012 11:03 PM, Stephen Rothwell wrote: > >> Hi all, >> >> Changes since 20120710: > > > > on i386 and/or x86_64, drivers/media/video/v4l2-ioctl.c has too many > errors to be listed here. This is the beginning few lines of the errors: I see the errors on ARM too. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the regulator tree with the mfd tree
Hi all,
Today's linux-next merge of the regulator tree got a conflicts in
drivers/regulator/s5m8767.c between commit 63063bfbffe9 ("mfd: Modify
samsung mfd driver for common api") from the mfd tree and commits
3fe3a182adfe ("regulator: Remove s5m8767a buck initialization"),
df2643cfa4ad ("regulator: Replace set_voltage with set_voltage_sel"),
c848bc8538cd ("regulator: s5m8767a: Support AP watchdog reset
operation"), 1af142c6f984 ("regulator: Modify ramp_delay value for
s5m8767a"), e2eb169b1bc2 ("regulator: s5m8767: Convert to
regulator_list_voltage_linear") from the regulator tree.
I fixed it all up (I think - see below) and can carry the fixes as
necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/regulator/s5m8767.c
index aeea91b,102287f..000
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@@ -431,14 -407,8 +407,8 @@@ static int s5m8767_set_voltage_sel(stru
if (ret)
return ret;
- sec_reg_read(s5m8767->iodev, reg, );
- val = (val & ~mask) | sel;
-
- ret = sec_reg_write(s5m8767->iodev, reg, val);
- return s5m_reg_update(s5m8767->iodev, reg, selector, mask);
++ return sec_reg_update(s5m8767->iodev, reg, selector, mask);
}
-
- *selector = sel;
- return ret;
}
static int s5m8767_set_voltage_time_sel(struct regulator_dev *rdev,
@@@ -579,6 -567,27 +567,27 @@@ static __devinit int s5m8767_pmic_probe
s5m8767->buck4_ramp = pdata->buck4_ramp_enable;
s5m8767->opmode = pdata->opmode;
+ buck_init = s5m8767_convert_voltage_to_sel(_voltage_val2,
+ pdata->buck2_init,
+ pdata->buck2_init +
+ buck_voltage_val2.step);
+
- s5m_reg_write(s5m8767->iodev, S5M8767_REG_BUCK2DVS2, buck_init);
++ sec_reg_write(s5m8767->iodev, S5M8767_REG_BUCK2DVS2, buck_init);
+
+ buck_init = s5m8767_convert_voltage_to_sel(_voltage_val2,
+ pdata->buck3_init,
+ pdata->buck3_init +
+ buck_voltage_val2.step);
+
- s5m_reg_write(s5m8767->iodev, S5M8767_REG_BUCK3DVS2, buck_init);
++ sec_reg_write(s5m8767->iodev, S5M8767_REG_BUCK3DVS2, buck_init);
+
+ buck_init = s5m8767_convert_voltage_to_sel(_voltage_val2,
+ pdata->buck4_init,
+ pdata->buck4_init +
+ buck_voltage_val2.step);
+
- s5m_reg_write(s5m8767->iodev, S5M8767_REG_BUCK4DVS2, buck_init);
++ sec_reg_write(s5m8767->iodev, S5M8767_REG_BUCK4DVS2, buck_init);
+
for (i = 0; i < 8; i++) {
if (s5m8767->buck2_gpiodvs) {
s5m8767->buck2_vol[i] =
@@@ -608,48 -617,70 +617,70 @@@
}
}
- if (pdata->buck2_gpiodvs || pdata->buck3_gpiodvs ||
- pdata->buck4_gpiodvs) {
- if (gpio_is_valid(pdata->buck_gpios[0]) &&
- gpio_is_valid(pdata->buck_gpios[1]) &&
- gpio_is_valid(pdata->buck_gpios[2])) {
- ret = gpio_request(pdata->buck_gpios[0],
- "S5M8767 SET1");
- if (ret == -EBUSY)
- dev_warn(>dev, "Duplicated gpio request
for SET1\n");
-
- ret = gpio_request(pdata->buck_gpios[1],
- "S5M8767 SET2");
- if (ret == -EBUSY)
- dev_warn(>dev, "Duplicated gpio request
for SET2\n");
-
- ret = gpio_request(pdata->buck_gpios[2],
- "S5M8767 SET3");
- if (ret == -EBUSY)
- dev_warn(>dev, "Duplicated gpio request
for SET3\n");
- /* SET1 GPIO */
- gpio_direction_output(pdata->buck_gpios[0],
- (s5m8767->buck_gpioindex >> 2) & 0x1);
- /* SET2 GPIO */
- gpio_direction_output(pdata->buck_gpios[1],
- (s5m8767->buck_gpioindex >> 1) & 0x1);
- /* SET3 GPIO */
- gpio_direction_output(pdata->buck_gpios[2],
- (s5m8767->buck_gpioindex >> 0) & 0x1);
- ret = 0;
- } else {
- dev_err(>dev, "GPIO NOT VALID\n");
- ret = -EINVAL;
+ if (gpio_is_valid(pdata->buck_gpios[0]) &&
+ gpio_is_valid(pdata->buck_gpios[1]) &&
+
[PATCH] firmware_map : unify argument of firmware_map_add_early/hotplug
There are two ways to create /sys/firmware/memmap/X sysfs:
- firmware_map_add_early
When the system starts, it is calledd from e820_reserve_resources()
- firmware_map_add_hotplug
When the memory is hot plugged, it is called from add_memory()
But these functions are called without unifying value of end argument as below:
- end argument of firmware_map_add_early() : start + size - 1
- end argument of firmware_map_add_hogplug() : start + size
The patch unifies them to "start + size". Even if applying the patch,
/sys/firmware/memmap/X/end file content does not change.
CC: Thomas Gleixner
CC: Ingo Molnar
CC: H. Peter Anvin
CC: Tejun Heo
CC: Andrew Morton
Reviewed-by: Dave Hansen
Signed-off-by: Yasuaki Ishimatsu
---
arch/x86/kernel/e820.c|2 +-
drivers/firmware/memmap.c |8
2 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-next/arch/x86/kernel/e820.c
===
--- linux-next.orig/arch/x86/kernel/e820.c 2012-07-02 09:50:23.0
+0900
+++ linux-next/arch/x86/kernel/e820.c 2012-07-12 13:30:45.942318179 +0900
@@ -944,7 +944,7 @@
for (i = 0; i < e820_saved.nr_map; i++) {
struct e820entry *entry = _saved.map[i];
firmware_map_add_early(entry->addr,
- entry->addr + entry->size - 1,
+ entry->addr + entry->size,
e820_type_to_string(entry->type));
}
}
Index: linux-next/drivers/firmware/memmap.c
===
--- linux-next.orig/drivers/firmware/memmap.c 2012-07-02 09:50:26.0
+0900
+++ linux-next/drivers/firmware/memmap.c2012-07-12 13:40:53.823318481
+0900
@@ -98,7 +98,7 @@
/**
* firmware_map_add_entry() - Does the real work to add a firmware memmap
entry.
* @start: Start of the memory range.
- * @end: End of the memory range (inclusive).
+ * @end: End of the memory range.
* @type: Type of the memory range.
* @entry: Pre-allocated (either kmalloc() or bootmem allocator), uninitialised
* entry.
@@ -113,7 +113,7 @@
BUG_ON(start > end);
entry->start = start;
- entry->end = end;
+ entry->end = end - 1;
entry->type = type;
INIT_LIST_HEAD(>list);
kobject_init(>kobj, _ktype);
@@ -148,7 +148,7 @@
* firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
* memory hotplug.
* @start: Start of the memory range.
- * @end: End of the memory range (inclusive).
+ * @end: End of the memory range.
* @type: Type of the memory range.
*
* Adds a firmware mapping entry. This function is for memory hotplug, it is
@@ -175,7 +175,7 @@
/**
* firmware_map_add_early() - Adds a firmware mapping entry.
* @start: Start of the memory range.
- * @end: End of the memory range (inclusive).
+ * @end: End of the memory range.
* @type: Type of the memory range.
*
* Adds a firmware mapping entry. This function uses the bootmem allocator
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [TRIVIAL] perf: missing struct before structure name
>From 3abcb73682893ed2bde318d17f1cc3430bf70224 Mon Sep 17 00:00:00 2001
From: Jovi Zhang
Date: Tue, 17 Jul 2012 17:21:56 +0800
Subject: [PATCH] [TRIVIAL] perf: missing struct before structure name
when CONFIG_PERF_EVENTS disabled, there will have a compiliation error,
because missing struct before structure name.
Signed-off-by: Jovi Zhang
---
arch/x86/include/asm/perf_event.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/perf_event.h
b/arch/x86/include/asm/perf_event.h
index 588f52e..2643877 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -235,7 +235,7 @@ struct perf_guest_switch_msr {
extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);
extern void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap);
#else
-static inline perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
+static inline struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
{
*nr = 0;
return NULL;
--
1.7.9.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] staging: comedi: remove the devpriv and thisboard macros
On Monday, July 16, 2012 7:09 PM, Greg KH wrote: > Because I didn't take your other large patch series, this one didn't > apply :( Of course... ;-) Looking at using the hw_dev right now. I should have something tomorrow. Thanks. Hartley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] staging: sbe-2t3e3: Remove code that will never execute
On Thu, Jul 12, 2012 at 11:27:49PM -0300, Marcos Paulo de Souza wrote: > This patch removes all references of "if 0" blocks in the sbe-2t3e3 driver. > > Signed-off-by: Marcos Paulo de Souza > --- > drivers/staging/sbe-2t3e3/2t3e3.h|3 -- > drivers/staging/sbe-2t3e3/cpld.c | 15 - > drivers/staging/sbe-2t3e3/ctrl.c | 19 +++ > drivers/staging/sbe-2t3e3/dc.c | 17 -- > drivers/staging/sbe-2t3e3/exar7250.c | 40 +++ > drivers/staging/sbe-2t3e3/exar7300.c | 17 -- > drivers/staging/sbe-2t3e3/intr.c | 60 > ++ > drivers/staging/sbe-2t3e3/io.c | 21 > 8 files changed, 10 insertions(+), 182 deletions(-) > > diff --git a/drivers/staging/sbe-2t3e3/2t3e3.h > b/drivers/staging/sbe-2t3e3/2t3e3.h > index fe9f086..383f2cf 100644 > --- a/drivers/staging/sbe-2t3e3/2t3e3.h > +++ b/drivers/staging/sbe-2t3e3/2t3e3.h > > Just fix the commit message fo sbr-2t3e3 to sbe-2t3e3. > > @@ -801,9 +801,6 @@ u32 cpld_read(struct channel *sc, u32 reg); Woah, what is that line in the middle of the patch here? That causes git to (rightfully) choke on the patch. Please fix this and resend. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: fix compile for OF && !COMMON_CLK
On 07/16/2012 07:12 PM, Mike Turquette wrote:
> On 20120716-16:46, Rob Herring wrote:
>> From: Rob Herring
>>
>> With commit 766e6a4ec602d0c107 (clk: add DT clock binding support),
>> compiling with OF && !COMMON_CLK is broken.
>>
>
> Hi Rob,
>
> Thanks for sending this quickly.
>
>
>> @@ -313,19 +314,19 @@ int clk_add_alias(const char *alias, const char
>> *alias_dev_name, char *id,
>> struct device_node;
>> struct of_phandle_args;
>>
>> -#ifdef CONFIG_OF
>> +#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
>> struct clk *of_clk_get(struct device_node *np, int index);
>> struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
>> struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
>> #else
>> static inline struct clk *of_clk_get(struct device_node *np, int index)
>> {
>> -return NULL;
>> +return ERR_PTR(-EINVAL);
>
> This change seems unrelated?
>
>> }
>> static inline struct clk *of_clk_get_by_name(struct device_node *np,
>> const char *name)
>> {
>> -return NULL;
>> +return ERR_PTR(-EINVAL);
>
> Ditto.
Yeah, it should probably go in Shawn's fix as that is actually when it
will start breaking.
Rob
>
> Thanks,
> Mike
>
>> }
>> #endif
>>
>> --
>> 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 2/2] staging: comedi: remove the devpriv and thisboard macros
On Thu, Jul 12, 2012 at 05:47:21PM -0700, H Hartley Sweeten wrote: > The macros 'devpriv' and 'thisboard' rely on a local variable having > a specific name and yeild pointers derived from that variable. Replace > the macros with local variables where used and use to comedi_board() > helper to get the 'thisboard' pointer. > > Signed-off-by: H Hartley Sweeten > Cc: Ian Abbott > Cc: Greg Kroah-Hartman Because I didn't take your other large patch series, this one didn't apply :( greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
(2012/07/14 3:47), Steven Rostedt wrote:
> On Thu, 2012-07-12 at 21:39 +0900, Masami Hiramatsu wrote:
>
>> /*
>> * X86_32 CPUs don't save ss and esp if the CPU is already in kernel mode
>> * when it traps. The previous stack will be directly underneath the saved
>> * registers, and 'sp/ss' won't even have been saved. Thus the '>sp'.
>> *
>> * This is valid only for kernel mode traps.
>> */
>> static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
>> {
>> #ifdef CONFIG_X86_32
>> return (unsigned long)(>sp);
>> #else
>> return regs->sp;
>> #endif
>> }
>
> I found that regs_get_register() doesn't honor this either. Thus,
> kprobes in tracing gets this:
>
> # echo 'p:ftrace sys_read+4 s=%sp' > /debug/tracing/kprobe_events
> # echo 1 > /debug/tracing/events/kprobes/enable
> # cat trace
> sshd-1345 [000] d... 489.117168: ftrace: (sys_read+0x4/0x70)
> s=b7e96768
> sshd-1345 [000] d... 489.117191: ftrace: (sys_read+0x4/0x70)
> s=b7e96768
> cat-1447 [000] d... 489.117392: ftrace: (sys_read+0x4/0x70)
> s=5a7
> cat-1447 [001] d... 489.118023: ftrace: (sys_read+0x4/0x70)
> s=b77ad05f
> less-1448 [000] d... 489.118079: ftrace: (sys_read+0x4/0x70)
> s=b7762e06
> less-1448 [000] d... 489.118117: ftrace: (sys_read+0x4/0x70)
> s=b7764970
>
Yes, that is by design, since I made it so. :)
Instead of %sp, kprobe tracer provides $stack special argument
for stack address, because "sp" is not always means the stack
address on every arch.
Thanks,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 0/4] staging: adding OMAP bandgap driver
On Thu, Jul 12, 2012 at 07:02:28PM +0300, Eduardo Valentin wrote: > Greg, > > Here is again the OMAP BG driver, under staging area. > I fixed the compilation issue I didn't see, wrt implicit function > declarations. As I mentioned on other thread, my compilation test > didn't see it, that's why I thought it was fine to send it. > > I also limited the driver compilation to OMAP4/5. I edited the Makefile part of the patch by hand, and applied these patches, can you pull my tree and verify that I didn't break anything? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: ftrace: Trace function entry before updating index
Commit 722b3c74695377d11d18a52f3da08114d37f3f37 modified x86 ftrace to
avoid tracing all functions called from irqs when function graph was
used with a filter. Port the same fix to ARM.
Cc: Steven Rostedt
Signed-off-by: Colin Cross
---
It looks like the same issue affects blackfin, microblaze, mips,
parisc, powerpc, s390, sh, and sparc, but I don't have patches to
fix those.
arch/arm/kernel/ftrace.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index df0bf0c..34e5664 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -179,19 +179,20 @@ void prepare_ftrace_return(unsigned long *parent,
unsigned long self_addr,
old = *parent;
*parent = return_hooker;
- err = ftrace_push_return_trace(old, self_addr, ,
- frame_pointer);
- if (err == -EBUSY) {
- *parent = old;
- return;
- }
-
trace.func = self_addr;
+ trace.depth = current->curr_ret_stack + 1;
/* Only trace if the calling function expects to */
if (!ftrace_graph_entry()) {
- current->curr_ret_stack--;
*parent = old;
+ return;
+ }
+
+ err = ftrace_push_return_trace(old, self_addr, ,
+ frame_pointer);
+ if (err == -EBUSY) {
+ *parent = old;
+ return;
}
}
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 1/4] staging: OMAP4+: thermal: introduce bandgap temperature sensor
On Thu, Jul 12, 2012 at 07:02:29PM +0300, Eduardo Valentin wrote: > In the System Control Module, OMAP supplies a voltage reference > and a temperature sensor feature that are gathered in the band > gap voltage and temperature sensor (VBGAPTS) module. The band > gap provides current and voltage reference for its internal > circuits and other analog IP blocks. The analog-to-digital > converter (ADC) produces an output value that is proportional > to the silicon temperature. > > This patch provides a platform driver which expose this feature. > It is moduled as a MFD child of the System Control Module core > MFD driver. > > This driver provides only APIs to access the device properties, > like temperature, thresholds and update rate. > > Signed-off-by: Eduardo Valentin > Signed-off-by: J Keerthy > --- > drivers/staging/Kconfig |2 + > drivers/staging/Makefile |1 + > drivers/staging/omap-thermal/Kconfig | 11 + > drivers/staging/omap-thermal/Makefile |2 + > drivers/staging/omap-thermal/TODO | 28 + > drivers/staging/omap-thermal/omap-bandgap.c | 1167 > + > drivers/staging/omap-thermal/omap-bandgap.h | 425 + > drivers/staging/omap-thermal/omap_bandgap.txt | 30 + > 8 files changed, 1666 insertions(+), 0 deletions(-) > create mode 100644 drivers/staging/omap-thermal/Kconfig > create mode 100644 drivers/staging/omap-thermal/Makefile > create mode 100644 drivers/staging/omap-thermal/TODO > create mode 100644 drivers/staging/omap-thermal/omap-bandgap.c > create mode 100644 drivers/staging/omap-thermal/omap-bandgap.h > create mode 100644 drivers/staging/omap-thermal/omap_bandgap.txt > > Patch changelog: > Change from V1 to V2: > - Compilation fixes on Kconfig and Makefiles under drivers/staging > Change from V2 to V3: > - Removed empty line from end of Kconfig file, so git is happy while applying > - Keerthy's SOB now matches Copyright notice found in files > Change from V3 to V4: > - Fixed -Werror-implicit-function-declaration compilation issues. > - Limited driver compilation to OMAP4/5 > > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > index d3934d7..e3402d5 100644 > --- a/drivers/staging/Kconfig > +++ b/drivers/staging/Kconfig > @@ -134,4 +134,6 @@ source "drivers/staging/gdm72xx/Kconfig" > > source "drivers/staging/csr/Kconfig" > > +source "drivers/staging/omap-thermal/Kconfig" > + > endif # STAGING > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > index 5b2219a..dbbdbbc 100644 > --- a/drivers/staging/Makefile > +++ b/drivers/staging/Makefile > @@ -59,3 +59,4 @@ obj-$(CONFIG_USB_WPAN_HCD) += ozwpan/ > obj-$(CONFIG_USB_G_CCG) += ccg/ > obj-$(CONFIG_WIMAX_GDM72XX) += gdm72xx/ > obj-$(CONFIG_CSR_WIFI) += csr/ > +obj-y+= omap-thermal/ Ick, no, why did you do that? This should only be entered if the config entry is selected, right? Did I just miss this on your previous patches? Sorry about that. I'll see if I can fix it up by hand... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/30] staging: comedi: add pci_dev pointer to comedi_device
On Mon, Jul 16, 2012 at 08:55:47PM -0500, H Hartley Sweeten wrote:
> On Monday, July 16, 2012 6:52 PM, Greg KH wrote:
> > On Wed, Jul 11, 2012 at 02:49:14PM -0700, H Hartley Sweeten wrote:
> >> The pci_dev pointer in the private driver data is used by every
> >> comedi pci driver. Some of them only have the need for the
> >> private data because of this pointer.
> >>
> >> Introduce the pci_dev pointer in the comedi_device struct so it
> >> can be used instead of needing it in the private data.
> >>
> >> Signed-off-by: H Hartley Sweeten
> >> Cc: Ian Abbott
> >> Cc: Greg Kroah-Hartman
> >> ---
> >> drivers/staging/comedi/comedidev.h | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/staging/comedi/comedidev.h
> >> b/drivers/staging/comedi/comedidev.h
> >> index de8c99c..55f2373 100644
> >> --- a/drivers/staging/comedi/comedidev.h
> >> +++ b/drivers/staging/comedi/comedidev.h
> >> @@ -212,6 +212,8 @@ struct comedi_device {
> >> * DMA_NONE */
> >>struct device *hw_dev;
> >>
> >> + struct pci_dev *pcidev;
> >
> > No, the field above this, hw_dev, should be used instead here, as that's
> > what it is there for, right?
>
> The hw_dev pointer is currently only used for something dealing with dma.
> I have not dug into it yet to see what exactly it's used for. The comment
> says:
>
> /* hw_dev is passed to dma_alloc_coherent when allocating async buffers
>* for subdevices that have async_dma_dir set to something other than
>* DMA_NONE */
Which is exactly what the pci device should be used for, it knows this
information :)
> > Care to rework this series with that change instead?
>
> It could probably be used with some sort of container_of but I'm not sure.
Yes it can.
To set the field:
hw_dev = _dev->dev;
to get it back:
pci_dev = container_of(hw_dev, struct pci_device, struct device);
I think. That's off the top of my head, please try it out first.
And use a macro for the container_of stuff, that makes it easier to
understand.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to map ata_link to physical link and ata_port to physical port
CC-ed Gwendal and Jeff
Ping.
On Mon, Jul 16, 2012 at 11:09 AM, Yang Bai wrote:
> Hi hackers,
>
> In our internal usage, we want to map the disk in system like
> sd{a,b,c} to physical disk slot. When the disk is attached to LSI HBA
> card, we find that we can rely on the phy attribute of the disk to
> find the slot since this attribute does not change no matter which
> kind of disks we attach or what order we attach the disks. But when
> doing this for AHCI, we do not find an attribute that we can rely on
> it to map the disk to slot. No matter ata_port number or ata_host
> number, when we changed the order we attached the disks to slots, they
> changed.
>
> So I want to know is there some attribute we can get from AHCI that
> map the logical disk to physical slot?
>
> Thanks,
> Yang
--
"""
Keep It Simple,Stupid.
"""
Chinese Name: 白杨
Nick Name: Hamo
Homepage: http://hamobai.com/
GPG KEY ID: 0xA4691A33
Key fingerprint = 09D5 2D78 8E2B 0995 CF8E 4331 33C4 3D24 A469 1A33
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 RESEND] Fix a dead loop in async_synchronize_full()
On Mon, Jul 16, 2012 at 04:01:33PM -0700, Dan Williams wrote: > On Mon, Jul 16, 2012 at 11:32 AM, Christian Kujau > wrote: > > Is this still scheduled to go into 3.5? I'm asking because -rc7 has been > > released and does not contain this fix. W/o this fix, my powerpc system > > won't boot[0] :-\ > > I don't expect James is going to push my async changes for 3.5. So > maybe we should go with Zhong's smaller fix for 3.5 and then replace > with the ASYNC_DOMAIN patches in 3.6? Makes sense to me! I have been using Zhong's fix for my testing on PowerPC for some weeks now with no trouble. 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: [Regression][Revert request] Excessive delay or hang during resume from system suspend due to a hrti
On 07/16/2012 10:54 AM, John Stultz wrote: Thanks for sending your config and test results. Looking at the call trace you provided, I'm not seeing anything yet, but I'll be looking over the code while running my test boxes in a reboot loop w/ your config to see if I can't figure out the get_next_timer_interrupt issue you saw at bootup. Left my two boxes (one bare-metal, the other a VM) in reboot loops all day with your config and haven't hit anything. :( Do let me know if you're able to trigger this again. Given that the back trace you listed doesn't seem to be directly linked to the leapsecond related hrtimer changes, I'm wondering if this might be something else. But if you get any more details, do let me know and I'll try to sort it out. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 01/30] staging: comedi: add pci_dev pointer to comedi_device
On Monday, July 16, 2012 6:52 PM, Greg KH wrote:
> On Wed, Jul 11, 2012 at 02:49:14PM -0700, H Hartley Sweeten wrote:
>> The pci_dev pointer in the private driver data is used by every
>> comedi pci driver. Some of them only have the need for the
>> private data because of this pointer.
>>
>> Introduce the pci_dev pointer in the comedi_device struct so it
>> can be used instead of needing it in the private data.
>>
>> Signed-off-by: H Hartley Sweeten
>> Cc: Ian Abbott
>> Cc: Greg Kroah-Hartman
>> ---
>> drivers/staging/comedi/comedidev.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/staging/comedi/comedidev.h
>> b/drivers/staging/comedi/comedidev.h
>> index de8c99c..55f2373 100644
>> --- a/drivers/staging/comedi/comedidev.h
>> +++ b/drivers/staging/comedi/comedidev.h
>> @@ -212,6 +212,8 @@ struct comedi_device {
>> * DMA_NONE */
>> struct device *hw_dev;
>>
>> +struct pci_dev *pcidev;
>
> No, the field above this, hw_dev, should be used instead here, as that's
> what it is there for, right?
The hw_dev pointer is currently only used for something dealing with dma.
I have not dug into it yet to see what exactly it's used for. The comment
says:
/* hw_dev is passed to dma_alloc_coherent when allocating async buffers
* for subdevices that have async_dma_dir set to something other than
* DMA_NONE */
> Care to rework this series with that change instead?
It could probably be used with some sort of container_of but I'm not sure.
Regards,
Hartley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
Hi Wen,
2012/07/17 10:44, Yasuaki Ishimatsu wrote:
> Hi Wen,
>
> 2012/07/13 12:35, Wen Congyang wrote:
>> At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
>>> acpi_memory_device_remove() has been prepared to remove physical memory.
>>> But, the function only frees acpi_memory_device currentlry.
>>>
>>> The patch adds following functions into acpi_memory_device_remove():
>>> - offline memory
>>> - remove physical memory (only return -EBUSY)
>>> - free acpi_memory_device
>>>
>>> CC: David Rientjes
>>> CC: Jiang Liu
>>> CC: Len Brown
>>> CC: Benjamin Herrenschmidt
>>> CC: Paul Mackerras
>>> CC: Christoph Lameter
>>> Cc: Minchan Kim
>>> CC: Andrew Morton
>>> CC: KOSAKI Motohiro
>>> CC: Wen Congyang
>>> Signed-off-by: Yasuaki Ishimatsu
>>>
>>> ---
>>>drivers/acpi/acpi_memhotplug.c | 26 +-
>>>drivers/base/memory.c | 39
>>> +++
>>>include/linux/memory.h |5 +
>>>include/linux/memory_hotplug.h |1 +
>>>mm/memory_hotplug.c|8
>>>5 files changed, 78 insertions(+), 1 deletion(-)
>>>
>>> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
>>> ===
>>> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
>>> 18:08:29.946888653 +0900
>>> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c2012-07-09
>>> 18:08:43.470719531 +0900
>>> @@ -29,6 +29,7 @@
>>>#include
>>>#include
>>>#include
>>> +#include
>>>#include
>>>#include
>>>#include
>>> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
>>>static int acpi_memory_device_remove(struct acpi_device *device, int
>>> type)
>>>{
>>> struct acpi_memory_device *mem_device = NULL;
>>> -
>>> + struct acpi_memory_info *info, *tmp;
>>> + int result;
>>> + int node;
>>>
>>> if (!device || !acpi_driver_data(device))
>>> return -EINVAL;
>>>
>>> mem_device = acpi_driver_data(device);
>>> +
>>> + node = acpi_get_node(mem_device->device->handle);
>>> +
>>> + list_for_each_entry_safe(info, tmp, _device->res_list, list) {
>>> + if (!info->enabled)
>>> + continue;
>>> +
>>> + if (!is_memblk_offline(info->start_addr, info->length)) {
>>> + result = offline_memory(info->start_addr, info->length);
>>> + if (result)
>>> + return result;
>>> + }
>>> +
>>> + result = remove_memory(node, info->start_addr, info->length);
>>
>> The user may online the memory between offline_memory() and remove_memory().
>> So I think we should lock memory hotplug before check the memory's status
>> and release it after remove_memory().
>
> How about get "mem_block->state_mutex" of removed memory? When offlining
> memory, we need to change "memory_block->state" into "MEM_OFFLINE".
> In this case, we get mem_block->state_mutex. So I think the mutex lock
> is beneficial.
It is not good idea since remove_memory frees mem_block structure...
Do you have any ideas?
Thanks,
Yasuaki Ishimatsu
> Thanks,
> Yasuaki Ishimatsu
>
>>
>> Thanks
>> Wen Congyang
>>
>>> + if (result)
>>> + return result;
>>> +
>>> + list_del(>list);
>>> + kfree(info);
>>> + }
>>> +
>>> kfree(mem_device);
>>>
>>> return 0;
>>> Index: linux-3.5-rc6/include/linux/memory_hotplug.h
>>> ===
>>> --- linux-3.5-rc6.orig/include/linux/memory_hotplug.h 2012-07-09
>>> 18:08:29.955888542 +0900
>>> +++ linux-3.5-rc6/include/linux/memory_hotplug.h2012-07-09
>>> 18:08:43.471719518 +0900
>>> @@ -233,6 +233,7 @@ static inline int is_mem_section_removab
>>>extern int mem_online_node(int nid);
>>>extern int add_memory(int nid, u64 start, u64 size);
>>>extern int arch_add_memory(int nid, u64 start, u64 size);
>>> +extern int remove_memory(int nid, u64 start, u64 size);
>>>extern int offline_memory(u64 start, u64 size);
>>>extern int sparse_add_one_section(struct zone *zone, unsigned long
>>> start_pfn,
>>> int nr_pages);
>>> Index: linux-3.5-rc6/mm/memory_hotplug.c
>>> ===
>>> --- linux-3.5-rc6.orig/mm/memory_hotplug.c 2012-07-09 18:08:29.953888567
>>> +0900
>>> +++ linux-3.5-rc6/mm/memory_hotplug.c 2012-07-09 18:08:43.476719455
>>> +0900
>>> @@ -659,6 +659,14 @@ out:
>>>}
>>>EXPORT_SYMBOL_GPL(add_memory);
>>>
>>> +int remove_memory(int nid, u64 start, u64 size)
>>> +{
>>> + return -EBUSY;
>>> +
>>> +}
>>> +EXPORT_SYMBOL_GPL(remove_memory);
>>> +
>>> +
>>>#ifdef CONFIG_MEMORY_HOTREMOVE
>>>/*
>>> * A free page on the buddy free lists (not the per-cpu lists) has
>>> PageBuddy
>>> Index:
Re: [PATCH 01/30] staging: comedi: add pci_dev pointer to comedi_device
On Wed, Jul 11, 2012 at 02:49:14PM -0700, H Hartley Sweeten wrote:
> The pci_dev pointer in the private driver data is used by every
> comedi pci driver. Some of them only have the need for the
> private data because of this pointer.
>
> Introduce the pci_dev pointer in the comedi_device struct so it
> can be used instead of needing it in the private data.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Ian Abbott
> Cc: Greg Kroah-Hartman
> ---
> drivers/staging/comedi/comedidev.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/comedi/comedidev.h
> b/drivers/staging/comedi/comedidev.h
> index de8c99c..55f2373 100644
> --- a/drivers/staging/comedi/comedidev.h
> +++ b/drivers/staging/comedi/comedidev.h
> @@ -212,6 +212,8 @@ struct comedi_device {
>* DMA_NONE */
> struct device *hw_dev;
>
> + struct pci_dev *pcidev;
No, the field above this, hw_dev, should be used instead here, as that's
what it is there for, right?
Care to rework this series with that change instead?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: move uevent call to driver_register
On Tue, Jul 17, 2012 at 09:35:02AM +0800, Ming Lei wrote: > On Tue, Jul 3, 2012 at 1:08 AM, Sebastian Ott > wrote: > > > --- a/drivers/base/driver.c > > +++ b/drivers/base/driver.c > > @@ -187,6 +187,9 @@ int driver_register(struct device_driver > > ret = driver_add_groups(drv, drv->groups); > > if (ret) > > bus_remove_driver(drv); > > + > > + kobject_uevent(>p->kobj, KOBJ_ADD); > > You should just send the uevent if 'ret' equals to zero., otherwise > OOPS may be triggered by kobject_uevent() after the 'drv' has been > removed. Ugh, just missed that. Sebastian, care to send a follow-on patch for this? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
Hi Wen,
2012/07/13 12:35, Wen Congyang wrote:
> At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
>> acpi_memory_device_remove() has been prepared to remove physical memory.
>> But, the function only frees acpi_memory_device currentlry.
>>
>> The patch adds following functions into acpi_memory_device_remove():
>>- offline memory
>>- remove physical memory (only return -EBUSY)
>>- free acpi_memory_device
>>
>> CC: David Rientjes
>> CC: Jiang Liu
>> CC: Len Brown
>> CC: Benjamin Herrenschmidt
>> CC: Paul Mackerras
>> CC: Christoph Lameter
>> Cc: Minchan Kim
>> CC: Andrew Morton
>> CC: KOSAKI Motohiro
>> CC: Wen Congyang
>> Signed-off-by: Yasuaki Ishimatsu
>>
>> ---
>> drivers/acpi/acpi_memhotplug.c | 26 +-
>> drivers/base/memory.c | 39
>> +++
>> include/linux/memory.h |5 +
>> include/linux/memory_hotplug.h |1 +
>> mm/memory_hotplug.c|8
>> 5 files changed, 78 insertions(+), 1 deletion(-)
>>
>> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
>> ===
>> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c2012-07-09
>> 18:08:29.946888653 +0900
>> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
>> 18:08:43.470719531 +0900
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
>> static int acpi_memory_device_remove(struct acpi_device *device, int type)
>> {
>> struct acpi_memory_device *mem_device = NULL;
>> -
>> +struct acpi_memory_info *info, *tmp;
>> +int result;
>> +int node;
>>
>> if (!device || !acpi_driver_data(device))
>> return -EINVAL;
>>
>> mem_device = acpi_driver_data(device);
>> +
>> +node = acpi_get_node(mem_device->device->handle);
>> +
>> +list_for_each_entry_safe(info, tmp, _device->res_list, list) {
>> +if (!info->enabled)
>> +continue;
>> +
>> +if (!is_memblk_offline(info->start_addr, info->length)) {
>> +result = offline_memory(info->start_addr, info->length);
>> +if (result)
>> +return result;
>> +}
>> +
>> +result = remove_memory(node, info->start_addr, info->length);
>
> The user may online the memory between offline_memory() and remove_memory().
> So I think we should lock memory hotplug before check the memory's status
> and release it after remove_memory().
How about get "mem_block->state_mutex" of removed memory? When offlining
memory, we need to change "memory_block->state" into "MEM_OFFLINE".
In this case, we get mem_block->state_mutex. So I think the mutex lock
is beneficial.
Thanks,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>
>> +if (result)
>> +return result;
>> +
>> +list_del(>list);
>> +kfree(info);
>> +}
>> +
>> kfree(mem_device);
>>
>> return 0;
>> Index: linux-3.5-rc6/include/linux/memory_hotplug.h
>> ===
>> --- linux-3.5-rc6.orig/include/linux/memory_hotplug.h2012-07-09
>> 18:08:29.955888542 +0900
>> +++ linux-3.5-rc6/include/linux/memory_hotplug.h 2012-07-09
>> 18:08:43.471719518 +0900
>> @@ -233,6 +233,7 @@ static inline int is_mem_section_removab
>> extern int mem_online_node(int nid);
>> extern int add_memory(int nid, u64 start, u64 size);
>> extern int arch_add_memory(int nid, u64 start, u64 size);
>> +extern int remove_memory(int nid, u64 start, u64 size);
>> extern int offline_memory(u64 start, u64 size);
>> extern int sparse_add_one_section(struct zone *zone, unsigned long
>> start_pfn,
>> int nr_pages);
>> Index: linux-3.5-rc6/mm/memory_hotplug.c
>> ===
>> --- linux-3.5-rc6.orig/mm/memory_hotplug.c 2012-07-09 18:08:29.953888567
>> +0900
>> +++ linux-3.5-rc6/mm/memory_hotplug.c2012-07-09 18:08:43.476719455
>> +0900
>> @@ -659,6 +659,14 @@ out:
>> }
>> EXPORT_SYMBOL_GPL(add_memory);
>>
>> +int remove_memory(int nid, u64 start, u64 size)
>> +{
>> +return -EBUSY;
>> +
>> +}
>> +EXPORT_SYMBOL_GPL(remove_memory);
>> +
>> +
>> #ifdef CONFIG_MEMORY_HOTREMOVE
>> /*
>>* A free page on the buddy free lists (not the per-cpu lists) has
>> PageBuddy
>> Index: linux-3.5-rc6/drivers/base/memory.c
>> ===
>> --- linux-3.5-rc6.orig/drivers/base/memory.c 2012-07-09 18:08:29.947888640
>> +0900
>> +++ linux-3.5-rc6/drivers/base/memory.c 2012-07-09 18:10:54.880076739
>> +0900
>> @@ -70,6 +70,45 @@ void unregister_memory_isolate_notifier(
>>
Re: [PATCH] driver core: move uevent call to driver_register
On Tue, Jul 3, 2012 at 1:08 AM, Sebastian Ott wrote: > --- a/drivers/base/driver.c > +++ b/drivers/base/driver.c > @@ -187,6 +187,9 @@ int driver_register(struct device_driver > ret = driver_add_groups(drv, drv->groups); > if (ret) > bus_remove_driver(drv); > + > + kobject_uevent(>p->kobj, KOBJ_ADD); You should just send the uevent if 'ret' equals to zero., otherwise OOPS may be triggered by kobject_uevent() after the 'drv' has been removed. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
