Re: [GIT PULL] PWM subsystem for v3.6
On Fri 27 Jul 2012 02:10:54 PM JST, Thierry Reding wrote: * PGP Signed by an unknown key On Thu, Jul 26, 2012 at 02:11:58PM -0700, Linus Torvalds wrote: On Thu, Jul 26, 2012 at 12:16 AM, Thierry Reding wrote: The new PWM subsystem aims at collecting all implementations of the legacy PWM API and to eventually replace it completely. The subsystem has been in development for over half a year now and many drivers have already been converted. It has been in linux-next for a couple of weeks and there have been no major issues so I think it is ready for inclusion in your tree. For new subsystems like this, I really want ack's from the people who are expected to use it. At least the patch that adds me as the maintainer is Acked-by: Sascha Hauer, who did the original work, and Arnd Bergmann who was involved in the review process. Other people such as Shawn Guo and Mark Brown have also been reviewing these patches and new patches have been contributed by Eric Bénard, Axel Lin, Sachin Kamat, Alexandre Courbot, Alexandre Pereira da Silva and Philip Avinash. I'm adding all of them on Cc so they can ack this (I'm assuming acking this email will suffice). Acked-by: Alexandre Courbot Tested-by: Alexandre Courbot I arrived too late to ack your patches, but if the practice is accepted please feel free to put these in the latest version of your pwm framework and pwm-backlight patches. Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [media] davinci: vpfe: Add documentation
Laurent,
Thank you for your comments.
On Thu, Jul 26, 2012 at 05:55:31, Laurent Pinchart wrote:
> Hi Manjunath,
>
> On Tuesday 17 July 2012 10:43:54 Hadli, Manjunath wrote:
> > On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
> > > On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
> > > > Add documentation on the Davinci VPFE driver. Document the subdevs,
> > > > and private IOTCLs the driver implements
> > > >
> > > > Signed-off-by: Manjunath Hadli
> > > > Signed-off-by: Lad, Prabhakar
>
> [snip]
>
> > > > +Private IOCTLs
> > > > +==
> > > > +
> > > > +The Davinci Video processing Front End (VPFE) driver supports standard
> > > > V4L2 +IOCTLs and controls where possible and practical. Much of the
> > > > functions provided
> > > > +by the VPFE, however, does not fall under the standard IOCTLs.
> > > > +
> > > > +In general, there is a private ioctl for configuring each of the blocks
> > > > +containing hardware-dependent functions.
> > > > +
> > > > +The following private IOCTLs are supported:
> > > > +
> > > > +1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
> > > > +Description:
> > > > + Sets/Gets the parameters required by the previewer module
> > > > +Parameter:
> > > > + /**
> > > > +* struct prev_module_param- structure to configure preview
> > > > modules
> > > > +* @version: Version of the preview module
> > >
> > > Who is responsible for filling this field, the application or the driver ?
> >
> > The application is responsible for filling this info. He would enumerate the
> > capabilities first and set them using S_PARAM/G_PARAM.
>
> And what's the point of the application setting the version field ? How does
> the driver use it ?
The version may not be required. Will remove it.
>
> > > > +* @len: Length of the module config structure
> > > > +* @module_id: Module id
> > > > +* @param: pointer to module config parameter.
> > >
> > > What is module_id for ? What does param point to ?
> >
> > There are a lot of tiny modules in the previewer/resizer which are
> > enumerated as individual modules. The param points to the parameter set
> > that the module expects to be set.
>
> Why don't you implement something similar to
> VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS instead ?
I feel if we implement direct IOCTLS there might be many of them. To make sure
than independent of the number of internal modules present, having the same
IOCTL used for all modules is a good idea.
>
> > > > +*/
> > > > + struct prev_module_param {
> > > > + char version[IMP_MAX_NAME_SIZE];
> > >
> > > Is there a need to express the version as a string instead of an integer ?
> >
> > It could be integer. It is generally a fixed point num, and easy to read it
> > as a string than an integer. Can I keep it as a string?
>
> Let's first decide whether a version field is needed at all :-)
Will remove.
>
> > > > + unsigned short len;
> > > > + unsigned short module_id;
> > > > + void *param;
> > > > + };
> > > > +
> > > > +2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
> > > > +Description:
> > > > + Sets/Gets the configuration required by the previewer channel
> > > > +Parameter:
> > > > + /**
> > > > +* struct prev_channel_config - structure for configuring the
> > > > previewer
> > > > channel
> > > > +* @len: Length of the user configuration
> > > > +* @config: pointer to either single shot config or continuous
> > > > +*/
> > > > + struct prev_channel_config {
> > > > + unsigned short len;
> > > > + void *config;
> > > > + };
> > >
> > > What's the difference between parameters and configuration ? What does
> > > config point to ?
> >
> > Config is setting which is required for a subdev to function based on what
> > it is set for (single shot/continuous.) common to all platforms. Parameters
> > are the settings for individual small sub-ips which might be slightly
> > different from one platform to another. Config points to
> > prev_single_shot_config or prev_continuous_config currently defined in
> > linux/dm3656ipipe.h. I think we will move it to a common location.
>
> Why don't you implement something similar to
> VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS here as well (same for
> the resizer configuration ioctls) ?
>
Ditto.
> > > > +
> > > > +3: IOCTL: PREV_ENUM_CAP
> > > > +Description:
> > > > + Queries the modules available in the image processor for
> > > > preview the
> > > > + input image.
> > > > +Parameter:
> > > > + /**
> > > > +* struct prev_cap - structure to enumerate capabilities of
> > > > previewer
> > > > +* @index: application use this to iterate over the available
> > > > modules
> > > > +* @version: version of the preview module
> > > > +* @module_id: module id
> > > > +*
Re: [GIT PULL (PATCH 0/4)] VFIO driver for v3.6
On Wed, Jul 25, 2012 at 08:53:06AM -0600, Alex Williamson wrote: > Hi Linus, > > This series includes the VFIO userspace driver interface for the > 3.6 kernel merge window. This driver is intended to provide a > secure interface for device access using IOMMU protection for > applications like assignment of physical devices to virtual > machines. Qemu will be the first user of this interface, enabling > assignment of PCI devices to Qemu guests. This interface is > intended to eventually replace the x86-specific assignment mechanism > currently available in KVM. This interface has the advantage of > being more secure, by working with IOMMU groups to ensure device > isolation and providing it's own filtered resource access mechanism, > and also more flexible, in not being x86 or KVM specific (extensions > to enable POWER are already working). > > As a new driver, I'm including both the individual patches in email, > as well as a branch to pull from: > > git://github.com/awilliam/linux-vfio.git for-linus > > This driver is originally the work of Tom Lyon, but has since been > handed over to me and gone through a complete overhaul thanks to the > input from David Gibson, Ben Herrenschmidt, Chris Wright, Joerg > Roedel, and others. This driver has been available in linux-next for > the last month. Thanks, Linus, Are you thinking of pulling this driver in for 3.6? I would be glad to see it go in since we want to use it with KVM on PowerPC. If possible we'd like the PowerPC bits for it to go in as well. 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: [GIT PULL] PWM subsystem for v3.6
On Thu, Jul 26, 2012 at 02:11:58PM -0700, Linus Torvalds wrote: > On Thu, Jul 26, 2012 at 12:16 AM, Thierry Reding > wrote: > > > > The new PWM subsystem aims at collecting all implementations of the > > legacy PWM API and to eventually replace it completely. The subsystem > > has been in development for over half a year now and many drivers have > > already been converted. It has been in linux-next for a couple of weeks > > and there have been no major issues so I think it is ready for inclusion > > in your tree. > > For new subsystems like this, I really want ack's from the people who > are expected to use it. At least the patch that adds me as the maintainer is Acked-by: Sascha Hauer, who did the original work, and Arnd Bergmann who was involved in the review process. Other people such as Shawn Guo and Mark Brown have also been reviewing these patches and new patches have been contributed by Eric Bénard, Axel Lin, Sachin Kamat, Alexandre Courbot, Alexandre Pereira da Silva and Philip Avinash. I'm adding all of them on Cc so they can ack this (I'm assuming acking this email will suffice). > For a gitorious pull like this, I also want signed tags with the gpg > key having signatures from people I recognize. I don't think I have > such a key from you. Right. I don't have any signatures on my GPG key, but I'm not aware of any kernel developers in my area and unfortunately I don't get around much either. I can request key-signing via us...@kernel.org and see if I missed anyone. I think that is the correct mailing list? I remember reading about it a while back but I can't find the link anymore. Thierry pgpJbpcjzP8Lw.pgp Description: PGP signature
Re: [PATCH] staging/olpc_dcon: fix checkpatch warnings
On Fri, Jul 27, 2012 at 2:03 PM, Joe Perches wrote:
> On Fri, 2012-07-27 at 13:46 +0900, Toshiaki Yamane wrote:
>> fixed some checkpatch warnings.
>> (Excluding -WARNING: msleep < 20ms can sleep for up to 20ms-)
> []
>> diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
>> b/drivers/staging/olpc_dcon/olpc_dcon.c
> []
>> @@ -71,18 +72,18 @@ static int dcon_hw_init(struct dcon_priv *dcon, int
>> is_init)
>>
>> ver = dcon_read(dcon, DCON_REG_ID);
>> if ((ver >> 8) != 0xDC) {
>> - printk(KERN_ERR "olpc-dcon: DCON ID not 0xDCxx: 0x%04x
>> instead.\n",
>> - ver);
>> + pr_err("DCON ID not 0xDCxx: 0x%04x instead.\n",
>> +ver);
>
> Please fit arguments on a single line where feasible.
I agree.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/olpc_dcon: fix checkpatch warnings
On Fri, 2012-07-27 at 13:46 +0900, Toshiaki Yamane wrote:
> fixed some checkpatch warnings.
> (Excluding -WARNING: msleep < 20ms can sleep for up to 20ms-)
[]
> diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
> b/drivers/staging/olpc_dcon/olpc_dcon.c
[]
> @@ -71,18 +72,18 @@ static int dcon_hw_init(struct dcon_priv *dcon, int
> is_init)
>
> ver = dcon_read(dcon, DCON_REG_ID);
> if ((ver >> 8) != 0xDC) {
> - printk(KERN_ERR "olpc-dcon: DCON ID not 0xDCxx: 0x%04x
> instead.\n",
> - ver);
> + pr_err("DCON ID not 0xDCxx: 0x%04x instead.\n",
> +ver);
Please fit arguments on a single line where feasible.
pr_err("DCON ID not 0xDCxx: 0x%04x instead.\n", ver);
[]
> @@ -231,7 +232,7 @@ static void dcon_sleep(struct dcon_priv *dcon, bool sleep)
> dcon->disp_mode |= MODE_BL_ENABLE;
> x = dcon_bus_stabilize(dcon, 1);
> if (x)
> - printk(KERN_WARNING "olpc-dcon: unable to reinit dcon
> hardware: %d!\n",
> + pr_warn("unable to reinit dcon hardware: %d!\n",
> x);
pr_warn("unable to reinit dcon hardware: %d!\n", x);
etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] charger-manager: Disable regulator for charging when charger cable is detached
This patch disable regulator for charging when charger cable is detached
before stopping charging forcibly on abnormal battery state and check
return value of regulator_enable/disable() function to confirm correct
operation of enabling or disabling regulator for charging.
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
Signed-off-by: Kyungmin Park
---
drivers/power/charger-manager.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 526e5c9..240de49 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -271,9 +271,24 @@ static int try_charger_enable(struct charger_manager *cm,
bool enable)
if (enable) {
if (cm->emergency_stop)
return -EAGAIN;
- for (i = 0 ; i < desc->num_charger_regulators ; i++)
- regulator_enable(desc->charger_regulators[i].consumer);
+ for (i = 0 ; i < desc->num_charger_regulators ; i++) {
+ err =
regulator_enable(desc->charger_regulators[i].consumer);
+ if (err < 0) {
+ dev_warn(cm->dev,
+ "Cannot enable %s regulator\n",
+
desc->charger_regulators[i].regulator_name);
+ }
+ }
} else {
+ for (i = 0 ; i < desc->num_charger_regulators ; i++) {
+ err =
regulator_disable(desc->charger_regulators[i].consumer);
+ if (err < 0) {
+ dev_warn(cm->dev,
+ "Cannot disable %s regulator\n",
+
desc->charger_regulators[i].regulator_name);
+ }
+ }
+
/*
* Abnormal battery state - Stop charging forcibly,
* even if charger was enabled at the other places
--
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 0/2] charger-manager: Stop charging when charge cable is detached and code clean
This patchset fix bug related to stop charging when charger cable is detached and check return value of regulator_enable/disable() function to confirm correct operation of enabled or disabling regulator for charging. Second patch is code clean which remove unnecessary variable type. Chanwoo Choi (2): charger-manager: Disable regulator for charging when charger cable is detached charger-manager: Use replacement variable to check state of battery drivers/power/charger-manager.c | 21 ++--- include/linux/power/charger-manager.h |3 --- 2 files changed, 18 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] charger-manager: Use replacement variable to check state of battery
This patch remove unnecessary variable(cm->fullbatt_vchk_uV) by using
'desc->fullbatt_uV' field directly in fullbatt_handler() function
to check the state of battery.
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
Signed-off-by: Kyungmin Park
---
drivers/power/charger-manager.c |2 +-
include/linux/power/charger-manager.h |3 ---
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 240de49..cdf29d2 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -415,7 +415,7 @@ static void fullbatt_vchk(struct work_struct *work)
return;
}
- diff = cm->fullbatt_vchk_uV;
+ diff = desc->fullbatt_uV;
diff -= batt_uV;
dev_dbg(cm->dev, "VBATT dropped %duV after full-batt.\n", diff);
diff --git a/include/linux/power/charger-manager.h
b/include/linux/power/charger-manager.h
index cd22029..7d7b90f 100644
--- a/include/linux/power/charger-manager.h
+++ b/include/linux/power/charger-manager.h
@@ -194,8 +194,6 @@ struct charger_desc {
* @charger_enabled: the state of charger
* @fullbatt_vchk_jiffies_at:
* jiffies at the time full battery check will occur.
- * @fullbatt_vchk_uV: voltage in microvolt
- * criteria for full battery
* @fullbatt_vchk_work: work queue for full battery check
* @emergency_stop:
* When setting true, stop charging
@@ -218,7 +216,6 @@ struct charger_manager {
bool charger_enabled;
unsigned long fullbatt_vchk_jiffies_at;
- unsigned int fullbatt_vchk_uV;
struct delayed_work fullbatt_vchk_work;
int emergency_stop;
--
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] staging/olpc_dcon: fix checkpatch warnings
fixed some checkpatch warnings.
(Excluding -WARNING: msleep < 20ms can sleep for up to 20ms-)
$ find drivers/staging/olpc_dcon/ -name "*.[ch]"|xargs ./scripts/checkpatch.pl \
-f --terse --nosummary|cut -f3- -d":"|sort |uniq -c|sort -n
2 WARNING: msleep < 20ms can sleep for up to 20ms; see
Documentation/timers/timers-howto.txt
3 WARNING: Prefer pr_debug(... to printk(KERN_DEBUG, ...
3 WARNING: Prefer pr_warn(... to printk(KERN_WARNING, ...
6 WARNING: Prefer pr_info(... to printk(KERN_INFO, ...
19 WARNING: Prefer pr_err(... to printk(KERN_ERR, ...
And added pr_fmt.
Signed-off-by: Toshiaki Yamane
---
drivers/staging/olpc_dcon/olpc_dcon.c| 52 +-
drivers/staging/olpc_dcon/olpc_dcon_xo_1.c | 15 ---
drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c |6 ++-
3 files changed, 39 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
b/drivers/staging/olpc_dcon/olpc_dcon.c
index 992275c..f092c80 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -11,6 +11,7 @@
* License as published by the Free Software Foundation.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
#include
@@ -71,18 +72,18 @@ static int dcon_hw_init(struct dcon_priv *dcon, int is_init)
ver = dcon_read(dcon, DCON_REG_ID);
if ((ver >> 8) != 0xDC) {
- printk(KERN_ERR "olpc-dcon: DCON ID not 0xDCxx: 0x%04x
instead.\n",
- ver);
+ pr_err("DCON ID not 0xDCxx: 0x%04x instead.\n",
+ ver);
rc = -ENXIO;
goto err;
}
if (is_init) {
- printk(KERN_INFO "olpc-dcon: Discovered DCON version %x\n",
- ver & 0xFF);
+ pr_info("Discovered DCON version %x\n",
+ ver & 0xFF);
rc = pdata->init(dcon);
if (rc != 0) {
- printk(KERN_ERR "olpc-dcon: Unable to init.\n");
+ pr_err("Unable to init.\n");
goto err;
}
}
@@ -136,7 +137,7 @@ power_up:
x = 1;
x = olpc_ec_cmd(0x26, (unsigned char *), 1, NULL, 0);
if (x) {
- printk(KERN_WARNING "olpc-dcon: unable to force dcon
to power up: %d!\n",
+ pr_warn("unable to force dcon to power up: %d!\n",
x);
return x;
}
@@ -150,7 +151,7 @@ power_up:
x = dcon_read(dcon, DCON_REG_ID);
}
if (x < 0) {
- printk(KERN_ERR "olpc-dcon: unable to stabilize dcon's smbus,
reasserting power and praying.\n");
+ pr_err("unable to stabilize dcon's smbus, reasserting power and
praying.\n");
BUG_ON(olpc_board_at_least(olpc_board(0xc2)));
x = 0;
olpc_ec_cmd(0x26, (unsigned char *), 1, NULL, 0);
@@ -221,7 +222,7 @@ static void dcon_sleep(struct dcon_priv *dcon, bool sleep)
x = 0;
x = olpc_ec_cmd(0x26, (unsigned char *), 1, NULL, 0);
if (x)
- printk(KERN_WARNING "olpc-dcon: unable to force dcon
to power down: %d!\n",
+ pr_warn("unable to force dcon to power down: %d!\n",
x);
else
dcon->asleep = sleep;
@@ -231,7 +232,7 @@ static void dcon_sleep(struct dcon_priv *dcon, bool sleep)
dcon->disp_mode |= MODE_BL_ENABLE;
x = dcon_bus_stabilize(dcon, 1);
if (x)
- printk(KERN_WARNING "olpc-dcon: unable to reinit dcon
hardware: %d!\n",
+ pr_warn("unable to reinit dcon hardware: %d!\n",
x);
else
dcon->asleep = sleep;
@@ -303,12 +304,11 @@ static void dcon_source_switch(struct work_struct *work)
switch (source) {
case DCON_SOURCE_CPU:
- printk(KERN_INFO "dcon_source_switch to CPU\n");
+ pr_info("dcon_source_switch to CPU\n");
/* Enable the scanline interrupt bit */
if (dcon_write(dcon, DCON_REG_MODE,
dcon->disp_mode | MODE_SCAN_INT))
- printk(KERN_ERR
- "olpc-dcon: couldn't enable scanline
interrupt!\n");
+ pr_err("couldn't enable scanline interrupt!\n");
else {
/* Wait up to one second for the scanline interrupt */
wait_event_timeout(dcon_wait_queue,
@@ -316,11 +316,11 @@ static void dcon_source_switch(struct work_struct *work)
}
if (!dcon->switched)
-
[PATCHv3] locks: prevent side-effects of locks_release_private before file_lock is initialized
When calling fcntl(fd, F_SETLEASE, lck) [with lck=F_WRLCK or F_RDLCK],
the custom signal or owner (if any were previously set using F_SETSIG
or F_SETOWN fcntls) would be reset when F_SETLEASE was called for the
second time on the same file descriptor.
This bug is a regression of 2.6.37 and is described here:
https://bugzilla.kernel.org/show_bug.cgi?id=43336
This patch reverts a commit from Oct 2004 (with subject "nfs4 lease:
move the f_delown processing") which originally introduced the
lm_release_private callback.
Signed-off-by: Filipe Brandenburger
---
fs/locks.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 82c3533..6595882 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -427,18 +427,8 @@ static void lease_break_callback(struct file_lock *fl)
kill_fasync(>fl_fasync, SIGIO, POLL_MSG);
}
-static void lease_release_private_callback(struct file_lock *fl)
-{
- if (!fl->fl_file)
- return;
-
- f_delown(fl->fl_file);
- fl->fl_file->f_owner.signum = 0;
-}
-
static const struct lock_manager_operations lease_manager_ops = {
.lm_break = lease_break_callback,
- .lm_release_private = lease_release_private_callback,
.lm_change = lease_modify,
};
@@ -1155,8 +1145,13 @@ int lease_modify(struct file_lock **before, int arg)
return error;
lease_clear_pending(fl, arg);
locks_wake_up_blocks(fl);
- if (arg == F_UNLCK)
+ if (arg == F_UNLCK) {
+ struct file *filp = fl->fl_file;
+
+ f_delown(filp);
+ filp->f_owner.signum = 0;
locks_delete_lock(before);
+ }
return 0;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here's a handful of powerpc patches, a couple of regression fixes for problems introduced in the main batch in this merge window, a couple of defconfig updates, and some trivials. The radeonfb one is something that was long standing in SLES which I forgot to pickup earlier. Cheers, Ben. The following changes since commit bdc0077af574800d24318b6945cf2344e8dbb050: Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2012-07-24 18:11:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to bac821a6e3404330d509fd3a245bf7701f210c7c: powerpc/ftrace: Trace function graph entry before updating index (2012-07-27 11:42:34 +1000) Alexander Graf (1): powerpc/kvm/bookehv: Fix build regression Anton Blanchard (2): powerpc: Enable pseries hardware RNG and crypto modules powerpc: Lack of firmware flash support is not an error Benjamin Herrenschmidt (1): powerpc: Update g5_defconfig Steven Rostedt (1): powerpc/ftrace: Trace function graph entry before updating index Stuart Yoder (1): powerpc: Set stack limit properly in crit_transfer_to_handler Tony Breeds (1): radeonfb: Add quirk for the graphics adapter in some JSxx arch/powerpc/configs/g5_defconfig | 103 ++-- arch/powerpc/configs/ppc64_defconfig |6 +- arch/powerpc/configs/pseries_defconfig |6 +- arch/powerpc/kernel/entry_32.S | 12 +++- arch/powerpc/kernel/ftrace.c | 11 ++-- arch/powerpc/kernel/rtas_flash.c |2 +- arch/powerpc/kvm/bookehv_interrupts.S | 77 drivers/video/aty/radeon_monitor.c | 35 +++ 8 files changed, 128 insertions(+), 124 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/
[PULL] trivial comment changes, init and cpumask.
The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c: Linux 3.5-rc7 (2012-07-14 15:40:28 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git tags/cpumask-for-linus for you to fetch changes up to 231daf0751ccaf21373f591c524a3f557a15d03f: cpumask: cpulist_parse() comments correction (2012-07-27 09:29:42 +0930) Trivial comment changes to cpumask code. I guess it's getting boring. Alex Shi (2): cpumask: add a few comments of cpumask functions cpumask: cpulist_parse() comments correction Jim Cromie (1): init: add comments to keep initcall-names in sync with initcall levels include/linux/cpumask.h | 15 +-- include/linux/init.h|3 ++- init/main.c |1 + 3 files changed, 16 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 3/3] virtio-blk: Add bio-based IO path for virtio-blk
On Fri, 13 Jul 2012 16:38:51 +0800, Asias He wrote: > Add 'virtio_blk.use_bio=1' to kernel cmdline or 'modprobe virtio_blk > use_bio=1' to enable ->make_request_fn() based I/O path. This patch conflicts with Paolo's Bonzini's 'virtio-blk: allow toggling host cache between writeback and writethrough' which is also queued (see linux-next). I'm not sure what the correct behavior for bio & cacheflush is, if any. But as to the patch itself: it's a hack. 1) Leaving the guest's admin to turn on the switch is a terrible choice. 2) The block layer should stop merging and sorting when a device is fast, not the driver. 3) I pointed out that slow disks have low IOPS, so why is this conditional? Sure, more guest exits, but it's still a small number for a slow device. 4) The only case where we want merging is on a slow device when the host isn't doing it. Now, despite this, I'm prepared to commit it. But in my mind it's a hack: we should aim for use_bio to be based on a feature bit fed from the host, and use the module parameter only if we want to override it. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for July 27
Hi all, Please do not add anything to linux-next included branches/series that is destined for v3.7 until after v3.6-rc1 is released. Reminder: do not rebase your branches before asking Linus to pull them ... Changes since 20120726: Linus' tree gained a build failure for which I applied a patch. The acpi tree lost its conflict. The drm tree lost its conflict. The tty tree still has its build failures for which I have disabled 2 staging drivers and applied a patch. The usb tree lost its conflict. The staging tree lost its conflicts. The remoteproc tree lost its conflict. the gpio-lw tree lost its conflict. I have still reverted 3 commits from the signal tree at the request of the arm maintainer. The akpm tree gained conflicts against Linus' tree and the tip tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 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 (a9197f9 Merge tag 'remoteproc-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Applying: Btrfs: using vrmzalloc and friends needs vmalloc.h 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 (1525e06 m68k/apollo: Rename "timer" to "apollo_timer") Merging powerpc-merge/merge (50fb31c tty/hvc_opal: Fix debug function name) Merging sparc/master (427f23c sparc32, copy_thread: Clear TIF_USEDFPU flag of created task instead of current) Merging net/master (c710998 ipv6: Early TCP socket demux) Merging sound-current/for-linus (f2ad24f ALSA: hda - Detach from converter at closing in patch_hdmi.c) 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 (9dbf5f5 bcma: add missing iounmap on error path) Merging driver-core.current/driver-core-linus (84a1caf Linux 3.5-rc7) 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 (314820c Merge branch 'next' into for-linus) Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (a434788 crypto: twofish-avx - remove useless instruction) 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-cu
Re: [PATCH] leds: triggers: send uevent when changing triggers
On Fri, Jul 27, 2012 at 12:51 AM, Greg KH wrote:
> On Thu, Jul 26, 2012 at 01:03:11PM +0800, Bryan Wu wrote:
>> Just one quick patch for my idea: emitting a uevent in sysfs_create_file().
>>
>> --
>> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
>> index 00012e3..04da869 100644
>> --- a/fs/sysfs/file.c
>> +++ b/fs/sysfs/file.c
>> @@ -570,10 +570,14 @@ int sysfs_add_file(struct sysfs_dirent *dir_sd,
>> const struct attribute *attr,
>>
>> int sysfs_create_file(struct kobject * kobj, const struct attribute * attr)
>> {
>> + int err = 0;
>> +
>> BUG_ON(!kobj || !kobj->sd || !attr);
>>
>> - return sysfs_add_file(kobj->sd, attr, SYSFS_KOBJ_ATTR);
>> + err = sysfs_add_file(kobj->sd, attr, SYSFS_KOBJ_ATTR);
>> + kobject_uevent(kobj, KOBJ_CHANGE);
>
> That's a veritable flood of change events when a new kobject is created,
> right? It also created uevents for a device that has not told userspace
> that it is even present, which could cause massive confusion, don't you
> think?
>
Indeed, this is unacceptable. I reworked a new patchset and just sent
our for you review.
Thanks,
-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add Etron XHCI quirk to avoid warning spam
When various USB3 devices with Etron XHCI controllers, we see a bunch of
warnings:
xhci_hcd :02:00.0: WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk?
Acknowledge the issue by adding the quirk.
Signed-off-by: Daniel J Blueman
---
drivers/usb/host/xhci-pci.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 18b231b..715ad11 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -95,10 +95,13 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
xhci->limit_active_eps = 64;
xhci->quirks |= XHCI_SW_BW_CHECKING;
}
- if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
- pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
- xhci->quirks |= XHCI_RESET_ON_RESUME;
- xhci_dbg(xhci, "QUIRK: Resetting on resume\n");
+ if (pdev->vendor == PCI_VENDOR_ID_ETRON) {
+ xhci->quirks |= XHCI_TRUST_TX_LENGTH;
+
+ if (pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
+ xhci->quirks |= XHCI_RESET_ON_RESUME;
+ xhci_dbg(xhci, "QUIRK: Resetting on resume\n");
+ }
}
if (pdev->vendor == PCI_VENDOR_ID_VIA)
xhci->quirks |= XHCI_RESET_ON_RESUME;
--
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 3/3] ledtrig-timer: convert to use device_create_file_uevent API
To send KOBJ_CHANGE uevent to userspace which is required by Android Signed-off-by: Bryan Wu --- drivers/leds/ledtrig-timer.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/leds/ledtrig-timer.c b/drivers/leds/ledtrig-timer.c index 9010f7a..d8b6296 100644 --- a/drivers/leds/ledtrig-timer.c +++ b/drivers/leds/ledtrig-timer.c @@ -78,10 +78,12 @@ static void timer_trig_activate(struct led_classdev *led_cdev) led_cdev->trigger_data = NULL; - rc = device_create_file(led_cdev->dev, _attr_delay_on); + rc = device_create_file_uevent(led_cdev->dev, _attr_delay_on, + "TRIGGER=timer", KOBJ_CHANGE); if (rc) return; - rc = device_create_file(led_cdev->dev, _attr_delay_off); + rc = device_create_file_uevent(led_cdev->dev, _attr_delay_off, + "TRIGGER=timer", KOBJ_CHANGE); if (rc) goto err_out_delayon; -- 1.7.11.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] drivers: add a new device_create_file_uevent API
This will use sysfs_create_file_uevent to create a sysfs file and send out
a uevent to userspace application such as udev.
Signed-off-by: Bryan Wu
---
drivers/base/core.c| 19 +++
include/linux/device.h | 4
2 files changed, 23 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 346be8b..62fd266 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -538,6 +538,25 @@ int device_create_file(struct device *dev,
}
/**
+ * device_create_file_uevent - create sysfs attribute file for device
+ * and send a uevent to userspace.
+ * @dev: device.
+ * @attr: device attribute descriptor.
+ * @desc: description about the uevent.
+ * @action: kobject uevent action type.
+ */
+int device_create_file_uevent(struct device *dev,
+ const struct device_attribute *attr,
+ const char *desc,
+ enum kobject_action action)
+{
+ int error = 0;
+ if (dev)
+ error = sysfs_create_file_uevent(>kobj, >attr,
+desc, action);
+ return error;
+}
+/**
* device_remove_file - remove sysfs attribute file.
* @dev: device.
* @attr: device attribute descriptor.
diff --git a/include/linux/device.h b/include/linux/device.h
index 6de9415..d1545f3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -510,6 +510,10 @@ ssize_t device_store_int(struct device *dev, struct
device_attribute *attr,
extern int device_create_file(struct device *device,
const struct device_attribute *entry);
+extern int device_create_file_uevent(struct device *dev,
+ const struct device_attribute *attr,
+ const char *desc,
+ enum kobject_action action);
extern void device_remove_file(struct device *dev,
const struct device_attribute *attr);
extern int __must_check device_create_bin_file(struct device *dev,
--
1.7.11.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] sysfs: introduce a sysfs_create_file_uevent new API
Send a uevent notification whenever a new sysfs file is created to allow
userspace processes such as udev to modify permissions on the new files.
This new API function helps to do this.
Signed-off-by: Bryan Wu
---
fs/sysfs/file.c | 28
include/linux/sysfs.h | 13 +
2 files changed, 41 insertions(+)
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 00012e3..5a22d13 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -576,6 +576,34 @@ int sysfs_create_file(struct kobject * kobj, const struct
attribute * attr)
}
+/**
+ * sysfs_create_file_uevent - create an attribute file for an object
+ and send a uevent to userspace.
+ * @kobj: object we're creating for.
+ * @attr: attribute descriptor.
+ * @desc: description about the uevent.
+ * @action: kobject uevent action type.
+ */
+
+int sysfs_create_file_uevent(struct kobject *kobj, const struct attribute
*attr,
+ const char *desc, enum kobject_action action)
+{
+ int err = 0;
+ char *envp[2];
+
+ BUG_ON(!kobj || !kobj->sd || !attr || !desc);
+
+ err = sysfs_add_file(kobj->sd, attr, SYSFS_KOBJ_ATTR);
+
+ if (desc) {
+ envp[0] = desc;
+ envp[1] = NULL;
+ kobject_uevent_env(kobj, action, envp);
+ }
+
+ return err;
+}
+
int sysfs_create_files(struct kobject *kobj, const struct attribute **ptr)
{
int err = 0;
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 381f06d..0054d41 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -22,6 +22,7 @@
struct kobject;
struct module;
enum kobj_ns_type;
+enum kobject_action;
struct attribute {
const char *name;
@@ -142,6 +143,10 @@ int __must_check sysfs_move_dir(struct kobject *kobj,
int __must_check sysfs_create_file(struct kobject *kobj,
const struct attribute *attr);
+int __must_check sysfs_create_file_uevent(struct kobject * kobj,
+ const struct attribute * attr,
+ const char * desc,
+ enum kobject_action action);
int __must_check sysfs_create_files(struct kobject *kobj,
const struct attribute **attr);
int __must_check sysfs_chmod_file(struct kobject *kobj,
@@ -226,6 +231,14 @@ static inline int sysfs_create_file(struct kobject *kobj,
return 0;
}
+static inline int sysfs_create_file_uevent(struct kobject * kobj,
+ const struct attribute * attr,
+ const char *desc,
+ enum kobject_action action)
+{
+ return 0;
+}
+
static inline int sysfs_create_files(struct kobject *kobj,
const struct attribute **attr)
{
--
1.7.11.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] add new API to sysfs and device core code
Send out a uevent when create file in sysfs, which is required by userspace application such udev in Android Bryan Wu (3): sysfs: introduce a sysfs_create_file_uevent new API drivers: add a new device_create_file_uevent API ledtrig-timer: convert to use device_create_file_uevent API drivers/base/core.c | 19 +++ drivers/leds/ledtrig-timer.c | 6 -- fs/sysfs/file.c | 28 include/linux/device.h | 4 include/linux/sysfs.h| 13 + 5 files changed, 68 insertions(+), 2 deletions(-) -- 1.7.11.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: efi, x86, pci: Improve graphics support on some Apple hardware
On Thu, Jul 26, 2012 at 06:02:45PM -0400, Matthew Garrett wrote: > Some Apple machines only provide their video ROM via an EFI-specific mechanism > and don't permit it to be retrieved from the BAR. Add infrastructure to stash > it and provide access to drivers. I've verified that these patches produce funtioning radeon graphics on both the Macbook Pro 8,2 and Mac Mini 5,2 under native EFI boot. Previously the radeon driver did not work on these machines due to failure to locate the video ROM. So for the whole series: Tested-by: Seth Forshee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] watchdog: watchdog-test: make term() static
On Thu, Jul 26, 2012 at 8:52 PM, Jerry Snitselaar wrote:
> In 3.5 warning during build 'no previous prototype for term'. Since it
> is only used in watchdog-test.c make term() static.
>
> Signed-off-by: Jerry Snitselaar
> ---
> Documentation/watchdog/src/watchdog-test.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/watchdog/src/watchdog-test.c
> b/Documentation/watchdog/src/watchdog-test.c
> index 73ff5cc..3da8229 100644
> --- a/Documentation/watchdog/src/watchdog-test.c
> +++ b/Documentation/watchdog/src/watchdog-test.c
> @@ -31,7 +31,7 @@ static void keep_alive(void)
> * or "-e" to enable the card.
> */
>
> -void term(int sig)
> +static void term(int sig)
> {
> close(fd);
> fprintf(stderr, "Stopping watchdog ticks...\n");
> --
> 1.7.12.rc0
>
Disregard this patch. I didn't see Randy's patch when I did a search
in my email.
Jerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 akpm tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
fs/btrfs/relocation.c between commit 23291a044c31 ("Btrfs: fix error
handling in __add_reloc_root()") from Linus' tree and commit "btrfs: use
printk_get_level and printk_skip_level, add __printf, fix fallout" from
the akpm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/btrfs/relocation.c
index c5dbd91,790f492..000
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@@ -1239,11 -1239,10 +1239,11 @@@ static int __must_check __add_reloc_roo
node->bytenr, >rb_node);
spin_unlock(>reloc_root_tree.lock);
if (rb_node) {
- kfree(node);
btrfs_panic(root->fs_info, -EEXIST, "Duplicate root found "
"for start=%llu while inserting into relocation "
- "tree\n");
+ "tree\n", node->bytenr);
+ kfree(node);
+ return -EEXIST;
}
list_add_tail(>root_list, >reloc_roots);
pgpKpbPbZT4Kk.pgp
Description: PGP signature
[PATCH 1/2] perf/x86: Fixes for Nehalem-EX uncore driver
From: "Yan, Zheng"
This patch includes following fixes and update:
- Only some events in the Sbox and Mbox can use the match/mask
registers, add code to check this.
- The format definitions for xbr_mm_cfg and xbr_match registers
in the Rbox are wrong, xbr_mm_cfg should use 32 bits, xbr_match
should use 64 bits.
- Cleanup the Rbox code. Compute the addresses extra registers in
the enable_event function instead of the hw_config function.
This simplifies the code in nhmex_rbox_alter_er().
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 195 --
arch/x86/kernel/cpu/perf_event_intel_uncore.h | 1 +
2 files changed, 87 insertions(+), 109 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 7563fda..5750142 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -796,7 +796,6 @@ static struct intel_uncore_type *nhm_msr_uncores[] = {
DEFINE_UNCORE_FORMAT_ATTR(event5, event, "config:1-5");
DEFINE_UNCORE_FORMAT_ATTR(counter, counter, "config:6-7");
-DEFINE_UNCORE_FORMAT_ATTR(mm_cfg, mm_cfg, "config:63");
DEFINE_UNCORE_FORMAT_ATTR(match, match, "config1:0-63");
DEFINE_UNCORE_FORMAT_ATTR(mask, mask, "config2:0-63");
@@ -1032,24 +1031,22 @@ static struct intel_uncore_type nhmex_uncore_bbox = {
static int nhmex_sbox_hw_config(struct intel_uncore_box *box, struct
perf_event *event)
{
- struct hw_perf_event_extra *reg1 = >hw.extra_reg;
- struct hw_perf_event_extra *reg2 = >hw.branch_reg;
+ struct hw_perf_event *hwc = >hw;
+ struct hw_perf_event_extra *reg1 = >extra_reg;
+ struct hw_perf_event_extra *reg2 = >branch_reg;
- if (event->attr.config & NHMEX_S_PMON_MM_CFG_EN) {
- reg1->config = event->attr.config1;
- reg2->config = event->attr.config2;
- } else {
- reg1->config = ~0ULL;
- reg2->config = ~0ULL;
- }
+ /* only TO_R_PROG_EV event uses the match/mask register */
+ if ((hwc->config & NHMEX_PMON_CTL_EV_SEL_MASK) !=
+ NHMEX_S_EVENT_TO_R_PROG_EV)
+ return 0;
if (box->pmu->pmu_idx == 0)
reg1->reg = NHMEX_S0_MSR_MM_CFG;
else
reg1->reg = NHMEX_S1_MSR_MM_CFG;
-
reg1->idx = 0;
-
+ reg1->config = event->attr.config1;
+ reg2->config = event->attr.config2;
return 0;
}
@@ -1059,8 +1056,8 @@ static void nhmex_sbox_msr_enable_event(struct
intel_uncore_box *box, struct per
struct hw_perf_event_extra *reg1 = >extra_reg;
struct hw_perf_event_extra *reg2 = >branch_reg;
- wrmsrl(reg1->reg, 0);
- if (reg1->config != ~0ULL || reg2->config != ~0ULL) {
+ if (reg1->idx != EXTRA_REG_NONE) {
+ wrmsrl(reg1->reg, 0);
wrmsrl(reg1->reg + 1, reg1->config);
wrmsrl(reg1->reg + 2, reg2->config);
wrmsrl(reg1->reg, NHMEX_S_PMON_MM_CFG_EN);
@@ -1074,7 +1071,6 @@ static struct attribute *nhmex_uncore_sbox_formats_attr[]
= {
_attr_edge.attr,
_attr_inv.attr,
_attr_thresh8.attr,
- _attr_mm_cfg.attr,
_attr_match.attr,
_attr_mask.attr,
NULL,
@@ -1264,7 +1260,8 @@ again:
}
/* for the match/mask registers */
- if ((uncore_box_is_fake(box) || !reg2->alloc) &&
+ if (reg2->idx != EXTRA_REG_NONE &&
+ (uncore_box_is_fake(box) || !reg2->alloc) &&
!nhmex_mbox_get_shared_reg(box, reg2->idx, reg2->config))
goto fail;
@@ -1278,7 +1275,8 @@ again:
if (idx[0] != 0xff && idx[0] != __BITS_VALUE(reg1->idx, 0, 8))
nhmex_mbox_alter_er(event, idx[0], true);
reg1->alloc |= alloc;
- reg2->alloc = 1;
+ if (reg2->idx != EXTRA_REG_NONE)
+ reg2->alloc = 1;
}
return NULL;
fail:
@@ -1342,9 +1340,6 @@ static int nhmex_mbox_hw_config(struct intel_uncore_box
*box, struct perf_event
struct extra_reg *er;
unsigned msr;
int reg_idx = 0;
-
- if (WARN_ON_ONCE(reg1->idx != -1))
- return -EINVAL;
/*
* The mbox events may require 2 extra MSRs at the most. But only
* the lower 32 bits in these MSRs are significant, so we can use
@@ -1355,11 +1350,6 @@ static int nhmex_mbox_hw_config(struct intel_uncore_box
*box, struct perf_event
continue;
if (event->attr.config1 & ~er->valid_mask)
return -EINVAL;
- if (er->idx == __BITS_VALUE(reg1->idx, 0, 8) ||
- er->idx == __BITS_VALUE(reg1->idx, 1, 8))
- continue;
- if (WARN_ON_ONCE(reg_idx >= 2))
- return -EINVAL;
msr = er->msr +
[PATCH 2/2] perf/x86: Add Intel Westmere-EX uncore support
From: "Yan, Zheng"
The Westmere-EX uncore is similar to the Nehalem-EX uncore. The
differences are:
- Westmere-EX uncore has 10 instances of Cbox. The MSRs for Cbox8
and Cbox9 in the Westmere-EX aren't contiguous with Cbox 0~7.
- The fvid field in the ZDP_CTL_FVC register in the Mbox is
different. It's 5 bits in the Nehalem-EX, 6 bits in the
Westmere-EX.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 56 ++-
arch/x86/kernel/cpu/perf_event_intel_uncore.h | 45 ++---
2 files changed, 68 insertions(+), 33 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 5750142..740406f 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -901,16 +901,21 @@ static struct attribute_group
nhmex_uncore_cbox_format_group = {
.attrs = nhmex_uncore_cbox_formats_attr,
};
+/* msr offset for each instance of cbox */
+static unsigned nhmex_cbox_msr_offsets[] = {
+ 0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x240, 0x2c0,
+};
+
static struct intel_uncore_type nhmex_uncore_cbox = {
.name = "cbox",
.num_counters = 6,
- .num_boxes = 8,
+ .num_boxes = 10,
.perf_ctr_bits = 48,
.event_ctl = NHMEX_C0_MSR_PMON_EV_SEL0,
.perf_ctr = NHMEX_C0_MSR_PMON_CTR0,
.event_mask = NHMEX_PMON_RAW_EVENT_MASK,
.box_ctl= NHMEX_C0_MSR_PMON_GLOBAL_CTL,
- .msr_offset = NHMEX_C_MSR_OFFSET,
+ .msr_offsets= nhmex_cbox_msr_offsets,
.pair_ctr_ctl = 1,
.ops= _uncore_ops,
.format_group = _uncore_cbox_format_group
@@ -1138,6 +1143,9 @@ static struct extra_reg nhmex_uncore_mbox_extra_regs[] = {
EVENT_EXTRA_END
};
+/* Nehalem-EX or Westmere-EX ? */
+bool uncore_nhmex;
+
static bool nhmex_mbox_get_shared_reg(struct intel_uncore_box *box, int idx,
u64 config)
{
struct intel_uncore_extra_reg *er;
@@ -1167,18 +1175,29 @@ static bool nhmex_mbox_get_shared_reg(struct
intel_uncore_box *box, int idx, u64
return false;
/* mask of the shared fields */
- mask = NHMEX_M_PMON_ZDP_CTL_FVC_MASK;
+ if (uncore_nhmex)
+ mask = NHMEX_M_PMON_ZDP_CTL_FVC_MASK;
+ else
+ mask = WSMEX_M_PMON_ZDP_CTL_FVC_MASK;
er = >shared_regs[EXTRA_REG_NHMEX_M_ZDP_CTL_FVC];
raw_spin_lock_irqsave(>lock, flags);
/* add mask of the non-shared field if it's in use */
- if (__BITS_VALUE(atomic_read(>ref), idx, 8))
- mask |= NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ if (__BITS_VALUE(atomic_read(>ref), idx, 8)) {
+ if (uncore_nhmex)
+ mask |= NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ else
+ mask |= WSMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ }
if (!atomic_read(>ref) || !((er->config ^ config) & mask)) {
atomic_add(1 << (idx * 8), >ref);
- mask = NHMEX_M_PMON_ZDP_CTL_FVC_MASK |
- NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ if (uncore_nhmex)
+ mask = NHMEX_M_PMON_ZDP_CTL_FVC_MASK |
+ NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ else
+ mask = WSMEX_M_PMON_ZDP_CTL_FVC_MASK |
+ WSMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
er->config &= ~mask;
er->config |= (config & mask);
ret = true;
@@ -1212,7 +1231,10 @@ u64 nhmex_mbox_alter_er(struct perf_event *event, int
new_idx, bool modify)
/* get the non-shared control bits and shift them */
idx = orig_idx - EXTRA_REG_NHMEX_M_ZDP_CTL_FVC;
- config &= NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ if (uncore_nhmex)
+ config &= NHMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
+ else
+ config &= WSMEX_M_PMON_ZDP_CTL_FVC_EVENT_MASK(idx);
if (new_idx > orig_idx) {
idx = new_idx - orig_idx;
config <<= 3 * idx;
@@ -1222,6 +1244,10 @@ u64 nhmex_mbox_alter_er(struct perf_event *event, int
new_idx, bool modify)
}
/* add the shared control bits back */
+ if (uncore_nhmex)
+ config |= NHMEX_M_PMON_ZDP_CTL_FVC_MASK & reg1->config;
+ else
+ config |= WSMEX_M_PMON_ZDP_CTL_FVC_MASK & reg1->config;
config |= NHMEX_M_PMON_ZDP_CTL_FVC_MASK & reg1->config;
if (modify) {
/* adjust the main event selector */
@@ -1480,6 +1506,12 @@ static struct uncore_event_desc
nhmex_uncore_mbox_events[] = {
{ /* end: all zeroes */ },
};
[PATCH] watchdog: watchdog-test: make term() static
In 3.5 warning during build 'no previous prototype for term'. Since it
is only used in watchdog-test.c make term() static.
Signed-off-by: Jerry Snitselaar
---
Documentation/watchdog/src/watchdog-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/watchdog/src/watchdog-test.c
b/Documentation/watchdog/src/watchdog-test.c
index 73ff5cc..3da8229 100644
--- a/Documentation/watchdog/src/watchdog-test.c
+++ b/Documentation/watchdog/src/watchdog-test.c
@@ -31,7 +31,7 @@ static void keep_alive(void)
* or "-e" to enable the card.
*/
-void term(int sig)
+static void term(int sig)
{
close(fd);
fprintf(stderr, "Stopping watchdog ticks...\n");
--
1.7.12.rc0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 akpm tree with the tip tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/x86/kernel/cpu/perf_event_intel_uncore.h between commit 254298c726b9
("perf/x86: Add Intel Nehalem-EX uncore support") from the tip tree and
commit "arch/x86/kernel/cpu/perf_event_intel_uncore.h: make
UNCORE_PMU_HRTIMER_INTERVAL 64-bit" from the akpm tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/kernel/cpu/perf_event_intel_uncore.h
index f385189,d85c25d..000
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
@@@ -5,7 -5,9 +5,7 @@@
#include "perf_event.h"
#define UNCORE_PMU_NAME_LEN 32
- #define UNCORE_PMU_HRTIMER_INTERVAL (60 * NSEC_PER_SEC)
-#define UNCORE_BOX_HASH_SIZE 8
-
+ #define UNCORE_PMU_HRTIMER_INTERVAL (60LL * NSEC_PER_SEC)
#define UNCORE_FIXED_EVENT0xff
#define UNCORE_PMC_IDX_MAX_GENERIC8
pgpJrweEuxg3f.pgp
Description: PGP signature
Re: [PATCH -alternative] mm: hugetlbfs: Close race during teardown of hugetlbfs shared page tables V2 (resend)
On 07/26/2012 02:37 PM, Rik van Riel wrote: On 07/23/2012 12:04 AM, Hugh Dickins wrote: I spent hours trying to dream up a better patch, trying various approaches. I think I have a nice one now, what do you think? And more importantly, does it work? I have not tried to test it at all, that I'm hoping to leave to you, I'm sure you'll attack it with gusto! If you like it, please take it over and add your comments and signoff and send it in. The second part won't come up in your testing, and could be made a separate patch if you prefer: it's a related point that struck me while I was playing with a different approach. I'm sorely tempted to leave a dangerous pair of eyes off the Cc, but that too would be unfair. Subject-to-your-testing- Signed-off-by: Hugh Dickins This patch looks good to me. Larry, does Hugh's patch survive your testing? Like I said earlier, no. However, I finally set up a reproducer that only takes a few seconds on a large system and this totally fixes the problem: - diff --git a/mm/hugetlb.c b/mm/hugetlb.c index c36febb..cc023b8 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2151,7 +2151,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, goto nomem; /* If the pagetables are shared don't copy or take references */ - if (dst_pte == src_pte) + if (*(unsigned long *)dst_pte == *(unsigned long *)src_pte) continue; spin_lock(>page_table_lock); --- When we compare what the src_pte & dst_pte point to instead of their addresses everything works, I suspect there is a missing memory barrier somewhere ??? Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/7] procfs: Add ability to plug in auxiliary fdinfo providers
> +static int prep_fdinfo_driver(struct proc_fdinfo_extra *extra)
> +{
> + struct proc_fdinfo_driver *s;
> +
> + down_read(_drivers_sem);
> + list_for_each_entry(s, _drivers, list) {
> + if (s->probe(extra->f_file)) {
> + extra->driver = s;
> + break;
> + }
> + }
> + up_read(_drivers_sem);
> +
> + return 0;
> +}
Maybe a simple list of file_operations:seq_operations mappings would be simpler?
> +static void *seq_next(struct seq_file *m, void *p, loff_t *pos)
> +{
> + struct proc_fdinfo_extra *extra = m->private;
> + void *v = NULL;
> +
> + if (extra->driver) {
> + int ret = 0;
> +
> + if (*pos == 0) {
> + v = extra->driver->ops->start(m, pos);
> + if (v) {
> + ret = extra->driver->ops->show(m, v);
Why is it necessary to call ->show here? The logic should be
seq_start = (pos == 0 ? nop : extra->start)
seq_next = (pos == 0 ? extra->start : extra->next)
seq_stop = (pos == 0 ? nop : extra->stop)
seq_show = (pos == 0 ? proc_show : extra->show)
Or I'm missing something?
Thanks,
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] ACPI: Add acpi_pr_() interfaces
On Thu, 2012-07-26 at 14:57 -0700, Joe Perches wrote: > On Thu, 2012-07-26 at 15:50 -0600, Bjorn Helgaas wrote: > > On Thu, Jul 26, 2012 at 3:43 PM, Joe Perches wrote: > > > On Thu, 2012-07-26 at 15:37 -0600, Bjorn Helgaas wrote: > > >> PNP0C01:00: new device for \_SB_.PCI0.ISA_.MBIO > > >> > > >> I fiddled with this a while ago; it would look something like this: > > > [] > > >> +static noinline_for_stack > > >> +char *acpi_name_string(char *buf, char *end, acpi_handle handle, > > >> +struct printf_spec spec, const char *fmt) > [] > > Yes. I'm hesitant about this approach in general, because I don't > > think printing the ACPI path is something we should be doing often. > > It's not like a struct resource or a MAC address, where there are > > dozens or hundreds of users. I really think we should only print ACPI > > paths in one or two places, so adding a %p extension would waste a > > letter and encourage the wrong behavior. > > I don't much care for adding ACPI specific calls to vsprintf > as acpi is supposed to be OS generic anyway. > > I don't think there's anything wrong with Toshi's approach. > Anyone that looks for speed in a logging message is looking > for an oddly fitting thing. Tracing sure, but logging? Fully agreed! One cannot use printk in performance path. Thanks, -Toshi > I also don't see anything wrong with renaming it to just > acpi_, but that's a different discussion. > > 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] ACPI: Add acpi_pr_() interfaces
On Thu, 2012-07-26 at 15:50 -0600, Bjorn Helgaas wrote:
> On Thu, Jul 26, 2012 at 3:43 PM, Joe Perches wrote:
> > On Thu, 2012-07-26 at 15:37 -0600, Bjorn Helgaas wrote:
> >> PNP0C01:00: new device for \_SB_.PCI0.ISA_.MBIO
> >>
> >> I fiddled with this a while ago; it would look something like this:
> > []
> >> +static noinline_for_stack
> >> +char *acpi_name_string(char *buf, char *end, acpi_handle handle,
> >> +struct printf_spec spec, const char *fmt)
> >> +{
> >> + acpi_status status;
> >> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> >> + u32 type = ACPI_SINGLE_NAME;
> >> + char *p = buf;
> >> +
> >> + if (fmt[0] == 'A')
> >> + type = ACPI_FULL_PATHNAME;
> >
> > maybe if (fmt[1] == 'f')
> >
> >> @@ -982,6 +1007,9 @@ char *pointer(const char *fmt, char *buf, char *end,
> >> void *ptr,
> >> }
> >>
> >> switch (*fmt) {
> >> + case 'A':
> >> + case 'a':
> >> + return acpi_name_string(buf, end, ptr, spec, fmt);
> >
> > There are only so many letters, it might be better to
> > just use 'a' and another 'f' after that if necessary
> > for "full".
> >
> > And of course that should be #ifdef'd too
>
> Yes. I'm hesitant about this approach in general, because I don't
> think printing the ACPI path is something we should be doing often.
> It's not like a struct resource or a MAC address, where there are
> dozens or hundreds of users. I really think we should only print ACPI
> paths in one or two places, so adding a %p extension would waste a
> letter and encourage the wrong behavior.
That's a good point. I agree. So, let's continue to use
acpi_pr_() for printing ACPI device path. The use of this
interface is limited anyway.
Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pvrusb2: Declare MODULE_FIRMWARE usage
Acked-By: Mike Isely
-Mike
On Thu, 26 Jul 2012, Tim Gardner wrote:
> Cc: Mike Isely
> Cc: Mauro Carvalho Chehab
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Tim Gardner
> ---
> drivers/media/video/pvrusb2/pvrusb2-devattr.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
> b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
> index d8c8982..adc501d3 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
> @@ -54,8 +54,9 @@ static const struct pvr2_device_client_desc
> pvr2_cli_29xxx[] = {
> { .module_id = PVR2_CLIENT_ID_DEMOD },
> };
>
> +#define PVR2_FIRMWARE_29xxx "v4l-pvrusb2-29xxx-01.fw"
> static const char *pvr2_fw1_names_29xxx[] = {
> - "v4l-pvrusb2-29xxx-01.fw",
> + PVR2_FIRMWARE_29xxx,
> };
>
> static const struct pvr2_device_desc pvr2_device_29xxx = {
> @@ -87,8 +88,9 @@ static const struct pvr2_device_client_desc
> pvr2_cli_24xxx[] = {
> { .module_id = PVR2_CLIENT_ID_DEMOD },
> };
>
> +#define PVR2_FIRMWARE_24xxx "v4l-pvrusb2-24xxx-01.fw"
> static const char *pvr2_fw1_names_24xxx[] = {
> - "v4l-pvrusb2-24xxx-01.fw",
> + PVR2_FIRMWARE_24xxx,
> };
>
> static const struct pvr2_device_desc pvr2_device_24xxx = {
> @@ -369,8 +371,9 @@ static const struct pvr2_device_client_desc
> pvr2_cli_73xxx[] = {
> .i2c_address_list = "\x42"},
> };
>
> +#define PVR2_FIRMWARE_73xxx "v4l-pvrusb2-73xxx-01.fw"
> static const char *pvr2_fw1_names_73xxx[] = {
> - "v4l-pvrusb2-73xxx-01.fw",
> + PVR2_FIRMWARE_73xxx,
> };
>
> static const struct pvr2_device_desc pvr2_device_73xxx = {
> @@ -475,8 +478,9 @@ static const struct pvr2_dvb_props pvr2_751xx_dvb_props =
> {
> };
> #endif
>
> +#define PVR2_FIRMWARE_75xxx "v4l-pvrusb2-73xxx-01.fw"
> static const char *pvr2_fw1_names_75xxx[] = {
> - "v4l-pvrusb2-73xxx-01.fw",
> + PVR2_FIRMWARE_75xxx,
> };
>
> static const struct pvr2_device_desc pvr2_device_750xx = {
> @@ -556,7 +560,10 @@ struct usb_device_id pvr2_device_table[] = {
> };
>
> MODULE_DEVICE_TABLE(usb, pvr2_device_table);
> -
> +MODULE_FIRMWARE(PVR2_FIRMWARE_29xxx);
> +MODULE_FIRMWARE(PVR2_FIRMWARE_24xxx);
> +MODULE_FIRMWARE(PVR2_FIRMWARE_73xxx);
> +MODULE_FIRMWARE(PVR2_FIRMWARE_75xxx);
>
> /*
>Stuff for Emacs to see, in order to encourage consistent editing style:
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: recover SD_WAKE_AFFINE in select_task_rq_fair and code clean up
On Fri, 2012-07-27 at 09:47 +0800, Alex Shi wrote:
> On 07/26/2012 05:37 PM, Mike Galbraith wrote:
>
> > On Thu, 2012-07-26 at 13:27 +0800, Alex Shi wrote:
> >
> >>if (affine_sd) {
> >> - if (cpu == prev_cpu || wake_affine(affine_sd, p, sync))
> >> + if (wake_affine(affine_sd, p, sync))
> >>prev_cpu = cpu;
> >>
> >>new_cpu = select_idle_sibling(p, prev_cpu);
> >
> > Hm, if cpu == prev_cpu, asking wake_affine() if it's ok to put wakee
> > back where it came from is wasted cycles.. that's where the task is
> > headed regardless of reply.
> >
> > -Mike
> >
>
>
>
>
> Sure. I modified the patch as below:
(dang, plain text can't make upside down ack;)
> ===
> From 610515185d8a98c14c7c339c25381bc96cd99d93 Mon Sep 17 00:00:00 2001
> From: Alex Shi
> Date: Thu, 26 Jul 2012 08:55:34 +0800
> Subject: [PATCH 1/3] sched: recover SD_WAKE_AFFINE in select_task_rq_fair and
> code clean up
>
> Since power saving code was removed from sched now, the implement
> code is out of service in this function, and even pollute other logical.
> like, 'want_sd' never has chance to be set '0', that remove the effect
> of SD_WAKE_AFFINE here.
>
> So, clean up the obsolete code and some other unnecessary code.
>
> Signed-off-by: Alex Shi
> ---
> kernel/sched/fair.c | 32 +++-
> 1 files changed, 3 insertions(+), 29 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 22321db..53fd8db 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2686,7 +2686,6 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
> int wake_flags)
> int prev_cpu = task_cpu(p);
> int new_cpu = cpu;
> int want_affine = 0;
> - int want_sd = 1;
> int sync = wake_flags & WF_SYNC;
>
> if (p->nr_cpus_allowed == 1)
> @@ -2704,48 +2703,23 @@ select_task_rq_fair(struct task_struct *p, int
> sd_flag, int wake_flags)
> continue;
>
> /*
> - * If power savings logic is enabled for a domain, see if we
> - * are not overloaded, if so, don't balance wider.
> - */
> - if (tmp->flags & (SD_PREFER_LOCAL)) {
> - unsigned long power = 0;
> - unsigned long nr_running = 0;
> - unsigned long capacity;
> - int i;
> -
> - for_each_cpu(i, sched_domain_span(tmp)) {
> - power += power_of(i);
> - nr_running += cpu_rq(i)->cfs.nr_running;
> - }
> -
> - capacity = DIV_ROUND_CLOSEST(power, SCHED_POWER_SCALE);
> -
> - if (nr_running < capacity)
> - want_sd = 0;
> - }
> -
> - /*
>* If both cpu and prev_cpu are part of this domain,
>* cpu is a valid SD_WAKE_AFFINE target.
>*/
> if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
> cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
> affine_sd = tmp;
> - want_affine = 0;
> - }
> -
> - if (!want_sd && !want_affine)
> break;
> + }
>
> if (!(tmp->flags & sd_flag))
> continue;
>
> - if (want_sd)
> - sd = tmp;
> + sd = tmp;
> }
>
> if (affine_sd) {
> - if (cpu == prev_cpu || wake_affine(affine_sd, p, sync))
> + if (cpu != prev_cpu && wake_affine(affine_sd, p, sync))
> prev_cpu = cpu;
>
> new_cpu = select_idle_sibling(p, prev_cpu);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RAID extremely slow
On 07/26/2012 07:53 PM, Kevin Ross wrote: On 07/26/2012 07:27 PM, David Dillow wrote: On Thu, 2012-07-26 at 19:17 -0700, Kevin Ross wrote: On 07/26/2012 07:17 PM, David Dillow wrote: On Thu, 2012-07-26 at 22:15 -0400, David Dillow wrote: If you can, upgrade to the latest 3.4 stable kernel (3.4.6 right now). As far as I can see, the latest 3.2 stable does not contain the delayed stripe fix. And I was looking at the wrong version; 3.2.24 does indeed have the fix. I'm running 3.2.21, does that contain the fix? No, that was the one I looked at. It is commit c0159c780e8d42309d04e83271986274d3880826. Okay, I grabbed 3.4.4 from Debian experimental, and I'm running with that now. Hopefully this fixes the problem. Thanks for your help! -- Kevin Just noticed I need 3.4.5 or later. Doh! I'll grab a vanilla kernel from kernel.org and build it. Thanks! -- Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: imx-dma: Fix kernel crash due to missing clock conversion
On Tue, 2012-07-03 at 15:33 -0300, Fabio Estevam wrote: > From: Fabio Estevam > > With the new i.MX clock infrastructure we need to request the dma clocks > seperately: ahb and ipg clocks. > > This fixes the following kernel crash and make audio to be functional again: > > root@freescale /home$ aplay audio48k16S.wav > Playing WAVE 'audio48k16S.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, > Stereo > Unable to handle kernel NULL pointer dereference at virtual address > pgd = c7b74000 > [] *pgd=a7bb5831, *pte=, *ppte= > Internal error: Oops: 17 [#1] PREEMPT ARM > Modules linked in: > CPU: 0Not tainted (3.5.0-rc5-next-20120702-7-g3028b64 #1128) > PC is at snd_dmaengine_pcm_get_chan+0x8/0x10 > LR is at snd_imx_pcm_hw_params+0x18/0xdc > pc : []lr : []psr: a013 > sp : c7b45e30 ip : fp : c7ae58e0 > r10: r9 : c7ae981c r8 : c7b88800 > r7 : c7ae5a60 r6 : c7ae5b20 r5 : c7ae9810 r4 : c7afa060 > r3 : r2 : 0001 r1 : c7b88800 r0 : c7afa060 > Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 0005317f Table: a7b74000 DAC: 0015 > Process aplay (pid: 701, stack limit = 0xc7b44270) > Stack: (0xc7b45e30 to 0xc7b46000) > 5e20: 0010 0029 c7b88800 c02db870 > 5e40: c7ae5a60 c02d4594 0010 01ae5a60 c7ae5a60 c7ae9810 c7ae9810 c7afa060 > 5e60: c7ae5b20 c7ae5a60 c7b88800 c02e3ef0 c02e3e08 c7b1e400 c7afa060 c7b88800 > 5e80: c0014da8 c7b44000 bec566ac c02cd400 c7afa060 c7afa060 > 5ea0: bec56800 c7b88800 c0014da8 c02cdd7c c04ee710 c04ee7b8 0003 c005fc74 > 5ec0: 7fff c7b45f00 c7afa060 c7b67420 c7ba3070 0004 c0014da8 > 5ee0: c7b44000 bec566ac c02ced88 c04e95f8 b6f5ab04 c7b45fb0 0145a468 > 5f00: 0145a600 bec566bc bec56800 c7b67420 c7ba3070 c00d499c c7b45f18 c7b45f18 > 5f20: 001a 0004 0001 c7b44000 c0527f40 0009 0008 > 5f40: c7b44000 c002c9ec 0001 c04f0ab0 c04ebec0 0101 000a > 5f60: 6093 c7b67420 bec56800 c25c4111 0004 c0014da8 c7b44000 > 5f80: bec566ac c00d4f38 b6ffb658 c0522d80 0145a468 b6fd5000 0145a418 > 5fa0: 0036 c0014c00 0145a468 b6fd5000 0004 c25c4111 bec56800 00020001 > 5fc0: 0145a468 b6fd5000 0145a418 0036 0145a468 0145a600 bec566bc bec566ac > 5fe0: 0145a468 bec56388 b6f65ce4 b6dcebec 2010 0004 > [] (snd_dmaengine_pcm_get_chan+0x8/0x10) from [] > (snd_imx_pcm_hw_params+0x18/0xdc) > [] (snd_imx_pcm_hw_params+0x18/0xdc) from [] > (soc_pcm_hw_params+0xe8/0x1f0) > [] (soc_pcm_hw_params+0xe8/0x1f0) from [] > (snd_pcm_hw_params+0x124/0x474) > [] (snd_pcm_hw_params+0x124/0x474) from [] > (snd_pcm_common_ioctl1+0x4b4/0xf74) > [] (snd_pcm_common_ioctl1+0x4b4/0xf74) from [] > (snd_pcm_playback_ioctl1+0x30/0x510) > [] (snd_pcm_playback_ioctl1+0x30/0x510) from [] > (do_vfs_ioctl+0x80/0x5e4) > [] (do_vfs_ioctl+0x80/0x5e4) from [] (sys_ioctl+0x38/0x60) > [] (sys_ioctl+0x38/0x60) from [] > (ret_fast_syscall+0x0/0x2c) > Code: e593000c e12fff1e e59030a0 e59330bc (e593) > ---[ end trace fa518c8ba3a74e97 ]-- > > Reported-by: Javier Martin > Signed-off-by: Fabio Estevam Applied thanks (to fixes-for 3.7) Sorry for missing this out, please ping if you dont see a response to patch in week or so. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v8 0/7] power management patch set
On Fri, Jul 27, 2012 at 1:29 AM, Kumar Gala wrote: > > On Jul 26, 2012, at 9:02 AM, Li Yang wrote: > >> On Fri, Jul 20, 2012 at 8:42 PM, Zhao Chenhui >> wrote: >>> Changes for v8: >>> * Separated the cpu hotplug patch into three patches, as follows >>> [PATCH v8 1/7] powerpc/smp: use a struct epapr_spin_table to replace macros >>> [PATCH v8 2/7] powerpc/smp: add generic_set_cpu_up() to set cpu_state as >>> CPU_UP_PREPARE >>> [PATCH v8 4/7] powerpc/85xx: add HOTPLUG_CPU support >>> >>> * Replaced magic numbers with macros in "[PATCH 5/7] powerpc/85xx: add >>> sleep and deep sleep support" >>> >>> * no change to the rest of the patch set >> >> Hi Kumar, >> >> How about picking about this series for 3.6? The review seems to >> settle down for this revision. > > Its too late for 3.6, but will look at queuing it up for 3.7. Too late? The latest version were submitted on Jul 20 and you are still picking up other patches today. :) I do think the patches have been floating around for too long time to wait for another release cycle. If there are problems, we can work on addressing them in follow up patches. Leo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
2012/7/25 Boaz Harrosh : > On 07/25/2012 02:44 PM, Sen Wang wrote: > >> 2012/7/25 Paolo Bonzini : >>> Il 25/07/2012 10:29, Wang Sen ha scritto: When using the commands below to write some data to a virtio-scsi LUN of the QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) # sudo mount /dev/sdb /mnt # dd if=/dev/zero of=/mnt/file bs=1M count=1024 In current implementation, sg_set_buf is called to add buffers to sg list which is put into the virtqueue eventually. But there are some HighMem pages in table->sgl can not get virtual address by sg_virt. So, sg_virt(sg_elem) may return NULL value. This will cause QEMU exit when virtqueue_map_sg is called in QEMU because an invalid GPA is passed by virtqueue. >>> >>> Heh, I was compiling (almost) the same patch as we speak. :) >> >> Uh, what a coincidence! :) >> >>> >>> I've never seen QEMU crash; the VM would more likely just fail to boot >>> with a panic. But it's the same bug anyway. >> >> I never met this before. How this situation happens? >> >>> My solution is using sg_set_page instead of sg_set_buf. I have tested the patch on my workstation. QEMU would not crash any more. Signed-off-by: Wang Sen --- drivers/scsi/virtio_scsi.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index 1b38431..fc5c88a 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -198,7 +198,8 @@ static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx, int i; for_each_sg(table->sgl, sg_elem, table->nents, i) - sg_set_buf([idx++], sg_virt(sg_elem), sg_elem->length); + sg_set_page([idx++], sg_page(sg_elem), sg_elem->length, + sg_elem->offset); >>> >>> This can simply be >>> >>>sg[idx++] = *sg_elem; >>> >> >> Yes, I saw your another E-mail. I think you're right. Simply calling >> sg_set_page can not handle >> the flag bits correctly. So, I'll repost the patch soon. Thank you! >> > > > No this code is correct, though you will need to make sure to properly > terminate the destination sg_list. Yes, the terminate marker in the destination list is set when initialization. sg_set_page would not break this marker because it saved both the two maker bits at sg_asign_page. Also, the allocation of destination sg list considered the total number of the source sg_list. So, sg_set_page can work correctly. The value assignment method also can also work correctly, because the termination marker in source sg_list has been set in blk_rq_map_sg(), as the last entry of source sg_list is just copied to the the last entry in destination list. Uh, Paolo, Boaz, have you reached agreement on which method to use? > > But since old code was using sg_set_buf(), than it means it was properly > terminated before, and there for this code is good as is please don't > touch it. > > Thanks > Boaz > >>> Can you repost it with this change, and also add sta...@vger.kernel.org >>> to the Cc? Thanks very much! >>> >>> Paolo >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> > -- -- Wang Sen Addr: XUPT,Xi'an,Shaanxi,China Email: kelvin.x...@gmail.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/
[PATCH v4 3/4] ACPI: Update Memory hotplug messages
Updated Memory hotplug log messages with acpi_pr_(),
dev_() and pr_().
Signed-off-by: Toshi Kani
---
drivers/acpi/acpi_memhotplug.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 24c807f..183fa3d 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -170,7 +170,7 @@ acpi_memory_get_device(acpi_handle handle,
/* Get the parent device */
result = acpi_bus_get_device(phandle, );
if (result) {
- printk(KERN_WARNING PREFIX "Cannot get acpi bus device");
+ acpi_pr_warn(phandle, "Cannot get acpi bus device\n");
return -EINVAL;
}
@@ -180,14 +180,14 @@ acpi_memory_get_device(acpi_handle handle,
*/
result = acpi_bus_add(, pdevice, handle, ACPI_BUS_TYPE_DEVICE);
if (result) {
- printk(KERN_WARNING PREFIX "Cannot add acpi bus");
+ acpi_pr_warn(handle, "Cannot add acpi bus\n");
return -EINVAL;
}
end:
*mem_device = acpi_driver_data(device);
if (!(*mem_device)) {
- printk(KERN_ERR "\n driver data not found");
+ dev_err(>dev, "driver data not found\n");
return -ENODEV;
}
@@ -224,7 +224,8 @@ static int acpi_memory_enable_device(struct
acpi_memory_device *mem_device)
/* Get the range from the _CRS */
result = acpi_memory_get_device_resources(mem_device);
if (result) {
- printk(KERN_ERR PREFIX "get_device_resources failed\n");
+ dev_err(_device->device->dev,
+ "get_device_resources failed\n");
mem_device->state = MEMORY_INVALID_STATE;
return result;
}
@@ -257,7 +258,7 @@ static int acpi_memory_enable_device(struct
acpi_memory_device *mem_device)
num_enabled++;
}
if (!num_enabled) {
- printk(KERN_ERR PREFIX "add_memory failed\n");
+ dev_err(_device->device->dev, "add_memory failed\n");
mem_device->state = MEMORY_INVALID_STATE;
return -EINVAL;
}
@@ -353,7 +354,7 @@ static void acpi_memory_device_notify(acpi_handle handle,
u32 event, void *data)
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"\nReceived DEVICE CHECK notification
for device\n"));
if (acpi_memory_get_device(handle, _device)) {
- printk(KERN_ERR PREFIX "Cannot find driver data\n");
+ acpi_pr_err(handle, "Cannot find driver data\n");
break;
}
@@ -361,7 +362,7 @@ static void acpi_memory_device_notify(acpi_handle handle,
u32 event, void *data)
break;
if (acpi_memory_enable_device(mem_device)) {
- printk(KERN_ERR PREFIX "Cannot enable memory device\n");
+ acpi_pr_err(handle, "Cannot enable memory device\n");
break;
}
@@ -373,12 +374,12 @@ static void acpi_memory_device_notify(acpi_handle handle,
u32 event, void *data)
"\nReceived EJECT REQUEST notification for
device\n"));
if (acpi_bus_get_device(handle, )) {
- printk(KERN_ERR PREFIX "Device doesn't exist\n");
+ acpi_pr_err(handle, "Device doesn't exist\n");
break;
}
mem_device = acpi_driver_data(device);
if (!mem_device) {
- printk(KERN_ERR PREFIX "Driver Data is NULL\n");
+ acpi_pr_err(handle, "Driver Data is NULL\n");
break;
}
@@ -389,7 +390,7 @@ static void acpi_memory_device_notify(acpi_handle handle,
u32 event, void *data)
* with generic sysfs driver
*/
if (acpi_memory_disable_device(mem_device)) {
- printk(KERN_ERR PREFIX "Disable memory device\n");
+ acpi_pr_err(handle, "Failed to remove memory device\n");
/*
* If _EJ0 was called but failed, _OST is not
* necessary.
@@ -449,7 +450,7 @@ static int acpi_memory_device_add(struct acpi_device
*device)
/* Set the device state */
mem_device->state = MEMORY_POWER_ON_STATE;
- printk(KERN_DEBUG "%s \n", acpi_device_name(device));
+ pr_debug("%s\n", acpi_device_name(device));
/*
* Early boot code has recognized memory area by EFI/E820.
@@ -464,7 +465,7 @@ static int acpi_memory_device_add(struct acpi_device
*device)
/* call add_memory func */
result = acpi_memory_enable_device(mem_device);
[PATCH v4 2/4] ACPI: Update CPU hotplug messages
Updated CPU hotplug log messages with acpi_pr_(),
dev_() and pr_(). Some messages are also
changed for clarity.
Signed-off-by: Toshi Kani
Tested-by: Vijay Mohan Pandarathil
---
drivers/acpi/processor_driver.c | 37 ++---
1 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index d745a97..2cb88e6 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -282,7 +282,9 @@ static int acpi_processor_get_info(struct acpi_device
*device)
/* Declared with "Processor" statement; match ProcessorID */
status = acpi_evaluate_object(pr->handle, NULL, NULL, );
if (ACPI_FAILURE(status)) {
- printk(KERN_ERR PREFIX "Evaluating processor object\n");
+ dev_err(>dev,
+ "Failed to evaluate processor object (0x%x)\n",
+ status);
return -ENODEV;
}
@@ -301,8 +303,9 @@ static int acpi_processor_get_info(struct acpi_device
*device)
status = acpi_evaluate_integer(pr->handle, METHOD_NAME__UID,
NULL, );
if (ACPI_FAILURE(status)) {
- printk(KERN_ERR PREFIX
- "Evaluating processor _UID [%#x]\n", status);
+ dev_err(>dev,
+ "Failed to evaluate processor _UID (0x%x)\n",
+ status);
return -ENODEV;
}
device_declaration = 1;
@@ -345,7 +348,7 @@ static int acpi_processor_get_info(struct acpi_device
*device)
if (!object.processor.pblk_address)
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
else if (object.processor.pblk_length != 6)
- printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n",
+ dev_err(>dev, "Invalid PBLK length [%d]\n",
object.processor.pblk_length);
else {
pr->throttling.address = object.processor.pblk_address;
@@ -429,8 +432,8 @@ static int acpi_cpu_soft_notify(struct notifier_block *nfb,
* Initialize missing things
*/
if (pr->flags.need_hotplug_init) {
- printk(KERN_INFO "Will online and init hotplugged "
- "CPU: %d\n", pr->id);
+ pr_info("Will online and init hotplugged CPU: %d\n",
+ pr->id);
WARN(acpi_processor_start(pr), "Failed to start CPU:"
" %d\n", pr->id);
pr->flags.need_hotplug_init = 0;
@@ -491,14 +494,16 @@ static __ref int acpi_processor_start(struct
acpi_processor *pr)
>cdev->device.kobj,
"thermal_cooling");
if (result) {
- printk(KERN_ERR PREFIX "Create sysfs link\n");
+ dev_err(>dev,
+ "Failed to create sysfs link 'thermal_cooling'\n");
goto err_thermal_unregister;
}
result = sysfs_create_link(>cdev->device.kobj,
>dev.kobj,
"device");
if (result) {
- printk(KERN_ERR PREFIX "Create sysfs link\n");
+ dev_err(>cdev->device,
+ "Failed to create sysfs link 'device'\n");
goto err_remove_sysfs_thermal;
}
@@ -560,8 +565,8 @@ static int __cpuinit acpi_processor_add(struct acpi_device
*device)
*/
if (per_cpu(processor_device_array, pr->id) != NULL &&
per_cpu(processor_device_array, pr->id) != device) {
- printk(KERN_WARNING "BIOS reported wrong ACPI id "
- "for the processor\n");
+ dev_warn(>dev,
+ "BIOS reported wrong ACPI id for the processor\n");
result = -ENODEV;
goto err_free_cpumask;
}
@@ -715,7 +720,7 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
result = acpi_processor_device_add(handle, );
if (result) {
- printk(KERN_ERR PREFIX "Unable to add the device\n");
+ acpi_pr_err(handle, "Unable to add the device\n");
break;
}
@@ -727,17 +732,19 @@ static void acpi_processor_hotplug_notify(acpi_handle
handle,
"received ACPI_NOTIFY_EJECT_REQUEST\n"));
if (acpi_bus_get_device(handle, )) {
- pr_err(PREFIX "Device don't exist, dropping EJECT\n");
+ acpi_pr_err(handle,
+
[PATCH v4 4/4] ACPI: Update Container hotplug messages
Updated Container hotplug log messages with acpi_pr_()
and pr_(). Removed unnecessary check to device pointer.
Signed-off-by: Toshi Kani
---
drivers/acpi/container.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 1f9f7d7..519c1d6 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -97,12 +97,6 @@ static int acpi_container_add(struct acpi_device *device)
{
struct acpi_container *container;
-
- if (!device) {
- printk(KERN_ERR PREFIX "device is NULL\n");
- return -EINVAL;
- }
-
container = kzalloc(sizeof(struct acpi_container), GFP_KERNEL);
if (!container)
return -ENOMEM;
@@ -164,7 +158,7 @@ static void container_notify_cb(acpi_handle handle, u32
type, void *context)
case ACPI_NOTIFY_BUS_CHECK:
/* Fall through */
case ACPI_NOTIFY_DEVICE_CHECK:
- printk(KERN_WARNING "Container driver received %s event\n",
+ pr_debug("Container driver received %s event\n",
(type == ACPI_NOTIFY_BUS_CHECK) ?
"ACPI_NOTIFY_BUS_CHECK" : "ACPI_NOTIFY_DEVICE_CHECK");
@@ -185,7 +179,7 @@ static void container_notify_cb(acpi_handle handle, u32
type, void *context)
result = container_device_add(, handle);
if (result) {
- printk(KERN_WARNING "Failed to add container\n");
+ acpi_pr_warn(handle, "Failed to add container\n");
break;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/4] ACPI: Add acpi_pr_() interfaces
This patch introduces acpi_pr_(), where is a kernel
message level such as err/warn/info, to support improved logging
messages for ACPI, esp. in hotplug operations. acpi_pr_()
appends "ACPI" prefix and ACPI object path to the messages. This
improves diagnostics in hotplug operations since it identifies an
object that caused an issue in a log file.
acpi_pr_() takes acpi_handle as an argument, which is passed
to ACPI hotplug notify handlers from the ACPICA. Therefore, it is
always available unlike other kernel objects, such as device.
For example, the statement below
acpi_pr_err(handle, "Device don't exist, dropping EJECT\n");
logs an error message like this at KERN_ERR.
ACPI: \_SB_.SCK4.CPU4: Device don't exist, dropping EJECT
ACPI drivers can use acpi_pr_() when they need to identify
a target ACPI object path in their messages, such as error messages.
The usage model is similar to dev_(). acpi_pr_() can
be used when device is not created/valid, which may be the case for
ACPI hotplug handlers. ACPI object path is also consistent on the
platform. Device name changes over hotplug operations.
ACPI drivers should use dev_() when device is valid and
acpi_pr_() is already used by the caller in its error path.
Device name provides more user friendly information.
ACPI drivers also continue to use pr_() when messages do not
need to specify device information, such as boot-up messages.
Note: ACPI_[WARNING|INFO|ERROR]() are intended for the ACPICA and
are not associated with the kernel message level.
Signed-off-by: Toshi Kani
Tested-by: Vijay Mohan Pandarathil
---
drivers/acpi/utils.c| 34 ++
include/acpi/acpi_bus.h | 31 +++
2 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 3e87c9c..ec0c6f9 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -454,3 +454,37 @@ acpi_evaluate_hotplug_ost(acpi_handle handle, u32
source_event,
#endif
}
EXPORT_SYMBOL(acpi_evaluate_hotplug_ost);
+
+/**
+ * acpi_printk: Print messages with ACPI prefix and object path
+ *
+ * This function is intended to be called through acpi_pr_ macros.
+ */
+void
+acpi_printk(const char *level, acpi_handle handle, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ struct acpi_buffer buffer = {
+ .length = ACPI_ALLOCATE_BUFFER,
+ .pointer = NULL
+ };
+ const char *path;
+ acpi_status ret;
+
+ va_start(args, fmt);
+ vaf.fmt = fmt;
+ vaf.va =
+
+ ret = acpi_get_name(handle, ACPI_FULL_PATHNAME, );
+ if (ret == AE_OK)
+ path = buffer.pointer;
+ else
+ path = "";
+
+ printk("%sACPI: %s: %pV", level, path, );
+
+ va_end(args);
+ kfree(buffer.pointer);
+}
+EXPORT_SYMBOL(acpi_printk);
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index bde976e..1c855b8 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -85,6 +85,37 @@ struct acpi_pld {
acpi_status
acpi_get_physical_device_location(acpi_handle handle, struct acpi_pld *pld);
+
+void acpi_printk(const char *level, acpi_handle handle, const char *fmt, ...);
+
+#define acpi_pr_emerg(handle, fmt, ...)\
+ acpi_printk(KERN_EMERG, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_alert(handle, fmt, ...)\
+ acpi_printk(KERN_ALERT, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_crit(handle, fmt, ...) \
+ acpi_printk(KERN_CRIT, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_err(handle, fmt, ...) \
+ acpi_printk(KERN_ERR, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_warn(handle, fmt, ...) \
+ acpi_printk(KERN_WARNING, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_notice(handle, fmt, ...) \
+ acpi_printk(KERN_NOTICE, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_info(handle, fmt, ...) \
+ acpi_printk(KERN_INFO, handle, fmt, ##__VA_ARGS__)
+
+/* REVISIT: Need to support CONFIG_DYNAMIC_DEBUG */
+#if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG)
+#define acpi_pr_debug(handle, fmt, ...)
\
+ acpi_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__)
+#else
+#define acpi_pr_debug(handle, fmt, ...)
\
+({ \
+ if (0) \
+ acpi_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__);\
+ 0; \
+})
+#endif
+
#ifdef CONFIG_ACPI
#include
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
[PATCH v4 0/4] ACPI: hotplug messages improvement
This patchset improves logging messages for ACPI CPU, Memory, and Container hotplug notify handlers. The patchset introduces a set of new macro interfaces, acpi_pr_(), and updates the notify handlers to use them. acpi_pr_() appends "ACPI" prefix and ACPI object path to the messages, and its usage model is similar to dev_(). This improves diagnostics in hotplug operations since it identifies an object that caused an issue in a log file. v4: - Changed to use dev_() where it is appropriate. v3: - Changed acpi_pr_debug() to NOP when !DEBUG and !DYNAMIC_DEBUG. DYNAMIC_DEBUG will be supported later. - Added const to a path variable in acpi_printk(). - Added more descriptions to the change log of patch 1/4. v2: - Set buffer.pointer to NULL in acpi_printk(). - Added acpi_pr_debug(). --- This patchset applies on top of the patch below. [PATCH] ACPI: Add ACPI CPU hot-remove support http://marc.info/?l=linux-acpi=134098193327362=2 --- Toshi Kani (4): ACPI: Add acpi_pr_() interfaces ACPI: Update CPU hotplug messages ACPI: Update Memory hotplug messages ACPI: Update Container hotplug messages --- drivers/acpi/acpi_memhotplug.c | 25 + drivers/acpi/container.c| 10 ++ drivers/acpi/processor_driver.c | 37 ++--- drivers/acpi/utils.c| 34 ++ include/acpi/acpi_bus.h | 31 +++ 5 files changed, 102 insertions(+), 35 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] create sun sysfs file
Even if a device has _SUN method, there is no way to know the slot unique-ID.
Thus the patch creates "sun" file in sysfs so that we can recognize it.
Index: linux-3.5/include/acpi/acpi_bus.h
===
--- linux-3.5.orig/include/acpi/acpi_bus.h 2012-07-22 05:58:29.0
+0900
+++ linux-3.5/include/acpi/acpi_bus.h 2012-07-27 10:05:13.860598455 +0900
@@ -209,6 +209,7 @@ struct acpi_device_pnp {
struct list_head ids; /* _HID and _CIDs */
acpi_device_name device_name; /* Driver-determined */
acpi_device_class device_class; /*" */
+ unsigned long sun; /* _SUN */
};
#define acpi_device_bid(d) ((d)->pnp.bus_id)
Index: linux-3.5/drivers/acpi/scan.c
===
--- linux-3.5.orig/drivers/acpi/scan.c 2012-07-22 05:58:29.0 +0900
+++ linux-3.5/drivers/acpi/scan.c 2012-07-27 10:17:55.670550879 +0900
@@ -192,10 +192,21 @@ end:
}
static DEVICE_ATTR(path, 0444, acpi_device_path_show, NULL);
+static ssize_t
+acpi_device_sun_show(struct device *dev, struct device_attribute *attr, char
*buf) {
+ struct acpi_device *acpi_dev = to_acpi_device(dev);
+ int result;
+
+ result = sprintf(buf, "%lu\n", acpi_dev->pnp.sun);
+ return result;
+}
+static DEVICE_ATTR(sun, 0444, acpi_device_sun_show, NULL);
+
static int acpi_device_setup_files(struct acpi_device *dev)
{
acpi_status status;
acpi_handle temp;
+ unsigned long long sun;
int result = 0;
/*
@@ -217,6 +228,14 @@ static int acpi_device_setup_files(struc
goto end;
}
+ status = acpi_evaluate_integer(dev->handle, "_SUN", NULL, );
+ if (ACPI_SUCCESS(status)) {
+ dev->pnp.sun = (unsigned long)sun;
+ result = device_create_file(>dev, _attr_sun);
+ if (result)
+ goto end;
+ }
+
/*
* If device has _EJ0, 'eject' file is created that is used to trigger
* hot-removal function from userland.
@@ -241,6 +260,10 @@ static void acpi_device_remove_files(str
if (ACPI_SUCCESS(status))
device_remove_file(>dev, _attr_eject);
+ status = acpi_get_handle(dev->handle, "_SUN", );
+ if (ACPI_SUCCESS(status))
+ device_remove_file(>dev, _attr_sun);
+
device_remove_file(>dev, _attr_modalias);
device_remove_file(>dev, _attr_hid);
if (dev->handle)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 use the generic thermal sysfs.
On Fri, 2012-07-27 at 09:21 +0800, Zhang Rui wrote: > On 四, 2012-07-26 at 17:31 +0800, Wei Ni wrote: > > On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote: > > > On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote: > > > > > > > > Our tegra thermal framework also will use the generic thermal layer. It > > > > will register the cooling device, and run the throttling in this generic > > > > framework. > > > > But we have a special mechanism, when the temp is below the trip temp, > > > > we will set different cpu capability for different temp range. For > > > > example, set the low/high temp as 20C/30C to the sensor, and set the cpu > > > > to the max capability, it mean the cpu can run up to the max freq and > > > > voltage in this temp range. if the temp is out that range, the sensor > > > > will have irq/alert to notify the tegra framework, then we will set to > > > > another temperature range and cpu capability. > > > > I think we can try to add this mechanism to the generic framework as a > > > > new policy, right? > > > > > > > I think you can make use of the upper limit in my patch set. > > > Say, here is your thermal policy > > > 20C - 30C, P0 > > > 30C - 40C, P1 - P2 > > > 40C - 60C, P3 - P5 > > > 60C+, P6 ~ Pn > > > > > > you can register to the thermal layer 4 passive trip points, > > > 20C, 30C, 40C, 60C, and then > > > 1) for trip 0 (20C), upper limit 0, lower limit 0 > > > 2) for trip 1 (30C), upper limit 2, lower limit 1 > > > 3) for trip 2 (40C), upper limit 5, lower limit 3 > > > 4) for trip 3 (60C), upper limit n, lower limit 6 > > > > > > you can program your own sensor to get interrupt when the temperature > > > hits 20C/30C/40C/60C, and the generic thermal layer will put the > > > processors to proper frequency for each trip point. > > > > > > what do you think? > > > > Hi, Rui > > I'm trying your upper/lower codes on our tegra platform. > > Since we want to set limit value to the sensor to get interrupt, and > > many sensor drivers can support the limit alert property, could we add a > > new callback .set_limits() for the thermal zone device, so that we can > > program it in the generic layer. when the temperature hits the > > trip_temp, > > at this time, there should be an interrupt, right? Yes, there will have an interrupt. > > > we can try to set to the next limit range. > > is it possible to program the sensor at this time, in your own thermal > driver? Since we are using the generic thermal driver lm90.c, I'm not sure if we could program these limits in the generic driver, I think it's better to have a generic interface to set the limits, so I wish to add a callback .set_limits() in the generic thermal framework. > > thanks, > rui > > I can try to add these codes base on your patches. > > > > Thanks. > > Wei. > > > > > > > > BTW, the upper and lower limit is introduced in the patch set I'm > > > testing, so maybe you were not aware of it. > > > > > > thanks, > > > rui > > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: RAID extremely slow
On Wed, 2012-07-25 at 18:55 -0700, Kevin Ross wrote: > On 07/25/2012 06:00 PM, Phil Turmel wrote: > > Piles of small reads scattered across multiple drives, and a > > concentration of queued writes to /dev/sda. What's on /dev/sda? > > It's not a member of the raid, so it must be some other system task > > involved. > After rebooting, MythTV is currently recording two shows, and the resync > is running at full speed. > > # cat /proc/mdstat > Personalities : [raid6] [raid5] [raid4] > md0 : active raid6 sdh1[0] sdd1[9] sde1[10] sdb1[6] sdi1[7] sdc1[4] > sdf1[3] sdg1[8] sdj1[1] >6837311488 blocks super 1.2 level 6, 512k chunk, algorithm 2 > [9/9] [U] >[=>...] resync = 9.3% (91363840/976758784) > finish=1434.3min speed=10287K/sec > > unused devices: > > atop shows the avio of all the drives to be less than 1ms, where before > they were much higher. It will run for a couple days under load just > fine, and then it will come to a halt. > > It's a 3.2.21 kernel. I'm running Debian Testing, and the exact Debian > package version is: I suspect you are being hit by same bug I was -- delayed stripes never got processed. If you get into the state where the rebuild isn't progressing, and you find that increasing the size of the stripe cache allows the rebuild to proceed (but the filesystem stays wedged), then that cinches it. If you can, upgrade to the latest 3.4 stable kernel (3.4.6 right now). As far as I can see, the latest 3.2 stable does not contain the delayed stripe fix. After applying those fixes to my kernel, my MythTV setup over a 5 disk RAID5 has been pretty solid, where before I was getting lockups every few days. It still seems to be getting slower over time, but I've not looked into it yet as it is not as catastrophic as the wedging. HTH, Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RAID extremely slow
On Thu, 2012-07-26 at 22:15 -0400, David Dillow wrote: > If you can, upgrade to the latest 3.4 stable kernel (3.4.6 right now). > As far as I can see, the latest 3.2 stable does not contain the delayed > stripe fix. And I was looking at the wrong version; 3.2.24 does indeed have the fix. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] ACPI: Update Container hotplug messages
On Thu, 2012-07-26 at 13:23 -0600, Bjorn Helgaas wrote:
> On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani wrote:
> > Updated Container hotplug log messages with acpi_pr_()
> > and pr_().
> >
> > Signed-off-by: Toshi Kani
> > ---
> > drivers/acpi/container.c |6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
> > index 01a986d..643e962 100644
> > --- a/drivers/acpi/container.c
> > +++ b/drivers/acpi/container.c
> > @@ -99,7 +99,7 @@ static int acpi_container_add(struct acpi_device *device)
> >
> >
> > if (!device) {
> > - printk(KERN_ERR PREFIX "device is NULL\n");
> > + pr_err(PREFIX "device is NULL\n");
> > return -EINVAL;
> > }
>
> This whole "if (!device)" check and the printk should be deleted. If
> the ACPI core calls .add() with a null acpi_device pointer, it's a
> core bug, and it's better to take the oops and get the backtrace.
Agreed. Delete the check.
> >
> > @@ -164,7 +164,7 @@ static void container_notify_cb(acpi_handle handle, u32
> > type, void *context)
> > case ACPI_NOTIFY_BUS_CHECK:
> > /* Fall through */
> > case ACPI_NOTIFY_DEVICE_CHECK:
> > - printk(KERN_WARNING "Container driver received %s event\n",
> > + pr_warn("Container driver received %s event\n",
> >(type == ACPI_NOTIFY_BUS_CHECK) ?
> >"ACPI_NOTIFY_BUS_CHECK" :
> > "ACPI_NOTIFY_DEVICE_CHECK");
>
> This message looks dubious. Receiving this event should be a normal
> occurrence, so the message might be useful for debugging, but doesn't
> seem like a KERN_WARNING event for the user.
Changed to pr_debug() for now.
Thanks!
-Toshi
> >
> > @@ -185,7 +185,7 @@ static void container_notify_cb(acpi_handle handle, u32
> > type, void *context)
> >
> > result = container_device_add(, handle);
> > if (result) {
> > - pr_warn("Failed to add container\n");
> > + acpi_pr_warn(handle, "Failed to add container\n");
> > break;
> > }
> >
> > --
> > 1.7.7.6
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] ACPI: Update Memory hotplug messages
On Thu, 2012-07-26 at 13:23 -0600, Bjorn Helgaas wrote:
> On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani wrote:
> > Updated Memory hotplug log messages with acpi_pr_()
> > and pr_().
> >
> > Signed-off-by: Toshi Kani
> > ---
> > drivers/acpi/acpi_memhotplug.c | 24
> > 1 files changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> > index 06c55cd..dcc8f4d 100644
> > --- a/drivers/acpi/acpi_memhotplug.c
> > +++ b/drivers/acpi/acpi_memhotplug.c
> > @@ -170,7 +170,7 @@ acpi_memory_get_device(acpi_handle handle,
> > /* Get the parent device */
> > result = acpi_bus_get_device(phandle, );
> > if (result) {
> > - printk(KERN_WARNING PREFIX "Cannot get acpi bus device");
> > + acpi_pr_warn(phandle, "Cannot get acpi bus device\n");
> > return -EINVAL;
> > }
> >
> > @@ -180,14 +180,14 @@ acpi_memory_get_device(acpi_handle handle,
> > */
> > result = acpi_bus_add(, pdevice, handle,
> > ACPI_BUS_TYPE_DEVICE);
> > if (result) {
> > - printk(KERN_WARNING PREFIX "Cannot add acpi bus");
> > + acpi_pr_warn(handle, "Cannot add acpi bus\n");
> > return -EINVAL;
> > }
> >
> >end:
> > *mem_device = acpi_driver_data(device);
> > if (!(*mem_device)) {
> > - printk(KERN_ERR "\n driver data not found");
> > + acpi_pr_err(handle, "driver data not found\n");
>
> acpi_driver_data() requires a valid acpi_device *, so dev_err() should
> work here.
Agreed. Changed to use dev_err().
>
> > return -ENODEV;
> > }
> >
> > @@ -224,7 +224,7 @@ static int acpi_memory_enable_device(struct
> > acpi_memory_device *mem_device)
> > /* Get the range from the _CRS */
> > result = acpi_memory_get_device_resources(mem_device);
> > if (result) {
> > - printk(KERN_ERR PREFIX "get_device_resources failed\n");
> > + pr_err(PREFIX "get_device_resources failed\n");
>
> And here.
Changed to use dev_err().
>
> > mem_device->state = MEMORY_INVALID_STATE;
> > return result;
> > }
> > @@ -257,7 +257,7 @@ static int acpi_memory_enable_device(struct
> > acpi_memory_device *mem_device)
> > num_enabled++;
> > }
> > if (!num_enabled) {
> > - printk(KERN_ERR PREFIX "add_memory failed\n");
> > + acpi_pr_err(mem_device->device->handle, "add_memory
> > failed\n");
>
> And here.
Changed to use dev_err().
>
> > mem_device->state = MEMORY_INVALID_STATE;
> > return -EINVAL;
> > }
> > @@ -353,7 +353,7 @@ static void acpi_memory_device_notify(acpi_handle
> > handle, u32 event, void *data)
> > ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> > "\nReceived DEVICE CHECK
> > notification for device\n"));
> > if (acpi_memory_get_device(handle, _device)) {
> > - printk(KERN_ERR PREFIX "Cannot find driver data\n");
> > + acpi_pr_err(handle, "Cannot find driver data\n");
> > break;
> > }
> >
> > @@ -361,7 +361,7 @@ static void acpi_memory_device_notify(acpi_handle
> > handle, u32 event, void *data)
> > break;
> >
> > if (acpi_memory_enable_device(mem_device)) {
> > - pr_err(PREFIX "Cannot enable memory device\n");
> > + acpi_pr_err(handle, "Cannot enable memory
> > device\n");
>
> And here.
No change since it is called directly from the handler.
> > break;
> > }
> >
> > @@ -373,12 +373,12 @@ static void acpi_memory_device_notify(acpi_handle
> > handle, u32 event, void *data)
> > "\nReceived EJECT REQUEST notification
> > for device\n"));
> >
> > if (acpi_bus_get_device(handle, )) {
> > - printk(KERN_ERR PREFIX "Device doesn't exist\n");
> > + acpi_pr_err(handle, "Device doesn't exist\n");
> > break;
> > }
> > mem_device = acpi_driver_data(device);
> > if (!mem_device) {
> > - printk(KERN_ERR PREFIX "Driver Data is NULL\n");
> > + acpi_pr_err(handle, "Driver Data is NULL\n");
>
> And here.
No change since it is called directly from the handler.
> > break;
> > }
> >
> > @@ -389,7 +389,7 @@ static void acpi_memory_device_notify(acpi_handle
> > handle, u32 event, void *data)
> > * with generic sysfs driver
> > */
> > if (acpi_memory_disable_device(mem_device)) {
> > -
Re: RAID extremely slow
On 07/26/2012 07:27 PM, David Dillow wrote: On Thu, 2012-07-26 at 19:17 -0700, Kevin Ross wrote: On 07/26/2012 07:17 PM, David Dillow wrote: On Thu, 2012-07-26 at 22:15 -0400, David Dillow wrote: If you can, upgrade to the latest 3.4 stable kernel (3.4.6 right now). As far as I can see, the latest 3.2 stable does not contain the delayed stripe fix. And I was looking at the wrong version; 3.2.24 does indeed have the fix. I'm running 3.2.21, does that contain the fix? No, that was the one I looked at. It is commit c0159c780e8d42309d04e83271986274d3880826. Okay, I grabbed 3.4.4 from Debian experimental, and I'm running with that now. Hopefully this fixes the problem. Thanks for your help! -- Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] ACPI: Update CPU hotplug messages
On Thu, 2012-07-26 at 13:23 -0600, Bjorn Helgaas wrote:
> On Wed, Jul 25, 2012 at 5:12 PM, Toshi Kani wrote:
> > Updated CPU hotplug log messages with acpi_pr_(),
> > dev_() and pr_(). Some messages are also
> > changed for clarity.
> >
> > Signed-off-by: Toshi Kani
> > Tested-by: Vijay Mohan Pandarathil
> > ---
> > drivers/acpi/processor_driver.c | 36 +---
> > 1 files changed, 21 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_driver.c
> > b/drivers/acpi/processor_driver.c
> > index a6bdeaa..225f252 100644
> > --- a/drivers/acpi/processor_driver.c
> > +++ b/drivers/acpi/processor_driver.c
> > @@ -282,7 +282,9 @@ static int acpi_processor_get_info(struct acpi_device
> > *device)
> > /* Declared with "Processor" statement; match ProcessorID */
> > status = acpi_evaluate_object(pr->handle, NULL, NULL,
> > );
> > if (ACPI_FAILURE(status)) {
> > - printk(KERN_ERR PREFIX "Evaluating processor
> > object\n");
> > + acpi_pr_err(pr->handle,
> > + "Failed to evaluate processor object
> > (0x%x)\n",
> > + status);
>
> This looks like it could be a dev_err().
Agreed. Changed to use dev_err().
> > return -ENODEV;
> > }
> >
> > @@ -301,8 +303,9 @@ static int acpi_processor_get_info(struct acpi_device
> > *device)
> > status = acpi_evaluate_integer(pr->handle, METHOD_NAME__UID,
> > NULL, );
> > if (ACPI_FAILURE(status)) {
> > - printk(KERN_ERR PREFIX
> > - "Evaluating processor _UID [%#x]\n", status);
> > + acpi_pr_err(pr->handle,
> > + "Failed to evaluate processor _UID
> > (0x%x)\n",
> > + status);
>
> And this.
Changed to use dev_err().
> > return -ENODEV;
> > }
> > device_declaration = 1;
> > @@ -345,7 +348,7 @@ static int acpi_processor_get_info(struct acpi_device
> > *device)
> > if (!object.processor.pblk_address)
> > ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL
> > address)\n"));
> > else if (object.processor.pblk_length != 6)
> > - printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n",
> > + acpi_pr_err(pr->handle, "Invalid PBLK length [%d]\n",
>
> And this.
Changed to use dev_err().
>
> > object.processor.pblk_length);
> > else {
> > pr->throttling.address = object.processor.pblk_address;
> > @@ -429,8 +432,8 @@ static int acpi_cpu_soft_notify(struct notifier_block
> > *nfb,
> > * Initialize missing things
> > */
> > if (pr->flags.need_hotplug_init) {
> > - printk(KERN_INFO "Will online and init hotplugged "
> > - "CPU: %d\n", pr->id);
> > + pr_info("Will online and init hotplugged CPU: %d\n",
> > + pr->id);
> > WARN(acpi_processor_start(pr), "Failed to start
> > CPU:"
> > " %d\n", pr->id);
> > pr->flags.need_hotplug_init = 0;
> > @@ -491,14 +494,16 @@ static __ref int acpi_processor_start(struct
> > acpi_processor *pr)
> >>cdev->device.kobj,
> >"thermal_cooling");
> > if (result) {
> > - printk(KERN_ERR PREFIX "Create sysfs link\n");
> > + dev_err(>dev,
> > + "Failed to create sysfs link 'thermal_cooling'\n");
> > goto err_thermal_unregister;
> > }
> > result = sysfs_create_link(>cdev->device.kobj,
> >>dev.kobj,
> >"device");
> > if (result) {
> > - printk(KERN_ERR PREFIX "Create sysfs link\n");
> > + dev_err(>cdev->device,
> > + "Failed to create sysfs link 'device'\n");
> > goto err_remove_sysfs_thermal;
> > }
> >
> > @@ -560,8 +565,7 @@ static int __cpuinit acpi_processor_add(struct
> > acpi_device *device)
> > */
> > if (per_cpu(processor_device_array, pr->id) != NULL &&
> > per_cpu(processor_device_array, pr->id) != device) {
> > - printk(KERN_WARNING "BIOS reported wrong ACPI id "
> > - "for the processor\n");
> > + pr_warn("BIOS reported wrong ACPI id for the processor\n");
>
> And this.
Changed to use dev_warn().
> > result = -ENODEV;
> > goto err_free_cpumask;
> > }
> > @@ -715,7 +719,7 @@
Re: [PATCH] staging/olpc_dcon: fix checkpatch warnings
On Fri, Jul 27, 2012 at 11:28 AM, Andres Salomon wrote: > On Fri, 27 Jul 2012 08:49:19 +0900 > Toshiaki Yamane wrote: > >> Now checkpatch clean. >> >> $ find drivers/staging/olpc_dcon/ -name >> "*.[ch]"|xargs ./scripts/checkpatch.pl \ -f --terse --nosummary|cut >> -f3- -d":"|sort |uniq -c|sort -n 2 WARNING: msleep < 20ms can sleep >> for up to 20ms; see Documentation/timers/timers-howto.txt 3 WARNING: > > NACK - please don't modify the msleep timings right now. The pr_* > changes are welcome, however. > I agree. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/olpc_dcon: fix checkpatch warnings
On Fri, 27 Jul 2012 08:49:19 +0900 Toshiaki Yamane wrote: > Now checkpatch clean. > > $ find drivers/staging/olpc_dcon/ -name > "*.[ch]"|xargs ./scripts/checkpatch.pl \ -f --terse --nosummary|cut > -f3- -d":"|sort |uniq -c|sort -n 2 WARNING: msleep < 20ms can sleep > for up to 20ms; see Documentation/timers/timers-howto.txt 3 WARNING: NACK - please don't modify the msleep timings right now. The pr_* changes are welcome, however. > Prefer pr_debug(... to printk(KERN_DEBUG, ... 3 WARNING: Prefer > pr_warn(... to printk(KERN_WARNING, ... 6 WARNING: Prefer > pr_info(... to printk(KERN_INFO, ... 19 WARNING: Prefer pr_err(... > to printk(KERN_ERR, ... > > And added pr_fmt. > > Signed-off-by: Toshiaki Yamane [...] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: RAID extremely slow
On Thu, 2012-07-26 at 19:17 -0700, Kevin Ross wrote: > On 07/26/2012 07:17 PM, David Dillow wrote: > > On Thu, 2012-07-26 at 22:15 -0400, David Dillow wrote: > >> If you can, upgrade to the latest 3.4 stable kernel (3.4.6 right now). > >> As far as I can see, the latest 3.2 stable does not contain the delayed > >> stripe fix. > > And I was looking at the wrong version; 3.2.24 does indeed have the fix. > > > > I'm running 3.2.21, does that contain the fix? No, that was the one I looked at. It is commit c0159c780e8d42309d04e83271986274d3880826. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/17] vfs: add the ability to retry on ESTALE to several syscalls
Hi Jeff. Which testcase(or test method) do I use to know improved point from ESTALE error ? I want to know before & after using testcase with this patch-set. Thanks. 2012/7/26, Jeff Layton : > This patchset is a respin of the one I sent on June 29th. The main > reason for the resend is to deal with some minor merge conflicts that > have cropped up due to recent changes. > > This series depends on the "audit" series that I sent earlier today. > It's also available via the "estale" branch of my git tree: > > git://git.samba.org/jlayton/linux.git estale > > The original cover letter text follows: > > ESTALE errors are a source of pain for many users, primarily those who > are doing work on NFS. When userspace provides a path to a syscall, then > there's really little excuse for returning ESTALE. If userspace gave us > a path that we had to lookup in order to do the call, then it's not > particularly helpful to return ESTALE just because that path went stale > before we could do the actual operation. > > We can and should do better here. The kernel should instead catch that > error and retry the lookup and call, while forcing a revalidation of all > dentries involved. > > Unfortunately fixing this requires touching the syscalls themselves, or > at least their immediate helper functions. Not all syscalls can be > retried -- only those that take a pathname as an argument. > > With this patchset, I've decided to take the relatively less > controversial approach of just having the kernel retry once when it gets > an ESTALE error. I still think that it's not as strong as it should be, > but it should improve the situation in many common cases. > > I've also tried to engineer this in such a way that if we do decide that > we need to retry more than once, then it should be easy to change that > later. This should cover all of the syscalls in fs/stat.c and > fs/namei.c. > > Once these are merged, I'll look at adding similar handling to other > path-based syscalls in a later set. A quick look shows that we have > about 50-odd path-based syscalls that will need similar handling, so > this is just a start. > > Jeff Layton (17): > vfs: add a retry_estale helper function to handle retries on ESTALE > vfs: add a kern_path_at function > vfs: make fstatat retry on ESTALE errors from getattr call > vfs: fix readlinkat to retry on ESTALE > vfs: remove user_path_at_empty > vfs: turn "empty" arg in getname_flags into a bool > vfs: add new "reval" argument to kern_path_create > vfs: fix mknodat to retry on ESTALE errors > vfs: fix mkdir to retry on ESTALE errors > vfs: fix symlinkat to retry on ESTALE errors > vfs: fix linkat to retry on ESTALE errors > vfs: make rmdir retry on ESTALE errors > vfs: make do_unlinkat retry on ESTALE errors > vfs: fix renameat to retry on ESTALE errors > vfs: remove user_path_parent > vfs: have do_sys_truncate retry once on an ESTALE error > vfs: have faccessat retry once on an ESTALE error > > drivers/base/devtmpfs.c | 7 +- > fs/namei.c | 407 > +--- > fs/open.c | 162 ++- > fs/stat.c | 44 -- > include/linux/fs.h | 22 +++ > include/linux/namei.h | 4 +- > net/unix/af_unix.c | 3 +- > 7 files changed, 400 insertions(+), 249 deletions(-) > > -- > 1.7.11.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: RAID extremely slow
On 07/26/2012 07:17 PM, David Dillow wrote: On Thu, 2012-07-26 at 22:15 -0400, David Dillow wrote: If you can, upgrade to the latest 3.4 stable kernel (3.4.6 right now). As far as I can see, the latest 3.2 stable does not contain the delayed stripe fix. And I was looking at the wrong version; 3.2.24 does indeed have the fix. I'm running 3.2.21, does that contain the fix? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/olpc_dcon: fix checkpatch warnings
On Fri, Jul 27, 2012 at 10:40 AM, Joe Perches wrote:
> On Fri, 2012-07-27 at 08:49 +0900, Toshiaki Yamane wrote:
>> Now checkpatch clean.
> []
>> diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
>> b/drivers/staging/olpc_dcon/olpc_dcon.c
> []
>> @@ -11,6 +11,7 @@
> []
>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> []
>> @@ -71,18 +72,18 @@ static int dcon_hw_init(struct dcon_priv *dcon, int
>> is_init)
>>
>> ver = dcon_read(dcon, DCON_REG_ID);
>> if ((ver >> 8) != 0xDC) {
>> - printk(KERN_ERR "olpc-dcon: DCON ID not 0xDCxx: 0x%04x
>> instead.\n",
>> - ver);
>> + pr_err("olpc-dcon: DCON ID not 0xDCxx: 0x%04x instead.\n",
>> +ver);
>> rc = -ENXIO;
>> goto err;
>> }
>>
>> if (is_init) {
>> - printk(KERN_INFO "olpc-dcon: Discovered DCON version %x\n",
>> - ver & 0xFF);
>> + pr_info("olpc-dcon: Discovered DCON version %x\n",
>> + ver & 0xFF);
>
> Hello.
>
> Please remove all the embedded "olpc-dcon: " prefixes.
> There is a pr_fmt define that adds "olpc_dcon" already.
>
> You can use the strings program on the output .o files to
> verify the formats that are produced.
>
Thanks for your reply.
I was able to check for duplicates in strings.
I will try to fix with care.
--
Regards,
.
.
...
Yamane Toshiaki
yamaneto...@gmail.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/
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 9161c3b796a2841a9a7be3d9c9dd121269ce90e8: Merge tag 'clk-for-linus' of git://git.linaro.org/people/mturquette/linux (2012-07-24 16:40:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for you to fetch changes up to fa7c865ad999d6ca340bca471fab7f3a3e6ae011: ARM: mxs: fix compile error caused by prom_update_property change (2012-07-25 22:36:39 -0700) ARM: SoC fixes A mixed bag of fixes, some for merge window fallout (tegra, MXS), and a short series of fixes for marvell platforms that didn't make it in before 3.5. Andrew Lunn (2): ARM: Kirkwood: Ensure runit clock always ticks. ARM: Kirkwood: Replace mrvl with marvell Arnd Bergmann (2): Merge branch 'master' of git://git.kernel.org/.../torvalds/linux into fixes Merge branch 'v3.5-rc7-fixes' of git://github.com/lunn/linux into fixes Hannes Reinecke (1): ARM: Dove: Fixup ge00 initialisation Laxman Dewangan (1): ARM: tegra: harmony: add regulator supply name and its input supply Pawel Moll (1): ARM: versatile: Don't use platform clock for Integrator & VE Shawn Guo (1): ARM: mxs: fix compile error caused by prom_update_property change Simon Baatz (2): ARM: Kirkwood: Fix PHY disable clk problems ARM: Orion: fix driver probe error handling with respect to clk Stephen Warren (2): ARM: dt: tegra trimslice: add vbus-gpio property ARM: dt: tegra trimslice: enable USB2 port Tony Prisk (1): ARM: vt8500: Add maintainer for VT8500 architecture .../devicetree/bindings/mtd/orion-nand.txt | 4 +- MAINTAINERS| 11 arch/arm/Kconfig | 2 - arch/arm/boot/dts/kirkwood-dns320.dts | 2 +- arch/arm/boot/dts/kirkwood-dns325.dts | 2 +- arch/arm/boot/dts/kirkwood-dreamplug.dts | 2 +- arch/arm/boot/dts/kirkwood-ib62x0.dts | 2 +- arch/arm/boot/dts/kirkwood-iconnect.dts| 2 +- arch/arm/boot/dts/kirkwood.dtsi| 6 +- arch/arm/boot/dts/tegra20-trimslice.dts| 2 + arch/arm/mach-dove/common.c| 4 +- arch/arm/mach-kirkwood/common.c| 70 +- arch/arm/mach-mxs/mach-mxs.c | 8 +-- arch/arm/mach-tegra/board-harmony-power.c | 33 ++ drivers/crypto/mv_cesa.c | 4 ++ drivers/mmc/host/mvsdio.c | 4 ++ drivers/mtd/nand/orion_nand.c | 6 +- drivers/net/ethernet/marvell/mv643xx_eth.c | 6 ++ drivers/rtc/rtc-mv.c | 2 +- drivers/usb/host/ehci-orion.c | 4 ++ sound/soc/kirkwood/kirkwood-i2s.c | 8 ++- 21 files changed, 133 insertions(+), 51 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: [RFC PATCH 12/13] driver core: firmware loader: use small timeout for cache device firmware
On Fri, Jul 27, 2012 at 1:54 AM, Borislav Petkov wrote: >> No, it is not what I was saying. I just mean the point is not mentioned in my commit log, but I admit it should be a appropriate cause. > > Ok, maybe I'm not understanding this then. So explain to me this: why > do you need that timeout value of 10, how did we decide it to be 10 If one firmware image was loaded successfully before, the probability of loading it successfully at this time should be much higher than the 1st time because something crazy(for example, the firmware is deleted) happens with low probability. Choosing 10 secs is just a estimation for loading time because the maximum size of firmware in current distributions is about 2M bytes, since we know it has been loaded successfully before. > (and not 20 or 30 or whatever)? Generally, why do we need to reprogram > the timer to a smaller timeout instead of simply doing the completion > without a timeout? No, it should be crazy without a timeout, and it can be triggered in init call easily. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sched: fix a logical error in select_task_rq_fair
>> In that case aren't we covering up a bug in find_idlest_group(), it >> appears to have returned a group that isn't eligible to be idlest. > > > If it is possible happening in sched_domain rebuilding? > I didn't meet this bug. Just guess. Even so, it is not related with this patch. So, Thanks for clarify! and forget 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 1/2] sched: recover SD_WAKE_AFFINE in select_task_rq_fair and code clean up
On 07/26/2012 05:37 PM, Mike Galbraith wrote:
> On Thu, 2012-07-26 at 13:27 +0800, Alex Shi wrote:
>
>> if (affine_sd) {
>> -if (cpu == prev_cpu || wake_affine(affine_sd, p, sync))
>> +if (wake_affine(affine_sd, p, sync))
>> prev_cpu = cpu;
>>
>> new_cpu = select_idle_sibling(p, prev_cpu);
>
> Hm, if cpu == prev_cpu, asking wake_affine() if it's ok to put wakee
> back where it came from is wasted cycles.. that's where the task is
> headed regardless of reply.
>
> -Mike
>
Sure. I modified the patch as below:
===
>From 610515185d8a98c14c7c339c25381bc96cd99d93 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Thu, 26 Jul 2012 08:55:34 +0800
Subject: [PATCH 1/3] sched: recover SD_WAKE_AFFINE in select_task_rq_fair and
code clean up
Since power saving code was removed from sched now, the implement
code is out of service in this function, and even pollute other logical.
like, 'want_sd' never has chance to be set '0', that remove the effect
of SD_WAKE_AFFINE here.
So, clean up the obsolete code and some other unnecessary code.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 32 +++-
1 files changed, 3 insertions(+), 29 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 22321db..53fd8db 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2686,7 +2686,6 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
int wake_flags)
int prev_cpu = task_cpu(p);
int new_cpu = cpu;
int want_affine = 0;
- int want_sd = 1;
int sync = wake_flags & WF_SYNC;
if (p->nr_cpus_allowed == 1)
@@ -2704,48 +2703,23 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
int wake_flags)
continue;
/*
-* If power savings logic is enabled for a domain, see if we
-* are not overloaded, if so, don't balance wider.
-*/
- if (tmp->flags & (SD_PREFER_LOCAL)) {
- unsigned long power = 0;
- unsigned long nr_running = 0;
- unsigned long capacity;
- int i;
-
- for_each_cpu(i, sched_domain_span(tmp)) {
- power += power_of(i);
- nr_running += cpu_rq(i)->cfs.nr_running;
- }
-
- capacity = DIV_ROUND_CLOSEST(power, SCHED_POWER_SCALE);
-
- if (nr_running < capacity)
- want_sd = 0;
- }
-
- /*
* If both cpu and prev_cpu are part of this domain,
* cpu is a valid SD_WAKE_AFFINE target.
*/
if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
affine_sd = tmp;
- want_affine = 0;
- }
-
- if (!want_sd && !want_affine)
break;
+ }
if (!(tmp->flags & sd_flag))
continue;
- if (want_sd)
- sd = tmp;
+ sd = tmp;
}
if (affine_sd) {
- if (cpu == prev_cpu || wake_affine(affine_sd, p, sync))
+ if (cpu != prev_cpu && wake_affine(affine_sd, p, sync))
prev_cpu = cpu;
new_cpu = select_idle_sibling(p, prev_cpu);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [vmw_vmci 00/11] VMCI for Linux
On Thu, Jul 26, 2012 at 09:06:25PM -0400, Josh Boyer wrote: > On Thu, Jul 26, 2012 at 7:39 PM, Andrew Stiegmann (stieg) > wrote: > > drivers/misc/Kconfig |1 + > > drivers/misc/Makefile |1 + > > drivers/misc/vmw_vmci/Kconfig | 16 + > > Is there a reason this isn't going into staging first? The Hyper-V > drivers went through staging and that actually seemed to work fairly > well. Is there some reason you feel this should be in the staging tree now? Why? 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 v8 0/7] power management patch set
On 07/26/2012 09:02 AM, Li Yang wrote: > On Fri, Jul 20, 2012 at 8:42 PM, Zhao Chenhui > wrote: >> Changes for v8: >> * Separated the cpu hotplug patch into three patches, as follows >> [PATCH v8 1/7] powerpc/smp: use a struct epapr_spin_table to replace macros >> [PATCH v8 2/7] powerpc/smp: add generic_set_cpu_up() to set cpu_state as >> CPU_UP_PREPARE >> [PATCH v8 4/7] powerpc/85xx: add HOTPLUG_CPU support >> >> * Replaced magic numbers with macros in "[PATCH 5/7] powerpc/85xx: add sleep >> and deep sleep support" >> >> * no change to the rest of the patch set > > Hi Kumar, > > How about picking about this series for 3.6? The review seems to > settle down for this revision. > > > Hi Scott, > > Thanks for the review comments provided. We'd like to get the ACK > from you for the series if you can. I ACKed v7; I assume v8 hasn't made anything worse. :-) I think it's time to merge this, and deal with any issues as they come up. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/olpc_dcon: fix checkpatch warnings
On Fri, 2012-07-27 at 08:49 +0900, Toshiaki Yamane wrote:
> Now checkpatch clean.
[]
> diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
> b/drivers/staging/olpc_dcon/olpc_dcon.c
[]
> @@ -11,6 +11,7 @@
[]
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
[]
> @@ -71,18 +72,18 @@ static int dcon_hw_init(struct dcon_priv *dcon, int
> is_init)
>
> ver = dcon_read(dcon, DCON_REG_ID);
> if ((ver >> 8) != 0xDC) {
> - printk(KERN_ERR "olpc-dcon: DCON ID not 0xDCxx: 0x%04x
> instead.\n",
> - ver);
> + pr_err("olpc-dcon: DCON ID not 0xDCxx: 0x%04x instead.\n",
> +ver);
> rc = -ENXIO;
> goto err;
> }
>
> if (is_init) {
> - printk(KERN_INFO "olpc-dcon: Discovered DCON version %x\n",
> - ver & 0xFF);
> + pr_info("olpc-dcon: Discovered DCON version %x\n",
> + ver & 0xFF);
Hello.
Please remove all the embedded "olpc-dcon: " prefixes.
There is a pr_fmt define that adds "olpc_dcon" already.
You can use the strings program on the output .o files to
verify the formats that are produced.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI: replace strlen("string") with sizeof("string") -1
...both give the number of chars in the string
without the '\0', as strncmp() wants,
but sizeof() is compile-time.
Reported-by: Alan Stern
Cc: Pavel Vasilyev
Signed-off-by: Len Brown
---
drivers/acpi/sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 240a244..7c3f98b 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -173,7 +173,7 @@ static int param_set_trace_state(const char *val,
struct kernel_param *kp)
{
int result = 0;
- if (!strncmp(val, "enable", strlen("enable"))) {
+ if (!strncmp(val, "enable", sizeof("enable") - 1)) {
result = acpi_debug_trace(trace_method_name, trace_debug_level,
trace_debug_layer, 0);
if (result)
@@ -181,7 +181,7 @@ static int param_set_trace_state(const char *val,
struct kernel_param *kp)
goto exit;
}
- if (!strncmp(val, "disable", strlen("disable"))) {
+ if (!strncmp(val, "disable", sizeof("disable") - 1)) {
int name = 0;
result = acpi_debug_trace((char *), trace_debug_level,
trace_debug_layer, 0);
--
1.7.12.rc0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/13] driver core: firmware loader: fix device lifetime
On Fri, Jul 27, 2012 at 1:46 AM, Borislav Petkov wrote: > On Thu, Jul 26, 2012 at 11:44:48PM +0800, Ming Lei wrote: >> On Thu, Jul 26, 2012 at 8:20 PM, Borislav Petkov wrote: >> > >> > Ok, here's what I got from looking at the patch: >> > >> > Your commit message says: "Also request_firmware_nowait should be called >> > in atomic context now, so fix the obsolete comments." >> > >> > Atomic context in my book means you're not allowed to sleep at all. >> >> In fact, I mean the function can be called in atomic context now, and >> I know some time ago the function will create kthread to execute >> the request_firmware, and atomic context is not allowed. > > Right, but when called with GFP_KERNEL mask, it can sleep, right? > >> > But the comment says that it is possible to sleep a little. This is very >> > wrongly formulated AFAICT. >> >> The function can be run in both contexts, and I don't see any words which >> says the function will sleep. > > " > ... > * Asynchronous variant of request_firmware() for user contexts where > * it is not possible to sleep for long time. > **/ > " > > Not possible to sleep for a long time means the function still *can* > sleep... even for short time. For a certain definion of "short." In fact, many drivers like to use it in its probe() because too long sleep in probe will slow down kernel boot if driver is built in kernel. During kernel boot, rootfs is not mounted and user space is not ready, request_firmware will timeout to cause problem. Also after introducing work in this function, it is allowed to be called in atomic context if 'gfp' is passed as GFP_ATOMIC, so I removed the obsolete comments. > >> > But, since request_firmware_nowait receives a GFP mask as one of its >> > arguments and some of its callers don't supply GFP_ATOMIC then this >> > has nothing to do with atomic contexts at all. Then, you should simply >> > explain in the comment why exactly callers aren't allowed to be sleeping >> > for a long time. And using adjectives like "long" or "short" is very >> > misleading in such explanations so please be more specific as to why the >> >> It is the original one, and I don't think it is wrong. Also it >> shouldn't be covered >> by this patch. >> >> Maybe I shouldn't have fixed the comment in this patch. > > Why, simply fix the comment to adhere to what the function does. And > since it can sleep, maybe the easiest fix is to say simply that: > "function can sleep", right? No, the comment above is misleading and not useless, and I think the below is good: * Asynchronous variant of request_firmware() for user contexts where * it is not possible to sleep for long time or can't sleep at all, depends * on the @gfp flag passed. Anyway, the original part of 'It can't be called in atomic contexts.' is wrong and should be 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/
RE: How to use the generic thermal sysfs.
On 四, 2012-07-26 at 17:31 +0800, Wei Ni wrote: > On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote: > > On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote: > > > > > > Our tegra thermal framework also will use the generic thermal layer. It > > > will register the cooling device, and run the throttling in this generic > > > framework. > > > But we have a special mechanism, when the temp is below the trip temp, > > > we will set different cpu capability for different temp range. For > > > example, set the low/high temp as 20C/30C to the sensor, and set the cpu > > > to the max capability, it mean the cpu can run up to the max freq and > > > voltage in this temp range. if the temp is out that range, the sensor > > > will have irq/alert to notify the tegra framework, then we will set to > > > another temperature range and cpu capability. > > > I think we can try to add this mechanism to the generic framework as a > > > new policy, right? > > > > > I think you can make use of the upper limit in my patch set. > > Say, here is your thermal policy > > 20C - 30C, P0 > > 30C - 40C, P1 - P2 > > 40C - 60C, P3 - P5 > > 60C+, P6 ~ Pn > > > > you can register to the thermal layer 4 passive trip points, > > 20C, 30C, 40C, 60C, and then > > 1) for trip 0 (20C), upper limit 0, lower limit 0 > > 2) for trip 1 (30C), upper limit 2, lower limit 1 > > 3) for trip 2 (40C), upper limit 5, lower limit 3 > > 4) for trip 3 (60C), upper limit n, lower limit 6 > > > > you can program your own sensor to get interrupt when the temperature > > hits 20C/30C/40C/60C, and the generic thermal layer will put the > > processors to proper frequency for each trip point. > > > > what do you think? > > Hi, Rui > I'm trying your upper/lower codes on our tegra platform. > Since we want to set limit value to the sensor to get interrupt, and > many sensor drivers can support the limit alert property, could we add a > new callback .set_limits() for the thermal zone device, so that we can > program it in the generic layer. when the temperature hits the > trip_temp, at this time, there should be an interrupt, right? > we can try to set to the next limit range. is it possible to program the sensor at this time, in your own thermal driver? thanks, rui > I can try to add these codes base on your patches. > > Thanks. > Wei. > > > > > BTW, the upper and lower limit is introduced in the patch set I'm > > testing, so maybe you were not aware of it. > > > > thanks, > > rui > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [vmw_vmci 00/11] VMCI for Linux
On Thu, Jul 26, 2012 at 7:39 PM, Andrew Stiegmann (stieg) wrote: > drivers/misc/Kconfig |1 + > drivers/misc/Makefile |1 + > drivers/misc/vmw_vmci/Kconfig | 16 + Is there a reason this isn't going into staging first? The Hyper-V drivers went through staging and that actually seemed to work fairly well. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure in Linus' tree
On Thu, Jul 26, 2012 at 5:15 PM, Stephen Rothwell wrote: > > After merging the origin tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: Oh well. I did an x86-64 build after that pull (because of the need for that semantic merge thing), but apparently x86-64 gets the vmalloc.h indirectly through some other header. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] A possible deadlock with stacked devices (was: [PATCH v4 08/12] block: Introduce new bio_split())
On Wed, 25 Jul 2012, Kent Overstreet wrote:
> On Wed, Jul 25, 2012 at 02:55:40PM +0300, Boaz Harrosh wrote:
> > On 07/24/2012 11:11 PM, Kent Overstreet wrote:
> >
> > > The new bio_split() can split arbitrary bios - it's not restricted to
> > > single page bios, like the old bio_split() (previously renamed to
> > > bio_pair_split()). It also has different semantics - it doesn't allocate
> > > a struct bio_pair, leaving it up to the caller to handle completions.
> > >
> > > Signed-off-by: Kent Overstreet
> > > ---
> > > fs/bio.c | 99
> > > ++
> > > 1 files changed, 99 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/fs/bio.c b/fs/bio.c
> > > index 5d02aa5..a15e121 100644
> > > --- a/fs/bio.c
> > > +++ b/fs/bio.c
> > > @@ -1539,6 +1539,105 @@ struct bio_pair *bio_pair_split(struct bio *bi,
> > > int first_sectors)
> > > EXPORT_SYMBOL(bio_pair_split);
> > >
> > > /**
> > > + * bio_split - split a bio
> > > + * @bio: bio to split
> > > + * @sectors: number of sectors to split from the front of @bio
> > > + * @gfp: gfp mask
> > > + * @bs: bio set to allocate from
> > > + *
> > > + * Allocates and returns a new bio which represents @sectors from the
> > > start of
> > > + * @bio, and updates @bio to represent the remaining sectors.
> > > + *
> > > + * If bio_sectors(@bio) was less than or equal to @sectors, returns @bio
> > > + * unchanged.
> > > + *
> > > + * The newly allocated bio will point to @bio's bi_io_vec, if the split
> > > was on a
> > > + * bvec boundry; it is the caller's responsibility to ensure that @bio
> > > is not
> > > + * freed before the split.
> > > + *
> > > + * If bio_split() is running under generic_make_request(), it's not safe
> > > to
> > > + * allocate more than one bio from the same bio set. Therefore, if it is
> > > running
> > > + * under generic_make_request() it masks out __GFP_WAIT when doing the
> > > + * allocation. The caller must check for failure if there's any
> > > possibility of
> > > + * it being called from under generic_make_request(); it is then the
> > > caller's
> > > + * responsibility to retry from a safe context (by e.g. punting to
> > > workqueue).
> > > + */
> > > +struct bio *bio_split(struct bio *bio, int sectors,
> > > + gfp_t gfp, struct bio_set *bs)
> > > +{
> > > + unsigned idx, vcnt = 0, nbytes = sectors << 9;
> > > + struct bio_vec *bv;
> > > + struct bio *ret = NULL;
> > > +
> > > + BUG_ON(sectors <= 0);
> > > +
> > > + /*
> > > + * If we're being called from underneath generic_make_request() and we
> > > + * already allocated any bios from this bio set, we risk deadlock if we
> > > + * use the mempool. So instead, we possibly fail and let the caller punt
> > > + * to workqueue or somesuch and retry in a safe context.
> > > + */
> > > + if (current->bio_list)
> > > + gfp &= ~__GFP_WAIT;
> >
> >
> > NACK!
> >
> > If as you said above in the comment:
> > if there's any possibility of it being called from under
> > generic_make_request();
> > it is then the caller's responsibility to ...
> >
> > So all the comment needs to say is:
> > ... caller's responsibility to not set __GFP_WAIT at gfp.
> >
> > And drop this here. It is up to the caller to decide. If the caller wants
> > he can do
> > "if (current->bio_list)" by his own.
> >
> > This is a general purpose utility you might not know it's context.
> > for example with osdblk above will break.
>
> Well I'm highly highly skeptical that using __GFP_WAIT under
> generic_make_request() is ever a sane thing to do - it could certainly
> be safe in specific circumstances, but it's just such a fragile thing to
> rely on, you have to _never_ use the same bio pool more than once. And
> even then I bet there's other subtle ways it could break.
>
> But you're not the first to complain about it, and your point about
> existing code is compelling.
Both md and dm use __GFP_WAIT allocations from mempools in
generic_make_request.
I think you found an interesting bug here. Suppose that we have three
stacked devices: d1 depends on d2 and d2 depends on d3.
Now, a bio b1 comes to d1. d1 splits it to two bios: b2.1 and b2.2 and
sends them to the device d2 - these bios end up in current->bio_list. The
driver for d2 receives bio b2.1 and sends bio b3.1 to d3. Now,
current->bio_list contains bios b2.2, b3.1. Now, bio b2.2 is popped off
the bio list and the driver for d2 is called with b2.2 - suppose that for
some reason mempool in d2 is exhausted and the driver needs to wait until
b2.1 finishes. b2.1 never finishes, because b2.1 depends on b3.1 and b3.1
is still in current->bio_list. So it deadlocks.
Turning off __GFP_WAIT fixes nothing - it just turns one bug (a possible
deadlock) into another bug (a possible bio failure with -ENOMEM).
Increasing mempool sizes doesn't fix it either, the bio would just have to
be split to more pieces in the above example
[GIT PULL] LED subsystem update for v3.6
Hi Linus, Please consider pulling the following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92: Linux 3.5 (2012-07-21 13:58:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for-3.6-rc1 for you to fetch changes up to d45bb11616c94c76c6e40960a120c0687b708a2e: leds-lp8788: forgotten unlock at lp8788_led_work (2012-07-27 08:16:07 +0800) Axel Lin (1): leds: max8997: Simplify max8997_led_set_mode implementation Bryan Wu (22): led-triggers: rename *trigger to *trig for unified naming scheme leds: fix sparse warnings due to missing static leds: convert Big Networks LED driver to devm_kzalloc() leds: convert HTC ASIC3 LED driver to devm_kzalloc() and cleanup error exit path leds: convert Atmel PWM LED driver to devm_kzalloc() leds: convert LP3944 LED driver to devm_kzalloc() leds: convert DA9030/DA9034 LED driver to devm_kzalloc() and cleanup error exit path leds: convert LP5521 LED driver to devm_kzalloc() and cleanup error exit path leds: convert BD2802 RGB LED driver to devm_kzalloc() and cleanup error exit path leds: convert PCA9633 LED driver to devm_kzalloc() leds: convert LP5523 LED driver to devm_kzalloc() and cleanup error exit path leds: convert Renesas TPU LED driver to devm_kzalloc() and cleanup error exit path leds: convert LT3593 LED driver to devm_kzalloc() leds: convert PCA9532 LED driver to devm_kzalloc() leds: convert Sun Fire LED driver to devm_kzalloc() and cleanup error exit path leds: convert PCA955x LED driver to devm_kzalloc() and cleanup error exit path leds: convert ADP5520 LED driver to devm_kzalloc() and cleanup error exit path leds: convert Freescale MC13783 LED driver to devm_kzalloc() and cleanup error exit path leds: convert TCA6507 LED driver to devm_kzalloc() leds: convert LM3530 LED driver to devm_kzalloc() and cleanup error exit path leds: convert DAC124S085 LED driver to devm_kzalloc() leds: convert Network Space v2 LED driver to devm_kzalloc() and cleanup error exit path Dan Carpenter (3): leds-lp5523: BUG() in error handling in probe() LEDS: memory leak in blinkm_led_common_set() LEDS: propagate error codes in blinkm_detect() Devendra Naga (5): leds: [trivial]Remove unnecesary return leds-88pm860x: use devm_kzalloc function leds-mc13783: set platform data to NULL at mc13783_led_remove leds/leds-s3c24xx: use devm_gpio_request leds-lp8788: forgotten unlock at lp8788_led_work Fabio Baltieri (5): leds: add oneshot blink functions ledtrig-ide-disk: use generic one-shot blink api leds: fix led_brightness_set when soft-blinking leds: add oneshot trigger leds: use led_set_brightness in led_trigger_event G.Shark Jeong (1): leds: Add LED driver for lm3556 chip Jan-Simon Möller (1): LEDS: add BlinkM RGB LED driver, documentation and update MAINTAINERS Jesper Dangaard Brouer (1): leds: correct trivial type in drivers/leds/Kconfig Kim, Milo (1): leds: add new lp8788 led driver Peter Meerwald (1): leds: convert tca6507 driver to module_i2c_driver() Sachin Kamat (5): leds: Use module_platform_driver() in leds-max8997.c file leds: Use devm_kzalloc in leds-pwm.c file leds: Use devm_kzalloc in leds-regulator.c file leds: Use devm_kzalloc in leds-max8997.c file leds: Use devm_kzalloc in leds-gpio.c file Shuah Khan (2): leds: Rename led_set_brightness() to __led_set_brightness() leds: Rename led_brightness_set() to led_set_brightness() Sylwester Nawrocki (2): leds: Convert S3C24XX LED driver to devm_kzalloc() leds: Convert S3C24XX LED driver to gpiolib API Documentation/leds/00-INDEX | 2 + Documentation/leds/leds-blinkm.txt| 80 +++ Documentation/leds/leds-lm3556.txt| 85 Documentation/leds/ledtrig-oneshot.txt| 59 +++ MAINTAINERS | 5 + drivers/leds/Kconfig | 39 +- drivers/leds/Makefile | 4 + drivers/leds/led-class.c | 27 +- drivers/leds/led-core.c | 66 ++- drivers/leds/led-triggers.c | 114 +++-- drivers/leds/leds-88pm860x.c | 9 +- drivers/leds/leds-adp5520.c | 8 +- drivers/leds/leds-asic3.c | 16 +- drivers/leds/leds-atmel-pwm.c | 5 +- drivers/leds/leds-bd2802.c| 8 +- drivers/leds/leds-blinkm.c| 815 ++ drivers/leds/leds-da903x.c| 9 +- drivers/leds/leds-dac124s085.c| 4 +- drivers/leds/leds-gpio.c | 11 +- drivers/leds/leds-lm3530.c| 24 +-
Re: [PATCH] kernel/watchdog.c : fix smp_processor_id() warning
On Fri, Jul 27, 2012 at 3:43 AM, Don Zickus wrote: > On Wed, Jul 25, 2012 at 12:39:45PM +0800, Ming Lei wrote: >> Use raw_smp_processor_id in lockup_detector_bootcpu_resume() >> because it is enough when non-boot CPUs are offline. >> >> This patch fixes the following warning when DEBUG_PREEMPT >> is enabled. > > Is this patched on top of linux-next? Yes. The warning is introduced by the commit below: 7fb860ff90ae970cf62cf676dfc1addcf8415674 (NMI watchdog: fix for lockup detector breakage on resume) > It seems right based on the code usage. Though it makes me sad the resume > code has to hack into the cpu notifiers like that. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure in Linus' tree
On Fri, 27 Jul 2012 10:15:35 +1000 Stephen Rothwell wrote: > > From: Stephen Rothwell > Date: Fri, 27 Jul 2012 10:11:13 +1000 > Subject: [PATCH] Btrfs: using vrmzalloc and friends needs vmalloc.h That should say "vmalloc". of course. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpugIrYwrbdh.pgp Description: PGP signature
linux-next: build failure in Linus' tree
Hi Linus,
After merging the origin tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/btrfs/send.c: In function 'fs_path_free':
fs/btrfs/send.c:185:4: error: implicit declaration of function 'vfree'
[-Werror=implicit-function-declaration]
fs/btrfs/send.c: In function 'fs_path_ensure_buf':
fs/btrfs/send.c:215:4: error: implicit declaration of function 'vmalloc'
[-Werror=implicit-function-declaration]
fs/btrfs/send.c:215:12: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:225:12: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:233:13: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c: In function 'iterate_dir_item':
fs/btrfs/send.c:900:10: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:909:11: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c: In function 'btrfs_ioctl_send':
fs/btrfs/send.c:4463:17: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:4469:17: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:4475:2: error: implicit declaration of function 'vzalloc'
[-Werror=implicit-function-declaration]
fs/btrfs/send.c:4475:20: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:4483:21: warning: assignment makes pointer from integer without
a cast [enabled by default]
Caused by commit 31db9f7c23fb ("Btrfs: introduce BTRFS_IOC_SEND for btrfs
send/receive").
P.S. Chris, can we please get the btrfs tree into linux-next?
I added this patch for today:
From: Stephen Rothwell
Date: Fri, 27 Jul 2012 10:11:13 +1000
Subject: [PATCH] Btrfs: using vrmzalloc and friends needs vmalloc.h
Fixes these build errors:
fs/btrfs/send.c: In function 'fs_path_free':
fs/btrfs/send.c:185:4: error: implicit declaration of function 'vfree'
[-Werror=implicit-function-declaration]
fs/btrfs/send.c: In function 'fs_path_ensure_buf':
fs/btrfs/send.c:215:4: error: implicit declaration of function 'vmalloc'
[-Werror=implicit-function-declaration]
fs/btrfs/send.c:215:12: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:225:12: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:233:13: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c: In function 'iterate_dir_item':
fs/btrfs/send.c:900:10: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:909:11: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c: In function 'btrfs_ioctl_send':
fs/btrfs/send.c:4463:17: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:4469:17: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:4475:2: error: implicit declaration of function 'vzalloc'
[-Werror=implicit-function-declaration]
fs/btrfs/send.c:4475:20: warning: assignment makes pointer from integer without
a cast [enabled by default]
fs/btrfs/send.c:4483:21: warning: assignment makes pointer from integer without
a cast [enabled by default]
Signed-off-by: Stephen Rothwell
---
fs/btrfs/send.c |1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index c8ca49b..fb5ffe9 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "send.h"
#include "backref.h"
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpeQctmRx83a.pgp
Description: PGP signature
Re: [PATCH RT 05/12] slab: Prevent local lock deadlock
On 07/18/12 15:39, Steven Rostedt wrote:
> From: Thomas Gleixner
>
> On RT we avoid the cross cpu function calls and take the per cpu local
> locks instead. Now the code missed that taking the local lock on the
> cpu which runs the code must use the proper local lock functions and
> not a simple spin_lock(). Otherwise it deadlocks later when trying to
> acquire the local lock with the proper function.
>
> Reported-and-tested-by: Chris Pringle
> Signed-off-by: Thomas Gleixner
> Signed-off-by: Steven Rostedt
> ---
> mm/slab.c | 26 ++
> 1 file changed, 22 insertions(+), 4 deletions(-)
This patch leads to a warning during boot on the ARM pandaboard:
[0.225097] Brought up 2 CPUs
[0.225097] SMP: Total of 2 processors activated (2007.19 BogoMIPS).
[0.225952]
[0.225982] =
[0.225982] [ INFO: possible recursive locking detected ]
[0.225982] 3.0.36-rt58 #1
[0.225982] -
[0.225982] swapper/0/1 is trying to acquire lock:
[0.226013] (_cpu(slab_lock, __cpu).lock){+.+...}, at: []
do_ccupdate_local+0x18/0x44
[0.226043]
[0.226043] but task is already holding lock:
[0.226043] (_cpu(slab_lock, __cpu).lock){+.+...}, at: []
lock_slab_on+0x48/0x134
[0.226074]
[0.226074] other info that might help us debug this:
[0.226074] Possible unsafe locking scenario:
[0.226074]
[0.226074]CPU0
[0.226074]
[0.226074] lock(_cpu(slab_lock, __cpu).lock);
[0.226104] lock(_cpu(slab_lock, __cpu).lock);
[0.226104]
[0.226104] *** DEADLOCK ***
[0.226104]
[0.226104] May be due to missing lock nesting notation
[0.226104]
[0.226104] 2 locks held by swapper/0/1:
[0.226135] #0: (cache_chain_mutex){+.+.+.}, at: []
kmem_cache_create+0x74/0x4bc
[0.226135] #1: (_cpu(slab_lock, __cpu).lock){+.+...}, at:
[] lock_slab_on+0x48/0x134
[0.226165]
[0.226165] stack backtrace:
[0.226196] [] (unwind_backtrace+0x0/0xf0) from []
(__lock_acquire+0x1984/0x1ce8)
[0.226196] [] (__lock_acquire+0x1984/0x1ce8) from []
(lock_acquire+0x100/0x120)
[0.226226] [] (lock_acquire+0x100/0x120) from []
(rt_spin_lock+0x4c/0x5c)
[0.226257] [] (rt_spin_lock+0x4c/0x5c) from []
(do_ccupdate_local+0x18/0x44)
[0.226257] [] (do_ccupdate_local+0x18/0x44) from []
(slab_on_each_cpu+0x2c/0x64)
[0.226287] [] (slab_on_each_cpu+0x2c/0x64) from []
(do_tune_cpucache+0xd8/0x3e8)
[0.226287] [] (do_tune_cpucache+0xd8/0x3e8) from []
(enable_cpucache+0x50/0xcc)
[0.226318] [] (enable_cpucache+0x50/0xcc) from []
(kmem_cache_create+0x3d0/0x4bc)
[0.226318] [] (kmem_cache_create+0x3d0/0x4bc) from []
(init_tmpfs+0x3c/0xe8)
[0.226348] [] (init_tmpfs+0x3c/0xe8) from []
(kernel_init+0x80/0x150)
[0.226379] [] (kernel_init+0x80/0x150) from []
(kernel_thread_exit+0x0/0x8)
[0.239776] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for emif_fw
[0.239776] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for
l3_instr
Config is from arch/arm/configs/omap2plus_defconfig
plus:
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_NET_SMSC95XX=y
CONFIG_PREEMPT_RT_FULL=y
-Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tpm: Move tpm_get_random api into the TPM device driver
On 06/07/2012 11:47 AM, Kent Yoder wrote: Move the tpm_get_random api from the trusted keys code into the TPM device driver itself so that other callers can make use of it. Also, change the api slightly so that the number of bytes read is returned in the call, since the TPM command can potentially return fewer bytes than requested. Signed-off-by: Kent Yoder I see a second problem with this patch: you don't seem to handle the case where you get a short return anywhere in your code. Presumably this should either be considered an error condition, or you need to create a private wrapper which can loop and make additional requests. As it is if you get a short return you simply proceed as if you had gotten what you requested, since this was not an error mode supported by the old code. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [vmw_vmci 07/11] Apply VMCI hash table
Must have missed it. Will look into it. - Original Message - > From: "Greg KH" > To: "Andrew Stiegmann (stieg)" > Cc: linux-kernel@vger.kernel.org, virtualizat...@lists.linux-foundation.org, > pv-driv...@vmware.com, > vm-crosst...@vmware.com, csch...@vmware.com > Sent: Thursday, July 26, 2012 4:49:54 PM > Subject: Re: [vmw_vmci 07/11] Apply VMCI hash table > > On Thu, Jul 26, 2012 at 04:39:36PM -0700, Andrew Stiegmann (stieg) > wrote: > > Implements a hash table for VMCI's use. > > What's wrong with the in-kernel hash table(s)? > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [vmw_vmci 01/11] Apply VMCI context code
Removed. Thanks. - Original Message - > From: "Greg KH" > To: "Andrew Stiegmann (stieg)" > Cc: linux-kernel@vger.kernel.org, virtualizat...@lists.linux-foundation.org, > pv-driv...@vmware.com, > vm-crosst...@vmware.com, csch...@vmware.com > Sent: Thursday, July 26, 2012 4:48:50 PM > Subject: Re: [vmw_vmci 01/11] Apply VMCI context code > > On Thu, Jul 26, 2012 at 04:39:30PM -0700, Andrew Stiegmann (stieg) > wrote: > > Context code maintains state for vmci and allows the driver > > to communicate with multiple VMs. > > > > Signed-off-by: Andrew Stiegmann (stieg) > > One tiny nit: > > > diff --git a/drivers/misc/vmw_vmci/vmci_context.c > > b/drivers/misc/vmw_vmci/vmci_context.c > > new file mode 100644 > > index 000..46faf10 > > --- /dev/null > > +++ b/drivers/misc/vmw_vmci/vmci_context.c > > @@ -0,0 +1,1269 @@ > > +/* > > + * VMware VMCI Driver > > + * > > + * Copyright (C) 2012 VMware, Inc. All rights reserved. > > + * > > + * This program is free software; you can redistribute it and/or > > modify it > > + * under the terms of the GNU General Public License as published > > by the > > + * Free Software Foundation version 2 and no later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > but > > + * WITHOUT ANY WARRANTY; without even the implied warranty of > > MERCHANTABILITY > > + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General > > Public License > > + * for more details. > > + * > > + * You should have received a copy of the GNU General Public > > License along > > + * with this program; if not, write to the Free Software > > Foundation, Inc., > > + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > > Are you prepared to track the office movements of the FSF for the > next > 40 years to keep this up to date? If not, please don't include it, > it's > not needed at all. > > 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/
[GIT] Sparc
Nothing much this merge window for sparc. 1) Fix FPU state management in sparc32, from Tkhai Kirill. 2) More sparc32 mm layer code cleanups, largely more side effects of the sun4c support removal in the 3.5 From Sam Ravnborg. 3) Remove unused code in sparc64, from Bjorn Helgaas and Kirill Tkhai. 4) Some declaration and comment tidies in PROM support code, from Geert Uytterhoeven. Please pull, thanks a lot! The following changes since commit d1346a6cbabf6d377d753f1adc16cb0b305830cc: Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux (2012-06-26 11:26:50 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master for you to fetch changes up to 427f23cb3abc21c3784df8ae907c4c3a31d885d1: sparc32, copy_thread: Clear TIF_USEDFPU flag of created task instead of current (2012-07-26 16:49:40 -0700) Bjorn Helgaas (1): sparc/PCI: remove unused pcibios_assign_resource() definition David S. Miller (1): sparc64: Consistently use fsrc2 rather than fmovd in optimized asm. Geert Uytterhoeven (2): sparc: Correct comments about prom_init() return values sparc32: Remove superfluous extern declarations for prom_*() functions Kirill Tkhai (1): sparc64: remove unused function straddles_64bit_va_hole() Sam Ravnborg (18): sparc32: define a few srmmu functions __init sparc32: sort includes in srmmu.c sparc32: fix coding-style in srmmu.c sparc32: use void * in nocache get/free sparc32: beautify srmmu_inherit_prom_mappings() sparc32: drop swapper_pg_dir sparc32: drop unused kmap_atomic_to_page sparc32: fixmap.h cleanup sparc32: drop fixmap.h sparc32,leon: drop leon_init() sparc32: drop sparc_unmapped_base sparc32: drop sparc model check in paging_init sparc32: drop quicklist sparc32: centralize all mmu context handling in srmmu.c sparc32: drop unused BAD_PAGE stuff sparc32: move probe_memory() to srmmu.c sparc32: move kmap_init() to highmem.c sparc32: delete dead code in show_mem() Tkhai Kirill (1): sparc32, copy_thread: Clear TIF_USEDFPU flag of created task instead of current arch/sparc/include/asm/fixmap.h | 110 arch/sparc/include/asm/highmem.h| 3 - arch/sparc/include/asm/leon.h | 1 - arch/sparc/include/asm/mmu_context_32.h | 8 +- arch/sparc/include/asm/page_32.h| 3 +- arch/sparc/include/asm/pgalloc_32.h | 29 ++ arch/sparc/include/asm/pgtable_32.h | 44 +--- arch/sparc/include/asm/vaddrs.h | 22 arch/sparc/kernel/head_32.S | 2 - arch/sparc/kernel/leon_kernel.c | 16 --- arch/sparc/kernel/pcic.c| 5 - arch/sparc/kernel/process_32.c | 4 +- arch/sparc/kernel/setup_32.c| 1 - arch/sparc/kernel/sys_sparc_64.c| 17 --- arch/sparc/lib/NG2memcpy.S | 72 ++--- arch/sparc/lib/U1memcpy.S | 4 +- arch/sparc/lib/copy_page.S | 56 +- arch/sparc/mm/fault_32.c| 18 arch/sparc/mm/highmem.c | 42 arch/sparc/mm/init_32.c | 58 +-- arch/sparc/mm/srmmu.c | 332 --- arch/sparc/prom/init_32.c | 7 +- arch/sparc/prom/init_64.c | 4 +- 23 files changed, 331 insertions(+), 527 deletions(-) delete mode 100644 arch/sparc/include/asm/fixmap.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/
[GIT] Networking
1) Reinstate the no-ref optimization for input route lookups in ipv4 to fix some routing cache removal perf regressions. 2) Make TCP socket pre-demux work on ipv6 side too, from Eric Dumazet. 3) Get RX hash value from correct place in be2net driver, from Sarveshwar Bandi. 4) Validation of FIB cached routes missing critical check, from Eric Dumazet. 5) EEH support in mlx4 driver, from Kleber Sacilotto de Souza. Please pull, thanks a lot! The following changes since commit 3c4cfadef6a1665d9cd02a543782d03d3e6740c6: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2012-07-24 10:01:50 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to c7109986db3c945f50ceed884a30e0fd8af3b89b: ipv6: Early TCP socket demux (2012-07-26 15:50:39 -0700) Alan Cox (2): caif: fix NULL pointer check wanmain: comparing array with NULL Amir Vadai (1): net/mlx4_en: Limit the RFS filter IDs to be < RPS_NO_FILTER Andy Cress (3): pch_gbe: fix transmit watchdog timeout pch_gbe: add extra clean tx pch_gbe: vlan skb len fix Anton Blanchard (1): be2net: Missing byteswap in be_get_fw_log_level causes oops on PowerPC Dan Williams (1): cdc-ncm: tag Ericsson WWAN devices (eg F5521gw) with FLAG_WWAN David S. Miller (1): ipv4: Fix input route performance regression. Emil Tantilov (1): ixgbe: fix panic while dumping packets on Tx hang with IOMMU Eric Dumazet (3): tcp: early_demux fixes ipv4: rt_cache_valid must check expired routes ipv6: Early TCP socket demux Haiyang Zhang (2): hyperv: Add a check for ring_size value hyperv: Add error handling to rndis_filter_device_add() Jiri Pirko (1): team: init error value to 0 in team_netpoll_setup() Kleber Sacilotto de Souza (1): mlx4: Add support for EEH error recovery Sarveshwar Bandi (1): be2net: Fix to parse RSS hash from Receive completions correctly. Wei Yang (1): net/pch_gpe: Cannot disable ethernet autonegation Yuval Mintz (1): bnx2x: Correct EEE statistics gathering frank.blasc...@de.ibm.com (3): net: wiznet add missing HAS_IOMEM dependency netiucv: cleanup attribute usage qeth: repair crash in qeth_l3_vlan_rx_kill_vid() drivers/net/caif/caif_serial.c | 3 ++ drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h | 4 +++ drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 8 +++-- drivers/net/ethernet/emulex/benet/be_ethtool.c | 5 ++-- drivers/net/ethernet/emulex/benet/be_main.c | 6 ++-- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++ drivers/net/ethernet/mellanox/mlx4/catas.c | 25 +++- drivers/net/ethernet/mellanox/mlx4/cmd.c| 49 +-- drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +- drivers/net/ethernet/mellanox/mlx4/main.c | 30 ++- drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c | 1 - drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c| 70 ++-- drivers/net/ethernet/wiznet/Kconfig | 1 + drivers/net/hyperv/netvsc_drv.c | 7 - drivers/net/hyperv/rndis_filter.c | 11 +++ drivers/net/team/team.c | 2 +- drivers/net/usb/cdc_ncm.c | 68 +++--- drivers/s390/net/netiucv.c | 34 - drivers/s390/net/qeth_l3_main.c | 4 +++ include/net/inet6_hashtables.h | 13 include/net/protocol.h | 2 ++ include/net/route.h | 19 ++-- net/ipv4/arp.c | 2 +- net/ipv4/fib_semantics.c| 4 +-- net/ipv4/ip_fragment.c | 4 +-- net/ipv4/ip_input.c | 10 +-- net/ipv4/route.c| 56 +-- net/ipv4/tcp_ipv4.c | 9 ++ net/ipv4/xfrm4_input.c | 4 +-- net/ipv6/ip6_input.c| 13 ++-- net/ipv6/tcp_ipv6.c | 38 net/wanrouter/wanmain.c | 51 +++- 32 files changed, 374 insertions(+), 192 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More
Re: [vmw_vmci 11/11] Apply the header code to make VMCI build
On Thu, Jul 26, 2012 at 04:39:40PM -0700, Andrew Stiegmann (stieg) wrote:
> +#define ASSERT(cond) BUG_ON(!(cond))
Don't do that, you just crashed someone's box and now they have no way
to recover it and tell you that you broke it.
> +#define CAN_BLOCK(_f) (!((_f) & VMCI_QPFLAG_NONBLOCK))
> +#define QP_PINNED(_f) ((_f) & VMCI_QPFLAG_PINNED)
> +
> +#define PCI_VENDOR_ID_VMWARE 0x15AD
What's wrong with the one in pci_ids.h?
> +#define PCI_DEVICE_ID_VMWARE_VMCI0x0740
> +#define VMCI_DRIVER_VERSION_STRING "9.5.5.0-k"
Do you really need this?
> +#define MODULE_NAME "vmw_vmci"
The kernel provides this for you already, don't duplicate it.
> +
> +/* Print magic... whee! */
> +#ifdef pr_fmt
> +#undef pr_fmt
No need for these 2 lines
> +#define pr_fmt(fmt) MODULE_NAME ": " fmt
> +#endif
Or this one.
> +/*
> + * Linux defines _IO* macros, but the core kernel code ignore the encoded
> + * ioctl value. It is up to individual drivers to decode the value (for
> + * example to look at the size of a structure to determine which version
> + * of a specific command should be used) or not (which is what we
> + * currently do, so right now the ioctl value for a given command is the
> + * command itself).
> + *
> + * Hence, we just define the IOCTL_VMCI_foo values directly, with no
> + * intermediate IOCTLCMD_ representation.
> + */
> +# define IOCTLCMD(_cmd) IOCTL_VMCI_ ## _cmd
Are you sure about this comment?
> +
> +enum {
> + /*
> + * We need to bracket the range of values used for ioctls,
> + * because x86_64 Linux forces us to explicitly register ioctl
> + * handlers by value for handling 32 bit ioctl syscalls.
> + * Hence FIRST and LAST. Pick something for FIRST that
> + * doesn't collide with vmmon (2001+).
> + */
> + IOCTLCMD(FIRST) = 1951,
> + IOCTLCMD(VERSION) = IOCTLCMD(FIRST),
> +
> + /* BEGIN VMCI */
> + IOCTLCMD(INIT_CONTEXT),
> +
> + /*
> + * The following two were used for process and datagram
> + * process creation. They are not used anymore and reserved
> + * for future use. They will fail if issued.
> + */
> + IOCTLCMD(RESERVED1),
> + IOCTLCMD(RESERVED2),
> +
> + /*
> + * The following used to be for shared memory. It is now
> + * unused and and is reserved for future use. It will fail if
> + * issued.
> + */
> + IOCTLCMD(RESERVED3),
> +
> + /*
> + * The follwoing three were also used to be for shared
> + * memory. An old WS6 user-mode client might try to use them
> + * with the new driver, but since we ensure that only contexts
> + * created by VMX'en of the appropriate version
> + * (VMCI_VERSION_NOTIFY or VMCI_VERSION_NEWQP) or higher use
> + * these ioctl, everything is fine.
> + */
> + IOCTLCMD(QUEUEPAIR_SETVA),
> + IOCTLCMD(NOTIFY_RESOURCE),
> + IOCTLCMD(NOTIFICATIONS_RECEIVE),
> + IOCTLCMD(VERSION2),
> + IOCTLCMD(QUEUEPAIR_ALLOC),
> + IOCTLCMD(QUEUEPAIR_SETPAGEFILE),
> + IOCTLCMD(QUEUEPAIR_DETACH),
> + IOCTLCMD(DATAGRAM_SEND),
> + IOCTLCMD(DATAGRAM_RECEIVE),
> + IOCTLCMD(DATAGRAM_REQUEST_MAP),
> + IOCTLCMD(DATAGRAM_REMOVE_MAP),
> + IOCTLCMD(CTX_ADD_NOTIFICATION),
> + IOCTLCMD(CTX_REMOVE_NOTIFICATION),
> + IOCTLCMD(CTX_GET_CPT_STATE),
> + IOCTLCMD(CTX_SET_CPT_STATE),
> + IOCTLCMD(GET_CONTEXT_ID),
> + IOCTLCMD(LAST),
> + /* END VMCI */
> +
> + /*
> + * VMCI Socket IOCTLS are defined next and go from
> + * IOCTLCMD(LAST) (1972) to 1990. VMware reserves a range of
> + * 4 ioctls for VMCI Sockets to grow. We cannot reserve many
> + * ioctls here since we are close to overlapping with vmmon
> + * ioctls (2001+). Define a meta-ioctl if running out of this
> + * binary space.
> + */
> + IOCTLCMD(SOCKETS_LAST) = 1994, /* 1994 on Linux. */
> +
> + /*
> + * The VSockets ioctls occupy the block above. We define a
> + * new range of VMCI ioctls to maintain binary compatibility
> + * between the user land and the kernel driver. Careful,
> + * vmmon ioctls start from 2001, so this means we can add only
> + * 4 new VMCI ioctls. Define a meta-ioctl if running out of
> + * this binary space.
> + */
> + IOCTLCMD(FIRST2),
> + IOCTLCMD(SET_NOTIFY) = IOCTLCMD(FIRST2),/* 1995 on Linux. */
> + IOCTLCMD(LAST2),
> +};
That's a lot of ioctls. Why not just create a new system call, or many
system calls, instead?
> +/*
> + * This struct is used to contain data for events. Size of this struct is a
> + * multiple of 8 bytes, and all fields are aligned to their natural
> alignment.
> + */
> +struct vmci_event_data {
> + uint32_t event; /* 4 bytes. */
> + uint32_t _pad;
> + /* Event payload is put here. */
> +};
Why not put an empty array so you can get to the data easier instead of
having to do looney inline functions like this:
> +/*
> + * We use the
[vmw_vmci 11/11] Apply the header code to make VMCI build
Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: Andrew Stiegmann (stieg) --- drivers/misc/Kconfig|1 + drivers/misc/Makefile |1 + drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile | 43 ++ drivers/misc/vmw_vmci/vmci_common_int.h | 58 ++ include/linux/vmw_vmci_api.h| 89 +++ include/linux/vmw_vmci_defs.h | 921 +++ 7 files changed, 1129 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source "drivers/misc/lis3lv02d/Kconfig" source "drivers/misc/carma/Kconfig" source "drivers/misc/altera-stapl/Kconfig" source "drivers/misc/mei/Kconfig" +source "drivers/misc/vmw_vmci/Kconfig" endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..af9e413 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,4 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-y += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate "VMware VMCI Driver" + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..19755fb --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,43 @@ + +# +# Linux driver for VMware's VMCI device. +# +# Copyright (C) 2007-2012, VMware, Inc. All Rights Reserved. +# +# This program is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by the +# Free Software Foundation; version 2 of the License and no 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, GOOD TITLE or +# NON INFRINGEMENT. See the GNU General Public License for more +# details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# The full GNU General Public License is included in this distribution in +# the file called "COPYING". +# +# Maintained by: Andrew Stiegmann +# + + +# +# Makefile for the VMware VMCI +# + +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o + +vmw_vmci-objs += vmci_context.o +vmw_vmci-objs += vmci_datagram.o +vmw_vmci-objs += vmci_doorbell.o +vmw_vmci-objs += vmci_driver.o +vmw_vmci-objs += vmci_event.o +vmw_vmci-objs += vmci_handle_array.o +vmw_vmci-objs += vmci_hash_table.o +vmw_vmci-objs += vmci_queue_pair.o +vmw_vmci-objs += vmci_resource.o +vmw_vmci-objs += vmci_route.o diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..6e82610 --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,58 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 2012 VMware, Inc. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation version 2 and no later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the
Re: [vmw_vmci 07/11] Apply VMCI hash table
On Thu, Jul 26, 2012 at 04:39:36PM -0700, Andrew Stiegmann (stieg) wrote: > Implements a hash table for VMCI's use. What's wrong with the in-kernel hash table(s)? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[vmw_vmci 10/11] Apply vmci routing code
This code is responsible for routing between various hosts/guests as
well as routing in nested scenarios.
Signed-off-by: Andrew Stiegmann (stieg)
---
drivers/misc/vmw_vmci/vmci_route.c | 241
drivers/misc/vmw_vmci/vmci_route.h | 34 +
2 files changed, 275 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_route.c
create mode 100644 drivers/misc/vmw_vmci/vmci_route.h
diff --git a/drivers/misc/vmw_vmci/vmci_route.c
b/drivers/misc/vmw_vmci/vmci_route.c
new file mode 100644
index 000..b9c301d
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_route.c
@@ -0,0 +1,241 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include "vmci_common_int.h"
+#include "vmci_context.h"
+#include "vmci_driver.h"
+#include "vmci_route.h"
+
+/*
+ * Make a routing decision for the given source and destination handles.
+ * This will try to determine the route using the handles and the available
+ * devices. Will set the source context if it is invalid.
+ */
+int vmci_route(struct vmci_handle *src,
+ const struct vmci_handle *dst,
+ bool fromGuest,
+ enum vmci_route *route)
+{
+ bool hasHostDevice = vmci_host_code_active();
+ bool hasGuestDevice = vmci_guest_code_active();
+
+ ASSERT(src);
+ ASSERT(dst);
+ ASSERT(route);
+
+ *route = VMCI_ROUTE_NONE;
+
+ /*
+* "fromGuest" is only ever set to true by
+* IOCTL_VMCI_DATAGRAM_SEND (or by the vmkernel equivalent),
+* which comes from the VMX, so we know it is coming from a
+* guest.
+*
+* To avoid inconsistencies, test these once. We will test
+* them again when we do the actual send to ensure that we do
+* not touch a non-existent device.
+*/
+
+ /* Must have a valid destination context. */
+ if (VMCI_INVALID_ID == dst->context)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ /* Anywhere to hypervisor. */
+ if (VMCI_HYPERVISOR_CONTEXT_ID == dst->context) {
+
+ /*
+* If this message already came from a guest then we
+* cannot send it to the hypervisor. It must come
+* from a local client.
+*/
+ if (fromGuest)
+ return VMCI_ERROR_DST_UNREACHABLE;
+
+ /*
+* We must be acting as a guest in order to send to
+* the hypervisor.
+*/
+ if (!hasGuestDevice)
+ return VMCI_ERROR_DEVICE_NOT_FOUND;
+
+ /* And we cannot send if the source is the host context. */
+ if (VMCI_HOST_CONTEXT_ID == src->context)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ /*
+* If the client passed the ANON source handle then
+* respect it (both context and resource are invalid).
+* However, if they passed only an invalid context,
+* then they probably mean ANY, in which case we
+* should set the real context here before passing it
+* down.
+*/
+ if (VMCI_INVALID_ID == src->context &&
+ VMCI_INVALID_ID != src->resource)
+ src->context = VMCI_GetContextID();
+
+ /* Send from local client down to the hypervisor. */
+ *route = VMCI_ROUTE_AS_GUEST;
+ return VMCI_SUCCESS;
+ }
+
+ /* Anywhere to local client on host. */
+ if (VMCI_HOST_CONTEXT_ID == dst->context) {
+ /*
+* If it is not from a guest but we are acting as a
+* guest, then we need to send it down to the host.
+* Note that if we are also acting as a host then this
+* will prevent us from sending from local client to
+* local client, but we accept that restriction as a
+* way to remove any ambiguity from the host context.
+*/
+ if (src->context == VMCI_HYPERVISOR_CONTEXT_ID) {
+ /*
+* If the hypervisor
[vmw_vmci 06/11] Apply dynamic array code
This code adds support for dynamic arrays that will grow if they
need to.
Signed-off-by: Andrew Stiegmann (stieg)
---
drivers/misc/vmw_vmci/vmci_handle_array.c | 174 +
drivers/misc/vmw_vmci/vmci_handle_array.h | 50
2 files changed, 224 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_handle_array.c
create mode 100644 drivers/misc/vmw_vmci/vmci_handle_array.h
diff --git a/drivers/misc/vmw_vmci/vmci_handle_array.c
b/drivers/misc/vmw_vmci/vmci_handle_array.c
new file mode 100644
index 000..e23e82b
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_handle_array.c
@@ -0,0 +1,174 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "vmci_common_int.h"
+#include "vmci_handle_array.h"
+
+static unsigned handle_arr_calc_size(uint32_t c)
+{
+ /*
+* Decrement c because vmci_handle_arr already includes
+* one vmci_handle entry.
+*/
+ return sizeof(struct vmci_handle_arr) +
+ --c * sizeof(struct vmci_handle);
+}
+
+struct vmci_handle_arr *vmci_handle_arr_create(uint32_t capacity)
+{
+ struct vmci_handle_arr *array;
+ uint32_t arr_size;
+
+ if (capacity == 0)
+ capacity = VMCI_HANDLE_ARRAY_DEFAULT_SIZE;
+
+ arr_size = handle_arr_calc_size(capacity);
+ array = kmalloc(arr_size, GFP_ATOMIC);
+ if (!array)
+ return NULL;
+
+ array->capacity = capacity;
+ array->size = 0;
+
+ return array;
+}
+
+void vmci_handle_arr_destroy(struct vmci_handle_arr *array)
+{
+ kfree(array);
+}
+
+void vmci_handle_arr_append_entry(struct vmci_handle_arr **arrayPtr,
+ struct vmci_handle handle)
+{
+ struct vmci_handle_arr *array;
+
+ ASSERT(arrayPtr && *arrayPtr);
+ array = *arrayPtr;
+
+ if (unlikely(array->size >= array->capacity)) {
+ /* reallocate. */
+ struct vmci_handle_arr *newArray;
+ const uint32_t arraySize =
+ handle_arr_calc_size(array->capacity *
+VMCI_ARR_CAP_MULT);
+
+ newArray = kmalloc(arraySize, GFP_ATOMIC);
+ if (!newArray)
+ return;
+
+ memcpy(newArray, array, arraySize);
+ newArray->capacity *= VMCI_ARR_CAP_MULT;
+ kfree(array);
+ *arrayPtr = newArray;
+ array = newArray;
+ }
+
+ array->entries[array->size] = handle;
+ array->size++;
+}
+
+/*
+ * Handle that was removed, VMCI_INVALID_HANDLE if entry not found.
+ */
+struct vmci_handle vmci_handle_arr_remove_entry(struct vmci_handle_arr *array,
+ struct vmci_handle entryHandle)
+{
+ uint32_t i;
+ struct vmci_handle handle = VMCI_INVALID_HANDLE;
+
+ ASSERT(array);
+ for (i = 0; i < array->size; i++) {
+ if (VMCI_HANDLE_EQUAL(array->entries[i], entryHandle)) {
+ handle = array->entries[i];
+ array->size--;
+ array->entries[i] = array->entries[array->size];
+ array->entries[array->size] = VMCI_INVALID_HANDLE;
+ break;
+ }
+ }
+
+ return handle;
+}
+
+/*
+ * Handle that was removed, VMCI_INVALID_HANDLE if array was empty.
+ */
+struct vmci_handle vmci_handle_arr_remove_tail(struct vmci_handle_arr *array)
+{
+ struct vmci_handle handle = VMCI_INVALID_HANDLE;
+
+ if (array->size) {
+ array->size--;
+ handle = array->entries[array->size];
+ array->entries[array->size] = VMCI_INVALID_HANDLE;
+ }
+
+ return handle;
+}
+
+/*
+ * Handle at given index, VMCI_INVALID_HANDLE if invalid index.
+ */
+struct vmci_handle
+vmci_handle_arr_get_entry(const struct vmci_handle_arr *array,
+ uint32_t index)
+{
+ ASSERT(array);
+
+ if (unlikely(index >= array->size))
+ return VMCI_INVALID_HANDLE;
+
+ return array->entries[index];
+}
+
+uint32_t vmci_handle_arr_get_size(const struct vmci_handle_arr *array)
+{
+
[vmw_vmci 01/11] Apply VMCI context code
Context code maintains state for vmci and allows the driver
to communicate with multiple VMs.
Signed-off-by: Andrew Stiegmann (stieg)
---
drivers/misc/vmw_vmci/vmci_context.c | 1269 ++
drivers/misc/vmw_vmci/vmci_context.h | 161 +
2 files changed, 1430 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_context.c
create mode 100644 drivers/misc/vmw_vmci/vmci_context.h
diff --git a/drivers/misc/vmw_vmci/vmci_context.c
b/drivers/misc/vmw_vmci/vmci_context.c
new file mode 100644
index 000..46faf10
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_context.c
@@ -0,0 +1,1269 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vmci_common_int.h"
+#include "vmci_context.h"
+#include "vmci_datagram.h"
+#include "vmci_doorbell.h"
+#include "vmci_driver.h"
+#include "vmci_event.h"
+#include "vmci_queue_pair.h"
+
+/*
+ * List of current VMCI contexts.
+ */
+static struct {
+ struct list_head head;
+ spinlock_t lock;
+ spinlock_t firingLock;
+} ctx_list;
+
+
+static void ctx_signal_notify(struct vmci_ctx *context)
+{
+ if (context->notify)
+ *context->notify = true;
+}
+
+static void ctx_clear_notify(struct vmci_ctx *context)
+{
+ if (context->notify)
+ *context->notify = false;
+}
+
+/*
+ * If nothing requires the attention of the guest, clears both
+ * notify flag and call.
+ */
+static void ctx_clear_notify_call(struct vmci_ctx *context)
+{
+ if (context->pendingDatagrams == 0 &&
+ vmci_handle_arr_get_size(context->pendingDoorbellArray) == 0)
+ ctx_clear_notify(context);
+}
+
+/*
+ * Check if a context with the specified context ID exists.
+ * Assumes the ctx_list.lock is held.
+ */
+static bool ctx_exists_locked(uint32_t cid)
+{
+ struct vmci_ctx *context;
+
+ list_for_each_entry(context, _list.head, listItem) {
+ if (context->cid == cid)
+ return true;
+ }
+
+ return false;
+}
+
+/*
+ * Sets the context's notify flag iff datagrams are pending for this
+ * context. Called from vmci_setup_notify().
+ */
+void vmci_ctx_check_signal_notify(struct vmci_ctx *context)
+{
+ ASSERT(context);
+
+ spin_lock(_list.lock);
+ if (context->pendingDatagrams)
+ ctx_signal_notify(context);
+ spin_unlock(_list.lock);
+}
+
+int __init vmci_ctx_init(void)
+{
+ INIT_LIST_HEAD(_list.head);
+
+ spin_lock_init(_list.lock);
+ spin_lock_init(_list.firingLock);
+
+ return VMCI_SUCCESS;
+}
+
+/*
+ * Allocates and initializes a VMCI context.
+ */
+int vmci_ctx_init_ctx(uint32_t cid,
+ uint32_t privFlags,
+ uintptr_t eventHnd,
+ int userVersion,
+ uid_t *user, struct vmci_ctx **outContext)
+{
+ struct vmci_ctx *context;
+ int result;
+
+ if (privFlags & ~VMCI_PRIVILEGE_ALL_FLAGS) {
+ pr_devel("Invalid flag (flags=0x%x) for VMCI context.",
+privFlags);
+ return VMCI_ERROR_INVALID_ARGS;
+ }
+
+ if (userVersion == 0)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ context = kzalloc(sizeof *context, GFP_KERNEL);
+ if (context == NULL) {
+ pr_warn("Failed to allocate memory for VMCI context.");
+ return VMCI_ERROR_NO_MEM;
+ }
+
+ INIT_LIST_HEAD(>listItem);
+ INIT_LIST_HEAD(>datagramQueue);
+
+ context->userVersion = userVersion;
+
+ context->queuePairArray = vmci_handle_arr_create(0);
+ if (!context->queuePairArray) {
+ result = VMCI_ERROR_NO_MEM;
+ goto error;
+ }
+
+ context->doorbellArray = vmci_handle_arr_create(0);
+ if (!context->doorbellArray) {
+ result = VMCI_ERROR_NO_MEM;
+ goto error;
+ }
+
+ context->pendingDoorbellArray = vmci_handle_arr_create(0);
+ if (!context->pendingDoorbellArray) {
+ result = VMCI_ERROR_NO_MEM;
+ goto error;
+ }
+
+ context->notifierArray = vmci_handle_arr_create(0);
+ if
[vmw_vmci 09/11] Apply VMCI resource code
Tracks all used resources within the vmci code.
Signed-off-by: Andrew Stiegmann (stieg)
---
drivers/misc/vmw_vmci/vmci_resource.c | 194 +
drivers/misc/vmw_vmci/vmci_resource.h | 62 +++
2 files changed, 256 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_resource.c
create mode 100644 drivers/misc/vmw_vmci/vmci_resource.h
diff --git a/drivers/misc/vmw_vmci/vmci_resource.c
b/drivers/misc/vmw_vmci/vmci_resource.c
new file mode 100644
index 000..03d1f44
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_resource.c
@@ -0,0 +1,194 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "vmci_common_int.h"
+#include "vmci_hash_table.h"
+#include "vmci_resource.h"
+#include "vmci_driver.h"
+
+/* 0 through VMCI_RESERVED_RESOURCE_ID_MAX are reserved. */
+static uint32_t resourceID = VMCI_RESERVED_RESOURCE_ID_MAX + 1;
+static spinlock_t resourceIdLock;
+static struct vmci_hash_table *resourceTable;
+
+/*
+ * Initializes the VMCI Resource Access Control API. Creates a hashtable
+ * to hold all resources, and registers vectors and callbacks for
+ * hypercalls.
+ */
+int __init vmci_resource_init(void)
+{
+ spin_lock_init();
+
+ resourceTable = vmci_hash_create(128);
+ if (resourceTable == NULL) {
+ pr_warn("Failed creating a resource hash table.");
+ return VMCI_ERROR_NO_MEM;
+ }
+
+ return VMCI_SUCCESS;
+}
+
+void vmci_resource_exit(void)
+{
+ if (resourceTable)
+ vmci_hash_destroy(resourceTable);
+}
+
+/*
+ * Return resource ID. The first VMCI_RESERVED_RESOURCE_ID_MAX are
+ * reserved so we start from its value + 1. Returns
+ * VMCI resource id on success, VMCI_INVALID_ID on failure.
+ */
+uint32_t vmci_resource_get_id(uint32_t contextID)
+{
+ uint32_t oldRID = resourceID;
+ uint32_t currentRID;
+ bool foundRID = false;
+
+ /*
+* Generate a unique resource ID. Keep on trying until we wrap around
+* in the RID space.
+*/
+ ASSERT(oldRID > VMCI_RESERVED_RESOURCE_ID_MAX);
+
+ do {
+ struct vmci_handle handle;
+
+ spin_lock();
+ currentRID = resourceID;
+ handle = vmci_make_handle(contextID, currentRID);
+ resourceID++;
+ if (unlikely(resourceID == VMCI_INVALID_ID)) {
+ /* Skip the reserved rids. */
+
+ resourceID = VMCI_RESERVED_RESOURCE_ID_MAX + 1;
+ }
+ spin_unlock();
+ foundRID = !vmci_hash_exists(resourceTable, handle);
+ } while (!foundRID && resourceID != oldRID);
+
+ return (unlikely(!foundRID)) ? VMCI_INVALID_ID : currentRID;
+}
+
+int vmci_resource_add(struct vmci_resource *resource,
+ enum vmci_resource_type resourceType,
+ struct vmci_handle resourceHandle,
+ VMCIResourceFreeCB containerFreeCB,
+ void *containerObject)
+{
+ int result;
+
+ ASSERT(resource);
+
+ if (VMCI_HANDLE_EQUAL(resourceHandle, VMCI_INVALID_HANDLE)) {
+ pr_devel("Invalid argument resource (handle=0x%x:0x%x)",
+resourceHandle.context, resourceHandle.resource);
+ return VMCI_ERROR_INVALID_ARGS;
+ }
+
+ vmci_hash_init_entry(>hashEntry, resourceHandle);
+ resource->type = resourceType;
+ resource->containerFreeCB = containerFreeCB;
+ resource->containerObject = containerObject;
+
+ /* Add resource to hashtable. */
+ result = vmci_hash_add(resourceTable, >hashEntry);
+ if (result != VMCI_SUCCESS) {
+ pr_devel("Failed to add entry to hash table " \
+"(result=%d).", result);
+ return result;
+ }
+
+ return result;
+}
+
+void vmci_resource_remove(struct vmci_handle resourceHandle,
+ enum vmci_resource_type resourceType)
+{
+ struct vmci_resource *resource =
+ vmci_resource_get(resourceHandle, resourceType);
+
+ if (resource == NULL)
+ return;
+
+ /* Remove resource from hashtable. */
+
[vmw_vmci 02/11] Apply VMCI datagram code
Implements datagrams to allow data to be sent between host
and guest.
Signed-off-by: Andrew Stiegmann (stieg)
---
drivers/misc/vmw_vmci/vmci_datagram.c | 586 +
drivers/misc/vmw_vmci/vmci_datagram.h | 56
2 files changed, 642 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_datagram.c
create mode 100644 drivers/misc/vmw_vmci/vmci_datagram.h
diff --git a/drivers/misc/vmw_vmci/vmci_datagram.c
b/drivers/misc/vmw_vmci/vmci_datagram.c
new file mode 100644
index 000..a804f99
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_datagram.c
@@ -0,0 +1,586 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "vmci_common_int.h"
+#include "vmci_context.h"
+#include "vmci_datagram.h"
+#include "vmci_driver.h"
+#include "vmci_event.h"
+#include "vmci_hash_table.h"
+#include "vmci_resource.h"
+#include "vmci_route.h"
+
+/*
+ * struct datagram_entry describes the datagram entity. It is used for datagram
+ * entities created only on the host.
+ */
+struct datagram_entry {
+ struct vmci_resource resource;
+ uint32_t flags;
+ bool runDelayed;
+ VMCIDatagramRecvCB recvCB;
+ void *clientData;
+ wait_queue_head_t destroyEvent;
+ uint32_t privFlags;
+};
+
+struct delayed_datagram_info {
+ bool inDGHostQueue;
+ struct datagram_entry *entry;
+ struct vmci_dg msg;
+};
+
+static atomic_t delayedDGHostQueueSize;
+
+static void dg_free_cb(void *clientData)
+{
+ struct datagram_entry *entry = (struct datagram_entry *)clientData;
+ ASSERT(entry);
+
+ /*
+* Entry is freed in VMCIDatagram_DestroyHnd, who waits for
+* the signal.
+*/
+ wake_up(>destroyEvent);
+}
+
+static int dg_release_cb(void *clientData)
+{
+ struct datagram_entry *entry = (struct datagram_entry *)clientData;
+ ASSERT(entry);
+ vmci_resource_release(>resource);
+ return 0;
+}
+
+/*
+ * Create a datagram entry given a handle pointer.
+ */
+static int dg_create_handle(uint32_t resourceID,
+ uint32_t flags,
+ uint32_t privFlags,
+ VMCIDatagramRecvCB recvCB,
+ void *clientData,
+ struct vmci_handle *outHandle)
+{
+ int result;
+ uint32_t contextID;
+ struct vmci_handle handle;
+ struct datagram_entry *entry;
+
+ ASSERT(recvCB != NULL);
+ ASSERT(outHandle != NULL);
+ ASSERT(!(privFlags & ~VMCI_PRIVILEGE_ALL_FLAGS));
+
+ if ((flags & VMCI_FLAG_WELLKNOWN_DG_HND) != 0) {
+ return VMCI_ERROR_INVALID_ARGS;
+ } else {
+ if ((flags & VMCI_FLAG_ANYCID_DG_HND) != 0) {
+ contextID = VMCI_INVALID_ID;
+ } else {
+ contextID = VMCI_GetContextID();
+ if (contextID == VMCI_INVALID_ID)
+ return VMCI_ERROR_NO_RESOURCES;
+ }
+
+ if (resourceID == VMCI_INVALID_ID) {
+ resourceID = vmci_resource_get_id(contextID);
+ if (resourceID == VMCI_INVALID_ID)
+ return VMCI_ERROR_NO_HANDLE;
+ }
+
+ handle = vmci_make_handle(contextID, resourceID);
+ }
+
+ entry = kmalloc(sizeof *entry, GFP_KERNEL);
+ if (entry == NULL) {
+ pr_warn("Failed allocating memory for datagram entry.");
+ return VMCI_ERROR_NO_MEM;
+ }
+
+ entry->runDelayed = (flags & VMCI_FLAG_DG_DELAYED_CB) ? true : false;
+ entry->flags = flags;
+ entry->recvCB = recvCB;
+ entry->clientData = clientData;
+ init_waitqueue_head(>destroyEvent);
+ entry->privFlags = privFlags;
+
+ /* Make datagram resource live. */
+ result = vmci_resource_add(>resource,
+ VMCI_RESOURCE_TYPE_DATAGRAM,
+ handle, dg_free_cb, entry);
+ if (result != VMCI_SUCCESS) {
+ pr_warn("Failed to add new resource (handle=0x%x:0x%x).",
+
[PATCH] staging/olpc_dcon: fix checkpatch warnings
Now checkpatch clean.
$ find drivers/staging/olpc_dcon/ -name "*.[ch]"|xargs ./scripts/checkpatch.pl \
-f --terse --nosummary|cut -f3- -d":"|sort |uniq -c|sort -n
2 WARNING: msleep < 20ms can sleep for up to 20ms; see
Documentation/timers/timers-howto.txt
3 WARNING: Prefer pr_debug(... to printk(KERN_DEBUG, ...
3 WARNING: Prefer pr_warn(... to printk(KERN_WARNING, ...
6 WARNING: Prefer pr_info(... to printk(KERN_INFO, ...
19 WARNING: Prefer pr_err(... to printk(KERN_ERR, ...
And added pr_fmt.
Signed-off-by: Toshiaki Yamane
---
drivers/staging/olpc_dcon/olpc_dcon.c| 56 +-
drivers/staging/olpc_dcon/olpc_dcon_xo_1.c | 15 ---
drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c |6 ++-
3 files changed, 41 insertions(+), 36 deletions(-)
diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
b/drivers/staging/olpc_dcon/olpc_dcon.c
index 992275c..4e6efc1 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -11,6 +11,7 @@
* License as published by the Free Software Foundation.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
#include
@@ -71,18 +72,18 @@ static int dcon_hw_init(struct dcon_priv *dcon, int is_init)
ver = dcon_read(dcon, DCON_REG_ID);
if ((ver >> 8) != 0xDC) {
- printk(KERN_ERR "olpc-dcon: DCON ID not 0xDCxx: 0x%04x
instead.\n",
- ver);
+ pr_err("olpc-dcon: DCON ID not 0xDCxx: 0x%04x instead.\n",
+ ver);
rc = -ENXIO;
goto err;
}
if (is_init) {
- printk(KERN_INFO "olpc-dcon: Discovered DCON version %x\n",
- ver & 0xFF);
+ pr_info("olpc-dcon: Discovered DCON version %x\n",
+ ver & 0xFF);
rc = pdata->init(dcon);
if (rc != 0) {
- printk(KERN_ERR "olpc-dcon: Unable to init.\n");
+ pr_err("olpc-dcon: Unable to init.\n");
goto err;
}
}
@@ -136,21 +137,21 @@ power_up:
x = 1;
x = olpc_ec_cmd(0x26, (unsigned char *), 1, NULL, 0);
if (x) {
- printk(KERN_WARNING "olpc-dcon: unable to force dcon
to power up: %d!\n",
+ pr_warn("olpc-dcon: unable to force dcon to power up:
%d!\n",
x);
return x;
}
- msleep(10); /* we'll be conservative */
+ usleep_range(1, 2);
}
pdata->bus_stabilize_wiggle();
for (x = -1, timeout = 50; timeout && x < 0; timeout--) {
- msleep(1);
+ usleep_range(1000, 2000);
x = dcon_read(dcon, DCON_REG_ID);
}
if (x < 0) {
- printk(KERN_ERR "olpc-dcon: unable to stabilize dcon's smbus,
reasserting power and praying.\n");
+ pr_err("olpc-dcon: unable to stabilize dcon's smbus,
reasserting power and praying.\n");
BUG_ON(olpc_board_at_least(olpc_board(0xc2)));
x = 0;
olpc_ec_cmd(0x26, (unsigned char *), 1, NULL, 0);
@@ -221,7 +222,7 @@ static void dcon_sleep(struct dcon_priv *dcon, bool sleep)
x = 0;
x = olpc_ec_cmd(0x26, (unsigned char *), 1, NULL, 0);
if (x)
- printk(KERN_WARNING "olpc-dcon: unable to force dcon
to power down: %d!\n",
+ pr_warn("olpc-dcon: unable to force dcon to power
down: %d!\n",
x);
else
dcon->asleep = sleep;
@@ -231,7 +232,7 @@ static void dcon_sleep(struct dcon_priv *dcon, bool sleep)
dcon->disp_mode |= MODE_BL_ENABLE;
x = dcon_bus_stabilize(dcon, 1);
if (x)
- printk(KERN_WARNING "olpc-dcon: unable to reinit dcon
hardware: %d!\n",
+ pr_warn("olpc-dcon: unable to reinit dcon hardware:
%d!\n",
x);
else
dcon->asleep = sleep;
@@ -303,12 +304,11 @@ static void dcon_source_switch(struct work_struct *work)
switch (source) {
case DCON_SOURCE_CPU:
- printk(KERN_INFO "dcon_source_switch to CPU\n");
+ pr_info("dcon_source_switch to CPU\n");
/* Enable the scanline interrupt bit */
if (dcon_write(dcon, DCON_REG_MODE,
dcon->disp_mode | MODE_SCAN_INT))
- printk(KERN_ERR
- "olpc-dcon: couldn't enable scanline
interrupt!\n");
+ pr_err("olpc-dcon: couldn't enable scanline
interrupt!\n");
else {
[vmw_vmci 07/11] Apply VMCI hash table
Implements a hash table for VMCI's use.
Signed-off-by: Andrew Stiegmann (stieg)
---
drivers/misc/vmw_vmci/vmci_hash_table.c | 332 +++
drivers/misc/vmw_vmci/vmci_hash_table.h | 56 +
2 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_hash_table.c
create mode 100644 drivers/misc/vmw_vmci/vmci_hash_table.h
diff --git a/drivers/misc/vmw_vmci/vmci_hash_table.c
b/drivers/misc/vmw_vmci/vmci_hash_table.c
new file mode 100644
index 000..a7423df
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_hash_table.c
@@ -0,0 +1,332 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "vmci_context.h"
+#include "vmci_common_int.h"
+#include "vmci_driver.h"
+#include "vmci_hash_table.h"
+
+#define VMCI_HANDLE_TO_CONTEXT_ID(_handle) ((_handle).context)
+#define VMCI_HANDLE_TO_RESOURCE_ID(_handle) ((_handle).resource)
+#define VMCI_HASHTABLE_HASH(_h, _sz) \
+ vmci_hash_calc(VMCI_HANDLE_TO_RESOURCE_ID(_h), (_sz))
+
+struct vmci_hash_table *vmci_hash_create(int size)
+{
+ struct vmci_hash_table *table;
+
+ table = kmalloc(sizeof *table, GFP_KERNEL);
+ if (table == NULL)
+ return NULL;
+
+ table->entries = kcalloc(size, sizeof *table->entries, GFP_KERNEL);
+ if (table->entries == NULL) {
+ kfree(table);
+ return NULL;
+ }
+
+ table->size = size;
+ spin_lock_init(>lock);
+
+ return table;
+}
+
+/*
+ * This function should be called at module exit time.
+ * We rely on the module ref count to insure that no one is accessing any
+ * hash table entries at this point in time. Hence we should be able to just
+ * remove all entries from the hash table.
+ */
+void vmci_hash_destroy(struct vmci_hash_table *table)
+{
+ ASSERT(table);
+
+ spin_lock_bh(>lock);
+ kfree(table->entries);
+ table->entries = NULL;
+ spin_unlock_bh(>lock);
+ kfree(table);
+}
+
+void vmci_hash_init_entry(struct vmci_hash_entry *entry,
+ struct vmci_handle handle)
+{
+ ASSERT(entry);
+ entry->handle = handle;
+ entry->refCount = 0;
+}
+
+/*
+ * Unlocked version of vmci_hash_exists.
+ * True if handle already in hashtable. false otherwise.
+ */
+static bool hash_exists_locked(struct vmci_hash_table *table,
+ struct vmci_handle handle)
+{
+ struct vmci_hash_entry *entry;
+ int idx;
+
+ ASSERT(table);
+
+ idx = VMCI_HASHTABLE_HASH(handle, table->size);
+
+ for (entry = table->entries[idx]; entry; entry = entry->next) {
+ if (VMCI_HANDLE_TO_RESOURCE_ID(entry->handle) ==
+ VMCI_HANDLE_TO_RESOURCE_ID(handle) &&
+ ((VMCI_HANDLE_TO_CONTEXT_ID(entry->handle) ==
+ VMCI_HANDLE_TO_CONTEXT_ID(handle)) ||
+(VMCI_INVALID_ID == VMCI_HANDLE_TO_CONTEXT_ID(handle))
+|| (VMCI_INVALID_ID ==
+VMCI_HANDLE_TO_CONTEXT_ID(entry->handle {
+ return true;
+ }
+ }
+
+ return false;
+}
+
+/*
+ * Assumes caller holds table lock.
+ */
+static int hash_unlink(struct vmci_hash_table *table,
+ struct vmci_hash_entry *entry)
+{
+ int result;
+ struct vmci_hash_entry *prev, *cur;
+ const int idx = VMCI_HASHTABLE_HASH(entry->handle, table->size);
+
+ prev = NULL;
+ cur = table->entries[idx];
+ while (true) {
+ if (cur == NULL) {
+ result = VMCI_ERROR_NOT_FOUND;
+ break;
+ }
+ if (VMCI_HANDLE_EQUAL(cur->handle, entry->handle)) {
+ ASSERT(cur == entry);
+
+ /* Remove entry and break. */
+ if (prev)
+ prev->next = cur->next;
+ else
+ table->entries[idx] = cur->next;
+
+ cur->next = NULL;
+ result = VMCI_SUCCESS;
+ break;
+ }
+ prev = cur;
+ cur =
Re: [vmw_vmci 01/11] Apply VMCI context code
On Thu, Jul 26, 2012 at 04:39:30PM -0700, Andrew Stiegmann (stieg) wrote: > Context code maintains state for vmci and allows the driver > to communicate with multiple VMs. > > Signed-off-by: Andrew Stiegmann (stieg) One tiny nit: > diff --git a/drivers/misc/vmw_vmci/vmci_context.c > b/drivers/misc/vmw_vmci/vmci_context.c > new file mode 100644 > index 000..46faf10 > --- /dev/null > +++ b/drivers/misc/vmw_vmci/vmci_context.c > @@ -0,0 +1,1269 @@ > +/* > + * VMware VMCI Driver > + * > + * Copyright (C) 2012 VMware, Inc. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the > + * Free Software Foundation version 2 and no later version. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY > + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * for more details. > + * > + * You should have received a copy of the GNU General Public License along > + * with this program; if not, write to the Free Software Foundation, Inc., > + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Are you prepared to track the office movements of the FSF for the next 40 years to keep this up to date? If not, please don't include it, it's not needed at all. 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/
[vmw_vmci 03/11] Apply VMCI doorbell code
Doorbell code allows for notifcations between host and guest.
Signed-off-by: Andrew Stiegmann (stieg)
---
drivers/misc/vmw_vmci/vmci_doorbell.c | 751 +
drivers/misc/vmw_vmci/vmci_doorbell.h | 57 +++
2 files changed, 808 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_doorbell.c
create mode 100644 drivers/misc/vmw_vmci/vmci_doorbell.h
diff --git a/drivers/misc/vmw_vmci/vmci_doorbell.c
b/drivers/misc/vmw_vmci/vmci_doorbell.c
new file mode 100644
index 000..389ba4c
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_doorbell.c
@@ -0,0 +1,751 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "vmci_common_int.h"
+#include "vmci_datagram.h"
+#include "vmci_doorbell.h"
+#include "vmci_driver.h"
+#include "vmci_resource.h"
+#include "vmci_route.h"
+
+#define VMCI_DOORBELL_INDEX_TABLE_SIZE (1 << 6)
+#define VMCI_DOORBELL_HASH(_idx) \
+ vmci_hash_calc((_idx), VMCI_DOORBELL_INDEX_TABLE_SIZE)
+
+/*
+ * DoorbellEntry describes the a doorbell notification handle allocated by the
+ * host.
+ */
+struct dbell_entry {
+ struct vmci_resource resource;
+ uint32_t idx;
+ struct list_head idxListItem;
+ uint32_t privFlags;
+ bool runDelayed;
+ VMCICallback notifyCB;
+ void *clientData;
+ wait_queue_head_t destroyEvent;
+ atomic_t active;/* Only used by guest personality */
+};
+
+/* The VMCI index table keeps track of currently registered doorbells. */
+static struct dbell_index_table {
+ spinlock_t lock;
+ struct list_head entries[VMCI_DOORBELL_INDEX_TABLE_SIZE];
+} vmciDoorbellIT;
+
+/*
+ * The maxNotifyIdx is one larger than the currently known bitmap index in
+ * use, and is used to determine how much of the bitmap needs to be scanned.
+ */
+static uint32_t maxNotifyIdx;
+
+/*
+ * The notifyIdxCount is used for determining whether there are free entries
+ * within the bitmap (if notifyIdxCount + 1 < maxNotifyIdx).
+ */
+static uint32_t notifyIdxCount;
+
+/*
+ * The lastNotifyIdxReserved is used to track the last index handed out - in
+ * the case where multiple handles share a notification index, we hand out
+ * indexes round robin based on lastNotifyIdxReserved.
+ */
+static uint32_t lastNotifyIdxReserved;
+
+/* This is a one entry cache used to by the index allocation. */
+static uint32_t lastNotifyIdxReleased = PAGE_SIZE;
+
+/*
+ * General init code.
+ */
+int __init vmci_dbell_init(void)
+{
+ uint32_t bucket;
+
+ for (bucket = 0; bucket < ARRAY_SIZE(vmciDoorbellIT.entries); ++bucket)
+ INIT_LIST_HEAD([bucket]);
+
+ spin_lock_init();
+ return VMCI_SUCCESS;
+}
+
+/*
+ * Callback to free doorbell entry structure when resource is no longer used,
+ * The entry is freed in VMCIDoorbell_Destroy(), which is waiting on the
+ * signal that gets fired here.
+ */
+static void dbell_free_cb(void *clientData)
+{
+ struct dbell_entry *entry = (struct dbell_entry *)clientData;
+ ASSERT(entry);
+ wake_up(>destroyEvent);
+}
+
+static int dbell_release_cb(void *clientData)
+{
+ struct dbell_entry *entry = (struct dbell_entry *)clientData;
+ ASSERT(entry);
+ vmci_resource_release(>resource);
+ return 0;
+}
+
+/*
+ * Utility function that retrieves the privilege flags associated
+ * with a given doorbell handle. For guest endpoints, the
+ * privileges are determined by the context ID, but for host
+ * endpoints privileges are associated with the complete
+ * handle. Hypervisor endpoints are not yet supported.
+ */
+int vmci_dbell_get_priv_flags(struct vmci_handle handle,
+ uint32_t *privFlags)
+{
+ if (privFlags == NULL || handle.context == VMCI_INVALID_ID)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ if (handle.context == VMCI_HOST_CONTEXT_ID) {
+ struct dbell_entry *entry;
+ struct vmci_resource *resource;
+
+ resource =
+ vmci_resource_get(handle, VMCI_RESOURCE_TYPE_DOORBELL);
+ if (resource == NULL)
+ return VMCI_ERROR_NOT_FOUND;
+
+
[vmw_vmci 00/11] VMCI for Linux
In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later post. VMCI allows virtual machines to communicate with host kernel modules and the VMware hypervisors. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets, a socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. In a virtual machine, VMCI is exposed as a regular PCI device. The primary communication mechanisms supported are a point-to-point bidirectional transport based on a pair of memory-mapped queues, and asynchronous notifications in the form of datagrams and doorbells. These features are available to kernel level components such as HGFS and VMCI Sockets through the VMCI kernel API. In addition to this, the VMCI kernel API provides support for receiving events related to the state of the VMCI communication channels, and the virtual machine itself. Outside the virtual machine, the host side support of the VMCI kernel module makes the same VMCI kernel API available to VMCI endpoints on the host. In addition to this, the host side manages each VMCI device in a virtual machine through a context object. This context object serves to identify the virtual machine for communication, and to track the resource consumption of the given VMCI device. Both operations related to communication between the virtual machine and the host kernel, and those related to the management of the VMCI device state in the host kernel, are invoked by the user level component of the hypervisor through a set of ioctls on the VMCI device node. To provide seamless support for nested virtualization, where a virtual machine may use both a VMCI PCI device to talk to its hypervisor, and the VMCI host side support to run nested virtual machines, the VMCI host and virtual machine support are combined in a single kernel module. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. Andrew Stiegmann (stieg) (11): Apply VMCI context code Apply VMCI datagram code Apply VMCI doorbell code Apply VMCI driver code Apply VMCI event code Apply dynamic array code Apply VMCI hash table Apply VMCI queue pairs Apply VMCI resource code Apply vmci routing code Apply the header code to make VMCI build drivers/misc/Kconfig |1 + drivers/misc/Makefile |1 + drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile| 43 + drivers/misc/vmw_vmci/vmci_common_int.h | 58 + drivers/misc/vmw_vmci/vmci_context.c | 1269 +++ drivers/misc/vmw_vmci/vmci_context.h | 161 ++ drivers/misc/vmw_vmci/vmci_datagram.c | 586 + drivers/misc/vmw_vmci/vmci_datagram.h | 56 + drivers/misc/vmw_vmci/vmci_doorbell.c | 751 ++ drivers/misc/vmw_vmci/vmci_doorbell.h | 57 + drivers/misc/vmw_vmci/vmci_driver.c | 2298 +++ drivers/misc/vmw_vmci/vmci_driver.h | 52 + drivers/misc/vmw_vmci/vmci_event.c| 451 drivers/misc/vmw_vmci/vmci_event.h| 29 + drivers/misc/vmw_vmci/vmci_handle_array.c | 174 ++ drivers/misc/vmw_vmci/vmci_handle_array.h | 50 + drivers/misc/vmw_vmci/vmci_hash_table.c | 332 +++ drivers/misc/vmw_vmci/vmci_hash_table.h | 56 + drivers/misc/vmw_vmci/vmci_queue_pair.c | 3548 + drivers/misc/vmw_vmci/vmci_queue_pair.h | 182 ++ drivers/misc/vmw_vmci/vmci_resource.c | 194 ++ drivers/misc/vmw_vmci/vmci_resource.h | 62 + drivers/misc/vmw_vmci/vmci_route.c| 241 ++ drivers/misc/vmw_vmci/vmci_route.h| 34 + include/linux/vmw_vmci_api.h | 89 + include/linux/vmw_vmci_defs.h | 921 27 files changed, 11712 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644
[vmw_vmci 05/11] Apply VMCI event code
Code that manages event handlers and handles callbacks when
specific events fire.
Signed-off-by: Andrew Stiegmann (stieg)
---
drivers/misc/vmw_vmci/vmci_event.c | 451
drivers/misc/vmw_vmci/vmci_event.h | 29 +++
2 files changed, 480 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_event.c
create mode 100644 drivers/misc/vmw_vmci/vmci_event.h
diff --git a/drivers/misc/vmw_vmci/vmci_event.c
b/drivers/misc/vmw_vmci/vmci_event.c
new file mode 100644
index 000..bc4e976
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_event.c
@@ -0,0 +1,451 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "vmci_event.h"
+#include "vmci_driver.h"
+
+#define EVENT_MAGIC 0xEABE
+#define VMCI_EVENT_MAX_ATTEMPTS 10
+
+struct vmci_subscription {
+ uint32_t id;
+ int refCount;
+ bool runDelayed;
+ wait_queue_head_t destroyEvent;
+ uint32_t event;
+ VMCI_EventCB callback;
+ void *callbackData;
+ struct list_head subscriberListItem;
+};
+
+static struct list_head subscriberArray[VMCI_EVENT_MAX];
+static spinlock_t subscriberLock;
+
+struct delayed_event_info {
+ struct vmci_subscription *sub;
+ uint8_t eventPayload[sizeof(struct vmci_event_data_max)];
+};
+
+struct event_ref {
+ struct vmci_subscription *sub;
+ struct list_head listItem;
+};
+
+int __init vmci_event_init(void)
+{
+ int i;
+
+ for (i = 0; i < VMCI_EVENT_MAX; i++)
+ INIT_LIST_HEAD([i]);
+
+ spin_lock_init();
+ return VMCI_SUCCESS;
+}
+
+void vmci_event_exit(void)
+{
+ int e;
+
+ /* We free all memory at exit. */
+ for (e = 0; e < VMCI_EVENT_MAX; e++) {
+ struct vmci_subscription *cur, *p2;
+ list_for_each_entry_safe(cur, p2, [e],
+subscriberListItem) {
+
+ /*
+* We should never get here because all events
+* should have been unregistered before we try
+* to unload the driver module. Also, delayed
+* callbacks could still be firing so this
+* cleanup would not be safe. Still it is
+* better to free the memory than not ... so
+* we leave this code in just in case
+*/
+ pr_warn("Unexpected free events occuring.");
+ kfree(cur);
+ }
+ }
+
+}
+
+/*
+ * Gets a reference to the given VMCISubscription.
+ */
+static void event_get(struct vmci_subscription *entry)
+{
+ ASSERT(entry);
+
+ entry->refCount++;
+}
+
+/*
+ * Releases the given VMCISubscription.
+ * Fires the destroy event if the reference count has gone to zero.
+ */
+static void event_release(struct vmci_subscription *entry)
+{
+ ASSERT(entry);
+ ASSERT(entry->refCount > 0);
+
+ entry->refCount--;
+ if (entry->refCount == 0)
+ wake_up(>destroyEvent);
+}
+
+/*
+ * Callback to release the event entry reference. It is called by the
+ * VMCI_WaitOnEvent function before it blocks.
+ */
+static int event_release_cb(void *clientData)
+{
+ struct vmci_subscription *sub = (struct vmci_subscription *)clientData;
+
+ ASSERT(sub);
+
+ spin_lock_bh();
+ event_release(sub);
+ spin_unlock_bh();
+
+ return 0;
+}
+
+/*
+ * Find entry. Assumes lock is held.
+ * Increments the VMCISubscription refcount if an entry is found.
+ */
+static struct vmci_subscription *event_find(uint32_t subID)
+{
+ int e;
+
+ for (e = 0; e < VMCI_EVENT_MAX; e++) {
+ struct vmci_subscription *cur;
+ list_for_each_entry(cur, [e],
+ subscriberListItem) {
+ if (cur->id == subID) {
+ event_get(cur);
+ return cur;
+ }
+ }
+ }
+ return NULL;
+}
+
+/*
+ * Calls the specified callback in a delayed context.
+ */
+static void
Re: [vmw_vmci 00/11] VMCI for Linux
On Thu, Jul 26, 2012 at 04:39:29PM -0700, Andrew Stiegmann (stieg) wrote: > In an effort to improve the out-of-the-box experience with Linux > kernels for VMware users, VMware is working on readying the Virtual > Machine Communication Interface (vmw_vmci) and VMCI Sockets > (vmw_vsock) kernel modules for inclusion in the Linux kernel. The > purpose of this post is to acquire feedback on the vmw_vmci kernel > module. The vmw_vsock kernel module will be presented in a later post. Ugh, you do realize this is the middle of the merge window when we are all busy doing other things than code review of new stuff, right? It's going to be a few weeks before I can look at this, sorry. good luck, 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: [Resend][PATCH] ACPI / PM: Fix build warning in sleep.c for CONFIG_ACPI_SLEEP unset
Applied. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] n_tty: Don't lose characters when PARMRK is enabled
When PARMRK is set and large transfers of characters that will get
marked are being received, n_tty could drop data silently (i.e.
without reporting any error to the client). This is because
characters have the potential to take up to three bytes in the line
discipline (when they get marked with parity or framing errors), but
the amount of free space reported to tty_buffer flush_to_ldisc (via
tty->receive_room) is based on the pre-marked data size.
With this patch, the n_tty layer will no longer assume that each byte
will only take up one byte in the line discipline. Instead, it will
make an overly conservative estimate that each byte will take up
three bytes in the line discipline when PARMRK is set.
Signed-off-by: Jaeden Amero
---
drivers/tty/n_tty.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 101790c..5299cda 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -92,10 +92,20 @@ static inline int tty_put_user(struct tty_struct *tty,
unsigned char x,
static void n_tty_set_room(struct tty_struct *tty)
{
- /* tty->read_cnt is not read locked ? */
- int left = N_TTY_BUF_SIZE - tty->read_cnt - 1;
+ int left;
int old_left;
+ /* tty->read_cnt is not read locked ? */
+ if (I_PARMRK(tty))
+ {
+ /* Multiply read_cnt by 3, since each byte might take up to
+* three times as many spaces when PARMRK is set (depending on
+* its flags, e.g. parity error). */
+ left = N_TTY_BUF_SIZE - tty->read_cnt * 3 - 1;
+ }
+ else
+ left = N_TTY_BUF_SIZE - tty->read_cnt - 1;
+
/*
* If we are doing input canonicalization, and there are no
* pending newlines, let characters through without limit, so
--
1.7.11.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/15] arm-soc: changes for v3.6
On Tue, Jul 24, 2012 at 02:51:35PM -0600, Paul Walmsley wrote: > Hi > > On Tue, 24 Jul 2012, Arnd Bergmann wrote: > > > On Tuesday 24 July 2012, Linus Torvalds wrote: > > > > > In your "for-linus" branch, "_3xxx_clkdm" remains in the > > > clockdomains_common[] array. In my merge, it is gone. But I think I > > > did the merge correctly, and you did it wrong. HOWEVER, I don't know > > > the code, maybe there is some subtle reason why you did it like you > > > did. > > > > Yes, I think you are right now that I look at it again. Paul Walmsley > > can have another look at the merge and send an update if we are both > > missing something now. > > Linus' merge is correct. FWIW, it looks right to me too. Thanks, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpuidle: coupled: fix sleeping while atomic in cpu notifier
On Thu, Jul 26, 2012 at 9:25 AM, Shilimkar, Santosh wrote: > On Wed, Jul 25, 2012 at 11:20 PM, Colin Cross wrote: >> The cpu hotplug notifier gets called in both atomic and non-atomic >> contexts, it is not always safe to lock a mutex. Filter out all events >> except the six necessary ones, which are all sleepable, before taking >> the mutex. >> >> Signed-off-by: Colin Cross >> --- > Agree. > Have you observed any lock-up ? > Colin explained me about cause of the issue in an off-list discussion. Thought of updating the thread in case some one wants to reproduce the issue. You get a warning during cpu hotplug in suspend if you turn on sleeping while atomic debugging option in kernel build and the patch fixes it. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: No big TTY/serial patch merge for 3.6-rc1
On Thu, 26 Jul 2012 14:28:07 -0700 Greg KH wrote: > On Thu, Jul 26, 2012 at 10:23:13PM +0100, Alan Cox wrote: > > On Thu, 26 Jul 2012 12:08:14 -0700 > > Greg KH wrote: > > > > > tty: Move the handling of the tty release logic > > > > Can we lose that one specifically. I've chased down Ian Abbotts problem > > and replicated it and that is the offending patch not the lock localise > > (which still needs to be kept out as it depends upon this one) > > > > I have it fixed but it's not had enough testing for -rc1 and moving the > > termios data has enough spectacular hits all drivers fallout for 3.6 > > Yes, I can go revert it. I'm working on building up a small tty-linus > branch at the moment for just the "must haves" for 3.6. Right now it's > just 10 patches listed below. Any objection to me sending these after > a round trip through linux-next? All look good to me -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
