* [PATCH] EDB93xx: Add support for CS4271 CODEC on EDB93xx boards
From: Alexander Sverdlin @ 2011-02-01 23:40 UTC (permalink / raw)
To: linux-arm-kernel, alsa-devel, Liam Girdwood, Mark Brown,
Dimitris Papastamos
Cc: H Hartley Sweeten, Lennert Buytenhek
From: Alexander Sverdlin <subaparts@yandex.ru>
Add support for CS4271 SPI-connected CODEC on EDB93xx boards.
Major rework based on code provided by H Hartley Sweeten <hsweeten@visionengravers.com>.
Tested on EDB9302, others (EDB9301, EDB9302A, EDB9307A, EDB0315A) should work.
Signed-off-by: Alexander Sverdlin <subaparts@yandex.ru>
---
arch/arm/mach-ep93xx/edb93xx.c | 117 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 117 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
index 4b04316..f20be96 100644
--- a/arch/arm/mach-ep93xx/edb93xx.c
+++ b/arch/arm/mach-ep93xx/edb93xx.c
@@ -30,12 +30,22 @@
#include <linux/gpio.h>
#include <linux/i2c.h>
#include <linux/i2c-gpio.h>
+#include <linux/spi/spi.h>
+#include <linux/delay.h>
+#include <mach/ep93xx_spi.h>
#include <mach/hardware.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
+#include <sound/cs4271.h>
+
+#define edb93xx_has_audio() (machine_is_edb9301() || \
+ machine_is_edb9302() || \
+ machine_is_edb9302a() || \
+ machine_is_edb9307a() || \
+ machine_is_edb9315a())
static void __init edb93xx_register_flash(void)
{
@@ -93,6 +103,111 @@ static void __init edb93xx_register_i2c(void)
/*************************************************************************
+ * EDB93xx SPI peripheral handling
+ *************************************************************************/
+static int edb93xx_cs4271_hw_setup(struct spi_device *spi)
+{
+ int gpio_nreset;
+ int err;
+
+ if (machine_is_edb9301() || machine_is_edb9302()) {
+ gpio_nreset = EP93XX_GPIO_LINE_EGPIO1;
+ } else if (machine_is_edb9302a() || machine_is_edb9307a()) {
+ ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_HONIDE);
+ gpio_nreset = EP93XX_GPIO_LINE_DD2;
+ } else if (machine_is_edb9315a()) {
+ gpio_nreset = EP93XX_GPIO_LINE_EGPIO14;
+ } else {
+ return -EINVAL;
+ }
+
+ err = gpio_request(gpio_nreset, spi->modalias);
+ if (err)
+ return err;
+ err = gpio_request(EP93XX_GPIO_LINE_EGPIO6, spi->modalias);
+ if (err)
+ return err;
+
+ gpio_direction_output(EP93XX_GPIO_LINE_EGPIO6, 1);
+
+ /* Reset codec */
+ gpio_direction_output(gpio_nreset, 0);
+ udelay(1);
+ gpio_set_value(gpio_nreset, 1);
+ /* Give the codec time to wake up */
+ udelay(1);
+
+ return 0;
+}
+
+static void edb93xx_cs4271_hw_cleanup(struct spi_device *spi)
+{
+ int gpio_nreset;
+
+ if (machine_is_edb9301() || machine_is_edb9302())
+ gpio_nreset = EP93XX_GPIO_LINE_EGPIO1;
+ else if (machine_is_edb9302a() || machine_is_edb9307a())
+ gpio_nreset = EP93XX_GPIO_LINE_DD2;
+ else if (machine_is_edb9315a())
+ gpio_nreset = EP93XX_GPIO_LINE_EGPIO14;
+ else
+ return;
+
+ gpio_set_value(gpio_nreset, 0);
+ gpio_free(gpio_nreset);
+
+ gpio_set_value(EP93XX_GPIO_LINE_EGPIO6, 1);
+ gpio_free(EP93XX_GPIO_LINE_EGPIO6);
+}
+
+static void edb93xx_cs4271_hw_cs_control(struct spi_device *spi, int value)
+{
+ gpio_set_value(EP93XX_GPIO_LINE_EGPIO6, value);
+}
+
+static struct ep93xx_spi_chip_ops edb93xx_cs4271_hw = {
+ .setup = edb93xx_cs4271_hw_setup,
+ .cleanup = edb93xx_cs4271_hw_cleanup,
+ .cs_control = edb93xx_cs4271_hw_cs_control,
+};
+
+static struct spi_board_info edb93xx_spi_board_info[] __initdata = {
+ {
+ .modalias = "cs4271",
+ .controller_data = &edb93xx_cs4271_hw,
+ .max_speed_hz = 6000000,
+ .bus_num = 0,
+ .chip_select = 0,
+ .mode = SPI_MODE_3,
+ },
+};
+
+static struct ep93xx_spi_info edb93xx_spi_info = {
+ .num_chipselect = ARRAY_SIZE(edb93xx_spi_board_info),
+};
+
+static void __init edb93xx_register_spi(void)
+{
+ if (edb93xx_has_audio()) {
+ ep93xx_register_spi(&edb93xx_spi_info,
+ edb93xx_spi_board_info,
+ ARRAY_SIZE(edb93xx_spi_board_info));
+ }
+}
+
+
+/*************************************************************************
+ * EDB93xx I2S
+ *************************************************************************/
+static void __init edb93xx_register_i2s(void)
+{
+ if (edb93xx_has_audio()) {
+ ep93xx_register_i2s();
+ }
+}
+
+
+/*************************************************************************
* EDB93xx pwm
*************************************************************************/
static void __init edb93xx_register_pwm(void)
@@ -117,6 +232,8 @@ static void __init edb93xx_init_machine(void)
edb93xx_register_flash();
ep93xx_register_eth(&edb93xx_eth_data, 1);
edb93xx_register_i2c();
+ edb93xx_register_spi();
+ edb93xx_register_i2s();
edb93xx_register_pwm();
}
^ permalink raw reply related
* Re: [PATCH net-2.6 2/2] be2net: remove netif_stop_queue being called before register_netdev.
From: David Miller @ 2011-02-01 23:42 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20110131232755.GA4691@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@emulex.com>
Date: Mon, 31 Jan 2011 17:27:55 -0600
> It is illegal to call netif_stop_queue before register_netdev.
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Applied, thanks.
^ permalink raw reply
* [folded] epoll-epoll_wait-should-not-use-timespec_add_ns-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:44 UTC (permalink / raw)
To: akpm, davidel, eric.dumazet, shawn.bohrer, sim, stable,
mm-commits
The patch titled
epoll-epoll_wait-should-not-use-timespec_add_ns-fix
has been removed from the -mm tree. Its filename was
epoll-epoll_wait-should-not-use-timespec_add_ns-fix.patch
This patch was dropped because it was folded into epoll-epoll_wait-should-not-use-timespec_add_ns.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: epoll-epoll_wait-should-not-use-timespec_add_ns-fix
From: Andrew Morton <akpm@linux-foundation.org>
s/epoll_set_mstimeout/ep_set_mstimeout/, per Davide
Cc: <stable@kernel.org> [2.6.37.x]
Cc: Davide Libenzi <davidel@xmailserver.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Shawn Bohrer <shawn.bohrer@gmail.com>
Cc: Simon Kirby <sim@hostway.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/eventpoll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN fs/eventpoll.c~epoll-epoll_wait-should-not-use-timespec_add_ns-fix fs/eventpoll.c
--- a/fs/eventpoll.c~epoll-epoll_wait-should-not-use-timespec_add_ns-fix
+++ a/fs/eventpoll.c
@@ -1114,7 +1114,7 @@ static int ep_send_events(struct eventpo
return ep_scan_ready_list(ep, ep_send_events_proc, &esed);
}
-static inline struct timespec epoll_set_mstimeout(long ms)
+static inline struct timespec ep_set_mstimeout(long ms)
{
struct timespec now, ts = {
.tv_sec = ms / MSEC_PER_SEC,
@@ -1135,7 +1135,7 @@ static int ep_poll(struct eventpoll *ep,
ktime_t expires, *to = NULL;
if (timeout > 0) {
- struct timespec end_time = epoll_set_mstimeout(timeout);
+ struct timespec end_time = ep_set_mstimeout(timeout);
slack = select_estimate_accuracy(&end_time);
to = &expires;
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
epoll-epoll_wait-should-not-use-timespec_add_ns.patch
maintainers-fixup-simtec-support-email-entries-fix.patch
thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes.patch
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix.patch
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
leds-convert-bd2802-driver-to-dev_pm_ops-fix.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-backlight-type-fix.patch
backlight-add-backlight-type-fix-fix.patch
fs-ocfs2-dlm-dlmdomainc-avoid-a-gfp_atomic-allocation.patch
drivers-message-fusion-mptsasc-fix-warning.patch
drbd-fix-warning.patch
mm.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch
scatterlist-new-helper-functions.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
* Re: [PATCH 16/32] scsi/be2iscsi,qla2xxx: convert to alloc_workqueue()
From: Mike Christie @ 2011-02-01 23:45 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, Jayamohan Kallickal, Andrew Vasquez,
James E.J. Bottomley, linux-scsi
In-Reply-To: <1294062595-30097-17-git-send-email-tj@kernel.org>
On 01/03/2011 07:49 AM, Tejun Heo wrote:
> diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
> index 75a85aa..4339196 100644
> --- a/drivers/scsi/be2iscsi/be_main.c
> +++ b/drivers/scsi/be2iscsi/be_main.c
> @@ -4276,7 +4276,7 @@ static int __devinit beiscsi_dev_probe(struct pci_dev *pcidev,
>
> snprintf(phba->wq_name, sizeof(phba->wq_name), "beiscsi_q_irq%u",
> phba->shost->host_no);
> - phba->wq = create_workqueue(phba->wq_name);
> + phba->wq = alloc_workqueue(phba->wq_name, WQ_MEM_RECLAIM, 1);
> if (!phba->wq) {
> shost_printk(KERN_ERR, phba->shost, "beiscsi_dev_probe-"
> "Failed to allocate work queue\n");
> diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
> index 2c0876c..2cd0a77 100644
> --- a/drivers/scsi/qla2xxx/qla_os.c
> +++ b/drivers/scsi/qla2xxx/qla_os.c
> @@ -356,7 +356,7 @@ static int qla25xx_setup_mode(struct scsi_qla_host *vha)
> "Can't create request queue\n");
> goto fail;
> }
> - ha->wq = create_workqueue("qla2xxx_wq");
> + ha->wq = alloc_workqueue("qla2xxx_wq", WQ_MEM_RECLAIM, 1);
> vha->req = ha->req_q_map[req];
> options |= BIT_1;
> for (ques = 1; ques< ha->max_rsp_queues; ques++) {
I think these are used in the main IO path, so would you also want
WQ_HIGHPRI | WQ_CPU_INTENSIVE to be set? I think qla2xxx was using this
in a path they expected to have high throughput/low latency, and from
the interrupt handler they would try to queue the work on the same cpu
the isr was answered on. With the new workqueue code could you possibly
get queued onto a workqueue that is doing other work for other drivers?
Should qla2xxx be using the blkiopoll framework instead of a workqueue
or will workqueues still provide the same performance when setting
WQ_HIGHPRI | WQ_CPU_INTENSIVE?
^ permalink raw reply
* RE: [PATCH] md: do not write resync checkpoint, if max_sector has been reached.
From: Hawrylewicz Czarnowski, Przemyslaw @ 2011-02-01 23:45 UTC (permalink / raw)
To: NeilBrown
Cc: linux-raid@vger.kernel.org, Neubauer, Wojciech, Williams, Dan J,
Ciechanowski, Ed
In-Reply-To: <20110201120752.00a9b534@notabene.brown>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of NeilBrown
> Sent: Tuesday, February 01, 2011 2:08 AM
> To: Hawrylewicz Czarnowski, Przemyslaw
> Cc: linux-raid@vger.kernel.org; Neubauer, Wojciech; Williams, Dan J;
> Ciechanowski, Ed
> Subject: Re: [PATCH] md: do not write resync checkpoint, if max_sector has
> been reached.
>
[cut]
> > >
> > > This is wrong. If curr_resync has reached some value, then the array
> *is*
> > > in-sync up to that point.
> > >
> > > If a device fails then that often makes the array fully in-sync -
> because
> > > there it no longer any room for inconsistency.
> > > This is particularly true for RAID1. If one drive in a 2-drive RAID1
> > > fails,
> > > then the array instantly becomes in-sync.
> > > For RAID5, we should arguably fail the array at that point rather than
> > > marking it in-sync, but that would probably cause more data loss than
> it
> > > avoids, so we don't.
> > > In any case - the array is now in-sync.
> > Yes, I agree. But it is not the point here, in this bug.
> >
> > >
> > > If a spare is added by mdmon at this time, then the array is not 'out
> of
> > > sync', it is 'in need for recovery'. 'recovery' and 'resync' are
> different
> > > things.
> > I fully understand the difference between recovery and resync (and
> reshape).
> >
> > >
> > > md_check_recovery should run remove_and_add_spares are this point.
> That
> > And it does.
> >
> > > should return a non-zero value (because it found the spare that mdmon
> > > added)
> > But the return value is wrong (it is correct according to current
> configuration). Please let me explain once again what's going on.
> >
> > The flow is as follows:
> > 0. resync is in progress
> > 1. one disk fails
> > 2. md_error() wakes up raid thread
> > 3. md_do_sync() gets skipped=1 from mddev->pers->sync_request() and some
> amount of skipped sectors/stripes - usually all remaining to resync. mddev-
> >recovery_cp is set to last sector (max_sector in md_do_sync)
> > 3a. md_check_recovery() sees MD_RECOVERY_INTR (clears it) and unregisters
> recovery thread (which actually does resync)
> > 3b. mdmon unblocks array member
> > 4. md_check_recovery checks if some action is required.
> > 4a. reshape is not taken into account as reshape_position==MaxSector
> > 4b. recovery is not taken into account as mdmon did not add spare yet
> > 4c. resync is started, as recovery_cp!=MaxSector (!)
> > 5. md_do_sync exists normally (gets skipped=1 from mddev->pers-
> >sync_request()) as checkpoint pointed at the last sector; it clears mddev-
> >recovery_cp.
> > 6. mdmon adds disk (via slot-store())
> > 7. md_check_recovery() does cleanup after finished resync
> > 7a. MD_RECOVERY_INTR is not set anymore, mddev->pers->spare_active() is
> started and ALL devices !In_sync available in array are set in_sync, and
> array degradation is cleared(!).
> > 7b. remove_and_add_spares() does not see spares available (mddev-
> >degraded==0) so recovery does not start.
> >
>
> Thank you for this excellent problem description.
>
> I think the mistake here is at step 6.
> mdmon should not be trying to add a disk until the resync has completed.
> In particular, mdmon shouldn't try, and md should not allow mdmon to
> succeed.
>
> So slot_store should return -EBUSY if MD_RECOVERY_RUNNING is set
>
> mdmon needs to 'know' when a sync/etc is happening, and should avoid
> processing ->check_degraded if it is.
>
> I have added the md fix to my for-next branch.
I took a look at this change. It does no compile. It should be:
if (test_bit(MD_RECOVERY_RUNNING, &rdev->mddev->recovery)
return -EBUSY;
> I might do the mdadm fix later.
Now (without this kernel/mdmon handshaking) there is a infinite loop in manager (it is quite well reproducible for IMSM raid5). I have noticed, that state is still "resync", mdmon continuously sends "-blocked" and manager does not add spare (because of resync). I haven't found root cause why array_state is still "resync", but at first glance after md_do_sync finishes md_check_recovery do not start.
I will make some more tests tomorrow...
Przemek
>
> Thanks,
> NeilBrown
>
>
[cut]
^ permalink raw reply
* [folded] maintainers-fixup-simtec-support-email-entries-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:45 UTC (permalink / raw)
To: akpm, ben-linux, jwjstone, linux, support, vince, mm-commits
The patch titled
maintainers-fixup-simtec-support-email-entries-fix
has been removed from the -mm tree. Its filename was
maintainers-fixup-simtec-support-email-entries-fix.patch
This patch was dropped because it was folded into maintainers-fixup-simtec-support-email-entries.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: maintainers-fixup-simtec-support-email-entries-fix
From: Andrew Morton <akpm@linux-foundation.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Jack Stone <jwjstone@fastmail.fm>
Cc: Simtec Linux Team <linux@simtec.co.uk>
Cc: Simtec Support <support@simtec.co.uk>
Cc: Vincent Sanders <vince@simtec.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN MAINTAINERS~maintainers-fixup-simtec-support-email-entries-fix MAINTAINERS
--- a/MAINTAINERS~maintainers-fixup-simtec-support-email-entries-fix
+++ a/MAINTAINERS
@@ -5622,7 +5622,7 @@ F: include/linux/sfi*.h
SIMTEC EB110ATX (Chalice CATS)
P: Ben Dooks
-P: Vincent Sanders <support@simtec.co.uk>
+P: Vincent Sanders <vince@simtec.co.uk>
M: Simtec Linux Team <linux@simtec.co.uk>
W: http://www.simtec.co.uk/products/EB110ATX/
S: Supported
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
epoll-epoll_wait-should-not-use-timespec_add_ns.patch
maintainers-fixup-simtec-support-email-entries.patch
thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes.patch
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix.patch
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
leds-convert-bd2802-driver-to-dev_pm_ops-fix.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-backlight-type-fix.patch
backlight-add-backlight-type-fix-fix.patch
fs-ocfs2-dlm-dlmdomainc-avoid-a-gfp_atomic-allocation.patch
drivers-message-fusion-mptsasc-fix-warning.patch
drbd-fix-warning.patch
mm.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch
scatterlist-new-helper-functions.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
* Re: [PATCH] Xfstests: make 014 only run on xfs
From: Alex Elder @ 2011-02-01 23:48 UTC (permalink / raw)
To: Dave Chinner; +Cc: Josef Bacik, xfs
In-Reply-To: <20110127005945.GE21311@dastard>
On Thu, 2011-01-27 at 11:59 +1100, Dave Chinner wrote:
> On Wed, Jan 26, 2011 at 09:05:29AM -0500, Josef Bacik wrote:
> > This test relies on mounting with -o allocsize, which is an xfs specific mount
> > option, so make the test only work on xfs. Thanks,
>
> Oh, sorry, my fault. Perhaps something like this instead?
Since test 014 reportedly works on other filesystem
types provided the allocsize option isn't provided,
Dave's version looks better.
Josef will you please take a look over--and preferably
test--what Dave proposed, and if you agree offer your
signoff?
Thanks.
-Alex
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [folded] thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes.patch removed from -mm tree
From: akpm @ 2011-02-01 23:45 UTC (permalink / raw)
To: akpm, aarcange, andi, jin.dongming, seto.hidetoshi, mm-commits
The patch titled
thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes
has been removed from the -mm tree. Its filename was
thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes.patch
This patch was dropped because it was folded into thp-fix-splitting-of-hwpoisoned-hugepages.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes
From: Andrew Morton <akpm@linux-foundation.org>
WARNING: line over 80 characters
#49: FILE: mm/memory-failure.c:900:
+ * PageAnon is just for avoid tripping a split_huge_page internal
WARNING: line over 80 characters
#54: FILE: mm/memory-failure.c:905:
+ * in the first place, having a refcount on the tail isn't enough
WARNING: line over 80 characters
#60: FILE: mm/memory-failure.c:911:
+ * FIXME: if splitting THP is failed, it is better
WARNING: line over 80 characters
#62: FILE: mm/memory-failure.c:913:
+ * causing panic by unmapping. System might survive
total: 0 errors, 4 warnings, 42 lines checked
./patches/thp-fix-splitting-of-hwpoisoned-hugepages.patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory-failure.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff -puN mm/memory-failure.c~thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes mm/memory-failure.c
--- a/mm/memory-failure.c~thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes
+++ a/mm/memory-failure.c
@@ -897,21 +897,21 @@ static int hwpoison_user_mappings(struct
if (PageTransHuge(hpage)) {
/*
* Verify that this isn't a hugetlbfs head page, the check for
- * PageAnon is just for avoid tripping a split_huge_page internal
- * debug check, as split_huge_page refuses to deal with anything
- * that isn't an anon page. PageAnon can't go away from under us
- * because we hold a refcount on the hpage, without a refcount
- * on the hpage. split_huge_page can't be safely called
- * in the first place, having a refcount on the tail isn't enough
- * to be safe.
+ * PageAnon is just for avoid tripping a split_huge_page
+ * internal debug check, as split_huge_page refuses to deal with
+ * anything that isn't an anon page. PageAnon can't go away fro
+ * under us because we hold a refcount on the hpage, without a
+ * refcount on the hpage. split_huge_page can't be safely called
+ * in the first place, having a refcount on the tail isn't
+ * enough * to be safe.
*/
if (!PageHuge(hpage) && PageAnon(hpage)) {
if (unlikely(split_huge_page(hpage))) {
/*
- * FIXME: if splitting THP is failed, it is better
- * to stop the following operation rather than
- * causing panic by unmapping. System might survive
- * if the page is freed later.
+ * FIXME: if splitting THP is failed, it is
+ * better to stop the following operation rather
+ * than causing panic by unmapping. System might
+ * survive if the page is freed later.
*/
printk(KERN_INFO
"MCE %#lx: failed to split THP\n", pfn);
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
epoll-epoll_wait-should-not-use-timespec_add_ns.patch
maintainers-fixup-simtec-support-email-entries.patch
thp-fix-splitting-of-hwpoisoned-hugepages.patch
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix.patch
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
leds-convert-bd2802-driver-to-dev_pm_ops-fix.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-backlight-type-fix.patch
backlight-add-backlight-type-fix-fix.patch
fs-ocfs2-dlm-dlmdomainc-avoid-a-gfp_atomic-allocation.patch
drivers-message-fusion-mptsasc-fix-warning.patch
drbd-fix-warning.patch
mm.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch
scatterlist-new-helper-functions.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
* [folded] thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:46 UTC (permalink / raw)
To: akpm, aarcange, andi, jin.dongming, seto.hidetoshi, mm-commits
The patch titled
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix
has been removed from the -mm tree. Its filename was
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix.patch
This patch was dropped because it was folded into thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix
From: Andrew Morton <akpm@linux-foundation.org>
fix spello in comment
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/huge_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/huge_memory.c~thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix mm/huge_memory.c
--- a/mm/huge_memory.c~thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix
+++ a/mm/huge_memory.c
@@ -1163,7 +1163,7 @@ static void __split_huge_page_refcount(s
smp_mb();
/*
- * remain hwpoison flag of the poisoned tail page:
+ * retain hwpoison flag of the poisoned tail page:
* fix for the unsuitable process killed on Guest Machine(KVM)
* by the memory-failure.
*/
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
epoll-epoll_wait-should-not-use-timespec_add_ns.patch
maintainers-fixup-simtec-support-email-entries.patch
thp-fix-splitting-of-hwpoisoned-hugepages.patch
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages.patch
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
leds-convert-bd2802-driver-to-dev_pm_ops-fix.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-backlight-type-fix.patch
backlight-add-backlight-type-fix-fix.patch
fs-ocfs2-dlm-dlmdomainc-avoid-a-gfp_atomic-allocation.patch
drivers-message-fusion-mptsasc-fix-warning.patch
drbd-fix-warning.patch
mm.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch
scatterlist-new-helper-functions.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
* [folded] thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:46 UTC (permalink / raw)
To: akpm, aarcange, andi, jin.dongming, seto.hidetoshi, mm-commits
The patch titled
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix
has been removed from the -mm tree. Its filename was
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch
This patch was dropped because it was folded into thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix
From: Andrew Morton <akpm@linux-foundation.org>
fix unrelated typo in shake_page() comment
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory-failure.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN mm/memory-failure.c~thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix mm/memory-failure.c
--- a/mm/memory-failure.c~thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix
+++ a/mm/memory-failure.c
@@ -233,8 +233,8 @@ void shake_page(struct page *p, int acce
}
/*
- * Only all shrink_slab here (which would also
- * shrink other caches) if access is not potentially fatal.
+ * Only call shrink_slab here (which would also shrink other caches) if
+ * access is not potentially fatal.
*/
if (access) {
int nr;
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
epoll-epoll_wait-should-not-use-timespec_add_ns.patch
maintainers-fixup-simtec-support-email-entries.patch
thp-fix-splitting-of-hwpoisoned-hugepages.patch
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages.patch
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
leds-convert-bd2802-driver-to-dev_pm_ops-fix.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-backlight-type-fix.patch
backlight-add-backlight-type-fix-fix.patch
fs-ocfs2-dlm-dlmdomainc-avoid-a-gfp_atomic-allocation.patch
drivers-message-fusion-mptsasc-fix-warning.patch
drbd-fix-warning.patch
mm.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch
scatterlist-new-helper-functions.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
* [folded] memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch removed from -mm tree
From: akpm @ 2011-02-01 23:47 UTC (permalink / raw)
To: hannes, balbir, kamezawa.hiroyu, minchan.kim, nishimura,
mm-commits
The patch titled
memcg: prevent endless loop when charging huge pages to near-limit group
has been removed from the -mm tree. Its filename was
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
This patch was dropped because it was folded into memcg-prevent-endless-loop-when-charging-huge-pages.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memcg: prevent endless loop when charging huge pages to near-limit group
From: Johannes Weiner <hannes@cmpxchg.org>
If reclaim after a failed charging was unsuccessful, the limits are
checked again, just in case they settled by means of other tasks.
This is all fine as long as every charge is of size PAGE_SIZE, because in
that case, being below the limit means having at least PAGE_SIZE bytes
available.
But with transparent huge pages, we may end up in an endless loop where
charging and reclaim fail, but we keep going because the limits are not
yet exceeded, although not allowing for a huge page.
Fix this up by explicitely checking for enough room, not just whether we
are within limits.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/res_counter.h | 12 ++++++++++++
mm/memcontrol.c | 27 ++++++++++++++++++++-------
2 files changed, 32 insertions(+), 7 deletions(-)
diff -puN include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group include/linux/res_counter.h
--- a/include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group
+++ a/include/linux/res_counter.h
@@ -182,6 +182,18 @@ static inline bool res_counter_check_und
return ret;
}
+static inline bool res_counter_check_margin(struct res_counter *cnt,
+ unsigned long bytes)
+{
+ bool ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(&cnt->lock, flags);
+ ret = cnt->limit - cnt->usage >= bytes;
+ spin_unlock_irqrestore(&cnt->lock, flags);
+ return ret;
+}
+
static inline bool res_counter_check_under_soft_limit(struct res_counter *cnt)
{
bool ret;
diff -puN mm/memcontrol.c~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group mm/memcontrol.c
--- a/mm/memcontrol.c~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group
+++ a/mm/memcontrol.c
@@ -1111,6 +1111,15 @@ static bool mem_cgroup_check_under_limit
return false;
}
+static bool mem_cgroup_check_margin(struct mem_cgroup *mem, unsigned long bytes)
+{
+ if (!res_counter_check_margin(&mem->res, bytes))
+ return false;
+ if (do_swap_account && !res_counter_check_margin(&mem->memsw, bytes))
+ return false;
+ return true;
+}
+
static unsigned int get_swappiness(struct mem_cgroup *memcg)
{
struct cgroup *cgrp = memcg->css.cgroup;
@@ -1852,15 +1861,19 @@ static int __mem_cgroup_do_charge(struct
return CHARGE_WOULDBLOCK;
ret = mem_cgroup_hierarchical_reclaim(mem_over_limit, NULL,
- gfp_mask, flags);
+ gfp_mask, flags);
+ if (mem_cgroup_check_margin(mem_over_limit, csize))
+ return CHARGE_RETRY;
/*
- * try_to_free_mem_cgroup_pages() might not give us a full
- * picture of reclaim. Some pages are reclaimed and might be
- * moved to swap cache or just unmapped from the cgroup.
- * Check the limit again to see if the reclaim reduced the
- * current usage of the cgroup before giving up
+ * Even though the limit is exceeded at this point, reclaim
+ * may have been able to free some pages. Retry the charge
+ * before killing the task.
+ *
+ * Only for regular pages, though: huge pages are rather
+ * unlikely to succeed so close to the limit, and we fall back
+ * to regular pages anyway in case of failure.
*/
- if (ret || mem_cgroup_check_under_limit(mem_over_limit))
+ if (csize == PAGE_SIZE && ret)
return CHARGE_RETRY;
/*
_
Patches currently in -mm which might be from hannes@cmpxchg.org are
memcg-prevent-endless-loop-when-charging-huge-pages.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch
memcg-never-oom-when-charging-huge-pages.patch
memcg-fix-event-counting-breakage-by-recent-thp-update.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path-fix.patch
memcg-res_counter_read_u64-fix-potential-races-on-32-bit-machines.patch
memcg-fix-ugly-initialization-of-return-value-is-in-caller.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
^ permalink raw reply
* [folded] memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:47 UTC (permalink / raw)
To: hannes, balbir, kamezawa.hiroyu, minchan.kim, nishimura,
mm-commits
The patch titled
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
has been removed from the -mm tree. Its filename was
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch
This patch was dropped because it was folded into memcg-prevent-endless-loop-when-charging-huge-pages.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
From: Johannes Weiner <hannes@cmpxchg.org>
res_counter: document res_counter_check_margin()
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/res_counter.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix include/linux/res_counter.h
--- a/include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
+++ a/include/linux/res_counter.h
@@ -182,6 +182,14 @@ static inline bool res_counter_check_und
return ret;
}
+/**
+ * res_counter_check_margin - check if the counter allows charging
+ * @cnt: the resource counter to check
+ * @bytes: the number of bytes to check the remaining space against
+ *
+ * Returns a boolean value on whether the counter can be charged
+ * @bytes or whether this would exceed the limit.
+ */
static inline bool res_counter_check_margin(struct res_counter *cnt,
unsigned long bytes)
{
_
Patches currently in -mm which might be from hannes@cmpxchg.org are
memcg-prevent-endless-loop-when-charging-huge-pages.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch
memcg-never-oom-when-charging-huge-pages.patch
memcg-fix-event-counting-breakage-by-recent-thp-update.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path-fix.patch
memcg-res_counter_read_u64-fix-potential-races-on-32-bit-machines.patch
memcg-fix-ugly-initialization-of-return-value-is-in-caller.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
^ permalink raw reply
* how to get PHY error codes from AR9382 / HB116
From: George Nychis @ 2011-02-01 23:48 UTC (permalink / raw)
To: linux-wireless, Eric Rozner
Hi all,
I have an Atheros AR9382 chipset, on the 2x2 HB116.
I was wondering if anyone knows how to enable PHY error codes on this
card/chipset being passed up. Including synchronization errors, like
in the PLCP.
In: drivers/net/wireless/ath/ath9k/hw.c, and function: void
ath9k_hw_setrxfilter(struct ath_hw *ah, u32 bits)
... I did a REG_WRITE(ah, AR_PHY_ERR, 0xffffffff); to enable all phy
error packets upwards in terms of the RX filter.
I am also setting the following in ath9k_hw_ani_init
(drivers/net/wireless/ath/ath9k/ani.c)
REG_WRITE(ah, AR_PHY_ERR_1, ah->ani[0].ofdmPhyErrBase);
REG_WRITE(ah, AR_PHY_ERR_2, ah->ani[0].cckPhyErrBase);
I am also commented this out in drivers/net/wireless/ath/ath9k/recv.c:
rfilt |= ATH9K_RX_FILTER_PHYERR;
I've also tried forcing the card in to promiscuous mode.
However, when I get errored packets up from the card, they all have
the same error type which is 0x00, which makes me believe that the
actual error bits are not being set, or something along these lines.
Does anyone know what I might be missing? I'd greatly appreciate any help.
- George
^ permalink raw reply
* [folded] memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:48 UTC (permalink / raw)
To: hannes, balbir, kamezawa.hiroyu, minchan.kim, nishimura,
mm-commits
The patch titled
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix
has been removed from the -mm tree. Its filename was
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch
This patch was dropped because it was folded into memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix
From: Johannes Weiner <hannes@cmpxchg.org>
*oink*
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memcontrol.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN mm/memcontrol.c~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix mm/memcontrol.c
--- a/mm/memcontrol.c~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix
+++ a/mm/memcontrol.c
@@ -1111,6 +1111,14 @@ static bool mem_cgroup_check_under_limit
return false;
}
+/**
+ * mem_cgroup_check_margin - check if the memory cgroup allows charging
+ * @mem: memory cgroup to check
+ * @bytes: the number of bytes the caller intends to charge
+ *
+ * Returns a boolean value on whether @mem can be charged @bytes or
+ * whether this would exceed the limit.
+ */
static bool mem_cgroup_check_margin(struct mem_cgroup *mem, unsigned long bytes)
{
if (!res_counter_check_margin(&mem->res, bytes))
_
Patches currently in -mm which might be from hannes@cmpxchg.org are
memcg-prevent-endless-loop-when-charging-huge-pages.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
memcg-never-oom-when-charging-huge-pages.patch
memcg-fix-event-counting-breakage-by-recent-thp-update.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path-fix.patch
memcg-res_counter_read_u64-fix-potential-races-on-32-bit-machines.patch
memcg-fix-ugly-initialization-of-return-value-is-in-caller.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
^ permalink raw reply
* [folded] memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:48 UTC (permalink / raw)
To: hannes, balbir, kamezawa.hiroyu, minchan.kim, nishimura,
mm-commits
The patch titled
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
has been removed from the -mm tree. Its filename was
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch
This patch was dropped because it was folded into memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
From: Johannes Weiner <hannes@cmpxchg.org>
res_counter: document res_counter_check_margin()
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/res_counter.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix include/linux/res_counter.h
--- a/include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
+++ a/include/linux/res_counter.h
@@ -182,6 +182,14 @@ static inline bool res_counter_check_und
return ret;
}
+/**
+ * res_counter_check_margin - check if the counter allows charging
+ * @cnt: the resource counter to check
+ * @bytes: the number of bytes to check the remaining space against
+ *
+ * Returns a boolean value on whether the counter can be charged
+ * @bytes or whether this would exceed the limit.
+ */
static inline bool res_counter_check_margin(struct res_counter *cnt,
unsigned long bytes)
{
_
Patches currently in -mm which might be from hannes@cmpxchg.org are
memcg-prevent-endless-loop-when-charging-huge-pages.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch
memcg-never-oom-when-charging-huge-pages.patch
memcg-fix-event-counting-breakage-by-recent-thp-update.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path-fix.patch
memcg-res_counter_read_u64-fix-potential-races-on-32-bit-machines.patch
memcg-fix-ugly-initialization-of-return-value-is-in-caller.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
^ permalink raw reply
* [PATCH] MAINTAINERS: remove stale reference to Chris Wright's LSM tree
From: Lucian Adrian Grijincu @ 2011-02-01 23:51 UTC (permalink / raw)
To: linux-kernel, Chris Wright; +Cc: Lucian Adrian Grijincu
A quick glance at [1] will show that the tree hasn't been updated
since June 2008 => No need to have a reference to it.
[1] http://git.kernel.org/?p=linux/kernel/git/chrisw/lsm-2.6.git;a=summary
Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
---
MAINTAINERS | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 445537d..0a4b0ff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3866,7 +3866,6 @@ F: drivers/*/*/*pasemi*
LINUX SECURITY MODULE (LSM) FRAMEWORK
M: Chris Wright <chrisw@sous-sol.org>
L: linux-security-module@vger.kernel.org
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrisw/lsm-2.6.git
S: Supported
LLC (802.2)
--
1.7.4.rc1.7.g2cf08.dirty
^ permalink raw reply related
* [PATCH] arm: mach-omap2: mux: free allocated memory on error exit
From: Tony Lindgren @ 2011-02-01 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296226255-5694-1-git-send-email-aaro.koskinen@nokia.com>
* Aaro Koskinen <aaro.koskinen@nokia.com> [110128 06:47]:
> Free allocated memory on error exit.
>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
> ---
> arch/arm/mach-omap2/mux.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index df8d2f2..18aea0c 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -1000,6 +1000,7 @@ int __init omap_mux_init(const char *name, u32 flags,
> if (!partition->base) {
> pr_err("%s: Could not ioremap mux partition at 0x%08x\n",
> __func__, partition->phys);
> + kfree(partition);
> return -ENODEV;
> }
Thanks, adding into devel-fixes for the -rc cycle.
Tony
^ permalink raw reply
* Re: [PATCH] arm: mach-omap2: mux: free allocated memory on error exit
From: Tony Lindgren @ 2011-02-01 23:52 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: linux-arm-kernel, linux-omap
In-Reply-To: <1296226255-5694-1-git-send-email-aaro.koskinen@nokia.com>
* Aaro Koskinen <aaro.koskinen@nokia.com> [110128 06:47]:
> Free allocated memory on error exit.
>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
> ---
> arch/arm/mach-omap2/mux.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index df8d2f2..18aea0c 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -1000,6 +1000,7 @@ int __init omap_mux_init(const char *name, u32 flags,
> if (!partition->base) {
> pr_err("%s: Could not ioremap mux partition at 0x%08x\n",
> __func__, partition->phys);
> + kfree(partition);
> return -ENODEV;
> }
Thanks, adding into devel-fixes for the -rc cycle.
Tony
^ permalink raw reply
* [PATCH] arm: mach-omap2: board-rm680: fix rm680_vemmc regulator constraints
From: Tony Lindgren @ 2011-02-01 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201202725.804aa011.jhnikula@gmail.com>
* Jarkko Nikula <jhnikula@gmail.com> [110201 10:26]:
> On Tue, 1 Feb 2011 17:36:28 +0200
> Aaro Koskinen <aaro.koskinen@nokia.com> wrote:
>
> > With the commit 757902513019e6ee469791ff76f954b19ca8d036 fixed voltage
> > regulator setup will fail if there are voltage constraints defined. This
> > made MMC unusable on this board. Fix by just deleting those redundant
> > constraints.
> >
> True. Before there were a test min_uV == max_uV && ops->set_voltage and
> now min_uV == max_uV followed by test for ops->set_voltage that returns
> EINVAL if not set (NULL for fixed voltage regulator obviously).
>
> Reviewed-by: Jarkko Nikula <jhnikula@gmail.com>
Thanks adding into devel-fixes.
Tony
^ permalink raw reply
* Re: [PATCH] arm: mach-omap2: board-rm680: fix rm680_vemmc regulator constraints
From: Tony Lindgren @ 2011-02-01 23:52 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: Aaro Koskinen, linux-omap, linux-arm-kernel
In-Reply-To: <20110201202725.804aa011.jhnikula@gmail.com>
* Jarkko Nikula <jhnikula@gmail.com> [110201 10:26]:
> On Tue, 1 Feb 2011 17:36:28 +0200
> Aaro Koskinen <aaro.koskinen@nokia.com> wrote:
>
> > With the commit 757902513019e6ee469791ff76f954b19ca8d036 fixed voltage
> > regulator setup will fail if there are voltage constraints defined. This
> > made MMC unusable on this board. Fix by just deleting those redundant
> > constraints.
> >
> True. Before there were a test min_uV == max_uV && ops->set_voltage and
> now min_uV == max_uV followed by test for ops->set_voltage that returns
> EINVAL if not set (NULL for fixed voltage regulator obviously).
>
> Reviewed-by: Jarkko Nikula <jhnikula@gmail.com>
Thanks adding into devel-fixes.
Tony
^ permalink raw reply
* Re: [PATCH 1/4] omap1: remove duplicated #include
From: Tony Lindgren @ 2011-02-01 23:53 UTC (permalink / raw)
To: Huang Weiyi; +Cc: linux-omap
In-Reply-To: <1296223478-728-1-git-send-email-weiyi.huang@gmail.com>
* Huang Weiyi <weiyi.huang@gmail.com> [110128 06:03]:
> Remove duplicated #include('s) in
> arch/arm/mach-omap1/time.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
> ---
> arch/arm/mach-omap1/time.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
> index f83fc33..6885d2f 100644
> --- a/arch/arm/mach-omap1/time.c
> +++ b/arch/arm/mach-omap1/time.c
> @@ -44,7 +44,6 @@
> #include <linux/clocksource.h>
> #include <linux/clockchips.h>
> #include <linux/io.h>
> -#include <linux/sched.h>
>
> #include <asm/system.h>
> #include <mach/hardware.h>
Thanks queuing this as a fix for the -rc cycle.
Tony
^ permalink raw reply
* another test message (checking List-ID: header)
From: David Rientjes @ 2011-02-01 23:55 UTC (permalink / raw)
To: linux-mm
Test message for Gmail diagnostics, please ignore.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Mutual Aid Stash of Fortune
From: George @ 2011-02-01 23:56 UTC (permalink / raw)
Mutual Aid Stash of Fortune
Hi
I would hold back certain information for security reasons for now until
you have found time to visit the BBC website stated below to enable you
have an insight into what I intend sharing with you.
http://news.bbc.co.uk/2/hi/middle_east/2988455.stm
Get back to me having visited the above website with this email:
ivannickerson.claims-/E1597aS9LTXPF5Rlphj1Q@public.gmane.org
Best Regards
A former member of the 3rd Infantry Division
^ permalink raw reply
* Re: [PATCH] ASoC: EDB93xx machine sound driver with CS4271
From: Alexander Sverdlin @ 2011-02-01 23:58 UTC (permalink / raw)
To: todorcolov; +Cc: alsa-devel
Dear Todor,
> Zdrastvuj Aleks,
> I'd like to test the sound module. Which is the latest patch versions
> and
> coresponding kernel version? In which official kernel release do you
> plan to
> merge it?
As I can conclude from list, you should see it in 2.6.39 and possibly
-next already. 75% of the driver has been merged already. All you have
to do to start testing is to add patch that I've just sent to the list
([PATCH] EDB93xx: Add support for CS4271 CODEC on EDB93xx boards).
Best regards,
Alexander.
^ permalink raw reply
* [U-Boot] [GIT PULL] Pull request: u-boot-imx
From: Albert ARIBAUD @ 2011-02-01 23:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4D484D2F.4070305@denx.de>
Hi Stefano,
Le 01/02/2011 19:13, Stefano Babic a ?crit :
> Hi Albert,
>
> here my pull request for u-boot-imx. Since my last pull-request, I
> rebased my tree to substitute:
>
> imximage: Add MX53 boot image support
>
> I fixed the wrong mode,too, and I cherry-picked from u-boot-arm:
>
> ARM: fix broken build of ARM
>
> that you have already merged, to avoid leaving u-boot-imx broken. I hope
> this is not a problem for you.
Pulled into u-boot-arm/master, thanks -- had to force update, though.
Amicalement,
--
Albert.
^ 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.