RE: [PATCH] da8xx: Allow use by am33xx based devices
On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote: Hi Vaibhav, On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote: On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote: Hi Tomi, On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote: Hi, On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote: This driver can be used for AM33xx devices, like the popular beaglebone. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/video/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9791d10..e7868d8 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2202,7 +2202,7 @@ config FB_SH7760 config FB_DA8XX tristate DA8xx/OMAP-L1xx Framebuffer support - depends on FB ARCH_DAVINCI_DA8XX + depends on FB (ARCH_DAVINCI_DA8XX || SOC_AM33XX) Agreed this is present on da8xx and am33xx, but moving forward for supporting DT, we should be avoiding these dependencies. So instead change this to remove machine dependencies. I could be wrong here, having dependency on platform seems to be right. Otherwise may lead to build errors for other platforms. No, it should not result in to build error unless driver uses some platform specific api's. Agreed, should not result in build error. But is it ok to show this option on the platforms which do not have this IP? You can choose to put machine dependency here, as this patch is already doing it. The side-effect of this would be, list may grow and you may have to edit this file everytime. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] AES instead of SHA1 for /dev/urandom
On Wed, Dec 12, 2012 at 01:08:26PM +1100, NeilBrown wrote: On Wed, 12 Dec 2012 03:03:54 +0100 Ondřej Bílka nel...@seznam.cz wrote: I consider to speed-up /dev/urandom on recent intel processors by using hardware aes. Same for accelerated aes crypto. Would you accept a patch if I wrote it? Have you read https://lwn.net/Articles/525459 ? Yes In particular the paragraph containing: A member of the audience asked why the kernel couldn't just do away with the existing system and use the HWRNG directly. Does that answer your question in any way? No as AES is a HWRNG about as much as horse is type of automobile. Ondra -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3] Support volatile range for anon vma
On Wed, Dec 12, 2012 at 02:43:49PM +0800, Wanpeng Li wrote: On Tue, Dec 11, 2012 at 11:41:04AM +0900, Minchan Kim wrote: Sorry, resending with fixing compile error. :( From 0cfd3b65e4e90ab59abe8a337334414f92423cad Mon Sep 17 00:00:00 2001 From: Minchan Kim minc...@kernel.org Date: Tue, 11 Dec 2012 11:38:30 +0900 Subject: [RFC v3] Support volatile range for anon vma This still is [RFC v3] because just passed my simple test with TCMalloc tweaking. I hope more inputs from user-space allocator people and test patch with their allocator because it might need design change of arena management design for getting real vaule. Changelog from v2 * Removing madvise(addr, length, MADV_NOVOLATILE). * add vmstat about the number of discarded volatile pages * discard volatile pages without promotion in reclaim path This is based on v3.6. - What's the madvise(addr, length, MADV_VOLATILE)? It's a hint that user deliver to kernel so kernel can *discard* pages in a range anytime. - What happens if user access page(ie, virtual address) discarded by kernel? The user can see zero-fill-on-demand pages as if madvise(DONTNEED). - What happens if user access page(ie, virtual address) doesn't discarded by kernel? The user can see old data without page fault. - What's different with madvise(DONTNEED)? System call semantic DONTNEED makes sure user always can see zero-fill pages after he calls madvise while VOLATILE can see zero-fill pages or old data. Internal implementation The madvise(DONTNEED) should zap all mapped pages in range so overhead is increased linearly with the number of mapped pages. Even, if user access zapped pages by write, page fault + page allocation + memset should be happened. The madvise(VOLATILE) should mark the flag in a range(ie, VMA). It doesn't touch pages any more so overhead of the system call should be very small. If memory pressure happens, VM can discard pages in VMAs marked by VOLATILE. If user access address with write mode by discarding by VM, he can see zero-fill pages so the cost is same with DONTNEED but if memory pressure isn't severe, user can see old data without (page fault + page allocation + memset) The VOLATILE mark should be removed in page fault handler when first page fault occur in marked vma so next page faults will follow normal page fault path. That's why user don't need madvise(MADV_NOVOLATILE) interface. - What's the benefit compared to DONTNEED? 1. The system call overhead is smaller because VOLATILE just marks the flag to VMA instead of zapping all the page in a range. 2. It has a chance to eliminate overheads (ex, page fault + page allocation + memset(PAGE_SIZE)). - Isn't there any drawback? DONTNEED doesn't need exclusive mmap_sem locking so concurrent page fault of other threads could be allowed. But VOLATILE needs exclusive mmap_sem so other thread would be blocked if they try to access not-mapped pages. That's why I designed madvise(VOLATILE)'s overhead should be small as far as possible. Other concern of exclusive mmap_sem is when page fault occur in VOLATILE marked vma. We should remove the flag of vma and merge adjacent vmas so needs exclusive mmap_sem. It can slow down page fault handling and prevent concurrent page fault. But we need such handling just once when page fault occur after we mark VOLATILE into VMA only if memory pressure happpens so the page is discarded. So it wouldn't not common so that benefit we get by this feature would be bigger than lose. - What's for targetting? Firstly, user-space allocator like ptmalloc, tcmalloc or heap management of virtual machine like Dalvik. Also, it comes in handy for embedded which doesn't have swap device so they can't reclaim anonymous pages. By discarding instead of swap, it could be used in the non-swap system. For it, we have to age anon lru list although we don't have swap because I don't want to discard volatile pages by top priority when memory pressure happens as volatile in this patch means We don't need to swap out because user can handle the situation which data are disappear suddenly, NOT They are useless so hurry up to reclaim them. So I want to apply same aging rule of nomal pages to them. Anonymous page background aging of non-swap system would be a trade-off for getting good feature. Even, we had done it two years ago until merge [1] and I believe gain of this patch will beat loss of anon lru aging's overead once all of allocator start to use madvise. (This patch doesn't include background aging in case of non-swap system but it's trivial if we decide) [1] 74e3f3c3, vmscan: prevent background aging of anon page in no swap system Cc: Michael Kerrisk mtk.manpa...@gmail.com Cc: Arun Sharma asha...@fb.com Cc: san...@google.com Cc: Paul
Re: [GIT PULL] thermal management updates for v3.8-rc1
Hi, Linus, On Wed, 2012-12-12 at 12:57 +0800, Zhang Rui wrote: Hi Linus, Please pull from the git repository at git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git release to receive thermal management updates for v3.8. sorry that I missed the latest two fixes. Please pull from the git repository at git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git release to receive thermal management updates for v3.8. Highlights: * Introduction of thermal policy support, together with three new thermal governors, including step_wise, user_space, fire_share. * Introduction of ST-Ericsson db8500_thermal driver and ST-Ericsson db8500_cpufreq_cooling driver. * Thermal Kconfig file and Makefile refactor. * Fixes for generic thermal layer, generic cpucooling, rcar thermal driver and Exynos thermal driver. thanks, rui The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git release Durgadoss R (16): Thermal: Refactor thermal.h file Thermal: Move thermal_instance to thermal_core.h Thermal: Add get trend, get instance API's to thermal_sys Thermal: Add platform level information to thermal.h Thermal: Pass zone parameters as argument to tzd_register Thermal: Add thermal governor registration APIs Thermal: Add a policy sysfs attribute Thermal: Update binding logic based on platform data Thermal: Make thermal_cdev_update as a global function Thermal: Introduce fair_share thermal governor Thermal: Introduce a step_wise thermal governor Thermal: Add a thermal notifier for user space Thermal: Remove throttling logic out of thermal_sys.c Thermal: Add a notification API Thermal: Add documentation for platform layer data Thermal: Provide option to choose default thermal governor Eduardo Valentin (2): thermal: cpu cooling: use const parameter while registering thermal: cpu cooling: allow module builds Hugh Dickins (1): Thermal: Fix oops and unlocking in thermal_sys.c Kuninori Morimoto (3): thermal: rcar_thermal: remove explicitly used devm_kfree/iounap() thermal: rcar: fixup the unit of temperature thermal: rcar: add rcar_zone_to_priv() macro Sachin Kamat (4): thermal: step_wise: Add missing static storage class specifiers thermal: fair_share: Add missing static storage class specifiers thermal: user_space: Add missing static storage class specifiers thermal: cpu_cooling: Make 'notify_device' static Zhang Rui (5): Refactor drivers/thermal/Kconfig Exynos: Add missing dependency drivers/thermal/Makefile refactor Thermal: fix a NULL pointer dereference when generic thermal layer is built as a module Thermal: Fix DEFAULT_THERMAL_GOVERNOR hongbo.zhang (5): Thermal: add indent for code alignment. Thermal: fix bug of counting cpu frequencies. Thermal: Remove the cooling_cpufreq_list. Thermal: Add ST-Ericsson DB8500 thermal driver. Thermal: Add ST-Ericsson DB8500 thermal properties and platform data. .../devicetree/bindings/thermal/db8500-thermal.txt | 44 ++ Documentation/thermal/sysfs-api.txt| 64 ++ arch/arm/boot/dts/dbx5x0.dtsi | 14 + arch/arm/boot/dts/snowball.dts | 31 + arch/arm/configs/u8500_defconfig |2 + arch/arm/mach-ux500/board-mop500.c | 64 ++ drivers/acpi/thermal.c |6 +- drivers/platform/x86/acerhdf.c |2 +- drivers/platform/x86/intel_mid_thermal.c |2 +- drivers/power/power_supply_core.c |2 +- drivers/staging/omap-thermal/omap-thermal-common.c |2 +- drivers/thermal/Kconfig| 82 +++- drivers/thermal/Makefile | 17 +- drivers/thermal/cpu_cooling.c | 107 +--- drivers/thermal/db8500_cpufreq_cooling.c | 108 +++ drivers/thermal/db8500_thermal.c | 531 +++ drivers/thermal/exynos_thermal.c |2 +- drivers/thermal/fair_share.c | 133 drivers/thermal/rcar_thermal.c | 27 +- drivers/thermal/spear_thermal.c|2 +- drivers/thermal/step_wise.c| 194 ++ drivers/thermal/thermal_core.h | 53 ++ drivers/thermal/thermal_sys.c | 701 +--- drivers/thermal/user_space.c | 68 ++ include/linux/cpu_cooling.h|6 +- include/linux/platform_data/db8500_thermal.h | 38 ++ include/linux/thermal.h| 134 +++- 27 files changed,
[PATCH] OMAP: add pwm driver using dmtimers.
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..7df573a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -85,6 +85,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP
+ tristate OMAP pwm support
+ depends on ARCH_OMAP
+ help
+ Generic PWM framework driver for OMAP
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-omap
+
config PWM_PUV3
tristate PKUnity NetBook-0916 PWM support
depends on ARCH_PUV3
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..f5d200d 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_OMAP) += pwm-omap.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
new file mode 100644
index 000..e3dbce3
--- /dev/null
+++ b/drivers/pwm/pwm-omap.c
@@ -0,0 +1,318 @@
+/*
+ *Copyright (c) 2012 NeilBrown ne...@suse.de
+ *Heavily based on earlier code which is:
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.com
+ *
+ *Also based on pwm-samsung.c
+ *
+ *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.
+ *
+ *Description:
+ * This file is the core OMAP2/3 support for the generic, Linux
+ * PWM driver / controller, using the OMAP's dual-mode timers.
+ *
+ *The 'id' number for the device encodes the number of the dm timer
+ *to use, and the polarity of the output.
+ *lsb is '1' of active-high, and '0' for active low
+ *remaining bit a timer number and need to be shifted down before use.
+ */
+
+#define pr_fmt(fmt) pwm-omap: fmt
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/module.h
+
+#include plat/dmtimer.h
+
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+struct omap_chip {
+ struct platform_device *pdev;
+
+ struct omap_dm_timer*dm_timer;
+ unsigned intpolarity;
+ const char *label;
+
+ unsigned intduty_ns, period_ns;
+ struct pwm_chip chip;
+};
+
+#define to_omap_chip(chip) container_of(chip, struct omap_chip, chip)
+
+#definepwm_dbg(_pwm, msg...) dev_dbg((_pwm)-pdev-dev, msg)
+
+/**
+ * pwm_calc_value - determines the counter value for a clock rate and period.
+ * @clk_rate: The clock rate, in Hz, of the PWM's clock source to compute the
+ *counter value for.
+ * @ns: The period, in nanoseconds, to computer the counter value for.
+ *
+ * Returns the PWM counter value for the specified clock rate and period.
+ */
+static inline int pwm_calc_value(unsigned long clk_rate, int ns)
+{
+ const unsigned long nanoseconds_per_second = 10;
+ int cycles;
+ __u64 c;
+
+ c = (__u64)clk_rate * ns;
+ do_div(c, nanoseconds_per_second);
+ cycles = c;
+
+ return DM_TIMER_LOAD_MIN - cycles;
+}
+
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
+
+ /* Enable the counter--always--before attempting to write its
+* registers and then set the timer to its minimum load value to
+* ensure we get an overflow event right away once we start it.
+*/
+
+ omap_dm_timer_enable(omap-dm_timer);
+ omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN);
+ omap_dm_timer_start(omap-dm_timer);
+ omap_dm_timer_disable(omap-dm_timer);
+
+ return status;
+}
+
+static void omap_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+
+ omap_dm_timer_stop(omap-dm_timer);
+}
+
+static int omap_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
+ const bool enable = true;
+ const bool autoreload = true;
+ const bool toggle = true;
+ const int trigger =
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v3 of the patch-set that solves issues pointed out by Enric Balletbo and Benoit Cousson. The patch-set is composed of the following patches: [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- Hi Benoit and Tony, Any comments on these? Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init
Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y
and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option,
system will boot fail.
This failure is caused by following code path:
setup_hugepagesz
hugetlb_add_hstate
hugetlb_cgroup_file_init
cgroup_add_cftypes
kzalloc --slab is *not available* yet
For this path, slab is not available yet, so memory allocated will be
failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
So I move hugetlb_cgroup_file_init() into hugetlb_init().
Signed-off-by: Jianguo Wu wujian...@huawei.com
Signed-off-by: Jiang Liu jiang@huawei.com
---
include/linux/hugetlb_cgroup.h |7 ++-
mm/hugetlb.c | 11 +--
mm/hugetlb_cgroup.c| 23 +--
3 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
index d73878c..5bb9c28 100644
--- a/include/linux/hugetlb_cgroup.h
+++ b/include/linux/hugetlb_cgroup.h
@@ -62,7 +62,7 @@ extern void hugetlb_cgroup_uncharge_page(int idx, unsigned
long nr_pages,
struct page *page);
extern void hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
struct hugetlb_cgroup *h_cg);
-extern int hugetlb_cgroup_file_init(int idx) __init;
+extern void hugetlb_cgroup_file_init(void) __init;
extern void hugetlb_cgroup_migrate(struct page *oldhpage,
struct page *newhpage);
@@ -111,10 +111,7 @@ hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long
nr_pages,
return;
}
-static inline int __init hugetlb_cgroup_file_init(int idx)
-{
- return 0;
-}
+static inline void __init hugetlb_cgroup_file_init() {}
static inline void hugetlb_cgroup_migrate(struct page *oldhpage,
struct page *newhpage)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 1ef2cd4..a30da48 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1906,14 +1906,12 @@ static int __init hugetlb_init(void)
default_hstate.max_huge_pages = default_hstate_max_huge_pages;
hugetlb_init_hstates();
-
gather_bootmem_prealloc();
-
report_hugepages();
hugetlb_sysfs_init();
-
hugetlb_register_all_nodes();
+ hugetlb_cgroup_file_init();
return 0;
}
@@ -1943,13 +1941,6 @@ void __init hugetlb_add_hstate(unsigned order)
h-next_nid_to_free = first_node(node_states[N_HIGH_MEMORY]);
snprintf(h-name, HSTATE_NAME_LEN, hugepages-%lukB,
huge_page_size(h)/1024);
- /*
-* Add cgroup control files only if the huge page consists
-* of more than two normal pages. This is because we use
-* page[2].lru.next for storing cgoup details.
-*/
- if (order = HUGETLB_CGROUP_MIN_ORDER)
- hugetlb_cgroup_file_init(hugetlb_max_hstate - 1);
parsed_hstate = h;
}
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index a3f358f..284cb68 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -340,7 +340,7 @@ static char *mem_fmt(char *buf, int size, unsigned long
hsize)
return buf;
}
-int __init hugetlb_cgroup_file_init(int idx)
+static void __init __hugetlb_cgroup_file_init(int idx)
{
char buf[32];
struct cftype *cft;
@@ -382,7 +382,26 @@ int __init hugetlb_cgroup_file_init(int idx)
WARN_ON(cgroup_add_cftypes(hugetlb_subsys, h-cgroup_files));
- return 0;
+ return;
+}
+
+void __init hugetlb_cgroup_file_init()
+{
+ struct hstate *h;
+ int idx;
+
+ idx = 0;
+ for_each_hstate(h) {
+ /*
+* Add cgroup control files only if the huge page consists
+* of more than two normal pages. This is because we use
+* page[2].lru.next for storing cgoup details.
+*/
+ if (h-order = HUGETLB_CGROUP_MIN_ORDER)
+ __hugetlb_cgroup_file_init(idx);
+
+ idx++;
+ }
}
/*
-- 1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block2mtd: throttle writes by calling balance_dirty_pages_ratelimited.
If you create a block2mtd device that is larger than main memory, and write to all of it, then lots of pages will be dirtied but they will never be flushed out as nothing calls any variant of balance_dirty_pages. It would be nice to call set_page_dirty_balance(), but that isn't exported, so just call balance_dirty_pages_ratelimited() directly. Signed-off-by: NeilBrown ne...@suse.de diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c index 681e2ee..2c3e8e7 100644 --- a/drivers/mtd/devices/block2mtd.c +++ b/drivers/mtd/devices/block2mtd.c @@ -62,6 +62,7 @@ static int _block2mtd_erase(struct block2mtd_dev *dev, loff_t to, size_t len) memset(page_address(page), 0xff, PAGE_SIZE); set_page_dirty(page); unlock_page(page); + balance_dirty_pages_ratelimited(mapping); break; } @@ -152,6 +153,7 @@ static int _block2mtd_write(struct block2mtd_dev *dev, const u_char *buf, memcpy(page_address(page) + offset, buf, cpylen); set_page_dirty(page); unlock_page(page); + balance_dirty_pages_ratelimited(mapping); } page_cache_release(page); signature.asc Description: PGP signature
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Wed, 2012-12-12 at 08:30 +0530, Viresh Kumar wrote: * It requires slave drivers to know that they are using the dw_dmac driver and pass a pointer to dw_generic_filter, which is not generic at all * It requires the dmac node to have information about all slaves There are also some minor issues, such as the naming of DT properties, but the above need to be resolved first. I saw the binding document and it looks it can be applied to dw_dmac too, as there is nothing special for it. The question is how? We are already late for merge window and this one is queued. Supplying a new patch, getting it reviewed/tested and being pulled by Linus is not so easy :) Two ways: - Keep it as is, and i will fix it separately and quickly - Drop it :( Will we survive if the patch is in mainline? I mean how big the impact of it is? -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] backlight: corgi_lcd: Use gpio_set_value_cansleep() to avoid WARN_ON
On Monday, December 10, 2012 5:18 PM, Jingoo Han wrote On Thursday, December 06, 2012 4:22 AM, Russell King - ARM Linux wrote On Wed, Dec 05, 2012 at 07:20:00PM +0100, Marko Katić wrote: On Wed, Dec 5, 2012 at 10:30 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Dec 05, 2012 at 09:59:07AM +0900, Jingoo Han wrote: ... Eric shares my opinion of the _cansleep() mess, but unfortunately it's what we have and no one's come up with any better solutions to it. (I argued from the outset that the gpio_xxx_cansleep() should've been gpio_xxx() and the non-cansleep() version should be called gpio_xxx_atomic() so that by default people use the version which _can_ sleep, but have to think about it when they want to manipulate GPIOs in non-task contexts.) Hi Russell, Thank you for your explanation. It is very helpful for getting hold of. I have been confused by the current function name such as gpio_xxx_cansleep(). As you mentioned, gpio_xxx_cansleep()and gpio_xxx_atomic() would be better. Oh, sorry. There is a mistake. It should be as below: 'gpio_xxx()and gpio_xxx_atomic() would be better'. Best regards, Jingoo Han -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Mon, 2012-12-10 at 22:08 +, Arnd Bergmann wrote: The build bug is not the problem however, but the abuse of the API is. Andy, are you sure you understood what this does when you gave you Reviewed-by comment? Thank you for pointing this out to refresh my memories and go through documentation again. -- Andy Shevchenko andriy.shevche...@linux.intel.com Intel Finland Oy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs
On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote: The problem is the possibility of denial-of-service attacks here. We can try to prevent them by: FWIW I already see a DoS 'attack'. I have some filestore shared using NFS (to Linux and Solaris) and using samba (to Windows). I use it for release builds of a product to ensure the versions built for the different operating systems match, and because some files have to be built on an 'alien' system (eg gcc targetted at embedded card). I can't run the windows build at the same time as the others because the windows C compiler manages to obtain exclusive access to the source files - stopping the other systems from reading them. David -- David Laight: da...@l8s.co.uk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3] Support volatile range for anon vma
On Wed, Dec 12, 2012 at 04:17:14PM +0800, Wanpeng Li wrote: On Wed, Dec 12, 2012 at 02:43:49PM +0800, Wanpeng Li wrote: On Tue, Dec 11, 2012 at 11:41:04AM +0900, Minchan Kim wrote: Sorry, resending with fixing compile error. :( From 0cfd3b65e4e90ab59abe8a337334414f92423cad Mon Sep 17 00:00:00 2001 From: Minchan Kim minc...@kernel.org Date: Tue, 11 Dec 2012 11:38:30 +0900 Subject: [RFC v3] Support volatile range for anon vma This still is [RFC v3] because just passed my simple test with TCMalloc tweaking. I hope more inputs from user-space allocator people and test patch with their allocator because it might need design change of arena management design for getting real vaule. Changelog from v2 * Removing madvise(addr, length, MADV_NOVOLATILE). * add vmstat about the number of discarded volatile pages * discard volatile pages without promotion in reclaim path This is based on v3.6. - What's the madvise(addr, length, MADV_VOLATILE)? It's a hint that user deliver to kernel so kernel can *discard* pages in a range anytime. - What happens if user access page(ie, virtual address) discarded by kernel? The user can see zero-fill-on-demand pages as if madvise(DONTNEED). - What happens if user access page(ie, virtual address) doesn't discarded by kernel? The user can see old data without page fault. - What's different with madvise(DONTNEED)? System call semantic DONTNEED makes sure user always can see zero-fill pages after he calls madvise while VOLATILE can see zero-fill pages or old data. Internal implementation The madvise(DONTNEED) should zap all mapped pages in range so overhead is increased linearly with the number of mapped pages. Even, if user access zapped pages by write, page fault + page allocation + memset should be happened. The madvise(VOLATILE) should mark the flag in a range(ie, VMA). It doesn't touch pages any more so overhead of the system call should be very small. If memory pressure happens, VM can discard pages in VMAs marked by VOLATILE. If user access address with write mode by discarding by VM, he can see zero-fill pages so the cost is same with DONTNEED but if memory pressure isn't severe, user can see old data without (page fault + page allocation + memset) The VOLATILE mark should be removed in page fault handler when first page fault occur in marked vma so next page faults will follow normal page fault path. That's why user don't need madvise(MADV_NOVOLATILE) interface. - What's the benefit compared to DONTNEED? 1. The system call overhead is smaller because VOLATILE just marks the flag to VMA instead of zapping all the page in a range. 2. It has a chance to eliminate overheads (ex, page fault + page allocation + memset(PAGE_SIZE)). - Isn't there any drawback? DONTNEED doesn't need exclusive mmap_sem locking so concurrent page fault of other threads could be allowed. But VOLATILE needs exclusive mmap_sem so other thread would be blocked if they try to access not-mapped pages. That's why I designed madvise(VOLATILE)'s overhead should be small as far as possible. Other concern of exclusive mmap_sem is when page fault occur in VOLATILE marked vma. We should remove the flag of vma and merge adjacent vmas so needs exclusive mmap_sem. It can slow down page fault handling and prevent concurrent page fault. But we need such handling just once when page fault occur after we mark VOLATILE into VMA only if memory pressure happpens so the page is discarded. So it wouldn't not common so that benefit we get by this feature would be bigger than lose. - What's for targetting? Firstly, user-space allocator like ptmalloc, tcmalloc or heap management of virtual machine like Dalvik. Also, it comes in handy for embedded which doesn't have swap device so they can't reclaim anonymous pages. By discarding instead of swap, it could be used in the non-swap system. For it, we have to age anon lru list although we don't have swap because I don't want to discard volatile pages by top priority when memory pressure happens as volatile in this patch means We don't need to swap out because user can handle the situation which data are disappear suddenly, NOT They are useless so hurry up to reclaim them. So I want to apply same aging rule of nomal pages to them. Anonymous page background aging of non-swap system would be a trade-off for getting good feature. Even, we had done it two years ago until merge [1] and I believe gain of this patch will beat loss of anon lru aging's overead once all of allocator start to use madvise. (This patch doesn't include background aging in case of non-swap system but it's trivial if we decide) [1] 74e3f3c3, vmscan: prevent background aging of anon page in no swap system Cc: Michael Kerrisk mtk.manpa...@gmail.com
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On 12 December 2012 14:10, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: Will we survive if the patch is in mainline? I mean how big the impact of it is? It doesn't fail to do fulfill its purpose and even ALL DT stuff would work well. Its just the matter of using the right API's, design and bindings :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] uio: do not expose inode to uio open/release hooks
On Tue, Dec 11, 2012 at 08:46:48PM -0800, Greg KH wrote: On Wed, Dec 12, 2012 at 02:42:22AM +0100, Hans J. Koch wrote: On Tue, Dec 11, 2012 at 03:20:32PM -0800, Greg KH wrote: On Wed, Dec 12, 2012 at 12:12:02AM +0100, Benedikt Spranger wrote: The inode parameter is unused by in kernel users of UIO. Ok. Also the inode parameter makes it hard to resolve the existing open(), mmap() and close() difficulty. I don't understand, what do you mean by this? What is this parameter causing problems with? The problem is that according to POSIX, it is guaranteed that in userspace you can do fd = open(/dev/uio0, ...) ptr = mmap(...fd...) close(fd) with ptr still being valid and useable after that. Yes, but what does that have to do with this in-kernel, internal api? Ah, OK. You're right, the commit message is confusing. Bene, it's enough to say we drop the inode parameter because nobody ever needed it. I cannot see why this also helps with the other problem. Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] spi: devicetree: add support for loopback mode
there are a few spi master drivers which make use of that flag but there is no way to pass it through devicetree. This patch just creates a way to pass SPI_LOOP via devicetree. Signed-off-by: Felipe Balbi ba...@ti.com --- Documentation/devicetree/bindings/spi/spi-bus.txt | 2 ++ drivers/spi/spi.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index 296015e..1949586 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -55,6 +55,8 @@ contain the following properties. chip select active high - spi-3wire - (optional) Empty property indicating device requires 3-wire mode. +- spi-loopback- (optional) Empty property indicating device requires + loopback mode. If a gpio chipselect is used for the SPI slave the gpio number will be passed via the cs_gpio diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 3f1b9ee..6bcdc03 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -868,6 +868,8 @@ static void of_register_spi_devices(struct spi_master *master) spi-mode |= SPI_CS_HIGH; if (of_find_property(nc, spi-3wire, NULL)) spi-mode |= SPI_3WIRE; + if (of_find_property(nc, spi-loopback, NULL)) + spi-mode |= SPI_LOOP; /* Device speed */ prop = of_get_property(nc, spi-max-frequency, len); -- 1.8.1.rc1.5.g7e0651a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] spi: omap2: disable DMA requests before complete()
No actual errors have been found for completing before disabling DMA request lines, but it just looks more semantically correct that on our DMA callback we quiesce the whole thing before stating transfer is finished. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/spi/spi-omap2-mcspi.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index b610f52..68446db 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -298,10 +298,10 @@ static void omap2_mcspi_rx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master); struct omap2_mcspi_dma *mcspi_dma = mcspi-dma_channels[spi-chip_select]; - complete(mcspi_dma-dma_rx_completion); - /* We must disable the DMA RX request */ omap2_mcspi_set_dma_req(spi, 1, 0); + + complete(mcspi_dma-dma_rx_completion); } static void omap2_mcspi_tx_callback(void *data) @@ -310,10 +310,10 @@ static void omap2_mcspi_tx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master); struct omap2_mcspi_dma *mcspi_dma = mcspi-dma_channels[spi-chip_select]; - complete(mcspi_dma-dma_tx_completion); - /* We must disable the DMA TX request */ omap2_mcspi_set_dma_req(spi, 0, 0); + + complete(mcspi_dma-dma_tx_completion); } static void omap2_mcspi_tx_dma(struct spi_device *spi, -- 1.8.1.rc1.5.g7e0651a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v2 3/6] memcg: rework mem_cgroup_iter to use cgroup iterators
On Tue 11-12-12 14:43:37, Ying Han wrote:
On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 11-12-12 16:50:25, Michal Hocko wrote:
On Sun 09-12-12 08:59:54, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
+ /*
+* Even if we found a group we have to make sure it is
alive.
+* css !memcg means that the groups should be
skipped and
+* we should continue the tree walk.
+* last_visited css is safe to use because it is
protected by
+* css_get and the tree walk is rcu safe.
+*/
+ if (css == root-css || (css css_tryget(css)))
+ memcg = mem_cgroup_from_css(css);
if (reclaim) {
- iter-position = id;
+ struct mem_cgroup *curr = memcg;
+
+ if (last_visited)
+ css_put(last_visited-css);
+
+ if (css !memcg)
+ curr = mem_cgroup_from_css(css);
In this case, the css_tryget() failed which implies the css is on the
way to be removed. (refcnt ==0) If so, why it is safe to call
css_get() directly on it below? It seems not preventing the css to be
removed by doing so.
Well, I do not remember exactly but I guess the code is meant to say
that we need to store a half-dead memcg because the loop has to be
retried. As we are under RCU hood it is just half dead.
Now that you brought this up I think this is not safe as well because
another thread could have seen the cached value while we tried to retry
and his RCU is not protecting the group anymore.
Hmm, thinking about it some more, it _is_ be safe in the end.
We are safe because we are under RCU. And even if somebody else looked
at the half-dead memcg from iter-last_visited it cannot disappear
because the current one will retry without dropping RCU so the grace
period couldn't have been finished.
CPU0CPU1
rcu_read_lock() rcu_read_lock()
while(!memcg) { while(!memcg)
[...]
spin_lock(iter-iter_lock)
[...]
if (css == root-css ||
(css css_tryget(css)))
memcg = mem_cgroup_from_css(css)
[...]
if (css !memcg)
curr = mem_cgroup_from_css(css)
if (curr)
css_get(curr);
spin_unlock(iter-iter_lock)
spin_lock(iter-iter_lock)
/* sees the half
dead memcg but its cgroup is still valid */
[...]
spin_unlock(iter-iter_lock)
/* we do retry */
}
rcu_read_unlock()
so the css_get will just helps to prevent from further code obfuscation.
Makes sense? The code gets much simplified later in the series,
fortunately.
My understanding on this is that we should never call css_get()
without calling css_tryget() and it succeed.
Hmm, what would be the point of using css_get then?
Whether or not it is *safe* to do so, that seems conflicts with the
assumption of the cgroup_rmdir().
I would rather make the change to do the retry after css_tryget()
failed. The patch I have on my local tree:
OK, I am not against, the retry is just nicer and that is the reason
I changed that in the follow up patch. Just note that this is an
intermediate patch and the code is changed significantly in the later
patches so the question is whether it is worth changing that.
This surely couldn't have caused your testing issue, right?
So I can refactor the two patches and move the retry from the later to
this one if you or anybody else really insist ;)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index f26..e2af02d 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -991,6 +991,7 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
*root,
while (!memcg) {
struct mem_cgroup_reclaim_iter *uninitialized_var(iter);
struct cgroup_subsys_state *css = NULL;
+ struct cgroup *prev_cgroup, *next_cgroup;
if (reclaim) {
int nid = zone_to_nid(reclaim-zone);
@@ -1018,10 +1019,9 @@ struct mem_cgroup *mem_cgroup_iter(struct
mem_cgroup *root,
if (!last_visited) {
css = root-css;
} else {
- struct cgroup *prev_cgroup, *next_cgroup;
-
prev_cgroup = (last_visited == root) ? NULL
: last_visited-css.cgroup;
+skip_node:
Re: [PATCH 2/2] uio: do not expose inode to uio open/release hooks
Am Wed, 12 Dec 2012 09:50:54 +0100 schrieb Hans J. Koch h...@hansjkoch.de: On Tue, Dec 11, 2012 at 08:46:48PM -0800, Greg KH wrote: Yes, but what does that have to do with this in-kernel, internal api? Ah, OK. You're right, the commit message is confusing. Bene, it's enough to say we drop the inode parameter because nobody ever needed it. I am fine with that. I cannot see why this also helps with the other problem. It would help, because we can defer calling the release hook until the last mmap user is gone. In this case the inode pointer may not be valid anymore. Regards Bene -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 3] ARM: plat-versatile: move secondary CPU startup into cpuinit
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the right section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana claudio.font...@huawei.com Tested-by: Claudio Fontana claudio.font...@huawei.com diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include linux/linkage.h #include linux/init.h - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] leds: leds-pwm: Add device tree bindings
On 12/11/2012 08:25 AM, Thierry Reding wrote:
+static const struct of_device_id of_pwm_leds_match[] = {
+{ .compatible = pwm-leds, },
+{},
+};
Doesn't this cause a compiler warning for !OF builds?
This is not causing any compiler warnings.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/7] leds: leds-pwm: Preparing the driver for device tree support
In order to be able to add device tree support for leds-pwm driver we need
to rearrange the data structures used by the drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/leds/leds-pwm.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 351257c..c767837 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -30,6 +30,11 @@ struct led_pwm_data {
unsigned intperiod;
};
+struct led_pwm_priv {
+ int num_leds;
+ struct led_pwm_data leds[0];
+};
+
static void led_pwm_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
@@ -47,25 +52,29 @@ static void led_pwm_set(struct led_classdev *led_cdev,
}
}
+static inline size_t sizeof_pwm_leds_priv(int num_leds)
+{
+ return sizeof(struct led_pwm_priv) +
+ (sizeof(struct led_pwm_data) * num_leds);
+}
+
static int led_pwm_probe(struct platform_device *pdev)
{
struct led_pwm_platform_data *pdata = pdev-dev.platform_data;
- struct led_pwm *cur_led;
- struct led_pwm_data *leds_data, *led_dat;
+ struct led_pwm_priv *priv;
int i, ret = 0;
if (!pdata)
return -EBUSY;
- leds_data = devm_kzalloc(pdev-dev,
- sizeof(struct led_pwm_data) * pdata-num_leds,
- GFP_KERNEL);
- if (!leds_data)
+ priv = devm_kzalloc(pdev-dev, sizeof_pwm_leds_priv(pdata-num_leds),
+ GFP_KERNEL);
+ if (!priv)
return -ENOMEM;
for (i = 0; i pdata-num_leds; i++) {
- cur_led = pdata-leds[i];
- led_dat = leds_data[i];
+ struct led_pwm *cur_led = pdata-leds[i];
+ struct led_pwm_data *led_dat = priv-leds[i];
led_dat-pwm = devm_pwm_get(pdev-dev, cur_led-name);
if (IS_ERR(led_dat-pwm)) {
@@ -88,15 +97,16 @@ static int led_pwm_probe(struct platform_device *pdev)
if (ret 0)
goto err;
}
+ priv-num_leds = pdata-num_leds;
- platform_set_drvdata(pdev, leds_data);
+ platform_set_drvdata(pdev, priv);
return 0;
err:
if (i 0) {
for (i = i - 1; i = 0; i--)
- led_classdev_unregister(leds_data[i].cdev);
+ led_classdev_unregister(priv-leds[i].cdev);
}
return ret;
@@ -104,14 +114,11 @@ err:
static int led_pwm_remove(struct platform_device *pdev)
{
+ struct led_pwm_priv *priv = platform_get_drvdata(pdev);
int i;
- struct led_pwm_platform_data *pdata = pdev-dev.platform_data;
- struct led_pwm_data *leds_data;
-
- leds_data = platform_get_drvdata(pdev);
- for (i = 0; i pdata-num_leds; i++)
- led_classdev_unregister(leds_data[i].cdev);
+ for (i = 0; i priv-num_leds; i++)
+ led_classdev_unregister(priv-leds[i].cdev);
return 0;
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/7] leds: leds-pwm: Convert to use devm_get_pwm
Update the driver to use the new API for requesting pwm so we can take
advantage of the pwm_lookup table to find the correct pwm to be used for the
LED functionality.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/leds/leds-pwm.c | 19 ++-
include/linux/leds_pwm.h | 2 +-
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 2157524..351257c 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -67,12 +67,11 @@ static int led_pwm_probe(struct platform_device *pdev)
cur_led = pdata-leds[i];
led_dat = leds_data[i];
- led_dat-pwm = pwm_request(cur_led-pwm_id,
- cur_led-name);
+ led_dat-pwm = devm_pwm_get(pdev-dev, cur_led-name);
if (IS_ERR(led_dat-pwm)) {
ret = PTR_ERR(led_dat-pwm);
- dev_err(pdev-dev, unable to request PWM %d\n,
- cur_led-pwm_id);
+ dev_err(pdev-dev, unable to request PWM for %s\n,
+ cur_led-name);
goto err;
}
@@ -86,10 +85,8 @@ static int led_pwm_probe(struct platform_device *pdev)
led_dat-cdev.flags |= LED_CORE_SUSPENDRESUME;
ret = led_classdev_register(pdev-dev, led_dat-cdev);
- if (ret 0) {
- pwm_free(led_dat-pwm);
+ if (ret 0)
goto err;
- }
}
platform_set_drvdata(pdev, leds_data);
@@ -98,10 +95,8 @@ static int led_pwm_probe(struct platform_device *pdev)
err:
if (i 0) {
- for (i = i - 1; i = 0; i--) {
+ for (i = i - 1; i = 0; i--)
led_classdev_unregister(leds_data[i].cdev);
- pwm_free(leds_data[i].pwm);
- }
}
return ret;
@@ -115,10 +110,8 @@ static int led_pwm_remove(struct platform_device *pdev)
leds_data = platform_get_drvdata(pdev);
- for (i = 0; i pdata-num_leds; i++) {
+ for (i = 0; i pdata-num_leds; i++)
led_classdev_unregister(leds_data[i].cdev);
- pwm_free(leds_data[i].pwm);
- }
return 0;
}
diff --git a/include/linux/leds_pwm.h b/include/linux/leds_pwm.h
index 33a0711..a65e964 100644
--- a/include/linux/leds_pwm.h
+++ b/include/linux/leds_pwm.h
@@ -7,7 +7,7 @@
struct led_pwm {
const char *name;
const char *default_trigger;
- unsignedpwm_id;
+ unsignedpwm_id __deprecated;
u8 active_low;
unsignedmax_brightness;
unsignedpwm_period_ns;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/7] leds: leds-pwm: Device tree support
Hello, Changes since v3: Addressed comments from Thierry Redding: - DT binding documentation for leds-pwm updated - of_pwm_request() renamed as of_pwm_get() - introduction of devm_of_pwm_get() - Commit message updates - Other comments has been also addressed - Acked-by from Grant is not added to the patches since they were modified since v3 Changes since v2: - rebased on top of linux-next - DT bindings now alligned with Grant's request - exporting of_pwm_request() from PWM core to allow clean DT bindings - DT binding documentation changed to reflect the changes Changes since v1: - As suggested by Bryan Wu: the legacy pwm_request() has been removed from patch 1 - Device tree bindings added for leds-pwm driver. When we boot with Device tree we handle one LED per device to be more aligned with PWM core's DT implementation. An example of the DT usage is provided in the new DT binding documentation for leds-pwm. Tested on OMAP4 Blaze (SDP), BeagleBoard with legacy and DT boot. On Zoom2 with legacy boot. Regards, Peter --- Peter Ujfalusi (7): leds: leds-pwm: Convert to use devm_get_pwm leds: leds-pwm: Preparing the driver for device tree support pwm: Correct parameter name in header for *pwm_get() functions pwm: core: Rename of_pwm_request() to of_pwm_get() and export it pwm: Add devm_of_pwm_get() as exported API for users leds: leds-pwm: Simplify cleanup code leds: leds-pwm: Add device tree bindings .../devicetree/bindings/leds/leds-pwm.txt | 48 +++ drivers/leds/leds-pwm.c| 152 +++-- drivers/pwm/core.c | 38 +- include/linux/leds_pwm.h | 2 +- include/linux/pwm.h| 20 ++- 5 files changed, 212 insertions(+), 48 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm.txt -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/7] pwm: core: Rename of_pwm_request() to of_pwm_get() and export it
Allow client driver to use of_pwm_get() to get the PWM they need. This
is needed for drivers which handle more than one PWM separately, like
leds-pwm driver, which have:
pwmleds {
compatible = pwm-leds;
kpad {
label = omap4::keypad;
pwms = twl_pwm 0 7812500;
max-brightness = 127;
};
charging {
label = omap4:green:chrg;
pwms = twl_pwmled 0 7812500;
max-brightness = 255;
};
};
in the dts files.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/core.c | 8
include/linux/pwm.h | 7 +++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 903138b..3cb741d 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -471,7 +471,7 @@ static struct pwm_chip *of_node_to_pwmchip(struct
device_node *np)
}
/**
- * of_pwm_request() - request a PWM via the PWM framework
+ * of_pwm_get() - request a PWM via the PWM framework
* @np: device node to get the PWM from
* @con_id: consumer name
*
@@ -486,8 +486,7 @@ static struct pwm_chip *of_node_to_pwmchip(struct
device_node *np)
* becomes mandatory for devices that look up the PWM device via the con_id
* parameter.
*/
-static struct pwm_device *of_pwm_request(struct device_node *np,
-const char *con_id)
+struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id)
{
struct pwm_device *pwm = NULL;
struct of_phandle_args args;
@@ -545,6 +544,7 @@ put:
return pwm;
}
+EXPORT_SYMBOL_GPL(of_pwm_get);
/**
* pwm_add_table() - register PWM device consumers
@@ -587,7 +587,7 @@ struct pwm_device *pwm_get(struct device *dev, const char
*con_id)
/* look up via DT first */
if (IS_ENABLED(CONFIG_OF) dev dev-of_node)
- return of_pwm_request(dev-of_node, con_id);
+ return of_pwm_get(dev-of_node, con_id);
/*
* We look up the provider in the static table typically provided by
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index cc908a5..76a1959 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -175,6 +175,7 @@ struct pwm_device *of_pwm_xlate_with_flags(struct pwm_chip
*pc,
const struct of_phandle_args *args);
struct pwm_device *pwm_get(struct device *dev, const char *con_id);
+struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id);
void pwm_put(struct pwm_device *pwm);
struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id);
@@ -213,6 +214,12 @@ static inline struct pwm_device *pwm_get(struct device
*dev,
return ERR_PTR(-ENODEV);
}
+static inline struct pwm_device *of_pwm_get(struct device_node *np,
+ const char *con_id)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void pwm_put(struct pwm_device *pwm)
{
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v2 3/6] memcg: rework mem_cgroup_iter to use cgroup iterators
On Tue 11-12-12 14:36:10, Ying Han wrote:
On Tue, Dec 11, 2012 at 7:54 AM, Michal Hocko mho...@suse.cz wrote:
On Sun 09-12-12 11:39:50, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
if (reclaim) {
- iter-position = id;
+ struct mem_cgroup *curr = memcg;
+
+ if (last_visited)
+ css_put(last_visited-css);
^^^
here
+
+ if (css !memcg)
+ curr = mem_cgroup_from_css(css);
+
+ /* make sure that the cached memcg is not
removed */
+ if (curr)
+ css_get(curr-css);
+ iter-last_visited = curr;
Here we take extra refcnt for last_visited, and assume it is under
target reclaim which then calls mem_cgroup_iter_break() and we leaked
a refcnt of the target memcg css.
I think you are not right here. The extra reference is kept for
iter-last_visited and it will be dropped the next time somebody sees
the same zone-priority iter. See above.
Or have I missed your question?
Hmm, question remains.
My understanding of the mem_cgroup_iter() is that each call path
should close the loop itself, in the sense that no *leaked* css refcnt
after that loop finished. It is the case for all the caller today
where the loop terminates at memcg == NULL, where all the refcnt have
been dropped by then.
Now I am not sure I understand you. mem_cgroup_iter_break will always
drop the reference of the last returned memcg. So far so good. But if
the last memcg got cached in per-zone-priority last_visited then we
_have_ to keep a reference to it regardless we broke out of the loop.
The last_visited thingy is shared between all parallel reclaimers so we
cannot just drop a reference to it.
One exception is mem_cgroup_iter_break(), where the loop terminates
with *leaked* refcnt and that is what the iter_break() needs to clean
up. We can not rely on the next caller of the loop since it might
never happen.
Yes, this is true and I already have a half baked patch for that. I
haven't posted it yet but it basically checks all node-zone-prio
last_visited and removes itself from them on the way out in pre_destroy
callback (I just need to cleanup find a new last_visited part and will
post it).
It makes sense to drop the refcnt of last_visited, the same reason as
drop refcnt of prev. I don't see why it makes different.
Because then it might vanish when somebody else wants to access it. If
we just did mem_cgroup_get which would be enough to keep only memcg part
in memory then what can we do at the time we visit it? css_tryget would
tell us no your buddy is gone, you do not have any links to the tree
so you would need to start from the beginning. That is what I have
implemented in the first version. Then I've realized that this could
make a bigger pressure on the groups created earlier which doesn't seem
to be right. With css pinning we are sure that there is a link to a next
node in the tree.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/7] pwm: Correct parameter name in header for *pwm_get() functions
To synchronize the header file definition and the actual code. In the code the consumer parameter is named as con_id, change the header file and replace consumer - con_id in the parameter list. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- include/linux/pwm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/pwm.h b/include/linux/pwm.h index 6d661f3..cc908a5 100644 --- a/include/linux/pwm.h +++ b/include/linux/pwm.h @@ -174,10 +174,10 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip, struct pwm_device *of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args); -struct pwm_device *pwm_get(struct device *dev, const char *consumer); +struct pwm_device *pwm_get(struct device *dev, const char *con_id); void pwm_put(struct pwm_device *pwm); -struct pwm_device *devm_pwm_get(struct device *dev, const char *consumer); +struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id); void devm_pwm_put(struct device *dev, struct pwm_device *pwm); #else static inline int pwm_set_chip_data(struct pwm_device *pwm, void *data) -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 5/7] pwm: Add devm_of_pwm_get() as exported API for users
When booted with DT users can use devm version of of_pwm_get() to benefit
from automatic resource release.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/pwm/core.c | 30 ++
include/linux/pwm.h | 9 +
2 files changed, 39 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 3cb741d..4a13da4 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -708,6 +708,36 @@ struct pwm_device *devm_pwm_get(struct device *dev, const
char *con_id)
}
EXPORT_SYMBOL_GPL(devm_pwm_get);
+/**
+ * devm_of_pwm_get() - resource managed of_pwm_get()
+ * @dev: device for PWM consumer
+ * @np: device node to get the PWM from
+ * @con_id: consumer name
+ *
+ * This function performs like of_pwm_get() but the acquired PWM device will
+ * automatically be released on driver detach.
+ */
+struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
+ const char *con_id)
+{
+ struct pwm_device **ptr, *pwm;
+
+ ptr = devres_alloc(devm_pwm_release, sizeof(**ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ pwm = of_pwm_get(np, con_id);
+ if (!IS_ERR(pwm)) {
+ *ptr = pwm;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return pwm;
+}
+EXPORT_SYMBOL_GPL(devm_of_pwm_get);
+
static int devm_pwm_match(struct device *dev, void *res, void *data)
{
struct pwm_device **p = res;
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 76a1959..70655a2 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -179,6 +179,8 @@ struct pwm_device *of_pwm_get(struct device_node *np, const
char *con_id);
void pwm_put(struct pwm_device *pwm);
struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id);
+struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
+ const char *con_id);
void devm_pwm_put(struct device *dev, struct pwm_device *pwm);
#else
static inline int pwm_set_chip_data(struct pwm_device *pwm, void *data)
@@ -230,6 +232,13 @@ static inline struct pwm_device *devm_pwm_get(struct
device *dev,
return ERR_PTR(-ENODEV);
}
+static inline struct pwm_device *devm_of_pwm_get(struct device *dev,
+struct device_node *np,
+const char *con_id)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
{
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 6/7] leds: leds-pwm: Simplify cleanup code
The code looks more nicer if we use:
while (i--)
instead:
if (i 0)
for (i = i - 1; i = 0; i--)
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/leds/leds-pwm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index c767837..46f4e44 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -104,10 +104,8 @@ static int led_pwm_probe(struct platform_device *pdev)
return 0;
err:
- if (i 0) {
- for (i = i - 1; i = 0; i--)
- led_classdev_unregister(priv-leds[i].cdev);
- }
+ while (i--)
+ led_classdev_unregister(priv-leds[i].cdev);
return ret;
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] AES instead of SHA1 for /dev/urandom
On Wed, 12 Dec 2012 09:58:16 +0100 Ondřej Bílka nel...@seznam.cz wrote: On Wed, Dec 12, 2012 at 01:08:26PM +1100, NeilBrown wrote: On Wed, 12 Dec 2012 03:03:54 +0100 Ondřej Bílka nel...@seznam.cz wrote: I consider to speed-up /dev/urandom on recent intel processors by using hardware aes. Same for accelerated aes crypto. Would you accept a patch if I wrote it? Have you read https://lwn.net/Articles/525459 ? Yes In particular the paragraph containing: A member of the audience asked why the kernel couldn't just do away with the existing system and use the HWRNG directly. Does that answer your question in any way? No as AES is a HWRNG about as much as horse is type of automobile. Yes, of course. Thanks. NeilBrown signature.asc Description: PGP signature
Re: [PATCH v3 3/5] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes
On 12/12/2012 08:49 AM, Jiang Liu wrote: This patch introduces a new array zone_movable_limit[] to store the ZONE_MOVABLE limit from movablecore_map boot option for all nodes. The function sanitize_zone_movable_limit() will find out to which node the ranges in movable_map.map[] belongs, and calculates the low boundary of ZONE_MOVABLE for each node. What's the difference between zone_movable_limit[nid] and zone_movable_pfn[nid]? zone_movable_limit[] is a temporary storage for zone_moveable_pfn[]. It's used to handle a special case if user specifies both movablecore_map and movablecore/kernelcore on the kernel command line. Hi Simon, Liu, Sorry for the late and thanks for your discussion. :) As Liu said, zone_movable_limit[] is a temporary array for calculation. If users specified movablecore_map option, zone_movable_limit[] holds the lowest pfn of ZONE_MOVABLE limited by movablecore_map option. It is constant, won't change. Please refer to find_zone_movable_pfns_for_nodes() in patch4, you will see that zone_moveable_pfn[] will be changed each time kernel area increases. So when kernel area increases on node i, zone_moveable_pfn[i] will increase. And if zone_moveable_pfn[i] zone_movable_limit[i], we should stop allocate memory for kernel on node i. Here, I give movablecore_map higher priority than kernelcore/movablecore. And also, I tried to use zone_moveable_pfn[] to store limits. But when calculating the kernel area, I still have to store the limits in temporary variables. I think the code was ugly. So I added an new array. Thanks. :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 7/7] leds: leds-pwm: Add device tree bindings
Support for device tree booted kernel.
For usage see:
Documentation/devicetree/bindings/leds/leds-pwm.txt
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
.../devicetree/bindings/leds/leds-pwm.txt | 48 +
drivers/leds/leds-pwm.c| 112 +
2 files changed, 140 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt
b/Documentation/devicetree/bindings/leds/leds-pwm.txt
new file mode 100644
index 000..7297107
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt
@@ -0,0 +1,48 @@
+LED connected to PWM
+
+Required properties:
+- compatible : should be pwm-leds.
+
+Each LED is represented as a sub-node of the pwm-leds device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+- pwms : PWM property to point to the PWM device (phandle)/port (id) and to
+ specify the period time to be used: phandle id period_ns;
+- pwm-names : (optional) Name to be used by the PWM subsystem for the PWM
device
+ For the pwms and pwm-names property please refer to:
+ Documentation/devicetree/bindings/pwm/pwm.txt
+- max-brightness : Maximum brightness possible for the LED
+- label : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+twl_pwm: pwm {
+ /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
+ compatible = ti,twl6030-pwm;
+ #pwm-cells = 2;
+};
+
+twl_pwmled: pwmled {
+ /* provides one PWM (id 0 for Charing indicator LED) */
+ compatible = ti,twl6030-pwmled;
+ #pwm-cells = 2;
+};
+
+pwmleds {
+ compatible = pwm-leds;
+ kpad {
+ label = omap4::keypad;
+ pwms = twl_pwm 0 7812500;
+ max-brightness = 127;
+ };
+
+ charging {
+ label = omap4:green:chrg;
+ pwms = twl_pwmled 0 7812500;
+ max-brightness = 255;
+ };
+};
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 46f4e44..a1ea5f6 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -16,6 +16,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
+#include linux/of_platform.h
#include linux/fb.h
#include linux/leds.h
#include linux/err.h
@@ -58,46 +59,110 @@ static inline size_t sizeof_pwm_leds_priv(int num_leds)
(sizeof(struct led_pwm_data) * num_leds);
}
-static int led_pwm_probe(struct platform_device *pdev)
+static struct led_pwm_priv *led_pwm_create_of(struct platform_device *pdev)
{
- struct led_pwm_platform_data *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *child;
struct led_pwm_priv *priv;
- int i, ret = 0;
+ int count, ret;
- if (!pdata)
- return -EBUSY;
+ /* count LEDs in this device, so we know how much to allocate */
+ count = of_get_child_count(node);
+ if (!count)
+ return NULL;
- priv = devm_kzalloc(pdev-dev, sizeof_pwm_leds_priv(pdata-num_leds),
+ priv = devm_kzalloc(pdev-dev, sizeof_pwm_leds_priv(count),
GFP_KERNEL);
if (!priv)
- return -ENOMEM;
+ return NULL;
- for (i = 0; i pdata-num_leds; i++) {
- struct led_pwm *cur_led = pdata-leds[i];
- struct led_pwm_data *led_dat = priv-leds[i];
+ for_each_child_of_node(node, child) {
+ struct led_pwm_data *led_dat = priv-leds[priv-num_leds];
- led_dat-pwm = devm_pwm_get(pdev-dev, cur_led-name);
+ led_dat-cdev.name = of_get_property(child, label,
+NULL) ? : child-name;
+
+ led_dat-pwm = devm_of_pwm_get(pdev-dev, child, NULL);
if (IS_ERR(led_dat-pwm)) {
- ret = PTR_ERR(led_dat-pwm);
dev_err(pdev-dev, unable to request PWM for %s\n,
- cur_led-name);
+ led_dat-cdev.name);
goto err;
}
+ /* Get the period from PWM core when n*/
+ led_dat-period = pwm_get_period(led_dat-pwm);
+
+ led_dat-cdev.default_trigger = of_get_property(child,
+ linux,default-trigger, NULL);
+ of_property_read_u32(child, max-brightness,
+led_dat-cdev.max_brightness);
- led_dat-cdev.name = cur_led-name;
- led_dat-cdev.default_trigger = cur_led-default_trigger;
- led_dat-active_low = cur_led-active_low;
-
Re: [RFC] dynamic_debug: introduce debug_hex_dump()
On Tuesday, December 11, 2012 02:55:55 PM Luis R. Rodriguez wrote:
Vladimir, to be clear, you can continue with waiting for the patches
to get into 3.9 but that will take a while but given that you want
your driver in 3.8 you can fold those routines into your driver as
you had before but with a rename by adding a prefix and sumbit that
driver and specify it is for 3.8.
I have internally patch that will compensate not merged yet functionality,
without any rename, see below. I can massage commit message and include it
with my driver as separate patch to be easier to undo later.
Comments?
From c4e7254d0cba51c8b43d36a317a1b847fffb18d8 Mon Sep 17 00:00:00 2001
From: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com
Date: Wed, 21 Nov 2012 13:57:21 +0200
Subject: [PATCH] [DEBUG] Allow to compile with mainstream kernel
Unless patch for dynamic hexdump merged into mainstream kernel,
need to provide replacement for the dynamic hexdump functionality
Do not hurt compilation with kernel that have patch above merged.
REMOVE when dynamic hexdump merged into mainstream kernel!!
Change-Id: I6abb8f91ed529ffc84bd9cc21444a59ee15fe456
---
dbg_hexdump.h | 32
wil6210.h |2 ++
2 files changed, 34 insertions(+)
create mode 100644 dbg_hexdump.h
diff --git a/dbg_hexdump.h b/dbg_hexdump.h
new file mode 100644
index 000..7144eed
--- /dev/null
+++ b/dbg_hexdump.h
@@ -0,0 +1,32 @@
+#ifndef DBG_HEXDUMP_H_
+#define DBG_HEXDUMP_H_
+
+#if !defined(print_hex_dump_debug)
+#if defined(CONFIG_DYNAMIC_DEBUG)
+#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+do { \
+ DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, \
+ __builtin_constant_p(prefix_str) ? prefix_str : hexdump);\
+ if (unlikely(descriptor.flags _DPRINTK_FLAGS_PRINT)) \
+ print_hex_dump(KERN_DEBUG, prefix_str, \
+ prefix_type, rowsize, groupsize, \
+ buf, len, ascii);\
+} while (0)
+
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+ dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)
+
+#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
+ dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
+#else /* defined(CONFIG_DYNAMIC_DEBUG) */
+#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
+groupsize, buf, len, ascii)\
+ print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, rowsize,\
+ groupsize, buf, len, ascii)
+#endif /* defined(CONFIG_DYNAMIC_DEBUG) */
+#endif /* !defined(print_hex_dump_debug) */
+
+#endif /* DBG_HEXDUMP_H_ */
diff --git a/wil6210.h b/wil6210.h
index b37c3d2..4797da0 100644
--- a/wil6210.h
+++ b/wil6210.h
@@ -21,6 +21,8 @@
#include linux/wireless.h
#include net/cfg80211.h
+#include dbg_hexdump.h
+
#define WIL_NAME wil6210
/**
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4 v2] gpio/mvebu: convert to use irq_domain_add_simple()
Dear Linus Walleij, On Wed, 12 Dec 2012 08:56:03 +0100, Linus Walleij wrote: Unfortunately, this creates the following warning at boot time for each GPIO bank: Grant has a patch in his irqdomain tree that will turn this warning into a simple pr_info() thing instead. It's not that bad... The immediate problem will soon go away. Ok. Of course, the fix should be to remove the irq_alloc_descs() from the driver prior to calling irq_domain_add_simple(). But the thing is that our gpio-mvebu driver uses the irq_alloc_generic_chip()/irq_setup_generic_chip() infrastructure, which it seems requires a legacy IRQ domain (it needs the base IRQ number). Actually it looks like a core infrastructure issue. Sorry for not spotting this in the first place: First you allocate some descriptors, just any descriptors, with mvchip-irqbase = irq_alloc_descs(-1, 0, ngpios, -1); Then you allocate a generic chip using the obtained descriptor base: gc = irq_alloc_generic_chip(mvebu_gpio_irq, 2, mvchip-irqbase, mvchip-membase, handle_level_irq); Then you set up the generic chip with a nailed down IRQ base number from step 1: irq_setup_generic_chip(gc, IRQ_MSK(ngpios), 0, IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE); This, if I understand it correctly, is done because you have two different chip types on the generic chip: one for high/low level IRQ and another for rising/falling. (Which is a very nice way to use the generic chip!) Finally set up the IRQ domain: mvchip-domain = irq_domain_add_simple(np, mvchip-chip.ngpio, mvchip-irqbase, irq_domain_simple_ops, mvchip); So the problem is that you cannot allocate a generic chip without having a base IRQ at that point, if I understand correctly. If this was not necessary you would not need to allocate descriptors in advance. Yes that's my understand as well. Or rather: the *real* problem, which will face anyone trying to implement a combined edge+level IRQ chip in a driver, is that the generic irqchip does not play well with irqdomain. Using legacy in this case is clearly wrong, the generic IRQ chip is not one least bit legacy, it's top-of-the-line IRQ handling, using generic code as we want. However it seems generic chips cannot handle sparse IRQs at all, it requires the descriptors to be allocated before we create and instance of it. So I see two solutions: - Fix the generic chip to handle sparse IRQs by patching a lot in kernel/irq/generic-chip.c and allowing to pass something like 0 for irq base. - Add something like irq_domain_add_generic() for generic chips and handle the oddities there. The latter would be a pretty straight-forward wrapper to legacy domain as of now. Any preference? Or should we just consider generic irqchips a legacy case? There has been some work in the past to make generic-chip play well with irqdomain (by Rob Herring), but apparently, none of that work has been merged. See: Subject: [PATCH v6] irq: add irq_domain support to generic-chip Date: Wed, 8 Feb 2012 16:55:22 -0600 Also at: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/083897.html Rob, do you intend to push something like this further? What were the blocking points? Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH, resend] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Rob Clark rob.cl...@linaro.org
---
Resubmit since it seemed to have gotten lost last cycle.
include/linux/dma-buf.h | 99 -
1 file changed, 99 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index eb48f38..bd2e52c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
get_file(dmabuf-file);
}
-#ifdef CONFIG_DMA_SHARED_BUFFER
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
void dma_buf_detach(struct dma_buf *dmabuf,
@@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
*,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-#else
-
-static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *dmabuf_attach)
-{
- return;
-}
-
-static inline struct dma_buf *dma_buf_export(void *priv,
-const struct dma_buf_ops *ops,
-size_t size, int flags)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
-{
- return -ENODEV;
-}
-
-static inline struct dma_buf *dma_buf_get(int fd)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_put(struct dma_buf *dmabuf)
-{
- return;
-}
-
-static inline struct sg_table *dma_buf_map_attachment(
- struct dma_buf_attachment *attach, enum dma_data_direction write)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
- struct sg_table *sg, enum dma_data_direction dir)
-{
- return;
-}
-
-static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
- return -ENODEV;
-}
-
-static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
-}
-
-static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
- unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
-unsigned long pnum, void *vaddr)
-{
-}
-
-static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
- unsigned long pnum, void *vaddr)
-{
-}
-
-static inline int dma_buf_mmap(struct dma_buf *dmabuf,
- struct vm_area_struct *vma,
- unsigned long pgoff)
-{
- return -ENODEV;
-}
-
-static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
-{
- return NULL;
-}
-
-static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
-{
-}
-#endif /* CONFIG_DMA_SHARED_BUFFER */
#endif /* __DMA_BUF_H__ */
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/5] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes
On Wed, 2012-12-12 at 17:09 +0800, Tang Chen wrote: On 12/12/2012 08:49 AM, Jiang Liu wrote: This patch introduces a new array zone_movable_limit[] to store the ZONE_MOVABLE limit from movablecore_map boot option for all nodes. The function sanitize_zone_movable_limit() will find out to which node the ranges in movable_map.map[] belongs, and calculates the low boundary of ZONE_MOVABLE for each node. What's the difference between zone_movable_limit[nid] and zone_movable_pfn[nid]? zone_movable_limit[] is a temporary storage for zone_moveable_pfn[]. It's used to handle a special case if user specifies both movablecore_map and movablecore/kernelcore on the kernel command line. Hi Simon, Liu, Sorry for the late and thanks for your discussion. :) As Liu said, zone_movable_limit[] is a temporary array for calculation. If users specified movablecore_map option, zone_movable_limit[] holds the lowest pfn of ZONE_MOVABLE limited by movablecore_map option. It is constant, won't change. Please refer to find_zone_movable_pfns_for_nodes() in patch4, you will see that zone_moveable_pfn[] will be changed each time kernel area increases. So when kernel area increases on node i, zone_moveable_pfn[i] will increase. And if zone_moveable_pfn[i] zone_movable_limit[i], we should stop allocate memory for kernel on node i. Here, I give movablecore_map higher priority than kernelcore/movablecore. And also, I tried to use zone_moveable_pfn[] to store limits. But when calculating the kernel area, I still have to store the limits in temporary variables. I think the code was ugly. So I added an new array. Thanks. :) Thanks for your clarify. Enable PAE on x86 32bit kernel, 8G memory, movablecore=6.5G [0.00] 8304MB HIGHMEM available. [0.00] 885MB LOWMEM available. [0.00] mapped low ram: 0 - 375fe000 [0.00] low ram: 0 - 375fe000 [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] Normal [mem 0x0100-0x375fdfff] [0.00] HighMem [mem 0x375fe000-0x3e5f] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009cfff] [0.00] node 0: [mem 0x0010-0x1fff] [0.00] node 0: [mem 0x2020-0x3fff] [0.00] node 0: [mem 0x4020-0xb69cbfff] [0.00] node 0: [mem 0xb6a46000-0xb6a47fff] [0.00] node 0: [mem 0xb6b1c000-0xb6cf] [0.00] node 0: [mem 0x-0x3e5f] [0.00] On node 0 totalpages: 2051391 [0.00] free_area_init_node: node 0, pgdat c0c26a80, node_mem_map f19de200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3949 pages, LIFO batch:0 [0.00] Normal zone: 1740 pages used for memmap [0.00] Normal zone: 220466 pages, LIFO batch:31 [0.00] HighMem zone: 16609 pages used for memmap [0.00] HighMem zone: 1808595 pages, LIFO batch:31 Why zone movable disappear? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/5][RESEND] page_alloc: Make movablecore_map has higher priority
Hi Simon,
Thanks for reviewing. This logic is aimed at make movablecore_map
coexist with kernelcore/movablecore.
Please see below. :)
On 12/12/2012 09:33 AM, Simon Jeons wrote:
@@ -4839,9 +4839,17 @@ static void __init find_zone_movable_pfns_for_nodes(void)
required_kernelcore = max(required_kernelcore, corepages);
}
- /* If kernelcore was not specified, there is no ZONE_MOVABLE */
- if (!required_kernelcore)
+ /*
+* If neither kernelcore/movablecore nor movablecore_map is specified,
+* there is no ZONE_MOVABLE. But if movablecore_map is specified, the
+* start pfn of ZONE_MOVABLE has been stored in zone_movable_limit[].
+*/
+ if (!required_kernelcore) {
+ if (movablecore_map.nr_map)
+ memcpy(zone_movable_pfn, zone_movable_limit,
+ sizeof(zone_movable_pfn));
If users didn't specified kernelcore option, then zone_movable_pfn[]
and zone_movable_limit[] are all the same. We skip the logic.
goto out;
+ }
/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */
usable_startpfn = arch_zone_lowest_possible_pfn[movable_zone];
@@ -4871,10 +4879,24 @@ restart:
for_each_mem_pfn_range(i, nid,start_pfn,end_pfn, NULL) {
unsigned long size_pages;
+ /*
+* Find more memory for kernelcore in
+* [zone_movable_pfn[nid], zone_movable_limit[nid]).
+*/
start_pfn = max(start_pfn, zone_movable_pfn[nid]);
if (start_pfn= end_pfn)
continue;
Hi Chen,
+ if (zone_movable_limit[nid]) {
If users didn't give any limitation of ZONE_MOVABLE on node i, we could
skip the logic too.
+ end_pfn = min(end_pfn, zone_movable_limit[nid]);
In order to reuse the original kernelcore/movablecore logic, we keep
end_pfn = zone_movable_limit[nid]. We device [start_pfn, end_pfn) into
two parts:
[start_pfn, zone_movable_limit[nid])
and
[zone_movable_limit[nid], end_pfn).
We just remove the second part, and go on to the original logic.
+ /* No range left for kernelcore in this node */
+ if (start_pfn= end_pfn) {
Since we re-evaluated end_pfn, if we have crossed the limitation, we
should stop.
+ zone_movable_pfn[nid] =
+ zone_movable_limit[nid];
Here, we found the real limitation. That means, the lowest pfn of
ZONE_MOVABLE is either zone_movable_limit[nid] or the value the original
logic calculates out, which is below zone_movable_limit[nid].
+ break;
Then we break and go on to the next node.
+ }
+ }
+
Could you explain this part of codes? hard to understand.
/* Account for what is only usable for kernelcore */
if (start_pfn usable_startpfn) {
unsigned long kernel_pages;
@@ -4934,12 +4956,12 @@ restart:
if (usable_nodes required_kernelcore usable_nodes)
goto restart;
+out:
/* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */
for (nid = 0; nid MAX_NUMNODES; nid++)
zone_movable_pfn[nid] =
roundup(zone_movable_pfn[nid], MAX_ORDER_NR_PAGES);
-out:
/* restore the node_state */
node_states[N_HIGH_MEMORY] = saved_node_state;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] First round of SCSI updates for the 3.7+ merge window
This patch set includes two large new drivers: mpt3sas (for the next gen fusion SAS hardware) and csiostor a FCoE offload driver for the Chelsio converged network cards (this includes some net changes which I've OK'd with DaveM). The rest of the patch is driver updates (qla2xxx, lpfc, hptiop, be2iscsi) plus a few assorted updates and bug fixes. We also have a Power Management rework in the Upper Layer Drivers preparatory to doing ACPI zero power optical devices, but the actual enabler is still being worked on. Because of the need to keep the tree stable for next testing, anything submitted after last Saturday (1 Dec) will be in the next round. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc The short changelog is Aaron Lu (5): sd: update sd to use the new pm callbacks scsi_pm: use callbacks from dev_pm_ops for scsi devices Revert [SCSI] runtime resume parent for child's system-resume Revert [SCSI] scsi_pm: set device runtime state before parent suspended sd: put to stopped power state when runtime suspend Andrew Vasquez (2): qla2xxx: Use correct Request-Q-Out register during bidirectional request processing qla2xxx: Clear unsupported 'states' during Get-FW-State queries. Armen Baloyan (2): qla2xxx: No fcport FC-4 type assignment in GA_NXT response. qla2xxx: Properly set result field of bsg_job reply structure for success and failure. Boaz Harrosh (1): osd_uld: Add osdname systemid sysfs at scsi_osd class Chad Dupuis (3): qla2xxx: Update ql2xextended_error_logging parameter description with new option. qla2xxx: Move noisy Start scsi failed messages to verbose logging level. qla2xxx: Remove spurious taking of ha-vport_slock spinlock. Dan Carpenter (1): csiostor: remove unneeded memset() David Jeffery (1): qla2xxx: Test and clear FCPORT_UPDATE_NEEDED atomically. Eddie Wai (1): bnx2i: removed the individual PCI DEVICE ID checking Eric Northup (1): virtio_scsi: fix memory leak on full queue condition. Giridhar Malavali (1): qla2xxx: Change in setting UNLOADING flag and FC vports logout sequence while unloading qla2xxx driver. HighPoint Linux Team (1): hptiop: Support HighPoint RR4520/RR4522 HBA James Smart (7): lpfc 8.3.36: Update lpfc version for 8.3.36 driver release lpfc 8.3.36: Correct mask error lpfc 8.3.36: Correct buffer length overrun lpfc 8.3.36: Fixed setting sequential delivery bit lpfc 8.3.36: Update DIF support for passthru/strip/insert lpfc 8.3.36: Fix bug with Target Resets and FCP2 devices lpfc 8.3.36: Fixed boot from san failure Jason J. Herne (1): sd: Use SCSI read/write(16) with 32-bit LBA drives Joe Carnuccio (4): qla2xxx: Parameterize the link speed of hba rather than fcport. qla2xxx: Add 16Gb/s case to get port speed capability. qla2xxx: Move marking fcport online ahead of setting iiDMA speed. qla2xxx: Add acquiring of risc semaphore before doing ISP reset. Joel D. Diaz (1): sd: Reshuffle init_sd to avoid crash John Soni Jose (18): be2iscsi: Bump the driver version be2iscsi: Fix Unrecoverable Error Detection be2iscsi: Fix for MBX timeout issue be2iscsi: Update the copyright information be2iscsi: Fix issue of displaying adapter family. be2iscsi: Fix Task Completion Event handling be2iscsi: Fix session update context with V2 version. be2iscsi: Fix support for V2 version of WRB. be2iscsi: Fix support for handling CQ_CREATE V2 version. be2iscsi: Fix max EQ supported by the driver. be2iscsi: Fix driver support for Skyhawk-R adapter. be2iscsi: Fix return value and typo. be2iscsi: Fix kernel panic in blk_iopoll disable mode. be2iscsi: Issue an function level reset when driver is loaded be2iscsi: Display driver name and version in device attribute be2iscsi: Fix max supported EQ count to 8. be2iscsi: Fix memory leak in control path of driver be2iscsi: Display Completion Event string instead of Opcode Mahesh Rajashekhara (1): aacraid: SCSI dma mapping failure case handling Masanari Iida (1): qla2xxx: Fix typo in qla2xxx driver. Minh Tran (1): be2iscsi: Fix the issue with soft reset. Naresh Kumar Inna (3): csiostor: Fix sparse warnings. csiostor: Chelsio FCoE offload driver cxgb4/cxgb4vf: Chelsio FCoE offload driver submission (common header updates). Sasha Levin (1): prevent stack buffer overflow in host_reset Saurav Kashyap (9): qla2xxx: Display that driver is operating in legacy interrupt mode. qla2xxx: Dont clear drv active on iospace config failure. qla2xxx: Ignore driver ack bit if corresponding presence bit is not set. qla2xxx: Fix typo in qla83xx_fw_dump function. qla2xxx: Add Gen3 PCIe speed 8GT/s to the log message. qla2xxx: Fix
[PATCH 0/7] various ste_dma40 fixes
Hi all, this patch set contains some fixes for the ste_dma40 driver. Thanks, Fabio Gerald Baeza (1): dmaengine: ste_dma40: support fixed physical channel allocation Narayanan (1): dmaengine: ste_dma40: reset priority bit for logical channels Narayanan G (1): dmaengine: ste_dma40: don't check for pm_runtime_suspended() Per Forlin (3): dmaengine: ste_dma40: use writel_relaxed for lcxa dmaengine: ste_dma40: set dma max seg size dmaengine: ste_dma40: limit burst size to 16 Rabin Vincent (1): dmaengine: ste_dma40: don't allow high priority dest event lines drivers/dma/ste_dma40.c| 46 +- drivers/dma/ste_dma40_ll.c | 27 ++- 2 files changed, 55 insertions(+), 18 deletions(-) -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] dmaengine: ste_dma40: use writel_relaxed for lcxa
From: Per Forlin per.for...@stericsson.com
lcpa and lcla are written often and the cache_sync() overhead in writel
is costly, especially for wlan where every single network packet (in RX
mode) corresponds to a separate DMA transfer.
Signed-off-by: Per Forlin per.for...@stericsson.com
Reviewed-by: Narayanan Gopalakrishnan narayanan.gopalakrish...@stericsson.com
Reviewed-by: Rabin Vincent rabin.vinc...@stericsson.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org
---
drivers/dma/ste_dma40_ll.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index 536e848..c0781ae 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -332,10 +332,10 @@ void d40_log_lli_lcpa_write(struct d40_log_lli_full *lcpa,
{
d40_log_lli_link(lli_dst, lli_src, next, flags);
- writel(lli_src-lcsp02, lcpa[0].lcsp0);
- writel(lli_src-lcsp13, lcpa[0].lcsp1);
- writel(lli_dst-lcsp02, lcpa[0].lcsp2);
- writel(lli_dst-lcsp13, lcpa[0].lcsp3);
+ writel_relaxed(lli_src-lcsp02, lcpa[0].lcsp0);
+ writel_relaxed(lli_src-lcsp13, lcpa[0].lcsp1);
+ writel_relaxed(lli_dst-lcsp02, lcpa[0].lcsp2);
+ writel_relaxed(lli_dst-lcsp13, lcpa[0].lcsp3);
}
void d40_log_lli_lcla_write(struct d40_log_lli *lcla,
@@ -345,10 +345,10 @@ void d40_log_lli_lcla_write(struct d40_log_lli *lcla,
{
d40_log_lli_link(lli_dst, lli_src, next, flags);
- writel(lli_src-lcsp02, lcla[0].lcsp02);
- writel(lli_src-lcsp13, lcla[0].lcsp13);
- writel(lli_dst-lcsp02, lcla[1].lcsp02);
- writel(lli_dst-lcsp13, lcla[1].lcsp13);
+ writel_relaxed(lli_src-lcsp02, lcla[0].lcsp02);
+ writel_relaxed(lli_src-lcsp13, lcla[0].lcsp13);
+ writel_relaxed(lli_dst-lcsp02, lcla[1].lcsp02);
+ writel_relaxed(lli_dst-lcsp13, lcla[1].lcsp13);
}
static void d40_log_fill_lli(struct d40_log_lli *lli,
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] dmaengine: ste_dma40: support fixed physical channel allocation
From: Gerald Baeza gerald.ba...@stericsson.com
This patch makes existing use_fixed_channel field (of stedma40_chan_cfg
structure) applicable to physical channels.
Signed-off-by: Gerald Baeza gerald.ba...@stericsson.com
Tested-by: Yannick Fertre yannick.fer...@stericsson.com
Reviewed-by: Per Forlin per.for...@stericsson.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org
---
drivers/dma/ste_dma40.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index f871df6..efe8be7 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -1712,10 +1712,12 @@ static int d40_allocate_channel(struct d40_chan *d40c,
bool *first_phy_user)
int i;
int j;
int log_num;
+ int num_phy_chans;
bool is_src;
bool is_log = d40c-dma_cfg.mode == STEDMA40_MODE_LOGICAL;
phys = d40c-base-phy_res;
+ num_phy_chans = d40c-base-num_phy_chans;
if (d40c-dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
dev_type = d40c-dma_cfg.src_dev_type;
@@ -1736,12 +1738,19 @@ static int d40_allocate_channel(struct d40_chan *d40c,
bool *first_phy_user)
if (!is_log) {
if (d40c-dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
/* Find physical half channel */
- for (i = 0; i d40c-base-num_phy_chans; i++) {
-
+ if (d40c-dma_cfg.use_fixed_channel) {
+ i = d40c-dma_cfg.phy_channel;
if (d40_alloc_mask_set(phys[i], is_src,
0, is_log,
first_phy_user))
goto found_phy;
+ } else {
+ for (i = 0; i num_phy_chans; i++) {
+ if (d40_alloc_mask_set(phys[i], is_src,
+ 0, is_log,
+ first_phy_user))
+ goto found_phy;
+ }
}
} else
for (j = 0; j d40c-base-num_phy_chans; j += 8) {
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] dmaengine: ste_dma40: limit burst size to 16
From: Per Forlin per.for...@stericsson.com
The client is not aware of the maximum burst size in the dma driver. If
the size exceeds 16 set max to 16.
Signed-off-by: Per Forlin per.for...@stericsson.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org
---
drivers/dma/ste_dma40.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 16c96f5..0b80ee9 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2579,6 +2579,14 @@ static int d40_set_runtime_config(struct dma_chan *chan,
return -EINVAL;
}
+ if (src_maxburst 16) {
+ src_maxburst = 16;
+ dst_maxburst = src_maxburst * src_addr_width / dst_addr_width;
+ } else if (dst_maxburst 16) {
+ dst_maxburst = 16;
+ src_maxburst = dst_maxburst * dst_addr_width / src_addr_width;
+ }
+
ret = dma40_config_to_halfchannel(d40c, cfg-src_info,
src_addr_width,
src_maxburst);
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] xen/swiotlb: Exchange to contiguous memory for map_sg hook
On 12.12.12 at 02:03, Xu, Dongxiao dongxiao...@intel.com wrote: From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] On Tue, Dec 11, 2012 at 06:39:35AM +, Xu, Dongxiao wrote: From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] What if this check was done in the routines that provide the software static buffers and there try to provide a nice DMA contingous swatch of pages? Yes, this approach also came to our mind, which needs to modify the driver itself. If so, it requires driver not using such static buffers (e.g., from kmalloc) to do DMA even if the buffer is continuous in native. I am bit loss here. Is the issue you found only with drivers that do not use DMA API? Can you perhaps point me to the code that triggered this fix in the first place? Yes, we met this issue on a specific SAS device/driver, and it calls into libata-core code, you can refer to function ata_dev_read_id() called from ata_dev_reread_id() in drivers/ata/libata-core.c. In the above function, the target buffer is (void *)dev-link-ap-sector_buf, which is 512 bytes static buffer and unfortunately it across the page boundary. I wonder whether such use of sg_init_one()/sg_set_buf() is correct in the first place. While there aren't any restrictions documented for its use, one clearly can't pass in whatever one wants (a pointer into vmalloc()-ed memory, for instance, won't work afaict). I didn't go through all other users of it, but quite a few of the uses elsewhere look similarly questionable. I am still not completely clear on what you had in mind. The one method I thought about that might help in this is to have Xen-SWIOTLB track which memory ranges were exchanged (so xen_swiotlb_fixup would save the *buf and the size for each call to xen_create_contiguous_region in a list or array). When xen_swiotlb_map/xen_swiotlb_map_sg_attrs care called they would consult said array/list to see if the region they retrieved crosses said 2MB chunks. If so.. and here I am unsure of what would be the best way to proceed. We thought we can solve the issue in several ways: 1) Like the previous patch I sent out, we check the DMA region in xen_swiotlb_map_page() and xen_swiotlb_map_sg_attr(), and if DMA region crosses page boundary, we exchange the memory and copy the content. However it has race condition that when copying the memory content (we introduced two memory copies in the patch), some other code may also visit the page, which may encounter incorrect values. That's why, after mapping a buffer (or SG list) one has to call the sync functions before looking at data. Any race as described by you is therefore a programming error. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] dmaengine: ste_dma40: don't allow high priority dest event lines
From: Rabin Vincent rabin.vinc...@stericsson.com
Hardware bug: when a logical channel is triggerred by a high priority
destination event line, an extra packet transaction is generated in case
of important data write response latency on previous logical channel A
and if the source transfer of current logical channel B is already
completed and if no other channel with a higher priority than B is
waiting for execution.
Software workaround: do not set the high priority level for the
destination event lines that trigger logical channels.
Signed-off-by: Rabin Vincent rabin.vinc...@stericsson.com
Reviewed-by: Shreshtha Kumar Sahu shreshthakumar.s...@stericsson.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org
---
drivers/dma/ste_dma40.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index d8d58d9..f871df6 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -2181,11 +2181,24 @@ static void __d40_set_prio_rt(struct d40_chan *d40c,
int dev_type, bool src)
{
bool realtime = d40c-dma_cfg.realtime;
bool highprio = d40c-dma_cfg.high_priority;
- u32 prioreg = highprio ? D40_DREG_PSEG1 : D40_DREG_PCEG1;
u32 rtreg = realtime ? D40_DREG_RSEG1 : D40_DREG_RCEG1;
u32 event = D40_TYPE_TO_EVENT(dev_type);
u32 group = D40_TYPE_TO_GROUP(dev_type);
u32 bit = 1 event;
+ u32 prioreg;
+
+ /*
+* Due to a hardware bug, in some cases a logical channel triggered by
+* a high priority destination event line can generate extra packet
+* transactions.
+*
+* The workaround is to not set the high priority level for the
+* destination event lines that trigger logical channels.
+*/
+ if (!src chan_is_logical(d40c))
+ highprio = false;
+
+ prioreg = highprio ? D40_DREG_PSEG1 : D40_DREG_PCEG1;
/* Destination event lines are stored in the upper halfword */
if (!src)
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] sched/rt: don't enable runtime if already enabled
On Tue, 2012-12-11 at 21:38 -0800, Neil Zhang wrote:
Ingo and All,
Hm, /me wonders why we would even need update_runtime() handler. We
disable at CPU_DOWN_PREPARE in update_runtime(), again at CPU_DYING in
migration_call(), and enable at CPU_ONLINE in both.
-Original Message-
From: Neil Zhang
Sent: 2012年12月4日 17:31
To: Neil Zhang; pet...@infradead.org; mi...@kernel.org
Cc: Chao Xie; linux-kernel@vger.kernel.org
Subject: RE: [PATCH] sched/rt: don't enable runtime if already enabled
Hi All,
-Original Message-
From: Neil Zhang [mailto:zhan...@marvell.com]
Sent: 2012年12月3日 16:01
To: mi...@redhat.com; pet...@infradead.org
Cc: Chao Xie; linux-kernel@vger.kernel.org; Neil Zhang
Subject: [PATCH] sched/rt: don't enable runtime if already enabled
There are two paths will call __enable_runtime, they are enable_runtime and
rq_online. Don't enable runtime again if it is already enabled.
It can fix the following kernel BUG when do cpu hotplug while there are
realtime threads running.
[ 3347.091644] kernel BUG at kernel/sched/rt.c:687!
[ 3347.091674] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [
3347.091674] Modules linked in: cidatattydev(O) gs_diag(O) diag(O)
gs_modem(O) ccinetdev(O) cci_datastub(O) citty(O) msocke
[ 3347.091705] CPU: 1Tainted: G O (3.4.5+ #439)
[ 3347.091735] PC is at __disable_runtime+0x1e4/0x240 [ 3347.091735] LR is at
__disable_runtime+0x1dc/0x240
[ 3347.091735] pc : [c0162124]lr : [c016211c]psr:
a093
[ 3347.091735] sp : e0061dc8 ip : c0807861 fp : c07a9740 [ 3347.091766]
r10: c1a0b740 r9 : r8 : fd050f80 [ 3347.091766] r7 : 0002 r6
: 03f8 r5 : c1a13740 r4 : c1a137d8 [ 3347.091766] r3 : r2 :
e0061dbc r1 : c06b11b6 r0 : 0037 [ 3347.091796] Flags: NzCv IRQs off
FIQs on Mode SVC_32 ISA ARM Segment kernel [ 3347.091796] Control:
10c53c7d Table: 21e5004a DAC: 0015
Signed-off-by: Neil Zhang zhan...@marvell.com
---
kernel/sched/rt.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 418feb0..6525e5b
100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -722,9 +722,11 @@ static void __enable_runtime(struct rq *rq)
raw_spin_lock(rt_b-rt_runtime_lock);
raw_spin_lock(rt_rq-rt_runtime_lock);
- rt_rq-rt_runtime = rt_b-rt_runtime;
- rt_rq-rt_time = 0;
- rt_rq-rt_throttled = 0;
+ if (rt_rq-rt_runtime == RUNTIME_INF) {
+ rt_rq-rt_runtime = rt_b-rt_runtime;
+ rt_rq-rt_time = 0;
+ rt_rq-rt_throttled = 0;
+ }
raw_spin_unlock(rt_rq-rt_runtime_lock);
raw_spin_unlock(rt_b-rt_runtime_lock);
}
--
1.7.4.1
Ingo seems use another mail now, update the To list.
Best Regards,
Neil Zhang
Please help review it.
Best Regards,
Neil Zhang
NР骒rybX肚v^)藓{.n+伐{赙zXФ≤}财zj:+v赙zZ++zf＂h~izwア?ㄨ)撷f^j谦ym@Aa囤0鹅hi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] dmaengine: ste_dma40: don't check for pm_runtime_suspended()
From: Narayanan G narayanan.gopalakrish...@stericsson.com The check for runtime suspend is not needed during a regular suspend, as the framework takes care of this. This fixes the issue of DMA driver not letting the system to go to deepsleep in the first attempt. Signed-off-by: Narayanan G narayanan.gopalakrish...@stericsson.com Reviewed-by: Rabin Vincent rabin.vinc...@stericsson.com Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org --- drivers/dma/ste_dma40.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c index 0b80ee9..d8d58d9 100644 --- a/drivers/dma/ste_dma40.c +++ b/drivers/dma/ste_dma40.c @@ -2783,8 +2783,6 @@ static int dma40_pm_suspend(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct d40_base *base = platform_get_drvdata(pdev); int ret = 0; - if (!pm_runtime_suspended(dev)) - return -EBUSY; if (base-lcpa_regulator) ret = regulator_disable(base-lcpa_regulator); -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] dmaengine: ste_dma40: set dma max seg size
From: Per Forlin per.for...@stericsson.com
Maximum DMA seg size is (0x x data_width). If max seg
size is not set it deafults to 64k. This results in failure
if transferring 64k in byte mode.
Large seg sizes may be supported by splitting large transfer.
Signed-off-by: Per Forlin per.for...@stericsson.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org
---
drivers/dma/ste_dma40.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index ae55091..16c96f5 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -345,6 +345,7 @@ struct d40_base {
int irq;
int num_phy_chans;
int num_log_chans;
+ struct device_dma_parameters dma_parms;
struct dma_device dma_both;
struct dma_device dma_slave;
struct dma_device dma_memcpy;
@@ -3363,6 +3364,13 @@ static int __init d40_probe(struct platform_device *pdev)
if (err)
goto failure;
+ base-dev-dma_parms = base-dma_parms;
+ err = dma_set_max_seg_size(base-dev, STEDMA40_MAX_SEG_SIZE);
+ if (err) {
+ d40_err(pdev-dev, Failed to set dma max seg size\n);
+ goto failure;
+ }
+
d40_hw_init(base);
dev_info(base-dev, initialized\n);
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] dmaengine: ste_dma40: reset priority bit for logical channels
From: Narayanan G narayanan.gopalakrish...@stericsson.com
This patch sets the SSCFG/SDCFG bit[7] PRI only for physical channel
requests with high priority. For logical channels, this bit will be
zero.
Signed-off-by: Narayanan G narayanan.gopalakrish...@stericsson.com
Reviewed-by: Rabin Vincent rabin.vinc...@stericsson.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org
---
drivers/dma/ste_dma40_ll.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
index cad9e1d..536e848 100644
--- a/drivers/dma/ste_dma40_ll.c
+++ b/drivers/dma/ste_dma40_ll.c
@@ -102,17 +102,18 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
src |= cfg-src_info.data_width D40_SREG_CFG_ESIZE_POS;
dst |= cfg-dst_info.data_width D40_SREG_CFG_ESIZE_POS;
+ /* Set the priority bit to high for the physical channel */
+ if (cfg-high_priority) {
+ src |= 1 D40_SREG_CFG_PRI_POS;
+ dst |= 1 D40_SREG_CFG_PRI_POS;
+ }
+
} else {
/* Logical channel */
dst |= 1 D40_SREG_CFG_LOG_GIM_POS;
src |= 1 D40_SREG_CFG_LOG_GIM_POS;
}
- if (cfg-high_priority) {
- src |= 1 D40_SREG_CFG_PRI_POS;
- dst |= 1 D40_SREG_CFG_PRI_POS;
- }
-
if (cfg-src_info.big_endian)
src |= 1 D40_SREG_CFG_LBE_POS;
if (cfg-dst_info.big_endian)
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen/blkback: prevent repeated backend_changed invocations
On 11.12.12 at 21:50, Olaf Hering o...@aepfle.de wrote: backend_changed might be called multiple times, which will leak be-mode. Make sure it will be called only once. Remove some unneeded checks. Also the be-mode string was leaked, release the memory on device shutdown. So did I miss some discussion here? I haven't seen any confirmation of this function indeed being supposed to be called just once. Also, as said previously, if indeed it is to be called just once, removing the watch during/after the first invocation would seem to be the more appropriate thing to do. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] HID: autodetect USB HID sensor hubs.
On Sun, 9 Dec 2012, Alexander Holler wrote: It should not be necessary to add IDs for HID sensor hubs to lists in hid-core.c and hid-sensor-hub.c. So instead of a whitelist, autodetect such USB HID sensor hubs, based on a collection of type physical inside a useage page of type sensor. If some sensor hubs stil must be usable as raw devices, a blacklist might be created. Signed-off-by: Alexander Holler hol...@ahsoftware.de I like this change and would like to merge it, but I'd appreciate Ack from Srinivas first. Srinivas? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] llist: add a safe version of llist_for_each_entry
On 12/12/12 01:37, Huang Ying wrote: On Tue, 2012-12-11 at 12:25 +0100, Roger Pau Monne wrote: Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Huang Ying ying.hu...@intel.com Cc: Konrad Rzeszutek Wilk kon...@kernel.org --- Changes since v2: * Allow to pass a NULL node as the first entry of deleted list entries. --- include/linux/llist.h | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/include/linux/llist.h b/include/linux/llist.h index a5199f6..4e0aec1 100644 --- a/include/linux/llist.h +++ b/include/linux/llist.h @@ -125,6 +125,33 @@ static inline void init_llist_head(struct llist_head *list) (pos) = llist_entry((pos)-member.next, typeof(*(pos)), member)) /** + * llist_for_each_entry_safe - safely iterate over some deleted entries of + * lock-less list of given type + * @pos:the type * to use as a loop cursor. + * @n: the struct llist_node to use as a temporary loop cursor In list_for_each_entry_safe, n is type *, why not follow that? Thanks for the review, yes I just saw it, I was using llist_node because I didn't need a type *, but I agree that it's best to stick with list_for_each_entry_safe interface. Will send v4 Best Regards, Huang Ying + * @node: the fist entry of deleted list entries. + * @member: the name of the llist_node with the struct. + * + * In general, some entries of the lock-less list can be traversed + * safely only after being removed from list, so start with an entry + * instead of list head. + * + * If being used on entries deleted from lock-less list directly, the + * traverse order is from the newest to the oldest added entry. If + * you want to traverse from the oldest to the newest, you must + * reverse the order by yourself before traversing. + * + * n is used to store a reference to the next item llist_node, so + * pos can be freed while iterating. + */ +#define llist_for_each_entry_safe(pos, n, node, member) \ +for ((pos) = llist_entry((node), typeof(*(pos)), member), \ + (n) = ((pos)-member != NULL) ? (pos)-member.next : NULL;\ + (pos)-member != NULL;\ + (pos) = llist_entry(n, typeof(*(pos)), member),\ + (n) = ((pos)-member != NULL) ? (pos)-member.next : NULL) + +/** * llist_empty - tests whether a lock-less list is empty * @head: the list to test * -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [braindump][RFC] signals and syscall restarts (Re: [PATCH v2 19/44] metag: Signal handling)
On 08/12/12 18:14, Al Viro wrote:
On Thu, Dec 06, 2012 at 10:09:55PM +, Al Viro wrote:
What we need to guarantee is
* restarts do not happen on signals caught in interrupts or exceptions
* restarts do not happen on signals caught in sigreturn()
Since we don't currently have an orig syscall in our pt_regs that
we can make invalid, is it acceptable to just explicitly exclude
rt_sigreturn? e.g. using something like this around the switch
statements that check for -ERESTART*:
/*
* Decide whether a syscall restart should be checked for.
* This needs to exclude non-syscalls (syscall == -1), and sys_rt_sigreturn.
*/
static int restartable_syscall(int syscall)
{
return syscall = 0 syscall != __NR_rt_sigreturn;
}
* restart should happen only once, even if we get through do_signal() many
times.
BTW, signal caught in sigreturn is *not* something requiring a narrow
race. It's perfectly normal to have some signals blocked for the
duration of signal handler - the signal itself is blocked by default
unless you have set SA_NODEFER in sa_flags and there's sa_mask allowing
to block an arbitrary set of signals. Upon return from signal handler
we undo that and if any of the temporary blocked signals has arrived
while we'd been in the handler (e.g. had been raised by the handler itself),
it will be caught as soon as we unblock it, i.e. in sigreturn.
Unfortunately, the testcases are somewhat architecture-dependent. See, for
example, arm one in commit 653d48b22166db2d8b1515ebe6f9f0f7c95dfc86; there
might be a way to arrange for asm-free equivalent if one played with -O0,
but it's probably not worth the trouble. That one deals with sigreturn
from signal caught in interrupt; sigreturn from signal caught in syscall
is a bit trickier. TBH, I don't understand your syscall calling conventions
well enough to cook one up; your restart logics looks really strange.
You leave -DX[0].U0 modified - fair enough, it doesn't seem to be used
by syscall entry path - *and* you revert -DX[0].U1 to the state you
used to have on entry. The thing is, I don't see any place that would
have changed it in between; why do you need that
regs-REG_SYSCALL = orig_syscall;
in there at all?
Yes, this doesn't seem to be necessary. The only other place
REG_SYSCALL is changed is when it's set to __NR_restart_syscall, in
which case I presume it never needs to be reset i.e. if a syscall
returns -ERESTART_RESTARTBLOCK, it either doesn't return a different
-ERESTART* from the restart block callback, or it's acceptable in
that case to restart sys_restart_syscall rather than the original
syscall that returned -ERESTART_RESTARTBLOCK. Is that right?
BTW, could you (and other folks submitting ports) document the ABI?
See e.g. Documentation/frv/kernel-ABI.txt for fairly decent example...
Good idea, something like below?
Thanks
James
Date: Tue, 11 Dec 2012 10:08:26 +
Subject: [PATCH 1/1] metag: add kernel-ABI document
Add a document in Documentation/metag/ describing the Linux ABI for
metag. It includes an outline of the registers, which ones are special
in userland and the kernel, the system call ABI, and an overview of the
calling conventions.
It was suggested that new architecture ports should have some ABI
documentation available, with Documentation/frv/kernel-ABI.txt
referenced as a decent example, from which some inspiration was drawn
for this patch.
Signed-off-by: James Hogan james.ho...@imgtec.com
Reported-by: Al Viro v...@zeniv.linux.org.uk
---
Documentation/metag/00-INDEX |2 +
Documentation/metag/kernel-ABI.txt | 256
2 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 Documentation/metag/kernel-ABI.txt
diff --git a/Documentation/metag/00-INDEX b/Documentation/metag/00-INDEX
index 4fe2e16..4a93a27 100644
--- a/Documentation/metag/00-INDEX
+++ b/Documentation/metag/00-INDEX
@@ -6,3 +6,5 @@ coremem.txt
- Documents the core memory interface used by suspend code
comet/
- Documentation specific to the Comet SoC
+kernel-ABI.txt
+ - Documents metag ABI details
diff --git a/Documentation/metag/kernel-ABI.txt
b/Documentation/metag/kernel-ABI.txt
new file mode 100644
index 000..7b8dee8
--- /dev/null
+++ b/Documentation/metag/kernel-ABI.txt
@@ -0,0 +1,256 @@
+ ==
+ KERNEL ABIS FOR METAG ARCH
+ ==
+
+This document describes the Linux ABIs for the metag architecture, and has the
+following sections:
+
+ (*) Outline of registers
+ (*) Userland registers
+ (*) Kernel registers
+ (*) System call ABI
+ (*) Calling conventions
+
+
+
+OUTLINE OF REGISTERS
+
+
+The main Meta core registers are arranged in units:
+
+ UNITTypeDESCRIPTION GP EXT PRIVGLOBAL
+ === === === === === ===
[Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).
Hello Omar Ramirez Luna:
in drivers/staging/tidspbridge/core/io_sm.c:
it is for function dump_dsp_stack.
char name[256] is not initialized. (line 1898)
name is as out buf for node_find_addr (line 2021..2024, 2066..2071,
2098..2103)
if node_find_addr fails, pr_err may cause issue (name may not be
initialized)
in drivers/staging/tidspbridge/rmgr/node.c:
function node_find_addr can be called by dump_dsp_stack.
param sym_name is as out buf which may be not initialized.
so pr_debug may cause issue (print sym_name).
in drivers/staging/tidspbridge/rmgr/nldr.c:
function nldr_find_addr can be called by node_find_addr
param sym_name is as out buf which may be not initialized.
so pr_debug may cause issue (print sym_name).
please help checking, thanks.
gchen.
in drivers/staging/tidspbridge/rmgr/nldr.c:
1798 int nldr_find_addr(struct nldr_nodeobject *nldr_node, u32 sym_addr,
1799 u32 offset_range, void *offset_output, char
*sym_name)
1800 {
1801 int status = 0;
1802 bool status1 = false;
1803 s32 i = 0;
1804 struct lib_node root = { NULL, 0, NULL };
1805 pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n, __func__, (u32)
nldr_node,
1806 sym_addr, offset_range, (u32) offset_output,
sym_name);
1807
...
in drivers/staging/tidspbridge/rmgr/node.c:
3009 int node_find_addr(struct node_mgr *node_mgr, u32 sym_addr,
3010 u32 offset_range, void *sym_addr_output, char *sym_name)
3011 {
3012 struct node_object *node_obj;
3013 int status = -ENOENT;
3014
3015 pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n, __func__,
3016 (unsigned int) node_mgr,
3017 sym_addr, offset_range,
3018 (unsigned int) sym_addr_output, sym_name);
3019
3020 list_for_each_entry(node_obj, node_mgr-node_list, list_elem) {
3021 status = nldr_find_addr(node_obj-nldr_node_obj, sym_addr,
3022 offset_range, sym_addr_output, sym_name);
3023 if (!status)
3024 break;
3025 }
3026
3027 return status;
3028 }
in drivers/staging/tidspbridge/core/io_sm.c:
1892 int dump_dsp_stack(struct bridge_dev_context *bridge_context)
1893 {
1894 int status = 0;
1895 struct cod_manager *code_mgr;
1896 struct node_mgr *node_mgr;
1897 u32 trace_begin;
1898 char name[256];
1899 struct {
1900 u32 head[2];
1901 u32 size;
1902 } mmu_fault_dbg_info;
1903 u32 *buffer;
1904 u32 *buffer_beg;
1905 u32 *buffer_end;
1906 u32 exc_type;
1907 u32 dyn_ext_base;
1908 u32 i;
1909 u32 offset_output;
1910 u32 total_size;
1911 u32 poll_cnt;
1912 const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
1913 IRP, NRP, AMR, SSR,
1914 ILC, RILC, IER, CSR};
1915 const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
1916 struct bridge_drv_interface *intf_fxns;
1917 struct dev_object *dev_object = bridge_context-dev_obj;
1918
1919 status = dev_get_cod_mgr(dev_object, code_mgr);
1920 if (!code_mgr) {
1921 pr_debug(%s: Failed on dev_get_cod_mgr.\n, __func__);
1922 status = -EFAULT;
1923 }
1924
1925 if (!status) {
1926 status = dev_get_node_manager(dev_object, node_mgr);
1927 if (!node_mgr) {
1928 pr_debug(%s: Failed on dev_get_node_manager.\n,
1929 __func__);
1930 status = -EFAULT;
1931 }
1932 }
1933
1934 if (!status) {
1935 /* Look for SYS_PUTCBEG/SYS_PUTCEND: */
1936 status =
1937 cod_get_sym_value(code_mgr, COD_TRACEBEG,
trace_begin);
1938 pr_debug(%s: trace_begin Value 0x%x\n,
1939 __func__, trace_begin);
1940 if (status)
1941 pr_debug(%s: Failed on cod_get_sym_value.\n,
1942 __func__);
1943 }
1944 if (!status)
1945 status = dev_get_intf_fxns(dev_object, intf_fxns);
1946 /*
1947 * Check for the magic number in the trace buffer. If it has
1948 * yet to appear then poll the trace buffer to wait for it. Its
1949 * appearance signals that the DSP has finished dumping its state.
1950 */
1951 mmu_fault_dbg_info.head[0] = 0;
1952 mmu_fault_dbg_info.head[1] = 0;
1953 if (!status) {
1954 poll_cnt = 0;
1955 while ((mmu_fault_dbg_info.head[0] !=
Re: [PATCH] xen/blkback: prevent repeated backend_changed invocations
On Wed, Dec 12, Jan Beulich wrote: On 11.12.12 at 21:50, Olaf Hering o...@aepfle.de wrote: backend_changed might be called multiple times, which will leak be-mode. Make sure it will be called only once. Remove some unneeded checks. Also the be-mode string was leaked, release the memory on device shutdown. So did I miss some discussion here? I haven't seen any confirmation of this function indeed being supposed to be called just once. Also, as said previously, if indeed it is to be called just once, removing the watch during/after the first invocation would seem to be the more appropriate thing to do. Does the API allow this, that the called function can disable the watch? Olaf -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4 v3] rtc: add rtc-driver for HID sensors of type time
On 12/11/2012 07:21 PM, Alexander Holler wrote:
This driver makes the time from HID sensors (hubs) which are offering
such available like any other RTC does.
Currently the time can only be read. Setting the time must be done
through sending a report, which currently isn't supported by
hid-sensor-hub. (I've planned to submit patches.)
It is necessary that all values like year, month etc, are send as
8bit values (1 byte each) and all of them in 1 report. Also the
spec HUTRR39b doesn't define the range of the year field, we
tread it as 0 - 99 because that's what most RTCs I know about are
offering.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Looks good, but as I wrote during the last review the __devinits need to go.
A few other suggerstions online
---
drivers/rtc/Kconfig | 16 ++
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-hid-sensor-time.c | 284
+
3 files changed, 301 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-hid-sensor-time.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 19c03ab..7c7b33e 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS
This driver can also be built as a module, if so, the module
will be called rtc-snvs.
+comment HID Sensor RTC drivers
+
+config RTC_DRV_HID_SENSOR_TIME
+ tristate HID Sensor Time
+ depends on USB_HID
+ select IIO
+ select HID_SENSOR_HUB
+ select HID_SENSOR_IIO_COMMON
+ help
+ Say yes here to build support for the HID Sensors of type Time.
+ This drivers makes such sensors available as RTCs.
+
+ If this driver is compiled as a module, it will be named
+ rtc-hid-sensor-time.
The help text should be indented using one tab followed by two spaces
+
+
endif # RTC_CLASS
[...]
diff --git a/drivers/rtc/rtc-hid-sensor-time.c
b/drivers/rtc/rtc-hid-sensor-time.c
new file mode 100644
index 000..42b7ba1
--- /dev/null
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -0,0 +1,284 @@
[...]
+
+/* Channel names for verbose error messages */
+static const char *hid_time_channel_names[TIME_RTC_CHANNEL_MAX] = {
const char * const
+ year, month, day, hour, minute, second,
+};
+
+/* Callback handler to send event after all samples are received and
captured */
+static int hid_time_proc_event(struct hid_sensor_hub_device *hsdev,
+ unsigned usage_id, void *priv)
+{
+ unsigned long flags;
+ struct hid_time_state *time_state = platform_get_drvdata(priv);
+
+ spin_lock_irqsave(time_state-lock_last_time, flags);
+ time_state-last_time = time_state-time_buf;
+ spin_unlock_irqrestore(time_state-lock_last_time, flags);
+ complete(time_state-comp_last_time);
+ return 0;
+}
+
+static int hid_time_capture_sample(struct hid_sensor_hub_device *hsdev,
+ unsigned usage_id, size_t raw_len,
+ char *raw_data, void *priv)
+{
+ struct hid_time_state *time_state = platform_get_drvdata(priv);
+ struct rtc_time *time_buf = time_state-time_buf;
+
+ switch (usage_id) {
+ case HID_USAGE_SENSOR_TIME_YEAR:
+ time_buf-tm_year = *(u8 *)raw_data;
+ if (time_buf-tm_year 70)
+ /* assume we are in 1970...2069 */
+ time_buf-tm_year += 100;
+ break;
+ case HID_USAGE_SENSOR_TIME_MONTH:
+ time_buf-tm_mon = --*(u8 *)raw_data;
What's up with the double minus?
+ break;
+ case HID_USAGE_SENSOR_TIME_DAY:
+ time_buf-tm_mday = *(u8 *)raw_data;
+ break;
+ case HID_USAGE_SENSOR_TIME_HOUR:
+ time_buf-tm_hour = *(u8 *)raw_data;
+ break;
+ case HID_USAGE_SENSOR_TIME_MINUTE:
+ time_buf-tm_min = *(u8 *)raw_data;
+ break;
+ case HID_USAGE_SENSOR_TIME_SECOND:
+ time_buf-tm_sec = *(u8 *)raw_data;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+/* small helper, haven't found any other way */
+static const char *attrib_name(u32 attrib_id)
+{
+ unsigned i = 0;
+ static const char unknown[] = unknown;
+
+ for (; i TIME_RTC_CHANNEL_MAX; ++i) {
I would put the i = 0 in the for header.
+ if (hid_time_addresses[i] == attrib_id)
+ return hid_time_channel_names[i];
+ }
+ return unknown; /* should never happen */
+}
+
+static int hid_time_parse_report(struct platform_device *pdev,
+ struct hid_sensor_hub_device *hsdev,
+ unsigned usage_id,
+ struct hid_time_state *time_state)
+{
+ int ret, i = 0;
+
+ for (; i TIME_RTC_CHANNEL_MAX; ++i) {
Same here
+
Re: [PATCH 0/18] sched: simplified fork, enable load average into LB and power awareness scheduling
On Tue, Dec 11, 2012 at 10:10 PM, Arjan van de Ven ar...@linux.intel.com wrote: On 12/11/2012 8:13 AM, Borislav Petkov wrote: On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote: On 12/11/2012 7:48 AM, Borislav Petkov wrote: On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote: Another testing of parallel compress with pigz on Linus' git tree. results show we get much better performance/power with powersaving and balance policy: testing command: #pigz -k -c -p$x -r linux* /dev/null On a NHM EP box powersaving balance performance x = 4166.516 /88 68 170.515 /82 71 165.283 /103 58 x = 8173.654 /61 94 177.693 /60 93 172.31 /76 76 This looks funny: so performance is eating less watts than powersaving and balance on NHM. Could it be that the average watts measurements on NHM are not correct/precise..? On SNB they look as expected, according to your scheme. well... it's not always beneficial to group or to spread out it depends on cache behavior mostly which is best Let me try to understand what this means: so performance above with 8 threads means that those threads are spread out across more than one socket, no? If so, this would mean that you have a smaller amount of tasks on each socket, thus the smaller wattage. The powersaving method OTOH fills up the one socket up to the brim, thus the slightly higher consumption due to all threads being occupied. Is that it? not sure. by and large, power efficiency is the same as performance efficiency, with some twists. or to reword that to be more clear if you waste performance due to something that becomes inefficient, you're wasting power as well. now, you might have some hardware effects that can then save you power... but those effects then first need to overcome the waste from the performance inefficiency... and that almost never happens. for example, if you have two workloads that each fit barely inside the last level cache... it's much more efficient to spread these over two sockets... where each has its own full LLC to use. If you'd group these together, both would thrash the cache all the time and run inefficient -- bad for power. now, on the other hand, if you have two threads of a process that share a bunch of data structures, and you'd spread these over 2 sockets, you end up bouncing data between the two sockets a lot, running inefficient -- bad for power. Agree with all of the above. However.. having said all this, if you have to tasks that don't have such cache effects, the most efficient way of running things will be on 2 hyperthreading halves... it's very hard to beat the power efficiency of that. .. there are alternatives to hyperthreading. On ARM's big.LITTLE architecture you could simply schedule them on the LITTLE cores. The big cores just can't beat the power efficiency of the LITTLE ones even with 'race to halt' that you allude to below. And usecases like mp3 playback simply don't require the kind of performance that the big cores can offer. But this assumes the tasks don't compete with resources much on the HT level, and achieve good scaling. and this still has to compete with race to halt, because if you're done quicker, you can put the memory in self refresh quicker. none of this stuff is easy for humans or computer programs to determine ahead of time... or sometimes even afterwards. heck, even for just performance it's really really hard already, never mind adding power. my personal gut feeling is that we should just optimize this scheduler stuff for performance, and that we're going to be doing quite well on power already if we achieve that. If Linux is to continue to work efficiently on heterogeneous multi-processing platforms, it needs to provide scheduling mechanisms that can be exploited as per the demands of the HW architecture. An example is the small task packing (and spreading) for which Vincent Guittot has posted a patchset[1] earlier and so has Alex now. [1] http://lwn.net/Articles/518834/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen/blkback: prevent repeated backend_changed invocations
On 12.12.12 at 10:47, Olaf Hering o...@aepfle.de wrote: On Wed, Dec 12, Jan Beulich wrote: On 11.12.12 at 21:50, Olaf Hering o...@aepfle.de wrote: backend_changed might be called multiple times, which will leak be-mode. Make sure it will be called only once. Remove some unneeded checks. Also the be-mode string was leaked, release the memory on device shutdown. So did I miss some discussion here? I haven't seen any confirmation of this function indeed being supposed to be called just once. Also, as said previously, if indeed it is to be called just once, removing the watch during/after the first invocation would seem to be the more appropriate thing to do. Does the API allow this, that the called function can disable the watch? That is what would need looking into (and why I said during/after). Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: no release today (20121212)
Normal releases will resume tomorrow. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpx6rukip8fi.pgp Description: PGP signature
Re: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).
于 2012年12月12日 17:48, Chen Gang 写道:
Hello Omar Ramirez Luna:
in drivers/staging/tidspbridge/core/io_sm.c:
it is for function dump_dsp_stack.
char name[256] is not initialized. (line 1898)
name is as out buf for node_find_addr (line 2021..2024, 2066..2071,
2098..2103)
if node_find_addr fails, pr_err may cause issue (name may not be
initialized)
oh sorry, pr_err no issue (it is my fault).
in drivers/staging/tidspbridge/rmgr/node.c:
function node_find_addr can be called by dump_dsp_stack.
param sym_name is as out buf which may be not initialized.
so pr_debug may cause issue (print sym_name).
in drivers/staging/tidspbridge/rmgr/nldr.c:
function nldr_find_addr can be called by node_find_addr
param sym_name is as out buf which may be not initialized.
so pr_debug may cause issue (print sym_name).
but they are still have issue.
I find by code review, please help check whether this suggestion is valid.
thanks.
please help checking, thanks.
gchen.
in drivers/staging/tidspbridge/rmgr/nldr.c:
1798 int nldr_find_addr(struct nldr_nodeobject *nldr_node, u32 sym_addr,
1799 u32 offset_range, void *offset_output, char
*sym_name)
1800 {
1801 int status = 0;
1802 bool status1 = false;
1803 s32 i = 0;
1804 struct lib_node root = { NULL, 0, NULL };
1805 pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n, __func__, (u32)
nldr_node,
1806 sym_addr, offset_range, (u32) offset_output,
sym_name);
1807
...
in drivers/staging/tidspbridge/rmgr/node.c:
3009 int node_find_addr(struct node_mgr *node_mgr, u32 sym_addr,
3010 u32 offset_range, void *sym_addr_output, char *sym_name)
3011 {
3012 struct node_object *node_obj;
3013 int status = -ENOENT;
3014
3015 pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n, __func__,
3016 (unsigned int) node_mgr,
3017 sym_addr, offset_range,
3018 (unsigned int) sym_addr_output, sym_name);
3019
3020 list_for_each_entry(node_obj, node_mgr-node_list, list_elem) {
3021 status = nldr_find_addr(node_obj-nldr_node_obj,
sym_addr,
3022 offset_range, sym_addr_output, sym_name);
3023 if (!status)
3024 break;
3025 }
3026
3027 return status;
3028 }
in drivers/staging/tidspbridge/core/io_sm.c:
1892 int dump_dsp_stack(struct bridge_dev_context *bridge_context)
1893 {
1894 int status = 0;
1895 struct cod_manager *code_mgr;
1896 struct node_mgr *node_mgr;
1897 u32 trace_begin;
1898 char name[256];
1899 struct {
1900 u32 head[2];
1901 u32 size;
1902 } mmu_fault_dbg_info;
1903 u32 *buffer;
1904 u32 *buffer_beg;
1905 u32 *buffer_end;
1906 u32 exc_type;
1907 u32 dyn_ext_base;
1908 u32 i;
1909 u32 offset_output;
1910 u32 total_size;
1911 u32 poll_cnt;
1912 const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
1913 IRP, NRP, AMR, SSR,
1914 ILC, RILC, IER, CSR};
1915 const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
1916 struct bridge_drv_interface *intf_fxns;
1917 struct dev_object *dev_object = bridge_context-dev_obj;
1918
1919 status = dev_get_cod_mgr(dev_object, code_mgr);
1920 if (!code_mgr) {
1921 pr_debug(%s: Failed on dev_get_cod_mgr.\n, __func__);
1922 status = -EFAULT;
1923 }
1924
1925 if (!status) {
1926 status = dev_get_node_manager(dev_object, node_mgr);
1927 if (!node_mgr) {
1928 pr_debug(%s: Failed on dev_get_node_manager.\n,
1929
__func__);
1930 status = -EFAULT;
1931 }
1932 }
1933
1934 if (!status) {
1935 /* Look for SYS_PUTCBEG/SYS_PUTCEND: */
1936 status =
1937 cod_get_sym_value(code_mgr, COD_TRACEBEG,
trace_begin);
1938 pr_debug(%s: trace_begin Value 0x%x\n,
1939 __func__, trace_begin);
1940 if (status)
1941 pr_debug(%s: Failed on cod_get_sym_value.\n,
1942
__func__);
1943 }
1944 if (!status)
1945 status = dev_get_intf_fxns(dev_object, intf_fxns);
1946 /*
1947 * Check for the magic number in the trace buffer. If it has
1948 * yet to appear then poll the trace
[GIT PULL] Automatic NUMA Balancing V11
Hi Linus, This is a pull request for Automatic NUMA Balancing V11. The list of changes since commit f4a75d2eb7b1e2206094b901be09adb31ba63681: Linux 3.7-rc6 (2012-11-16 17:42:40 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux-balancenuma.git balancenuma-v11 for you to fetch changes up to 4fc3f1d66b1ef0d7b8dc11f4ff1cc510f78b37d6: mm/rmap, migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable (2012-12-11 14:43:00 +) There are three implementations for NUMA balancing, this tree (balancenuma), numacore which has been developed in tip/master and autonuma which is in aa.git. In almost all respects balancenuma is the dumbest of the three because its main impact is on the VM side with no attempt to be smart about scheduling. In the interest of getting the ball rolling, it would be desirable to see this much merged for 3.8 with the view to building scheduler smarts on top and adapting the VM where required for 3.9. The most recent set of comparisons available from different people are mel:https://lkml.org/lkml/2012/12/9/108 mingo: https://lkml.org/lkml/2012/12/7/331 tglx: https://lkml.org/lkml/2012/12/10/437 srikar: https://lkml.org/lkml/2012/12/10/397 The results are a mixed bag. In my own tests, balancenuma does reasonably well. It's dumb as rocks and does not regress against mainline. On the other hand, Ingo's tests shows that balancenuma is incapable of converging for this workloads driven by perf which is bad but is potentially explained by the lack of scheduler smarts. Thomas' results show balancenuma improves on mainline but falls far short of numacore or autonuma. Srikar's results indicate we all suffer on a large machine with imbalanced node sizes. My own testing showed that recent numacore results have improved dramatically, particularly in the last week but not universally. We've butted heads heavily on system CPU usage and high levels of migration even when it shows that overall performance is better. There are also cases where it regresses. Of interest is that for specjbb in some configurations it will regress for lower numbers of warehouses and show gains for higher numbers which is not reported by the tool by default and sometimes missed in treports. Recently I reported for numacore that the JVM was crashing with NullPointerExceptions but currently it's unclear what the source of this problem is. Initially I thought it was in how numacore batch handles PTEs but I'm no longer think this is the case. It's possible numacore is just able to trigger it due to higher rates of migration. These reports were quite late in the cycle so I/we would like to start with this tree as it contains much of the code we can agree on and has not changed significantly over the last 2-3 weeks. Thanks. Andrea Arcangeli (5): mm: numa: define _PAGE_NUMA mm: numa: pte_numa() and pmd_numa() mm: numa: Support NUMA hinting page faults from gup/gup_fast mm: numa: split_huge_page: transfer the NUMA type from the pmd to the pte mm: numa: Structures for Migrate On Fault per NUMA migration rate limiting Hillf Danton (2): mm: numa: split_huge_page: Transfer last_nid on tail page mm: numa: migrate: Set last_nid on newly allocated page Ingo Molnar (3): mm: Optimize the TLB flush of sys_mprotect() and change_protection() users mm/rmap: Convert the struct anon_vma::mutex to an rwsem mm/rmap, migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable Lee Schermerhorn (3): mm: mempolicy: Add MPOL_NOOP mm: mempolicy: Check for misplaced page mm: mempolicy: Add MPOL_MF_LAZY Mel Gorman (26): mm: Check if PTE is already allocated during page fault mm: compaction: Move migration fail/success stats to migrate.c mm: migrate: Add a tracepoint for migrate_pages mm: compaction: Add scanned and isolated counters for compaction mm: numa: Create basic numa page hinting infrastructure mm: migrate: Drop the misplaced pages reference count if the target node is full mm: mempolicy: Use _PAGE_NUMA to migrate pages mm: mempolicy: Implement change_prot_numa() in terms of change_protection() mm: mempolicy: Hide MPOL_NOOP and MPOL_MF_LAZY from userspace for now sched, numa, mm: Count WS scanning against present PTEs, not virtual memory ranges mm: numa: Add pte updates, hinting and migration stats mm: numa: Migrate on reference policy mm: numa: Migrate pages handled during a pmd_numa hinting fault mm: numa: Rate limit the amount of memory that is migrated between nodes mm: numa: Rate limit setting of pte_numa if node is saturated sched: numa: Slowly increase the scanning period as NUMA faults are handled mm: numa: Introduce last_nid to the page frame mm: numa: Use a two-stage filter to restrict pages being migrated for unlikely task-node relationships
Re: linux-next: no release today (20121212)
On Wed, Dec 12, 2012 at 10:59 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Normal releases will resume tomorrow. Good, no more ambitions to repair my Ubuntu/precise WUBI installation after Win7 updates or sth. else broke the wubi-loader... - Sedat - -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: decompressor: Flush tlb before swiching domain 0 to client mode
On Wednesday 12 December 2012 02:41 AM, Arve Hjønnevåg wrote: If the bootloader used a page table that is incompatible with domain 0 in client mode, then swithing domain 0 to client mode causes a fault if we don't flush the tlb after updating the page table pointer. Signed-off-by: Arve Hjønnevåg a...@android.com --- arch/arm/boot/compressed/head.S |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 90275f0..9c8034c 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -704,6 +704,7 @@ __armv7_mmu_cache_on: bic r6, r6, #1 31@ 32-bit translation system bic r6, r6, #3 0 @ use only ttbr0 mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer + mcrne p15, 0, r0, c8, c7, 0 @ flush I,D TLBs mcrne p15, 0, r1, c3, c0, 0 @ load domain access control mcrne p15, 0, r6, c2, c0, 2 @ load ttb control #endif The TLB's are already flushed few lines above so above patching shouldn't help if it was really dirty TLB entry issue. I suspect that your boot-loader clean-up [1] function may not be taking care of flushing caches which could potetially lead to the issue. Have you checked that ? Regards Santosh [1] http://www.arm.linux.org.uk/developer/noboot-checklist/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Read starvation by sync writes
On Wed 12-12-12 10:55:15, Shaohua Li wrote: 2012/12/11 Jan Kara j...@suse.cz: Hi, I was looking into IO starvation problems where streaming sync writes (in my case from kjournald but DIO would look the same) starve reads. This is because reads happen in small chunks and until a request completes we don't start reading further (reader reads lots of small files) while writers have plenty of big requests to submit. Both processes end up fighting for IO requests and writer writes nr_batching 512 KB requests while reader reads just one 4 KB request or so. Here the effect is magnified by the fact that the drive has relatively big queue depth so it usually takes longer than BLK_BATCH_TIME to complete the read request. The net result is it takes close to two minutes to read files that can be read under a second without writer load. Without the big drive's queue depth, results are not ideal but they are bearable - it takes about 20 seconds to do the reading. And for comparison, when writer and reader are not competing for IO requests (as it happens when writes are submitted as async), it takes about 2 seconds to complete reading. Simple reproducer is: echo 3 /proc/sys/vm/drop_caches dd if=/dev/zero of=/tmp/f bs=1M count=1 sleep 30 time cat /etc/* 21 /dev/null killall dd rm /tmp/f The question is how can we fix this? Two quick hacks that come to my mind are remove timeout from the batching logic (is it that important?) or further separate request allocation logic so that reads have their own request pool. More systematic fix would be to change request allocation logic to always allow at least a fixed number of requests per IOC. What do people think about this? As long as queue depth workload iodepth, there is little we can do to prioritize tasks/IOC. Because throttling a task/IOC means queue will be idle. We don't want to idle a queue (especially for SSD), so we always push as more requests as possible to the queue, which will break any prioritization. As far as I know we always have such issue in CFQ for big queue depth disk. Yes, I understand that. But actually big queue depth on its own doesn't make the problem really bad (at least for me). When the reader doesn't have to wait for free IO requests, it progresses at a reasonable speed. What makes it really bad is that big queue depth effectively disallows any use of ioc_batching() mode for the reader and thus it blocks in request allocation for every single read request unlike writer which always uses its full batch (32 requests). Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
Hi Javier, On 12/12/2012 09:25 AM, Javier Martinez Canillas wrote: On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v3 of the patch-set that solves issues pointed out by Enric Balletbo and Benoit Cousson. The patch-set is composed of the following patches: [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- Hi Benoit and Tony, Any comments on these? Nope, that's fine. I'll applied the series for 3.9. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: Re: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).
Hello Greg Kroah-Hartman:
excuse me, I have to forward this mail to you.
I have sent it to Omar Ramirez Luna omar.rami...@ti.com, but failed.
(get mail delivery failed )
thanks.
gchen
原始消息
主题: Re: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug
for uninitialized buffer (name buf not initialized).
日期: Wed, 12 Dec 2012 18:02:44 +0800
发件人: Chen Gang gang.c...@asianux.com
收件人: omar.rami...@ti.com
抄送: linux-kernel@vger.kernel.org linux-kernel@vger.kernel.org
于 2012年12月12日 17:48, Chen Gang 写道:
Hello Omar Ramirez Luna:
in drivers/staging/tidspbridge/core/io_sm.c:
it is for function dump_dsp_stack.
char name[256] is not initialized. (line 1898)
name is as out buf for node_find_addr (line 2021..2024, 2066..2071,
2098..2103)
if node_find_addr fails, pr_err may cause issue (name may not be
initialized)
oh sorry, pr_err no issue (it is my fault).
in drivers/staging/tidspbridge/rmgr/node.c:
function node_find_addr can be called by dump_dsp_stack.
param sym_name is as out buf which may be not initialized.
so pr_debug may cause issue (print sym_name).
in drivers/staging/tidspbridge/rmgr/nldr.c:
function nldr_find_addr can be called by node_find_addr
param sym_name is as out buf which may be not initialized.
so pr_debug may cause issue (print sym_name).
but they are still have issue (pr_debug).
I find by code review, please help check whether this suggestion is valid.
thanks.
please help checking, thanks.
gchen.
in drivers/staging/tidspbridge/rmgr/nldr.c:
1798 int nldr_find_addr(struct nldr_nodeobject *nldr_node, u32 sym_addr,
1799 u32 offset_range, void *offset_output, char
*sym_name)
1800 {
1801 int status = 0;
1802 bool status1 = false;
1803 s32 i = 0;
1804 struct lib_node root = { NULL, 0, NULL };
1805 pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n, __func__, (u32)
nldr_node,
1806 sym_addr, offset_range, (u32) offset_output,
sym_name);
1807
...
in drivers/staging/tidspbridge/rmgr/node.c:
3009 int node_find_addr(struct node_mgr *node_mgr, u32 sym_addr,
3010 u32 offset_range, void *sym_addr_output, char *sym_name)
3011 {
3012 struct node_object *node_obj;
3013 int status = -ENOENT;
3014
3015 pr_debug(%s(0x%x, 0x%x, 0x%x, 0x%x, %s)\n, __func__,
3016 (unsigned int) node_mgr,
3017 sym_addr, offset_range,
3018 (unsigned int) sym_addr_output, sym_name);
3019
3020 list_for_each_entry(node_obj, node_mgr-node_list, list_elem) {
3021 status = nldr_find_addr(node_obj-nldr_node_obj,
sym_addr,
3022 offset_range, sym_addr_output, sym_name);
3023 if (!status)
3024 break;
3025 }
3026
3027 return status;
3028 }
in drivers/staging/tidspbridge/core/io_sm.c:
1892 int dump_dsp_stack(struct bridge_dev_context *bridge_context)
1893 {
1894 int status = 0;
1895 struct cod_manager *code_mgr;
1896 struct node_mgr *node_mgr;
1897 u32 trace_begin;
1898 char name[256];
1899 struct {
1900 u32 head[2];
1901 u32 size;
1902 } mmu_fault_dbg_info;
1903 u32 *buffer;
1904 u32 *buffer_beg;
1905 u32 *buffer_end;
1906 u32 exc_type;
1907 u32 dyn_ext_base;
1908 u32 i;
1909 u32 offset_output;
1910 u32 total_size;
1911 u32 poll_cnt;
1912 const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
1913 IRP, NRP, AMR, SSR,
1914 ILC, RILC, IER, CSR};
1915 const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
1916 struct bridge_drv_interface *intf_fxns;
1917 struct dev_object *dev_object = bridge_context-dev_obj;
1918
1919 status = dev_get_cod_mgr(dev_object, code_mgr);
1920 if (!code_mgr) {
1921 pr_debug(%s: Failed on dev_get_cod_mgr.\n, __func__);
1922 status = -EFAULT;
1923 }
1924
1925 if (!status) {
1926 status = dev_get_node_manager(dev_object, node_mgr);
1927 if (!node_mgr) {
1928 pr_debug(%s: Failed on dev_get_node_manager.\n,
1929
__func__);
1930 status = -EFAULT;
1931 }
1932 }
1933
1934 if (!status) {
1935 /* Look for SYS_PUTCBEG/SYS_PUTCEND: */
1936 status =
1937 cod_get_sym_value(code_mgr, COD_TRACEBEG,
trace_begin);
1938 pr_debug(%s: trace_begin Value
Re: [PATCH 4/4 v3] rtc: add rtc-driver for HID sensors of type time
Am 12.12.2012 10:51, schrieb Lars-Peter Clausen: Looks good, but as I wrote during the last review the __devinits need to go. A few other suggerstions online Oh, have forgotten it. Ok, will make a v4, changing the other few things too. + case HID_USAGE_SENSOR_TIME_MONTH: + time_buf-tm_mon = --*(u8 *)raw_data; Time sensors are sending the month in the range 1-12, not 0-11. Regards, Alexander -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] various ste_dma40 fixes
On Wed, Dec 12, 2012 at 10:37:14AM +0100, Fabio Baltieri wrote: this patch set contains some fixes for the ste_dma40 driver. Adding DMA maintainers to the thread. Want me to resend the whole set? Thanks, Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4 v3] rtc: add rtc-driver for HID sensors of type time
On 12/12/2012 11:14 AM, Alexander Holler wrote: Am 12.12.2012 10:51, schrieb Lars-Peter Clausen: Looks good, but as I wrote during the last review the __devinits need to go. A few other suggerstions online Oh, have forgotten it. Ok, will make a v4, changing the other few things too. +case HID_USAGE_SENSOR_TIME_MONTH: +time_buf-tm_mon = --*(u8 *)raw_data; Time sensors are sending the month in the range 1-12, not 0-11. Ah, sorry, I guess hadn't had enough coffee yet, I read this as -(-(*(u8 *)raw_data))) and was a bit confused... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init
On Wed 12-12-12 16:25:59, Jianguo Wu wrote:
Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y
and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option,
system will boot fail.
This failure is caused by following code path:
setup_hugepagesz
hugetlb_add_hstate
hugetlb_cgroup_file_init
cgroup_add_cftypes
kzalloc --slab is *not available* yet
For this path, slab is not available yet, so memory allocated will be
failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
So I move hugetlb_cgroup_file_init() into hugetlb_init().
I do not think this is a good idea. hugetlb_init is in __init section as
well so what guarantees that the slab is initialized by then? Isn't this
just a good ordering that makes this working?
Shouldn't this be rather placed in hugetlb_cgroup_create?
Signed-off-by: Jianguo Wu wujian...@huawei.com
Signed-off-by: Jiang Liu jiang@huawei.com
---
include/linux/hugetlb_cgroup.h |7 ++-
mm/hugetlb.c | 11 +--
mm/hugetlb_cgroup.c| 23 +--
3 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
index d73878c..5bb9c28 100644
--- a/include/linux/hugetlb_cgroup.h
+++ b/include/linux/hugetlb_cgroup.h
@@ -62,7 +62,7 @@ extern void hugetlb_cgroup_uncharge_page(int idx, unsigned
long nr_pages,
struct page *page);
extern void hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
struct hugetlb_cgroup *h_cg);
-extern int hugetlb_cgroup_file_init(int idx) __init;
+extern void hugetlb_cgroup_file_init(void) __init;
extern void hugetlb_cgroup_migrate(struct page *oldhpage,
struct page *newhpage);
@@ -111,10 +111,7 @@ hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long
nr_pages,
return;
}
-static inline int __init hugetlb_cgroup_file_init(int idx)
-{
- return 0;
-}
+static inline void __init hugetlb_cgroup_file_init() {}
static inline void hugetlb_cgroup_migrate(struct page *oldhpage,
struct page *newhpage)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 1ef2cd4..a30da48 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1906,14 +1906,12 @@ static int __init hugetlb_init(void)
default_hstate.max_huge_pages = default_hstate_max_huge_pages;
hugetlb_init_hstates();
-
gather_bootmem_prealloc();
-
report_hugepages();
hugetlb_sysfs_init();
-
hugetlb_register_all_nodes();
+ hugetlb_cgroup_file_init();
return 0;
}
@@ -1943,13 +1941,6 @@ void __init hugetlb_add_hstate(unsigned order)
h-next_nid_to_free = first_node(node_states[N_HIGH_MEMORY]);
snprintf(h-name, HSTATE_NAME_LEN, hugepages-%lukB,
huge_page_size(h)/1024);
- /*
- * Add cgroup control files only if the huge page consists
- * of more than two normal pages. This is because we use
- * page[2].lru.next for storing cgoup details.
- */
- if (order = HUGETLB_CGROUP_MIN_ORDER)
- hugetlb_cgroup_file_init(hugetlb_max_hstate - 1);
parsed_hstate = h;
}
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index a3f358f..284cb68 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -340,7 +340,7 @@ static char *mem_fmt(char *buf, int size, unsigned long
hsize)
return buf;
}
-int __init hugetlb_cgroup_file_init(int idx)
+static void __init __hugetlb_cgroup_file_init(int idx)
{
char buf[32];
struct cftype *cft;
@@ -382,7 +382,26 @@ int __init hugetlb_cgroup_file_init(int idx)
WARN_ON(cgroup_add_cftypes(hugetlb_subsys, h-cgroup_files));
- return 0;
+ return;
+}
+
+void __init hugetlb_cgroup_file_init()
+{
+ struct hstate *h;
+ int idx;
+
+ idx = 0;
+ for_each_hstate(h) {
+ /*
+ * Add cgroup control files only if the huge page consists
+ * of more than two normal pages. This is because we use
+ * page[2].lru.next for storing cgoup details.
+ */
+ if (h-order = HUGETLB_CGROUP_MIN_ORDER)
+ __hugetlb_cgroup_file_init(idx);
+
+ idx++;
+ }
}
/*
-- 1.7.1
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command
From: fangxiaozhi huana...@huawei.com
1. To optimize the match rules for the Huawei USB storage devices. Avoid to
load USB storage driver for modem interface with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.
Signed-off-by: fangxiaozhi huana...@huawei.com
-
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c
linux-3.7/drivers/usb/storage/initializers.c
--- linux-3.7_bak/drivers/usb/storage/initializers.c2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.c2012-12-12
16:26:53.0 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
}
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
{
int result;
@@ -104,3 +104,60 @@ int usb_stor_huawei_e220_init(struct us_
US_DEBUGP(Huawei mode set result is %d\n, result);
return 0;
}
+
+/*Find the supported Huawei USB dongles*/
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+ int ret = 0;
+ struct usb_interface_descriptor *idesc = NULL;
+ idesc = us-pusb_intf-cur_altsetting-desc;
+ if (idesc != NULL idesc-bInterfaceNumber == 0) {
+ if ((us-pusb_dev-descriptor.idProduct = 0x1401
us-pusb_dev-descriptor.idProduct = 0x1600)
+ || (us-pusb_dev-descriptor.idProduct
= 0x1c02 us-pusb_dev-descriptor.idProduct = 0x2202)
+ || (us-pusb_dev-descriptor.idProduct
== 0x1001)
+ || (us-pusb_dev-descriptor.idProduct
== 0x1003)
+ || (us-pusb_dev-descriptor.idProduct
== 0x1004)) {
+
+ if (us-pusb_dev-descriptor.idProduct =
0x1501
+us-pusb_dev-descriptor.idProduct
= 0x1504) {
+ ret = 0;
+ } else {
+ ret = 1;
+ }
+ }
+ }
+ return ret;
+}
+
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+ int result = 0;
+ int act_len = 0;
+ unsigned char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x00,
0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00};
+ struct bulk_cb_wrap bcbw = {0};
+ bcbw.Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw.Tag = 0;
+ bcbw.DataTransferLength = cpu_to_le32(0);
+ bcbw.Flags = bcbw.Lun = 0;
+ bcbw.Length = sizeof(rewind_cmd);
+ memset(bcbw.CDB, 0, sizeof(bcbw.CDB));
+ memcpy(bcbw.CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf (us, us-send_bulk_pipe, bcbw, 31,
act_len);
+ US_DEBUGP(usb_stor_bulk_transfer_buf performing result is %d, transfer
the actual length=%d\n, result, act_len);
+ return result;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+ int result = 0;
+ if(usb_stor_huawei_dongles_pid(us)) {
+ if ((us-pusb_dev-descriptor.idProduct = 0x1446)) {
+ result = usb_stor_huawei_scsi_init(us);
+ } else {
+ result = usb_stor_huawei_feature_init(us);
+ }
+ }
+ return result;
+}
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.h
linux-3.7/drivers/usb/storage/initializers.h
--- linux-3.7_bak/drivers/usb/storage/initializers.h2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.h2012-12-12
11:43:58.0 +0800
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
diff -uprN linux-3.7_bak/drivers/usb/storage/unusual_devs.h
linux-3.7/drivers/usb/storage/unusual_devs.h
--- linux-3.7_bak/drivers/usb/storage/unusual_devs.h2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/unusual_devs.h2012-12-12
11:47:34.0 +0800
@@ -1527,335 +1527,10 @@ UNUSUAL_DEV( 0x1210, 0x0003, 0x0100, 0x
/* Reported by fangxiaozhi huana...@huawei.com
* This brings the HUAWEI data card devices into multi-port mode
*/
-UNUSUAL_DEV( 0x12d1, 0x1001, 0x, 0x,
+UNUSUAL_VENDOR_INTF( 0x12d1, 0x08, 0x06, 0x50,
HUAWEI MOBILE,
Mass Storage,
- USB_SC_DEVICE, USB_PR_DEVICE,
Re: [PATCH V4 3/3] MCE: fix an error of mce_bad_pages statistics
On Wed, Dec 12, 2012 at 11:35:33AM +0800, Xishi Qiu wrote: Since MCE is an x86 concept, and this code is in mm/, it would be better to use the name num_poisoned_pages instead of mce_bad_pages. Signed-off-by: Xishi Qiu qiuxi...@huawei.com Signed-off-by: Jiang Liu jiang@huawei.com Signed-off-by: Borislav Petkov b...@alien8.de This is not how Signed-of-by: works. You should read Documentation/SubmittingPatches (yes, the whole of it) about how that whole S-o-b thing works. And, FWIW, it should be Suggested-by: Borislav Petkov b...@alien8.de Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] battery-2.6.git
Hello Linus, Here are a few updates and new drivers queued for v3.8. All the patches were sitting in the -next tree for awhile, except for the last merge commit -- I made it a few hours ago just to fix some conflicts, so that you won't have to bother. Highlights for this pull: - Two new drivers from Pali Rohár and N900 hackers: rx51_battery and bq2415x_charger. The drivers are a part of a solution to replace the proprietary Nokia BME stack; - Power supply core now registers devices with a thermal cooling subsystem, so we can now automatically throttle charging. Thanks to Ramakrishna Pallala! - Device tree support for ab8500 and max8925_power drivers; - Random fixups and enhancements for a bunch of drivers. Thanks! The following changes since commit 1ebaf4f4e6912199f8a4e30ba3ab55da2b71bcdf: Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2012-12-11 20:01:33 -0800) are available in the git repository at: git://git.infradead.org/battery-2.6.git tags/for-v3.8-merged for you to fetch changes up to 76d8a23b127020472207b281427d3e9f4f1227e4: Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux (2012-12-11 22:15:57 -0800) Alan Cox (1): max17042_battery: Fix missing verify_model_lock() return value check Anton Vorontsov (3): bq2415x_charger: Add Kconfig/Makefile entries bq2415x_charger: Fix style issues Merge git://git.kernel.org/.../torvalds/linux Axel Lin (1): generic-adc-battery: Fix checking return value of request_any_context_irq Dan Carpenter (2): generic-adc-battery: Pointer math issue in gab_probe() ds2782_battery: Fix signedness bug in ds278x_read_reg16() Kim, Milo (3): lp8788-charger: Use consumer device name on setting IIO channels lp8788-charger: Fix wrong ADC conversion lp8788-charger: Fix ADC channel names Marcos Paulo de Souza (2): jz4740-battery: Use devm_kzalloc jz4740-battery: Use devm_request_and_ioremap Pali Rohár (3): power_supply: Add new Nokia RX-51 (N900) power supply battery driver power_supply: Add bq2415x charger driver bq27x00_battery: Fixup nominal available capacity reporting Peter Ujfalusi (1): twl4030_charger: Change TWL4030_MODULE_* ids to TWL_MODULE_* Qing Xu (1): max8925_power: Add support for device-tree initialization Rajanikanth H.V (4): ab8500: Add devicetree support for fuelgauge ab8500: Add devicetree support for btemp ab8500: Add devicetree support for charger ab8500: Add devicetree support for chargalg Ramakrishna Pallala (2): power_supply: Add support for CHARGE_CONTROL_* attributes power_supply: Register power supply for thermal cooling device Documentation/devicetree/bindings/mfd/ab8500.txt | 27 +- Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt | 16 + .../devicetree/bindings/power_supply/ab8500/chargalg.txt | 16 + .../devicetree/bindings/power_supply/ab8500/charger.txt | 25 + Documentation/devicetree/bindings/power_supply/ab8500/fg.txt | 58 + Documentation/power/power_supply_class.txt |3 + arch/arm/boot/dts/dbx5x0.dtsi| 28 +- drivers/mfd/ab8500-core.c| 20 + drivers/power/Kconfig| 23 +- drivers/power/Makefile |4 +- drivers/power/ab8500_bmdata.c| 521 + drivers/power/ab8500_btemp.c | 77 +- drivers/power/ab8500_charger.c | 84 +- drivers/power/ab8500_fg.c| 82 +- drivers/power/abx500_chargalg.c | 56 +- drivers/power/bq2415x_charger.c | 1670 drivers/power/bq27x00_battery.c |8 + drivers/power/ds2782_battery.c |4 +- drivers/power/generic-adc-battery.c |5 +- drivers/power/jz4740-battery.c | 45 +- drivers/power/lp8788-charger.c | 75 +- drivers/power/max17042_battery.c |3 +- drivers/power/max8925_power.c| 51 +- drivers/power/power_supply_core.c| 96 ++ drivers/power/power_supply_sysfs.c |2 + drivers/power/rx51_battery.c | 251 + drivers/power/twl4030_charger.c | 12 +- include/linux/mfd/abx500.h | 34 +-
Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
On Tue, Dec 11, 2012 at 11:14 PM, Yinghai Lu ying...@kernel.org wrote: please check draft version for early_memremap version for microcode... 1. make find_cpio take map/unmap function pointer, and use that to set sliding window. 2. clean the end to size in some function to fix -1 offset 3. update_mc_saved to change back to __va for ap etc and after initrd_relocation. should use this one on top of early_ioremap_head64.patch that i sent it out this afternoon. this one pass the test on 64bit without microcode cpio with initrd... Fenghua, can you check it on 64 config with more than 4g RAM ? on top of tip/x86/microcode and early_ioremap_head64.patch Thanks Yinghai fix_microcode_v2.patch Description: Binary data
Re: Read starvation by sync writes
On Wed 12-12-12 15:18:21, Dave Chinner wrote: On Wed, Dec 12, 2012 at 03:31:37AM +0100, Jan Kara wrote: On Tue 11-12-12 16:44:15, Jeff Moyer wrote: Jan Kara j...@suse.cz writes: Hi, I was looking into IO starvation problems where streaming sync writes (in my case from kjournald but DIO would look the same) starve reads. This is because reads happen in small chunks and until a request completes we don't start reading further (reader reads lots of small files) while writers have plenty of big requests to submit. Both processes end up fighting for IO requests and writer writes nr_batching 512 KB requests while reader reads just one 4 KB request or so. Here the effect is magnified by the fact that the drive has relatively big queue depth so it usually takes longer than BLK_BATCH_TIME to complete the read request. The net result is it takes close to two minutes to read files that can be read under a second without writer load. Without the big drive's queue depth, results are not ideal but they are bearable - it takes about 20 seconds to do the reading. And for comparison, when writer and reader are not competing for IO requests (as it happens when writes are submitted as async), it takes about 2 seconds to complete reading. Simple reproducer is: echo 3 /proc/sys/vm/drop_caches dd if=/dev/zero of=/tmp/f bs=1M count=1 sleep 30 time cat /etc/* 21 /dev/null killall dd rm /tmp/f This is a buffered writer. How does it end up that you are doing all synchronous write I/O? Also, you forgot to mention what file system you were using, and which I/O scheduler. So IO scheduler is CFQ, filesystem is ext3 - which is the culprit why IO ends up being synchronous - in ext3 in data=ordered mode kjournald often ends up submitting all the data to disk and it can do it as WRITE_SYNC if someone is waiting for transaction commit. In theory this can happen with AIO DIO writes or someone running fsync on a big file as well. Although when I tried this now, I wasn't able to create as big problem as kjournald does (a kernel thread submitting huge linked list of buffer heads in a tight loop is hard to beat ;). Hum, so maybe just adding some workaround in kjournald so that it's not as aggressive will solve the real world cases as well... Maybe kjournald shouldn't be using WRITE_SYNC for those buffers? I mean, if there is that many of them then it's really a batch submission an dthe latency of a single buffer IO is really irrelevant to the rate at which the buffers are flushed to disk Yeah, the idea why kjournald uses WRITE_SYNC is that we know someone is waiting for transaction commit and that's pretty much definition of what WRITE_SYNC means. Kjournald could keep using WRITE if we see we have tens of megabytes of data in the commit. I'm just afraid that e.g. a process doing large DIO overwrite (which is WRITE_SYNC as well) could starve kjournald doing async IO and thus would effectively block any other fs activity. Hum, maybe if DIO wasn't using WRITE_SYNC (one could make similar argument there as with kjournald). But then the definition of what WRITE_SYNC should mean starts to be pretty foggy. Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/5] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes
Hi Simon, On 12/12/2012 05:29 PM, Simon Jeons wrote: Thanks for your clarify. Enable PAE on x86 32bit kernel, 8G memory, movablecore=6.5G Could you please provide more info ? Such as the whole kernel commondline. And did this happen after you applied these patches ? What is the output without these patches ? Thanks. :) [0.00] 8304MB HIGHMEM available. [0.00] 885MB LOWMEM available. [0.00] mapped low ram: 0 - 375fe000 [0.00] low ram: 0 - 375fe000 [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] Normal [mem 0x0100-0x375fdfff] [0.00] HighMem [mem 0x375fe000-0x3e5f] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009cfff] [0.00] node 0: [mem 0x0010-0x1fff] [0.00] node 0: [mem 0x2020-0x3fff] [0.00] node 0: [mem 0x4020-0xb69cbfff] [0.00] node 0: [mem 0xb6a46000-0xb6a47fff] [0.00] node 0: [mem 0xb6b1c000-0xb6cf] [0.00] node 0: [mem 0x-0x3e5f] [0.00] On node 0 totalpages: 2051391 [0.00] free_area_init_node: node 0, pgdat c0c26a80, node_mem_map f19de200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3949 pages, LIFO batch:0 [0.00] Normal zone: 1740 pages used for memmap [0.00] Normal zone: 220466 pages, LIFO batch:31 [0.00] HighMem zone: 16609 pages used for memmap [0.00] HighMem zone: 1808595 pages, LIFO batch:31 Why zone movable disappear? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] xen/blkback: prevent repeated backend_changed invocations
On Wed, 2012-12-12 at 09:42 +, Jan Beulich wrote: On 11.12.12 at 21:50, Olaf Hering o...@aepfle.de wrote: backend_changed might be called multiple times, which will leak be-mode. Make sure it will be called only once. Remove some unneeded checks. Also the be-mode string was leaked, release the memory on device shutdown. So did I miss some discussion here? I haven't seen any confirmation of this function indeed being supposed to be called just once. Also, as said previously, if indeed it is to be called just once, removing the watch during/after the first invocation would seem to be the more appropriate thing to do. The watch fires (often needlessly) when you first register it so in the common case it is going to be called twice. Of course that first time should abort early on so perhaps that's a moot point. Ian. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command
Hi,
ok, let's start.
On Wed, Dec 12, 2012 at 06:20:33PM +0800, fangxiaozhi 00110321 wrote:
From: fangxiaozhi huana...@huawei.com
1. To optimize the match rules for the Huawei USB storage devices. Avoid to
load USB storage driver for modem interface with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.
first of all you're doing a whole lot more than these two things and
your commit log is a lot over 72 characters.
Signed-off-by: fangxiaozhi huana...@huawei.com
-
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c
linux-3.7/drivers/usb/storage/initializers.c
--- linux-3.7_bak/drivers/usb/storage/initializers.c 2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.c 2012-12-12
16:26:53.0 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
}
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
renaming this function doesn't look like is part of $SUBJECT
{
int result;
@@ -104,3 +104,60 @@ int usb_stor_huawei_e220_init(struct us_
US_DEBUGP(Huawei mode set result is %d\n, result);
return 0;
}
+
+/*Find the supported Huawei USB dongles*/
comment style is wrong, you miss a space after /* and before */
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+ int ret = 0;
+ struct usb_interface_descriptor *idesc = NULL;
could add a blank line here to aid readability
+ idesc = us-pusb_intf-cur_altsetting-desc;
+ if (idesc != NULL idesc-bInterfaceNumber == 0) {
+ if ((us-pusb_dev-descriptor.idProduct = 0x1401
us-pusb_dev-descriptor.idProduct = 0x1600)
+ || (us-pusb_dev-descriptor.idProduct
= 0x1c02 us-pusb_dev-descriptor.idProduct = 0x2202)
+ || (us-pusb_dev-descriptor.idProduct
== 0x1001)
+ || (us-pusb_dev-descriptor.idProduct
== 0x1003)
+ || (us-pusb_dev-descriptor.idProduct
== 0x1004)) {
clearly you didn't even run checkpatch.pl here.
+ if (us-pusb_dev-descriptor.idProduct =
0x1501
^
trailing
whitespace
+ us-pusb_dev-descriptor.idProduct
= 0x1504) {
+ ret = 0;
ret is already initialized to zero, why do it again ?
+ } else {
+ ret = 1;
+ }
+ }
+ }
+ return ret;
+}
+
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+ int result = 0;
+ int act_len = 0;
+ unsigned char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x00,
0x00,
^
trailing
whitespace
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00};
+ struct bulk_cb_wrap bcbw = {0};
+ bcbw.Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw.Tag = 0;
+ bcbw.DataTransferLength = cpu_to_le32(0);
+ bcbw.Flags = bcbw.Lun = 0;
+ bcbw.Length = sizeof(rewind_cmd);
+ memset(bcbw.CDB, 0, sizeof(bcbw.CDB));
the entire structure is already initialized to zero, no ?
+ memcpy(bcbw.CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf (us, us-send_bulk_pipe, bcbw, 31,
act_len);
+ US_DEBUGP(usb_stor_bulk_transfer_buf performing result is %d, transfer
the actual length=%d\n, result, act_len);
waay over 80-characters. Run checkpatch.pl
+ return result;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+ int result = 0;
+ if(usb_stor_huawei_dongles_pid(us)) {
+ if ((us-pusb_dev-descriptor.idProduct = 0x1446)) {
+ result = usb_stor_huawei_scsi_init(us);
+ } else {
+ result = usb_stor_huawei_feature_init(us);
+ }
read Documentation/CodingStyle, you'll see this is wrong.
+ }
+ return result;
+}
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.h
linux-3.7/drivers/usb/storage/initializers.h
---
Re: [Xen-devel] [PATCH] xen/blkback: prevent repeated backend_changed invocations
On Wed, Dec 12, Ian Campbell wrote: On Wed, 2012-12-12 at 09:42 +, Jan Beulich wrote: On 11.12.12 at 21:50, Olaf Hering o...@aepfle.de wrote: backend_changed might be called multiple times, which will leak be-mode. Make sure it will be called only once. Remove some unneeded checks. Also the be-mode string was leaked, release the memory on device shutdown. So did I miss some discussion here? I haven't seen any confirmation of this function indeed being supposed to be called just once. Also, as said previously, if indeed it is to be called just once, removing the watch during/after the first invocation would seem to be the more appropriate thing to do. The watch fires (often needlessly) when you first register it so in the common case it is going to be called twice. Of course that first time should abort early on so perhaps that's a moot point. The current code handles that, if a property does not exist the function will exit early. Olaf -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init
On 2012/12/12 18:19, Michal Hocko wrote:
On Wed 12-12-12 16:25:59, Jianguo Wu wrote:
Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y
and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option,
system will boot fail.
This failure is caused by following code path:
setup_hugepagesz
hugetlb_add_hstate
hugetlb_cgroup_file_init
cgroup_add_cftypes
kzalloc --slab is *not available* yet
For this path, slab is not available yet, so memory allocated will be
failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
So I move hugetlb_cgroup_file_init() into hugetlb_init().
I do not think this is a good idea. hugetlb_init is in __init section as
well so what guarantees that the slab is initialized by then? Isn't this
just a good ordering that makes this working?
Hi Michal,
__initcall functions will be called in
start_kernel()
rest_init() // - slab is already
kernel_init()
kernel_init_freeable()
do_basic_setup()
do_initcalls()
and setup_hugepagesz() will be called in
start_kernel()
parse_early_param() // - before mm_init() - kmem_cache_init()
Is this right?
Thanks
Xishi Qiu
Shouldn't this be rather placed in hugetlb_cgroup_create?
Signed-off-by: Jianguo Wu wujian...@huawei.com
Signed-off-by: Jiang Liu jiang@huawei.com
---
include/linux/hugetlb_cgroup.h |7 ++-
mm/hugetlb.c | 11 +--
mm/hugetlb_cgroup.c| 23 +--
3 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
index d73878c..5bb9c28 100644
--- a/include/linux/hugetlb_cgroup.h
+++ b/include/linux/hugetlb_cgroup.h
@@ -62,7 +62,7 @@ extern void hugetlb_cgroup_uncharge_page(int idx, unsigned
long nr_pages,
struct page *page);
extern void hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
struct hugetlb_cgroup *h_cg);
-extern int hugetlb_cgroup_file_init(int idx) __init;
+extern void hugetlb_cgroup_file_init(void) __init;
extern void hugetlb_cgroup_migrate(struct page *oldhpage,
struct page *newhpage);
@@ -111,10 +111,7 @@ hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long
nr_pages,
return;
}
-static inline int __init hugetlb_cgroup_file_init(int idx)
-{
-return 0;
-}
+static inline void __init hugetlb_cgroup_file_init() {}
static inline void hugetlb_cgroup_migrate(struct page *oldhpage,
struct page *newhpage)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 1ef2cd4..a30da48 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1906,14 +1906,12 @@ static int __init hugetlb_init(void)
default_hstate.max_huge_pages = default_hstate_max_huge_pages;
hugetlb_init_hstates();
-
gather_bootmem_prealloc();
-
report_hugepages();
hugetlb_sysfs_init();
-
hugetlb_register_all_nodes();
+hugetlb_cgroup_file_init();
return 0;
}
@@ -1943,13 +1941,6 @@ void __init hugetlb_add_hstate(unsigned order)
h-next_nid_to_free = first_node(node_states[N_HIGH_MEMORY]);
snprintf(h-name, HSTATE_NAME_LEN, hugepages-%lukB,
huge_page_size(h)/1024);
-/*
- * Add cgroup control files only if the huge page consists
- * of more than two normal pages. This is because we use
- * page[2].lru.next for storing cgoup details.
- */
-if (order = HUGETLB_CGROUP_MIN_ORDER)
-hugetlb_cgroup_file_init(hugetlb_max_hstate - 1);
parsed_hstate = h;
}
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index a3f358f..284cb68 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -340,7 +340,7 @@ static char *mem_fmt(char *buf, int size, unsigned long
hsize)
return buf;
}
-int __init hugetlb_cgroup_file_init(int idx)
+static void __init __hugetlb_cgroup_file_init(int idx)
{
char buf[32];
struct cftype *cft;
@@ -382,7 +382,26 @@ int __init hugetlb_cgroup_file_init(int idx)
WARN_ON(cgroup_add_cftypes(hugetlb_subsys, h-cgroup_files));
-return 0;
+return;
+}
+
+void __init hugetlb_cgroup_file_init()
+{
+struct hstate *h;
+int idx;
+
+idx = 0;
+for_each_hstate(h) {
+/*
+ * Add cgroup control files only if the huge page consists
+ * of more than two normal pages. This is because we use
+ * page[2].lru.next for storing cgoup details.
+ */
+if (h-order = HUGETLB_CGROUP_MIN_ORDER)
+__hugetlb_cgroup_file_init(idx);
+
+idx++;
+}
}
/*
-- 1.7.1
Re: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command
On Wed, 12 Dec 2012 18:20:33 +0800 fangxiaozhi 00110321 fangxiao...@huawei.com wrote: From: fangxiaozhi huana...@huawei.com 1. To optimize the match rules for the Huawei USB storage devices. Avoid to load USB storage driver for modem interface with Huawei devices. 2. Add to support new switch command for new Huawei USB dongles. This prevents people getting access to the storage device if they want. It also means you need to change kernel not simply a user space file to add support for different new identifiers. So it seems a large step backwards to me. Why not just teach udev the new switch command then it'll work as a udev update on all sorts of existing kernels as well as being the kind of small safe change you can get into the entprise distributions ? Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/3] MCE: fix an error of mce_bad_pages statistics
On 2012/12/12 18:25, Borislav Petkov wrote: On Wed, Dec 12, 2012 at 11:35:33AM +0800, Xishi Qiu wrote: Since MCE is an x86 concept, and this code is in mm/, it would be better to use the name num_poisoned_pages instead of mce_bad_pages. Signed-off-by: Xishi Qiu qiuxi...@huawei.com Signed-off-by: Jiang Liu jiang@huawei.com Signed-off-by: Borislav Petkov b...@alien8.de This is not how Signed-of-by: works. You should read Documentation/SubmittingPatches (yes, the whole of it) about how that whole S-o-b thing works. And, FWIW, it should be Suggested-by: Borislav Petkov b...@alien8.de Thanks. Sorry, I will pay more attention to it next time, thank you. : -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avoid entropy starvation due to stack protection
On 11.12.2012 13:33:04, +0100, Stephan Mueller smuel...@chronox.de wrote:
Hi,
I just noticed a misuse of a variable in my initial patch
+ if (r-limit == 2 r-entropy_count = r-poolinfo-poolwords)
Instead of r-entropy_count, the code should use entropy_count.
Please see new patch attached.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
diff -purN linux-3.6/drivers/char/random.c
linux-3.6-sm/drivers/char/random.c
--- linux-3.6/drivers/char/random.c2012-10-01 01:47:46.0 +0200
+++ linux-3.6-sm/drivers/char/random.c2012-12-12 11:06:23.443403746
+0100
@@ -404,11 +404,12 @@ static bool debug;
module_param(debug, bool, 0644);
#define DEBUG_ENT(fmt, arg...) do { \
if (debug) \
-printk(KERN_DEBUG random %04d %04d %04d: \
+printk(KERN_DEBUG random %04d %04d %04d %04d: \
fmt,\
input_pool.entropy_count,\
blocking_pool.entropy_count,\
nonblocking_pool.entropy_count,\
+kernel_pool.entropy_count,\
## arg); } while (0)
#else
#define DEBUG_ENT(fmt, arg...) do {} while (0)
@@ -428,7 +429,11 @@ struct entropy_store {
__u32 *pool;
const char *name;
struct entropy_store *pull;
-int limit;
+int limit;/* 0 - no limit when extracting data (nonblocking)
+ * 1 - limit extracted data based on entropy counter
+ * 2 - no limit when extracting data and disabling
+ * use of seed source once pool has full entropy
+ */
/* read-write data: */
spinlock_t lock;
@@ -443,6 +448,7 @@ struct entropy_store {
static __u32 input_pool_data[INPUT_POOL_WORDS];
static __u32 blocking_pool_data[OUTPUT_POOL_WORDS];
static __u32 nonblocking_pool_data[OUTPUT_POOL_WORDS];
+static __u32 kernel_pool_data[OUTPUT_POOL_WORDS];
static struct entropy_store input_pool = {
.poolinfo = poolinfo_table[0],
@@ -469,6 +475,15 @@ static struct entropy_store nonblocking_
.pool = nonblocking_pool_data
};
+static struct entropy_store kernel_pool = {
+.poolinfo = poolinfo_table[1],
+.name = kernel,
+.limit = 2,
+.pull = input_pool,
+.lock = __SPIN_LOCK_UNLOCKED(kernel_pool.lock),
+.pool = kernel_pool_data
+};
+
static __u32 const twist_table[8] = {
0x, 0x3b6e20c8, 0x76dc4190, 0x4db26158,
0xedb88320, 0xd6d6a3e8, 0x9b64c2b0, 0xa00ae278 };
@@ -613,6 +628,15 @@ retry:
r-initialized = 1;
}
+/*
+ * An entropy pool that is marked with limit 2 will only be
+ * seeded by the input_pool until it is full of entropy.
+ */
+if (r-limit == 2 entropy_count = r-poolinfo-poolwords)
+{
+r-pull = NULL;
+}
+
trace_credit_entropy_bits(r-name, nbits, entropy_count,
r-entropy_total, _RET_IP_);
@@ -652,6 +676,8 @@ void add_device_randomness(const void *b
mix_pool_bytes(input_pool, time, sizeof(time), NULL);
mix_pool_bytes(nonblocking_pool, buf, size, NULL);
mix_pool_bytes(nonblocking_pool, time, sizeof(time), NULL);
+mix_pool_bytes(kernel_pool, buf, size, NULL);
+mix_pool_bytes(kernel_pool, time, sizeof(time), NULL);
}
EXPORT_SYMBOL(add_device_randomness);
@@ -820,7 +846,7 @@ static void xfer_secondary_pool(struct e
if (r-pull r-entropy_count nbytes * 8
r-entropy_count r-poolinfo-POOLBITS) {
/* If we're limited, always leave two wakeup worth's BITS */
-int rsvd = r-limit ? 0 : random_read_wakeup_thresh/4;
+int rsvd = r-limit == 1 ? 0 : random_read_wakeup_thresh/4;
int bytes = nbytes;
/* pull at least as many as BYTES as wakeup BITS */
@@ -868,7 +894,7 @@ static size_t account(struct entropy_sto
nbytes = 0;
} else {
/* If limited, never pull more than available */
-if (r-limit nbytes + reserved = r-entropy_count / 8)
+if (r-limit == 1 nbytes + reserved = r-entropy_count / 8)
nbytes = r-entropy_count/8 - reserved;
if (r-entropy_count / 8 = nbytes + reserved)
@@ -883,7 +909,7 @@ static size_t account(struct entropy_sto
}
DEBUG_ENT(debiting %d entropy credits from %s%s\n,
- nbytes * 8, r-name, r-limit ? : (unlimited));
+ nbytes * 8, r-name, r-limit == 1 ? : (unlimited));
spin_unlock_irqrestore(r-lock, flags);
@@ -1037,6 +1063,21 @@ void get_random_bytes(void *buf, int nby
EXPORT_SYMBOL(get_random_bytes);
/*
+ * This function exports the kernel random number pool. It is of
+ * slightly less quality than the nonblocking_pool exported by
+ * the function get_random_bytes because once it is filled completely
+ * with entropy, it is never seeded again. Yet, the quality of the
+ * random bytes depend on the SHA-1 hash and should be sufficient
+ * for purposes like ASLR and stack protection.
+ */
+void get_random_kernel_bytes(void *buf, int nbytes)
+{
+extract_entropy(kernel_pool, buf, nbytes, 0, 0);
+}
+EXPORT_SYMBOL(get_random_kernel_bytes);
+
+
+/*
* This
Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11
On Wed, Dec 12, 2012 at 12:44:33AM +0100, Rafael J. Wysocki wrote: On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote: On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote: Boris, please send the output of lspci -vvv' from that box. Attached. So the audio is a Root Complex Integrated Endpoind and there shouldn't be any problems with it related to PCIe ports power management. It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN to indicate that it actually can't be suspended (if my understanding the code is correct). However, it shouldn't do that, because that causes the runtime PM core to repeat the attempts. It rather should implement a .runtime_idle() callback returning an error code instead. Those messages are just noise, though. Adding author of this (b8dfc4624162c0547d7f36a9df48da2d9b4bd58a). Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] kernel BUG at mm/huge_memory.c:212!
On Wed, Dec 12, 2012 at 01:36:36PM +0800, Bob Liu wrote: On Mon, Dec 3, 2012 at 9:02 PM, Jiri Slaby jsl...@suse.cz wrote: On 11/30/2012 04:03 PM, Kirill A. Shutemov wrote: From: Kirill A. Shutemov kirill.shute...@linux.intel.com Hi Jiri, Sorry for late answer. It took time to reproduce and debug the issue. Could you test two patches below by thread. I expect it to fix both issues: put_huge_zero_page() and Bad rss-counter state. Hi, yes, since applying the patches on the last Thu, it didn't recur. Kirill A. Shutemov (2): thp: fix anononymous page accounting in fallback path for COW of HZP thp: avoid race on multiple parallel page faults to the same page mm/huge_memory.c | 30 +- 1 file changed, 25 insertions(+), 5 deletions(-) I still saw this bug on 3.7.0-rc8, but it's hard to reproduce it. It appears only once. I guess the patch you've posted fixes the issue, right? It's useful to enable debug_cow to test fallback path: echo 1 /sys/kernel/mm/transparent_hugepage/debug_cow -- Kirill A. Shutemov signature.asc Description: Digital signature
Re: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11
At Wed, 12 Dec 2012 00:44:33 +0100,
Rafael J. Wysocki wrote:
On Tuesday, December 11, 2012 06:55:08 PM Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 06:48:23PM +0100, Rafael J. Wysocki wrote:
Boris, please send the output of lspci -vvv' from that box.
Attached.
So the audio is a Root Complex Integrated Endpoind and there shouldn't be
any problems with it related to PCIe ports power management.
It looks like azx_runtime_suspend() is new in 3.7 and it returns -EAGAIN
to indicate that it actually can't be suspended (if my understanding the
code is correct). However, it shouldn't do that, because that causes
the runtime PM core to repeat the attempts. It rather should implement
a .runtime_idle() callback returning an error code instead.
Borislav, could you test the patch below?
thanks,
Takashi
---
From: Takashi Iwai ti...@suse.de
Subject: [PATCH] ALSA: hda - Move runtime PM check to runtime_idle callback
The runtime_idle callback is the right place to check the suspend
capability, but currently we do it wrongly in the runtime_suspend
callback. This leads to a kernel error message like:
pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel]
returns -11
and the runtime PM core would even repeat the attempts.
Reported-by: Borislav Petkov b...@alien8.de
Cc: sta...@vger.kernel.org [v3.7]
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/pci/hda/hda_intel.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1da8a5c..0f3d3db 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2691,10 +2691,6 @@ static int azx_runtime_suspend(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card-private_data;
- if (!power_save_controller ||
- !(chip-driver_caps AZX_DCAPS_PM_RUNTIME))
- return -EAGAIN;
-
azx_stop_chip(chip);
azx_clear_irq_pending(chip);
return 0;
@@ -2709,12 +2705,25 @@ static int azx_runtime_resume(struct device *dev)
azx_init_chip(chip, 1);
return 0;
}
+
+static int azx_runtime_idle(struct device *dev)
+{
+ struct snd_card *card = dev_get_drvdata(dev);
+ struct azx *chip = card-private_data;
+
+ if (!power_save_controller ||
+ !(chip-driver_caps AZX_DCAPS_PM_RUNTIME))
+ return -EBUSY;
+
+ return 0;
+}
+
#endif /* CONFIG_PM_RUNTIME */
#ifdef CONFIG_PM
static const struct dev_pm_ops azx_pm = {
SET_SYSTEM_SLEEP_PM_OPS(azx_suspend, azx_resume)
- SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume, NULL)
+ SET_RUNTIME_PM_OPS(azx_runtime_suspend, azx_runtime_resume,
azx_runtime_idle)
};
#define AZX_PM_OPS azx_pm
--
1.8.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] gpio: twl4030: Correct status reporting for outputs
Hi Grant, On 12/07/2012 09:09 AM, Linus Walleij wrote: On Thu, Dec 6, 2012 at 11:52 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: As Grant commneted on the first version: https://lkml.org/lkml/2012/12/5/53 Introduce bitfields to cache the directionand output status of the pins so we can report them correctly. To do this I did some cleanup within the driver to get rid of the global variables and moved them under a private structure, changed the locking as well to protect the bitfield operation. As a last patch I added a note that the PWMA/B handling should not be in this driver at all. This looks good to me: Acked-by: Linus Walleij linus.wall...@linaro.org Since Grant was requesting the changes I'll let him decide to merge. Would you have time to take a look at this set? Thanks, Péter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
This driver makes the time from HID sensors (hubs) which are offering
such available like any other RTC does.
Currently the time can only be read. Setting the time must be done
through sending a report, which currently isn't supported by
hid-sensor-hub. (I've planned to submit patches.)
It is necessary that all values like year, month etc, are send as
8bit values (1 byte each) and all of them in 1 report. Also the
spec HUTRR39b doesn't define the range of the year field, we
tread it as 0 - 99 because that's what most RTCs I know about are
offering.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
drivers/rtc/Kconfig | 16 ++
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-hid-sensor-time.c | 283 +
3 files changed, 300 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-hid-sensor-time.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 19c03ab..e0d29b5 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS
This driver can also be built as a module, if so, the module
will be called rtc-snvs.
+comment HID Sensor RTC drivers
+
+config RTC_DRV_HID_SENSOR_TIME
+ tristate HID Sensor Time
+ depends on USB_HID
+ select IIO
+ select HID_SENSOR_HUB
+ select HID_SENSOR_IIO_COMMON
+ help
+ Say yes here to build support for the HID Sensors of type Time.
+ This drivers makes such sensors available as RTCs.
+
+ If this driver is compiled as a module, it will be named
+ rtc-hid-sensor-time.
+
+
endif # RTC_CLASS
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 56297f0..9d1658a 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_RTC_DRV_EM3027) += rtc-em3027.o
obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93xx.o
obj-$(CONFIG_RTC_DRV_FM3130) += rtc-fm3130.o
obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
+obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o
obj-$(CONFIG_RTC_DRV_IMXDI)+= rtc-imxdi.o
obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o
obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
diff --git a/drivers/rtc/rtc-hid-sensor-time.c
b/drivers/rtc/rtc-hid-sensor-time.c
new file mode 100644
index 000..41bc011
--- /dev/null
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -0,0 +1,283 @@
+/*
+ * HID Sensor Time Driver
+ * Copyright (c) 2012, Alexander Holler.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 St - Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/module.h
+#include linux/hid-sensor-hub.h
+#include linux/iio/iio.h
+#include linux/rtc.h
+
+/* Format: HID-SENSOR-usage_id_in_hex */
+/* Usage ID from spec for Time: 0x2000A0 */
+#define DRIVER_NAME HID-SENSOR-2000a0 /* must be lowercase */
+
+enum hid_time_channel {
+ CHANNEL_SCAN_INDEX_YEAR,
+ CHANNEL_SCAN_INDEX_MONTH,
+ CHANNEL_SCAN_INDEX_DAY,
+ CHANNEL_SCAN_INDEX_HOUR,
+ CHANNEL_SCAN_INDEX_MINUTE,
+ CHANNEL_SCAN_INDEX_SECOND,
+ TIME_RTC_CHANNEL_MAX,
+};
+
+struct hid_time_state {
+ struct hid_sensor_hub_callbacks callbacks;
+ struct hid_sensor_iio_common common_attributes;
+ struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX];
+ struct rtc_time last_time;
+ spinlock_t lock_last_time;
+ struct completion comp_last_time;
+ struct rtc_time time_buf;
+ struct rtc_device *rtc;
+};
+
+static const u32 hid_time_addresses[TIME_RTC_CHANNEL_MAX] = {
+ HID_USAGE_SENSOR_TIME_YEAR,
+ HID_USAGE_SENSOR_TIME_MONTH,
+ HID_USAGE_SENSOR_TIME_DAY,
+ HID_USAGE_SENSOR_TIME_HOUR,
+ HID_USAGE_SENSOR_TIME_MINUTE,
+ HID_USAGE_SENSOR_TIME_SECOND,
+};
+
+/* Channel names for verbose error messages */
+static const char * const hid_time_channel_names[TIME_RTC_CHANNEL_MAX] = {
+ year, month, day, hour, minute, second,
+};
+
+/* Callback handler to send event after all samples are received and captured
*/
+static int hid_time_proc_event(struct hid_sensor_hub_device *hsdev,
+ unsigned usage_id, void *priv)
+{
+ unsigned long flags;
+ struct hid_time_state *time_state = platform_get_drvdata(priv);
+
+ spin_lock_irqsave(time_state-lock_last_time,
Re: [PATCH v3 2/3] mtd: devices: elm: Add support for ELM error correction
On 12/10/2012 12:13 PM, Philip, Avinash wrote:
On Fri, Dec 07, 2012 at 16:07:23, Nori, Sekhar wrote:
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
[...]
+struct device *elm_request(enum bch_ecc bch_type)
+{
+ struct elm_info *info;
+
+ list_for_each_entry(info, elm_devices, list) {
+ if (info info-dev) {
+ info-bch_type = bch_type;
+ elm_config(info);
+ return info-dev;
+ }
+ }
This will always return the first ELM device probed since you never
remove the allocated device from the list.
But now I realized that, there is no mechanism of freeing the requested
resource.
Right. You essentially want to assign an ELM instance to work with a
given instance of GPMC and that could be done statically too. Just pass
phandle of ELM node in GPMC DT data?
So I will add mechanism to request ELM module successfully only if ELM
module is not requested already and add mechanism to free it, on NAND
driver module unload (loadable module support). This way ELM driver
can achieve multi instance support.
I wonder why you really need a list?
The prime motivation for the list is the driver should support multi
instances of ELM by removing global symbols.
I still think a request/free API is bit too much for something that will
turn out to be a simple 1-to-1 match anyway. Can you please look at the
phandle suggestion above? I am no DT expert, but I think that will work
for your use case.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Mfd: Initial support for Texas Instruments AIC family of CODECs
Initial support for TI's AIC platform and TLV320AIC3262 CODEC device. The AIC platform provides common interface to series of low power audio CODECS. This MFD core driver instantiates subdevices that help in supporting range of features provided by AIC family of devices. Signed-off-by: Mehar Bajwa mehar.ba...@ti.com --- drivers/mfd/Kconfig | 41 +++ drivers/mfd/Makefile|3 + drivers/mfd/tlv320aic3xxx-core.c| 462 +++ drivers/mfd/tlv320aic3xxx-i2c.c | 97 ++ drivers/mfd/tlv320aic3xxx-irq.c | 234 ++ drivers/mfd/tlv320aic3xxx-spi.c | 96 ++ include/linux/mfd/tlv320aic3262-registers.h | 312 ++ include/linux/mfd/tlv320aic3xxx-core.h | 153 + include/linux/mfd/tlv320aic3xxx-registers.h | 75 + 9 files changed, 1473 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/tlv320aic3xxx-core.c create mode 100644 drivers/mfd/tlv320aic3xxx-i2c.c create mode 100644 drivers/mfd/tlv320aic3xxx-irq.c create mode 100644 drivers/mfd/tlv320aic3xxx-spi.c create mode 100644 include/linux/mfd/tlv320aic3262-registers.h create mode 100644 include/linux/mfd/tlv320aic3xxx-core.h create mode 100644 include/linux/mfd/tlv320aic3xxx-registers.h diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 50bbe88..2ecfbad 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -45,6 +45,47 @@ config MFD_88PM805 components like codec device, headset/Mic device under the corresponding menus. +config MFD_AIC3XXX + bool Support for AIC3XXX + select REGMAP + select MFD_CORE + help + Say yes here if you want support for Texas Instruments AIC audio + codec. + You have to select individual I2C or SPI depending on + AIC3XXX interfacing with platform. + +config MFD_AIC3XXX_I2C + bool Support Texas Instruments AIC3XXX platform with I2C + select MFD_AIC3XXX + select REGMAP_I2C + depends on I2C + help + Support for the Texas Instruments TLV320AIC3XXX family of audio SoC + core functionality controlled via I2C. This driver provides common + support for accessing the device, additional drivers must be enabled + in order to use the functionality of the device. + +config MFD_AIC3XXX_SPI + bool Support Texas Instruments AIC3XXX platform with SPI + select MFD_AIC3XXX + select REGMAP_SPI + depends on SPI_MASTER + help + Support for the Texas Instruments TLV320AIC3XXX family of audio SoC + core functionality controlled via SPI. This driver provides common + support for accessing the device, additional drivers must be enabled + in order to use the functionality of the device. + +config MFD_AIC3262 + bool Support Texas Instruments AIC3262 + depends on MFD_AIC3XXX + help + If you say yes here you will get support for Texas Instrument + TLV320AIC3262 low power audio SoC. + Addition driver must be enabled to use this in order to use + functionality on device. + config MFD_SM501 tristate Support for Silicon Motion SM501 ---help--- diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index f2216df..8c97872 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -6,6 +6,9 @@ obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o +obj-$(CONFIG_MFD_AIC3XXX) += tlv320aic3xxx-core.o tlv320aic3xxx-irq.o +obj-$(CONFIG_MFD_AIC3XXX_I2C) += tlv320aic3xxx-i2c.o +obj-$(CONFIG_MFD_AIC3XXX_SPI) += tlv320aic3xxx-spi.o obj-$(CONFIG_MFD_SM501)+= sm501.o obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o diff --git a/drivers/mfd/tlv320aic3xxx-core.c b/drivers/mfd/tlv320aic3xxx-core.c new file mode 100644 index 000..6fd151b --- /dev/null +++ b/drivers/mfd/tlv320aic3xxx-core.c @@ -0,0 +1,462 @@ +/* + * tlv320aic3xxx-core.c -- driver for TLV320AIC3XXX + * + * Author: Mukund Navada nav...@ti.com + * Mehar Bajwa mehar.ba...@ti.com + * + * 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. + * + * 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 St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include linux/kernel.h +#include
Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init
On Wed 12-12-12 18:44:13, Xishi Qiu wrote: On 2012/12/12 18:19, Michal Hocko wrote: On Wed 12-12-12 16:25:59, Jianguo Wu wrote: Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option, system will boot fail. This failure is caused by following code path: setup_hugepagesz hugetlb_add_hstate hugetlb_cgroup_file_init cgroup_add_cftypes kzalloc --slab is *not available* yet For this path, slab is not available yet, so memory allocated will be failed, and cause WARN_ON() in hugetlb_cgroup_file_init(). So I move hugetlb_cgroup_file_init() into hugetlb_init(). I do not think this is a good idea. hugetlb_init is in __init section as well so what guarantees that the slab is initialized by then? Isn't this just a good ordering that makes this working? Hi Michal, __initcall functions will be called in start_kernel() rest_init() // - slab is already kernel_init() kernel_init_freeable() do_basic_setup() do_initcalls() and setup_hugepagesz() will be called in start_kernel() parse_early_param() // - before mm_init() - kmem_cache_init() Is this right? Yes this is right. I just noticed that kmem_cache_init_late is an __init function as well and didn't realize it is called directly. Sorry about the confusion. Anyway I still think it would be a better idea to move the call into the hugetlb_cgroup_create callback where it is more logical IMO but now that I'm looking at other controllers (blk and kmem.tcp) they all do this from init calls as well. So it doesn't make sense to have hugetlb behave differently. So Acked-by: Michal Hocko mho...@suse.cz Thanks! -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OMAP: add pwm driver using dmtimers.
On Wed, Dec 12, 2012 at 07:24:30PM +1100, NeilBrown wrote:
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
I'd prefer some kind of description about the driver here. Also the
subject should be something like:
pwm: Add OMAP support using dual-mode timers
or
pwm: omap: Add PWM support using dual-mode timers
I take this description to mean that OMAP doesn't have dedicated PWM
hardware? Otherwise it might be bad to call this pwm-omap.
Also please use all-caps when referring to PWM devices in prose. A few
other comments inline below.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..7df573a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -85,6 +85,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP
+ tristate OMAP pwm support
OMAP PWM support
diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
[...]
+ *The 'id' number for the device encodes the number of the dm timer
+ *to use, and the polarity of the output.
+ *lsb is '1' of active-high, and '0' for active low
+ *remaining bit a timer number and need to be shifted down before use.
I don't know if this is such a good idea. Usually you number platform
devices sequentially, while this would leave gaps in the numbering. I
know that adding platform data may sound a bit like overkill, but I
really think the added clarity and consistency is worth it.
+#define pr_fmt(fmt) pwm-omap: fmt
You don't seem to be using any of the pr_*() logging functions, so this
isn't needed.
+#include linux/export.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/module.h
+
+#include plat/dmtimer.h
+
+#define DM_TIMER_LOAD_MIN0xFFFE
+
+struct omap_chip {
+ struct platform_device *pdev;
I don't see this field being used anywhere.
+ struct omap_dm_timer*dm_timer;
+ unsigned intpolarity;
The PWM subsystem already has enum pwm_polarity for this.
+ const char *label;
This isn't used anywhere either.
+
+ unsigned intduty_ns, period_ns;
+ struct pwm_chip chip;
+};
+
+#define to_omap_chip(chip) container_of(chip, struct omap_chip, chip)
+
+#define pwm_dbg(_pwm, msg...) dev_dbg((_pwm)-pdev-dev, msg)
This is never used.
+
+/**
+ * pwm_calc_value - determines the counter value for a clock rate and period.
Nit: You should either start the sentence with a capital or not
terminate it with a full stop.
+ * @clk_rate: The clock rate, in Hz, of the PWM's clock source to compute the
+ *counter value for.
+ * @ns: The period, in nanoseconds, to computer the counter value for.
compute
+ *
+ * Returns the PWM counter value for the specified clock rate and period.
+ */
+static inline int pwm_calc_value(unsigned long clk_rate, int ns)
+{
+ const unsigned long nanoseconds_per_second = 10;
Maybe use NSEC_PER_SEC instead?
+ int cycles;
+ __u64 c;
I think for in-kernel use, the custom is to stick with simply u64.
+
+ c = (__u64)clk_rate * ns;
+ do_div(c, nanoseconds_per_second);
+ cycles = c;
+
+ return DM_TIMER_LOAD_MIN - cycles;
Can't you just do DM_TIMER_LOAD_MIN - c and get rid of the cycles
variable altogether?
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
+
+ /* Enable the counter--always--before attempting to write its
+ * registers and then set the timer to its minimum load value to
+ * ensure we get an overflow event right away once we start it.
+ */
Block comments should be in the following format:
/*
* foo...
* bar...
*/
+
+ omap_dm_timer_enable(omap-dm_timer);
+ omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN);
+ omap_dm_timer_start(omap-dm_timer);
+ omap_dm_timer_disable(omap-dm_timer);
So omap_dm_timer_disable() doesn't actually stop the timer? It just
disables the access to the registers?
+ return status;
return 0; and drop the status variable.
+static int omap_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+int duty_ns, int period_ns)
+{
+ struct omap_chip *omap = to_omap_chip(chip);
+ int status = 0;
This one can be dropped as well.
+ const bool enable = true;
+ const bool autoreload = true;
+ const bool toggle = true;
+ const int trigger =
[PATCH] x86: Add support for 64bit get_user() on x86-32
From: Ville Syrjälä ville.syrj...@linux.intel.com
Implement __get_user_8() for x86-32. It will return the
64bit result in edx:eax register pair, and ecx is used
to pass in the address and return the error value.
For consistency, change the register assignment for all
other __get_user_x() variants, so that address is passed in
ecx/rcx, the error value is returned in ecx/rcx, and eax/rax
contains the actual value.
This is a partial refresh of a patch [1] by Jamie Lokier from
2004. Only the minimal changes to implement 64bit get_user()
were picked from the original patch.
[1] http://article.gmane.org/gmane.linux.kernel/198823
Cc: Jamie Lokier ja...@shareable.org
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
arch/x86/include/asm/uaccess.h | 17 ++--
arch/x86/kernel/i386_ksyms_32.c |1 +
arch/x86/lib/getuser.S | 82 ++
3 files changed, 69 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 7ccf8d1..3f4387e 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -127,7 +127,7 @@ extern int __get_user_bad(void);
#define __get_user_x(size, ret, x, ptr) \
asm volatile(call __get_user_ #size \
-: =a (ret), =d (x) \
+: =c (ret), =a (x) \
: 0 (ptr)) \
/* Careful: we have to cast the result to the type of the pointer
@@ -151,8 +151,11 @@ extern int __get_user_bad(void);
* On error, the variable @x is set to zero.
*/
#ifdef CONFIG_X86_32
-#define __get_user_8(__ret_gu, __val_gu, ptr) \
- __get_user_x(X, __ret_gu, __val_gu, ptr)
+#define __get_user_8(ret, x, ptr)\
+ asm volatile(call __get_user_8 \
+: =c (ret), =A (x) \
+: 0 (ptr)) \
+
#else
#define __get_user_8(__ret_gu, __val_gu, ptr) \
__get_user_x(8, __ret_gu, __val_gu, ptr)
@@ -162,6 +165,7 @@ extern int __get_user_bad(void);
({ \
int __ret_gu; \
unsigned long __val_gu; \
+ unsigned long long __val_gu8; \
__chk_user_ptr(ptr);\
might_fault(); \
switch (sizeof(*(ptr))) { \
@@ -175,13 +179,16 @@ extern int __get_user_bad(void);
__get_user_x(4, __ret_gu, __val_gu, ptr); \
break; \
case 8: \
- __get_user_8(__ret_gu, __val_gu, ptr); \
+ __get_user_8(__ret_gu, __val_gu8, ptr); \
break; \
default:\
__get_user_x(X, __ret_gu, __val_gu, ptr); \
break; \
} \
- (x) = (__typeof__(*(ptr)))__val_gu; \
+ if (sizeof(*(ptr)) == 8)\
+ (x) = (__typeof__(*(ptr)))__val_gu8;\
+ else\
+ (x) = (__typeof__(*(ptr)))__val_gu; \
__ret_gu; \
})
diff --git a/arch/x86/kernel/i386_ksyms_32.c b/arch/x86/kernel/i386_ksyms_32.c
index 9c3bd4a..0fa6912 100644
--- a/arch/x86/kernel/i386_ksyms_32.c
+++ b/arch/x86/kernel/i386_ksyms_32.c
@@ -26,6 +26,7 @@ EXPORT_SYMBOL(csum_partial_copy_generic);
EXPORT_SYMBOL(__get_user_1);
EXPORT_SYMBOL(__get_user_2);
EXPORT_SYMBOL(__get_user_4);
+EXPORT_SYMBOL(__get_user_8);
EXPORT_SYMBOL(__put_user_1);
EXPORT_SYMBOL(__put_user_2);
diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
index 156b9c8..38afef0 100644
--- a/arch/x86/lib/getuser.S
+++ b/arch/x86/lib/getuser.S
@@ -14,12 +14,11 @@
/*
* __get_user_X
*
- * Inputs: %[r|e]ax contains the address.
- * The register is modified, but all changes are undone
- * before returning because the C code doesn't know about it.
+ * Inputs: %[r|e]cx contains the address.
*
- * Outputs:%[r|e]ax is error code (0 or -EFAULT)
- * %[r|e]dx contains zero-extended value
+ * Outputs:%[r|e]cx is error code (0 or -EFAULT)
+ *
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
On Wed, Dec 12, 2012 at 11:11 AM, Benoit Cousson b-cous...@ti.com wrote: Hi Javier, On 12/12/2012 09:25 AM, Javier Martinez Canillas wrote: On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v3 of the patch-set that solves issues pointed out by Enric Balletbo and Benoit Cousson. The patch-set is composed of the following patches: [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module Best regards, Javier -- Hi Benoit and Tony, Any comments on these? Nope, that's fine. I'll applied the series for 3.9. Thanks, Benoit Great, thanks a lot for! Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] sched: rt: fix selecting runqueue for task to be pushed
On Wed, Dec 12, 2012 at 10:46 AM, Steven Rostedt rost...@goodmis.org wrote: On Tue, 2012-12-11 at 20:54 -0500, Steven Rostedt wrote: I'm actually thinking that that test should always fail. The cpupri_find() does a scan of all priorities up to but not including the current task's priority. If cpupri_find() finds a mask, it means that it found CPUs that are running only tasks of lower priority than the task we are checking. Which means, it should never include the task's CPU, as that CPU should have a higher priority than what is being returned by lowest_mask. If it can't find a set of CPUs of lower priority, it should return false, and the find_lowest_rq() should exit. I'll add a WARN_ON_ONCE() there, and see if I can trigger it. :-/ Ah, for select_task_rq_rt() it can get that CPU, because it's called in the wakeup path before the task is added into the CPUs priority. And we definitely want the current CPU in that case. Hm ... the latency of the woken task increases iff we overload its runqueue, no? Hillf -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: core: if voltage scaling fails, restore original voltage values
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
---
drivers/regulator/core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..c347fd0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
{
struct regulator_dev *rdev = regulator-rdev;
int ret = 0;
+ int old_min_uV, old_max_uV;
mutex_lock(rdev-mutex);
@@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
ret = regulator_check_voltage(rdev, min_uV, max_uV);
if (ret 0)
goto out;
+
+ /* restore original values in case of error */
+ old_min_uV = regulator-min_uV;
+ old_max_uV = regulator-max_uV;
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
ret = regulator_check_consumers(rdev, min_uV, max_uV);
if (ret 0)
- goto out;
+ goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
-
+ if (ret 0)
+ goto out2;
+
out:
mutex_unlock(rdev-mutex);
return ret;
+out2:
+ regulator-min_uV = old_min_uV;
+ regulator-max_uV = old_max_uV;
+ mutex_unlock(rdev-mutex);
+ return ret;
}
EXPORT_SYMBOL_GPL(regulator_set_voltage);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] gpio: twl4030: Correct status reporting for outputs
On Wed, Dec 12, 2012 at 11:12 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: Hi Grant, On 12/07/2012 09:09 AM, Linus Walleij wrote: On Thu, Dec 6, 2012 at 11:52 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: As Grant commneted on the first version: https://lkml.org/lkml/2012/12/5/53 Introduce bitfields to cache the directionand output status of the pins so we can report them correctly. To do this I did some cleanup within the driver to get rid of the global variables and moved them under a private structure, changed the locking as well to protect the bitfield operation. As a last patch I added a note that the PWMA/B handling should not be in this driver at all. This looks good to me: Acked-by: Linus Walleij linus.wall...@linaro.org Since Grant was requesting the changes I'll let him decide to merge. Would you have time to take a look at this set? I will take a look at it this week, but I cannot pick it up for v3.8 unless it is a regression bug fix from v3.6. It will have to wait for v3.9 and it can be merged into linux-next after the v3.8 merge window closes. g. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: core: if voltage scaling fails, restore original
And after a second look it's clear what's going on:
[...]
[5.575744] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV -- 800 MHz, 1325 mV
[5.582946] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
[5.590332] cpu cpu0: omap_target: unable to scale voltage up.
[1]
[5.596649] notification 1 of frequency transition to 30 kHz
[5.603179] FREQ: 30 - CPU: 0
[5.606597] governor: change or update limits
[5.611572] __cpufreq_governor for CPU 0, event 3
[5.616699] setting to 80 kHz because of event 3
[5.622039] target for CPU 0: 80 kHz, relation 1
[5.627441] request for target 80 kHz (relation: 1) for cpu 0
[5.634063] target is 2 (80 kHz, 2)
[5.638183] notification 0 of frequency transition to 80 kHz
[5.644775] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV -- 800 MHz, 1325 mV
[2]
[hangs here]
first time[1] it tries to ramp up frequency (and thus voltage),
regulator_set_voltage() returns an error and we exit:
omap-cpufreq.c::omap_target():
...
dev_dbg(mpu_dev, cpufreq-omap: %u MHz, %ld mV -- %u MHz, %ld mV\n,
freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
freqs.new / 1000, volt ? volt / 1000 : -1);
/* scaling up? scale voltage before frequency */
if (mpu_reg (freqs.new freqs.old)) {
r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r 0) {
dev_warn(mpu_dev, %s: unable to scale voltage up.\n,
__func__);
freqs.new = freqs.old;
goto done;
}
}
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
...
but inside regulator_set_voltage(), we save the new regulator voltage before
actually ramping up:
core.c::regulator_set_voltage():
...
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
ret = regulator_check_consumers(rdev, min_uV, max_uV);
if (ret 0)
goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV); -- ERROR!!!
if (ret 0)
goto out2;
...
and by the time we try to change frequency again[2], regulator_set_voltage()
is a noop because it thinks we are already at the desired voltage:
core.c::regulator_set_voltage():
...
/* If we're setting the same range as last time the change
* should be a noop (some cpufreq implementations use the same
* voltage for multiple frequencies, for example).
*/
if (regulator-min_uV == min_uV regulator-max_uV == max_uV)
goto out;
...
and as a consequence, in omap_target(), we call clk_set_rate() with
the wrong voltage.
The attached patch restore the original regulator voltage values in case
of an error.
CCing stable@ since it predates 2.6.38rc1 when the noop optimization was
introduced:
commit 95a3c23ae620c1b4c499746e70f4034bdc067737
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date: Thu Dec 16 15:49:37 2010 +
regulator: Optimise out noop voltage changes
Paolo Pisati (1):
regulator: core: if voltage scaling fails, restore original voltage
values
drivers/regulator/core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/pinctrl/pinctrl-at91.c: convert kfree to devm_kfree
On 11:58 Tue 11 Dec , Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
The function at91_dt_node_to_map is ultimately called by the function
pinctrl_get, which is an exported function. Since it is possible that this
function is not called from within a probe function, for safety, the kfree
is converted to a devm_kfree, to both free the data and remove it from the
device in a failure situation.
A newline is added in the call to devm_kfree to avoid exceeding the 80
character limit.
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/pinctrl/pinctrl-at91.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index c5e7571..0da8a5f 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -255,7 +255,8 @@ static int at91_dt_node_to_map(struct pinctrl_dev
*pctldev,
}
map_num += grp-npins;
- new_map = devm_kzalloc(pctldev-dev, sizeof(*new_map) * map_num,
GFP_KERNEL);
+ new_map = devm_kzalloc(pctldev-dev, sizeof(*new_map) * map_num,
+GFP_KERNEL);
not related please drop
if (!new_map)
return -ENOMEM;
@@ -265,7 +266,7 @@ static int at91_dt_node_to_map(struct pinctrl_dev
*pctldev,
/* create mux map */
parent = of_get_parent(np);
if (!parent) {
- kfree(new_map);
+ devm_kfree(pctldev-dev, new_map);
ok
return -EINVAL;
}
new_map[0].type = PIN_MAP_TYPE_MUX_GROUP;
Best Regards,
J.
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: vexpress: Add missing n_voltages setting
On Tue, 2012-12-11 at 23:39 +, Axel Lin wrote:
I was thinking below patch to fix the issue:
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index cd1b201..891bc96 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1885,9 +1885,14 @@ int regulator_can_change_voltage(struct
regulator *regulator)
struct regulator_dev*rdev = regulator-rdev;
if (rdev-constraints
- rdev-constraints-valid_ops_mask REGULATOR_CHANGE_VOLTAGE
- rdev-desc-n_voltages 1)
- return 1;
+ rdev-constraints-valid_ops_mask REGULATOR_CHANGE_VOLTAGE) {
+ if (rdev-desc-n_voltages 1)
+ return 1;
+ if (rdev-desc-continuous_voltage_range
+ rdev-constraints-min_uV rdev-constraints-max_uV)
+ return 1;
+
+ }
return 0;
}
I wouldn't say so, although of course it's not my call. To my ming the
(valid_ops_mask REGULATOR_CHANGE_VOLTAGE) should really be the only
condition here. I'd even risk saying that checking n_voltages 1 or
continuous_voltage_range is a bit over the top. So maybe the correct
thing to do would be:
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index cd1b201..38fe3a2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1885,8 +1885,7 @@ int regulator_can_change_voltage(struct regulator
*regulator)
struct regulator_dev*rdev = regulator-rdev;
if (rdev-constraints
- rdev-constraints-valid_ops_mask REGULATOR_CHANGE_VOLTAGE
- rdev-desc-n_voltages 1)
+ rdev-constraints-valid_ops_mask REGULATOR_CHANGE_VOLTAGE)
return 1;
return 0;
And before you ask - I initialize regulator data from the device tree,
so I get all constraints and valid_ops_mask set by
of_get_regulator_init_data() and of_get_regulation_constraints().
But then I think if the core relies on n_voltages settings, why not
set n_voltages in the driver
even if a driver has continuous_voltage_range set.
I'm not sure that you can say that the core relies on n_voltages. This
is probably a question for Mark, but to my mind it's one of the possible
cases.
Maybe I'm still not full understand about continuous_voltage_range,
A driver with continuous_voltage_range looks special to me:
1. regulator_count_voltages() always return 0
2. regulator_list_voltage() returns -EINVAL. ( Does it make sense to
not implement list_voltage ? )
Because it doesn't have discreet operating points. The count/list
voltage interface is supposed to represent a regulator that can be set
to (for example) 1V, 2V, 3V, 4V or 5V. My regulator (example again)
can be set to any value between 1V and 5V, for example 2.3456. Why would
you like to enumerate all thousands of possible values between 1 and 5?
3. vexpress_regulator_set_voltage() looks does not have voltage range
checking:
Given init_data-constraints.min_uV= 5
init_data-constraints.max_uV=6
What happen if vexpress_regulator_set_voltage is called with
min_uV=8, max_uV=10?
The core takes care of that - have a look at regulator_set_voltage()
(hint: regulator_check_voltage ;-). The driver can assume that it will
get values within the constraints.
4. It's unclear to me if only one of
init_data-constraints-min_uV/init_data-constraints-max_uV is set.
Again, from my point of view it's the core's problem. I don't think it's
a legal case though.
Paweł
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [[PATCH v9 3/3] 1/1] virtio_console: Remove buffers from out_vq at port removal
On (Wed) 12 Dec 2012 [10:31:04], Rusty Russell wrote: Amit Shah amit.s...@redhat.com writes: On (Tue) 11 Dec 2012 [09:39:41], Rusty Russell wrote: Amit Shah amit.s...@redhat.com writes: On (Fri) 16 Nov 2012 [11:22:09], Rusty Russell wrote: Amit Shah amit.s...@redhat.com writes: From: Sjur Brændeland sjur.brandel...@stericsson.com Remove buffers from the out-queue when a port is removed. Rproc_serial communicates with remote processors that may crash and leave buffers in the out-queue. The virtio serial ports may have buffers in the out-queue as well, e.g. for non-blocking ports and the host didn't consume them yet. [Amit: Remove WARN_ON for generic ports case.] Signed-off-by: Sjur Brændeland sjur.brandel...@stericsson.com Signed-off-by: Amit Shah amit.s...@redhat.com I already have this in my pending queue; I've promoted it to my virtio-next branch now. Rusty, I still see this series in your pending queue, not in virtio-next. Did anything change in the meantime? Hmm: 40e625ac50f40d87ddba93280d0a503425aa68e9? I'm sorry, I meant the remoteproc code, not this patch. Still waiting for v9, AFIACT? Instead of sending all patches marked v9, just this patch was re-spun. I think you can just pick up patches 1 and 2 from v8 (they have my acked-by), and patch 3 was an earlier version of this one, which should just be dropped. Amit -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
