* [ath9k-devel] [PATCH] ath9k_hw: add default chainmask for AR9462
From: Mohammed Shafi Shajakhan @ 2011-11-30 15:40 UTC (permalink / raw)
To: ath9k-devel
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
the default tx/rx chainmask for AR9462 is 0x3.
this patch helps to assign 0x3 rather than 0x7 for
AR9462 with the help of fix_chainmask module if something
goes wrong in reading tx/rx chain mask from OTP/EEPROM
card(though its very unlikely)
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8876134..f282dae 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2149,6 +2149,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
if (AR_SREV_9485(ah) || AR_SREV_9285(ah) || AR_SREV_9330(ah))
chip_chainmask = 1;
+ else if (AR_SREV_9462(ah))
+ chip_chainmask = 3;
else if (!AR_SREV_9280_20_OR_LATER(ah))
chip_chainmask = 7;
else if (!AR_SREV_9300_20_OR_LATER(ah) || AR_SREV_9340(ah))
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/1] btrfs: btrfs_calc_avail_data_space cope with no read/write devices V2
From: Andy Whitcroft @ 2011-11-30 15:40 UTC (permalink / raw)
To: Li Zefan
Cc: Jonathan Nieder, Chris Mason, Josef Bacik, Miao Xie,
Ivan Vilata i Balaguer, linux-btrfs, linux-kernel
In-Reply-To: <4ED434A9.8020809@cn.fujitsu.com>
On Tue, Nov 29, 2011 at 09:26:01AM +0800, Li Zefan wrote:
> This patch has the same problem with your previous one, that it will set
> f_bavail to 0. I've sent out a new patch yesterday.
Ahh, sounds great thanks. Often a patch is a good way to start a
discussion to a more correct patch. Specially when one is not an expert
in the area.
-apw
^ permalink raw reply
* Re: PCIe Hotplugging not working
From: Matthew Garrett @ 2011-11-30 15:40 UTC (permalink / raw)
To: Anand Kanaginhal
Cc: Linux PCI mailing, linux kernel mailing, linux hotplug mailing
In-Reply-To: <BAY163-W47DD39095DA3EB108AA3F2FBB30@phx.gbl>
Make sure that you have CONFIG_HOTPLUG_PCI_ACPI=y and
CONFIG_HOTPLUG_PCI_PCIE=y.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [3.2-rc3] 100% CPU usage while in del_timer_sync from iwl3945_rs_free_sta
From: Stanislaw Gruszka @ 2011-11-30 15:39 UTC (permalink / raw)
To: Michal Hocko; +Cc: LKML, John W. Linville, linux-wireless
In-Reply-To: <20111130140316.GA4153@tiehlicka.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 280 bytes --]
On Wed, Nov 30, 2011 at 03:03:16PM +0100, Michal Hocko wrote:
> No, didn't help unfortunately...
Lets gather some more messages. Please apply attached simple patch,
recompile with:
CONFIG_MAC80211_DEBUG_MENU=y
CONFIG_MAC80211_VERBOSE_DEBUG=y
and provide dmesg.
Thanks
Stanislaw
[-- Attachment #2: mac80211_debug.patch --]
[-- Type: text/plain, Size: 887 bytes --]
diff --git a/drivers/net/wireless/iwlegacy/iwl-3945-rs.c b/drivers/net/wireless/iwlegacy/iwl-3945-rs.c
index 8faeaf2..c728f94 100644
--- a/drivers/net/wireless/iwlegacy/iwl-3945-rs.c
+++ b/drivers/net/wireless/iwlegacy/iwl-3945-rs.c
@@ -413,6 +413,7 @@ static void *iwl3945_rs_alloc_sta(void *iwl_priv, struct ieee80211_sta *sta, gfp
IWL_DEBUG_RATE(priv, "enter\n");
rs_sta = &psta->rs_sta;
+ printk("%s rs_sta %p\n", __func__, rs_sta);
spin_lock_init(&rs_sta->lock);
init_timer(&rs_sta->rate_scale_flush);
@@ -432,6 +433,10 @@ static void iwl3945_rs_free_sta(void *iwl_priv, struct ieee80211_sta *sta,
* to use iwl_priv to print out debugging) since it may not be fully
* initialized at this point.
*/
+
+ printk("%s rs_sta %p\n", __func__, rs_sta);
+ if (WARN_ON(rs_sta->rate_scale_flush.base == NULL))
+ return;
del_timer_sync(&rs_sta->rate_scale_flush);
}
^ permalink raw reply related
* Re: [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
From: Dave Martin @ 2011-11-30 15:37 UTC (permalink / raw)
To: Pawel Moll
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Tixy,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1322579473-8804-5-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
On Tue, Nov 29, 2011 at 03:11:12PM +0000, Pawel Moll wrote:
> This patch adds support for RS1 memory map based Versatile Express
> motherboard.
[...]
> +config ARCH_VEXPRESS_RS1
> + bool
> + select AUTO_ZRELADDR
> + select ARM_PATCH_PHYS_VIRT
> + help
> + RS1 VE memory map (i.a. motherboard peripherals at
> + 0x1c000000, RAM at 0x80000000).
> +
> endmenu
> diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> index 8630b3d..05b77a5 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -1,3 +1,9 @@
> +ifeq ($(CONFIG_ARCH_VEXPRESS_RS1),y)
> + zreladdr-y += 0x80008000
> +params_phys-y := 0x80000100
> +initrd_phys-y := 0x80800000
This results in a uImage which is a bit broken if using a normal u-Boot
configured for vexpress-v2p-ca9, because the bootloader makes some
memory map assumptions, and anyway we don't expect the kernel to work
unless it's loaded at the start of RAM:
## Booting kernel from Legacy Image at 62000400 ...
Image Name: Linux-3.2.0-rc3+
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2464984 Bytes = 2.4 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 80ffffc0 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 2216523 Bytes = 2.1 MiB
Load Address: 81000000
Entry Point: 81000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80ffc000
Booting using the fdt blob at 0x80ffc000
Loading Kernel Image ... OK
OK
Loading Ramdisk to 7fcd3000, end 7fef024b ... OK
Loading Device Tree to 7fcce000, end 7fcd2779 ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Initializing cgroup subsys cpuset
Linux version 3.2.0-rc3+ (davem@e103592) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #12 SMP Wed Nov 30 15:10:19 GMT 2011
CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ARM Versatile Express, model: V2P-CA9
bootconsole [earlycon0] enabled
Ignoring RAM at 60000000-7fffffff (vmalloc region overlap).
Ignoring RAM at 60000000-9fffffff (vmalloc region overlap).
INITRD: 0x7fcd3000+0x0021d24b is not a memory region - disabling initrd
Memory policy: ECC disabled, Data cache writealloc
<HANG>
If I strip the uImage and rebuild it with -a 0x60008000 -e 0x60008000
and no other changes, that's sufficient to give me a fully booting
kernel. I can also boot a single image on v2p-ca9 both with and without
a dtb in this configuration.
I'm using a Linaro u-Boot from a couple of releses ago; it's possible
things have changed since.
Do you know of any specific u-Boot version which shouldn't have these
problems?
Was the hard-coded uImage load address/entry point problem ever fixed?
(It totally defeats loading a single uImage on multiple board variants.)
Cheers
---Dave
^ permalink raw reply
* [PATCH v3 4/5] ARM: vexpress: Initial RS1 memory map support
From: Dave Martin @ 2011-11-30 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1322579473-8804-5-git-send-email-pawel.moll@arm.com>
On Tue, Nov 29, 2011 at 03:11:12PM +0000, Pawel Moll wrote:
> This patch adds support for RS1 memory map based Versatile Express
> motherboard.
[...]
> +config ARCH_VEXPRESS_RS1
> + bool
> + select AUTO_ZRELADDR
> + select ARM_PATCH_PHYS_VIRT
> + help
> + RS1 VE memory map (i.a. motherboard peripherals at
> + 0x1c000000, RAM at 0x80000000).
> +
> endmenu
> diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> index 8630b3d..05b77a5 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -1,3 +1,9 @@
> +ifeq ($(CONFIG_ARCH_VEXPRESS_RS1),y)
> + zreladdr-y += 0x80008000
> +params_phys-y := 0x80000100
> +initrd_phys-y := 0x80800000
This results in a uImage which is a bit broken if using a normal u-Boot
configured for vexpress-v2p-ca9, because the bootloader makes some
memory map assumptions, and anyway we don't expect the kernel to work
unless it's loaded at the start of RAM:
## Booting kernel from Legacy Image at 62000400 ...
Image Name: Linux-3.2.0-rc3+
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2464984 Bytes = 2.4 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 80ffffc0 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 2216523 Bytes = 2.1 MiB
Load Address: 81000000
Entry Point: 81000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80ffc000
Booting using the fdt blob at 0x80ffc000
Loading Kernel Image ... OK
OK
Loading Ramdisk to 7fcd3000, end 7fef024b ... OK
Loading Device Tree to 7fcce000, end 7fcd2779 ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Initializing cgroup subsys cpuset
Linux version 3.2.0-rc3+ (davem at e103592) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #12 SMP Wed Nov 30 15:10:19 GMT 2011
CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ARM Versatile Express, model: V2P-CA9
bootconsole [earlycon0] enabled
Ignoring RAM at 60000000-7fffffff (vmalloc region overlap).
Ignoring RAM at 60000000-9fffffff (vmalloc region overlap).
INITRD: 0x7fcd3000+0x0021d24b is not a memory region - disabling initrd
Memory policy: ECC disabled, Data cache writealloc
<HANG>
If I strip the uImage and rebuild it with -a 0x60008000 -e 0x60008000
and no other changes, that's sufficient to give me a fully booting
kernel. I can also boot a single image on v2p-ca9 both with and without
a dtb in this configuration.
I'm using a Linaro u-Boot from a couple of releses ago; it's possible
things have changed since.
Do you know of any specific u-Boot version which shouldn't have these
problems?
Was the hard-coded uImage load address/entry point problem ever fixed?
(It totally defeats loading a single uImage on multiple board variants.)
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH 01/11] imsm: FIX: Return longer map for failure setting
From: Williams, Dan J @ 2011-11-30 15:37 UTC (permalink / raw)
To: Kwolek, Adam
Cc: neilb@suse.de, linux-raid@vger.kernel.org, Ciechanowski, Ed,
Labun, Marcin
In-Reply-To: <79556383A0E1384DB3A3903742AAC04A054C06@IRSMSX101.ger.corp.intel.com>
On Tue, Nov 29, 2011 at 11:56 PM, Kwolek, Adam <adam.kwolek@intel.com> wrote:
>> I don't understand this patch. If we are setting a new degraded disk
>> migration is idle and the degraded state is set in map[0].
>>
>> --
>> Dan
>
> This is made for future in case when support for shrinking will be added.
If it's for a future unimplemented case then this is not a "FIX".
> When second map is longer than first one and degradation occurs on position that is not present in first map.
> It situation should be stored in map also.
What's wrong with using get_imsm_map(dev, 1) for this case?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM MemoryRegion
From: Andreas Färber @ 2011-11-30 15:34 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel Developers
In-Reply-To: <4ED4AB4A.2010209@redhat.com>
Am 29.11.2011 10:52, schrieb Avi Kivity:
> On 11/29/2011 12:39 AM, Andreas Färber wrote:
>> Am 28.11.2011 18:17, schrieb Avi Kivity:
>>> On 11/28/2011 05:06 PM, Andreas Färber wrote:
>>>> diff --git a/exec.c b/exec.c
>>>> index 6b92198..fba5ba1 100644
>>>> --- a/exec.c
>>>> +++ b/exec.c
>>>> @@ -3508,6 +3508,21 @@ static inline uint32_t subpage_readlen (subpage_t *mmio,
>>>>
>>>> addr += mmio->region_offset[idx];
>>>> idx = mmio->sub_io_index[idx];
>>>> + if (unlikely(idx == IO_MEM_RAM)) {
>>>
>>> IMO, io_mem_init() should have something like
>>>
>>> cpu_register_io_memory_fixed(IO_MEM_SUBPAGE_RAM, subpage_ram_read,
>>> subpage_ram_write, ...);
>>>
>>> so you don't need those ugly switches; you just convert IO_MEM_RAM to
>>> IO_MEM_SUBPAGE_RAM. Maybe even register IO_MEM_RAM itself. Note need
>>> to handle dirty logging carefully.
>>
>> That didn't work because cpu_register_io_memory_fixed() is called from
>> subpage_init(), which is called once for the whole page only, and the
>> actual subpages are set up with multiple calls to subpage_register()
>> instead.
>
> I don't mean replacing the subpage handle with a call to c_r_io_m_f();
> just make the handle that is placed supage_t::sub_io_index have real io
> callbacks.
>
> In io_mem_init(), call cpu_register_io_memory_fixed() with a new
> mem_read[] callback array an the existing notdirty_mem_write[] array.
> In subpage_register(), if we get an IO_MEM_RAM, convert it to
> IO_MEM_SUBPAGE_RAM (and copy the 'memory' to region_offset).
Sorry, I simply misunderstood your suggestion (memory newbie): Since we
*continue* to go through subpage_{read,write}len(), we don't need a
specific opaque value any longer so can do this from generic code.
v2 sent out.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply
* [PULL] Device Tree updates for 3.2-rc
From: Rob Herring @ 2011-11-30 15:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel@vger.kernel.org, Paweł Moll, Grant Likely
Linus,
As Grant mentioned previously, he's offline for a sabbatical so I'm
gathering up DT patches for 3.2-rc. Not much here. 1 doc update and a
fix to handle reverted commit "of/irq: of_irq_find_parent: check for
parent equal to child" (dc9372808412edb) in different way. Please pull.
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git dt-for-linus
Pawel Moll (1):
of: Add Silicon Image vendor prefix
Rob Herring (1):
of/irq: of_irq_init: add check for parent equal to child node
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/of/irq.c | 2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
Regards,
Rob
^ permalink raw reply
* Re: fallocate vs ENOSPC
From: Ted Ts'o @ 2011-11-30 15:32 UTC (permalink / raw)
To: Pádraig Brady; +Cc: Dave Chinner, Christoph Hellwig, linux-fsdevel
In-Reply-To: <4ED5F740.8090005@draigBrady.com>
On Wed, Nov 30, 2011 at 09:28:32AM +0000, Pádraig Brady wrote:
>
> But then posix_fallocate() would always be slow I think,
> requiring one to actually write the NULs.
Almost no one should ever use posix_fallocate(); it's can be a
performance disaster because you don't know whether or not the file
system will really do fallocate, or will do the slow "write zeros"
thing.
You really should use fallocate(), take the failure if the file system
doesn't support fallocate, and then you can decide what the
appropriate thing to do might be.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] ath9k_hw: Fix TX IQ calibration for AR9003
From: Mohammed Shafi Shajakhan @ 2011-11-30 15:31 UTC (permalink / raw)
To: John W. Linville
Cc: Jouni Malinen, linux-wireless, Rodriguez Luis,
Balasubramanian senthilkumar, Vasanthakumar Thiagarajan,
Rajkumar Manoharan, Vivek Natarajan, ath9k-devel,
Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
only for AR9485 (or) later chipsets TxIQ calibration
runs as part of AGC calibration. without this patch
TX IQ cal completion i.e. ar9003_hw_tx_iq_cal_run won't be executed
for AR9003
Reviewed-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8876134..2de52d2 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2332,7 +2332,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
if (AR_SREV_9300_20_OR_LATER(ah)) {
ah->enabled_cals |= TX_IQ_CAL;
- if (!AR_SREV_9330(ah))
+ if (AR_SREV_9485_OR_LATER(ah))
ah->enabled_cals |= TX_IQ_ON_AGC_CAL;
}
if (AR_SREV_9462(ah))
--
1.7.0.4
^ permalink raw reply related
* [ath9k-devel] [PATCH v2] ath9k_hw: Fix TX IQ calibration for AR9003
From: Mohammed Shafi Shajakhan @ 2011-11-30 15:31 UTC (permalink / raw)
To: ath9k-devel
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
only for AR9485 (or) later chipsets TxIQ calibration
runs as part of AGC calibration. without this patch
TX IQ cal completion i.e. ar9003_hw_tx_iq_cal_run won't be executed
for AR9003
Reviewed-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8876134..2de52d2 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2332,7 +2332,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
if (AR_SREV_9300_20_OR_LATER(ah)) {
ah->enabled_cals |= TX_IQ_CAL;
- if (!AR_SREV_9330(ah))
+ if (AR_SREV_9485_OR_LATER(ah))
ah->enabled_cals |= TX_IQ_ON_AGC_CAL;
}
if (AR_SREV_9462(ah))
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] specific do_timer_cpu value for nohz off mode
From: Dimitri Sivanich @ 2011-11-30 15:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Gleixner
In-Reply-To: <20111122160802.e99d6218.akpm@linux-foundation.org>
On Tue, Nov 22, 2011 at 04:08:02PM -0800, Andrew Morton wrote:
> On Tue, 8 Nov 2011 13:11:49 -0600
> Dimitri Sivanich <sivanich@sgi.com> wrote:
> > Allow manual override of the tick_do_timer_cpu.
> >
> > While not necessarily harmful, doing jiffies updates on an application cpu
> > does cause some extra overhead that HPC benchmarking people notice. They
> > prefer to have OS activity isolated to certain cpus. They like reproducibility
> > of results, and having jiffies updates bouncing around introduces variability.
>
> This doesn't really explain what the patch does. "override" with what?
> What effects can the user expect to see from doing
> the-action-which-you-didn't-describe?
Hopefully my new description and documentation are acceptable.
> > +sysfs_show_do_timer_cpu(struct sys_device *dev,
> > + struct sysdev_attribute *attr, char *buf)
> > +{
> > + ssize_t count = 0;
> > +
> > + count = snprintf(buf, PAGE_SIZE, "%d\n", tick_do_timer_cpu);
> > +
> > + return count;
>
> Save some trees:
>
> return snprintf(buf, PAGE_SIZE, "%d\n", tick_do_timer_cpu);
The new patch below should address this by using the already existing
'sysdev_show_int' function.
> > +
> > + if (sscanf(b, "%d", &c) != 1)
> > + return -EINVAL;
>
> You should be able to use strim() in here, and eliminate b[]. Not that
> the \n needed to be removed anyway! I think it's OK to modify the
> incoming memory for sysfs write handlers.
>
> Also, kstrto*() should be used to detect and reject input of the form
> "42foo".
Using kstrtouint, see patch below.
>
> But surely we have a helper function somewhere to read an integer out
> of a sysfs-written buffer. If not, we should!
Here I need more strict input checking for online cpu values.
>
> > + if (!cpu_online(c))
> > + return -EINVAL;
> > +
> > + tick_do_timer_cpu = c;
> > +
> > + return ret;
> > +}
> > +
> > +/*
> > + * Sysfs setup bits:
> > + */
> > +static SYSDEV_ATTR(jiffies_cpu, 0644, sysfs_show_do_timer_cpu,
> > + sysfs_override_do_timer_cpu);
> > +
> > +static struct sysdev_class timekeeping_sysclass = {
> > + .name = "timekeeping",
> > +};
>
> The patch shouod add some user-facing documentation for the user-facing
> feature.
Hopefully documenting this in Documentation/ABI/testing is acceptable at this
point(?). See patch below.
Show and modify the tick_do_timer_cpu via sysfs. This determines the cpu
on which global time (jiffies) updates occur. Modification can only be
done on systems with nohz mode turned off.
While not necessarily harmful, doing jiffies updates on an application cpu
does cause some extra overhead that HPC benchmarking people notice. They
prefer to have OS activity isolated to certain cpus. They like reproducibility
of results, and having jiffies updates bouncing around introduces variability.
Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
---
Documentation/ABI/testing/sysfs-devices-system-timekeeping | 16 ++
drivers/base/sys.c | 10 -
include/linux/sysdev.h | 2
kernel/time/tick-sched.c | 59 ++++++++++
4 files changed, 81 insertions(+), 6 deletions(-)
Index: linux/include/linux/sysdev.h
===================================================================
--- linux.orig/include/linux/sysdev.h
+++ linux/include/linux/sysdev.h
@@ -132,6 +132,8 @@ struct sysdev_ext_attribute {
void *var;
};
+#define SYSDEV_TO_EXT_ATTR(x) container_of(x, struct sysdev_ext_attribute, attr)
+
/*
* Support for simple variable sysdev attributes.
* The pointer to the variable is stored in a sysdev_ext_attribute
Index: linux/drivers/base/sys.c
===================================================================
--- linux.orig/drivers/base/sys.c
+++ linux/drivers/base/sys.c
@@ -339,13 +339,11 @@ int __init system_bus_init(void)
return 0;
}
-#define to_ext_attr(x) container_of(x, struct sysdev_ext_attribute, attr)
-
ssize_t sysdev_store_ulong(struct sys_device *sysdev,
struct sysdev_attribute *attr,
const char *buf, size_t size)
{
- struct sysdev_ext_attribute *ea = to_ext_attr(attr);
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
char *end;
unsigned long new = simple_strtoul(buf, &end, 0);
if (end == buf)
@@ -360,7 +358,7 @@ ssize_t sysdev_show_ulong(struct sys_dev
struct sysdev_attribute *attr,
char *buf)
{
- struct sysdev_ext_attribute *ea = to_ext_attr(attr);
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
return snprintf(buf, PAGE_SIZE, "%lx\n", *(unsigned long *)(ea->var));
}
EXPORT_SYMBOL_GPL(sysdev_show_ulong);
@@ -369,7 +367,7 @@ ssize_t sysdev_store_int(struct sys_devi
struct sysdev_attribute *attr,
const char *buf, size_t size)
{
- struct sysdev_ext_attribute *ea = to_ext_attr(attr);
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
char *end;
long new = simple_strtol(buf, &end, 0);
if (end == buf || new > INT_MAX || new < INT_MIN)
@@ -384,7 +382,7 @@ ssize_t sysdev_show_int(struct sys_devic
struct sysdev_attribute *attr,
char *buf)
{
- struct sysdev_ext_attribute *ea = to_ext_attr(attr);
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
return snprintf(buf, PAGE_SIZE, "%d\n", *(int *)(ea->var));
}
EXPORT_SYMBOL_GPL(sysdev_show_int);
Index: linux/kernel/time/tick-sched.c
===================================================================
--- linux.orig/kernel/time/tick-sched.c
+++ linux/kernel/time/tick-sched.c
@@ -834,6 +834,65 @@ void tick_cancel_sched_timer(int cpu)
}
#endif
+#ifdef CONFIG_SYSFS
+/*
+ * Allow modification of tick_do_timer_cpu when nohz mode is off.
+ */
+static ssize_t sysfs_store_do_timer_cpu(struct sys_device *dev,
+ struct sysdev_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct sysdev_ext_attribute *ea = SYSDEV_TO_EXT_ATTR(attr);
+ unsigned int new;
+ int rv;
+
+#ifdef CONFIG_NO_HZ
+ /* nohz mode not supported */
+ if (tick_nohz_enabled)
+ return -EINVAL;
+#endif
+
+ rv = kstrtouint(buf, 0, &new);
+ if (rv)
+ return rv;
+
+ if (new >= NR_CPUS || !cpu_online(new))
+ return -ERANGE;
+
+ *(unsigned int *)(ea->var) = new;
+ return size;
+}
+
+static struct sysdev_ext_attribute attr_jiffies_cpu = {
+ _SYSDEV_ATTR(jiffies_cpu, 0644, sysdev_show_int,
+ sysfs_store_do_timer_cpu),
+ &tick_do_timer_cpu };
+
+static struct sysdev_class timekeeping_sysclass = {
+ .name = "timekeeping",
+};
+
+static struct sys_device device_timekeeping = {
+ .id = 0,
+ .cls = &timekeeping_sysclass,
+};
+
+static int __init init_timekeeping_sysfs(void)
+{
+ int error = sysdev_class_register(&timekeeping_sysclass);
+
+ if (!error)
+ error = sysdev_register(&device_timekeeping);
+ if (!error)
+ error = sysdev_create_file(
+ &device_timekeeping,
+ &attr_jiffies_cpu.attr);
+ return error;
+}
+
+device_initcall(init_timekeeping_sysfs);
+#endif /* SYSFS */
+
/**
* Async notification about clocksource changes
*/
Index: linux/Documentation/ABI/testing/sysfs-devices-system-timekeeping
===================================================================
--- /dev/null
+++ linux/Documentation/ABI/testing/sysfs-devices-system-timekeeping
@@ -0,0 +1,16 @@
+What: /sys/devices/system/timekeeping/
+Date: November 2011
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description: Timekeeping attributes
+
+
+What: /sys/devices/system/timekeeping/timekeeping0/jiffies_cpu
+Date: November 2011
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description: Show and modify the kernel's tick_do_timer_cpu. This
+ determines the cpu on which global time (jiffies) updates
+ occur. This can only be modified on systems running with
+ the nohz mode turned off (nohz=off).
+
+ Possible values are:
+ 0 - <num online cpus>
^ permalink raw reply
* [PATCH] ath9k_hw: Fix TX IQ calibration for AR9003
From: Mohammed Shafi Shajakhan @ 2011-11-30 15:28 UTC (permalink / raw)
To: John W. Linville
Cc: Jouni Malinen, linux-wireless, Rodriguez Luis,
Balasubramanian senthilkumar, Vasanthakumar Thiagarajan,
Rajkumar Manoharan, Vivek Natarajan, ath9k-devel,
Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
only for AR9485 (or) later chipsets TxIQ calibration
runs as part of AGC calibration. without this patch
TX IQ cal i.e. ar9003_hw_tx_iq_cal_run won't be executed
for AR9003
Reviewed-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8876134..2de52d2 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2332,7 +2332,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
if (AR_SREV_9300_20_OR_LATER(ah)) {
ah->enabled_cals |= TX_IQ_CAL;
- if (!AR_SREV_9330(ah))
+ if (AR_SREV_9485_OR_LATER(ah))
ah->enabled_cals |= TX_IQ_ON_AGC_CAL;
}
if (AR_SREV_9462(ah))
--
1.7.0.4
^ permalink raw reply related
* [ath9k-devel] [PATCH] ath9k_hw: Fix TX IQ calibration for AR9003
From: Mohammed Shafi Shajakhan @ 2011-11-30 15:28 UTC (permalink / raw)
To: ath9k-devel
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
only for AR9485 (or) later chipsets TxIQ calibration
runs as part of AGC calibration. without this patch
TX IQ cal i.e. ar9003_hw_tx_iq_cal_run won't be executed
for AR9003
Reviewed-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8876134..2de52d2 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2332,7 +2332,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
if (AR_SREV_9300_20_OR_LATER(ah)) {
ah->enabled_cals |= TX_IQ_CAL;
- if (!AR_SREV_9330(ah))
+ if (AR_SREV_9485_OR_LATER(ah))
ah->enabled_cals |= TX_IQ_ON_AGC_CAL;
}
if (AR_SREV_9462(ah))
--
1.7.0.4
^ permalink raw reply related
* [Bug 37549] Dell Studio XPS 1340 - fails to enter suspend mode
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-11-30 15:28 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-37549-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=37549
--- Comment #2 from Daniel Manrique <daniel-FhjLw7zaDyBIvLhBkaBJOXtgZLXuOG4l@public.gmane.org> 2011-11-30 07:28:42 PST ---
Just to update on this, I tested with a 3.2-rc2 kernel, where this problem is
still present as described originally.
Thanks!
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH 02/16] MPILIB: Add a missing ENOMEM check [ver #2]
From: Serge Hallyn @ 2011-11-30 15:28 UTC (permalink / raw)
To: David Howells
Cc: keyrings, linux-crypto, linux-security-module, linux-kernel,
dmitry.kasatkin, zohar, arjan.van.de.ven, alan.cox
In-Reply-To: <20111129234323.13625.34554.stgit@warthog.procyon.org.uk>
On 11/29/2011 05:43 PM, David Howells wrote:
> Add a missing ENOMEM check.
>
> Signed-off-by: David Howells<dhowells@redhat.com>
> ---
>
> lib/mpi/mpicoder.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
>
> diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
> index fe84bb9..6e225a8 100644
> --- a/lib/mpi/mpicoder.c
> +++ b/lib/mpi/mpicoder.c
> @@ -255,6 +255,8 @@ void *mpi_get_buffer(MPI a, unsigned *nbytes, int *sign)
> if (!n)
> n++; /* avoid zero length allocation */
> p = buffer = kmalloc(n, GFP_KERNEL);
> + if (p< 0)
> + return NULL;
Sorry, maybe i'm having a confused morning, but shouldn't this check be
for p==NULL rather than p<0?
>
> for (i = a->nlimbs - 1; i>= 0; i--) {
> alimb = a->d[i];
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [U-Boot] [PATCH 01/13] davinci_emac: move arch-independent defines to separate header
From: Tom Rini @ 2011-11-30 15:27 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4ED648E4.9060307@compulab.co.il>
On Wed, Nov 30, 2011 at 8:16 AM, Igor Grinberg <grinberg@compulab.co.il> wrote:
> On 11/30/11 16:21, Tom Rini wrote:
>> On Wed, Nov 30, 2011 at 12:35 AM, Igor Grinberg <grinberg@compulab.co.il> wrote:
>>> On 11/29/11 20:57, Tom Rini wrote:
>>>> On Mon, Nov 28, 2011 at 9:37 AM, Ilya Yanok <yanok@emcraft.com> wrote:
>>>>> DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs
>>>>> also. This patch moves common defines from arch-davinci/emac_defs.h to
>>>>> drivers/net/davinci_emac.h
>>>>>
>>>>> DaVinci specific PHY drivers hacked to include the new header. We might
>>>>> want to switch to phylib in future.
>>>>>
>>>>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>>>>
>>>> I missed the 0/13 email but, patches 1 to 10 will be queued up into
>>>> u-boot-ti, Scott mentioned a problem with 11, I haven't seen anything
>>>> about 12 (but it's delegated to someone else) and I've commented on
>>>> 13. ?This should at least reduce the repost burden, thanks for all
>>>> your patience here!
>>>
>>> Good to hear, you are a co-custodian for u-boot-ti, I really like it, but...
>>> You should let patches hang a little on the list...
>>> This version was published just 1.5 days ago...
>>
>> True, but the changes you object to were around for a while longer
>> than that. ?And really what needs to happen with this driver is
>> switching to phylib (like the kernel version does).
>
> That is also true, I admit.
> Meanwhile, shouldn't we make at least this one kind of clearer?
> Because, future intend is not an excuse for ugly code, right?
Relative includes are also relatively common. This wins on depth,
true. Albert? Wolfgang? Is this "too ugly to live" and we need to
fix it or live with it until we can switch to phylib?
--
Tom
^ permalink raw reply
* Re: [PATCH 1/1] mmc:Support of PCI mode for the dw_mmc driver
From: Shashidhar Hiremath @ 2011-11-30 15:27 UTC (permalink / raw)
To: James Hogan
Cc: Chris Ball, Shawn Guo, Philip Rakity, Mark F. Brown, Wolfram Sang,
Will Newton, Jaehoon Chung, Kyungmin Park, linux-mmc
In-Reply-To: <4ED63861.7030607@imgtec.com>
Hi James,
Sorry for the minor alignment issues.Will fix them . I actually did
compile the code but as separate driver not along with the kernel. In
fact, I have also tested the PCI patch ,but not as separate files but
with the earlier #ifdef method I had sent in initial patch .
On Wed, Nov 30, 2011 at 7:36 PM, James Hogan <james.hogan@imgtec.com> wrote:
> Hi,
>
> *sigh* You haven't actually tried compiling this have you? How do you
> know whether it works or not? You really really should at least make
> sure it compiles (for simple changes) and works without breaking
> anything (for anything non-trivial like adding support for a new bus
> like PCI)!
>
> Couple of other minor things below.
>
> On 11/30/2011 12:36 PM, Shashidhar Hiremath wrote:
>> Support of PCI mode for the dw_mmc driver. This Patch adds the
>> support for the scenario where the Synopsys Designware IP
>> is present on the PCI bus. The patch adds the minimal modifications
>> necessary for the driver to work on PCI platform. Also added separate
>> files for PCI and PLATFORM modes of operation.
>>
>> Signed-off-by: Shashidhar Hiremath <shashidharh@vayavyalabs.com>
>> ---
>> v2:
>> *As per Suggestions by Will Newton and James Hogan
>> -Reduced the number of ifdefs
>> v3:
>> *As per Suggestions by Will Newton and James Hogan
>> -Added separate files for PCI and PLATFORM Modes similar to SDHCI driver
>> v4:
>> *As per Suggestions by James Hogan
>> -Fixed Indentation Issue.
>> -Added Proper error Handling for probe and remove sequences.
>> -Modified location of some code.
>> -Added isr_flags to dw_mmc.h and removed the ifdef PCI from driver.
>>
>> drivers/mmc/host/Kconfig | 23 ++++++
>> drivers/mmc/host/dw_mmc-pci.c | 158 +++++++++++++++++++++++++++++++++++++++
>> drivers/mmc/host/dw_mmc-pltfm.c | 134 +++++++++++++++++++++++++++++++++
>> drivers/mmc/host/dw_mmc.c | 151 +++++++++++++------------------------
>> drivers/mmc/host/dw_mmc.h | 7 ++
>> include/linux/mmc/dw_mmc.h | 6 +-
>> 6 files changed, 377 insertions(+), 102 deletions(-)
>> create mode 100644 drivers/mmc/host/dw_mmc-pci.c
>> create mode 100644 drivers/mmc/host/dw_mmc-pltfm.c
>>
>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>> index 87d5067..2d8fad6 100644
>> --- a/drivers/mmc/host/Kconfig
>> +++ b/drivers/mmc/host/Kconfig
>> @@ -534,6 +534,29 @@ config MMC_DW_IDMAC
>> Designware Mobile Storage IP block. This disables the external DMA
>> interface.
>>
>> +config MMC_DW_PCI
>> + tristate "Synopsys Designware MCI support on PCI bus"
>> + depends on MMC_DW && PCI
>> + help
>> + This selects the PCI bus for the Synopsys Designware Mobile Storage IP.
>> + Select this option if the IP is present on PCI platform.
>> +
>> + If you have a controller with this interface, say Y or M here.
>> +
>> + If unsure, say N.
>> +
>> +config MMC_DW_PLTFM
>> + tristate "platform driver helper for Synopsys Designware Mobile Storage IP"
>
> It would be nice if this followed the same pattern as MMC_DW_PCI, i.e.
> something like "Synopsys DesignWare MCI support as platform device"
> (makes it look nicer on the menu :) ).
>
> Presuming this is the more common case, it might make sense for it to be
> default y too (the driver cannot be used by default until one or both of
> these options has been selected).
>
>> + depends on MMC_DW
>> + help
>> + This selects the common helper functions support for Host Controller
>> + Interface based platform driver.Please select this option if the IP
>> + is present as a platform device.
>> +
>> + If you have a controller with this interface, say Y or M here.
>> +
>> + If unsure, say N.
>> +
>> config MMC_SH_MMCIF
>> tristate "SuperH Internal MMCIF support"
>> depends on MMC_BLOCK && (SUPERH || ARCH_SHMOBILE)
>
> <snip>
>
>> +static int dw_mci_pltfm_probe(struct platform_device *pdev)
>> +{
>> + struct dw_mci *host;
>> + struct resource *regs;
>> + int ret;
>> +
>> + host = kzalloc(sizeof(struct dw_mci), GFP_KERNEL);
>> + if (!host)
>> + return -ENOMEM;
>> +
>> + regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!regs) {
>> + ret = -ENXIO;
>> + goto err_free;
>> + }
>> +
>> + host->irq = platform_get_irq(pdev, 0);
>> + if (host->irq < 0) {
>> + ret = host->irq;
>> + goto err_free;
>> + }
>> +
>> + host->dev = pdev->dev;
>> + host->irq_flags = 0;
>> + host->pdata = pdev->dev.platform_data;
>> + ret = -ENOMEM;
>> + host->regs = ioremap(regs->start, resource_size(regs));
>> + if (!host->regs)
>> + goto err_free;
>> + platform_set_drvdata(pdev, host);
>> + ret = dw_mci_probe(host);
>> + if (ret)
>> + goto err_out;
>> + else
>> + return ret;
>> +err_out:
>> + iounmap(host->regs);
>> +err_free:
>> + kfree(host);
>
> alignment needs fixing here. There's no need for the else either.
>
> Thanks
> James
>
--
regards,
Shashidhar Hiremath
^ permalink raw reply
* Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark
From: Patrick McHardy @ 2011-11-30 15:27 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Pablo Neira Ayuso, jengelh, netfilter-devel, netdev,
hans.schillstrom
In-Reply-To: <hr62jai.42522fc2b4c8846204d05566f5c6b926@obelix.schillstrom.com>
On 11/28/2011 10:36 AM, Hans Schillstrom wrote:
>> If you don't want to use conntrack in your setup and you want to handle
>> fragments, then you have to configure HMARK to calculate the hashing
>> based on the network addresses. If you want to fully support fragments,
>> then enable conntrack and you can configure HMARK to calculate the
>> hashing based on network address + transport bits.
>>
>> Fix this by removing the fragmentation handling, then assume that
>> people can select between two hashing configuration for HMARK. One
>> based for network address which is fragment-safe, one that uses the
>> transport layer information, that requires conntrack. Otherwise, I
>> don't see a sane way to handle this situation.
> Correct me if I'm wrong here,
> If conntrack is enabled hmark don't see the packet until it is reassembled and
> in that case the fragmentation header is removed.
>
> So, with conntrack HMARK will operate on full packets not fragments
> without conntrack ports will not be used on any fragment
Correct.
You don't necessarily need conntrack for defragmentation though,
we've moved defragmentation to a seperate module for TPROXY. You
can depend on that and get defragmentation without full
connection tracking.
^ permalink raw reply
* [Qemu-devel] [PATCH v2] exec.c: Fix subpage memory access to RAM MemoryRegion
From: Andreas Färber @ 2011-11-30 15:26 UTC (permalink / raw)
To: qemu-devel; +Cc: Andreas Färber, Gleb Natapov, Avi Kivity
Commit 95c318f5e1f88d7e5bcc6deac17330fd4806a2d3 (Fix segfault in mmio
subpage handling code.) prevented a segfault by making all subpage
registrations over an existing memory page perform an unassigned access.
Symptoms were writes not taking effect and reads returning zero.
Very small page sizes are not currently supported either,
so subpage memory areas cannot fully be avoided.
Therefore change the previous fix to use a new IO_MEM_SUBPAGE_RAM
instead of IO_MEM_UNASSIGNED. Suggested by Avi.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Cc: Avi Kivity <avi@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
---
cpu-common.h | 1 +
exec.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index c9878ba..3f45428 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -172,6 +172,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
#define IO_MEM_ROM (1 << IO_MEM_SHIFT) /* hardcoded offset */
#define IO_MEM_UNASSIGNED (2 << IO_MEM_SHIFT)
#define IO_MEM_NOTDIRTY (3 << IO_MEM_SHIFT)
+#define IO_MEM_SUBPAGE_RAM (4 << IO_MEM_SHIFT)
/* Acts like a ROM when read and like a device when written. */
#define IO_MEM_ROMD (1)
diff --git a/exec.c b/exec.c
index 6b92198..6c206ff 100644
--- a/exec.c
+++ b/exec.c
@@ -3570,6 +3570,63 @@ static CPUWriteMemoryFunc * const subpage_write[] = {
&subpage_writel,
};
+static uint32_t subpage_ram_readb(void *opaque, target_phys_addr_t addr)
+{
+ ram_addr_t raddr = addr;
+ void *ptr = qemu_get_ram_ptr(raddr);
+ return ldub_p(ptr);
+}
+
+static void subpage_ram_writeb(void *opaque, target_phys_addr_t addr,
+ uint32_t value)
+{
+ ram_addr_t raddr = addr;
+ void *ptr = qemu_get_ram_ptr(raddr);
+ stb_p(ptr, value);
+}
+
+static uint32_t subpage_ram_readw(void *opaque, target_phys_addr_t addr)
+{
+ ram_addr_t raddr = addr;
+ void *ptr = qemu_get_ram_ptr(raddr);
+ return lduw_p(ptr);
+}
+
+static void subpage_ram_writew(void *opaque, target_phys_addr_t addr,
+ uint32_t value)
+{
+ ram_addr_t raddr = addr;
+ void *ptr = qemu_get_ram_ptr(raddr);
+ stw_p(ptr, value);
+}
+
+static uint32_t subpage_ram_readl(void *opaque, target_phys_addr_t addr)
+{
+ ram_addr_t raddr = addr;
+ void *ptr = qemu_get_ram_ptr(raddr);
+ return ldl_p(ptr);
+}
+
+static void subpage_ram_writel(void *opaque, target_phys_addr_t addr,
+ uint32_t value)
+{
+ ram_addr_t raddr = addr;
+ void *ptr = qemu_get_ram_ptr(raddr);
+ stl_p(ptr, value);
+}
+
+static CPUReadMemoryFunc * const subpage_ram_read[] = {
+ &subpage_ram_readb,
+ &subpage_ram_readw,
+ &subpage_ram_readl,
+};
+
+static CPUWriteMemoryFunc * const subpage_ram_write[] = {
+ &subpage_ram_writeb,
+ &subpage_ram_writew,
+ &subpage_ram_writel,
+};
+
static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
ram_addr_t memory, ram_addr_t region_offset)
{
@@ -3583,8 +3640,9 @@ static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
printf("%s: %p start %08x end %08x idx %08x eidx %08x mem %ld\n", __func__,
mmio, start, end, idx, eidx, memory);
#endif
- if ((memory & ~TARGET_PAGE_MASK) == IO_MEM_RAM)
- memory = IO_MEM_UNASSIGNED;
+ if ((memory & ~TARGET_PAGE_MASK) == IO_MEM_RAM) {
+ memory = IO_MEM_SUBPAGE_RAM;
+ }
memory = (memory >> IO_MEM_SHIFT) & (IO_MEM_NB_ENTRIES - 1);
for (; idx <= eidx; idx++) {
mmio->sub_io_index[idx] = memory;
@@ -3817,6 +3875,9 @@ static void io_mem_init(void)
cpu_register_io_memory_fixed(IO_MEM_NOTDIRTY, error_mem_read,
notdirty_mem_write, NULL,
DEVICE_NATIVE_ENDIAN);
+ cpu_register_io_memory_fixed(IO_MEM_SUBPAGE_RAM, subpage_ram_read,
+ subpage_ram_write, NULL,
+ DEVICE_NATIVE_ENDIAN);
for (i=0; i<5; i++)
io_mem_used[i] = 1;
--
1.7.7
^ permalink raw reply related
* [xen-unstable test] 10190: tolerable FAIL - PUSHED
From: xen.org @ 2011-11-30 15:26 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 10190 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10190/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-i386-xl-win7-amd64 7 windows-install fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail never pass
test-amd64-amd64-xl-winxpsp3 7 windows-install fail never pass
test-amd64-i386-xend-winxpsp3 7 windows-install fail never pass
test-amd64-amd64-xl-win7-amd64 7 windows-install fail never pass
test-i386-i386-xl-winxpsp3 7 windows-install fail never pass
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass
test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-i386-i386-win 14 guest-start.2 fail like 10189
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-i386-i386-xl-win 13 guest-stop fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
version targeted for testing:
xen 64088ba60263
baseline version:
xen df7cec2c6c03
------------------------------------------------------------
People who touched revisions under test:
Haitao Shan <maillists.shan@gmail.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson.citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
test-i386-i386-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable
+ revision=64088ba60263
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readconfigonly();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 64088ba60263
+ branch=xen-unstable
+ revision=64088ba60263
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readconfigonly();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 64088ba60263 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
^ permalink raw reply
* suspend broken with macbookpro2,2 with the current Mainline
From: Justin P. Mattock @ 2011-11-30 15:24 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-pm, rjw
I seem to be hitting an issue with suspend on the current mainline.
basically once I close the lid everything seems to work, even waking
up(opening the lid), but if I close the lid and go to work I come back
to my machine off(shutdown) after a few hours of being suspended.
last good kernel I have is:
3.0.0-13-generic
which is ubuntus generic kernel. I am in the process of starting a
bisect but will take some time due to complete. if anybody is seeing
this, and knows a fix let me know.
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH] dmaengine/ste_dma40: allow fixed physical channel
From: Linus Walleij @ 2011-11-30 15:24 UTC (permalink / raw)
To: Narayanan G; +Cc: linux-kernel, Vinod Koul, linus.walleij, Rabin Vincent
In-Reply-To: <1322661042-18645-1-git-send-email-narayanan.gopalakrishnan@stericsson.com>
On Wed, Nov 30, 2011 at 2:50 PM, Narayanan G
<narayanan.gopalakrishnan@stericsson.com> wrote:
> Allow logical channels to specify the physical channel they want to use.
> This is needed to avoid two peripherals operating on the same physical
> channel during some special use-cases. (like mmc and usb during a
> usb mass storage case).
>
> Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
> Signed-off-by: Narayanan G <narayanan.gopalakrishnan@stericsson.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
(I reviewed and provided feedback some time ago, I'm likely blind for
any remaining issues.)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2 v3] pinctrl: make a copy of pinmux map
From: Linus Walleij @ 2011-11-30 15:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, linux-kernel, Stephen Warren, Grant Likely,
Barry Song, Shawn Guo, Thomas Abraham, Dong Aisheng,
Rajendra Nayak, Haojian Zhuang
In-Reply-To: <201111301330.09043.arnd.bergmann@linaro.org>
On Wed, Nov 30, 2011 at 2:30 PM, Arnd Bergmann <arnd.bergmann@linaro.org> wrote:
> Reviewed-by: Arnd Bergmann <arnd@linaro.org>
Thanks!
>> + int ret = 0;
(...)
>
> A trick pointed out by Rusty Russell in a recent blog post [1] is to
> not initialize the return value initially, but always set it only
> in the error path so that the compiler can warn you when you ever
> forget setting it in one path.
Clever! I do away with ret altogether in the next patch though,
so I'll remember this another time. Maybe even something for
checkpatch to react on...
Yours,
Linus Walleij
^ 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.