Re: [PATCH] pwm: devm: alloc correct pointer size
On Mon, Jun 10, 2013 at 3:04 AM, Wolfram Sang wrote: > On Thu, Jun 06, 2013 at 10:43:41PM +0300, Andy Shevchenko wrote: >> On Mon, Jun 3, 2013 at 11:27 PM, Wolfram Sang wrote: >> > The allocated object should be the size of what the pointer is pointing >> > to and not the size of the pointer itself. >> >> All devm_* functions in this module use **ptr as a parameter (except >> allocation). >> May be we first should understand why it so? > > Huh? **ptr is already created on the stack, but assigned the alloced > memory. Later, the mem it points to is set to 'pwm' which is then added > to devres. So, the alloced memory must be able to contain '*ptr' (or > *pwm which would be more readable IMO, but other subsystems also stick > to *ptr), no? Yes, you right. Take my Reviewed-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko -- 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: Scaling problem with a lot of AF_PACKET sockets on different interfaces
07.06.2013 17:33, Daniel Borkmann пишет: On 06/07/2013 04:17 PM, Vitaly V. Bursov wrote: 07.06.2013 16:05, Daniel Borkmann пишет: [...] Ideas are welcome :) Probably, that depends on _your scenario_ and/or BPF filter, but would it be an alternative if you have only a few packet sockets (maybe one pinned to each cpu) and cluster/load-balance them together via packet fanout? (Where you bind the socket to ifindex 0, so that you get traffic from all devs...) That would at least avoid that "hot spot", and you could post-process the interface via sockaddr_ll. But I'd agree that this will not solve the actual problem you've observed. ;-) I was't aware of the ifindex 0 thing, it can help, thanks! Of course, if it'll work for me (applications is a custom DHCP server) it'll surely increase the overhead of BPF (I don't need to tap the traffic from all interfaces), there are vlans, bridges and bonds - likely the server will receive same packets multiple times and replies must be sent too... but it still should be faster. Well, as already said, if you use a fanout socket group, then you won't receive the _exact_ same packet twice. Rather, packets are balanced by different policies among your packet sockets in that group. What you could do is to have a (e.g.) single BPF filter (jitted) for all those sockets that'll let needed packets pass and you can then access the interface they came from via sockaddr_ll, which then is further processed in your fast path (or dropped depending on the iface). There's also a BPF extension (BPF_S_ANC_IFINDEX) that lets you load the ifindex of the skb into the BPF accumulator, so you could also filter early from there for a range of ifindexes (in combination to bind the sockets to index 0). Probably that could work. Thanks everybody, this should help a lot. -- Vitaly -- 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/3] MMC: FSL SDHC: Add support for hard-wired (permanent) card. Kernel version 3.4.47
On 02.06.2013 08:38, Oded Gabbay wrote: This patch adds support of recognizing hard-wired (permanent) cards to Freescale's SDHC host driver. This is done by adding the option "fsl,card-wired" to the SDHC device-tree entry. Detection of this option is done in the probe function. Update documentation in file fsl-esdhc.txt Why don't you want to introduce "fsl,card-wired"? Why don't you use "non-removable"? To my understanding the patch https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f217794ffa72f208a250b79ab0b7ea3de19677f explicitly removed "fsl,card-wired". So I don't think re-introducing it is a good idea? Best regards Dirk -- 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/2] x86,mtrr: Fix original mtrr range get for mtrr_cleanup
Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge during add range) broke mtrr cleanup on his setup in 3.9.5. corresponding commit in upstream is fbe06b7bae7c. *BAD*gran_size: 64K chunk_size: 16M num_reg: 6 lose cover RAM: -0G https://bugzilla.kernel.org/show_bug.cgi?id=59491 So it rejects new var mtrr layout. It turns out we have some problem with initial mtrr range retrievel. current sequence is: x86_get_mtrr_mem_range ==> bunchs of add_range_with_merge ==> bunchs of subract_range ==> clean_sort_range add_range_with_merge for [0,1M) sort_range() add_range_with_merge could have blank slots, so we can not just sort only, that will have final result have extra blank slot in head. So move that calling add_range_with_merge for [0,1M), with that we could avoid extra clean_sort_range calling. Reported-by: Joshua Covington Tested-by: Joshua Covington Signed-off-by: Yinghai Lu Cc: v3.9 --- arch/x86/kernel/cpu/mtrr/cleanup.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-2.6/arch/x86/kernel/cpu/mtrr/cleanup.c === --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/cleanup.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/cleanup.c @@ -714,15 +714,15 @@ int __init mtrr_cleanup(unsigned address if (mtrr_tom2) x_remove_size = (mtrr_tom2 >> PAGE_SHIFT) - x_remove_base; - nr_range = x86_get_mtrr_mem_range(range, 0, x_remove_base, x_remove_size); /* * [0, 1M) should always be covered by var mtrr with WB * and fixed mtrrs should take effect before var mtrr for it: */ - nr_range = add_range_with_merge(range, RANGE_NUM, nr_range, 0, + nr_range = add_range_with_merge(range, RANGE_NUM, 0, 0, 1ULL<<(20 - PAGE_SHIFT)); - /* Sort the ranges: */ - sort_range(range, nr_range); + /* add from var mtrr at last */ + nr_range = x86_get_mtrr_mem_range(range, nr_range, + x_remove_base, x_remove_size); range_sums = sum_ranges(range, nr_range); printk(KERN_INFO "total RAM covered: %ldM\n", -- 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/2] x86, range: Do not add new blank slot with add_range_with_merge
Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
during add range) broke mtrr cleanup on his setup in 3.9.5.
corresponding commit in upstream is fbe06b7bae7c.
The reason is add_range_with_merge could generate blank spot.
We could avoid that by searching new expanded start/end, that
new range should include all connected ranges in range array.
At last add the new expanded start/end to the range array.
Also move up left array so do not add new blank slot in the
range array.
-v2: move left array to avoid enhance add_range()
Reported-by: Joshua Covington
Signed-off-by: Yinghai Lu
Cc: v3.9
---
arch/x86/kernel/cpu/mtrr/cleanup.c |2 +-
kernel/range.c | 21 +++--
2 files changed, 12 insertions(+), 11 deletions(-)
Index: linux-2.6/kernel/range.c
===
--- linux-2.6.orig/kernel/range.c
+++ linux-2.6/kernel/range.c
@@ -32,9 +32,8 @@ int add_range_with_merge(struct range *r
if (start >= end)
return nr_range;
- /* Try to merge it with old one: */
+ /* get new start/end: */
for (i = 0; i < nr_range; i++) {
- u64 final_start, final_end;
u64 common_start, common_end;
if (!range[i].end)
@@ -45,14 +44,16 @@ int add_range_with_merge(struct range *r
if (common_start > common_end)
continue;
- final_start = min(range[i].start, start);
- final_end = max(range[i].end, end);
-
- /* clear it and add it back for further merge */
- range[i].start = 0;
- range[i].end = 0;
- return add_range_with_merge(range, az, nr_range,
- final_start, final_end);
+ /* new start/end, will add it back at last */
+ start = min(range[i].start, start);
+ end = max(range[i].end, end);
+
+ memmove(&range[i], &range[i + 1],
+ (nr_range - (i + 1)) * sizeof(range[i]));
+ range[nr_range - 1].start = 0;
+ range[nr_range - 1].end = 0;
+ nr_range--;
+ i--;
}
/* Need to add it: */
--
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 0/2] ARM: dts: Add palmas dtsi
This patch series adds palmas.dtsi and adds the omap5 specific palmas entries in the omap5-uevm board file. This patch series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm board. J Keerthy (2): ARM: dts: add dtsi for palmas ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties arch/arm/boot/dts/omap5-uevm.dts | 145 ++ arch/arm/boot/dts/palmas.dtsi| 98 + 2 files changed, 243 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/palmas.dtsi -- 1.7.5.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 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties.
This patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.11/dts
Boot tested on omap5-uevm board.
Signed-off-by: J Keerthy
---
arch/arm/boot/dts/omap5-uevm.dts | 145 ++
1 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..88172db 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -254,6 +254,151 @@
pinctrl-0 = <&i2c1_pins>;
clock-frequency = <40>;
+
+ palmas: palmas@48 {
+ reg = <0x48>;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-parent = <&gic>;
+ };
+
+};
+
+#include "palmas.dtsi"
+
+&palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = < 60>;
+ regulator-max-microvolt = <150>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-min-microvolt = < 60>;
+ regulator-max-microvolt = <131>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = < 60>;
+ regulator-max-microvolt = <131>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = <210>;
+ regulator-max-microvolt = <210>;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = <0x80>;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = <290>;
+ regulator-max-microvolt = <290>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = <220>;
+ regulator-max-microvolt = <220>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-min-microvolt = <150>;
+
[PATCH 1/2] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes.
Signed-off-by: Graeme Gregory
Signed-off-by: J Keerthy
---
arch/arm/boot/dts/palmas.dtsi | 98 +
1 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..4c5162f
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,98 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+&palmas {
+ compatible = "ti,palmas";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ palmas_pmic {
+ compatible = "ti,palmas-pmic";
+ interrupt-parent = <&palmas>;
+ interrupts = <14 IRQ_TYPE_NONE>;
+ interrupt-name = "short-irq";
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = "smps123";
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = "smps45";
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = "smps6";
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = "smps7";
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = "smps8";
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = "smps9";
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = "smps10";
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = "ldo1";
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = "ldo2";
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = "ldo3";
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-name = "ldo4";
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-name = "ldo5";
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-name = "ldo6";
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-name = "ldo7";
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-name = "ldo8";
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-name = "ldo9";
+ };
+
+ ldoln_reg: ldoln {
+ regulator-name = "ldoln";
+ };
+
+ ldousb_reg: ldousb {
+ regulator-name = "ldousb";
+ };
+ };
+ };
+};
--
1.7.5.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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Sun, Jun 09, 2013 at 04:23:51PM -0700, David Daney wrote: > On 06/09/2013 12:31 AM, Gleb Natapov wrote: > >On Fri, Jun 07, 2013 at 04:15:00PM -0700, David Daney wrote: > >>I should also add that I will shortly send patches for the kvm tool > >>required to drive this VM as well as a small set of patches that > >>create a para-virtualized MIPS/Linux guest kernel. > >> > >>The idea is that because there is no standard SMP linux system, we > >>create a standard para-virtualized system that uses a handful of > >>hypercalls, but mostly just uses virtio devices. It has no emulated > >>real hardware (no 8250 UART, no emulated legacy anything...) > >> > >Virtualization is useful for running legacy code. Why dismiss support > >for non pv guests so easily? > > Just because we create standard PV system devices, doesn't preclude > emulating real hardware. In fact Sanjay Lal's work includes QEMU > support for doing just this for a MIPS malta board. I just wanted a > very simple system I could implement with the kvm tool in a couple > of days, so that is what I initially did. > That makes sense. From your wording I misunderstood that there is something in proposed patches that requires PV to run a guest. -- Gleb. -- 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/2] tps6507x-ts: Add DT support
Hi Manish,
On Tue, May 21, 2013 at 02:24:17PM +0530, Vishwanathrao Badarkhe, Manish wrote:
> Add device tree based support for TI's tps6507x touchscreen.
>
> Tested on da850-evm.
>
> Signed-off-by: Vishwanathrao Badarkhe, Manish
> ---
> Changes since V2:
> - Removed unnecessary code.
> - Updated Documentation to provide proper names of
>devicetree properties.
>
> Changes since V1:
> - Updated documentation to specify tps6507x as multifunctional
>device.
> - return proper error value in absence of platform and DT
>data for touchscreen.
> - Updated commit message.
>
> :100755 100755 8fffa3c... 65ee2cd... M
> Documentation/devicetree/bindings/mfd/tps6507x.txt
> :100644 100644 65e0f9a... 89232ee... M
> drivers/input/touchscreen/tps6507x-ts.c
> Documentation/devicetree/bindings/mfd/tps6507x.txt | 28 ++-
> drivers/input/touchscreen/tps6507x-ts.c| 98
> ++--
> 2 files changed, 95 insertions(+), 31 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt
> b/Documentation/devicetree/bindings/mfd/tps6507x.txt
> index 8fffa3c..65ee2cd 100755
> --- a/Documentation/devicetree/bindings/mfd/tps6507x.txt
> +++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
> @@ -1,4 +1,8 @@
> -TPS6507x Power Management Integrated Circuit
> +TPS6507x Multifunctional Device.
> +
> +Features provided by TPS6507x:
> +1.Power Management Integrated Circuit.
> +2.Touch-Screen.
>
> Required properties:
> - compatible: "ti,tps6507x"
> @@ -23,6 +27,12 @@ Required properties:
> vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
> vindcdc3-supply : VDCDC3 input.
> vldo1_2-supply : VLDO1 and VLDO2 input.
> +- tsc: This node specifies touch screen data.
> + ti,poll-period : Time at which touch input is getting sampled in ms.
> + ti,min-pressure: Minimum pressure value to trigger touch.
> + ti,vref: voltage reference for ADC.
> + 0: Reference voltage for ADC is disabled.
> + 1: Reference voltage for ADC is enabled.
>
> Regulator Optional properties:
> - defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
> @@ -30,6 +40,14 @@ Regulator Optional properties:
> 1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
>If this property is not defined, it defaults to 0 (not enabled).
>
> +Touchscreen Optional properties:
> +- ti,vendor : Touchscreen vendor id to populate
> + in sysclass interface.
> +- ti,product: Touchscreen product id to populate
> + in sysclass interface.
> +- ti,version: Touchscreen version id to populate
> + in sysclass interface.
> +
> Example:
>
> pmu: tps6507x@48 {
> @@ -88,4 +106,12 @@ Example:
> };
> };
>
> + tsc {
> + ti,poll-period = <30>;
> + ti,min-pressure = <0x30>;
> + ti,vref = <0>;
> + ti,vendor = <0>;
> + ti,product = <65070>;
> + ti,version = <0x100>;
> + };
> };
> diff --git a/drivers/input/touchscreen/tps6507x-ts.c
> b/drivers/input/touchscreen/tps6507x-ts.c
> index 65e0f9a..89232ee 100644
> --- a/drivers/input/touchscreen/tps6507x-ts.c
> +++ b/drivers/input/touchscreen/tps6507x-ts.c
> @@ -21,6 +21,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
> #define TPS_DEFAULT_MIN_PRESSURE 0x30
> @@ -231,36 +233,76 @@ done:
> ret = tps6507x_adc_standby(tsc);
> }
>
> +static int tsc_init_data(struct tps6507x_dev *tps6507x_dev,
> + struct input_dev *input_dev)
> +{
> + struct device_node *node = tps6507x_dev->dev->of_node;
> + struct tps6507x_board *tps_board =
> + (struct tps6507x_board *)tps6507x_dev->dev->platform_data;
Please make tps_board const pointer and use dev_get_platdata() to fetch
it.
> + struct touchscreen_init_data *init_data = NULL;
> + int err;
> +
> + if (node)
> + node = of_find_node_by_name(node, "tsc");
Why do you have to locate OF node manually instead of already having it
attached to the device stucture?
> + if (tps_board)
> + init_data = tps_board->tps6507x_ts_init_data;
> +
> + if (node == NULL || init_data == NULL) {
> + err = -EINVAL;
> + goto error_ret;
> + } else if (init_data) {
> + tps6507x_dev->ts->poll_period = init_data->poll_period;
> + tps6507x_dev->ts->min_pressure = init_data->min_pressure;
> + tps6507x_dev->ts->vref = init_data->vref;
> + input_dev->id.vendor = init_data->vendor;
> + input_dev->id.product = init_data->product;
> + input_dev->id.version = init_data->version;
> + } else if (node) {
> + err = of_property_read_u32(node, "ti,poll-period",
> +
Re: [checkpatch] - Confusion
On Mon, Jun 10, 2013 at 11:21 AM, PINTU KUMAR wrote: > Hi, > > I wanted to submit my first patch. > But I have some confusion about the /scripts/checkpatch.pl errors. > > After correcting some checkpatch errors, when I run checkpatch.pl, it showed > me 0 errors. > But when I create patches are git format-patch, it is showing me 1 error. did you run the checkpatch.pl on the file which gets created after git format-patch? If yes, then I think it is not necessary.You can use git-am to apply your own patch on a undisturbed file and if it applies properly then you are good to go i.e. you can send your patch. > > If I fix error in patch, it showed me back again in files. > > Now, I am confused which error to fix while submitting patches, the file or > the patch errors. > > Please provide your opinion. > > File: mm/page_alloc.c > Previous file errors: > total: 16 errors, 110 warnings, 6255 lines checked > > After fixing errors: > total: 0 errors, 105 warnings, 6255 lines checked > > > And, after running on patch: > ERROR: need consistent spacing around '*' (ctx:WxV) > #153: FILE: mm/page_alloc.c:5476: > +int min_free_kbytes_sysctl_handler(ctl_table *table, int write, > > > > > - Pintu > -- > 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/
[checkpatch] - Confusion
Hi, I wanted to submit my first patch. But I have some confusion about the /scripts/checkpatch.pl errors. After correcting some checkpatch errors, when I run checkpatch.pl, it showed me 0 errors. But when I create patches are git format-patch, it is showing me 1 error. If I fix error in patch, it showed me back again in files. Now, I am confused which error to fix while submitting patches, the file or the patch errors. Please provide your opinion. File: mm/page_alloc.c Previous file errors: total: 16 errors, 110 warnings, 6255 lines checked After fixing errors: total: 0 errors, 105 warnings, 6255 lines checked And, after running on patch: ERROR: need consistent spacing around '*' (ctx:WxV) #153: FILE: mm/page_alloc.c:5476: +int min_free_kbytes_sysctl_handler(ctl_table *table, int write, - Pintu -- 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] mtd: orion_nand: Improve error handling in orion_nand_probe
Monday, June 10, 2013 9:01 AM, Emil Goode wrote:
>
> This patch fixes some issues in the error handling and simplifies
> the code by converting to devm* functions.
>
> If the kzalloc call fails it is unnecessary to use the label no_res
> and pass a NULL pointer to kfree. If the devm_kzalloc call fails on
> line 110 we forget to call iounmap for the previous ioremap call.
>
> The following changes are introduced:
> - Convert to devm_kzalloc and remove calls to kfree.
> - Convert to devm_ioremap_resource that adds a missing call to
> *request_mem_region and remove calls to iounmap.
> - The devm_ioremap_resource function checks the passed resource so
> we can remove the NULL check after the platform_get_resource call.
>
> Signed-off-by: Emil Goode
> ---
> This patch is only build tested
> v2: Fix change log typo and remove error messages for kzalloc calls
>
> drivers/mtd/nand/orion_nand.c | 49
> +
> 1 file changed, 15 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
> index 8fbd002..76b9fba 100644
> --- a/drivers/mtd/nand/orion_nand.c
> +++ b/drivers/mtd/nand/orion_nand.c
> @@ -85,35 +85,24 @@ static int __init orion_nand_probe(struct platform_device
> *pdev)
> int ret = 0;
> u32 val = 0;
>
> - nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info),
> GFP_KERNEL);
> - if (!nc) {
> - printk(KERN_ERR "orion_nand: failed to allocate device
> structure.\n");
CC'ed Dan Carpenter, Andy Shevchenko
You don't need to remove this error message.
You would replace 'printk(KERN_ERR "orion_nand:...)' with
'dev_err(&pdev->dev,)'.
dev_err("failed to allocate device structure.\n");
> - ret = -ENOMEM;
> - goto no_res;
> - }
> + nc = devm_kzalloc(&pdev->dev, sizeof(struct nand_chip) +
> + sizeof(struct mtd_info), GFP_KERNEL);
> + if (!nc)
> + return -ENOMEM;
> +
> mtd = (struct mtd_info *)(nc + 1);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - ret = -ENODEV;
> - goto no_res;
> - }
> -
> - io_base = ioremap(res->start, resource_size(res));
> - if (!io_base) {
> - printk(KERN_ERR "orion_nand: ioremap failed\n");
Yes, this error message is not necessary.
devm_ioremap_resource() provides its own error messages; so all
explicit error messages can be removed from the failure code paths.
> - ret = -EIO;
> - goto no_res;
> - }
> + io_base = devm_ioremap_resource(&pdev->dev, res);
How about using devm_ioremap() instead of devm_ioremap_resource()?
Only ioremap() was used previously; however, devm_ioremap_resource()
internally calls both devm_request_mem_region() and devm_ioremap().
If it is wrong, please let me know kindly. :)
> + if (IS_ERR(io_base))
> + return PTR_ERR(io_base);
>
> if (pdev->dev.of_node) {
> board = devm_kzalloc(&pdev->dev, sizeof(struct orion_nand_data),
> - GFP_KERNEL);
> - if (!board) {
> - printk(KERN_ERR "orion_nand: failed to allocate board
> structure.\n");
As above mentioned, you don't need to remove this error message.
You would replace 'printk(KERN_ERR "orion_nand:...)' with
'dev_err(&pdev->dev,)'.
dev_err("failed to allocate board structure.\n");
Best regards,
Jingoo Han
> - ret = -ENOMEM;
> - goto no_res;
> - }
> + GFP_KERNEL);
> + if (!board)
> + return -ENOMEM;
> +
> if (!of_property_read_u32(pdev->dev.of_node, "cle", &val))
> board->cle = (u8)val;
> else
> @@ -167,7 +156,7 @@ static int __init orion_nand_probe(struct platform_device
> *pdev)
>
> if (nand_scan(mtd, 1)) {
> ret = -ENXIO;
> - goto no_dev;
> + goto disable_clk;
> }
>
> mtd->name = "orion_nand";
> @@ -176,20 +165,17 @@ static int __init orion_nand_probe(struct
> platform_device *pdev)
> board->parts, board->nr_parts);
> if (ret) {
> nand_release(mtd);
> - goto no_dev;
> + goto disable_clk;
> }
>
> return 0;
>
> -no_dev:
> +disable_clk:
> if (!IS_ERR(clk)) {
> clk_disable_unprepare(clk);
> clk_put(clk);
> }
> platform_set_drvdata(pdev, NULL);
> - iounmap(io_base);
> -no_res:
> - kfree(nc);
>
> return ret;
> }
> @@ -197,15 +183,10 @@ no_res:
> static int orion_nand_remove(struct platform_device *pdev)
> {
> struct mtd_info *mtd = platform_get_drvdata(pdev);
> - struct nand_chip *nc = mtd->priv;
> struct clk *clk;
>
> nand_release(mtd);
>
> - iounmap(nc->IO_ADDR
Re: [PATCH] arm: Prevent memory aliasing on non-LPAE kernels
Hello Stepan, On Fri, May 31, 2013 at 6:45 AM, Stepan Moskovchenko wrote: > Some LPAE-capable systems may use a Device Tree containing > memory nodes that describe memory extending beyond the 4GB > physical address boundary. Ignore or truncate these memory > nodes on kernels that have not been built with LPAE > support, to prevent the extended physical addresses from > being truncated and aliasing with physical addresses below > the 4GB boundary. > > Signed-off-by: Stepan Moskovchenko > --- > arch/arm/kernel/devtree.c | 12 > 1 files changed, 12 insertions(+), 0 deletions(-) Thanks for your efforts on fixing this issue. Before I was aware of this patch I wrote a different implementation to solve most likely the same issue, please see the following patches for more information. Thanks to Arnd for pointing me in the right direction. [PATCH 00/03] ARM: 64-bit memory fixes, APE6EVM second memory bank [PATCH 01/03] ARM: Let arm_add_memory() always use 64-bit arguments [PATCH 02/03] ARM: Handle 64-bit memory in case of 32-bit phys_addr_t [PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM Regarding this patch, I have now tested it on my APE6EVM board together with this patch: [PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM Without your patch the situation is as follows: HIGHMEM=n, LPAE=n - OK (busted, second bank ignored with message [1]) HIGHMEM=y, LPAE=n - NG (busted, board hangs on boot) HIGHMEM=n, LPAE=y - OK HIGHMEM=y, LPAE=y - OK [1] Ignoring RAM at -3fff (vmalloc region overlap). With your patch applied I get the following: HIGHMEM=n, LPAE=n - OK (with message [2]) HIGHMEM=y, LPAE=n - OK (with message [2]) HIGHMEM=n, LPAE=y - OK HIGHMEM=y, LPAE=y - OK [2] Ignoring memory at 0x2 due to lack of LPAE support So your patch unbreaks the second memory on my board perfectly well, thank you! Regarding implementation details, I wonder if we only need to cover the DT memory banks by performing the check inside early_init_dt_add_memory_arch()? To me the root cause of this issue seems to be how phys_addr_t is configured when LPAE=n. It is understandable that the kernel cannot handle 64-bit addresses when phys_addr_t is 32-bit, but I believe we need some sane way to omit those memory banks. Your patch handles the non-LPAE case before phys_addr_t is involved which seems to work well. Your approach is much better compared to as-is today with potentially wrapping phys_addr_t parameters to arm_add_memory(). The only question in my mind is about the location for this kind of test, shall it be done in early_init_dt_add_memory_arch() or arm_add_memory()? If we care about adding some bounds checking for the kernel command line mem=xxx option then arm_add_memory() seems to be the best location from my point of view. Any ideas? Please add me to CC if you respin your patch. I will give it a go on my board. 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/
Re: [PATCH v2] cpufreq: fix governor start/stop race condition
On 9 June 2013 13:20, Xiaoguang Chen wrote:
> cpufreq governor stop and start should be kept in sequence.
> If not, there will be unexpected behavior, for example:
>
> we have 4 cpus and policy->cpu=cpu0, cpu1/2/3 are linked to cpu0.
> the normal sequence is as below:
>
> 1) Current governor is userspace, one application tries to set
> governor to ondemand. it will call __cpufreq_set_policy in which it
> will stop userspace governor and then start ondemand governor.
>
> 2) Current governor is userspace, now cpu0 hotplugs in cpu3, it will
> call cpufreq_add_policy_cpu. on which it first stops userspace
> governor, and then starts userspace governor.
>
> Now if the sequence of above two cases interleaves, it becames
> below sequence:
>
> 1) application stops userspace governor
> 2) hotplug stops userspace governor
> 3) application starts ondemand governor
> 4) hotplug starts a governor
>
> in step 4, hotplug is supposed to start userspace governor, but now
> the governor has been changed by application to ondemand, so hotplug
> starts ondemand governor again
>
> The solution is: do not allow stop governor multi-times
> Governor stop should only do once, after it is stopped,
> no other governor stop should be executed.
>
> Signed-off-by: Xiaoguang Chen
> ---
> drivers/cpufreq/cpufreq.c | 10 +-
> include/linux/cpufreq.h | 1 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2d53f47..c8d7cb2 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1562,6 +1562,11 @@ static int __cpufreq_governor(struct cpufreq_policy
> *policy,
>
> pr_debug("__cpufreq_governor for CPU %u, event %u\n",
> policy->cpu, event);
> +
> + if ((!policy->governor->enabled && (event == CPUFREQ_GOV_STOP)) ||
> + (policy->governor->enabled && (event == CPUFREQ_GOV_START)))
> + return 0;
> +
> ret = policy->governor->governor(policy, event);
>
> if (!ret) {
> @@ -1569,6 +1574,10 @@ static int __cpufreq_governor(struct cpufreq_policy
> *policy,
> policy->governor->initialized++;
> else if (event == CPUFREQ_GOV_POLICY_EXIT)
> policy->governor->initialized--;
> + else if (event == CPUFREQ_GOV_STOP)
> + policy->governor->enabled = 0;
> + else if (event == CPUFREQ_GOV_START)
> + policy->governor->enabled = 1;
> }
>
> /* we keep one module reference alive for
> @@ -1581,7 +1590,6 @@ static int __cpufreq_governor(struct cpufreq_policy
> *policy,
> return ret;
> }
>
> -
> int cpufreq_register_governor(struct cpufreq_governor *governor)
> {
> int err;
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 037d36a..16c5b70 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -199,6 +199,7 @@ struct cpufreq_governor {
> will fallback to performance governor */
> struct list_headgovernor_list;
> struct module *owner;
> + int enabled;
> };
This isn't sufficient.
If there are two groups of clk-sharing-cpus, i.e. if we have multiple
policies and they are using same governor, then these functions
gets called twice for governor x. And you will return 0 for the second
policy.
--
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] NVMe: Use kzalloc instead of kmalloc+memset
Use kzalloc instead of kmalloc and a susbsequent memset.
Signed-off-by: Tushar Behera
---
drivers/block/nvme-scsi.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/block/nvme-scsi.c b/drivers/block/nvme-scsi.c
index fed54b0..51d39a0 100644
--- a/drivers/block/nvme-scsi.c
+++ b/drivers/block/nvme-scsi.c
@@ -934,13 +934,12 @@ static int nvme_trans_bdev_char_page(struct nvme_ns *ns,
struct sg_io_hdr *hdr,
int res = SNTI_TRANSLATION_SUCCESS;
int xfer_len;
- inq_response = kmalloc(EXTENDED_INQUIRY_DATA_PAGE_LENGTH, GFP_KERNEL);
+ inq_response = kzalloc(EXTENDED_INQUIRY_DATA_PAGE_LENGTH, GFP_KERNEL);
if (inq_response == NULL) {
res = -ENOMEM;
goto out_mem;
}
- memset(inq_response, 0, EXTENDED_INQUIRY_DATA_PAGE_LENGTH);
inq_response[1] = INQ_BDEV_CHARACTERISTICS_PAGE;/* Page Code */
inq_response[2] = 0x00;/* Page Length MSB */
inq_response[3] = 0x3C;/* Page Length LSB */
@@ -965,12 +964,11 @@ static int nvme_trans_log_supp_pages(struct nvme_ns *ns,
struct sg_io_hdr *hdr,
int xfer_len;
u8 *log_response;
- log_response = kmalloc(LOG_PAGE_SUPPORTED_LOG_PAGES_LENGTH, GFP_KERNEL);
+ log_response = kzalloc(LOG_PAGE_SUPPORTED_LOG_PAGES_LENGTH, GFP_KERNEL);
if (log_response == NULL) {
res = -ENOMEM;
goto out_mem;
}
- memset(log_response, 0, LOG_PAGE_SUPPORTED_LOG_PAGES_LENGTH);
log_response[0] = LOG_PAGE_SUPPORTED_LOG_PAGES_PAGE;
/* Subpage=0x00, Page Length MSB=0 */
@@ -1001,12 +999,11 @@ static int nvme_trans_log_info_exceptions(struct nvme_ns
*ns,
u8 temp_c;
u16 temp_k;
- log_response = kmalloc(LOG_INFO_EXCP_PAGE_LENGTH, GFP_KERNEL);
+ log_response = kzalloc(LOG_INFO_EXCP_PAGE_LENGTH, GFP_KERNEL);
if (log_response == NULL) {
res = -ENOMEM;
goto out_mem;
}
- memset(log_response, 0, LOG_INFO_EXCP_PAGE_LENGTH);
mem = dma_alloc_coherent(&dev->pci_dev->dev,
sizeof(struct nvme_smart_log),
@@ -1070,12 +1067,11 @@ static int nvme_trans_log_temperature(struct nvme_ns
*ns, struct sg_io_hdr *hdr,
u8 temp_c_cur, temp_c_thresh;
u16 temp_k;
- log_response = kmalloc(LOG_TEMP_PAGE_LENGTH, GFP_KERNEL);
+ log_response = kzalloc(LOG_TEMP_PAGE_LENGTH, GFP_KERNEL);
if (log_response == NULL) {
res = -ENOMEM;
goto out_mem;
}
- memset(log_response, 0, LOG_TEMP_PAGE_LENGTH);
mem = dma_alloc_coherent(&dev->pci_dev->dev,
sizeof(struct nvme_smart_log),
@@ -1381,12 +1377,11 @@ static int nvme_trans_mode_page_create(struct nvme_ns
*ns,
blk_desc_offset = mph_size;
mode_pages_offset_1 = blk_desc_offset + blk_desc_len;
- response = kmalloc(resp_size, GFP_KERNEL);
+ response = kzalloc(resp_size, GFP_KERNEL);
if (response == NULL) {
res = -ENOMEM;
goto out_mem;
}
- memset(response, 0, resp_size);
res = nvme_trans_fill_mode_parm_hdr(&response[0], mph_size, cdb10,
llbaa, mode_data_length, blk_desc_len);
@@ -2481,12 +2476,11 @@ static int nvme_trans_read_capacity(struct nvme_ns *ns,
struct sg_io_hdr *hdr,
}
id_ns = mem;
- response = kmalloc(resp_size, GFP_KERNEL);
+ response = kzalloc(resp_size, GFP_KERNEL);
if (response == NULL) {
res = -ENOMEM;
goto out_dma;
}
- memset(response, 0, resp_size);
nvme_trans_fill_read_cap(response, id_ns, cdb16);
xfer_len = min(alloc_len, resp_size);
@@ -2555,12 +2549,11 @@ static int nvme_trans_report_luns(struct nvme_ns *ns,
struct sg_io_hdr *hdr,
goto out_dma;
}
- response = kmalloc(resp_size, GFP_KERNEL);
+ response = kzalloc(resp_size, GFP_KERNEL);
if (response == NULL) {
res = -ENOMEM;
goto out_dma;
}
- memset(response, 0, resp_size);
/* The first LUN ID will always be 0 per the SAM spec */
for (lun_id = 0; lun_id < le32_to_cpu(id_ctrl->nn); lun_id++) {
@@ -2601,12 +2594,11 @@ static int nvme_trans_request_sense(struct nvme_ns *ns,
struct sg_io_hdr *hdr,
resp_size = ((desc_format) ? (DESC_FMT_SENSE_DATA_SIZE) :
(FIXED_FMT_SENSE_DATA_SIZE));
- response = kmalloc(resp_size, GFP_KERNEL);
+ response = kzalloc(resp_size, GFP_KERNEL);
if (response == NULL) {
res = -ENOMEM;
goto out;
}
- memset(response, 0, resp_size);
if (desc
[PATCH] mac80211: Fix bogus RCU warning from ieee80211_get_tx_rates (Was: Re: rcu)
rate_control_fill_sta_table(), whose sole caller is ieee80211_get_tx_rates(), is guaranteed by mac80211 not to be called concurrently with rate_control_set_rates() [1], the sole function that touches the rate table pointer/data in struct ieee80211_sta. The RCU dereference is therefore safe. [1]: See commit f6b3d85f7f6d6 Signed-off-by: Calvin Owens --- net/mac80211/rate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c index d3f414f..585297d 100644 --- a/net/mac80211/rate.c +++ b/net/mac80211/rate.c @@ -539,7 +539,7 @@ static void rate_control_fill_sta_table(struct ieee80211_sta *sta, int i; if (sta && !info->control.skip_table) - ratetbl = rcu_dereference(sta->rates); + ratetbl = rcu_dereference_protected(sta->rates, true); /* Fill remaining rate slots with data from the sta rate table. */ max_rates = min_t(int, max_rates, IEEE80211_TX_RATE_TABLE_SIZE); -- 1.8.2.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/
Message To: Email Account Owner!
Message To: Email Account Owner! WARNING!!! A 2013 DFXG Virus Detected on your mailbox and your account will be terminated in a short time from our database. Please verify the continue usage of this account by clicking or coping the below "LINK" to your browser and log-in with your full email Address to keep your account active... http://adminlogin-webmail.jimdo.com/ Failure to do this, will lead to lost of email account... Thanks for your understanding and Co-operation -- 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: [git pull] Please pull powerpc.git merge branch
On Sun, Jun 9, 2013 at 9:20 PM, Jeremy Kerr wrote: > > So, we now use the original date header (if present) in the mbox views: > > $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date > Date: Fri, 7 Jun 2013 15:42:54 +1000 > > ... for all your data-mining needs. Goodie, and I see that it even works with old patches. Thanks. Linus -- 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: [git pull] Please pull powerpc.git merge branch
Hi Linus, > No. The date from the email was > > Date: Fri, 7 Jun 2013 15:42:54 +1000 > > and we want *that* date. Ah, gotchya. So, we now use the original date header (if present) in the mbox views: $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date Date: Fri, 7 Jun 2013 15:42:54 +1000 ... for all your data-mining needs. Cheers, Jeremy -- 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] clk: exynos5250: Add CLK_IGNORE_UNUSED flag for pmu clock
On 06/06/2013 01:58 PM, Tushar Behera wrote:
> Currently 'pmu' clock is not handled by any of the drivers.
> Also before the introduction of CCF, this clock was not defined,
> hence was left enabled always.
>
> When this clock is disabled, software reset register becomes
> inaccessible and system reboot doesn't work.
>
> Upon restoring the default behaviour, system reboot starts working.
>
> Signed-off-by: Tushar Behera
> ---
> drivers/clk/samsung/clk-exynos5250.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5250.c
> b/drivers/clk/samsung/clk-exynos5250.c
> index 5c97e75..3853da9 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -378,7 +378,7 @@ struct samsung_gate_clock exynos5250_gate_clks[]
> __initdata = {
> GATE(hsi2c3, "hsi2c3", "aclk66", GATE_IP_PERIC, 31, 0, 0),
> GATE(chipid, "chipid", "aclk66", GATE_IP_PERIS, 0, 0, 0),
> GATE(sysreg, "sysreg", "aclk66", GATE_IP_PERIS, 1, 0, 0),
> - GATE(pmu, "pmu", "aclk66", GATE_IP_PERIS, 2, 0, 0),
> + GATE(pmu, "pmu", "aclk66", GATE_IP_PERIS, 2, CLK_IGNORE_UNUSED, 0),
> GATE(tzpc0, "tzpc0", "aclk66", GATE_IP_PERIS, 6, 0, 0),
> GATE(tzpc1, "tzpc1", "aclk66", GATE_IP_PERIS, 7, 0, 0),
> GATE(tzpc2, "tzpc2", "aclk66", GATE_IP_PERIS, 8, 0, 0),
>
If there are no objections, can this patch be queued for 3.10? It is
fixing regression w.r.t. system reboot on EXYNOS5250 based systems.
--
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 2/3] ARM: dts: Add FIMD node to Origen4210 board
On 06/08/2013 04:19 PM, Tomasz Figa wrote:
> On Friday 07 of June 2013 16:37:14 Tushar Behera wrote:
>> From: Sachin Kamat
>>
>> Added FIMD and display timing node to Origen4210 board.
>>
>> Signed-off-by: Sachin Kamat
>> Signed-off-by: Tushar Behera
>> ---
>> arch/arm/boot/dts/exynos4210-origen.dts | 21 +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
>> b/arch/arm/boot/dts/exynos4210-origen.dts index bcf8079..4c6c3cd 100644
>> --- a/arch/arm/boot/dts/exynos4210-origen.dts
>> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
>> @@ -290,4 +290,25 @@
>> clock-frequency = <2400>;
>> };
>> };
>> +
>> +fimd@11c0 {
>> +pinctrl-0 = <&lcd_en &lcd_clk &lcd_data24 &pwm0_out>;
>
> Ahh, this would explain the two pwm pin groups from previous patch.
>
> This seems somehow incorrect, though. AFAIK PWM outputs are not managed by
> FIMD in any way.
>
I couldn't find any better place to put the pwm0_out pin configurations.
Without configuring pwm0_out pins, display doesn't come up on the LCD.
Any suggestions?
>> +pinctrl-names = "default";
>> +status = "okay";
>> +};
>> +
>> +display-timings {
>> +native-mode = <&timing0>;
>> +timing0: timing {
>> +clock-frequency = <5>;
>
> Hmm, 50 KHz for pixel clock? Isn't it a bit too low? Or am I missing
> something?
>
Actually clock-frequency value is not used by DRM-FIMD, but instead
required by the framework.
Still it would be better to provide the actual pixel clock value here.
So I would update this with 40MHz which is actual pixel clock used on my
board.
> Best regards,
> Tomasz
>
>> +hactive = <1024>;
>> +vactive = <600>;
>> +hfront-porch = <64>;
>> +hback-porch = <16>;
>> +hsync-len = <48>;
>> +vback-porch = <64>;
>> +vfront-porch = <16>;
>> +vsync-len = <3>;
>> +};
>> +};
>> };
Thanks for your review.
--
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 RFC v2 0/3] add cpu physically hotplug driver
在 2013-06-10一的 12:51 +0900，Yasuaki Ishimatsu写道： > 2013/06/10 9:36, li guang wrote: > > Hi, Rafael > > > > 在 2013-06-06四的 13:00 +0200，Rafael J. Wysocki写道： > >> On Thursday, June 06, 2013 09:40:32 AM liguang wrote: > >>> This patch-set try to support physically hot-plug/unplug > >>> a cpu automatically, that is: > >>> if you offline a cpu, it will automatically actually remove > >>> a cpu, and if you hot-plug a cpu, then it will online this > >>> cpu automatically. > >> > >> No and no. > > > > Hmm... are you saying cpu online/offline designed to distinguish > > with real cpu plug/unplug? > > but, what the actual usage of online/offline? > > forgive my foolish. > > > >> > >> Why do you need this? > >> > > > > e.g. for QEMU case, if hot-plug a cpu, > > > we have to online a cpu manually if there's > > no user space support like udev to do it automatically. > > I could not understand why you do not use udev. > Please explain in detail. I did not say I can't use udev now, just for in case someone can't. > > > and also, I think maybe online/offline should be naturally > > integrated with real plug/unplug process of CPU. > > I could not understand this explanation too. > Why do we need it? > actually, I am asking if CPU online/offline have real purpose, you offline a CPU, then threads can't run on it, you online a CPU, then threads can run on it, so, the purpose here is just bouncing threads? obviously not, any profound historical reasons? I boldly think maybe online/offline should be integrated into real plug/unplug process of CPU. Thanks! > > > >> > >> > >>> so, offline is just like eject, but eject attribute seems not > >>> available since recent kernel(can't figure out when), with > >>> this driver, if allowed, it will trigger a eject cpu process. > >>> and for automatically online, it was said there are objections, > >>> don't know the reason, so, send this patch-set boldly. > >>> > >>> of course, this approach is for QEMU 's hotplug cpu emulation > >>> only, but not limited, if someone like to explore ec space to > >>> implment cpu hot-plug/unplug for real platform please > >>> feel free to continue. > >>> > >>> Li Guang (3) > >>>drivers/platform/x86: add cpu physically hotplug driver > >>>ec: add ec space notifier > >>>cpu_physic_hotplug: register handler for ec space notifier > >>> > >>> drivers/acpi/ec.c | 32 > >>> > >>> drivers/platform/x86/Kconfig | 8 > >>> drivers/platform/x86/Makefile | 1 + > >>> drivers/platform/x86/cpu_physic_hotplug.c | 90 > >>> + > >>> include/linux/acpi.h | 2 ++ > >>> 5 files changed, 130 insertions(+), 3 deletions(-) > >>> create mode 100644 drivers/platform/x86/cpu_physic_hotplug.c > > > > > > -- > > 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: [PATCHv2 4/6] sched_clock: Add support for >32 bit sched_clock
On 06/04/2013 05:21 AM, Russell King - ARM Linux wrote: > On Mon, Jun 03, 2013 at 06:51:59PM -0700, Stephen Boyd wrote: >> On 06/03/13 15:12, Russell King - ARM Linux wrote: >>> If you have a 56-bit clock which ticks at a period of 1ns, then >>> cd.rate = 1, and your sched_clock() values will be truncated to 56-bits. >>> The scheduler always _requires_ 64-bits from sched_clock. That's why we >>> have the complicated code to extend the 32-bits-or-less to a _full_ >>> 64-bit value. >>> >>> Let me make this clearer: sched_clock() return values _must_ without >>> exception monotonically increment from zero to 2^64-1 and then wrap >>> back to zero. No other behaviour is acceptable for sched_clock(). >> >> Ok so you're saying if we have less than 64 bits of useable information >> we _must_ do something to find where the wraparound will occur and >> adjust for it so that epoch_ns is always incrementing until 2^64-1. Fair >> enough. I was trying to avoid more work because on arm architected timer >> platforms it takes many years for that to happen. >> >> I'll see what I can do. > > Well, 56 bits at 1ns intervals is 833 days (2^56 / (10*60*60*24)). > We used to say that 497 days was enough several years ago, and that got > fixed. We used to say 640K was enough memory for anything, and that > got fixed. The ARM ARM states a minimum resolution of 40 years AND at least 56-bits of resolution. So a 1Gz counter would have to have more that 56 bits. 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 1/3] ARM: dts: exynos4210: Add LCD related pinctrl entries
On 06/08/2013 04:16 PM, Tomasz Figa wrote:
> Hi Tushar, Sachin,
>
> On Friday 07 of June 2013 16:37:13 Tushar Behera wrote:
>> From: Sachin Kamat
>>
>> Adds pinctrl entries required by FIMD.
>>
>> Signed-off-by: Sachin Kamat
>> Signed-off-by: Tushar Behera
>> ---
>> arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 75
>> + 1 file changed, 75 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>> b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi index 55a2efb..d241726
>> 100644
>> --- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>> +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>> @@ -330,6 +330,81 @@
>> samsung,pin-pud = <3>;
>> samsung,pin-drv = <0>;
>> };
>> +
>> +pwm0_out: pwm0-out {
>> +samsung,pins = "gpd0-0";
>> +samsung,pin-function = <2>;
>> +samsung,pin-pud = <0>;
>> +samsung,pin-drv = <0>;
>> +};
>> +
>> +pwm1_out: pwm1-out {
>> +samsung,pins = "gpd0-1";
>> +samsung,pin-function = <2>;
>> +samsung,pin-pud = <0>;
>> +samsung,pin-drv = <0>;
>> +};
>
> Hmm, these two seem to be unrelated. Rebase error? :)
>
Not a rebase error. pwm0_out needs to configured to get display on LCD.
--
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/4] de_thread: use change_pid() rather than detach_pid/attach_pid
Oleg Nesterov writes: > de_thread() can use change_pid() instead of detach + attach. > This looks better and this ensures that, say, next_thread() > can never see a task with ->pid == NULL. I want to say that there I though there was a good reason something to do with the exit logic. However I just read through attach_pid, detach_pid, and change_pid. And the sequence detach_pid(...); attach_pid(...) is equiavalent to change_pid(...); Reviewed-by: "Eric W. Biederman" > Signed-off-by: Oleg Nesterov > --- > fs/exec.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/fs/exec.c b/fs/exec.c > index 6430195..00eaba7 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -945,9 +945,8 @@ static int de_thread(struct task_struct *tsk) >* Note: The old leader also uses this pid until release_task >* is called. Odd but simple and correct. >*/ > - detach_pid(tsk, PIDTYPE_PID); > tsk->pid = leader->pid; > - attach_pid(tsk, PIDTYPE_PID, task_pid(leader)); > + change_pid(tsk, PIDTYPE_PID, task_pid(leader)); > transfer_pid(leader, tsk, PIDTYPE_PGID); > transfer_pid(leader, tsk, PIDTYPE_SID); -- 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: dts: add dtsi for palmas
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org;
linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org; ldewan...@nvidia.com;
grant.lik...@secretlab.ca; swar...@nvidia.com; sa...@linux.intel.com;
g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
> Adds palmas mfd and palmas regulator nodes. This is
> based on the patch series:
>
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
>
> The device tree nodes are based on:
> https://lkml.org/lkml/2013/6/6/25
> diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
> +&palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that it
makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by including
those overrides after the include.
Irrespective of that, some comments on this:
> + palmas_pmic {
> + ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
> +
> + regulators {
> + smps123_reg: smps123 {
> + regulator-name = "smps123";
> + regulator-min-microvolt = < 60>;
> + regulator-max-microvolt = <150>;
Or what if the board wants to limit the voltage range of this regulator
due to what it's used for on the board.
> + regulator-always-on;
> + regulator-boot-on;
And those two properties are almost certainly board-specific policy.
Totally agree to all the above concerns. So can we have a custom .dtsi file
for a board+pmic combination? Or have only the required properties over ridden
in the board file?
Regards,
Keerthy
--
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 v2 0/3] add cpu physically hotplug driver
2013/06/10 9:36, li guang wrote: Hi, Rafael 在 2013-06-06四的 13:00 +0200，Rafael J. Wysocki写道： On Thursday, June 06, 2013 09:40:32 AM liguang wrote: This patch-set try to support physically hot-plug/unplug a cpu automatically, that is: if you offline a cpu, it will automatically actually remove a cpu, and if you hot-plug a cpu, then it will online this cpu automatically. No and no. Hmm... are you saying cpu online/offline designed to distinguish with real cpu plug/unplug? but, what the actual usage of online/offline? forgive my foolish. Why do you need this? e.g. for QEMU case, if hot-plug a cpu, we have to online a cpu manually if there's no user space support like udev to do it automatically. I could not understand why you do not use udev. Please explain in detail. and also, I think maybe online/offline should be naturally integrated with real plug/unplug process of CPU. I could not understand this explanation too. Why do we need it? Thanks, Yasuaki Ishimatsu so, offline is just like eject, but eject attribute seems not available since recent kernel(can't figure out when), with this driver, if allowed, it will trigger a eject cpu process. and for automatically online, it was said there are objections, don't know the reason, so, send this patch-set boldly. of course, this approach is for QEMU 's hotplug cpu emulation only, but not limited, if someone like to explore ec space to implment cpu hot-plug/unplug for real platform please feel free to continue. Li Guang (3) drivers/platform/x86: add cpu physically hotplug driver ec: add ec space notifier cpu_physic_hotplug: register handler for ec space notifier drivers/acpi/ec.c | 32 drivers/platform/x86/Kconfig | 8 drivers/platform/x86/Makefile | 1 + drivers/platform/x86/cpu_physic_hotplug.c | 90 + include/linux/acpi.h | 2 ++ 5 files changed, 130 insertions(+), 3 deletions(-) create mode 100644 drivers/platform/x86/cpu_physic_hotplug.c -- 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 2/2] clk: exynos4: Add alias for cpufreq related clocks
On 06/08/2013 05:20 PM, Tomasz Figa wrote:
> On Thursday 06 of June 2013 16:52:28 Tushar Behera wrote:
>> cpufreq driver for EXYNOS4 based SoCs are not platform drivers, hence
>> we cannot currently pass the clock names through a device tree node.
>> Instead, we need to make them available through a global alias.
>>
>> 'armclk', 'moutcore', 'mout_mpll' and 'mout_apll' clock aliases are
>> defined.
>>
>> Signed-off-by: Tushar Behera
>> ---
>> drivers/clk/samsung/clk-exynos4.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos4.c
>> b/drivers/clk/samsung/clk-exynos4.c index 3c1f888..1e4258a 100644
>> --- a/drivers/clk/samsung/clk-exynos4.c
>> +++ b/drivers/clk/samsung/clk-exynos4.c
>> @@ -356,8 +356,8 @@ struct samsung_fixed_rate_clock
>> exynos4210_fixed_rate_clks[] __initdata = {
>>
>> /* list of mux clocks supported in all exynos4 soc's */
>> struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
>> -MUX_F(mout_apll, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
>> -CLK_SET_RATE_PARENT, 0),
>> +MUX_FA(mout_apll, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
>> +CLK_SET_RATE_PARENT, 0, "mout_apll"),
>> MUX(none, "mout_hdmi", mout_hdmi_p, SRC_TV, 0, 1),
>> MUX(none, "mout_mfc1", sclk_evpll_p, SRC_MFC, 4, 1),
>> MUX(none, "mout_mfc", mout_mfc_p, SRC_MFC, 8, 1),
>> @@ -385,9 +385,9 @@ struct samsung_mux_clock exynos4210_mux_clks[]
>> __initdata = { MUX(none, "mout_g2d", mout_g2d_p, E4210_SRC_IMAGE, 8,
>> 1),
>> MUX(none, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4),
>> MUX(none, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
>> -MUX_A(sclk_mpll, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1,
> "sclk_mpll"),
>> +MUX_A(sclk_mpll, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1,
> "mout_mpll"),
>
> This is not fully compliant with patch description. I'm not sure if there
> weren't any users of the sclk_mpll alias.
>
As of now, there are no other users of sclk_mpll other than a debug
print within the same file.
>> 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").
>> MUX_A(sclk_vpll, "sclk_vpll", sclk_vpll_p4210,
>> SRC_TOP0, 8, 1, "sclk_vpll"),
>> MUX(mout_fimc0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4),
>> @@ -534,7 +534,7 @@ struct samsung_div_clock exynos4_div_clks[]
>> __initdata = { DIV(none, "div_spi_pre2", "div_spi2", DIV_PERIL2, 8, 8),
>> DIV(none, "div_audio1", "mout_audio1", DIV_PERIL4, 0, 4),
>> DIV(none, "div_audio2", "mout_audio2", DIV_PERIL4, 16, 4),
>> -DIV_A(arm_clk, "arm_clk", "div_core2", DIV_CPU0, 28, 3,
> "arm_clk"),
>> +DIV_A(arm_clk, "arm_clk", "div_core2", DIV_CPU0, 28, 3, "armclk"),
>
> Same here.
>
Same as above, "armclk" is used elsewhere, not "arm_clk".
>> DIV_A(sclk_apll, "sclk_apll", "mout_apll",
>> DIV_CPU0, 24, 3, "sclk_apll"),
>> DIV_F(none, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4,
>
> 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.
> This is especially important in case of regulators, which currently have
> to be hacked by using vdd_arm as regulator name in device tree.
>
Agree.
> CCing people that might be interested in this topic.
>
> Best regards,
> Tomasz
>
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 V2] ahci: sata: add support for exynos5440 sata
HI,
can this patch be pulled in for 3.11
On Tue, Apr 16, 2013 at 2:58 PM, Girish K S wrote:
> This patch adds the compatible string of the exynos5440 sata controller
> compliant with the ahci 1.3 and sata 3.0 specification.
>
> Signed-off-by: Girish K S
>
> changes in v2:
> changed the compatible string by adding the actual IP
> owners name instead of the SoC vendor name.
>
> ---
> drivers/ata/ahci_platform.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 7a8a284..c06f021 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -327,6 +327,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend,
> ahci_resume);
>
> static const struct of_device_id ahci_of_match[] = {
> { .compatible = "snps,spear-ahci", },
> + { .compatible = "snps,exynos5440-ahci", },
> {},
> };
> MODULE_DEVICE_TABLE(of, ahci_of_match);
> --
> 1.7.5.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: [git pull] Please pull powerpc.git merge branch
On Sun, Jun 9, 2013 at 8:20 PM, Linus Torvalds wrote: > > .. the rationale for this is that the work pattern of people is > actually interesting information. You can do things like this: > > git log --pretty=%aD --author=Torvalds Final side note: for me, and other git users that apply other peoples patches, it's probably better to use git log --pretty=%cD --committer=Torvalds instead. Interestingly, that shows a different pattern than my "authorship" statistics, which are mainly pull requests. It turns out I commit patches much more in the afternoon. The reason is probably simple: in the mornings, I have pull requests waiting from overnight, so a fair number of pull requests where I am author at 9-11. But my biggest source of patches tends to be Andrew Morton, who sends the patches in the afternoon, so suddenly the commit counts skew towards being between 3pm-8pm when you take all my commits into accoint. Doing git log --since=6.months --pretty=%aD --grep=Signed.*Andrew.Morton backs that up: most of the commits that have sign-offs by Andrew are sent in the afternoon. I just find details like that really interesting, where you can actually mine for the workpatterns of people. Linus -- 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 v1 0/3] Polling support for s3c64xx spi controller
Hello Mark, pls let me know if there is any issue with this series On Mon, May 20, 2013 at 12:21 PM, Girish K S wrote: > This patch series adds support for the polling mode only. Also 2nd patch > in the series adds support for dedicated cs pin. After Thomas's patch for > using default gpio is merged(commit id: 00ab539), one of the patch in this > series is dropped and new series is generated. > > Girish K S (3): > spi: s3c64xx: added support for polling mode > spi: s3c64xx: Added provision for dedicated cs pin > spi: s3c64xx: Added support for exynos5440 spi > > drivers/spi/spi-s3c64xx.c | 197 > - > 1 files changed, 140 insertions(+), 57 deletions(-) > > -- > 1.7.5.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: [git pull] Please pull powerpc.git merge branch
On Sun, Jun 9, 2013 at 8:06 PM, Linus Torvalds wrote: > > And it does matter. .. the rationale for this is that the work pattern of people is actually interesting information. You can do things like this: git log --pretty=%aD --author=Torvalds to see what my work pattern is, and I think that's *interesting*. Gathering statistics like whether people are generally doing 9-5 Mon-Fri is actually interesting data. You can do things like this: git log --since=6.months --pretty=%aD --author=Torvalds | cut -c1-3 | sort | uniq -c | sort -n and see (for example) that I do slow down on weekends. Same goes for things like what time of day ends up being most productive. You can do the statistics for me, and see that I tend to do the bulk of my pulls in the mornings (peak between 9-11) and that I'm not a night-owl (*big* drop-off after 8PM - that's what kids do to you). You can see a few really early-morning cases, but I suspect they were when I was jetlagged. So the date data is actually meaningful data. It's not just random noise. And to do these kinds of things, you absolutely have to have local-time with proper timezone information. Anything that screws that up is *broken*. git gets this right, unlike a lot of other broken SCM's. Git gets it right for a reason. Yeah, yeah, when people forward other peoples patches they often drop the date field, and the date of the patch ends up being the time that the last version of the patch got sent rather than anything else, so many of the statistics aren't valid. But a _tool_ that actively corrupts the date and time of a patch is just broken. Linus -- 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: [git pull] Please pull powerpc.git merge branch
On Sun, Jun 9, 2013 at 7:44 PM, Jeremy Kerr wrote: > > We keep all patch dates in UTC, but were generating the Date header > incorrectly. Now fixed: No, not fixed. Keeping patch dates in UTC *corrupts* the date. I'll ask people to stop using patchworks if it cannot keep track of emailed dates. The date very much is a local time WITH A TIMEZONE. And it does matter. > $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date > Date: Fri, 07 Jun 2013 05:42:54 - No. The date from the email was Date: Fri, 7 Jun 2013 15:42:54 +1000 and we want *that* date. Not some random date that patchwork makes up that has no relevance. I know you have that date, because it shows up when asking for the headers in patchwork. Just use the right one, don't make up incorrect ones. Linus -- 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] ocfs2: Cocci spatch "memdup.spatch"
Acked-by: Joel Becker
On Sat, Jun 01, 2013 at 11:41:12AM +0200, Thomas Meyer wrote:
>
> Signed-off-by: Thomas Meyer
> ---
>
> diff -u -p a/fs/ocfs2/localalloc.c b/fs/ocfs2/localalloc.c
> --- a/fs/ocfs2/localalloc.c
> +++ b/fs/ocfs2/localalloc.c
> @@ -434,12 +434,11 @@ void ocfs2_shutdown_local_alloc(struct o
> bh = osb->local_alloc_bh;
> alloc = (struct ocfs2_dinode *) bh->b_data;
>
> - alloc_copy = kmalloc(bh->b_size, GFP_NOFS);
> + alloc_copy = kmemdup(alloc, bh->b_size, GFP_NOFS);
> if (!alloc_copy) {
> status = -ENOMEM;
> goto out_commit;
> }
> - memcpy(alloc_copy, alloc, bh->b_size);
>
> status = ocfs2_journal_access_di(handle, INODE_CACHE(local_alloc_inode),
>bh, OCFS2_JOURNAL_ACCESS_WRITE);
> @@ -1244,13 +1243,12 @@ static int ocfs2_local_alloc_slide_windo
>* local alloc shutdown won't try to double free main bitmap
>* bits. Make a copy so the sync function knows which bits to
>* free. */
> - alloc_copy = kmalloc(osb->local_alloc_bh->b_size, GFP_NOFS);
> + alloc_copy = kmemdup(alloc, osb->local_alloc_bh->b_size, GFP_NOFS);
> if (!alloc_copy) {
> status = -ENOMEM;
> mlog_errno(status);
> goto bail;
> }
> - memcpy(alloc_copy, alloc, osb->local_alloc_bh->b_size);
>
> status = ocfs2_journal_access_di(handle,
>INODE_CACHE(local_alloc_inode),
>
>
> --
> 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: [git pull] Please pull powerpc.git merge branch
Hi Linus, > Is Jeremy the patchwork maintainer? Yep, that's me. > and it turns out that apparently 'patchwork' is just making up random > times, because when you download the email as an mbox, it will turn > this into that corrupt and incorrect > > Date: Thu, 06 Jun 2013 19:42:54 - > > thing which is apparently how you got the wrong timestamp to begin with. We keep all patch dates in UTC, but were generating the Date header incorrectly. Now fixed: $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date Date: Fri, 07 Jun 2013 05:42:54 - Commit is at: http://git.ozlabs.org/?p=patchwork;a=commitdiff;h=e7353352 Cheers, Jeremy -- 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/07/2013 03:29 PM, Alex Shi wrote: > There are some 64 bits variables in cfs_rq/tg etc. That ask expersive > 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. BTW, this patch bases on my v8 patchset: use runnable load in balance. the git tree is here: g...@github.com:alexshi/power-scheduling.git runnablelb Any more comments? > > 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/
Re: Active-low behavior in gpiolib
On Fri, Jun 7, 2013 at 4:10 PM, Linus Walleij wrote: > Well it is designed as a sysfs-only thing according to the comment: > drivers/gpio/gpiolib.c:#define FLAG_ACTIVE_LOW 6 /* sysfs value > has active low */ > > So I think your actual question is whether it should also be > enabled for the kernel-internal interfaces. Yes, that's my question. > Currently we have things like this: > > /** > * struct mmci_platform_data - platform configuration for the MMCI > * (also known as PL180) block. > (...) > * @gpio_cd: read this GPIO pin to detect card insertion > * @cd_invert: true if the gpio_cd pin value is active low > (...) > int gpio_cd; > boolcd_invert; > > So the knowledge of whether a certain GPIO is active high or low > is spread out through drivers, and the API only drives the line in a > very explicit way. > > I am uncertain whether it is wise to move this into gpiolib for > in-kernel consumers, it is mainly a convention of where the > knowledge should sit. In the mentioned case, the flags will still > be needed because we need to have the information there to > set the flag toward the gpiolib API anyway. > > So the only thing gained is that gpiolib gets some knowledge > of how the pin is used. But what is the gain of that? Well, my problem is clearly highlighted by the example you mention, which is a very common usage pattern especially for DT-obtained GPIOs which can have this OF_GPIO_ACTIVE_LOW flag. E.g. we have a lot of this: gpio = of_get_named_gpio_flags(np, "foo-gpios", 0, &flags); active_low = flags & OF_GPIO_ACTIVE_LOW ? 1 : 0; ... state = (gpio_get_value(gpio) ? 1 : 0) ^ active_low; ... gpio_set_value(gpio, (value ? 1 : 0) ^ active_low; which could be simplified into this: gpio = of_get_named_gpiod_flags(np, "foo-gpios", 0); ... state = gpiod_get_value(gpio); ... gpiod_set_value(gpio, value); Board design makes it possible to turn any GPIO active low for any (good or bad) reason, thus the drivers, which interact with gpiolib, are more likely to want to set the GPIO logical value (taking the active low parameter into account) rather than its raw level. In the end, drivers that are not using an active_low flag are most likely doing so just because they never encountered such a situation. In practice, I suspect nearly all drivers want to be aware of the active-low property. Since gpiolib is already half-aware of this property, through the sysfs active_low node and the OF_GPIO_ACTIVE_LOW DT property, why not complete the circle and ease the life of driver writers? As Stephen wrote, an alternative set of functions to get/set the actual raw value of the line could be provided, but my understanding is that an overwhelming majority of GPIO users would benefit from having the active low property being handled transparently. 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/
Re: [patch v8 6/9] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task
On 06/10/2013 10:01 AM, Alex Shi wrote: > On 06/10/2013 09:49 AM, Gu Zheng wrote: >> On 06/07/2013 03:20 PM, Alex Shi wrote: >> They are the base values in load balance, update them with rq runnable load average, then the load balance will consider runnable load avg naturally. We also try to include the blocked_load_avg as cpu load in balancing, but that cause kbuild performance drop 6% on every Intel machine, and aim7/oltp drop on some of 4 CPU sockets machines. >> Hi Alex, >>Could you explain me why including the blocked_load_avg causes >> performance drop ? > > > Thanks for review! > > the 9th patch has few explanation. like, after the only task got into > sleep in a CPU, there is only blocked_load_avg left, it looks quite big > in short time. that, block it get tasks before sleep, drive task to > other cpu in periodic balance. So, it cause clear load imbalance. > Got it. Thanks very much for your explanation.:) Best regards, Gu -- 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 v8 6/9] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task
On 06/10/2013 09:49 AM, Gu Zheng wrote: > On 06/07/2013 03:20 PM, Alex Shi wrote: > >> > They are the base values in load balance, update them with rq runnable >> > load average, then the load balance will consider runnable load avg >> > naturally. >> > >> > We also try to include the blocked_load_avg as cpu load in balancing, >> > but that cause kbuild performance drop 6% on every Intel machine, and >> > aim7/oltp drop on some of 4 CPU sockets machines. > Hi Alex, >Could you explain me why including the blocked_load_avg causes performance > drop ? Thanks for review! the 9th patch has few explanation. like, after the only task got into sleep in a CPU, there is only blocked_load_avg left, it looks quite big in short time. that, block it get tasks before sleep, drive task to other cpu in periodic balance. So, it cause clear load imbalance. -- 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/
[PATCH RESEND] scsi: Introduce a help function local_time_seconds() to simplify the getting time stamp operation
There are four places convert system time in UTC to local time seconds as a
time stamp in scsi-subsystem,
so we introduce a help function local_time_seconds() to simplify these
operations.
Signed-off-by: Gu Zheng
---
drivers/scsi/3w-9xxx.c | 14 ++
drivers/scsi/3w-sas.c | 14 ++
include/scsi/scsi.h|9 +
3 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index 5e1e12c..44b3ea8 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -374,8 +374,6 @@ out:
/* This function will queue an event */
static void twa_aen_queue_event(TW_Device_Extension *tw_dev,
TW_Command_Apache_Header *header)
{
- u32 local_time;
- struct timeval time;
TW_Event *event;
unsigned short aen;
char host[16];
@@ -398,9 +396,7 @@ static void twa_aen_queue_event(TW_Device_Extension
*tw_dev, TW_Command_Apache_H
memset(event, 0, sizeof(TW_Event));
event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
- do_gettimeofday(&time);
- local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
- event->time_stamp_sec = local_time;
+ event->time_stamp_sec = local_time_seconds();
event->aen_code = aen;
event->retrieved = TW_AEN_NOT_RETRIEVED;
event->sequence_id = tw_dev->error_sequence_id;
@@ -479,11 +475,9 @@ out:
static void twa_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
{
u32 schedulertime;
- struct timeval utc;
TW_Command_Full *full_command_packet;
TW_Command *command_packet;
TW_Param_Apache *param;
- u32 local_time;
/* Fill out the command packet */
full_command_packet = tw_dev->command_packet_virt[request_id];
@@ -503,11 +497,7 @@ static void twa_aen_sync_time(TW_Device_Extension *tw_dev,
int request_id)
param->parameter_id = cpu_to_le16(0x3); /* SchedulerTime */
param->parameter_size_bytes = cpu_to_le16(4);
- /* Convert system time in UTC to local time seconds since last
- Sunday 12:00AM */
- do_gettimeofday(&utc);
- local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
- schedulertime = local_time - (3 * 86400);
+ schedulertime = local_time_seconds() - (3 * 86400);
schedulertime = cpu_to_le32(schedulertime % 604800);
memcpy(param->data, &schedulertime, sizeof(u32));
diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
index c845bdb..69f1d8a 100644
--- a/drivers/scsi/3w-sas.c
+++ b/drivers/scsi/3w-sas.c
@@ -236,8 +236,6 @@ out:
/* This function will queue an event */
static void twl_aen_queue_event(TW_Device_Extension *tw_dev,
TW_Command_Apache_Header *header)
{
- u32 local_time;
- struct timeval time;
TW_Event *event;
unsigned short aen;
char host[16];
@@ -256,9 +254,7 @@ static void twl_aen_queue_event(TW_Device_Extension
*tw_dev, TW_Command_Apache_H
memset(event, 0, sizeof(TW_Event));
event->severity = TW_SEV_OUT(header->status_block.severity__reserved);
- do_gettimeofday(&time);
- local_time = (u32)(time.tv_sec - (sys_tz.tz_minuteswest * 60));
- event->time_stamp_sec = local_time;
+ event->time_stamp_sec = local_time_seconds();
event->aen_code = aen;
event->retrieved = TW_AEN_NOT_RETRIEVED;
event->sequence_id = tw_dev->error_sequence_id;
@@ -444,11 +440,9 @@ out:
static void twl_aen_sync_time(TW_Device_Extension *tw_dev, int request_id)
{
u32 schedulertime;
- struct timeval utc;
TW_Command_Full *full_command_packet;
TW_Command *command_packet;
TW_Param_Apache *param;
- u32 local_time;
/* Fill out the command packet */
full_command_packet = tw_dev->command_packet_virt[request_id];
@@ -468,11 +462,7 @@ static void twl_aen_sync_time(TW_Device_Extension *tw_dev,
int request_id)
param->parameter_id = cpu_to_le16(0x3); /* SchedulerTime */
param->parameter_size_bytes = cpu_to_le16(4);
- /* Convert system time in UTC to local time seconds since last
- Sunday 12:00AM */
- do_gettimeofday(&utc);
- local_time = (u32)(utc.tv_sec - (sys_tz.tz_minuteswest * 60));
- schedulertime = local_time - (3 * 86400);
+ schedulertime = local_time_seconds() - (3 * 86400);
schedulertime = cpu_to_le32(schedulertime % 604800);
memcpy(param->data, &schedulertime, sizeof(u32));
diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
index 66216c1..f3377ca 100644
--- a/include/scsi/scsi.h
+++ b/include/scsi/scsi.h
@@ -574,4 +574,13 @@ static inline __u32 scsi_to_u32(__u8 *ptr)
return (ptr[0]<<24) + (ptr[1]<<16) + (ptr[2]<<8) + ptr[3];
}
+/*
+ * Convert system time in UTC to local time seconds.
+ */
+static inline u32 local_time_seconds(void)
+{
+ struct timeval utc;
+ do_gettimeofday(&ut
Re: [patch v8 3/9] sched: set initial value of runnable avg for new forked task
On 06/07/2013 03:20 PM, Alex Shi wrote:
> We need initialize the se.avg.{decay_count, load_avg_contrib} for a
> new forked task.
> Otherwise random values of above variables cause mess when do new task
> enqueue:
> enqueue_task_fair
> enqueue_entity
> enqueue_entity_load_avg
>
> 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().
>
> Signed-off-by: Alex Shi
Reviewed-by: Gu Zheng
> ---
> kernel/sched/core.c | 6 ++
> kernel/sched/fair.c | 23 +++
> kernel/sched/sched.h | 2 ++
> 3 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b9e7036..6f226c2 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1598,10 +1598,6 @@ static void __sched_fork(struct task_struct *p)
> p->se.vruntime = 0;
> INIT_LIST_HEAD(&p->se.group_node);
>
> -#ifdef CONFIG_SMP
> - p->se.avg.runnable_avg_period = 0;
> - p->se.avg.runnable_avg_sum = 0;
> -#endif
> #ifdef CONFIG_SCHEDSTATS
> memset(&p->se.statistics, 0, sizeof(p->se.statistics));
> #endif
> @@ -1745,6 +1741,8 @@ void wake_up_new_task(struct task_struct *p)
> set_task_cpu(p, select_task_rq(p, SD_BALANCE_FORK, 0));
> #endif
>
> + /* Give new task start runnable values */
> + set_task_runnable_avg(p);
> rq = __task_rq_lock(p);
> activate_task(rq, p, 0);
> p->on_rq = 1;
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index f404468..1fc30b9 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -680,6 +680,26 @@ static u64 sched_vslice(struct cfs_rq *cfs_rq, struct
> sched_entity *se)
> return calc_delta_fair(sched_slice(cfs_rq, se), se);
> }
>
> +#ifdef CONFIG_SMP
> +static inline void __update_task_entity_contrib(struct sched_entity *se);
> +
> +/* Give new task start runnable values to heavy its load in infant time */
> +void set_task_runnable_avg(struct task_struct *p)
> +{
> + u32 slice;
> +
> + p->se.avg.decay_count = 0;
> + slice = sched_slice(task_cfs_rq(p), &p->se) >> 10;
> + p->se.avg.runnable_avg_sum = slice;
> + p->se.avg.runnable_avg_period = slice;
> + __update_task_entity_contrib(&p->se);
> +}
> +#else
> +void set_task_runnable_avg(struct task_struct *p)
> +{
> +}
> +#endif
> +
> /*
> * Update the current task's runtime statistics. Skip current tasks that
> * are not in our scheduling class.
> @@ -1527,6 +1547,9 @@ static inline void enqueue_entity_load_avg(struct
> cfs_rq *cfs_rq,
>* We track migrations using entity decay_count <= 0, on a wake-up
>* migration we use a negative decay count to track the remote decays
>* accumulated while sleeping.
> + *
> + * When enqueue a new forked task, the se->avg.decay_count == 0, so
> + * we bypass update_entity_load_avg(), use avg.load_avg_contrib direct.
>*/
> if (unlikely(se->avg.decay_count <= 0)) {
> se->avg.last_runnable_update = rq_clock_task(rq_of(cfs_rq));
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 24b1503..8bc66c6 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1058,6 +1058,8 @@ extern void init_rt_bandwidth(struct rt_bandwidth
> *rt_b, u64 period, u64 runtime
>
> extern void update_idle_cpu_load(struct rq *this_rq);
>
> +extern void set_task_runnable_avg(struct task_struct *p);
> +
> #ifdef CONFIG_PARAVIRT
> static inline u64 steal_ticks(u64 steal)
> {
--
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 v8 6/9] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task
On 06/07/2013 03:20 PM, Alex Shi wrote:
> They are the base values in load balance, update them with rq runnable
> load average, then the load balance will consider runnable load avg
> naturally.
>
> We also try to include the blocked_load_avg as cpu load in balancing,
> but that cause kbuild performance drop 6% on every Intel machine, and
> aim7/oltp drop on some of 4 CPU sockets machines.
Hi Alex,
Could you explain me why including the blocked_load_avg causes performance
drop ?
Thanks,
Gu
>
> Signed-off-by: Alex Shi
Reviewed-by: Gu Zheng
> ---
> kernel/sched/fair.c | 5 +++--
> kernel/sched/proc.c | 17 +++--
> 2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 42c7be0..eadd2e7 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2962,7 +2962,7 @@ static void dequeue_task_fair(struct rq *rq, struct
> task_struct *p, int flags)
> /* Used instead of source_load when we know the type == 0 */
> static unsigned long weighted_cpuload(const int cpu)
> {
> - return cpu_rq(cpu)->load.weight;
> + return cpu_rq(cpu)->cfs.runnable_load_avg;
> }
>
> /*
> @@ -3007,9 +3007,10 @@ static unsigned long cpu_avg_load_per_task(int cpu)
> {
> struct rq *rq = cpu_rq(cpu);
> unsigned long nr_running = ACCESS_ONCE(rq->nr_running);
> + unsigned long load_avg = rq->cfs.runnable_load_avg;
>
> if (nr_running)
> - return rq->load.weight / nr_running;
> + return load_avg / nr_running;
>
> return 0;
> }
> diff --git a/kernel/sched/proc.c b/kernel/sched/proc.c
> index bb3a6a0..ce5cd48 100644
> --- a/kernel/sched/proc.c
> +++ b/kernel/sched/proc.c
> @@ -501,6 +501,18 @@ static void __update_cpu_load(struct rq *this_rq,
> unsigned long this_load,
> sched_avg_update(this_rq);
> }
>
> +#ifdef CONFIG_SMP
> +unsigned long get_rq_runnable_load(struct rq *rq)
> +{
> + return rq->cfs.runnable_load_avg;
> +}
> +#else
> +unsigned long get_rq_runnable_load(struct rq *rq)
> +{
> + return rq->load.weight;
> +}
> +#endif
> +
> #ifdef CONFIG_NO_HZ_COMMON
> /*
> * There is no sane way to deal with nohz on smp when using jiffies because
> the
> @@ -522,7 +534,7 @@ static void __update_cpu_load(struct rq *this_rq,
> unsigned long this_load,
> void update_idle_cpu_load(struct rq *this_rq)
> {
> unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
> - unsigned long load = this_rq->load.weight;
> + unsigned long load = get_rq_runnable_load(this_rq);
> unsigned long pending_updates;
>
> /*
> @@ -568,11 +580,12 @@ void update_cpu_load_nohz(void)
> */
> void update_cpu_load_active(struct rq *this_rq)
> {
> + unsigned long load = get_rq_runnable_load(this_rq);
> /*
>* See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
>*/
> this_rq->last_load_update_tick = jiffies;
> - __update_cpu_load(this_rq, this_rq->load.weight, 1);
> + __update_cpu_load(this_rq, load, 1);
>
> calc_load_account_active(this_rq);
> }
--
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 00/48] Add namespace support for audit
On 06/07/2013 06:47 AM, Serge Hallyn wrote: > Quoting Serge Hallyn (serge.hal...@ubuntu.com): >> Quoting Gao feng (gaof...@cn.fujitsu.com): >>> On 05/07/2013 10:20 AM, Gao feng wrote: This patchset try to add namespace support for audit. I choose to assign audit to the user namespace. Right now,there are six kinds of namespaces, such as net, mount, ipc, pid, uts and user. the first five namespaces have special usage. the audit isn't suitable to belong to these five namespaces, so the user namespace may be the best choice. Through I decide to make audit related resources per user namespace, but audit uses netlink to communicate between kernel space and user space, and the netlink is a private resource of per net namespace. So we need the capability to allow the netlink sockets to communicate with each other in the same user namespace even they are in different net namespace. [PATCH 2/48] does this job, it adds a new function "compare" for per netlink table to compare two sockets. it means the netlink protocols can has its own compare fuction, For other protocols, two netlink sockets are different if they belong to the different net namespace. For audit protocol, two sockets can be the same even they in different net namespace,we use user namespace not net namespace to make the decision. There is one point that some people may dislike,in [PATCH 1/48], the kernel side audit netlink socket is created only when we create the first netns for the userns, and this userns will hold the netns until we destroy this userns. The other patches just make the audit related resources per user namespace. This patchset is sent as an RFC,any comments are welcome. >> >> Hi, >> >> thanks for sending this. I think you need to ping the selinux folks >> for comment though. It appears to me that, after this patchset, the >> kernel with CONFIG_USER_NS=y could not be LSPP-compliant, because >> the selinux-generated audit messages do not always go to init_user_ns. >> >> Additionally, the only type of namespacing selinux wants is where it >> is enforced by policy compiler and installer using typenames - i.e. >> 'container1.user_t' vs 'user_t'. Selinux does not want user namespaces >> to affect selinux enforcement at all. (at least last I knew, several >> years ago at a mini-summit, I believe this was from Stephen Smalley). > > That sort of sounds like I'm distancing myself from that, which I > don't mean to do. I agree with the decison: MAC (selinux, apparmor > and smack) should not be confuddled by user namespaces. (posix caps > are, as always, a bit different). Thanks for your comments! Very useful information, it sounds reasonable. Let's just drop those patches. Thanks, Gao > >> I think it's good to have userspace-generated audit messages (i.e. >> auditctl -m 'hi there') sent to the same user namespace. But the >> selinux messages, near as I can tell, need to all go to init_user_ns. >> >> thanks, >> -serge >> ___ >> Containers mailing list >> contain...@lists.linux-foundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/containers > -- > 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 0/9] sched: use runnable load avg in balance
Ingo & Peter: How are you? I know you are very very busy since services for wide key kernel parts. So hope this email don't disturb you. :) PJT's runnable load was introduced into kernel from 3.8 kernel. But besides increase longer code path, it does nothing help now. This patch try to enable the runnable load into scheduler balance. Most of this patchset are bug fixing related except 6~8th which are direct service for introducing runnable load into balance. The patchset was talked in LKML from last Nov, adopted many suggestions from PTJ, MikeG, Morten, PeterZ etc. Also tested on x86 and arm platforms, both got positive feedback. With this patchset, CFS scheduler will has better and stabler performance on hackbench, sysbench, pgbench. etc benchmarks. You will like the performance number which mentioned in last emails. I appreciated for any further review and comments! Wish you all best! Alex On 06/07/2013 03:20 PM, Alex Shi wrote: > Peter&Ingo: > > v8: add a marco div64_ul and used it in task_h_load() > v7: rebasing on tip/sched/core tree. > > I tested on Intel core2, NHM, SNB, IVB, 2 and 4 sockets machines with > benchmark kbuild, aim7, dbench, tbench, hackbench, oltp, and netperf > loopback etc. > > On SNB EP 4 sockets machine, the hackbench increased about 50%, and > result become stable. on other machines, hackbench increased about > 2~10%. oltp increased about 30% in NHM EX box. netperf loopback also > increased on SNB EP 4 sockets box. > No clear changes on other benchmarks. > > Michael Wang gotten better performance on pgbench on his box with this > patchset. https://lkml.org/lkml/2013/5/16/82 > > And Morten tested previous version with better power consumption. > http://comments.gmane.org/gmane.linux.kernel/1463371 > > Changlong found ltp cgroup stress testing get faster on SNB EP > machine with the last patch. https://lkml.org/lkml/2013/5/23/65 > --- > 3.10-rc1 patch1-7 patch1-8 > duration=764 duration=754 duration=750 > duration=764 duration=754 duration=751 > duration=763 duration=755 duration=751 > > duration means the seconds of testing cost. > --- > > Jason also found java server load benefited on his 8 sockets machine > with last patch. https://lkml.org/lkml/2013/5/29/673 > --- > When using a 3.10-rc2 tip kernel with patches 1-8, there was about a 40% > improvement in performance of the workload compared to when using the > vanilla 3.10-rc2 tip kernel with no patches. When using a 3.10-rc2 tip > kernel with just patches 1-7, the performance improvement of the > workload over the vanilla 3.10-rc2 tip kernel was about 25%. > --- > > We also tried to include blocked load avg in balance. but find many > benchmark performance drop a lot! Seems accumulating current > blocked_load_avg into cpu load isn't a good idea. Because: > 1, The blocked_load_avg is decayed same as runnable load, sometime is far > bigger than runnable load, that drive tasks to other idle or slight > load cpu, than cause both performance and power issue. But if the > blocked load is decayed too fast, it lose its effect. > 2, Another issue of blocked load is that when waking up task, we can not > know blocked load proportion of the task on rq. So, the blocked load is > meaningless in wake affine decision. > > According to above problem, we can not figure out a right way now to use > blocked_load_avg in balance. > > Since using runnable load avg in balance brings much benefit on > performance and power. and this patch was reviewed for long time. > So seems it's time to let it be clobbered in some sub tree, like > tip or linux-next. Any comments? > > 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] scripts/setlocalversion on write-protected source tree
Hi, I just stumbled across another[0] issue when scripts/setlocalversion operates on a write-protected source tree. Back then[0] the source tree was on an read-only NFS share, so "test -w" was introduced before "git update-index" was run. This time, the source tree is on read/write NFS share, but the permissions are world-readable and only a specific user (or root) can write. Thus, "test -w ." returns "0" and then runs "git update-index", producing the following message (on a dirty tree): fatal: Unable to create '/usr/local/src/linux-git/.git/index.lock': Permission denied While it says "fatal", compilation continues just fine. The patch below adds yet another (clumsy) check before "git update-index", but I'm not sure if this is the right way to go. On a side note, I don't think a kernel compilation should alter the source tree (or the .git directory) in any way and I don't see how removing "git update-index" could do any harm. The Mercurial and SVN routines in scripts/setlocalversion don't have any tree-modifying commands, AFAICS. So, maybe the attached patch would be acceptable. Thoughts? Christian. [0] https://patchwork.kernel.org/patch/29718/ diff --git a/scripts/setlocalversion b/scripts/setlocalversion old mode 100755 new mode 100644 index 84b88f1..2560718 --- a/scripts/setlocalversion +++ b/scripts/setlocalversion @@ -72,7 +72,8 @@ scm_version() fi # Update index only on r/w media - [ -w . ] && git update-index --refresh --unmerged > /dev/null + [ -w . ] && touch .git/index.lock 2>/dev/null && rm -f .git/index.lock && \ + git update-index --refresh --unmerged > /dev/null # Check for uncommitted changes if git diff-index --name-only HEAD | grep -qv "^scripts/package"; then -- BOFH excuse #359: YOU HAVE AN I/O ERROR -> Incompetent Operator errordiff --git a/scripts/setlocalversion b/scripts/setlocalversion index 84b88f1..d105a44 100755 --- a/scripts/setlocalversion +++ b/scripts/setlocalversion @@ -71,9 +71,6 @@ scm_version() printf -- '-svn%s' "`git svn find-rev $head`" fi - # Update index only on r/w media - [ -w . ] && git update-index --refresh --unmerged > /dev/null - # Check for uncommitted changes if git diff-index --name-only HEAD | grep -qv "^scripts/package"; then printf '%s' -dirty
[RFC 05/10] irqdomain: Eliminate revmap type
The NOMAP irq_domain type is only used by a handful of interrupt
controllers and it unnecessarily complicates the code by adding special
cases on how to look up mappings and different revmap functions are used
for each type which need to validate the correct type is passed to it
before performing the reverse map. Eliminating the revmap_type and
making a single reverse mapping function simplifies the code. It also
shouldn't be any slower than having separate revmap functions because
the type of the revmap needed to be checked anyway.
The linear and tree revmap types were already merged in a previous
patch. This patch rolls the NOMAP or direct mapping behaviour into the
same domain code making is possible for an irq domain to do any mapping
type; linear, tree or direct; and that the mapping will be transparent
to the interrupt controller driver.
With this change, direct mappings will get stored in the linear or tree
mapping for consistency. Reverse mapping from the hwirq to virq will go
through the normal lookup process. However, any controller using a
direct mapping can take advantage of knowing that hwirq==virq for any
mapped interrupts skip doing a revmap lookup when handling IRQs.
Signed-off-by: Grant Likely
---
include/linux/irqdomain.h | 48 +
kernel/irq/generic-chip.c | 5 +
kernel/irq/irqdomain.c| 55 +++
3 files changed, 43 insertions(+), 65 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 1cbb741..51ef84a 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -73,50 +73,42 @@ struct irq_domain_chip_generic;
/**
* struct irq_domain - Hardware interrupt number translation object
* @link: Element in global irq_domain list.
- * @revmap_type: Method used for reverse mapping hwirq numbers to linux irq.
This
- * will be one of the IRQ_DOMAIN_MAP_* values.
+ * @name: Name of interrupt domain
* @ops: pointer to irq_domain methods
* @host_data: private data pointer for use by owner. Not touched by
irq_domain
* core code.
- * @irq_base: Start of irq_desc range assigned to the irq_domain. The creator
- *of the irq_domain is responsible for allocating the array of
- *irq_desc structures.
- * @nr_irq: Number of irqs managed by the irq domain
- * @hwirq_base: Starting number for hwirqs managed by the irq domain
- * @of_node: (optional) Pointer to device tree nodes associated with the
- * irq_domain. Used when decoding device tree interrupt specifiers.
+ *
+ * Optional elements
+ * @of_node: Pointer to device tree nodes associated with the irq_domain. Used
+ * when decoding device tree interrupt specifiers.
+ * @gc: Pointer to a list of generic chips. There is a helper function for
+ * setting up one or more generic chips for interrupt controllers
+ * drivers using the generic chip library which uses this pointer.
+ *
+ * Revmap data, used internally by irq_domain
+ * @revmap_direct_max_irq: The largest hwirq that can be set for controllers
that
+ * support direct mapping
+ * @revmap_size: Size of the linear map table @linear_revmap[]
+ * @revmap_tree: Radix map tree for hwirqs that don't fit in the linear map
+ * @linear_revmap: Linear table of hwirq->virq reverse mappings
*/
struct irq_domain {
struct list_head link;
const char *name;
-
- /* type of reverse mapping_technique */
- unsigned int revmap_type;
- struct {
- struct {
- unsigned int size;
- } linear;
- struct {
- unsigned int max_irq;
- } nomap;
- struct radix_tree_root tree;
- } revmap_data;
const struct irq_domain_ops *ops;
void *host_data;
- irq_hw_number_t inval_irq;
- /* Optional device node pointer */
+ /* Optional data */
struct device_node *of_node;
- /* Optional pointer to generic interrupt chips */
struct irq_domain_chip_generic *gc;
- /* Linear reverse map */
+ /* reverse map data. The linear map gets appended to the irq_domain */
+ unsigned int revmap_direct_max_irq;
+ unsigned int revmap_size;
+ struct radix_tree_root revmap_tree;
unsigned int linear_revmap[];
};
-#define IRQ_DOMAIN_MAP_NOMAP 1 /* no fast reverse mapping */
-#define IRQ_DOMAIN_MAP_LINEAR 2 /* linear map of interrupts */
-
#ifdef CONFIG_IRQ_DOMAIN
struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
unsigned int size,
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index ca98cc5..4b01106 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -270,10 +270,7 @@ int irq_alloc_domain_generic_chips(struct irq_domain *d,
int irqs_per_chip,
if (d->gc)
[RFC 04/10] irqdomain: merge linear and tree reverse mappings.
From: Grant Likely
Keeping them separate makes irq_domain more complex and adds a lot of
code (as proven by the diffstat). Merging them simplifies the whole
scheme. This change makes it so both the tree and linear methods can be
used by the same irq_domain instance. If the hwirq is less than the
->linear_size, then the linear map is used to reverse map the hwirq.
Otherwise the radix tree is used. The test for which map to use is no
more expensive that the existing code, so the performance of fast path
is preserved.
It also means that complex interrupt controllers can use both the
linear map and a tree in the same domain. This may be useful for an
interrupt controller with a base set of core irqs and a large number
of GPIOs which might be used as irqs. The linear map could cover the
core irqs, and the tree used for thas irqs. The linear map could
cover the core irqs, and the tree used for the gpios.
v2: Drop reorganization of revmap data
Signed-off-by: Grant Likely
Cc: Paul Mundt
Cc: Benjamin Herrenschmidt
Cc: Thomas Gleixner
Cc: Rob Herring
---
include/linux/irqdomain.h | 18
kernel/irq/irqdomain.c| 107 +-
2 files changed, 39 insertions(+), 86 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index e5e513c..1cbb741 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -75,7 +75,6 @@ struct irq_domain_chip_generic;
* @link: Element in global irq_domain list.
* @revmap_type: Method used for reverse mapping hwirq numbers to linux irq.
This
* will be one of the IRQ_DOMAIN_MAP_* values.
- * @revmap_data: Revmap method specific data.
* @ops: pointer to irq_domain methods
* @host_data: private data pointer for use by owner. Not touched by
irq_domain
* core code.
@@ -93,10 +92,9 @@ struct irq_domain {
/* type of reverse mapping_technique */
unsigned int revmap_type;
- union {
+ struct {
struct {
unsigned int size;
- unsigned int *revmap;
} linear;
struct {
unsigned int max_irq;
@@ -111,11 +109,13 @@ struct irq_domain {
struct device_node *of_node;
/* Optional pointer to generic interrupt chips */
struct irq_domain_chip_generic *gc;
+
+ /* Linear reverse map */
+ unsigned int linear_revmap[];
};
#define IRQ_DOMAIN_MAP_NOMAP 1 /* no fast reverse mapping */
#define IRQ_DOMAIN_MAP_LINEAR 2 /* linear map of interrupts */
-#define IRQ_DOMAIN_MAP_TREE 3 /* radix tree */
#ifdef CONFIG_IRQ_DOMAIN
struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
@@ -137,10 +137,6 @@ struct irq_domain *irq_domain_add_nomap(struct device_node
*of_node,
unsigned int max_irq,
const struct irq_domain_ops *ops,
void *host_data);
-struct irq_domain *irq_domain_add_tree(struct device_node *of_node,
-const struct irq_domain_ops *ops,
-void *host_data);
-
extern struct irq_domain *irq_find_host(struct device_node *node);
extern void irq_set_default_host(struct irq_domain *host);
@@ -152,6 +148,12 @@ static inline struct irq_domain *irq_domain_add_legacy_isa(
return irq_domain_add_legacy(of_node, NUM_ISA_INTERRUPTS, 0, 0, ops,
host_data);
}
+static inline struct irq_domain *irq_domain_add_tree(struct device_node
*of_node,
+const struct irq_domain_ops *ops,
+void *host_data)
+{
+ return irq_domain_add_linear(of_node, 0, ops, host_data);
+}
extern void irq_domain_remove(struct irq_domain *host);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index b1b5e67..5a1d8ec 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -34,22 +34,24 @@ static struct irq_domain *irq_default_domain;
* to IRQ domain, or NULL on failure.
*/
static struct irq_domain *irq_domain_alloc(struct device_node *of_node,
- unsigned int revmap_type,
+ unsigned int revmap_type, int size,
const struct irq_domain_ops *ops,
void *host_data)
{
struct irq_domain *domain;
- domain = kzalloc_node(sizeof(*domain), GFP_KERNEL,
- of_node_to_nid(of_node));
+ domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) * size),
+ GFP_KERNEL, of_node_to_nid(of_node));
if (WARN_ON(!domain))
return NULL;
/* Fill structure */
+ INIT_RADIX_TREE(&domain->revmap_data.tree, GFP
[RFC 02/10] irqdomain: Replace LEGACY mapping with LINEAR
The LEGACY mapping unnecessarily complicates the irqdomain code and
can easily be implemented with a linear mapping. By ripping it out
and replacing it with the LINEAR mapping the object size of
irqdomain.c shrinks by about 330 bytes (ARMv7) which offsets the
additional allocation required by the linear map. It also makes it
possible for current LEGACY map users to pre-allocate irq_descs for a
subset of the hwirqs and dynamically allocate the rest as needed.
Signed-off-by: Grant Likely
Cc: Paul Mundt
Cc: Benjamin Herrenschmidt
Cc: Thomas Gleixner
Cc: Rob Herring
---
include/linux/irqdomain.h | 7
kernel/irq/irqdomain.c| 84 ---
2 files changed, 6 insertions(+), 85 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index ba2c708..6f06241 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -95,11 +95,6 @@ struct irq_domain {
union {
struct {
unsigned int size;
- unsigned int first_irq;
- irq_hw_number_t first_hwirq;
- } legacy;
- struct {
- unsigned int size;
unsigned int *revmap;
} linear;
struct {
@@ -117,8 +112,6 @@ struct irq_domain {
struct irq_domain_chip_generic *gc;
};
-#define IRQ_DOMAIN_MAP_LEGACY 0 /* driver allocated fixed range of irqs.
-* ie. legacy 8259, gets irqs 1..15 */
#define IRQ_DOMAIN_MAP_NOMAP 1 /* no fast reverse mapping */
#define IRQ_DOMAIN_MAP_LINEAR 2 /* linear map of interrupts */
#define IRQ_DOMAIN_MAP_TREE 3 /* radix tree */
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 61d6d3c..1ac8cf4 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -82,13 +82,6 @@ void irq_domain_remove(struct irq_domain *domain)
mutex_lock(&irq_domain_mutex);
switch (domain->revmap_type) {
- case IRQ_DOMAIN_MAP_LEGACY:
- /*
-* Legacy domains don't manage their own irq_desc
-* allocations, we expect the caller to handle irq_desc
-* freeing on their own.
-*/
- break;
case IRQ_DOMAIN_MAP_TREE:
/*
* radix_tree_delete() takes care of destroying the root
@@ -122,17 +115,6 @@ void irq_domain_remove(struct irq_domain *domain)
}
EXPORT_SYMBOL_GPL(irq_domain_remove);
-static unsigned int irq_domain_legacy_revmap(struct irq_domain *domain,
-irq_hw_number_t hwirq)
-{
- irq_hw_number_t first_hwirq = domain->revmap_data.legacy.first_hwirq;
- int size = domain->revmap_data.legacy.size;
-
- if (WARN_ON(hwirq < first_hwirq || hwirq >= first_hwirq + size))
- return 0;
- return hwirq - first_hwirq + domain->revmap_data.legacy.first_irq;
-}
-
/**
* irq_domain_add_simple() - Allocate and register a simple irq_domain.
* @of_node: pointer to interrupt controller's device tree node.
@@ -213,57 +195,17 @@ struct irq_domain *irq_domain_add_legacy(struct
device_node *of_node,
void *host_data)
{
struct irq_domain *domain;
- unsigned int i;
- domain = irq_domain_alloc(of_node, IRQ_DOMAIN_MAP_LEGACY, ops,
host_data);
+ pr_debug("Setting up legacy domain virq[%i:%i] ==> hwirq[%i:%i]\n",
+first_irq, first_irq + size - 1,
+(int)first_hwirq, (int)first_hwirq + size -1);
+
+ domain = irq_domain_add_linear(of_node, first_hwirq + size, ops,
host_data);
if (!domain)
return NULL;
- domain->revmap_data.legacy.first_irq = first_irq;
- domain->revmap_data.legacy.first_hwirq = first_hwirq;
- domain->revmap_data.legacy.size = size;
-
- mutex_lock(&irq_domain_mutex);
- /* Verify that all the irqs are available */
- for (i = 0; i < size; i++) {
- int irq = first_irq + i;
- struct irq_data *irq_data = irq_get_irq_data(irq);
-
- if (WARN_ON(!irq_data || irq_data->domain)) {
- mutex_unlock(&irq_domain_mutex);
- irq_domain_free(domain);
- return NULL;
- }
- }
+ WARN_ON(irq_domain_associate_many(domain, first_irq, first_hwirq,
size));
- /* Claim all of the irqs before registering a legacy domain */
- for (i = 0; i < size; i++) {
- struct irq_data *irq_data = irq_get_irq_data(first_irq + i);
- irq_data->hwirq = first_hwirq + i;
- irq_data->domain = domain;
- }
- mutex_unlock(&irq_domain_mutex);
-
- for (i = 0; i < size; i++) {
- int irq = first_irq + i;
- int hwirq = first_hwirq + i;
-
- /* IRQ0 gets ignored
[RFC 07/10] irqdomain: Beef up debugfs output
This patch increases the amount of output produced by the
irq_domain_mapping debugfs file by first listing all of the registered
irq domains at the beginning of the output, and then by including all
mapped IRQs in the output, not just the active ones. It is very useful
when debugging irqdomain issues to be able to see the entire list of
mapped irqs, not just the ones that happen to be connected to devices.
Signed-off-by: Grant Likely
---
kernel/irq/irqdomain.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index e0db59e..280b804 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -596,12 +596,29 @@ static int virq_debug_show(struct seq_file *m, void
*private)
{
unsigned long flags;
struct irq_desc *desc;
- void *data;
+ struct irq_domain *domain;
+ struct radix_tree_iter iter;
+ void *data, **slot;
int i;
- seq_printf(m, "%-5s %-7s %-15s %-*s %s\n", "irq", "hwirq",
+ seq_printf(m, " %-16s %-6s %-10s %-10s %s\n",
+ "name", "mapped", "linear-max", "direct-max",
"devtree-node");
+ mutex_lock(&irq_domain_mutex);
+ list_for_each_entry(domain, &irq_domain_list, link) {
+ int count = 0;
+ radix_tree_for_each_slot(slot, &domain->revmap_tree, &iter, 0)
+ count++;
+ seq_printf(m, "%c%-16s %6u %10u %10u %s\n",
+ domain == irq_default_domain ? '*' : ' ',
domain->name,
+ domain->revmap_size + count, domain->revmap_size,
+ domain->revmap_direct_max_irq,
+ domain->of_node ? of_node_full_name(domain->of_node)
: "");
+ }
+ mutex_unlock(&irq_domain_mutex);
+
+ seq_printf(m, "%-5s %-7s %-15s %-*s %6s %-14s %s\n", "irq",
"hwirq",
"chip name", (int)(2 * sizeof(void *) + 2), "chip data",
- "domain name");
+ "active", "type", "domain");
for (i = 1; i < nr_irqs; i++) {
desc = irq_to_desc(i);
@@ -609,12 +626,15 @@ static int virq_debug_show(struct seq_file *m, void
*private)
continue;
raw_spin_lock_irqsave(&desc->lock, flags);
+ domain = desc->irq_data.domain;
- if (desc->action && desc->action->handler) {
+ if (domain) {
struct irq_chip *chip;
+ int hwirq = desc->irq_data.hwirq;
+ bool direct;
seq_printf(m, "%5d ", i);
- seq_printf(m, "0x%05lx ", desc->irq_data.hwirq);
+ seq_printf(m, "0x%05x ", hwirq);
chip = irq_desc_get_chip(desc);
seq_printf(m, "%-15s ", (chip && chip->name) ?
chip->name : "none");
@@ -622,6 +642,11 @@ static int virq_debug_show(struct seq_file *m, void
*private)
data = irq_desc_get_chip_data(desc);
seq_printf(m, data ? "0x%p " : " %p ", data);
+ seq_printf(m, " %c", (desc->action &&
desc->action->handler) ? '*' : ' ');
+ direct = (i == hwirq) && (i <
domain->revmap_direct_max_irq);
+ seq_printf(m, "%6s%-8s ",
+ (hwirq < domain->revmap_size) ? "LINEAR" :
"RADIX",
+ direct ? "(DIRECT)" : "");
seq_printf(m, "%s\n", desc->irq_data.domain->name);
}
--
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/
[RFC 06/10] irqdomain: Clean up aftermath of irq_domain refactoring
After refactoring the irqdomain code, there are a number of API
functions that are merely empty wrappers around core code. Drop those
wrappers out of the C file and replace them with static inlines in the
header.
Signed-off-by: Grant Likely
---
arch/powerpc/platforms/cell/beat_interrupt.c | 2 +-
arch/powerpc/platforms/powermac/smp.c| 2 +-
include/linux/irqdomain.h| 31 +--
kernel/irq/irqdomain.c | 127 ---
4 files changed, 62 insertions(+), 100 deletions(-)
diff --git a/arch/powerpc/platforms/cell/beat_interrupt.c
b/arch/powerpc/platforms/cell/beat_interrupt.c
index 8c6dc42..9e5dfbc 100644
--- a/arch/powerpc/platforms/cell/beat_interrupt.c
+++ b/arch/powerpc/platforms/cell/beat_interrupt.c
@@ -239,7 +239,7 @@ void __init beatic_init_IRQ(void)
ppc_md.get_irq = beatic_get_irq;
/* Allocate an irq host */
- beatic_host = irq_domain_add_nomap(NULL, 0, &beatic_pic_host_ops, NULL);
+ beatic_host = irq_domain_add_nomap(NULL, ~0, &beatic_pic_host_ops,
NULL);
BUG_ON(beatic_host == NULL);
irq_set_default_host(beatic_host);
}
diff --git a/arch/powerpc/platforms/powermac/smp.c
b/arch/powerpc/platforms/powermac/smp.c
index bdb738a..f921067 100644
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c
@@ -192,7 +192,7 @@ static int psurge_secondary_ipi_init(void)
{
int rc = -ENOMEM;
- psurge_host = irq_domain_add_nomap(NULL, 0, &psurge_host_ops, NULL);
+ psurge_host = irq_domain_add_nomap(NULL, ~0, &psurge_host_ops, NULL);
if (psurge_host)
psurge_secondary_virq = irq_create_direct_mapping(psurge_host);
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 51ef84a..fd4b26f 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -110,6 +110,10 @@ struct irq_domain {
};
#ifdef CONFIG_IRQ_DOMAIN
+struct irq_domain *__irq_domain_add(struct device_node *of_node,
+ int size, int direct_max,
+ const struct irq_domain_ops *ops,
+ void *host_data);
struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
unsigned int size,
unsigned int first_irq,
@@ -121,17 +125,30 @@ struct irq_domain *irq_domain_add_legacy(struct
device_node *of_node,
irq_hw_number_t first_hwirq,
const struct irq_domain_ops *ops,
void *host_data);
-struct irq_domain *irq_domain_add_linear(struct device_node *of_node,
+extern struct irq_domain *irq_find_host(struct device_node *node);
+extern void irq_set_default_host(struct irq_domain *host);
+
+/**
+ * irq_domain_add_linear() - Allocate and register a linear revmap irq_domain.
+ * @of_node: pointer to interrupt controller's device tree node.
+ * @size: Number of interrupts in the domain.
+ * @ops: map/unmap domain callbacks
+ * @host_data: Controller private data pointer
+ */
+static inline struct irq_domain *irq_domain_add_linear(struct device_node
*of_node,
unsigned int size,
const struct irq_domain_ops *ops,
-void *host_data);
-struct irq_domain *irq_domain_add_nomap(struct device_node *of_node,
+void *host_data)
+{
+ return __irq_domain_add(of_node, size, 0, ops, host_data);
+}
+static inline struct irq_domain *irq_domain_add_nomap(struct device_node
*of_node,
unsigned int max_irq,
const struct irq_domain_ops *ops,
-void *host_data);
-extern struct irq_domain *irq_find_host(struct device_node *node);
-extern void irq_set_default_host(struct irq_domain *host);
-
+void *host_data)
+{
+ return __irq_domain_add(of_node, 0, max_irq, ops, host_data);
+}
static inline struct irq_domain *irq_domain_add_legacy_isa(
struct device_node *of_node,
const struct irq_domain_ops *ops,
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index c38be78..e0db59e 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -23,8 +23,11 @@ static DEFINE_MUTEX(revmap_trees_mutex);
static struct irq_domain *irq_default_domain;
/**
- * irq_domain_alloc() - Allocate a new irq_domain data structure
+ * __irq_domain_add() - Allocate a new irq_domain data structure
* @of_node: optional device-tree node of the interrupt controller
+ * @size: Size of linear map; 0 for radix mapping only
+ * @direct_max: Maximum value of direct maps; Use ~0 for no li
[RFC 09/10] irqdomain: remove irq_domain_generate_simple()
Nobody calls it; remove the function
Signed-off-by: Grant Likely
---
include/linux/irqdomain.h | 8
kernel/irq/irqdomain.c| 15 ---
2 files changed, 23 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index f9e8e06..fe7c57d 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -205,14 +205,6 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d,
struct device_node *ctrlr,
const u32 *intspec, unsigned int intsize,
irq_hw_number_t *out_hwirq, unsigned int *out_type);
-#if defined(CONFIG_OF_IRQ)
-extern void irq_domain_generate_simple(const struct of_device_id *match,
- u64 phys_base, unsigned int irq_start);
-#else /* CONFIG_OF_IRQ */
-static inline void irq_domain_generate_simple(const struct of_device_id *match,
- u64 phys_base, unsigned int irq_start)
{ }
-#endif /* !CONFIG_OF_IRQ */
-
#else /* CONFIG_IRQ_DOMAIN */
static inline void irq_dispose_mapping(unsigned int virq) { }
#endif /* !CONFIG_IRQ_DOMAIN */
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 80e9249..e47b356 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -741,18 +741,3 @@ const struct irq_domain_ops irq_domain_simple_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
EXPORT_SYMBOL_GPL(irq_domain_simple_ops);
-
-#ifdef CONFIG_OF_IRQ
-void irq_domain_generate_simple(const struct of_device_id *match,
- u64 phys_base, unsigned int irq_start)
-{
- struct device_node *node;
- pr_debug("looking for phys_base=%llx, irq_start=%i\n",
- (unsigned long long) phys_base, (int) irq_start);
- node = of_find_matching_node_by_address(NULL, match, phys_base);
- if (node)
- irq_domain_add_legacy(node, 32, irq_start, 0,
- &irq_domain_simple_ops, NULL);
-}
-EXPORT_SYMBOL_GPL(irq_domain_generate_simple);
-#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/
[RFC 00/10] Refactor irqdomain
I've done a bunch of refactoring work on the irq_domain infrastructure. Some of these patches I've posted before, and some our brand new. The goal of this is to greatly simplify how irq_domains work. With this series, instead of there being multiple different types of irq domains, each with different mapping rules, instead there is now only one time of irq_domain that contains both kinds of map; the linear map for irqs below a certain value, and the radix tree for large & sparse irq controllers. As you can see from the following diffstat, the result is a fair bit less code. It should make it easier to understand irqdomains too. arch/powerpc/platforms/cell/beat_interrupt.c | 2 +- arch/powerpc/platforms/powermac/smp.c| 2 +- drivers/irqchip/Kconfig | 1 + drivers/irqchip/irq-versatile-fpga.c | 104 -- include/linux/irqdomain.h| 123 ++- kernel/irq/generic-chip.c| 6 +- kernel/irq/irqdomain.c | 555 -- 7 files changed, 282 insertions(+), 511 deletions(-) I've pushed this series out to my git server at the following branch: git://git.secretlab.ca/git/linux irqdomain/next It depends on the tip tree's irq/for-arm branch and also Linus' mainline (they need to be merged). The branch above includes both. I've tested this on ARM qemu models, but not much else. I'll test on real hardware before pushing out, but I would appreciate anybody doing additional testing, particularly on PowerPC and other non-ARM platforms. Cheers, 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/
[RFC 01/10] irqdomain: Relax failure path on setting up mappings
Commit 98aa468e, "irqdomain: Support for static IRQ mapping and
association" introduced an API for directly associating blocks of hwirqs
to linux irqs. However, if any irq in that block failed to map (say if
the mapping functions returns an error because the irq is already
mapped) then the whole thing will fail and roll back. This is probably
too aggressive since there are valid reasons why a mapping may fail.
ie. Firmware may have a particular IRQ marked as unusable.
This patch drops the error path out of irq_domain_associate(). If a
mapping fails, then it is simply skipped. There is no reason to fail the
entire allocation.
v2: Still output an information message on failed mappings and make sure
attempted mapping gets cleared out of the irq_data structure.
Signed-off-by: Grant Likely
Cc: Paul Mundt
Cc: Benjamin Herrenschmidt
Cc: Thomas Gleixner
---
kernel/irq/irqdomain.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 20b677d..61d6d3c 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -464,23 +464,15 @@ int irq_domain_associate_many(struct irq_domain *domain,
unsigned int irq_base,
/*
* If map() returns -EPERM, this interrupt is
protected
* by the firmware or some other service and
shall not
-* be mapped.
-*
-* Since on some platforms we blindly try to
map everything
-* we end up with a log full of backtraces.
-*
-* So instead, we silently fail on -EPERM, it
is the
-* responsibility of the PIC driver to display
a relevant
-* message if needed.
+* be mapped. Don't bother telling the user
about it.
*/
if (ret != -EPERM) {
- pr_err("irq-%i==>hwirq-0x%lx mapping
failed: %d\n",
- virq, hwirq, ret);
- WARN_ON(1);
+ pr_info("%s didn't like hwirq-0x%lx to
VIRQ%i mapping (rc=%d)\n",
+
of_node_full_name(domain->of_node), hwirq, virq, ret);
}
irq_data->domain = NULL;
irq_data->hwirq = 0;
- goto err_unmap;
+ continue;
}
}
--
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/
[RFC 08/10] irqdomain: Refactor irq_domain_associate_many()
Originally, irq_domain_associate_many() was designed to unwind the
mapped irqs on a failure of any individual association. However, that
proved to be a problem with certain IRQ controllers. Some of them only
support a subset of irqs, and will fail when attempting to map a
reserved IRQ. In those cases we want to map as many IRQs as possible, so
instead it is better for irq_domain_associate_many() to make a
best-effort attempt to map irqs, but not fail if any or all of them
don't succeed. If a caller really cares about how many irqs got
associated, then it should instead go back and check that all of the
irqs is cares about were mapped.
The original design open-coded the individual association code into the
body of irq_domain_associate_many(), but with no longer needing to
unwind associations, the code becomes simpler to split out
irq_domain_associate() to contain the bulk of the logic, and
irq_domain_associate_many() to be a simple loop wrapper.
This patch also adds a new error check to the associate path to make
sure it isn't called for an irq larger than the controller can handle,
and adds locking so that the irq_domain_mutex is held while setting up a
new association.
Signed-off-by: Grant Likely
---
include/linux/irqdomain.h | 22 +++---
kernel/irq/irqdomain.c| 185 +++---
2 files changed, 101 insertions(+), 106 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index fd4b26f..f9e8e06 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -103,6 +103,7 @@ struct irq_domain {
struct irq_domain_chip_generic *gc;
/* reverse map data. The linear map gets appended to the irq_domain */
+ irq_hw_number_t hwirq_max;
unsigned int revmap_direct_max_irq;
unsigned int revmap_size;
struct radix_tree_root revmap_tree;
@@ -110,8 +111,8 @@ struct irq_domain {
};
#ifdef CONFIG_IRQ_DOMAIN
-struct irq_domain *__irq_domain_add(struct device_node *of_node,
- int size, int direct_max,
+struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
+ irq_hw_number_t hwirq_max, int direct_max,
const struct irq_domain_ops *ops,
void *host_data);
struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
@@ -140,14 +141,14 @@ static inline struct irq_domain
*irq_domain_add_linear(struct device_node *of_no
const struct irq_domain_ops *ops,
void *host_data)
{
- return __irq_domain_add(of_node, size, 0, ops, host_data);
+ return __irq_domain_add(of_node, size, size, 0, ops, host_data);
}
static inline struct irq_domain *irq_domain_add_nomap(struct device_node
*of_node,
unsigned int max_irq,
const struct irq_domain_ops *ops,
void *host_data)
{
- return __irq_domain_add(of_node, 0, max_irq, ops, host_data);
+ return __irq_domain_add(of_node, 0, max_irq, max_irq, ops, host_data);
}
static inline struct irq_domain *irq_domain_add_legacy_isa(
struct device_node *of_node,
@@ -166,14 +167,11 @@ static inline struct irq_domain
*irq_domain_add_tree(struct device_node *of_node
extern void irq_domain_remove(struct irq_domain *host);
-extern int irq_domain_associate_many(struct irq_domain *domain,
-unsigned int irq_base,
-irq_hw_number_t hwirq_base, int count);
-static inline int irq_domain_associate(struct irq_domain *domain, unsigned int
irq,
- irq_hw_number_t hwirq)
-{
- return irq_domain_associate_many(domain, irq, hwirq, 1);
-}
+extern int irq_domain_associate(struct irq_domain *domain, unsigned int irq,
+ irq_hw_number_t hwirq);
+extern void irq_domain_associate_many(struct irq_domain *domain,
+ unsigned int irq_base,
+ irq_hw_number_t hwirq_base, int count);
extern unsigned int irq_create_mapping(struct irq_domain *host,
irq_hw_number_t hwirq);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 280b804..80e9249 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -35,8 +35,8 @@ static struct irq_domain *irq_default_domain;
* register allocated irq_domain with irq_domain_register(). Returns pointer
* to IRQ domain, or NULL on failure.
*/
-struct irq_domain *__irq_domain_add(struct device_node *of_node,
- int size, int direct_max,
+struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
+
[RFC 03/10] irqdomain: Add a name field
This patch adds a name field to the irq_domain structure to help mere
mortals understand the mappings between irq domains and virqs. It also
converts a number of places that have open-coded some kind of fudging
an irqdomain name to use the new field. This means a more consistent
display of names in irq domain log messages and debugfs output.
Signed-off-by: Grant Likely
---
include/linux/irqdomain.h | 1 +
kernel/irq/generic-chip.c | 1 +
kernel/irq/irqdomain.c| 19 ++-
3 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 6f06241..e5e513c 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -89,6 +89,7 @@ struct irq_domain_chip_generic;
*/
struct irq_domain {
struct list_head link;
+ const char *name;
/* type of reverse mapping_technique */
unsigned int revmap_type;
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index 95575d8..ca98cc5 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -305,6 +305,7 @@ int irq_alloc_domain_generic_chips(struct irq_domain *d,
int irqs_per_chip,
/* Calc pointer to the next generic chip */
tmp += sizeof(*gc) + num_ct * sizeof(struct irq_chip_type);
}
+ d->name = name;
return 0;
}
EXPORT_SYMBOL_GPL(irq_alloc_domain_generic_chips);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 1ac8cf4..b1b5e67 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -410,12 +410,15 @@ int irq_domain_associate_many(struct irq_domain *domain,
unsigned int irq_base,
*/
if (ret != -EPERM) {
pr_info("%s didn't like hwirq-0x%lx to
VIRQ%i mapping (rc=%d)\n",
-
of_node_full_name(domain->of_node), hwirq, virq, ret);
+ domain->name, hwirq, virq, ret);
}
irq_data->domain = NULL;
irq_data->hwirq = 0;
continue;
}
+ /* If not already assigned, give the domain the chip's
name */
+ if (!domain->name && irq_data->chip)
+ domain->name = irq_data->chip->name;
}
switch (domain->revmap_type) {
@@ -708,8 +711,6 @@ static int virq_debug_show(struct seq_file *m, void
*private)
{
unsigned long flags;
struct irq_desc *desc;
- const char *p;
- static const char none[] = "none";
void *data;
int i;
@@ -731,20 +732,12 @@ static int virq_debug_show(struct seq_file *m, void
*private)
seq_printf(m, "0x%05lx ", desc->irq_data.hwirq);
chip = irq_desc_get_chip(desc);
- if (chip && chip->name)
- p = chip->name;
- else
- p = none;
- seq_printf(m, "%-15s ", p);
+ seq_printf(m, "%-15s ", (chip && chip->name) ?
chip->name : "none");
data = irq_desc_get_chip_data(desc);
seq_printf(m, data ? "0x%p " : " %p ", data);
- if (desc->irq_data.domain)
- p =
of_node_full_name(desc->irq_data.domain->of_node);
- else
- p = none;
- seq_printf(m, "%s\n", p);
+ seq_printf(m, "%s\n", desc->irq_data.domain->name);
}
raw_spin_unlock_irqrestore(&desc->lock, flags);
--
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/
[RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
This is an RFC patch to convert the versatile FPGA irq controller driver
to use generic irq chip. It builds on the series that extends the
generic chip code to allow a linear irq domain to contain one or more
generic irq chips so that each interrupt controller doesn't need to hand
code the generic chip setup.
I've written this as a proof of concept to see if the new generic irq
code does what it needs to. I had to extend it slightly to properly
handle the valid mask used by the versatile FPGA driver.
Tested on QEMU, but not on real hardware.
Signed-off-by: Grant Likely
Cc: Russell King
Cc: Linus Walleij
Cc: Thomas Gleixner
---
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-versatile-fpga.c | 104 +--
2 files changed, 39 insertions(+), 66 deletions(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4a33351..8765502 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -14,6 +14,7 @@ config ARM_VIC
bool
select IRQ_DOMAIN
select MULTI_IRQ_HANDLER
+ select GENERIC_IRQ_CHIP
config ARM_VIC_NR
int
diff --git a/drivers/irqchip/irq-versatile-fpga.c
b/drivers/irqchip/irq-versatile-fpga.c
index 47a52ab..8c7097b 100644
--- a/drivers/irqchip/irq-versatile-fpga.c
+++ b/drivers/irqchip/irq-versatile-fpga.c
@@ -34,37 +34,18 @@
* @used_irqs: number of active IRQs on this controller
*/
struct fpga_irq_data {
- void __iomem *base;
- struct irq_chip chip;
- u32 valid;
struct irq_domain *domain;
- u8 used_irqs;
};
/* we cannot allocate memory when the controllers are initially registered */
static struct fpga_irq_data fpga_irq_devices[CONFIG_VERSATILE_FPGA_IRQ_NR];
static int fpga_irq_id;
-static void fpga_irq_mask(struct irq_data *d)
-{
- struct fpga_irq_data *f = irq_data_get_irq_chip_data(d);
- u32 mask = 1 << d->hwirq;
-
- writel(mask, f->base + IRQ_ENABLE_CLEAR);
-}
-
-static void fpga_irq_unmask(struct irq_data *d)
-{
- struct fpga_irq_data *f = irq_data_get_irq_chip_data(d);
- u32 mask = 1 << d->hwirq;
-
- writel(mask, f->base + IRQ_ENABLE_SET);
-}
-
static void fpga_irq_handle(unsigned int irq, struct irq_desc *desc)
{
- struct fpga_irq_data *f = irq_desc_get_handler_data(desc);
- u32 status = readl(f->base + IRQ_STATUS);
+ struct irq_domain *domain = irq_desc_get_handler_data(desc);
+ struct irq_chip_generic *gc = irq_get_domain_generic_chip(domain, 0);
+ u32 status = readl(gc->reg_base + IRQ_STATUS);
if (status == 0) {
do_bad_IRQ(irq, desc);
@@ -74,7 +55,7 @@ static void fpga_irq_handle(unsigned int irq, struct irq_desc
*desc)
do {
irq = ffs(status) - 1;
status &= ~(1 << irq);
- generic_handle_irq(irq_find_mapping(f->domain, irq));
+ generic_handle_irq(irq_find_mapping(domain, irq));
} while (status);
}
@@ -85,11 +66,12 @@ static void fpga_irq_handle(unsigned int irq, struct
irq_desc *desc)
*/
static int handle_one_fpga(struct fpga_irq_data *f, struct pt_regs *regs)
{
+ struct irq_chip_generic *gc = irq_get_domain_generic_chip(f->domain, 0);
int handled = 0;
int irq;
u32 status;
- while ((status = readl(f->base + IRQ_STATUS))) {
+ while ((status = readl(gc->reg_base + IRQ_STATUS))) {
irq = ffs(status) - 1;
handle_IRQ(irq_find_mapping(f->domain, irq), regs);
handled = 1;
@@ -112,63 +94,53 @@ asmlinkage void __exception_irq_entry
fpga_handle_irq(struct pt_regs *regs)
} while (handled);
}
-static int fpga_irqdomain_map(struct irq_domain *d, unsigned int irq,
- irq_hw_number_t hwirq)
-{
- struct fpga_irq_data *f = d->host_data;
-
- /* Skip invalid IRQs, only register handlers for the real ones */
- if (!(f->valid & BIT(hwirq)))
- return -EPERM;
- irq_set_chip_data(irq, f);
- irq_set_chip_and_handler(irq, &f->chip,
- handle_level_irq);
- set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
- return 0;
-}
-
-static struct irq_domain_ops fpga_irqdomain_ops = {
- .map = fpga_irqdomain_map,
- .xlate = irq_domain_xlate_onetwocell,
-};
-
void __init fpga_irq_init(void __iomem *base, const char *name, int irq_start,
int parent_irq, u32 valid, struct device_node *node)
{
+ struct irq_chip_generic *gc;
struct fpga_irq_data *f;
- int i;
+ int ret;
if (fpga_irq_id >= ARRAY_SIZE(fpga_irq_devices)) {
pr_err("%s: too few FPGA IRQ controllers, increase
CONFIG_VERSATILE_FPGA_IRQ_NR\n", __func__);
return;
}
f = &fpga_irq_devices[fpga_irq_id];
- f->base = base;
- f->chip.name = name;
- f->chip.irq_ack = fpga_irq_mask;
- f->chip.irq_mask = fpga_
Re: [PATCH RFC v2 2/3] ec: add ec space notifier
在 2013-06-06四的 12:59 +0200，Rafael J. Wysocki写道：
> On Thursday, June 06, 2013 09:40:34 AM liguang wrote:
> > add a notifier for anyone who are instresting in
> > ec space changing.
> >
> > Signed-off-by: liguang
>
> I'm not going to apply this anyway, but can you please explain what's the
> problem you're trying to solve here?
OK, currently it is for QEMU to do cpu online automatically after
hot-plug a cpu,
and maybe potentially for real platform's cpu
plug/unplug implementation.
with this notifier, we don't need any GPIOes,IO ports, and other
hardware cost if we do have an EC chip in board to trigger kernel's
cpu process for this.
Yep, you said you'll reject this anyway,
but I have to ask do this notifier offend
any rules of your development?
or some other reasons?
Thanks!
>
> > ---
> > drivers/acpi/ec.c| 32
> > include/linux/acpi.h |2 ++
> > 2 files changed, 34 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> > index edc0081..dee3417 100644
> > --- a/drivers/acpi/ec.c
> > +++ b/drivers/acpi/ec.c
> > @@ -124,6 +124,35 @@ static int EC_FLAGS_MSI; /* Out-of-spec MSI controller
> > */
> > static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */
> > static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT
> > scan */
> >
> > +/* notifier chain for who are intresting in ec space changing */
> > +static RAW_NOTIFIER_HEAD(ec_space_chain);
> > +
> > +int __ref register_ec_space_notifier(struct notifier_block *nb)
> > +{
> > +int ret;
> > +
> > +ret = raw_notifier_chain_register(&ec_space_chain, nb);
> > +
> > +return ret;
> > +}
> > +EXPORT_SYMBOL(register_ec_space_notifier);
> > +
> > +void __ref unregister_ec_space_notifier(struct notifier_block *nb)
> > +{
> > +
> > +raw_notifier_chain_unregister(&ec_space_chain, nb);
> > +}
> > +EXPORT_SYMBOL(unregister_ec_space_notifier);
> > +
> > +static int ec_space_notify(void *data)
> > +{
> > +int ret;
> > +
> > +ret = __raw_notifier_call_chain(&ec_space_chain, 0, data, -1, NULL);
> > +
> > + return notifier_to_errno(ret);
> > +}
> > +
> > /*
> > --
> > Transaction Management
> >
> > --
> > */
> > @@ -638,6 +667,9 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
> > wake_up(&ec->wait);
> > ec_check_sci(ec, acpi_ec_read_status(ec));
> > }
> > +
> > + ec_space_notify(data);
> > +
> > return ACPI_INTERRUPT_HANDLED | ACPI_REENABLE_GPE;
> > }
> >
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> > index 17b5b59..4fe2247 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -158,6 +158,8 @@ extern int ec_transaction(u8 command,
> >const u8 *wdata, unsigned wdata_len,
> >u8 *rdata, unsigned rdata_len);
> > extern acpi_handle ec_get_handle(void);
> > +extern int register_ec_space_notifier(struct notifier_block *nb);
> > +extern void unregister_ec_space_notifier(struct notifier_block *nb);
> >
> > #if defined(CONFIG_ACPI_WMI) || defined(CONFIG_ACPI_WMI_MODULE)
> >
> >
--
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: [f2fs-dev] [PATCH 1/4] f2fs: reorganize the f2fs_setattr() function.
Hello, Namjae
If using ACL, whenever i_mode is changed we should update acl_mode which
is written to xattr block, too. And vice versa.
Because update_inode() is called at any reason and anytime, so we should
sync both the moment xattr is written.
We don't hope that only i_mode is written to disk and xattr is not. So
f2fs_setattr is dirty.
And, below code has a bug. When error is occurred, inode->i_mode
shouldn't be changed. Please, check one more time, Namjae.
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index deefd25..29cd449 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -352,10 +352,8 @@ int f2fs_setattr(struct dentry *dentry, struct
iattr *attr)
if (attr->ia_valid & ATTR_MODE) {
err = f2fs_acl_chmod(inode);
- if (err || is_inode_flag_set(fi, FI_ACL_MODE)) {
- inode->i_mode = fi->i_acl_mode;
+ if (err || is_inode_flag_set(fi, FI_ACL_MODE))
clear_inode_flag(fi, FI_ACL_MODE);
- }
}
Thanks.
On 토, 2013-06-08 at 21:25 +0900, Namjae Jeon wrote:
> From: Namjae Jeon
>
> Remove the redundant code from this function and make it aligned with
> usages of latest generic vfs layer function e.g using the setattr_copy()
> instead of using the f2fs specific function.
>
> Also correct the condition for updating the size of file via
> truncate_setsize().
>
> Signed-off-by: Namjae Jeon
> Signed-off-by: Pankaj Kumar
> ---
> fs/f2fs/acl.c |5 +
> fs/f2fs/file.c | 47 +--
> 2 files changed, 6 insertions(+), 46 deletions(-)
>
> diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
> index 44abc2f..2d13f44 100644
> --- a/fs/f2fs/acl.c
> +++ b/fs/f2fs/acl.c
> @@ -17,9 +17,6 @@
> #include "xattr.h"
> #include "acl.h"
>
> -#define get_inode_mode(i)((is_inode_flag_set(F2FS_I(i), FI_ACL_MODE)) ? \
> - (F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
> -
> static inline size_t f2fs_acl_size(int count)
> {
> if (count <= 4) {
> @@ -299,7 +296,7 @@ int f2fs_acl_chmod(struct inode *inode)
> struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
> struct posix_acl *acl;
> int error;
> - umode_t mode = get_inode_mode(inode);
> + umode_t mode = inode->i_mode;
>
> if (!test_opt(sbi, POSIX_ACL))
> return 0;
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index deefd25..8dfc1da 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -300,63 +300,26 @@ static int f2fs_getattr(struct vfsmount *mnt,
> return 0;
> }
>
> -#ifdef CONFIG_F2FS_FS_POSIX_ACL
> -static void __setattr_copy(struct inode *inode, const struct iattr *attr)
> -{
> - struct f2fs_inode_info *fi = F2FS_I(inode);
> - unsigned int ia_valid = attr->ia_valid;
> -
> - if (ia_valid & ATTR_UID)
> - inode->i_uid = attr->ia_uid;
> - if (ia_valid & ATTR_GID)
> - inode->i_gid = attr->ia_gid;
> - if (ia_valid & ATTR_ATIME)
> - inode->i_atime = timespec_trunc(attr->ia_atime,
> - inode->i_sb->s_time_gran);
> - if (ia_valid & ATTR_MTIME)
> - inode->i_mtime = timespec_trunc(attr->ia_mtime,
> - inode->i_sb->s_time_gran);
> - if (ia_valid & ATTR_CTIME)
> - inode->i_ctime = timespec_trunc(attr->ia_ctime,
> - inode->i_sb->s_time_gran);
> - if (ia_valid & ATTR_MODE) {
> - umode_t mode = attr->ia_mode;
> -
> - if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
> - mode &= ~S_ISGID;
> - set_acl_inode(fi, mode);
> - }
> -}
> -#else
> -#define __setattr_copy setattr_copy
> -#endif
> -
> int f2fs_setattr(struct dentry *dentry, struct iattr *attr)
> {
> struct inode *inode = dentry->d_inode;
> - struct f2fs_inode_info *fi = F2FS_I(inode);
> int err;
>
> err = inode_change_ok(inode, attr);
> if (err)
> return err;
>
> - if ((attr->ia_valid & ATTR_SIZE) &&
> - attr->ia_size != i_size_read(inode)) {
> - truncate_setsize(inode, attr->ia_size);
> + if ((attr->ia_valid & ATTR_SIZE)) {
> + if (attr->ia_size != i_size_read(inode))
> + truncate_setsize(inode, attr->ia_size);
> f2fs_truncate(inode);
> f2fs_balance_fs(F2FS_SB(inode->i_sb));
> }
>
> - __setattr_copy(inode, attr);
> + setattr_copy(inode, attr);
>
> - if (attr->ia_valid & ATTR_MODE) {
> + if (attr->ia_valid & ATTR_MODE)
> err = f2fs_acl_chmod(inode);
> - if (err || is_inode_flag_set(fi, FI_ACL_MODE)) {
> - inode->i_mode = fi->i_acl_mode;
> - clear_inode_flag(fi, FI_ACL_MODE);
> - }
> - }
>
> mark_inode_dirty(inode);
> return er
Re: [PATCH RFC v2 0/3] add cpu physically hotplug driver
Hi, Rafael 在 2013-06-06四的 13:00 +0200，Rafael J. Wysocki写道： > On Thursday, June 06, 2013 09:40:32 AM liguang wrote: > > This patch-set try to support physically hot-plug/unplug > > a cpu automatically, that is: > > if you offline a cpu, it will automatically actually remove > > a cpu, and if you hot-plug a cpu, then it will online this > > cpu automatically. > > No and no. Hmm... are you saying cpu online/offline designed to distinguish with real cpu plug/unplug? but, what the actual usage of online/offline? forgive my foolish. > > Why do you need this? > e.g. for QEMU case, if hot-plug a cpu, we have to online a cpu manually if there's no user space support like udev to do it automatically. and also, I think maybe online/offline should be naturally integrated with real plug/unplug process of CPU. > > > > so, offline is just like eject, but eject attribute seems not > > available since recent kernel(can't figure out when), with > > this driver, if allowed, it will trigger a eject cpu process. > > and for automatically online, it was said there are objections, > > don't know the reason, so, send this patch-set boldly. > > > > of course, this approach is for QEMU 's hotplug cpu emulation > > only, but not limited, if someone like to explore ec space to > > implment cpu hot-plug/unplug for real platform please > > feel free to continue. > > > > Li Guang (3) > > drivers/platform/x86: add cpu physically hotplug driver > > ec: add ec space notifier > > cpu_physic_hotplug: register handler for ec space notifier > > > > drivers/acpi/ec.c | 32 > > > > drivers/platform/x86/Kconfig | 8 > > drivers/platform/x86/Makefile | 1 + > > drivers/platform/x86/cpu_physic_hotplug.c | 90 + > > include/linux/acpi.h | 2 ++ > > 5 files changed, 130 insertions(+), 3 deletions(-) > > create mode 100644 drivers/platform/x86/cpu_physic_hotplug.c -- 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 1/2] dma-buf: add importer private data to attachment
On 2013년 06월 07일 20:24, Maarten Lankhorst wrote:
> Op 07-06-13 04:32, 김승우 schreef:
>> Hello Maarten,
>>
>> On 2013년 06월 05일 22:23, Maarten Lankhorst wrote:
>>> Op 31-05-13 10:54, Seung-Woo Kim schreef:
dma-buf attachment has only exporter private data, but importer private
data
can be useful for importer especially to re-import the same dma-buf.
To use importer private data in attachment of the device, the function to
search attachment in the attachment list of dma-buf is also added.
Signed-off-by: Seung-Woo Kim
---
drivers/base/dma-buf.c | 31 +++
include/linux/dma-buf.h |4
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 08fe897..a1eaaf2 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -259,6 +259,37 @@ err_attach:
EXPORT_SYMBOL_GPL(dma_buf_attach);
/**
+ * dma_buf_get_attachment - Get attachment with the device from dma_buf's
+ * attachments list
+ * @dmabuf: [in]buffer to find device from.
+ * @dev: [in]device to be found.
+ *
+ * Returns struct dma_buf_attachment * attaching the device; may return
+ * negative error codes.
+ *
+ */
+struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
+struct device *dev)
+{
+ struct dma_buf_attachment *attach;
+
+ if (WARN_ON(!dmabuf || !dev))
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(&dmabuf->lock);
+ list_for_each_entry(attach, &dmabuf->attachments, node) {
+ if (attach->dev == dev) {
+ mutex_unlock(&dmabuf->lock);
+ return attach;
+ }
+ }
+ mutex_unlock(&dmabuf->lock);
+
+ return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
>>> NAK in any form..
>>>
>>> Spot the race condition between dma_buf_get_attachment and
>>> dma_buf_attach
>> Both dma_buf_get_attachment and dma_buf_attach has mutet with
>> dmabuf->lock, and dma_buf_get_attachment is used for get attachment from
>> same device before calling dma_buf_attach.
>
> hint: what happens if 2 threads do this:
>
> if (IS_ERR(attach = dma_buf_get_attachment(buf, dev)))
> attach = dma_buf_attach(buf, dev);
>
> There really is no correct usecase for this kind of thing, so please don't do
> it.
Ok, dma_buf_get_attachment can not prevent attachments from one device.
Anyway, do you think that importer side private data, not to allow
re-import one dma-buf to a device, has some advantage?
If that, I'll add some check_and_attach function, otherwise, I'll find
other way.
Thanks and Regards,
- Seung-Woo Kim
>
>> While, dma_buf_detach can removes attachment because it does not have
>> ref count. So importer should check ref count in its importer private
>> data before calling dma_buf_detach if the importer want to use
>> dma_buf_get_attachment.
>>
>> And dma_buf_get_attachment is for the importer, so exporter attach and
>> detach callback operation should not call it as like exporter detach
>> callback operation should not call dma_buf_attach if you mean this kind
>> of race.
>>
>> If you have other considerations here, please describe more specifically.
>>
>> Thanks and Best Regards,
>> - Seung-Woo Kim
>>
>>> ~Maarten
>>>
>>>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Seung-Woo Kim
Samsung Software R&D Center
--
--
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] pwm: devm: alloc correct pointer size
On Thu, Jun 06, 2013 at 10:43:41PM +0300, Andy Shevchenko wrote: > On Mon, Jun 3, 2013 at 11:27 PM, Wolfram Sang wrote: > > The allocated object should be the size of what the pointer is pointing > > to and not the size of the pointer itself. > > All devm_* functions in this module use **ptr as a parameter (except > allocation). > May be we first should understand why it so? Huh? **ptr is already created on the stack, but assigned the alloced memory. Later, the mem it points to is set to 'pwm' which is then added to devres. So, the alloced memory must be able to contain '*ptr' (or *pwm which would be more readable IMO, but other subsystems also stick to *ptr), no? signature.asc Description: Digital signature
[PATCH v2] mtd: orion_nand: Improve error handling in orion_nand_probe
This patch fixes some issues in the error handling and simplifies
the code by converting to devm* functions.
If the kzalloc call fails it is unnecessary to use the label no_res
and pass a NULL pointer to kfree. If the devm_kzalloc call fails on
line 110 we forget to call iounmap for the previous ioremap call.
The following changes are introduced:
- Convert to devm_kzalloc and remove calls to kfree.
- Convert to devm_ioremap_resource that adds a missing call to
*request_mem_region and remove calls to iounmap.
- The devm_ioremap_resource function checks the passed resource so
we can remove the NULL check after the platform_get_resource call.
Signed-off-by: Emil Goode
---
This patch is only build tested
v2: Fix change log typo and remove error messages for kzalloc calls
drivers/mtd/nand/orion_nand.c | 49 +
1 file changed, 15 insertions(+), 34 deletions(-)
diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index 8fbd002..76b9fba 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -85,35 +85,24 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
int ret = 0;
u32 val = 0;
- nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info),
GFP_KERNEL);
- if (!nc) {
- printk(KERN_ERR "orion_nand: failed to allocate device
structure.\n");
- ret = -ENOMEM;
- goto no_res;
- }
+ nc = devm_kzalloc(&pdev->dev, sizeof(struct nand_chip) +
+ sizeof(struct mtd_info), GFP_KERNEL);
+ if (!nc)
+ return -ENOMEM;
+
mtd = (struct mtd_info *)(nc + 1);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- ret = -ENODEV;
- goto no_res;
- }
-
- io_base = ioremap(res->start, resource_size(res));
- if (!io_base) {
- printk(KERN_ERR "orion_nand: ioremap failed\n");
- ret = -EIO;
- goto no_res;
- }
+ io_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(io_base))
+ return PTR_ERR(io_base);
if (pdev->dev.of_node) {
board = devm_kzalloc(&pdev->dev, sizeof(struct orion_nand_data),
- GFP_KERNEL);
- if (!board) {
- printk(KERN_ERR "orion_nand: failed to allocate board
structure.\n");
- ret = -ENOMEM;
- goto no_res;
- }
+GFP_KERNEL);
+ if (!board)
+ return -ENOMEM;
+
if (!of_property_read_u32(pdev->dev.of_node, "cle", &val))
board->cle = (u8)val;
else
@@ -167,7 +156,7 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
if (nand_scan(mtd, 1)) {
ret = -ENXIO;
- goto no_dev;
+ goto disable_clk;
}
mtd->name = "orion_nand";
@@ -176,20 +165,17 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
board->parts, board->nr_parts);
if (ret) {
nand_release(mtd);
- goto no_dev;
+ goto disable_clk;
}
return 0;
-no_dev:
+disable_clk:
if (!IS_ERR(clk)) {
clk_disable_unprepare(clk);
clk_put(clk);
}
platform_set_drvdata(pdev, NULL);
- iounmap(io_base);
-no_res:
- kfree(nc);
return ret;
}
@@ -197,15 +183,10 @@ no_res:
static int orion_nand_remove(struct platform_device *pdev)
{
struct mtd_info *mtd = platform_get_drvdata(pdev);
- struct nand_chip *nc = mtd->priv;
struct clk *clk;
nand_release(mtd);
- iounmap(nc->IO_ADDR_W);
-
- kfree(nc);
-
clk = clk_get(&pdev->dev, NULL);
if (!IS_ERR(clk)) {
clk_disable_unprepare(clk);
--
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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Sun, 9 Jun 2013, David Daney wrote: > > How different MIPS SMP systems are? > > o Old SGI heavy metal (several different system architectures). > > o Cavium OCTEON SMP SoCs. > > o Broadcom (several flavors) SoCs > > o Loongson o Old DEC hardware (DECsystem 58x0, R3000-based). o Malta-based MIPS Technologies CMP solutions (1004K, 1074K, interAptiv). Maciej -- 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: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sun, Jun 9, 2013 at 11:31 PM, Russell King - ARM Linux wrote: > On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote: >> this is all a rather round-about way to say that for those people who >> heard and are thinking of heeding russell's call to "be silent and to >> ignore me" > > Okay, so you've just misrepresented me in the above comment. I never > said anything of the sort. The closest that I've come to a comment like > that is asking you to stop wasting people's time. close enough. > So, given your displayed inability to properly convey what people have > said to you in a discussion in your own replies, is there *any* reason > that anyone should trust you to communicate their position to any other > third party? trust is always something that has to be given, russell. respect is earned, but trust is given. many make the mistake of believing that trust is earned [people who seek to defeat others as "enemies" know this and exploit it to devastating effect]. so i can't answer your question directly, but consider this: the people that i work with have known me for a long time. they know i'm a bit of a live wire (you saw that wookey called me "crazy luke") and they often go as completely spare at some of the spanners i throw in the works just as everyone else does. it's *they* who will be doing all the talking, and i will be advising them in the background over the next week so that *technically* they're prepped. everyone has a different role to play here. /peace l. -- 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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On 06/09/2013 12:31 AM, Gleb Natapov wrote: On Fri, Jun 07, 2013 at 04:15:00PM -0700, David Daney wrote: I should also add that I will shortly send patches for the kvm tool required to drive this VM as well as a small set of patches that create a para-virtualized MIPS/Linux guest kernel. The idea is that because there is no standard SMP linux system, we create a standard para-virtualized system that uses a handful of hypercalls, but mostly just uses virtio devices. It has no emulated real hardware (no 8250 UART, no emulated legacy anything...) Virtualization is useful for running legacy code. Why dismiss support for non pv guests so easily? Just because we create standard PV system devices, doesn't preclude emulating real hardware. In fact Sanjay Lal's work includes QEMU support for doing just this for a MIPS malta board. I just wanted a very simple system I could implement with the kvm tool in a couple of days, so that is what I initially did. The problem is that almost nobody has real malta boards, they are really only of interest because QEMU implements a virtual malta board. Personally, I see the most interesting us cases of MIPS KVM being a deployment platform for new services, so legacy support is not so important to me. That doesn't mean that other people wouldn't want some sort of legacy support. The problem with 'legacy' on MIPS is that there are hundreds of legacies to choose from (Old SGI and DEC hardware, various network hardware from many different vendors, etc.). Which would you choose? How different MIPS SMP systems are? o Old SGI heavy metal (several different system architectures). o Cavium OCTEON SMP SoCs. o Broadcom (several flavors) SoCs o Loongson Come to think of it, Emulating SGI hardware might be an interesting case. There may be old IRIX systems and applications that could be running low on real hardware. Some of those systems take up a whole room and draw a lot of power. They might run faster and at much lower power consumption on a modern 48-Way SMP SoC based system. What about running non pv UP systems? See above. I think this is what Sanjay Lal is doing. David Daney On 06/07/2013 04:03 PM, David Daney wrote: From: David Daney These patches take a somewhat different approach to MIPS virtualization via the MIPS-VZ extensions than the patches previously sent by Sanjay Lal. Several facts about the code: o Existing exception handlers are modified to hook in to KVM instead of intercepting all exceptions via the EBase register, and then chaining to real exception handlers. o Able to boot 64-bit SMP guests that use the FPU (I have booted 4-way SMP 64-bit MIPS/Linux). o Additional overhead on every exception even when *no* vCPU is running. o Lower interrupt overhead, than the EBase interception method, when vCPU *is* running. o This code is somewhat smaller than the existing trap/emulate implementation (about 2100 lines vs. about 5300 lines) o Currently probably only usable on the OCTEON III CPU model, as some MIPS-VZ implementation-defined behaviors were assumed to have the OCTEON III behavior. Note: I think Ralf already has the 17/31 (MIPS: Quit exposing Kconfig symbols in uapi headers.) queued, but I also include it here. David Daney (31): MIPS: Move allocate_kscratch to cpu-probe.c and make it public. MIPS: Save and restore K0/K1 when CONFIG_KVM_MIPSVZ mips/kvm: Fix 32-bitisms in kvm_locore.S mips/kvm: Add casts to avoid pointer width mismatch build failures. mips/kvm: Use generic cache flushing functions. mips/kvm: Rename kvm_vcpu_arch.pc to kvm_vcpu_arch.epc mips/kvm: Rename VCPU_registername to KVM_VCPU_ARCH_registername mips/kvm: Fix code formatting in arch/mips/kvm/kvm_locore.S mips/kvm: Factor trap-and-emulate support into a pluggable implementation. mips/kvm: Implement ioctls to get and set FPU registers. MIPS: Rearrange branch.c so it can be used by kvm code. MIPS: Add instruction format information for WAIT, MTC0, MFC0, et al. mips/kvm: Add accessors for MIPS VZ registers. mips/kvm: Add thread_info flag to indicate operation in MIPS VZ Guest Mode. mips/kvm: Exception handling to leave and reenter guest mode. mips/kvm: Add exception handler for MIPSVZ Guest exceptions. MIPS: Quit exposing Kconfig symbols in uapi headers. mips/kvm: Add pt_regs slots for BadInstr and BadInstrP mips/kvm: Add host definitions for MIPS VZ based host. mips/kvm: Hook into TLB fault handlers. mips/kvm: Allow set_except_vector() to be used from MIPSVZ code. mips/kvm: Split get_new_mmu_context into two parts. mips/kvm: Hook into CP unusable exception handler. mips/kvm: Add thread_struct fields used by MIPSVZ hosts. mips/kvm: Add some asm-offsets constants used by MIPSVZ. mips/kvm: Split up Kconfig and Makefile definitions in preperation for MIPSVZ. mips/kvm: Gate the use of kvm_local_flush_tlb_all() by KVM_MIPSTE
Block layer / MMC: Order of segments in SG-list
Hi, So I tried dumping addresses of an SG list in omap_hsmmc driver before it is passed to DMA. I found some interesting traces occasionally such as the below SG list of length 4. [6.758716] (0) length=4096, sg virt addr=c1318000, sg phy addr=81318000 [6.765863] (1) length=4096, sg virt addr=c1317000, sg phy addr=81317000 [6.773011] (2) length=4096, sg virt addr=c1316000, sg phy addr=81316000 [6.780087] (3) length=4096, sg virt addr=c1315000, sg phy addr=81315000 What is interesting is these chunks are really physically contiguous but in reverse order in the list. I think a smarter ordering can actually improve through put considerably and save precious DMA resources by not having to allocate slots for parts of contiguous chunk of physical memory. Is there any particular reason why this might be the case? I traced to find that the SG list is actually prepared by mmc_queue_map_sg -> blk_rq_map_sg Thanks in advance on any insight on the above. Regards, Joel -- 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] f2fs: sync dir->i_size with its block allocation
If new dentry block is allocated and its i_size is updated, we should update
its inode block together in order to sync i_size and its block allocation.
Otherwise, we can loose additional dentry block due to the unconsistent i_size.
Errorneous Scenario
---
In the recovery routine,
- recovery_dentry
| - __f2fs_add_link
| | - get_new_data_page
| | | - i_size_write(new_i_size)
| | | - mark_inode_dirty_sync(dir)
| | - update_parent_metadata
| | | - mark_inode_dirty(dir)
|
- write_checkpoint
- sync_dirty_dir_inodes
- filemap_flush(dentry_blocks)
- f2fs_write_data_page
- skip to write the last dentry block due to index < i_size
In the above flow, new_i_size is not updated to its inode block so that the
last dentry block will be lost accordingly.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 2 ++
fs/f2fs/dir.c | 9 -
fs/f2fs/f2fs.h | 1 +
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 93917e3..5b145fc 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -339,6 +339,8 @@ repeat:
if (new_i_size &&
i_size_read(inode) < ((index + 1) << PAGE_CACHE_SHIFT)) {
i_size_write(inode, ((index + 1) << PAGE_CACHE_SHIFT));
+ /* Only the directory inode sets new_i_size */
+ set_inode_flag(F2FS_I(inode), FI_UPDATE_DIR);
mark_inode_dirty_sync(inode);
}
return page;
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 81a1d6f..b72b274 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -370,22 +370,20 @@ error:
static void update_parent_metadata(struct inode *dir, struct inode *inode,
unsigned int current_depth)
{
- bool need_dir_update = false;
-
if (is_inode_flag_set(F2FS_I(inode), FI_NEW_INODE)) {
if (S_ISDIR(inode->i_mode)) {
inc_nlink(dir);
- need_dir_update = true;
+ set_inode_flag(F2FS_I(dir), FI_UPDATE_DIR);
}
clear_inode_flag(F2FS_I(inode), FI_NEW_INODE);
}
dir->i_mtime = dir->i_ctime = CURRENT_TIME;
if (F2FS_I(dir)->i_current_depth != current_depth) {
F2FS_I(dir)->i_current_depth = current_depth;
- need_dir_update = true;
+ set_inode_flag(F2FS_I(dir), FI_UPDATE_DIR);
}
- if (need_dir_update)
+ if (is_inode_flag_set(F2FS_I(inode), FI_UPDATE_DIR))
update_inode_page(dir);
else
mark_inode_dirty(dir);
@@ -502,6 +500,7 @@ add_dentry:
update_parent_metadata(dir, inode, current_depth);
fail:
+ clear_inode_flag(F2FS_I(dir), FI_UPDATE_DIR);
kunmap(dentry_page);
f2fs_put_page(dentry_page, 1);
return err;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index bfb97c9..091c688 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -859,6 +859,7 @@ enum {
FI_INC_LINK,/* need to increment i_nlink */
FI_ACL_MODE,/* indicate acl mode */
FI_NO_ALLOC,/* should not allocate any blocks */
+ FI_UPDATE_DIR, /* should update inode block for consistency */
FI_DELAY_IPUT, /* used for the recovery */
};
--
1.8.1.3.566.gaa39828
--
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] acpi: video: add function to support unregister backlight interface
From: "Lee, Chun-Yi"
There have some situation we unregister whole acpi/video driver by downstream
driver just want to remove backlight control interface of acpi/video. It caues
we lost other functions of acpi/video, e.g. transfer acpi event to input event.
So, this patch add a new function, find_video_unregister_backlight, it provide
the interface let downstream driver can tell acpi/video to unregister backlight
interface of all acpi video devices. Then we can keep functions of acpi/video
but only remove backlight support.
Reference: bko#35622
https://bugzilla.kernel.org/show_bug.cgi?id=35622
v2: Also unregister cooling devices.
Tested-by: Andrzej Krentosz
Cc: Zhang Rui
Cc: Len Brown
Cc: Rafael J. Wysocki
Cc: Carlos Corbacho
Cc: Matthew Garrett
Cc: Dmitry Torokhov
Cc: Corentin Chary
Cc: Aaron Lu
Cc: Thomas Renninger
Signed-off-by: Lee, Chun-Yi
---
drivers/acpi/video.c | 93
include/acpi/video.h | 2 ++
2 files changed, 89 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 5b32e15..da08ff7 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#define PREFIX "ACPI: "
@@ -86,6 +87,9 @@ module_param(allow_duplicates, bool, 0644);
static bool use_bios_initial_backlight = 1;
module_param(use_bios_initial_backlight, bool, 0644);
+static bool backlight_disable;
+module_param(backlight_disable, bool, 0644);
+
static int register_count = 0;
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
@@ -214,6 +218,8 @@ static const char device_decode[][30] = {
"UNKNOWN",
};
+static DEFINE_MUTEX(backlight_mutex);
+
static void acpi_video_device_notify(acpi_handle handle, u32 event, void
*data);
static void acpi_video_device_rebind(struct acpi_video_bus *video);
static void acpi_video_device_bind(struct acpi_video_bus *video,
@@ -882,7 +888,7 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
device->cap._DDC = 1;
}
- if (acpi_video_backlight_support()) {
+ if (acpi_video_backlight_support() || backlight_disable) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
@@ -1083,15 +1089,22 @@ acpi_video_bus_get_one_device(struct acpi_device
*device,
struct acpi_video_device *data;
struct acpi_video_device_attrib* attribute;
+ mutex_lock(&backlight_mutex);
+
status =
acpi_evaluate_integer(device->handle, "_ADR", NULL, &device_id);
/* Some device omits _ADR, we skip them instead of fail */
- if (ACPI_FAILURE(status))
- return 0;
+ if (ACPI_FAILURE(status)) {
+ status = 0;
+ goto out;
+ }
data = kzalloc(sizeof(struct acpi_video_device), GFP_KERNEL);
- if (!data)
- return -ENOMEM;
+ if (!data) {
+ status = -ENOMEM;
+ goto out;
+ }
+
strcpy(acpi_device_name(device), ACPI_VIDEO_DEVICE_NAME);
strcpy(acpi_device_class(device), ACPI_VIDEO_CLASS);
@@ -1156,6 +1169,8 @@ acpi_video_bus_get_one_device(struct acpi_device *device,
list_add_tail(&data->entry, &video->video_device_list);
mutex_unlock(&video->device_list_lock);
+out:
+ mutex_unlock(&backlight_mutex);
return status;
}
@@ -1336,7 +1351,7 @@ acpi_video_switch_brightness(struct acpi_video_device
*device, int event)
int result = -EINVAL;
/* no warning message if acpi_backlight=vendor is used */
- if (!acpi_video_backlight_support())
+ if (!acpi_video_backlight_support() || backlight_disable)
return 0;
if (!device->brightness)
@@ -1869,6 +1884,72 @@ static int __init intel_opregion_present(void)
return opregion;
}
+static acpi_status
+find_video_unregister_backlight(acpi_handle handle, u32 lvl, void *context,
+ void **rv)
+{
+ struct acpi_device *acpi_dev;
+ struct acpi_video_bus *video;
+ struct acpi_video_device *dev, *next;
+ acpi_status status = AE_OK;
+
+ mutex_lock(&backlight_mutex);
+
+ if (acpi_bus_get_device(handle, &acpi_dev))
+ goto out;
+
+ if (!acpi_match_device_ids(acpi_dev, video_device_ids)) {
+ video = acpi_driver_data(acpi_dev);
+
+ if (!video)
+ goto out;
+
+ acpi_video_bus_stop_devices(video);
+ mutex_lock(&video->device_list_lock);
+ list_for_each_entry_safe(dev, next, &video->video_device_list,
+ entry) {
+ if (dev->backlight) {
+ backlight_device_unregister(dev->backlight);
+
[PATCH 2/3] ACPICA: Add interface for getting latest OS version requested via _OSI
Drivers may need to make policy decisions based on the OS that the firmware
believes it's interacting with. ACPI firmware will make a series of _OSI
calls, starting from the oldest OS version they support and ending with the
most recent. Add a function to return the last successful call so that
drivers know what the firmware's expecting.
Based on a patch by Seth Forshee
Signed-off-by: Matthew Garrett
Cc: Seth Forshee
---
drivers/acpi/acpica/aclocal.h | 13 -
drivers/acpi/acpica/utxface.c | 19 +++
include/acpi/acpixf.h | 22 ++
3 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index d5bfbd3..8a2f532 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -948,19 +948,6 @@ struct acpi_bit_register_info {
/* Structs and definitions for _OSI support and I/O port validation */
-#define ACPI_OSI_WIN_2000 0x01
-#define ACPI_OSI_WIN_XP 0x02
-#define ACPI_OSI_WIN_XP_SP1 0x03
-#define ACPI_OSI_WINSRV_20030x04
-#define ACPI_OSI_WIN_XP_SP2 0x05
-#define ACPI_OSI_WINSRV_2003_SP10x06
-#define ACPI_OSI_WIN_VISTA 0x07
-#define ACPI_OSI_WINSRV_20080x08
-#define ACPI_OSI_WIN_VISTA_SP1 0x09
-#define ACPI_OSI_WIN_VISTA_SP2 0x0A
-#define ACPI_OSI_WIN_7 0x0B
-#define ACPI_OSI_WIN_8 0x0C
-
#define ACPI_ALWAYS_ILLEGAL 0x00
struct acpi_interface_info {
diff --git a/drivers/acpi/acpica/utxface.c b/drivers/acpi/acpica/utxface.c
index 6505774..c1638c3 100644
--- a/drivers/acpi/acpica/utxface.c
+++ b/drivers/acpi/acpica/utxface.c
@@ -389,6 +389,25 @@ ACPI_EXPORT_SYMBOL(acpi_install_interface_handler)
/*
*
+ * FUNCTION:acpi_osi_version
+ *
+ * PARAMETERS: None
+ *
+ * RETURN: Last OS version requested via _OSI
+ *
+ * DESCRIPTION: Returns the argument to the most recent _OSI query performed
+ * by the firmware
+ *
+ /
+u8 acpi_osi_version(void)
+{
+ return acpi_gbl_osi_data;
+}
+
+ACPI_EXPORT_SYMBOL(acpi_osi_version)
+
+/*
+ *
* FUNCTION:acpi_check_address_range
*
* PARAMETERS: space_id- Address space ID
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index 454881e..41d3ac1 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -82,6 +82,22 @@ extern u8 acpi_gbl_truncate_io_addresses;
extern u8 acpi_gbl_disable_auto_repair;
/*
+ * Values returned by acpi_osi_version()
+ */
+#define ACPI_OSI_WIN_2000 0x01
+#define ACPI_OSI_WIN_XP 0x02
+#define ACPI_OSI_WIN_XP_SP1 0x03
+#define ACPI_OSI_WINSRV_20030x04
+#define ACPI_OSI_WIN_XP_SP2 0x05
+#define ACPI_OSI_WINSRV_2003_SP10x06
+#define ACPI_OSI_WIN_VISTA 0x07
+#define ACPI_OSI_WINSRV_20080x08
+#define ACPI_OSI_WIN_VISTA_SP1 0x09
+#define ACPI_OSI_WIN_VISTA_SP2 0x0A
+#define ACPI_OSI_WIN_7 0x0B
+#define ACPI_OSI_WIN_8 0x0C
+
+/*
* Hardware-reduced prototypes. All interfaces that use these macros will
* be configured out of the ACPICA build if the ACPI_REDUCED_HARDWARE flag
* is set to TRUE.
@@ -307,6 +323,12 @@ acpi_status acpi_install_notify_handler(acpi_handle
device, u32 handler_type,
acpi_notify_handler handler,
void *context);
+#ifdef CONFIG_ACPI
+u8 acpi_osi_version(void);
+#else
+static inline u8 acpi_osi_version(void) { return 0; }
+#endif
+
acpi_status
acpi_remove_notify_handler(acpi_handle device,
u32 handler_type, acpi_notify_handler handler);
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8
Windows 8 leaves backlight control up to individual graphics drivers rather than making ACPI calls itself. There's plenty of evidence to suggest that the Intel driver for Windows doesn't use the ACPI interface, including the fact that it's broken on a bunch of machines when the OS claims to support Windows 8. The simplest thing to do appears to be to disable the ACPI backlight interface on these systems. Signed-off-by: Matthew Garrett --- drivers/gpu/drm/i915/i915_dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 3b315ba..23b6292 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) /* Must be done after probing outputs */ intel_opregion_init(dev); acpi_video_register(); + /* Don't use ACPI backlight functions on Windows 8 platforms */ + if (acpi_osi_version() >= ACPI_OSI_WIN_8) + acpi_video_backlight_unregister(); } if (IS_GEN5(dev)) -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. The first two patches in this series are picked from other patchesets aimed at solving similar problems. The last simply unregisters ACPI backlight control on Windows 8 systems when using an Intel GPU. Similar code could be added to other drivers, but I'm reluctant to do so without further investigation as to the behaviour of the vendor drivers under Windows. -- Matthew Garrett | mj...@srcf.ucam.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 v5 5/6] mips/kvm: Fix ABI by moving manipulation of CP0 registers to KVM_{G,S}ET_ONE_REG
On 06/08/2013 04:05 AM, Gleb Natapov wrote: On Wed, May 22, 2013 at 11:43:55AM -0700, David Daney wrote: From: David Daney Because not all 256 CP0 registers are ever implemented, we need a different method of manipulating them. Use the KVM_SET_ONE_REG/KVM_GET_ONE_REG mechanism. Now unused code and definitions are removed. Just noticed that KVM_REG_MIPS_ definitions are wrong. You need to define KVM_REG_MIPS in include/uapi/linux/kvm.h (please use 0x7000ULL as 0x6000ULL is reserved for ARM64) and define all KVM_REG_MIPS_ values as "KVM_REG_MIPS | value". Can you send a patch to do that ASAP? It will have to be tomorrow, I cannot test anything today. Thanks, David Daney -- 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 0/5] Enable f2fs support inline data
Hi, 2013-06-08 (토), 15:25 +0800, Huajun Li: > > Hi Jaegeuk, > Thanks for your suggestion. > On Wed, Jun 5, 2013 at 3:13 PM, Jaegeuk Kim > wrote: > Hi Haicheng, > 2013-06-04 (화), 14:01 +0800, Haicheng Li: > > Hi Jaegeuk & Namjae, > > > > Sure, we'll address your comments. And this version is RFC, > just wanna to > > make sure this feature is meaningful for f2fs project, and > there is no obvious > > mistake, e.g. missing some critical path. > IMO, it is worth to design and implement the inline feature > though, I'd > like to review the total design before looking at trivial > mistakes. > Since if the initial design is changed frequently, we need to > review > again and again. > > Agree. So let's understand/clarify your following proposal firstly. > So, we need to decide the overall inline design. > Currently we have to consider three data structures at a same > time for > the on-disk *inline* inode block structure, which are data, > dentry, and > xattr as well. > > IMO, we can give three inode flags: F2FS_INLINE_DATA, > F2FS_INLINE_DENT, > and F2FS_INLINE_XATTR. > > Small data and dentries can be inline. And xattr (such as XATTR_USER, > XATTR_TRUSTED, eg. ) can be inline too, right ? Right. > Or inline xattr is just working for inline data/dentries? > > < on-disk inode block > > - metadata > - if F2FS_INLINE_XATTR is set, > : use fixed 2*255 bytes to *cache* two xattrs for simplicity > > These 2 xattrs are working for the ones storing in xattr_nid block > before, or just providing info for inline data/dent ? I meant that we can store a fixed number of xattrs in the inode block like *inline* data. The number, 2, is just for example. If users give only one or two xattrs, we can store them in the inode block instead of using extra node blocks. If a system enables SELinux, it is able to set security labels to all the files according to the policy, so that we need to consider inline xattr seriously. > > > `- if F2FS_INLINE_DATA is set, >: use the remained space varied by F2FS_INLINE_XATTR. > `- if F2FS_INLINE_DENT is set, >: use variable number of dentries determined by > F2FS_INLINE_XATTR. > Do you mean inline dent depends on inline xattr, that is, we need a > dedicated xattr entry providing info for inline denteries, right? What I meant was the size of inline dentry space. We need to calculate the size for inline dentries on-the-fly as the F2FS_INLINE_XATTR is set or not. > > > `- Otherwise, use as pointers > > And then, we need to define how to deal with their > combinations. > > Operational conditions > -- > - use inline xattr or not, by checking other inline flags and > inline > data size. > - calculate inline data size and its offset according to the > use of > inline xattrs. > - the places of inline operaions wrt the lock consistency and > coverage > - Power-off-recovery routine should care about the on-disk > inode > structure. > - unset F2FS_INLINE_DATA if i_size = 0 > - unset F2FS_INLINE_XATTR if xattr entries = 0 > - unset F2FS_INLINE_DENT if dentries = 0 > > - what else? > - clear these flags after the inline data/dent is moved to normal data > block > - maybe we need store xattr_header while making xattr inline. It seems that there is nothing to store any header information. Thanks, > > Once we design the whole thing, we can make general functions > to deal > with them gracefully. > > > And if you team has some special opensource test suites used > in your daily > > f2fs test cycle, pls. kindly share the info with us, then we > can make sure our > > patchset can pass these cases before we send out next > version. > > > 1. xfstests for functionality > 2. fsstress for deadlock/consistency check > 3. power-off with fsstress > > Thanks, > > > BTW, test the kernel source tree or kernel build is a good > suggestion. thanks. > > > > On Tue, Jun 04, 2013 at 01:23:57PM +0900, Namjae Jeon wrote: > > > Hi. Huajun. > > > > > > I agree jaegeuk's opinion. > > > Additionally, It is better that you describe the effect in > change-log > > > when this feature is added to f2fs. > > > e.g. > > > 1. how much space is saved when storing > kernel-tree(small files) ? > > > 2. small files creation performanc
Re: power-efficient scheduling design
Hi Preeti, (trimming lots of text, hopefully to make it easier to follow) On Sun, Jun 09, 2013 at 04:42:18AM +0100, Preeti U Murthy wrote: > On 06/08/2013 07:32 PM, Rafael J. Wysocki wrote: > > On Saturday, June 08, 2013 12:28:04 PM Catalin Marinas wrote: > >> On Fri, Jun 07, 2013 at 07:08:47PM +0100, Preeti U Murthy wrote: > >>> Meanwhile the scheduler should ensure that the tasks are retained on > >>> that CPU,whose frequency is boosted and should not load balance it, so > >>> that they can get over quickly. This I think is what is missing. Again > >>> this comes down to the scheduler taking feedback from the CPU frequency > >>> governors which is not currently happening. > >> > >> Same loop again. The cpu load goes high because (a) there is more work, > >> possibly triggered by external events, and (b) the scheduler decided to > >> balance the CPUs in a certain way. As for cpuidle above, the scheduler > >> has direct influence on the cpufreq decisions. How would the scheduler > >> know which CPU not to balance against? Are CPUs in a cluster > >> synchronous? Is it better do let other CPU idle or more efficient to run > >> this cluster at half-speed? > >> > >> Let's say there is an increase in the load, does the scheduler wait > >> until cpufreq figures this out or tries to take the other CPUs out of > >> idle? Who's making this decision? That's currently a potentially > >> unstable loop. > > > > Yes, it is and I don't think we currently have good answers here. > > My answer to the above question is scheduler does not wait until cpufreq > figures it out. All that the scheduler cares about today is load > balancing. Spread the load and hope it finishes soon. There is a > possibility today that even before cpu frequency governor can boost the > frequency of cpu, the scheduler can spread the load. > > As for the second question it will wakeup idle cpus if it must to load > balance. That's exactly my point. Such behaviour can become unstable (it probably won't oscillate but it affects the power or performance). > It is a good question asked: "does the scheduler wait until cpufreq > figures it out." Currently the answer is no, it does not communicate > with cpu frequency at all (except through cpu power, but that is the > good part of the story, so I will not get there now). But maybe we > should change this. I think we can do so the following way. > > When can a scheduler talk to cpu frequency? It can do so under the below > circumstances: > > 1. Load is too high across the systems, all cpus are loaded, no chance > of load balancing. Therefore ask cpu frequency governor to step up > frequency to get improve performance. Too high or too low loads across the whole system are relatively simple scenarios: for the former boost the frequency (cpufreq can do this on its own, the scheduler has nowhere to balance anyway), for the latter pack small tasks (or other heuristics). But the bigger issue is where some CPUs are idle while others are running at a smaller frequency. With the current implementation it is even hard to get into this asymmetric state (some cluster loaded while the other in deep sleep) unless the load is low and you apply some small task packing patch. > 2. The scheduler finds out that if it has to load balance, it has to do > so on cpus which are in deep idle state( Currently this logic is not > present, but worth getting it in). It then decides to increase the > frequency of the already loaded cpus to improve performance. It calls > cpu freq governor. So you say that the scheduler decides to increase the frequency of the already loaded cpus to improve performance. Doesn't this mean that the scheduler takes on some of the responsibilities of cpufreq? You now add logic about boosting CPU frequency to the scheduler. What's even more problematic is that cpufreq has policies decided by the user (or pre-configured OS policies) but the scheduler is not aware of them. Let's say the user wants a more conservative cpufreq policy, how long should the scheduler wait for cpufreq to boost the frequency before waking idle CPUs? There are many questions like above. I'm not looking for specific answers but rather trying get a higher level clear view of the responsibilities of the three main factors contributing to power/performance: load balancing (scheduler), cpufreq and cpuidle. > 3. The scheduler finds out that if it has to load balance, it has to do > so on a different power domain which is idle currently(shallow/deep). It > thinks the better of it and calls cpu frequency governor to boost the > frequency of the cpus in the current domain. As for 2, the scheduler would make power decisions. Then why don't make a unified implementation? Or remove such decisions from the scheduler. > > The results of many measurements seem to indicate that it generally is > > better > > to do the work as quickly as possible and then go idle again, but there are > > costs associated with going back and forth fro
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here's the previous pull request with a couple of commits removed, this is purely regressions (though not all recent ones) or stable material. Cheers, Ben. The following changes since commit 1612e111e4e565422242727efb59499cce8738e4: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-06-06 18:09:05 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to b11ae95100f7061b39a15e5c1ecbf862464ac4b4: powerpc: Partial revert of "Context switch more PMU related SPRs" (2013-06-10 08:36:35 +1000) Gavin Shan (1): powerpc/eeh: Don't check RTAS token to get PE addr Kevin Hao (1): powerpc/pci: Check the bus address instead of resource address in pcibios_fixup_resources Michael Ellerman (2): powerpc/perf: Fix deadlock caused by calling printk() in PMU exception powerpc: Partial revert of "Context switch more PMU related SPRs" Michael Neuling (4): powerpc/power8: Fix oprofile and perf powerpc/pseries: Simplify denormalization handler powerpc/power8: Update denormalization handler powerpc/hw_breakpoints: Add DABRX cpu feature to fix 32-bit regression arch/powerpc/include/asm/cputable.h | 17 +++-- arch/powerpc/kernel/cputable.c |8 +-- arch/powerpc/kernel/entry_64.S | 28 arch/powerpc/kernel/exceptions-64s.S | 90 -- arch/powerpc/kernel/pci-common.c |4 +- arch/powerpc/kernel/process.c|3 +- arch/powerpc/perf/core-book3s.c |2 +- arch/powerpc/platforms/pseries/eeh_pseries.c | 12 ++-- 8 files changed, 51 insertions(+), 113 deletions(-) -- 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] mtd: orion_nand: Improve error handling in orion_nand_probe
Hello, Sorry for not responding earlier, I was away from my computer. Thanks for the review, I will send a second version that applies on top of Andy's patch and fix that typo in the change log. Best regards, Emil On Mon, Jun 10, 2013 at 12:15:22AM +0300, Andy Shevchenko wrote: > On Sun, Jun 9, 2013 at 11:57 PM, Dan Carpenter > wrote: > > On Sun, Jun 09, 2013 at 10:27:03PM +0300, Andy Shevchenko wrote: > >> On Sun, Jun 9, 2013 at 10:17 PM, Dan Carpenter > >> wrote: > >> > On Sun, Jun 09, 2013 at 08:15:20PM +0300, Andy Shevchenko wrote: > > >> >> What about another patch (that I guess should go first) that converts > >> >> printk to dev_* or pr_*? > >> > >> > Huh, what? Those are two totally unrelated things. Emil's patch is > >> > a bug fix. > >> > >> To be precise his patch is bugfix and cleanup at once. > >> My proposal is to add a clean up patch. > > > > The printk idea isn't a bad one, it's just totally unrelated to what > > the patch is doing. > > I don't agree with word 'totally'. It touches probe function and > shuffles code there. > > > You can't just randomly tell people to do a > > bunch of work for no reason. "Good bugfix, but before we apply it > > you have to mow my lawn." > > In this particular case I didn't think it's a big deal to fix 3 printfs. > Anyway, see patch in the next message. > > > -- > With Best Regards, > Andy Shevchenko -- 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: [git pull] Please pull powerpc.git merge branch
On Sun, 2013-06-09 at 14:33 -0700, Linus Torvalds wrote: > On Sun, Jun 9, 2013 at 12:56 AM, Benjamin Herrenschmidt > wrote: > > > > Here are a few more powerpc changes for 3.10. I've merged your > > tree in at some point (which I generally avoid) in order to get > > the compat network fixes as soon as possible. > > > > Mostly regressions, and stuff I judged could/should still go in at > > this stage. > > Not pulled, because your hamster smells of eldeberries. > > This is not just bugfixes. In fact, as far as I can tell, this > *introduces* bugs, with that "get_user()" in the exception path that > can apparently happen with irqs disabled and will thus potentially > result in new warnings that just make things unreadable. Ah right, brown paper bag for Anton and I :( I shouldn't have put that one in, it was a last minute bad decision after spending time tracking another stupid sigill in userspace (this time FSL CPUs not implementing some optional instructions that Fedora compiler seems configured to generate nowadays). > I'm f*cking tired of people having problems understanding "we're past > rc5". If it's not something you would call stable material, you > shouldn't send it to me. I've taken out that commit and the rename of the PMU interrupt (which while trivial probably wasn't important enough). Everything else is regressions/stable material. That does mean I rebased, but normally nobody bases on that merge branch so it should be fine. I'll send a new pull request. Cheers, Ben. > Linus > -- > 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: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote: > this is all a rather round-about way to say that for those people who > heard and are thinking of heeding russell's call to "be silent and to > ignore me" Okay, so you've just misrepresented me in the above comment. I never said anything of the sort. The closest that I've come to a comment like that is asking you to stop wasting people's time. So, given your displayed inability to properly convey what people have said to you in a discussion in your own replies, is there *any* reason that anyone should trust you to communicate their position to any other third party? In some ways, I'm *glad* that you've passed everything on verbatum, because it means that it's (hopefully) free from any misrepresentations such as the above. -- 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] ethernet/arc/arc_emac - Add new driver
Alexey Brodkin :
> On 06/08/2013 12:33 AM, Francois Romieu wrote:
> > Alexey Brodkin :
[...]
> As replied to Joe I just want to name people contributed in this driver.
> What is a appropriate way to do it?
A polite way could be to see with contributors if it's ok for them to
appear in the (c) section.
[...]
> > You may #define (FRST_MASK | LAST_MASK)
>
> This combo is used in only 2 places so is it worth to introduce another
> define? With these (FRST_MASK | LAST_MASK) I suppose reader will
> understand that these are 2 separate bits. But still it might be just my
> vision and if #define (FRST_MASK | LAST_MASK) looks better then I'll add
> it immediately.
Your call. The #define only needs to appear in or near the function.
[...]
> >> + if (!skbnew) {
> >> + netdev_err(net_dev, "Out of memory, "
> >> +"dropping packet\n");
> >
> > Rate limit or do nothing.
>
> Not clear what do you mean. Could you please clarify ?
net_ratelimit() will prevent a storm of log messages. Actually I would
avoid the message completely.
[...]
> >> +{
> >> + struct arc_emac_priv *priv = netdev_priv(net_dev);
> >> +
> >> + napi_disable(&priv->napi);
> >> + netif_stop_queue(net_dev);
> >> +
> >> + /* Disable interrupts */
> >> + EMAC_REG_CLR(priv->reg_base_addr, R_ENABLE,
> >> + TXINT_MASK | /* Tx interrupt */
> >> + RXINT_MASK | /* Rx interrupt */
> >> + ERR_MASK | /* Error interrupt */
> >> + TXCH_MASK);/* Transmit chaining error interrupt */
> >
> > Useless comments.
>
> Is it clear that TXCH means "Transmit chaining error interrupt"?
ERR_TXCHAIN_MASK ?
> Or those defines should just have comments where they are defined and
> later just use them with no comments?
s/should have/may have/
Otherwise, yes.
[...]
> >> +static int arc_mdio_read(struct mii_bus *bus, int phy_addr, int
> reg_num)
> >> +{
> >> + int error;
> >> + unsigned int value;
> >> + struct arc_mdio_priv *priv = bus->priv;
> >
> > Revert the xmas tree.
>
> Not clear what does it mean? Could you please calrify?
struct arc_mdio_priv *priv = bus->priv;
unsigned int value;
int error;
[...]
> >> +struct arc_mdio_priv {
> >> + struct mii_bus *bus;
> >> + struct device *dev;
> >> + void __iomem *reg_base_addr; /* MAC registers base address */
> >> +};
> >
> > Overengineered ?
>
> Why so? Not clear, sorry.
Most of this struct is shared with the device private one. I am not
sure that they need to be separated.
[...]
> >> +#define EMAC_REG_SET(reg_base_addr, reg, val)\
> >> + iowrite32((val), reg_base_addr + reg * sizeof(int))
> >> +
> >> +#define EMAC_REG_GET(reg_base_addr, reg) \
> >> + ioread32(reg_base_addr + reg * sizeof(int))
> >
> > May use real non-caps functions.
>
> Do you mean to use "io{read|write}32" directly without macro?
Add your own arc_{r/w} functions and use the device private struct
pointer as one of their parameters (whence no void * parameter).
[...]
> Thanks a lot for this deep analisys.
Not that deep:
- arc_emac_tx should disable tx queue as soon as the tx ring is exhausted
- you may consider moving work from the irq handler to napi poll.
--
Ueimor
--
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: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
ok, so the deadline's almost up but the discussions of the past two or so days have basically i think everything that needs to be said, and i'm extremely grateful to everyone who's contributed, privately and publicly, especially on such short notice. i've passed it over to my associates who will turn it into executive-level-speak: they understand that the situation is sensitive and have far more sense than i, which is good. i'm not sure if i should admit this, but there's some irony here that needs to be shared. i passed the collation of input from people - most of it verbatim - over to my associate who is used to dealing with executive-level people, and he said it couldn't possibly go as-is to them, not even to their assistant. when i asked why he said it was because it sounded too much like ordering them what decisions to make. if you've been following the shit-storm criticism that's been directed at me, and you've also noticed the bit about "most of it being verbatim" you have to appreciate the irony, really. so *sigh* we have to trust my associates and their experience in dealing with executives to work out a way to get the message across: i understand the things about public communication on-list(s) being important and so on and will fight to make sure those are got across in some clear form. the good news is that they *have* asked for advice and for a report, so there *is* an opening, it's not an unwelcome cold-call that we're engaging in, here. the last thing i'd like to say is this: free (libre) software developers and advocates are in an extremely... odd position of not really being fully or adequately monetarily compensated for the true level of service that they truly provide. i mention "service" because regardless of whether it's business or whether it's spare-time work just for the heck of it, we *are* acting as servants to a great many people, and in many cases those people who directly receive the benefit of our work - millions if not hundreds of people now that the linux kernel has made its way into android - have absolutely no way of being able to identify us and pay us for that service. i've never thought about giving up, but i *have* been thinking "what the hell am i doing wrong i.e. why have i only received direct donations of about $300 in *total* for all work done for the free software community since 1995 including samba and exchange 5.5 reverse-engineering and much more", up until recently when i learned some new insights that i thought it important to share, here. the insight is this: that there is a separate tally which is inviolate that keeps a *true* account of the level of service that we *truly* provide to others, of which monetary compensation is only a partial reflection [subtracted from that inviolate account, in some cases resulting in a DEBT in the inviolate and true account - which will need to be repaid - if the monetary compensation was too high or the service provided too poor]. so, for anyone reading this who has seen the shit-storm of the past few days and felt either embarrassed, or for any other reason has felt that they should quit working with free software, please don't: remember that the work itself is not necessarily the reward (although that's important too), nor that you're providing service to others and that that itself should be the reward, but that you *will* or *are* receiving true and accurate compensation: believe it, because it's true. this is all a rather round-about way to say that for those people who heard and are thinking of heeding russell's call to "be silent and to ignore me", to do so would be a significant dis-service both to yourself and to the hundreds of millions of end-users whom you are serving, if the long-term and immediate-term projects that i have embarked on are the success that i envision them to be. even with that having been said, it is, indeed, entirely your choice, that nobody but you should make. l. -- 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/
[Update][PATCH] ACPI / scan: Simplify ACPI driver probing
From: Rafael J. Wysocki
Subject: ACPI / scan: Simplify ACPI driver probing
There is no particular reason why acpi_bus_driver_init() needs to be
a separate function and its location with respect to its only caller,
acpi_device_probe(), makes the code a bit difficult to follow.
Besides, it doesn't really make sense to check if 'device' is not
NULL in acpi_bus_driver_init(), because we've already dereferenced
dev->driver in acpi_device_probe() at that point and, moreover,
'device' cannot be NULL then, because acpi_device_probe() is called
via really_probe() (which also sets dev->driver for that matter).
For these reasons, drop acpi_bus_driver_init() altogether and move
the remaining code from it directly into acpi_device_probe().
Signed-off-by: Rafael J. Wysocki
---
It's in the bleeding-edge branch of the linux-pm.git tree already.
Thanks,
Rafael
---
drivers/acpi/scan.c | 81 +---
1 file changed, 27 insertions(+), 54 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -933,32 +933,40 @@ static void acpi_device_remove_notify_ha
acpi_device_notify);
}
-static int acpi_bus_driver_init(struct acpi_device *, struct acpi_driver *);
-static int acpi_device_probe(struct device * dev)
+static int acpi_device_probe(struct device *dev)
{
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = to_acpi_driver(dev->driver);
int ret;
- ret = acpi_bus_driver_init(acpi_dev, acpi_drv);
- if (!ret) {
- if (acpi_drv->ops.notify) {
- ret = acpi_device_install_notify_handler(acpi_dev);
- if (ret) {
- if (acpi_drv->ops.remove)
- acpi_drv->ops.remove(acpi_dev);
- acpi_dev->driver = NULL;
- acpi_dev->driver_data = NULL;
- return ret;
- }
- }
+ if (!acpi_drv->ops.add)
+ return -ENOSYS;
+
+ ret = acpi_drv->ops.add(acpi_dev);
+ if (ret)
+ return ret;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "Found driver [%s] for device [%s]\n",
- acpi_drv->name, acpi_dev->pnp.bus_id));
- get_device(dev);
+ acpi_dev->driver = acpi_drv;
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ "Driver [%s] successfully bound to device [%s]\n",
+ acpi_drv->name, acpi_dev->pnp.bus_id));
+
+ if (acpi_drv->ops.notify) {
+ ret = acpi_device_install_notify_handler(acpi_dev);
+ if (ret) {
+ if (acpi_drv->ops.remove)
+ acpi_drv->ops.remove(acpi_dev);
+
+ acpi_dev->driver = NULL;
+ acpi_dev->driver_data = NULL;
+ return ret;
+ }
}
- return ret;
+
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found driver [%s] for device [%s]\n",
+ acpi_drv->name, acpi_dev->pnp.bus_id));
+ get_device(dev);
+ return 0;
}
static int acpi_device_remove(struct device * dev)
@@ -1114,41 +1122,6 @@ static void acpi_device_unregister(struc
Driver Management
--
*/
/**
- * acpi_bus_driver_init - add a device to a driver
- * @device: the device to add and initialize
- * @driver: driver for the device
- *
- * Used to initialize a device via its device driver. Called whenever a
- * driver is bound to a device. Invokes the driver's add() ops.
- */
-static int
-acpi_bus_driver_init(struct acpi_device *device, struct acpi_driver *driver)
-{
- int result = 0;
-
- if (!device || !driver)
- return -EINVAL;
-
- if (!driver->ops.add)
- return -ENOSYS;
-
- result = driver->ops.add(device);
- if (result)
- return result;
-
- device->driver = driver;
-
- /*
-* TBD - Configuration Management: Assign resources to device based
-* upon possible configuration and currently allocated resources.
-*/
-
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "Driver successfully bound to device\n"));
- return 0;
-}
-
-/**
* acpi_bus_register_driver - register a driver with the ACPI bus
* @driver: driver being registered
*
--
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/l
Re: [PATCH] ACPI / scan: Simplify ACPI driver probing
On Sunday, June 09, 2013 09:54:49 AM Aaron Lu wrote:
> On 06/09/2013 09:19 AM, Aaron Lu wrote:
> > On 06/09/2013 06:28 AM, Rafael J. Wysocki wrote:
> >> From: Rafael J. Wysocki
> >>
> >> There is no particular reason why acpi_bus_driver_init() needs to be
> >> a separate function and its location with respect to its only caller,
> >> acpi_device_probe(), makes the code a bit difficult to follow.
> >>
> >> Besides, it doesn't really make sense to check if 'device' is not
> >> NULL in acpi_bus_driver_init(), because we've already dereferenced
> >> dev->driver in acpi_device_probe() at that point, so that check has
> >> to be moved to acpi_device_probe() anyway.
> >>
> >> For these reasons, drop acpi_bus_driver_init() altogether and move
> >> the code from it directly into acpi_device_probe().
> >>
> >> Signed-off-by: Rafael J. Wysocki
> >> ---
> >>
> >> Should apply on top of the bleeding-edge branch of the linux-pm.git tree.
> >>
> >> Thanks,
> >> Rafael
> >>
> >> ---
> >> drivers/acpi/scan.c | 88
> >> +++-
> >> 1 file changed, 33 insertions(+), 55 deletions(-)
> >>
> >> Index: linux-pm/drivers/acpi/scan.c
> >> ===
> >> --- linux-pm.orig/drivers/acpi/scan.c
> >> +++ linux-pm/drivers/acpi/scan.c
> >> @@ -933,32 +933,45 @@ static void acpi_device_remove_notify_ha
> >> acpi_device_notify);
> >> }
> >>
> >> -static int acpi_bus_driver_init(struct acpi_device *, struct acpi_driver
> >> *);
> >> static int acpi_device_probe(struct device * dev)
> >> {
> >> - struct acpi_device *acpi_dev = to_acpi_device(dev);
> >> - struct acpi_driver *acpi_drv = to_acpi_driver(dev->driver);
> >> + struct acpi_device *acpi_dev;
> >> + struct acpi_driver *acpi_drv;
> >>int ret;
> >>
> >> - ret = acpi_bus_driver_init(acpi_dev, acpi_drv);
> >> - if (!ret) {
> >> - if (acpi_drv->ops.notify) {
> >> - ret = acpi_device_install_notify_handler(acpi_dev);
> >> - if (ret) {
> >> - if (acpi_drv->ops.remove)
> >> - acpi_drv->ops.remove(acpi_dev);
> >> - acpi_dev->driver = NULL;
> >> - acpi_dev->driver_data = NULL;
> >> - return ret;
> >> - }
> >> - }
> >> + if (!dev || !dev->driver)
> >> + return -EINVAL;
> >
> > Just out of curiosity, will dev ever be NULL in this function?
> > This function is called in really_probe by dev->bus->probe after
> > assigning dev->driver, so does the above check make any sense?
Well, it makes sense as such, but it's not useful. :-)
> BTW, I also tested the patch on a desktop and two laptops, no problems
> found. Feel free to add my tested-by tag.
I've modified the patch to remove that check and will post it again shortly.
Can you please give the new version a run?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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: ondemand: Change the calculation of target frequency
On Sunday, June 09, 2013 11:14:49 PM Borislav Petkov wrote: > On Sun, Jun 09, 2013 at 10:58:51PM +0200, Rafael J. Wysocki wrote: > > Can you possibly prepare a graph showing both the execution time > > and energy consumption for several different loop durations in your > > program (let's keep the 5000 us sleep for now), including multiples of > > sampling_rate as well as some other durations? > > Judgind by the times in C0 one of the cores spent, this small program > is single-threaded and is a microbenchmark. Yes, it is single-threaded, but that can be easily addressed by running multiple copies of it in parallel. :-) And yes, it is a microbenchmark, -> > And you know how optimizing against a microbenchmark doesn't really make > a lot of sense. -> but this is more about finding possible issues that about optimizing. I'm regarding this change as a substantial code simplification in the first place, both in terms of conceptual complexity and the actual code size, so I'd like to know what is *likely* to be affected by it (be it a microbenchmark or whatever). IOW, try to play a devil's advocate and find something that get's worse after applying these changes. If we can't find anything like that, there won't be any reason not to apply them. > I wonder if lmbench or aim9 or whatever would make more sense to try here... I think we'll need to try them too. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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: [git pull] Please pull powerpc.git merge branch
[ Is Jeremy the patchwork maintainer? If not, can people forward this to the real maintainer? ] On Sun, Jun 9, 2013 at 2:33 PM, Linus Torvalds wrote: > > This is not just bugfixes. In fact, as far as I can tell, this > *introduces* bugs, with that "get_user()" in the exception path that > can apparently happen with irqs disabled and will thus potentially > result in new warnings that just make things unreadable. Looking at that particular commit, I also notice that the commit itself is buggered in other ways too. It says: Date: Thu Jun 6 19:42:54 2013 + which surprised me due to the odd timezone, and it turns out it is pure and utter crap. Google finds the patch in patchwork, and "Show headers" there shows the expected timezone Date: Fri, 7 Jun 2013 15:42:54 +1000 and it turns out that apparently 'patchwork' is just making up random times, because when you download the email as an mbox, it will turn this into that corrupt and incorrect Date: Thu, 06 Jun 2013 19:42:54 - thing which is apparently how you got the wrong timestamp to begin with. That odd time doesn't even make any sense that I can see, because those two times have absolutely nothing in common afaik. Unless timezones work differently down under. It looks like some west-coast local time, but then it says "-" which is code for "I have no f*cking clue what I'm doing". Just to make things extra exciting, patchwork actually shows yet *another* date string when you just look at the patch in the web interface: Date June 7, 2013, 5:42 a.m. and that actually seems to be the *correct* UTC version of that original email date. I have no idea what that "Thu, 06 Jun 2013 19:42:54 -" date is, and where it came from. But it is utter shite. Can somebody please make sure that patchwork doesn't destroy timezone/date information? I'm assuming this has been going on forever, and I just noticed because I looked at that particular commit for other reasons, and went "Is Anton in Europe now?". Linus -- 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: [git pull] Exotic architecture fixes
Hi Linus,
On Sun, Jun 9, 2013 at 11:34 PM, Linus Torvalds
wrote:
> Which of these are critical and have to be in 3.10?
Most (I agree not all) of them are build fixes. Some (the h8300 symbol prefix
commit and the input one) are fixes for regressions introduced in
early v3.10-rc.
I'd like to have as many green builds as possible on
http://kisskb.ellerman.id.au/kisskb/matrix/,
to make it easier to catch regressions.
> And if the answer is not "all of them" (and I *guarantee* you that
> isn't the answer), why did you bother to send it to me after -rc5?
Because I promised to do so when I announced the creation of this branch,
around v3.10-rc2, cfr. https://lkml.org/lkml/2013/5/23/509.
Usually I just send patches like these to Andrew, who forwards them to you near
the last rc of a cycle. But this time I had accumulated so many of them I wanted
to offload him by creating my own branch and pull request.
Thanks for considering pulling anyway!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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]memblock: do double array and add merge directly path in memblock_insert_region
Hello,
On Mon, Jun 10, 2013 at 01:34:30AM +0800, Wang YanQing wrote:
> If we allow do merge directly when insertion, we can get better performance,
> this patch add support to do merge directly in memblock_insert_region.
Do you have actual case where performance in this patch is
problematic?
> -static void __init_memblock memblock_insert_region(struct memblock_type
> *type,
> +static int __init_memblock memblock_insert_region(struct memblock_type *type,
> int idx, phys_addr_t base,
> -phys_addr_t size, int nid)
> +phys_addr_t size, int nid,
> int merge)
bool merge and you need to update comment accordingly.
> {
> struct memblock_region *rgn = &type->regions[idx];
>
> - BUG_ON(type->cnt >= type->max);
> + if (merge && (base + size) == rgn->base &&
> + nid == memblock_get_region_node(rgn)) {
> + rgn->base = base;
> + rgn->size += size;
> + type->total_size += size;
> + return 0;
> + }
What if merge is from upside down or this connects two disjoint
regions?
> static int __init_memblock memblock_add_region(struct memblock_type *type,
> phys_addr_t base, phys_addr_t size, int nid)
...
> if (rbase > base) {
> - nr_new++;
> - if (insert)
> - memblock_insert_region(type, i++, base,
> -rbase - base, nid);
> + ret = memblock_insert_region(type, i++, base,
> + rbase - base, nid, 1);
> + if (ret) {
> + return ret;
> + }
Superflous { } and you need roll back what you've done upto this point
before returning. That's the reason why the function is structured
the way it is. If insertion fails due to array expansion failure, the
previous code doesn't change the memblock tables at all. Your new
code leaves it half-updated.
> @@ -498,8 +488,11 @@ static int __init_memblock memblock_isolate_range(struct
> memblock_type *type,
> rgn->base = base;
> rgn->size -= base - rbase;
> type->total_size -= base - rbase;
> - memblock_insert_region(type, i, rbase, base - rbase,
> -memblock_get_region_node(rgn));
> + ret = memblock_insert_region(type, i, rbase, base -
> rbase,
> + memblock_get_region_node(rgn), 0);
> + if (ret) {
> + return ret;
> + }
Ditto, you need to roll back on failure.
> @@ -533,6 +529,7 @@ static int __init_memblock __memblock_remove(struct
> memblock_type *type,
>
> for (i = end_rgn - 1; i >= start_rgn; i--)
> memblock_remove_region(type, i);
> + memblock_merge_regions(type);
Why is this 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 4/6] ARM: sunxi: dt: Add Allwinner A10s DTSI
On Sunday 09 June 2013 18:36:05 Maxime Ripard wrote: > Signed-off-by: Maxime Ripard > --- > arch/arm/boot/dts/sun5i-a10s.dtsi | 286 > ++ > 1 file changed, 286 insertions(+) > create mode 100644 arch/arm/boot/dts/sun5i-a10s.dtsi Would it make sense to split out the parts that are common with A13 into a separate sun5i.dtsi file? 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 buf-fix] kernel, range: fix broken mtrr_cleanup
On Sun, Jun 9, 2013 at 2:42 AM, Shan Wei wrote:
> From: Samuel Liao
>
>
> commit fbe06b7bae7c9cf6ab05168fce5ee93b2f4bae7c broken the mtrr_cleanup
> due to return incorrect merged range. this patch remove the empty range
> by swapping with the last.
>
> Error messages:
> Jun 9 14:06:18 kernel: [0.00] *BAD*gran_size: 64K chunk_size: 64K
>num_reg: 4 lose cover RAM: -0G
> Jun 9 14:06:18 kernel: [0.00] *BAD*gran_size: 64K chunk_size: 128K
>num_reg: 4 lose cover RAM: -0G
> Jun 9 14:06:18 kernel: [0.00] *BAD*gran_size: 64K chunk_size: 256K
>num_reg: 4 lose cover RAM: -0G
> Jun 9 14:06:18 kernel: [0.00] *BAD*gran_size: 64K chunk_size: 512K
>num_reg: 4 lose cover RAM: -0G
>
>
> Signed-off-by: Samuel Liao
> ---
> kernel/range.c | 15 ++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/range.c b/kernel/range.c
> index eb911db..b723697 100644
> --- a/kernel/range.c
> +++ b/kernel/range.c
> @@ -48,11 +48,18 @@ int add_range_with_merge(struct range *range, int az, int
> nr_range,
> final_start = min(range[i].start, start);
> final_end = max(range[i].end, end);
>
> + if (final_start == range[i].start && final_end ==
> range[i].end)
> + return nr_range;
> +
> /* clear it and add it back for further merge */
> - range[i].start = 0;
> - range[i].end = 0;
> - return add_range_with_merge(range, az, nr_range,
> - final_start, final_end);
> + nr_range -= 1;
> + if (i != nr_range) {
> + range[i].start = range[nr_range].start;
> + range[i].end = range[nr_range].end;
> + }
> + range[nr_range].start = 0;
> + range[nr_range].end = 0;
> + i = -1;
> }
>
> /* Need to add it: */
this patch is totally wrong.
if the ranges already have [0,1g), [2g, 3g). and want to add [1g, 2g) to it.
what is the result after this patch?
only [1g, 2g)
Thanks
Yinghai
--
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: [git pull] Please pull powerpc.git merge branch
On Sun, Jun 9, 2013 at 12:56 AM, Benjamin Herrenschmidt wrote: > > Here are a few more powerpc changes for 3.10. I've merged your > tree in at some point (which I generally avoid) in order to get > the compat network fixes as soon as possible. > > Mostly regressions, and stuff I judged could/should still go in at > this stage. Not pulled, because your hamster smells of eldeberries. This is not just bugfixes. In fact, as far as I can tell, this *introduces* bugs, with that "get_user()" in the exception path that can apparently happen with irqs disabled and will thus potentially result in new warnings that just make things unreadable. I'm f*cking tired of people having problems understanding "we're past rc5". If it's not something you would call stable material, you shouldn't send it to me. Linus -- 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: ondemand: Change the calculation of target frequency
On Sun, Jun 09, 2013 at 10:58:51PM +0200, Rafael J. Wysocki wrote: > Can you possibly prepare a graph showing both the execution time > and energy consumption for several different loop durations in your > program (let's keep the 5000 us sleep for now), including multiples of > sampling_rate as well as some other durations? Judgind by the times in C0 one of the cores spent, this small program is single-threaded and is a microbenchmark. And you know how optimizing against a microbenchmark doesn't really make a lot of sense. I wonder if lmbench or aim9 or whatever would make more sense to try here... Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: orion_nand: Improve error handling in orion_nand_probe
On Sun, Jun 9, 2013 at 11:57 PM, Dan Carpenter wrote: > On Sun, Jun 09, 2013 at 10:27:03PM +0300, Andy Shevchenko wrote: >> On Sun, Jun 9, 2013 at 10:17 PM, Dan Carpenter >> wrote: >> > On Sun, Jun 09, 2013 at 08:15:20PM +0300, Andy Shevchenko wrote: >> >> What about another patch (that I guess should go first) that converts >> >> printk to dev_* or pr_*? >> >> > Huh, what? Those are two totally unrelated things. Emil's patch is >> > a bug fix. >> >> To be precise his patch is bugfix and cleanup at once. >> My proposal is to add a clean up patch. > > The printk idea isn't a bad one, it's just totally unrelated to what > the patch is doing. I don't agree with word 'totally'. It touches probe function and shuffles code there. > You can't just randomly tell people to do a > bunch of work for no reason. "Good bugfix, but before we apply it > you have to mow my lawn." In this particular case I didn't think it's a big deal to fix 3 printfs. Anyway, see patch in the next message. -- With Best Regards, Andy Shevchenko -- 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] keucr: removed unnecessary variables and comments
From: Laura Lawniczak
blen and bn were only used in commented code fragments.
since comments should be informative and not for storing old
code, both, commented code and variables, were removed.
Signed-off-by: Laura Lawniczak
Signed-off-by: Johannes Schilling
---
this one is against latest gregkh/staging-next, and at least for me applies
cleanly.
drivers/staging/keucr/transport.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/keucr/transport.c
b/drivers/staging/keucr/transport.c
index 1f9ea58..aeb2186 100644
--- a/drivers/staging/keucr/transport.c
+++ b/drivers/staging/keucr/transport.c
@@ -85,16 +85,9 @@ static void usb_stor_print_cmd(struct us_data *us, struct
scsi_cmnd *srb)
{
PBYTE Cdb = srb->cmnd;
DWORD cmd = Cdb[0];
- DWORD bn = ((Cdb[2] << 24) & 0xff00) |
- ((Cdb[3] << 16) & 0x00ff) |
- ((Cdb[4] << 8) & 0xff00) |
- ((Cdb[5] << 0) & 0x00ff);
- WORDblen = ((Cdb[7] << 8) & 0xff00) | ((Cdb[8] << 0) & 0x00ff);
switch (cmd) {
case TEST_UNIT_READY:
- /* dev_dbg(&us->pusb_dev->dev,
- "scsi cmd %X --- SCSIOP_TEST_UNIT_READY\n", cmd); */
break;
case INQUIRY:
dev_dbg(&us->pusb_dev->dev,
@@ -113,14 +106,8 @@ static void usb_stor_print_cmd(struct us_data *us, struct
scsi_cmnd *srb)
"scsi cmd %X --- SCSIOP_READ_CAPACITY\n", cmd);
break;
case READ_10:
- /* dev_dbg(&us->pusb_dev->dev,
- "scsi cmd %X --- SCSIOP_READ,bn = %X, blen = %X\n"
- cmd, bn, blen); */
break;
case WRITE_10:
- /* dev_dbg(&us->pusb_dev->dev,
- "scsi cmd %X --- SCSIOP_WRITE, bn = %X, blen = %X\n",
- cmd, bn, blen); */
break;
case ALLOW_MEDIUM_REMOVAL:
dev_dbg(&us->pusb_dev->dev,
@@ -130,7 +117,6 @@ static void usb_stor_print_cmd(struct us_data *us, struct
scsi_cmnd *srb)
dev_dbg(&us->pusb_dev->dev, "scsi cmd %X --- Other cmd\n", cmd);
break;
}
- bn = 0;
}
/*
--
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: [RFC][PATCH] kconfig: Fix defconfig when one choice menu selects options that another choice menu depends on
Arve, All, On 2013-06-06 20:37 -0700, Arve Hjønnevåg spake thusly: > The defconfig and Kconfig combination below, which is based on 3.10-rc4 > Kconfigs, resulted in several options getting set to "m" instead of "y". OK, I was able to reproduce your test-case, and the fix seems reasonable. I'm just back from a week-end no-internet-access break, so I'll look at it more thoroughly tomorrow. Thank you! Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' -- 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] mtd: orion_nand: Improve error handling in orion_nand_probe
On Sun, Jun 09, 2013 at 10:27:03PM +0300, Andy Shevchenko wrote: > On Sun, Jun 9, 2013 at 10:17 PM, Dan Carpenter > wrote: > > On Sun, Jun 09, 2013 at 08:15:20PM +0300, Andy Shevchenko wrote: > > [] > > >> What about another patch (that I guess should go first) that converts > >> printk to dev_* or pr_*? > > > Huh, what? Those are two totally unrelated things. Emil's patch is > > a bug fix. > > To be precise his patch is bugfix and cleanup at once. > My proposal is to add a clean up patch. The printk idea isn't a bad one, it's just totally unrelated to what the patch is doing. You can't just randomly tell people to do a bunch of work for no reason. "Good bugfix, but before we apply it you have to mow my lawn." regards, dan carpenter -- 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: ondemand: Change the calculation of target frequency
On Sunday, June 09, 2013 09:08:23 PM Stratos Karafotis wrote: > On 06/09/2013 07:26 PM, Borislav Petkov wrote: > > On Sun, Jun 09, 2013 at 12:18:09AM +0200, Rafael J. Wysocki wrote: > >> The average power drawn by the package is slightly higher with the > >> patchset applied (27.66 W vs 27.25 W), but since the time needed to > >> complete the workload with the patchset applied was shorter by about > >> 2.3 sec, the total energy used was less in the latter case (by about > >> 25.7 J if I'm not mistaken, or 1% relative). This means that in the > >> absence of a power limit between 27.25 W and 27.66 W it's better to > >> use the kernel with the patchset applied for that particular workload > >> from the performance and energy usage perspective. > >> > >> Good, hopefully that's going to be confirmed on other systems and/or > >> with other workloads. :-) > > > > Yep, I see similar results on my AMD F15h. > > > > So there's a register which tells you what the current energy > > consumption in Watts is and support for it is integrated in lm_sensors. > > I did one read per second, for the duration of the kernel build (10-r5 + > > tip), with and without the patch, and averaged out the results: > > > > without > > === > > > > 1. 158 samples, avg Watts: 116.915 > > 2. 158 samples, avg Watts: 116.855 > > 3. 158 samples, avg Watts: 116.737 > > 4. 158 samples, avg Watts: 116.792 > > > > => 116.82475 avg Watts. > > > > with > > > > > > 1. 157 samples, avg Watts: 116.496 > > 2. 156 samples, avg Watts: 117.535 > > 3. 156 samples, avg Watts: 118.174 > > 4. 157 samples, avg Watts: 117.95 > > > > => 117.53875 avg Watts. > > > > So there's a slight raise in the average power consumption but the > > samples count drops by 1 or 2, which is consistent with the observed > > kernel build speedup of 1 or 2 seconds. > > > > perf doesn't show any significant difference with and without the patch > > but those are single runs only. > > > > without > > === > > > > Performance counter stats for 'make -j9': > > > > 1167856.647713 task-clock#7.272 CPUs utilized > > 1,071,177 context-switches #0.917 K/sec > > 52,844 cpu-migrations#0.045 K/sec > > 43,600,721 page-faults #0.037 M/sec > > 4,712,068,048,465 cycles#4.035 GHz > > 1,181,730,064,794 stalled-cycles-frontend # 25.08% frontend cycles > > idle > > 243,576,229,438 stalled-cycles-backend#5.17% backend cycles > > idle > > 2,966,369,010,209 instructions #0.63 insns per cycle > > #0.40 stalled cycles per > > insn > > 651,136,706,156 branches # 557.548 M/sec > > 34,582,447,788 branch-misses #5.31% of all branches > > > > 160.599796045 seconds time elapsed > > > > with > > > > > > Performance counter stats for 'make -j9': > > > > 1169278.095561 task-clock#7.271 CPUs utilized > > 1,076,528 context-switches #0.921 K/sec > > 53,284 cpu-migrations#0.046 K/sec > > 43,598,610 page-faults #0.037 M/sec > > 4,721,747,687,668 cycles#4.038 GHz > > 1,182,301,583,422 stalled-cycles-frontend # 25.04% frontend cycles > > idle > > 248,675,448,161 stalled-cycles-backend#5.27% backend cycles > > idle > > 2,967,419,684,598 instructions #0.63 insns per cycle > > #0.40 stalled cycles per > > insn > > 651,527,448,140 branches # 557.205 M/sec > > 34,560,656,638 branch-misses #5.30% of all branches > > > > 160.811815170 seconds time elapsed > > Hi, > > Boris, thanks so much for your tests! > > Rafael, thanks for your analysis! > > I did some additional tests to see how the CPU behaves in it's low and high > limits. > > I used Phoronix Java SciMark 2.0 test (FFT, Monte Carlo etc) to check the > patch in > really heavy loads. The results were almost identical with and without this > patch. > This is the expected behavior because I believe the load is greater than > up_threshold > most of the time in this cases. > With this patch. > Duration: 120.568521 sec > Pkg_W: 20.97 > > Without this patch > Duration: 120.606813 sec > Pkg_W: 21.11 The kernel with the patch applied still uses slightly less energy, however. > I also used a small program to check the CPU in very small loads with duration > comparable to sampling rate (1 in my config). > The program uses a tight 'for' loop with duration ~ (2 x sampling_rate). > After this it sleeps for 5000us. > I repeat the above for 100 times and then the program sleeps for 1 sec. > The above procedure repeats 15 times. > > Results show that there is a slow down (~4%) WITH this patch. > Though
[BOUNTY] Need a Working Driver Brought Up From 2.6.29 to 2.6.34. Will Pay.
I have an OEM Driver that works Excellent under 2.6.29. I need it working in 2.6.34 The Target Platform is ARM / Gumstix Overo. It is a network WiFi driver, so I may post there as well. But, the stack trace from when the module hangs on load gives switch_to() as the last function call when addr2line is used to check the address against the kernel file. Also, the driver does not curently use the net_driver_ops API. I have signed the NDA with the OEM, and I think the SRC is OK for GPL. After this issue is solved the project will go on IndieGoGo, and I will take it to the next level. For now I can pay, but I am not a MegaCorp. I can certainly work with anyone offline, but please respond here if appropriate. I do believe the end product can, and probably should be included in the 2.6.34 mainline release. Thanks, BallCam. -- 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 v2 1/2] saa7115: Implement i2c_board_info.platform_data
On Sun, Jun 09, 2013 at 11:36:55AM +0200, Hans Verkuil wrote:
> On Sat June 8 2013 19:29:41 Jon Arne Jørgensen wrote:
> > On Fri, Jun 07, 2013 at 11:12:47AM +0200, Hans Verkuil wrote:
> > > On Fri May 31 2013 13:40:25 Jon Arne Jørgensen wrote:
> > > > Implement i2c_board_info.platform_data handling in the driver so we can
> > > > make device specific changes to the chips we support.
> > > >
> > > > Signed-off-by: Jon Arne Jørgensen
> > > > ---
> > > > drivers/media/i2c/saa7115.c | 101
> > > > +--
> > > > drivers/media/i2c/saa711x_regs.h | 8
> > > > include/media/saa7115.h | 39 +++
> > > > 3 files changed, 143 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
> > > > index d6f589a..4a52b4d 100644
> > > > --- a/drivers/media/i2c/saa7115.c
> > > > +++ b/drivers/media/i2c/saa7115.c
> > > > @@ -216,10 +216,7 @@ static const unsigned char saa7111_init[] = {
> > > > 0x00, 0x00
> > > > };
> > > >
> > > > -/* SAA7113/GM7113C init codes
> > > > - * It's important that R_14... R_17 == 0x00
> > > > - * for the gm7113c chip to deliver stable video
> > > > - */
> > > > +/* SAA7113/GM7113C init codes */
> > > > static const unsigned char saa7113_init[] = {
> > > > R_01_INC_DELAY, 0x08,
> > > > R_02_INPUT_CNTL_1, 0xc2,
> > > > @@ -248,6 +245,35 @@ static const unsigned char saa7113_init[] = {
> > > > 0x00, 0x00
> > > > };
> > > >
> > > > +/* SAA7113 Init according to the datasheet */
> > > > +static const unsigned char saa7113_datasheet_init[] = {
> > > > + R_01_INC_DELAY, 0x08,
> > > > + R_02_INPUT_CNTL_1, 0xc0,
> > > > + R_03_INPUT_CNTL_2, 0x33,
> > > > + R_04_INPUT_CNTL_3, 0x00,
> > > > + R_05_INPUT_CNTL_4, 0x00,
> > > > + R_06_H_SYNC_START, 0xe9,
> > > > + R_07_H_SYNC_STOP, 0x0d,
> > > > + R_08_SYNC_CNTL, 0x98,
> > > > + R_09_LUMA_CNTL, 0x01,
> > > > + R_0A_LUMA_BRIGHT_CNTL, 0x80,
> > > > + R_0B_LUMA_CONTRAST_CNTL, 0x47,
> > > > + R_0C_CHROMA_SAT_CNTL, 0x40,
> > > > + R_0D_CHROMA_HUE_CNTL, 0x00,
> > > > + R_0E_CHROMA_CNTL_1, 0x01,
> > > > + R_0F_CHROMA_GAIN_CNTL, 0x2a,
> > > > + R_10_CHROMA_CNTL_2, 0x00,
> > > > + R_11_MODE_DELAY_CNTL, 0x0c,
> > > > + R_12_RT_SIGNAL_CNTL, 0x01,
> > > > + R_13_RT_X_PORT_OUT_CNTL, 0x00,
> > > > + R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
> > > > + R_15_VGATE_START_FID_CHG, 0x00,
> > > > + R_16_VGATE_STOP, 0x00,
> > > > + R_17_MISC_VGATE_CONF_AND_MSB, 0x00,
> > > > +
> > > > + 0x00, 0x00
> > > > +};
> > > > +
> > > > /* If a value differs from the Hauppauge driver values, then the
> > > > comment starts with
> > > > 'was 0xXX' to denote the Hauppauge value. Otherwise the value is
> > > > identical to what the
> > > > Hauppauge driver sets. */
> > > > @@ -1603,6 +1629,64 @@ static const struct v4l2_subdev_ops saa711x_ops
> > > > = {
> > > > };
> > > >
> > > > /*
> > > > ---
> > > > */
> > > > +static void saa711x_write_platform_data(struct saa711x_state *state,
> > > > + struct saa7115_platform_data
> > > > *data)
> > > > +{
> > > > + struct v4l2_subdev *sd = &state->sd;
> > > > + u8 work;
> > > > +
> > > > + if (state->ident != V4L2_IDENT_GM7113C)
> > > > + return;
> > > > +
> > > > + if (data->horizontal_time_const) {
> > > > + work = saa711x_read(sd, R_08_SYNC_CNTL);
> > > > + work &= ~SAA7113_R_08_HTC_MASK;
> > > > + work |= ((data->horizontal_time_const >> 1) << 3);
> > > > + v4l2_dbg(1, debug, sd,
> > > > +"set R_08 horizontal_time_const: 0x%x\n",
> > > > work);
> > > > + saa711x_write(sd, R_08_SYNC_CNTL, work);
> > > > + }
> > > > +
> > > > + if (data->vref_len) {
> > > > + work = saa711x_read(sd, R_10_CHROMA_CNTL_2);
> > > > + work &= ~SAA7113_R_10_VRLN_MASK;
> > > > + work |= (1 << 3);
> > > > + v4l2_dbg(1, debug, sd, "set R_10 vref_len: 0x%x\n",
> > > > work);
> > > > + saa711x_write(sd, R_10_CHROMA_CNTL_2, work);
> > > > + }
> > > > +
> > > > + if (data->output_format != SAA7113_OFTS_STD_ITU_656) {
> > > > + work = saa711x_read(sd, R_10_CHROMA_CNTL_2);
> > > > + work &= ~SAA7113_R_10_OFTS_MASK;
> > > > + work |= (data->output_format << 6);
> > > > + v4l2_dbg(1, debug, sd, "set R_10 output_format:
> > > > 0x%x\n", work);
> > > > + saa711x_write(sd, R_10_CHROMA_CNTL_2, work);
> > > > + }
> > > > +
> > > > + if (data->rt_signal0) {
> > > > + work = saa711x_read(sd, R_12_RT_SIGNAL_CNTL);
> > > > + work &= ~SAA7113
Re: N900 device tree conversion: how to do first step
Hi,
On Sun, Jun 09, 2013 at 03:59:44AM +0200, Pavel Machek wrote:
> I'd like to convert Nokia N900 to device tree.
>
> Unfortunately, serial port is not easily available (very special cable
> would be needed, does someone know where to get one?) and I don't have
> BDI (and very special cable would be needed, too).
>
> So I tried doing very small first step, hoping that I get booting
> system... obviously I did not.
The following works for me, it's enough to boot and get the USB networking
working. After that I can connect to the device with ssh. I don't use
serial either, I just have initramfs with busybox+dropbear with hardcoded
interface setup.
---8<---
/dts-v1/;
/include/ "omap34xx.dtsi"
/ {
model = "Nokia N900";
compatible = "nokia,omap3-n900", "ti,omap3";
cpus {
cpu@0 {
cpu0-supply = <&vcc>;
};
};
memory {
device_type = "memory";
reg = <0x8000 0x1000>; /* 256 MB */
};
};
&i2c1 {
clock-frequency = <220>;
twl: twl@48 {
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <&intc>;
};
};
/include/ "twl4030.dtsi"
&twl_gpio {
ti,pullups = <0x0>;
ti,pulldowns= <0x03ff3f>; /* BIT(0..5) | BIT(8..17) */
};
&i2c2 {
clock-frequency = <40>;
};
&i2c3 {
clock-frequency = <10>;
};
&mmc1 {
status = "disabled";
};
&mmc2 {
status = "disabled";
};
&mmc3 {
status = "disabled";
};
&usb_otg_hs {
interface-type = <0>;
usb-phy = <&usb2_phy>;
mode = <2>;
power = <50>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] x86, range: make add_range use blank slot
Now add_range_with_merge will generate blank slot as subtract_range.
we could reach the array limit because of blank slots.
We can let add_range to have second try to use blank slot.
Also use WARN_ONCE to print trace.
Reported-by: Joshua Covington
Signed-off-by: Yinghai Lu
Cc: v3.9
---
kernel/range.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
Index: linux-2.6/kernel/range.c
===
--- linux-2.6.orig/kernel/range.c
+++ linux-2.6/kernel/range.c
@@ -3,23 +3,34 @@
*/
#include
#include
+#include
#include
-
#include
int add_range(struct range *range, int az, int nr_range, u64 start, u64 end)
{
- if (start >= end)
- return nr_range;
+ int i;
- /* Out of slots: */
- if (nr_range >= az)
+ if (start >= end)
return nr_range;
- range[nr_range].start = start;
- range[nr_range].end = end;
+ /* Out of slots ? */
+ if (nr_range < az) {
+ i = nr_range;
+ nr_range++;
+ } else {
+ /* find blank slot */
+ for (i = 0; i < az; i++)
+ if (!range[i].end)
+ break;
+ if (i == az) {
+ WARN_ONCE(1, "run out of slot in ranges\n");
+ return az;
+ }
+ }
- nr_range++;
+ range[i].start = start;
+ range[i].end = end;
return nr_range;
}
@@ -98,10 +109,9 @@ void subtract_range(struct range *range,
if (i < az) {
range[i].end = range[j].end;
range[i].start = end;
- } else {
- pr_err("%s: run out of slot in ranges\n",
- __func__);
- }
+ } else
+ WARN_ONCE(1, "run out of slot in ranges\n");
+
range[j].end = start;
continue;
}
--
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/
