* LVM2 WHATS_NEW
From: jbrassow @ 2011-12-01 0:05 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: jbrassow at sourceware.org 2011-12-01 00:05:40
Modified files:
. : WHATS_NEW
Log message:
WHATS_NEW for previous commit.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.2199&r2=1.2200
--- LVM2/WHATS_NEW 2011/11/30 02:02:10 1.2199
+++ LVM2/WHATS_NEW 2011/12/01 00:05:40 1.2200
@@ -1,5 +1,6 @@
Version 2.02.89 -
==================================
+ Do not allow users to change permissions on RAID sub-LVs
Support the ability to replace specific devices in a RAID array via lvconvert.
Add activation/use_linear_target enabled by default.
Use gcc warning options only with .c to .o compilation.
^ permalink raw reply
* LVM2/tools lvchange.c
From: jbrassow @ 2011-12-01 0:04 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: jbrassow at sourceware.org 2011-12-01 00:04:21
Modified files:
tools : lvchange.c
Log message:
Do not allow users to change permissions on RAID sub-LVs.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/tools/lvchange.c.diff?cvsroot=lvm2&r1=1.136&r2=1.137
--- LVM2/tools/lvchange.c 2011/11/18 19:22:49 1.136
+++ LVM2/tools/lvchange.c 2011/12/01 00:04:21 1.137
@@ -43,6 +43,14 @@
return 0;
}
+ /* Not allowed to change permissions on RAID sub-LVs directly */
+ if ((lv->status & RAID_META) || (lv->status & RAID_IMAGE)) {
+ log_error("Cannot change permissions of RAID %s \"%s\"",
+ (lv->status & RAID_IMAGE) ? "image" :
+ "metadata area", lv->name);
+ return 0;
+ }
+
if (lv_access & LVM_WRITE) {
lv->status |= LVM_WRITE;
log_verbose("Setting logical volume \"%s\" read/write",
^ permalink raw reply
* [U-Boot] [PATCH V3 1/5] i.mx: introduce the armv7/imx-common folder
From: Fabio Estevam @ 2011-12-01 0:04 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1322216285-23479-2-git-send-email-jason.hui@linaro.org>
On Fri, Nov 25, 2011 at 8:18 AM, Jason Liu <jason.hui@linaro.org> wrote:
> +static char *get_reset_cause(void)
> +{
> + ? ? ? u32 cause;
> + ? ? ? struct src *src_regs = (struct src *)SRC_BASE_ADDR;
> +
> + ? ? ? cause = readl(&src_regs->srsr);
> + ? ? ? writel(cause, &src_regs->srsr);
Isn?t this writel unneeded?
Regards,
Fabio Estevam
^ permalink raw reply
* Re: [dm-devel] [PATCH] deadlock with suspend and quotas
From: Jan Kara @ 2011-12-01 0:03 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Alasdair G Kergon, Jan Kara, esandeen, linux-kernel, dm-devel,
linux-fsdevel, Christopher Chaltain, Valerie Aurora
In-Reply-To: <Pine.LNX.4.64.1111301136360.5759@hs20-bc2-1.build.redhat.com>
On Wed 30-11-11 11:53:40, Mikulas Patocka wrote:
>
>
> On Wed, 30 Nov 2011, Alasdair G Kergon wrote:
>
> > On Tue, Nov 29, 2011 at 11:19:01AM +0100, Jan Kara wrote:
> > > So I believe the consensus was that we should not block sync or flusher
>
> Well, I think that not blocking sync actually doesn't help at all.
>
> Suppose at first that you have a perfectly-barriered filesystem --- that
> is filesystem, that contains barriers around all code paths that could
> possibly create dirty data. In this case it is impossible to have dirty
> data while the filesystem is suspended. --- In this case you can call
> sync on suspened filesystem as much as you like, sync never finds ady
> dirty data, consequently it never tries to write anything and it can't
> deadlock. So skipping sync has no effect.
>
> Suppose as a second case that you have imperfectly-barriered filesystem
> --- that means there exists a code path that creates dirty data while the
> filesystem is suspended. In this case if you skip sync, you are violating
> sync semantics, because the application can create dirty data while
> suspended, call sync while still suspended and assume that the dirty data
> was written.
Except that currently we are in situation c) with e.g. ext4 and xfs. We
have perfectly-barriered filesystem *but* there are dirty bits set in this
filesystem although we are certain there are no dirty data. This
inconsistency between dirty bits and fact whether a page contains dirty
data is due to way how page faults are handled. I've already tried to
explain this in this thread in https://lkml.org/lkml/2011/11/29/109 but
apparently I failed. I can try to explain it once more but in fact I don't
think this technical detail makes a difference in this discussion. So in our
situation c) skipping sync makes difference and does not break guarantees
sync should have.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
* Re: Resize command syntax wrong?
From: Phillip Susi @ 2011-12-01 0:01 UTC (permalink / raw)
To: helmut; +Cc: Helmut Hullen, linux-btrfs
In-Reply-To: <ByrPr1UD1uB@helmut.hullen.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/30/2011 01:59 PM, Helmut Hullen wrote:
> Hallo, Phillip,
>
> Du meintest am 30.11.11:
>
>> Currently the resize command is under filesystem, and takes a path to
>> the mounted filesystem. This seems wrong to me. Shouldn't it be
>> under device, and take a path to a device to resize?
>
> No - it's a filesystem operation.
No, it isn't. You can see the function that implements the resize in the code operates on a specific disk, and the ioctl does take as an argument which disk you are trying to resize. Logically you are adjusting the space that is available on a particular device, which only indirectly affects the filesystem. In other words, the only reason that the size of the filesystem changes is because you have changed the size of a device. In fact, internally device removal is implemented by first resizing the device to 0.
It appears that the utility just passes devid=1 to the kernel when you don't specify it. It should take a dev node as an argument and translate it to the devid for you.
> p.e.
> You start with a system of 2 disks. They get filled nearly
> simultaneously.
> Then you add a 3rd disk (which is empty at that time). Now it's a good
> idea to run "balance" for equalizing the filling.
balance != resize
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7Ww+gACgkQJ4UciIs+XuJjlwCgr2u3zvuhYWC0vv9ObdhBS41Z
M3MAn09xhEopzuIJdN4QP+8bQvYzhvo1
=Qck2
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: 3.2.0-rc3-next-20111128 lockdep splat during boot..
From: Valdis.Kletnieks @ 2011-11-30 23:59 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: James E.J. Bottomley, Len Brown, Pavel Machek, linux-kernel,
linux-scsi, linux-acpi, linux-pm
In-Reply-To: <201112010017.19156.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
On Thu, 01 Dec 2011 00:17:18 +0100, "Rafael J. Wysocki" said:
> On Wednesday, November 30, 2011, Valdis.Kletnieks@vt.edu wrote:
> > Seen this twice out of two boots while initrd was waiting for me to
> > enter the passphrase for encrypted LVM. No idea *who* to toss this
> > one at - got ACPI, PM, SCSI and vtconsole all listed in tracebacks, so
> > I'm tossing this at everybody and hope it sticks. ;)
>
> This was caused by one of my patches in linux-next and was linux-next-only.
>
> I've already replaced the offending patch with a new version.
OK, thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH][oe-core 1/3] sysstat: don't run populate-volatile.sh update in do_rootfs or without populate-volatile.sh
From: Martin Jansa @ 2011-11-30 23:51 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1322696033.17484.84.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
On Wed, Nov 30, 2011 at 11:33:53PM +0000, Richard Purdie wrote:
> On Wed, 2011-11-30 at 23:56 +0100, Martin Jansa wrote:
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> > meta/recipes-extended/sysstat/sysstat.inc | 6 +++++-
> > meta/recipes-extended/sysstat/sysstat_10.0.2.bb | 2 +-
> > 2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-extended/sysstat/sysstat.inc b/meta/recipes-extended/sysstat/sysstat.inc
> > index 2936f96..5e0f7af 100644
> > --- a/meta/recipes-extended/sysstat/sysstat.inc
> > +++ b/meta/recipes-extended/sysstat/sysstat.inc
> > @@ -22,7 +22,11 @@ do_install() {
> > }
> >
> > pkg_postinst_${PN} () {
> > - /etc/init.d/populate-volatile.sh update
> > + if [ "x$D" != "x" ]; then
>
> Is that really what you mean?
Ah, sorry, you're right. Fixed in branch and sent here.
>
> > + if [ -e /etc/init.d/populate-volatile.sh ]; then
> > + /etc/init.d/populate-volatile.sh update
> > + fi
> > + fi
> > }
> >
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: 3.1-rc10 oops in nameidata_to_filp
From: Andrew Morton @ 2011-11-30 23:57 UTC (permalink / raw)
To: Al Viro; +Cc: George Spelvin, jack, linux-fsdevel, linux-kernel
In-Reply-To: <20111124175002.GM2203@ZenIV.linux.org.uk>
(sorry for the delay)
On Thu, 24 Nov 2011 17:50:03 +0000
Al Viro <viro@ZenIV.linux.org.uk> wrote:
> On Thu, Nov 24, 2011 at 05:38:29PM +0000, Al Viro wrote:
> > Said that, I'm not buying the theory of open assigning to ->f_mapping and
> > screwing it up; all such assignments end up with ->i_mapping of *some*
> > inode, as far as I can see from cursory grep over the tree. Just in case:
> > do you have CONFIG_FS_POSIX_ACL set?
>
> BTW, why are we going through that dance with ->host->i_mapping anyway?
> It had been introduced by commit by akpm back in 2004 and from my reading
> of the commit message it was an overkill even back then. Basically,
> that call got moved to the point past the call of ->open() (good, ->f_mapping
> could've been changed by it) *and* converted from ->f_mapping to
> ->f_mapping->host->i_mapping, which is useless. Definitely so in the
> case mentioned in that commit (blkdev_open() sets ->f_mapping
> bdev->bd_inode->i_mapping and that thing will have ->host pointing
> back to bdev->bd_inode). Commit was in BK, its copy in historical tree
> is commit 1c211088833a27daa4512348bcae9890e8cf92d4
> Author: Andrew Morton <akpm@osdl.org>
> Date: Wed May 26 17:35:42 2004 -0700
>
> [PATCH] Fix the setting of file->f_ra on block-special files
>
> We need to set file->f_ra _after_ calling blkdev_open(), when inode->i_mapping
> points at the right thing. And we need to get it from
> inode->i_mapping->host->i_mapping too, which represents the underlying device.
>
> Also, don't test for null file->f_mapping in the O_DIRECT checks.
>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
>
> and the only difference wrt setting ->f_mapping on bdev open back then
> is that it used to be done in do_open() instead of blkdev_open() itself.
> So I don't understand what that part of changes had been for... Andrew?
Beats me, sorry. Here's the thread:
http://www.gossamer-threads.com/lists/linux/kernel/443511?do=post_view_flat#443511
^ permalink raw reply
* [PATCH] sysstat: don't run populate-volatile.sh update in do_rootfs or without populate-volatile.sh
From: Martin Jansa @ 2011-11-30 23:50 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1322696033.17484.84.camel@ted>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
meta/recipes-extended/sysstat/sysstat.inc | 7 ++++++-
meta/recipes-extended/sysstat/sysstat_10.0.2.bb | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/sysstat/sysstat.inc b/meta/recipes-extended/sysstat/sysstat.inc
index 2936f96..ca40ab5 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -22,7 +22,12 @@ do_install() {
}
pkg_postinst_${PN} () {
- /etc/init.d/populate-volatile.sh update
+ if [ -n "$D" ]; then
+ exit 1
+ fi
+ if [ -e /etc/init.d/populate-volatile.sh ]; then
+ /etc/init.d/populate-volatile.sh update
+ fi
}
diff --git a/meta/recipes-extended/sysstat/sysstat_10.0.2.bb b/meta/recipes-extended/sysstat/sysstat_10.0.2.bb
index bd559d8..7b57bc8 100644
--- a/meta/recipes-extended/sysstat/sysstat_10.0.2.bb
+++ b/meta/recipes-extended/sysstat/sysstat_10.0.2.bb
@@ -2,7 +2,7 @@ require sysstat.inc
LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b"
-PR = "r0"
+PR = "r1"
--
1.7.8.rc4
^ permalink raw reply related
* Re: [PATCH] firmware: google: fix gsmi.c build warning
From: Mike Waychison @ 2011-11-30 23:56 UTC (permalink / raw)
To: Maxin B. John; +Cc: linux-kernel, gregkh, paul.gortmaker, dlaurie, adurbin
In-Reply-To: <20111130233733.GA11577@maxin>
On Wed, Nov 30, 2011 at 3:37 PM, Maxin B. John <maxin.john@gmail.com> wrote:
> Use min_t() macro instead of min() to fix a build warning:
>
Looks good. Greg, could you please pull this into your drivers tree?
> CC drivers/firmware/google/gsmi.o
> drivers/firmware/google/gsmi.c: In function ‘gsmi_get_variable’:
> drivers/firmware/google/gsmi.c:348: warning: comparison of distinct
> pointer types lacks a cast
>
> Signed-off-by: Maxin B. John <maxin.john@gmail.com>
> ---
> diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
> index c4e7c59..91ddf0f 100644
> --- a/drivers/firmware/google/gsmi.c
> +++ b/drivers/firmware/google/gsmi.c
> @@ -345,7 +345,8 @@ static efi_status_t gsmi_get_variable(efi_char16_t *name,
> memcpy(¶m, gsmi_dev.param_buf->start, sizeof(param));
>
> /* The size reported is the min of all of our buffers */
> - *data_size = min(*data_size, gsmi_dev.data_buf->length);
> + *data_size = min_t(unsigned long, *data_size,
> + gsmi_dev.data_buf->length);
> *data_size = min_t(unsigned long, *data_size, param.data_len);
>
> /* Copy data back to return buffer. */
^ permalink raw reply
* [PATCH] ARM: kprobes: Change testcase with unpredictable STRD instruction
From: Russell King - ARM Linux @ 2011-11-30 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1322395885.2408.1.camel@computer2>
On Sun, Nov 27, 2011 at 12:11:25PM +0000, Tixy wrote:
> There is a kprobes testcase for the instruction "strd r2, [r3], r4".
> This has unpredictable behaviour as it uses r3 for register writeback
> addressing and also stores it to memory.
>
> On a cortex A9, this testcase would fail because the instruction writes
> the updated value of r3 to memory, whereas the kprobes emulation code
> writes the original value.
>
> Fix this by changing testcase to used r5 instead of r3.
Is this a -stable candidate?
^ permalink raw reply
* Re: [PATCH 4/4] xfs: fix the logspace waiting algorithm
From: Ben Myers @ 2011-11-30 23:56 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20111128081925.981681380@bombadil.infradead.org>
Christoph,
I feel that the ordering of the accesses to l_grant_head and the writeq
list may be important in the lockless path, and notice that they used to
be in opposite order. It could use a comment explaining why (if) it is
ok.
-Ben
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [PATCH] ARM: kprobes: Restrict probing SWP instructions to ARMv5 and below
From: Russell King - ARM Linux @ 2011-11-30 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1322396080.2408.5.camel@computer2>
On Sun, Nov 27, 2011 at 12:14:40PM +0000, Tixy wrote:
> The SWP instruction is deprecated on ARMv6 and with ARMv7 it will be
> UNDEFINED when CONFIG_SWP_EMULATE is selected. In this case, probing a
> SWP instruction will cause an oops when the kprobes emulation code
> executes an undefined instruction.
>
> As the SWP instruction should be rare or non-existent in kernels for
> ARMv6 and later, we can simply avoid these problems by not allowing
> probing of these.
Is this something for -stable stuff?
^ permalink raw reply
* Re: [PATCH v2] nfsd41: check reclaim for open claim previous at nfsd4_open
From: J. Bruce Fields @ 2011-11-30 23:55 UTC (permalink / raw)
To: Mi Jinlong; +Cc: NFS
In-Reply-To: <4ECC5F08.4070900@cn.fujitsu.com>
On Wed, Nov 23, 2011 at 10:48:40AM +0800, Mi Jinlong wrote:
> Opening file with filehandle, check reclaim is not needed.
> So, let open reclaim check at nfsd4_open.
Thanks! Applying for 3.3.--b.
>
> Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
> ---
> fs/nfsd/nfs4proc.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> index fa38336..9415bc4 100644
> --- a/fs/nfsd/nfs4proc.c
> +++ b/fs/nfsd/nfs4proc.c
> @@ -266,10 +266,6 @@ do_open_fhandle(struct svc_rqst *rqstp, struct svc_fh *current_fh, struct nfsd4_
> {
> __be32 status;
>
> - /* Only reclaims from previously confirmed clients are valid */
> - if ((status = nfs4_check_open_reclaim(&open->op_clientid)))
> - return status;
> -
> /* We don't know the target directory, and therefore can not
> * set the change info
> */
> @@ -373,6 +369,9 @@ nfsd4_open(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> break;
> case NFS4_OPEN_CLAIM_PREVIOUS:
> open->op_openowner->oo_flags |= NFS4_OO_CONFIRMED;
> + status = nfs4_check_open_reclaim(&open->op_clientid);
> + if (status)
> + goto out;
> case NFS4_OPEN_CLAIM_FH:
> case NFS4_OPEN_CLAIM_DELEG_CUR_FH:
> status = do_open_fhandle(rqstp, &cstate->current_fh,
> --
> 1.7.7
>
>
^ permalink raw reply
* Re: New "ABS_WHEEL2" axis?
From: Jason Gerecke @ 2011-11-30 23:52 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Ping Cheng, Linux Input
In-Reply-To: <20111130231910.GA3220@core.coreip.homeip.net>
On Wed, Nov 30, 2011 at 3:19 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Nov 30, 2011 at 02:42:09PM -0800, Ping Cheng wrote:
>> > On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
>> >> On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
>> >> <dmitry.torokhov@gmail.com> wrote:
>> >> > On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
>> >> >> I'm working on adding support for the recently-announced Cintiq 24HD,
>> >> >> and am hashing out most of the details on the linuxwacom mailing list.
>> >> >> In the discussions there, it was suggested that we add a new e.g.
>> >> >> "ABS_WHEEL2" axis to the input.h header to represent the second touch
>> >> >> ring available on the 24HD. I think it's a good idea, but wanted to
>> >> >> get some opinions from over here before making a patch. The other
>> >> >> option we have available is to use an axis not already in use by the
>> >> >> wacom driver (such as ABS_RUDDER), but none have a matching semantic
>> >> >> meaning.
>> >
>> > Looking at this once more ABS_WHEEL does not semantically match to what
>> > Wacom driver users it for either. ABS_WHEEL is not "an abstract
>> > circular-shaped sensor on a device" for rather a "steering wheel"-like
>> > control on a game controller. So Wacom needs to move away from using this
>> > event.
>>
>> We can move away from using the WHEEL. But, we do still need to use
>> something to report the values. We need a constructive suggestion to
>> "move away" ;).
>>
>> >> The rings are controls built into the "pad" -- the hardware you bring
>> >> the stylus in proximity to. Along with the touch rings, there are also
>> >> buttons and touch strips. Now, some devices have controls on only the
>> >> left-hand side of the pad, while others have the controls on both
>> >> sides of the pad. While one could argue that this makes each "side" a
>> >> complete context that can be broken apart into separate devices, that
>> >> doesn't really solve anything. What's stopping us from grouping
>> >> several rings together?
>> >
>> > Well, there are several topics here...
>> >
>> > What you apparently have is a group of unclassified, as far as Linux
>> > input subsystem concerned, sensors. When I say unclassified I mean that
>> > there is no appropriate event code we can assign to the control to allow
>> > a generic consumer determine the purpose of that sensor. You need help
>> > of a specialized driver to decide what to do with the data or, in case
>> > of generic driver, user has to explicitly map it to some action, but
>> > there is no way for automatic discovery/configuration which is the goal
>> > of input core. The only and closest event that we have that is suitable
>> > here is ABS_MISC.
>> >
>> > Here however is a problem: there is only one ABS_MISC and we often have
>> > several such sensors on a device. I do not want to have ABS_MISCx as
>> > again, it does not solve anything, manufactures always come with bigger
>> > and bigger devices (there some music controllers with dozens of
>> > sliders). Encoding data into ABS_MISC (let's say highest byte denotes
>> > sensor number) is awkward as well. So that is why I propose splitting
>> > them into separate input devices and have driver discover and handle
>> > them as it sees fit.
>>
>> The rings are on the tablet. Events from them are combined with the
>> events from the other tools moving on the tablet. Splitting the
>> wheels/expresskeys from the tablet would only complicate the
>> situation. We would have to link the wheels back to the tablet in the
>> user land, an unnecessary step that we should/could avoid in the
>> kernel.
>
> The fact that they are in the same physical package does not mean that
> they are necessarily mapped to a single input device. For example my USB
> keyboard consists of 3 logical devices.
>
> I understand that having data from them in the same event stream would
> be nice and if you have an idea how to achieve that in a generic way
> without resorting to ABS_MISC55 - that would be great. Maybe we
> need something similar to multitouch protocol solution, but for
> unclassified data.
>
> OTOH separate input devices complicate userland in cases when driver
> wants to handle them together but is really flexible.
>
> --
> Dmitry
Confound my slow reply speeds... I was just about to hit the "send"
button too! :D
I'm not sure there is a good solution given the current expectations
of and by the input subsystem. Abusing/ignoring semantic meaning of
axes can confuse the userland. Arbitrarily adding new axes is not
sustainable. Splitting the hardware into per-sensor devices requires
additional needlesly-difficult re-unification code.
Augmenting the input subsystem with something similar to the MT
protocol would be one possible way of "properly" tackling the issue.
You'd have to figure out a way to deal with arbitrary tool types
though. For instance, say the touch strip on the 24HD were exposed to
the user as a strip and not faux-buttons. Two of the three
unclassified sensors producing the same "kind" of data, while the
third sensor produces a different "kind" of data.
Regardless, how should we handle the issue that presents itself in the
here-and-now? Even if refactoring things to split the tablet into more
devices is the route we ultimately decide on, that's going to take
some time to implement. It'd be nice if 24HD support weren't stalled
waiting for yet-to-be-written code to appear, and preferable if the
hardware worked in its entirety (meaning substituting ABS_WHEEL2 with
e.g. ABS_THROTTLE for the time being).
Jason
---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
^ permalink raw reply
* + tick-sched-add-specific-do_timer_cpu-value-for-nohz-off-mode.patch added to -mm tree
From: akpm @ 2011-11-30 23:51 UTC (permalink / raw)
To: mm-commits; +Cc: sivanich, john.stultz, tglx
The patch titled
Subject: tick-sched: add specific do_timer_cpu value for nohz off mode
has been added to the -mm tree. Its filename is
tick-sched-add-specific-do_timer_cpu-value-for-nohz-off-mode.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Dimitri Sivanich <sivanich@sgi.com>
Subject: tick-sched: add specific do_timer_cpu value for nohz off mode
Show and modify the tick_do_timer_cpu via sysfs. This determines the cpu
on which global time (jiffies) updates occur. Modification can only be
done on systems with nohz mode turned off.
While not necessarily harmful, doing jiffies updates on an application cpu
does cause some extra overhead that HPC benchmarking people notice. They
prefer to have OS activity isolated to certain cpus. They like reproducibility
of results, and having jiffies updates bouncing around introduces variability.
Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/ABI/testing/sysfs-devices-system-timekeeping | 16 ++
drivers/base/sys.c | 10 -
include/linux/sysdev.h | 2
kernel/time/tick-sched.c | 59 ++++++++++
4 files changed, 81 insertions(+), 6 deletions(-)
diff -puN /dev/null Documentation/ABI/testing/sysfs-devices-system-timekeeping
--- /dev/null
+++ a/Documentation/ABI/testing/sysfs-devices-system-timekeeping
@@ -0,0 +1,16 @@
+What: /sys/devices/system/timekeeping/
+Date: November 2011
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description: Timekeeping attributes
+
+
+What: /sys/devices/system/timekeeping/timekeeping0/jiffies_cpu
+Date: November 2011
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description: Show and modify the kernel's tick_do_timer_cpu. This
+ determines the cpu on which global time (jiffies) updates
+ occur. This can only be modified on systems running with
+ the nohz mode turned off (nohz=off).
+
+ Possible values are:
+ 0 - <num online cpus>
diff -puN drivers/base/sys.c~tick-sched-add-specific-do_timer_cpu-value-for-nohz-off-mode drivers/base/sys.c
--- a/drivers/base/sys.c~tick-sched-add-specific-do_timer_cpu-value-for-nohz-off-mode
+++ a/drivers/base/sys.c
@@ -339,13 +339,11 @@ int __init system_bus_init(void)
return 0;
}
-#define to_ext_attr(x) container_of(x, struct sysdev_ext_attribute, attr)
-
ssize_t sysdev_store_ulong(struct sys_device *sysdev,
struct sysdev_attribute *attr,
const char *buf, size_t size)
{
- struct sysdev_ext_attribute *ea = to_ext_attr(attr);
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
char *end;
unsigned long new = simple_strtoul(buf, &end, 0);
if (end == buf)
@@ -360,7 +358,7 @@ ssize_t sysdev_show_ulong(struct sys_dev
struct sysdev_attribute *attr,
char *buf)
{
- struct sysdev_ext_attribute *ea = to_ext_attr(attr);
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
return snprintf(buf, PAGE_SIZE, "%lx\n", *(unsigned long *)(ea->var));
}
EXPORT_SYMBOL_GPL(sysdev_show_ulong);
@@ -369,7 +367,7 @@ ssize_t sysdev_store_int(struct sys_devi
struct sysdev_attribute *attr,
const char *buf, size_t size)
{
- struct sysdev_ext_attribute *ea = to_ext_attr(attr);
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
char *end;
long new = simple_strtol(buf, &end, 0);
if (end == buf || new > INT_MAX || new < INT_MIN)
@@ -384,7 +382,7 @@ ssize_t sysdev_show_int(struct sys_devic
struct sysdev_attribute *attr,
char *buf)
{
- struct sysdev_ext_attribute *ea = to_ext_attr(attr);
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
return snprintf(buf, PAGE_SIZE, "%d\n", *(int *)(ea->var));
}
EXPORT_SYMBOL_GPL(sysdev_show_int);
diff -puN include/linux/sysdev.h~tick-sched-add-specific-do_timer_cpu-value-for-nohz-off-mode include/linux/sysdev.h
--- a/include/linux/sysdev.h~tick-sched-add-specific-do_timer_cpu-value-for-nohz-off-mode
+++ a/include/linux/sysdev.h
@@ -132,6 +132,8 @@ struct sysdev_ext_attribute {
void *var;
};
+#define SYSDEV_TO_EXT_ATTR(x) container_of(x, struct sysdev_ext_attribute, attr)
+
/*
* Support for simple variable sysdev attributes.
* The pointer to the variable is stored in a sysdev_ext_attribute
diff -puN kernel/time/tick-sched.c~tick-sched-add-specific-do_timer_cpu-value-for-nohz-off-mode kernel/time/tick-sched.c
--- a/kernel/time/tick-sched.c~tick-sched-add-specific-do_timer_cpu-value-for-nohz-off-mode
+++ a/kernel/time/tick-sched.c
@@ -834,6 +834,65 @@ void tick_cancel_sched_timer(int cpu)
}
#endif
+#ifdef CONFIG_SYSFS
+/*
+ * Allow modification of tick_do_timer_cpu when nohz mode is off.
+ */
+static ssize_t sysfs_store_do_timer_cpu(struct sys_device *dev,
+ struct sysdev_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
+ unsigned int new;
+ int rv;
+
+#ifdef CONFIG_NO_HZ
+ /* nohz mode not supported */
+ if (tick_nohz_enabled)
+ return -EINVAL;
+#endif
+
+ rv = kstrtouint(buf, 0, &new);
+ if (rv)
+ return rv;
+
+ if (new >= NR_CPUS || !cpu_online(new))
+ return -ERANGE;
+
+ *(unsigned int *)(ea->var) = new;
+ return size;
+}
+
+static struct sysdev_ext_attribute attr_jiffies_cpu = {
+ _SYSDEV_ATTR(jiffies_cpu, 0644, sysdev_show_int,
+ sysfs_store_do_timer_cpu),
+ &tick_do_timer_cpu };
+
+static struct sysdev_class timekeeping_sysclass = {
+ .name = "timekeeping",
+};
+
+static struct sys_device device_timekeeping = {
+ .id = 0,
+ .cls = &timekeeping_sysclass,
+};
+
+static int __init init_timekeeping_sysfs(void)
+{
+ int error = sysdev_class_register(&timekeeping_sysclass);
+
+ if (!error)
+ error = sysdev_register(&device_timekeeping);
+ if (!error)
+ error = sysdev_create_file(
+ &device_timekeeping,
+ &attr_jiffies_cpu.attr);
+ return error;
+}
+
+device_initcall(init_timekeeping_sysfs);
+#endif /* SYSFS */
+
/**
* Async notification about clocksource changes
*/
_
Subject: Subject: tick-sched: add specific do_timer_cpu value for nohz off mode
Patches currently in -mm which might be from sivanich@sgi.com are
tick-sched-add-specific-do_timer_cpu-value-for-nohz-off-mode.patch
^ permalink raw reply
* Re: [PATCH 20/62] mmc: remove the second argument of k[un]map_atomic()
From: David Brown @ 2011-11-30 23:51 UTC (permalink / raw)
To: Cong Wang
Cc: linux-kernel, akpm, Nicolas Ferre, Chris Ball, David Brown,
Daniel Walker, Bryan Huntsman, Alex Dubov, Guennadi Liakhovetski,
Ian Molton, linux-arm-kernel, linux-mmc, linux-arm-msm
In-Reply-To: <1322371662-26166-21-git-send-email-amwang@redhat.com>
On Sun, Nov 27, 2011 at 01:27:00PM +0800, Cong Wang wrote:
> drivers/mmc/host/msm_sdcc.c | 6 +++---
Acked-by: David Brown <davidb@codeaurora.org>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 20/62] mmc: remove the second argument of k[un]map_atomic()
From: David Brown @ 2011-11-30 23:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1322371662-26166-21-git-send-email-amwang@redhat.com>
On Sun, Nov 27, 2011 at 01:27:00PM +0800, Cong Wang wrote:
> drivers/mmc/host/msm_sdcc.c | 6 +++---
Acked-by: David Brown <davidb@codeaurora.org>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [U-Boot] [PATCH v3] video: cfb_console: Make the software cursor non-destructive
From: Anatolij Gustschin @ 2011-11-30 23:50 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320788820-19191-1-git-send-email-gabeblack@chromium.org>
From: Gabe Black <gabeblack@chromium.org>
When printing the string "\r\n" to the framebuffer console, the first
character of the current line was being replaced with a space. The "boot"
prompt would become the "oot" prompt. This change makes the cursor
non-destructive so that no matter where it goes on its way to where it's
supposed to be, the end result is that the cursor is where it's supposed to
be with the other text preserved.
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
Changes in v3:
- fixed checkpatch errors
- slightly modified subject line
- fixed cursor position if video logo is used
Changes in v2:
- Tidy up commit message wording.
- Undo change to documenting comment.
- Undo minor whitespace tweak.
- Consolidate CONFIG_CONSOLE_CURSOR and CONFIG_VIDEO_SW_CURSOR.
- Get rid of a space between video_invertchar and its (.
drivers/video/cfb_console.c | 109 +++++++++++++++++++++----------------------
1 files changed, 53 insertions(+), 56 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 480df64..9be6166 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -242,8 +242,9 @@
#define CURSOR_SET
#endif
-#ifdef CONFIG_CONSOLE_CURSOR
-#ifdef CURSOR_ON
+#if defined(CONFIG_CONSOLE_CURSOR) || defined(CONFIG_VIDEO_SW_CURSOR)
+#if defined(CURSOR_ON) || \
+ (defined(CONFIG_CONSOLE_CURSOR) && defined(CONFIG_VIDEO_SW_CURSOR))
#error only one of CONFIG_CONSOLE_CURSOR, CONFIG_VIDEO_SW_CURSOR, \
or CONFIG_VIDEO_HW_CURSOR can be defined
#endif
@@ -251,27 +252,18 @@ void console_cursor(int state);
#define CURSOR_ON console_cursor(1)
#define CURSOR_OFF console_cursor(0)
-#define CURSOR_SET
+#define CURSOR_SET video_set_cursor()
+#endif /* CONFIG_CONSOLE_CURSOR || CONFIG_VIDEO_SW_CURSOR */
+
+#ifdef CONFIG_CONSOLE_CURSOR
+#ifndef CONFIG_CONSOLE_TIME
+#error CONFIG_CONSOLE_CURSOR must be defined for CONFIG_CONSOLE_TIME
+#endif
#ifndef CONFIG_I8042_KBD
#warning Cursor drawing on/off needs timer function s.a. drivers/input/i8042.c
#endif
-#else
-#ifdef CONFIG_CONSOLE_TIME
-#error CONFIG_CONSOLE_CURSOR must be defined for CONFIG_CONSOLE_TIME
-#endif
#endif /* CONFIG_CONSOLE_CURSOR */
-#ifdef CONFIG_VIDEO_SW_CURSOR
-#ifdef CURSOR_ON
-#error only one of CONFIG_CONSOLE_CURSOR, CONFIG_VIDEO_SW_CURSOR, \
- or CONFIG_VIDEO_HW_CURSOR can be defined
-#endif
-#define CURSOR_ON
-#define CURSOR_OFF video_putchar(console_col * VIDEO_FONT_WIDTH,\
- console_row * VIDEO_FONT_HEIGHT, ' ')
-#define CURSOR_SET video_set_cursor()
-#endif /* CONFIG_VIDEO_SW_CURSOR */
-
#ifdef CONFIG_VIDEO_HW_CURSOR
#ifdef CURSOR_ON
@@ -376,6 +368,10 @@ static void *video_console_address; /* console buffer start address */
static int video_logo_height = VIDEO_LOGO_HEIGHT;
+static int cursor_state;
+static int old_col;
+static int old_row;
+
static int console_col; /* cursor col */
static int console_row; /* cursor row */
@@ -435,6 +431,22 @@ static const int video_font_draw_table32[16][4] = {
};
+static void video_invertchar(int xx, int yy)
+{
+ int firstx = xx * VIDEO_PIXEL_SIZE;
+ int lastx = (xx + VIDEO_FONT_WIDTH) * VIDEO_PIXEL_SIZE;
+ int firsty = yy * VIDEO_LINE_LEN;
+ int lasty = (yy + VIDEO_FONT_HEIGHT) * VIDEO_LINE_LEN;
+ int x, y;
+ for (y = firsty; y < lasty; y += VIDEO_LINE_LEN) {
+ for (x = firstx; x < lastx; x++) {
+ u8 *dest = (u8 *)(video_fb_address) + x + y;
+ *dest = ~*dest;
+ }
+ }
+}
+
+
static void video_drawchars(int xx, int yy, unsigned char *s, int count)
{
u8 *cdat, *dest, *dest0;
@@ -610,27 +622,15 @@ static void video_putchar(int xx, int yy, unsigned char c)
#if defined(CONFIG_CONSOLE_CURSOR) || defined(CONFIG_VIDEO_SW_CURSOR)
static void video_set_cursor(void)
{
- /* swap drawing colors */
- eorx = fgx;
- fgx = bgx;
- bgx = eorx;
- eorx = fgx ^ bgx;
- /* draw cursor */
- video_putchar(console_col * VIDEO_FONT_WIDTH,
- console_row * VIDEO_FONT_HEIGHT, ' ');
- /* restore drawing colors */
- eorx = fgx;
- fgx = bgx;
- bgx = eorx;
- eorx = fgx ^ bgx;
+ if (cursor_state)
+ console_cursor(0);
+ console_cursor(1);
}
-#endif
-#ifdef CONFIG_CONSOLE_CURSOR
+
+
void console_cursor(int state)
{
- static int last_state = 0;
-
#ifdef CONFIG_CONSOLE_TIME
struct rtc_time tm;
char info[16];
@@ -652,17 +652,22 @@ void console_cursor(int state)
}
#endif
- if (state && (last_state != state)) {
- video_set_cursor();
- }
-
- if (!state && (last_state != state)) {
- /* clear cursor */
- video_putchar(console_col * VIDEO_FONT_WIDTH,
- console_row * VIDEO_FONT_HEIGHT, ' ');
+ if (cursor_state != state) {
+ if (cursor_state) {
+ /* turn off the cursor */
+ video_invertchar(old_col * VIDEO_FONT_WIDTH,
+ old_row * VIDEO_FONT_HEIGHT +
+ video_logo_height);
+ } else {
+ /* turn off the cursor and record where it is */
+ video_invertchar(console_col * VIDEO_FONT_WIDTH,
+ console_row * VIDEO_FONT_HEIGHT +
+ video_logo_height);
+ old_col = console_col;
+ old_row = console_row;
+ }
+ cursor_state = state;
}
-
- last_state = state;
}
#endif
@@ -729,19 +734,11 @@ static void console_back(void)
if (console_row < 0)
console_row = 0;
}
- video_putchar(console_col * VIDEO_FONT_WIDTH,
- console_row * VIDEO_FONT_HEIGHT, ' ');
+ CURSOR_SET;
}
static void console_newline(void)
{
- /* Check if last character in the line was just drawn. If so, cursor was
- overwriten and need not to be cleared. Cursor clearing without this
- check causes overwriting the 1st character of the line if line lenght
- is >= CONSOLE_COLS
- */
- if (console_col < CONSOLE_COLS)
- CURSOR_OFF;
console_row++;
console_col = 0;
@@ -757,7 +754,6 @@ static void console_newline(void)
static void console_cr(void)
{
- CURSOR_OFF;
console_col = 0;
}
@@ -765,6 +761,8 @@ void video_putc(const char c)
{
static int nl = 1;
+ CURSOR_OFF;
+
switch (c) {
case 13: /* back to first column */
console_cr();
@@ -777,7 +775,6 @@ void video_putc(const char c)
break;
case 9: /* tab 8 */
- CURSOR_OFF;
console_col |= 0x0008;
console_col &= ~0x0007;
--
1.7.1
^ permalink raw reply related
* Re: Using MT9P031 digital sensor
From: Laurent Pinchart @ 2011-11-30 23:49 UTC (permalink / raw)
To: Gary Thomas; +Cc: Javier Martinez Canillas, Linux Media Mailing List
In-Reply-To: <4ED66147.8090109@mlbassoc.com>
Hi Gary,
On Wednesday 30 November 2011 18:00:55 Gary Thomas wrote:
> On 2011-11-30 07:57, Gary Thomas wrote:
> > On 2011-11-30 07:30, Laurent Pinchart wrote:
> >> On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote:
[snip]
> >>> This sort of works(*), but I'm still having issues (at least I can move
> >>> frames!) When I configure the pipeline like this:
> >>> media-ctl -r
> >>> media-ctl -l '"mt9p031 3-005d":0->"OMAP3 ISP CCDC":0[1]'
> >>> media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]'
> >>> media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]'
> >>> media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
> >>> media-ctl -f '"mt9p031 3-005d":0[SGRBG12 2592x1944]'
> >>> media-ctl -f '"OMAP3 ISP CCDC":0 [SGRBG12 2592x1944]'
> >>> media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 2592x1944]'
> >>> media-ctl -f '"OMAP3 ISP preview":0 [SGRBG10 2592x1943]'
> >>> media-ctl -f '"OMAP3 ISP resizer":0 [YUYV 2574x1935]'
> >>> media-ctl -f '"OMAP3 ISP resizer":1 [YUYV 660x496]'
> >>> the resulting frames are 666624 bytes each instead of 654720
> >>>
> >>> When I tried to grab from the previewer, the frames were 9969120
> >>> instead of 9961380
> >>>
> >>> Any ideas what resolution is actually being moved through?
> >>
> >> Because the OMAP3 ISP has alignment requirements. Both the preview
> >> engine and the resizer output line lenghts must be multiple of 32
> >> bytes. The driver adds padding at end of lines when the output width
> >> isn't a multiple of 16 pixels.
> >
> > Any guess which resolution(s) I should change and to what?
>
> I changed the resizer output to be 672x496 and was able to capture video
> using ffmpeg.
>
> I don't know what to expect with this sensor (I've never seen it in use
> before), but the image seems to have color balance issues - it's awash in
> a green hue. It may be the poor lighting in my office... I did try the 9
> test patterns which I was able to select via
> # v4l2-ctl -d /dev/v4l-subdev8 --set-ctrl=test_pattern=N
> and these looked OK. You can see them at
> http://www.mlbassoc.com/misc/mt9p031_images/
Neither the sensor nor the OMAP3 ISP implement automatic white balance. The
ISP preview engine can be used to modify the white balance, and the statistics
engine can be used to extract data useful to compute the white balance
parameters, but linking the two needs to be performed in userspace.
> >> So this means that your original problem comes from the BT656 patches.
> >
> > Yes, it does look that way. Now that I have something that moves data, I
> > can compare how the ISP is setup between the two versions and come up
> > with a fix.
>
> This is next on my plate, but it may take a while to figure it out.
>
> Is there some recent tree which will have this digital (mt9p031) part
> working that also has the BT656 support in it? I'd like to try that
> rather than spending time figuring out why an older tree isn't working.
No, I haven't had time to create one, sorry. It shouldn't be difficult to
rebase the BT656 patches on top of the latest OMAP3 ISP and MT9P031 code.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* + drivers-leds-leds-lp5523c-remove-unneeded-forward-declaration.patch added to -mm tree
From: akpm @ 2011-11-30 23:48 UTC (permalink / raw)
To: mm-commits; +Cc: axel.lin, rpurdie, samu.p.onkalo
The patch titled
Subject: drivers/leds/leds-lp5523.c: remove unneeded forward declaration
has been added to the -mm tree. Its filename is
drivers-leds-leds-lp5523c-remove-unneeded-forward-declaration.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
From: Axel Lin <axel.lin@gmail.com>
Subject: drivers/leds/leds-lp5523.c: remove unneeded forward declaration
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Samu Onkalo <samu.p.onkalo@nokia.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/leds/leds-lp5523.c | 2 --
1 file changed, 2 deletions(-)
diff -puN drivers/leds/leds-lp5523.c~drivers-leds-leds-lp5523c-remove-unneeded-forward-declaration drivers/leds/leds-lp5523.c
--- a/drivers/leds/leds-lp5523.c~drivers-leds-leds-lp5523c-remove-unneeded-forward-declaration
+++ a/drivers/leds/leds-lp5523.c
@@ -870,8 +870,6 @@ static int __devinit lp5523_init_led(str
return 0;
}
-static struct i2c_driver lp5523_driver;
^ permalink raw reply
* Re: [PATCH 2/2] svcrpc: avoid memory-corruption on pool shutdown
From: Ben Greear @ 2011-11-30 23:47 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux-nfs, Jeff Layton
In-Reply-To: <20111130234303.GC354@fieldses.org>
On 11/30/2011 03:43 PM, J. Bruce Fields wrote:
> Anyone see any remaining hole, or does this finally fix the problem?
>
> Any idea for something simpler?
>
> If not I'll likely commit this for 3.2 and -stable before the end of the
> week.
I never did understand this code too well, so I'm afraid I can't
really review this. I'll be sure to run our NFS stress tests when we upgrade
to newer kernels..but that will likely be a while.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] [RFC] KSM: numa awareness sysfs knob
From: Andrew Morton @ 2011-11-30 23:47 UTC (permalink / raw)
To: Petr Holasek
Cc: Hugh Dickins, Andrea Arcangeli, linux-kernel, linux-mm,
Anton Arapov
In-Reply-To: <1322649446-11437-1-git-send-email-pholasek@redhat.com>
On Wed, 30 Nov 2011 11:37:26 +0100
Petr Holasek <pholasek@redhat.com> wrote:
> Introduce a new sysfs knob /sys/kernel/mm/ksm/max_node_dist, whose
> value will be used as the limitation for node distance of merged pages.
>
The changelog doesn't really describe why you think Linux needs this
feature? What's the reasoning? Use cases? What value does it provide?
> index b392e49..b882140 100644
> --- a/Documentation/vm/ksm.txt
> +++ b/Documentation/vm/ksm.txt
> @@ -58,6 +58,10 @@ sleep_millisecs - how many milliseconds ksmd should sleep before next scan
> e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
> Default: 20 (chosen for demonstration purposes)
>
> +max_node_dist - maximum node distance between two pages which could be
> + merged.
> + Default: 255 (without any limitations)
And this doesn't explain to our users why they might want to alter it,
and what effects they would see from doing so. Maybe that's obvious to
them...
> run - set 0 to stop ksmd from running but keep merged pages,
> set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
> set 2 to stop ksmd and unmerge all pages currently merged,
>
> ...
>
> +#ifdef CONFIG_NUMA
> +static inline int node_dist(int from, int to)
> +{
> + int dist = node_distance(from, to);
> +
> + return dist == -1 ? 0 : dist;
> +}
So I spent some time grubbing around trying to work out what a return
value of -1 from node_distance() means, and wasn't successful. Perhaps
an explanatory comment here would have helped.
> +#else
> +static inline int node_dist(int from, int to)
> +{
> + return 0;
> +}
> +#endif
>
> ...
>
> +static ssize_t max_node_dist_store(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int err;
> + unsigned long node_dist;
> +
> + err = kstrtoul(buf, 10, &node_dist);
> + if (err || node_dist > 255)
> + return -EINVAL;
If kstrtoul() returned an errno we should propagate that back rather than
overwriting it with -EINVAL.
> + ksm_node_distance = node_dist;
> +
> + return count;
> +}
>
> ...
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] [RFC] KSM: numa awareness sysfs knob
From: Andrew Morton @ 2011-11-30 23:47 UTC (permalink / raw)
To: Petr Holasek
Cc: Hugh Dickins, Andrea Arcangeli, linux-kernel, linux-mm,
Anton Arapov
In-Reply-To: <1322649446-11437-1-git-send-email-pholasek@redhat.com>
On Wed, 30 Nov 2011 11:37:26 +0100
Petr Holasek <pholasek@redhat.com> wrote:
> Introduce a new sysfs knob /sys/kernel/mm/ksm/max_node_dist, whose
> value will be used as the limitation for node distance of merged pages.
>
The changelog doesn't really describe why you think Linux needs this
feature? What's the reasoning? Use cases? What value does it provide?
> index b392e49..b882140 100644
> --- a/Documentation/vm/ksm.txt
> +++ b/Documentation/vm/ksm.txt
> @@ -58,6 +58,10 @@ sleep_millisecs - how many milliseconds ksmd should sleep before next scan
> e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
> Default: 20 (chosen for demonstration purposes)
>
> +max_node_dist - maximum node distance between two pages which could be
> + merged.
> + Default: 255 (without any limitations)
And this doesn't explain to our users why they might want to alter it,
and what effects they would see from doing so. Maybe that's obvious to
them...
> run - set 0 to stop ksmd from running but keep merged pages,
> set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
> set 2 to stop ksmd and unmerge all pages currently merged,
>
> ...
>
> +#ifdef CONFIG_NUMA
> +static inline int node_dist(int from, int to)
> +{
> + int dist = node_distance(from, to);
> +
> + return dist == -1 ? 0 : dist;
> +}
So I spent some time grubbing around trying to work out what a return
value of -1 from node_distance() means, and wasn't successful. Perhaps
an explanatory comment here would have helped.
> +#else
> +static inline int node_dist(int from, int to)
> +{
> + return 0;
> +}
> +#endif
>
> ...
>
> +static ssize_t max_node_dist_store(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int err;
> + unsigned long node_dist;
> +
> + err = kstrtoul(buf, 10, &node_dist);
> + if (err || node_dist > 255)
> + return -EINVAL;
If kstrtoul() returned an errno we should propagate that back rather than
overwriting it with -EINVAL.
> + ksm_node_distance = node_dist;
> +
> + return count;
> +}
>
> ...
>
^ permalink raw reply
* [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Michael S. Tsirkin @ 2011-11-30 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbbZH3ZFzbwwyVBGEvwHPbogDW6+Kb_1pRam2jj5oJHuDA@mail.gmail.com>
On Thu, Dec 01, 2011 at 01:27:10AM +0200, Ohad Ben-Cohen wrote:
> On Wed, Nov 30, 2011 at 6:24 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> > On Wed, Nov 30, 2011 at 6:15 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> How are the rings mapped? normal memory, right?
> >
> > No, device memory.
>
> Ok, I have more info.
>
> Originally remoteproc was mapping the rings using ioremap, and that
> meant ARM Device memory.
>
> Recently, though, we moved to CMA (allocating memory for the rings via
> dma_alloc_coherent), and that isn't Device memory anymore: it's
> uncacheable Normal memory (on ARM v6+).
And these accesses need to be ordered with DSB? Or DMB?
> We still require mandatory barriers though: one very reproducible
> problem I personally face is that the avail index doesn't get updated
> before the kick.
Aha! The *kick* really is MMIO. So I think we do need a mandatory barrier
before the kick. Maybe we need it for virtio-pci as well
(not on kvm, naturally :) Off-hand this seems to belong in the transport
layer but need to think about it.
> As a result, the remote processor misses a buffer
> that was just added (the kick wakes it up only to find that the avail
> index wasn't changed yet). In this case, it probably happens because
> the mailbox, used to kick the remote processor, is mapped as Device
> memory, and therefore the kick can be reordered before the updates to
> the ring can be observed.
>
> I did get two additional reports about reordering issues, on different
> setups than my own, and which I can't personally reproduce: the one
> I've described earlier (avail index gets updated before the avail
> array) and one in the receive path (reading a used buffer which we
> already read). I couldn't personally verify those, but both issues
> were reported to be gone when mandatory barriers were used.
Hmm. So it's a hint that something is wrong with memory
but not what's wrong exactly.
> I expect those reports only to increase: the diversity of platforms
> that are now looking into adopting virtio for this kind of
> inter-process communication is quite huge, with several different
> architectures and even more hardware implementations on the way (not
> only ARM).
>
> Thanks,
> Ohad.
Right. We need to be very careful with memory,
it's a tricky field. One known problem with virtio
is its insistance on using native endian-ness
for some fields. If power is used, we'll have to fix this.
--
MST
^ permalink raw reply
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.