Re: [RFC PATCH 2/3] si2165: Add first driver version
Moikka Matthias Any progress with that driver :) I have one device I would like to test it. mmkay, maybe I could try even it is not ready... regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Em Wed, 23 Apr 2014 22:50:36 +0200 Daniel Exner d...@dragonslave.de escreveu: Hi, Am 23.04.2014 22:42, schrieb Devin Heitmueller: On Wed, Apr 23, 2014 at 4:34 PM, Daniel Exner d...@dragonslave.de wrote: You can get the firmware via the following procedure: http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware or if you're on Ubuntu it's already packaged in linux-firmware-nonfree. The file itself is 66220 bytes and has an MD5 checksum of 293dc5e915d9a0f74a368f8a2ce3cc10. I used that procedure and have exactly that file in my /lib/firmware dir. Note that if you have that file in /lib/firmware, it's entirely possible that the driver is just broken (this happens quite often). The values read back by dmesg are from the device itself, so if the chip wasn't properly initialized fields such as the version will contain garbage values. On the page you linked above older firmware versions are mentions that should be supported by the driver. My Question is: how to get them? But you may be right, because Device is Xceive 34584 seems also wrong (didn't find any hint such a device exists..) I'm willing to invest some time to repair the driver. Anyone interested in helping me in getting this thing back to work? That doesn't seem to be a driver issue, but a badly extracted firmware. The firmware version should be 2.7. It the version doesn't match, that means that the firmware was not properly loaded. The driver checks if the firmware version loaded matches the version of the file, and prints warnings via dmesg. Are you sure that the md5sum of the firmware is 293dc5e915d9a0f74a368f8a2ce3cc10? -- Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: get_user_pages(write,force) refuse to COW in shared areas
Hi Hugh,
Sorry for late reply. First of all, to avoid the confusion, I think the
patch is fine.
When I saw this patch I decided that uprobes should be updated accordingly,
but I just realized that I do not understand what should I write in the
changelog.
On 04/04, Hugh Dickins wrote:
+ if (gup_flags FOLL_WRITE) {
+ if (!(vm_flags VM_WRITE)) {
+ if (!(gup_flags FOLL_FORCE))
+ goto efault;
+ /*
+ * We used to let the write,force case do COW
+ * in a VM_MAYWRITE VM_SHARED !VM_WRITE vma, so
+ * ptrace could set a breakpoint in a read-only
+ * mapping of an executable, without corrupting
+ * the file (yet only when that file had been
+ * opened for writing!). Anon pages in shared
+ * mappings are surprising: now just reject it.
+ */
+ if (!is_cow_mapping(vm_flags)) {
+ WARN_ON_ONCE(vm_flags VM_MAYWRITE);
+ goto efault;
+ }
OK. But could you please clarify Anon pages in shared mappings are surprising
?
I mean, does this only apply to VM_MAYWRITE VM_SHARED !VM_WRITE vma mentioned
above or this is bad even if a !FMODE_WRITE file was mmaped as MAP_SHARED ?
Yes, in this case this vma is not VM_SHARED and it is not VM_MAYWRITE, it is
only
VM_MAYSHARE. This is in fact private mapping except mprotect(PROT_WRITE) will
not
work.
But with or without this patch gup(FOLL_WRITE | FOLL_FORCE) won't work in this
case,
(although perhaps it could ?), is_cow_mapping() == F because of !VM_MAYWRITE.
However, currently uprobes assumes that a cowed anon page is fine in this case,
and
this differs from gup().
So, what do you think about the patch below? It is probably fine in any case,
but is there any strong reason to follow the gup's behaviour and forbid the
anon page in VM_MAYSHARE !VM_MAYWRITE vma?
Oleg.
--- x/kernel/events/uprobes.c
+++ x/kernel/events/uprobes.c
@@ -127,12 +127,13 @@ struct xol_area {
*/
static bool valid_vma(struct vm_area_struct *vma, bool is_register)
{
- vm_flags_t flags = VM_HUGETLB | VM_MAYEXEC | VM_SHARED;
+ vm_flags_t flags = VM_HUGETLB | VM_MAYEXEC;
if (is_register)
flags |= VM_WRITE;
- return vma-vm_file (vma-vm_flags flags) == VM_MAYEXEC;
+ return vma-vm_file is_cow_mapping(vma-vm_flags)
+ (vma-vm_flags flags) == VM_MAYEXEC;
}
static unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] fix mceusb endpoint type identification/handling
From: Matt DeVillier matt.devill...@gmail.com
Change the I/O endpoint handling of the mceusb driver to respect the endpoint
type reported by device (bulk/interrupt), rather than treating all endpoints
as type interrupt, which breaks devices using bulk endpoints when connected
to a xhci controller. Accordingly, change the function calls to initialize
an endpoint's transfer pipe and urb handlers to use the correct function based
on the endpoint type.
Signed-off-by: Matt DeVillier matt.devill...@gmail.com
Tested-by: Sean Young s...@mess.org
-
This is a continuation of the work started in patch #21648
Patch compiled and tested against linux-media git master. Backported and tested
against 3.14.1 stable as well.
v3 corrects formatting issues which prevented the patch from being applied
with 'git am,' and replaces a few complex conditionals with inline functions
for improved clarity.
---
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 5d8f3d4..74721cc 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -747,11 +747,19 @@ static void mce_request_packet(struct mceusb_dev *ir,
unsigned char *data,
}
/* outbound data */
- pipe = usb_sndintpipe(ir-usbdev,
- ir-usb_ep_out-bEndpointAddress);
- usb_fill_int_urb(async_urb, ir-usbdev, pipe,
- async_buf, size, mce_async_callback,
- ir, ir-usb_ep_out-bInterval);
+ if (usb_endpoint_xfer_int(ir-usb_ep_out)) {
+ pipe = usb_sndintpipe(ir-usbdev,
+ir-usb_ep_out-bEndpointAddress);
+ usb_fill_int_urb(async_urb, ir-usbdev, pipe, async_buf,
+size, mce_async_callback, ir,
+ir-usb_ep_out-bInterval);
+ } else {
+ pipe = usb_sndbulkpipe(ir-usbdev,
+ir-usb_ep_out-bEndpointAddress);
+ usb_fill_bulk_urb(async_urb, ir-usbdev, pipe,
+async_buf, size, mce_async_callback,
+ir);
+ }
memcpy(async_buf, data, size);
} else if (urb_type == MCEUSB_RX) {
@@ -1269,32 +1277,26 @@ static int mceusb_dev_probe(struct usb_interface *intf,
for (i = 0; i idesc-desc.bNumEndpoints; ++i) {
ep = idesc-endpoint[i].desc;
- if ((ep_in == NULL)
-((ep-bEndpointAddress USB_ENDPOINT_DIR_MASK)
- == USB_DIR_IN)
-(((ep-bmAttributes USB_ENDPOINT_XFERTYPE_MASK)
- == USB_ENDPOINT_XFER_BULK)
- || ((ep-bmAttributes USB_ENDPOINT_XFERTYPE_MASK)
- == USB_ENDPOINT_XFER_INT))) {
-
- ep_in = ep;
- ep_in-bmAttributes = USB_ENDPOINT_XFER_INT;
- ep_in-bInterval = 1;
- dev_dbg(intf-dev, acceptable inbound endpoint
found);
+ if ((ep_in == NULL) {
+ if (usb_endpoint_is_bulk_in(ep)) {
+ ep_in = ep;
+ mce_dbg(intf-dev, acceptable bulk inbound
endpoint found\n);
+ } else if (usb_endpoint_is_int_in(ep)) {
+ ep_in = ep;
+ ep_in-bInterval = 1;
+ mce_dbg(intf-dev, acceptable interrupt
inbound endpoint found\n);
+ }
}
- if ((ep_out == NULL)
-((ep-bEndpointAddress USB_ENDPOINT_DIR_MASK)
- == USB_DIR_OUT)
-(((ep-bmAttributes USB_ENDPOINT_XFERTYPE_MASK)
- == USB_ENDPOINT_XFER_BULK)
- || ((ep-bmAttributes USB_ENDPOINT_XFERTYPE_MASK)
- == USB_ENDPOINT_XFER_INT))) {
-
- ep_out = ep;
- ep_out-bmAttributes = USB_ENDPOINT_XFER_INT;
- ep_out-bInterval = 1;
- dev_dbg(intf-dev, acceptable outbound endpoint
found);
+ if ((ep_out == NULL) {
+ if (usb_endpoint_is_bulk_out(ep)) {
+ ep_out = ep;
+ mce_dbg(intf-dev, acceptable bulk outbound
endpoint found\n);
+ } else if (usb_endpoint_is_int_out(ep)) {
+ ep_out = ep;
+ ep_out-bInterval = 1;
+ mce_dbg(intf-dev, acceptable interrupt
outbound endpoint found\n);
+ }
}
}
if (ep_in == NULL) {
@@ -1302,7
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Hi, Am Thu, 24 Apr 2014 08:29:19 -0300 schrieb Mauro Carvalho Chehab m.che...@samsung.com: That doesn't seem to be a driver issue, but a badly extracted firmware. The firmware version should be 2.7. It the version doesn't match, that means that the firmware was not properly loaded. The driver checks if the firmware version loaded matches the version of the file, and prints warnings via dmesg. Are you sure that the md5sum of the firmware is 293dc5e915d9a0f74a368f8a2ce3cc10? Yes, I am sure. The tuner-xc2028 module even reports FW Version 2.7. What I suspect is, that this piece of hardware simply doesn't work with that firmware version. Find attached the whole output of dmesg after loading the module with debug=1, pluggin in device and starting xawtv. Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc usb 3-2: new high-speed USB device number 3 using xhci_hcd usb 3-2: New USB device found, idVendor=0ccd, idProduct=0043 usb 3-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0 usb 3-2: Product: Cinergy T USB XS usb 3-2: Manufacturer: TerraTec Electronic GmbH em28xx: New device TerraTec Electronic GmbH Cinergy T USB XS @ 480 Mbps (0ccd:0043, interface 0, class 0) em28xx: Video interface 0 found: isoc em28xx: DVB interface 0 found: isoc em28xx: chip ID is em2870 em2870 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 0x8d1e3bdf em2870 #0: EEPROM info: em2870 #0: No audio on board. em2870 #0: 500mA max power em2870 #0: Table at offset 0x06, strings=0x246a, 0x348e, 0x em2870 #0: Identified as Terratec Cinergy T XS (card=43) em2870 #0: em2870 #0: The support for this board weren't valid yet. em2870 #0: Please send a report of having this working em2870 #0: not to V4L mailing list (and/or to other addresses) em2870 #0: analog set to isoc mode. em2870 #0: dvb set to isoc mode. usbcore: registered new interface driver em28xx em2870 #0: Registering V4L2 extension Chip ID is not zero. It is not a TEA5767 tuner 16-0060: Tuner -1 found with type(s) Radio TV. xc2028: Xcv2028/3028 init called! xc2028 16-0060: creating new instance xc2028 16-0060: type set to XCeive xc2028/xc3028 tuner xc2028 16-0060: xc2028_set_config called xc2028 16-0060: xc2028_set_analog_freq called xc2028 16-0060: generic_set_freq called xc2028 16-0060: should set frequency 567250 kHz xc2028 16-0060: check_firmware called xc2028 16-0060: xc2028_set_analog_freq called xc2028 16-0060: generic_set_freq called xc2028 16-0060: should set frequency 567250 kHz xc2028 16-0060: check_firmware called xc2028 16-0060: request_firmware_nowait(): OK xc2028 16-0060: load_all_firmwares called xc2028 16-0060: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 16-0060: Reading firmware type BASE F8MHZ (3), id 0, size=8718. xc2028 16-0060: Reading firmware type BASE F8MHZ MTS (7), id 0, size=8712. xc2028 16-0060: Reading firmware type BASE FM (401), id 0, size=8562. xc2028 16-0060: Reading firmware type BASE FM INPUT1 (c01), id 0, size=8576. xc2028 16-0060: Reading firmware type BASE (1), id 0, size=8706. xc2028 16-0060: Reading firmware type BASE MTS (5), id 0, size=8682. xc2028 16-0060: Reading firmware type (0), id 10007, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 10007, size=169. xc2028 16-0060: Reading firmware type (0), id 20007, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 20007, size=169. xc2028 16-0060: Reading firmware type (0), id 40007, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 40007, size=169. xc2028 16-0060: Reading firmware type (0), id 80007, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 80007, size=169. xc2028 16-0060: Reading firmware type (0), id 300e0, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 300e0, size=169. xc2028 16-0060: Reading firmware type (0), id c00e0, size=161. xc2028 16-0060: Reading firmware type MTS (4), id c00e0, size=169. xc2028 16-0060: Reading firmware type (0), id 20, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 20, size=169. xc2028 16-0060: Reading firmware type (0), id 400, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 400, size=169. xc2028 16-0060: Reading firmware type D2633 DTV6 ATSC (10030), id 0, size=149. xc2028 16-0060: Reading firmware type D2620 DTV6 QAM (68), id 0, size=149. xc2028 16-0060: Reading firmware type D2633 DTV6 QAM (70), id 0, size=149. xc2028 16-0060: Reading firmware type D2620 DTV7 (88), id 0, size=149. xc2028 16-0060: Reading firmware type D2633 DTV7 (90), id 0, size=149. xc2028 16-0060: Reading firmware type D2620 DTV78 (108), id 0, size=149. xc2028 16-0060: Reading firmware type D2633 DTV78 (110), id 0, size=149. xc2028 16-0060: Reading firmware type D2620 DTV8 (208), id 0, size=149. xc2028 16-0060: Reading firmware type D2633 DTV8 (210), id 0, size=149. xc2028 16-0060: Reading firmware type FM (400), id 0, size=135.
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Yes, I am sure. The tuner-xc2028 module even reports FW Version 2.7. Yeah, the firmware image itself looks fine. What I suspect is, that this piece of hardware simply doesn't work with that firmware version. You've got the right blob (that's the only firmware that has ever run on the xc3028a chip). The message you provided which says Device is Xceive 34584 version 8.7, firmware version 1.8 is the value read out of the xc3028 chip after the firmware is loaded. The value isn't read out of the firmware blob. There are really three possibilities here: 1. The xc3028 is being held in reset. They've screwed up the GPIOs in the em28xx driver so many times that I've lost count. If the chip is in reset during the firmware load or when reading the version info, you'll get whatever garbage happened to be in memory when the I2C call was made. Alternatively, the xc3028 gets it's reset line probed between loading the firmware and reading the version (but this is less likely). 2. The xc3028 is not in reset, and the firmware load failed. In this case, for whatever reason the firmware wasn't loaded properly into the chip (for example, due to a bug in the I2C code in the em28xx driver) and the CPU on the 3028 never gets started. Hence when it goes to subsequently read the firmware version back out of the chip, the CPU on the 3028 isn't running so you're getting a garbage value back from the 3028. 3. The firmware loaded properly, but due to some other condition the I2C call to read the firmware version never actually made it to the 3028 and you're getting back whatever garbage value happened to be in the kernel memory that was supposed to be populated with the I2C response. The right way to debug this is probably to put a logic analyzer on the I2C bus and see if the traffic is making it to the xc3028 at all. Would also monitor the reset line with a scope and make sure it's high and watch for it being strobed when it shouldn't be. Of course both of those debugging techniques require hardware. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Em Thu, 24 Apr 2014 15:24:20 -0400
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:
Yes, I am sure. The tuner-xc2028 module even reports FW Version 2.7.
Yeah, the firmware image itself looks fine.
What I suspect is, that this piece of hardware simply doesn't work with
that firmware version.
You've got the right blob (that's the only firmware that has ever run
on the xc3028a chip). The message you provided which says Device is
Xceive 34584 version 8.7, firmware version 1.8 is the value read out
of the xc3028 chip after the firmware is loaded. The value isn't read
out of the firmware blob.
There are really three possibilities here:
1. The xc3028 is being held in reset. They've screwed up the GPIOs
in the em28xx driver so many times that I've lost count. If the chip
is in reset during the firmware load or when reading the version info,
you'll get whatever garbage happened to be in memory when the I2C call
was made. Alternatively, the xc3028 gets it's reset line probed
between loading the firmware and reading the version (but this is less
likely).
Hmm... This device entry is too simple for my taste:
[EM2870_BOARD_TERRATEC_XS] = {
.name = Terratec Cinergy T XS,
.valid= EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_XC2028,
.tuner_gpio = default_tuner_gpio,
},
And we never had a feedback that this works, as it still have a
.valid= EM28XX_BOARD_NOT_VALIDATED,
entry on it.
Maybe default_tuner_gpio is not the right one here, or it needs
something like:
.i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_100_KHZ,
for it to work.
2. The xc3028 is not in reset, and the firmware load failed. In this
case, for whatever reason the firmware wasn't loaded properly into the
chip (for example, due to a bug in the I2C code in the em28xx driver)
and the CPU on the 3028 never gets started. Hence when it goes to
subsequently read the firmware version back out of the chip, the CPU
on the 3028 isn't running so you're getting a garbage value back from
the 3028.
The most likely cause for this would be if the I2C speed is too high.
Not sure if this could also be affected by .xclk configuration.
3. The firmware loaded properly, but due to some other condition the
I2C call to read the firmware version never actually made it to the
3028 and you're getting back whatever garbage value happened to be in
the kernel memory that was supposed to be populated with the I2C
response.
The right way to debug this is probably to put a logic analyzer on the
I2C bus and see if the traffic is making it to the xc3028 at all.
Would also monitor the reset line with a scope and make sure it's high
and watch for it being strobed when it shouldn't be. Of course both
of those debugging techniques require hardware.
You likely don't need a hardware I2C analyzer, if the device is
not broken.
What can do, instead, is to sniff the traffic at the USB port, and get
the proper GPIO, XCLK and I2C speed settings for this device.
My suggestion is to either run it on a QEMU VM machine, redirecting
the USB device to the VM and sniffing the traffic on Linux, or to
use some USB snoop software.
Take a look at: http://linuxtv.org/wiki/index.php/Bus_snooping/sniffing
We have a script that parses em28xx traffic, converting them into
register writes. All you need to do is to sniff the traffic and check
what GPIO registers are needed to reset the device.
Then, add the corresponding data at em28xx-cards.c.
Regard
--
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: get_user_pages(write,force) refuse to COW in shared areas
On Thu, 24 Apr 2014, Oleg Nesterov wrote:
Hi Hugh,
Sorry for late reply. First of all, to avoid the confusion, I think the
patch is fine.
When I saw this patch I decided that uprobes should be updated accordingly,
but I just realized that I do not understand what should I write in the
changelog.
Thanks a lot for considering similar issues in uprobes, Oleg: I merely
checked that its uses of get_user_pages() would not be problematic,
and didn't look around to rediscover the worrying mm business that
goes on down there in kernel/events.
On 04/04, Hugh Dickins wrote:
+ if (gup_flags FOLL_WRITE) {
+ if (!(vm_flags VM_WRITE)) {
+ if (!(gup_flags FOLL_FORCE))
+ goto efault;
+ /*
+* We used to let the write,force case do COW
+* in a VM_MAYWRITE VM_SHARED !VM_WRITE vma, so
+* ptrace could set a breakpoint in a read-only
+* mapping of an executable, without corrupting
+* the file (yet only when that file had been
+* opened for writing!). Anon pages in shared
+* mappings are surprising: now just reject it.
+*/
+ if (!is_cow_mapping(vm_flags)) {
+ WARN_ON_ONCE(vm_flags VM_MAYWRITE);
+ goto efault;
+ }
OK. But could you please clarify Anon pages in shared mappings are
surprising ?
I mean, does this only apply to VM_MAYWRITE VM_SHARED !VM_WRITE vma
mentioned
above or this is bad even if a !FMODE_WRITE file was mmaped as MAP_SHARED ?
Good question. I simply didn't consider that - and (as you have realized)
didn't need to consider it, because I was just stopping the problematic
behaviour in gup(), and didn't need to consider whether other behaviour
prohibited by gup() was actually unproblematic.
Yes, in this case this vma is not VM_SHARED and it is not VM_MAYWRITE, it is
only
VM_MAYSHARE. This is in fact private mapping except mprotect(PROT_WRITE) will
not
work.
But with or without this patch gup(FOLL_WRITE | FOLL_FORCE) won't work in
this case,
this meaning my patch rather than yours below
(although perhaps it could ?), is_cow_mapping() == F because of !VM_MAYWRITE.
However, currently uprobes assumes that a cowed anon page is fine in this
case, and
this differs from gup().
So, what do you think about the patch below? It is probably fine in any case,
but is there any strong reason to follow the gup's behaviour and forbid the
anon page in VM_MAYSHARE !VM_MAYWRITE vma?
I don't think there is a strong reason to forbid it.
The strongest reason is simply that it's much safer if uprobes follows
the same conventions as mm, and get_user_pages() happens to have
forbidden that all along.
The philosophical reason to forbid it is that the user mmapped with
MAP_SHARED, and it's merely a kernel-internal detail that we flip off
VM_SHARED and treat these read-only shared mappings very much like
private mappings. The user asked for MAP_SHARED, and we prefer to
respect that by not letting private COWs creep in.
We could treat those mappings even more like private mappings, and
allow the COWs; but better to be strict about it, so long as doing
so doesn't give you regressions.
Oleg.
--- x/kernel/events/uprobes.c
+++ x/kernel/events/uprobes.c
@@ -127,12 +127,13 @@ struct xol_area {
*/
static bool valid_vma(struct vm_area_struct *vma, bool is_register)
{
- vm_flags_t flags = VM_HUGETLB | VM_MAYEXEC | VM_SHARED;
+ vm_flags_t flags = VM_HUGETLB | VM_MAYEXEC;
I think a one-line patch changing VM_SHARED to VM_MAYSHARE would do it,
wouldn't it? And save you from having to export is_cow_mapping()
from mm/memory.c. (I used is_cow_mapping() because I had to make the
test more complex anyway, just to exclude the case which had been
oddly handled before.)
Hugh
if (is_register)
flags |= VM_WRITE;
- return vma-vm_file (vma-vm_flags flags) == VM_MAYEXEC;
+ return vma-vm_file is_cow_mapping(vma-vm_flags)
+ (vma-vm_flags flags) == VM_MAYEXEC;
}
static unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t
offset)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Apr 25 04:00:30 CEST 2014 git branch: test git hash: 393cbd8dc532c1ebed60719da8d379f50d445f28 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
