* [PATCH v2] regulator: max8649 Convert max8649 to use regmap api
From: Mark Brown @ 2011-10-24 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319462786-2602-1-git-send-email-jhbird.choi@gmail.com>
On Mon, Oct 24, 2011 at 10:26:26PM +0900, jhbird.choi at gmail.com wrote:
> From: Jonghwan Choi <jhbird.choi@gmail.com>
>
> Signed-off-by: Jonghwan Choi <jhbird.choi@gmail.com>
Looks good!
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Once the merge window is over it might be useful to look at enabling
register cache for the driver, you'll get a performance improvement as
it'll be able to skip the read part of read/modify/write cycles.
^ permalink raw reply
* Re: Problem with TeVii S-470
From: Mike Mironov @ 2011-10-24 13:45 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Josu Lazkano
In-Reply-To: <CAL9G6WXS9cPTG1w=AGgUDLA5vkcYyAK1e7ZHdK33aAXjzVCU0A@mail.gmail.com>
24.10.2011 17:32, Josu Lazkano пишет:
> 2011/10/24 Mike Mironov<subscribe@darkmike.ru>:
>> 24.10.2011 15:29, Josu Lazkano пишет:
>>>
>>> 2011/10/24 Mike Mironov<subscribe@darkmike.ru>:
>>>>
>>>> Hello!
>>>>
>>>> I have this card http://www.linuxtv.org/wiki/index.php/TeVii_S470
>>>>
>>>> I try to use it under Debian Squeeze, but I can't get channel data from
>>>> it.
>>>>
>>>> I try to use drivers from 2.6.38, 2.6.39 kernels, s2-liplianin drivers
^^^^^^^^^^^^
>
> Hello again, actually, I am using this method for Tevii S660 and S470:
>
> apt-get install linux-headers-`uname -r` build-essential
> mkdir /usr/local/src/dvb
> cd /usr/local/src/dvb
> wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip
> unzip tip.zip
> cd s2-liplianin-0b7d3cc65161
> make CONFIG_DVB_FIREDTV:=n
> make install
>
> Both methods works for me on a Debian Squeeze (2.6.32). Here more
> info: http://linuxtv.org/wiki/index.php/TeVii_S470
>
As your can see in quoted text I always try to use this drivers. Result
is same. I'll always read WiKi link. I know that another users use this
card without problems. I have good signal quality (88% signal and 79-80%
snr). But in my 2 linux systems I can't get channel data. Scan work
fine(!).
^ permalink raw reply
* Re: [PATCH 5/5] staging:iio:adc:max1363 use new demuxing support.
From: Jonathan Cameron @ 2011-10-24 13:45 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: linux-iio
In-Reply-To: <1319128169-3722-6-git-send-email-jic23@cam.ac.uk>
On 10/20/11 17:29, Jonathan Cameron wrote:
> Note that time stamps are not currently supported
> hence for now I've cheekly removed them from this
> driver. Also hence no sign off.
Also in a last minute 'cleanup' I removed the bit that set
buffer->bpe appropriately. Bad idea as now it is used
(before it wasn't).
oops.
> ---
> drivers/staging/iio/adc/max1363_core.c | 4 ----
> drivers/staging/iio/adc/max1363_ring.c | 27 ++++++---------------------
> 2 files changed, 6 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/max1363_core.c b/drivers/staging/iio/adc/max1363_core.c
> index eb699ad..8f19d2d 100644
> --- a/drivers/staging/iio/adc/max1363_core.c
> +++ b/drivers/staging/iio/adc/max1363_core.c
> @@ -325,7 +325,6 @@ static const enum max1363_modes max1363_mode_list[] = {
> MAX1363_CHAN_B(2, 3, d2m3, 5, bits, em), \
> MAX1363_CHAN_B(1, 0, d1m0, 6, bits, em), \
> MAX1363_CHAN_B(3, 2, d3m2, 7, bits, em), \
> - IIO_CHAN_SOFT_TIMESTAMP(8) \
> }
>
> static struct iio_chan_spec max1036_channels[] = MAX1363_4X_CHANS(8, 0);
> @@ -383,7 +382,6 @@ static const enum max1363_modes max1238_mode_list[] = {
> MAX1363_CHAN_B(7, 6, d7m6, 21, bits, 0), \
> MAX1363_CHAN_B(9, 8, d9m8, 22, bits, 0), \
> MAX1363_CHAN_B(11, 10, d11m10, 23, bits, 0), \
> - IIO_CHAN_SOFT_TIMESTAMP(24) \
> }
> static struct iio_chan_spec max1038_channels[] = MAX1363_12X_CHANS(8);
> static struct iio_chan_spec max1138_channels[] = MAX1363_12X_CHANS(10);
> @@ -424,7 +422,6 @@ static const enum max1363_modes max11608_mode_list[] = {
> MAX1363_CHAN_B(3, 2, d3m2, 13, bits, 0), \
> MAX1363_CHAN_B(5, 4, d5m4, 14, bits, 0), \
> MAX1363_CHAN_B(7, 6, d7m6, 15, bits, 0), \
> - IIO_CHAN_SOFT_TIMESTAMP(16) \
> }
> static struct iio_chan_spec max11602_channels[] = MAX1363_8X_CHANS(8);
> static struct iio_chan_spec max11608_channels[] = MAX1363_8X_CHANS(10);
> @@ -439,7 +436,6 @@ static const enum max1363_modes max11644_mode_list[] = {
> MAX1363_CHAN_U(1, _s1, 1, bits, 0), \
> MAX1363_CHAN_B(0, 1, d0m1, 2, bits, 0), \
> MAX1363_CHAN_B(1, 0, d1m0, 3, bits, 0), \
> - IIO_CHAN_SOFT_TIMESTAMP(4) \
> }
>
> static struct iio_chan_spec max11646_channels[] = MAX1363_2X_CHANS(10);
> diff --git a/drivers/staging/iio/adc/max1363_ring.c b/drivers/staging/iio/adc/max1363_ring.c
> index df6893e..294dec9 100644
> --- a/drivers/staging/iio/adc/max1363_ring.c
> +++ b/drivers/staging/iio/adc/max1363_ring.c
> @@ -68,36 +68,21 @@ error_ret:
> static int max1363_ring_preenable(struct iio_dev *indio_dev)
> {
> struct max1363_state *st = iio_priv(indio_dev);
> - struct iio_buffer *ring = indio_dev->buffer;
> - size_t d_size = 0;
> - unsigned long numvals;
>
> /*
> * Need to figure out the current mode based upon the requested
> * scan mask in iio_dev
> */
> - st->current_mode = max1363_match_mode(ring->scan_mask,
> - st->chip_info);
> + st->current_mode = max1363_match_mode(indio_dev->buffer->scan_mask,
> + st->chip_info);
> if (!st->current_mode)
> return -EINVAL;
> -
> max1363_set_scan_mode(st);
>
> - numvals = bitmap_weight(st->current_mode->modemask,
> - indio_dev->masklength);
> - if (ring->access->set_bytes_per_datum) {
> - if (ring->scan_timestamp)
> - d_size += sizeof(s64);
> - if (st->chip_info->bits != 8)
> - d_size += numvals*2;
> - else
> - d_size += numvals;
> - if (ring->scan_timestamp && (d_size % 8))
> - d_size += 8 - (d_size % 8);
> - ring->access->set_bytes_per_datum(ring, d_size);
> - }
> + /* work out how to pull out the channels we actually want */
> + iio_update_demux(indio_dev);
>
> - return 0;
> + return iio_sw_buffer_preenable(indio_dev);
> }
>
> static irqreturn_t max1363_trigger_handler(int irq, void *p)
> @@ -141,7 +126,7 @@ static irqreturn_t max1363_trigger_handler(int irq, void *p)
>
> memcpy(rxbuf + d_size - sizeof(s64), &time_ns, sizeof(time_ns));
>
> - indio_dev->buffer->access->store_to(indio_dev->buffer, rxbuf, time_ns);
> + iio_push_to_buffer(indio_dev->buffer, rxbuf, time_ns);
> done:
> iio_trigger_notify_done(indio_dev->trig);
> kfree(rxbuf);
^ permalink raw reply
* [GIT PULL FOR v3.2] uvcvideo fixes
From: Laurent Pinchart @ 2011-10-24 13:45 UTC (permalink / raw)
To: linux-media
Hi Mauro,
The following changes since commit 35a912455ff5640dc410e91279b03e04045265b2:
Merge branch 'v4l_for_linus' into staging/for_v3.2 (2011-10-19 12:41:18
-0200)
are available in the git repository at:
git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
Hans de Goede (1):
uvcvideo: GET_RES should only be checked for BITMAP type menu controls
drivers/media/video/uvc/uvc_ctrl.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 2/4] Add access control support to qemu bridge helper
From: Corey Bryant @ 2011-10-24 13:44 UTC (permalink / raw)
To: Blue Swirl; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <CAAu8pHtEjTGynJ=ekkDQmEEnYrAVRDV3TVkCpjCa_N2kxhO1jA@mail.gmail.com>
On 10/23/2011 09:10 AM, Blue Swirl wrote:
> On Fri, Oct 21, 2011 at 15:07, Corey Bryant<coreyb@linux.vnet.ibm.com> wrote:
>> > We go to great lengths to restrict ourselves to just cap_net_admin as an OS
>> > enforced security mechanism. However, we further restrict what we allow users
>> > to do to simply adding a tap device to a bridge interface by virtue of the fact
>> > that this is the only functionality we expose.
>> >
>> > This is not good enough though. An administrator is likely to want to restrict
>> > the bridges that an unprivileged user can access, in particular, to restrict
>> > an unprivileged user from putting a guest on what should be isolated networks.
>> >
>> > This patch implements an ACL mechanism that is enforced by qemu-bridge-helper.
>> > The ACLs are fairly simple whitelist/blacklist mechanisms with a wildcard of
>> > 'all'. All users are blacklisted by default, and deny takes precedence over
>> > allow.
>> >
>> > An interesting feature of this ACL mechanism is that you can include external
>> > ACL files. The main reason to support this is so that you can set different
>> > file system permissions on those external ACL files. This allows an
>> > administrator to implement rather sophisicated ACL policies based on user/group
> sophisticated
>
Yep, thanks.
>> > policies via the file system.
>> >
>> > As an example:
>> >
>> > /etc/qemu/bridge.conf root:qemu 0640
>> >
>> > allow br0
>> > include /etc/qemu/alice.conf
>> > include /etc/qemu/bob.conf
>> > include /etc/qemu/charlie.conf
>> >
>> > /etc/qemu/alice.conf root:alice 0640
>> > allow br1
>> >
>> > /etc/qemu/bob.conf root:bob 0640
>> > allow br2
>> >
>> > /etc/qemu/charlie.conf root:charlie 0640
>> > deny all
> I think syntax 'include/etc/qemu/user.d/*.conf' or 'includedir
> /etc/qemu/user.d' could be also useful.
>
That could be useful, though I'm not sure it's necessary right now.
>> > This ACL pattern allows any user in the qemu group to get a tap device
>> > connected to br0 (which is bridged to the physical network).
>> >
>> > Users in the alice group can additionally get a tap device connected to br1.
>> > This allows br1 to act as a private bridge for the alice group.
>> >
>> > Users in the bob group can additionally get a tap device connected to br2.
>> > This allows br2 to act as a private bridge for the bob group.
>> >
>> > Users in the charlie group cannot get a tap device connected to any bridge.
>> >
>> > Under no circumstance can the bob group get access to br1 or can the alice
>> > group get access to br2. And under no cicumstance can the charlie group
>> > get access to any bridge.
>> >
>> > Signed-off-by: Anthony Liguori<aliguori@us.ibm.com>
>> > Signed-off-by: Richa Marwaha<rmarwah@linux.vnet.ibm.com>
>> > Signed-off-by: Corey Bryant<coreyb@linux.vnet.ibm.com>
>> > ---
>> > qemu-bridge-helper.c | 141 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> > 1 files changed, 141 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
>> > index 2ce82fb..db257d5 100644
>> > --- a/qemu-bridge-helper.c
>> > +++ b/qemu-bridge-helper.c
>> > @@ -33,6 +33,105 @@
>> >
>> > #include "net/tap-linux.h"
>> >
>> > +#define MAX_ACLS (128)
> If all users (or groups) in the system have an ACL, this number could
> be way too low. Please use a list instead.
>
I agree, we shouldn't be hard-coding the limit here. I'll update this.
>> > +#define DEFAULT_ACL_FILE CONFIG_QEMU_CONFDIR "/bridge.conf"
>> > +
>> > +enum {
>> > + ACL_ALLOW = 0,
>> > + ACL_ALLOW_ALL,
>> > + ACL_DENY,
>> > + ACL_DENY_ALL,
>> > +};
>> > +
>> > +typedef struct ACLRule {
>> > + int type;
>> > + char iface[IFNAMSIZ];
>> > +} ACLRule;
>> > +
>> > +static int parse_acl_file(const char *filename, ACLRule *acls, int *pacl_count)
>> > +{
>> > + int acl_count = *pacl_count;
>> > + FILE *f;
>> > + char line[4096];
>> > +
>> > + f = fopen(filename, "r");
>> > + if (f == NULL) {
>> > + return -1;
>> > + }
>> > +
>> > + while (acl_count != MAX_ACLS&&
>> > + fgets(line, sizeof(line), f) != NULL) {
>> > + char *ptr = line;
>> > + char *cmd, *arg, *argend;
>> > +
>> > + while (isspace(*ptr)) {
>> > + ptr++;
>> > + }
>> > +
>> > + /* skip comments and empty lines */
>> > + if (*ptr == '#' || *ptr == 0) {
>> > + continue;
>> > + }
>> > +
>> > + cmd = ptr;
>> > + arg = strchr(cmd, ' ');
>> > + if (arg == NULL) {
>> > + arg = strchr(cmd, '\t');
>> > + }
>> > +
>> > + if (arg == NULL) {
>> > + fprintf(stderr, "Invalid config line:\n %s\n", line);
>> > + fclose(f);
>> > + errno = EINVAL;
>> > + return -1;
>> > + }
>> > +
>> > + *arg = 0;
>> > + arg++;
>> > + while (isspace(*arg)) {
>> > + arg++;
>> > + }
>> > +
>> > + argend = arg + strlen(arg);
>> > + while (arg != argend&& isspace(*(argend - 1))) {
>> > + argend--;
>> > + }
> These while loops to skip spaces are repeated, but the comment
> skipping part is not, so it is not possible to have comments after
> rules or split rules to several lines. I'd add a simple state variable
> to track at which stage we are in parsing instead.
>
That could be useful too, but again not sure it's necessary right now.
I really like the simplicity we have with the existing approach.
>> > + *argend = 0;
>> > +
>> > + if (strcmp(cmd, "deny") == 0) {
>> > + if (strcmp(arg, "all") == 0) {
>> > + acls[acl_count].type = ACL_DENY_ALL;
>> > + } else {
>> > + acls[acl_count].type = ACL_DENY;
>> > + snprintf(acls[acl_count].iface, IFNAMSIZ, "%s", arg);
>> > + }
>> > + acl_count++;
>> > + } else if (strcmp(cmd, "allow") == 0) {
>> > + if (strcmp(arg, "all") == 0) {
>> > + acls[acl_count].type = ACL_ALLOW_ALL;
>> > + } else {
>> > + acls[acl_count].type = ACL_ALLOW;
>> > + snprintf(acls[acl_count].iface, IFNAMSIZ, "%s", arg);
>> > + }
>> > + acl_count++;
>> > + } else if (strcmp(cmd, "include") == 0) {
>> > + /* ignore errors */
>> > + parse_acl_file(arg, acls,&acl_count);
>> > + } else {
>> > + fprintf(stderr, "Unknown command `%s'\n", cmd);
>> > + fclose(f);
>> > + errno = EINVAL;
>> > + return -1;
>> > + }
>> > + }
>> > +
>> > + *pacl_count = acl_count;
>> > +
>> > + fclose(f);
>> > +
>> > + return 0;
>> > +}
>> > +
>> > static int has_vnet_hdr(int fd)
>> > {
>> > unsigned int features = 0;
>> > @@ -95,6 +194,9 @@ int main(int argc, char **argv)
>> > const char *bridge;
>> > char iface[IFNAMSIZ];
>> > int index;
>> > + ACLRule acls[MAX_ACLS];
>> > + int acl_count = 0;
>> > + int i, access_allowed, access_denied;
>> >
>> > /* parse arguments */
>> > if (argc< 3 || argc> 4) {
>> > @@ -115,6 +217,45 @@ int main(int argc, char **argv)
>> > bridge = argv[index++];
>> > unixfd = atoi(argv[index++]);
>> >
>> > + /* parse default acl file */
>> > + if (parse_acl_file(DEFAULT_ACL_FILE, acls,&acl_count) == -1) {
>> > + fprintf(stderr, "failed to parse default acl file `%s'\n",
>> > + DEFAULT_ACL_FILE);
>> > + return -errno;
>> > + }
>> > +
>> > + /* validate bridge against acl -- default policy is to deny
>> > + * according acl policy if we have a deny and allow both
>> > + * then deny should always win over allow
>> > + */
>> > + access_allowed = 0;
>> > + access_denied = 0;
>> > + for (i = 0; i< acl_count; i++) {
>> > + switch (acls[i].type) {
>> > + case ACL_ALLOW_ALL:
>> > + access_allowed = 1;
>> > + break;
>> > + case ACL_ALLOW:
>> > + if (strcmp(bridge, acls[i].iface) == 0) {
>> > + access_allowed = 1;
>> > + }
>> > + break;
>> > + case ACL_DENY_ALL:
>> > + access_denied = 1;
>> > + break;
>> > + case ACL_DENY:
>> > + if (strcmp(bridge, acls[i].iface) == 0) {
>> > + access_denied = 1;
>> > + }
>> > + break;
>> > + }
>> > + }
>> > +
>> > + if ((access_allowed == 0) || (access_denied == 1)) {
>> > + fprintf(stderr, "access denied by acl file\n");
>> > + return -EPERM;
>> > + }
>> > +
>> > /* open a socket to use to control the network interfaces */
>> > ctlfd = socket(AF_INET, SOCK_STREAM, 0);
>> > if (ctlfd == -1) {
>> > --
>> > 1.7.3.4
>> >
>> >
>> >
--
Regards,
Corey
^ permalink raw reply
* [Buildroot] Call For Participation: buildroot + crosstool-NG Developpers' Day
From: Robert Schwebel @ 2011-10-24 13:45 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201110241432.01625.yann.morin.1998@anciens.enib.fr>
On Mon, Oct 24, 2011 at 02:32:01PM +0200, Yann E. MORIN wrote:
> We'll be sure to keep you informed before Friday. If you can't get your
> mails once in Prague, you can try and get to us (Peter, Thomas, or me)
> during the conferences.
Thanks for the update, that's all fine, I think we'll meet on wednesday
anyway.
I just wanted to check if you still plan to have the event, as I pushed
my travel back to sunday in order to have a chance to participate.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* multipath-tools/multipath main.c
From: bmarzins @ 2011-10-24 13:44 UTC (permalink / raw)
To: dm-cvs, dm-devel
CVSROOT: /cvs/dm
Module name: multipath-tools
Branch: RHEL5_FC6
Changes by: bmarzins@sourceware.org 2011-10-24 13:44:25
Modified files:
multipath : main.c
Log message:
Fix for bz #740022. Do better type checking on the argument passed to multipath,
to determine whether it's a path device name, dev_t, or a multipath device.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/multipath/main.c.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.44.2.10&r2=1.44.2.11
--- multipath-tools/multipath/main.c 2010/04/24 05:28:06 1.44.2.10
+++ multipath-tools/multipath/main.c 2011/10/24 13:44:25 1.44.2.11
@@ -1,7 +1,7 @@
/*
* Soft: multipath device mapper target autoconfig
*
- * Version: $Id: main.c,v 1.44.2.10 2010/04/24 05:28:06 bmarzins Exp $
+ * Version: $Id: main.c,v 1.44.2.11 2011/10/24 13:44:25 bmarzins Exp $
*
* Author: Christophe Varoqui
*
@@ -21,7 +21,8 @@
* Copyright (c) 2005 Patrick Caulfield, Redhat
* Copyright (c) 2005 Edward Goggin, EMC
*/
-
+#include <sys/types.h>
+#include <sys/stat.h>
#include <stdio.h>
#include <unistd.h>
#include <ctype.h>
@@ -47,6 +48,7 @@
#include <configure.h>
#include <pgpolicies.h>
#include <version.h>
+#include "dev_t.h"
static int
filter_pathvec (vector pathvec, char * refwwid)
@@ -302,13 +304,29 @@
return r;
}
+static int
+get_dev_type(char *dev) {
+ struct stat buf;
+ int i;
+
+ if (stat(dev, &buf) == 0 && S_ISBLK(buf.st_mode)) {
+ if (dm_is_dm_major(MAJOR(buf.st_rdev)))
+ return DEV_DEVMAP;
+ return DEV_DEVNODE;
+ }
+ else if (sscanf(dev, "%d:%d", &i, &i) == 2)
+ return DEV_DEVT;
+ else
+ return DEV_DEVMAP;
+}
+
int
main (int argc, char *argv[])
{
int arg;
extern char *optarg;
extern int optind;
- int i, r = 1;
+ int r = 1;
if (getuid() != 0) {
fprintf(stderr, "need to be root\n");
@@ -396,13 +414,7 @@
strncpy(conf->dev, argv[optind], FILE_NAME_SIZE);
- if (filepresent(conf->dev))
- conf->dev_type = DEV_DEVNODE;
- else if (sscanf(conf->dev, "%d:%d", &i, &i) == 2)
- conf->dev_type = DEV_DEVT;
- else
- conf->dev_type = DEV_DEVMAP;
-
+ conf->dev_type = get_dev_type(conf->dev);
}
dm_init();
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Jan Kiszka @ 2011-10-24 13:43 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Avi Kivity, Marcelo Tosatti, kvm
In-Reply-To: <4EA563FD.5060308@siemens.com>
On 2011-10-24 15:11, Jan Kiszka wrote:
> On 2011-10-24 14:43, Michael S. Tsirkin wrote:
>> On Mon, Oct 24, 2011 at 02:06:08PM +0200, Jan Kiszka wrote:
>>> On 2011-10-24 13:09, Avi Kivity wrote:
>>>> On 10/24/2011 12:19 PM, Jan Kiszka wrote:
>>>>>>
>>>>>> With the new feature it may be worthwhile, but I'd like to see the whole
>>>>>> thing, with numbers attached.
>>>>>
>>>>> It's not a performance issue, it's a resource limitation issue: With the
>>>>> new API we can stop worrying about user space device models consuming
>>>>> limited IRQ routes of the KVM subsystem.
>>>>>
>>>>
>>>> Only if those devices are in the same process (or have access to the
>>>> vmfd). Interrupt routing together with irqfd allows you to disaggregate
>>>> the device model. Instead of providing a competing implementation with
>>>> new limitations, we need to remove the limitations of the old
>>>> implementation.
>>>
>>> That depends on where we do the cut. Currently we let the IRQ source
>>> signal an abstract edge on a pre-allocated pseudo IRQ line. But we
>>> cannot build correct MSI-X on top of the current irqfd model as we lack
>>> the level information (for PBA emulation). *)
>>
>>
>> I don't agree here. IMO PBA emulation would need to
>> clear pending bits on interrupt status register read.
>> So clearing pending bits could be done by ioctl from qemu
>> while setting them would be done from irqfd.
>
> How should QEMU know if the reason for "pending" has been cleared at
> device level if the device is outside the scope of QEMU? This model only
> works for PV devices when you agree that spurious IRQs are OK.
>
>>
>>> So we either need to
>>> extend the existing model anyway -- or push per-vector masking back to
>>> the IRQ source. In the latter case, it would be a very good chance to
>>> give up on limited pseudo GSIs with static routes and do MSI messaging
>>> from external IRQ sources to KVM directly.
>>> But all those considerations affect different APIs than what I'm
>>> proposing here. We will always need a way to inject MSIs in the context
>>> of the VM as there will always be scenarios where devices are better run
>>> in that very same context, for performance or simplicity or whatever
>>> reasons. E.g., I could imagine that one would like to execute an
>>> emulated IRQ remapper rather in the hypervisor context than
>>> "over-microkernelized" in a separate process.
>>>
>>> Jan
>>>
>>> *) Realized this while trying to generalize the proposed MSI-X MMIO
>>> acceleration for assigned devices to arbitrary device models, vhost-net,
>>
>> I'm actually working on a qemu patch to get pba emulation working correctly.
>> I think it's doable with existing irqfd.
>
> irqfd has no notion of level. You can only communicate a rising edge and
> then need a side channel for the state of the edge reason.
>
>>
>>> and specifically vfio.
>>
>> Interesting. How would you clear the pseudo interrupt level?
>
> Ideally: not at all (for MSI). If we manage the mask at device level, we
> only need to send the message if there is actually something to deliver
> to the interrupt controller and masked input events would be lost on
> real HW as well.
This wouldn't work out nicely as well. We rather need a combined model:
Devices need to maintain the PBA actively, i.e. set & clear them
themselves and do not rely on the core here (with the core being either
QEMU user space or an in-kernel MSI-X MMIO accelerator). The core only
checks the PBA if it is about to deliver some message and refrains from
doing so if the bit became 0 in the meantime (specifically during the
masked period). For QEMU device models, that means no additional IOCTLs,
just memory sharing of the PBA which is required anyway.
But that means QEMU-external device models need to gain at least basic
MSI-X knowledge. And if they gain this awareness, they could also use it
to send full-blown messages directly (e.g. device-id/vector tuples)
instead of encoding them into finite GSI numbers. But that's an add-on
topic.
Moreover, we still need a corresponding side channel for line-base
interrupts.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [CONSOLIDATED PULL 20/27] libtool: Upgrade from 2.4 -> 2.4.2
From: Koen Kooi @ 2011-10-24 13:37 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319463290.25011.10.camel@ted>
Op 24 okt. 2011, om 15:34 heeft Richard Purdie het volgende geschreven:
> On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
>> From: Khem Raj <raj.khem@gmail.com>
>>
>> Adjust prefix.patch and delete resolve-sysroot.patch
>> since its already applied upstream
>>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
>> .../libtool/{libtool.inc => libtool-2.4.2.inc} | 26 +++++++++---
>> meta/recipes-devtools/libtool/libtool-2.4.inc | 13 ------
>> ...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} | 2 +-
>> ...btool-native_2.4.bb => libtool-native_2.4.2.bb} | 2 +-
>> ...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} | 2 +-
>> meta/recipes-devtools/libtool/libtool/prefix.patch | 46 ++++++++++----------
>> .../libtool/libtool/resolve-sysroot.patch | 42 ------------------
>> .../libtool/{libtool_2.4.bb => libtool_2.4.2.bb} | 2 +-
>> 8 files changed, 47 insertions(+), 88 deletions(-)
>> rename meta/recipes-devtools/libtool/{libtool.inc => libtool-2.4.2.inc} (57%)
>> delete mode 100644 meta/recipes-devtools/libtool/libtool-2.4.inc
>> rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} (98%)
>> rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb => libtool-native_2.4.2.bb} (96%)
>> rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} (97%)
>> delete mode 100644 meta/recipes-devtools/libtool/libtool/resolve-sysroot.patch
>> rename meta/recipes-devtools/libtool/{libtool_2.4.bb => libtool_2.4.2.bb} (94%)
>>
>> diff --git a/meta/recipes-devtools/libtool/libtool.inc b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>> similarity index 57%
>> rename from meta/recipes-devtools/libtool/libtool.inc
>> rename to meta/recipes-devtools/libtool/libtool-2.4.2.inc
>> index ef9095b..1f652ef 100644
>> --- a/meta/recipes-devtools/libtool/libtool.inc
>> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>> @@ -1,4 +1,3 @@
>> -SUMMARY = "Generic library support script"
>
> Why drop the SUMMARY field?
What's the difference between SUMMARY and DESCRIPTION? And what happens if both are set?
regards,
Koen
^ permalink raw reply
* Linux 3.1
From: Linus Torvalds @ 2011-10-24 13:43 UTC (permalink / raw)
To: Linux Kernel Mailing List
As promised, the kernel summit has started, and Linux-3.1 is out. The
(small) shortlog of changes since -rc10 are appended, we have mostly
some sparc and networking changes, along with some radeon and intel
iommu fixes (mostly for largepages and integrated graphics issues).
Most people probably will not notice the changes.
One big change from -rc10 is that there are tar-balls and patches, so
if you aren't a git user (why?) you can download it now in a
traditional format. On of the things to note is that the files are now
signed by my gpg key, and it's the *uncompressed* version that the
signature is for.
And of course, this means that the merge window for 3.2 is open. I'll
do some merging during the KS, but probably most when I get back home
- but you can still send me the pull request, even if I may not
necessarily pull it for a few days.
NOTE! Because the -rc series was longer than usual, and as a result
linux-next is bigger than usual, I'm going to be much more of a
stickler for "has your patch series been in linux-next" than usual. If
I get a big pull request for things that I can't find in my linux-next
branch, I will simply not pull it - we have enough code that has gone
through the proper channels as it is, and we don't need anything
extra.
Another thing worth mentioning is that I really want the pull request
to be validated some way. With the small changes late in the -rc
series, I could afford to spend the time to look at commits and try to
verify them, but with the merge window (and the 11k commits or so that
I saw pending in the last linux-next tree), that just isn't
reasonable.
So use git.kernel.org or some other host that I can trust is really you.
Have fun,
Linus
---
Alasdair G Kergon (1):
dm kcopyd: fix job_pool leak
Alex Deucher (4):
drm/radeon/kms/DCE4.1: fix dig encoder to transmitter mapping
drm/radeon/kms/DCE4.1: ss is not supported on the internal pplls
drm/radeon/kms/DCE4.1: fix Select_CrtcSource EncodeMode setting
for DP bridges (v2)
drm/radeon/kms/atom: fix handling of FB scratch indices
Allen Kay (3):
intel-iommu: fix return value of iommu_unmap() API
intel-iommu: set iommu_superpage on VM domains to lowest common
denominator
intel-iommu: fix superpage support in pfn_to_dma_pte()
Antonio Ospite (1):
[media] videodev: fix a NULL pointer dereference in v4l2_device_release()
Daniel Hellstrom (1):
sparc32,leon: SRMMU MMU Table probe fix
Daniel Suchy (1):
ALSA: HDA: conexant support for Lenovo T520/W520
David S. Miller (1):
sparc: Avoid calling sigprocmask()
David Woodhouse (2):
intel-iommu: Workaround IOTLB hang on Ironlake GPU
intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.
Domenico Andreoli (1):
ARM: S3C24XX: Fix s3c24xx build errors if !CONFIG_PM
Eric Dumazet (3):
l2tp: fix a potential skb leak in l2tp_xmit_skb()
pptp: fix skb leak in pptp_xmit()
pptp: pptp_rcv_core() misses pskb_may_pull() call
Florian Westphal (1):
netfilter: nf_conntrack: fix event flooding in GRE protocol tracker
Gao feng (1):
netconsole: enable netconsole can make net_device refcnt incorrent
Gerrit Renker (1):
udplite: fast-path computation of checksum coverage
Hans Schillstrom (1):
IPVS netns shutdown/startup dead-lock
Hugh Dickins (1):
mm: fix race between mremap and removing migration entry
Jean Delvare (1):
hwmon: (w83627ehf) Fix negative 8-bit temperature values
Jiri Pirko (1):
tg3: negate USE_PHYLIB flag check
KOVACS Krisztian (1):
tproxy: copy transparent flag when creating a time wait
Kjetil Oftedal (1):
sparc: Add alignment flag to PCI expansion resources
Linus Torvalds (1):
Linux 3.1
Marek Szyprowski (1):
ARM: S5P: fix offset calculation on gpio-interrupt
Matt Fleming (1):
sparc: Use set_current_blocked()
Matthew Daley (3):
x25: Validate incoming call user data lengths
x25: Handle undersized/fragmented skbs
x25: Prevent skb overreads when checking call user data
Mitsuo Hayasaka (1):
bonding: use local function pointer of bond->recv_probe in
bond_handle_frame
Nick Bowler (1):
crypto: ghash - Avoid null pointer dereference if no key is set
Paul Moore (1):
bluetooth: Properly clone LSM attributes to newly created child
connections
Peter Zijlstra (1):
cputimer: Cure lock inversion
Phil Edworthy (1):
smsc911x: Add support for SMSC LAN89218
Roland Dreier (2):
intel-iommu: Fix AB-BA lockdep report
MAINTAINERS: Update VT-d entry for drivers/pci -> drivers/iommu move
Takashi Iwai (2):
ALSA: hda - Add position_fix quirk for Dell Inspiron 1010
x86: Fix S4 regression
Thadeu Lima de Souza Cascardo (1):
ehea: Change maintainer to me
Thomas Hellstrom (1):
ttm: Fix error-path using an uninitialized value
Yan, Zheng (1):
fib_rules: fix unresolved_rules counting
françois romieu (1):
r8169: fix driver shutdown WoL regression.
hayeswang (1):
r8169: fix wrong eee setting for rlt8111evl
stephen hemminger (1):
bridge: fix hang on removal of bridge via netlink
^ permalink raw reply
* Re: NFS4 BAD_STATEID loop (kernel 3.0)
From: Chuck Lever @ 2011-10-24 13:43 UTC (permalink / raw)
To: David Flynn; +Cc: linux-nfs
In-Reply-To: <20111024104042.GD32587@rd.bbc.co.uk>
On Oct 24, 2011, at 6:40 AM, David Flynn wrote:
> Dear All,
>
> On a system running kernel 3.0, mounting a Solaris NFS4 export, we
> observe a continuous 20Mbit/sec exchange between client and server that had
> been occurring for 10 days.
Can you tell us a little more about the server? Which release of Solaris? What hardware?
> From /proc/mounts:
> home:/home/ /home nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.29.190.21,minorversion=0,local_lock=none,addr=172.29.120.140 0 0
>
> Reconciling logs, we find that around the time the exchange started,
> the kernel reports a process having blocked:
>
> [787321.680029] INFO: task bash:17799 blocked for more than 120 seconds.
> [787321.680067] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [787321.680104] bash D 0000000000000002 0 17799 1 0x00000000
> [787321.680131] ffff880173ad9ca8 0000000000000086 ffff88017216b008 0000000000012a40
> [787321.680171] ffff880173ad9fd8 0000000000012a40 ffff880173ad8000 0000000000012a40
> [787321.680211] 0000000000012a40 0000000000012a40 ffff880173ad9fd8 0000000000012a40
> [787321.680251] Call Trace:
> [787321.680275] [<ffffffff8110e900>] ? __lock_page+0x70/0x70
> [787321.680299] [<ffffffff815fea2c>] io_schedule+0x8c/0xd0
> [787321.680321] [<ffffffff8110e90e>] sleep_on_page+0xe/0x20
> [787321.680344] [<ffffffff815ff2af>] __wait_on_bit+0x5f/0x90
> [787321.680366] [<ffffffff8110ead3>] wait_on_page_bit+0x73/0x80
> [787321.680390] [<ffffffff81085980>] ? autoremove_wake_function+0x40/0x40
> [787321.680416] [<ffffffff8111aeb5>] ? pagevec_lookup_tag+0x25/0x40
> [787321.680439] [<ffffffff8110ed06>] filemap_fdatawait_range+0xf6/0x1a0
> [787321.680483] [<ffffffffa022e740>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
> [787321.680507] [<ffffffff8111a3b1>] ? do_writepages+0x21/0x40
> [787321.680530] [<ffffffff8110ff8b>] ? __filemap_fdatawrite_range+0x5b/0x60
> [787321.680555] [<ffffffff81110000>] filemap_write_and_wait_range+0x70/0x80
> [787321.680580] [<ffffffff8119b45a>] vfs_fsync_range+0x5a/0x90
> [787321.680602] [<ffffffff8119b4fc>] vfs_fsync+0x1c/0x20
> [787321.680628] [<ffffffffa0222be4>] nfs_file_flush+0x54/0x80 [nfs]
> [787321.680653] [<ffffffff8116d66f>] filp_close+0x3f/0x90
> [787321.680675] [<ffffffff8116e097>] sys_close+0xb7/0x120
> [787321.680698] [<ffffffff816090c2>] system_call_fastpath+0x16/0x1b
>
> A network trace showed the following exchange below being continually
> repeated. Unfortunately this system too has since been rebooted.
>
> Any thoughts on the matter would be most welcome,
>
> Kind regards,
>
> ..david
>
>
> No. Time Source Destination Protocol Size Info
> 9880 11:40:12.833617 172.29.190.21 172.29.120.140 NFS 1122 V4 COMPOUND Call (Reply In 9881) <EMPTY> PUTFH;WRITE;GETATTR
>
> Frame 9880: 1122 bytes on wire (8976 bits), 1122 bytes captured (8976 bits)
> Arrival Time: Oct 17, 2011 11:40:12.833617000 BST
> Frame Length: 1122 bytes (8976 bits)
> Capture Length: 1122 bytes (8976 bits)
> Ethernet II, Src: ChelsioC_06:68:f9 (00:07:43:06:68:f9), Dst: All-HSRP-routers_be (00:00:0c:07:ac:be)
> Internet Protocol, Src: 172.29.190.21 (172.29.190.21), Dst: 172.29.120.140 (172.29.120.140)
> Transmission Control Protocol, Src Port: 816 (816), Dst Port: nfs (2049), Seq: 5199745, Ack: 275801, Len: 1056
> Remote Procedure Call, Type:Call XID:0x5daa6e93
> Network File System
> [Program Version: 4]
> [V4 Procedure: COMPOUND (1)]
> Tag: <EMPTY>
> length: 0
> contents: <EMPTY>
> minorversion: 0
> Operations (count: 3)
> Opcode: PUTFH (22)
> filehandle
> length: 36
> [hash (CRC-32): 0x6e4b15f3]
> decode type as: unknown
> filehandle: 7df3a75d5e1cd908000ab44c5b000000efc80200000a0300...
> Opcode: WRITE (38)
> stateid
> seqid: 0x00000000
> Data: 4e06f15b800f82e300000000
> offset: 11392
> stable: FILE_SYNC4 (2)
> Write length: 814
> Data: <DATA>
> length: 814
> contents: <DATA>
> fill bytes: opaque data
> Opcode: GETATTR (9)
> GETATTR4args
> attr_request
> bitmap[0] = 0x00000018
> [2 attributes requested]
> mand_attr: FATTR4_CHANGE (3)
> mand_attr: FATTR4_SIZE (4)
> bitmap[1] = 0x00300000
> [2 attributes requested]
> recc_attr: FATTR4_TIME_METADATA (52)
> recc_attr: FATTR4_TIME_MODIFY (53)
>
> No. Time Source Destination Protocol Size Info
> 9881 11:40:12.833956 172.29.120.140 172.29.190.21 NFS 122 V4 COMPOUND Reply (Call In 9880) <EMPTY> PUTFH;WRITE
>
> Frame 9881: 122 bytes on wire (976 bits), 122 bytes captured (976 bits)
> Arrival Time: Oct 17, 2011 11:40:12.833956000 BST
> [Time delta from previous captured frame: 0.000339000 seconds]
> Frame Length: 122 bytes (976 bits)
> Capture Length: 122 bytes (976 bits)
> Ethernet II, Src: Cisco_1e:f7:80 (00:13:5f:1e:f7:80), Dst: ChelsioC_06:68:f9 (00:07:43:06:68:f9)
> Internet Protocol, Src: 172.29.120.140 (172.29.120.140), Dst: 172.29.190.21 (172.29.190.21)
> Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 816 (816), Seq: 275801, Ack: 5200801, Len: 56
> Remote Procedure Call, Type:Reply XID:0x5daa6e93
> Network File System
> [Program Version: 4]
> [V4 Procedure: COMPOUND (1)]
> Status: NFS4ERR_BAD_STATEID (10025)
> Tag: <EMPTY>
> length: 0
> contents: <EMPTY>
> Operations (count: 2)
> Opcode: PUTFH (22)
> Status: NFS4_OK (0)
> Opcode: WRITE (38)
> Status: NFS4ERR_BAD_STATEID (10025)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: [PATCH v2] iio:staging: Add documentation for IIO_EVENT_CODE
From: Jonathan Cameron @ 2011-10-24 13:42 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers
In-Reply-To: <1319463592-19710-1-git-send-email-lars@metafoo.de>
On 10/24/11 14:39, Lars-Peter Clausen wrote:
> Document the different parameters of the IIO_EVENT_CODE macro and friends.
>
> While we are at it standardise the name of channel type parameter.
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
I'll pick this one up as well.
>
> ---
> Changes since v1:
> * Standardise channel type parameter name
> * Remove redundant elements from the channel number description of
> macros for non-differential channels.
> ---
> drivers/staging/iio/events.h | 37 +++++++++++++++++++++++++++++++++----
> 1 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/iio/events.h b/drivers/staging/iio/events.h
> index 389c781..7cf9306 100644
> --- a/drivers/staging/iio/events.h
> +++ b/drivers/staging/iio/events.h
> @@ -40,6 +40,18 @@ enum iio_event_direction {
> IIO_EV_DIR_FALLING,
> };
>
> +/**
> + * IIO_EVENT_CODE() - create event identifier
> + * @chan_type: Type of the channel. Should be one of enum iio_chan_type.
> + * @diff: Whether the event is for an differential channel or not.
> + * @modifier: Modifier for the channel. Should be one of enum iio_modifier.
> + * @direction: Direction of the event. Should be one of enum iio_event_direction.
> + * @type: Type of the event. Should be one enum iio_event_type.
> + * @chan: Channel number for non-differential channels.
> + * @chan1: First channel number for differential channels.
> + * @chan2: Second channel number for differential channels.
> + */
> +
> #define IIO_EVENT_CODE(chan_type, diff, modifier, direction, \
> type, chan, chan1, chan2) \
> (((u64)type << 56) | ((u64)diff << 55) | \
> @@ -51,12 +63,29 @@ enum iio_event_direction {
> #define IIO_EV_BIT(type, direction) \
> (1 << (type*IIO_EV_DIR_MAX + direction))
>
> -#define IIO_MOD_EVENT_CODE(channelclass, number, modifier, \
> +/**
> + * IIO_MOD_EVENT_CODE() - create event identifier for modified channels
> + * @chan_type: Type of the channel. Should be one of enum iio_chan_type.
> + * @number: Channel number.
> + * @modifier: Modifier for the channel. Should be one of enum iio_modifier.
> + * @type: Type of the event. Should be one enum iio_event_type.
> + * @direction: Direction of the event. Should be one of enum iio_event_direction.
> + */
> +
> +#define IIO_MOD_EVENT_CODE(chan_type, number, modifier, \
> type, direction) \
> - IIO_EVENT_CODE(channelclass, 0, modifier, direction, type, number, 0, 0)
> + IIO_EVENT_CODE(chan_type, 0, modifier, direction, type, number, 0, 0)
> +
> +/**
> + * IIO_UNMOD_EVENT_CODE() - create event identifier for unmodified channels
> + * @chan_type: Type of the channel. Should be one of enum iio_chan_type.
> + * @number: Channel number.
> + * @type: Type of the event. Should be one enum iio_event_type.
> + * @direction: Direction of the event. Should be one of enum iio_event_direction.
> + */
>
> -#define IIO_UNMOD_EVENT_CODE(channelclass, number, type, direction) \
> - IIO_EVENT_CODE(channelclass, 0, 0, direction, type, number, 0, 0)
> +#define IIO_UNMOD_EVENT_CODE(chan_type, number, type, direction) \
> + IIO_EVENT_CODE(chan_type, 0, 0, direction, type, number, 0, 0)
>
> #define IIO_EVENT_CODE_EXTRACT_TYPE(mask) ((mask >> 56) & 0xFF)
>
^ permalink raw reply
* Re: [BUG] Invalid file descriptor.
From: Daniel Wagner @ 2011-10-24 13:42 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Lucas De Marchi, linux-bluetooth
In-Reply-To: <CABBYNZL_FvdVDk8dH+uNxys=LRXLtWaBo0rKAfJ72dSfokkdgA@mail.gmail.com>
On 10/24/2011 03:36 PM, Luiz Augusto von Dentz wrote:
> Hi Daniel,
>
> On Mon, Oct 24, 2011 at 4:23 PM, Daniel Wagner<wagi@monom.org> wrote:
>>>
>>> What about the patch?
>>
>> Sure, I will do as soon I have fixed all outstanding ConnMan bugs I found
>> just recently. In other words don't expect very soon this patch :)
>
> Try with this:
>
> diff --git a/audio/manager.c b/audio/manager.c
> index 818451c..3103824 100644
> --- a/audio/manager.c
> +++ b/audio/manager.c
> @@ -607,7 +607,6 @@ static void hf_io_cb(GIOChannel *chan, gpointer data)
> if (perr< 0) {
> DBG("Authorization denied!");
> gateway_set_state(device, GATEWAY_STATE_DISCONNECTED);
> - goto drop;
> }
>
> return;
>
Yes, that fixes the error message.
Thanks,
daniel
^ permalink raw reply
* multipath-tools/path_priority pp_alua/rtpg.c p ...
From: bmarzins @ 2011-10-24 13:41 UTC (permalink / raw)
To: dm-cvs, dm-devel
CVSROOT: /cvs/dm
Module name: multipath-tools
Branch: RHEL5_FC6
Changes by: bmarzins@sourceware.org 2011-10-24 13:41:32
Modified files:
path_priority/pp_alua: rtpg.c
path_priority/pp_balance_units: pp_balance_units.c
Log message:
Fix for bz #737072. Shorten the timeout for the alua prio callout function
from 5 minutes to 1 minute.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/path_priority/pp_alua/rtpg.c.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.3.2.5&r2=1.3.2.6
http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/path_priority/pp_balance_units/pp_balance_units.c.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.6&r2=1.6.2.1
--- multipath-tools/path_priority/pp_alua/rtpg.c 2009/08/18 21:12:02 1.3.2.5
+++ multipath-tools/path_priority/pp_alua/rtpg.c 2011/10/24 13:41:32 1.3.2.6
@@ -29,7 +29,7 @@
#include "rtpg.h"
#define SENSE_BUFF_LEN 32
-#define DEF_TIMEOUT 300000
+#define DEF_TIMEOUT 60000
/*
* Macro used to print debug messaged.
--- multipath-tools/path_priority/pp_balance_units/pp_balance_units.c 2006/08/02 21:37:24 1.6
+++ multipath-tools/path_priority/pp_balance_units/pp_balance_units.c 2011/10/24 13:41:32 1.6.2.1
@@ -38,7 +38,7 @@
#define INQUIRY_CMDLEN 6
#define INQUIRY_CMD 0x12
#define SENSE_BUFF_LEN 32
-#define DEF_TIMEOUT 300000
+#define DEF_TIMEOUT 60000
#define RECOVERED_ERROR 0x01
#define MX_ALLOC_LEN 255
#define SCSI_CHECK_CONDITION 0x2
^ permalink raw reply
* Re: [CONSOLIDATED PULL 20/27] libtool: Upgrade from 2.4 -> 2.4.2
From: Richard Purdie @ 2011-10-24 13:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <d546fdc94cb627040c657facc23f00406967c838.1319394187.git.sgw@linux.intel.com>
On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> From: Khem Raj <raj.khem@gmail.com>
>
> Adjust prefix.patch and delete resolve-sysroot.patch
> since its already applied upstream
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> .../libtool/{libtool.inc => libtool-2.4.2.inc} | 26 +++++++++---
> meta/recipes-devtools/libtool/libtool-2.4.inc | 13 ------
> ...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} | 2 +-
> ...btool-native_2.4.bb => libtool-native_2.4.2.bb} | 2 +-
> ...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} | 2 +-
> meta/recipes-devtools/libtool/libtool/prefix.patch | 46 ++++++++++----------
> .../libtool/libtool/resolve-sysroot.patch | 42 ------------------
> .../libtool/{libtool_2.4.bb => libtool_2.4.2.bb} | 2 +-
> 8 files changed, 47 insertions(+), 88 deletions(-)
> rename meta/recipes-devtools/libtool/{libtool.inc => libtool-2.4.2.inc} (57%)
> delete mode 100644 meta/recipes-devtools/libtool/libtool-2.4.inc
> rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} (98%)
> rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb => libtool-native_2.4.2.bb} (96%)
> rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} (97%)
> delete mode 100644 meta/recipes-devtools/libtool/libtool/resolve-sysroot.patch
> rename meta/recipes-devtools/libtool/{libtool_2.4.bb => libtool_2.4.2.bb} (94%)
>
> diff --git a/meta/recipes-devtools/libtool/libtool.inc b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> similarity index 57%
> rename from meta/recipes-devtools/libtool/libtool.inc
> rename to meta/recipes-devtools/libtool/libtool-2.4.2.inc
> index ef9095b..1f652ef 100644
> --- a/meta/recipes-devtools/libtool/libtool.inc
> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> @@ -1,4 +1,3 @@
> -SUMMARY = "Generic library support script"
Why drop the SUMMARY field?
> DESCRIPTION = "This is GNU libtool, a generic library support script. \
> Libtool hides the complexity of generating special library types \
> (such as shared libraries) behind a consistent interface."
> @@ -8,21 +7,36 @@ LICENSE = "GPLv2 & LGPLv2.1"
> LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
> file://libltdl/COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
>
> +INC_PR = "r0"
> +
> SRC_URI = "${GNU_MIRROR}/libtool/libtool-${PV}.tar.gz \
> file://trailingslash.patch \
> file://prefix-manpage-fix.patch \
> file://rename-with-sysroot.patch \
> - file://resolve-sysroot.patch \
> file://use-sysroot-in-libpath.patch \
> file://fix-final-rpath.patch \
> file://avoid_absolute_paths_for_general_utils.patch \
> - file://fix-rpath.patch "
> + file://fix-rpath.patch \
> + "
> +
> +SRC_URI[md5sum] = "d2f3b7d4627e69e13514a40e72a24d50"
> +SRC_URI[sha256sum] = "b38de44862a987293cd3d8dfae1c409d514b6c4e794ebc93648febf9afc38918"
>
> do_compile_prepend () {
> - # Sometimes this file doesn't get rebuilt, force the issue
> - rm -f ${S}/libltdl/config/ltmain.sh
> - make libltdl/config/ltmain.sh
> + # Sometimes this file doesn't get rebuilt, force the issue
> + rm -f ${S}/libltdl/config/ltmain.sh
> + make libltdl/config/ltmain.sh
> }
Unintended indentation changes?
> inherit autotools
> EXTRA_AUTORECONF = "--exclude=libtoolize"
> +
> +DEPENDS = "libtool-native"
> +
> +PACKAGES =+ "libltdl libltdl-dev libltdl-dbg"
> +FILES_${PN} += "${datadir}/aclocal*"
> +FILES_libltdl = "${libdir}/libltdl.so.*"
> +FILES_libltdl-dev = "${libdir}/libltdl.* ${includedir}/ltdl.h"
> +FILES_libltdl-dbg = "${libdir}/.debug/"
> +
> +EXTRA_OECONF = "--with-sysroot"
> diff --git a/meta/recipes-devtools/libtool/libtool-2.4.inc b/meta/recipes-devtools/libtool/libtool-2.4.inc
> deleted file mode 100644
> index e3d17b7..0000000
> --- a/meta/recipes-devtools/libtool/libtool-2.4.inc
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -require libtool.inc
> -DEPENDS = "libtool-native"
> -
> -PACKAGES =+ "libltdl libltdl-dev libltdl-dbg"
> -FILES_${PN} += "${datadir}/aclocal*"
> -FILES_libltdl = "${libdir}/libltdl.so.*"
> -FILES_libltdl-dev = "${libdir}/libltdl.* ${includedir}/ltdl.h"
> -FILES_libltdl-dbg = "${libdir}/.debug/"
> -
> -SRC_URI[md5sum] = "b32b04148ecdd7344abc6fe8bd1bb021"
> -SRC_URI[sha256sum] = "13df57ab63a94e196c5d6e95d64e53262834fe780d5e82c28f177f9f71ddf62e"
> -
> -EXTRA_OECONF = "--with-sysroot"
> \ No newline at end of file
> diff --git a/meta/recipes-devtools/libtool/libtool-cross_2.4.bb b/meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb
> similarity index 98%
> rename from meta/recipes-devtools/libtool/libtool-cross_2.4.bb
> rename to meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb
> index 6d512b1..b7fe851 100644
> --- a/meta/recipes-devtools/libtool/libtool-cross_2.4.bb
> +++ b/meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb
> @@ -1,6 +1,6 @@
> require libtool-${PV}.inc
>
> -PR = "r4"
> +PR = "${INC_PR}.0"
> PACKAGES = ""
> SRC_URI += "file://prefix.patch"
No mention of conversion to INC_PR in the commit message. I'm not sure
this is worth doing at this point considering the need to find a better
way to automate PR bumping.
Cheers,
Richard
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024130636.GB26033@opensource.wolfsonmicro.com>
On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
>
> > If we can attach the device_node of 'regulators' node to dev->of_node
> > when calling regulator_register(regulator_desc, dev, ...) from
> > regulator driver, the regulator core will be able to find all nodes under
> > 'regulators' using for_each_child_of_node(dev->of_node, child).
>
> Please provide concrete examples of the bindings you're talking about,
> the really important thing here is how sane the bindings look and I've
> really got no idea what any of what you're talking about will look like
> or if they make sense.
>
The only thing different from what I attached last time is the
compatible string added to 'regulators' node.
ecspi at 70010000 { /* ECSPI1 */
fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
<&gpio3 25 0>; /* GPIO4_25 */
status = "okay";
pmic: mc13892 at 0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mc13892";
spi-max-frequency = <6000000>;
reg = <0>;
mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
regulators {
compatible = "fsl,mc13892-regulator";
sw1reg: mc13892_sw1 {
regulator-min-uV = <600000>;
regulator-max-uV = <1375000>;
regulator-change-voltage;
regulator-boot-on;
regulator-always-on;
};
sw2reg: mc13892_sw2 {
regulator-min-uV = <900000>;
regulator-max-uV = <1850000>;
regulator-change-voltage;
regulator-boot-on;
regulator-always-on;
};
......
};
leds {
......
};
buttons {
......
};
};
flash: at45db321d at 1 {
......
};
};
> > hesitate to hack this into mfd_add_devices(), so I would like to add
> > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > find the node using of_find_compatible_node(dev->parent, NULL,
> > "fsl,mc13892-regulators").
>
> It's not immediately obvious to me that having a binding for the
> regulators separately makes sense, it's not a usefully distinct device.
>
Fair point. Actually, I also hate to have the finding of node
'regulators' plugged into regulator driver. What about following
change to address Grant's concern on global device tree search?
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 8fe132d..29dcf90 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
/* find device_node and attach it */
- rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
+ rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
+ regulator_desc->name);
/* register with sysfs */
rdev->dev.class = ®ulator_class;
--
Regards,
Shawn
^ permalink raw reply related
* Re: xfs_symlink problem? 3.1 after rc10
From: Arkadiusz Miśkiewicz @ 2011-10-24 13:40 UTC (permalink / raw)
To: Carlos Maiolino; +Cc: xfs
In-Reply-To: <20111024122729.GA4441@andromeda.usersys.redhat.com>
On Monday 24 of October 2011, Carlos Maiolino wrote:
> > My 3.1 (after) rc10 crashed (there was no xfs changes after it afaik).
> >
> > Could anyone verify that this isn't some nasty xfs problem since it's
> > close to final 3.1? Happened only once.
> >
> > http://ixion.pld-linux.org/~arekm/IMG_6019.JPG
> >
> > No quota was used, xfs on top of luks on top of ssd drive.
>
> It looks to be caused by a general protection fault, and giving the place
It happened again:
http://ixion.pld-linux.org/~arekm/100_5434.JPG
http://ixion.pld-linux.org/~arekm/100_5433.JPG
> where this crashed I would say this sounds like the bug I've fixed some
> days ago related with the size of the symlinks.
> I can be wrong though, and this is related with another problem.
The weird thing is that I never ever hit this before with pre 3.1rc10 git
kernels. Was your bugfix a fix for new issue that was introduced in 3.1 cycle
or for something old?
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [BUG] Invalid file descriptor.
From: Lucas De Marchi @ 2011-10-24 13:39 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Daniel Wagner, linux-bluetooth
In-Reply-To: <CABBYNZL_FvdVDk8dH+uNxys=LRXLtWaBo0rKAfJ72dSfokkdgA@mail.gmail.com>
Hi Luiz,
On Mon, Oct 24, 2011 at 11:36 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Daniel,
>
> On Mon, Oct 24, 2011 at 4:23 PM, Daniel Wagner <wagi@monom.org> wrote:
>>>
>>> What about the patch?
>>
>> Sure, I will do as soon I have fixed all outstanding ConnMan bugs I found
>> just recently. In other words don't expect very soon this patch :)
>
> Try with this:
>
> diff --git a/audio/manager.c b/audio/manager.c
> index 818451c..3103824 100644
> --- a/audio/manager.c
> +++ b/audio/manager.c
> @@ -607,7 +607,6 @@ static void hf_io_cb(GIOChannel *chan, gpointer data)
> if (perr < 0) {
> DBG("Authorization denied!");
> gateway_set_state(device, GATEWAY_STATE_DISCONNECTED);
> - goto drop;
> }
It seems correct. As far as I remember there are similar problems in
other profiles like input /manager.c.
Lucas De Marchi
^ permalink raw reply
* multipath-tools/libmultipath callout.c
From: bmarzins @ 2011-10-24 13:39 UTC (permalink / raw)
To: dm-cvs, dm-devel
CVSROOT: /cvs/dm
Module name: multipath-tools
Branch: RHEL5_FC6
Changes by: bmarzins@sourceware.org 2011-10-24 13:39:56
Modified files:
libmultipath : callout.c
Log message:
Fix for bz #729478. Add a new callout format parameter %c, that converts the "!"
in cciss device names to "/".
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/libmultipath/callout.c.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.5.2.2&r2=1.5.2.3
--- multipath-tools/libmultipath/callout.c 2009/05/15 21:01:26 1.5.2.2
+++ multipath-tools/libmultipath/callout.c 2011/10/24 13:39:56 1.5.2.3
@@ -133,6 +133,19 @@
return retval;
}
+void
+convert_cciss(char *dest, char *src)
+{
+ char *ptr;
+
+ strcpy(dest, src);
+ if (strncmp(src, "cciss", 5))
+ return;
+ ptr = strrchr(dest, '!');
+ if (ptr)
+ *ptr = '/';
+}
+
extern int
apply_format (char * string, char * cmd, struct path * pp)
{
@@ -141,6 +154,7 @@
char * p;
int len;
int myfree;
+ char converted_dev[FILE_NAME_SIZE];
if (!string)
return 1;
@@ -179,6 +193,17 @@
snprintf(p, len, "%s", pp->dev);
p += len - 1;
break;
+ case 'c':
+ convert_cciss(converted_dev, pp->dev);
+ len = strlen(converted_dev) + 1;
+ myfree -= len;
+
+ if (myfree < 2)
+ return 1;
+
+ snprintf(p, len, "%s", converted_dev);
+ p += len - 1;
+ break;
case 'd':
len = strlen(pp->dev_t) + 1;
myfree -= len;
^ permalink raw reply
* [PATCH v2] iio:staging: Add documentation for IIO_EVENT_CODE
From: Lars-Peter Clausen @ 2011-10-24 13:39 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers,
Lars-Peter Clausen
Document the different parameters of the IIO_EVENT_CODE macro and friends.
While we are at it standardise the name of channel type parameter.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
Changes since v1:
* Standardise channel type parameter name
* Remove redundant elements from the channel number description of
macros for non-differential channels.
---
drivers/staging/iio/events.h | 37 +++++++++++++++++++++++++++++++++----
1 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/iio/events.h b/drivers/staging/iio/events.h
index 389c781..7cf9306 100644
--- a/drivers/staging/iio/events.h
+++ b/drivers/staging/iio/events.h
@@ -40,6 +40,18 @@ enum iio_event_direction {
IIO_EV_DIR_FALLING,
};
+/**
+ * IIO_EVENT_CODE() - create event identifier
+ * @chan_type: Type of the channel. Should be one of enum iio_chan_type.
+ * @diff: Whether the event is for an differential channel or not.
+ * @modifier: Modifier for the channel. Should be one of enum iio_modifier.
+ * @direction: Direction of the event. Should be one of enum iio_event_direction.
+ * @type: Type of the event. Should be one enum iio_event_type.
+ * @chan: Channel number for non-differential channels.
+ * @chan1: First channel number for differential channels.
+ * @chan2: Second channel number for differential channels.
+ */
+
#define IIO_EVENT_CODE(chan_type, diff, modifier, direction, \
type, chan, chan1, chan2) \
(((u64)type << 56) | ((u64)diff << 55) | \
@@ -51,12 +63,29 @@ enum iio_event_direction {
#define IIO_EV_BIT(type, direction) \
(1 << (type*IIO_EV_DIR_MAX + direction))
-#define IIO_MOD_EVENT_CODE(channelclass, number, modifier, \
+/**
+ * IIO_MOD_EVENT_CODE() - create event identifier for modified channels
+ * @chan_type: Type of the channel. Should be one of enum iio_chan_type.
+ * @number: Channel number.
+ * @modifier: Modifier for the channel. Should be one of enum iio_modifier.
+ * @type: Type of the event. Should be one enum iio_event_type.
+ * @direction: Direction of the event. Should be one of enum iio_event_direction.
+ */
+
+#define IIO_MOD_EVENT_CODE(chan_type, number, modifier, \
type, direction) \
- IIO_EVENT_CODE(channelclass, 0, modifier, direction, type, number, 0, 0)
+ IIO_EVENT_CODE(chan_type, 0, modifier, direction, type, number, 0, 0)
+
+/**
+ * IIO_UNMOD_EVENT_CODE() - create event identifier for unmodified channels
+ * @chan_type: Type of the channel. Should be one of enum iio_chan_type.
+ * @number: Channel number.
+ * @type: Type of the event. Should be one enum iio_event_type.
+ * @direction: Direction of the event. Should be one of enum iio_event_direction.
+ */
-#define IIO_UNMOD_EVENT_CODE(channelclass, number, type, direction) \
- IIO_EVENT_CODE(channelclass, 0, 0, direction, type, number, 0, 0)
+#define IIO_UNMOD_EVENT_CODE(chan_type, number, type, direction) \
+ IIO_EVENT_CODE(chan_type, 0, 0, direction, type, number, 0, 0)
#define IIO_EVENT_CODE_EXTRACT_TYPE(mask) ((mask >> 56) & 0xFF)
--
1.7.7
^ permalink raw reply related
* [U-Boot] [PATCH 3/3] nds32: asm/io.h: add __iormb and __iowmb support
From: Marek Vasut @ 2011-10-24 13:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319449593-2427-3-git-send-email-macpaul@andestech.com>
> This patch add required __iormb and __iowmb to io.h.
> This also fix some misbehavior to periphal drivers.
>
> This io.h has been fixed with referencing arm/include/asm/io.h.
>
> Signed-off-by: Macpaul Lin <macpaul@andestech.com>
Hi,
can you possibly implement those as inline functions ? It'd be also great if you
could convert the other macros to inline functions.
Thanks!
^ permalink raw reply
* Re: [CONSOLIDATED PULL 26/27] abiword: convert to svn
From: Saul Wold @ 2011-10-24 13:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi
In-Reply-To: <884DC19F-D167-41B9-B5E6-62A959BE99CB@dominion.thruhere.net>
On 10/24/2011 03:18 PM, Koen Kooi wrote:
>
> Op 24 okt. 2011, om 15:14 heeft Richard Purdie het volgende geschreven:
>
>> On Sun, 2011-10-23 at 11:27 -0700, Saul Wold wrote:
>>> Signed-off-by: Saul Wold<sgw@linux.intel.com>
>>> ---
>>> meta-demoapps/recipes-gnome/abiword/abiword.inc | 4 ++--
>>> meta-demoapps/recipes-gnome/abiword/abiword_cvs.bb | 10 ----------
>>> meta-demoapps/recipes-gnome/abiword/abiword_svn.bb | 10 ++++++++++
>>> 3 files changed, 12 insertions(+), 12 deletions(-)
>>> delete mode 100644 meta-demoapps/recipes-gnome/abiword/abiword_cvs.bb
>>> create mode 100644 meta-demoapps/recipes-gnome/abiword/abiword_svn.bb
>>>
>>> diff --git a/meta-demoapps/recipes-gnome/abiword/abiword.inc b/meta-demoapps/recipes-gnome/abiword/abiword.inc
>>> index b1b0f67..2b34a7a 100644
>>> --- a/meta-demoapps/recipes-gnome/abiword/abiword.inc
>>> +++ b/meta-demoapps/recipes-gnome/abiword/abiword.inc
>>> @@ -13,8 +13,8 @@ RRECOMMENDS_${PN} = "glibc-gconv-ibm850 glibc-gconv-cp1252 \
>>> RELURI = "http://www.abiword.org/downloads/abiword/${PV}/source/abiword-${PV}.tar.gz"
>>> RELSRC = "${WORKDIR}/abiword-${PV}/abi"
>>>
>>> -CVSURI = "cvs://anoncvs:anoncvs@anoncvs.abisource.com/cvsroot;module=abi"
>>> -CVSSRC = "${WORKDIR}/abi"
>>> +SVNURI = "cvs://svn.abisource.com/abiword/trunk;module=abiword;proto=http"
>>> +SVNSRC = "${WORKDIR}/abi"
>>>
>> Er, its still using cvs:// ?!
>
> The whole abiword section is outdated, it has 2.5.2 which was released on 21-Aug-2007, latest is 2.8.6 released on 13-Jun-2010. I have an uncommited update in meta-oe to update abiword to 2.8.6, need to clean that up.
>
I will defer my patch for what Koen has pending then for meta-oe,
probably the better place for it anyways, it should be removed from the
meta-demoapps.
Sau!
> regards,
>
> Koen
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* multipath-tools/kpartx gpt.c
From: bmarzins @ 2011-10-24 13:37 UTC (permalink / raw)
To: dm-cvs, dm-devel
CVSROOT: /cvs/dm
Module name: multipath-tools
Branch: RHEL5_FC6
Changes by: bmarzins@sourceware.org 2011-10-24 13:37:18
Modified files:
kpartx : gpt.c
Log message:
Fix for bz #719575. Validate size of GPT partitions.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/kpartx/gpt.c.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.3&r2=1.3.2.1
--- multipath-tools/kpartx/gpt.c 2006/10/13 23:28:47 1.3
+++ multipath-tools/kpartx/gpt.c 2011/10/24 13:37:18 1.3.2.1
@@ -358,6 +358,15 @@
return 0;
}
+ /* Check that sizeof_partition_entry has the correct value */
+ if (__le32_to_cpu((*gpt)->sizeof_partition_entry) != sizeof(gpt_entry)) {
+ // printf("GUID partition entry size check failed.\n");
+ free(*gpt);
+ *gpt = NULL;
+ return 0;
+ }
+
+
if (!(*ptes = alloc_read_gpt_entries(fd, *gpt))) {
free(*gpt);
*gpt = NULL;
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 13:47 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Grant Likely, broonie, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <4EA52C56.3080908@ti.com>
On Mon, Oct 24, 2011 at 02:43:58PM +0530, Rajendra Nayak wrote:
> Case 2:
> One device for all regulators:
>
> DT nodes look something like this
>
> regulators {
> reg1: reg@1 {
> ...
> ...
> };
>
> reg2: reg@2 {
> ...
> ...
> };
> };
>
> The regulator driver probes only one device and the dev->of_node
> points to the "regulators" node above.
The mc13892 example I put in the reply to Grant demonstrates that
for some case, dev->of_node is NULL (devices are created by mfd core).
> The regulator driver then based on compatible property extracts
> and registers all the child nodes of "regulators" (for ex: reg1, reg2
> above) with each call to regulator_register and passes the child nodes
> as of_node to be associated with the regulator device.
>
I still think the discovery of all the child nodes of "regulators" does
not necessarily need to be done in regulator driver. Instead, it can
be done in regulator core.
--
Regards,
Shawn
^ permalink raw reply
* [Buildroot] [git commit] orc: add host support
From: Peter Korsgaard @ 2011-10-24 13:36 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=5889480ec61ecba3e6abe0d9cb70c1b7507a6ee5
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Some packages use orc to generate C code at build time using orcc, so we
need to build orc for the host as well.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/orc/orc.mk | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/package/orc/orc.mk b/package/orc/orc.mk
index d4ff3e2..97c80f2 100644
--- a/package/orc/orc.mk
+++ b/package/orc/orc.mk
@@ -6,6 +6,7 @@
ORC_VERSION = 0.4.14
ORC_SITE = http://code.entropywave.com/download/orc/
ORC_INSTALL_STAGING = YES
+ORC_DEPENDENCIES = host-orc
define ORC_REMOVE_BUGREPORT
rm -f $(TARGET_DIR)/usr/bin/orc-bugreport
@@ -22,3 +23,4 @@ ORC_POST_INSTALL_TARGET_HOOKS += ORC_REMOVE_DEVFILES
endif
$(eval $(call AUTOTARGETS))
+$(eval $(call AUTOTARGETS,host))
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.