* Re: [PATCH 7/8] xfstests: add new stress test
From: Christoph Hellwig @ 2011-10-24 9:08 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: linux-fsdevel, xfs, linux-ext4, jack, hch, aelder
In-Reply-To: <1319020189-13584-8-git-send-email-dmonakhov@openvz.org>
On Wed, Oct 19, 2011 at 02:29:48PM +0400, Dmitry Monakhov wrote:
> During stress testing we want to cover as much code paths as possible
> fsstress is very good for this purpose. But it has expandable nature
> (disk usage almost continually grow). So once it goes in no ENOSPC
> condition it will be where till the end. But by running 'dd' writers
> in parallel we can regularly trigger ENOSPC but only for a limited
> periods of time because each time it opens file with O_TRUNC.
Looks good, but please use a more useful subject line, e.g.
xfstests: add a new test that runs fsstress under ENOSPC conditions.
^ permalink raw reply
* Re: [PATCH 7/8] xfstests: add new stress test
From: Christoph Hellwig @ 2011-10-24 9:08 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: jack, xfs, hch, aelder, linux-fsdevel, linux-ext4
In-Reply-To: <1319020189-13584-8-git-send-email-dmonakhov@openvz.org>
On Wed, Oct 19, 2011 at 02:29:48PM +0400, Dmitry Monakhov wrote:
> During stress testing we want to cover as much code paths as possible
> fsstress is very good for this purpose. But it has expandable nature
> (disk usage almost continually grow). So once it goes in no ENOSPC
> condition it will be where till the end. But by running 'dd' writers
> in parallel we can regularly trigger ENOSPC but only for a limited
> periods of time because each time it opens file with O_TRUNC.
Looks good, but please use a more useful subject line, e.g.
xfstests: add a new test that runs fsstress under ENOSPC conditions.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Peter Maydell @ 2011-10-24 9:09 UTC (permalink / raw)
To: Kevin Wolf; +Cc: Paolo Bonzini, avi, Alexander Graf, qemu-devel
In-Reply-To: <4EA51F16.3030700@redhat.com>
On 24 October 2011 09:17, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 24.10.2011 09:53, schrieb Paolo Bonzini:
>> I think it's not about "why is it there", but rather about "what is it
>> useful for". My interpretation of it is "I do not need the image
>> anymore unless the command exits cleanly": VM installations, qemu-img
>> conversions, BDRV_O_SNAPSHOT (doesn't do it yet, but it could). Even
>> SIGINT and SIGTERM would be excluded from this definition, but they cost
>> nothing so it's nice to include them.
>
> I think another common interpretation is: "I don't run this VM in
> production but for development. I want the VM to go faster and I can
> recreate the image in the unlikely event that power fails during my
> work. But it certainly would be nasty."
So at the moment the documentation (qemu-doc.html) says:
"Writeback caching will report data writes as completed as soon as the
data is present in the host page cache. This is safe as long as you trust
your host. If your host crashes or loses power, then the guest may
experience data corruption."
and also:
"In case you don't care about data integrity over host failures, use
cache=unsafe. This option tells qemu that it never needs to write any
data to the disk but can instead keeps things in cache. If anything
goes wrong, like your host losing power, the disk storage getting
disconnected accidently, etc. you're image will most probably be
rendered unusable."
which to me reads in both cases as "will not corrupt data if the
guest crashes but may do so if the host crashes" and leaves me
with no idea what the difference is. It might be nice if we could
clarify that a bit...
-- PMM
^ permalink raw reply
* Re: [PATCH 2/3] mfd: Add s5m series irq support
From: Mark Brown @ 2011-10-24 9:10 UTC (permalink / raw)
To: Sangbeom Kim; +Cc: 'Samuel Ortiz', linux-kernel
In-Reply-To: <009801cc9171$c4ea1970$4ebe4c50$@com>
On Sun, Oct 23, 2011 at 07:51:50PM +0900, Sangbeom Kim wrote:
> I hope that this driver will be base code for regmap based irq driver
> I want discuss more detail in Prague.
FWIW I've got an interface and part of the implementation coded up
already but I've not got appropriate hardware for testing with me -
let's use that as a basis for discussion, if I've got time I might also
have the implementation implemented but not tested.
^ permalink raw reply
* Re: [Qemu-devel] [RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous packet when needed
From: Ben Hutchings @ 2011-10-24 9:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rusty Russell, Jason Wang, aliguori, quintela, jan.kiszka,
qemu-devel, blauwirbel, pbonzini, kvm, netdev
In-Reply-To: <20111024052526.GA2362@redhat.com>
On Mon, 2011-10-24 at 07:25 +0200, Michael S. Tsirkin wrote:
> On Mon, Oct 24, 2011 at 02:54:59PM +1030, Rusty Russell wrote:
> > On Sat, 22 Oct 2011 13:43:11 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > > This make let virtio-net driver can send gratituous packet by a new
> > > config bit - VIRTIO_NET_S_ANNOUNCE in each config update
> > > interrupt. When this bit is set by backend, the driver would schedule
> > > a workqueue to send gratituous packet through NETDEV_NOTIFY_PEERS.
> > >
> > > This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE.
> > >
> > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> >
> > This seems like a huge layering violation. Imagine this in real
> > hardware, for example.
>
> commits 06c4648d46d1b757d6b9591a86810be79818b60c
> and 99606477a5888b0ead0284fecb13417b1da8e3af
> document the need for this:
>
> NETDEV_NOTIFY_PEERS notifier indicates that a device moved to a
> different physical link.
> and
> In real hardware such notifications are only
> generated when the device comes up or the address changes.
>
> So hypervisor could get the same behaviour by sending link up/down
> events, this is just an optimization so guest won't do
> unecessary stuff like try to reconfigure an IP address.
>
>
> Maybe LOCATION_CHANGE would be a better name?
[...]
We also use this in bonding failover, where the system location doesn't
change but a different link is used. However, I do recognise that the
name ought to indicate what kind of change happened and not what the
expected action is.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [GIT PULL] i.MX6Q support
From: Russell King - ARM Linux @ 2011-10-24 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4z7AUQmfH47kmjBvGTtwoKWitOH6WWx5cRRmz51-+hYFQ@mail.gmail.com>
On Mon, Oct 24, 2011 at 09:15:38AM +0800, Barry Song wrote:
> 2011/10/21 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Fri, Oct 21, 2011 at 01:11:59AM +0800, Shawn Guo wrote:
> >> Please pull imx6q series. ?It's based on v3.1-rc10 with the following
> >> branches merged plus a number of cache-l2x0 patches currently sitting
> >> on rmk/for-next.
> >
> > Don't do that. ?If there's something you need, _ask_ me. ?The L2x0
> > patches got shuffled out into their own branch when the SMP and debug
> > patches got split out of the 'misc' branch.
>
> does it mean i can rebase the prima2 l2 patch based on the rmk/l2
> branch with the two commits i need:
> ARM: 7090/1: CACHE-L2X0: filter start address can be 0 and is often 0;
> ARM: 7114/1: cache-l2x0: add resume entry for l2 in secure mode
The l2x0 branch contains these commits, so you can use that as a basis
for your work. If you have other dependencies, you may have to merge
this with other branches.
Note - an issue which came up with the GIC PPI pull request - if
you're merging by commit ID, please go back and edit the commit
message using git commit --amend and make it _more_ informative. This
is far from a useful commit message:
Merge commit '32cffdd' into ppi-irq-core-for-rmk
What this is actually doing is merging Thomas' IRQ tree, but that message
gives no clue that's what happened. On the other hand, a real pull gives
this kind of message:
Merge branch 'ppi-irq-core-for-rmk' of git://github.com/mzyngier/arm-platforms into devel-stable
And this says exactly what tree is being merged from where - and such
a line explains why the other commits (which come from someone elses
tree) are there.
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Sebastian Rasmussen @ 2011-10-24 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA51C4A.7040802@stericsson.com>
Hi!
> If the ARM PL180 TRM prevent us from from doing this kind of operations in
> runtime_suspend, we must think of an alternative solution which just apply
> for ST-Ericssons derivative of PL180. THIS IS VERY IMPORTANT to be able to
> implement a proper power management solution.
I believe that what it boils down to is how the power regulators are controlled.
In ST-Ericssons PL180 derivative there must be two independent regulators,
controlled by something outside the PL180 itself, one for the controller and
one for the external card. So if you know what you are doing you can power
down the controller while still keeping the card powered.
In the case of ARM PL180 it seems to me as if there is one power regulator,
controlled by something outside the PL180, that supplies power to the
controller, and one power regulator, controlled by the PL180, that supplies
power to the card. Therefore it is simply not possible to clear the ARM
PL180s MCIPower register (because that means that the card will loose
power since the control signals to the card's power regulator are now asking
it to cut power to the card). In addition I believe that it may not be
possible to
power the controller down...
/ Sebastian
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Sebastian Rasmussen @ 2011-10-24 9:11 UTC (permalink / raw)
To: Ulf Hansson
Cc: Russell King - ARM Linux, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Lee Jones
In-Reply-To: <4EA51C4A.7040802@stericsson.com>
Hi!
> If the ARM PL180 TRM prevent us from from doing this kind of operations in
> runtime_suspend, we must think of an alternative solution which just apply
> for ST-Ericssons derivative of PL180. THIS IS VERY IMPORTANT to be able to
> implement a proper power management solution.
I believe that what it boils down to is how the power regulators are controlled.
In ST-Ericssons PL180 derivative there must be two independent regulators,
controlled by something outside the PL180 itself, one for the controller and
one for the external card. So if you know what you are doing you can power
down the controller while still keeping the card powered.
In the case of ARM PL180 it seems to me as if there is one power regulator,
controlled by something outside the PL180, that supplies power to the
controller, and one power regulator, controlled by the PL180, that supplies
power to the card. Therefore it is simply not possible to clear the ARM
PL180s MCIPower register (because that means that the card will loose
power since the control signals to the card's power regulator are now asking
it to cut power to the card). In addition I believe that it may not be
possible to
power the controller down...
/ Sebastian
^ permalink raw reply
* Re: [Qemu-devel] [RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous packet when needed
From: Ben Hutchings @ 2011-10-24 9:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: aliguori, kvm, quintela, jan.kiszka, Jason Wang, Rusty Russell,
qemu-devel, blauwirbel, netdev, pbonzini
In-Reply-To: <20111024052526.GA2362@redhat.com>
On Mon, 2011-10-24 at 07:25 +0200, Michael S. Tsirkin wrote:
> On Mon, Oct 24, 2011 at 02:54:59PM +1030, Rusty Russell wrote:
> > On Sat, 22 Oct 2011 13:43:11 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > > This make let virtio-net driver can send gratituous packet by a new
> > > config bit - VIRTIO_NET_S_ANNOUNCE in each config update
> > > interrupt. When this bit is set by backend, the driver would schedule
> > > a workqueue to send gratituous packet through NETDEV_NOTIFY_PEERS.
> > >
> > > This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE.
> > >
> > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> >
> > This seems like a huge layering violation. Imagine this in real
> > hardware, for example.
>
> commits 06c4648d46d1b757d6b9591a86810be79818b60c
> and 99606477a5888b0ead0284fecb13417b1da8e3af
> document the need for this:
>
> NETDEV_NOTIFY_PEERS notifier indicates that a device moved to a
> different physical link.
> and
> In real hardware such notifications are only
> generated when the device comes up or the address changes.
>
> So hypervisor could get the same behaviour by sending link up/down
> events, this is just an optimization so guest won't do
> unecessary stuff like try to reconfigure an IP address.
>
>
> Maybe LOCATION_CHANGE would be a better name?
[...]
We also use this in bonding failover, where the system location doesn't
change but a different link is used. However, I do recognise that the
name ought to indicate what kind of change happened and not what the
expected action is.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 9:11 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: <4EA52851.8000203@ti.com>
On Mon, Oct 24, 2011 at 02:26:49PM +0530, Rajendra Nayak wrote:
> On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
> >Okay, it's wrong then since so many people say it's wrong :) I guess
> >a quick fix would be adding one property in device tree node for
> >matching some unique field in regulator_desc, id, maybe? Mark, any
> >suggestion?
>
> Thats basically what the DT compatible property is for :)
But adding compatible property will get DT core create 'struct dev'
for each regulator node, while we are trying to avoid that since
regulator core has been doing this.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA52851.8000203@ti.com>
On Mon, Oct 24, 2011 at 02:26:49PM +0530, Rajendra Nayak wrote:
> On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
> >Okay, it's wrong then since so many people say it's wrong :) I guess
> >a quick fix would be adding one property in device tree node for
> >matching some unique field in regulator_desc, id, maybe? Mark, any
> >suggestion?
>
> Thats basically what the DT compatible property is for :)
But adding compatible property will get DT core create 'struct dev'
for each regulator node, while we are trying to avoid that since
regulator core has been doing this.
--
Regards,
Shawn
^ permalink raw reply
* [U-Boot] [PATCH] Fix compile issue in arch/arm/lib/board.c
From: Marek Vasut @ 2011-10-24 9:12 UTC (permalink / raw)
To: u-boot
The commit dc8bbea0170eb2aca428ea221c91fc2e5e11f199 breaks the build of U-Boot
if CONFIG_CMD_NET is enabled.
arm: Use getenv_ulong() in place of getenv(), strtoul
This changes the board code to use the new getenv_ulong() function.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
---
arch/arm/lib/board.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index c764844..558e973 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -566,7 +566,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
/* Initialize from environment */
load_addr = getenv_ulong("loadaddr", 16, load_addr);
#if defined(CONFIG_CMD_NET)
- s = getenv("bootfile");
+ char *s = getenv("bootfile");
if (s != NULL)
copy_filename(BootFile, s, sizeof(BootFile));
#endif
--
1.7.6.3
^ permalink raw reply related
* Re: Eclipse Plugin: ADT Version too old
From: Jack Mitchell @ 2011-10-24 9:12 UTC (permalink / raw)
To: yocto
In-Reply-To: <4EA529F5.4010706@communistcode.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On 24/10/2011 10:03, Jack Mitchell wrote:
> I am trying to use the new eclipse plugin, which I have had working
> fine for the past couple of weeks until I switched from the master
> branch to edison.
>
> I performed a fresh build using the stable edison branch, installed
> the new 1.1 eclipse plugin and now whenever I try to setup the Yocto
> eclipse environment I receive the following error:
>
> Yocto Preferences Configuration Error!
> OECORE related items are not found in envrionement setup files.
> The ADT version you're using is too old.
> Please upgrade to our latest ADT Version!
>
> This pops up in a message box, not the eclipse console. I have
> followed the ADT Setup guide to the letter and it's not playing ball -
> could someone confirm this as working or point me towards a reason why
> I may be getting this error?
>
> Cheers,
> Jack.
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
This is a pastebin of my current environment setup file:
http://pastebin.com/4vnWPAD2
[-- Attachment #2: Type: text/html, Size: 2070 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 9:23 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Grant Likely, patches, tony, devicetree-discuss, broonie,
linux-kernel, linux-arm-kernel, linux-omap, lrg
In-Reply-To: <4EA5279E.3000505@ti.com>
On Mon, Oct 24, 2011 at 02:23:50PM +0530, Rajendra Nayak wrote:
> On Monday 24 October 2011 01:47 PM, Grant Likely wrote:
> >On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
> >>On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
> >>>On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
> >>>[...]
> >>>>>+ /* find device_node and attach it */
> >>>>>+ rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
>
> Shawn/Mark,
>
> How about the driver passing the of_node to be associated with the
> regulator, as part of regulator_desc, to the regulator core,
> instead of this complete DT search and the restriction of having
> to match DT node names with names in regulator_desc.
>
If you agree that we should try to get DT core from creating
'struct dev' for each regulator, the of_node is not being attached
to any 'struct dev' in regulator driver either, so there is no
difference between finding the of_node in regulator driver and in
regulator core.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 1/5] ARM: SPMP8000: Add machine base files
From: Arnd Bergmann @ 2011-10-24 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGVye5PR3rDbGOf48sPtnZHJXPCa_eY1JqeUZKyeLGk4s_LNHA@mail.gmail.com>
On Sunday 23 October 2011, Zoltan Devai wrote:
> 2011/10/19 Arnd Bergmann <arnd@arndb.de>:
> > On Wednesday 19 October 2011 18:01:54 Zoltan Devai wrote:
> >> Files needed for the basic machine support of SPMP8000
> >>
> >> Signed-off-by: Zoltan Devai <zoss@devai.org>
> >
> > Hi Zoltan,
> >
> > This version looks very nice, only a few small things remain that I noticed
> > reading through it again:
> OK, will correct these.
>
> What's next then ?
We talked about it at the ARM subarchitecture maintainer summit, and I think
I'll just merge your platform code for 3.2 if you send the fixed version
in time. I'm not going to merge your clk support patch (2/5) though, since
there is a lot of work going into the common clk framework right now, and
I don't want to cause more work going into rewriting your code.
Please instead replace that patch with a stubbed-out version that builds
but doesn't actually do anything. Obviously you won't be able to run on
actual hardware then but you still have the patch you did and know how to
apply it for testing ;-).
> I assume I'd need some more review on at least the dts file.
It seems all good to me, but I would definitely appreciate Grant and Rob
to take a closer look.
> Also, can the timer code go through your tree into drivers/clocksource ?
It can, but it needs an Acked-by from John and/or Thomas in that case.
Alternatively, feel free to stick my acked-by on the patch and have
Thomas handle the patch.
Arnd
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-10-24 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024091158.GB1755@S2100-06.ap.freescale.net>
On Monday 24 October 2011 02:41 PM, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 02:26:49PM +0530, Rajendra Nayak wrote:
>> On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
>>> Okay, it's wrong then since so many people say it's wrong :) I guess
>>> a quick fix would be adding one property in device tree node for
>>> matching some unique field in regulator_desc, id, maybe? Mark, any
>>> suggestion?
>>
>> Thats basically what the DT compatible property is for :)
>
> But adding compatible property will get DT core create 'struct dev'
> for each regulator node, while we are trying to avoid that since
> regulator core has been doing this.
>
No it won't.
So here's what I am suggesting.
Case 1:
One device per regulator:
DT nodes look something like this
reg1: reg at 1 {
...
...
};
reg2: reg at 2 {
...
...
};
The regulator driver probes 2 devices and each time the
dev passed has a of_node associated which the regulator
driver can then pass to the core.
Case 2:
One device for all regulators:
DT nodes look something like this
regulators {
reg1: reg at 1 {
...
...
};
reg2: reg at 2 {
...
...
};
};
The regulator driver probes only one device and the dev->of_node
points to the "regulators" node above.
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.
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-10-24 9:13 UTC (permalink / raw)
To: Shawn Guo
Cc: Grant Likely, broonie, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024091158.GB1755@S2100-06.ap.freescale.net>
On Monday 24 October 2011 02:41 PM, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 02:26:49PM +0530, Rajendra Nayak wrote:
>> On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
>>> Okay, it's wrong then since so many people say it's wrong :) I guess
>>> a quick fix would be adding one property in device tree node for
>>> matching some unique field in regulator_desc, id, maybe? Mark, any
>>> suggestion?
>>
>> Thats basically what the DT compatible property is for :)
>
> But adding compatible property will get DT core create 'struct dev'
> for each regulator node, while we are trying to avoid that since
> regulator core has been doing this.
>
No it won't.
So here's what I am suggesting.
Case 1:
One device per regulator:
DT nodes look something like this
reg1: reg@1 {
...
...
};
reg2: reg@2 {
...
...
};
The regulator driver probes 2 devices and each time the
dev passed has a of_node associated which the regulator
driver can then pass to the core.
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 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.
^ permalink raw reply
* Re: [PATCH 8/8] xfstests: add new quota stress test
From: Christoph Hellwig @ 2011-10-24 9:14 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: linux-fsdevel, xfs, linux-ext4, jack, hch, aelder
In-Reply-To: <1319020189-13584-9-git-send-email-dmonakhov@openvz.org>
Same comment about the subject as the previous one.
Also please use su as xfstest currently doesn't use and require sudo.
Also please use $qa_user instead of using fsgqa directly.
^ permalink raw reply
* Re: [PATCH 8/8] xfstests: add new quota stress test
From: Christoph Hellwig @ 2011-10-24 9:14 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: jack, xfs, hch, aelder, linux-fsdevel, linux-ext4
In-Reply-To: <1319020189-13584-9-git-send-email-dmonakhov@openvz.org>
Same comment about the subject as the previous one.
Also please use su as xfstest currently doesn't use and require sudo.
Also please use $qa_user instead of using fsgqa directly.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Linus Walleij @ 2011-10-24 9:14 UTC (permalink / raw)
To: Ulf Hansson
Cc: Sebastian Rasmussen, Russell King - ARM Linux,
linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Lee Jones
In-Reply-To: <4EA51C4A.7040802@stericsson.com>
On Mon, Oct 24, 2011 at 10:05 AM, Ulf Hansson
<ulf.hansson@stericsson.com> wrote:
> The hole idea with this PM patch is to make sure the vcore regulator and the
> clock are disabled in runtime_suspend to be able to save a huge amount of
> current in "idle" mode.
>
> Disabling the vcore regulator will sooner or later (depending on your
> regulator tree) mean that that power to the controller is actually cut,
> which then means that all registers will be "cleared" including the MCIPWR.
I guess since this means writing power-off to bits 1 and 0 of
of MCIPower meaning "power off" it should not be done unless the MMC
core has first issued mmci_set_ios() with MMC_POWER_OFF set in
ios->power_mode. Which means mmc_power_off() must have
been called.
That in turn is called by mmc_power_save_host() or
mmc_suspend_host().
mmc_power_save_host() is in turn called by
mmc_runtime_suspend() in drivers/mmc/bus.c!
So if that is called *before* the driver-local runtime suspend
calls, you're actually on the safe side, and you can
proceed to cut the power.
So these need to be zero before we enter runtime suspend.
This could then be assured by:
if (readl(host->base + MMCIPOWER) & 3)
return -EBUSY;
If this has already been done we are on the green and can
runtime suspend the controller I guess?
So what this code
> + /* Save registers for POWER, CLOCK and IRQMASK0 */
> + host->irqmask0_reg = readl(host->base + MMCIMASK0);
> + host->pwr_reg = readl(host->base + MMCIPOWER);
> + host->clk_reg = readl(host->base + MMCICLOCK);
In the end does is save the contents of the other 30 bits.
(MCI_OD, MCI_ROD, and the ST-specific bits)
So can we first:
- Assure that mmc_power_save_host() has already been
done (MMCI_POWER_OFF)
- Make this variable a prerequiste for cutting the power in
runtime_pm?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Linus Walleij @ 2011-10-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA51C4A.7040802@stericsson.com>
On Mon, Oct 24, 2011 at 10:05 AM, Ulf Hansson
<ulf.hansson@stericsson.com> wrote:
> The hole idea with this PM patch is to make sure the vcore regulator and the
> clock are disabled in runtime_suspend to be able to save a huge amount of
> current in "idle" mode.
>
> Disabling the vcore regulator will sooner or later (depending on your
> regulator tree) mean that that power to the controller is actually cut,
> which then means that all registers will be "cleared" including the MCIPWR.
I guess since this means writing power-off to bits 1 and 0 of
of MCIPower meaning "power off" it should not be done unless the MMC
core has first issued mmci_set_ios() with MMC_POWER_OFF set in
ios->power_mode. Which means mmc_power_off() must have
been called.
That in turn is called by mmc_power_save_host() or
mmc_suspend_host().
mmc_power_save_host() is in turn called by
mmc_runtime_suspend() in drivers/mmc/bus.c!
So if that is called *before* the driver-local runtime suspend
calls, you're actually on the safe side, and you can
proceed to cut the power.
So these need to be zero before we enter runtime suspend.
This could then be assured by:
if (readl(host->base + MMCIPOWER) & 3)
return -EBUSY;
If this has already been done we are on the green and can
runtime suspend the controller I guess?
So what this code
> + /* Save registers for POWER, CLOCK and IRQMASK0 */
> + host->irqmask0_reg = readl(host->base + MMCIMASK0);
> + host->pwr_reg = readl(host->base + MMCIPOWER);
> + host->clk_reg = readl(host->base + MMCICLOCK);
In the end does is save the contents of the other 30 bits.
(MCI_OD, MCI_ROD, and the ST-specific bits)
So can we first:
- Assure that mmc_power_save_host() has already been
done (MMCI_POWER_OFF)
- Make this variable a prerequiste for cutting the power in
runtime_pm?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Mike Frysinger @ 2011-10-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdatiBathcoo2VjKs9jHJiKC5trDCJ0bePX1q6KbrYRN-g@mail.gmail.com>
On Mon, Oct 24, 2011 at 03:26, Linus Walleij wrote:
> On Sat, Oct 22, 2011 at 7:44 PM, Mike Frysinger wrote:
>> On Tue, Oct 4, 2011 at 16:35, Grant Likely wrote:
>>> On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote:
>>>> 2011/9/30 Grant Likely:
>>>> >?I'm not convinced that the sysfs approach is
>>>> > actually the right interface here (I'm certainly not a fan of the gpio
>>>> > sysfs i/f), and I'd rather not be putting in unneeded stuff until the
>>>> > userspace i/f is hammered out.
>>>>
>>>> Actually, thinking about it I cannot see what would be wrong
>>>> with /dev/gpio0 & friends in the first place.
>>>>
>>>> Using sysfs as swiss army knife for custom I/O does not
>>>> seem like it would be long-term viable so thanks for this
>>>> observation, and I think we need /dev/gpio* put on some
>>>> mental roadmap somewhere.
>>>
>>> Agreed. ?I don't want to be in the situation we are now with GPIO,
>>> where every time I look at the sysfs interface I shudder.
>>
>> the problem with that is it doesn't scale. ?if i have a device with
>> over 150 GPIOs on the SoC itself (obviously GPIO expanders can make
>> that much bigger), i don't want to see 150+ device nodes in /dev/.
>> that's a pretty big waste. ?sysfs only allocates/frees resources when
>> userspace actually wants to utilize a GPIO.
>
> I was more thinking along the lines of one device per GPIO controller,
> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
that brings its own set of trade offs. this might be OK from a
debugging point of view, but it means security wise we have to grant
access on a per-gpiochip basis instead of a per-gpio basis. i think
the sysfs interface has this granularity of support already as the
root user can chmod/chown the files after exporting them.
Grant suggested we extend UIO to export GPIOs. this would be a good
trade off i think -- sysfs is a good on-the-fly debugging/scripting
interface, but UIO gets us the performance. sysfs overhead can be
mitigated by using pwrite/pread, but without pwritev/preadv, we're
stuck with 1-transition-per-syscall.
-mike
^ permalink raw reply
* Re: [PATCH] staging: iio: light: Fix compiler warning in tsl2563.c
From: Jonathan Cameron @ 2011-10-24 9:14 UTC (permalink / raw)
To: Dan Carpenter
Cc: Maxin B John, Jonathan Cameron, Dan Carpenter, Bryan Freed,
public-linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
public-linux-iio-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
public-devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Amit Kucheria
In-Reply-To: <20111024090143.GB3526@mwanda>
On 10/24/11 10:01, Dan Carpenter wrote:
> On Mon, Oct 24, 2011 at 09:51:28AM +0100, Jonathan Cameron wrote:
>>>>> Signed-off-by: Maxin B. John <maxin.john-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Acked-by: Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
>>>>
>>>
>>> Sorry for the delay in replying to this mail. I am curious about the
>>> status of this patch. I couldn't locate this patch at iio-blue.git as
>>> it is not present in kernel.org now
>>> (http://git.kernel.org/?p=linux/kernel/git/jic23/iio-blue.git;a=summary)
>>> Please ignore this mail if you have already added this patch to your tree.
>> Ah, sorry I slipped up here and should have noticed it didn't go directly to
>> Greg. Just to check, with everyone I have author as Dan, reporter as Maxin
>> and have signed off myself (it's going through my tree anyway now).
>>
>> I think from looking back it was Dan's suggestion in response to Maxin's
>> patch. Hence convention would be a sign off from Dan and perhaps an
>> Ack from Maxin?
>>
>
> Maxim is the author. He didn't resend this in the proper way so it
> was confusing... Can you give me a Reviewed-by tag?
>
> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
>
Sure.
^ permalink raw reply
* Re: [PATCH] drivers: create a pin control subsystem v8
From: Mike Frysinger @ 2011-10-24 9:14 UTC (permalink / raw)
To: Linus Walleij
Cc: Grant Likely, Linus Walleij, Stephen Warren, Sascha Hauer,
Barry Song, linux-kernel, Joe Perches, Russell King, Linaro Dev,
Lee Jones, David Brown, linux-arm-kernel, Stijn Devriendt
In-Reply-To: <CACRpkdatiBathcoo2VjKs9jHJiKC5trDCJ0bePX1q6KbrYRN-g@mail.gmail.com>
On Mon, Oct 24, 2011 at 03:26, Linus Walleij wrote:
> On Sat, Oct 22, 2011 at 7:44 PM, Mike Frysinger wrote:
>> On Tue, Oct 4, 2011 at 16:35, Grant Likely wrote:
>>> On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote:
>>>> 2011/9/30 Grant Likely:
>>>> > I'm not convinced that the sysfs approach is
>>>> > actually the right interface here (I'm certainly not a fan of the gpio
>>>> > sysfs i/f), and I'd rather not be putting in unneeded stuff until the
>>>> > userspace i/f is hammered out.
>>>>
>>>> Actually, thinking about it I cannot see what would be wrong
>>>> with /dev/gpio0 & friends in the first place.
>>>>
>>>> Using sysfs as swiss army knife for custom I/O does not
>>>> seem like it would be long-term viable so thanks for this
>>>> observation, and I think we need /dev/gpio* put on some
>>>> mental roadmap somewhere.
>>>
>>> Agreed. I don't want to be in the situation we are now with GPIO,
>>> where every time I look at the sysfs interface I shudder.
>>
>> the problem with that is it doesn't scale. if i have a device with
>> over 150 GPIOs on the SoC itself (obviously GPIO expanders can make
>> that much bigger), i don't want to see 150+ device nodes in /dev/.
>> that's a pretty big waste. sysfs only allocates/frees resources when
>> userspace actually wants to utilize a GPIO.
>
> I was more thinking along the lines of one device per GPIO controller,
> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
that brings its own set of trade offs. this might be OK from a
debugging point of view, but it means security wise we have to grant
access on a per-gpiochip basis instead of a per-gpio basis. i think
the sysfs interface has this granularity of support already as the
root user can chmod/chown the files after exporting them.
Grant suggested we extend UIO to export GPIOs. this would be a good
trade off i think -- sysfs is a good on-the-fly debugging/scripting
interface, but UIO gets us the performance. sysfs overhead can be
mitigated by using pwrite/pread, but without pwritev/preadv, we're
stuck with 1-transition-per-syscall.
-mike
^ permalink raw reply
* Re: [PATCH 2/8] xfstests: add different logging option to fsstress
From: Christoph Hellwig @ 2011-10-24 9:15 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: linux-fsdevel, xfs, linux-ext4, jack, hch, aelder
In-Reply-To: <1319020189-13584-3-git-send-email-dmonakhov@openvz.org>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ 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.