* Re: [PATCH] KVM: MMU: initialize sptes early
From: Zhao Jin @ 2011-10-24 9:01 UTC (permalink / raw)
To: Xiao Guangrong; +Cc: avi, mtosatti, linux-kernel, kvm
In-Reply-To: <4EA516C6.1010706@qq.com>
2011/10/24 Xiao Guangrong <xiao.guangrong@qq.com>:
> On 2011/10/24 15:21, Zhao Jin wrote:
>> Otherwise, the following kvm_sync_pages() will see invalid sptes in a new
>> shadow page.
>>
>
> No, kvm_sync_pages just handle the unsync page, but the new sp is the sync page.
>
Sorry, I didn't notice the sp itself was zero-ed when allocated hence
was considered as synced. Please ignore this patch.
Thanks for the remainder.
^ 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
* Re: nouveau KMS fails with Vanta TNT2-M64
From: Meelis Roos @ 2011-10-24 8:41 UTC (permalink / raw)
To: Linux Kernel list, Ben Skeggs; +Cc: Francisco Jerez, Dave Airlie
In-Reply-To: <alpine.SOC.1.00.1110241019510.16192@math.ut.ee>
> got an old Nvidia card, Vanta/TNT2-M64. Without KMS, text console and X
> work fine. With modeset=1, KMS logs a lot of errors and X screen is
> garbled (mostly understabdable but vertical bands of compressed double
> image and some horizontal distortions - sorry, no camera here with me
> today). Some other nvidia and radeon cards work fine in this computer.
Sorry for bad report - it actually produces no image at all on screen
after KMS has been initialized. Otherwise the machine remains usable.
The garbled screen was another card with radeon driver - will
investigate some before reporting that one.
--
Meelis Roos (mroos@ut.ee) http://www.cs.ut.ee/~mroos/
^ permalink raw reply
* [U-Boot] DUTS without hardware
From: Mike Frysinger @ 2011-10-24 9:00 UTC (permalink / raw)
To: u-boot
so u-boot has DUTS for testing:
http://www.denx.de/wiki/DUTS/
it seems to have a lot of assumptions like connecting to u-boot over
the serial port. i'd like to extend this to support the new sandbox
target so we can do automated testing of common code without needing
any external hardware at all.
before i start digging too more, is this going to be painful to the
point of not being feasible ?
-mike
^ permalink raw reply
* TI OMAP4430 - UHS support
From: Manoharan Vijaya Raghavan @ 2011-10-24 8:56 UTC (permalink / raw)
To: linux-omap
Hi,
I need your help in writing a UHS-I driver for OMAP4430.
I would like to know the feasibility in implementing a UHS-I driver (for SD
card) in OMAP4430. (I am using Pandaboard).
The purpose is to have readspeed more than 40MB/s for SD cards (Which as per
the SD card specification 3.01 is possible only in UHS-I mode).
For this I see that OMAP4430 supports 1.8V and DDR50 mode also.
Please let me know your informed opinion about whether UHS-I can be
implemented for Pandaboard.
I am having trouble in switching to UHS-I mode in Pandaboard.
Following are my queries.
I am using an SD card which does support UHS-I mode. (Sandisk UHS Extreme Pro
(45 MB/s quoted speed))
I am trying to switch the card to UHS mode by first sending a ACMD41.
For this I have modified the mmc_send_app_op_cond () in
drivers/mmc/core/sd_ops.c to set the S18R bit.
And in the response from the SD card I see that S18A bit is
set.
After this response response from the SD Card I am sending CMD11 to SD Card.
After receiving the response from SD Card I am changing the SDVS in MMCHS_HCTL
to 0x5 which is for 1.8V.(As per mentioned in the Specification).
However I am not able to read the DLEV as 0xF from PSTATE register as per
mentioned in the OMAP4430 specification.
Please let me know what I might be missing.
Is there is a possbility that we could achieve 40MB/s of read speed in SD mode
without using the UHS-I ?
We see in the spec that it does support upto 48MB/s in DDR mode.
But as per the SD card specification 3.01 DDR mode is supported only in UHS-I
mode.
This is the reason I am trying to switch the card to UHS-I mode.
Please let me know if there is a way to use DDR mode in Pandaboard for SD
card without having to switch to UHS-I to achieve read speeds of around 40MB/s.
with thanks,
V.Manoharan
^ permalink raw reply
* I Need instructional video,Thanks
From: 李金成 @ 2011-10-24 8:59 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
Hi everyone!
I'm a chineses,I can't view instructional videos inhttp://vimeo.com and http://www.youtube.com,because we can,t connect this web in China.So pls give us thoses instructional videos in another way.
Chineases Thans you verymuch!
[-- Attachment #2: Type: text/html, Size: 467 bytes --]
^ permalink raw reply
* Re: lvs-users mailing list and archive dead?
From: Graeme Fowler @ 2011-10-24 8:58 UTC (permalink / raw)
To: Tomasz Chmielewski; +Cc: lvs-devel
In-Reply-To: <4EA525B4.1030601@wpkg.org>
On Mon, 2011-10-24 at 10:45 +0200, Tomasz Chmielewski wrote:
> On 24.10.2011 10:32, Graeme Fowler wrote:
> > Can you please tell me which IP netblock these queries are originating
> > from? I smell a previously unallocated (to an RIR) block which is in my
> > bogons list.
>
> I.e. 178.63.195.*, 178.63.11.*, 46.4.130.*, 46.4.96.124, 46.4.115.*,
> 176.9.54.*.
Yep, that was it - I had a terribly outdated bogons filter in my
named.conf which had been pulled in via my poor revision control system
(that is, I copied an old version in from a rather old named.conf when
rebuilding servers a few months ago).
Sorry - and thanks for the heads up!
Graeme
^ permalink raw reply
* Re: Building for TI 8148 EVM
From: Koen Kooi @ 2011-10-24 8:58 UTC (permalink / raw)
To: Rainer Koenig; +Cc: meta-ti@yoctoproject.org
In-Reply-To: <4EA5266C.4080002@ts.fujitsu.com>
Op 24 okt. 2011, om 10:48 heeft Rainer Koenig het volgende geschreven:
> Koen,
>
> Am 21.10.2011 11:14, schrieb Koen Kooi:
>
>>> I'm currently trying to build an image for the TI 8148 EVM board. For
>>> that I added the meta-ti layer to the standard Yocto/Edison environment.
>>
>> Please follow the instructions detailed in the meta-ti README: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/README
>>
>> Yocto/Poky lacks support for various meta-ti (and OE-classic) constructs needed for a successfull build. Following the instructions above you will get a proper setup.
>
> Tried this over the weekend on my home PC. Yes, works. But I was just
> able to build a console image. The build of systemd-gnome-image fails
> with the error that nothing provides "DRI". MACHINE=dm8148-evm.
I'm not seeing that with this set of metadata:
OE Build Configuration:
BB_VERSION = "1.13.3"
TARGET_ARCH = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE = "dm814x-evm"
DISTRO = "angstrom"
DISTRO_VERSION = "v2011.10-core"
TUNE_FEATURES = "armv7a vfp neon cortexa8"
TARGET_FPU = "vfp-neon"
meta-angstrom = "master:14f73c63403525f85a15f61f88895ba377364338"
meta-oe
meta-efl
meta-gpe
meta-gnome
meta-xfce = "master:5da48e6e4a4ab0488943c5e93f005211bd7a22f7"
meta-ti = "master:2ea9f93740259be7eee59edeb88e632c5441fb58"
meta-ettus = "master:617506b5cfd2b8325d85f0dcba0232c3f796d044"
meta-efikamx = "master:2ef47fdd4e8232d766c0c63d9427253ee56e31d0"
meta-nslu2 = "master:17853811179f2760791c6b138f96e9dd15493517"
meta-htc
meta-nokia
meta-openmoko
meta-palm = "oe-core:794b32d234dbf7e6626c8a0efc915fc04804b9d0"
meta-sugarbay
meta-crownbay
meta-emenlow
meta-fishriver
meta-jasperforest
meta-n450 = "master:0ea04b02119c44865e5e1c2529c74950928c3347"
meta = "master:99da9a4e65f9dffb04efc3ad60125194c476d6b3"
Could you please share your version of that so we can see if there are fixes missing?
regards,
Koen
^ permalink raw reply
* Re: [PATCH] staging:iio:treewide only use shared to decide on interfaces
From: Lars-Peter Clausen @ 2011-10-24 8:58 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: linux-iio, michael.hennerich, device-drivers-devel
In-Reply-To: <4EA522D3.9000906@cam.ac.uk>
On 10/24/2011 10:33 AM, Jonathan Cameron wrote:
> On 10/24/11 09:30, Lars-Peter Clausen wrote:
>> On 10/21/2011 05:39 PM, Jonathan Cameron wrote:
>>> Internally the fact that say scale is shared across channels is
>>> actually of remarkably little interest. Hence lets not store it.
>>> Numerous devices have weird combinations of channels sharing
>>> scale anyway so it is not as though this was really telling
>>> us much. Note however that we do still use the shared sysfs
>>> attrs thus massively reducing the number of attrs in complex
>>> drivers.
>>>
>>> Side effect is that certain drivers that were abusing this
>>> (mostly my work) needed to do a few more checks on what the
>>> channel they are being queried on actually is.
>>>
>>> This is also helpful for in kernel interfaces where we
>>> just want to query the scale and don't care whether it
>>> is shared with other channels or not.
>>>
>>> Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
>>
>> Hi
>>
>> Seems to work. I think it makes sense to submit this one and the other,
>> which removes the bitmask addressing, together. Will you take care of this?
> Yes. Might take a few days to hit though as I would guess Greg is going
> to be busy at the kernel summit.
>
> Are you happy to Ack this patch or if not give a tested-by.
> Whilst I can push stuff on without review to Greg, I always prefer not to!
>
> Jonathan
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-10-24 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024090228.GA1755@S2100-06.ap.freescale.net>
On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 10:17:06AM +0200, 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);
>>>>>
>>>>> so would this do a complete dt search for every regulator?
>>>>
>>>> Yes, with the first param being NULL, tthe entire device tree will be
>>>> searched.
>>>>
>>>>> we would also need the driver names and dt names to match for this to
>>>>> work, right?
>>>>>
>>>> Driver name does not matter. The key for this search to work is having
>>>> regulator's name (regulator_desc->name) match device tree node's name,
>>>> case ignored.
>>>
>>> Mark, whats your take on this? I am somehow not quite sure if we should
>>> have this limitation put in to match DT node names with whats in the
>>> driver structs (regulator_desc).
>>
>> This looks wrong to me. Matching based on node /name/, particularly
>> when searching the entire tree, will cause problems.
>>
> 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 :)
>
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-10-24 8:56 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: <20111024090228.GA1755@S2100-06.ap.freescale.net>
On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 10:17:06AM +0200, 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);
>>>>>
>>>>> so would this do a complete dt search for every regulator?
>>>>
>>>> Yes, with the first param being NULL, tthe entire device tree will be
>>>> searched.
>>>>
>>>>> we would also need the driver names and dt names to match for this to
>>>>> work, right?
>>>>>
>>>> Driver name does not matter. The key for this search to work is having
>>>> regulator's name (regulator_desc->name) match device tree node's name,
>>>> case ignored.
>>>
>>> Mark, whats your take on this? I am somehow not quite sure if we should
>>> have this limitation put in to match DT node names with whats in the
>>> driver structs (regulator_desc).
>>
>> This looks wrong to me. Matching based on node /name/, particularly
>> when searching the entire tree, will cause problems.
>>
> 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 :)
>
^ permalink raw reply
* 莎拉的钥匙
From: anitjrhh @ 2011-10-24 8:55 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 236 bytes --]
代##å¼€~~~~發ï¼ï¼ï¼çžŸ****** æž—-生 137-5119-1674 QQ 643-994-956
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-10-24 8:53 UTC (permalink / raw)
To: Grant Likely
Cc: Shawn Guo, broonie, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024081706.GC8708@ponder.secretlab.ca>
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.
regards,
Rajendra
>>>>
>>>> so would this do a complete dt search for every regulator?
>>>
>>> Yes, with the first param being NULL, tthe entire device tree will be
>>> searched.
>>>
>>>> we would also need the driver names and dt names to match for this to
>>>> work, right?
>>>>
>>> Driver name does not matter. The key for this search to work is having
>>> regulator's name (regulator_desc->name) match device tree node's name,
>>> case ignored.
>>
>> Mark, whats your take on this? I am somehow not quite sure if we should
>> have this limitation put in to match DT node names with whats in the
>> driver structs (regulator_desc).
>
> This looks wrong to me. Matching based on node /name/, particularly
> when searching the entire tree, will cause problems.
>
> g.
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-10-24 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024081706.GC8708@ponder.secretlab.ca>
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.
regards,
Rajendra
>>>>
>>>> so would this do a complete dt search for every regulator?
>>>
>>> Yes, with the first param being NULL, tthe entire device tree will be
>>> searched.
>>>
>>>> we would also need the driver names and dt names to match for this to
>>>> work, right?
>>>>
>>> Driver name does not matter. The key for this search to work is having
>>> regulator's name (regulator_desc->name) match device tree node's name,
>>> case ignored.
>>
>> Mark, whats your take on this? I am somehow not quite sure if we should
>> have this limitation put in to match DT node names with whats in the
>> driver structs (regulator_desc).
>
> This looks wrong to me. Matching based on node /name/, particularly
> when searching the entire tree, will cause problems.
>
> g.
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-10-24 8:53 UTC (permalink / raw)
To: Grant Likely
Cc: patches, tony, devicetree-discuss, broonie, linux-kernel,
linux-arm-kernel, linux-omap, lrg, Shawn Guo
In-Reply-To: <20111024081706.GC8708@ponder.secretlab.ca>
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.
regards,
Rajendra
>>>>
>>>> so would this do a complete dt search for every regulator?
>>>
>>> Yes, with the first param being NULL, tthe entire device tree will be
>>> searched.
>>>
>>>> we would also need the driver names and dt names to match for this to
>>>> work, right?
>>>>
>>> Driver name does not matter. The key for this search to work is having
>>> regulator's name (regulator_desc->name) match device tree node's name,
>>> case ignored.
>>
>> Mark, whats your take on this? I am somehow not quite sure if we should
>> have this limitation put in to match DT node names with whats in the
>> driver structs (regulator_desc).
>
> This looks wrong to me. Matching based on node /name/, particularly
> when searching the entire tree, will cause problems.
>
> g.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Kevin Wolf @ 2011-10-24 8:54 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Alexander Graf, qemu-devel, avi
In-Reply-To: <4EA5262D.7090901@redhat.com>
Am 24.10.2011 10:47, schrieb Paolo Bonzini:
> On 10/24/2011 10:17 AM, Kevin Wolf wrote:
>>> 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."
>
> Fair enough.
>
>> But I think that starting to make exceptions for single block drivers
>> isn't a good idea anyway. If we want bdrv_flush() to write out all
>> metadata internal to qemu, I think the approach with checking the flag
>> in drivers calling things like fsync() is better. The common thing is to
>> do the flush.
>
> I don't know... checking BDRV_O_NO_FLUSH in the drivers rather than in
> the generic code sounds like a layering violation. Perhaps what you're
> after is a separation of bdrv_co_flush from bdrv_{,co_,aio_}fsync? Then
> BDRV_O_NO_FLUSH (better renamed to BDRV_O_NO_FSYNC...) would only
> inhibit the latter.
Why? All other cache related BDRV_O_* flags are interpreted by the block
drivers, so why should BDRV_O_NO_FLUSH be special?
Kevin
^ permalink raw reply
* Re: [PATCH] staging: iio: light: Fix compiler warning in tsl2563.c
From: Jonathan Cameron @ 2011-10-24 8:51 UTC (permalink / raw)
To: Maxin B John
Cc: 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: <CAMhs6Yzw3-CARTULhy4s-Re4Q82Ek9gZGUQtABLLs0PSArHCuw@mail.gmail.com>
On 10/22/11 06:15, Maxin B John wrote:
> Hi,
>
> On Fri, Sep 2, 2011 at 1:55 PM, Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org> wrote:
>> On 09/02/11 10:41, Maxin B. John wrote:
>>>> Don't overwrite the error code. For example, the lower layers can
>>>> return -EAGAIN and that's more useful than just returning -EIO every
>>>> time.
>>> Ahh.. Thanks a lot for explaining this.
>>>
>>>> Your fix works, but it's not very clean. Just add a "*id = ret;"
>>>> line before the "return 0;" and that's it. (It doesn't make sense
>>>> to pass a pointer to "id" and not use it).
>>> Dan, yes, I agree with you. This fix is much much better than what I
>>> had in my mind.
>>>
>>>> Yikes - I wonder why my various compilers don't throw that up.
>>> I guess, in "iio-blue.git" tree, the 'id = 0' suppresses this warning.
>> That'd do it. oops.
>>
>> Ideally keep the white space but doesn't really matter. Either send on
>> to Greg directly or I'll add it to iio-blue and send on with the next fixes
>> series - probably this afternoon.
>>>
>>> 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?
Jonathan
>From c33a01010decf686f5f2984d2ed04c1a70e18bc3 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 24 Oct 2011 09:46:32 +0100
Subject: [PATCH] staging:iio:light:tsl2563 missing setting of id in get id
function.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Reported-by: Maxin B. John <maxin.john@gmail.com>
---
drivers/staging/iio/light/tsl2563.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/iio/light/tsl2563.c b/drivers/staging/iio/light/tsl2563.c
index 5cee5ca..45d04a1 100644
--- a/drivers/staging/iio/light/tsl2563.c
+++ b/drivers/staging/iio/light/tsl2563.c
@@ -227,6 +227,8 @@ static int tsl2563_read_id(struct tsl2563_chip *chip, u8 *id)
if (ret < 0)
return ret;
+ *id = ret;
+
return 0;
}
--
1.7.7
^ permalink raw reply related
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 9:02 UTC (permalink / raw)
To: Grant Likely
Cc: Rajendra Nayak, broonie, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024081706.GC8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 10:17:06AM +0200, 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);
> > >>
> > >>so would this do a complete dt search for every regulator?
> > >
> > >Yes, with the first param being NULL, tthe entire device tree will be
> > >searched.
> > >
> > >>we would also need the driver names and dt names to match for this to
> > >>work, right?
> > >>
> > >Driver name does not matter. The key for this search to work is having
> > >regulator's name (regulator_desc->name) match device tree node's name,
> > >case ignored.
> >
> > Mark, whats your take on this? I am somehow not quite sure if we should
> > have this limitation put in to match DT node names with whats in the
> > driver structs (regulator_desc).
>
> This looks wrong to me. Matching based on node /name/, particularly
> when searching the entire tree, will cause problems.
>
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?
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH] staging: iio: light: Fix compiler warning in tsl2563.c
From: Jonathan Cameron @ 2011-10-24 8:51 UTC (permalink / raw)
To: Maxin B John
Cc: 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: <CAMhs6Yzw3-CARTULhy4s-Re4Q82Ek9gZGUQtABLLs0PSArHCuw@mail.gmail.com>
On 10/22/11 06:15, Maxin B John wrote:
> Hi,
>
> On Fri, Sep 2, 2011 at 1:55 PM, Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org> wrote:
>> On 09/02/11 10:41, Maxin B. John wrote:
>>>> Don't overwrite the error code. For example, the lower layers can
>>>> return -EAGAIN and that's more useful than just returning -EIO every
>>>> time.
>>> Ahh.. Thanks a lot for explaining this.
>>>
>>>> Your fix works, but it's not very clean. Just add a "*id = ret;"
>>>> line before the "return 0;" and that's it. (It doesn't make sense
>>>> to pass a pointer to "id" and not use it).
>>> Dan, yes, I agree with you. This fix is much much better than what I
>>> had in my mind.
>>>
>>>> Yikes - I wonder why my various compilers don't throw that up.
>>> I guess, in "iio-blue.git" tree, the 'id = 0' suppresses this warning.
>> That'd do it. oops.
>>
>> Ideally keep the white space but doesn't really matter. Either send on
>> to Greg directly or I'll add it to iio-blue and send on with the next fixes
>> series - probably this afternoon.
>>>
>>> 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?
Jonathan
>>From c33a01010decf686f5f2984d2ed04c1a70e18bc3 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 24 Oct 2011 09:46:32 +0100
Subject: [PATCH] staging:iio:light:tsl2563 missing setting of id in get id
function.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Reported-by: Maxin B. John <maxin.john@gmail.com>
---
drivers/staging/iio/light/tsl2563.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/iio/light/tsl2563.c b/drivers/staging/iio/light/tsl2563.c
index 5cee5ca..45d04a1 100644
--- a/drivers/staging/iio/light/tsl2563.c
+++ b/drivers/staging/iio/light/tsl2563.c
@@ -227,6 +227,8 @@ static int tsl2563_read_id(struct tsl2563_chip *chip, u8 *id)
if (ret < 0)
return ret;
+ *id = ret;
+
return 0;
}
--
1.7.7
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] monitor: refactor whitespace and optional argument parsing
From: Markus Armbruster @ 2011-10-24 8:49 UTC (permalink / raw)
To: Alon Levy; +Cc: qemu-devel
In-Reply-To: <1319136227-7520-1-git-send-email-alevy@redhat.com>
Alon Levy <alevy@redhat.com> writes:
> Takes out the optional ('?') message parsing from the main switch loop
> in monitor_parse_command. Adds optional argument option for boolean parameters.
>
> Signed-off-by: Alon Levy <alevy@redhat.com>
> ---
> Previous patch used qemu_free (that's how old it is), fixed.
>
> monitor.c | 79 +++++++++++++++++++++++-------------------------------------
> 1 files changed, 30 insertions(+), 49 deletions(-)
>
> diff --git a/monitor.c b/monitor.c
> index ffda0fe..a482705 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -3976,6 +3976,29 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
> break;
> c = *typestr;
> typestr++;
> + while (qemu_isspace(*p)) {
> + p++;
> + }
> + /* take care of optional arguments */
> + switch (c) {
> + case 's':
> + case 'i':
> + case 'l':
> + case 'M':
> + case 'o':
> + case 'T':
> + case 'b':
> + if (*typestr == '?') {
> + typestr++;
> + if (*p == '\0') {
> + /* missing optional argument: NULL argument */
> + g_free(key);
> + key = NULL;
> + continue;
> + }
> + }
> + break;
> + }
> switch(c) {
> case 'F':
> case 'B':
> @@ -3983,15 +4006,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
> {
> int ret;
>
> - while (qemu_isspace(*p))
> - p++;
> - if (*typestr == '?') {
> - typestr++;
> - if (*p == '\0') {
> - /* no optional string: NULL argument */
> - break;
> - }
> - }
> ret = get_str(buf, sizeof(buf), &p);
> if (ret < 0) {
> switch(c) {
This is cases 'F', 'B' and 's'. I'm afraid your new code covers only
's'.
> @@ -4021,9 +4035,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
> if (!opts_list || opts_list->desc->name) {
> goto bad_type;
> }
> - while (qemu_isspace(*p)) {
> - p++;
> - }
> if (!*p)
> break;
> if (get_str(buf, sizeof(buf), &p) < 0) {
> @@ -4041,8 +4052,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
> {
> int count, format, size;
>
> - while (qemu_isspace(*p))
> - p++;
> if (*p == '/') {
> /* format found */
> p++;
> @@ -4122,23 +4131,15 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
> {
> int64_t val;
>
> - while (qemu_isspace(*p))
> - p++;
> - if (*typestr == '?' || *typestr == '.') {
> - if (*typestr == '?') {
> - if (*p == '\0') {
> - typestr++;
> - break;
> - }
> - } else {
> - if (*p == '.') {
> + if (*typestr == '.') {
> + if (*p == '.') {
> + p++;
> + while (qemu_isspace(*p)) {
> p++;
> - while (qemu_isspace(*p))
> - p++;
> - } else {
> - typestr++;
> - break;
> }
> + } else {
> + typestr++;
> + break;
> }
> typestr++;
> }
> @@ -4160,15 +4161,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
> int64_t val;
> char *end;
>
> - while (qemu_isspace(*p)) {
> - p++;
> - }
> - if (*typestr == '?') {
> - typestr++;
> - if (*p == '\0') {
> - break;
> - }
> - }
> val = strtosz(p, &end);
> if (val < 0) {
> monitor_printf(mon, "invalid size\n");
> @@ -4182,14 +4174,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
> {
> double val;
>
> - while (qemu_isspace(*p))
> - p++;
> - if (*typestr == '?') {
> - typestr++;
> - if (*p == '\0') {
> - break;
> - }
> - }
> if (get_double(mon, &val, &p) < 0) {
> goto fail;
> }
> @@ -4215,9 +4199,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
> const char *beg;
> int val;
>
> - while (qemu_isspace(*p)) {
> - p++;
> - }
> beg = p;
> while (qemu_isgraph(*p)) {
> p++;
Could be split into parts:
1. Hoist the space skip out of the switch
2. Hoist handling of '?' out of the switch
3. Permit optional boolean parameters
I'd delay the third part until there's a user.
^ permalink raw reply
* Re: Building for TI 8148 EVM
From: Rainer Koenig @ 2011-10-24 8:48 UTC (permalink / raw)
To: Koen Kooi; +Cc: meta-ti@yoctoproject.org
In-Reply-To: <2599D0DD-7A48-409A-95A5-CDA103E7E974@dominion.thruhere.net>
Koen,
Am 21.10.2011 11:14, schrieb Koen Kooi:
>> I'm currently trying to build an image for the TI 8148 EVM board. For
>> that I added the meta-ti layer to the standard Yocto/Edison environment.
>
> Please follow the instructions detailed in the meta-ti README: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/README
>
> Yocto/Poky lacks support for various meta-ti (and OE-classic) constructs needed for a successfull build. Following the instructions above you will get a proper setup.
Tried this over the weekend on my home PC. Yes, works. But I was just
able to build a console image. The build of systemd-gnome-image fails
with the error that nothing provides "DRI". MACHINE=dm8148-evm.
Regards
Rainer
--
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux Clients
Dept. PDG WPS R&D SW OSE
Fujitsu Technology Solutions
Bürgermeister-Ullrich-Str. 100
86199 Augsburg
Germany
Telephone: +49-821-804-3321
Telefax: +49-821-804-2131
Mail: mailto:Rainer.Koenig@ts.fujitsu.com
Internet ts.fujtsu.com
Company Details ts.fujitsu.com/imprint.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Paolo Bonzini @ 2011-10-24 8:47 UTC (permalink / raw)
To: Kevin Wolf; +Cc: Alexander Graf, qemu-devel, avi
In-Reply-To: <4EA51F16.3030700@redhat.com>
On 10/24/2011 10:17 AM, Kevin Wolf wrote:
> > 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."
Fair enough.
> But I think that starting to make exceptions for single block drivers
> isn't a good idea anyway. If we want bdrv_flush() to write out all
> metadata internal to qemu, I think the approach with checking the flag
> in drivers calling things like fsync() is better. The common thing is to
> do the flush.
I don't know... checking BDRV_O_NO_FLUSH in the drivers rather than in
the generic code sounds like a layering violation. Perhaps what you're
after is a separation of bdrv_co_flush from bdrv_{,co_,aio_}fsync? Then
BDRV_O_NO_FLUSH (better renamed to BDRV_O_NO_FSYNC...) would only
inhibit the latter.
Paolo
^ permalink raw reply
* Re: HYBRID: (PV in HVM) update
From: Ian Campbell @ 2011-10-24 8:47 UTC (permalink / raw)
To: Mukesh Rathor; +Cc: Xen-devel@lists.xensource.com, Keir Fraser
In-Reply-To: <20111020161709.42a56c27@mantra.us.oracle.com>
On Fri, 2011-10-21 at 00:17 +0100, Mukesh Rathor wrote:
> On Thu, 18 Aug 2011 15:54:14 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> >
> > JFYI... So I had a third type is_hybrid in my prototype, that I
> > thought I could get rid of, and hide things under is_hvm check. But
> > that just touches too much code, and things get ugly a bit all over.
> >
> > It seems I could just mark the guest PV if not EPT and using PV
> > paging, and mark it HVM if EPT enabled to keep changes minimum, and
> > just check for hybrid where needed (so add is_hybrid back in). Trying
> > that now....
> >
> > thanks
> > Mukesh
> >
>
>
> YEAY guys!!! I now have PV in HVM guest running with EPT!
That's awesome news!
> I'll clean up the code (tons of debug stuff right now), and post
> it for anyone to look at.
> Next and final frontier after that, running it as dom0.
Whee!
Ian.
^ permalink raw reply
* RE: [GIT PULL for v3.2] OMAP_VOUT: Few cleaups and feature addition
From: Hiremath, Vaibhav @ 2011-10-24 8:46 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-media@vger.kernel.org, mchehab@redhat.com
In-Reply-To: <201110241046.14485.laurent.pinchart@ideasonboard.com>
> -----Original Message-----
> From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
> Sent: Monday, October 24, 2011 2:16 PM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org; mchehab@redhat.com
> Subject: Re: [GIT PULL for v3.2] OMAP_VOUT: Few cleaups and feature
> addition
>
> Hi Vaibhav,
>
> On Monday 24 October 2011 10:18:32 Hiremath, Vaibhav wrote:
> > On Monday, October 24, 2011 12:53 PM Laurent Pinchart wrote:
> > > On Saturday 22 October 2011 14:06:24 hvaibhav@ti.com wrote:
> > > > Hi Mauro,
> > > >
> > > > The following changes since commit
> > > >
> > > > 35a912455ff5640dc410e91279b03e04045265b2: Mauro Carvalho Chehab (1):
> > > > Merge branch 'v4l_for_linus' into staging/for_v3.2
> > > >
> > > > are available in the git repository at:
> > > > git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git
> > > >
> > > > for-linux-media
> > > >
> > > > Archit Taneja (5):
> > > > OMAP_VOUT: Fix check in reqbuf for buf_size allocation
> > > > OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
> > > > OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
> > > > OMAP_VOUT: Add support for DSI panels
> > > > OMAP_VOUT: Increase MAX_DISPLAYS to a larger value
> > >
> > > What about http://patchwork.linuxtv.org/patch/299/ ? Do you plan to
> push
> > > it
> > > through your tree, or should I push it through mine ?
> >
> > Oops,
> >
> > Missed it... Thanks for reminding me.
>
> No worries.
>
> > If you are about to send pull request then go ahead and merge it with
> your
> > patch-sets. OR I can also send another request for this patch alone.
>
> I've got omap3-isp patches I'm about to send a pull request for, I'll add
> the
> omap_vout patch to the set.
>
Thanks
Regards,
Vaibhav
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [GIT PULL for v3.2] OMAP_VOUT: Few cleaups and feature addition
From: Laurent Pinchart @ 2011-10-24 8:46 UTC (permalink / raw)
To: Hiremath, Vaibhav; +Cc: linux-media@vger.kernel.org, mchehab@redhat.com
In-Reply-To: <19F8576C6E063C45BE387C64729E739406C1010164@dbde02.ent.ti.com>
Hi Vaibhav,
On Monday 24 October 2011 10:18:32 Hiremath, Vaibhav wrote:
> On Monday, October 24, 2011 12:53 PM Laurent Pinchart wrote:
> > On Saturday 22 October 2011 14:06:24 hvaibhav@ti.com wrote:
> > > Hi Mauro,
> > >
> > > The following changes since commit
> > >
> > > 35a912455ff5640dc410e91279b03e04045265b2: Mauro Carvalho Chehab (1):
> > > Merge branch 'v4l_for_linus' into staging/for_v3.2
> > >
> > > are available in the git repository at:
> > > git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git
> > >
> > > for-linux-media
> > >
> > > Archit Taneja (5):
> > > OMAP_VOUT: Fix check in reqbuf for buf_size allocation
> > > OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
> > > OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
> > > OMAP_VOUT: Add support for DSI panels
> > > OMAP_VOUT: Increase MAX_DISPLAYS to a larger value
> >
> > What about http://patchwork.linuxtv.org/patch/299/ ? Do you plan to push
> > it
> > through your tree, or should I push it through mine ?
>
> Oops,
>
> Missed it... Thanks for reminding me.
No worries.
> If you are about to send pull request then go ahead and merge it with your
> patch-sets. OR I can also send another request for this patch alone.
I've got omap3-isp patches I'm about to send a pull request for, I'll add the
omap_vout patch to the set.
--
Regards,
Laurent Pinchart
^ 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.