* Re: Linux 2.6.36-rc7
From: Eric Paris @ 2010-10-07 21:24 UTC (permalink / raw)
To: John Stoffel
Cc: Tvrtko Ursulin, Linus Torvalds, Linux Kernel Mailing List, agruen
In-Reply-To: <19630.13234.840343.153381@quad.stoffel.home>
On Thu, 2010-10-07 at 16:55 -0400, John Stoffel wrote:
> So what happens when you try to register a priority level and someone
> else has already gotten that level? Does the call fail? Do you get
> bumped down to the next open level? Can you *tell* what level you're
> at and whether or not some other decision maker is ahead of you?
Well it hasn't been discussed and implemented so I can't answer that.
*smile*
I will tell you that the way I envision it working (and being backwards
compatible) is that priority 0 is the last thing to be serviced. If 2
things register at the same priority the order between them getting
events is unpredictable. So when an HSM uses the interface it would use
the highest priority. An AV vendor might use (highest priority / 2)
while normal inotify like listeners would all be happy using priority 0.
> But I'd really like some docs in the next release which tells me as a
> poor dumb sysadmin how it can and should be used and what the gotchas
> are.
We have example man-like pages in the commit logs which I expected to be
used as the basis for man pages once the interface was accepted. They
aren't perfect but they are
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=52c923dd079df49f58016a9e56df184b132611d6
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2a3edf86040a7e15684525a2aadc29f532c51325
You'll also find an example program which shows all of the features at
http://git.kernel.org/?p=linux/kernel/git/agruen/fanotify-example.git;a=summary
I don't think digging around in kernel code is the right way :)
-Eric
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Matthew Garrett @ 2010-10-07 21:24 UTC (permalink / raw)
To: Mario Limonciello
Cc: Keng-Yu Lin, len.brown, alan-jenkins, platform-driver-x86,
linux-kernel
In-Reply-To: <AANLkTi=bj3T5hcX9r3j5kyEQkNb7PAZK948kcrx4R8tC@mail.gmail.com>
On Thu, Oct 07, 2010 at 03:53:37PM -0500, Mario Limonciello wrote:
> Yes the issue is the firmware's response to the keystroke. The
> intention here is to individual submit machines in future patches as
> they're discovered. The parameter's primary purpose is to assist in
> building the list. If someone reports a bug with these symptoms, they
> can add the parameter to their kernel command line, and report if it
> helps them. If it helps, their machine can be added to the DMI table.
Sorry, I'm not adding this as a module option. How can you not know
which machines are affected?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* RE: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Savoy, Pavan @ 2010-10-07 21:24 UTC (permalink / raw)
To: Gustavo F. Padovan, Marcel Holtmann
Cc: Greg KH, pavan-savoy@ti.com, linux-bluetooth@vger.kernel.org,
johan.hedberg@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <20101007175715.GA13602@vigoh>
Marcel, Gustavo,
> -----Original Message-----
> From: Gustavo F. Padovan [mailto:pao@profusion.mobi] On Behalf Of Gustavo F.
> Padovan
> Sent: Thursday, October 07, 2010 12:57 PM
> To: Marcel Holtmann
> Cc: Greg KH; pavan-savoy@ti.com; linux-bluetooth@vger.kernel.org;
> johan.hedberg@gmail.com; linux-kernel@vger.kernel.org; Savoy, Pavan
> Subject: Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
>
> * Marcel Holtmann <marcel@holtmann.org> [2010-10-07 17:21:07 +0200]:
>
> > Hi Greg,
> >
> > > > > This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> > > > > Texas Instrument's WiLink chipsets combine wireless technologies
> > > > > like BT, FM, GPS and WLAN onto a single chip.
> > > > >
> > > > > This Bluetooth driver works on top of the TI_ST shared transport
> > > > > line discipline driver which also allows other drivers like
> > > > > FM V4L2 and GPS character driver to make use of the same UART
> interface.
> > > > >
> > > > > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > > > > ---
> > > > > drivers/bluetooth/bt_ti.c | 463
> ++++++++++++++++++++++++++++++++++++
> > > > > drivers/staging/ti-st/bt_drv.c | 509 -------------------------------
> ---------
> > > > > drivers/staging/ti-st/bt_drv.h | 61 -----
> > > > > 3 files changed, 463 insertions(+), 570 deletions(-)
> > > > > create mode 100644 drivers/bluetooth/bt_ti.c
> > > > > delete mode 100644 drivers/staging/ti-st/bt_drv.c
> > > > > delete mode 100644 drivers/staging/ti-st/bt_drv.h
> > > >
> > > > I don't care about staging at all. So you sort that out with Greg.
> > > >
> > > > Submit your driver for upstream inclusion. And once accepted you can pin
> > > > Greg about removing it.
> > >
> > > The driver is already in staging, this is the request to move it out of
> > > staging and into the "correct" place in the tree. The core of the ti-st
> > > code is now in the drivers/misc/ directory in the linux-next tree, and
> > > this patch is the request to move the bluetooth drive into the proper
> > > drivers/bluetooth/ location.
> >
> > nice idea, but I don't want it that way. I am not dealing with staging
> > at all. They can submit this driver for upstream inclusion and then
> > delete it in a second step from staging. Or the other way around.
>
> We just have to be sure to do both steps in the same release cycle,
> otherwise we could ship the driver twice in the kernel (considering we
> will delete it after merge in drivers/bluetooth/)
Yes, once this is reviewed, I will send across patches to delete it from staging.
Also note, I have sent across updates patches, So please review.
The shared transport design can be found @ http://omappedia.org/wiki/Wilink_ST
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* RE: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Savoy, Pavan @ 2010-10-07 21:24 UTC (permalink / raw)
To: Gustavo F. Padovan, Marcel Holtmann
Cc: Greg KH, pavan-savoy@ti.com, linux-bluetooth@vger.kernel.org,
johan.hedberg@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <20101007175715.GA13602@vigoh>
Marcel, Gustavo,
> -----Original Message-----
> From: Gustavo F. Padovan [mailto:pao@profusion.mobi] On Behalf Of Gustavo=
F.
> Padovan
> Sent: Thursday, October 07, 2010 12:57 PM
> To: Marcel Holtmann
> Cc: Greg KH; pavan-savoy@ti.com; linux-bluetooth@vger.kernel.org;
> johan.hedberg@gmail.com; linux-kernel@vger.kernel.org; Savoy, Pavan
> Subject: Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
>=20
> * Marcel Holtmann <marcel@holtmann.org> [2010-10-07 17:21:07 +0200]:
>=20
> > Hi Greg,
> >
> > > > > This is the bluetooth protocol driver for the TI WiLink7 chipsets=
.
> > > > > Texas Instrument's WiLink chipsets combine wireless technologies
> > > > > like BT, FM, GPS and WLAN onto a single chip.
> > > > >
> > > > > This Bluetooth driver works on top of the TI_ST shared transport
> > > > > line discipline driver which also allows other drivers like
> > > > > FM V4L2 and GPS character driver to make use of the same UART
> interface.
> > > > >
> > > > > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > > > > ---
> > > > > drivers/bluetooth/bt_ti.c | 463
> ++++++++++++++++++++++++++++++++++++
> > > > > drivers/staging/ti-st/bt_drv.c | 509 --------------------------=
-----
> ---------
> > > > > drivers/staging/ti-st/bt_drv.h | 61 -----
> > > > > 3 files changed, 463 insertions(+), 570 deletions(-)
> > > > > create mode 100644 drivers/bluetooth/bt_ti.c
> > > > > delete mode 100644 drivers/staging/ti-st/bt_drv.c
> > > > > delete mode 100644 drivers/staging/ti-st/bt_drv.h
> > > >
> > > > I don't care about staging at all. So you sort that out with Greg.
> > > >
> > > > Submit your driver for upstream inclusion. And once accepted you ca=
n pin
> > > > Greg about removing it.
> > >
> > > The driver is already in staging, this is the request to move it out =
of
> > > staging and into the "correct" place in the tree. The core of the ti=
-st
> > > code is now in the drivers/misc/ directory in the linux-next tree, an=
d
> > > this patch is the request to move the bluetooth drive into the proper
> > > drivers/bluetooth/ location.
> >
> > nice idea, but I don't want it that way. I am not dealing with staging
> > at all. They can submit this driver for upstream inclusion and then
> > delete it in a second step from staging. Or the other way around.
>=20
> We just have to be sure to do both steps in the same release cycle,
> otherwise we could ship the driver twice in the kernel (considering we
> will delete it after merge in drivers/bluetooth/)
Yes, once this is reviewed, I will send across patches to delete it from st=
aging.
Also note, I have sent across updates patches, So please review.
The shared transport design can be found @ http://omappedia.org/wiki/Wilink=
_ST
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: 2.6.35.6 fails to suspend (pxa2xx-mci.0)
From: Rafael J. Wysocki @ 2010-10-07 21:23 UTC (permalink / raw)
To: Sven Neumann
Cc: Daniel Mack, Colin Cross, Greg Kroah-Hartman, linux-mmc,
linux-kernel, linux-arm-kernel
In-Reply-To: <1286463808.797.10.camel@bender>
On Thursday, October 07, 2010, Sven Neumann wrote:
> Hi,
>
> On Thu, 2010-10-07 at 02:18 +0200, Rafael J. Wysocki wrote:
>
> > On Thursday, October 07, 2010, Daniel Mack wrote:
> > > On Mon, Oct 04, 2010 at 09:30:35AM +0200, Sven Neumann wrote:
> > > > we are running an embedded system here based on the PXA300 platform.
> > > > Suspend/resume used to work well so far. However after upgrading the
> > > > kernel from 2.6.34.7 to 2.6.35.6, we get the following error when trying
> > > > to suspend the system:
> > > >
> > > > # echo "mem" > "/sys/power/state"
> > > > [ 5647.295953] PM: Syncing filesystems ... done.
> > > > [ 5647.318792] Freezing user space processes ... (elapsed 0.01 seconds) done.
> > > > [ 5647.337048] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> > > > [ 5647.356915] Suspending console(s) (use no_console_suspend to debug)
> > > > [ 5647.366651] pm_op(): platform_pm_suspend+0x0/0x5c returns -38
> > > > [ 5647.366671] PM: Device pxa2xx-mci.0 failed to suspend: error -38
> > > > [ 5647.367082] PM: Some devices failed to suspend
> > >
> > > We've bisected this effect down to commit 152e1d5920 ("PM: Prevent
> > > waiting forever on asynchronous resume after failing suspend").
> > > Suspending our PXA3xx based system breaks with this patch.
> > >
> > > I tried to understand what's going wrong, but I didn't follow the
> > > discussion about this logic, so I would rather like to pass it back to
> > > the originating people.
> > >
> > > I can only guess that the problem here is the somewhat tricky handling
> > > around mmc_sdio_suspend(), which returns -ENODEV (-38) in case a
> > > particular function of a card can not be suspended. The SDIO core would
> > > have simply removed the card in this case normally, but the PM core
> > > seems to interfere now, stopping the whole suspend procedure.
> > >
> > > Can anyone shed some light on this?
> >
> > I wonder what happens if you echo 0 to /sys/power/pm_async ?
>
> Nothing happens. The problem persists (tested with 2.6.36-rc7). What
> would you expect to happen?
Exactly that. :-)
Commit 152e1d5920 should not affect the non-async case (I'd be surprised if
it did really) and things should work with /sys/power/pm_async = 0 anyway.
Please try check if you can reproduce with commt 152e1d5920 reverted and
/sys/power/pm_async = 0. If you can, that's a driver bug.
Thanks,
Rafael
^ permalink raw reply
* + memblock-add-input-size-checking-to-memblock_find_region-fix.patch added to -mm tree
From: akpm @ 2010-10-07 20:51 UTC (permalink / raw)
To: mm-commits; +Cc: akpm, benh, hpa, mingo, tglx, yinghai
The patch titled
memblock-add-input-size-checking-to-memblock_find_region-fix
has been added to the -mm tree. Its filename is
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memblock-add-input-size-checking-to-memblock_find_region-fix
From: Andrew Morton <akpm@linux-foundation.org>
mm/memblock.c: In function 'memblock_find_region':
mm/memblock.c:109: warning: format '%#llx' expects type 'long long unsigned int', but argument 4 has type 'phys_addr_t'
mm/memblock.c:109: warning: format '%#llx' expects type 'long long unsigned int', but argument 5 has type 'phys_addr_t'
mm/memblock.c:109: warning: format '%#llx' expects type 'long long unsigned int', but argument 6 has type 'phys_addr_t'
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memblock.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff -puN mm/memblock.c~memblock-add-input-size-checking-to-memblock_find_region-fix mm/memblock.c
--- a/mm/memblock.c~memblock-add-input-size-checking-to-memblock_find_region-fix
+++ a/mm/memblock.c
@@ -106,7 +106,11 @@ static phys_addr_t __init memblock_find_
long j;
/* In case, huge size is requested */
- if (WARN_ONCE(end < size, "memblock_find_region: wrong range [%#llx-%#llx] size %#llx", start, end, size))
+ if (WARN_ONCE(end < size,
+ "memblock_find_region: wrong range [%#llx-%#llx] size %#llx",
+ (unsigned long long)start,
+ (unsigned long long)end,
+ (unsigned long long)size))
return MEMBLOCK_ERROR;
base = memblock_align_down((end - size), align);
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
maintainers-haavard-has-moved.patch
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch
linux-next.patch
next-remove-localversion.patch
fs-inodec-work-around-bug.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
arch-mips-include-asm-fcntlh-needs-typesh.patch
arch-x86-kernel-entry_64s-fix-build-with-gas-2161.patch
arch-x86-kernel-entry_32s-i386-too.patch
gcc-46-btrfs-clean-up-unused-variables-bugs.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
drivers-media-video-cx23885-cx23885-corec-fix-cx23885_dev_checkrevision.patch
fs-notify-fanotify-fanotify_userc-fix-warnings.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-low-threshold-to-pwm-backlight.patch
serial8250-ratelimit-too-much-work-error-fix.patch
serial8250-ratelimit-too-much-work-error-fix-fix.patch
sched-make-sched_param-argument-static-variables-in-some-sched_setscheduler-caller.patch
drivers-message-fusion-mptsasc-fix-warning.patch
vfs-allow-mnt_want_write-to-sleep-fix.patch
mm.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix-fix.patch
oom-rewrite-error-handling-for-oom_adj-and-oom_score_adj-tunables.patch
oom-fix-locking-for-oom_adj-and-oom_score_adj.patch
mm-only-build-per-node-scan_unevictable-functions-when-numa-is-enabled-cleanup.patch
memory-hotplug-unify-is_removable-and-offline-detection-code-checkpatch-fixes.patch
mm-stack-based-kmap_atomic-checkpatch-fixes.patch
mm-stack-based-kmap_atomic-fix.patch
rmap-make-anon_vma_free-static-fix.patch
vmstat-include-compactionh-when-config_compaction-fix.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
hpet-factor-timer-allocate-from-open-fix.patch
m68k-__pa-cast-arg-to-long.patch
kernelh-add-minmax3-macros-fix.patch
include-linux-kernelh-add-__must_check-to-strict_strto.patch
printk-declare-printk_ratelimit_state-in-ratelimith-fix.patch
vsprintfc-use-default-pointer-field-size-for-null-strings-fix.patch
scripts-get_maintainerpl-add-git-blame-rolestats-authored-lines-information.patch
idr-fix-idr_pre_get-locking-description-fix.patch
checkpatch-returning-errno-typically-should-be-negative.patch
select-rename-estimate_accuracy-to-select_estimate_accuracy.patch
vcs-add-poll-fasync-support-fix-fix.patch
cgroup_freezer-update_freezer_state-does-incorrect-state-transitions-checkpatch-fixes.patch
memcg-cpu-hotplug-aware-quick-acount_move-detection-checkpatch-fixes.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2-checkpatch-fixes.patch
drivers-char-hvc_consolec-remove-unneeded-__set_current_statetask_running.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
fuse-use-release_pages.patch
pps-add-async-pps-event-handler-fix.patch
memstick-add-driver-for-ricoh-r5c592-card-reader-fix.patch
kernel-resourcec-handle-reinsertion-of-an-already-inserted-resource.patch
ramoops-use-the-platform-data-structure-instead-of-module-params-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
getblk-handle-2tb-devices.patch
^ permalink raw reply
* 2.6.35.6 fails to suspend (pxa2xx-mci.0)
From: Rafael J. Wysocki @ 2010-10-07 21:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286463808.797.10.camel@bender>
On Thursday, October 07, 2010, Sven Neumann wrote:
> Hi,
>
> On Thu, 2010-10-07 at 02:18 +0200, Rafael J. Wysocki wrote:
>
> > On Thursday, October 07, 2010, Daniel Mack wrote:
> > > On Mon, Oct 04, 2010 at 09:30:35AM +0200, Sven Neumann wrote:
> > > > we are running an embedded system here based on the PXA300 platform.
> > > > Suspend/resume used to work well so far. However after upgrading the
> > > > kernel from 2.6.34.7 to 2.6.35.6, we get the following error when trying
> > > > to suspend the system:
> > > >
> > > > # echo "mem" > "/sys/power/state"
> > > > [ 5647.295953] PM: Syncing filesystems ... done.
> > > > [ 5647.318792] Freezing user space processes ... (elapsed 0.01 seconds) done.
> > > > [ 5647.337048] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> > > > [ 5647.356915] Suspending console(s) (use no_console_suspend to debug)
> > > > [ 5647.366651] pm_op(): platform_pm_suspend+0x0/0x5c returns -38
> > > > [ 5647.366671] PM: Device pxa2xx-mci.0 failed to suspend: error -38
> > > > [ 5647.367082] PM: Some devices failed to suspend
> > >
> > > We've bisected this effect down to commit 152e1d5920 ("PM: Prevent
> > > waiting forever on asynchronous resume after failing suspend").
> > > Suspending our PXA3xx based system breaks with this patch.
> > >
> > > I tried to understand what's going wrong, but I didn't follow the
> > > discussion about this logic, so I would rather like to pass it back to
> > > the originating people.
> > >
> > > I can only guess that the problem here is the somewhat tricky handling
> > > around mmc_sdio_suspend(), which returns -ENODEV (-38) in case a
> > > particular function of a card can not be suspended. The SDIO core would
> > > have simply removed the card in this case normally, but the PM core
> > > seems to interfere now, stopping the whole suspend procedure.
> > >
> > > Can anyone shed some light on this?
> >
> > I wonder what happens if you echo 0 to /sys/power/pm_async ?
>
> Nothing happens. The problem persists (tested with 2.6.36-rc7). What
> would you expect to happen?
Exactly that. :-)
Commit 152e1d5920 should not affect the non-async case (I'd be surprised if
it did really) and things should work with /sys/power/pm_async = 0 anyway.
Please try check if you can reproduce with commt 152e1d5920 reverted and
/sys/power/pm_async = 0. If you can, that's a driver bug.
Thanks,
Rafael
^ permalink raw reply
* [PATCH 2/2] compat: rename member in struct mmc_host.
From: Hauke Mehrtens @ 2010-10-07 21:22 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
In-Reply-To: <1286486544-18975-1-git-send-email-hauke@hauke-m.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/compat-2.6.37.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat-2.6.37.h b/include/linux/compat-2.6.37.h
index 3bb9228..716f528 100644
--- a/include/linux/compat-2.6.37.h
+++ b/include/linux/compat-2.6.37.h
@@ -110,6 +110,9 @@ int genl_unregister_family(struct genl_family *family);
#define genl_register_mc_group(_fam, _grp) genl_register_mc_group(&(_fam)->family, _grp)
#define genl_unregister_mc_group(_fam, _grp) genl_unregister_mc_group(&(_fam)->family, _grp)
+/* rename member in struct mmc_host in include/linux/mmc/host.h */
+#define max_segs max_hw_segs
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37)) */
#endif /* LINUX_26_37_COMPAT_H */
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] compat: backport some more kfifo stuff
From: Hauke Mehrtens @ 2010-10-07 21:22 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/compat-2.6.33.h | 37 +++++++++++++++++++++++++++++++++++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/include/linux/compat-2.6.33.h b/include/linux/compat-2.6.33.h
index e7e20d9..6a7cd3e 100644
--- a/include/linux/compat-2.6.33.h
+++ b/include/linux/compat-2.6.33.h
@@ -94,11 +94,44 @@ int pccard_loop_tuple(struct pcmcia_socket *s, unsigned int function,
/* Backport for kfifo
* kfifo_alloc and kfifo_free must be backported manually
*/
-#define kfifo_in(a, b, c) __kfifo_put(*a, b, c)
-#define kfifo_out(a, b, c) __kfifo_get(*a, b, c)
+#define kfifo_in(a, b, c) __kfifo_put(*a, (unsigned char *)b, c)
+#define kfifo_out(a, b, c) __kfifo_get(*a, (unsigned char *)b, c)
#define kfifo_len(a) __kfifo_len(*a)
/**
+ * kfifo_is_empty - returns true if the fifo is empty
+ * @fifo: the fifo to be used.
+ */
+static inline __must_check int kfifo_is_empty(struct kfifo **fifo)
+{
+ return (*fifo)->in == (*fifo)->out;
+}
+
+/**
+ * kfifo_size - returns the size of the fifo in bytes
+ * @fifo: the fifo to be used.
+ */
+static inline __must_check unsigned int kfifo_size(struct kfifo *fifo)
+{
+ return fifo->size;
+}
+
+/**
+ * kfifo_is_full - returns true if the fifo is full
+ * @fifo: the fifo to be used.
+ */
+static inline __must_check int kfifo_is_full(struct kfifo **fifo)
+{
+ return kfifo_len(fifo) == kfifo_size(*fifo);
+}
+
+static inline void compat_kfifo_free(struct kfifo **fifo) {
+ if (*fifo)
+ kfifo_free(*fifo);
+}
+#define kfifo_free compat_kfifo_free
+
+/**
* list_for_each_entry_continue_rcu - continue iteration over list of given type
* @pos: the type * to use as a loop cursor.
* @head: the head for your list.
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] compat-wireless: backport kfifo for rt2x00
From: Hauke Mehrtens @ 2010-10-07 21:21 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
In-Reply-To: <1286486469-18904-1-git-send-email-hauke@hauke-m.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/19-kfifo.patch | 36 ++++++++++++++++++++++++++++--------
1 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/patches/19-kfifo.patch b/patches/19-kfifo.patch
index 2a97ca0..1d04304 100644
--- a/patches/19-kfifo.patch
+++ b/patches/19-kfifo.patch
@@ -32,16 +32,36 @@ not be backported easily with defines in the compat module.
lbs_pr_err("Out of memory allocating event FIFO buffer\n");
goto out;
}
-@@ -763,7 +769,12 @@ static void lbs_free_adapter(struct lbs_
- lbs_deb_enter(LBS_DEB_MAIN);
+--- a/drivers/net/wireless/rt2x00/rt2x00.h
++++ b/drivers/net/wireless/rt2x00/rt2x00.h
+@@ -896,7 +896,11 @@ struct rt2x00_dev {
+ /*
+ * FIFO for storing tx status reports between isr and tasklet.
+ */
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33))
+ struct kfifo txstatus_fifo;
++#else
++ struct kfifo *txstatus_fifo;
++#endif
- lbs_free_cmd_buffer(priv);
+ /*
+ * Tasklet for processing tx status reports (rt2800pci).
+--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
++++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
+@@ -824,10 +824,16 @@ static int rt2x00lib_probe_hw(struct rt2
+ * queues gets reported before we've got a chance to handle
+ * them) 24*4=384 tx status reports need to be cached.
+ */
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33))
- kfifo_free(&priv->event_fifo);
+ status = kfifo_alloc(&rt2x00dev->txstatus_fifo, 512,
+ GFP_KERNEL);
+ if (status)
+ return status;
+#else
-+ if (priv->event_fifo)
-+ kfifo_free(priv->event_fifo);
++ rt2x00dev->txstatus_fifo = kfifo_alloc(512, GFP_KERNEL, NULL);
++ if (IS_ERR(rt2x00dev->txstatus_fifo))
++ return PTR_ERR(rt2x00dev->txstatus_fifo);
+#endif
- del_timer(&priv->command_timer);
- del_timer(&priv->auto_deepsleep_timer);
+ /* tasklet for processing the tx status reports. */
+ tasklet_init(&rt2x00dev->txstatus_tasklet,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] compat-wireless: remove already applied patches
From: Hauke Mehrtens @ 2010-10-07 21:21 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
...0211-perform-scan-cancel-in-hw-reset-work.patch | 72 -----
...carl9170-support-firmware-based-rx-filter.patch | 280 --------------------
2 files changed, 0 insertions(+), 352 deletions(-)
delete mode 100644 linux-next-pending/0001-mac80211-perform-scan-cancel-in-hw-reset-work.patch
delete mode 100644 linux-next-pending/0002-carl9170-support-firmware-based-rx-filter.patch
diff --git a/linux-next-pending/0001-mac80211-perform-scan-cancel-in-hw-reset-work.patch b/linux-next-pending/0001-mac80211-perform-scan-cancel-in-hw-reset-work.patch
deleted file mode 100644
index d606cbc..0000000
--- a/linux-next-pending/0001-mac80211-perform-scan-cancel-in-hw-reset-work.patch
+++ /dev/null
@@ -1,72 +0,0 @@
-
-Reason for adding to linux-next-pending/ :
-
-On Fri, Oct 01, 2010 at 05:47:53AM -0700, Christian Lamparter wrote:
-> Currently, everyone is waiting for:
-> "[PATCH 1/6] mac80211: perform scan cancel in hw reset work"
-> (hopefully, it fixes the dreaded ieee80211_hw_restart deadlock.)
-
-We need this for testing purposes for carl9170 which may
-get done this weekend.
-
-From 6b2daf7ad7067f3acc90f046700383a2c3ffad19 Mon Sep 17 00:00:00 2001
-From: Stanislaw Gruszka <sgruszka@redhat.com>
-Date: Fri, 1 Oct 2010 14:05:27 +0200
-Subject: [PATCH] mac80211: perform scan cancel in hw reset work
-
-Move ieee80211_scan_cancel() and all other related code to
-ieee80211_restart_work() as ieee80211_restart_hw() is intended to be
-callable from any context.
-
-Fix a bug that RTNL lock is not taken during ieee80211_cancel_scan().
-
-Take local->mtx before WARN(test_bit(SCAN_HW_SCANNING, &local->scanning)
-to prevent the race condition with __ieee80211_start_scan() described
-here: http://marc.info/?l=linux-wireless&m=128516716810537&w=2
-
-Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
----
- net/mac80211/main.c | 19 ++++++++++---------
- 1 files changed, 10 insertions(+), 9 deletions(-)
-
-diff --git a/net/mac80211/main.c b/net/mac80211/main.c
-index db341a9..ba332ef 100644
---- a/net/mac80211/main.c
-+++ b/net/mac80211/main.c
-@@ -295,7 +295,17 @@ static void ieee80211_restart_work(struct work_struct *work)
- struct ieee80211_local *local =
- container_of(work, struct ieee80211_local, restart_work);
-
-+ /* wait for scan work complete */
-+ flush_workqueue(local->workqueue);
-+
-+ mutex_lock(&local->mtx);
-+ WARN(test_bit(SCAN_HW_SCANNING, &local->scanning),
-+ "%s called with hardware scan in progress\n", __func__);
-+ mutex_unlock(&local->mtx);
-+
- rtnl_lock();
-+ if (unlikely(test_bit(SCAN_SW_SCANNING, &local->scanning)))
-+ ieee80211_scan_cancel(local);
- ieee80211_reconfig(local);
- rtnl_unlock();
- }
-@@ -306,15 +316,6 @@ void ieee80211_restart_hw(struct ieee80211_hw *hw)
-
- trace_api_restart_hw(local);
-
-- /* wait for scan work complete */
-- flush_workqueue(local->workqueue);
--
-- WARN(test_bit(SCAN_HW_SCANNING, &local->scanning),
-- "%s called with hardware scan in progress\n", __func__);
--
-- if (unlikely(test_bit(SCAN_SW_SCANNING, &local->scanning)))
-- ieee80211_scan_cancel(local);
--
- /* use this reason, ieee80211_reconfig will unblock it */
- ieee80211_stop_queues_by_reason(hw,
- IEEE80211_QUEUE_STOP_REASON_SUSPEND);
---
-1.7.0.4
-
diff --git a/linux-next-pending/0002-carl9170-support-firmware-based-rx-filter.patch b/linux-next-pending/0002-carl9170-support-firmware-based-rx-filter.patch
deleted file mode 100644
index 4c829e8..0000000
--- a/linux-next-pending/0002-carl9170-support-firmware-based-rx-filter.patch
+++ /dev/null
@@ -1,280 +0,0 @@
-
-Reason for it not being merged upstream yet: backlog.
-Since this will help with load and memory we want this for
-final testing and evaluation of the driver.
-
-From 8f56ba52913d4260fd7148a5919d913561e62cbd Mon Sep 17 00:00:00 2001
-From: Christian Lamparter <chunkeey@googlemail.com>
-Date: Tue, 28 Sep 2010 23:00:59 +0200
-Subject: [PATCH] carl9170: support firmware-based rx filter
-
-The hardware rx-filter was essentially disabled, because
-of a serve, yet unidentifiable problem with iwlagn.
-Due to these circumstances the driver and mac80211 were
-left with the job of filtering.
-
-This is very unfortunate and has proven to be expensive
-in terms of latency, memory and load.
-
-Therefore the new 1.8.8.3 firmware introduces a flexible
-filtering infrastructure which allows the driver to
-offload some of the checks (FCS & PLCP crc check,
-RA match, control frame filter, etc...) whenever possible.
-
-Note:
-This patch also includes all changes to the
-shared headers files since the inclusion.
-
-Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
----
- drivers/net/wireless/ath/carl9170/carl9170.h | 2 +
- drivers/net/wireless/ath/carl9170/cmd.h | 10 ++++++++
- drivers/net/wireless/ath/carl9170/fw.c | 7 ++++++
- drivers/net/wireless/ath/carl9170/fwcmd.h | 16 +++++++++++++
- drivers/net/wireless/ath/carl9170/fwdesc.h | 6 ++++-
- drivers/net/wireless/ath/carl9170/hw.h | 3 ++
- drivers/net/wireless/ath/carl9170/main.c | 30 ++++++++++++++++++++++++-
- drivers/net/wireless/ath/carl9170/phy.h | 5 +---
- drivers/net/wireless/ath/carl9170/version.h | 6 ++--
- 9 files changed, 75 insertions(+), 10 deletions(-)
-
-diff --git a/drivers/net/wireless/ath/carl9170/carl9170.h b/drivers/net/wireless/ath/carl9170/carl9170.h
-index 20f2a77..6cf0c9e 100644
---- a/drivers/net/wireless/ath/carl9170/carl9170.h
-+++ b/drivers/net/wireless/ath/carl9170/carl9170.h
-@@ -279,6 +279,7 @@ struct ar9170 {
- unsigned int beacon_max_len;
- bool rx_stream;
- bool tx_stream;
-+ bool rx_filter;
- unsigned int mem_blocks;
- unsigned int mem_block_size;
- unsigned int rx_size;
-@@ -314,6 +315,7 @@ struct ar9170 {
- u64 cur_mc_hash;
- u32 cur_filter;
- unsigned int filter_state;
-+ unsigned int rx_filter_caps;
- bool sniffer_enabled;
-
- /* MAC */
-diff --git a/drivers/net/wireless/ath/carl9170/cmd.h b/drivers/net/wireless/ath/carl9170/cmd.h
-index 0fc83d2..f78728c 100644
---- a/drivers/net/wireless/ath/carl9170/cmd.h
-+++ b/drivers/net/wireless/ath/carl9170/cmd.h
-@@ -59,6 +59,16 @@ static inline int carl9170_flush_cab(struct ar9170 *ar,
- return carl9170_bcn_ctrl(ar, vif_id, CARL9170_BCN_CTRL_DRAIN, 0, 0);
- }
-
-+static inline int carl9170_rx_filter(struct ar9170 *ar,
-+ const unsigned int _rx_filter)
-+{
-+ __le32 rx_filter = cpu_to_le32(_rx_filter);
-+
-+ return carl9170_exec_cmd(ar, CARL9170_CMD_RX_FILTER,
-+ sizeof(rx_filter), (u8 *)&rx_filter,
-+ 0, NULL);
-+}
-+
- struct carl9170_cmd *carl9170_cmd_buf(struct ar9170 *ar,
- const enum carl9170_cmd_oids cmd, const unsigned int len);
-
-diff --git a/drivers/net/wireless/ath/carl9170/fw.c b/drivers/net/wireless/ath/carl9170/fw.c
-index 3661546..ae6c006 100644
---- a/drivers/net/wireless/ath/carl9170/fw.c
-+++ b/drivers/net/wireless/ath/carl9170/fw.c
-@@ -257,6 +257,13 @@ static int carl9170_fw(struct ar9170 *ar, const __u8 *data, size_t len)
- if (SUPP(CARL9170FW_USB_UP_STREAM))
- ar->fw.rx_stream = true;
-
-+ if (SUPP(CARL9170FW_RX_FILTER)) {
-+ ar->fw.rx_filter = true;
-+ ar->rx_filter_caps = FIF_FCSFAIL | FIF_PLCPFAIL |
-+ FIF_CONTROL | FIF_PSPOLL | FIF_OTHER_BSS |
-+ FIF_PROMISC_IN_BSS;
-+ }
-+
- ar->fw.vif_num = otus_desc->vif_num;
- ar->fw.cmd_bufs = otus_desc->cmd_bufs;
- ar->fw.address = le32_to_cpu(otus_desc->fw_address);
-diff --git a/drivers/net/wireless/ath/carl9170/fwcmd.h b/drivers/net/wireless/ath/carl9170/fwcmd.h
-index d4a4e1d..d552166 100644
---- a/drivers/net/wireless/ath/carl9170/fwcmd.h
-+++ b/drivers/net/wireless/ath/carl9170/fwcmd.h
-@@ -53,6 +53,7 @@ enum carl9170_cmd_oids {
- CARL9170_CMD_REBOOT = 0x04,
- CARL9170_CMD_BCN_CTRL = 0x05,
- CARL9170_CMD_READ_TSF = 0x06,
-+ CARL9170_CMD_RX_FILTER = 0x07,
-
- /* CAM */
- CARL9170_CMD_EKEY = 0x10,
-@@ -153,6 +154,20 @@ struct carl9170_psm {
- } __packed;
- #define CARL9170_PSM_SIZE 4
-
-+struct carl9170_rx_filter_cmd {
-+ __le32 rx_filter;
-+} __packed;
-+#define CARL9170_RX_FILTER_CMD_SIZE 4
-+
-+#define CARL9170_RX_FILTER_BAD 0x01
-+#define CARL9170_RX_FILTER_OTHER_RA 0x02
-+#define CARL9170_RX_FILTER_DECRY_FAIL 0x04
-+#define CARL9170_RX_FILTER_CTL_OTHER 0x08
-+#define CARL9170_RX_FILTER_CTL_PSPOLL 0x10
-+#define CARL9170_RX_FILTER_CTL_BACKR 0x20
-+#define CARL9170_RX_FILTER_MGMT 0x40
-+#define CARL9170_RX_FILTER_DATA 0x80
-+
- struct carl9170_bcn_ctrl_cmd {
- __le32 vif_id;
- __le32 mode;
-@@ -188,6 +203,7 @@ struct carl9170_cmd {
- struct carl9170_rf_init rf_init;
- struct carl9170_psm psm;
- struct carl9170_bcn_ctrl_cmd bcn_ctrl;
-+ struct carl9170_rx_filter_cmd rx_filter;
- u8 data[CARL9170_MAX_CMD_PAYLOAD_LEN];
- } __packed;
- } __packed;
-diff --git a/drivers/net/wireless/ath/carl9170/fwdesc.h b/drivers/net/wireless/ath/carl9170/fwdesc.h
-index 7cd8117..71f3821 100644
---- a/drivers/net/wireless/ath/carl9170/fwdesc.h
-+++ b/drivers/net/wireless/ath/carl9170/fwdesc.h
-@@ -66,6 +66,9 @@ enum carl9170fw_feature_list {
- /* Firmware PSM support | CARL9170_CMD_PSM */
- CARL9170FW_PSM,
-
-+ /* Firmware RX filter | CARL9170_CMD_RX_FILTER */
-+ CARL9170FW_RX_FILTER,
-+
- /* KEEP LAST */
- __CARL9170FW_FEATURE_NUM
- };
-@@ -142,7 +145,7 @@ struct carl9170fw_fix_desc {
- (sizeof(struct carl9170fw_fix_desc))
-
- #define CARL9170FW_DBG_DESC_MIN_VER 1
--#define CARL9170FW_DBG_DESC_CUR_VER 2
-+#define CARL9170FW_DBG_DESC_CUR_VER 3
- struct carl9170fw_dbg_desc {
- struct carl9170fw_desc_head head;
-
-@@ -150,6 +153,7 @@ struct carl9170fw_dbg_desc {
- __le32 counter_addr;
- __le32 rx_total_addr;
- __le32 rx_overrun_addr;
-+ __le32 rx_filter;
-
- /* Put your debugging definitions here */
- } __packed;
-diff --git a/drivers/net/wireless/ath/carl9170/hw.h b/drivers/net/wireless/ath/carl9170/hw.h
-index b1292ac..2f471b3 100644
---- a/drivers/net/wireless/ath/carl9170/hw.h
-+++ b/drivers/net/wireless/ath/carl9170/hw.h
-@@ -731,6 +731,9 @@ struct ar9170_stream {
- #define SET_VAL(reg, value, newvalue) \
- (value = ((value) & ~reg) | (((newvalue) << reg##_S) & reg))
-
-+#define SET_CONSTVAL(reg, newvalue) \
-+ (((newvalue) << reg##_S) & reg)
-+
- #define MOD_VAL(reg, value, newvalue) \
- (((value) & ~reg) | (((newvalue) << reg##_S) & reg))
- #endif /* __CARL9170_SHARED_HW_H */
-diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
-index 84bd38e..3cc99f3 100644
---- a/drivers/net/wireless/ath/carl9170/main.c
-+++ b/drivers/net/wireless/ath/carl9170/main.c
-@@ -380,6 +380,13 @@ static int carl9170_op_start(struct ieee80211_hw *hw)
- if (err)
- goto out;
-
-+ if (ar->fw.rx_filter) {
-+ err = carl9170_rx_filter(ar, CARL9170_RX_FILTER_OTHER_RA |
-+ CARL9170_RX_FILTER_CTL_OTHER | CARL9170_RX_FILTER_BAD);
-+ if (err)
-+ goto out;
-+ }
-+
- err = carl9170_write_reg(ar, AR9170_MAC_REG_DMA_TRIGGER,
- AR9170_DMA_TRIGGER_RXQ);
- if (err)
-@@ -840,8 +847,7 @@ static void carl9170_op_configure_filter(struct ieee80211_hw *hw,
- struct ar9170 *ar = hw->priv;
-
- /* mask supported flags */
-- *new_flags &= FIF_ALLMULTI | FIF_FCSFAIL | FIF_PLCPFAIL |
-- FIF_OTHER_BSS | FIF_PROMISC_IN_BSS;
-+ *new_flags &= FIF_ALLMULTI | ar->rx_filter_caps;
-
- if (!IS_ACCEPTING_CMD(ar))
- return;
-@@ -867,6 +873,26 @@ static void carl9170_op_configure_filter(struct ieee80211_hw *hw,
- WARN_ON(carl9170_set_operating_mode(ar));
- }
-
-+ if (ar->fw.rx_filter && changed_flags & ar->rx_filter_caps) {
-+ u32 rx_filter = 0;
-+
-+ if (!(*new_flags & (FIF_FCSFAIL | FIF_PLCPFAIL)))
-+ rx_filter |= CARL9170_RX_FILTER_BAD;
-+
-+ if (!(*new_flags & FIF_CONTROL))
-+ rx_filter |= CARL9170_RX_FILTER_CTL_OTHER;
-+
-+ if (!(*new_flags & FIF_PSPOLL))
-+ rx_filter |= CARL9170_RX_FILTER_CTL_PSPOLL;
-+
-+ if (!(*new_flags & (FIF_OTHER_BSS | FIF_PROMISC_IN_BSS))) {
-+ rx_filter |= CARL9170_RX_FILTER_OTHER_RA;
-+ rx_filter |= CARL9170_RX_FILTER_DECRY_FAIL;
-+ }
-+
-+ WARN_ON(carl9170_rx_filter(ar, rx_filter));
-+ }
-+
- mutex_unlock(&ar->mutex);
- }
-
-diff --git a/drivers/net/wireless/ath/carl9170/phy.h b/drivers/net/wireless/ath/carl9170/phy.h
-index 53c18d3..02c34eb 100644
---- a/drivers/net/wireless/ath/carl9170/phy.h
-+++ b/drivers/net/wireless/ath/carl9170/phy.h
-@@ -423,8 +423,8 @@
- #define AR9170_PHY_CCK_DETECT_BB_ENABLE_ANT_FAST_DIV 0x2000
- #define AR9170_PHY_CCK_DETECT_BB_ENABLE_ANT_FAST_DIV_S 13
-
--#define AR9170_PHY_REG_GAIN_2GHZ_CHAIN_2 (AR9170_PHY_REG_BASE + 0x2a0c)
- #define AR9170_PHY_REG_GAIN_2GHZ (AR9170_PHY_REG_BASE + 0x0a0c)
-+#define AR9170_PHY_REG_GAIN_2GHZ_CHAIN_2 (AR9170_PHY_REG_BASE + 0x2a0c)
- #define AR9170_PHY_GAIN_2GHZ_RXTX_MARGIN 0x00fc0000
- #define AR9170_PHY_GAIN_2GHZ_RXTX_MARGIN_S 18
- #define AR9170_PHY_GAIN_2GHZ_BSW_MARGIN 0x00003c00
-@@ -561,7 +561,4 @@
- #define AR9170_PHY_CH2_EXT_MINCCA_PWR 0xff800000
- #define AR9170_PHY_CH2_EXT_MINCCA_PWR_S 23
-
--#define REDUCE_CHAIN_0 0x00000050
--#define REDUCE_CHAIN_1 0x00000051
--
- #endif /* __CARL9170_SHARED_PHY_H */
-diff --git a/drivers/net/wireless/ath/carl9170/version.h b/drivers/net/wireless/ath/carl9170/version.h
-index 0e917f8..ff53f07 100644
---- a/drivers/net/wireless/ath/carl9170/version.h
-+++ b/drivers/net/wireless/ath/carl9170/version.h
-@@ -1,7 +1,7 @@
- #ifndef __CARL9170_SHARED_VERSION_H
- #define __CARL9170_SHARED_VERSION_H
- #define CARL9170FW_VERSION_YEAR 10
--#define CARL9170FW_VERSION_MONTH 8
--#define CARL9170FW_VERSION_DAY 30
--#define CARL9170FW_VERSION_GIT "1.8.8.1"
-+#define CARL9170FW_VERSION_MONTH 9
-+#define CARL9170FW_VERSION_DAY 28
-+#define CARL9170FW_VERSION_GIT "1.8.8.3"
- #endif /* __CARL9170_SHARED_VERSION_H */
---
-1.7.0.4
-
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] compat-wireless: make patch apply again
From: Hauke Mehrtens @ 2010-10-07 21:21 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
In-Reply-To: <1286486469-18904-1-git-send-email-hauke@hauke-m.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/04-netns.patch | 38 ++++++++------------------------------
patches/09-threaded-irq.patch | 9 +++++----
2 files changed, 13 insertions(+), 34 deletions(-)
diff --git a/patches/04-netns.patch b/patches/04-netns.patch
index 3bdcdfb..44d3f84 100644
--- a/patches/04-netns.patch
+++ b/patches/04-netns.patch
@@ -4,31 +4,9 @@ for the other changes. It'd be nice to figure out a way to
bring thise here cleanly and seprately but they touch the same
files...
---- a/net/wireless/nl80211.c
-+++ b/net/wireless/nl80211.c
-@@ -30,7 +30,9 @@ static struct genl_family nl80211_fam =
- .hdrsize = 0, /* no private header */
- .version = 1, /* no particular meaning now */
- .maxattr = NL80211_ATTR_MAX,
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,32))
- .netnsok = true,
-+#endif
- };
-
- /* internal helper: get rdev and dev */
-@@ -4462,7 +4464,9 @@ static int nl80211_wiphy_netns(struct sk
-
- err = cfg80211_switch_netns(rdev, net);
- out_put_net:
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,24))
- put_net(net);
-+#endif
- out:
- cfg80211_unlock_rdev(rdev);
- out_rtnl:
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
-@@ -224,6 +224,7 @@ int cfg80211_dev_rename(struct cfg80211_
+@@ -208,6 +208,7 @@ int cfg80211_dev_rename(struct cfg80211_
return 0;
}
@@ -36,7 +14,7 @@ files...
int cfg80211_switch_netns(struct cfg80211_registered_device *rdev,
struct net *net)
{
-@@ -264,6 +265,7 @@ int cfg80211_switch_netns(struct cfg8021
+@@ -248,6 +249,7 @@ int cfg80211_switch_netns(struct cfg8021
return 0;
}
@@ -44,7 +22,7 @@ files...
static void cfg80211_rfkill_poll(struct rfkill *rfkill, void *data)
{
-@@ -376,7 +378,9 @@ struct wiphy *wiphy_new(const struct cfg
+@@ -382,7 +384,9 @@ too_many_devs:
rdev->wiphy.flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT;
#endif
@@ -54,7 +32,7 @@ files...
rdev->rfkill_ops.set_block = cfg80211_rfkill_set_block;
rdev->rfkill = rfkill_alloc(dev_name(&rdev->wiphy.dev),
-@@ -694,8 +698,10 @@ static int cfg80211_netdev_notifier_call
+@@ -700,8 +704,10 @@ static int cfg80211_netdev_notifier_call
mutex_lock(&rdev->devlist_mtx);
list_add_rcu(&wdev->list, &rdev->netdev_list);
rdev->devlist_generation++;
@@ -65,7 +43,7 @@ files...
if (sysfs_create_link(&dev->dev.kobj, &rdev->wiphy.dev.kobj,
"phy80211")) {
-@@ -841,6 +847,7 @@ static struct notifier_block cfg80211_ne
+@@ -847,6 +853,7 @@ static struct notifier_block cfg80211_ne
.notifier_call = cfg80211_netdev_notifier_call,
};
@@ -73,7 +51,7 @@ files...
static void __net_exit cfg80211_pernet_exit(struct net *net)
{
struct cfg80211_registered_device *rdev;
-@@ -858,14 +865,17 @@ static void __net_exit cfg80211_pernet_e
+@@ -864,14 +871,17 @@ static void __net_exit cfg80211_pernet_e
static struct pernet_operations cfg80211_pernet_ops = {
.exit = cfg80211_pernet_exit,
};
@@ -91,7 +69,7 @@ files...
err = wiphy_sysfs_init();
if (err)
-@@ -900,8 +910,10 @@ out_fail_nl80211:
+@@ -906,8 +916,10 @@ out_fail_nl80211:
out_fail_notifier:
wiphy_sysfs_exit();
out_fail_sysfs:
@@ -102,7 +80,7 @@ files...
return err;
}
subsys_initcall(cfg80211_init);
-@@ -913,7 +925,9 @@ static void __exit cfg80211_exit(void)
+@@ -919,7 +931,9 @@ static void __exit cfg80211_exit(void)
unregister_netdevice_notifier(&cfg80211_netdev_notifier);
wiphy_sysfs_exit();
regulatory_exit();
diff --git a/patches/09-threaded-irq.patch b/patches/09-threaded-irq.patch
index 86c1ae1..4c29f7f 100644
--- a/patches/09-threaded-irq.patch
+++ b/patches/09-threaded-irq.patch
@@ -51,7 +51,7 @@ thread in process context as well.
b43_release_firmware(dev);
--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
-@@ -756,6 +756,9 @@ struct b43_wldev {
+@@ -757,6 +757,9 @@ struct b43_wldev {
unsigned int tx_count;
unsigned int rx_count;
#endif
@@ -63,10 +63,11 @@ thread in process context as well.
/* Data structure for the WLAN parts (802.11 cores) of the b43 chip. */
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
-@@ -884,6 +884,9 @@ struct rt2x00_dev {
- * and interrupt thread routine.
+@@ -902,6 +902,10 @@ struct rt2x00_dev {
+ * Tasklet for processing tx status reports (rt2800pci).
*/
- u32 irqvalue[2];
+ struct tasklet_struct txstatus_tasklet;
++
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
+ struct compat_threaded_irq irq_compat;
+#endif
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 21:17 UTC (permalink / raw)
To: Mike Frysinger
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim, Feng Tang,
Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <AANLkTi==_WDX03gYRa0=qCSgZ2eoO-Uzpg66WeEX57rS@mail.gmail.com>
On Thu, 2010-10-07 at 17:05 -0400, Mike Frysinger wrote:
> On Thu, Oct 7, 2010 at 16:59, Daniel Walker wrote:
> > On Thu, 2010-10-07 at 16:47 -0400, Mike Frysinger wrote:
> >> On Thu, Oct 7, 2010 at 16:06, Daniel Walker wrote:
> >> > On Thu, 2010-10-07 at 16:02 -0400, Mike Frysinger wrote:
> >> >> how is that any different from:
> >> >> ln -s ttyJ0 /dev/ttyS0
> >> >
> >> > It has the same major and minors as ttyS* does. So you don't have to run
> >> > anything on the target.
> >>
> >> i dont see how those things are related. the major/minor are
> >> irrelevant, unless you've already hard coded these in some app that
> >> creates device nodes manually (instead of mdev/udev), but even then
> >> that's something that "needs to be run on the target". and both
> >> already have config support to transparently do something like
> >> "symlink ttyS# to XXX" as XXX is created.
> >
> > Something does ultimately run on all targets, the issues is does the
> > person debugging have the ability to change it .. It's not always the
> > case that they can change it. The userspace may not have udev at all.
> > The userspace may consist of a single binary .. I'm not making any
> > assumptions about the userspace here, it can be anything.
>
> then there is already a static rootfs with pre-populated /dev which
> would be fixed, or the single binary fixed. if the options are "my
> system works" or "my system doesnt work", i cant imagine people would
> continue to attempt to use "/dev/ttyS#" if it didnt exist or didnt
> work.
Ideally you would want this driver to work in any situation .. If it's
setup to use ttyS0 for debugging, even if it doesn't exist, then this
driver would be able to stand in for that interface.
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH] OLPC: Add XO-1 poweroff support
From: Andres Salomon @ 2010-10-07 21:20 UTC (permalink / raw)
To: Daniel Drake; +Cc: tglx, mingo, hpa, x86, linux-kernel
In-Reply-To: <AANLkTind-S=vzba56DmkzR2BixLGUyBTqu4rgaMcSf5w@mail.gmail.com>
On Thu, 7 Oct 2010 21:42:59 +0100
Daniel Drake <dsd@laptop.org> wrote:
> On 7 October 2010 21:09, Andres Salomon <dilinger@queued.net> wrote:
> > Any particular reason why this can't be modular?
>
> Because of the pm_power_off thing.
> Also, a similar situation would be encountered with set_suspend_ops().
>
> I don't really understand your suggestion. If we set it to NULL on
> module unload then the power off would crash on shutdown, right?
>
> Daniel
See arch/x86/kernel/apm_32.c for an example of modular pm_power_off
handling.
Power off shouldn't crash; at least, native_machine_power_off first
check if pm_power_off is !NULL before calling it.
^ permalink raw reply
* Re: [PATCH 1/6] Remote helper: accept ':<value> <name>' as a response to 'list'
From: Sverre Rabbelier @ 2010-10-07 21:17 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Tomas Carnecky, git, David Michael Barr, Ramkumar Ramachandra
In-Reply-To: <20101005020035.GA10818@burratino>
Heya,
On Tue, Oct 5, 2010 at 04:00, Jonathan Nieder <jrnieder@gmail.com> wrote:
> In particular, each line has a 40-character object id, a tab character,
> and then something like a refname.
>
> If we want to extend that, wouldn't we need to do something like
>
> 0000...0000 <refname>
> 0000...0000 <refname> is r11
>
> to avoid breaking people's scripts?
I don't know... I'd suspect that people's scripts are going to break
regardless, but if this is being used in scripts I agree we should
make it as easy as possible for scripters to parse this output.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* ASoC updates for 2.6.37
From: Mark Brown @ 2010-10-07 21:17 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Liam Girdwood
The following changes since commit ad5e4655f9a920b1cc13972e0389eaf9e0ba10b3:
ASoC: remove duplicated include for nuc900 (2010-10-05 19:26:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.37
Mark Brown (6):
ASoC: Add Dimitris Papastamos to Wolfson maintainers
ASoC: Update links for Wolfson MAINTAINERS entry
ASoC: Staticise AD1980 DAI
ASoC: Use delayed work for debounce of GPIO based jacks
ASoC: Staticise CS4270 DAI
Merge branch 'for-2.6.36' into for-2.6.37
MAINTAINERS | 4 +++-
include/sound/soc.h | 2 +-
sound/soc/codecs/ad1980.c | 2 +-
sound/soc/codecs/cs4270.c | 2 +-
sound/soc/soc-jack.c | 11 +++++------
5 files changed, 11 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: Linux 2.6.36-rc7
From: John Stoffel @ 2010-10-07 20:55 UTC (permalink / raw)
To: Eric Paris
Cc: Tvrtko Ursulin, Linus Torvalds, Linux Kernel Mailing List, agruen
In-Reply-To: <1286472835.2656.15.camel@dhcp231-98.rdu.redhat.com>
>>>>> "Eric" == Eric Paris <eparis@redhat.com> writes:
Eric> On Thu, 2010-10-07 at 18:15 +0100, Tvrtko Ursulin wrote:
>> On Thursday 07 Oct 2010 17:10:46 Tvrtko Ursulin wrote:
>> > On Wednesday 06 Oct 2010 22:45:13 Linus Torvalds wrote:
>> Priority argument was dropped from the fanotify_init syscall, and since it is
>> a syscall once released it is set in stone. Without the priority argument, how
>> are multiple clients supposed to be ordered?
>>
>> Co-existence between multiple clients was something which was supposed to be
>> designed in from the start. Use cases like hierarchical storage management,
>> anti-malware and content indexing should all be able to co-exist. Without a
>> priority argument I do not see how it can be assured HSM sees the perm event
>> before anti-malware, and content indexing after both of them? If there was any
>> discussion about dropping priority I missed it. :(
Eric> Shit. I'm trying to remember the logic. hrmph.... You could
Eric> have a real interface issue.... Shit. Let me think about it
Eric> for an hour or two.
Eric> Original idea of priorities was to allow multiple permissions
Eric> decision makers to co-exist without having the livelock problem
Eric> of each trying to grant and deny access to each other. That was
Eric> solved with the O_NONOTIFY hack and I think the priority was
Eric> then thought to be useless. But you're absolutely right, it
Eric> isn't useless if we consider that an HSM might need to run first
Eric> to make sure data exists on disk before an indexer looks at the
Eric> data.
Eric> I see two possibilities off the top of my head:
Eric> I could just slap an (unused) priority field onto the end of the
Eric> fanotify_init() syscall (assuming Linus doesn't murder me) so we
Eric> can build that support out with explicit priorities down the
Eric> line, which I think might be overkill, or
Eric> The other option (without breaking ABI as it stands today) is to
Eric> define some set of the fanotify_init() flags to be a priority
Eric> field, we've got 32 bits and only use 2 of them so giving 4-8
Eric> bits of that as a priority (next cycle) isn't an issue and can
Eric> be easily backwards compatible.
So what happens when you try to register a priority level and someone
else has already gotten that level? Does the call fail? Do you get
bumped down to the next open level? Can you *tell* what level you're
at and whether or not some other decision maker is ahead of you?
So if I register an HSM module for /home, with a priority of 1, and
then register a content indexer for /home/john at priority 1, will
they clash? Who wins? The one registered first?
I tried looking in Documentation/fs/fanotify.txt but I couldn't find
it anywhere. So I had to grep around looking for the file which held
fanotify_init() so I could look it over... and then my brain started
bleeding from the lack of any comments on the various functions on WTF
they were supposed to do.
But hey, I admit I'm not a kernel programmer at all, nor a low level
FS guy, so I probably just don't have the indepth understanding of
Linux kernel internals. I just need to spend six months hacking on
the code to come upto speed.
But I'd really like some docs in the next release which tells me as a
poor dumb sysadmin how it can and should be used and what the gotchas
are.
Thanks,
John
^ permalink raw reply
* ASoC updates for 2.6.36
From: Mark Brown @ 2010-10-07 21:16 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Liam Girdwood
The following changes since commit 0077ca0b5c986477e33451b797b6e7dc92a8bbc0:
ASoC: Fix multi-componentism (2010-09-22 18:47:40 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.36
Just a few MAINTAINERS updates.
Mark Brown (3):
ASoC: Add Jassi Brar as Samsung maintainer
ASoC: Add Dimitris Papastamos to Wolfson maintainers
ASoC: Update links for Wolfson MAINTAINERS entry
MAINTAINERS | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Greg KH @ 2010-10-07 21:15 UTC (permalink / raw)
To: Daniel Walker
Cc: Alan Cox, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Ben Dooks, Alan Cox, Kukjin Kim, Mike Frysinger,
Feng Tang, Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <1286484678.23836.49.camel@c-dwalke-linux.qualcomm.com>
On Thu, Oct 07, 2010 at 01:51:18PM -0700, Daniel Walker wrote:
> Your making too many assumptions .. You might be able to modify the
> kernel, and not the userspace. So you couldn't tweak the device
> creation .. It's much easier in the server world ..
You're saying it's easier to replace an embedded kernel than a userspace
file on an embedded system? Heh, that's funny.
And no, it's not easier to repace a kernel on a "server" than a
userspace file, due to all sorts of good reasons (certifications,
support contracts, etc...)
> > We've said no over a period of about ten years to a lot of attempts to
> > just borrow the ttyS0 range. If we'd said yes it would have been a
> > complete mess by now.
> >
> > So the answer is no.
>
> Nothing can be unilateral, there's always room for exceptions. You
> should say something more like "it's possible, but unlikely".
Hm, how about this, as the TTY and serial driver[1] maintainer, I will
not accept this kind of patch at all.
Is that final enough for you?
thanks,
greg k-h
[1] http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-06-tty/serial-mark-the-8250-driver-as-maintained.patch
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 21:14 UTC (permalink / raw)
To: Mike Frysinger
Cc: Alan Cox, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Greg Kroah-Hartman, Ben Dooks, Alan Cox,
Kukjin Kim, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <AANLkTimxUAV1=cSJoZFbYiv8JLT+QT=OLEXynxaUtfOS@mail.gmail.com>
On Thu, 2010-10-07 at 17:03 -0400, Mike Frysinger wrote:
> On Thu, Oct 7, 2010 at 16:51, Daniel Walker wrote:
> > On Thu, 2010-10-07 at 22:05 +0100, Alan Cox wrote:
> >> On Thu, 07 Oct 2010 13:36:06 -0700 Daniel Walker wrote:
> >> > On Thu, 2010-10-07 at 21:50 +0100, Alan Cox wrote:
> >> > > > + Say Y here if you want to install DCC driver as a normal serial port
> >> > > > + /dev/ttyS0 (major 4, minor 64). Otherwise, it appears as /dev/ttyJ0
> >> > > > + (major 4, minor 128) and can co-exist with other UARTs, such as
> >> > > > + 8250/16C550 compatibles.
> >> > > > +
> >> > >
> >> > > NAK to both
> >> >
> >> > I would agree if this wasn't strictly for debugging embedded devices in
> >> > difficult situations.. After talking to Mike, it's seems like it would
> >> > be useful to have this as a ttyS* specifically because embedded devices
> >> > won't always create a ttyJ* for you and ttyS* will likely already exist.
> >>
> >> If you are debugging an embedded device you are capable of changing it
> >> (otherwise you wouldn't debug it). Therefore the fact you might need to
> >> tweak the tty creation on the device is not a problem. If you can't
> >> change the device well there is no point debugging it is there !
> >
> > Your making too many assumptions .. You might be able to modify the
> > kernel, and not the userspace. So you couldn't tweak the device
> > creation .. It's much easier in the server world ..
>
> this driver isnt in the kernel. there is no ABI to preserve. if
> people want to use the mainline driver, they can fix their userspace.
> i dont think the "binary userspace" argument is terribly relevant to
> new driver submissions.
It is , what's to stop any userspace from using ttyS0 ? .. There's lots
of binary userspaces in the embedded world, along with many strange
usages ..
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [RFC/PATCH v3] usb: usb3.0 ch9 definitions
From: Greg KH @ 2010-10-07 21:09 UTC (permalink / raw)
To: Brokhman Tatyana
Cc: linux-usb, linux-arm-msm, Matthew Wilcox, Sarah Sharp,
linux-kernel
In-Reply-To: <1286476470-15265-1-git-send-email-tlinder@codeaurora.org>
On Thu, Oct 07, 2010 at 08:34:28PM +0200, Brokhman Tatyana wrote:
> Adding SuperSpeed usb definitions as defined by ch9 of the USB3.0 spec.
> This patch is a preparation for adding SuperSpeed support to the gadget
> framework.
>
> Signed-off-by: Brokhman Tatyana <tlinder@codeaurora.org>
Is this still a [RFC] or is it something that you think should be
applied to the tree?
> ---
> include/linux/usb/ch9.h | 58 ++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 57 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
> index da2ed77..a779b86 100644
> --- a/include/linux/usb/ch9.h
> +++ b/include/linux/usb/ch9.h
> @@ -123,8 +123,23 @@
> #define USB_DEVICE_A_ALT_HNP_SUPPORT 5 /* (otg) other RH port does */
> #define USB_DEVICE_DEBUG_MODE 6 /* (special devices only) */
>
> +/*
> + * New Feature Selectors as added by USB 3.0
> + * See USB 3.0 spec Table 9-6
> + */
> +#define USB_DEVICE_U1_ENABLE 48 /* dev may initiate U1 transition */
> +#define USB_DEVICE_U2_ENABLE 49 /* dev may initiate U2 transition*/
> +#define USB_DEVICE_LTM_ENABLE 50 /* dev may send LTM*/
> +#define USB_INTRF_FUNC_SUSPEND 0 /* function suspend*/
> +
> +#define USB_INTR_FUNC_SUSPEND_OPT_MASK 0xFF00
> +
> #define USB_ENDPOINT_HALT 0 /* IN/OUT will STALL */
>
> +/* Bit array elements as returned by the USB_REQ_GET_STATUS request. */
> +#define USB_DEV_STAT_U1_ENABLED 2 /* transition into U1 state */
> +#define USB_DEV_STAT_U2_ENABLED 3 /* transition into U2 state */
> +#define USB_DEV_STAT_LTM_ENABLED 4 /* Latency tolerance messages*/
>
> /**
> * struct usb_ctrlrequest - SETUP data for a USB device control request
> @@ -675,6 +690,7 @@ struct usb_bos_descriptor {
> __u8 bNumDeviceCaps;
> } __attribute__((packed));
>
> +#define USB_DT_BOS_SIZE 5
> /*-------------------------------------------------------------------------*/
>
> /* USB_DT_DEVICE_CAPABILITY: grouped with BOS */
> @@ -712,16 +728,56 @@ struct usb_wireless_cap_descriptor { /* Ultra Wide Band */
> __u8 bReserved;
> } __attribute__((packed));
>
> +/* USB 2.0 Extension descriptor */
> #define USB_CAP_TYPE_EXT 2
>
> struct usb_ext_cap_descriptor { /* Link Power Management */
> __u8 bLength;
> __u8 bDescriptorType;
> __u8 bDevCapabilityType;
> - __u8 bmAttributes;
> + __u32 bmAttributes;
> #define USB_LPM_SUPPORT (1 << 1) /* supports LPM */
> } __attribute__((packed));
This structure just got bigger? How is that going to affect existing
users of it? And shoudn't that be in __le32 format instead of __u32?
>
> +#define USB_DT_USB_EXT_CAP_SIZE 7
> +
> +/*
> + * SuperSpeed USB Capability descriptor: Defines the set of SuperSpeed USB
> + * specific device level capabilities
> + */
> +#define USB_SS_CAP_TYPE 3
> +struct usb_ss_cap_descriptor { /* Link Power Management */
> + __u8 bLength;
> + __u8 bDescriptorType;
> + __u8 bDevCapabilityType;
> + __u8 bmAttributes;
> +#define USB_LTM_SUPPORT (1 << 1) /* supports LTM */
> + __u16 wSpeedSupported;
__le16?
> +#define USB_LOW_SPEED_OPERATION (1) /* Low speed operation */
> +#define USB_FULL_SPEED_OPERATION (1 << 1) /* Full speed operation */
> +#define USB_HIGH_SPEED_OPERATION (1 << 2) /* High speed operation */
> +#define USB_5GBPS_OPERATION (1 << 3) /* Operation at 5Gbps */
> + __u8 bFunctionalitySupport;
> + __u8 bU1devExitLat;
> + __u16 bU2DevExitLat;
__le16? I'm guessing these fields haven't actually been used for
anything?
> +} __attribute__((packed));
> +
> +#define USB_DT_USB_SS_CAP_SIZE 10
> +
> +/*
> + * Container ID Capability descriptor: Defines the instance unique ID used to
> + * identify the instance across all operating modes
> + */
> +#define CONTAINER_ID_TYPE 4
> +struct usb_ss_container_id_descriptor {
> + __u8 bLength;
> + __u8 bDescriptorType;
> + __u8 bDevCapabilityType;
> + __u8 bReserved;
> + __u8 ContainerID[16]; /* 128-bit number */
Is this number in any specific endian format? If so, you're going to
have a hard time handling it as an array of bytes, aren't you? How is
this going to be managed?
thanks,
greg k-h
^ permalink raw reply
* Re: Can you please define "snapshot" and "subvolume"?
From: Chester @ 2010-10-07 21:14 UTC (permalink / raw)
To: kreijack; +Cc: linux-btrfs
In-Reply-To: <201010072313.18647.kreijack@libero.it>
If I were to use the defrag option in btrfsctl,
$ btrfsctl -d /
would it also defragment the subvolumes under the root?
^ permalink raw reply
* Re: Can you please define "snapshot" and "subvolume"?
From: Goffredo Baroncelli @ 2010-10-07 21:13 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <AANLkTinG8EN8x0=GxXq2x4W1uy6cZS078QQ5zDPFeDW2@mail.gmail.com>
On Thursday, 07 October, 2010, David Nicol wrote:
> On Thu, Oct 7, 2010 at 8:18 AM, Mike Hommey <mh@glandium.org> wrote:
> > BTW, it would be very useful to be able to turn existing directories
> > into subvolumes.
>
> does a (link,unlink) move work across subvolumes?
The link across subvolumes is not allowable. In the beginning it was
possible, but that was source of bugs. See the thread "Hard link across
subvolumes"
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg03286.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Alan Cox @ 2010-10-07 21:38 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim,
Mike Frysinger, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <1286484678.23836.49.camel@c-dwalke-linux.qualcomm.com>
> Your making too many assumptions .. You might be able to modify the
> kernel, and not the userspace. So you couldn't tweak the device
> creation .. It's much easier in the server world ..
Spare me the embedded is different lecture. It's not. In fact it's
usually easier because the environment you are testing is usually
standalone, doesn't cause a million dollar an hour downtime if you get it
wrong and was designed for debug/test so actually has a jtag port.
If you can modify the file system you can make /dev/ttyS0 the major/minor
of the jtag port.
If you can load anything in front of the userspace you can rename the
device/move it
So I find your example case fictional. In fact the only time I can see
you having a box so tightly locked up you can only tweak the kernel is
jailbreaking it, in which case you are such a fringe usage case and
technically competent that you can just do custom patches as you'll be
doing anyway for other bits.
> > We've said no over a period of about ten years to a lot of attempts to
> > just borrow the ttyS0 range. If we'd said yes it would have been a
> > complete mess by now.
> >
> > So the answer is no.
>
> Nothing can be unilateral, there's always room for exceptions. You
> should say something more like "it's possible, but unlikely".
This argument gets regurgitated every so often and nobody has yet
provided a plausable reason to make a nasty mess.
Either way I would suggest the path forward is
- Look at the blackfin jtag using tty_port alone and see if it looks
cleaner
- Fix the bugs noted
- Submit a driver that uses the existing allocated jtag major/minor only
and then have a debate about ttyS0 hackery separately.
Alan
^ permalink raw reply
* Re: [PATCHv5 1/8] commit.c: prefer get_header() to manual searching
From: Sverre Rabbelier @ 2010-10-07 21:12 UTC (permalink / raw)
To: Pat Notz; +Cc: git
In-Reply-To: <AANLkTinj5eZ7p8qW7U1iqNcjN4EG6HcftD2+etGvSKPA@mail.gmail.com>
Heya,
On Thu, Oct 7, 2010 at 23:11, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Cover letter?
Ah, there it is, sorry for the noise.
--
Cheers,
Sverre Rabbelier
^ 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.