* [merged] mips-read-buffer-overflow.patch removed from -mm tree
From: akpm @ 2009-08-06 20:31 UTC (permalink / raw)
To: roel.kluin, ralf, mm-commits
The patch titled
mips: fix read buffer overflow
has been removed from the -mm tree. Its filename was
mips-read-buffer-overflow.patch
This patch was dropped because it was merged into mainline or a subsystem tree
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: mips: fix read buffer overflow
From: Roel Kluin <roel.kluin@gmail.com>
Check whether index is within bounds before testing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/mips/jazz/jazzdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/mips/jazz/jazzdma.c~mips-read-buffer-overflow arch/mips/jazz/jazzdma.c
--- a/arch/mips/jazz/jazzdma.c~mips-read-buffer-overflow
+++ a/arch/mips/jazz/jazzdma.c
@@ -190,7 +190,7 @@ int vdma_free(unsigned long laddr)
return -1;
}
- while (pgtbl[i].owner == laddr && i < VDMA_PGTBL_ENTRIES) {
+ while (i < VDMA_PGTBL_ENTRIES && pgtbl[i].owner == laddr) {
pgtbl[i].owner = VDMA_PAGE_EMPTY;
i++;
}
_
Patches currently in -mm which might be from roel.kluin@gmail.com are
origin.patch
linux-next.patch
x86-fix-buffer-overflow-in-efi_init.patch
s3c-fix-check-of-index-into-s3c_gpios.patch
stmp3xxx-deallocation-with-negative-index-of-descriptors.patch
dm-strncpy-does-not-null-terminate-string.patch
powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned.patch
powerpc-fsl-booke-read-buffer-overflow.patch
powerpc-avoid-calculating-possibly-invalid-address.patch
media-strncpy-does-not-null-terminate-string.patch
siano-read-buffer-overflow.patch
drivers-media-video-bw-qcamc-fix-read-buffer-overflow.patch
stk-webcam-read-buffer-overflow.patch
hid-fix-read-buffer-overflow.patch
ipath-strncpy-does-not-null-terminate-string.patch
kvm-fix-read-buffer-overflow.patch
mips-decrease-size-of-au1xxx_dbdma_pm_regs.patch
slram-read-buffer-overflow.patch
slram-read-buffer-overflow-cleanup.patch
mtd-fix-read-buffer-overflow.patch
irda-fix-read-buffer-overflow.patch
hfc_usb-fix-read-buffer-overflow.patch
atlx-strncpy-does-not-null-terminate-string.patch
ext4-remove-redundant-test-on-unsigned.patch
ocfs2-keep-index-within-status_map.patch
cyclades-read-buffer-overflow.patch
serial167-fix-read-buffer-overflow.patch
serial167-fix-read-buffer-overflow-fix.patch
drivers-scsi-fnic-fnic_scsic-clean-up.patch
ibmmca-buffer-overflow.patch
scsi-eata-fix-buffer-overflow.patch
drivers-scsi-gdthc-fix-buffer-overflow.patch
drivers-scsi-u14-34fc-fix-uffer-overflow.patch
drivers-scsi-lpfc-lpfc_vportc-fix-read-buffer-overflow.patch
osst-fix-read-buffer-overflow.patch
usb-gadget-read-buffer-overflow.patch
i915-fix-read-outside-array-bounds.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
blackfin-fix-read-buffer-overflow.patch
arch-alpha-boot-tools-objstripc-wrong-variable-tested-after-open.patch
m32r-remove-redundant-tests-on-unsigned.patch
m68k-count-can-reach-51-not-50.patch
m68k-cnt-reaches-1-not-0.patch
dme1737-keep-index-within-pwm_config.patch
ncpfs-read-buffer-overflow.patch
smbfs-read-buffer-overflow.patch
platinumfb-misplaced-parenthesis.patch
sisfb-read-buffer-overflow.patch
drivers-video-console-newport_conc-fix-read-outside-array-bounds.patch
mwave-fix-read-buffer-overflow.patch
adfs-remove-redundant-test-on-unsigned.patch
^ permalink raw reply
* [merged] drm-radeon-kms-fix-memory-leak-in-radeon_driver_load_kms.patch removed from -mm tree
From: akpm @ 2009-08-06 20:31 UTC (permalink / raw)
To: dfeng, mm-commits
The patch titled
drm/radeon/kms: fix memory leak in radeon_driver_load_kms
has been removed from the -mm tree. Its filename was
drm-radeon-kms-fix-memory-leak-in-radeon_driver_load_kms.patch
This patch was dropped because it was merged into mainline or a subsystem tree
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: drm/radeon/kms: fix memory leak in radeon_driver_load_kms
From: Xiaotian Feng <dfeng@redhat.com>
Fix the following kmemleak report:
unreferenced object 0xffff88022cb53000 (size 4096):
comm "work_for_cpu", pid 97, jiffies 4294672345
backtrace:
[<ffffffff810eb222>] create_object+0x19f/0x2a0
[<ffffffff810eb422>] kmemleak_alloc+0x26/0x4c
[<ffffffff810e363f>] __kmalloc+0x187/0x1b0
[<ffffffffa005f3db>] kzalloc.clone.0+0x13/0x15 [radeon]
[<ffffffffa005f403>] radeon_driver_load_kms+0x26/0xe1 [radeon]
[<ffffffffa0017432>] drm_get_dev+0x37f/0x480 [drm]
[<ffffffffa007f424>] radeon_pci_probe+0x15/0x269 [radeon]
[<ffffffff811f8779>] local_pci_probe+0x17/0x1b
[<ffffffff8105ffbb>] do_work_for_cpu+0x18/0x2a
[<ffffffff81063c38>] kthread+0x8a/0x92
[<ffffffff81012cba>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/gpu/drm/radeon/radeon_kms.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN drivers/gpu/drm/radeon/radeon_kms.c~drm-radeon-kms-fix-memory-leak-in-radeon_driver_load_kms drivers/gpu/drm/radeon/radeon_kms.c
--- a/drivers/gpu/drm/radeon/radeon_kms.c~drm-radeon-kms-fix-memory-leak-in-radeon_driver_load_kms
+++ a/drivers/gpu/drm/radeon/radeon_kms.c
@@ -58,6 +58,8 @@ int radeon_driver_load_kms(struct drm_de
if (r) {
DRM_ERROR("Failed to initialize radeon, disabling IOCTL\n");
radeon_device_fini(rdev);
+ kfree(rdev);
+ dev->dev_private = NULL;
return r;
}
return 0;
_
Patches currently in -mm which might be from dfeng@redhat.com are
origin.patch
linux-next.patch
documentation-update-stale-definition-of-file-nr-in-fstxt.patch
cgroups-make-unlock-sequence-in-cgroup_get_sb-consistent.patch
^ permalink raw reply
* [merged] kgdb-remove-redundant-test.patch removed from -mm tree
From: akpm @ 2009-08-06 20:31 UTC (permalink / raw)
To: roel.kluin, jason.wessel, mm-commits
The patch titled
kgdb: remove redundant test
has been removed from the -mm tree. Its filename was
kgdb-remove-redundant-test.patch
This patch was dropped because it was merged into mainline or a subsystem tree
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: kgdb: remove redundant test
From: Roel Kluin <roel.kluin@gmail.com>
The for loop starts with a breakno of 0, and ends when it's 4. so
this test is always true.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/kernel/kgdb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -puN arch/x86/kernel/kgdb.c~kgdb-remove-redundant-test arch/x86/kernel/kgdb.c
--- a/arch/x86/kernel/kgdb.c~kgdb-remove-redundant-test
+++ a/arch/x86/kernel/kgdb.c
@@ -225,8 +225,7 @@ static void kgdb_correct_hw_break(void)
dr7 |= ((breakinfo[breakno].len << 2) |
breakinfo[breakno].type) <<
((breakno << 2) + 16);
- if (breakno >= 0 && breakno <= 3)
- set_debugreg(breakinfo[breakno].addr, breakno);
+ set_debugreg(breakinfo[breakno].addr, breakno);
} else {
if ((dr7 & breakbit) && !breakinfo[breakno].enabled) {
_
Patches currently in -mm which might be from roel.kluin@gmail.com are
origin.patch
linux-next.patch
x86-fix-buffer-overflow-in-efi_init.patch
s3c-fix-check-of-index-into-s3c_gpios.patch
stmp3xxx-deallocation-with-negative-index-of-descriptors.patch
dm-strncpy-does-not-null-terminate-string.patch
powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned.patch
powerpc-fsl-booke-read-buffer-overflow.patch
powerpc-avoid-calculating-possibly-invalid-address.patch
media-strncpy-does-not-null-terminate-string.patch
siano-read-buffer-overflow.patch
drivers-media-video-bw-qcamc-fix-read-buffer-overflow.patch
stk-webcam-read-buffer-overflow.patch
hid-fix-read-buffer-overflow.patch
ipath-strncpy-does-not-null-terminate-string.patch
kvm-fix-read-buffer-overflow.patch
mips-decrease-size-of-au1xxx_dbdma_pm_regs.patch
slram-read-buffer-overflow.patch
slram-read-buffer-overflow-cleanup.patch
mtd-fix-read-buffer-overflow.patch
irda-fix-read-buffer-overflow.patch
hfc_usb-fix-read-buffer-overflow.patch
atlx-strncpy-does-not-null-terminate-string.patch
ext4-remove-redundant-test-on-unsigned.patch
ocfs2-keep-index-within-status_map.patch
cyclades-read-buffer-overflow.patch
serial167-fix-read-buffer-overflow.patch
serial167-fix-read-buffer-overflow-fix.patch
drivers-scsi-fnic-fnic_scsic-clean-up.patch
ibmmca-buffer-overflow.patch
scsi-eata-fix-buffer-overflow.patch
drivers-scsi-gdthc-fix-buffer-overflow.patch
drivers-scsi-u14-34fc-fix-uffer-overflow.patch
drivers-scsi-lpfc-lpfc_vportc-fix-read-buffer-overflow.patch
osst-fix-read-buffer-overflow.patch
usb-gadget-read-buffer-overflow.patch
i915-fix-read-outside-array-bounds.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
blackfin-fix-read-buffer-overflow.patch
arch-alpha-boot-tools-objstripc-wrong-variable-tested-after-open.patch
m32r-remove-redundant-tests-on-unsigned.patch
m68k-count-can-reach-51-not-50.patch
m68k-cnt-reaches-1-not-0.patch
dme1737-keep-index-within-pwm_config.patch
ncpfs-read-buffer-overflow.patch
smbfs-read-buffer-overflow.patch
platinumfb-misplaced-parenthesis.patch
sisfb-read-buffer-overflow.patch
drivers-video-console-newport_conc-fix-read-outside-array-bounds.patch
mwave-fix-read-buffer-overflow.patch
adfs-remove-redundant-test-on-unsigned.patch
^ permalink raw reply
* [merged] i386-fix-double-accounting-in-reserve_top_address.patch removed from -mm tree
From: akpm @ 2009-08-06 20:31 UTC (permalink / raw)
To: JBeulich, jbeulich, mm-commits
The patch titled
i386: fix double accounting in reserve_top_address()
has been removed from the -mm tree. Its filename was
i386-fix-double-accounting-in-reserve_top_address.patch
This patch was dropped because it was merged into mainline or a subsystem tree
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: i386: fix double accounting in reserve_top_address()
From: "Jan Beulich" <JBeulich@novell.com>
With VMALLOC_END included in the calculation of MAXMEM (as of 2.6.28) it
is no longer correct to also bump __VMALLOC_RESERVE in
reserve_top_address(). Doing so results in needlessly small lowmem.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/mm/pgtable.c | 1 -
1 file changed, 1 deletion(-)
diff -puN arch/x86/mm/pgtable.c~i386-fix-double-accounting-in-reserve_top_address arch/x86/mm/pgtable.c
--- a/arch/x86/mm/pgtable.c~i386-fix-double-accounting-in-reserve_top_address
+++ a/arch/x86/mm/pgtable.c
@@ -329,7 +329,6 @@ void __init reserve_top_address(unsigned
printk(KERN_INFO "Reserving virtual address space above 0x%08x\n",
(int)-reserve);
__FIXADDR_TOP = -reserve - PAGE_SIZE;
- __VMALLOC_RESERVE += reserve;
#endif
}
_
Patches currently in -mm which might be from JBeulich@novell.com are
origin.patch
linux-next.patch
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Nick Edelen @ 2009-08-06 20:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Michael J Gruber, Junio C Hamano, Jeff King, Sam Vilain,
Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <c77435a80908061301n5e855aeci16af392ed3128651@mail.gmail.com>
Hrmm, I just realized that it dosn't actually cache paths/names...
This obviously has no bearing on its use in packing, but I should
either add that in or restrict usage in non-packing-related walks.
Weird how things like that escape you.
I think I may go ahead and add support for this tomorrow. It should
have no effect on performance and very little impact on cache slice
size.
On Thu, Aug 6, 2009 at 10:01 PM, Nick Edelen<sirnot@gmail.com> wrote:
> Hi,
>
>>My idea with that was that you already have a SHA-1 map in the pack index,
>>and if all you want to be able to accelerate the revision walker, you'd
>>probably need something that adds yet another mapping, from commit to
>>parents and tree, and from tree to sub-tree and blob (so you can avoid
>>unpacking commit and tree objects).
>
> As I mention in one of the patch descriptions, along with each commit
> a list of objects introduced per commit is cached, so no extra I/O is
> necessary for tree recursion, etc. during traversal.
>
>>I just thought that it could be more efficient to do it at the time the
>>pack index is written _anyway_, as nothing will change in the pack after
>>that anyway.
>
> Nothing might change in the pack, but the slices were made to allow
> for continual addition and refinement of the cache. In a typical
> usage slices will be added and fused on a regular basis, which would
> require tinkering in pack indexes if they were combined.
>
>>But I guess I can answer my question easily myself: the boundary commits
>>will not be handled that way.
>>
>>Still, there is some redundancy between the pack index and your cache, as
>>you have to write out the whole list of SHA-1s all over again. I guess it
>>is time to look at the code instead of asking stupid questions.
>
> The whole revision cache is redundant, technically speaking: nothing
> in it can't be found by rummaging through packs or objects. The point
> of it was to distill out important information for fast, easy access
> of the commit tree.
>
> On another note, I've eliminated the python dependancy. Shall I
> resend the patchset now or should I wait until it has been further
> reviewed? (don't want to flood the list with resubmits)
>
> - Nick
>
> On Thu, Aug 6, 2009 at 9:06 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Thu, 6 Aug 2009, Nick Edelen wrote:
>>
>>> > Sorry, I forgot the details, could you quickly remind me why these
>>> > caches are not in the pack index files?
>>>
>>> Er, I'm not sure what you mean. Are you asking why these revision
>>> caches are required if we have a pack index, or why they aren't in the
>>> pack index, or something different? I'm thinking probably the second:
>>
>> Yep.
>>
>>> the short answer is that cache slices are totally independant of pack
>>> files.
>>
>> My idea with that was that you already have a SHA-1 map in the pack index,
>> and if all you want to be able to accelerate the revision walker, you'd
>> probably need something that adds yet another mapping, from commit to
>> parents and tree, and from tree to sub-tree and blob (so you can avoid
>> unpacking commit and tree objects).
>>
>> I just thought that it could be more efficient to do it at the time the
>> pack index is written _anyway_, as nothing will change in the pack after
>> that anyway.
>>
>> But I guess I can answer my question easily myself: the boundary commits
>> will not be handled that way.
>>
>> Still, there is some redundancy between the pack index and your cache, as
>> you have to write out the whole list of SHA-1s all over again. I guess it
>> is time to look at the code instead of asking stupid questions.
>>
>>> It might be possible to somehow merge revision cache slices with pack
>>> indexes, but I don't think it'd be a very suitable modification. The
>>> rev-cache slices are meant to act almost like topo-relation pack files:
>>> new slices are simply new files, seperate slice files can be fused
>>> ("repacked") into a larger one, the index is a (recreatable) single file
>>> associating file (positions) with objects. The format was geared to
>>> reducing potential cache/data loss and preventing overly large cache
>>> slices.
>>>
>>> >> Hmpf.
>>> >>
>>> >> We got rid of the last Python script in Git a long time ago, but now
>>> >> two different patch series try to sneak that dependency (at least for
>>> >> testing) back in.
>>> >>
>>> >> That's all the worse because we cannot use Python in msysGit, and
>>> >> Windows should be a platform benefitting dramatically from your work.
>>> >
>>> > In fact, the test the script performs could be easily rephrased with
>>> > "sort", "uniq" and "comm". OTOH: If the walker is supposed to return
>>> > the exact same orderd list of commits you can just use test_cmp.
>>>
>>> The language that script is written in isn't important. I originally
>>> wrote it in python because I wanted something quick and wasn't much of
>>> a sh guru (sorry :-/ ). As Micheal said I've no doubt it can easily
>>> be converted to shell script
>>
>> That is not what I wanted to hear.
>>
>>> -- in fact, I'll try to get a shell version working today.
>>
>> That is.
>>
>> Thanks,
>> Dscho
>>
>
^ permalink raw reply
* Re: [BUG] git 2.6.31-rc3'ish: "<kobject> does not have a release() function, it is broken and must be fixed."
From: Roland Dreier @ 2009-08-06 20:28 UTC (permalink / raw)
To: Greg KH; +Cc: Andreas Mohr, linux-kernel, rusty
In-Reply-To: <20090716225525.GC1548@suse.de>
> > The error happening _before_ module _init() and _after_ module _exit()
> > clearly points to something outside of an individual driver's control,
> > i.e. a module core code bug, as hinted by Greg.
> >
> > x86_32 UP, Debian testing, module-init-tools 3.9-2, git as of yesterday.
>
> I can't duplicate this here at all. I wonder what the difference is.
> No one has touched this code path in a while, any chance you could run
> 'git bisect' to track this down?
I don't understand how you can't duplicate it. I see it here too
(missing release warning on module unload with kobject debugging turned
on) and it's obvious why it's happening from looking at the code;
lib/kobject.c has:
struct kobj_type *t = get_ktype(kobj);
//...
if (t && !t->release)
pr_debug("kobject: '%s' (%p): does not have a release() "
"function, it is broken and must be fixed.\n",
kobject_name(kobj), kobj);
and kernel/params.c has:
struct kobj_type module_ktype = {
.sysfs_ops = &module_sysfs_ops,
};
ie a ktype with no release method. And indeed, the release method was
removed in:
commit 7a6a41615bfb2f03ce797bc24104c50b42c935e5
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date: Sat Dec 22 21:18:25 2007 -0800
Modules: remove unneeded release function
ie you did it yourself!
What's the deal?
- R.
^ permalink raw reply
* [PATCH] Make SimManager property SubscriberNumbers writable.
From: Andrzej Zaborowski @ 2009-08-06 20:29 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 7885 bytes --]
This implements writing SubscriberNumbers if the SIM allows this (optional
to the SIM provider). Because the property is an array of phone numbers,
setting the property needs to write multiple records on the SIM so it's not
atomic and potentially can fail partially. In this case we have to report
a write error to DBus client but at the same time file may be changed and
we send a PropertyChanged.
---
src/sim.c | 205 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 200 insertions(+), 5 deletions(-)
diff --git a/src/sim.c b/src/sim.c
index b7832f5..0bdf9ab 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -59,6 +59,7 @@
static gboolean sim_op_next(gpointer user_data);
static gboolean sim_op_retrieve_next(gpointer user);
+static void sim_own_numbers_update(struct ofono_modem *modem);
struct sim_file_op {
int id;
@@ -80,6 +81,15 @@ struct sim_manager_data {
GSList *ready_notify;
gboolean ready;
GQueue *simop_q;
+
+ int efmsisdn_length;
+};
+
+struct msisdn_set_request {
+ struct ofono_modem *modem;
+ int pending;
+ int failed;
+ DBusMessage *msg;
};
static char **get_own_numbers(GSList *own_numbers)
@@ -172,8 +182,151 @@ static DBusMessage *sim_get_properties(DBusConnection *conn,
return reply;
}
+static void msisdn_set_done(struct msisdn_set_request *req)
+{
+ DBusMessage *reply;
+
+ if (req->failed)
+ reply = __ofono_error_failed(req->msg);
+ else
+ reply = dbus_message_new_method_return(req->msg);
+
+ __ofono_dbus_pending_reply(&req->msg, reply);
+
+ /* Re-read the numbers and emit signal if needed */
+ sim_own_numbers_update(req->modem);
+
+ g_free(req);
+}
+
+static void msisdn_set_cb(struct ofono_modem *modem, int ok, void *data)
+{
+ struct msisdn_set_request *req = data;
+
+ if (!ok)
+ req->failed++;
+
+ req->pending--;
+
+ if (!req->pending)
+ msisdn_set_done(req);
+}
+
+static void set_own_numbers(struct ofono_modem *modem,
+ GSList *new_numbers, DBusMessage *msg)
+{
+ struct sim_manager_data *sim = modem->sim_manager;
+ struct msisdn_set_request *req;
+ int record;
+ unsigned char efmsisdn[255];
+ struct ofono_phone_number *number;
+
+ if (!sim->own_numbers || g_slist_length(new_numbers) !=
+ g_slist_length(sim->own_numbers)) {
+ g_slist_foreach(new_numbers, (GFunc) g_free, 0);
+ g_slist_free(new_numbers);
+
+ msg = dbus_message_ref(msg);
+ __ofono_dbus_pending_reply(&msg,
+ __ofono_error_invalid_args(msg));
+
+ return;
+ }
+
+ req = g_new0(struct msisdn_set_request, 1);
+
+ req->modem = modem;
+ req->msg = dbus_message_ref(msg);
+
+ for (record = 1; new_numbers; record++) {
+ number = new_numbers->data;
+ new_numbers = g_slist_delete_link(new_numbers, new_numbers);
+
+ sim_adn_build(efmsisdn, sim->efmsisdn_length, number);
+ g_free(number);
+
+ if (ofono_sim_write(req->modem, SIM_EFMSISDN_FILEID,
+ msisdn_set_cb, OFONO_SIM_FILE_STRUCTURE_FIXED,
+ record++, efmsisdn,
+ sim->efmsisdn_length, req) == 0)
+ req->pending++;
+ else
+ req->failed++;
+ }
+
+ if (!req->pending)
+ msisdn_set_done(req);
+}
+
+static DBusMessage *sim_set_property(DBusConnection *conn, DBusMessage *msg,
+ void *data)
+{
+ struct ofono_modem *modem = data;
+ struct sim_manager_data *sim = modem->sim_manager;
+ DBusMessageIter iter;
+ DBusMessageIter var;
+ DBusMessageIter var_elem;
+ const char *name, *value;
+ struct ofono_phone_number *own;
+ GSList *own_numbers = NULL;
+
+ if (!dbus_message_iter_init(msg, &iter))
+ return __ofono_error_invalid_args(msg);
+
+ if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_STRING)
+ return __ofono_error_invalid_args(msg);
+
+ dbus_message_iter_get_basic(&iter, &name);
+
+ if (!strcmp(name, "SubscriberNumbers")) {
+ if (sim->efmsisdn_length == 0)
+ return __ofono_error_busy(msg);
+
+ dbus_message_iter_next(&iter);
+
+ if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_VARIANT)
+ return __ofono_error_invalid_args(msg);
+
+ dbus_message_iter_recurse(&iter, &var);
+
+ if (dbus_message_iter_get_arg_type(&var) != DBUS_TYPE_ARRAY ||
+ dbus_message_iter_get_element_type(&var) !=
+ DBUS_TYPE_STRING)
+ return __ofono_error_invalid_args(msg);
+
+ dbus_message_iter_recurse(&var, &var_elem);
+
+ do {
+ if (dbus_message_iter_get_arg_type(&var_elem) !=
+ DBUS_TYPE_STRING)
+ goto error;
+
+ dbus_message_iter_get_basic(&var_elem, &value);
+
+ if (!valid_phone_number_format(value))
+ goto error;
+
+ own = g_new0(struct ofono_phone_number, 1);
+ string_to_phone_number(value, own);
+
+ own_numbers = g_slist_prepend(own_numbers, own);
+ } while (dbus_message_iter_next(&var_elem));
+
+ set_own_numbers(modem, g_slist_reverse(own_numbers), msg);
+ return NULL;
+ }
+
+error:
+ g_slist_foreach(own_numbers, (GFunc) g_free, 0);
+ g_slist_free(own_numbers);
+
+ return __ofono_error_invalid_args(msg);
+}
+
static GDBusMethodTable sim_manager_methods[] = {
{ "GetProperties", "", "a{sv}", sim_get_properties },
+ { "SetProperty", "sv", "", sim_set_property,
+ G_DBUS_METHOD_FLAG_ASYNC },
{ }
};
@@ -182,6 +335,24 @@ static GDBusSignalTable sim_manager_signals[] = {
{ }
};
+static gboolean numbers_list_equal(GSList *a, GSList *b)
+{
+ struct ofono_phone_number *num_a, *num_b;
+
+ while (a || b) {
+ if (!a || !b)
+ return FALSE;
+
+ num_a = a->data;
+ num_b = b->data;
+
+ if (!g_str_equal(num_a->number, num_b->number) ||
+ num_a->type != num_b->type)
+ return FALSE;
+ }
+
+ return TRUE;
+}
static void sim_msisdn_read_cb(struct ofono_modem *modem, int ok,
enum ofono_sim_file_structure structure,
@@ -192,10 +363,13 @@ static void sim_msisdn_read_cb(struct ofono_modem *modem, int ok,
struct sim_manager_data *sim = modem->sim_manager;
int total;
struct ofono_phone_number ph;
+ GSList **new_own_numbers = userdata;
if (!ok)
goto check;
+ sim->efmsisdn_length = record_length;
+
if (structure != OFONO_SIM_FILE_STRUCTURE_FIXED)
return;
@@ -209,19 +383,24 @@ static void sim_msisdn_read_cb(struct ofono_modem *modem, int ok,
own = g_new(struct ofono_phone_number, 1);
memcpy(own, &ph, sizeof(struct ofono_phone_number));
- sim->own_numbers = g_slist_prepend(sim->own_numbers, own);
+ *new_own_numbers = g_slist_prepend(*new_own_numbers, own);
}
if (record != total)
return;
check:
- if (sim->own_numbers) {
+ /* All records retrieved */
+ if (*new_own_numbers)
+ *new_own_numbers = g_slist_reverse(*new_own_numbers);
+
+ if (!numbers_list_equal(*new_own_numbers, sim->own_numbers)) {
char **own_numbers;
DBusConnection *conn = ofono_dbus_get_connection();
- /* All records retrieved */
- sim->own_numbers = g_slist_reverse(sim->own_numbers);
+ g_slist_foreach(sim->own_numbers, (GFunc) g_free, NULL);
+ g_slist_free(sim->own_numbers);
+ sim->own_numbers = *new_own_numbers;
own_numbers = get_own_numbers(sim->own_numbers);
@@ -231,12 +410,28 @@ check:
DBUS_TYPE_STRING,
&own_numbers);
g_strfreev(own_numbers);
+ } else {
+ g_slist_foreach(*new_own_numbers, (GFunc) g_free, NULL);
+ g_slist_free(*new_own_numbers);
}
+
+ g_free(new_own_numbers);
+}
+
+static void sim_own_numbers_update(struct ofono_modem *modem)
+{
+ GSList **new_own_numbers = g_new0(GSList *, 1);
+
+ if (!new_own_numbers)
+ return;
+
+ ofono_sim_read(modem, SIM_EFMSISDN_FILEID,
+ sim_msisdn_read_cb, new_own_numbers);
}
static void sim_ready(struct ofono_modem *modem)
{
- ofono_sim_read(modem, SIM_EFMSISDN_FILEID, sim_msisdn_read_cb, NULL);
+ sim_own_numbers_update(modem);
}
static void sim_imsi_cb(const struct ofono_error *error, const char *imsi,
--
1.6.1
^ permalink raw reply related
* sn9c20x driver seems ok, but no video
From: Chris Hallinan @ 2009-08-06 20:29 UTC (permalink / raw)
To: linux-media
Hi folks,
Trying to get a usb webcam based on SN9C20x driver working on Ubuntu.
Loading the module, everything looks good (log output trimmed for easy reading):
kernel: usb 7-3: new high speed USB device using ehci_hcd and address 4
kernel: usb 7-3: configuration #1 chosen from 1 choice
kernel: sn9c20x: SN9C20X USB 2.0 Webcam - 0C45:628F plugged-in.
kernel: sn9c20x: Detected OV9650 Sensor.
kernel: sn9c20x: Webcam device 0C45:628F is now controlling video
device /dev/video0
kernel: input: SN9C20X Webcam as /class/input/input10
kernel: sn9c20x: No ack from I2C slave 0x30 for write to address 0x17
kernel: sn9c20x: Using yuv420 output format
However, I've tried several different apps (cheese, Xsane, gstreamer,
etc) but cannot
see any video output. I confess to being completely ignorant on
issues video, etc. :)
If I type 'cat /dev/video0 >j.dump', the green LED on camera comes on,
and j.dump is filled with binary data.
However, gst-launch shows this:
# gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
WARNING: from element /pipeline0/v4l2src0: Failed to get current input
on device '/dev/video0'. May be it is a radio device
Additional debug info:
v4l2_calls.c(756): gst_v4l2_get_input (): /pipeline0/v4l2src0: system
error: Invalid argument
ERROR: from element /pipeline0/v4l2src0: Could not negotiate format
Additional debug info:
gstbasesrc.c(2387): gst_base_src_start (): /pipeline0/v4l2src0:
Check your filtered caps, if any
Setting pipeline to NULL ...
FREEING pipeline ...
I'm running Ubuntu Jaunty kernel (2.6.28) with Hardy userland.
Any input/pointers would be most appreciated! And if there is a
better list to post such a question, I'd appreciate it. I posted on
microdia@googlegroups.com, but that list hasn't had a single message
in more than 24 hours!
Thanks,
Chris
--
Life is like Linux - it never stands still.
^ permalink raw reply
* [PATCH] Reorder statements to make SIM op queue more robust.
From: Andrzej Zaborowski @ 2009-08-06 20:29 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
This allows ofono_sim_read and ofono_sim_write callbacks to queue new
read or write operations. The callback must not be called between
removing the operation from queue and checking queue length.
---
src/sim.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/sim.c b/src/sim.c
index 3376462..b7832f5 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -304,6 +304,9 @@ static void sim_op_error(struct ofono_modem *modem)
struct sim_manager_data *sim = modem->sim_manager;
struct sim_file_op *op = g_queue_pop_head(sim->simop_q);
+ if (g_queue_get_length(sim->simop_q) > 0)
+ g_timeout_add(0, sim_op_next, modem);
+
if (op->is_read == TRUE)
((ofono_sim_file_read_cb_t) op->cb)
(modem, 0, 0, 0, 0, 0, 0, op->userdata);
@@ -312,9 +315,6 @@ static void sim_op_error(struct ofono_modem *modem)
(modem, 0, op->userdata);
sim_file_op_free(op);
-
- if (g_queue_get_length(sim->simop_q) > 0)
- g_timeout_add(0, sim_op_next, modem);
}
static gboolean cache_record(const char *path, int current, int record_len,
@@ -517,15 +517,15 @@ static void sim_op_write_cb(const struct ofono_error *error, void *data)
struct sim_file_op *op = g_queue_pop_head(sim->simop_q);
ofono_sim_file_write_cb_t cb = op->cb;
+ if (g_queue_get_length(sim->simop_q) > 0)
+ g_timeout_add(0, sim_op_next, modem);
+
if (error->type == OFONO_ERROR_TYPE_NO_ERROR)
cb(modem, 1, op->userdata);
else
cb(modem, 0, op->userdata);
sim_file_op_free(op);
-
- if (g_queue_get_length(sim->simop_q) > 0)
- g_timeout_add(0, sim_op_next, modem);
}
static gboolean sim_op_next(gpointer user_data)
--
1.6.1
^ permalink raw reply related
* [U-Boot] PATCH mtd CFI flash: timeout calculation underflow if imprecise 1kHz timer: fix
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-08-06 20:26 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4A7AD624.9030902@imagos.it>
On 15:09 Thu 06 Aug , Renato Andreola wrote:
> From 3723c8437d8c3d2e04bc3bc1de9c21b33072ab08 Mon Sep 17 00:00:00 2001
> From: Renato Andreola <renato.andreola@imagos.it>
> Date: Thu, 6 Aug 2009 14:49:59 +0200
> Subject: [PATCH] drivers/mtd/cfi_flash: precision and underflow problem
> in tout calculation
>
> With old configuration it could happen tout=0 if CONFIG_SYS_HZ<1000
> solved avoiding the preprocessor conditional and introducing a compile
> time branch between a high freq case and a slow freq case.
>
> Signed-off-by: Renato Andreola renato.andreola at imagos.it
> ---
> drivers/mtd/cfi_flash.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index 81ac5d3..b118f71 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -659,9 +659,10 @@ static int flash_status_check (flash_info_t * info,
> flash_sect_t sector,
> {
> ulong start;
>
> -#if CONFIG_SYS_HZ != 1000
> - tout *= CONFIG_SYS_HZ/1000;
> -#endif
> + if (CONFIG_SYS_HZ > 10000)
> + tout *= CONFIG_SYS_HZ/1000; /* for a big HZ, avoid
> overflow */
> + else
> + tout = tout * CONFIG_SYS_HZ / 1000 + 1;
as we are all supposed to have CONFIG_SYS_HZ at 1000 (mandtory)
to have cfi, tftp & co working perfectly I do not thing this is a good idea
as you will need to fix each part of u-boot that use CONFIG_SYS_HZ
which make no sense
the best will be to simply fix your timer
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 5/5] net: smsc911x: switch to new dev_pm_ops
From: David Miller @ 2009-08-06 20:26 UTC (permalink / raw)
To: Steve.Glendinning
Cc: daniel, linux-kernel, linux-pm, netdev, linux-sh, Ian.Saturley
In-Reply-To: <OF06D1E485.71250FEA-ON8025760A.003F9572-8025760A.00415798@smsc.com>
From: Steve.Glendinning@smsc.com
Date: Thu, 6 Aug 2009 12:53:45 +0100
> David Miller <davem@davemloft.net> wrote on 06/08/2009 04:29:22:
>
>> From: Daniel Mack <daniel@caiaq.de>
>> Date: Wed, 5 Aug 2009 20:29:31 +0200
>>
>> > Hibernation is unsupported for now, which meets the actual
>> > implementation in the driver. For free/thaw, the chip's D2 state
> should
>> > be entered.
>> >
>> > Signed-off-by: Daniel Mack <daniel@caiaq.de>
>>
>> Steve, if it looks good to you I can toss this into net-next-2.6
>>
>> Just let me know.
>
> Looks fine. Compiles ok and doesn't actually change any PM
> implementation.
>
> Acked-by: <steve.glendinning@smsc.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 5/5] net: smsc911x: switch to new dev_pm_ops
From: David Miller @ 2009-08-06 20:26 UTC (permalink / raw)
To: Steve.Glendinning
Cc: linux-sh, netdev, linux-kernel, daniel, Ian.Saturley, linux-pm
In-Reply-To: <OF06D1E485.71250FEA-ON8025760A.003F9572-8025760A.00415798@smsc.com>
From: Steve.Glendinning@smsc.com
Date: Thu, 6 Aug 2009 12:53:45 +0100
> David Miller <davem@davemloft.net> wrote on 06/08/2009 04:29:22:
>
>> From: Daniel Mack <daniel@caiaq.de>
>> Date: Wed, 5 Aug 2009 20:29:31 +0200
>>
>> > Hibernation is unsupported for now, which meets the actual
>> > implementation in the driver. For free/thaw, the chip's D2 state
> should
>> > be entered.
>> >
>> > Signed-off-by: Daniel Mack <daniel@caiaq.de>
>>
>> Steve, if it looks good to you I can toss this into net-next-2.6
>>
>> Just let me know.
>
> Looks fine. Compiles ok and doesn't actually change any PM
> implementation.
>
> Acked-by: <steve.glendinning@smsc.com>
Applied, thanks everyone.
^ permalink raw reply
* [U-Boot] MPC8280 Clock configuration for U-boot
From: Jerry Van Baren @ 2009-08-06 20:25 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20090806185644.1388.qmail@f4mail-234-237.rediffmail.com>
GurumurthyGowdar wrote:
> Dear all,
> i have an issue with the clock configuration for MPC8280 for U-boot 1.3.1,
>
> the following is the message when u-boot booted.
>
> U-Boot 1.3.1 (Jul 27 2009 - 17:27:10)
>
> MPC8260 Reset Status: External Soft, External Hard
>
> MPC8260 Clock Configuration
> - Bus-to-Core Mult 3x, VCO Div 4, 60x Bus Freq 16-50 , Core Freq 50-150
> - dfbrg 1, corecnf 0x10, busdf 4, cpmdf 1, plldf 0, pllmf 4, pcidf 3
> - vco_out 500000000, scc_clk 125000000, brg_clk 31250000
> - cpu_clk 300000000, cpm_clk 250000000, bus_clk 100000000
>
> CPU: MPC8260 (HiP7 Rev 14, Mask 1.0 1K49M) at 300 MHz
OK, your bus clock is 100MHz, your multiplier is 3x, and your corecnf is
0x10.
[snip]
> in terms of hardware i have configured as per the clock configuration but if we see the
> above message i have a doubt regarding the 60x Bus Freq 16-50 --> but i have set 100
> MHZ, Core Freq 50-150 , i have set for 300 MHZ by checking the MPC8280EC i have
> configured the clock settings.
[snip]
grep says this is coming from cpu/mpc8260/speed.c. The only entry that
matches the power on print out is:
{ _3x, 4, " 16-50 ", " 50-150" }, /* 0x10 */
The 0x10 matches your corecnf and this is where the printout comes from.
It also is *WRONG.*
You want the corecnf of 0x08, which is *ALSO* a 3x multiplier, but for
the 100MHz/300MHz configuration that you are running.
{ _3x, 2, " 33-100", "100-300" }, /* 0x08 */
See the MPC8260 (MPC8280) User's Manual chapter 10.
You should also verify that your XFC (external filter capacitor) the
correct value (probably OK, but would cause issues). When it comes to
hardware folks, trust, but verify! ;-)
From speed.c:
typedef struct {
int b2c_mult;
int vco_div;
char *freq_60x;
char *freq_core;
} corecnf_t;
/*
* this table based on "Errata to MPC8260 PowerQUICC II User's Manual",
* Rev. 1, 8/2000, page 10.
*/
corecnf_t corecnf_tab[] = {
{ _1_5x, 4, " 33-100", " 33-100" }, /* 0x00 */
{ _1x, 4, " 50-150", " 50-150" }, /* 0x01 */
{ _1x, 8, " 25-75 ", " 25-75 " }, /* 0x02 */
{ _byp, -1, " ?-? ", " ?-? " }, /* 0x03 */
{ _2x, 2, " 50-150", "100-300" }, /* 0x04 */
{ _2x, 4, " 25-75 ", " 50-150" }, /* 0x05 */
{ _2_5x, 2, " 40-120", "100-240" }, /* 0x06 */
{ _4_5x, 2, " 22-65 ", "100-300" }, /* 0x07 */
{ _3x, 2, " 33-100", "100-300" }, /* 0x08 */ <---- GOOD
{ _5_5x, 2, " 18-55 ", "100-300" }, /* 0x09 */
{ _4x, 2, " 25-75 ", "100-300" }, /* 0x0A */
{ _5x, 2, " 20-60 ", "100-300" }, /* 0x0B */
{ _1_5x, 8, " 16-50 ", " 16-50 " }, /* 0x0C */
{ _6x, 2, " 16-50 ", "100-300" }, /* 0x0D */
{ _3_5x, 2, " 30-85 ", "100-300" }, /* 0x0E */
{ _off, -1, " ?-? ", " ?-? " }, /* 0x0F */
{ _3x, 4, " 16-50 ", " 50-150" }, /* 0x10 */ <---- BAD
{ _2_5x, 4, " 20-60 ", " 50-120" }, /* 0x11 */
{ _6_5x, 2, " 15-46 ", "100-300" }, /* 0x12 */
{ _byp, -1, " ?-? ", " ?-? " }, /* 0x13 */
{ _7x, 2, " 14-43 ", "100-300" }, /* 0x14 */
{ _2x, 4, " 25-75 ", " 50-150" }, /* 0x15 */
{ _7_5x, 2, " 13-40 ", "100-300" }, /* 0x16 */
{ _4_5x, 2, " 22-65 ", "100-300" }, /* 0x17 */
{ _unk, -1, " ?-? ", " ?-? " }, /* 0x18 */
{ _5_5x, 2, " 18-55 ", "100-300" }, /* 0x19 */
{ _4x, 2, " 25-75 ", "100-300" }, /* 0x1A */
{ _5x, 2, " 20-60 ", "100-300" }, /* 0x1B */
{ _8x, 2, " 12-38 ", "100-300" }, /* 0x1C */
{ _6x, 2, " 16-50 ", "100-300" }, /* 0x1D */
{ _3_5x, 2, " 30-85 ", "100-300" }, /* 0x1E */
{ _off, -1, " ?-? ", " ?-? " }, /* 0x1F */
};
Good luck,
gvb
^ permalink raw reply
* Re: [PATCH 5/5] net: smsc911x: switch to new dev_pm_ops
From: David Miller @ 2009-08-06 20:26 UTC (permalink / raw)
To: Steve.Glendinning
Cc: daniel, linux-kernel, linux-pm, netdev, linux-sh, Ian.Saturley
In-Reply-To: <OF06D1E485.71250FEA-ON8025760A.003F9572-8025760A.00415798@smsc.com>
From: Steve.Glendinning@smsc.com
Date: Thu, 6 Aug 2009 12:53:45 +0100
> David Miller <davem@davemloft.net> wrote on 06/08/2009 04:29:22:
>
>> From: Daniel Mack <daniel@caiaq.de>
>> Date: Wed, 5 Aug 2009 20:29:31 +0200
>>
>> > Hibernation is unsupported for now, which meets the actual
>> > implementation in the driver. For free/thaw, the chip's D2 state
> should
>> > be entered.
>> >
>> > Signed-off-by: Daniel Mack <daniel@caiaq.de>
>>
>> Steve, if it looks good to you I can toss this into net-next-2.6
>>
>> Just let me know.
>
> Looks fine. Compiles ok and doesn't actually change any PM
> implementation.
>
> Acked-by: <steve.glendinning@smsc.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] pcmcia: add CNF-CDROM-ID for ide/pata
From: David Miller @ 2009-08-06 20:24 UTC (permalink / raw)
To: w.sang; +Cc: linux-ide, linux-pcmcia, jeff
In-Reply-To: <20090806131642.GD3154@pengutronix.de>
From: Wolfram Sang <w.sang@pengutronix.de>
Date: Thu, 6 Aug 2009 15:16:42 +0200
> as Jeff already picked up the pata part of this patch, I wondered how to
> proceed with the ide-cs-part. Will you pick it up for .31 or .32 or should it
> go via the pcmcia-tree (which will make its next pull-request for .32)?
Please just make a fresh submission of just the IDE part and I'll
apply it, thanks!
^ permalink raw reply
* Re: [PATCH 0/2] Fix sparc64 and x86_64 issues
From: Blue Swirl @ 2009-08-06 20:23 UTC (permalink / raw)
To: linux-sparse
In-Reply-To: <f43fc5580908051151o560e73bdw50c3d575f50f7096@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]
On Wed, Aug 5, 2009 at 9:51 PM, Blue Swirl<blauwirbel@gmail.com> wrote:
> Hi,
>
> With these patches, I can run Sparse on OpenBIOS sources (which use
> libgcc) also when compiling for 64 bit targets. 64 bit targets use 128
> bit double cells, just like 64 bit double cells are used on 32 bit
> targets.
>
> I'm not sure if 'long long long' is actually used, libgcc uses
> __attribute__ ((mode (TI))).
>
> Blue Swirl (2):
> Add support for TImode type (__int128_t)
> Define __LP64__ for x86_64 unless in 32 bit mode
>
> cgcc | 9 +++++----
> evaluate.c | 8 +++++---
> expand.c | 3 ++-
> gdbhelpers | 3 +++
> parse.c | 25 ++++++++++++++++++++++---
> show-parse.c | 3 +++
> symbol.c | 6 ++++++
> symbol.h | 8 +++++---
> target.c | 1 +
> target.h | 1 +
> 10 files changed, 53 insertions(+), 14 deletions(-)
>
There was a bug in the 128 bit constant in cgcc, I forgot to subtract
one. Here are updated patches as attachments.
[-- Attachment #2: 0001-Add-support-for-TImode-type-__int128_t.patch --]
[-- Type: application/mbox, Size: 11274 bytes --]
[-- Attachment #3: 0002-Define-__LP64__-for-x86_64-unless-in-32-bit-mode.patch --]
[-- Type: application/mbox, Size: 913 bytes --]
^ permalink raw reply
* Re: [GIT PULL 0/2] IEEE 802.15.4 last-minute fixes v3
From: David Miller @ 2009-08-06 20:23 UTC (permalink / raw)
To: dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1249561586-26927-1-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 6 Aug 2009 16:26:24 +0400
> git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-linus
>
> Dmitry Eremin-Solenikov (2):
> af_ieee802154: fix ioctl processing
> af_ieee802154: provide dummy get/setsockopt
Pulled, thanks.
I'm currently waiting for Linus to pull in a locking fix from
Ingo Molnar from my tree, and I don't want things to "magically"
appear in a tree I've already asked him to pull from.
So I'll push these changes back out once he's taken that fix from
Ingo.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: Is there any working video capture card which works and is still made?
From: Devin Heitmueller @ 2009-08-06 20:18 UTC (permalink / raw)
To: Bill Davidsen; +Cc: video4linux M/L
In-Reply-To: <4A7B37F9.8070905@tmr.com>
On Thu, Aug 6, 2009 at 4:07 PM, Bill Davidsen<davidsen@tmr.com> wrote:
> Though I covered that, the signal of interest is clear QAM and NTSC
> (analog). I haven't seem any cards for busses other than PCI or PCIe, USB is
> only on a dongle (AFAIK). If I could pass access to the bus back to a VM I
> could just run XP under KVM, but that's not exactly supported, either.
Well, I'm not sure you really answered the question. What bus type
specifically are you looking for? For PCI you can go with HVR-1600 or
PCTV 800i. For USB you can get HVR-950q or HVR-1950 if you want an
onboard MPEG encoder. There are lots of products which are currently
supported. A good amount of this also depends on which distro and
version you are interested in (since that effects which kernel it is
up to relative to when support was added for products).
Have you looked at the product matrices on the Wiki:
http://linuxtv.org/wiki/index.php/ATSC_USB_Devices
http://linuxtv.org/wiki/index.php/ATSC_PCI_Cards
http://linuxtv.org/wiki/index.php/ATSC_PCIe_Cards
> I was hoping someone would pop up with a solution like a dual mode HDhomerun
> or slingshot, too much to hope.
>
>> Might also be nice what your large collection is composed of, since we
>> might be able to get some of them to work.
>>
>
> Nothing with a driver, unfortunately, and much of it obsolete by this time,
> ie. driver now but out of production. When the FCC stopped approving
> non-digital cards a lot of stuff went off the market. I'd go with a mix of
> analog card and HDhomerun if I had to.
Well, the notion of "nothing with a driver" is pretty subjective. We
are adding driver support for products all the time, and if you threw
out a list of product names they might now be supported or could be
supported with minimal effort.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
^ permalink raw reply
* Re: [Socketcan-users] [PATCH] CAN: make checking in can_rcv less restrictive
From: Luotao Fu @ 2009-08-06 20:17 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Luotao Fu, socketcan-users, Michael Olbrich, linux-kernel
In-Reply-To: <4A7B0957.5020808@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]
Hi Oliver,
On Thu, Aug 06, 2009 at 06:48:23PM +0200, Oliver Hartkopp wrote:
> Luotao Fu wrote:
> > From: Michael Olbrich <m.olbrich@pengutronix.de>
> >
> > Checking for can frame format in can_rcv() is too restrictive. BUG_ON is way too
> > heavy for the case that the can interface probably received a can frame with
> > malicious format. Further it can be used for DDOS attack since BUG_ON can lead
> > to kernel panic. Hence we turn this to WARN_ON instead.
> >
> > Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
> > Signed-off-by: Luotao Fu <l.fu@pengutronix.de>
> > ---
> > net/can/af_can.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/can/af_can.c b/net/can/af_can.c
> > index e733725..e6dcf4b 100644
> > --- a/net/can/af_can.c
> > +++ b/net/can/af_can.c
> > @@ -656,7 +656,7 @@ static int can_rcv(struct sk_buff *skb, struct net_device *dev,
> > return 0;
> > }
> >
> > - BUG_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8);
> > + WARN_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8);
> >
> > /* update statistics */
> > can_stats.rx_frames++;
>
> NAK.
>
> The CAN applications can rely on getting proper CAN frames with this check. It
> was introduced some time ago together with several other sanity checks - even
> on the TX path.
>
> The CAN core *only* consumes skbuffs originated from a CAN netdevice
> (ARPHRD_CAN).
I don't quite get it. The problem here is a broken can message sent to
the device can bring down the kernel. Which means that we can this way
easily shoot down a system with a single can message. This might be a
serious security hole. Sanity check at this level should imho better
made in the can application. We shall not bring the systemstabity in
danger this way.
>
> When this BUG() triggers, someone provided a definitely broken *CAN* network
> driver, and this needsfp to be fixed on that level.
In our case a sender (a FPGA) generates correct can frames carrying
wrong dlc length. This way the can driver on our side runs into the bug
though the driver itself is allright. The opposite needed to be fixed,
not our side. Though we do suffer a system crash only because the
sender sends trash into the can network. This is imo quite bad.
cheers
Fu
--
Pengutronix e.K. | Dipl.-Ing. Luotao Fu |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* modprobe acpi-cpufreq FATAL: Error inserting
From: linuxcbon @ 2009-08-06 20:10 UTC (permalink / raw)
To: linux-kernel
Hi,
I have an AMD Athlon 64 X2.
I did :
# modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.30.1/kernel/arch/x86/=
kernel/cpu/cpufreq/acpi-cpufreq.ko): Device or resource busy
I thought that module was general...I know there are other modules for each kind of processors, but can you make one module for all processors or do we need to use the specific ones ?
Cheers.
^ permalink raw reply
* Re: [PATCH] appletalk: fix atalk_getname() leak
From: David Miller @ 2009-08-06 20:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4A7ACC3F.9070600@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 Aug 2009 14:27:43 +0200
> atalk_getname() can leak 8 bytes of kernel memory to user
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH 5/5] tc35815: Use 0 RxFragSize.MinFrag value for non-packing mode
From: David Miller @ 2009-08-06 20:17 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-5-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:49 +0900
> The datasheet say "When not enabling packing, the MinFrag value must
> remain at 0". Do not set value to RxFragSize register if
> TC35815_USE_PACKEDBUFFER disabled.
>
> This is not a bugfix. No real problem reported on this.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 4/5] tc35815: Fix rx_missed_errors count
From: David Miller @ 2009-08-06 20:16 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-4-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:48 +0900
> The Miss_Cnt register is cleared by reading. Accumulate its value to
> rx_missed_errors count.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 3/5] tc35815: Increase timeout for mdio
From: David Miller @ 2009-08-06 20:16 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-3-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:47 +0900
> The current timeout value is too short for very high-load condition
> which jiffies might jump up in busy-loop.
> Also add minimum delay before checking completion of MDIO.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/5] tc35815: Improve BLEx / FDAEx handling
From: David Miller @ 2009-08-06 20:16 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1249569709-21403-2-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 6 Aug 2009 23:41:46 +0900
> Clear Int_BLEx / Int_FDAEx after (not before) processing Rx interrupt.
> This will reduce number of unnecessary interrupts.
> Also print rx error messages only if netif_msg_rx_err() enabled.
>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Applied to net-next-2.6
^ 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.