* pull request: wireless-2.6 2010-10-07
From: John W. Linville @ 2010-10-07 18:58 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are a few more more-or-less-one-liner fixes intended for 2.6.36.
The one from Felix fixes a regression introduced in the 2.6.36 cycle.
The one from Johannes fixes a crash reported by Ben Greear (as
documented in the changelog). The one from me reverts and earlier patch
from me that can result in stuff in dmesg from not calling
netif_receive_skb in the proper context.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit fb3dbece264a50ab4373f3af0bbbd9175d3ad4d7:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6 (2010-10-07 00:59:39 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Felix Fietkau (1):
ath9k_hw: fix regression in ANI listen time calculation
Johannes Berg (1):
mac80211: delete AddBA response timer
John W. Linville (1):
Revert "mac80211: use netif_receive_skb in ieee80211_tx_status callpath"
drivers/net/wireless/ath/ath9k/ani.c | 2 +-
net/mac80211/agg-tx.c | 2 ++
net/mac80211/status.c | 4 ++--
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ani.c b/drivers/net/wireless/ath/ath9k/ani.c
index cc648b6..a3d95cc 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -543,7 +543,7 @@ static u8 ath9k_hw_chan_2_clockrate_mhz(struct ath_hw *ah)
if (conf_is_ht40(conf))
return clockrate * 2;
- return clockrate * 2;
+ return clockrate;
}
static int32_t ath9k_hw_ani_get_listen_time(struct ath_hw *ah)
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index c893f23..8f23401 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -175,6 +175,8 @@ int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
set_bit(HT_AGG_STATE_STOPPING, &tid_tx->state);
+ del_timer_sync(&tid_tx->addba_resp_timer);
+
/*
* After this packets are no longer handed right through
* to the driver but are put onto tid_tx->pending instead,
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 10caec5..34da679 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -377,7 +377,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_receive_skb(skb2);
+ netif_rx(skb2);
}
}
@@ -386,7 +386,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
}
if (prev_dev) {
skb->dev = prev_dev;
- netif_receive_skb(skb);
+ netif_rx(skb);
skb = NULL;
}
rcu_read_unlock();
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* [PATCH] OLPC: Add XO-1 poweroff support
From: Daniel Drake @ 2010-10-07 18:59 UTC (permalink / raw)
To: tglx, mingo, hpa, x86; +Cc: dilinger, linux-kernel
Add a pm_power_off handler for the OLPC XO-1 laptop.
Signed-off-by: Daniel Drake <dsd@laptop.org>
---
arch/x86/Kconfig | 6 ++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/olpc-xo1.c | 112 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/kernel/olpc-xo1.c
The new olpc-xo1.c file will also be used for further functionality
(suspend/resume, lid switch device, etc); patches to be submitted shortly
after the review/merge of this one.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cea0cd9..19e6439 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2065,6 +2065,12 @@ config OLPC
Add support for detecting the unique features of the OLPC
XO hardware.
+config OLPC_XO1
+ bool "OLPC XO-1 support"
+ depends on OLPC
+ ---help---
+ Add support for non-essential features of the OLPC XO-1 laptop.
+
config OLPC_OPENFIRMWARE
bool "Support for OLPC's Open Firmware"
depends on !X86_64 && !X86_PAE
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index fedf32a..247588f 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_SCx200) += scx200.o
scx200-y += scx200_32.o
obj-$(CONFIG_OLPC) += olpc.o
+obj-$(CONFIG_OLPC_XO1) += olpc-xo1.o
obj-$(CONFIG_OLPC_OPENFIRMWARE) += olpc_ofw.o
obj-$(CONFIG_X86_MRST) += mrst.o
diff --git a/arch/x86/kernel/olpc-xo1.c b/arch/x86/kernel/olpc-xo1.c
new file mode 100644
index 0000000..ee840de
--- /dev/null
+++ b/arch/x86/kernel/olpc-xo1.c
@@ -0,0 +1,112 @@
+/*
+ * Support for features of the OLPC XO-1 laptop
+ *
+ * Copyright (C) 2010 One Laptop per Child
+ * Copyright (C) 2006 Red Hat, Inc.
+ * Copyright (C) 2006 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+#include <linux/pm.h>
+
+#include <asm/io.h>
+#include <asm/olpc.h>
+
+#define DRV_NAME "olpc-xo1"
+
+#define PMS_BAR 4
+#define ACPI_BAR 5
+
+/* PMC registers (PMS block) */
+#define PM_SCLK 0x10
+#define PM_IN_SLPCTL 0x20
+#define PM_WKXD 0x34
+#define PM_WKD 0x30
+#define PM_SSC 0x54
+
+/* PM registers (ACPI block) */
+#define PM1_CNT 0x08
+#define PM_GPE0_STS 0x18
+
+static unsigned long acpi_base;
+static unsigned long pms_base;
+
+static void xo1_power_off(void)
+{
+ printk(KERN_INFO "OLPC XO-1 power off sequence...\n");
+
+ /* Enable all of these controls with 0 delay */
+ outl(0x40000000, pms_base + PM_SCLK);
+ outl(0x40000000, pms_base + PM_IN_SLPCTL);
+ outl(0x40000000, pms_base + PM_WKXD);
+ outl(0x40000000, pms_base + PM_WKD);
+
+ /* Clear status bits (possibly unnecessary) */
+ outl(0x0002ffff, pms_base + PM_SSC);
+ outl(0xffffffff, acpi_base + PM_GPE0_STS);
+
+ /* Write SLP_EN bit to start the machinery */
+ outl(0x00002000, acpi_base + PM1_CNT);
+}
+
+/* Read the base addresses from the PCI BAR info */
+static int __init setup_bases(struct pci_dev *pdev)
+{
+ int r;
+
+ r = pci_enable_device_io(pdev);
+ if (r) {
+ dev_err(&pdev->dev, "can't enable device IO\n");
+ return r;
+ }
+
+ r = pci_request_region(pdev, ACPI_BAR, DRV_NAME);
+ if (r) {
+ dev_err(&pdev->dev, "can't alloc PCI BAR #%d\n", ACPI_BAR);
+ return r;
+ }
+
+ r = pci_request_region(pdev, PMS_BAR, DRV_NAME);
+ if (r) {
+ dev_err(&pdev->dev, "can't alloc PCI BAR #%d\n", PMS_BAR);
+ pci_release_region(pdev, ACPI_BAR);
+ return r;
+ }
+
+ acpi_base = pci_resource_start(pdev, ACPI_BAR);
+ pms_base = pci_resource_start(pdev, PMS_BAR);
+
+ return 0;
+}
+
+static int __init olpc_xo1_init(void)
+{
+ struct pci_dev *pdev;
+ int r;
+
+ if (olpc_board_at_least(olpc_board_pre(0xd0))) /* XO-1 only */
+ return 0;
+
+ pdev = pci_get_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA,
+ NULL);
+ if (!pdev)
+ return -ENODEV;
+
+ r = setup_bases(pdev);
+ if (r)
+ return r;
+
+ pm_power_off = xo1_power_off;
+
+ printk(KERN_INFO "OLPC XO-1 support registered\n");
+ return 0;
+}
+device_initcall(olpc_xo1_init);
+
--
1.7.2.3
^ permalink raw reply related
* [PATCH] Documentation: update-index: -z applies also to --index-info
From: Bert Wesarg @ 2010-10-07 18:59 UTC (permalink / raw)
To: Štěpán Němec; +Cc: Junio C Hamano, git, Bert Wesarg
In-Reply-To: <AANLkTimsJ+uG7KhiBMii8szFYmbXo5OjAkYgs99_Hjzr@mail.gmail.com>
Also mention, that --stdin and --index-info needs to be the last
option supplied and indicate this in the usage string.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
Documentation/git-update-index.txt | 13 +++++++------
builtin/update-index.c | 2 +-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 74d1d49..022c0fc 100644 Documentation/git-update-index.txt
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -18,10 +18,10 @@ SYNOPSIS
[--skip-worktree | --no-skip-worktree]
[--ignore-submodules]
[--really-refresh] [--unresolve] [--again | -g]
- [--info-only] [--index-info]
- [-z] [--stdin]
+ [--info-only]
[--verbose]
- [--] [<file>]*
+ [[-z] --stdin | --index-info]
+ [--] [<file>]
DESCRIPTION
-----------
@@ -72,7 +72,7 @@ OPTIONS
Directly insert the specified info into the index.
--index-info::
- Read index information from stdin.
+ Read index information from stdin. (Must be the last option.)
--chmod=(+|-)x::
Set the execute permissions on the updated files.
@@ -139,13 +139,14 @@ you will need to handle the situation manually.
Instead of taking list of paths from the command line,
read list of paths from the standard input. Paths are
separated by LF (i.e. one path per line) by default.
+ (Must be the last option.)
--verbose::
Report what is being added and removed from index.
-z::
- Only meaningful with `--stdin`; paths are separated with
- NUL character instead of LF.
+ Only meaningful with `--stdin` or `--index-info`; paths are
+ separated with NUL character instead of LF.
\--::
Do not interpret any more arguments as options.
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 3ab214d..2c1a81e 100644 builtin/update-index.c
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -398,7 +398,7 @@ static void read_index_info(int line_termination)
}
static const char update_index_usage[] =
-"git update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--really-refresh] [--cacheinfo] [--chmod=(+|-)x] [--assume-unchanged] [--skip-worktree|--no-skip-worktree] [--info-only] [--force-remove] [--stdin] [--index-info] [--unresolve] [--again | -g] [--ignore-missing] [-z] [--verbose] [--] <file>...";
+"git update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--really-refresh] [--cacheinfo] [--chmod=(+|-)x] [--assume-unchanged] [--skip-worktree|--no-skip-worktree] [--info-only] [--force-remove] [--unresolve] [--again | -g] [--ignore-missing] [--verbose] [[-z] --stdin | --index-info] [--] <file>...";
static unsigned char head_sha1[20];
static unsigned char merge_head_sha1[20];
--
1.7.1.1067.g5aeb7
^ permalink raw reply related
* Re: [PATCHv5] ARM: imx: Add iram allocator functions
From: Uwe Kleine-König @ 2010-10-07 18:59 UTC (permalink / raw)
To: Dinh.Nguyen
Cc: linux-kernel, linux-arm-kernel, linux, s.hauer,
valentin.longchamp, daniel, grant.likely, bryan.wu, amit.kucheria,
xiao-lizhang
In-Reply-To: <1286467250-22644-1-git-send-email-Dinh.Nguyen@freescale.com>
Hello,
On Thu, Oct 07, 2010 at 11:00:50AM -0500, Dinh.Nguyen@freescale.com wrote:
> From: Dinh Nguyen <Dinh.Nguyen@freescale.com>
>
> Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR.
> The allocation size is 4KB multiples to guarantee alignment. The
> idea for these functions is for i.MX platforms to use them
> to dynamically allocate IRAM usage.
>
> Applies on 2.6.36-rc7
>
> Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com>
> Reviewed-by: Amit Kucheria <amit.kucheria@canonical.com>
> ---
> arch/arm/plat-mxc/Kconfig | 4 ++
> arch/arm/plat-mxc/Makefile | 1 +
> arch/arm/plat-mxc/include/mach/iram.h | 41 ++++++++++++++++++
> arch/arm/plat-mxc/iram_alloc.c | 74 +++++++++++++++++++++++++++++++++
> 4 files changed, 120 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/plat-mxc/include/mach/iram.h
> create mode 100644 arch/arm/plat-mxc/iram_alloc.c
>
> diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
> index 6785db4..0e99bb4 100644
> --- a/arch/arm/plat-mxc/Kconfig
> +++ b/arch/arm/plat-mxc/Kconfig
> @@ -110,4 +110,8 @@ config ARCH_MXC_AUDMUX_V1
> config ARCH_MXC_AUDMUX_V2
> bool
>
> +config IRAM_ALLOC
> + bool
> + select GENERIC_ALLOCATOR
> +
> endif
> diff --git a/arch/arm/plat-mxc/Makefile b/arch/arm/plat-mxc/Makefile
> index 78d405e..1ddfb13 100644
> --- a/arch/arm/plat-mxc/Makefile
> +++ b/arch/arm/plat-mxc/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_MXC_TZIC) += tzic.o
>
> obj-$(CONFIG_IMX_HAVE_IOMUX_V1) += iomux-v1.o
> obj-$(CONFIG_ARCH_MXC_IOMUX_V3) += iomux-v3.o
> +obj-$(CONFIG_IRAM_ALLOC) += iram_alloc.o
> obj-$(CONFIG_MXC_PWM) += pwm.o
> obj-$(CONFIG_USB_EHCI_MXC) += ehci.o
> obj-$(CONFIG_MXC_ULPI) += ulpi.o
> diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
> new file mode 100644
> index 0000000..f7edd45
> --- /dev/null
> +++ b/arch/arm/plat-mxc/include/mach/iram.h
> @@ -0,0 +1,41 @@
> +/*
> + * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301, USA.
> + */
> +#include <linux/errno.h>
> +
> +#ifdef CONFIG_IRAM_ALLOC
> +
> +int __init iram_init(unsigned long base, unsigned long size);
> +void *iram_alloc(unsigned int size, unsigned long *dma_addr);
here an __iomem is missing
> +void iram_free(unsigned long dma_addr, unsigned int size);
> +
> +#else
> +
> +static inline int __init iram_init(unsigned long base, unsigned long size)
> +{
> + return -ENOMEM;
> +}
> +
> +static inline void *iram_alloc(unsigned int size, unsigned long *dma_addr)
> +{
> + return NULL;
> +}
> +
> +static inline void iram_free(unsigned long base, unsigned long size) {}
> +
> +#endif
> diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
> new file mode 100644
> index 0000000..8f75a32
> --- /dev/null
> +++ b/arch/arm/plat-mxc/iram_alloc.c
> @@ -0,0 +1,74 @@
> +/*
> + * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301, USA.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/spinlock.h>
> +#include <linux/genalloc.h>
> +#include <mach/iram.h>
> +
> +static unsigned long iram_phys_base;
> +static void __iomem *iram_virt_base;
> +static struct gen_pool *iram_pool;
> +
> +static inline void __iomem *iram_phys_to_virt(unsigned long p)
> +{
> + p = iram_virt_base + (p - iram_phys_base);
> + return p;
if you combine the above two lines to
return iram_virt_base + (p - iram_phys_base);
you make sparse happy. Currently it wails:
arch/arm/plat-mxc/iram_alloc.c: In function 'iram_phys_to_virt':
arch/arm/plat-mxc/iram_alloc.c:33: warning: assignment makes integer from pointer without a cast
arch/arm/plat-mxc/iram_alloc.c:34: warning: return makes pointer from integer without a cast
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCHv5] ARM: imx: Add iram allocator functions
From: Uwe Kleine-König @ 2010-10-07 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286467250-22644-1-git-send-email-Dinh.Nguyen@freescale.com>
Hello,
On Thu, Oct 07, 2010 at 11:00:50AM -0500, Dinh.Nguyen at freescale.com wrote:
> From: Dinh Nguyen <Dinh.Nguyen@freescale.com>
>
> Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR.
> The allocation size is 4KB multiples to guarantee alignment. The
> idea for these functions is for i.MX platforms to use them
> to dynamically allocate IRAM usage.
>
> Applies on 2.6.36-rc7
>
> Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com>
> Reviewed-by: Amit Kucheria <amit.kucheria@canonical.com>
> ---
> arch/arm/plat-mxc/Kconfig | 4 ++
> arch/arm/plat-mxc/Makefile | 1 +
> arch/arm/plat-mxc/include/mach/iram.h | 41 ++++++++++++++++++
> arch/arm/plat-mxc/iram_alloc.c | 74 +++++++++++++++++++++++++++++++++
> 4 files changed, 120 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/plat-mxc/include/mach/iram.h
> create mode 100644 arch/arm/plat-mxc/iram_alloc.c
>
> diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
> index 6785db4..0e99bb4 100644
> --- a/arch/arm/plat-mxc/Kconfig
> +++ b/arch/arm/plat-mxc/Kconfig
> @@ -110,4 +110,8 @@ config ARCH_MXC_AUDMUX_V1
> config ARCH_MXC_AUDMUX_V2
> bool
>
> +config IRAM_ALLOC
> + bool
> + select GENERIC_ALLOCATOR
> +
> endif
> diff --git a/arch/arm/plat-mxc/Makefile b/arch/arm/plat-mxc/Makefile
> index 78d405e..1ddfb13 100644
> --- a/arch/arm/plat-mxc/Makefile
> +++ b/arch/arm/plat-mxc/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_MXC_TZIC) += tzic.o
>
> obj-$(CONFIG_IMX_HAVE_IOMUX_V1) += iomux-v1.o
> obj-$(CONFIG_ARCH_MXC_IOMUX_V3) += iomux-v3.o
> +obj-$(CONFIG_IRAM_ALLOC) += iram_alloc.o
> obj-$(CONFIG_MXC_PWM) += pwm.o
> obj-$(CONFIG_USB_EHCI_MXC) += ehci.o
> obj-$(CONFIG_MXC_ULPI) += ulpi.o
> diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
> new file mode 100644
> index 0000000..f7edd45
> --- /dev/null
> +++ b/arch/arm/plat-mxc/include/mach/iram.h
> @@ -0,0 +1,41 @@
> +/*
> + * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301, USA.
> + */
> +#include <linux/errno.h>
> +
> +#ifdef CONFIG_IRAM_ALLOC
> +
> +int __init iram_init(unsigned long base, unsigned long size);
> +void *iram_alloc(unsigned int size, unsigned long *dma_addr);
here an __iomem is missing
> +void iram_free(unsigned long dma_addr, unsigned int size);
> +
> +#else
> +
> +static inline int __init iram_init(unsigned long base, unsigned long size)
> +{
> + return -ENOMEM;
> +}
> +
> +static inline void *iram_alloc(unsigned int size, unsigned long *dma_addr)
> +{
> + return NULL;
> +}
> +
> +static inline void iram_free(unsigned long base, unsigned long size) {}
> +
> +#endif
> diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
> new file mode 100644
> index 0000000..8f75a32
> --- /dev/null
> +++ b/arch/arm/plat-mxc/iram_alloc.c
> @@ -0,0 +1,74 @@
> +/*
> + * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301, USA.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/spinlock.h>
> +#include <linux/genalloc.h>
> +#include <mach/iram.h>
> +
> +static unsigned long iram_phys_base;
> +static void __iomem *iram_virt_base;
> +static struct gen_pool *iram_pool;
> +
> +static inline void __iomem *iram_phys_to_virt(unsigned long p)
> +{
> + p = iram_virt_base + (p - iram_phys_base);
> + return p;
if you combine the above two lines to
return iram_virt_base + (p - iram_phys_base);
you make sparse happy. Currently it wails:
arch/arm/plat-mxc/iram_alloc.c: In function 'iram_phys_to_virt':
arch/arm/plat-mxc/iram_alloc.c:33: warning: assignment makes integer from pointer without a cast
arch/arm/plat-mxc/iram_alloc.c:34: warning: return makes pointer from integer without a cast
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: updating the source tree
From: Grzesiek Sójka @ 2010-10-07 18:58 UTC (permalink / raw)
To: Pekka Paalanen; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20101007215505.5dc21006-cxYvVS3buNOdIgDiPM52R8c4bpwCjbIv@public.gmane.org>
On 10/07/10 20:55, Pekka Paalanen wrote:
> On Thu, 07 Oct 2010 20:07:37 +0200
> Grzesiek Sójka<pld-t9zbU3WrWHI@public.gmane.org> wrote:
>
>> On 10/07/10 19:51, Pekka Paalanen wrote:
>>> On Thu, 07 Oct 2010 19:34:35 +0200
>>> Grzesiek Sójka<pld-t9zbU3WrWHI@public.gmane.org> wrote:
>>>
>>>> I downloaded the nouveau/linux-2.6 using the following:
>>>> git clone --depth 1
>>>> git://anongit.freedesktop.org/nouveau/linux-2.6 Is there an
>
> If you really did that
> and then went into linux-2.6/ dir and said:
I did it in the directory _containing_ the linux-2.6 dir. So probably my
mistake. I already downloaded the fresh version of the linux-2.6. I try
to follow your advice next time.
Cheers.
^ permalink raw reply
* Re: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write
From: Russell King - ARM Linux @ 2010-10-07 18:56 UTC (permalink / raw)
To: Menon, Nishanth
Cc: G, Manjunath Kondaiah, linux-omap@vger.kernel.org,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F74831E@dlee02.ent.ti.com>
On Thu, Oct 07, 2010 at 07:17:08AM -0500, Menon, Nishanth wrote:
>
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah
> > Sent: Tuesday, September 21, 2010 5:01 AM
> > To: linux-omap@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org; linux-mtd@lists.infradead.org
> > Subject: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw
> > read/write
> >
> > Following sparse warnings exists due to use of writel/w and readl/w
> > functions.
> >
> > This patch fixes the sparse warnings by converting readl/w functions usage
> > into
> > __raw_readl/__raw_readw functions.
>
> Apologies on bringing up an old topic here -> Is'nt it better to fix
> readl/w or writel/w than replacing it with __raw_readl/w etc?
No. If you're getting sparse warnings its because _you_ are using
readl/writel wrongly.
They take a void __iomem pointer, not a u32, unsigned long, int, or
even a void pointer.
^ permalink raw reply
* Re: bitbake COMPATIBLE_MACHINE stack backtrace
From: Chris Larson @ 2010-10-07 18:55 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <AANLkTimeMWsTvhkZjP+qjVJW7ynM69XcF_0WbS2VdenR@mail.gmail.com>
On Thu, Oct 7, 2010 at 11:36 AM, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:
> Hi,
>
> If I run bitbake (git head of about a week ago) with a recipe that has
> COMPATIBLE_MACHINE set and that is not for my machine, I get a bitbake
> tracedump;
>
Looking into it, thanks for the details.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write
From: Russell King - ARM Linux @ 2010-10-07 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F74831E@dlee02.ent.ti.com>
On Thu, Oct 07, 2010 at 07:17:08AM -0500, Menon, Nishanth wrote:
>
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> > owner at vger.kernel.org] On Behalf Of G, Manjunath Kondaiah
> > Sent: Tuesday, September 21, 2010 5:01 AM
> > To: linux-omap at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org; linux-mtd at lists.infradead.org
> > Subject: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw
> > read/write
> >
> > Following sparse warnings exists due to use of writel/w and readl/w
> > functions.
> >
> > This patch fixes the sparse warnings by converting readl/w functions usage
> > into
> > __raw_readl/__raw_readw functions.
>
> Apologies on bringing up an old topic here -> Is'nt it better to fix
> readl/w or writel/w than replacing it with __raw_readl/w etc?
No. If you're getting sparse warnings its because _you_ are using
readl/writel wrongly.
They take a void __iomem pointer, not a u32, unsigned long, int, or
even a void pointer.
^ permalink raw reply
* Re: [Xenomai-core] Overcoming the "foreign" stack
From: Jan Kiszka @ 2010-10-07 18:56 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai core
In-Reply-To: <4CAE0D90.1070208@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]
Am 07.10.2010 20:12, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>>> I'm on a wait and see stance about generalizing the use of the ftrace
>>> framework for our needs; like Gilles saw with ARM, I must admit that I
>>> did notice a massive overhead on low-end ppc as well when we moved the
>>> pipeline tracer over it. I'm aware of the mcount optimizations that
>>> should be there when cycles really matter, and that ftrace does branch
>>> directly to the trace function when only a single one exists, but this
>>> may not be easy to keep after the generalization has taken place.
>>> Anyway, I'll wait for more data to make my opinion.
>>
>> As I said, ftrace is more the a simple mcount-tracer. And it's standard,
>> distros start to enable it in their production kernels these days
>> (except for the function tracer).
>>
>> If the overhead of the ftrace's mcount is too high on low-end platforms
>> (I personally haven't tried it there yet), it would probably be a good
>> idea to develop some optimizations or allow some variant that does not
>> suffer that much - but upstream then.
>
> I can talk about ARM on that subject: the "fix" is to use dynamic ftrace
> (I did not get it working, so I am not sure it still has not one too
> many indirection layers, but it looks like it does not). But the patches
> to get dynamic ftrace working on ARM, though known since march, have not
> been merged yet, so will not be here in the upcoming 2.6.36. I suspect
> other architectures such as blackfin also lag behind x86. So, in the
> mean-time, if we want to get the I-pipe tracer working with a reasonable
> overhead, we have to make our own version, and from that perspective,
> the version where mcount calls directly the ipipe tracer, is much
> simpler than importing the whole dynamic ftrace stuff. So, I vote for
> keeping some #ifdefs or Kconfig stuff in the ipipe tracer code to be
> able to use a standalone tracer, as it will also simplify getting it to
> work with architectures which lag even more behind x86 than ARM or
> Blackfin. Say for instance, microblaze, nios, or sparc.
>
No question, even if we already had an ipipe tracer replacement for
ftrace, the existing generic bits would not be removed as long as we
have users or there are unacceptable limitations.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* HDA, Conexant CX20585: low volume of sound
From: Andrushka @ 2010-10-07 18:55 UTC (permalink / raw)
To: alsa-devel
Hello.
I have thinkpad x201i.
Hardware and software info located at:
http://www.alsa-project.org/db/?f=fe6a745fc2fa12cd082914aac2a9d810e978cb55
In mixer Master & PCM is set to 100%.
But sound volume in internal laptops speakers and headphones too low
:( In win7 sound volume much higher.
Please help.
^ permalink raw reply
* Re: updating the source tree
From: Pekka Paalanen @ 2010-10-07 18:55 UTC (permalink / raw)
To: Grzesiek Sójka; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <4CAE0C69.3040405-t9zbU3WrWHI@public.gmane.org>
On Thu, 07 Oct 2010 20:07:37 +0200
Grzesiek Sójka <pld-t9zbU3WrWHI@public.gmane.org> wrote:
> On 10/07/10 19:51, Pekka Paalanen wrote:
> > On Thu, 07 Oct 2010 19:34:35 +0200
> > Grzesiek Sójka<pld-t9zbU3WrWHI@public.gmane.org> wrote:
> >
> >> I downloaded the nouveau/linux-2.6 using the following:
> >> git clone --depth 1
> >> git://anongit.freedesktop.org/nouveau/linux-2.6 Is there an
If you really did that
and then went into linux-2.6/ dir and said:
> # git remote update
> fatal: Not a git repository (or any parent up to mount
> parent /home) Stopping at filesystem boundary
> (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
I don't understand. Somehow you have deleted the .git/ directory
from that checkout. Or you have GIT_DIR environment variable set.
> This probably means that to be able to update I need to download
> the nouveau/linux-2.6 using the
>
> git remote add nouveau
> git://anongit.freedesktop.org/nouveau/linux-2.6 git checkout -b
> nouveau-master nouveau/master
That works only if you already have a git repo. The previous error
says you don't have. Furthermore, the exact commands you quoted
do not actually download anything. You still need 'git remote update'
before checkout to download.
> instead of
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
This will clone Linus' git repo, after which you would use the
'git remote add' incatation to add nouveau repo.
--
Pekka Paalanen
http://www.iki.fi/pq/
^ permalink raw reply
* Re: [tip:core/memblock] x86, memblock: Fix crashkernel allocation
From: H. Peter Anvin @ 2010-10-07 18:54 UTC (permalink / raw)
To: Vivek Goyal
Cc: caiqian@redhat.com, linux-tip-commits@vger.kernel.org,
Kexec Mailing List, linux-kernel@vger.kernel.org,
mingo@redhat.com, tglx@linutronix.de, yinghai@kernel.org
In-Reply-To: <20101007181804.GE23308@redhat.com>
On 10/07/2010 11:18 AM, Vivek Goyal wrote:
>
> Ok, I was browsing through kexec-tools, x86 bzImage code and trying to
> refresh my memory what segments were being loaded and what were memory
> address concerns.
>
> - relocatable bzImage (max addr 0x37ffffff, 896MB).
> Though I don't know/understand where that 896MB come from.
>
> - initrd (max addr 0x37ffffff, 896MB)
> Don't know why 896MB as upper limit
896 MB is presumably the (default!!) LOWMEM limit on 32 bits. This is
actually wrong if vmalloc= is also specified on command line, though, or
with nonstandard compile-time options.
> - Purgatory (max addr 2G)
>
> - A segment to keep elf headers (no limit)
> These are accessed when second kernel as fully booted so can be
> addressed in higher addresses.
>
> - A backup segment to copy first 640K of memory (not aware of any limit)
> - Setup/parameter segment (no limit)
> - We don't really execute anything here and just access it for
> command line.
Probably has a 4 GB limit, since I believe it only has a 32-bit pointer.
> So atleast for bzImage it looks that if we specify crashkernel=128M<896M, it
> will work.
>
> So I am fine with above additional syntax for crashkernel=. May be we shall
> have to the deprecate the crashkernel=X<@0 syntax.
>
> CCing kexec list, in case others have any comments.
It would be easy enough to either deprecate or make it an alias for
crashkernel=...<896M, which is basically what Yinghai's patch does.
-hpa
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [tip:core/memblock] x86, memblock: Fix crashkernel allocation
From: H. Peter Anvin @ 2010-10-07 18:54 UTC (permalink / raw)
To: Vivek Goyal
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org,
yinghai@kernel.org, caiqian@redhat.com, tglx@linutronix.de,
linux-tip-commits@vger.kernel.org, Kexec Mailing List
In-Reply-To: <20101007181804.GE23308@redhat.com>
On 10/07/2010 11:18 AM, Vivek Goyal wrote:
>
> Ok, I was browsing through kexec-tools, x86 bzImage code and trying to
> refresh my memory what segments were being loaded and what were memory
> address concerns.
>
> - relocatable bzImage (max addr 0x37ffffff, 896MB).
> Though I don't know/understand where that 896MB come from.
>
> - initrd (max addr 0x37ffffff, 896MB)
> Don't know why 896MB as upper limit
896 MB is presumably the (default!!) LOWMEM limit on 32 bits. This is
actually wrong if vmalloc= is also specified on command line, though, or
with nonstandard compile-time options.
> - Purgatory (max addr 2G)
>
> - A segment to keep elf headers (no limit)
> These are accessed when second kernel as fully booted so can be
> addressed in higher addresses.
>
> - A backup segment to copy first 640K of memory (not aware of any limit)
> - Setup/parameter segment (no limit)
> - We don't really execute anything here and just access it for
> command line.
Probably has a 4 GB limit, since I believe it only has a 32-bit pointer.
> So atleast for bzImage it looks that if we specify crashkernel=128M<896M, it
> will work.
>
> So I am fine with above additional syntax for crashkernel=. May be we shall
> have to the deprecate the crashkernel=X<@0 syntax.
>
> CCing kexec list, in case others have any comments.
It would be easy enough to either deprecate or make it an alias for
crashkernel=...<896M, which is basically what Yinghai's patch does.
-hpa
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH 04/11] lsi53c895a: avoid a write only variable
From: Blue Swirl @ 2010-10-07 18:53 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Paolo Bonzini, qemu-devel
In-Reply-To: <m37hhuqrzy.fsf@blackfin.pond.sub.org>
On Thu, Oct 7, 2010 at 9:20 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
>> On 10/06/2010 11:32 PM, Blue Swirl wrote:
>>> Compiling with GCC 4.6.0 20100925 produced a warning:
>>> /src/qemu/hw/lsi53c895a.c: In function 'lsi_do_msgout':
>>> /src/qemu/hw/lsi53c895a.c:848:9: error: variable 'len' set but not
>>> used [-Werror=unused-but-set-variable]
>>>
>>> Fix by making the variable declaration and its uses also conditional
>>> to debug definition.
>>
>> NACK, this uglifies the code and loses track of _what_ is that msgbyte
>> we're reading.
That information could be saved by adding a comment, I used that
approach for vmstate.c.
>
> Seconded.
>
> If the warning bothers you, maybe "(void)len" can silence it in a less
> unsightly manner.
I'll use that approach next.
^ permalink raw reply
* [ath9k-devel] locating the rcstat file
From: BC @ 2010-10-07 18:53 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <AANLkTinkLKgQsbq=Oqez72qFZoE1Q5Yy6sb2VxyF5iXv@mail.gmail.com>
>very Sorry for the late reply , have you seen whether
>CONFIG_ATH9K_DEBUGFS=y is enable in config.mk of compat wireless
>shafi
Thank you so much for the reply Shafi. That worked for me. I'd like to suggest to whomever maintains the site http://wireless.kernel.org/en/users/Drivers/ath9k/debug
to add those instructions on how debug by changing parameters in the config.mk file. While searching the web I have read that several wireless researchers cannot figure out how to enable debugging in ath9k and view the /sys/kernel/debug/ath9k/phy0 files.
Thanks again for the response, it's greatly appreciated!!!
Brandon M. Combs
Brmcombs at iusb.edu
mypage.iusb.edu/~brmcombs
(574)202-0972
-----Original Message-----
From: Mohammed Shafi <shafi.ath9k@gmail.com>
To: BC <combsiu@aol.com>
Sent: Thu, Oct 7, 2010 4:04 am
Subject: Re: [ath9k-devel] locating the rcstat file
very Sorry for the late reply , have you seen whether
CONFIG_ATH9K_DEBUGFS=y is enable in config.mk of compat wireless
shafi
On Fri, Sep 3, 2010 at 2:37 AM, BC <combsiu@aol.com> wrote:
Iv been looking into using the rcstat file but I cannot seem to locate it in the system for some reason:
Rcstat file is used to know at what MCS rate that the ATH9k received the frames and you can find more details like PER (Packet error ratio), success and retries info. http://wireless.kernel.org/en/users/Drivers/ath9k/debug
It is supposed to be located here: /sys/kernel/debug/ath9k/phy0/rcstat
After issuing the command: 'mount -t debugfs debugfs /sys/kernel/debug/' but it does not work for me. My system does not have /sys/kernel/debug/ath9k only /sys/kernel/debug with no ath9k but, I am positive that I am using the ath9k driver? Thank you for any responses?
uname -a:
linux 2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20101007/7d9de4e0/attachment.htm
^ permalink raw reply
* [U-Boot] packed attribute problem
From: Scott Wood @ 2010-10-07 18:52 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101007175701.1C4B31539A0@gemini.denx.de>
On Thu, 7 Oct 2010 19:57:01 +0200
Wolfgang Denk <wd@denx.de> wrote:
> Dear Scott Wood,
>
> In message <20101007114634.70e0f197@udp111988uds.am.freescale.net> you wrote:
> >
> > I think this gets down to how such pointers are generated -- if you
> > stick with well-defined C, the compiler/ABI should be able to avoid
> > generating an unaligned pointer.
>
> It is a pretty common method to use a pointer to some struct (for
> example, some form of PDU) and make it point to some I/O buffer.
Yes, but at that point we are not talking about well-defined C, but
rather implementation-specific behavior. There's nothing wrong with
it, but the C standard is no longer authoritative on what happens in
such cases.
> Depending on I/O subsystem, pre-pended protocol headerss and such the
> resulting pointer may or may not be aligned. This is something that
> the compiler has zero influence on. [Yes, of course the application
> could always copy the data to a properly aligned memory region. But I
> bet you would quickly complain about the poor throughput if the
> network stack on your systems were implemented that way.]
Yes. And there would also be performance complaints if each of those
accesses were to trap and be emulated (even ignoring weird stuff like
old ARM). Thus it's nice to have some sort of pointer or data type
annotation to tell the compiler to be careful.
> > when unaligned, e.g. old ARM chips that do weird rotaty things rather
> > than trap when you do an unaligned access.
>
> I think it was acceptable for such systems to enforce the compiler (by
> setting special compiler switches) to implement such extra access modes.
> But doing it by default and unconditionally for all systems of that
> architecture seems broken to me. It's unfair collective punishment.
Yes, it ought to be configurable -- but this is only happening when
you use __attribute__((packed)) without explicit alignment, right?
BTW, I see GCC splitting accesses to bitfields in a packed
struct into bytes on powerpc, even with -mno-strict-align.
-Scott
^ permalink raw reply
* Re: [PATCH] Documentation: update-index: -z applies also to --index-info
From: Bert Wesarg @ 2010-10-07 18:52 UTC (permalink / raw)
To: Štěpán Němec; +Cc: Junio C Hamano, git
In-Reply-To: <87wrptua21.fsf@gmail.com>
On Thu, Oct 7, 2010 at 20:33, Štěpán Němec <stepnem@gmail.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> Also mention, that --stdin and --index-info needs to be the last
>> option supplied and indicate this in the usage string.
>>
>> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>>
>> ---
>>
>> We may like the usage string like this:
>>
>> [[-z] --stdin | --index-info]
>
> Yeah, that'd be definitely better IMO.
Will do.
>
> Also the usage string in builtin/update-index.c should be updated to the
> same effect.
>
> There is actually at least one more problem with the current SYNOPSIS of
> `update-index'. Obviously the `*' on the third line of the Asciidoc
> source makes the whole `--cacheinfo' line disappear and the rest bold
> (cf. e.g. the result at
> <http://www.kernel.org/pub/software/scm/git/docs/git-update-index.html>).
>
> I guess using `...' instead of the asterisks (also on the last line,
> i.e. [<file>...], not [<file>]*) would both fix the problem and at the
> same time make it more consistent with other man pages.
I wont change it in this patch, because I can't build the html docs right now.
>
>> to make it also clear, that -z applies only to --stdin or --index-only.
>> ---
>> Documentation/git-update-index.txt | 14 ++++++++------
>> 1 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/git-update-index.txt
>> b/Documentation/git-update-index.txt
>> index 74d1d49..4441d7c 100644 Documentation/git-update-index.txt
>> --- a/Documentation/git-update-index.txt
>> +++ b/Documentation/git-update-index.txt
>> @@ -18,8 +18,9 @@ SYNOPSIS
>> [--skip-worktree | --no-skip-worktree]
>> [--ignore-submodules]
>> [--really-refresh] [--unresolve] [--again | -g]
>> - [--info-only] [--index-info]
>> - [-z] [--stdin]
>> + [--info-only]
>> + [-z]
>> + [--stdin] [--index-info]
>> [--verbose]
>> [--] [<file>]*
>
> Shouldn't `--verbose' be also moved before the must-be-last options?
Sure. I noticed this myself, but the patch was already in the wire.
>
>> @@ -72,7 +73,7 @@ OPTIONS
>> Directly insert the specified info into the index.
>>
>> --index-info::
>> - Read index information from stdin.
>> + Read index information from stdin (Must be last option).
>
> I'm not a native speaker myself, but I suspect "must be THE last option"
> is more correct (including the lower-case `m' :-)).
Maybe this should be in its own sentence, like the '(Implies
--remove.)' in --force-remove.
>
>> --chmod=(+|-)x::
>> Set the execute permissions on the updated files.
>> @@ -138,14 +139,15 @@ you will need to handle the situation manually.
>> --stdin::
>> Instead of taking list of paths from the command line,
>> read list of paths from the standard input. Paths are
>> - separated by LF (i.e. one path per line) by default.
>> + separated by LF (i.e. one path per line) by default
>> + (Must be last option).
>
> (same here)
>
>>
>> --verbose::
>> Report what is being added and removed from index.
>>
>> -z::
>> - Only meaningful with `--stdin`; paths are separated with
>> - NUL character instead of LF.
>> + Only meaningful with `--stdin` or `--index-info`; paths are
>> + separated with NUL character instead of LF.
>>
>> \--::
>> Do not interpret any more arguments as options.
>
> Thanks,
Thank you.
Bert
>
> Štěpán
>
^ permalink raw reply
* Re: [PATCH 1/3] pnfs_submit: move layout segment valid test
From: Benny Halevy @ 2010-10-07 18:52 UTC (permalink / raw)
To: andros; +Cc: linux-nfs
In-Reply-To: <1286480230-9418-1-git-send-email-andros@netapp.com>
On 2010-10-07 15:37, andros@netapp.com wrote:
> From: Andy Adamson <andros@rhel6-1.androsmac.org>
>
> Do not get_lseg for a non-valid lseg.
> Prepare for calling put_lseg outside of inode i_lock.
>
> Signed-off-by: Andy Adamson <andros@netapp.com>
> ---
> fs/nfs/pnfs.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
> index 6b2a95d..24620cf 100644
> --- a/fs/nfs/pnfs.c
> +++ b/fs/nfs/pnfs.c
> @@ -845,7 +845,8 @@ pnfs_has_layout(struct pnfs_layout_hdr *lo,
> list_for_each_entry(lseg, &lo->segs, fi_list) {
> if (is_matching_lseg(lseg, range)) {
> ret = lseg;
> - get_lseg(ret);
> + if (lseg->valid)
> + get_lseg(ret);
We shouldn't be hiding this inside pnfs_has_layout
and have different side effects in the different cases.
Since we're called under the lock, pnfs_has_layout
can just return the lseg and never get a reference and its
caller can take it if necessary before releasing the lock.
Also, it doesn't need to be EXPORT_SYMBOL_GPLed as it's
not used outside of the nfs client module.
Benny
> break;
> }
> if (cmp_layout(range, &lseg->range) > 0)
> @@ -889,7 +890,6 @@ pnfs_update_layout(struct inode *ino,
> /* Check to see if the layout for the given range already exists */
> lseg = pnfs_has_layout(lo, &arg);
> if (lseg && !lseg->valid) {
> - put_lseg_locked(lseg);
> /* someone is cleaning the layout */
> lseg = NULL;
> goto out_unlock;
^ permalink raw reply
* RE: What happened to ~shefty/libibcm.git?
From: Hefty, Sean @ 2010-10-07 18:52 UTC (permalink / raw)
To: Hefty, Sean, Jason Gunthorpe; +Cc: Linux RDMA list
In-Reply-To: <CF9C39F99A89134C9CF9C4CCB68B8DDF25B788C995-osO9UTpF0USkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
> > > http://www.mail-archive.com/general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org/msg14919.html
>
> This patches doesn't appear to be there. I honestly don't remember this
> patch at this point. I will take a look at it.
I manually added this patch based on the one provided in the link and pushed those changes to the new ofa server. Let me know if you find any issues or other omissions.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Narendra_K @ 2010-10-07 18:44 UTC (permalink / raw)
To: kay.sievers
Cc: greg, Matt_Domsch, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 10:35:14PM +0530, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the
> naming?
>
> Anyway, I'm pretty sure all of this naming of onboard devices should
> happen only at install time, or from a system management tool and not
> at hotplug time.
>
> We should not get confused by the way the (very simple)
> automatic-rule-creater for persistent netdev naming in udev works.
> This is really just a tool for the common case, and works fine for the
> majority of people.
Right. It works as the automatic rule creator saves the snapshot of the
registered network interfaces at run time.
>
> I'm not sure, if we should put all these special use cases in the
> hotplug path. I mean it's not that people add and remove 4 port
> network cards with special BIOS all the time, and expect proper naming
> on the first bootup, right? The installer, or the system management
> tool could just create/edit udev rules to provide proper device naming
> on whatever property is available at a specific hardware, be it the
> MAC address or some other persistent match?
>
The proposal made is not expecting deterministic naming when an add-in
card with 'N' ports is plugged in/out. It is specific to onboard devices
only. Expectation is onboard devices have deterministic naming at first
bootup. And no special BIOS required as SMBIOS tables are in use for
sometime now.
I did explore using rules based on the exported attribute ATTRS{index}
on a system with 4 Onboard devices and two add-in devices.(where add-in
device becomes eth0 and eth1)
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
# tool) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
# ATTRS{index}=="1", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
(and similary for eth1..eth3)
And for add-in devices.
# PCI device 0x8086:0x10c9 (igb) (custom name provided by external tool)
# SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
# ATTR{address}=="00:1b:21:54:33:3c", ATTR{type}=="1", KERNEL=="eth*",
# NAME="eth4" (and similar for eth5 as they do not have an index)
This works as i edited the file manually.
If this has to be done on a large number of systems where an image
based deployment is preferred, getting onboard device names as expected
is an issue and is important.
--
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH 3/4] mfd/mc13xxx: add support for mc13892
From: Samuel Ortiz @ 2010-10-07 18:49 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: David Jander, linux-kernel
In-Reply-To: <20101007184501.GX29673@pengutronix.de>
Hi Uwe,
On Thu, Oct 07, 2010 at 08:45:01PM +0200, Uwe Kleine-König wrote:
> Hi Samuel,
>
> On Wed, Sep 29, 2010 at 06:23:46PM +0200, Uwe Kleine-König wrote:
> > mc13892 is the companion PMIC for Freescale's i.MX51. It's similar enough
> > to mc13782 to support it in a single driver.
> >
> > This patch introduces enough compatibility cruft to keep all users of the
> > superseded mc13783 driver unchanged.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > drivers/mfd/Kconfig | 9 +-
> > drivers/mfd/Makefile | 2 +-
> > drivers/mfd/mc13783-core.c | 743 --------------------------------------
> > drivers/mfd/mc13xxx-core.c | 840 +++++++++++++++++++++++++++++++++++++++++++
> > include/linux/mfd/mc13783.h | 247 ++++++-------
> > include/linux/mfd/mc13xxx.h | 154 ++++++++
> > 6 files changed, 1113 insertions(+), 882 deletions(-)
> > delete mode 100644 drivers/mfd/mc13783-core.c
> > create mode 100644 drivers/mfd/mc13xxx-core.c
> > create mode 100644 include/linux/mfd/mc13xxx.h
> >
> > [...]
> > diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
> > new file mode 100644
> > index 0000000..93258ad
> > --- /dev/null
> > +++ b/drivers/mfd/mc13xxx-core.c
> > @@ -0,0 +1,840 @@
> > +/*
> > + * Copyright 2009-2010 Pengutronix
> > + * Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
> > + *
> > + * loosely based on an earlier driver that has
> > + * Copyright 2009 Pengutronix, Sascha Hauer <s.hauer@pengutronix.de>
> > + *
> > + * This program is free software; you can redistribute it and/or modify it under
> > + * the terms of the GNU General Public License version 2 as published by the
> > + * Free Software Foundation.
> > + */
> > +#define DEBUG
> > +#define VERBOSE_DEBUG
> David Jander gave me a hint via private mail that I forgot to remove
> these two #defines.
> Would you care to remove these before Linus pulls? Should I send a
> patch or do you do it by hand?
I'll take care of it, don't bother.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* 2.6.36-rc7-next-20101007 failed to compile (arch/arm/kernel/setup.c)
From: Alex Sverdlin @ 2010-10-07 18:48 UTC (permalink / raw)
To: linux-arm-kernel
make output:
...
CC arch/arm/kernel/ptrace.o
CC arch/arm/kernel/return_address.o
CC arch/arm/kernel/setup.o
/tmp/cccRqJQQ.s: Assembler messages:
/tmp/cccRqJQQ.s:571: Error: bad instruction `isb'
make[2]: *** [arch/arm/kernel/setup.o] Error 1
make[1]: *** [arch/arm/kernel] Error 2
...
2.6.36-rc6 compiled without this problem...
Compiler is GCC 3.4.3, complete toolchain taken from
http://arm.cirrus.com/files/tools/arm-linux-gcc-3.4.3-1.0.1.tar.bz2
^ permalink raw reply
* Re: [PATCH] cifs: on multiuser mount, set ownership to current_fsuid/current_fsgid (try #5)
From: Steve French @ 2010-10-07 18:48 UTC (permalink / raw)
To: Jeff Layton; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1286477188-26681-1-git-send-email-jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Thanks - as I had commented before, I think this will help a few cases
where admin has to be override uid and mode to get apps to work.
On Thu, Oct 7, 2010 at 1:46 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> ...when unix extensions aren't enabled. This makes everything on the
> mount appear to be owned by the current user.
>
> This version of the patch differs from previous versions however in that
> the admin can still force the ownership of all files to appear as a
> single user via the uid=/gid= options.
>
> Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> fs/cifs/inode.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index dcd0886..7cf3d93 100644
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -1761,11 +1761,21 @@ check_inval:
> int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry,
> struct kstat *stat)
> {
> + struct cifs_sb_info *cifs_sb = CIFS_SB(dentry->d_sb);
> + struct cifsTconInfo *tcon = cifs_sb_master_tcon(cifs_sb);
> int err = cifs_revalidate_dentry(dentry);
> +
> if (!err) {
> generic_fillattr(dentry->d_inode, stat);
> stat->blksize = CIFS_MAX_MSGSIZE;
> stat->ino = CIFS_I(dentry->d_inode)->uniqueid;
> + if ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MULTIUSER) &&
> + !tcon->unix_ext) {
> + if (!cifs_sb->mnt_uid)
> + stat->uid = current_fsuid();
> + if (!cifs_sb->mnt_uid)
> + stat->gid = current_fsgid();
> + }
> }
> return err;
> }
> --
> 1.7.2.3
>
>
--
Thanks,
Steve
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Yehuda Sadeh Weinraub @ 2010-10-07 18:41 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, kvm, qemu-devel, ceph-devel, Christian Brunner
In-Reply-To: <4CAE13BA.70707@codemonkey.ws>
On Thu, Oct 7, 2010 at 11:38 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 10/07/2010 01:08 PM, Yehuda Sadeh Weinraub wrote:
>>
>> On Thu, Oct 7, 2010 at 7:12 AM, Anthony Liguori<anthony@codemonkey.ws>
>> wrote:
>>
>>>
>>> On 08/03/2010 03:14 PM, Christian Brunner wrote:
>>>
>>>>
>>>> +#include "qemu-common.h"
>>>> +#include "qemu-error.h"
>>>> +#include<sys/types.h>
>>>> +#include<stdbool.h>
>>>> +
>>>> +#include<qemu-common.h>
>>>>
>>>>
>>>
>>> This looks to be unnecessary. Generally, system includes shouldn't be
>>> required so all of these should go away except rado/librados.h
>>>
>>
>> Removed.
>>
>>
>>>
>>>
>>>>
>>>> +
>>>> +#include "rbd_types.h"
>>>> +#include "module.h"
>>>> +#include "block_int.h"
>>>> +
>>>> +#include<stdio.h>
>>>> +#include<stdlib.h>
>>>> +#include<rados/librados.h>
>>>> +
>>>> +#include<signal.h>
>>>> +
>>>> +
>>>> +int eventfd(unsigned int initval, int flags);
>>>>
>>>>
>>>
>>> This is not quite right. Depending on eventfd is curious but in the very
>>> least, you need to detect the presence of eventfd in configure and
>>> provide a
>>> wrapper that redefines it as necessary.
>>>
>>
>> Can fix that, though please see my later remarks.
>>
>>>>
>>>> +static int create_tmap_op(uint8_t op, const char *name, char
>>>> **tmap_desc)
>>>> +{
>>>> + uint32_t len = strlen(name);
>>>> + /* total_len = encoding op + name + empty buffer */
>>>> + uint32_t total_len = 1 + (sizeof(uint32_t) + len) +
>>>> sizeof(uint32_t);
>>>> + char *desc = NULL;
>>>>
>>>>
>>>
>>> char is the wrong type to use here as it may be signed or unsigned. That
>>> can have weird effects with binary data when you're directly manipulating
>>> it.
>>>
>>
>> Well, I can change it to uint8_t, so that it matches the op type, but
>> that'll require adding some other castings. In any case, you usually
>> get such a weird behavior when you cast to types of different sizes
>> and have the sign bit padded which is not the case in here.
>>
>>
>>>
>>>
>>>>
>>>> +
>>>> + desc = qemu_malloc(total_len);
>>>> +
>>>> + *tmap_desc = desc;
>>>> +
>>>> + *desc = op;
>>>> + desc++;
>>>> + memcpy(desc,&len, sizeof(len));
>>>> + desc += sizeof(len);
>>>> + memcpy(desc, name, len);
>>>> + desc += len;
>>>> + len = 0;
>>>> + memcpy(desc,&len, sizeof(len));
>>>> + desc += sizeof(len);
>>>>
>>>>
>>>
>>> Shouldn't endianness be a concern?
>>>
>>
>> Right. Fixed that.
>>
>>
>>>
>>>
>>>>
>>>> +
>>>> + return desc - *tmap_desc;
>>>> +}
>>>> +
>>>> +static void free_tmap_op(char *tmap_desc)
>>>> +{
>>>> + qemu_free(tmap_desc);
>>>> +}
>>>> +
>>>> +static int rbd_register_image(rados_pool_t pool, const char *name)
>>>> +{
>>>> + char *tmap_desc;
>>>> + const char *dir = RBD_DIRECTORY;
>>>> + int ret;
>>>> +
>>>> + ret = create_tmap_op(CEPH_OSD_TMAP_SET, name,&tmap_desc);
>>>> + if (ret< 0) {
>>>> + return ret;
>>>> + }
>>>> +
>>>> + ret = rados_tmap_update(pool, dir, tmap_desc, ret);
>>>> + free_tmap_op(tmap_desc);
>>>> +
>>>> + return ret;
>>>> +}
>>>>
>>>>
>>>
>>> This ops are all synchronous? IOW, rados_tmap_update() call blocks until
>>> the operation is completed?
>>>
>>
>> Yeah. And this is only called from the rbd_create() callback.
>>
>>
>>>>
>>>> + header_snap += strlen(header_snap) + 1;
>>>> + if (header_snap> end)
>>>> + error_report("bad header, snapshot list broken");
>>>>
>>>>
>>>
>>> Missing curly braces here.
>>>
>>
>> Fixed.
>>
>>
>>>>
>>>> + if (strncmp(hbuf + 68, RBD_HEADER_VERSION, 8)) {
>>>> + error_report("Unknown image version %s", hbuf + 68);
>>>> + r = -EMEDIUMTYPE;
>>>> + goto failed;
>>>> + }
>>>> +
>>>> + RbdHeader1 *header;
>>>>
>>>>
>>>>
>>>
>>> Don't mix variable definitions with code.
>>>
>>
>> Fixed.
>>
>>
>>>>
>>>> + s->efd = eventfd(0, 0);
>>>> + if (s->efd< 0) {
>>>> + error_report("error opening eventfd");
>>>> + goto failed;
>>>> + }
>>>> + fcntl(s->efd, F_SETFL, O_NONBLOCK);
>>>> + qemu_aio_set_fd_handler(s->efd, rbd_aio_completion_cb, NULL,
>>>> + rbd_aio_flush_cb, NULL, s);
>>>>
>>>>
>>>
>>> It looks like you just use the eventfd to signal aio completion
>>> callbacks.
>>> A better way to do this would be to schedule a bottom half. eventfds
>>> are
>>> Linux specific and specific to recent kernels.
>>>
>>
>> Digging back why we introduced the eventfd, it was due to some issues
>> seen with do_savevm() hangs on qemu_aio_flush(). The reason seemed
>> that we had no fd associated with the block device, which seemed to
>> not work well with the qemu aio model. If that assumption is wrong,
>> we'd be happy to change it. In any case, there are other more portable
>> ways to generate fds, so if it's needed we can do that.
>>
>
> There's no fd at all? How do you get notifications about an asynchronous
> event completion?
>
> Regards,
>
> Anthony Liguori
>
(resending to list, sorry)
The fd is hidden deep under in librados. We get callback notifications
for events completion.
Thanks,
Yehuda
^ 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.