* quota lockdep while running ext4 xfstests #219
From: Theodore Ts'o @ 2011-04-11 2:16 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-ext4
Hi Jan,
FYI, I manage to trigger the following lockdep warning while running
v2.6.39-rc1 plus the ext4 patch queue. None of the patches except for
your "ext4: remove unnecessary [cm]time update of quota file" patch
should affect the quota operations, and I don't think this patch should
have caused this, either.
I'm going to ignore this now, since it was triggered by repquota, and
I'm guessing it should occur rarely, but I thought I should let you know
in case I'm misjudging things.
Regards,
- Ted
219 7s ...[ 3314.895274] EXT4-fs (vdc1): warning: maximal mount count reached, running e2fsck is recommended
[ 3315.676490]
[ 3315.676493] =======================================================
[ 3315.679704] [ INFO: possible circular locking dependency detected ]
[ 3315.679704] 2.6.39-rc1-00009-g19e2b53 #1508
[ 3315.679704] -------------------------------------------------------
[ 3315.679704] repquota/10186 is trying to acquire lock:
[ 3315.679704] (&mm->mmap_sem){++++++}, at: [<c01e3cce>] might_fault+0x4c/0x8a
[ 3315.679704]
[ 3315.679704] but task is already holding lock:
[ 3315.679704] (&type->s_umount_key#21){+++++.}, at: [<c01fd7b2>] get_super+0x55/0x98
[ 3315.679704]
[ 3315.679704] which lock already depends on the new lock.
[ 3315.679704]
[ 3315.679704]
[ 3315.679704] the existing dependency chain (in reverse order) is:
[ 3315.679704]
[ 3315.679704] -> #2 (&type->s_umount_key#21){+++++.}:
[ 3315.679704] [<c0189957>] lock_acquire+0x99/0xbd
[ 3315.679704] [<c0688727>] down_read+0x39/0x76
[ 3315.679704] [<c0216db5>] writeback_inodes_sb_if_idle+0x26/0x3d
[ 3315.679704] [<c026392b>] ext4_da_write_begin+0xfe/0x27d
[ 3315.679704] [<c025e04c>] ext4_page_mkwrite+0x14b/0x198
[ 3315.679704] [<c01e6220>] __do_fault+0xfd/0x346
[ 3315.679704] [<c01e70a5>] handle_pte_fault+0x318/0x73c
[ 3315.679704] [<c01e7589>] handle_mm_fault+0xc0/0xd2
[ 3315.679704] [<c068c3c8>] do_page_fault+0x362/0x37e
[ 3315.679704] [<c0689fab>] error_code+0x5f/0x64
[ 3315.679704]
[ 3315.679704] -> #1 (&sb->s_type->i_alloc_sem_key#3){++++..}:
[ 3315.679704] [<c0189957>] lock_acquire+0x99/0xbd
[ 3315.679704] [<c0688727>] down_read+0x39/0x76
[ 3315.679704] [<c025df32>] ext4_page_mkwrite+0x31/0x198
[ 3315.679704] [<c01e6220>] __do_fault+0xfd/0x346
[ 3315.679704] [<c01e70a5>] handle_pte_fault+0x318/0x73c
[ 3315.679704] [<c01e7589>] handle_mm_fault+0xc0/0xd2
[ 3315.679704] [<c068c3c8>] do_page_fault+0x362/0x37e
[ 3315.679704] [<c0689fab>] error_code+0x5f/0x64
[ 3315.679704]
[ 3315.679704] -> #0 (&mm->mmap_sem){++++++}:
[ 3315.679704] [<c018964d>] __lock_acquire+0x926/0xb97
[ 3315.679704] [<c0189957>] lock_acquire+0x99/0xbd
[ 3315.679704] [<c01e3ced>] might_fault+0x6b/0x8a
[ 3315.679704] [<c036e6f0>] copy_to_user+0x34/0x10c
[ 3315.679704] [<c02365d1>] do_quotactl+0x247/0x39c
[ 3315.679704] [<c0236830>] sys_quotactl+0x10a/0x136
[ 3315.679704] [<c06898dd>] syscall_call+0x7/0xb
[ 3315.679704]
[ 3315.679704] other info that might help us debug this:
[ 3315.679704]
[ 3315.679704] 1 lock held by repquota/10186:
[ 3315.679704] #0: (&type->s_umount_key#21){+++++.}, at: [<c01fd7b2>] get_super+0x55/0x98
[ 3315.679704]
[ 3315.679704] stack backtrace:
[ 3315.679704] Pid: 10186, comm: repquota Not tainted 2.6.39-rc1-00009-g19e2b53 #1508
[ 3315.679704] Call Trace:
[ 3315.679704] [<c0188099>] print_circular_bug+0x90/0x9c
[ 3315.679704] [<c018964d>] __lock_acquire+0x926/0xb97
[ 3315.679704] [<c01876d3>] ? mark_lock+0x1e/0x1df
[ 3315.679704] [<c0189957>] lock_acquire+0x99/0xbd
[ 3315.679704] [<c01e3cce>] ? might_fault+0x4c/0x8a
[ 3315.679704] [<c01e3ced>] might_fault+0x6b/0x8a
[ 3315.679704] [<c01e3cce>] ? might_fault+0x4c/0x8a
[ 3315.679704] [<c036e6f0>] copy_to_user+0x34/0x10c
[ 3315.679704] [<c02365d1>] do_quotactl+0x247/0x39c
[ 3315.679704] [<c01fd7b2>] ? get_super+0x55/0x98
[ 3315.679704] [<c01fd7b2>] ? get_super+0x55/0x98
[ 3315.679704] [<c0236830>] sys_quotactl+0x10a/0x136
[ 3315.679704] [<c06898dd>] syscall_call+0x7/0xb
^ permalink raw reply
* (no subject)
From: TONY KINGS @ 2011-04-11 2:15 UTC (permalink / raw)
To: linux-sh
--
Are you in need of getting a loan today.Contact us via mail
at:tonykings_loans@yahoo.com
^ permalink raw reply
* [PATCH v4] mmc: sdhci: add error checking for mmc_add_host
From: Jaehoon Chung @ 2011-04-11 2:11 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org; +Cc: Chris Ball, Wolfram Sang, Kyungmin Park
Sometimes we can't add the device,but we didn't check any error status.
Need to check error status for mmc_add_host.
And Missing regulator disable/put. Fixed them.
[PATCH v4] : merged for v3 [PATCH 1/2] and [PATCH 2/2] reviewed on Wolfram Sang
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/mmc/host/sdhci.c | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9e15f41..e9cb09c 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2025,7 +2025,9 @@ int sdhci_add_host(struct sdhci_host *host)
mmiowb();
- mmc_add_host(mmc);
+ ret = mmc_add_host(mmc);
+ if (unlikely(ret))
+ goto err_free_mmc;
printk(KERN_INFO "%s: SDHCI controller on %s [%s] using %s\n",
mmc_hostname(mmc), host->hw_name, dev_name(mmc_dev(mmc)),
@@ -2036,15 +2038,31 @@ int sdhci_add_host(struct sdhci_host *host)
return 0;
+err_free_mmc:
+ mmc_remove_host(host);
+
#ifdef SDHCI_USE_LEDS_CLASS
+ led_classdev_ungregister(&host->led);
reset:
+#endif
sdhci_reset(host, SDHCI_RESET_ALL);
free_irq(host->irq, host);
-#endif
+ del_timer_sync(&host->timer);
+ if (host->vmmc) {
+ regulator_disable(host->vmmc);
+ regulator_put(host->vmmc);
+ }
+
untasklet:
tasklet_kill(&host->card_tasklet);
tasklet_kill(&host->finish_tasklet);
+ kfree(host->adma_desc);
+ kfree(host->align_buffer);
+
+ host->adma_desc = NULL;
+ host->align_buffer = NULL;
+
return ret;
}
^ permalink raw reply related
* [Buildroot] xterm vs rxvt
From: Michael J. Hammel @ 2011-04-11 2:12 UTC (permalink / raw)
To: buildroot
I noticed rxvt was pulled back in June last year. I've been trying to
get xterm running with 2011.02. It builds okay but fails to run. I've
applied two patches that showed up since 2011.02 was released but that
hasn't helped. The best info I can get so far is that there is a malloc
failure. I have a hunch it might be a problem with network
configuration (only loopback is enabled) and/or missing or improperly
created authorization files, but was not able to narrow it down. Strace
didn't tell me much.
rxvt, on the other hand, builds and runs just fine. I can find no
problems with it yet. I have a package and patch to put it back in if
anyone wants it. I was about to post an enhancement request when I
noticed it had already been pulled once before.
I know its old and not actively maintained, but is there something
specific about why rxvt is considered buggy?
http://git.buildroot.net/buildroot/commit/?id=bb43b2408696787ad90450c9417a2114bbf3949b
--
Michael J. Hammel <buildroot@graphics-muse.org>
^ permalink raw reply
* (no subject)
From: TONY KINGS @ 2011-04-11 2:08 UTC (permalink / raw)
To: linux-sctp
--
Are you in need of getting a loan today.Contact us via mail
at:tonykings_loans@yahoo.com
^ permalink raw reply
* [U-Boot] [PATCH v7 01/10] nds32: add header files support for nds32
From: Macpaul Lin @ 2011-04-11 2:05 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BANLkTi=haZVW17eNWYCmYf3McrGmbm-4Xw@mail.gmail.com>
Hi Wolfgang,
>>> I did check typedefs one by one by myself in hand and eye checking.
>>> If some thing is not suitable for using "typedefs" please let me know.
>>
>> Please don't add any new typedef's.
>>
>
> I think we still have to discuss about the typedef's.
> What does the "new" typedef means?
>
> According to the checkpatch result, "typedef" warning exists in 4 files.
> arch/nds32/include/asm/posix_types.h
> arch/nds32/include/asm/types.h
> arch/nds32/include/asm/global_data.h
> arch/nds32/include/asm/u-boot.h.
>
I've found the origin purpose of adding typedef check to checkpatch.pl
from the author "apw".
Please refer to url
"http://lkml.indiana.edu/hypermail/linux/kernel/0801.0/0354.html"
I quote his words as below.
Andy Whitcroft (apw said..)
"It is checkpatch's role to point out things which are likely to be
wrong. There will always be exceptions. Lines which are much more
readable if they spill over 80 characters, typedefs which do make sense.
atomic_t's for example. This may well be a valid use of them. Note
that this is mentioned as a WARNING not an ERROR. As is stated in the
patch submission notes, you are meant to be comfortable with everything
which checkpatch is still reporting.
checkpatch is a style _guide_, not the be all and end all. It is meant
to carry a preferred style to try and maintain some consistency kernel
wide."
There is also a section of the coding style which related to "typedef" in Linux
Kernel's Documents.
Please also refer to "Chapter 5, typedef" in "Documentation/CodingStyle".
Hope this information is helping other patch submitters. Thanks.
--
Best regards,
Macpaul Lin
^ permalink raw reply
* Re: [PATCH] nand: Fix S3C NAND clock stop
From: Randy Dunlap @ 2011-04-11 2:05 UTC (permalink / raw)
To: Jiri Pinkava
Cc: ben-linux, kgene.kim, dwmw2, linux-arm-kernel, linux-mtd,
linux-kernel
In-Reply-To: <1302485262-8401-1-git-send-email-jiri.pinkava@vscht.cz>
On 4/10/2011 6:27 PM, Jiri Pinkava wrote:
> Current implementation of s3c2410_nand_select_chip call
> clk_disable every time when chip = -1 (de-select). This happend
> multiple times even if chip was already de-selected. This causes
> disabling clock even if they are already disabled and due to
> nature of clock subsytem implementation this causes nand clock
> to be disabled and newer enabled again.
>
> Signed-off-by: Jiri Pinkava<jiri.pinkava@vscht.cz>
> ---
> drivers/mtd/nand/s3c2410.c | 57 +++++++++++++++++++++++++++++++------------
> 1 files changed, 41 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index 33d832d..79e18a3 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
> @@ -159,11 +165,33 @@ static struct s3c2410_platform_nand *to_nand_plat(struct platform_device *dev)
> return dev->dev.platform_data;
> }
>
> -static inline int allow_clk_stop(struct s3c2410_nand_info *info)
> +static inline int allow_clk_suspend(struct s3c2410_nand_info *info)
> {
> return clock_stop;
> }
>
> +/**
> + * s3c2410_nand_clk_set_state - Enable, disable or suspend NAND clock.
> + * @info: The controller instance.
> + * @state: State to which clock should be set.
@new_state:
> + */
> +static void s3c2410_nand_clk_set_state(struct s3c2410_nand_info *info,
> + int new_state)
> +{
> + if (!allow_clk_suspend(info)&& new_state == CLOCK_SUSPEND)
> + return;
> +
> + if (clock_state == CLOCK_ENABLE) {
> + if (new_state != CLOCK_ENABLE)
> + clk_disable(info->clk);
> + } else {
> + if (new_state == CLOCK_ENABLE)
> + clk_enable(info->clk);
> + }
> +
> + clock_state = new_state;
> +}
^ permalink raw reply
* [PATCH] nand: Fix S3C NAND clock stop
From: Randy Dunlap @ 2011-04-11 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1302485262-8401-1-git-send-email-jiri.pinkava@vscht.cz>
On 4/10/2011 6:27 PM, Jiri Pinkava wrote:
> Current implementation of s3c2410_nand_select_chip call
> clk_disable every time when chip = -1 (de-select). This happend
> multiple times even if chip was already de-selected. This causes
> disabling clock even if they are already disabled and due to
> nature of clock subsytem implementation this causes nand clock
> to be disabled and newer enabled again.
>
> Signed-off-by: Jiri Pinkava<jiri.pinkava@vscht.cz>
> ---
> drivers/mtd/nand/s3c2410.c | 57 +++++++++++++++++++++++++++++++------------
> 1 files changed, 41 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index 33d832d..79e18a3 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
> @@ -159,11 +165,33 @@ static struct s3c2410_platform_nand *to_nand_plat(struct platform_device *dev)
> return dev->dev.platform_data;
> }
>
> -static inline int allow_clk_stop(struct s3c2410_nand_info *info)
> +static inline int allow_clk_suspend(struct s3c2410_nand_info *info)
> {
> return clock_stop;
> }
>
> +/**
> + * s3c2410_nand_clk_set_state - Enable, disable or suspend NAND clock.
> + * @info: The controller instance.
> + * @state: State to which clock should be set.
@new_state:
> + */
> +static void s3c2410_nand_clk_set_state(struct s3c2410_nand_info *info,
> + int new_state)
> +{
> + if (!allow_clk_suspend(info)&& new_state == CLOCK_SUSPEND)
> + return;
> +
> + if (clock_state == CLOCK_ENABLE) {
> + if (new_state != CLOCK_ENABLE)
> + clk_disable(info->clk);
> + } else {
> + if (new_state == CLOCK_ENABLE)
> + clk_enable(info->clk);
> + }
> +
> + clock_state = new_state;
> +}
^ permalink raw reply
* Re: [PATCH] nand: Fix S3C NAND clock stop
From: Randy Dunlap @ 2011-04-11 2:05 UTC (permalink / raw)
To: Jiri Pinkava
Cc: kgene.kim, linux-kernel, linux-mtd, ben-linux, dwmw2,
linux-arm-kernel
In-Reply-To: <1302485262-8401-1-git-send-email-jiri.pinkava@vscht.cz>
On 4/10/2011 6:27 PM, Jiri Pinkava wrote:
> Current implementation of s3c2410_nand_select_chip call
> clk_disable every time when chip = -1 (de-select). This happend
> multiple times even if chip was already de-selected. This causes
> disabling clock even if they are already disabled and due to
> nature of clock subsytem implementation this causes nand clock
> to be disabled and newer enabled again.
>
> Signed-off-by: Jiri Pinkava<jiri.pinkava@vscht.cz>
> ---
> drivers/mtd/nand/s3c2410.c | 57 +++++++++++++++++++++++++++++++------------
> 1 files changed, 41 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index 33d832d..79e18a3 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
> @@ -159,11 +165,33 @@ static struct s3c2410_platform_nand *to_nand_plat(struct platform_device *dev)
> return dev->dev.platform_data;
> }
>
> -static inline int allow_clk_stop(struct s3c2410_nand_info *info)
> +static inline int allow_clk_suspend(struct s3c2410_nand_info *info)
> {
> return clock_stop;
> }
>
> +/**
> + * s3c2410_nand_clk_set_state - Enable, disable or suspend NAND clock.
> + * @info: The controller instance.
> + * @state: State to which clock should be set.
@new_state:
> + */
> +static void s3c2410_nand_clk_set_state(struct s3c2410_nand_info *info,
> + int new_state)
> +{
> + if (!allow_clk_suspend(info)&& new_state == CLOCK_SUSPEND)
> + return;
> +
> + if (clock_state == CLOCK_ENABLE) {
> + if (new_state != CLOCK_ENABLE)
> + clk_disable(info->clk);
> + } else {
> + if (new_state == CLOCK_ENABLE)
> + clk_enable(info->clk);
> + }
> +
> + clock_state = new_state;
> +}
^ permalink raw reply
* Re: [PATCH] 2.6.38: access permission filesystem 0.24
From: Randy Dunlap @ 2011-04-11 2:03 UTC (permalink / raw)
To: Olaf Dietsche; +Cc: linux-kernel, Rod Cordova
In-Reply-To: <87sjtpai9d.fsf@rat.lan>
On 4/10/2011 2:50 PM, Olaf Dietsche wrote:
> This *untested* patch adds a new permission managing file system.
> Furthermore, it adds two modules, which make use of this file system.
>
> One module allows granting capabilities based on user-/groupid. The
> second module allows to grant access to lower numbered ports based on
> user-/groupid, too.
>
> Changes:
> - updated to 2.6.38
>
> This patch is available at:
> <http://www.olafdietsche.de/linux/accessfs/>
>
> and attached inline below.
>
> Regards, Olaf
>
> Documentation/filesystems/accessfs.txt | 41 +++
> fs/Kconfig | 1 +
> fs/Makefile | 1 +
> fs/accessfs/Kconfig | 63 +++++
> fs/accessfs/Makefile | 11 +
> fs/accessfs/capabilities.c | 108 ++++++++
> fs/accessfs/inode.c | 432 ++++++++++++++++++++++++++++++++
> fs/accessfs/ip.c | 101 ++++++++
> include/linux/accessfs_fs.h | 42 +++
> include/net/sock.h | 43 ++++
> net/Kconfig | 12 +
> net/Makefile | 1 +
> net/hooks.c | 55 ++++
> net/ipv4/af_inet.c | 2 +-
> net/ipv6/af_inet6.c | 2 +-
> 15 files changed, 913 insertions(+), 2 deletions(-)
+config ACCESSFS_USER_PORTS
+ tristate "User permission based IP ports"
+ depends on ACCESS_FS
+ select NET_HOOKS
+ default n
+ help
+ If you say Y here, you will be able to control access to IP ports
+ based on user-/groupid. For this to work, you must say Y
+ to CONFIG_NET_HOOKS.
That last sentence is handled (in theory) by "select NET_HOOKS", right?
But NET_HOOKS depends on INET && EXPERIMENTAL, so this config should not
select NET_HOOKS unless INET && EXPERIMENTAL are enabled also.
^ permalink raw reply
* [PATCH] nand: Fix S3C NAND clock stop
From: Jiri Pinkava @ 2011-04-11 1:27 UTC (permalink / raw)
To: ben-linux
Cc: kgene.kim, dwmw2, linux-arm-kernel, linux-mtd, linux-kernel,
Jiri Pinkava
Current implementation of s3c2410_nand_select_chip call
clk_disable every time when chip = -1 (de-select). This happend
multiple times even if chip was already de-selected. This causes
disabling clock even if they are already disabled and due to
nature of clock subsytem implementation this causes nand clock
to be disabled and newer enabled again.
Signed-off-by: Jiri Pinkava <jiri.pinkava@vscht.cz>
---
drivers/mtd/nand/s3c2410.c | 57 +++++++++++++++++++++++++++++++------------
1 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
index 33d832d..79e18a3 100644
--- a/drivers/mtd/nand/s3c2410.c
+++ b/drivers/mtd/nand/s3c2410.c
@@ -54,8 +54,14 @@ static int hardware_ecc = 1;
static int hardware_ecc = 0;
#endif
+#define CLOCK_DISABLE 0
+#define CLOCK_ENABLE 1
+#define CLOCK_SUSPEND 2
+
+static int clock_state = CLOCK_DISABLE;
+
#ifdef CONFIG_MTD_NAND_S3C2410_CLKSTOP
-static int clock_stop = 1;
+static const int clock_stop = 1;
#else
static const int clock_stop = 0;
#endif
@@ -159,11 +165,33 @@ static struct s3c2410_platform_nand *to_nand_plat(struct platform_device *dev)
return dev->dev.platform_data;
}
-static inline int allow_clk_stop(struct s3c2410_nand_info *info)
+static inline int allow_clk_suspend(struct s3c2410_nand_info *info)
{
return clock_stop;
}
+/**
+ * s3c2410_nand_clk_set_state - Enable, disable or suspend NAND clock.
+ * @info: The controller instance.
+ * @state: State to which clock should be set.
+ */
+static void s3c2410_nand_clk_set_state(struct s3c2410_nand_info *info,
+ int new_state)
+{
+ if (!allow_clk_suspend(info) && new_state == CLOCK_SUSPEND)
+ return;
+
+ if (clock_state == CLOCK_ENABLE) {
+ if (new_state != CLOCK_ENABLE)
+ clk_disable(info->clk);
+ } else {
+ if (new_state == CLOCK_ENABLE)
+ clk_enable(info->clk);
+ }
+
+ clock_state = new_state;
+}
+
/* timing calculations */
#define NS_IN_KHZ 1000000
@@ -333,8 +361,8 @@ static void s3c2410_nand_select_chip(struct mtd_info *mtd, int chip)
nmtd = this->priv;
info = nmtd->info;
- if (chip != -1 && allow_clk_stop(info))
- clk_enable(info->clk);
+ if (chip != -1)
+ s3c2410_nand_clk_set_state(info, CLOCK_ENABLE);
cur = readl(info->sel_reg);
@@ -356,8 +384,8 @@ static void s3c2410_nand_select_chip(struct mtd_info *mtd, int chip)
writel(cur, info->sel_reg);
- if (chip == -1 && allow_clk_stop(info))
- clk_disable(info->clk);
+ if (chip == -1)
+ s3c2410_nand_clk_set_state(info, CLOCK_SUSPEND);
}
/* s3c2410_nand_hwcontrol
@@ -694,8 +722,7 @@ static int s3c24xx_nand_remove(struct platform_device *pdev)
/* free the common resources */
if (info->clk != NULL && !IS_ERR(info->clk)) {
- if (!allow_clk_stop(info))
- clk_disable(info->clk);
+ s3c2410_nand_clk_set_state(info, CLOCK_DISABLE);
clk_put(info->clk);
}
@@ -947,7 +974,7 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
goto exit_error;
}
- clk_enable(info->clk);
+ s3c2410_nand_clk_set_state(info, CLOCK_ENABLE);
/* allocate and map the resource */
@@ -1026,9 +1053,9 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
goto exit_error;
}
- if (allow_clk_stop(info)) {
+ if (allow_clk_suspend(info)) {
dev_info(&pdev->dev, "clock idle support enabled\n");
- clk_disable(info->clk);
+ s3c2410_nand_clk_set_state(info, CLOCK_SUSPEND);
}
pr_debug("initialised ok\n");
@@ -1059,8 +1086,7 @@ static int s3c24xx_nand_suspend(struct platform_device *dev, pm_message_t pm)
writel(info->save_sel | info->sel_bit, info->sel_reg);
- if (!allow_clk_stop(info))
- clk_disable(info->clk);
+ s3c2410_nand_clk_set_state(info, CLOCK_DISABLE);
}
return 0;
@@ -1072,7 +1098,7 @@ static int s3c24xx_nand_resume(struct platform_device *dev)
unsigned long sel;
if (info) {
- clk_enable(info->clk);
+ s3c2410_nand_clk_set_state(info, CLOCK_ENABLE);
s3c2410_nand_inithw(info);
/* Restore the state of the nFCE line. */
@@ -1082,8 +1108,7 @@ static int s3c24xx_nand_resume(struct platform_device *dev)
sel |= info->save_sel & info->sel_bit;
writel(sel, info->sel_reg);
- if (allow_clk_stop(info))
- clk_disable(info->clk);
+ s3c2410_nand_clk_set_state(info, CLOCK_SUSPEND);
}
return 0;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 4/6] ARM: mxc: don't allow to compile together i.MX51 and i.MX53
From: Nicolas Pitre @ 2011-04-11 2:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1302464943-20721-4-git-send-email-u.kleine-koenig@pengutronix.de>
On Sun, 10 Apr 2011, Uwe Kleine-K?nig wrote:
> The two SoCs have different PHYS_OFFSETs so it's not (yet) possible to
> compile a single (working) kernel for these.
Really?
Have a look at CONFIG_ARM_PATCH_PHYS_VIRT. It's in mainline and fully
functional.
Nicolas
^ permalink raw reply
* Re: [PATCH] Add support for SMSC LAN9530, LAN9730 and LAN89530
From: David Miller @ 2011-04-11 1:59 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1302288719-17103-1-git-send-email-steve.glendinning@smsc.com>
From: Steve Glendinning <steve.glendinning@smsc.com>
Date: Fri, 8 Apr 2011 19:51:59 +0100
> This patch adds support for SMSC's LAN9530, LAN9730 and LAN89530 USB
> ethernet controllers to the existing smsc95xx driver by adding
> their new USB VID/PID pairs.
>
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH 1/3] vxge: always enable hardware time stamp
From: David Miller @ 2011-04-11 1:58 UTC (permalink / raw)
To: jdmason; +Cc: netdev
In-Reply-To: <1302297083-22665-1-git-send-email-jdmason@kudzu.us>
From: Jon Mason <jdmason@kudzu.us>
Date: Fri, 8 Apr 2011 16:11:21 -0500
> Hardware time stamp calculation can only be enabled by the privileged
> function. Enable it always by default and simply use the ethtool
> interface to set a flag to indicate whether or not the respective
> function driver should indicate the timestamp along with the received
> packet.
>
> Also, make certain fields in vxge_hw_device_config bit-fields to reduce
> the size of the struct.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Doesn't this have some performance or latency impact?
I think it should be stay off by default, people who want this know
they want it and can turn it on if they want to.
^ permalink raw reply
* Re: [PATCH] x86-64, NUMA: reimplement cpu node map initialization for fake numa
From: KOSAKI Motohiro @ 2011-04-11 1:58 UTC (permalink / raw)
To: Tejun Heo
Cc: kosaki.motohiro, LKML, Yinghai Lu, Brian Gerst, Cyrill Gorcunov,
Shaohui Zheng, David Rientjes, Ingo Molnar, H. Peter Anvin
In-Reply-To: <20110408164337.GC3871@mtj.dyndns.org>
Hi Tejun,
> Hello, KOSAKI.
>
> On Fri, Apr 08, 2011 at 11:56:20PM +0900, KOSAKI Motohiro wrote:
> > This is regression since commit e23bba6044 (x86-64, NUMA: Unify
> > emulated distance mapping). Because It drop fake_physnodes() and
> > then cpu-node mapping was changed.
> >
> > old) all cpus are assinged node 0
> > now) cpus are assigned round robin
> > (the logic is implemented by numa_init_array())
>
> I think it's slightly more complex than that. If apicid -> NUMA node
> mapping exists, the mapping (remapped during emulation) is always
> used. The RR assignment is only used for CPUs which didn't have node
> assigned to it, most likely due to missing processor affinity entry.
Right. But, if my understanding is correct, we don't need worry it.
Because
2.6.38
---------------------------------------------------------
static void __init fake_physnodes(int acpi, int amd, int nr_nodes)
{
int i;
BUG_ON(acpi && amd);
#ifdef CONFIG_ACPI_NUMA
if (acpi) {
acpi_fake_nodes(nodes, nr_nodes);
}
#endif
#ifdef CONFIG_AMD_NUMA
if (amd) {
amd_fake_nodes(nodes, nr_nodes);
}
#endif
if (!acpi && !amd) {
for (i = 0; i < nr_cpu_ids; i++)
numa_set_node(i, 0);
}
}
---------------------------------------------------------
if acpi entry is appeared, acpi variable is 1. then, numa_se_node(i, 0)
aren't called.
my patch
-------------------------------------------------------------
+ /* Setup cpu node map. */
+ for (i = 0; i < nr_cpu_ids; i++) {
+ if (early_cpu_to_node(i) != NUMA_NO_NODE)
+ continue;
+ numa_set_node(i, 0);
+ }
+
-------------------------------------------------------------
If acpi entry is appeared, init_func() of numa_init() have already
changed cpu_to_node[] entry to !NUMA_NO_NODE. Then, this logic behave
no-op.
Then, I didn't describe this case. no change has no matter. :)
> I think, with or without the recent changes, numa_init_array() would
> have assigned RR nodes to those uninitialized CPUs. What changed is
> that the same RR fallback is now used even when emulation is used now.
Right.
So, I _guess_ numa_init_array() was only used very old machine and
they have no multi core in practical world. thus, they didn't hit
this issue.
But, I'm not sure which machine really need (and use) numa_init_array().
then, my patch choose most conservative way. (ie back old logic)
> > Why round robin assignment doesn't work? Because init_numa_sched_groups_power()
> > assume all logical cpus in a same physical cpu are assigned a same node.
> > (Then it only account group_first_cpu()). But the simple round robin broke
> > the assumption. Thus, this patch reimplement cpu node map initialization
> > for fake numa.
>
> Maybe I'm confused but I don't think this is the correct fix. What
> prevents RR assignment triggering the same problem when emulation is
> not used? If we're falling back every uninitialized cpu to node 0
> after emulation, we should be doing that for !emulation path too and I
> don't think that's what we want. It seems like the emulation is just
> triggering an underlying condition simplify because it's ending up
> with different assignment and the same condition might as well trigger
> without emulation. Am I missing something?
No, you are completely correct.
I think this breakage is existing from long past. And I _guess_
no such machine is existing in a real world. If any machine don't
hit the incorrect code, it's no matter even though the logic is buggy.
For 2.6.39 timeframe, we have a few option. I mean I personaly think
we have no option that 2.6.39 will be released that it remain to have
a boot failure bug.
1) revert all of your x86-64/mm chagesets
2) undo only numa_emulation change (my proposal)
3) make a radical improvement now and apply it without linux-next
testing phase.
I dislike 1) and 3) beucase, 1) we know the breakage is where come from.
then we have no reason to revert all. 3) I hate untested patch simply.
A few addional explanation is here: scheduler group for MC is created based
on cpu_llc_shared_mask(). And it was created set_cpu_sibling_map().
Unfortunatelly, it is constructed very later against numa_init_array().
Thus, numa_init_array() changing is no simple work and no low risk work.
In the other word, I didn't talk about which is correct (or proper)
algorithm, I did only talk about logic undo has least regression risk.
So, I still think making new RR numa assignment should be deferred
.40 or .41 and apply my bandaid patch now. However if you have an
alternative fixing patch, I can review and discuss it, of cource.
Thanks.
^ permalink raw reply
* Re: [alsa-devel] Tegra ASoC, multiple boards, platform data, and conditionals in machine driver
From: Mark Brown @ 2011-04-11 1:58 UTC (permalink / raw)
To: Olof Johansson
Cc: Stephen Warren,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
Erik Gilling (konkers-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org),
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org)
In-Reply-To: <BANLkTikQhe1+ufvZWFKU1DT+XCS9=xE0Xw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Apr 10, 2011 at 11:18:17AM -0700, Olof Johansson wrote:
> built. It also makes it harder to maintain a multiplatform kernel if
> configuration data is pulled in at build time instead of runtime (i.e.
> headers vs platform_data or similar).
Note that whatever option is chosen the configuration should be pulled
in at runtime, it's purely a question of where the data table goes - do
you pass the full thing through platform datra or do you just pass the
machine type.
> In other words, I would prefer option (b) above.
Another thing to bear in mind is that it's only feasable to try to
combine the Tegra/WM8903 combinations - trying to combine machine
drivers for multiple unrelated CODECs isn't going to work well.
^ permalink raw reply
* Re: [PATCH] net: bnx2: convert to hw_features
From: David Miller @ 2011-04-11 1:57 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, mchan
In-Reply-To: <20110410144746.AAFBF13A64@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sun, 10 Apr 2011 16:47:46 +0200 (CEST)
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ksz884x: convert to hw_features
From: David Miller @ 2011-04-11 1:56 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, Tristram.Ha
In-Reply-To: <20110410131321.BE47D13909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sun, 10 Apr 2011 15:13:21 +0200 (CEST)
> This also fixes possible race when changing receive checksum state
> and removes IPV6_CSUM_GEN_HACK as it's always set.
>
> BTW, The claim about fake IPV6 checksum looks dubious. If that were true,
> then there's a problem in networking core and should be fixed there and not
> in random drivers.
>
> BTW#2, there's no MAINTAINERS entry for this driver. I assume this driver
> is supported by Micrel?
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: via-velocity: convert to hw_features
From: David Miller @ 2011-04-11 1:56 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, romieu
In-Reply-To: <20110410131321.A6EA9138DD@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sun, 10 Apr 2011 15:13:21 +0200 (CEST)
> Trivial conversion.
>
> This also enables toggling TX VLAN offload and fixes TX checksumming
> race with offload changes.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: stmmac: convert to hw_features
From: David Miller @ 2011-04-11 1:56 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, peppe.cavallaro
In-Reply-To: <20110409124655.A015B13909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sat, 9 Apr 2011 14:46:55 +0200 (CEST)
> This also removes TSO as it's made fully in software --- better to leave this
> to networking core.
>
> If the MAC features can be detected at probe time and not at open, then
> stmmac_fix_features could be simplified by limiting hw_features. That's
> also better for users as they don't see offloads being togglable but
> never turned on.
>
> Redundant fallbacks for TX csum are removed as it's already handled
> by network core.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: 8139cp: convert to hw_features
From: David Miller @ 2011-04-11 1:56 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev
In-Reply-To: <20110409105818.F217813909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sat, 9 Apr 2011 12:58:18 +0200 (CEST)
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: r8169: convert to hw_features
From: David Miller @ 2011-04-11 1:55 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, romieu, dave
In-Reply-To: <20110408163556.D8D1213909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Fri, 8 Apr 2011 18:35:56 +0200 (CEST)
> Simple conversion with a bit of needed cleanup.
>
> This also fixes:
> - confusion around vlan_features in rtl8169_vlan_mode(),
> - problem with broken TSO for too big MTU (the limit is set
> at 0xFFF --- max MSS field value).
>
> SG+IP_CSUM+TSO is left disabled by default, based on suggestion by
> David Dillow.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: benet: convert to hw_features - fixup
From: David Miller @ 2011-04-11 1:55 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, sathya.perla, subbu.seetharaman, ajit.khaparde
In-Reply-To: <20110408123847.76855138DD@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Fri, 8 Apr 2011 14:38:47 +0200 (CEST)
> Fix up after merge with NETIF_F_RXHASH implementation.
>
> This allows to toggle NETIF_F_RXHASH and NETIF_F_HW_VLAN_TX.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Remove invalid offloads
From: David Miller @ 2011-04-11 1:55 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, linuxppc-dev, vbordug
In-Reply-To: <20110408123846.D947E13909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Fri, 8 Apr 2011 14:38:46 +0200 (CEST)
> Remove offload changing ethtool ops which drivers don't really support:
>
> - fs_enet
> - ucc_geth
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Remove invalid offloads
From: David Miller @ 2011-04-11 1:55 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, pantelis.antoniou, vbordug, leoli, linuxppc-dev
In-Reply-To: <20110408123846.D947E13909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Fri, 8 Apr 2011 14:38:46 +0200 (CEST)
> Remove offload changing ethtool ops which drivers don't really support:
>
> - fs_enet
> - ucc_geth
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ 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.