Re: sparc64 WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160()
Hi, On Mon, Jun 17, 2013 at 08:32:25AM +0300, Aaro Koskinen wrote: > On Mon, Jun 17, 2013 at 12:06:00AM +0300, Meelis Roos wrote: > > Got this in 3.10-rc6 whil testing debian unstable upgrade with aptitude. > > 3.10-rc5 did not exhibit this (nor any other kernel recently tried, > > including most -rc's). Does not seem to be reproducible. > > I get this regularly on Ultrasparc during long compilations. It's been > there with all recent kernels (probably at least since 3.8). Latest I > saw with 3.10-rc5. Two examples: [ 417.006586] [ cut here ] [ 417.065813] WARNING: at /home/aaro/los/work/shared/linux-v3.10-rc5/mm/mmap.c:2757 exit_mmap+0x134/0x160() [ 417.189209] Modules linked in: [ 417.229203] CPU: 0 PID: 1787 Comm: ld Not tainted 3.10.0-rc5-ultra #1 [ 417.310031] Call Trace: [ 417.342875] [004b5ef4] exit_mmap+0x134/0x160 [ 417.406941] [0044ef40] mmput+0x40/0xe0 [ 417.464591] [00454b38] do_exit+0x1b8/0x800 [ 417.526429] [00455d6c] do_group_exit+0x2c/0xa0 [ 417.592383] [00455df4] SyS_exit_group+0x14/0x20 [ 417.659257] [00406074] linux_sparc_syscall32+0x34/0x40 [ 417.733400] ---[ end trace b92a93fbf6d0204a ]--- [ 417.791913] BUG: Bad rss-counter state mm:f8001ebbb740 idx:1 val:1 [ 1674.164634] [ cut here ] [ 1674.218933] WARNING: at /home/aaro/los/work/shared/linux-v3.10-rc5/mm/mmap.c:2757 exit_mmap+0x134/0x160() [ 1674.333505] Modules linked in: [ 1674.369872] CPU: 0 PID: 26306 Comm: date Not tainted 3.10.0-rc5-ultra #1 [ 1674.450075] Call Trace: [ 1674.479245] [004b5ef4] exit_mmap+0x134/0x160 [ 1674.539661] [0044ef40] mmput+0x40/0xe0 [ 1674.593827] [00454b38] do_exit+0x1b8/0x800 [ 1674.652140] [00455d6c] do_group_exit+0x2c/0xa0 [ 1674.714630] [00455df4] SyS_exit_group+0x14/0x20 [ 1674.778172] [00406074] linux_sparc_syscall32+0x34/0x40 [ 1674.848993] ---[ end trace 77928f0ca6684101 ]--- [ 1674.904199] BUG: Bad rss-counter state mm:f8000f0c9d40 idx:0 val:1 A. -- 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] gpio: msm-v1: Remove errant __devinit to fix compile
On Tue, Jun 4, 2013 at 9:20 PM, Stephen Boyd wrote: > Commit 7bce696 (gpio: Make gpio-msm-v1 into a platform driver, > 2013-03-04) was based on an older kernel where __devinit still > existed. Remove the erroneous __devinit marking. > > Cc: David Brown > Signed-off-by: Stephen Boyd Patch applied. Yours, Linus Walleij -- 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] x86/iommu: remove useless code
From: "Li, Zhen-Hua"
In intel-iommu.c, the function dma_pte_addr does not change the
value of its parameter (pte). So it is useless if it nobody catches
its return value.
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel-iommu.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index b4f0e28..d9d378b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -809,7 +809,6 @@ static struct dma_pte *pfn_to_dma_pte(struct dmar_domain
*domain,
/* Someone else set it while we were thinking;
use theirs. */
free_pgtable_page(tmp_page);
} else {
- dma_pte_addr(pte);
domain_flush_cache(domain, pte, sizeof(*pte));
}
}
--
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] gpio: devres: make comments proper
On Tue, Jun 4, 2013 at 5:48 PM, Wolfram Sang wrote: > The free-function mentioned "interrupt" instead of "GPIO". While we are > here, use "GPIO" (capital letters) consistently. > > Signed-off-by: Wolfram Sang Patch applied. Yours, Linus Walleij -- 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 5/6] GPIO: xilinx: Enable driver for Xilinx zynq
On Mon, Jun 3, 2013 at 2:31 PM, Michal Simek wrote: > Enable gpio driver for usage on Xilinx ARM zynq platform. > > Signed-off-by: Michal Simek > --- > Changes in v2: > - New patch in this series Patch applied. Yours, Linus Walleij -- 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 6/6] DT: Add documentation for gpio-xilinx
On Mon, Jun 3, 2013 at 2:31 PM, Michal Simek wrote:
> Describe gpio-xilinx binding.
>
> Signed-off-by: Michal Simek
> ---
> Changes in v2:
> - Extend description
Thanks, patch applied but look into this:
> +Optional properties:
> +- interrupts : Interrupt mapping for GPIO IRQ.
> +- interrupt-parent : Phandle for the interrupt controller that
> + services interrupts for this device.
> +- xlnx,all-inputs : if n-th bit is setup, GPIO-n is input
> +- xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1
> +- xlnx,gpio-width : gpio width
> +- xlnx,tri-default : if n-th bit is 1, GPIO-n is in tristate mode
> +- xlnx,is-dual : if 1, controller also uses the second channel
If is present, xlnx,is-dual;
> +Example:
> +gpio: gpio@4000 {
> + #gpio-cells = <2>;
> + compatible = "xlnx,xps-gpio-1.00.a";
> + gpio-controller ;
> + interrupt-parent = <_0_intc>;
> + interrupts = < 6 2 >;
> + reg = < 0x4000 0x1 >;
> + xlnx,all-inputs = <0x0>;
> + xlnx,all-inputs-2 = <0x0>;
> + xlnx,dout-default = <0x0>;
> + xlnx,dout-default-2 = <0x0>;
> + xlnx,gpio-width = <0x2>;
> + xlnx,gpio2-width = <0x2>;
> + xlnx,interrupt-present = <0x1>;
> + xlnx,is-dual = <0x1>;
xlnx,is-dual;
I'm not giving up on this suggestion.
Test it please...
Yours,
Linus Walleij
--
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 4/6] GPIO: xilinx: Use BIT macro
On Mon, Jun 3, 2013 at 2:31 PM, Michal Simek wrote: > Use BIT macro from linux/bitops.h. > > Signed-off-by: Michal Simek > --- > Changes in v2: > - New patch in this series suggested by Linus Valleij Patch applied. Yours, Linus Walleij -- 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] GPIO: xilinx: Use __raw_readl/__raw_writel IO functions
On Mon, Jun 3, 2013 at 2:31 PM, Michal Simek wrote: > This driver can be used on Xilinx ARM Zynq platform > where in_be32/out_be32 functions are not implemented. > Use __raw_readl/__raw_writel functions which are > implemented on Microblaze and PowerPC. > For ARM readl/writel functions are used instead. > > The correct way how to implement this is to detect > endians directly on IP. But for the gpio case > without interrupt connected(it means without > interrupt logic) there are just 2 registers > data and tristate where auto detection can't be done. > > Signed-off-by: Michal Simek > --- > Changes in v2: > - New patch in this series > > I have chosen to use readl/writel for ARM because > of barriers and keep __raw versions for microblaze > and ppc where this is not a problem. > The reason why in_be32/out_be32 can't be used > is that it won't work on Microblaze LE when > I fix Microblaze IO function implementation which > is broken right now. Makes perfect sense. Patch applied. Yours, Linus Walleij -- 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 2/6] GPIO: xilinx: Add support for dual channel
On Mon, Jun 3, 2013 at 2:31 PM, Michal Simek wrote:
> Supporting the second channel in the driver.
> Offset is 0x8 and both channnels share the same
> IRQ.
>
> Signed-off-by: Michal Simek
>
> ---
> Changes in v2:
> - Use kernel doc format - suggested by Linus Walleij
> - Do not use __raw_readl/__raw_writel IO in this patch
> - Use of_property_read_u32 helper function
> - Use BIT()
> - Change patch subject
Patch is looking overall nice and improves the kernel so
applied.
But check this:
> @@ -202,6 +230,57 @@ static int xgpio_of_probe(struct device_node *np)
>np->full_name, status);
> return status;
> }
> +
> + pr_info("XGpio: %s: registered, base is %d\n", np->full_name,
> + chip->mmchip.gc.base);
> +
> + tree_info = of_get_property(np, "xlnx,is-dual", NULL);
> + if (tree_info && be32_to_cpup(tree_info)) {
Doesn't this work:
if (of_property_read_bool(np, "xlnx,is-dual")) {
(...)
?
Yours,
Linus Walleij
--
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 1/3] cpufreq: Add boost frequency support in core
On 14 June 2013 13:08, Lukasz Majewski wrote:
> Changes for v2:
> - Removal of cpufreq_boost structure and move its fields to cpufreq_driver
> structure
> - Flag to indicate if global boost attribute is already defined
> - Extent the pr_{err|debbug} functions to show current function names
>
> Changes for v3:
> - Method for reading boost status
> - Removal of cpufreq_frequency_table_max()
> - Extent cpufreq_frequency_table_cpuinfo() to support boost parameter
> - boost_supported flag added to cpufreq_driver struct
> - "boost" sysfs attribute control flag removed
> - One global flag describing state of the boost defined at cpufreq core
> - Rename cpufreq_driver's low_level_boost field to set_boost_freq()
> - Usage of cpufreq_sysfs_{remove|add}_file() routines
Latest change log first please.
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2ce86ed..02e57db 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -40,6 +40,7 @@
> * also protects the cpufreq_cpu_data array.
> */
> static struct cpufreq_driver *cpufreq_driver;
> +static bool cpufreq_boost_enabled;
> static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
> #ifdef CONFIG_HOTPLUG_CPU
> /* This one keeps track of the previously set governor of a removed CPU */
> @@ -315,6 +316,30 @@ EXPORT_SYMBOL_GPL(cpufreq_notify_transition);
> /*
> * SYSFS INTERFACE *
> */
> +ssize_t show_boost(struct kobject *kobj,
> +struct attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", cpufreq_boost_enabled);
> +}
> +
> +static ssize_t store_boost(struct kobject *kobj, struct attribute *attr,
> + const char *buf, size_t count)
> +{
> + int ret, enable;
> +
> + ret = sscanf(buf, "%d", );
> + if (ret != 1 || enable < 0 || enable > 1)
> + return -EINVAL;
> +
> + if (cpufreq_boost_trigger_state(enable)) {
> + pr_err("%s: Cannot %sable boost!\n", __func__,
> + enable ? "en" : "dis");
Please don't use %sable as discussed earlier.
> + return -EINVAL;
> + }
> +
> + return count;
> +}
> +define_one_global_rw(boost);
>
> static struct cpufreq_governor *__find_governor(const char *str_governor)
> {
> @@ -1896,6 +1921,55 @@ static struct notifier_block __refdata
> cpufreq_cpu_notifier = {
> };
>
> /*
> + * BOOST *
> + */
> +int cpufreq_boost_trigger_state(int state)
> +{
> + struct cpufreq_frequency_table *freq_table;
> + struct cpufreq_policy *policy;
> + unsigned long flags;
> + int ret = 0, cpu;
> +
> + if (!cpufreq_driver->boost_supported)
> + return -ENODEV;
This can't happen. sysfs directory is present only when we
have boost supported.
> + if (cpufreq_boost_enabled != state) {
> + if (cpufreq_driver->set_boost_freq) {
> + ret = cpufreq_driver->set_boost_freq(state);
I thought this routine was for setting boost frequency and not
for enabling boost feature. If boost has to be enabled separately
then this routine must take care of it while setting freq.
So, in other words, this must not be called here.
> + if (ret) {
> + pr_err("%s: BOOST cannot enable (%d)\n",
> + __func__, ret);
> + return ret;
> + }
> + }
> +
> + for_each_possible_cpu(cpu) {
> + policy = cpufreq_cpu_get(cpu);
In case this code is required, it would make more sense to keep list
of all available policies, which we can iterate through.
> + freq_table = cpufreq_frequency_get_table(cpu);
> + if (policy && freq_table) {
> + write_lock_irqsave(_driver_lock,
> flags);
> + cpufreq_frequency_table_cpuinfo(policy,
> + freq_table,
> + state);
We obviously don't need the last param to this routine and so bunch
of changes you did in this patch.
cpufreq_frequency_table_cpuinfo() can itself check if boost is enabled
or not.
> + cpufreq_boost_enabled = state;
> + write_unlock_irqrestore(_driver_lock,
> + flags);
> + }
> + }
I am not
Re: [PATCH v3 0/3] cpufreq:boost: CPU Boost mode support
On Mon, 17 Jun 2013 08:50:30 +0530, Viresh Kumar wrote: > On 14 June 2013 13:08, Lukasz Majewski wrote: > > arch/arm/mach-s3c24xx/cpufreq.c |2 +- > > arch/powerpc/platforms/pasemi/cpufreq.c |2 +- > > arch/powerpc/platforms/powermac/cpufreq_32.c |2 +- > > arch/powerpc/platforms/powermac/cpufreq_64.c |2 +- > > drivers/cpufreq/acpi-cpufreq.c | 62 > > +++--- drivers/cpufreq/arm_big_little.c > > |3 +- drivers/cpufreq/blackfin-cpufreq.c |2 +- > > drivers/cpufreq/cpufreq-cpu0.c |2 +- > > drivers/cpufreq/cpufreq.c| 87 > > ++ > > drivers/cpufreq/cris-artpec3-cpufreq.c |2 +- > > drivers/cpufreq/cris-etraxfs-cpufreq.c |2 +- > > drivers/cpufreq/davinci-cpufreq.c|2 +- > > drivers/cpufreq/dbx500-cpufreq.c |2 +- > > drivers/cpufreq/e_powersaver.c |3 +- > > drivers/cpufreq/elanfreq.c |2 +- > > drivers/cpufreq/exynos-cpufreq.c |7 ++- > > drivers/cpufreq/exynos5440-cpufreq.c |2 +- > > drivers/cpufreq/freq_table.c | 44 ++--- > > drivers/cpufreq/ia64-acpi-cpufreq.c |2 +- > > drivers/cpufreq/imx6q-cpufreq.c |2 +- > > drivers/cpufreq/kirkwood-cpufreq.c |3 +- > > drivers/cpufreq/longhaul.c |2 +- > > drivers/cpufreq/loongson2_cpufreq.c |2 +- > > drivers/cpufreq/maple-cpufreq.c |2 +- > > drivers/cpufreq/omap-cpufreq.c |2 +- > > drivers/cpufreq/p4-clockmod.c|2 +- > > drivers/cpufreq/powernow-k6.c|2 +- > > drivers/cpufreq/powernow-k7.c|2 +- > > drivers/cpufreq/powernow-k8.c|2 +- > > drivers/cpufreq/ppc_cbe_cpufreq.c|2 +- > > drivers/cpufreq/pxa2xx-cpufreq.c |4 +- > > drivers/cpufreq/pxa3xx-cpufreq.c |2 +- > > drivers/cpufreq/s3c2416-cpufreq.c|2 +- > > drivers/cpufreq/s3c64xx-cpufreq.c|2 +- > > drivers/cpufreq/s5pv210-cpufreq.c|2 +- > > drivers/cpufreq/sc520_freq.c |2 +- > > drivers/cpufreq/sh-cpufreq.c |2 +- > > drivers/cpufreq/sparc-us2e-cpufreq.c |2 +- > > drivers/cpufreq/sparc-us3-cpufreq.c |2 +- > > drivers/cpufreq/spear-cpufreq.c |3 +- > > drivers/cpufreq/speedstep-centrino.c |2 +- > > drivers/cpufreq/speedstep-ich.c |2 +- > > drivers/cpufreq/speedstep-smi.c |2 +- > > drivers/cpufreq/tegra-cpufreq.c |4 +- > > include/linux/cpufreq.h | 18 +- 45 files > > changed, 211 insertions(+), 95 deletions(-) > > Wow!! I am shocked to see these many files getting updated :) Hmm, CPUFREQ framework is quite popular :-). Changing this one particular function, seemed to be the best solution. -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- 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 1/6] GPIO: xilinx: Simplify driver probe function
On Mon, Jun 3, 2013 at 2:31 PM, Michal Simek wrote: > Simplification is done by using OF helper function > which increase readability of code and remove > (if (var) var = be32_to_cpup;) assignment. > > Signed-off-by: Michal Simek > --- > Changes in v2: > - New patch in this series Patch applied. Nice cleanup! Yours, Linus Walleij -- 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/3] ARM: msm: Remove gpiomux-v2 and re-organize MSM_GPIOMUX configs
On Sat, Jun 1, 2013 at 2:21 AM, Rohit Vaswani wrote: > Remove gpiomux-v2 as it's not being used and make way for future improvements. > > Signed-off-by: Rohit Vaswani > --- > arch/arm/mach-msm/Kconfig| 13 +++- > arch/arm/mach-msm/Makefile |6 +-- > arch/arm/mach-msm/gpiomux-8x60.c | 19 > arch/arm/mach-msm/gpiomux-v2.c | 25 --- > arch/arm/mach-msm/gpiomux-v2.h | 61 > -- > arch/arm/mach-msm/gpiomux.c | 15 + > arch/arm/mach-msm/gpiomux.h |5 --- > drivers/gpio/gpio-msm-v2.c |5 +-- > 8 files changed, 24 insertions(+), 125 deletions(-) > delete mode 100644 arch/arm/mach-msm/gpiomux-8x60.c > delete mode 100644 arch/arm/mach-msm/gpiomux-v2.c > delete mode 100644 arch/arm/mach-msm/gpiomux-v2.h Acked-by: Linus Walleij Yours, Linus Walleij -- 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: manual merge of the driver-core tree with the devicetree tree
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
include/linux/platform_device.h between commit 10dbc5e39a60 ("driver
core: move to_platform_driver to platform_device.h") from the devicetree
tree and commit 9447057eaff8 ("platform_device: use a macro instead of
platform_driver_register") from the driver-core tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/platform_device.h
index 3413897,cd46ee5..000
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@@ -180,10 -180,13 +180,16 @@@ struct platform_driver
const struct platform_device_id *id_table;
};
+#define to_platform_driver(drv) (container_of((drv), struct
platform_driver, \
+ driver))
+
- extern int platform_driver_register(struct platform_driver *);
+ /*
+ * use a macro to avoid include chaining to get THIS_MODULE
+ */
+ #define platform_driver_register(drv) \
+ __platform_driver_register(drv, THIS_MODULE)
+ extern int __platform_driver_register(struct platform_driver *,
+ struct module *);
extern void platform_driver_unregister(struct platform_driver *);
/* non-hotpluggable platform devices may use this so that probe() and
pgp27W49qbY2c.pgp
Description: PGP signature
Re: sparc64 WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160()
Hi, On Mon, Jun 17, 2013 at 12:06:00AM +0300, Meelis Roos wrote: > Got this in 3.10-rc6 whil testing debian unstable upgrade with aptitude. > 3.10-rc5 did not exhibit this (nor any other kernel recently tried, > including most -rc's). Does not seem to be reproducible. I get this regularly on Ultrasparc during long compilations. It's been there with all recent kernels (probably at least since 3.8). Latest I saw with 3.10-rc5. A. > [ 568.834221] [ cut here ] > [ 568.894907] WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160() > [ 568.971594] Modules linked in: ipv6 tg3 ptp pps_core hwmon > [ 569.043635] CPU: 1 PID: 2952 Comm: aptitude Not tainted 3.10.0-rc6 #85 > [ 569.129412] Call Trace: > [ 569.161440] [004d811c] exit_mmap+0x13c/0x160 > [ 569.227785] [0045680c] mmput.part.62+0xc/0xc0 > [ 569.295258] [0045c25c] exit_mm+0x11c/0x180 > [ 569.359301] [0045dc24] do_exit+0x244/0x340 > [ 569.423354] [0045dea8] do_group_exit+0x28/0xc0 > [ 569.491982] [00469a08] get_signal_to_deliver+0x1c8/0x3a0 > [ 569.572039] [00447874] do_signal32+0x14/0x220 > [ 569.639526] [0042c8e0] do_signal+0x2c0/0x520 > [ 569.705854] [0042d340] do_notify_resume+0x40/0x60 > [ 569.777907] [00404b04] __handle_signal+0xc/0x2c > [ 569.847671] ---[ end trace 4acf84f71c8b5f1b ]--- > [ 569.908406] BUG: Bad rss-counter state mm:f8000dcb6700 idx:1 val:1 > > Full dmesg: > > [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.30.4.a 2010/01/06 14:48' > [0.00] PROMLIB: Root node compatible: > [0.00] Linux version 3.10.0-rc6 (mroos@v210) (gcc version 4.6.4 > (Debian 4.6.4-2) ) #85 SMP Sun Jun 16 16:02:21 EEST 2013 > [0.00] debug: ignoring loglevel setting. > [0.00] bootconsole [earlyprom0] enabled > [0.00] ARCH: SUN4U > [0.00] Ethernet address: 00:03:ba:0a:f3:85 > [0.00] Kernel: Using 2 locked TLB entries for main kernel image. > [0.00] Remapping the kernel... done. > [0.00] OF stdout device is: /pci@1e,60/isa@7/serial@0,3f8 > [0.00] PROM: Built device tree with 77761 bytes of memory. > [0.00] Top of RAM: 0x1000, Total RAM: 0x1000 > [0.00] Memory hole size: 0MB > [0.00] Zone ranges: > [0.00] Normal [mem 0x-0x0fff] > [0.00] Movable zone start for each node > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x-0x0fff] > [0.00] On node 0 totalpages: 32768 > [0.00] Normal zone: 256 pages used for memmap > [0.00] Normal zone: 0 pages reserved > [0.00] Normal zone: 32768 pages, LIFO batch:7 > [0.00] Booting Linux... > [0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,ultra3,mul32,div32] > [0.00] CPU CAPS: [v8plus,vis,vis2] > [0.00] PERCPU: Embedded 6 pages/cpu @f8000f00 s13440 r8192 > d27520 u2097152 > [0.00] pcpu-alloc: s13440 r8192 d27520 u2097152 alloc=1*4194304 > [0.00] pcpu-alloc: [0] 0 1 > [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total > pages: 32512 > [0.00] Kernel command line: root=/dev/sda2 ro mem=256M debug > ignore_loglevel > [0.00] PID hash table entries: 1024 (order: 0, 8192 bytes) > [0.00] Dentry cache hash table entries: 32768 (order: 5, 262144 bytes) > [0.00] Inode-cache hash table entries: 16384 (order: 4, 131072 bytes) > [0.00] Sorting __ex_table... > [0.00] Memory: 253216k available (3248k kernel code, 1032k data, 152k > init) [f800,1000] > [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > [0.00] Hierarchical RCU implementation. > [0.00]Additional per-CPU info printed with stalls. > [0.00] NR_IRQS:255 > [0.00] clocksource: mult[5355] shift[24] > [0.00] clockevent: mult[3126e98] shift[32] > [0.00] Console: colour dummy device 80x25 > [0.00] console [tty0] enabled, bootconsole disabled > [ 33.851595] Calibrating delay using timer specific routine.. 24.00 > BogoMIPS (lpj=120048) > [ 33.851610] pid_max: default: 32768 minimum: 301 > [ 33.851772] Mount-cache hash table entries: 512 > [ 33.854162] CPU 0: synchronized TICK with master CPU (last diff 0 cycles, > maxerr 6 cycles) > [ 33.854242] Brought up 2 CPUs > [ 33.854269] Testing NMI watchdog ... OK. > [ 34.055163] NET: Registered protocol family 16 > [ 34.063864] /pci@1f,70: TOMATILLO PCI Bus Module ver[4:0] > [ 34.063883] /pci@1f,70: PCI IO[7f60100] MEM[7f7] > [ 34.065866] PCI: Scanning PBM /pci@1f,70 > [ 34.066071] schizo f0069c00: PCI host bridge to bus :00 > [ 34.066093] pci_bus :00: root bus resource [io > 0x7f60100-0x7f601ff] (bus address [0x-0xff]) > [ 34.066111] pci_bus :00: root bus resource [mem >
Re: [PATCH 1/2] GPIO: Add support for dual channel in gpio-xilinx.c
On Fri, May 31, 2013 at 9:34 AM, Michal Simek wrote: > On 05/31/2013 09:14 AM, Linus Walleij wrote: >> It's OK, but fix the boolean member so as to just needing to >> be present: >> >> xlnx,is-dual; >> >> Rather than >> >> xlnx,is-dual = <1>; > > Surely I can do it but it means to change our BSP and because > this IP is used on Microblaze from beginning this change > breaks all DTSes from past. I think of_property_read_bool() will accept xlnx,is-dual = <1>; to mean the same as xlnx,is-dual; try it. Yours, Linus Walleij -- 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: build failure after merge of the leds tree
Hi Bryan,
After merging the leds tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/leds/leds-mc13783.c: In function 'mc13xxx_led_probe':
drivers/leds/leds-mc13783.c:280:4: error: implicit declaration of function
'of_get_next_child' [-Werror=implicit-function-declaration]
child = of_get_next_child(parent, child);
^
Caused by commit 2ca3a455432f ("leds: leds-mc13783: Add devicetree support").
of_get_next_child() is only defined if CONFIG_OF is set.
I have used the version of the leds tree from next-20130607 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpzDUXRTgHlA.pgp
Description: PGP signature
Re: [PATCH v2 1/6] GPIO: xilinx: Simplify driver probe function
Hi Linus, can you please look at this? Thanks, Michal On 06/03/2013 02:31 PM, Michal Simek wrote: > Simplification is done by using OF helper function > which increase readability of code and remove > (if (var) var = be32_to_cpup;) assignment. > > Signed-off-by: Michal Simek > --- > Changes in v2: > - New patch in this series > > drivers/gpio/gpio-xilinx.c | 24 ++-- > 1 file changed, 10 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c > index 9ae7aa8..2aad534 100644 > --- a/drivers/gpio/gpio-xilinx.c > +++ b/drivers/gpio/gpio-xilinx.c > @@ -170,24 +170,20 @@ static int xgpio_of_probe(struct device_node *np) > return -ENOMEM; > > /* Update GPIO state shadow register with default value */ > - tree_info = of_get_property(np, "xlnx,dout-default", NULL); > - if (tree_info) > - chip->gpio_state = be32_to_cpup(tree_info); > + of_property_read_u32(np, "xlnx,dout-default", >gpio_state); > + > + /* By default, all pins are inputs */ > + chip->gpio_dir = 0x; > > /* Update GPIO direction shadow register with default value */ > - chip->gpio_dir = 0x; /* By default, all pins are inputs */ > - tree_info = of_get_property(np, "xlnx,tri-default", NULL); > - if (tree_info) > - chip->gpio_dir = be32_to_cpup(tree_info); > + of_property_read_u32(np, "xlnx,tri-default", >gpio_dir); > + > + /* By default assume full GPIO controller */ > + chip->mmchip.gc.ngpio = 32; > > /* Check device node and parent device node for device width */ > - chip->mmchip.gc.ngpio = 32; /* By default assume full GPIO controller */ > - tree_info = of_get_property(np, "xlnx,gpio-width", NULL); > - if (!tree_info) > - tree_info = of_get_property(np->parent, > - "xlnx,gpio-width", NULL); > - if (tree_info) > - chip->mmchip.gc.ngpio = be32_to_cpup(tree_info); > + of_property_read_u32(np, "xlnx,gpio-width", > + (u32 *)>mmchip.gc.ngpio); > > spin_lock_init(>gpio_lock); > > -- > 1.8.2.3 > -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 0/7] xilinxfb changes
On 06/06/2013 06:23 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 12:13 Mon 03 Jun , Michal Simek wrote: >> Hi, >> > > Arnd can you take look on it again please > > I'll take a look on it next week Any update on this? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
Re: [PATCH] pinctrl: update GPIO range doc
On 06/16/2013 05:18:29 AM, Linus Walleij wrote: From: Linus Walleij This updates the GPIO range documentation with the API changes for sparse/random/arbitrary pin-to-GPIO mappings. Acked-by: Rob Landley Why isn't this part of the pinctrl series you posted right afterwards? (It should go in through that maintainer...) For all functionalities dealing with pin biasing, pin muxing etc, the pin -controller subsystem will subtract the range's .base offset from the passed -in gpio number, and add the ranges's .pin_base offset to retrive a pin number. -After that, the subsystem passes it on to the pin control driver, so the driver +controller subsystem will look up the corresponding pin number from the passed +in gpio number, and use the ranges internals to retrive a pin number. After Range's perhaps? Rob-- 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: dma-mapping: Get pages if the cpu_addr is out of atomic_pool
YoungJun Cho wrote @ Mon, 17 Jun 2013 06:18:52 +0200: > In __iommu_get_pages(), the cpu_addr is checked wheather in > atomic_pool range or not. So if the cpu_addr is in atomic_pool > range, it does not need to check twice. > > Signed-off-by: YoungJun Cho > Signed-off-by: Kyungmin Park Looks ok to me, at least. -- 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: add heuristic logic to pick idle peers
Hi Michael,
On Mon, Jun 17, 2013 at 11:27 AM, Michael Wang
wrote:
> Hi, Lei
>
> On 06/17/2013 10:21 AM, Lei Wen wrote:
>> nr_busy_cpus in sched_group_power structure cannot present the purpose
>> for judging below statement:
>> "this cpu's scheduler group has multiple busy cpu's exceeding
>> the group's power."
>>
>> But only could tell how many cpus is doing their jobs for currently.
>
> AFAIK, this nr_busy_cpus presents how many cpus in local group are not
> idle, the logical here in nohz_kick_needed() is:
>
> if domain cpus share resources and at least 2 cpus in
> local group are not idle, prefer to do balance.
>
Seems reasonable for me. But this comment is conflicted with current documented
one. Do we need to modify the comment anyway, as previous says nr_busy>1 is
"scheduler group has multiple busy cpu;s exceeding the group's power"?
> And the idea behind is, we catch the timing when there are idle-cpu and
> busy-group and task-moving may cost low.
Since there is only one task over runqueue now, then why we could need the
load balance any way?...
>
> Your change will remove this timing for balance, I think you may need
> some test to prove that this patch will make things better.
I see. Yes, test data is always good. :)
Do you have any suggestion like using what kind of test program to
collect this data?
Thanks,
Lei
>
> Regards,
> Michael Wang
>
>>
>> However, the original purpose to add this logic still looks good.
>> So we move this kind of logic to find_new_ilb, so that we could pick
>> out peer from our sharing resource domain whenever possible.
>>
>> Signed-off-by: Lei Wen
>> ---
>> kernel/sched/fair.c | 28 ++--
>> 1 file changed, 22 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index c61a614..64f9120 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5368,10 +5368,31 @@ static struct {
>> unsigned long next_balance; /* in jiffy units */
>> } nohz cacheline_aligned;
>>
>> +/*
>> + * Add the heuristic logic to try waking up idle cpu from
>> + * those peers who share resources with us, so that the
>> + * cost would be brought to minimum.
>> + */
>> static inline int find_new_ilb(int call_cpu)
>> {
>> - int ilb = cpumask_first(nohz.idle_cpus_mask);
>> + int ilb = nr_cpu_ids;
>> + struct sched_domain *sd;
>> +
>> + rcu_read_lock();
>> + for_each_domain(call_cpu, sd) {
>> + /* We loop till sched_domain no longer share resource */
>> + if (!(sd->flags & SD_SHARE_PKG_RESOURCES)) {
>> + ilb = cpumask_first(nohz.idle_cpus_mask);
>> + break;
>> + }
>>
>> + /* else, we would try to pick the idle cpu from peers first */
>> + ilb = cpumask_first_and(nohz.idle_cpus_mask,
>> + sched_domain_span(sd));
>> + if (ilb < nr_cpu_ids)
>> + break;
>> + }
>> + rcu_read_unlock();
>> if (ilb < nr_cpu_ids && idle_cpu(ilb))
>> return ilb;
>>
>> @@ -5620,8 +5641,6 @@ end:
>> * Current heuristic for kicking the idle load balancer in the presence
>> * of an idle cpu is the system.
>> * - This rq has more than one task.
>> - * - At any scheduler domain level, this cpu's scheduler group has
>> multiple
>> - * busy cpu's exceeding the group's power.
>> * - For SD_ASYM_PACKING, if the lower numbered cpu's in the scheduler
>> * domain span are idle.
>> */
>> @@ -5659,9 +5678,6 @@ static inline int nohz_kick_needed(struct rq *rq, int
>> cpu)
>> struct sched_group_power *sgp = sg->sgp;
>> int nr_busy = atomic_read(>nr_busy_cpus);
>>
>> - if (sd->flags & SD_SHARE_PKG_RESOURCES && nr_busy > 1)
>> - goto need_kick_unlock;
>> -
>> if (sd->flags & SD_ASYM_PACKING && nr_busy != sg->group_weight
>> && (cpumask_first_and(nohz.idle_cpus_mask,
>> sched_domain_span(sd)) < cpu))
>>
>
> --
> 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/
--
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/9] s390: Replace weird use of PTR_RET.
On Sun, Jun 16, 2013 at 02:12:42PM +0930, Rusty Russell wrote: > Saves repeating "(void __force *)__uptr" but it's less clear. Using > the output of PTR_RET() to determine the error rather than just > testing IS_ERR() is odd. Ok, if it's confusing I won't mind if it gets changed. I intended to keep the code as short as possible, but.. ;) > For example, I *assume* __gptr_to_uptr() never returns NULL? Because > the __ret would be 0 for the old code. The new version is clearer, IMHO: > it would try to get_user() on that address. __gptr_to_uptr() could return 0 and it's not an error case. In that case it should indeed try a to get_user() on that address. > If you hate this variant, I can just s/PTR_RET/PTR_ERR_OR_ZERO/ instead. Your patch is fine. > Cc: Heiko Carstens > Cc: Christian Borntraeger > Cc: Martin Schwidefsky > Signed-off-by: Rusty Russell > --- > arch/s390/kvm/gaccess.h | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) Acked-by: Heiko Carstens -- 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/3] tracing/kprobes: Kill probe_enable_lock
(2013/06/17 2:21), Oleg Nesterov wrote:
> enable_trace_probe() and disable_trace_probe() should not worry about
> serialization, the caller (perf_trace_init or __ftrace_set_clr_event)
> holds event_mutex.
>
> They are also called by kprobe_trace_self_tests_init(), but this __init
> function can't race with itself or trace_events.c
Right,
For safety, we should comment this at the caller side, because
those calls are the reason why I have introduced this lock.
Thank you,
> And note that this code depended on event_mutex even before 41a7dd420c
> which introduced probe_enable_lock. In fact it assumes that the caller
> kprobe_register() can never race with itself. Otherwise, say, tp->flags
> manipulations are racy.
>
> Signed-off-by: Oleg Nesterov
> ---
> kernel/trace/trace_kprobe.c | 33 ++---
> 1 files changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index c0af476..5a73de0 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -183,16 +183,15 @@ static struct trace_probe *find_trace_probe(const char
> *event,
> return NULL;
> }
>
> +/*
> + * This and enable_trace_probe/disable_trace_probe rely on event_mutex
> + * held by the caller, __ftrace_set_clr_event().
> + */
> static int trace_probe_nr_files(struct trace_probe *tp)
> {
> - struct ftrace_event_file **file;
> + struct ftrace_event_file **file = rcu_dereference_raw(tp->files);
> int ret = 0;
>
> - /*
> - * Since all tp->files updater is protected by probe_enable_lock,
> - * we don't need to lock an rcu_read_lock.
> - */
> - file = rcu_dereference_raw(tp->files);
> if (file)
> while (*(file++))
> ret++;
> @@ -200,8 +199,6 @@ static int trace_probe_nr_files(struct trace_probe *tp)
> return ret;
> }
>
> -static DEFINE_MUTEX(probe_enable_lock);
> -
> /*
> * Enable trace_probe
> * if the file is NULL, enable "perf" handler, or enable "trace" handler.
> @@ -211,8 +208,6 @@ enable_trace_probe(struct trace_probe *tp, struct
> ftrace_event_file *file)
> {
> int ret = 0;
>
> - mutex_lock(_enable_lock);
> -
> if (file) {
> struct ftrace_event_file **new, **old;
> int n = trace_probe_nr_files(tp);
> @@ -223,7 +218,7 @@ enable_trace_probe(struct trace_probe *tp, struct
> ftrace_event_file *file)
> GFP_KERNEL);
> if (!new) {
> ret = -ENOMEM;
> - goto out_unlock;
> + goto out;
> }
> memcpy(new, old, n * sizeof(struct ftrace_event_file *));
> new[n] = file;
> @@ -247,10 +242,7 @@ enable_trace_probe(struct trace_probe *tp, struct
> ftrace_event_file *file)
> else
> ret = enable_kprobe(>rp.kp);
> }
> -
> - out_unlock:
> - mutex_unlock(_enable_lock);
> -
> + out:
> return ret;
> }
>
> @@ -283,8 +275,6 @@ disable_trace_probe(struct trace_probe *tp, struct
> ftrace_event_file *file)
> {
> int ret = 0;
>
> - mutex_lock(_enable_lock);
> -
> if (file) {
> struct ftrace_event_file **new, **old;
> int n = trace_probe_nr_files(tp);
> @@ -293,7 +283,7 @@ disable_trace_probe(struct trace_probe *tp, struct
> ftrace_event_file *file)
> old = rcu_dereference_raw(tp->files);
> if (n == 0 || trace_probe_file_index(tp, file) < 0) {
> ret = -EINVAL;
> - goto out_unlock;
> + goto out;
> }
>
> if (n == 1) { /* Remove the last file */
> @@ -304,7 +294,7 @@ disable_trace_probe(struct trace_probe *tp, struct
> ftrace_event_file *file)
> GFP_KERNEL);
> if (!new) {
> ret = -ENOMEM;
> - goto out_unlock;
> + goto out;
> }
>
> /* This copy & check loop copies the NULL stopper too */
> @@ -327,10 +317,7 @@ disable_trace_probe(struct trace_probe *tp, struct
> ftrace_event_file *file)
> else
> disable_kprobe(>rp.kp);
> }
> -
> - out_unlock:
> - mutex_unlock(_enable_lock);
> -
> + out:
> return ret;
> }
>
>
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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/
Re: [PATCH 3.9-stable] ARM: omap3: clock: fix wrong container_of in clock36xx.c
On Mon, 17 Jun 2013, Jonghwan Choi wrote:
> This patch looks like it should be in the 3.9-stable tree, should we apply
> it?
Please do.
- Paul
>
> --
>
> From: "Jean-Philippe Francois "
>
> commit a93d8a1cea0899982993e9a93404c6f78b123697 upstream
>
> omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of
> the clock to be a clk_hw_omap. However, looking at cclock3xxx_data.c,
> all concerned clock have parent defined as clk_divider. Fix the
> function to use clk_divider. Tested with 3.9 on dm3730.
>
> Signed-off-by: Jean-Philippe Francois
> Cc: NeilBrown
> Cc: Mike Turquette
> Signed-off-by: Paul Walmsley
> Signed-off-by: Jonghwan Choi
> ---
> arch/arm/mach-omap2/clock36xx.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock36xx.c
> b/arch/arm/mach-omap2/clock36xx.c
> index 8f3bf4e..bbd6a3f 100644
> --- a/arch/arm/mach-omap2/clock36xx.c
> +++ b/arch/arm/mach-omap2/clock36xx.c
> @@ -20,11 +20,12 @@
>
> #include
> #include
> +#include
> #include
>
> #include "clock.h"
> #include "clock36xx.h"
> -
> +#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
>
> /**
> * omap36xx_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
> @@ -39,29 +40,28 @@
> */
> int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
> {
> - struct clk_hw_omap *parent;
> + struct clk_divider *parent;
> struct clk_hw *parent_hw;
> - u32 dummy_v, orig_v, clksel_shift;
> + u32 dummy_v, orig_v;
> int ret;
>
> /* Clear PWRDN bit of HSDIVIDER */
> ret = omap2_dflt_clk_enable(clk);
>
> parent_hw = __clk_get_hw(__clk_get_parent(clk->clk));
> - parent = to_clk_hw_omap(parent_hw);
> + parent = to_clk_divider(parent_hw);
>
> /* Restore the dividers */
> if (!ret) {
> - clksel_shift = __ffs(parent->clksel_mask);
> - orig_v = __raw_readl(parent->clksel_reg);
> + orig_v = __raw_readl(parent->reg);
> dummy_v = orig_v;
>
> /* Write any other value different from the Read value */
> - dummy_v ^= (1 << clksel_shift);
> - __raw_writel(dummy_v, parent->clksel_reg);
> + dummy_v ^= (1 << parent->shift);
> + __raw_writel(dummy_v, parent->reg);
>
> /* Write the original divider */
> - __raw_writel(orig_v, parent->clksel_reg);
> + __raw_writel(orig_v, parent->reg);
> }
>
> return ret;
> --
> 1.7.9.5
>
- Paul
--
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: [uclinux-dist-devel] [PATCH 01/11] cpufreq: blackfin: enable driver for CONFIG_BFIN_CPU_FREQ
On Wednesday 12 June 2013 04:15:08 Viresh Kumar wrote: > By mistake blackfin's cpufreq driver is enabled when CONFIG_BLACKFIN was > present, whereas it should have been enabled only when CONFIG_BFIN_CPU_FREQ > is present. Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/2] clk: exynos4: Add alias for cpufreq related clocks
On 06/11/2013 12:23 AM, Tomasz Figa wrote: > On Monday 10 of June 2013 09:13:11 Tushar Behera wrote: >> On 06/08/2013 05:20 PM, Tomasz Figa wrote: >>> On Thursday 06 of June 2013 16:52:28 Tushar Behera wrote: [ ... ] MUX_A(mout_core, "mout_core", mout_core_p4210, - SRC_CPU, 16, 1, "mout_core"), + SRC_CPU, 16, 1, "moutcore"), >>> >>> IMHO those typo corrections are not part of this patch. >> >> But the older drivers (before migration to CCF) were using the clock >> "moutcore" (not "mout_core"). > > I mean, this should be placed in a separate patch, as this change is not > "adding alias for cpufreq related clocks", but rather fixing a typo. > Is it ok if I split this patch into 2, one adding clock alias 'mout_apll' and another one fixing the alias names 'mout_mpll', 'moutcore' and 'armclk'? [ ... ] >>> Basically I don't like the idea of those global aliases, which IMHO >>> should be completely dropped. Someone might not like it, but I'd go >>> with the conversion of our cpufreq drivers to platform drivers >>> instead, which could receive things like clocks and regulators using >>> DT-based lookups. >> I agree. Migration of exynos-cpufreq driver as a platform driver is the >> best solution. But unless someone picks up that work, cpufreq support >> for EXYNOS4 based systems is broken because of the incorrect clock >> aliases. > > We have patches for this in our internal tree. I will clean them up a bit > and submit soon. > If you are going to submit the cpufreq driver patches for v3.11, then we can ignore this patchset. Otherwise, I would prefer to get these patches merged for v3.11 to get cpufreq working. Once the driver changes are incorporated, we can very well modify these later. Thanks. -- Tushar Behera -- 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/3] tracing/kprobes: Avoid perf_trace_buf_*() if ->perf_events is empty
(2013/06/17 2:21), Oleg Nesterov wrote: > perf_trace_buf_prepare() + perf_trace_buf_submit() make no sense > if this task/CPU has no active counters. Change kprobe_perf_func() > and kretprobe_perf_func() to check call->perf_events beforehand > and return if this list is empty. > > For example, "perf record -e some_probe -p1". Only /sbin/init will > report, all other threads which hit the same probe will do > perf_trace_buf_prepare/perf_trace_buf_submit just to realize that > nobody wants perf_swevent_event(). > > Signed-off-by: Oleg Nesterov Looks good :) Thank you! Acked-by: Masami Hiramatsu > --- > kernel/trace/trace_kprobe.c | 12 > 1 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c > index 9f46e98..c0af476 100644 > --- a/kernel/trace/trace_kprobe.c > +++ b/kernel/trace/trace_kprobe.c > @@ -1157,6 +1157,10 @@ kprobe_perf_func(struct trace_probe *tp, struct > pt_regs *regs) > int size, __size, dsize; > int rctx; > > + head = this_cpu_ptr(call->perf_events); > + if (hlist_empty(head)) > + return; > + > dsize = __get_data_size(tp, regs); > __size = sizeof(*entry) + tp->size + dsize; > size = ALIGN(__size + sizeof(u32), sizeof(u64)); > @@ -1172,8 +1176,6 @@ kprobe_perf_func(struct trace_probe *tp, struct pt_regs > *regs) > entry->ip = (unsigned long)tp->rp.kp.addr; > memset([1], 0, dsize); > store_trace_args(sizeof(*entry), tp, regs, (u8 *)[1], dsize); > - > - head = this_cpu_ptr(call->perf_events); > perf_trace_buf_submit(entry, size, rctx, > entry->ip, 1, regs, head, NULL); > } > @@ -1189,6 +1191,10 @@ kretprobe_perf_func(struct trace_probe *tp, struct > kretprobe_instance *ri, > int size, __size, dsize; > int rctx; > > + head = this_cpu_ptr(call->perf_events); > + if (hlist_empty(head)) > + return; > + > dsize = __get_data_size(tp, regs); > __size = sizeof(*entry) + tp->size + dsize; > size = ALIGN(__size + sizeof(u32), sizeof(u64)); > @@ -1204,8 +1210,6 @@ kretprobe_perf_func(struct trace_probe *tp, struct > kretprobe_instance *ri, > entry->func = (unsigned long)tp->rp.kp.addr; > entry->ret_ip = (unsigned long)ri->ret_addr; > store_trace_args(sizeof(*entry), tp, regs, (u8 *)[1], dsize); > - > - head = this_cpu_ptr(call->perf_events); > perf_trace_buf_submit(entry, size, rctx, > entry->ret_ip, 1, regs, head, NULL); > } > -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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/
Re: [PATCH] pinctrl: establish pull-up/pull-down terminology
On 16/06/13 22:45, Linus Walleij wrote: From: Linus Walleij It is counter-intuitive to have "0" mean disable in a boolean manner for electronic properties of pins such as pull-up and pull-down. Therefore, define that a pull-up/pull-down argument of 0 to such a generic option means that the pin is short-circuited to VDD or GROUND. Pull disablement shall be done using PIN_CONFIG_BIAS_DISABLE. Cc: Heiko St�bner Cc: James Hogan Cc: Laurent Pinchart Signed-off-by: Linus Walleij --- include/linux/pinctrl/pinconf-generic.h | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h index d414a77..67780f5 100644 --- a/include/linux/pinctrl/pinconf-generic.h +++ b/include/linux/pinctrl/pinconf-generic.h @@ -36,14 +36,15 @@ *tristate. The argument is ignored. * @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with high *impedance to VDD). If the argument is != 0 pull-up is enabled, - * if it is 0, pull-up is disabled. + * if it is 0, pull-up it total, i.e. the pin is connected to VDD. s/it/is * @PIN_CONFIG_BIAS_PULL_DOWN: the pin will be pulled down (usually with high *impedance to GROUND). If the argument is != 0 pull-down is enabled, - * if it is 0, pull-down is disabled. + * if it is 0, pull-down is total, i.e. the pin is connected to GROUND. * @PIN_CONFIG_BIAS_PULL_PIN_DEFAULT: the pin will be pulled up or down based *on embedded knowledge of the controller, like current mux function. - * If the argument is != 0 pull up/down is enabled, if it is 0, - * the pull is disabled. + * If the argument is != 0 pull up/down is enabled, if it is 0, the + * configuration is ignored. The proper way to disable it is to use + * @PIN_CONFIG_BIAS_DISABLE. * @PIN_CONFIG_DRIVE_PUSH_PULL: the pin will be driven actively high and *low, this is the most typical case and is typically achieved with two *active transistors on the output. Setting this config will enable @@ -72,8 +73,8 @@ *supplies, the argument to this parameter (on a custom format) tells *the driver which alternative power source to use. * @PIN_CONFIG_SLEW_RATE: if the pin can select slew rate, the argument to - * this parameter (on a custom format) tells the driver which alternative - * slew rate to use. + * this parameter (on a custom format) tells the driver which alternative + * slew rate to use. * @PIN_CONFIG_LOW_POWER_MODE: this will configure the pin for low power *operation, if several modes of operation are supported these can be *passed in the argument on a custom form, else just use argument 1 ___ 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/
[PATCH] ARM: dma-mapping: Get pages if the cpu_addr is out of atomic_pool
In __iommu_get_pages(), the cpu_addr is checked wheather in
atomic_pool range or not. So if the cpu_addr is in atomic_pool
range, it does not need to check twice.
Signed-off-by: YoungJun Cho
Signed-off-by: Kyungmin Park
---
arch/arm/mm/dma-mapping.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ef3e0f3..1d158c2 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1372,16 +1372,17 @@ static int arm_iommu_mmap_attrs(struct device *dev,
struct vm_area_struct *vma,
void arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t handle, struct dma_attrs *attrs)
{
- struct page **pages = __iommu_get_pages(cpu_addr, attrs);
+ struct page **pages;
size = PAGE_ALIGN(size);
- if (!pages) {
- WARN(1, "trying to free invalid coherent area: %p\n", cpu_addr);
+ if (__in_atomic_pool(cpu_addr, size)) {
+ __iommu_free_atomic(dev, cpu_addr, handle, size);
return;
}
- if (__in_atomic_pool(cpu_addr, size)) {
- __iommu_free_atomic(dev, cpu_addr, handle, size);
+ pages = __iommu_get_pages(cpu_addr, attrs);
+ if (!pages) {
+ WARN(1, "trying to free invalid coherent area: %p\n", cpu_addr);
return;
}
--
1.7.4.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/
linux-next: manual merge of the fbdev tree with the drm tree
Hi all,
Today's linux-next merge of the fbdev tree got a conflict in
drivers/video/of_display_timing.c between commit f583662347c6 ("video:
display_timing: make parameter const") from the drm tree and commits
fcf7e6e5bd84 ("videomode: don't allocate mem in of_get_display_timing()")
and ffa3fd21de8a ("videomode: implement public of_get_display_timing()")
from the fbdev tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/video/of_display_timing.c
index 2894e03,9c0f17b..000
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@@ -53,13 -53,12 +53,12 @@@ static int parse_timing_property(const
}
/**
- * of_get_display_timing - parse display_timing entry from device_node
+ * of_parse_display_timing - parse display_timing entry from device_node
* @np: device_node with the properties
**/
- static struct display_timing *of_get_display_timing(const struct device_node
- *np)
-static int of_parse_display_timing(struct device_node *np,
++static int of_parse_display_timing(const struct device_node *np,
+ struct display_timing *dt)
{
- struct display_timing *dt;
u32 val = 0;
int ret = 0;
pgpirWd6qU3Uq.pgp
Description: PGP signature
Re: [PATCH v2] ARM: mmp: bring up pxa988 with device tree support
On Fri, Jun 14, 2013 at 8:56 PM, Arnd Bergmann wrote: > On Friday 14 June 2013 17:15:33 Chao Xie wrote: >> On Mon, Jun 10, 2013 at 4:35 PM, Arnd Bergmann wrote: > >> > I guess that is a problem we have on other platforms as well, we should >> > find a generic solution for that. It would be nice to reserve a page >> > in "fixmap" and have common code map the SCU page into that. >> > >> >> So you mean that reserve a page in arch/arm/asm/include/fixmap.h? > > Yes. > >> This reserve will depend on the cpu type beacuse only A9 will have SCU part. > > I think A5 and ARM11MPCore as well. > >> I do not know that in fixmap, the #ifdef is acceptable or not. > > Yes, it is. We don't really use fixmap on ARM for anything other than > kmap_atomic at the moment. Please have a look at the powerpc and x86 > implementations. > >> For the common code to map the SCU page, where do you suggest to put it? > > arch/arm/kernel/smp_scu.c. > I think smp_scu.c may not be good place to put the mapping for SCU page. As you know that the fix map will make use of the mapping that set up by vector page. It will make use of top_pmd, and some APIs only provided under arch/arm/mm/. For example get_mem_type: for the pgprot for MT_DEVICE set_top_pte: Is that possible to add a file fixmap.c under arch/arm/mm/? It can including all the fix mapping except highmem. So SCU is one of it. > Arnd -- 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] usb: dwc3: use extcon fwrk to receive connect/disconnect
On 06/14/2013 10:10 PM, Kishon Vijay Abraham I wrote:
> Modified dwc3-omap to receive connect and disconnect notification using
> extcon framework. Also did the necessary cleanups required after
> adapting to extcon framework.
>
> Signed-off-by: Kishon Vijay Abraham I
> Acked-by: Felipe Balbi
> ---
> This patch depends on
> git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git
> commit:f7ae906
>
> It should also be applied on top of
> usb: dwc3: omap: improve error handling of dwc3_omap_probe patch which is
> merged in Felipe's tree.
>
> So I'm not sure on whose tree this patch should go in.
>
> Changes from v3:
> * did #include of of_extcon.h after Chanwoo resent the patch separating
> extcon-class.c from of_extcon.c
> Changes from v2:
> * updated the Documentation with dwc3 dt binding information.
> * used of_extcon_get_extcon_dev to get extcon device from device tree data.
> Changes from v1:
> * regulator enable/disable is now done here instead of palmas-usb as some
> users
> of palmas-usb wont need regulator.
>
> Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
> drivers/usb/dwc3/dwc3-omap.c | 119
>
> include/linux/usb/dwc3-omap.h | 30 -
> 3 files changed, 105 insertions(+), 49 deletions(-)
> delete mode 100644 include/linux/usb/dwc3-omap.h
>
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index d4769f3..f1c15f3 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -53,6 +53,11 @@ OMAP DWC3 GLUE
> It should be set to "1" for HW mode and "2" for SW mode.
> - ranges: the child address space are mapped 1:1 onto the parent address
> space
>
> +Optional Properties:
> + - extcon : phandle for the extcon device omap dwc3 uses to detect
> + connect/disconnect events.
> + - vbus-supply : phandle to the regulator device tree node if needed.
> +
> Sub-nodes:
> The dwc3 core should be added as subnode to omap dwc3 glue.
> - dwc3 :
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index f8f76e6..14c1f1b 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -43,13 +43,15 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include
>
> @@ -124,9 +126,21 @@ struct dwc3_omap {
> u32 utmi_otg_status;
>
> u32 dma_status:1;
> +
> + struct extcon_specific_cable_nb extcon_vbus_dev;
> + struct extcon_specific_cable_nb extcon_id_dev;
> + struct notifier_block vbus_nb;
> + struct notifier_block id_nb;
> +
> + struct regulator*vbus_reg;
> };
>
> -static struct dwc3_omap *_omap;
> +enum omap_dwc3_vbus_id_status {
> + OMAP_DWC3_ID_FLOAT,
> + OMAP_DWC3_ID_GROUND,
> + OMAP_DWC3_VBUS_OFF,
> + OMAP_DWC3_VBUS_VALID,
> +};
>
> static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
> {
> @@ -138,18 +152,23 @@ static inline void dwc3_omap_writel(void __iomem *base,
> u32 offset, u32 value)
> writel(value, base + offset);
> }
>
> -int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
> +static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
> + enum omap_dwc3_vbus_id_status status)
> {
> - u32 val;
> - struct dwc3_omap*omap = _omap;
> -
> - if (!omap)
> - return -EPROBE_DEFER;
> + int ret;
> + u32 val;
>
> switch (status) {
> case OMAP_DWC3_ID_GROUND:
> dev_dbg(omap->dev, "ID GND\n");
>
> + if (omap->vbus_reg) {
> + ret = regulator_enable(omap->vbus_reg);
> + if (ret) {
> + dev_dbg(omap->dev, "regulator enable failed\n");
> + return;
> + }
> + }
> val = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
> val &= ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
> | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
> @@ -172,6 +191,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status
> status)
> break;
>
> case OMAP_DWC3_ID_FLOAT:
> + if (omap->vbus_reg)
> + regulator_disable(omap->vbus_reg);
> +
> case OMAP_DWC3_VBUS_OFF:
> dev_dbg(omap->dev, "VBUS Disconnect\n");
>
> @@ -185,12 +207,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status
> status)
> break;
>
> default:
> - dev_dbg(omap->dev, "ID float\n");
> + dev_dbg(omap->dev, "invalid state\n");
> }
> -
> - return 0;
> }
> -EXPORT_SYMBOL_GPL(dwc3_omap_mailbox);
>
> static
Re: [PATCH 6/9] remoteproc: don't use PTR_RET().
Ohad Ben-Cohen writes: > On Sun, Jun 16, 2013 at 7:42 AM, Rusty Russell wrote: >> >> We've already tested that it's an error. >> >> Cc: Ohad Ben-Cohen >> Cc: Robert Tivy >> Signed-off-by: Rusty Russell > > Acked-by: Ohad Ben-Cohen > > Thanks Rusty, feel free to take it via your tree together with the > rest of the PTR_RET patches. Thanks, done. Cheers, Rusty. -- 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 9/9] mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR().
David Rientjes writes:
> On Sun, 16 Jun 2013, Rusty Russell wrote:
>
>> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
>> index 79e451a..f9b9cd7 100644
>> --- a/mm/oom_kill.c
>> +++ b/mm/oom_kill.c
>> @@ -288,7 +288,7 @@ enum oom_scan_t oom_scan_process_thread(struct
>> task_struct *task,
>>
>> /*
>> * Simple selection loop. We chose the process with the highest
>> - * number of 'points'.
>> + * number of 'points'. Returns -1 on scan abort.
>> *
>> * (not docbooked, we don't want this one cluttering up the manual)
>> */
>> @@ -314,7 +314,7 @@ static struct task_struct *select_bad_process(unsigned
>> int *ppoints,
>> continue;
>> case OOM_SCAN_ABORT:
>> rcu_read_unlock();
>> -return ERR_PTR(-1UL);
>> +return (void *)(-1UL);
>> case OOM_SCAN_OK:
>> break;
>> };
>
> Any reason it's not struct task_struct *?
No good one. Changed.
Cheers,
Rusty.
Subject: mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR().
The normal expectation for ERR_PTR() is to put a negative errno into a
pointer. oom_kill puts the magic -1 in the result (and has since
pre-git), which is probably clearer with an explicit cast.
Cc: Andrew Morton
Signed-off-by: Rusty Russell
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 79e451a..f9b9cd7 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -288,7 +288,7 @@ enum oom_scan_t oom_scan_process_thread(struct task_struct
*task,
/*
* Simple selection loop. We chose the process with the highest
- * number of 'points'.
+ * number of 'points'. Returns -1 on scan abort.
*
* (not docbooked, we don't want this one cluttering up the manual)
*/
@@ -314,7 +314,7 @@ static struct task_struct *select_bad_process(unsigned int
*ppoints,
continue;
case OOM_SCAN_ABORT:
rcu_read_unlock();
- return ERR_PTR(-1UL);
+ return (struct task_struct *)(-1UL);
case OOM_SCAN_OK:
break;
};
@@ -657,7 +657,7 @@ void out_of_memory(struct zonelist *zonelist, gfp_t
gfp_mask,
dump_header(NULL, gfp_mask, order, NULL, mpol_mask);
panic("Out of memory and no killable processes...\n");
}
- if (PTR_ERR(p) != -1UL) {
+ if (p != (void *)-1UL) {
oom_kill_process(p, gfp_mask, order, points, totalpages, NULL,
nodemask, "Out of memory");
killed = 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 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On Sun, 2013-06-16 at 21:13 -0600, Alex Williamson wrote: > IOMMU groups themselves don't provide security, they're accessed by > interfaces like VFIO, which provide the security. Given a brief look, I > agree, this looks like a possible backdoor. The typical VFIO way to > handle this would be to pass a VFIO file descriptor here to prove that > the process has access to the IOMMU group. This is how /dev/vfio/vfio > gains the ability to setup an IOMMU domain an do mappings with the > SET_CONTAINER ioctl using a group fd. Thanks, How do you envision that in the kernel ? IE. I'm in KVM code, gets that vfio fd, what do I do with it ? Basically, KVM needs to know that the user is allowed to use that iommu group. I don't think we want KVM however to call into VFIO directly right ? Cheers, Ben. -- 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/3] tracing/kprobes: Avoid perf_trace_buf_*() if ->perf_events is empty
On 2013/6/17 1:21, Oleg Nesterov wrote:
> perf_trace_buf_prepare() + perf_trace_buf_submit() make no sense
> if this task/CPU has no active counters. Change kprobe_perf_func()
> and kretprobe_perf_func() to check call->perf_events beforehand
> and return if this list is empty.
>
> For example, "perf record -e some_probe -p1". Only /sbin/init will
> report, all other threads which hit the same probe will do
> perf_trace_buf_prepare/perf_trace_buf_submit just to realize that
> nobody wants perf_swevent_event().
>
> Signed-off-by: Oleg Nesterov
Good point, I think we also need to change other places in below patch.
After applied the patch, perf_tp_event() function call reduced a lots
when using task based perf tracing.
---
tracing: Avoid perf_trace_buf_*() if ->perf_events is empty
Signed-off-by: zhangwei(Jovi)
---
include/trace/ftrace.h|5 -
kernel/trace/trace_syscalls.c | 10 --
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 19edd7f..5d340f5 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -659,6 +659,10 @@ perf_trace_##call(void *__data, proto)
\
int __data_size;\
int rctx; \
\
+ head = this_cpu_ptr(event_call->perf_events); \
+ if (hlist_empty(head)) \
+ return; \
+ \
perf_fetch_caller_regs(&__regs);\
\
__data_size = ftrace_get_offsets_##call(&__data_offsets, args); \
@@ -679,7 +683,6 @@ perf_trace_##call(void *__data, proto)
\
\
{ assign; } \
\
- head = this_cpu_ptr(event_call->perf_events); \
perf_trace_buf_submit(entry, __entry_size, rctx, __addr,\
__count, &__regs, head, __task);\
}
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 8f2ac73..28debf4 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -553,6 +553,10 @@ static void perf_syscall_enter(void *ignore, struct
pt_regs *regs, long id)
if (!sys_data)
return;
+ head = this_cpu_ptr(sys_data->enter_event->perf_events);
+ if (hlist_empty(head))
+ return;
+
/* get the size after alignment with the u32 buffer size field */
size = sizeof(unsigned long) * sys_data->nb_args + sizeof(*rec);
size = ALIGN(size + sizeof(u32), sizeof(u64));
@@ -571,7 +575,6 @@ static void perf_syscall_enter(void *ignore, struct pt_regs
*regs, long id)
syscall_get_arguments(current, regs, 0, sys_data->nb_args,
(unsigned long *)>args);
- head = this_cpu_ptr(sys_data->enter_event->perf_events);
perf_trace_buf_submit(rec, size, rctx, 0, 1, regs, head, NULL);
}
@@ -629,6 +632,10 @@ static void perf_syscall_exit(void *ignore, struct pt_regs
*regs, long ret)
if (!sys_data)
return;
+ head = this_cpu_ptr(sys_data->exit_event->perf_events);
+ if (hlist_empty(head))
+ return;
+
/* We can probably do that at build time */
size = ALIGN(sizeof(*rec) + sizeof(u32), sizeof(u64));
size -= sizeof(u32);
@@ -649,7 +656,6 @@ static void perf_syscall_exit(void *ignore, struct pt_regs
*regs, long ret)
rec->nr = syscall_nr;
rec->ret = syscall_get_return_value(current, regs);
- head = this_cpu_ptr(sys_data->exit_event->perf_events);
perf_trace_buf_submit(rec, size, rctx, 0, 1, regs, head, NULL);
}
--
1.7.9.7
--
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: build failure after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
make[4]: *** No rule to make target `sound/soc/spear/spear_evb.o', needed by
`sound/soc/spear/built-in.o'. Stop.
Caused by commit e58070ee4fdf ("ASoC: Add Kconfig and Makefile to support
SPEAr audio driver").
I have used the version of the sound-asoc -tree from next-20130607 for
today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgphlRhv2fs3c.pgp
Description: PGP signature
Re: [PATCH V5 02/30] thermal: exynos: Add ARCH_HAS_TMU config to know the supported soc's
Hi Eduardo, On Mon, Jun 17, 2013 at 8:35 AM, Eduardo Valentin wrote: > Hey Amit, > > On 11-06-2013 08:53, Amit Daniel Kachhap wrote: >> This patch adds config sybmol ARCH_HAS_TMU to enable the TMU driver. >> This will allow adding support for new soc easily as now it is the >> platform responsibility to enable this config symbol. >> >> Acked-by: Kukjin Kim >> Signed-off-by: Amit Daniel Kachhap >> --- >> drivers/thermal/samsung/Kconfig |5 - >> 1 files changed, 4 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/thermal/samsung/Kconfig >> b/drivers/thermal/samsung/Kconfig >> index 2d3d9dc..145a55d 100644 >> --- a/drivers/thermal/samsung/Kconfig >> +++ b/drivers/thermal/samsung/Kconfig >> @@ -1,6 +1,9 @@ >> +config ARCH_HAS_TMU >> + bool >> + >> config EXYNOS_THERMAL >> tristate "Temperature sensor on Samsung EXYNOS" >> - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) >> + depends on ARCH_HAS_TMU > > I would rather use ARCH_HAS_BANDGAP as discussed and agreed during your > v4 review. I managed push this patch through RMK's system: > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7758/1 Agreed I will post my TMU re-structured patches with this config flag. Thanks, Amit Daniel > >> depends on CPU_THERMAL >> help >> If you say yes here you get support for TMU (Thermal Management >> > > > -- > You have got to be excited about what you are doing. (L. Lamport) > > Eduardo Valentin > -- 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 1/2] MAINTAINERS: Add Samsung pinctrl entries
Kyungmin Park skrev: >On Mon, Jun 17, 2013 at 7:17 AM, Doug Anderson >wrote: >> It's convenient if get_maintainer suggests sending samsung/exynos >> pinctrl changes to linux-samsung-soc and to Tomasz and Thomas. >> >> Signed-off-by: Doug Anderson >Acked-by: Kyungmin Park Acked-by: Olof Johansson -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. -- 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] x86/iommu: fix dma pte address size error
Hi Don,
This patch is not only for the sake of spec interpretation.
Till now I did not see any bugs , but it does not meant no bugs will appear
in the future. The address returned by dma_pte_addr is used in many places.
Thanks
Zhenhua
On 06/15/2013 04:16 AM, Don Dutile wrote:
On 05/23/2013 08:35 PM, Li, Zhen-Hua wrote:
In Intel Vt-D specs, Chapter 9.3 Page-Table Entry,
The size of ADDR(address) field is 12:51, but the function dma_pte_addr
treats it as 12:63.
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel-iommu.c |4 ++--
include/linux/dma_remapping.h |2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
Is this patching for the sake of spec interpretation?
a dma-pte format (consumed by iommu) has 63,61:52 as available for sw,
ignored by hw.
62 is 'transient mapping' bit, which is a _hint_ for selecting iotlbs
to flush sooner.
finally, the system would have to have a memory map that actually has
bit 62 set to
be affected.
So, for intel-iommu, I don't see a bug occurring.
Did you actually have one with previous definition, and if so,
could you provide that information ?
Cheers,
- Don
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index b4f0e28..c6d2847 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -311,10 +311,10 @@ static inline void dma_set_pte_prot(struct
dma_pte *pte, unsigned long prot)
static inline u64 dma_pte_addr(struct dma_pte *pte)
{
#ifdef CONFIG_64BIT
-return pte->val& VTD_PAGE_MASK;
+return pte->val& DMA_PTE_MASK;
#else
/* Must have a full atomic 64-bit read */
-return __cmpxchg64(>val, 0ULL, 0ULL)& VTD_PAGE_MASK;
+return __cmpxchg64(>val, 0ULL, 0ULL)& DMA_PTE_MASK;
#endif
}
diff --git a/include/linux/dma_remapping.h
b/include/linux/dma_remapping.h
index 57c9a8a..7a1e212 100644
--- a/include/linux/dma_remapping.h
+++ b/include/linux/dma_remapping.h
@@ -16,6 +16,8 @@
#define DMA_PTE_WRITE (2)
#define DMA_PTE_LARGE_PAGE (1<< 7)
#define DMA_PTE_SNP (1<< 11)
+#define DMA_PTE_ADD_LENGTH (40)
+#define DMA_PTE_MASKu64)1<< DMA_PTE_ADD_LENGTH) - 1)<<
VTD_PAGE_SHIFT)
#define CONTEXT_TT_MULTI_LEVEL0
#define CONTEXT_TT_DEV_IOTLB1
.
--
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 1/2] MAINTAINERS: Add Samsung pinctrl entries
On Mon, Jun 17, 2013 at 7:17 AM, Doug Anderson wrote: > It's convenient if get_maintainer suggests sending samsung/exynos > pinctrl changes to linux-samsung-soc and to Tomasz and Thomas. > > Signed-off-by: Doug Anderson Acked-by: Kyungmin Park > --- > Changes in v2: > - Updated with Thomas and Tomasz; removed Linus since he's already > there as part of the general pinctrl match. > > MAINTAINERS | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8d97b3e..f55e3c7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6284,6 +6284,16 @@ L: linux-arm-ker...@lists.infradead.org > (moderated for non-subscribers) > S: Maintained > F: drivers/pinctrl/pinctrl-at91.c > > +PIN CONTROLLER - SAMSUNG > +M: Tomasz Figa > +M: Thomas Abraham > +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) > +S: Maintained > +F: drivers/pinctrl/pinctrl-exynos.* > +F: drivers/pinctrl/pinctrl-s3c* > +F: drivers/pinctrl/pinctrl-samsung.* > + > PIN CONTROLLER - ST SPEAR > M: Viresh Kumar > L: spear-de...@list.st.com > -- > 1.8.3 > > -- > 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/ -- 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: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_sdvo.c between commit 7ba220cec0bb ("drm/i915:
Enable hotplug interrupts after querying hw capabilities") from Linus'
tree and commit e596a02ccfc6 ("drm/i915: Remove dead code from SDVO
initialisation") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_sdvo.c
index 7d31165,b8e1623..000
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@@ -2850,18 -2889,12 +2891,6 @@@ bool intel_sdvo_init(struct drm_device
}
}
- hotplug_mask = 0;
- if (IS_G4X(dev)) {
- hotplug_mask = intel_sdvo->is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_G4X :
SDVOC_HOTPLUG_INT_STATUS_G4X;
- } else if (IS_GEN4(dev)) {
- hotplug_mask = intel_sdvo->is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_I965 :
SDVOC_HOTPLUG_INT_STATUS_I965;
- } else {
- hotplug_mask = intel_sdvo->is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_I915 :
SDVOC_HOTPLUG_INT_STATUS_I915;
- }
-
- /* Only enable the hotplug irq if we need it, to work around noisy
- * hotplug lines.
- */
- if (intel_sdvo->hotplug_active)
- intel_encoder->hpd_pin = HPD_SDVO_B ? HPD_SDVO_B : HPD_SDVO_C;
-
intel_encoder->compute_config = intel_sdvo_compute_config;
intel_encoder->disable = intel_disable_sdvo;
intel_encoder->mode_set = intel_sdvo_mode_set;
pgpJmcGqAHUH7.pgp
Description: PGP signature
Re: [PATCH v3 0/3] cpufreq:boost: CPU Boost mode support
On 14 June 2013 13:08, Lukasz Majewski wrote: > arch/arm/mach-s3c24xx/cpufreq.c |2 +- > arch/powerpc/platforms/pasemi/cpufreq.c |2 +- > arch/powerpc/platforms/powermac/cpufreq_32.c |2 +- > arch/powerpc/platforms/powermac/cpufreq_64.c |2 +- > drivers/cpufreq/acpi-cpufreq.c | 62 +++--- > drivers/cpufreq/arm_big_little.c |3 +- > drivers/cpufreq/blackfin-cpufreq.c |2 +- > drivers/cpufreq/cpufreq-cpu0.c |2 +- > drivers/cpufreq/cpufreq.c| 87 > ++ > drivers/cpufreq/cris-artpec3-cpufreq.c |2 +- > drivers/cpufreq/cris-etraxfs-cpufreq.c |2 +- > drivers/cpufreq/davinci-cpufreq.c|2 +- > drivers/cpufreq/dbx500-cpufreq.c |2 +- > drivers/cpufreq/e_powersaver.c |3 +- > drivers/cpufreq/elanfreq.c |2 +- > drivers/cpufreq/exynos-cpufreq.c |7 ++- > drivers/cpufreq/exynos5440-cpufreq.c |2 +- > drivers/cpufreq/freq_table.c | 44 ++--- > drivers/cpufreq/ia64-acpi-cpufreq.c |2 +- > drivers/cpufreq/imx6q-cpufreq.c |2 +- > drivers/cpufreq/kirkwood-cpufreq.c |3 +- > drivers/cpufreq/longhaul.c |2 +- > drivers/cpufreq/loongson2_cpufreq.c |2 +- > drivers/cpufreq/maple-cpufreq.c |2 +- > drivers/cpufreq/omap-cpufreq.c |2 +- > drivers/cpufreq/p4-clockmod.c|2 +- > drivers/cpufreq/powernow-k6.c|2 +- > drivers/cpufreq/powernow-k7.c|2 +- > drivers/cpufreq/powernow-k8.c|2 +- > drivers/cpufreq/ppc_cbe_cpufreq.c|2 +- > drivers/cpufreq/pxa2xx-cpufreq.c |4 +- > drivers/cpufreq/pxa3xx-cpufreq.c |2 +- > drivers/cpufreq/s3c2416-cpufreq.c|2 +- > drivers/cpufreq/s3c64xx-cpufreq.c|2 +- > drivers/cpufreq/s5pv210-cpufreq.c|2 +- > drivers/cpufreq/sc520_freq.c |2 +- > drivers/cpufreq/sh-cpufreq.c |2 +- > drivers/cpufreq/sparc-us2e-cpufreq.c |2 +- > drivers/cpufreq/sparc-us3-cpufreq.c |2 +- > drivers/cpufreq/spear-cpufreq.c |3 +- > drivers/cpufreq/speedstep-centrino.c |2 +- > drivers/cpufreq/speedstep-ich.c |2 +- > drivers/cpufreq/speedstep-smi.c |2 +- > drivers/cpufreq/tegra-cpufreq.c |4 +- > include/linux/cpufreq.h | 18 +- > 45 files changed, 211 insertions(+), 95 deletions(-) Wow!! I am shocked to see these many files getting updated :) -- 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: add heuristic logic to pick idle peers
Hi, Lei
On 06/17/2013 10:21 AM, Lei Wen wrote:
> nr_busy_cpus in sched_group_power structure cannot present the purpose
> for judging below statement:
> "this cpu's scheduler group has multiple busy cpu's exceeding
> the group's power."
>
> But only could tell how many cpus is doing their jobs for currently.
AFAIK, this nr_busy_cpus presents how many cpus in local group are not
idle, the logical here in nohz_kick_needed() is:
if domain cpus share resources and at least 2 cpus in
local group are not idle, prefer to do balance.
And the idea behind is, we catch the timing when there are idle-cpu and
busy-group and task-moving may cost low.
Your change will remove this timing for balance, I think you may need
some test to prove that this patch will make things better.
Regards,
Michael Wang
>
> However, the original purpose to add this logic still looks good.
> So we move this kind of logic to find_new_ilb, so that we could pick
> out peer from our sharing resource domain whenever possible.
>
> Signed-off-by: Lei Wen
> ---
> kernel/sched/fair.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c61a614..64f9120 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5368,10 +5368,31 @@ static struct {
> unsigned long next_balance; /* in jiffy units */
> } nohz cacheline_aligned;
>
> +/*
> + * Add the heuristic logic to try waking up idle cpu from
> + * those peers who share resources with us, so that the
> + * cost would be brought to minimum.
> + */
> static inline int find_new_ilb(int call_cpu)
> {
> - int ilb = cpumask_first(nohz.idle_cpus_mask);
> + int ilb = nr_cpu_ids;
> + struct sched_domain *sd;
> +
> + rcu_read_lock();
> + for_each_domain(call_cpu, sd) {
> + /* We loop till sched_domain no longer share resource */
> + if (!(sd->flags & SD_SHARE_PKG_RESOURCES)) {
> + ilb = cpumask_first(nohz.idle_cpus_mask);
> + break;
> + }
>
> + /* else, we would try to pick the idle cpu from peers first */
> + ilb = cpumask_first_and(nohz.idle_cpus_mask,
> + sched_domain_span(sd));
> + if (ilb < nr_cpu_ids)
> + break;
> + }
> + rcu_read_unlock();
> if (ilb < nr_cpu_ids && idle_cpu(ilb))
> return ilb;
>
> @@ -5620,8 +5641,6 @@ end:
> * Current heuristic for kicking the idle load balancer in the presence
> * of an idle cpu is the system.
> * - This rq has more than one task.
> - * - At any scheduler domain level, this cpu's scheduler group has multiple
> - * busy cpu's exceeding the group's power.
> * - For SD_ASYM_PACKING, if the lower numbered cpu's in the scheduler
> * domain span are idle.
> */
> @@ -5659,9 +5678,6 @@ static inline int nohz_kick_needed(struct rq *rq, int
> cpu)
> struct sched_group_power *sgp = sg->sgp;
> int nr_busy = atomic_read(>nr_busy_cpus);
>
> - if (sd->flags & SD_SHARE_PKG_RESOURCES && nr_busy > 1)
> - goto need_kick_unlock;
> -
> if (sd->flags & SD_ASYM_PACKING && nr_busy != sg->group_weight
> && (cpumask_first_and(nohz.idle_cpus_mask,
> sched_domain_span(sd)) < cpu))
>
--
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: [BUGFIX v2 0/4] fix bug 56531, 59501 and 59581
2013/6/16 Jiang Liu : > On 06/15/2013 02:42 PM, Alexander E. Patrakov wrote: >> Both cases work, and exhibit similar backtraces in dmesg. So I am >> attaching a dmesg only from the first testcase. Please look for "INFO: >> trying to register non-static key" and for "*ERROR* Memory manager not >> clean. Delaying takedown". I understand that the second trace is >> unrelated to this patchset, but would like you to fix the first. > Hi Alexander, > Great thanks for your testing! > I have investigated the first issue but still have no idea about it. > According to source code, everything should be OK. > The r8169 driver has invoked INIT_WORK(>wk.work, rtl_task) to > initialize the work item, so it shouldn't trigger the warning. > Have you found this issue in other test cases? I am not 100% sure that the static key backtrace is the same in all cases. However, I do remember that it does appear both in the non-hotplug and hotplug cases. I will retest this after work, i.e. in ~12 hours. -- Alexander E. Patrakov -- 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: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit d62cf62ad07d
("drm/i915: Quirk the pipe A quirk in the modeset state checker") from
Linus' tree and commit 6c49f24180c3 ("drm/i915: hw state readout support
for pixel_multiplier") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index 6eb99e1,218bc93..000
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -8177,11 -8264,14 +8264,19 @@@ check_crtc_state(struct drm_device *dev
active = dev_priv->display.get_pipe_config(crtc,
_config);
+
+ /* hw state is inconsistent with the pipe A quirk */
+ if (crtc->pipe == PIPE_A && dev_priv->quirks &
QUIRK_PIPEA_FORCE)
+ active = crtc->active;
+
+ list_for_each_entry(encoder, >mode_config.encoder_list,
+ base.head) {
+ if (encoder->base.crtc != >base)
+ continue;
+ if (encoder->get_config)
+ encoder->get_config(encoder, _config);
+ }
+
WARN(crtc->active != active,
"crtc active state doesn't match with hw state "
"(expected %i, found %i)\n", crtc->active, active);
pgpYBoBilA48E.pgp
Description: PGP signature
Re: [PATCH 6/9] remoteproc: don't use PTR_RET().
On Sun, Jun 16, 2013 at 7:42 AM, Rusty Russell wrote: > > We've already tested that it's an error. > > Cc: Ohad Ben-Cohen > Cc: Robert Tivy > Signed-off-by: Rusty Russell Acked-by: Ohad Ben-Cohen Thanks Rusty, feel free to take it via your tree together with the rest of the PTR_RET patches. -- 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] KVM: PPC: Add support for IOMMU in-kernel handling
On Mon, 2013-06-17 at 08:39 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2013-06-05 at 16:11 +1000, Alexey Kardashevskiy wrote:
> > +long kvm_vm_ioctl_create_spapr_tce_iommu(struct kvm *kvm,
> > + struct kvm_create_spapr_tce_iommu *args)
> > +{
> > + struct kvmppc_spapr_tce_table *tt = NULL;
> > + struct iommu_group *grp;
> > + struct iommu_table *tbl;
> > +
> > + /* Find an IOMMU table for the given ID */
> > + grp = iommu_group_get_by_id(args->iommu_id);
> > + if (!grp)
> > + return -ENXIO;
> > +
> > + tbl = iommu_group_get_iommudata(grp);
> > + if (!tbl)
> > + return -ENXIO;
>
> So Alex Graf pointed out here, there is a security issue here, or are we
> missing something ?
>
> What prevents a malicious program that has access to /dev/kvm from
> taking over random iommu groups (including host used ones) that way?
>
> What is the security model of that whole iommu stuff to begin with ?
IOMMU groups themselves don't provide security, they're accessed by
interfaces like VFIO, which provide the security. Given a brief look, I
agree, this looks like a possible backdoor. The typical VFIO way to
handle this would be to pass a VFIO file descriptor here to prove that
the process has access to the IOMMU group. This is how /dev/vfio/vfio
gains the ability to setup an IOMMU domain an do mappings with the
SET_CONTAINER ioctl using a group fd. Thanks,
Alex
--
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: manual merge of the drm tree with Linus' tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/intel_sdvo.c between commit c3456fb3e471 ("drm/i915:
prefer VBT modes for SVDO-LVDS over EDID") from Linus' tree and commit
41aa344866e3 ("drm/i915: Organize VBT stuff inside drm_i915_private")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_sdvo.c
index d4ea6c2,7068195..000
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@@ -1776,17 -1848,14 +1848,17 @@@ static void intel_sdvo_get_lvds_modes(s
* Assume that the preferred modes are
* arranged in priority order.
*/
- intel_ddc_get_modes(connector, intel_sdvo->i2c);
- if (list_empty(>probed_modes) == false)
- goto end;
+ intel_ddc_get_modes(connector, _sdvo->ddc);
- /* Fetch modes from VBT */
+ /*
+ * Fetch modes from VBT. For SDVO prefer the VBT mode since some
+ * SDVO->LVDS transcoders can't cope with the EDID mode. Since
+ * drm_mode_probed_add adds the mode at the head of the list we add it
+ * last.
+ */
- if (dev_priv->sdvo_lvds_vbt_mode != NULL) {
+ if (dev_priv->vbt.sdvo_lvds_vbt_mode != NULL) {
newmode = drm_mode_duplicate(connector->dev,
-dev_priv->sdvo_lvds_vbt_mode);
+dev_priv->vbt.sdvo_lvds_vbt_mode);
if (newmode != NULL) {
/* Guarantee the mode is preferred */
newmode->type = (DRM_MODE_TYPE_PREFERRED |
pgppe9lg8cDQ8.pgp
Description: PGP signature
Re: [PATCH V5 02/30] thermal: exynos: Add ARCH_HAS_TMU config to know the supported soc's
Hey Amit, On 11-06-2013 08:53, Amit Daniel Kachhap wrote: > This patch adds config sybmol ARCH_HAS_TMU to enable the TMU driver. > This will allow adding support for new soc easily as now it is the > platform responsibility to enable this config symbol. > > Acked-by: Kukjin Kim > Signed-off-by: Amit Daniel Kachhap > --- > drivers/thermal/samsung/Kconfig |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig > index 2d3d9dc..145a55d 100644 > --- a/drivers/thermal/samsung/Kconfig > +++ b/drivers/thermal/samsung/Kconfig > @@ -1,6 +1,9 @@ > +config ARCH_HAS_TMU > + bool > + > config EXYNOS_THERMAL > tristate "Temperature sensor on Samsung EXYNOS" > - depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) > + depends on ARCH_HAS_TMU I would rather use ARCH_HAS_BANDGAP as discussed and agreed during your v4 review. I managed push this patch through RMK's system: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7758/1 > depends on CPU_THERMAL > help > If you say yes here you get support for TMU (Thermal Management > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] pinctrl: fix some issues with new pinconfig dt parsing
Hi Heiko, On Friday 14 June 2013 16:53:06 James Hogan wrote: > On 14/06/13 16:41, Heiko Stübner wrote: > > Some issues with the recently submitted generic pinconfig parsing from dt > > came up, so fix these in this follow-up series. > > > > Hopefully I did catch all of them. > > > > Tested on my rk3066 device. > > > > Heiko Stuebner (5): > > pinctrl: update the documentation for some pinconfig params > > pinctrl: clarify some dt pinconfig options > > pinctrl: handle zero found dt pinconfig properties better > > pinctrl: dynamically alloc temp array when parsing dt pinconf options > > patches 1-4: > Reviewed-by: James Hogan Probably too late as Linus has already applied the patches, but for 2, 3 and 4 Acked-by: Laurent Pinchart -- Regards, Laurent Pinchart -- 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 v2 0/5] clk: dt: bindings for mux, divider & gate clocks
This series introduces binding definitions for common register-mapped clock multiplexer, divider and gate IP blocks along with the corresponding setup functions for matching DT data. The bindings are similar to the struct definitions but please don't hold that against the binding: the struct definitions closely model the hardware register layout. This version incorporates review comments from the last RFC and includes the basic gate clock as well. This version is not considered RFC and hopefully can be agreed upon for 3.11, review comments notwithstanding. Also this second version of the series converts the divider implementation to use a bitmask internally. The registration APIs are not changed so existing users are not affected. This gives us a cleaner binding and a more flexible representation for more exotic hardware designs. I'm currently looking at the best way to match and setup these basic clocks without requiring every platform to write a small clock driver that matches the basic types. That is missing from this series but can be merged later as a separate change. Testing was done on OMAP4460 Panda ES using the experimental out-of-tree OMAP CCF conversion patches posted recently. Heiko, enough changed here such that I did not keep your Acked-by's and Tested-by's. But I am happy to take them again :-) Mike Turquette (5): clk: divider: replace bitfield width with mask clk: of: helper for determining number of parent clocks clk: dt: binding for basic multiplexer clock clk: dt: binding for basic divider clock clk: dt: binding for basic gate clock .../devicetree/bindings/clock/divider-clock.txt| 87 +++ .../devicetree/bindings/clock/gate-clock.txt | 34 ++ .../devicetree/bindings/clock/mux-clock.txt| 77 + arch/arm/mach-imx/clk-busy.c | 2 +- drivers/clk/clk-divider.c | 121 ++--- drivers/clk/clk-gate.c | 40 +++ drivers/clk/clk-mux.c | 62 ++- drivers/clk/clk.c | 6 + drivers/clk/mxs/clk-div.c | 2 +- include/linux/clk-private.h| 2 +- include/linux/clk-provider.h | 12 +- 11 files changed, 422 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/divider-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/gate-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/mux-clock.txt -- 1.8.1.2 -- 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 v2 5/5] clk: dt: binding for basic gate clock
Device Tree binding for the basic clock gate, plus the setup function to
register the clock. Based on the existing fixed-clock binding.
A different approach to this was proposed in 2012[1] and a similar
binding was proposed more recently[2] if anyone wants some extra
reading.
[1] http://article.gmane.org/gmane.linux.documentation/5679
[2]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137878.html
Signed-off-by: Mike Turquette
---
No change since v1, new patch
.../devicetree/bindings/clock/gate-clock.txt | 34 ++
drivers/clk/clk-gate.c | 40 ++
include/linux/clk-provider.h | 2 ++
3 files changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/gate-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/gate-clock.txt
b/Documentation/devicetree/bindings/clock/gate-clock.txt
new file mode 100644
index 000..4f1c776
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gate-clock.txt
@@ -0,0 +1,34 @@
+Binding for simple gate clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped clock gate controlled by a single bit that has only one
+input clock or parent. By default setting the specified bit gates the
+clock signal and clearing the bit ungates it.
+
+The binding must provide the register to control the gate and the bit
+shift for the corresponding gate control bit. Some clocks set the bit to
+gate the clock signal, and clear it to ungate the clock signal. The
+optional "set-bit-to-disable" specifies this behavior.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "gate-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link to phandle of parent clock
+- reg : base address for register controlling adjustable gate
+- bit-shift : bit shift for programming the clock gate
+
+Optional properties:
+- clock-output-names : from common clock binding.
+- set-bit-to-disable : inverts default gate programming. Setting the bit
+ gates the clock and clearing the bit ungates the clock.
+
+Examples:
+ clock_foo: clock_foo@4a008100 {
+ compatible = "gate-clock";
+ #clock-cells = <0>;
+ clocks = <_bar>;
+ reg = <0x4a008100 0x4>
+ bit-shift = <3>
+ };
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 790306e..3cbf54e 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
/**
* DOC: basic gatable clock which can gate and ungate it's ouput
@@ -161,3 +163,41 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
return clk;
}
+
+#ifdef CONFIG_OF
+/**
+ * of_gate_clk_setup() - Setup function for simple gate rate clock
+ */
+void of_gate_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ const char *clk_name = node->name;
+ void __iomem *reg;
+ const char *parent_name;
+ u8 clk_gate_flags = 0;
+ u8 bit_idx = 0;
+
+ of_property_read_string(node, "clock-output-names", _name);
+
+ parent_name = of_clk_get_parent_name(node, 0);
+
+ reg = of_iomap(node, 0);
+
+ if (of_property_read_u8(node, "bit-shift", _idx)) {
+ pr_err("%s: missing bit-shift property for %s\n",
+ __func__, node->name);
+ return;
+ }
+
+ if (of_property_read_bool(node, "set-bit-to-disable"))
+ clk_gate_flags |= CLK_GATE_SET_TO_DISABLE;
+
+ clk = clk_register_gate(NULL, clk_name, parent_name, 0, reg, bit_idx,
+ clk_gate_flags, NULL);
+
+ if (!IS_ERR(clk))
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+EXPORT_SYMBOL_GPL(of_gate_clk_setup);
+CLK_OF_DECLARE(gate_clk, "gate-clock", of_gate_clk_setup);
+#endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 723ce69..4aeaedb 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -232,6 +232,8 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
void __iomem *reg, u8 bit_idx,
u8 clk_gate_flags, spinlock_t *lock);
+void of_gate_clk_setup(struct device_node *node);
+
struct clk_div_table {
unsigned intval;
unsigned intdiv;
--
1.8.1.2
--
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 v2 2/5] clk: of: helper for determining number of parent clocks
Walks the "clocks" array of parent clock phandles and returns the
number.
Signed-off-by: Mike Turquette
---
No change since v1
drivers/clk/clk.c| 6 ++
include/linux/clk-provider.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index edf3fe1..a9feab6 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2081,6 +2081,12 @@ struct clk *of_clk_get_from_provider(struct
of_phandle_args *clkspec)
return clk;
}
+int of_clk_get_parent_count(struct device_node *np)
+{
+ return of_count_phandle_with_args(np, "clocks", "#clock-cells");
+}
+EXPORT_SYMBOL_GPL(of_clk_get_parent_count);
+
const char *of_clk_get_parent_name(struct device_node *np, int index)
{
struct of_phandle_args clkspec;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 4920fd1..8730cb9 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -457,6 +457,7 @@ void of_clk_del_provider(struct device_node *np);
struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
void *data);
struct clk *of_clk_src_onecell_get(struct of_phandle_args *clkspec, void
*data);
+int of_clk_get_parent_count(struct device_node *np);
const char *of_clk_get_parent_name(struct device_node *np, int index);
void of_clk_init(const struct of_device_id *matches);
--
1.8.1.2
--
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 v2 1/5] clk: divider: replace bitfield width with mask
The forthcoming Device Tree binding for the divider clock type will use
a bitfield mask instead of bitfield width, which is what the current
basic divider implementation uses.
This patch replaces the u8 width in struct clk_divider with a u32 mask.
The divider code is updated to use the bit mask internally but the two
registration functions still accept the width to maintain compatibility
with existing users.
Also updated in this patch is the clk-private.h divider macro and two
Freescale clock divider implementations that are based on struct
clk_divider.
Cc: Sascha Hauer
Cc: Shawn Guo
Signed-off-by: Mike Turquette
---
No change since v1, new patch
arch/arm/mach-imx/clk-busy.c | 2 +-
drivers/clk/clk-divider.c| 31 +++
drivers/clk/mxs/clk-div.c| 2 +-
include/linux/clk-private.h | 2 +-
include/linux/clk-provider.h | 2 +-
5 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-imx/clk-busy.c b/arch/arm/mach-imx/clk-busy.c
index 4bb1bc4..bc88e38 100644
--- a/arch/arm/mach-imx/clk-busy.c
+++ b/arch/arm/mach-imx/clk-busy.c
@@ -95,7 +95,7 @@ struct clk *imx_clk_busy_divider(const char *name, const char
*parent_name,
busy->div.reg = reg;
busy->div.shift = shift;
- busy->div.width = width;
+ busy->div.mask = BIT(width) - 1;
busy->div.lock = _ccm_lock;
busy->div_ops = _divider_ops;
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 6d55eb2..ac9cb7f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -30,8 +30,6 @@
#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
-#define div_mask(d)((1 << ((d)->width)) - 1)
-
static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
{
unsigned int maxdiv = 0;
@@ -46,12 +44,12 @@ static unsigned int _get_table_maxdiv(const struct
clk_div_table *table)
static unsigned int _get_maxdiv(struct clk_divider *divider)
{
if (divider->flags & CLK_DIVIDER_ONE_BASED)
- return div_mask(divider);
+ return divider->mask;
if (divider->flags & CLK_DIVIDER_POWER_OF_TWO)
- return 1 << div_mask(divider);
+ return 1 << divider->mask;
if (divider->table)
return _get_table_maxdiv(divider->table);
- return div_mask(divider) + 1;
+ return divider->mask + 1;
}
static unsigned int _get_table_div(const struct clk_div_table *table,
@@ -105,7 +103,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw
*hw,
unsigned int div, val;
val = readl(divider->reg) >> divider->shift;
- val &= div_mask(divider);
+ val &= divider->mask;
div = _get_div(divider, val);
if (!div) {
@@ -221,17 +219,17 @@ static int clk_divider_set_rate(struct clk_hw *hw,
unsigned long rate,
div = parent_rate / rate;
value = _get_val(divider, div);
- if (value > div_mask(divider))
- value = div_mask(divider);
+ if (value > divider->mask)
+ value = divider->mask;
if (divider->lock)
spin_lock_irqsave(divider->lock, flags);
if (divider->flags & CLK_DIVIDER_HIWORD_MASK) {
- val = div_mask(divider) << (divider->shift + 16);
+ val = divider->mask << (divider->shift + 16);
} else {
val = readl(divider->reg);
- val &= ~(div_mask(divider) << divider->shift);
+ val &= ~(divider->mask << divider->shift);
}
val |= value << divider->shift;
writel(val, divider->reg);
@@ -251,7 +249,7 @@ EXPORT_SYMBOL_GPL(clk_divider_ops);
static struct clk *_register_divider(struct device *dev, const char *name,
const char *parent_name, unsigned long flags,
- void __iomem *reg, u8 shift, u8 width,
+ void __iomem *reg, u8 shift, u32 mask,
u8 clk_divider_flags, const struct clk_div_table *table,
spinlock_t *lock)
{
@@ -260,8 +258,9 @@ static struct clk *_register_divider(struct device *dev,
const char *name,
struct clk_init_data init;
if (clk_divider_flags & CLK_DIVIDER_HIWORD_MASK) {
- if (width + shift > 16) {
- pr_warn("divider value exceeds LOWORD field\n");
+ if ((mask << shift) & 0x) {
+ pr_warn("%s: divider value exceeds LOWORD field\n",
+ __func__);
return ERR_PTR(-EINVAL);
}
}
@@ -282,7 +281,7 @@ static struct clk *_register_divider(struct device *dev,
const char *name,
/* struct clk_divider assignments */
div->reg = reg;
div->shift = shift;
- div->width = width;
+ div->mask = mask;
div->flags = clk_divider_flags;
div->lock = lock;
div->hw.init =
@@ -315,7 +314,7 @@
[PATCH v2 3/5] clk: dt: binding for basic multiplexer clock
Device Tree binding for the basic clock multiplexer, plus the setup
function to register the clock. Based on the existing fixed-clock
binding.
Includes minor beautification of clk-provider.h where some whitespace is
added and of_fixed_factor_clock_setup is relocated to maintain a
consistent style.
Signed-off-by: Mike Turquette
---
Changes since v1:
* pass shift value into clk_register_mux_table
* s/multiplexor/multiplexer/
* removed debug prints
* mask is u32, shift is u8
* DT property names use dashes instead of underscores
* DT property names are more verbose
* shift property is optional in binding and can be auto-generated from a
full 32-bit mask
.../devicetree/bindings/clock/mux-clock.txt| 77 ++
drivers/clk/clk-mux.c | 62 -
include/linux/clk-provider.h | 5 +-
3 files changed, 142 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/mux-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/mux-clock.txt
b/Documentation/devicetree/bindings/clock/mux-clock.txt
new file mode 100644
index 000..8fa370e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mux-clock.txt
@@ -0,0 +1,77 @@
+Binding for simple mux clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped multiplexer with multiple input clock signals or
+parents, one of which can be selected as output. This clock does not
+gate or adjust the parent rate via a divider or multiplier.
+
+By default the "clocks" property lists the parents in the same order
+as they are programmed into the regster. E.g:
+
+ clocks = <_clock>, <_clock>, <_clock>;
+
+results in programming the register as follows:
+
+register value selected parent clock
+0 foo_clock
+1 bar_clock
+2 baz_clock
+
+Some clock controller IPs do not allow a value of zero to be programmed
+into the register, instead indexing begins at 1. The optional property
+"index_one" modified the scheme as follows:
+
+register value selected clock parent
+1 foo_clock
+2 bar_clock
+3 baz_clock
+
+Additionally an optional table of bit and parent pairs may be supplied
+like so:
+
+ table = <_clock 0x0>, <_clock, 0x2>, <_clock, 0x4>;
+
+where the first value in the pair is the parent clock and the second
+value is the bitfield to be programmed into the register.
+
+The binding must provide the register to control the mux and the mask
+for the corresponding control bits. Optionally the number of bits to
+shift that mask if necessary. If the shift value is missing it is the
+same as supplying a zero shift.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "mux-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks
+- reg : base address for register controlling adjustable mux
+- bit-mask : arbitrary bitmask for programming the adjustable mux
+
+Optional properties:
+- clock-output-names : From common clock binding.
+- table : array of integer pairs defining parents & bitfield values
+- bit-shift : number of bits to shift the bit-mask, defaults to
+ (ffs(mask) - 1) if not present
+- index-starts-at-one : valid input select programming starts at 1, not
+ zero
+
+Examples:
+ clock: clock@4a008100 {
+ compatible = "mux-clock";
+ #clock-cells = <0>;
+ clocks = <_foo>, <_bar>, <_baz>;
+ reg = <0x4a008100 0x4>
+ mask = <0x3>;
+ index_one;
+ };
+
+ clock: clock@4a008100 {
+ #clock-cells = <0>;
+ compatible = "mux-clock";
+ clocks = <_foo>, <_bar>, <_baz>;
+ reg = <0x4a008100 0x4>;
+ mask = <0x3>;
+ shift = <0>;
+ table = <_foo 1>, <_bar 2>, <_baz 3>;
+ };
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 61c..a640228 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -1,7 +1,7 @@
/*
* Copyright (C) 2011 Sascha Hauer, Pengutronix
* Copyright (C) 2011 Richard Zhao, Linaro
- * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd
+ * Copyright (C) 2011-2013 Mike Turquette, Linaro Ltd
*
* 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
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include
/*
* DOC: basic adjustable multiplexer clock that cannot gate
@@ -166,3 +168,61 @@ struct clk *clk_register_mux(struct device *dev, const
char *name,
flags, reg, shift, mask, clk_mux_flags,
NULL, lock);
}
+
+#ifdef CONFIG_OF
+/**
+ *
[PATCH v2 4/5] clk: dt: binding for basic divider clock
Devicetree binding for the basic clock divider, plus the setup function
to register the clock. Based on the existing fixed-clock binding.
Signed-off-by: Mike Turquette
---
Changes since v1:
* mask is u32, shift is u8
* use bit mask instead of bitfield width
* DT property names use dashes instead of underscores
* DT property names are more verbose
* added minimum/maximum divider values to binding
* shift property is optional in binding and can be auto-generated from a
full 32-bit mask
.../devicetree/bindings/clock/divider-clock.txt| 87 +
drivers/clk/clk-divider.c | 90 +-
include/linux/clk-provider.h | 2 +
3 files changed, 178 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/divider-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/divider-clock.txt
b/Documentation/devicetree/bindings/clock/divider-clock.txt
new file mode 100644
index 000..96bea07
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/divider-clock.txt
@@ -0,0 +1,87 @@
+Binding for simple divider clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped adjustable clock rate divider that does not gate and has
+only one input clock or parent. By default the value programmed into
+the register is one less than the actual divisor value. E.g:
+
+register value actual divisor value
+0 1
+1 2
+2 3
+
+This assumption may be modified by the following optional properties:
+
+index-starts-at-one - valid divisor values start at 1, not the default
+of 0. E.g:
+register value actual divisor value
+1 1
+2 2
+3 3
+
+index-power-of-two - valid divisor values are powers of two. E.g:
+register value actual divisor value
+0 1
+1 2
+2 4
+
+index-allow-zero - same as index_one, but zero is divide-by-1. E.g:
+register value actual divisor value
+0 1
+1 1
+2 2
+
+Additionally a table of valid dividers may be supplied like so:
+
+ table = <4 0>, <8, 1>;
+
+where the first value in the pair is the divider and the second value is
+the programmed register bitfield.
+
+The binding must also provide the register to control the divider and
+the mask for the corresponding control bits. Optionally the number of
+bits to shift that mask, if necessary. If the shift value is missing it
+is the same as supplying a zero shift.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "divider-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link to phandle of parent clock
+- reg : base address for register controlling adjustable divider
+- bit-mask : arbitrary bitmask for programming the adjustable divider
+
+Optional properties:
+- clock-output-names : from common clock binding.
+- table : array of integer pairs defining divisors & bitfield values
+- bit-shift : number of bits to shift the bit-mask, defaults to
+ (ffs(mask) - 1) if not present
+- minimum-divider : min divisor for dividing the input clock rate, only
+ needed if the first divisor is offset from the default value
+- maximum-divider : max divisor for dividing the input clock rate, only
+ needed if the max divisor is less than (mask + 1).
+- index-starts-at-one : valid divisor programming starts at 1, not zero
+- index-power-of-two : valid divisor programming must be a power of two
+- index-allow-zero : implies index-one, and programming zero results in
+ divide-by-one
+
+Examples:
+ clock_foo: clock_foo@4a008100 {
+ compatible = "divider-clock";
+ #clock-cells = <0>;
+ clocks = <_baz>;
+ reg = <0x4a008100 0x4>
+ mask = <0x3>
+ maximum-divider = <3>
+ };
+
+ clock_bar: clock_bar@4a008108 {
+ #clock-cells = <0>;
+ compatible = "divider-clock";
+ clocks = <_foo>;
+ reg = <0x4a008108 0x4>;
+ mask = <0x1>;
+ shift = <0>;
+ table = < 4 0 >, < 8 1 >;
+ };
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index ac9cb7f..8c42c7f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -1,7 +1,7 @@
/*
* Copyright (C) 2011 Sascha Hauer, Pengutronix
* Copyright (C) 2011 Richard Zhao, Linaro
- * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd
+ * Copyright (C) 2011-2013 Mike Turquette, Linaro Ltd
*
* 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
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
Re: [PATCH 0/2] etzkx accelerometer support
On Mon, Jun 17, 2013 at 12:26:48AM +0200, Andi Shyti wrote: > > > these two patches provide the etzkx device driver which supports > > > the following accelerometers: > > > > > > - Kionix kxcnl > > > - Kionix kxtnk > > > - ST lisn3dsh > > > > > > Support for ST lis3dsh accelerometer is still in progress. > > > > > > The etzkx accelerometers are a kind of devices that are able to > > > do gesture recognition directly on the device. It uses two slots > > > of 16 steps (bytes) each for loading algorithms which perform > > > gesture recognition. > > > > > > The second patch contains the documentation of the device driver. > > > > > > On http://www.etezian.org/etzkx/etzkx/ is possible to find more > > > informations about the accelerometer. > > > > Why isn't this a drivers/iio/accel/ driver instead of a misc driver? > > Please make this an iio driver, then you will be using the correct > > user/kernel api to talk to your device. > > I was thinking it may be an issue, but it's not iio because the > time I developed the driver, iio was in the first staging period > and mainly because the on the board I'm using I cannot update the > Kernel to use the latest iio. > > I guess you don't like the promise "I can do it later" once the > supplier sends me a development board (which is planned) :) Sure, I'll gladly accept "I can do it later" from anyone, as long as you don't mind my, "I will merge it later" as well :) Sorry, I can't accept a driver now, that is known to going to be changing the kernel/user api in the future. So please, rewrite it to use IIO, that's what that interface / subsystem is there for. thanks, greg k-h -- 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/RFC] arm: arch_timer: Do not set C3STOP in case CPU_IDLE=n
On Mon, Jun 17, 2013 at 11:47:11AM +0900, Magnus Damm wrote: > Hi Simon, > > On Mon, Jun 17, 2013 at 11:13 AM, Simon Horman wrote: > > On Mon, Jun 17, 2013 at 09:20:56AM +0900, Magnus Damm wrote: > >> From: Magnus Damm > >> > >> Modify the ARM architected timer driver to not set C3STOP > >> in case CPU_IDLE is disabled. This is a short term fix that > >> allows use of high resolution timers even though no additional > >> clock event is registered. > >> > >> Not-really-Signed-off-by: Magnus Damm > >> --- > >> > >> If someone cares about this case then perhaps it should be > >> moved up to the clock event main code. The same issue should > >> in theory trigger on all architectures, perhaps x86 people > >> hunting for low latency may try to disable CPU_IDLE? > >> > >> I propose carrying this patch locally to enable high resolution > >> timers until CPU_IDLE and an additional clock event is supported. > >> > >> Observed on r8a73a4 and APE6EVM. > > > > Hi Magnus, > > > > Is this patch intended to be picked up by me for the LTSI-3.4.25 based > > backports that live in my renesas-backports tree? > > Yes, correct. > > The patch was mainly written to satisfy a feature request for your > backports, but I noticed that the same issue exists in upstream as > well. > > Ideally I'd like to use the same code for the backport and upstream, > but I am not sure if anyone in upstream really cares. The more long > term solution is obviously to install a second clock event, perhaps > that's good enough. > > > If so, could you clearly state this (below the '---' is fine) and > > include a proper Sob line to indicate that it is fit to be merged > > even if that merge is not into mainline. > > Sure, but I'd like to hear opinions from other people before > resending. I will follow your recommendation in next version. Thanks, I understand. I'll wait for discussion and a new version. -- 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] tracing/uprobes: Support ftrace_event_file base multibuffer
(2013/06/15 2:25), Paul E. McKenney wrote:
> On Fri, Jun 14, 2013 at 12:33:27PM -0400, Steven Rostedt wrote:
>> On Fri, 2013-06-14 at 09:21 -0700, Paul E. McKenney wrote:
>>
>> @@ -548,15 +556,35 @@ static void uprobe_trace_print(struct trace_uprobe
>> *tu,
>> /* uprobe handler */
>> static int uprobe_trace_func(struct trace_uprobe *tu, struct pt_regs
>> *regs)
>> {
>> -if (!is_ret_probe(tu))
>> -uprobe_trace_print(tu, 0, regs);
>> +struct ftrace_event_file **file;
>> +
>> +if (is_ret_probe(tu))
>> +return 0;
>> +
>> +file = rcu_dereference_raw(tu->files);
Why are you using rcu_dereference_raw() and not rcu_dereference(). The
_raw() is a bit special, and unless you know what you are doing with RCU
here, don't use it.
As I see you using rcu_dereference_raw() all over this patch, along with
mutexes, I believe that you are not using RCU correctly here.
>>>
>>> If irqs and preempt are disabled, I suggest using rcu_dereference_sched().
>>> That is what it is there for. ;-)
>>
>> I believe this just copied what kprobes did, where irqs and preemption
>> is disabled. I don't believe that these probes have that same luxury.
>>
>> But that begs the question. Should we convert the rcu_dereference_raw()
>> in the kprobe code to rcu_dereference_sched()?
>
> It makes a lot of sense to me, at least assuming no issues with the
> interrupts being disabled, but the checks not spotting this. Here
> is the check:
>
> preempt_count() != 0 || irqs_disabled()
>
> (With additional elaboration for if lockdep is enabled.)
OK, I see. So I'll convert all the rcu_dereference_raw() to
rcu_dereference_sched() except kprobe handler, because in the
kprobe handler above check always be true. :)
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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/
Re: [PATCH] pinctrl: establish pull-up/pull-down terminology
Hi Linus, On Sunday 16 June 2013 12:45:48 Linus Walleij wrote: > From: Linus Walleij > > It is counter-intuitive to have "0" mean disable in a boolean > manner for electronic properties of pins such as pull-up and > pull-down. Therefore, define that a pull-up/pull-down argument > of 0 to such a generic option means that the pin is > short-circuited to VDD or GROUND. Pull disablement shall be > done using PIN_CONFIG_BIAS_DISABLE. > > Cc: Heiko St�bner > Cc: James Hogan > Cc: Laurent Pinchart > Signed-off-by: Linus Walleij Nice clarification, thank you. Acked-by: Laurent Pinchart (with one small comment below) > --- > include/linux/pinctrl/pinconf-generic.h | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/include/linux/pinctrl/pinconf-generic.h > b/include/linux/pinctrl/pinconf-generic.h index d414a77..67780f5 100644 > --- a/include/linux/pinctrl/pinconf-generic.h > +++ b/include/linux/pinctrl/pinconf-generic.h > @@ -36,14 +36,15 @@ > * tristate. The argument is ignored. > * @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with high > * impedance to VDD). If the argument is != 0 pull-up is enabled, > - * if it is 0, pull-up is disabled. > + * if it is 0, pull-up it total, i.e. the pin is connected to VDD. > * @PIN_CONFIG_BIAS_PULL_DOWN: the pin will be pulled down (usually with > high *impedance to GROUND). If the argument is != 0 pull-down is > enabled, > - * if it is 0, pull-down is disabled. > + * if it is 0, pull-down is total, i.e. the pin is connected to GROUND. > * @PIN_CONFIG_BIAS_PULL_PIN_DEFAULT: the pin will be pulled up or down > based * on embedded knowledge of the controller, like current mux > function. > - * If the argument is != 0 pull up/down is enabled, if it is 0, > - * the pull is disabled. > + * If the argument is != 0 pull up/down is enabled, if it is 0, the > + * configuration is ignored. The proper way to disable it is to use > + * @PIN_CONFIG_BIAS_DISABLE. > * @PIN_CONFIG_DRIVE_PUSH_PULL: the pin will be driven actively high and > * low, this is the most typical case and is typically achieved with two > * active transistors on the output. Setting this config will enable > @@ -72,8 +73,8 @@ > * supplies, the argument to this parameter (on a custom format) tells > * the driver which alternative power source to use. > * @PIN_CONFIG_SLEW_RATE: if the pin can select slew rate, the argument to > - * this parameter (on a custom format) tells the driver which alternative > - * slew rate to use. > + * this parameter (on a custom format) tells the driver which alternative > + * slew rate to use. This hunk doesn't seem to belong to the patch. > * @PIN_CONFIG_LOW_POWER_MODE: this will configure the pin for low power > * operation, if several modes of operation are supported these can be > * passed in the argument on a custom form, else just use argument 1 -- Regards, Laurent Pinchart -- 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/RFC] arm: arch_timer: Do not set C3STOP in case CPU_IDLE=n
Hi Simon, On Mon, Jun 17, 2013 at 11:13 AM, Simon Horman wrote: > On Mon, Jun 17, 2013 at 09:20:56AM +0900, Magnus Damm wrote: >> From: Magnus Damm >> >> Modify the ARM architected timer driver to not set C3STOP >> in case CPU_IDLE is disabled. This is a short term fix that >> allows use of high resolution timers even though no additional >> clock event is registered. >> >> Not-really-Signed-off-by: Magnus Damm >> --- >> >> If someone cares about this case then perhaps it should be >> moved up to the clock event main code. The same issue should >> in theory trigger on all architectures, perhaps x86 people >> hunting for low latency may try to disable CPU_IDLE? >> >> I propose carrying this patch locally to enable high resolution >> timers until CPU_IDLE and an additional clock event is supported. >> >> Observed on r8a73a4 and APE6EVM. > > Hi Magnus, > > Is this patch intended to be picked up by me for the LTSI-3.4.25 based > backports that live in my renesas-backports tree? Yes, correct. The patch was mainly written to satisfy a feature request for your backports, but I noticed that the same issue exists in upstream as well. Ideally I'd like to use the same code for the backport and upstream, but I am not sure if anyone in upstream really cares. The more long term solution is obviously to install a second clock event, perhaps that's good enough. > If so, could you clearly state this (below the '---' is fine) and > include a proper Sob line to indicate that it is fit to be merged > even if that merge is not into mainline. Sure, but I'd like to hear opinions from other people before resending. I will follow your recommendation in next version. Thanks, / magnus -- 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: manual merge of the net-next tree with Linus' tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/batman-adv/bat_iv_ogm.c between commit 7c24bbbeab41 ("batman-adv:
forward late OGMs from best next hop") from Linus' tree and commit
24a5deeb8a19 ("batman-adv: move ring_buffer helper functions in
bat_iv_ogm") from the net-next tree.
I fixed it up (as specified in your email (thanks) - see below) and can
carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/batman-adv/bat_iv_ogm.c
index f680ee1,d07323b..000
--- a/net/batman-adv/bat_iv_ogm.c
+++ b/net/batman-adv/bat_iv_ogm.c
@@@ -30,20 -29,47 +29,63 @@@
#include "network-coding.h"
/**
+ * batadv_dup_status - duplicate status
+ * @BATADV_NO_DUP: the packet is a duplicate
+ * @BATADV_ORIG_DUP: OGM is a duplicate in the originator (but not for the
+ * neighbor)
+ * @BATADV_NEIGH_DUP: OGM is a duplicate for the neighbor
+ * @BATADV_PROTECTED: originator is currently protected (after reboot)
+ */
+enum batadv_dup_status {
+ BATADV_NO_DUP = 0,
+ BATADV_ORIG_DUP,
+ BATADV_NEIGH_DUP,
+ BATADV_PROTECTED,
+};
+
++/**
+ * batadv_ring_buffer_set - update the ring buffer with the given value
+ * @lq_recv: pointer to the ring buffer
+ * @lq_index: index to store the value at
+ * @value: value to store in the ring buffer
+ */
+ static void batadv_ring_buffer_set(uint8_t lq_recv[], uint8_t *lq_index,
+ uint8_t value)
+ {
+ lq_recv[*lq_index] = value;
+ *lq_index = (*lq_index + 1) % BATADV_TQ_GLOBAL_WINDOW_SIZE;
+ }
+
+ /**
+ * batadv_ring_buffer_set - compute the average of all non-zero values stored
+ * in the given ring buffer
+ * @lq_recv: pointer to the ring buffer
+ *
+ * Returns computed average value.
+ */
+ static uint8_t batadv_ring_buffer_avg(const uint8_t lq_recv[])
+ {
+ const uint8_t *ptr;
+ uint16_t count = 0, i = 0, sum = 0;
+
+ ptr = lq_recv;
+
+ while (i < BATADV_TQ_GLOBAL_WINDOW_SIZE) {
+ if (*ptr != 0) {
+ count++;
+ sum += *ptr;
+ }
+
+ i++;
+ ptr++;
+ }
+
+ if (count == 0)
+ return 0;
+
+ return (uint8_t)(sum / count);
+ }
++
static struct batadv_neigh_node *
batadv_iv_ogm_neigh_new(struct batadv_hard_iface *hard_iface,
const uint8_t *neigh_addr,
@@@ -1013,11 -1062,10 +1085,11 @@@ static void batadv_iv_ogm_process(cons
struct batadv_neigh_node *orig_neigh_router = NULL;
int has_directlink_flag;
int is_my_addr = 0, is_my_orig = 0, is_my_oldorig = 0;
- int is_broadcast = 0, is_bidirect;
+ int is_bidirect;
bool is_single_hop_neigh = false;
bool is_from_best_next_hop = false;
- int is_duplicate, sameseq, simlar_ttl;
+ int sameseq, similar_ttl;
+ enum batadv_dup_status dup_status;
uint32_t if_incoming_seqno;
uint8_t *prev_sender;
pgpWafjb33rCn.pgp
Description: PGP signature
Re: [PATCH 1/2] f2fs: add remount_fs callback support
On 06/16/2013 08:48 AM, Namjae Jeon wrote:
> From: Namjae Jeon
>
> Add the f2fs_remount function call which will be used
> during the filesystem remounting. This function
> will help us to change the mount options specific to
> f2fs.
>
> Also modify the f2fs background_gc mount option, which
> will allow the user to dynamically trun on/off the
> garbage collection in f2fs based on the background_gc
> value. If background_gc=on, Garbage collection will
> be turned off & if background_gc=off, Garbage collection
> will be truned on.
>
> By default the garbage collection is on in f2fs.
>
> Change Log:
> v2: Incorporated the review comments by Gu Zheng.
> Removing the restore part for VFS flags
> Updating comments with proper flag conditions
> Display GC background option as ON/OFF
> Revised conditions to stop GC in case of remount
>
> v1: Initial changes for adding remount_fs callback
> support.
>
> Cc: Gu Zheng
> Signed-off-by: Namjae Jeon
> Signed-off-by: Pankaj Kumar
Reviewed-by: Gu Zheng
Thanks,
Gu
> ---
> Documentation/filesystems/f2fs.txt |9 +-
> fs/f2fs/super.c| 235
> +++-
> 2 files changed, 160 insertions(+), 84 deletions(-)
>
> diff --git a/Documentation/filesystems/f2fs.txt
> b/Documentation/filesystems/f2fs.txt
> index bd3c56c..b91e2f2 100644
> --- a/Documentation/filesystems/f2fs.txt
> +++ b/Documentation/filesystems/f2fs.txt
> @@ -98,8 +98,13 @@ Cleaning Overhead
> MOUNT OPTIONS
>
>
>
> -background_gc_off Turn off cleaning operations, namely garbage
> collection,
> -triggered in background when I/O subsystem is idle.
> +background_gc=%s Turn on/off cleaning operations, namely garbage
> + collection, triggered in background when I/O
> subsystem is
> + idle. If background_gc=on, it will turn on the garbage
> + collection and if background_gc=off, garbage
> collection
> + will be truned off.
> + Default value for this option is on. So garbage
> + collection is on by default.
> disable_roll_forward Disable the roll-forward recovery routine
> discardIssue discard/TRIM commands when a segment is cleaned.
> no_heapDisable heap-style segment allocation which finds free
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index ba56549..5a11484 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -34,7 +34,7 @@
> static struct kmem_cache *f2fs_inode_cachep;
>
> enum {
> - Opt_gc_background_off,
> + Opt_gc_background,
> Opt_disable_roll_forward,
> Opt_discard,
> Opt_noheap,
> @@ -46,7 +46,7 @@ enum {
> };
>
> static match_table_t f2fs_tokens = {
> - {Opt_gc_background_off, "background_gc_off"},
> + {Opt_gc_background, "background_gc=%s"},
> {Opt_disable_roll_forward, "disable_roll_forward"},
> {Opt_discard, "discard"},
> {Opt_noheap, "no_heap"},
> @@ -76,6 +76,91 @@ static void init_once(void *foo)
> inode_init_once(>vfs_inode);
> }
>
> +static int parse_options(struct super_block *sb, char *options)
> +{
> + struct f2fs_sb_info *sbi = F2FS_SB(sb);
> + substring_t args[MAX_OPT_ARGS];
> + char *p, *name;
> + int arg = 0;
> +
> + if (!options)
> + return 0;
> +
> + while ((p = strsep(, ",")) != NULL) {
> + int token;
> + if (!*p)
> + continue;
> + /*
> + * Initialize args struct so we know whether arg was
> + * found; some options take optional arguments.
> + */
> + args[0].to = args[0].from = NULL;
> + token = match_token(p, f2fs_tokens, args);
> +
> + switch (token) {
> + case Opt_gc_background:
> + name = match_strdup([0]);
> +
> + if (!name)
> + return -ENOMEM;
> + if (!strncmp(name, "on", 2))
> + set_opt(sbi, BG_GC);
> + else if (!strncmp(name, "off", 3))
> + clear_opt(sbi, BG_GC);
> + else {
> + kfree(name);
> + return -EINVAL;
> + }
> + kfree(name);
> + break;
> + case Opt_disable_roll_forward:
> + set_opt(sbi, DISABLE_ROLL_FORWARD);
> + break;
> + case Opt_discard:
> + set_opt(sbi, DISCARD);
> + break;
> + case Opt_noheap:
> + set_opt(sbi, NOHEAP);
> + break;
> +#ifdef CONFIG_F2FS_FS_XATTR
> + case Opt_nouser_xattr:
linux-next: manual merge of the net-next tree with Linus' tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/xen-netback/netback.c between commit 94f950c4060c
("xen-netback: don't de-reference vif pointer after having called
xenvif_put()") from Linus' tree and commit e1f00a69ec26 ("xen-netback:
split event channels support for Xen backend driver") from the net-next
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/xen-netback/netback.c
index 8c20935,82576ff..000
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@@ -783,9 -789,8 +790,9 @@@ static void xen_netbk_rx_action(struct
}
list_for_each_entry_safe(vif, tmp, , notify_list) {
- notify_remote_via_irq(vif->irq);
+ notify_remote_via_irq(vif->rx_irq);
list_del_init(>notify_list);
+ xenvif_put(vif);
}
/* More work to do? */
pgppAhk4V5ekh.pgp
Description: PGP signature
Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO
"Michael S. Tsirkin" writes: > On Wed, Jun 12, 2013 at 03:56:36PM +0100, Ben Hutchings wrote: >> On Mon, 2013-06-10 at 10:07 +0300, Michael S. Tsirkin wrote: >> > On Thu, Feb 07, 2013 at 01:14:20PM -0500, David Miller wrote: >> > > From: Ben Hutchings >> > > Date: Thu, 7 Feb 2013 16:20:46 + >> > > >> > > > If the consensus is still that we must preserve packets exactly (aside >> > > > from the usual modifications by IP routers) then LRO should be disabled >> > > > on all devices for which forwarding is enabled. >> > > >> > > I believe this is still undoubtedly the consensus. >> > >> > With virtio we are getting packets from a linux host, >> > so we could thinkably preserve packets exactly >> > even with LRO. I am guessing other hardware could be >> > doing this as well. >> > >> > I am not sure what information would need to be preserved - >> > could someone help clarify please? >> >> Some LRO implementations may not preserve: >> >> - Packet boundaries >> - TSO/GSO produces packets all the same size, except possibly for the >> last one. GRO therefore flushes a flow after merging a packet with >> a different segment size. >> - IPv4 TTL, IPv6 hop-limit, TCP timestamp >> - TSO/GSO will put the same values in all packets. GRO flushes a flow >> if they change. >> - IPv4 fragment ID >> - TSO/GSO produces consecutive fragment IDs. GRO flushes a flow >> if it sees a non-consecutive fragment ID. >> - MAC header, IPv4 TOS, IPv6 traffic class >> - Should be the same for all packets in a flow. GRO actually checks >> and flushes a flow if they change. >> >> Ben. > > Thanks! > > Okay so since LRO in virtio is actually running on top > of GRO/TSO in linux, looks like the only things worth preserving > that we don't preserve at the moment are the packet > boundaries, for which it's enough to report > the first segment size to guest - we have the total length, > from that we can calculate the last segment size. Isn't this reflected in virtio_net_hdr->gso_size? But the bigger point here is that we shouldn't be feeding guests LRO packets which don't meet the stricter GRO requirements, as we don't know what the guest is doing with them. It might be forwarding them itself. I thought LRO was deprecated and GRO was the new hotness, but I haven't been following. Do we still care about LRO? Cheers, Rusty. -- 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] sched: add heuristic logic to pick idle peers
nr_busy_cpus in sched_group_power structure cannot present the purpose
for judging below statement:
"this cpu's scheduler group has multiple busy cpu's exceeding
the group's power."
But only could tell how many cpus is doing their jobs for currently.
However, the original purpose to add this logic still looks good.
So we move this kind of logic to find_new_ilb, so that we could pick
out peer from our sharing resource domain whenever possible.
Signed-off-by: Lei Wen
---
kernel/sched/fair.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c61a614..64f9120 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5368,10 +5368,31 @@ static struct {
unsigned long next_balance; /* in jiffy units */
} nohz cacheline_aligned;
+/*
+ * Add the heuristic logic to try waking up idle cpu from
+ * those peers who share resources with us, so that the
+ * cost would be brought to minimum.
+ */
static inline int find_new_ilb(int call_cpu)
{
- int ilb = cpumask_first(nohz.idle_cpus_mask);
+ int ilb = nr_cpu_ids;
+ struct sched_domain *sd;
+
+ rcu_read_lock();
+ for_each_domain(call_cpu, sd) {
+ /* We loop till sched_domain no longer share resource */
+ if (!(sd->flags & SD_SHARE_PKG_RESOURCES)) {
+ ilb = cpumask_first(nohz.idle_cpus_mask);
+ break;
+ }
+ /* else, we would try to pick the idle cpu from peers first */
+ ilb = cpumask_first_and(nohz.idle_cpus_mask,
+ sched_domain_span(sd));
+ if (ilb < nr_cpu_ids)
+ break;
+ }
+ rcu_read_unlock();
if (ilb < nr_cpu_ids && idle_cpu(ilb))
return ilb;
@@ -5620,8 +5641,6 @@ end:
* Current heuristic for kicking the idle load balancer in the presence
* of an idle cpu is the system.
* - This rq has more than one task.
- * - At any scheduler domain level, this cpu's scheduler group has multiple
- * busy cpu's exceeding the group's power.
* - For SD_ASYM_PACKING, if the lower numbered cpu's in the scheduler
* domain span are idle.
*/
@@ -5659,9 +5678,6 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
struct sched_group_power *sgp = sg->sgp;
int nr_busy = atomic_read(>nr_busy_cpus);
- if (sd->flags & SD_SHARE_PKG_RESOURCES && nr_busy > 1)
- goto need_kick_unlock;
-
if (sd->flags & SD_ASYM_PACKING && nr_busy != sg->group_weight
&& (cpumask_first_and(nohz.idle_cpus_mask,
sched_domain_span(sd)) < cpu))
--
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: [Part3 PATCH v2 0/4] Support hot-remove local pagetable pages.
On 06/17/2013 09:58 AM, Jianguo Wu wrote: Hi Tang, On 2013/6/13 21:03, Tang Chen wrote: The following patch-set from Yinghai allocates pagetables to local nodes. v1: https://lkml.org/lkml/2013/3/7/642 v2: https://lkml.org/lkml/2013/3/10/47 v3: https://lkml.org/lkml/2013/4/4/639 v4: https://lkml.org/lkml/2013/4/11/829 Since pagetable pages are used by the kernel, they cannot be offlined. As a result, they cannot be hot-remove. This patch fix this problem with the following solution: 1. Introduce a new bootmem type LOCAL_NODE_DATAL, and register local pagetable pages as LOCAL_NODE_DATAL by setting page->lru.next to LOCAL_NODE_DATAL, just like we register SECTION_INFO pages. 2. Skip LOCAL_NODE_DATAL pages in offline/online procedures. When the whole memory block they reside in is offlined, the kernel can still access the pagetables. (This changes the semantics of offline/online a little bit.) 3. Do not free LOCAL_NODE_DATAL pages to buddy system because they were skipped when in offline/online procedures. The memory block they reside in could have been offlined. s/LOCAL_NODE_DATAL/LOCAL_NODE_DATA Oh...thank you. Will send a new version soon. :) Anyway, this problem should be fixed. Any better idea is welcome. Change log: v1 -> v2: patch2: As suggested by Wu Jianguo, define a macro to check if a page cantains local node data. patch4: As suggested by Wu Jianguo, prevent freeing LOCAL_NODE_DATA pages in free_pagetable() instead of in put_page_bootmem(). Tang Chen (4): bootmem, mem-hotplug: Register local pagetable pages with LOCAL_NODE_DATA when freeing bootmem. mem-hotplug: Skip LOCAL_NODE_DATA pages in memory offline procedure. mem-hotplug: Skip LOCAL_NODE_DATA pages in memory online procedure. mem-hotplug: Do not free LOCAL_NODE_DATA pages to buddy system in hot-remove procedure. arch/x86/mm/init_64.c | 10 +++- include/linux/memblock.h | 22 + include/linux/memory_hotplug.h | 20 +-- mm/memblock.c | 52 mm/memory_hotplug.c| 31 +++ mm/page_alloc.c| 15 ++- mm/page_isolation.c|5 7 files changed, 149 insertions(+), 6 deletions(-) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email:mailto:"d...@kvack.org;> em...@kvack.org . -- 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/ -- 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/RFC] arm: arch_timer: Do not set C3STOP in case CPU_IDLE=n
On Mon, Jun 17, 2013 at 09:20:56AM +0900, Magnus Damm wrote:
> From: Magnus Damm
>
> Modify the ARM architected timer driver to not set C3STOP
> in case CPU_IDLE is disabled. This is a short term fix that
> allows use of high resolution timers even though no additional
> clock event is registered.
>
> Not-really-Signed-off-by: Magnus Damm
> ---
>
> If someone cares about this case then perhaps it should be
> moved up to the clock event main code. The same issue should
> in theory trigger on all architectures, perhaps x86 people
> hunting for low latency may try to disable CPU_IDLE?
>
> I propose carrying this patch locally to enable high resolution
> timers until CPU_IDLE and an additional clock event is supported.
>
> Observed on r8a73a4 and APE6EVM.
Hi Magnus,
Is this patch intended to be picked up by me for the LTSI-3.4.25 based
backports that live in my renesas-backports tree?
If so, could you clearly state this (below the '---' is fine) and
include a proper Sob line to indicate that it is fit to be merged
even if that merge is not into mainline.
Thanks
>
> drivers/clocksource/arm_arch_timer.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> --- 0001/drivers/clocksource/arm_arch_timer.c
> +++ work/drivers/clocksource/arm_arch_timer.c 2013-06-17 09:03:44.0
> +0900
> @@ -125,7 +125,23 @@ static int arch_timer_set_next_event_phy
>
> static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
> {
> - clk->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP;
> + clk->features = CLOCK_EVT_FEAT_ONESHOT;
> +#ifdef CONFIG_CPU_IDLE
> + /* By not setting the C3STOP flag it is possible to let the
> + * ARM architected timer to be the only clock event installed
> + * on the system and have working high resolution timers.
> + *
> + * If the C3STOP flag is set unconditionally then the kernel
> + * will always prevent using the high resoultion timer feature
> + * unless an additional clock event is registered.
> + *
> + * In the case where CPU_IDLE is enabled then there is a chance
> + * that deeper sleep states will be handled by software, but
> + * if CPU_IDLE is disabled then deep sleep states cannot be
> + * entered and the feature flagged by C3STOP is not needed.
> + */
> + clk->features |= CLOCK_EVT_FEAT_C3STOP;
> +#endif
> clk->name = "arch_sys_timer";
> clk->rating = 450;
> if (arch_timer_use_virtual) {
>
--
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: [Part3 PATCH v2 0/4] Support hot-remove local pagetable pages.
Hi Tang, On 2013/6/13 21:03, Tang Chen wrote: > The following patch-set from Yinghai allocates pagetables to local nodes. > v1: https://lkml.org/lkml/2013/3/7/642 > v2: https://lkml.org/lkml/2013/3/10/47 > v3: https://lkml.org/lkml/2013/4/4/639 > v4: https://lkml.org/lkml/2013/4/11/829 > > Since pagetable pages are used by the kernel, they cannot be offlined. > As a result, they cannot be hot-remove. > > This patch fix this problem with the following solution: > > 1. Introduce a new bootmem type LOCAL_NODE_DATAL, and register local > pagetable pages as LOCAL_NODE_DATAL by setting page->lru.next to > LOCAL_NODE_DATAL, just like we register SECTION_INFO pages. > > 2. Skip LOCAL_NODE_DATAL pages in offline/online procedures. When the > whole memory block they reside in is offlined, the kernel can > still access the pagetables. > (This changes the semantics of offline/online a little bit.) > > 3. Do not free LOCAL_NODE_DATAL pages to buddy system because they > were skipped when in offline/online procedures. The memory block > they reside in could have been offlined. > s/LOCAL_NODE_DATAL/LOCAL_NODE_DATA > Anyway, this problem should be fixed. Any better idea is welcome. > > Change log: > v1 -> v2: > patch2: As suggested by Wu Jianguo, define a macro to check if a page > cantains local node data. > patch4: As suggested by Wu Jianguo, prevent freeing LOCAL_NODE_DATA > pages in free_pagetable() instead of in put_page_bootmem(). > > Tang Chen (4): > bootmem, mem-hotplug: Register local pagetable pages with > LOCAL_NODE_DATA when freeing bootmem. > mem-hotplug: Skip LOCAL_NODE_DATA pages in memory offline procedure. > mem-hotplug: Skip LOCAL_NODE_DATA pages in memory online procedure. > mem-hotplug: Do not free LOCAL_NODE_DATA pages to buddy system in > hot-remove procedure. > > arch/x86/mm/init_64.c | 10 +++- > include/linux/memblock.h | 22 + > include/linux/memory_hotplug.h | 20 +-- > mm/memblock.c | 52 > > mm/memory_hotplug.c| 31 +++ > mm/page_alloc.c| 15 ++- > mm/page_isolation.c|5 > 7 files changed, 149 insertions(+), 6 deletions(-) > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org > > . > -- 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: Add unlikely for current_order test
Hi David, On 06/17/2013 02:04 AM, David Rientjes wrote: > On Sat, 15 Jun 2013, Zhang Yanfei wrote: > >> From: Zhang Yanfei >> >> Since we have an unlikely for the "current_order >= pageblock_order / 2" >> test above, adding an unlikely for this "current_order >= pageblock_order" >> test seems more appropriate. >> > > I don't understand the justification at all, current_order being unlikely > greater than or equal to pageblock_order / 2 doesn't imply at all that > it's unlikely that current_order is greater than or equal to > pageblock_order. > hmmm... I am confused. Since current_order is >= pageblock_order / 2 is unlikely, why current_order is >= pageblock_order isn't unlikely. Or there are other tips? Actually, I am also a little confused about why current_order should be unlikely greater than or equal to pageblock_order / 2. When borrowing pages with other migrate_type, we always search from MAX_ORDER-1, which is greater or equal to pageblock_order. -- Thanks. Zhang Yanfei -- 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] libata: remove dead code from libata-acpi.c
On 06/15/2013 11:02 AM, Liu Jiang wrote:
> From: Liu Jiang
>
> Commit 30dcf76acc69 "libata: migrate ACPI code over to new bindings"
> removed ACPI dock notification related code, but there's some dead
> code left, so clean up it.
I never noticed this, but it looks to be the case...
I'm not sure the dock notification code is removed intentionally or
mistakenly though, if it is a mistake, then instead of removing the left
code here, we probably should add the dock notification code back.
But I have no test system or any knowledge about how ata dock works, so
I may be wrong :-)
Thanks,
Aaron
>
> Cc: Tejun Heo
> Cc: Matthew Garrett
> Cc: Aaron Lu
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Liu Jiang
> ---
> drivers/ata/libata-acpi.c | 123
> --
> 1 file changed, 123 deletions(-)
>
> diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
> index 87f2f39..e50c987 100644
> --- a/drivers/ata/libata-acpi.c
> +++ b/drivers/ata/libata-acpi.c
> @@ -91,129 +91,6 @@ acpi_handle ata_dev_acpi_handle(struct ata_device *dev)
> }
> EXPORT_SYMBOL(ata_dev_acpi_handle);
>
> -/* @ap and @dev are the same as ata_acpi_handle_hotplug() */
> -static void ata_acpi_detach_device(struct ata_port *ap, struct ata_device
> *dev)
> -{
> - if (dev)
> - dev->flags |= ATA_DFLAG_DETACH;
> - else {
> - struct ata_link *tlink;
> - struct ata_device *tdev;
> -
> - ata_for_each_link(tlink, ap, EDGE)
> - ata_for_each_dev(tdev, tlink, ALL)
> - tdev->flags |= ATA_DFLAG_DETACH;
> - }
> -
> - ata_port_schedule_eh(ap);
> -}
> -
> -/**
> - * ata_acpi_handle_hotplug - ACPI event handler backend
> - * @ap: ATA port ACPI event occurred
> - * @dev: ATA device ACPI event occurred (can be NULL)
> - * @event: ACPI event which occurred
> - *
> - * All ACPI bay / device realted events end up in this function. If
> - * the event is port-wide @dev is NULL. If the event is specific to a
> - * device, @dev points to it.
> - *
> - * Hotplug (as opposed to unplug) notification is always handled as
> - * port-wide while unplug only kills the target device on device-wide
> - * event.
> - *
> - * LOCKING:
> - * ACPI notify handler context. May sleep.
> - */
> -static void ata_acpi_handle_hotplug(struct ata_port *ap, struct ata_device
> *dev,
> - u32 event)
> -{
> - struct ata_eh_info *ehi = >link.eh_info;
> - int wait = 0;
> - unsigned long flags;
> -
> - spin_lock_irqsave(ap->lock, flags);
> - /*
> - * When dock driver calls into the routine, it will always use
> - * ACPI_NOTIFY_BUS_CHECK/ACPI_NOTIFY_DEVICE_CHECK for add and
> - * ACPI_NOTIFY_EJECT_REQUEST for remove
> - */
> - switch (event) {
> - case ACPI_NOTIFY_BUS_CHECK:
> - case ACPI_NOTIFY_DEVICE_CHECK:
> - ata_ehi_push_desc(ehi, "ACPI event");
> -
> - ata_ehi_hotplugged(ehi);
> - ata_port_freeze(ap);
> - break;
> - case ACPI_NOTIFY_EJECT_REQUEST:
> - ata_ehi_push_desc(ehi, "ACPI event");
> -
> - ata_acpi_detach_device(ap, dev);
> - wait = 1;
> - break;
> - }
> -
> - spin_unlock_irqrestore(ap->lock, flags);
> -
> - if (wait)
> - ata_port_wait_eh(ap);
> -}
> -
> -static void ata_acpi_dev_notify_dock(acpi_handle handle, u32 event, void
> *data)
> -{
> - struct ata_device *dev = data;
> -
> - ata_acpi_handle_hotplug(dev->link->ap, dev, event);
> -}
> -
> -static void ata_acpi_ap_notify_dock(acpi_handle handle, u32 event, void
> *data)
> -{
> - struct ata_port *ap = data;
> -
> - ata_acpi_handle_hotplug(ap, NULL, event);
> -}
> -
> -static void ata_acpi_uevent(struct ata_port *ap, struct ata_device *dev,
> - u32 event)
> -{
> - struct kobject *kobj = NULL;
> - char event_string[20];
> - char *envp[] = { event_string, NULL };
> -
> - if (dev) {
> - if (dev->sdev)
> - kobj = >sdev->sdev_gendev.kobj;
> - } else
> - kobj = >dev->kobj;
> -
> - if (kobj) {
> - snprintf(event_string, 20, "BAY_EVENT=%d", event);
> - kobject_uevent_env(kobj, KOBJ_CHANGE, envp);
> - }
> -}
> -
> -static void ata_acpi_ap_uevent(acpi_handle handle, u32 event, void *data)
> -{
> - ata_acpi_uevent(data, NULL, event);
> -}
> -
> -static void ata_acpi_dev_uevent(acpi_handle handle, u32 event, void *data)
> -{
> - struct ata_device *dev = data;
> - ata_acpi_uevent(dev->link->ap, dev, event);
> -}
> -
> -static const struct acpi_dock_ops ata_acpi_dev_dock_ops = {
> - .handler = ata_acpi_dev_notify_dock,
> - .uevent = ata_acpi_dev_uevent,
> -};
> -
> -static const struct acpi_dock_ops ata_acpi_ap_dock_ops = {
> - .handler = ata_acpi_ap_notify_dock,
> - .uevent =
linux-next: manual merge of the pci tree with Linus' tree
Hi Bjorn,
Today's linux-next merge of the pci tree got a conflict in
include/linux/aer.h between commit 37448adfc7ce ("aerdrv: Move
cper_print_aer() call out of interrupt context") from Linus' tree and
commit fde41b9fa2d0 ("PCI/AER: Remove "extern" from function
declarations") from the pci tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/aer.h
index 737f90a,55bb3dc..000
--- a/include/linux/aer.h
+++ b/include/linux/aer.h
@@@ -49,11 -53,10 +53,10 @@@ static inline int pci_cleanup_aer_uncor
}
#endif
- extern void cper_print_aer(struct pci_dev *dev,
- int cper_severity, struct aer_capability_regs *aer);
- extern int cper_severity_to_aer(int cper_severity);
- extern void aer_recover_queue(int domain, unsigned int bus, unsigned int
devfn,
- int severity,
- struct aer_capability_regs *aer_regs);
-void cper_print_aer(const char *prefix, struct pci_dev *dev, int
cper_severity,
++void cper_print_aer(struct pci_dev *dev, int cper_severity,
+ struct aer_capability_regs *aer);
+ int cper_severity_to_aer(int cper_severity);
+ void aer_recover_queue(int domain, unsigned int bus, unsigned int devfn,
- int severity);
++ int severity, struct aer_capability_regs *aer_regs);
#endif //_AER_H_
pgp3R_0Fcfphi.pgp
Description: PGP signature
Re: + mm-remove-duplicated-call-of-get_pfn_range_for_nid.patch added to -mm tree
On 06/11/2013 06:28 AM, a...@linux-foundation.org wrote:
> Subject: + mm-remove-duplicated-call-of-get_pfn_range_for_nid.patch added to
> -mm tree
> To: zhangyan...@cn.fujitsu.com
> From: a...@linux-foundation.org
> Date: Mon, 10 Jun 2013 15:28:23 -0700
>
>
> The patch titled
> Subject: mm: Remove duplicated call of get_pfn_range_for_nid
> has been added to the -mm tree. Its filename is
> mm-remove-duplicated-call-of-get_pfn_range_for_nid.patch
Hello Andrew,
Could you please update this patch to the below one. It fixes the uninitialized
warnings in Arches with no CONFIG_HAVE_MEMBLOCK_NODE_MAP.
--
From: Zhang Yanfei
Date: Mon, 17 Jun 2013 09:07:49 +0800
Subject: [PATCH] mm: Remove duplicated call of get_pfn_range_for_nid
When calculating pages in a node,
for each zone in that node, we will have
zone_spanned_pages_in_node
--> get_pfn_range_for_nid
zone_absent_pages_in_node
--> get_pfn_range_for_nid
That is to say, we call the get_pfn_range_for_nid to get start_pfn
and end_pfn of the node for MAX_NR_ZONES * 2 times. And this is
totally unnecessary if we call the get_pfn_range_for_nid before
zone_*_pages_in_node add two extra arguments node_start_pfn
and node_end_pfn for zone_*_pages_in_node, then we can remove the
get_pfn_range_in_node in zone_*_pages_in_node.
Signed-off-by: Zhang Yanfei
Cc: kbuild test robot
Cc: Michal Hocko
---
mm/page_alloc.c | 42 +++---
1 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 18102e1..1a8cac5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4418,13 +4418,13 @@ static void __meminit
adjust_zone_range_for_zone_movable(int nid,
*/
static unsigned long __meminit zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
unsigned long *ignored)
{
- unsigned long node_start_pfn, node_end_pfn;
unsigned long zone_start_pfn, zone_end_pfn;
- /* Get the start and end of the node and zone */
- get_pfn_range_for_nid(nid, _start_pfn, _end_pfn);
+ /* Get the start and end of the zone */
zone_start_pfn = arch_zone_lowest_possible_pfn[zone_type];
zone_end_pfn = arch_zone_highest_possible_pfn[zone_type];
adjust_zone_range_for_zone_movable(nid, zone_type,
@@ -4479,14 +4479,14 @@ unsigned long __init absent_pages_in_range(unsigned
long start_pfn,
/* Return the number of page frames in holes in a zone on a node */
static unsigned long __meminit zone_absent_pages_in_node(int nid,
unsigned long zone_type,
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
unsigned long *ignored)
{
unsigned long zone_low = arch_zone_lowest_possible_pfn[zone_type];
unsigned long zone_high = arch_zone_highest_possible_pfn[zone_type];
- unsigned long node_start_pfn, node_end_pfn;
unsigned long zone_start_pfn, zone_end_pfn;
- get_pfn_range_for_nid(nid, _start_pfn, _end_pfn);
zone_start_pfn = clamp(node_start_pfn, zone_low, zone_high);
zone_end_pfn = clamp(node_end_pfn, zone_low, zone_high);
@@ -4499,6 +4499,8 @@ static unsigned long __meminit
zone_absent_pages_in_node(int nid,
#else /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
static inline unsigned long __meminit zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
unsigned long *zones_size)
{
return zones_size[zone_type];
@@ -4506,6 +4508,8 @@ static inline unsigned long __meminit
zone_spanned_pages_in_node(int nid,
static inline unsigned long __meminit zone_absent_pages_in_node(int nid,
unsigned long zone_type,
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
unsigned long *zholes_size)
{
if (!zholes_size)
@@ -4517,21 +4521,27 @@ static inline unsigned long __meminit
zone_absent_pages_in_node(int nid,
#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
static void __meminit calculate_node_totalpages(struct pglist_data *pgdat,
- unsigned long *zones_size, unsigned long *zholes_size)
+ unsigned long node_start_pfn,
+ unsigned long node_end_pfn,
+
Re: [PATCH] arch: blackfin: kernel: sprintf(), need avoid NUL for '%s'
On 06/16/2013 11:02 AM, Mike Frysinger wrote: > i think you mean NULL instead of NUL > > that said, the kernel is smart enough to replace NULL with "(null)", > so i don't see much point in this patch Oh, really it is, it is my fault (originally, I did not know about it). Thanks. -- Chen Gang Asianux Corporation -- 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 0/4] change 64 bit variables to long type
On 06/14/2013 10:20 PM, Alex Shi wrote: > On 06/07/2013 03:29 PM, Alex Shi wrote: >> There are some 64 bits variables in cfs_rq/tg etc. That ask expensive >> operations in 32 bit machine. But in fact, long type is enough for them. >> >> So do this change lead more efficient code and without data lose. >> > > some variable like cfs_rq->runnable_load_avg, there is no much changes > in patch 1/4, since in most of place it was treated as a 'unsigned > long', not u64. > The patchset change some u64 load avg variables to 'unsigned long' type, because the related load variable is 'unsigned long' too. Peter, It looks quite straight. So if Paul is too busy to look into this, Believe you can do decide independent. :) >> Regards >> Alex >> > > -- Thanks Alex -- 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/
[RFC] arm: Remove sa1111 special case from arm_mm_memblock_reserve()
The machine desc structure has a hook for doing machine-specific
memblock code, but the SA still has a platform-specific hook in the
generic code. This patch merely moves the needed memblock_reserve()
into a callback.
This still leaves a special case in mem_init() to call
free_reserved_area() on the same region, but there isn't a suitable hook
in mdesc for making that call so the change is left to another patch.
Compile tested only.
Signed-off-by: Grant Likely
Cc: Russell King
Cc: Nicolas Pitre
Cc: Catalin Marinas
Cc: Arnd Bergmann
---
arch/arm/mach-sa1100/assabet.c| 1 +
arch/arm/mach-sa1100/badge4.c | 1 +
arch/arm/mach-sa1100/generic.c| 12
arch/arm/mach-sa1100/generic.h| 1 +
arch/arm/mach-sa1100/jornada720.c | 1 +
arch/arm/mm/mmu.c | 8
6 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-sa1100/assabet.c b/arch/arm/mach-sa1100/assabet.c
index e838ba2..aab247a 100644
--- a/arch/arm/mach-sa1100/assabet.c
+++ b/arch/arm/mach-sa1100/assabet.c
@@ -621,6 +621,7 @@ MACHINE_START(ASSABET, "Intel-Assabet")
.fixup = fixup_assabet,
.map_io = assabet_map_io,
.nr_irqs= SA1100_NR_IRQS,
+ .reserve= sa1100_reserve,
.init_irq = sa1100_init_irq,
.init_time = sa1100_timer_init,
.init_machine = assabet_init,
diff --git a/arch/arm/mach-sa1100/badge4.c b/arch/arm/mach-sa1100/badge4.c
index 63361b6..9033d74 100644
--- a/arch/arm/mach-sa1100/badge4.c
+++ b/arch/arm/mach-sa1100/badge4.c
@@ -334,6 +334,7 @@ MACHINE_START(BADGE4, "Hewlett-Packard Laboratories
BadgePAD 4")
.atag_offset= 0x100,
.map_io = badge4_map_io,
.nr_irqs= SA1100_NR_IRQS,
+ .reserve= sa1100_reserve,
.init_irq = sa1100_init_irq,
.init_late = sa11x0_init_late,
.init_time = sa1100_timer_init,
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 9db3e98..1e7164e 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -26,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -351,6 +353,16 @@ static struct platform_device *sa11x0_devices[] __initdata
= {
_device,
};
+void __init sa1100_reserve(void)
+{
+ /*
+* Because of the SA DMA bug, we want to preserve our
+* precious DMA-able memory...
+*/
+ if (IS_ENABLED(CONFIG_SA))
+ memblock_reserve(PHYS_OFFSET, __pa(swapper_pg_dir) -
PHYS_OFFSET);
+}
+
static int __init sa1100_init(void)
{
pm_power_off = sa1100_power_off;
diff --git a/arch/arm/mach-sa1100/generic.h b/arch/arm/mach-sa1100/generic.h
index 2abc6a1..5d8398c 100644
--- a/arch/arm/mach-sa1100/generic.h
+++ b/arch/arm/mach-sa1100/generic.h
@@ -5,6 +5,7 @@
*/
extern void sa1100_timer_init(void);
+extern void sa1100_reserve(void);
extern void __init sa1100_map_io(void);
extern void __init sa1100_init_irq(void);
extern void __init sa1100_init_gpio(void);
diff --git a/arch/arm/mach-sa1100/jornada720.c
b/arch/arm/mach-sa1100/jornada720.c
index c0b1f5b..d95961a 100644
--- a/arch/arm/mach-sa1100/jornada720.c
+++ b/arch/arm/mach-sa1100/jornada720.c
@@ -345,6 +345,7 @@ MACHINE_START(JORNADA720, "HP Jornada 720")
.atag_offset= 0x100,
.map_io = jornada720_map_io,
.nr_irqs= SA1100_NR_IRQS,
+ .reserve= sa1100_reserve,
.init_irq = sa1100_init_irq,
.init_time = sa1100_timer_init,
.init_machine = jornada720_mach_init,
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e0d8565..f281a24 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1147,14 +1147,6 @@ void __init arm_mm_memblock_reserve(void)
* and can only be in node 0.
*/
memblock_reserve(__pa(swapper_pg_dir), SWAPPER_PG_DIR_SIZE);
-
-#ifdef CONFIG_SA
- /*
-* Because of the SA DMA bug, we want to preserve our
-* precious DMA-able memory...
-*/
- memblock_reserve(PHYS_OFFSET, __pa(swapper_pg_dir) - PHYS_OFFSET);
-#endif
}
/*
--
1.8.1.2
--
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.9-stable] arm: omap2: fix AM33xx hwmod infos for UART2
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Thomas Petazzoni "
commit 768dc16397fb18c9de209cbcb84d890b8279faa7 upstream
The UART2 hwmod structure is pointing to the EDMA channels of UART1,
which doesn't look right. This patch fixes this by making the UART2
hwmod structure to a new structure that lists the EDMA channels to be
used by the UART2.
Signed-off-by: Thomas Petazzoni
Acked-by: Vaibhav Hiremath
[p...@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley
Signed-off-by: Jonghwan Choi
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 26eee4a..6a57150 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1979,6 +1979,13 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
},
};
+/* uart2 */
+static struct omap_hwmod_dma_info uart2_edma_reqs[] = {
+ { .name = "tx", .dma_req = 28, },
+ { .name = "rx", .dma_req = 29, },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
{ .irq = 73 + OMAP_INTC_START, },
{ .irq = -1 },
@@ -1989,7 +1996,7 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
.class = _class,
.clkdm_name = "l4ls_clkdm",
.mpu_irqs = am33xx_uart2_irqs,
- .sdma_reqs = uart1_edma_reqs,
+ .sdma_reqs = uart2_edma_reqs,
.main_clk = "dpll_per_m2_div4_ck",
.prcm = {
.omap4 = {
--
1.7.9.5
--
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] arm: Remove sa1111 special case from mm setup code
On Sun, Jun 16, 2013 at 10:10 AM, Russell King - ARM Linux wrote: > On Sun, Jun 16, 2013 at 12:15:08AM +0100, Grant Likely wrote: >> I don't think this special case is needed anymore. From what I can tell, >> setup_dma_zone() takes care of marking the region to be reserved for >> DMA, and that happens before arm_memblock_init() which calls >> arm_mm_memblock_reserve(). Therefore the mm setup should already know >> about the reserved region and it won't need to be explicitly reserved >> and then freed. That means the special case can be dropped from the >> common code. > > No it doesn't. setup_dma_zone is all about setting the high watermark > for GFP_DMA allocations. It has nothing to do with _temoprarily_ > reserving the low 1MB, ensuring that no other user can use any of that > precious SA memory during the kernel boot. Ah, okay. So it's to protect against early allocations. All right, I've got an alternate patch that at least gets rid of one of the special case hooks. I'll post that one shortly. 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/
linux-next: manual merge of the arm64 tree with Linus' tree
Hi Catalin,
Today's linux-next merge of the arm64 tree got a conflict in
include/uapi/linux/kvm.h between commit 2a8fedd0c142 ("kvm: Add
definition of KVM_REG_MIPS") from Linus' tree and commit 7c8c5e6a9101
("arm64: KVM: system register handling") from the arm64 tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/uapi/linux/kvm.h
index d88c8ee,aac2764..000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -783,7 -784,7 +784,8 @@@ struct kvm_dirty_tlb
#define KVM_REG_IA64 0x3000ULL
#define KVM_REG_ARM 0x4000ULL
#define KVM_REG_S390 0x5000ULL
+ #define KVM_REG_ARM64 0x6000ULL
+#define KVM_REG_MIPS 0x7000ULL
#define KVM_REG_SIZE_SHIFT52
#define KVM_REG_SIZE_MASK 0x00f0ULL
pgpvkQPgL9J1F.pgp
Description: PGP signature
Re: [patch v8 3/9] sched: set initial value of runnable avg for new forked task
On 06/15/2013 08:09 PM, Lei Wen wrote: > >>> > and make forking balancing imbalance since incorrect > >>> > load_avg_contrib. > >>> > > >>> > Further more, Morten Rasmussen notice some tasks were not launched > >>> > at > >>> > once after created. So Paul and Peter suggest giving a start value > >>> > for > >>> > new task runnable avg time same as sched_slice(). >>> >> I am confused at this comment, how set slice to runnable avg would change >>> >> the behavior of "some tasks were not launched at once after created"? >> > >> > I also don't know the details on Morten's machine. but just guess, there >> > are much tasks on in the run queue. the minimum load avg make the new >> > task wait its time... > Is there some possibility that since task structure is allocated without being > set to 0, and it cause the imbalance between runqueues. Then the new forked > is migrated to other cpus, so that it cause its execution being delayed? Is there sth weird happens? The task should be running a while before migration. and periodic load balance also need some time to happen. So generally, it has no such worries. -- Thanks Alex -- 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/
paper supplier
Dear Purchasing manager: Nice time to you It is my big pleasure to hear you need A4 paper we have A4 paper and A3 paper If you still need that pls tell me Then i can send you our best price Best wishes Zara Zara Wang SALES MANAGER HANGZHOU XINHAO INDUSTRY CO., LIMITED SKYPE: hzxinhao Email:h...@xhindustry.com
[PATCH/RFC] arm: arch_timer: Do not set C3STOP in case CPU_IDLE=n
From: Magnus Damm
Modify the ARM architected timer driver to not set C3STOP
in case CPU_IDLE is disabled. This is a short term fix that
allows use of high resolution timers even though no additional
clock event is registered.
Not-really-Signed-off-by: Magnus Damm
---
If someone cares about this case then perhaps it should be
moved up to the clock event main code. The same issue should
in theory trigger on all architectures, perhaps x86 people
hunting for low latency may try to disable CPU_IDLE?
I propose carrying this patch locally to enable high resolution
timers until CPU_IDLE and an additional clock event is supported.
Observed on r8a73a4 and APE6EVM.
drivers/clocksource/arm_arch_timer.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
--- 0001/drivers/clocksource/arm_arch_timer.c
+++ work/drivers/clocksource/arm_arch_timer.c 2013-06-17 09:03:44.0
+0900
@@ -125,7 +125,23 @@ static int arch_timer_set_next_event_phy
static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
{
- clk->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP;
+ clk->features = CLOCK_EVT_FEAT_ONESHOT;
+#ifdef CONFIG_CPU_IDLE
+ /* By not setting the C3STOP flag it is possible to let the
+* ARM architected timer to be the only clock event installed
+* on the system and have working high resolution timers.
+*
+* If the C3STOP flag is set unconditionally then the kernel
+* will always prevent using the high resoultion timer feature
+* unless an additional clock event is registered.
+*
+* In the case where CPU_IDLE is enabled then there is a chance
+* that deeper sleep states will be handled by software, but
+* if CPU_IDLE is disabled then deep sleep states cannot be
+* entered and the feature flagged by C3STOP is not needed.
+*/
+ clk->features |= CLOCK_EVT_FEAT_C3STOP;
+#endif
clk->name = "arch_sys_timer";
clk->rating = 450;
if (arch_timer_use_virtual) {
--
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/3] Staging: silicom: move symbol exports beneath definitions in bypass.c
Move the EXPORT_SYMBOL macros in bypass.c beneath the definitions
they refer to, resolving checkpatch.pl warnings. While we're at it, use
EXPORT_SYMBOL rather than EXPORT_SYMBOL_NOVERS.
Signed-off-by: Chad Williamson
---
drivers/staging/silicom/bypasslib/bypass.c | 89 +++---
1 file changed, 44 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/silicom/bypasslib/bypass.c
b/drivers/staging/silicom/bypasslib/bypass.c
index 9ed2508..ba0d23a 100644
--- a/drivers/staging/silicom/bypasslib/bypass.c
+++ b/drivers/staging/silicom/bypasslib/bypass.c
@@ -188,69 +188,82 @@ static int is_bypass(int if_index)
return is_bypass_dev(if_index);
return ret;
}
+EXPORT_SYMBOL(is_bypass);
static int get_bypass_slave(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_bypass_slave, GET_BYPASS_SLAVE, if_index);
}
+EXPORT_SYMBOL(get_bypass_slave);
static int get_bypass_caps(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_bypass_caps, GET_BYPASS_CAPS, if_index);
}
+EXPORT_SYMBOL(get_bypass_caps);
static int get_wd_set_caps(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_wd_set_caps, GET_WD_SET_CAPS, if_index);
}
+EXPORT_SYMBOL(get_wd_set_caps);
static int set_bypass(int if_index, int bypass_mode)
{
DO_BPLIB_SET_ARG_FN(set_bypass, SET_BYPASS, if_index, bypass_mode);
}
+EXPORT_SYMBOL(set_bypass);
static int get_bypass(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_bypass, GET_BYPASS, if_index);
}
+EXPORT_SYMBOL(get_bypass);
static int get_bypass_change(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_bypass_change, GET_BYPASS_CHANGE, if_index);
}
+EXPORT_SYMBOL(get_bypass_change);
static int set_dis_bypass(int if_index, int dis_bypass)
{
DO_BPLIB_SET_ARG_FN(set_dis_bypass, SET_DIS_BYPASS, if_index,
dis_bypass);
}
+EXPORT_SYMBOL(set_dis_bypass);
static int get_dis_bypass(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_dis_bypass, GET_DIS_BYPASS, if_index);
}
+EXPORT_SYMBOL(get_dis_bypass);
static int set_bypass_pwoff(int if_index, int bypass_mode)
{
DO_BPLIB_SET_ARG_FN(set_bypass_pwoff, SET_BYPASS_PWOFF, if_index,
bypass_mode);
}
+EXPORT_SYMBOL(set_bypass_pwoff);
static int get_bypass_pwoff(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_bypass_pwoff, GET_BYPASS_PWOFF, if_index);
}
+EXPORT_SYMBOL(get_bypass_pwoff);
static int set_bypass_pwup(int if_index, int bypass_mode)
{
DO_BPLIB_SET_ARG_FN(set_bypass_pwup, SET_BYPASS_PWUP, if_index,
bypass_mode);
}
+EXPORT_SYMBOL(set_bypass_pwup);
static int get_bypass_pwup(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_bypass_pwup, GET_BYPASS_PWUP, if_index);
}
+EXPORT_SYMBOL(get_bypass_pwup);
static int set_bypass_wd(int if_index, int ms_timeout, int *ms_timeout_set)
{
@@ -267,6 +280,7 @@ static int set_bypass_wd(int if_index, int ms_timeout, int
*ms_timeout_set)
}
return ret;
}
+EXPORT_SYMBOL(set_bypass_wd);
static int get_bypass_wd(int if_index, int *ms_timeout_set)
{
@@ -278,6 +292,7 @@ static int get_bypass_wd(int if_index, int *ms_timeout_set)
ret = doit(GET_BYPASS_WD, if_index, data);
return ret;
}
+EXPORT_SYMBOL(get_bypass_wd);
static int get_wd_expire_time(int if_index, int *ms_time_left)
{
@@ -292,143 +307,171 @@ static int get_wd_expire_time(int if_index, int
*ms_time_left)
}
return ret;
}
+EXPORT_SYMBOL(get_wd_expire_time);
static int reset_bypass_wd_timer(int if_index)
{
DO_BPLIB_GET_ARG_FN(reset_bypass_wd_timer, RESET_BYPASS_WD_TIMER,
if_index);
}
+EXPORT_SYMBOL(reset_bypass_wd_timer);
static int set_std_nic(int if_index, int bypass_mode)
{
DO_BPLIB_SET_ARG_FN(set_std_nic, SET_STD_NIC, if_index, bypass_mode);
}
+EXPORT_SYMBOL(set_std_nic);
static int get_std_nic(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_std_nic, GET_STD_NIC, if_index);
}
+EXPORT_SYMBOL(get_std_nic);
static int set_tx(int if_index, int tx_state)
{
DO_BPLIB_SET_ARG_FN(set_tx, SET_TX, if_index, tx_state);
}
+EXPORT_SYMBOL(set_tx);
static int get_tx(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_tx, GET_TX, if_index);
}
+EXPORT_SYMBOL(get_tx);
static int set_tap(int if_index, int tap_mode)
{
DO_BPLIB_SET_ARG_FN(set_tap, SET_TAP, if_index, tap_mode);
}
+EXPORT_SYMBOL(set_tap);
static int get_tap(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_tap, GET_TAP, if_index);
}
+EXPORT_SYMBOL(get_tap);
static int get_tap_change(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_tap_change, GET_TAP_CHANGE, if_index);
}
+EXPORT_SYMBOL(get_tap_change);
static int set_dis_tap(int if_index, int dis_tap)
{
DO_BPLIB_SET_ARG_FN(set_dis_tap, SET_DIS_TAP, if_index, dis_tap);
}
+EXPORT_SYMBOL(set_dis_tap);
static int get_dis_tap(int if_index)
{
DO_BPLIB_GET_ARG_FN(get_dis_tap, GET_DIS_TAP, if_index);
}
[PATCH 0/3] Staging: silicom: EXPORT_SYMBOL cleanup
This patchset cleans up the EXPORT_SYMBOL calls in staging/silicom by placing the exports immediately below the definitions they refer to (as is the convention) and removing the no-longer-useful EXPORT_SYMBOL_NOVERS macro. Chad Williamson (3): Staging: silicom: move symbol exports beneath definitions in bpctl_mod.c Staging: silicom: move symbol exports beneath definitions in bypass.c Staging: silicom: remove the EXPORT_SYMBOL_NOVERS macro drivers/staging/silicom/bp_mod.h | 2 - drivers/staging/silicom/bpctl_mod.c| 91 +++--- drivers/staging/silicom/bypasslib/bplibk.h | 2 - drivers/staging/silicom/bypasslib/bypass.c | 89 +++-- 4 files changed, 89 insertions(+), 95 deletions(-) -- 1.8.1.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/
[PATCH 1/3] Staging: silicom: move symbol exports beneath definitions in bpctl_mod.c
Move the EXPORT_SYMBOL macros in bpctl_mod.c beneath the definitions
they refer to, resolving checkpatch.pl warnings. While we're at it, use
EXPORT_SYMBOL rather than EXPORT_SYMBOL_NOVERS.
Signed-off-by: Chad Williamson
---
drivers/staging/silicom/bpctl_mod.c | 91 ++---
1 file changed, 45 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/silicom/bpctl_mod.c
b/drivers/staging/silicom/bpctl_mod.c
index a3b974b..4c8fb86 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -6878,59 +6878,69 @@ int is_bypass_sd(int ifindex)
{
return is_bypass(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(is_bypass_sd);
int set_bypass_sd(int ifindex, int bypass_mode)
{
return set_bypass_fn(get_dev_idx_p(ifindex), bypass_mode);
}
+EXPORT_SYMBOL(set_bypass_sd);
int get_bypass_sd(int ifindex)
{
return get_bypass_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_bypass_sd);
int get_bypass_change_sd(int ifindex)
{
return get_bypass_change_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_bypass_change_sd);
int set_dis_bypass_sd(int ifindex, int dis_param)
{
return set_dis_bypass_fn(get_dev_idx_p(ifindex), dis_param);
}
+EXPORT_SYMBOL(set_dis_bypass_sd);
int get_dis_bypass_sd(int ifindex)
{
return get_dis_bypass_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_dis_bypass_sd);
int set_bypass_pwoff_sd(int ifindex, int bypass_mode)
{
return set_bypass_pwoff_fn(get_dev_idx_p(ifindex), bypass_mode);
}
+EXPORT_SYMBOL(set_bypass_pwoff_sd);
int get_bypass_pwoff_sd(int ifindex)
{
return get_bypass_pwoff_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_bypass_pwoff_sd);
int set_bypass_pwup_sd(int ifindex, int bypass_mode)
{
return set_bypass_pwup_fn(get_dev_idx_p(ifindex), bypass_mode);
}
+EXPORT_SYMBOL(set_bypass_pwup_sd);
int get_bypass_pwup_sd(int ifindex)
{
return get_bypass_pwup_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_bypass_pwup_sd);
int set_bypass_wd_sd(int if_index, int ms_timeout, int *ms_timeout_set)
{
@@ -6939,136 +6949,159 @@ int set_bypass_wd_sd(int if_index, int ms_timeout,
int *ms_timeout_set)
*ms_timeout_set = set_bypass_wd_fn(get_dev_idx_p(if_index), ms_timeout);
return 0;
}
+EXPORT_SYMBOL(set_bypass_wd_sd);
int get_bypass_wd_sd(int ifindex, int *timeout)
{
return get_bypass_wd_fn(get_dev_idx_p(ifindex), timeout);
}
+EXPORT_SYMBOL(get_bypass_wd_sd);
int get_wd_expire_time_sd(int ifindex, int *time_left)
{
return get_wd_expire_time_fn(get_dev_idx_p(ifindex), time_left);
}
+EXPORT_SYMBOL(get_wd_expire_time_sd);
int reset_bypass_wd_timer_sd(int ifindex)
{
return reset_bypass_wd_timer_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(reset_bypass_wd_timer_sd);
int get_wd_set_caps_sd(int ifindex)
{
return get_wd_set_caps_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_wd_set_caps_sd);
int set_std_nic_sd(int ifindex, int nic_mode)
{
return set_std_nic_fn(get_dev_idx_p(ifindex), nic_mode);
}
+EXPORT_SYMBOL(set_std_nic_sd);
int get_std_nic_sd(int ifindex)
{
return get_std_nic_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_std_nic_sd);
int set_tap_sd(int ifindex, int tap_mode)
{
return set_tap_fn(get_dev_idx_p(ifindex), tap_mode);
}
+EXPORT_SYMBOL(set_tap_sd);
int get_tap_sd(int ifindex)
{
return get_tap_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_tap_sd);
int set_tap_pwup_sd(int ifindex, int tap_mode)
{
return set_tap_pwup_fn(get_dev_idx_p(ifindex), tap_mode);
}
+EXPORT_SYMBOL(set_tap_pwup_sd);
int get_tap_pwup_sd(int ifindex)
{
return get_tap_pwup_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_tap_pwup_sd);
int get_tap_change_sd(int ifindex)
{
return get_tap_change_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_tap_change_sd);
int set_dis_tap_sd(int ifindex, int dis_param)
{
return set_dis_tap_fn(get_dev_idx_p(ifindex), dis_param);
}
+EXPORT_SYMBOL(set_dis_tap_sd);
int get_dis_tap_sd(int ifindex)
{
return get_dis_tap_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_dis_tap_sd);
int set_bp_disc_sd(int ifindex, int disc_mode)
{
return set_disc_fn(get_dev_idx_p(ifindex), disc_mode);
}
+EXPORT_SYMBOL(set_bp_disc_sd);
int get_bp_disc_sd(int ifindex)
{
return get_disc_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_bp_disc_sd);
int set_bp_disc_pwup_sd(int ifindex, int disc_mode)
{
return set_disc_pwup_fn(get_dev_idx_p(ifindex), disc_mode);
}
+EXPORT_SYMBOL(set_bp_disc_pwup_sd);
int get_bp_disc_pwup_sd(int ifindex)
{
return get_disc_pwup_fn(get_dev_idx_p(ifindex));
}
+EXPORT_SYMBOL(get_bp_disc_pwup_sd);
int get_bp_disc_change_sd(int ifindex)
{
return get_disc_change_fn(get_dev_idx_p(ifindex));
}
[PATCH 3/3] Staging: silicom: remove the EXPORT_SYMBOL_NOVERS macro
Since all references to EXPORT_SYMBOL_NOVERS have been removed,
we can remove its definition from bp_mod.h and bypasslib/bplibk.h.
Signed-off-by: Chad Williamson
---
drivers/staging/silicom/bp_mod.h | 2 --
drivers/staging/silicom/bypasslib/bplibk.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/staging/silicom/bp_mod.h b/drivers/staging/silicom/bp_mod.h
index b8275f5..cfa1f43 100644
--- a/drivers/staging/silicom/bp_mod.h
+++ b/drivers/staging/silicom/bp_mod.h
@@ -15,8 +15,6 @@
#define BP_MOD_H
#include "bits.h"
-#define EXPORT_SYMBOL_NOVERS EXPORT_SYMBOL
-
#define usec_delay(x) udelay(x)
#ifndef msec_delay_bp
#define msec_delay_bp(x) \
diff --git a/drivers/staging/silicom/bypasslib/bplibk.h
b/drivers/staging/silicom/bypasslib/bplibk.h
index b31694f..c5c75c4 100644
--- a/drivers/staging/silicom/bypasslib/bplibk.h
+++ b/drivers/staging/silicom/bypasslib/bplibk.h
@@ -28,8 +28,6 @@
((pid == INTEL_PEG4BPII_PID) || \
(pid == INTEL_PEG4BPFII_PID)))
-#define EXPORT_SYMBOL_NOVERS EXPORT_SYMBOL
-
#ifdef BP_VENDOR_SUPPORT
char *bp_desc_array[] = { "e1000bp", "e1000bpe", "slcm5700",
"bnx2xbp", "ixgbp", "ixgbpe", NULL };
--
1.8.1.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: A question on RCU vs. preempt-RCU
Tejun Heo writes: > I've been running some performance tests with different preemption > levels and, with CONFIG_PREEMPT, the percpu ref could be slower by > around 10% or at the worst contrived case maybe even close to 20% when > compared to simple atomic_t on a single CPU (when hit by multiple CPUs > concurrently, it of course destroys atomic_t). Most of the slow down > seems to come from the preempt tree RCU calls and there no longer > seems to be a way to opt out of that RCU implementation when > CONFIG_PREEMPT. > > For most use cases, the trade-off should be fine. With any kind of > cross-cpu traffic, which there usually will be, it should be an easy > win for the percpu-refcount even when CONFIG_PREEMPT; however, I've > been looking to replace the module ref with the generic one and the > performance degradation there has low but existing possibility of > being noticeable in some edge use cases. I'm confused: is it actually 10% slower than the existing module refcount code, or 10% slower than atomic inc? > We can convert the percpu-refcount to use preempt_disable/enable() > paired with call_rcu_sched() but IIUC that would have latency > implications from the callback processing side, right? Given that > module ref killing would be very low-frequency, it shouldn't > contribute significant amount of callbacks but I'd like to avoid > providing two separate implementations if at all possible. > > So, what would be the right thing to do here? How bad would > converting percpu-refcount to sched-RCU by default be? Would the > extra overhead on module ref be acceptable when CONFIG_PREEMPT? > What do you guys think? CONFIG_PREEMPT, now with more preempt! Sure, that has a cost, but you're arguably fixing a bug. If we want to improve CONFIG_PREEMPT performance, we can probably use a trick I wanted to try long ago: 1) Use a per-cpu counter rather than a per-task counter for preempt. 2) Lay out preempt_counter so it covers NR_CPU pages, one per page. 3) When you want to preempt a CPU and counter isn't zero, make the page RO. 4) Handle preemption enable in the fault handler. Then there's no branch in preempt_enable(). At a glance, the same trick could apply to t->rcu_read_unlock_special, but I'd have to offload that to my RCU coprocessor. Paul? :) Cheers, Rusty. -- 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: vmscan: remove redundant querying to shrinker
On Fri, Jun 14, 2013 at 07:07:51PM +0900, Heesub Shin wrote:
> shrink_slab() queries each slab cache to get the number of
> elements in it. In most cases such queries are cheap but,
> on some caches. For example, Android low-memory-killer,
> which is operates as a slab shrinker, does relatively
> long calculation once invoked and it is quite expensive.
As has already been pointed out, the low memory killer is a badly
broken piece of code. I can't run a normal machine with it enabled
because it randomly kills processes whenever memory pressure is
generated. What it does is simply broken and hence arguing that it
has too much overhead is not a convincing argument for changing core
shrinker infrastructure.
> This patch removes redundant queries to shrinker function
> in the loop of shrink batch.
>
> Signed-off-by: Heesub Shin
> ---
> mm/vmscan.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fa6a853..11b6695 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -282,9 +282,8 @@ unsigned long shrink_slab(struct shrink_control *shrink,
> max_pass, delta, total_scan);
>
> while (total_scan >= batch_size) {
> - int nr_before;
> + int nr_before = max_pass;
>
> - nr_before = do_shrinker_shrink(shrinker, shrink, 0);
> shrink_ret = do_shrinker_shrink(shrinker, shrink,
> batch_size);
> if (shrink_ret == -1)
> @@ -293,6 +292,7 @@ unsigned long shrink_slab(struct shrink_control *shrink,
> ret += nr_before - shrink_ret;
> count_vm_events(SLABS_SCANNED, batch_size);
> total_scan -= batch_size;
> + max_pass = shrink_ret;
>
> cond_resched();
> }
Shrinkers run concurrently on different CPUs, and so the state of
the cache being shrunk can change significantly when cond_resched()
actually yields the CPU. Hence we need to recalculate the current
state of the cache before we shrink again to get an accurate idea of
how much work the current loop has done. If we get this badly wrong,
the caller of shrink_slab() will get an incorrect idea of how much
work was actually done by the shrinkers
This problem is fixed in mmtom by the change of shrinker API that
results shrinker->scan_objects() returning the number of objects
freed directly, and hence it isn't necessary to have a
shrinker->count_objects() call in the scan loop anymore. i.e. the
reworked scan loop ends up like:
while (total_scan >= batch_size) {
unsigned long ret;
shrinkctl->nr_to_scan = batch_size;
ret = shrinker->scan_objects(shrinker, shrinkctl);
if (ret == SHRINK_STOP)
break;
freed += ret;
count_vm_events(SLABS_SCANNED, batch_size);
total_scan -= batch_size;
}
So we've already solved the problem you are concerned about
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.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 3.9-stable] ARM: omap3: clock: fix wrong container_of in clock36xx.c
This patch looks like it should be in the 3.9-stable tree, should we apply
it?
--
From: "Jean-Philippe Francois "
commit a93d8a1cea0899982993e9a93404c6f78b123697 upstream
omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of
the clock to be a clk_hw_omap. However, looking at cclock3xxx_data.c,
all concerned clock have parent defined as clk_divider. Fix the
function to use clk_divider. Tested with 3.9 on dm3730.
Signed-off-by: Jean-Philippe Francois
Cc: NeilBrown
Cc: Mike Turquette
Signed-off-by: Paul Walmsley
Signed-off-by: Jonghwan Choi
---
arch/arm/mach-omap2/clock36xx.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/clock36xx.c
b/arch/arm/mach-omap2/clock36xx.c
index 8f3bf4e..bbd6a3f 100644
--- a/arch/arm/mach-omap2/clock36xx.c
+++ b/arch/arm/mach-omap2/clock36xx.c
@@ -20,11 +20,12 @@
#include
#include
+#include
#include
#include "clock.h"
#include "clock36xx.h"
-
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
/**
* omap36xx_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
@@ -39,29 +40,28 @@
*/
int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
{
- struct clk_hw_omap *parent;
+ struct clk_divider *parent;
struct clk_hw *parent_hw;
- u32 dummy_v, orig_v, clksel_shift;
+ u32 dummy_v, orig_v;
int ret;
/* Clear PWRDN bit of HSDIVIDER */
ret = omap2_dflt_clk_enable(clk);
parent_hw = __clk_get_hw(__clk_get_parent(clk->clk));
- parent = to_clk_hw_omap(parent_hw);
+ parent = to_clk_divider(parent_hw);
/* Restore the dividers */
if (!ret) {
- clksel_shift = __ffs(parent->clksel_mask);
- orig_v = __raw_readl(parent->clksel_reg);
+ orig_v = __raw_readl(parent->reg);
dummy_v = orig_v;
/* Write any other value different from the Read value */
- dummy_v ^= (1 << clksel_shift);
- __raw_writel(dummy_v, parent->clksel_reg);
+ dummy_v ^= (1 << parent->shift);
+ __raw_writel(dummy_v, parent->reg);
/* Write the original divider */
- __raw_writel(orig_v, parent->clksel_reg);
+ __raw_writel(orig_v, parent->reg);
}
return ret;
--
1.7.9.5
--
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 percpu/for-3.11] percpu-refcount: use RCU-sched insted of normal RCU
On Sun, Jun 16, 2013 at 02:55:46PM -0700, Tejun Heo wrote:
> percpu-refcount was incorrectly using preempt_disable/enable() for RCU
> critical sections against call_rcu(). 6a24474da8 ("percpu-refcount:
> consistently use plain (non-sched) RCU") fixed it by converting the
> preepmtion operations with rcu_read_[un]lock() citing that there isn't
> any advantage in using sched-RCU over using the usual one; however,
> rcu_read_[un]lock() for the preemptible RCU implementation -
> CONFIG_TREE_PREEMPT_RCU, chosen when CONFIG_PREEMPT - are slightly
> more expensive than preempt_disable/enable().
>
> In a contrived microbench which repeats the followings,
>
> - percpu_ref_get()
> - copy 32 bytes of data into percpu buffer
> - percpu_put_get()
> - copy 32 bytes of data into percpu buffer
>
> rcu_read_[un]lock() used in percpu_ref_get/put() makes it go slower by
> about 15% when compared to using sched-RCU.
>
> As the RCU critical sections are extremely short, using sched-RCU
> shouldn't have any latency implications. Convert to RCU-sched.
>
> Signed-off-by: Tejun Heo
> Cc: Kent Overstreet
> Cc: Michal Hocko
> Cc: "Paul E. McKenney"
> Cc: Rusty Russell
Applied to percpu/for-3.11 with acks added. Thanks!
--
tejun
--
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 percpu/for-3.11] percpu-refcount: use RCU-sched insted of normal RCU
On Sun, Jun 16, 2013 at 02:55:46PM -0700, Tejun Heo wrote:
> percpu-refcount was incorrectly using preempt_disable/enable() for RCU
> critical sections against call_rcu(). 6a24474da8 ("percpu-refcount:
> consistently use plain (non-sched) RCU") fixed it by converting the
> preepmtion operations with rcu_read_[un]lock() citing that there isn't
> any advantage in using sched-RCU over using the usual one; however,
> rcu_read_[un]lock() for the preemptible RCU implementation -
> CONFIG_TREE_PREEMPT_RCU, chosen when CONFIG_PREEMPT - are slightly
> more expensive than preempt_disable/enable().
>
> In a contrived microbench which repeats the followings,
>
> - percpu_ref_get()
> - copy 32 bytes of data into percpu buffer
> - percpu_put_get()
> - copy 32 bytes of data into percpu buffer
>
> rcu_read_[un]lock() used in percpu_ref_get/put() makes it go slower by
> about 15% when compared to using sched-RCU.
>
> As the RCU critical sections are extremely short, using sched-RCU
> shouldn't have any latency implications. Convert to RCU-sched.
>
> Signed-off-by: Tejun Heo
> Cc: Kent Overstreet
> Cc: Michal Hocko
> Cc: "Paul E. McKenney"
> Cc: Rusty Russell
Acked-by: Kent Overstreet
--
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 percpu/for-3.11] percpu-refcount: use RCU-sched insted of normal RCU
On Sun, Jun 16, 2013 at 02:55:46PM -0700, Tejun Heo wrote:
> percpu-refcount was incorrectly using preempt_disable/enable() for RCU
> critical sections against call_rcu(). 6a24474da8 ("percpu-refcount:
> consistently use plain (non-sched) RCU") fixed it by converting the
> preepmtion operations with rcu_read_[un]lock() citing that there isn't
> any advantage in using sched-RCU over using the usual one; however,
> rcu_read_[un]lock() for the preemptible RCU implementation -
> CONFIG_TREE_PREEMPT_RCU, chosen when CONFIG_PREEMPT - are slightly
> more expensive than preempt_disable/enable().
>
> In a contrived microbench which repeats the followings,
>
> - percpu_ref_get()
> - copy 32 bytes of data into percpu buffer
> - percpu_put_get()
> - copy 32 bytes of data into percpu buffer
>
> rcu_read_[un]lock() used in percpu_ref_get/put() makes it go slower by
> about 15% when compared to using sched-RCU.
>
> As the RCU critical sections are extremely short, using sched-RCU
> shouldn't have any latency implications. Convert to RCU-sched.
>
> Signed-off-by: Tejun Heo
> Cc: Kent Overstreet
> Cc: Michal Hocko
> Cc: "Paul E. McKenney"
Acked-by: Paul E. McKenney
> Cc: Rusty Russell
> ---
> include/linux/percpu-refcount.h | 12 ++--
> lib/percpu-refcount.c |2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> --- a/include/linux/percpu-refcount.h
> +++ b/include/linux/percpu-refcount.h
> @@ -105,7 +105,7 @@ static inline void percpu_ref_get(struct
> {
> unsigned __percpu *pcpu_count;
>
> - rcu_read_lock();
> + rcu_read_lock_sched();
>
> pcpu_count = ACCESS_ONCE(ref->pcpu_count);
>
> @@ -114,7 +114,7 @@ static inline void percpu_ref_get(struct
> else
> atomic_inc(>count);
>
> - rcu_read_unlock();
> + rcu_read_unlock_sched();
> }
>
> /**
> @@ -134,7 +134,7 @@ static inline bool percpu_ref_tryget(str
> unsigned __percpu *pcpu_count;
> int ret = false;
>
> - rcu_read_lock();
> + rcu_read_lock_sched();
>
> pcpu_count = ACCESS_ONCE(ref->pcpu_count);
>
> @@ -143,7 +143,7 @@ static inline bool percpu_ref_tryget(str
> ret = true;
> }
>
> - rcu_read_unlock();
> + rcu_read_unlock_sched();
>
> return ret;
> }
> @@ -159,7 +159,7 @@ static inline void percpu_ref_put(struct
> {
> unsigned __percpu *pcpu_count;
>
> - rcu_read_lock();
> + rcu_read_lock_sched();
>
> pcpu_count = ACCESS_ONCE(ref->pcpu_count);
>
> @@ -168,7 +168,7 @@ static inline void percpu_ref_put(struct
> else if (unlikely(atomic_dec_and_test(>count)))
> ref->release(ref);
>
> - rcu_read_unlock();
> + rcu_read_unlock_sched();
> }
>
> #endif
> --- a/lib/percpu-refcount.c
> +++ b/lib/percpu-refcount.c
> @@ -154,5 +154,5 @@ void percpu_ref_kill_and_confirm(struct
> (((unsigned long) ref->pcpu_count)|PCPU_REF_DEAD);
> ref->confirm_kill = confirm_kill;
>
> - call_rcu(>rcu, percpu_ref_kill_rcu);
> + call_rcu_sched(>rcu, percpu_ref_kill_rcu);
> }
>
--
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] PCI: only WARN_ON() when pci_ioremap_bar() is called for io port BAR
On Fri, Jun 14, 2013 at 8:44 PM, Jiang Liu wrote:
> Ideally caller should check availability of IO BAR resource before
> calling pci_ioremap_bar(), but no caller doing that yet:(
> The WARN_ON() in function pci_ioremap_bar() is used to warn the caller
> if it's called for an IO port BAR, so disable it if OS fails to allocate
> resources for the BAR, otherwise it will generate heavy log messages as
> below (actually the last line of log message is enough for analysis):
> [ 157.383390] [ cut here ]
> [ 157.383396] WARNING: at drivers/pci/pci.c:130 pci_ioremap_bar+0x69/0x70()
> [ 157.383397] Modules linked in: ata_generic pata_acpi pata_marvell fuse
> zram(C) rfcomm bnep snd_hda_codec_hdmi snd_hda_codec_realtek rtsx_pci_ms
> rtsx_pci_sdmmc memstick mmc_core iTCO_wdt iTCO_vendor_support arc4 uvcvideo
> iwldvm videobuf2_vmalloc videobuf2_memops mac80211 qcserial videobuf2_core
> usb_wwan videodev media usbserial btusb bluetooth iwlwifi coretemp kvm_intel
> kvm sony_laptop cfg80211 snd_hda_intel snd_hda_codec rfkill i915 pcspkr r8169
> joydev mii rtsx_pci snd_hwdep intel_agp snd_pcm intel_gtt i2c_algo_bit
> snd_page_alloc drm_kms_helper snd_timer drm lpc_ich snd agpgart i2c_i801
> mfd_core sha256_ssse3 sha256_generic dm_crypt raid0 md_mod crc32_pclmul
> crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 glue_helper lrw
> gf128mul ablk_helper cryptd xhci_hcd ehci_pci ehci_hcd dm_mirror
> dm_region_hash
> [ 157.383462] dm_log dm_mod [last unloaded: microcode]
> [ 157.383469] CPU: 0 PID: 40 Comm: kworker/0:1 Tainted: GWC
> 3.10.0-rc4 #7
> [ 157.383473] Hardware name: Sony Corporation VPCZ23A4R/VAIO, BIOS R1013H5
> 05/21/2012
> [ 157.383478] Workqueue: kacpi_hotplug _handle_hotplug_event_bridge
> [ 157.383481] 81a2a114 880253d3f808 8165aab8
> 880253d3f848
> [ 157.383487] 8103c8cb 880253d3f828 880253152800
> 88022eb09000
> [ 157.383494] 880253153000 0001
> 880253d3f858
> [ 157.383500] Call Trace:
> [ 157.383507] [] dump_stack+0x19/0x1b
> [ 157.383513] [] warn_slowpath_common+0x6b/0xa0
> [ 157.383519] [] warn_slowpath_null+0x15/0x20
> [ 157.383524] [] pci_ioremap_bar+0x69/0x70
> [ 157.383532] [] azx_first_init+0x56/0x600 [snd_hda_intel]
> [ 157.383536] [] ? pci_get_domain_bus_and_slot+0x2f/0x70
> [ 157.383540] [] azx_probe+0x555/0x940 [snd_hda_intel]
> [ 157.383543] [] ? trace_hardirqs_on+0xd/0x10
> [ 157.383546] [] local_pci_probe+0x46/0x80
> [ 157.383549] [] pci_device_probe+0xf9/0x120
> [ 157.383549] [] pci_device_probe+0xf9/0x120
> [ 157.383554] [] driver_probe_device+0x76/0x220
> [ 157.383556] [] __device_attach+0x4b/0x60
> [ 157.383559] [] ? __driver_attach+0xb0/0xb0
> [ 157.383561] [] bus_for_each_drv+0x5c/0x90
> [ 157.383564] [] device_attach+0x98/0xb0
> [ 157.383566] [] pci_bus_add_device+0x34/0x60
> [ 157.383569] [] pci_bus_add_devices+0x39/0xa0
> [ 157.383571] [] pci_bus_add_devices+0x87/0xa0
> [ 157.383573] [] pci_bus_add_devices+0x87/0xa0
> [ 157.383575] [] pci_bus_add_devices+0x87/0xa0
> [ 157.383577] [] pci_bus_add_devices+0x87/0xa0
> [ 157.383580] [] enable_device+0x370/0x450
> [ 157.383583] [] acpiphp_enable_slot+0xca/0x140
> [ 157.383585] [] acpiphp_check_bridge+0x77/0x100
> [ 157.383587] [] _handle_hotplug_event_bridge+0x13d/0x290
> [ 157.383591] [] process_one_work+0x1c2/0x560
> [ 157.383594] [] ? process_one_work+0x157/0x560
> [ 157.383596] [] worker_thread+0x116/0x370
> [ 157.383598] [] ? manage_workers.isra.20+0x2d0/0x2d0
> [ 157.383601] [] kthread+0xd6/0xe0
> [ 157.383604] [] ? _raw_spin_unlock_irq+0x2b/0x60
> [ 157.383607] [] ? __init_kthread_worker+0x70/0x70
> [ 157.383610] [] ret_from_fork+0x7c/0xb0
> [ 157.383613] [] ? __init_kthread_worker+0x70/0x70
> [ 157.383614] ---[ end trace f366acc9dc87b38a ]---
> [ 157.383616] hda-intel :16:00.1: ioremap error
>
> Signed-off-by: Jiang Liu
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/pci/pci.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index a899d8b..9288161 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -127,7 +127,8 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int
> bar)
> * Make sure the BAR is actually a memory resource, not an IO resource
> */
> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
> - WARN_ON(1);
> + if (pci_resource_flags(pdev, bar))
> + WARN_ON(1);
This needs a URL to an email problem report or (better) a bugzilla
with the whole dmesg log.
The changelog is confusing, but here's what I *think* you're doing:
Today we WARN_ON() for any non-MEM BAR. The probe routine calls
"pci_ioremap_bar(pdev, 0)", so obviously BAR 0 is a MEM BAR because we
don't see usually see the warning. But in
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On Wed, 2013-06-05 at 16:11 +1000, Alexey Kardashevskiy wrote:
> +long kvm_vm_ioctl_create_spapr_tce_iommu(struct kvm *kvm,
> + struct kvm_create_spapr_tce_iommu *args)
> +{
> + struct kvmppc_spapr_tce_table *tt = NULL;
> + struct iommu_group *grp;
> + struct iommu_table *tbl;
> +
> + /* Find an IOMMU table for the given ID */
> + grp = iommu_group_get_by_id(args->iommu_id);
> + if (!grp)
> + return -ENXIO;
> +
> + tbl = iommu_group_get_iommudata(grp);
> + if (!tbl)
> + return -ENXIO;
So Alex Graf pointed out here, there is a security issue here, or are we
missing something ?
What prevents a malicious program that has access to /dev/kvm from
taking over random iommu groups (including host used ones) that way?
What is the security model of that whole iommu stuff to begin with ?
Cheers,
Ben.
--
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/
[13/83] ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()
3.2.47-rc1 review patch. If anyone has any objections, please let me know.
--
From: Xi Wang
commit 4fa0e81b83503900be277e6273a79651b375e288 upstream.
A malicious USB device may feed in carefully crafted min/max/res values,
so that the inner loop in parse_uac2_sample_rate_range() could run for
a long time or even never terminate, e.g., given max = INT_MAX.
Also nr_rates could be a large integer, which causes an integer overflow
in the subsequent call to kmalloc() in parse_audio_format_rates_v2().
Thus, kmalloc() would allocate a smaller buffer than expected, leading
to a memory corruption.
To exploit the two vulnerabilities, an attacker needs physical access
to the machine to plug in a malicious USB device.
This patch makes two changes.
1) The type of "rate" is changed to unsigned int, so that the loop could
stop once "rate" is larger than INT_MAX.
2) Limit nr_rates to 1024.
Suggested-by: Takashi Iwai
Signed-off-by: Xi Wang
Signed-off-by: Takashi Iwai
Signed-off-by: Ben Hutchings
---
sound/usb/format.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/sound/usb/format.c b/sound/usb/format.c
index 89421d1..e09aba1 100644
--- a/sound/usb/format.c
+++ b/sound/usb/format.c
@@ -209,6 +209,8 @@ static int parse_audio_format_rates_v1(struct snd_usb_audio
*chip, struct audiof
return 0;
}
+#define MAX_UAC2_NR_RATES 1024
+
/*
* Helper function to walk the array of sample rate triplets reported by
* the device. The problem is that we need to parse whole array first to
@@ -226,7 +228,7 @@ static int parse_uac2_sample_rate_range(struct audioformat
*fp, int nr_triplets,
int min = combine_quad([2 + 12 * i]);
int max = combine_quad([6 + 12 * i]);
int res = combine_quad([10 + 12 * i]);
- int rate;
+ unsigned int rate;
if ((max < 0) || (min < 0) || (res < 0) || (max < min))
continue;
@@ -253,6 +255,10 @@ static int parse_uac2_sample_rate_range(struct audioformat
*fp, int nr_triplets,
fp->rates |= snd_pcm_rate_to_rate_bit(rate);
nr_rates++;
+ if (nr_rates >= MAX_UAC2_NR_RATES) {
+ snd_printk(KERN_ERR "invalid uac2 rates\n");
+ break;
+ }
/* avoid endless loop */
if (res == 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/
[31/83] USB: serial: ftdi_sio: Handle the old_termios == 0 case e.g. uart_resume_port()
3.2.47-rc1 review patch. If anyone has any objections, please let me know. -- From: Andrew Worsley commit c515598e0f5769916c31c00392cc2bfe6af74e55 upstream. Handle null old_termios in ftdi_set_termios() calls from uart_resume_port(). Signed-off-by: Andrew Worsley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings --- drivers/usb/serial/ftdi_sio.c |4 1 file changed, 4 insertions(+) --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -2169,6 +2169,9 @@ static void ftdi_set_termios(struct tty_ cflag = termios->c_cflag; + if (old_termios == 0) + goto no_skip; + if (old_termios->c_cflag == termios->c_cflag && old_termios->c_ispeed == termios->c_ispeed && old_termios->c_ospeed == termios->c_ospeed) @@ -2182,6 +2185,7 @@ static void ftdi_set_termios(struct tty_ (termios->c_cflag & (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB))) goto no_data_parity_stop_changes; +no_skip: /* Set number of data bits, parity, stop bits */ urb_value = 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/
[06/83] mac80211: close AP_VLAN interfaces before unregistering all
3.2.47-rc1 review patch. If anyone has any objections, please let me know.
--
From: Johannes Berg
commit c8aa22db0112f640ac6631347f850879c621840b upstream.
Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces")
there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
up. If the AP_VLAN interface was registered after the AP it belongs
to (which is the typical case) and then we get into this code path,
unregister_netdevice_many() will crash because it isn't prepared to
deal with interfaces being closed in the middle of it. Exactly this
happens though, because we iterate the list, find the AP master this
AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
unregister_netdevice_many() won't pick up the fact that the AP_VLAN
is already down and will do it again, causing a crash.
Cc: Eric Dumazet
Signed-off-by: Johannes Berg
Signed-off-by: Ben Hutchings
---
net/mac80211/iface.c |9 +
1 file changed, 9 insertions(+)
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1242,6 +1242,15 @@ void ieee80211_remove_interfaces(struct
ASSERT_RTNL();
+ /*
+* Close all AP_VLAN interfaces first, as otherwise they
+* might be closed while the AP interface they belong to
+* is closed, causing unregister_netdevice_many() to crash.
+*/
+ list_for_each_entry(sdata, >interfaces, list)
+ if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ dev_close(sdata->dev);
+
mutex_lock(>iflist_mtx);
list_for_each_entry_safe(sdata, tmp, >interfaces, list) {
list_del(>list);
--
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/
[07/83] iwlwifi: dvm: fix zero LQ CMD sending avoidance
3.2.47-rc1 review patch. If anyone has any objections, please let me know. -- From: Emmanuel Grumbach commit a87783699b23395c46bbeeb5d28f6db24897bf26 upstream. In 63b77bf489881747c5118476918cc8c29378ee63 iwlwifi: dvm: don't send zeroed LQ cmd I tried to avoid to send zeroed LQ cmd, but I made a (very) stupid mistake in the memcmp. Since this patch has been ported to stable, the fix should go to stable too. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58341 Reported-by: Hinnerk van Bruinehsen Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings --- drivers/net/wireless/iwlwifi/iwl-agn-sta.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/iwlwifi/iwl-agn-sta.c +++ b/drivers/net/wireless/iwlwifi/iwl-agn-sta.c @@ -604,7 +604,7 @@ void iwl_restore_stations(struct iwl_pri memcpy(, priv->stations[i].lq, sizeof(struct iwl_link_quality_cmd)); - if (!memcmp(, _lq, sizeof(lq))) + if (memcmp(, _lq, sizeof(lq))) send_lq = true; } spin_unlock_irqrestore(>shrd->sta_lock, -- 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/
