[PATCHv2 02/11] ARM: dts: exynos4: Use labels for overriding nodes in Exynos4210
Usage of lablels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210.dtsi | 43 +++
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 76b84852f29c..a9a55304e31a 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -52,16 +52,6 @@
};
};
- pmu_system_controller: system-controller@1002 {
- clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
- "clkout4", "clkout8", "clkout9";
- clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
- <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
- <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
- <&clock CLK_XUSBXTI>;
- #clock-cells = <1>;
- };
-
sysram: sysram@0202 {
compatible = "mmio-sram";
reg = <0x0202 0x2>;
@@ -95,18 +85,6 @@
arm,data-latency = <2 2 1>;
};
- gic: interrupt-controller@1049 {
- cpu-offset = <0x8000>;
- };
-
- combiner: interrupt-controller@1044 {
- samsung,combiner-nr = <16>;
- interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
- };
-
mct: mct@1005 {
compatible = "samsung,exynos4210-mct";
reg = <0x1005 0x800>;
@@ -245,3 +223,24 @@
status = "disabled";
};
};
+
+&gic {
+ cpu-offset = <0x8000>;
+};
+
+&combiner {
+ samsung,combiner-nr = <16>;
+ interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
+<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
+};
+
+&pmu_system_controller {
+ clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
+ "clkout4", "clkout8", "clkout9";
+ clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
+ <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
+ <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>, <&clock CLK_XUSBXTI>;
+ #clock-cells = <1>;
+};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 04/11] ARM: dts: exynos4: Use labels for overriding nodes in SMDKv310
Usage of lablels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-smdkv310.dts | 280 +++---
1 file changed, 140 insertions(+), 140 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 86216fff1b4f..043b03caff8f 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -30,181 +30,181 @@
stdout-path = &serial_1;
};
- sdhci@1253 {
- bus-width = <4>;
- pinctrl-names = "default";
- pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
- status = "okay";
- };
+ fixed-rate-clocks {
+ xxti {
+ compatible = "samsung,clock-xxti";
+ clock-frequency = <1200>;
+ };
- g2d@1280 {
- status = "okay";
+ xusbxti {
+ compatible = "samsung,clock-xusbxti";
+ clock-frequency = <2400>;
+ };
};
+};
- codec@1340 {
- samsung,mfc-r = <0x4300 0x80>;
- samsung,mfc-l = <0x5100 0x80>;
- status = "okay";
- };
+&g2d {
+ status = "okay";
+};
- serial@1380 {
- status = "okay";
- };
+&i2c_0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-max-bus-freq = <10>;
+ status = "okay";
- serial@1381 {
- status = "okay";
+ eeprom@50 {
+ compatible = "samsung,24ad0xd1";
+ reg = <0x50>;
};
- serial@1382 {
- status = "okay";
+ eeprom@52 {
+ compatible = "samsung,24ad0xd1";
+ reg = <0x52>;
};
+};
- serial@1383 {
- status = "okay";
+&keypad {
+ samsung,keypad-num-rows = <2>;
+ samsung,keypad-num-columns = <8>;
+ linux,keypad-no-autorepeat;
+ linux,keypad-wakeup;
+ pinctrl-names = "default";
+ pinctrl-0 = <&keypad_rows &keypad_cols>;
+ status = "okay";
+
+ key_1 {
+ keypad,row = <0>;
+ keypad,column = <3>;
+ linux,code = <2>;
};
- pinctrl@1100 {
- keypad_rows: keypad-rows {
- samsung,pins = "gpx2-0", "gpx2-1";
- samsung,pin-function = <3>;
- samsung,pin-pud = <3>;
- samsung,pin-drv = <0>;
- };
-
- keypad_cols: keypad-cols {
- samsung,pins = "gpx1-0", "gpx1-1", "gpx1-2", "gpx1-3",
- "gpx1-4", "gpx1-5", "gpx1-6", "gpx1-7";
- samsung,pin-function = <3>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
- };
+ key_2 {
+ keypad,row = <0>;
+ keypad,column = <4>;
+ linux,code = <3>;
};
- keypad@100A {
- samsung,keypad-num-rows = <2>;
- samsung,keypad-num-columns = <8>;
- linux,keypad-no-autorepeat;
- linux,keypad-wakeup;
- pinctrl-names = "default";
- pinctrl-0 = <&keypad_rows &keypad_cols>;
- status = "okay";
+ key_3 {
+ keypad,row = <0>;
+ keypad,column = <5>;
+ linux,code = <4>;
+ };
- key_1 {
- keypad,row = <0>;
- keypad,column = <3>;
- linux,code = <2>;
- };
+ key_4 {
+ keypad,row = <0>;
+ keypad,column = <6>;
+ linux,code = <5>;
+ };
- key_2 {
- keypad,row = <0>;
- keypad,column = <4>;
- linux,code = <3>;
- };
+ key_5 {
+ keypad,row = <0>;
+ keypad,column = <7>;
+ linux,code = <6>;
+ };
- key_3 {
- keypad,row = <0>;
- keypad,column = <5>;
- linux,code = <4>;
- };
+ key_a {
+ keypad,row = <1>;
+ keypad,column = <3>;
+ linux,code = <30>;
+ };
- key_4 {
- keypad,row = <0>;
- keypad,column = <6>;
- linux,code = <5>;
- };
+ key_b {
+ keypad,row = <1>;
+ keypad,column = <4>;
+ linux,code = <48>;
+ };
- key_5 {
-
Re: [GIT PULL] kdbus for 4.1-rc1
Hi Havoc, On 04/16/2015 09:01 PM, Havoc Pennington wrote: > On Thu, Apr 16, 2015 at 9:13 AM, Tom Gundersen wrote: >> All types of messages (unicast and broadcast) are directly stored into >> a pool slice of the receiving connection, and this slice is not reused >> by the kernel until userspace is finished with it and frees it. Hence, >> a client which doesn't process its incoming messages will, at some >> point, run out of pool space. If that happens for unicast messages, >> the sender will get an EXFULL error. If it happens for a multicast >> message, all we can do is drop the message, and tell the receiver how >> many messages have been lost when it issues KDBUS_CMD_RECV the next >> time. There's more on that in kdbus.message(7). > > Have you guys already grappled with what libraries/apps should do with > this information? > > To handle the knowledge that "N messages have been lost," it seems > like the client must answer "are there any messages that, if lost, > would put any code using this connection into a confused state" and > then the client has to recover from said confused state. This can only happen with user-originated DBus signal messages. For unicast messages such as method calls, the sender will actually see -EXFULL, and no part of the message is transmitted, leaving neither side in a confused state. But yes, for broadcast signal messages, we can't reject the sender because one single peer is out of buffer space, and we can't allow boundless allocations on the receiver either, so informing the other side is the best we can do. Note that dbus-daemon just drops such signals silently. So with this counter we simply add a debug mechanism for now. There hasn't been a consensus on how to react to such errors on the application level. The easiest way is obviously to re-sync all your state with the peer (which could be as easy as calling ObjectManager.GetManagedObjects() or Properties.GetAll()). > A library probably can't do this - it doesn't know what state matters > or how to recover it - so each app would have to... and are > connections ever shared between modules of an app? (for example: could > a library such as GTK+ or pulseaudio be using the connection, and then > application code is also using the connection, so none of those code > modules has the whole picture... at that point, none of the modules > knows what to do about lost messages... to try to handle lost messages > in a module, you'd need a private connection(?)... which might be fine > as long as each app having a number of connections isn't too bloated.) > > How to handle a send error depends a lot on what's being sent... but > if I were writing a general-purpose library wrapper, I'd be very > tempted to hide EXFULL behind an unbounded (or very-high-bounded) > userspace send buffer, which of course is what you were trying to > avoid, but I am skeptical that the average app will handle this error > sensibly. Actually, we see no real difference between constrained outgoing or incoming buffers. Even with a very-high-bounded send-buffer, you still need to deal with it running full. > The traditional userspace bus isn't any better than what you've > described here, of course - it's even worse - and it works well > enough. The limits are simply set high enough that they won't be hit > unless someone's broken or evil. Which is also the traditional > approach to say file descriptor limits or swap space: set the limit > high and hope you won't reach it. For the case of the X server, the > limit on message buffers appears to be "until malloc fails," so they > have the limit quite high, higher than userspace dbus does. "set high > limits and don't hit them" is a tried-and-true approach. > > With either the existing userspace bus or kdbus, I bet you could come > up with ways to use limit exhaustion to get various services and apps > into confused states as they miss messages they were relying on, > simply because this is too hard for apps to reliably get right. The > lower the limits, the easier it would be to cause trouble by forcing > them to be hit. > > In a perfect world we could figure out which client is "at fault" for > filling a buffer - the slow receiver or the overzealous sender - so we > could throttle or disconnect the guilty party instead of throwing > errors that won't be handled well ... but not sure that's practical. Exactly, you need heuristics for that. It's non-trivial to figure out whether the receiver or sender is to blame. We've thought about how to address that for a while and came up with a quota logic that is similar to what dbus-daemon implements in order to prevent single connections from overflowing the pool of a receiver. The limits that apply to that are currently hard-coded, and they work well on our systems. In the future, they can easily be made a bus-wide property that can be configured at bus creation time. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-ker
Re: [RFC 1/4] fs: Add generic file system event notifications
On 2015-04-17 09:04, Beata Michalska wrote:
On 04/17/2015 01:31 PM, Jan Kara wrote:
On Wed 15-04-15 09:15:44, Beata Michalska wrote:
...
+static const match_table_t fs_etypes = {
+ { FS_EVENT_INFO,"info" },
+ { FS_EVENT_WARN,"warn" },
+ { FS_EVENT_THRESH, "thr" },
+ { FS_EVENT_ERR, "err" },
+ { 0, NULL },
+};
Why are there these generic message types? Threshold messages make good
sense to me. But not so much the rest. If they don't have a clear meaning,
it will be a mess. So I also agree with a message like - "filesystem has
trouble, you should probably unmount and run fsck" - that's fine. But
generic "info" or "warning" doesn't really carry any meaning on its own and
thus seems pretty useless to me. To explain a bit more, AFAIU this
shouldn't be a generic logging interface where something like severity
makes sense but rather a relatively specific interface notifying about
events in filesystem userspace should know about so I expect relatively low
number of types of events, not tens or even hundreds...
Honza
Getting rid of those would simplify the configuration part, indeed.
So we would be left with 'generic' and threshold events.
I guess I've overdone this part.
For some filesystems, it may make sense to differentiate between a
generic warning and an error. For BTRFS and ZFS for example, if there
is a csum error on a block, this will get automatically corrected in
many configurations, and won't require anything like fsck to be run, but
monitoring applications will still probably want to be notified.
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCHv2 06/11] ARM: dts: exynos4: Use labels for overriding nodes in Exynos4212
Usage of lablels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4212.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 5be03288f1ee..d9c8efeef208 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -41,12 +41,12 @@
reg = <0xA01>;
};
};
+};
- combiner: interrupt-controller@1044 {
- samsung,combiner-nr = <18>;
- };
+&combiner {
+ samsung,combiner-nr = <18>;
+};
- gic: interrupt-controller@1049 {
- cpu-offset = <0x8000>;
- };
+&gic {
+ cpu-offset = <0x8000>;
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] proc: move the adding option Ngid to the end of proc/PID/status
Tejun Heo wrote: > On Fri, Apr 17, 2015 at 10:13:15AM +0800, Wang Xiaoming wrote: > > Move debugging has been done and the following Kernel issue > > was found with a number of applications. > > Take a look at: (even though the comments are for Weibo.browser > > they also pertain to other apps that use Libsecuritysdk-x.x.x.so > > > > In kernel(3.14) is a little different than before > > it will generate /proc/PID/status in this way: > > Name: a.weibo.browser > > State: T (stopped) > > Tgid: 8487 > > Ngid: 0 add in kernel after (3.11 maybe) > > Well, that's kinda hilarious and I don't know. 3.11 is way back and > what if there are others depending on the current ordering? Both > situations kinda suck so what's the point of changing? It was demonstrated that Ngid addition as line 4 breaks apps, but your "what if" remains "what if". I'd say Ngid should be moved to the end and every new field must be added to the end from now on, people can't parse simple file correctly, let's not create problems for them. -- 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] ASoC: tfa9879: Fix return value check in tfa9879_i2c_probe()
On Thu, Apr 16, 2015 at 08:17:46PM +0800, weiyj...@163.com wrote: > From: Wei Yongjun > > In case of error, the function devm_kzalloc() returns NULL > not ERR_PTR(). The IS_ERR() test in the return value check > should be replaced with NULL test. Applied, thanks. signature.asc Description: Digital signature
[PATCHv2 01/11] ARM: dts: Add labels to Exynos4 nodes
Add new labels to certain nodes so they could be easily referenced by
Exynos4 board DTS files.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4.dtsi| 22 +++---
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 6 +++---
arch/arm/boot/dts/exynos4210.dtsi | 6 +++---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 8
arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
5 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e20cdc24c3bb..ef944e4f42d0 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -257,7 +257,7 @@
};
};
- watchdog@1006 {
+ watchdog: watchdog@1006 {
compatible = "samsung,s3c2410-wdt";
reg = <0x1006 0x100>;
interrupts = <0 43 0>;
@@ -266,7 +266,7 @@
status = "disabled";
};
- rtc@1007 {
+ rtc: rtc@1007 {
compatible = "samsung,s3c6410-rtc";
reg = <0x1007 0x100>;
interrupt-parent = <&pmu_system_controller>;
@@ -276,7 +276,7 @@
status = "disabled";
};
- keypad@100A {
+ keypad: keypad@100A {
compatible = "samsung,s5pv210-keypad";
reg = <0x100A 0x100>;
interrupts = <0 109 0>;
@@ -285,7 +285,7 @@
status = "disabled";
};
- sdhci@1251 {
+ sdhci_0: sdhci@1251 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x1251 0x100>;
interrupts = <0 73 0>;
@@ -294,7 +294,7 @@
status = "disabled";
};
- sdhci@1252 {
+ sdhci_1: sdhci@1252 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x1252 0x100>;
interrupts = <0 74 0>;
@@ -303,7 +303,7 @@
status = "disabled";
};
- sdhci@1253 {
+ sdhci_2: sdhci@1253 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x1253 0x100>;
interrupts = <0 75 0>;
@@ -312,7 +312,7 @@
status = "disabled";
};
- sdhci@1254 {
+ sdhci_3: sdhci@1254 {
compatible = "samsung,exynos4210-sdhci";
reg = <0x1254 0x100>;
interrupts = <0 76 0>;
@@ -331,7 +331,7 @@
status = "disabled";
};
- hsotg@1248 {
+ hsotg: hsotg@1248 {
compatible = "samsung,s3c6400-hsotg";
reg = <0x1248 0x2>;
interrupts = <0 71 0>;
@@ -342,7 +342,7 @@
status = "disabled";
};
- ehci@1258 {
+ ehci: ehci@1258 {
compatible = "samsung,exynos4210-ehci";
reg = <0x1258 0x100>;
interrupts = <0 70 0>;
@@ -368,7 +368,7 @@
};
};
- ohci@1259 {
+ ohci: ohci@1259 {
compatible = "samsung,exynos4210-ohci";
reg = <0x1259 0x100>;
interrupts = <0 70 0>;
@@ -621,7 +621,7 @@
status = "disabled";
};
- pwm@139D {
+ pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index a7c212891674..4704e7bb2628 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -15,7 +15,7 @@
*/
/ {
- pinctrl@1140 {
+ pinctrl_0: pinctrl@1140 {
gpa0: gpa0 {
gpio-controller;
#gpio-cells = <2>;
@@ -421,7 +421,7 @@
};
};
- pinctrl@1100 {
+ pinctrl_1: pinctrl@1100 {
gpj0: gpj0 {
gpio-controller;
#gpio-cells = <2>;
@@ -822,7 +822,7 @@
};
};
- pinctrl@0386 {
+ pinctrl_3: pinctrl@0386 {
gpz: gpz {
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index be89f83f70e7..76b84852f29c 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -62,7 +62,7 @@
#clock-cells = <1>;
};
- sysram@0202 {
+ sysram: sysram@0202 {
compatible = "mmio-sram";
reg = <0x0202 0x2>;
#address-cells = <1>;
@@ -107,7 +107,7 @@
[PATCHv2 03/11] ARM: dts: exynos4: Use labels for overriding nodes in Exynos4210 Origen
Usage of lablels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-origen.dts | 418
1 file changed, 209 insertions(+), 209 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index b81146141402..e0abfc3324d1 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -50,209 +50,6 @@
};
};
- watchdog@1006 {
- status = "okay";
- };
-
- rtc@1007 {
- status = "okay";
- };
-
- tmu@100C {
- status = "okay";
- };
-
- sdhci@1253 {
- bus-width = <4>;
- pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus4 &sd2_cd>;
- pinctrl-names = "default";
- vmmc-supply = <&mmc_reg>;
- status = "okay";
- };
-
- sdhci@1251 {
- bus-width = <4>;
- pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_cd>;
- pinctrl-names = "default";
- vmmc-supply = <&mmc_reg>;
- status = "okay";
- };
-
- g2d@1280 {
- status = "okay";
- };
-
- codec@1340 {
- samsung,mfc-r = <0x4300 0x80>;
- samsung,mfc-l = <0x5100 0x80>;
- status = "okay";
- };
-
- serial@1380 {
- status = "okay";
- };
-
- serial@1381 {
- status = "okay";
- };
-
- serial@1382 {
- status = "okay";
- };
-
- serial@1383 {
- status = "okay";
- };
-
- i2c@1386 {
- status = "okay";
- samsung,i2c-sda-delay = <100>;
- samsung,i2c-max-bus-freq = <2>;
- pinctrl-0 = <&i2c0_bus>;
- pinctrl-names = "default";
-
- max8997_pmic@66 {
- compatible = "maxim,max8997-pmic";
- reg = <0x66>;
- interrupt-parent = <&gpx0>;
- interrupts = <4 0>, <3 0>;
-
- max8997,pmic-buck1-dvs-voltage = <135>;
- max8997,pmic-buck2-dvs-voltage = <110>;
- max8997,pmic-buck5-dvs-voltage = <120>;
-
- regulators {
- ldo1_reg: LDO1 {
- regulator-name = "VDD_ABB_3.3V";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
-
- ldo2_reg: LDO2 {
- regulator-name = "VDD_ALIVE_1.1V";
- regulator-min-microvolt = <110>;
- regulator-max-microvolt = <110>;
- regulator-always-on;
- };
-
- ldo3_reg: LDO3 {
- regulator-name = "VMIPI_1.1V";
- regulator-min-microvolt = <110>;
- regulator-max-microvolt = <110>;
- };
-
- ldo4_reg: LDO4 {
- regulator-name = "VDD_RTC_1.8V";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- regulator-always-on;
- };
-
- ldo6_reg: LDO6 {
- regulator-name = "VMIPI_1.8V";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- regulator-always-on;
- };
-
- ldo7_reg: LDO7 {
- regulator-name = "VDD_AUD_1.8V";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- };
-
- ldo8_reg: LDO8 {
- regulator-name = "VADC_3.3V";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
-
- ldo9_reg: LDO9 {
- regulator-name =
[PATCHv2 07/11] ARM: dts: exynos4: Use labels for overriding nodes in Exynos4x12
Usage of lablels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4x12.dtsi | 210 +++---
1 file changed, 105 insertions(+), 105 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 657b5ca39ce8..04812b842290 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -96,32 +96,6 @@
};
};
- combiner: interrupt-controller@1044 {
- interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
-<0 107 0>, <0 108 0>, <0 48 0>, <0 42 0>;
- };
-
- pinctrl_0: pinctrl@1140 {
- compatible = "samsung,exynos4x12-pinctrl";
- reg = <0x1140 0x1000>;
- interrupts = <0 47 0>;
- };
-
- pinctrl_1: pinctrl@1100 {
- compatible = "samsung,exynos4x12-pinctrl";
- reg = <0x1100 0x1000>;
- interrupts = <0 46 0>;
-
- wakup_eint: wakeup-interrupt-controller {
- compatible = "samsung,exynos4210-wakeup-eint";
- interrupt-parent = <&gic>;
- interrupts = <0 32 0>;
- };
- };
-
adc: adc@126C {
compatible = "samsung,exynos-adc-v1";
reg = <0x126C 0x100>;
@@ -135,30 +109,6 @@
status = "disabled";
};
- pinctrl_2: pinctrl@0386 {
- compatible = "samsung,exynos4x12-pinctrl";
- reg = <0x0386 0x1000>;
- interrupt-parent = <&combiner>;
- interrupts = <10 0>;
- };
-
- pinctrl_3: pinctrl@106E {
- compatible = "samsung,exynos4x12-pinctrl";
- reg = <0x106E 0x1000>;
- interrupts = <0 72 0>;
- };
-
- pmu_system_controller: system-controller@1002 {
- compatible = "samsung,exynos4212-pmu", "syscon";
- clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
- "clkout4", "clkout8", "clkout9";
- clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
- <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
- <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
- <&clock CLK_XUSBXTI>;
- #clock-cells = <1>;
- };
-
g2d: g2d@1080 {
compatible = "samsung,exynos4212-g2d";
reg = <0x1080 0x1000>;
@@ -173,40 +123,7 @@
<&clock CLK_PIXELASYNCM0>, <&clock CLK_PIXELASYNCM1>;
clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0",
"pxl_async1";
- fimc_0: fimc@1180 {
- compatible = "samsung,exynos4212-fimc";
- samsung,pix-limits = <4224 8192 1920 4224>;
- samsung,mainscaler-ext;
- samsung,isp-wb;
- samsung,cam-if;
- };
-
- fimc_1: fimc@1181 {
- compatible = "samsung,exynos4212-fimc";
- samsung,pix-limits = <4224 8192 1920 4224>;
- samsung,mainscaler-ext;
- samsung,isp-wb;
- samsung,cam-if;
- };
-
- fimc_2: fimc@1182 {
- compatible = "samsung,exynos4212-fimc";
- samsung,pix-limits = <4224 8192 1920 4224>;
- samsung,mainscaler-ext;
- samsung,isp-wb;
- samsung,lcd-wb;
- samsung,cam-if;
- };
-
- fimc_3: fimc@1183 {
- compatible = "samsung,exynos4212-fimc";
- samsung,pix-limits = <1920 8192 1366 1920>;
- samsung,rotators = <0>;
- samsung,mainscaler-ext;
- samsung,isp-wb;
- samsung,lcd-wb;
- };
-
+ /* fimc_[0-3] are configured outside, under phandles */
fimc_lite_0: fimc-lite@1239 {
compatible = "samsung,exynos4212-fimc-lite";
reg = <0x1239 0x1000>;
@@ -283,30 +200,113 @@
clock-names = "biu", "ciu";
status = "disabled";
};
+};
- exynos-usbphy@125B {
- compatible = "samsung,exynos4x12-usb2-phy";
- samsung,sysreg-phandle = <&sys_reg>;
- };
+&combiner {
+ interrupts = <0 0 0>, <0 1 0
[PATCHv2 09/11] ARM: dts: exynos4: Use labels for overriding nodes in Odroid
Usage of lablels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 728
arch/arm/boot/dts/exynos4412-odroidx.dts| 16 +-
2 files changed, 372 insertions(+), 372 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 8de12af7c276..6801ee6c4449 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -37,16 +37,6 @@
};
};
- i2s0: i2s@0383 {
- pinctrl-0 = <&i2s0_bus>;
- pinctrl-names = "default";
- status = "okay";
- clocks = <&clock_audss EXYNOS_I2S_BUS>,
-<&clock_audss EXYNOS_DOUT_AUD_BUS>,
-<&clock_audss EXYNOS_SCLK_I2S>;
- clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
- };
-
sound: sound {
compatible = "simple-audio-card";
assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
@@ -82,425 +72,435 @@
reset-gpios = <&gpk1 2 1>;
};
- mmc@1255 {
- pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
- pinctrl-names = "default";
- vmmc-supply = <&ldo20_reg &buck8_reg>;
- mmc-pwrseq = <&emmc_pwrseq>;
- status = "okay";
-
- num-slots = <1>;
- broken-cd;
- card-detect-delay = <200>;
- samsung,dw-mshc-ciu-div = <3>;
- samsung,dw-mshc-sdr-timing = <2 3>;
- samsung,dw-mshc-ddr-timing = <1 2>;
- bus-width = <8>;
- cap-mmc-highspeed;
- };
-
- watchdog@1006 {
- status = "okay";
- };
-
- rtc@1007 {
- status = "okay";
- };
-
- g2d@1080 {
- status = "okay";
- };
-
camera {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <>;
+ };
- fimc_0: fimc@1180 {
- status = "okay";
- assigned-clocks = <&clock CLK_MOUT_FIMC0>,
- <&clock CLK_SCLK_FIMC0>;
- assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
- assigned-clock-rates = <0>, <17600>;
- };
-
- fimc_1: fimc@1181 {
- status = "okay";
- assigned-clocks = <&clock CLK_MOUT_FIMC1>,
- <&clock CLK_SCLK_FIMC1>;
- assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
- assigned-clock-rates = <0>, <17600>;
+ fixed-rate-clocks {
+ xxti {
+ compatible = "samsung,clock-xxti";
+ clock-frequency = <0>;
};
- fimc_2: fimc@1182 {
- status = "okay";
- assigned-clocks = <&clock CLK_MOUT_FIMC2>,
- <&clock CLK_SCLK_FIMC2>;
- assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
- assigned-clock-rates = <0>, <17600>;
+ xusbxti {
+ compatible = "samsung,clock-xusbxti";
+ clock-frequency = <2400>;
};
+ };
- fimc_3: fimc@1183 {
- status = "okay";
- assigned-clocks = <&clock CLK_MOUT_FIMC3>,
- <&clock CLK_SCLK_FIMC3>;
- assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
- assigned-clock-rates = <0>, <17600>;
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+/* Corresponds to 800MHz at freq_table */
+cooling-device = <&cpu0 7 7>;
+ };
+ map1 {
+/* Corresponds to 200MHz at freq_table */
+cooling-device = <&cpu0 13 13>;
+ };
+ };
};
};
+};
- sdhci@1253 {
- bus-width = <4>;
- pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
- pinctrl-names = "default";
- vmmc-supply = <&ldo4_reg &ldo21_reg>;
- cd-gpios = <&gpk2 2 0>;
- cd-inverted;
- status = "okay";
- };
+/* RSTN signal for eMMC */
+&sd1_cd {
+
[PATCHv2 05/11] ARM: dts: exynos4: Use labels for overriding nodes in Trats
Usage of lablels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-trats.dts | 592 -
1 file changed, 296 insertions(+), 296 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 32c5fd8f6269..98f3ce65cb9a 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -89,42 +89,6 @@
};
};
- hsotg@1248 {
- vusb_d-supply = <&vusb_reg>;
- vusb_a-supply = <&vusbdac_reg>;
- dr_mode = "peripheral";
- status = "okay";
- };
-
- sdhci_emmc: sdhci@1251 {
- bus-width = <8>;
- non-removable;
- pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus8>;
- pinctrl-names = "default";
- vmmc-supply = <&vemmc_reg>;
- status = "okay";
- };
-
- exynos-usbphy@125B {
- status = "okay";
- };
-
- serial@1380 {
- status = "okay";
- };
-
- serial@1381 {
- status = "okay";
- };
-
- serial@1382 {
- status = "okay";
- };
-
- serial@1383 {
- status = "okay";
- };
-
gpio-keys {
compatible = "gpio-keys";
@@ -158,201 +122,6 @@
};
};
- i2c@1389 {
- samsung,i2c-sda-delay = <100>;
- samsung,i2c-slave-addr = <0x10>;
- samsung,i2c-max-bus-freq = <40>;
- pinctrl-0 = <&i2c3_bus>;
- pinctrl-names = "default";
- status = "okay";
-
- mms114-touchscreen@48 {
- compatible = "melfas,mms114";
- reg = <0x48>;
- interrupt-parent = <&gpx0>;
- interrupts = <4 2>;
- x-size = <720>;
- y-size = <1280>;
- avdd-supply = <&tsp_reg>;
- vdd-supply = <&tsp_reg>;
- };
- };
-
- i2c@138B {
- samsung,i2c-sda-delay = <100>;
- samsung,i2c-slave-addr = <0x10>;
- samsung,i2c-max-bus-freq = <10>;
- pinctrl-0 = <&i2c5_bus>;
- pinctrl-names = "default";
- status = "okay";
-
- max8997_pmic@66 {
- compatible = "maxim,max8997-pmic";
-
- reg = <0x66>;
-
- max8997,pmic-buck1-uses-gpio-dvs;
- max8997,pmic-buck2-uses-gpio-dvs;
- max8997,pmic-buck5-uses-gpio-dvs;
-
- max8997,pmic-ignore-gpiodvs-side-effect;
- max8997,pmic-buck125-default-dvs-idx = <0>;
-
- max8997,pmic-buck125-dvs-gpios = <&gpx0 5 0>,
-<&gpx0 6 0>,
-<&gpl0 0 0>;
-
- max8997,pmic-buck1-dvs-voltage = <135>, <130>,
-<125>, <120>,
-<115>, <110>,
-<100>, <95>;
-
- max8997,pmic-buck2-dvs-voltage = <110>, <100>,
-<95>, <90>,
-<110>, <100>,
-<95>, <90>;
-
- max8997,pmic-buck5-dvs-voltage = <120>, <120>,
-<120>, <120>,
-<120>, <120>,
-<120>, <120>;
-
- regulators {
- valive_reg: LDO2 {
-regulator-name = "VALIVE_1.1V_C210";
-regulator-min-microvolt = <110>;
-regulator-max-microvolt = <110>;
-regulator-always-on;
- };
-
- vusb_reg: LDO3 {
-regulator-name = "VUSB_1.1V_C210";
-regulator-min-microvolt = <110>;
-regulator-max-microvolt = <110>;
- };
-
- vmipi_reg: LDO4 {
-regulator-name = "VMIPI_1.8V";
-
[PATCHv2 08/11] ARM: dts: exynos4: Use labels for overriding nodes in Exynos4412
Usage of lablels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412.dtsi | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 68ad43b391ae..b78ada70bd05 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -54,19 +54,19 @@
};
};
- combiner: interrupt-controller@1044 {
- samsung,combiner-nr = <20>;
- };
-
pmu {
interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
};
+};
- gic: interrupt-controller@1049 {
- cpu-offset = <0x4000>;
- };
+&pmu_system_controller {
+ compatible = "samsung,exynos4412-pmu", "syscon";
+};
- pmu_system_controller: system-controller@1002 {
- compatible = "samsung,exynos4412-pmu", "syscon";
- };
+&combiner {
+ samsung,combiner-nr = <20>;
+};
+
+&gic {
+ cpu-offset = <0x4000>;
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 00/11] ARM: dts: exynos4: labels for overriding nodes
Hi, Changes since v1 1. Re-phrased the description (phandle->label). Suggested by Arnd. Description === The label-based notation reduces possible mistakes when overriding nodes by child DTSI and board files and reduces duplication of addresses. The patchset refactors Exynos4 boards to use labels for overriding nodes. Tested by comparison of decompiled DTB for each commit. Best regards, Krzysztof Krzysztof Kozlowski (11): ARM: dts: Add labels to Exynos4 nodes ARM: dts: exynos4: Use labels for overriding nodes in Exynos4210 ARM: dts: exynos4: Use labels for overriding nodes in Exynos4210 Origen ARM: dts: exynos4: Use labels for overriding nodes in SMDKv310 ARM: dts: exynos4: Use labels for overriding nodes in Trats ARM: dts: exynos4: Use labels for overriding nodes in Exynos4212 ARM: dts: exynos4: Use labels for overriding nodes in Exynos4x12 ARM: dts: exynos4: Use labels for overriding nodes in Exynos4412 ARM: dts: exynos4: Use labels for overriding nodes in Odroid ARM: dts: exynos4: Use labels for overriding nodes in SMDK4412 ARM: dts: exynos4: Use labels for overriding nodes in Trats2 arch/arm/boot/dts/exynos4.dtsi | 22 +- arch/arm/boot/dts/exynos4210-origen.dts | 418 +++ arch/arm/boot/dts/exynos4210-pinctrl.dtsi |6 +- arch/arm/boot/dts/exynos4210-smdkv310.dts | 280 ++--- arch/arm/boot/dts/exynos4210-trats.dts | 592 +- arch/arm/boot/dts/exynos4210.dtsi | 49 +- arch/arm/boot/dts/exynos4212.dtsi | 12 +- arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 728 ++--- arch/arm/boot/dts/exynos4412-odroidx.dts| 16 +- arch/arm/boot/dts/exynos4412-smdk4412.dts | 210 ++-- arch/arm/boot/dts/exynos4412-trats2.dts | 1331 --- arch/arm/boot/dts/exynos4412.dtsi | 20 +- arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |8 +- arch/arm/boot/dts/exynos4x12.dtsi | 212 ++-- 14 files changed, 1952 insertions(+), 1952 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
On Friday 17 April 2015 10:01:56 Catalin Marinas wrote: > On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote: > > On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: > > > On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote: > > > > There are only a few places where long should be 32bit rather than > > > > 64bit. The non-time_t field of timespec is the only one I can think > > > > of. > > > > > > It may be the only one but we could end up with a non-compliant > > > timespec. Unless we keep the tv_nsec as 32-bit long and add some > > > padding, we could work around it by getting the C library to sign-extend > > > such padding or we do it in a new "compat" layer in the kernel (but both > > > cases imply copying the structure). > > > > > > However, timerspec is included in other structures, so we'd have to > > > intercept those as well. Philipp provided a list here: > > > > > > http://article.gmane.org/gmane.linux.kernel/1931497 > > > > We're basically in the same boat as x32 then, and should do the same > > thing on both most importantly, whatever that ends up. > > I'm getting confused ;). I thought you were pushing for a 32-bit time_t > on AArch64 ILP32. > > I'm not sure we need to be in the same boat as x32. Their decision was > to primarily use the LP64 ABI and there are performance advantages, not > only the 2038 issue. The downside, few POSIX incompatibilities that I > think they are happy to live with. If we are happy to live with them as > well, we go ahead with the current patchset. We may try to patch some of > the POSIX incompatibilities (see Philipp's list above) by > padding/copying/sign-extending the affected structures. Here is my current line of thinking: - Using all the aarch32 data structures would be the easiest way, then we could use the side of asm-generic/unistd.h and everything should work to the same degree as it does today for aarch32 emulation. This means 32-bit time_t of course, and it would give us the best tradeoff between the amount of work needed and the results we get. A few downsides have been mentioned, but I still think it's the best approach. This would be the approach e) that you suggested earlier. - If we do not use the exact data structures that we have on aarch32, then I think we should make aarch32 emulation and aarch64-ilp32 emulation mutually exclusive, and provide two separate asm/compat.h header files that contain the differences. In this case, we should try to come up with an ABI that makes the most sense for the majority of the use cases that people are interested in. The two most likely choices here would be f) create a new ABI that follows exactly what x32 did. This is a variation of the earlier b), c), or d), but with the change of fixing ioctl support by using a matching asm/compat.h. This would not be entirely POSIX compliant, but it would be a nice hack to get the highest performance in microbenchmarks, as it avoids most of the compat layer. Over time, it can get extended to coexist with aarch32 emulation, but that may take a few years. g) create a new ABI that does things in exactly the way that we would use as the native syscall interface if we had an ilp32 kernel running on aarch64 with the asm-generic/unistd.h. This would mean a 32-bit __kernel_long_t and time_t, but extending time_t in the long run, together with aarch32 and i386. This one is particularly interesting for people that are interested in maximum posix compliance and in having a "nice" ABI, in particular if there is a slight chance that within the next decade we have reason to support building an arch/arm64 kernel itself in aarch64-ilp32 mode. Between e), f), and g), I'd lean towards e), but I'm fine with the other two as well and still lack sufficient information on what people want to do with it in the long run. > > However, it would be nice to get agreement on the normal 32-bit ABI > > for time_t and timespec first, and then use the same thing everywhere. > > Do you mean for native 32-bit architectures? I think OpenBSD uses a > 64-bit time_t already on 32-bit arches, it's doable in Linux as well. Yes, and I'm working on that for Linux. The first step involves fixing the kernel, one file at a time, changing all users of time_t to use some other type (ktime_t or time64_t in most cases) instead, and introducing additional system calls to handle the boundary to user space without breaking stuff. See my presentation at http://elinux.org/ELC_2015_Presentations for more detail. 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: [RFC 1/4] fs: Add generic file system event notifications
On Fri 17-04-15 15:04:37, Beata Michalska wrote:
> On 04/17/2015 01:31 PM, Jan Kara wrote:
> > On Wed 15-04-15 09:15:44, Beata Michalska wrote:
> > Also I think that we should make it clear that each event type has
> > different set of arguments. For threshold events they'll be L1 & L2, for
> > other events there may be no arguments, for other events maybe something
> > else...
> >
>
> Currently only the threshold events use arguments - not sure what arguments
> could be used for the remaining notifications. But any suggestions are
> welcomed.
Me neither be someone will surely find something in future ;)
> > ...
> >> +static const match_table_t fs_etypes = {
> >> + { FS_EVENT_INFO,"info" },
> >> + { FS_EVENT_WARN,"warn" },
> >> + { FS_EVENT_THRESH, "thr" },
> >> + { FS_EVENT_ERR, "err" },
> >> + { 0, NULL },
> >> +};
> > Why are there these generic message types? Threshold messages make good
> > sense to me. But not so much the rest. If they don't have a clear meaning,
> > it will be a mess. So I also agree with a message like - "filesystem has
> > trouble, you should probably unmount and run fsck" - that's fine. But
> > generic "info" or "warning" doesn't really carry any meaning on its own and
> > thus seems pretty useless to me. To explain a bit more, AFAIU this
> > shouldn't be a generic logging interface where something like severity
> > makes sense but rather a relatively specific interface notifying about
> > events in filesystem userspace should know about so I expect relatively low
> > number of types of events, not tens or even hundreds...
> >
>
> Getting rid of those would simplify the configuration part, indeed.
> So we would be left with 'generic' and threshold events.
> I guess I've overdone this part.
Well, I would avoid defining anything that's not really used. So
currently you can define threshold events and we start with just those.
When someone hooks up filesystem error paths to send notification, we can
create event type for telling "filesystem corrupted". And so on... We just
have to be careful to document that new event types can be added and
userspace has to ignore events it does not understand.
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] fs: Add generic file system event notifications
On 04/17/2015 03:04 PM, Beata Michalska wrote: > On 04/17/2015 01:31 PM, Jan Kara wrote: >> On Wed 15-04-15 09:15:44, Beata Michalska wrote: >>> Introduce configurable generic interface for file >>> system-wide event notifications to provide file >>> systems with a common way of reporting any potential >>> issues as they emerge. >>> >>> The notifications are to be issued through generic >>> netlink interface, by a dedicated, for file system >>> events, multicast group. The file systems might as >>> well use this group to send their own custom messages. >>> >>> The events have been split into four base categories: >>> information, warnings, errors and threshold notifications, >>> with some very basic event types like running out of space >>> or file system being remounted as read-only. >>> >>> Threshold notifications have been included to allow >>> triggering an event whenever the amount of free space >>> drops below a certain level - or levels to be more precise >>> as two of them are being supported: the lower and the upper >>> range. The notifications work both ways: once the threshold >>> level has been reached, an event shall be generated whenever >>> the number of available blocks goes up again re-activating >>> the threshold. >>> >>> The interface has been exposed through a vfs. Once mounted, >>> it serves as an entry point for the set-up where one can >>> register for particular file system events. >>> >>> Signed-off-by: Beata Michalska >> Thanks for the patches! Some comments are below. >> >>> --- >>> Documentation/filesystems/events.txt | 254 +++ >>> fs/Makefile |1 + >>> fs/events/Makefile |6 + >>> fs/events/fs_event.c | 775 >>> ++ >>> fs/events/fs_event.h | 27 ++ >>> fs/events/fs_event_netlink.c | 94 + >>> fs/namespace.c |1 + >>> include/linux/fs.h |6 +- >>> include/linux/fs_event.h | 69 +++ >>> include/uapi/linux/fs_event.h| 62 +++ >>> include/uapi/linux/genetlink.h |1 + >>> net/netlink/genetlink.c |7 +- >>> 12 files changed, 1301 insertions(+), 2 deletions(-) >>> create mode 100644 Documentation/filesystems/events.txt >>> create mode 100644 fs/events/Makefile >>> create mode 100644 fs/events/fs_event.c >>> create mode 100644 fs/events/fs_event.h >>> create mode 100644 fs/events/fs_event_netlink.c >>> create mode 100644 include/linux/fs_event.h >>> create mode 100644 include/uapi/linux/fs_event.h >>> >>> diff --git a/Documentation/filesystems/events.txt >>> b/Documentation/filesystems/events.txt >>> new file mode 100644 >>> index 000..c85dd88 >>> --- /dev/null >>> +++ b/Documentation/filesystems/events.txt >>> @@ -0,0 +1,254 @@ >>> + >>> + Generic file system event notification interface >>> + >>> +Document created 09 April 2015 by Beata Michalska >>> + >>> +1. The reason behind: >>> += >>> + >>> +There are many corner cases when things might get messy with the >>> filesystems. >>> +And it is not always obvious what and when went wrong. Sometimes you might >>> +get some subtle hints that there is something going on - but by the time >>> +you realise it, it might be too late as you are already out-of-space >>> +or the filesystem has been remounted as read-only (i.e.). The generic >>> +interface for the filesystem events fills the gap by providing a rather >>> +easy way of real-time notifications triggered whenever something >>> intreseting >>> +happens, allowing filesystems to report events in a common way, as they >>> occur. >>> + >>> +2. How does it work: >>> + >>> + >>> +The interface itself has been exposed as fstrace-type Virtual File System, >>> +primarily to ease the process of setting up the configuration for the file >>> +system notifications. So for starters it needs to get mounted (obviously): >>> + >>> + mount -t fstrace none /sys/fs/events >>> + >>> +This will unveil the single fstrace filesystem entry - the 'config' file, >>> +through which the notification are being set-up. >>> + >>> +Activating notifications for particular filesystem is as straightforward >>> +as writing into the 'config' file. Note that by default all events despite >>> +the actual filesystem type are being disregarded. >> Is there a reason to have a special filesystem for this? Do you expect >> extending it by (many) more files? Why not just creating a file in sysfs or >> something like that? > > No particular reason here - just for possible future extension if needed. > I'm totally fine with having a single sysfs entry. > On the other hand sysfs entries are mostly single-valued or are sets of values of a single type, so not sure if we would fit in here - with the current configuration for the interface. >> >>> +Synopsis of config: >>> +-- >>> + >>> + MOUNT EVENT_TYPE [L1]
Re: [PATCH V6 4/6] perf, x86: handle multiple records in PEBS buffer
On Fri, Apr 17, 2015 at 12:50:33PM +, Liang, Kan wrote: > > > > > > > > A) the CTRn value reaches 0: > > > - the corresponding bit in GLOBAL_STATUS gets set > > > - we start arming the hardware assist > > > > > > < some unspecified amount of time later -- > > > this could cover multiple events of interest > > > > > > > B) the hardware assist is armed, any next event will trigger it > > > > > > C) a matching event happens: > > > - the hardware assist triggers and generates a PEBS record > > > this includes a copy of GLOBAL_STATUS at this moment > > > - if we auto-reload we (re)set CTRn > > > > Is this actually true? Do we reload here or on A ? > > > > Yes, on C. > According to SDM Volume 3, 18.7.1.1, the reset value will be > loaded after each PEBS record is written, which is done > by hw assist. OK, then I did indeed remember that right. But that brings us to patch 1 of this series, how is that correct in the face of this? There is an arbitrary delay (A->B) added to the period. And the Changelog of course never did bother to make that clear. -- 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: [tip:timers/urgent] timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in idle loop
On Sun, Mar 29, 2015 at 09:04:47AM +0200, Ingo Molnar wrote:
>
> * Preeti U Murthy wrote:
>
> > Hi,
> >
> > Can you please add sta...@vger.kernel.org to the Cc?
> > Without the patch, we get RCU warnings during bootup.
> > Hence the patch is important for the stable kernels as well.
>
> This fix is now upstream.
>
> Greg, please back-port the following upstream commit to -stable:
>
> a127d2bcf1fb ("timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in
> idle loop")
>
> this bug was introduced in v3.15 and will cleanly apply to v3.15 and
> all later stable kernels.
Now applied, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] First batch of KVM changes for 4.1
On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
> On 17/04/2015 12:55, Peter Zijlstra wrote:
> > Also, it looks like you already do exactly this for other things, look
> > at:
> >
> > kvm_sched_in()
> > kvm_arch_vcpu_load()
> > if (unlikely(vcpu->cpu != cpu) ... )
> >
> > So no, I don't believe for one second you need this.
>
> You're missing that this snippet is running in the host, while this
> patch is concerned with the guest (paravirt).
This doesn't make sense; but it brings us back to where we were last
time. There is _0_ justification for this in the patches, that alone is
grounds enough to reject it.
Why should the guest task care about the physical cpu of the vcpu;
that's a layering fail if ever there was one.
Furthermore, the only thing that migration handler seems to do is
increment a variable that is not actually used in that file.
> And frankly, I think the static key is snake oil. The cost of task
> migration in terms of cache misses and TLB misses is in no way
> comparable to the cost of filling in a structure on the stack,
> dereferencing the head of the notifiers list and seeing that it's NULL.
The path this notifier is called from has nothing to do with those
costs. And the fact you're inflicting these costs on _everyone_ for a
single x86_64-paravirt case is insane.
I've had enough of this, the below goes into sched/urgent and you can
come back with sane patches if and when you're ready.
---
arch/x86/kernel/pvclock.c | 24
include/linux/sched.h | 8
kernel/sched/core.c | 15 ---
3 files changed, 47 deletions(-)
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index e5ecd20e72dd..82f116de3835 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -160,27 +160,6 @@ struct pvclock_vcpu_time_info
*pvclock_get_vsyscall_time_info(int cpu)
}
#ifdef CONFIG_X86_64
-static int pvclock_task_migrate(struct notifier_block *nb, unsigned long l,
- void *v)
-{
- struct task_migration_notifier *mn = v;
- struct pvclock_vsyscall_time_info *pvti;
-
- pvti = pvclock_get_vsyscall_user_time_info(mn->from_cpu);
-
- /* this is NULL when pvclock vsyscall is not initialized */
- if (unlikely(pvti == NULL))
- return NOTIFY_DONE;
-
- pvti->migrate_count++;
-
- return NOTIFY_DONE;
-}
-
-static struct notifier_block pvclock_migrate = {
- .notifier_call = pvclock_task_migrate,
-};
-
/*
* Initialize the generic pvclock vsyscall state. This will allocate
* a/some page(s) for the per-vcpu pvclock information, set up a
@@ -202,9 +181,6 @@ int __init pvclock_init_vsyscall(struct
pvclock_vsyscall_time_info *i,
PAGE_KERNEL_VVAR);
}
-
- register_task_migration_notifier(&pvclock_migrate);
-
return 0;
}
#endif
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 3f3308824fa4..0eabab99e126 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -176,14 +176,6 @@ extern void get_iowait_load(unsigned long *nr_waiters,
unsigned long *load);
extern void calc_global_load(unsigned long ticks);
extern void update_cpu_load_nohz(void);
-/* Notifier for when a task gets migrated to a new CPU */
-struct task_migration_notifier {
- struct task_struct *task;
- int from_cpu;
- int to_cpu;
-};
-extern void register_task_migration_notifier(struct notifier_block *n);
-
extern unsigned long get_parent_ip(unsigned long addr);
extern void dump_cpu_task(int cpu);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1d0bc4fe266d..dbfc93d40292 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1013,13 +1013,6 @@ void check_preempt_curr(struct rq *rq, struct
task_struct *p, int flags)
rq_clock_skip_update(rq, true);
}
-static ATOMIC_NOTIFIER_HEAD(task_migration_notifier);
-
-void register_task_migration_notifier(struct notifier_block *n)
-{
- atomic_notifier_chain_register(&task_migration_notifier, n);
-}
-
#ifdef CONFIG_SMP
void set_task_cpu(struct task_struct *p, unsigned int new_cpu)
{
@@ -1050,18 +1043,10 @@ void set_task_cpu(struct task_struct *p, unsigned int
new_cpu)
trace_sched_migrate_task(p, new_cpu);
if (task_cpu(p) != new_cpu) {
- struct task_migration_notifier tmn;
-
if (p->sched_class->migrate_task_rq)
p->sched_class->migrate_task_rq(p, new_cpu);
p->se.nr_migrations++;
perf_sw_event_sched(PERF_COUNT_SW_CPU_MIGRATIONS, 1, 0);
-
- tmn.task = p;
- tmn.from_cpu = task_cpu(p);
- tmn.to_cpu = new_cpu;
-
- atomic_notifier_call_chain(&task_migration_notifier, 0, &tmn);
}
__set_task_cpu(p, new_cpu);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
[RFC PATCH 2/2] gfp: use the best near online node if the target node is offline
Since the change to the cpu <--> mapping (map the cpu to the physical
node for all possible at the boot), the node of cpu may be not present,
so we use the best near online node if the node is not present in the low
level allocation APIs.
Signed-off-by: Gu Zheng
---
include/linux/gfp.h | 28 +++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 97a9373..19684a8 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -298,9 +298,31 @@ __alloc_pages(gfp_t gfp_mask, unsigned int order,
return __alloc_pages_nodemask(gfp_mask, order, zonelist, NULL);
}
+static int find_near_online_node(int node)
+{
+ int n, val;
+ int min_val = INT_MAX;
+ int best_node = -1;
+
+ for_each_online_node(n) {
+ val = node_distance(node, n);
+
+ if (val < min_val) {
+ min_val = val;
+ best_node = n;
+ }
+ }
+
+ return best_node;
+}
+
static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
unsigned int order)
{
+ /* Offline node, use the best near online node */
+ if (!node_online(nid))
+ nid = find_near_online_node(nid);
+
/* Unknown node is current node */
if (nid < 0)
nid = numa_node_id();
@@ -311,7 +333,11 @@ static inline struct page *alloc_pages_node(int nid, gfp_t
gfp_mask,
static inline struct page *alloc_pages_exact_node(int nid, gfp_t gfp_mask,
unsigned int order)
{
- VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid));
+ /* Offline node, use the best near online node */
+ if (!node_online(nid))
+ nid = find_near_online_node(nid);
+
+ VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
}
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/2] x86/cpu hotplug: make apicid <--> cpuid mapping persistent
Yasuaki Ishimatsu found that with node online/offline, cpu<->node relationship
is established. Because workqueue uses a info which was established at boot
time, but it may be changed by node hotpluging.
Once pool->node points to a stale node, following allocation failure
happens.
==
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default
order:
1, min order: 0
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
==
As the apicid <---> pxm and pxm <--> node relationship are persistent, then
the apicid <--> node mapping is persistent, so the root cause is the
cpu-id <-> lapicid mapping is not persistent (because the currently
implementation
always choose the first free cpu id for the new added cpu). If we can build
persistent cpu-id <-> lapicid relationship, this problem will be fixed.
This patch tries to build the whole world mapping cpuid <-> apicid <-> pxm <->
node
for all possible processor at the boot, the detail implementation are 2 steps:
Step1: generate a logic cpu id for all the local apic (both enabled and
dsiabled)
when register local apic
Step2: map the cpu to the phyical node via an additional acpi ns walk for
processor.
Please refer to:
https://lkml.org/lkml/2015/2/27/145
https://lkml.org/lkml/2015/3/25/989
for the previous discussion.
Reported-by: Yasuaki Ishimatsu
Signed-off-by: Gu Zheng
---
arch/ia64/kernel/acpi.c |2 +-
arch/x86/include/asm/mpspec.h |1 +
arch/x86/kernel/acpi/boot.c |8 +--
arch/x86/kernel/apic/apic.c | 71 +++
arch/x86/mm/numa.c| 20
drivers/acpi/acpi_processor.c |2 +-
drivers/acpi/bus.c|3 +
drivers/acpi/processor_core.c | 108 ++--
include/linux/acpi.h |2 +
9 files changed, 162 insertions(+), 55 deletions(-)
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 2c44989..e7958f8 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -796,7 +796,7 @@ int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
* ACPI based hotplug CPU support
*/
#ifdef CONFIG_ACPI_HOTPLUG_CPU
-static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
/*
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index b07233b..db902d8 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -86,6 +86,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
#endif
int generic_processor_info(int apicid, int version);
+int __generic_processor_info(int apicid, int version, bool enabled);
#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_LOCAL_APIC)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 803b684..b084cc0 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -174,15 +174,13 @@ static int acpi_register_lapic(int id, u8 enabled)
return -EINVAL;
}
- if (!enabled) {
+ if (!enabled)
++disabled_cpus;
- return -EINVAL;
- }
if (boot_cpu_physical_apicid != -1U)
ver = apic_version[boot_cpu_physical_apicid];
- return generic_processor_info(id, ver);
+ return __generic_processor_info(id, ver, enabled);
}
static int __init
@@ -726,7 +724,7 @@ static void __init acpi_set_irq_model_ioapic(void)
#ifdef CONFIG_ACPI_HOTPLUG_CPU
#include
-static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
int nid;
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index dcb5285..7fbf2cb 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1977,7 +1977,38 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
-int generic_processor_info(int apicid, int version)
+/*
+ * Logic cpu number(cpuid) to local APIC id persistent mappings.
+ * Do not clear the mapping even if cpu hot removed.
+ * */
+static int apicid_to_cpuid[] = {
+ [0 ... NR_CPUS - 1] = -1,
+};
+
+/*
+ * Internal cpu id bits, set the bit once cpu present, and never clear it.
+ * */
+static cpumask_t cpuid_mask = CPU_MASK_NONE;
+
+static int get_cpuid(int apicid)
+{
+ int free_id, i;
+
+ free_id = cpumask_next_zero(-1, &cpuid_mask);
+ if (free_id >= nr_cpu_ids)
+ return -1;
+
+ for (i = 0; i < free_id; i++)
+ if (apicid_to_cpuid[i] == apicid)
+ return i;
+
+ apicid_to_cpuid[free_id] = apicid;
+ cpumask_set_cpu(free_id, &cpuid_mask);
+
+ return free_id;
+}
+
+int __generic_processor_info(int apicid, int version,
[PATCH 2/2] ARM: dts: tegra: Use labels for overriding nodes in Tegra114 boards
Usage of labels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/tegra114-dalmore.dts | 2210
arch/arm/boot/dts/tegra114-roth.dts| 1945 ++--
arch/arm/boot/dts/tegra114-tn7.dts | 459 ---
3 files changed, 2307 insertions(+), 2307 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
b/arch/arm/boot/dts/tegra114-dalmore.dts
index 8b7aa0dcdc6e..c85129897472 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -22, +22,6 @@
reg = <0x8000 0x4000>;
};
- host1x@5000 {
- hdmi@5428 {
- status = "okay";
-
- hdmi-supply = <&vdd_5v0_hdmi>;
- vdd-supply = <&vdd_hdmi_reg>;
- pll-supply = <&palmas_smps3_reg>;
-
- nvidia,ddc-i2c-bus = <&hdmi_ddc>;
- nvidia,hpd-gpio =
- <&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
- };
-
- dsi@5430 {
- status = "okay";
-
- avdd-dsi-csi-supply = <&avdd_1v2_reg>;
-
- panel@0 {
- compatible = "panasonic,vvx10f004b00",
-"simple-panel";
- reg = <0>;
-
- power-supply = <&avdd_lcd_reg>;
- backlight = <&backlight>;
- };
- };
- };
-
- pinmux@7868 {
- pinctrl-names = "default";
- pinctrl-0 = <&state_default>;
-
- state_default: pinmux {
- clk1_out_pw4 {
- nvidia,pins = "clk1_out_pw4";
- nvidia,function = "extperiph1";
- nvidia,pull = ;
- nvidia,tristate = ;
- nvidia,enable-input = ;
- };
- dap1_din_pn1 {
- nvidia,pins = "dap1_din_pn1";
- nvidia,function = "i2s0";
- nvidia,pull = ;
- nvidia,tristate = ;
- nvidia,enable-input = ;
- };
- dap1_dout_pn2 {
- nvidia,pins = "dap1_dout_pn2",
- "dap1_fs_pn0",
- "dap1_sclk_pn3";
- nvidia,function = "i2s0";
- nvidia,pull = ;
- nvidia,tristate = ;
- nvidia,enable-input = ;
- };
- dap2_din_pa4 {
- nvidia,pins = "dap2_din_pa4";
- nvidia,function = "i2s1";
- nvidia,pull = ;
- nvidia,tristate = ;
- nvidia,enable-input = ;
- };
- dap2_dout_pa5 {
- nvidia,pins = "dap2_dout_pa5",
- "dap2_fs_pa2",
- "dap2_sclk_pa3";
- nvidia,function = "i2s1";
- nvidia,pull = ;
- nvidia,tristate = ;
- nvidia,enable-input = ;
- };
- dap4_din_pp5 {
- nvidia,pins = "dap4_din_pp5",
- "dap4_dout_pp6",
- "dap4_fs_pp4",
- "dap4_sclk_pp7";
- nvidia,function = "i2s3";
- nvidia,pull = ;
- nvidia,tristate = ;
- nvidia,enable-input = ;
- };
- dvfs_pwm_px0 {
- nvidia,pins = "dvfs_pwm_px0",
- "dvfs_clk_px2";
- nvidia,function = "cldvfs";
- nvidia,pull = ;
- nvidia,tristate = ;
- nvidia,enable-input = ;
- };
- ulpi_clk_py0 {
- nvidia,pins = "ulpi_clk_py0",
- "ulpi_data0_po1",
- "ulpi_data
Re: [RFC 1/4] fs: Add generic file system event notifications
On 04/17/2015 01:31 PM, Jan Kara wrote: > On Wed 15-04-15 09:15:44, Beata Michalska wrote: >> Introduce configurable generic interface for file >> system-wide event notifications to provide file >> systems with a common way of reporting any potential >> issues as they emerge. >> >> The notifications are to be issued through generic >> netlink interface, by a dedicated, for file system >> events, multicast group. The file systems might as >> well use this group to send their own custom messages. >> >> The events have been split into four base categories: >> information, warnings, errors and threshold notifications, >> with some very basic event types like running out of space >> or file system being remounted as read-only. >> >> Threshold notifications have been included to allow >> triggering an event whenever the amount of free space >> drops below a certain level - or levels to be more precise >> as two of them are being supported: the lower and the upper >> range. The notifications work both ways: once the threshold >> level has been reached, an event shall be generated whenever >> the number of available blocks goes up again re-activating >> the threshold. >> >> The interface has been exposed through a vfs. Once mounted, >> it serves as an entry point for the set-up where one can >> register for particular file system events. >> >> Signed-off-by: Beata Michalska > Thanks for the patches! Some comments are below. > >> --- >> Documentation/filesystems/events.txt | 254 +++ >> fs/Makefile |1 + >> fs/events/Makefile |6 + >> fs/events/fs_event.c | 775 >> ++ >> fs/events/fs_event.h | 27 ++ >> fs/events/fs_event_netlink.c | 94 + >> fs/namespace.c |1 + >> include/linux/fs.h |6 +- >> include/linux/fs_event.h | 69 +++ >> include/uapi/linux/fs_event.h| 62 +++ >> include/uapi/linux/genetlink.h |1 + >> net/netlink/genetlink.c |7 +- >> 12 files changed, 1301 insertions(+), 2 deletions(-) >> create mode 100644 Documentation/filesystems/events.txt >> create mode 100644 fs/events/Makefile >> create mode 100644 fs/events/fs_event.c >> create mode 100644 fs/events/fs_event.h >> create mode 100644 fs/events/fs_event_netlink.c >> create mode 100644 include/linux/fs_event.h >> create mode 100644 include/uapi/linux/fs_event.h >> >> diff --git a/Documentation/filesystems/events.txt >> b/Documentation/filesystems/events.txt >> new file mode 100644 >> index 000..c85dd88 >> --- /dev/null >> +++ b/Documentation/filesystems/events.txt >> @@ -0,0 +1,254 @@ >> + >> +Generic file system event notification interface >> + >> +Document created 09 April 2015 by Beata Michalska >> + >> +1. The reason behind: >> += >> + >> +There are many corner cases when things might get messy with the >> filesystems. >> +And it is not always obvious what and when went wrong. Sometimes you might >> +get some subtle hints that there is something going on - but by the time >> +you realise it, it might be too late as you are already out-of-space >> +or the filesystem has been remounted as read-only (i.e.). The generic >> +interface for the filesystem events fills the gap by providing a rather >> +easy way of real-time notifications triggered whenever something intreseting >> +happens, allowing filesystems to report events in a common way, as they >> occur. >> + >> +2. How does it work: >> + >> + >> +The interface itself has been exposed as fstrace-type Virtual File System, >> +primarily to ease the process of setting up the configuration for the file >> +system notifications. So for starters it needs to get mounted (obviously): >> + >> +mount -t fstrace none /sys/fs/events >> + >> +This will unveil the single fstrace filesystem entry - the 'config' file, >> +through which the notification are being set-up. >> + >> +Activating notifications for particular filesystem is as straightforward >> +as writing into the 'config' file. Note that by default all events despite >> +the actual filesystem type are being disregarded. > Is there a reason to have a special filesystem for this? Do you expect > extending it by (many) more files? Why not just creating a file in sysfs or > something like that? No particular reason here - just for possible future extension if needed. I'm totally fine with having a single sysfs entry. > >> +Synopsis of config: >> +-- >> + >> +MOUNT EVENT_TYPE [L1] [L2] >> + >> + MOUNT : the filesystem's mount point > I'm not quite decided but is mountpoint really the right thing to pass > via the interface? They aren't unique (filesystem can be mounted in > multiple places) and more importantly can change over time. So won't it be > better to pass major:minor over the interface? These are stable, unique
Re: [PATCH] Avoid null-pointer access in w1/slaves/w1_therm
Hi 16.04.2015, 15:00, "Thorsten Bschorr" : >> Let's push this patch upstream as a temporal fix until we are ready with the >> new solution. >> Thorsten, does it fix your crash? > > I'm running David's refcounting-patch for about 3 weeks now on my 3.18.y > kernel, and did not observe any problems with it, especially no crash or > dead-lock. David, please send a formal patch to linux-kernel@ and Greg Kroah-Hartman with signed-of and acked-by lines -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: dts: tegra: Add labels to Tegra114 nodes
Add new labels to certain nodes on Tegra114 so they could be easily
referenced by board DTS files.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/tegra114.dtsi | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index f58a3d9d5f13..1b31cefd1047 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -10,7 +10,7 @@
compatible = "nvidia,tegra114";
interrupt-parent = <&lic>;
- host1x@5000 {
+ host1x: host1x@5000 {
compatible = "nvidia,tegra114-host1x", "simple-bus";
reg = <0x5000 0x00028000>;
interrupts = , /* syncpt */
@@ -318,7 +318,7 @@
status = "disabled";
};
- i2c@7000c000 {
+ i2c1: i2c@7000c000 {
compatible = "nvidia,tegra114-i2c";
reg = <0x7000c000 0x100>;
interrupts = ;
@@ -363,7 +363,7 @@
status = "disabled";
};
- i2c@7000c700 {
+ i2c4: i2c@7000c700 {
compatible = "nvidia,tegra114-i2c";
reg = <0x7000c700 0x100>;
interrupts = ;
@@ -378,7 +378,7 @@
status = "disabled";
};
- i2c@7000d000 {
+ i2c5: i2c@7000d000 {
compatible = "nvidia,tegra114-i2c";
reg = <0x7000d000 0x100>;
interrupts = ;
@@ -438,7 +438,7 @@
status = "disabled";
};
- spi@7000da00 {
+ spi4: spi@7000da00 {
compatible = "nvidia,tegra114-spi";
reg = <0x7000da00 0x200>;
interrupts = ;
@@ -500,7 +500,7 @@
status = "disabled";
};
- pmc@7000e400 {
+ pmc: pmc@7000e400 {
compatible = "nvidia,tegra114-pmc";
reg = <0x7000e400 0x400>;
clocks = <&tegra_car TEGRA114_CLK_PCLK>, <&clk32k_in>;
@@ -527,7 +527,7 @@
#iommu-cells = <1>;
};
- ahub@7008 {
+ ahub: ahub@7008 {
compatible = "nvidia,tegra114-ahub";
reg = <0x7008 0x200>,
<0x70080200 0x100>,
@@ -648,7 +648,7 @@
status = "disabled";
};
- sdhci@78000400 {
+ sdhci3: sdhci@78000400 {
compatible = "nvidia,tegra114-sdhci", "nvidia,tegra30-sdhci";
reg = <0x78000400 0x200>;
interrupts = ;
@@ -658,7 +658,7 @@
status = "disabled";
};
- sdhci@78000600 {
+ sdhci4: sdhci@78000600 {
compatible = "nvidia,tegra114-sdhci", "nvidia,tegra30-sdhci";
reg = <0x78000600 0x200>;
interrupts = ;
@@ -668,7 +668,7 @@
status = "disabled";
};
- usb@7d00 {
+ usb1: usb@7d00 {
compatible = "nvidia,tegra30-ehci", "usb-ehci";
reg = <0x7d00 0x4000>;
interrupts = ;
@@ -704,7 +704,7 @@
status = "disabled";
};
- usb@7d008000 {
+ usb3: usb@7d008000 {
compatible = "nvidia,tegra30-ehci", "usb-ehci";
reg = <0x7d008000 0x4000>;
interrupts = ;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables
On Thu, 16 Apr 2015 20:27:00 +0300, subscivan wrote: > On 16.04.15 18:44, Jean Delvare wrote: > > Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit : > >> We cannot be sure that firmware_kobj created at time of dmi_init(). > >> The sources don't oblige you to call it at core level, > >> for instance like it was done for arm64. For x86, dmi_init() can be called > >> before firmware_kobj is created. > > Looking at the code, it seems that firmware_kobj is created very, very > > early in the boot process. In do_basic_setup(), you can see that > > driver_init() (which in turn calls firmware_init(), creating > > firmware_kobj) is called before do_initcalls(). So firmware_kobj must be > > defined before dmi_scan_machine() or dmi_init() is called. > > No. Not must, rather should. See below. > > > Oh, and this wasn't even my point ;-) I'm fine with you checking if > > firmware_kobj is defined. My question was about the dmi_available check > > above. But that question was silly anyway, sorry. I confused > > dmi_available with dmi_initialized. Checking for dmi_available is > > perfectly reasonable, please scratch my objection. > > > >> And if I call it from dmi_init() I suppose > >> I would face an error. As I can't call it in dmi_init I can't be sure that > >> DMI is available at all. So, no, we have to check dmi_available here and > >> call it at subsys layer, where it's supposed to be. > > I can't parse that, I suspect you wrote dmi_init where you actually > > meant dmi_scan_machine? Given how early firmware_kobj is created, I > > think the code currently in dmi_init could in fact go at the end of > > dmi_scan_machine. > > Actually, dmi_scan_machine can be called even earlier. > As I've sad, for x86, it's called before firmware_kobj is created. > > kernel_start() > setup_arch() > dmi_scan_machine() > > And for firmware_init(), as you noticed already: > > start_kernel() > rest_init() > kernel_init() > kernel_init_freeable() > do_basic_setup() > driver_init() > firmware_init() > > Pay attentions that setup_arch() is called much earlier than rest_init(). > So dmi_init couldn't in fact go at the end of dmi_scan_machine. Yeah, you're right, sorry. Somehow I thought that setup_arch was an arch_initcall, but it is not, so I got the order all wrong. -- Jean Delvare SUSE L3 Support -- 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: s3c2416: Use labels for overriding nodes in SMDK2416
Usage of labels instead of full paths reduces possible mistakes when
overriding nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c2416-smdk2416.dts | 86 +-
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/arch/arm/boot/dts/s3c2416-smdk2416.dts
b/arch/arm/boot/dts/s3c2416-smdk2416.dts
index ea92fd69529a..f257926c13b7 100644
--- a/arch/arm/boot/dts/s3c2416-smdk2416.dts
+++ b/arch/arm/boot/dts/s3c2416-smdk2416.dts
@@ -31,55 +31,55 @@
#clock-cells = <0>;
};
};
+};
- serial@5000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_data>, <&uart0_fctl>;
- };
+&rtc {
+ status = "okay";
+};
- serial@50004000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_data>, <&uart1_fctl>;
- };
+&sdhci_0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd1_clk>, <&sd1_cmd>,
+ <&sd1_bus1>, <&sd1_bus4>;
+ bus-width = <4>;
+ broken-cd;
+ status = "okay";
+};
- serial@50008000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&uart2_data>;
- };
+&sdhci_1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd0_clk>, <&sd0_cmd>,
+ <&sd0_bus1>, <&sd0_bus4>;
+ bus-width = <4>;
+ cd-gpios = <&gpf 1 0>;
+ cd-inverted;
+ status = "okay";
+};
- serial@5000C000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&uart3_data>;
- };
+&uart_0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_data>, <&uart0_fctl>;
+};
- watchdog@5300 {
- status = "okay";
- };
+&uart_1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_data>, <&uart1_fctl>;
+};
- rtc@5700 {
- status = "okay";
- };
+&uart_2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_data>;
+};
- sdhci@4AC0 {
- pinctrl-names = "default";
- pinctrl-0 = <&sd0_clk>, <&sd0_cmd>,
- <&sd0_bus1>, <&sd0_bus4>;
- bus-width = <4>;
- cd-gpios = <&gpf 1 0>;
- cd-inverted;
- status = "okay";
- };
+&uart_3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_data>;
+};
- sdhci@4A80 {
- pinctrl-names = "default";
- pinctrl-0 = <&sd1_clk>, <&sd1_cmd>,
- <&sd1_bus1>, <&sd1_bus4>;
- bus-width = <4>;
- broken-cd;
- status = "okay";
- };
+&watchdog {
+ status = "okay";
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
Hi Boris, On 17/04/2015 10:39, Boris Brezillon wrote: > On Fri, 17 Apr 2015 10:33:56 +0200 > Boris Brezillon wrote: > >> Hi Jason, >> >> On Mon, 13 Apr 2015 20:11:46 + >> Jason Cooper wrote: >> > I'd appreciate if we'd look into it. I understand from on-list and > off-list discussion that the rewrite was unavoidable. So I'm willing to > concede that. Giving people time to migrate from old to new while still > being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? >>> >>> I say keep it simple. We shouldn't use the DT changes to trigger one >>> vice the other. We need to be able to build both, but only load one at >>> a time. If that's anything other than simple to do, then we make it a >>> Kconfig binary choice and move on. >> >> Actually I was planning to handle it with a Kconfig dependency rule >> (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends >> on !NEW_DRIVER). >> I don't know how to make it a runtime check without adding new >> compatible strings for the kirkwood, dove and orion platforms, and I'm >> sure sure this is a good idea. > ^ not > >> Do you have any ideas ? You use devm_ioremap_resource() in the new driver, so if the old one is already loaded the memory region will be already hold and the new driver will simply fail during the probe. So for this part it is OK. However, the old driver doesn't try to reserve the region, it directly uses an ioremap(). So if the new driver is loaded first, then the old one will manage to be loaded too. I think that just adding a request_region()/release_region() (or converting the ioremap in a devm_ioremap_resource() in the old driver would be enough. Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: dts: s3c2416: Add labels to S3C2416 nodes
Add new labels to certain nodes on S3C2416 so they could be easily
referenced by board DTS files.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c2416.dtsi | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
index 30b8f7e47454..a5184ff56933 100644
--- a/arch/arm/boot/dts/s3c2416.dtsi
+++ b/arch/arm/boot/dts/s3c2416.dtsi
@@ -17,7 +17,7 @@
compatible = "samsung,s3c2416";
aliases {
- serial3 = &uart3;
+ serial3 = &uart_3;
};
cpus {
@@ -48,7 +48,7 @@
clock-names = "timers";
};
- serial@5000 {
+ uart_0: serial@5000 {
compatible = "samsung,s3c2440-uart";
clock-names = "uart", "clk_uart_baud2",
"clk_uart_baud3";
@@ -56,7 +56,7 @@
<&clocks SCLK_UART>;
};
- serial@50004000 {
+ uart_1: serial@50004000 {
compatible = "samsung,s3c2440-uart";
clock-names = "uart", "clk_uart_baud2",
"clk_uart_baud3";
@@ -64,7 +64,7 @@
<&clocks SCLK_UART>;
};
- serial@50008000 {
+ uart_2: serial@50008000 {
compatible = "samsung,s3c2440-uart";
clock-names = "uart", "clk_uart_baud2",
"clk_uart_baud3";
@@ -72,7 +72,7 @@
<&clocks SCLK_UART>;
};
- uart3: serial@5000C000 {
+ uart_3: serial@5000C000 {
compatible = "samsung,s3c2440-uart";
reg = <0x5000C000 0x4000>;
interrupts = <1 18 24 4>, <1 18 25 4>;
@@ -83,7 +83,7 @@
status = "disabled";
};
- sdhci@4AC0 {
+ sdhci_1: sdhci@4AC0 {
compatible = "samsung,s3c6410-sdhci";
reg = <0x4AC0 0x100>;
interrupts = <0 0 21 3>;
@@ -94,7 +94,7 @@
status = "disabled";
};
- sdhci@4A80 {
+ sdhci_0: sdhci@4A80 {
compatible = "samsung,s3c6410-sdhci";
reg = <0x4A80 0x100>;
interrupts = <0 0 20 3>;
@@ -105,13 +105,13 @@
status = "disabled";
};
- watchdog@5300 {
+ watchdog: watchdog@5300 {
interrupts = <1 9 27 3>;
clocks = <&clocks PCLK_WDT>;
clock-names = "watchdog";
};
- rtc@5700 {
+ rtc: rtc@5700 {
compatible = "samsung,s3c2416-rtc";
clocks = <&clocks PCLK_RTC>;
clock-names = "rtc";
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] parisc: Replace PT_NLEVELS with CONFIG_PGTABLE_LEVELS
On Wed, Apr 15, 2015 at 01:34:28PM -0700, Guenter Roeck wrote:
> The following warning is seen when compiling parisc images
>
> ./arch/parisc/include/asm/pgalloc.h: In function 'pgd_alloc':
> ./arch/parisc/include/asm/pgalloc.h:29:5: warning: "PT_NLEVELS" is not defined
>
> Some definitions of PT_NLEVELS were missed with the conversion to
> CONFIG_PGTABLE_LEVELS.
>
> Fixes: f24ffde43237 ("parisc: expose number of page table levels
> on Kconfig level")
> Cc: Kirill A. Shutemov
> Signed-off-by: Guenter Roeck
Acked-by: Kirill A. Shutemov
--
Kirill A. Shutemov
--
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 V6 4/6] perf, x86: handle multiple records in PEBS buffer
> > > > A) the CTRn value reaches 0: > > - the corresponding bit in GLOBAL_STATUS gets set > > - we start arming the hardware assist > > > > < some unspecified amount of time later -- > > this could cover multiple events of interest > > > > > B) the hardware assist is armed, any next event will trigger it > > > > C) a matching event happens: > > - the hardware assist triggers and generates a PEBS record > > this includes a copy of GLOBAL_STATUS at this moment > > - if we auto-reload we (re)set CTRn > > Is this actually true? Do we reload here or on A ? > Yes, on C. According to SDM Volume 3, 18.7.1.1, the reset value will be loaded after each PEBS record is written, which is done by hw assist. > > - we clear the relevant bit in GLOBAL_STATUS -- 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] firmware: dmi_scan: rename dmi_table to dmi_decode_table
On Fri, 17 Apr 2015 15:04:23 +0300, Ivan.khoronzhuk wrote: > On 17.04.15 13:11, Ivan.khoronzhuk wrote: > > On 17.04.15 11:54, Jean Delvare wrote: > >> I have no formal tree yet, but my current patch set can be seen at: > >> http://jdelvare.nerim.net/devel/linux-3/jdelvare-dmi/ > >> > >> First 2 patches from you are already upstream. You should rebase your > >> updated patch series on top of upstream + patches 03 and 04, as they > >> will go in first. > > > > Not sure that's a good idea to base on patches that doesn't path any > > review and > > no one cannot apply. At least it be good you send them that I can > > point on them in > > commit message. > > Don't know why your patches don't apply on top of linux next. > They looks w/o conflicts. I've applied them by hand. To avoid mess, > could you > please send them in order I can refer on them in my commit message. Sorry, I had the the whitespace wrong when backporting one of your two old patches, so I ended up with a code base different from what upstream has. It's all fixed now, you can download the patches again and they should apply fine (starting from 01 if working with kernel v4.0, starting from 03 if working with linux-next.) Sorry for the trouble. The reason why my patch series is based on v4.0 and not linux-next is that I'm going to test it on a remote development system which implements SMBIOS 3.0 and is currently running kernel v4.0, so I don't want to use an unstable code base which could cause problems by itself. -- Jean Delvare SUSE L3 Support -- 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] First batch of KVM changes for 4.1
On 17/04/2015 12:55, Peter Zijlstra wrote:
> Also, it looks like you already do exactly this for other things, look
> at:
>
> kvm_sched_in()
> kvm_arch_vcpu_load()
> if (unlikely(vcpu->cpu != cpu) ... )
>
> So no, I don't believe for one second you need this.
You're missing that this snippet is running in the host, while this
patch is concerned with the guest (paravirt).
This notifier runs for _all_ tasks, not just for the KVM threads. In
fact there will most likely be no KVM in the guest.
There is no vcpu->cpu where this notifier is run.
And frankly, I think the static key is snake oil. The cost of task
migration in terms of cache misses and TLB misses is in no way
comparable to the cost of filling in a structure on the stack,
dereferencing the head of the notifiers list and seeing that it's NULL.
If this was a real problem, it would be better solved by adding
inlining in kernel/notifier.c:
diff --git a/kernel/notifier.c b/kernel/notifier.c
index ae9fc7cc360e..9c0cd0f739e0 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -59,28 +59,14 @@ static int notifier_chain_unregister(struct notifier_block
**nl,
return -ENOENT;
}
-/**
- * notifier_call_chain - Informs the registered notifiers about an event.
- * @nl:Pointer to head of the blocking notifier chain
- * @val: Value passed unmodified to notifier function
- * @v: Pointer passed unmodified to notifier function
- * @nr_to_call:Number of notifier functions to be called. Don't care
- * value of this parameter is -1.
- * @nr_calls: Records the number of notifications sent. Don't care
- * value of this field is NULL.
- * @returns: notifier_call_chain returns the value returned by the
- * last notifier function called.
- */
-static int notifier_call_chain(struct notifier_block **nl,
- unsigned long val, void *v,
- int nr_to_call, int *nr_calls)
+static int __notifier_call_chain(struct notifier_block *nb,
+unsigned long val, void *v,
+int nr_to_call, int *nr_calls)
{
int ret = NOTIFY_DONE;
- struct notifier_block *nb, *next_nb;
-
- nb = rcu_dereference_raw(*nl);
+ struct notifier_block *next_nb;
- while (nb && nr_to_call) {
+ do {
next_nb = rcu_dereference_raw(nb->next);
#ifdef CONFIG_DEBUG_NOTIFIERS
@@ -94,14 +80,38 @@ static int notifier_call_chain(struct notifier_block **nl,
if (nr_calls)
(*nr_calls)++;
-
- if ((ret & NOTIFY_STOP_MASK) == NOTIFY_STOP_MASK)
- break;
- nb = next_nb;
- nr_to_call--;
- }
+ } while (!(ret & NOTIFY_STOP_MASK) &&
+(nb = next_nb) != NULL &&
+--nr_to_call);
return ret;
}
+NOKPROBE_SYMBOL(__notifier_call_chain);
+
+/**
+ * notifier_call_chain - Informs the registered notifiers about an event.
+ * @nl:Pointer to head of the blocking notifier chain
+ * @val: Value passed unmodified to notifier function
+ * @v: Pointer passed unmodified to notifier function
+ * @nr_to_call:Number of notifier functions to be called. Don't care
+ * value of this parameter is -1.
+ * @nr_calls: Records the number of notifications sent. Don't care
+ * value of this field is NULL.
+ * @returns: notifier_call_chain returns the value returned by the
+ * last notifier function called.
+ */
+static __always_inline int notifier_call_chain(struct notifier_block **nl,
+ unsigned long val, void *v,
+ int nr_to_call, int *nr_calls)
+{
+ struct notifier_block *nb = rcu_dereference_raw(*nl);
+ if (unlikely(nr_to_call == 0))
+ return NOTIFY_DONE;
+
+ if (!nb)
+ return NOTIFY_DONE;
+
+ return __notifier_call_chain(nb, val, v, nr_to_call, nr_calls);
+}
NOKPROBE_SYMBOL(notifier_call_chain);
/*
@@ -190,7 +199,12 @@ NOKPROBE_SYMBOL(__atomic_notifier_call_chain);
int atomic_notifier_call_chain(struct atomic_notifier_head *nh,
unsigned long val, void *v)
{
- return __atomic_notifier_call_chain(nh, val, v, -1, NULL);
+ int ret;
+
+ rcu_read_lock();
+ ret = notifier_call_chain(&nh->head, val, v, -1, NULL);
+ rcu_read_unlock();
+ return ret;
}
EXPORT_SYMBOL_GPL(atomic_notifier_call_chain);
NOKPROBE_SYMBOL(atomic_notifier_call_chain);
Also, move enough stuff to a header so that the fast path is inlined to
a single pointer derefrence.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
Re: [PATCH v3 1/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver
On 17/04/15 13:37, Duc Dang wrote:
> On Fri, Apr 17, 2015 at 3:17 AM, Marc Zyngier wrote:
>> On 17/04/15 11:00, Duc Dang wrote:
>>> On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier wrote:
On Tue, 14 Apr 2015 19:20:19 +0100
Duc Dang wrote:
> On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier
> wrote:
>> On 2015-04-11 00:42, Duc Dang wrote:
>>>
>>> On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier
>>> wrote:
On 09/04/15 18:05, Duc Dang wrote:
>
> X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
> 16 HW IRQ lines.
>
> Signed-off-by: Duc Dang
> Signed-off-by: Tanmay Inamdar
> ---
> drivers/pci/host/Kconfig | 6 +
> drivers/pci/host/Makefile| 1 +
> drivers/pci/host/pci-xgene-msi.c | 407
> +++
> drivers/pci/host/pci-xgene.c | 21 ++
> 4 files changed, 435 insertions(+)
> create mode 100644 drivers/pci/host/pci-xgene-msi.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 7b892a9..c9b61fa 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -89,11 +89,17 @@ config PCI_XGENE
> depends on ARCH_XGENE
> depends on OF
> select PCIEPORTBUS
> + select PCI_MSI_IRQ_DOMAIN if PCI_MSI
> + select PCI_XGENE_MSI if PCI_MSI
> help
> Say Y here if you want internal PCI support on APM
> X-Gene SoC. There are 5 internal PCIe ports available. Each port
> is GEN3 capable
> and have varied lanes from x1 to x8.
>
> +config PCI_XGENE_MSI
> + bool "X-Gene v1 PCIe MSI feature"
> + depends on PCI_XGENE && PCI_MSI
> +
> config PCI_LAYERSCAPE
> bool "Freescale Layerscape PCIe controller"
> depends on OF && ARM
> diff --git a/drivers/pci/host/Makefile
> b/drivers/pci/host/Makefile index e61d91c..f39bde3 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -11,5 +11,6 @@ obj-$(CONFIG_PCIE_SPEAR13XX) +=
> pcie-spear13xx.o obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o
> pci-keystone.o obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
> obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
> +obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
> obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
> obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
> diff --git a/drivers/pci/host/pci-xgene-msi.c
> b/drivers/pci/host/pci-xgene-msi.c
> new file mode 100644
> index 000..4f0ff42
> --- /dev/null
> +++ b/drivers/pci/host/pci-xgene-msi.c
> @@ -0,0 +1,407 @@
> +/*
> + * APM X-Gene MSI Driver
> + *
> + * Copyright (c) 2014, Applied Micro Circuits Corporation
> + * Author: Tanmay Inamdar
> + *Duc Dang
> + *
> + * This program is free software; you can redistribute it
> and/or modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License,
> or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be
> useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty
> of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MSI_INDEX0 0x00
> +#define MSI_INT0 0x80
> +
> +struct xgene_msi_settings {
> + u32 index_per_group;
> + u32 irqs_per_index;
> + u32 nr_msi_vec;
> + u32 nr_hw_irqs;
> +};
> +
> +struct xgene_msi {
> + struct device_node *node;
> + struct msi_controller mchip;
> + struct irq_domain *domain;
> + struct xgene_msi_settings *settings;
> + u32 msi_addr_lo;
> + u32 msi_addr_hi;
I'd rather see the mailbox address directly, and only do the
split when assigning it to the message (you seem to play all kind
of tricks on the address anyway).
>>>
>>>
>>> msi_addr_lo
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
Am 17.04.2015 um 14:17 schrieb Christoph Lameter: > On Fri, 17 Apr 2015, Hajime Tazaki wrote: > >> add header includion for CONFIG_LIB to wrap kmalloc and co. This will >> bring malloc(3) based allocator used by arch/lib. > > Maybe add another allocator insteadl? SLLB which implements memory > management using malloc()? Yeah, that's a good idea. Hajime, another question, do you really want a malloc/free backend? I'm not a mm expert, but does malloc() behave exactly as the kernel counter parts? In UML we allocate a big file on the host side, mmap() it and give this mapping to the kernel as physical memory such that any kernel allocator can work with it. Thanks, //richard -- 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] tpm: enable PPI for TPM 2.0
On Thu, Apr 16, 2015 at 06:54:39PM +0300, Jarkko Sakkinen wrote:
> Added PPI interface to the character device sysfs directory accessible
> both for 1.x and 2.0 devices.
>
> In order to maintain backwards compatibility when using 1.x devices,
> symlink is created from the pdev to the PPI directory. For this reason
> we need to export kernfs_create_link() and kernfs_remove_by_name_ns().
>
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Jason Gunthorpe
> ---
> drivers/char/tpm/tpm-chip.c | 28
> drivers/char/tpm/tpm.h | 14 +-
> drivers/char/tpm/tpm_ppi.c | 34 +++---
> fs/kernfs/dir.c | 1 +
> fs/kernfs/symlink.c | 1 +
> 5 files changed, 38 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index 283f00a..34930ef 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include "tpm.h"
> #include "tpm_eventlog.h"
>
> @@ -119,6 +120,9 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
> chip->dev.class = tpm_class;
> chip->dev.release = tpm_dev_release;
> chip->dev.parent = chip->pdev;
> +#ifdef CONFIG_ACPI
> + chip->dev.groups = chip->groups;
> +#endif
>
> if (chip->dev_num == 0)
> chip->dev.devt = MKDEV(MISC_MAJOR, TPM_MINOR);
> @@ -181,12 +185,6 @@ static int tpm1_chip_register(struct tpm_chip *chip)
> if (rc)
> return rc;
>
> - rc = tpm_add_ppi(chip);
> - if (rc) {
> - tpm_sysfs_del_device(chip);
> - return rc;
> - }
> -
> chip->bios_dir = tpm_bios_log_setup(chip->devname);
>
> return 0;
> @@ -200,8 +198,6 @@ static void tpm1_chip_unregister(struct tpm_chip *chip)
> if (chip->bios_dir)
> tpm_bios_log_teardown(chip->bios_dir);
>
> - tpm_remove_ppi(chip);
> -
> tpm_sysfs_del_device(chip);
> }
>
> @@ -218,16 +214,29 @@ static void tpm1_chip_unregister(struct tpm_chip *chip)
> */
> int tpm_chip_register(struct tpm_chip *chip)
> {
> + struct kernfs_node *target;
> + struct kernfs_node *link;
> int rc;
>
> rc = tpm1_chip_register(chip);
> if (rc)
> return rc;
>
> + tpm_add_ppi(chip);
> +
> rc = tpm_dev_add_device(chip);
> if (rc)
> goto out_err;
>
> + if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
> + target = kernfs_find_and_get(chip->dev.kobj.sd, "ppi");
Check that valid node was returned.
> + link = kernfs_create_link(chip->pdev->kobj.sd, "ppi", target);
> + if (IS_ERR(link)) {
> + rc = PTR_ERR(link);
> + goto out_err;
> + }
Oops, kernfs_put() missing from the patch.
> + }
> +
> /* Make the chip available. */
> spin_lock(&driver_lock);
> list_add_rcu(&chip->list, &tpm_chip_list);
> @@ -262,6 +271,9 @@ void tpm_chip_unregister(struct tpm_chip *chip)
> spin_unlock(&driver_lock);
> synchronize_rcu();
>
> + if (!(chip->flags & TPM_CHIP_FLAG_TPM2))
> + kernfs_remove_by_name(chip->pdev->kobj.sd, "ppi");
> +
> tpm1_chip_unregister(chip);
> tpm_dev_del_device(chip);
> }
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index f8319a0..bbb1fae 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -175,6 +175,8 @@ struct tpm_chip {
> struct dentry **bios_dir;
>
> #ifdef CONFIG_ACPI
> + const struct attribute_group *groups[2];
> + unsigned int groups_cnt;
> acpi_handle acpi_dev_handle;
> char ppi_version[TPM_PPI_VERSION_LEN + 1];
> #endif /* CONFIG_ACPI */
> @@ -182,7 +184,7 @@ struct tpm_chip {
> struct list_head list;
> };
>
> -#define to_tpm_chip(n) container_of(n, struct tpm_chip, vendor)
> +#define to_tpm_chip(n) container_of(dev, struct tpm_chip, dev)
>
> static inline void tpm_chip_put(struct tpm_chip *chip)
> {
> @@ -412,15 +414,9 @@ void tpm_sysfs_del_device(struct tpm_chip *chip);
> int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, u8 *res_buf);
>
> #ifdef CONFIG_ACPI
> -extern int tpm_add_ppi(struct tpm_chip *chip);
> -extern void tpm_remove_ppi(struct tpm_chip *chip);
> +extern void tpm_add_ppi(struct tpm_chip *chip);
> #else
> -static inline int tpm_add_ppi(struct tpm_chip *chip)
> -{
> - return 0;
> -}
> -
> -static inline void tpm_remove_ppi(struct tpm_chip *chip)
> +static inline void tpm_add_ppi(struct tpm_chip *chip)
> {
> }
> #endif
> diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
> index 6ca9b5d..692a2c6 100644
> --- a/drivers/char/tpm/tpm_ppi.c
> +++ b/drivers/char/tpm/tpm_ppi.c
> @@ -53,7 +53,7 @@ tpm_eval_dsm(acpi_handle ppi_handle, int func,
> acpi_object_type type,
> static ssize_t tpm_show_ppi_version(struct device *dev,
>
Re: [PATCH v3 1/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver
On Fri, Apr 17, 2015 at 3:17 AM, Marc Zyngier wrote:
> On 17/04/15 11:00, Duc Dang wrote:
>> On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier wrote:
>>> On Tue, 14 Apr 2015 19:20:19 +0100
>>> Duc Dang wrote:
>>>
On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier
wrote:
> On 2015-04-11 00:42, Duc Dang wrote:
>>
>> On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier
>> wrote:
>>>
>>> On 09/04/15 18:05, Duc Dang wrote:
X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
16 HW IRQ lines.
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
drivers/pci/host/Kconfig | 6 +
drivers/pci/host/Makefile| 1 +
drivers/pci/host/pci-xgene-msi.c | 407
+++
drivers/pci/host/pci-xgene.c | 21 ++
4 files changed, 435 insertions(+)
create mode 100644 drivers/pci/host/pci-xgene-msi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 7b892a9..c9b61fa 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -89,11 +89,17 @@ config PCI_XGENE
depends on ARCH_XGENE
depends on OF
select PCIEPORTBUS
+ select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+ select PCI_XGENE_MSI if PCI_MSI
help
Say Y here if you want internal PCI support on APM
X-Gene SoC. There are 5 internal PCIe ports available. Each port
is GEN3 capable
and have varied lanes from x1 to x8.
+config PCI_XGENE_MSI
+ bool "X-Gene v1 PCIe MSI feature"
+ depends on PCI_XGENE && PCI_MSI
+
config PCI_LAYERSCAPE
bool "Freescale Layerscape PCIe controller"
depends on OF && ARM
diff --git a/drivers/pci/host/Makefile
b/drivers/pci/host/Makefile index e61d91c..f39bde3 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -11,5 +11,6 @@ obj-$(CONFIG_PCIE_SPEAR13XX) +=
pcie-spear13xx.o obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o
pci-keystone.o obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
+obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
diff --git a/drivers/pci/host/pci-xgene-msi.c
b/drivers/pci/host/pci-xgene-msi.c
new file mode 100644
index 000..4f0ff42
--- /dev/null
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -0,0 +1,407 @@
+/*
+ * APM X-Gene MSI Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Tanmay Inamdar
+ *Duc Dang
+ *
+ * This program is free software; you can redistribute it
and/or modify it
+ * under the terms of the GNU General Public License as
published by the
+ * Free Software Foundation; either version 2 of the License,
or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be
useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty
of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MSI_INDEX0 0x00
+#define MSI_INT0 0x80
+
+struct xgene_msi_settings {
+ u32 index_per_group;
+ u32 irqs_per_index;
+ u32 nr_msi_vec;
+ u32 nr_hw_irqs;
+};
+
+struct xgene_msi {
+ struct device_node *node;
+ struct msi_controller mchip;
+ struct irq_domain *domain;
+ struct xgene_msi_settings *settings;
+ u32 msi_addr_lo;
+ u32 msi_addr_hi;
>>>
>>>
>>> I'd rather see the mailbox address directly, and only do the
>>> split when assigning it to the message (you seem to play all kind
>>> of tricks on the address anyway).
>>
>>
>> msi_addr_lo and msi_addr_hi store the physical base address of MSI
>> controller registers. I will add comment to clarify this.
>
>
> What I mean is that the
[PATCH 5/5] MIPS: ath79: Improve the DDR controller interface
The DDR controller need to be used by the IRQ controller to flush
the write buffer of some devices before running the IRQ handler.
It is also used by the PCI controller to setup the PCI memory windows.
The current interface used to access the DDR controller doesn't
provides any useful abstraction and simply rely on a shared global
pointer.
Replace this by a simple API to setup the PCI memory windows and use
the write buffer flush independently of the SoC type. That remove the
need for the shared global pointer, simplify the IRQ handler code.
Signed-off-by: Alban Bedel
---
arch/mips/ath79/common.c | 32 ++-
arch/mips/ath79/common.h | 1 +
arch/mips/ath79/irq.c| 147 +++
arch/mips/ath79/setup.c | 3 +-
arch/mips/include/asm/mach-ath79/ath79.h | 3 +-
arch/mips/pci/pci-ar71xx.c | 10 +--
6 files changed, 68 insertions(+), 128 deletions(-)
diff --git a/arch/mips/ath79/common.c b/arch/mips/ath79/common.c
index eb3966c..61022b6 100644
--- a/arch/mips/ath79/common.c
+++ b/arch/mips/ath79/common.c
@@ -38,11 +38,27 @@ unsigned int ath79_soc_rev;
void __iomem *ath79_pll_base;
void __iomem *ath79_reset_base;
EXPORT_SYMBOL_GPL(ath79_reset_base);
-void __iomem *ath79_ddr_base;
+static void __iomem *ath79_ddr_base;
+static void __iomem *ath79_ddr_wb_flush_base;
+static void __iomem *ath79_ddr_pci_win_base;
+
+void ath79_ddr_ctrl_init(void)
+{
+ ath79_ddr_base = ioremap_nocache(AR71XX_DDR_CTRL_BASE,
+AR71XX_DDR_CTRL_SIZE);
+ if (soc_is_ar71xx() || soc_is_ar934x()) {
+ ath79_ddr_wb_flush_base = ath79_ddr_base + 0x9c;
+ ath79_ddr_pci_win_base = ath79_ddr_base + 0x7c;
+ } else {
+ ath79_ddr_wb_flush_base = ath79_ddr_base + 0x7c;
+ ath79_ddr_pci_win_base = 0;
+ }
+}
+EXPORT_SYMBOL_GPL(ath79_ddr_ctrl_init);
void ath79_ddr_wb_flush(u32 reg)
{
- void __iomem *flush_reg = ath79_ddr_base + reg;
+ void __iomem *flush_reg = ath79_ddr_wb_flush_base + reg;
/* Flush the DDR write buffer. */
__raw_writel(0x1, flush_reg);
@@ -56,6 +72,18 @@ void ath79_ddr_wb_flush(u32 reg)
}
EXPORT_SYMBOL_GPL(ath79_ddr_wb_flush);
+void ath79_ddr_set_pci_windows(void)
+{
+ unsigned win;
+
+ BUG_ON(!ath79_ddr_pci_win_base);
+
+ for (win = 0; win < AR71XX_PCI_WIN_COUNT ; win++)
+ __raw_writel(AR71XX_PCI_MEM_BASE + win * AR71XX_PCI_WIN_SIZE,
+ ath79_ddr_pci_win_base + win);
+}
+EXPORT_SYMBOL_GPL(ath79_ddr_set_pci_windows);
+
void ath79_device_reset_set(u32 mask)
{
unsigned long flags;
diff --git a/arch/mips/ath79/common.h b/arch/mips/ath79/common.h
index a312071..a14269f 100644
--- a/arch/mips/ath79/common.h
+++ b/arch/mips/ath79/common.h
@@ -22,6 +22,7 @@
void ath79_clocks_init(void);
unsigned long ath79_get_sys_clk_rate(const char *id);
+void ath79_ddr_ctrl_init(void);
void ath79_ddr_wb_flush(unsigned int reg);
void ath79_gpio_function_enable(u32 mask);
diff --git a/arch/mips/ath79/irq.c b/arch/mips/ath79/irq.c
index 6adae36..2c3991a 100644
--- a/arch/mips/ath79/irq.c
+++ b/arch/mips/ath79/irq.c
@@ -24,9 +24,6 @@
#include
#include "common.h"
-static void (*ath79_ip2_handler)(void);
-static void (*ath79_ip3_handler)(void);
-
static void ath79_misc_irq_handler(unsigned int irq, struct irq_desc *desc)
{
void __iomem *base = ath79_reset_base;
@@ -129,10 +126,10 @@ static void ar934x_ip2_irq_dispatch(unsigned int irq,
struct irq_desc *desc)
status = ath79_reset_rr(AR934X_RESET_REG_PCIE_WMAC_INT_STATUS);
if (status & AR934X_PCIE_WMAC_INT_PCIE_ALL) {
- ath79_ddr_wb_flush(AR934X_DDR_REG_FLUSH_PCIE);
+ ath79_ddr_wb_flush(3);
generic_handle_irq(ATH79_IP2_IRQ(0));
} else if (status & AR934X_PCIE_WMAC_INT_WMAC_ALL) {
- ath79_ddr_wb_flush(AR934X_DDR_REG_FLUSH_WMAC);
+ ath79_ddr_wb_flush(4);
generic_handle_irq(ATH79_IP2_IRQ(1));
} else {
spurious_interrupt();
@@ -235,128 +232,50 @@ static void qca955x_irq_init(void)
irq_set_chained_handler(ATH79_CPU_IRQ(3), qca955x_ip3_irq_dispatch);
}
-asmlinkage void plat_irq_dispatch(void)
-{
- unsigned long pending;
-
- pending = read_c0_status() & read_c0_cause() & ST0_IM;
-
- if (pending & STATUSF_IP7)
- do_IRQ(ATH79_CPU_IRQ(7));
-
- else if (pending & STATUSF_IP2)
- ath79_ip2_handler();
-
- else if (pending & STATUSF_IP4)
- do_IRQ(ATH79_CPU_IRQ(4));
-
- else if (pending & STATUSF_IP5)
- do_IRQ(ATH79_CPU_IRQ(5));
-
- else if (pending & STATUSF_IP3)
- ath79_ip3_handler();
-
- else if (pending & STATUSF_IP6)
- do_IRQ(ATH79_CPU_IRQ(6));
-
- else
- spurious_in
[PATCH 4/5] MIPS: ath79: Fix the PCI memory size and offset of window 7
The define AR71XX_PCI_MEM_SIZE miss one window, there is 7 windows, not 6. To make things clearer, and allow simpler code, derive AR71XX_PCI_MEM_SIZE from the newly introduced AR71XX_PCI_WIN_COUNT and AR71XX_PCI_WIN_SIZE. The define AR71XX_PCI_WIN7_OFFS also add a typo, fix it. Signed-off-by: Alban Bedel --- arch/mips/include/asm/mach-ath79/ar71xx_regs.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h index aa3800c..e2669a8 100644 --- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h +++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h @@ -41,7 +41,9 @@ #define AR71XX_RESET_SIZE 0x100 #define AR71XX_PCI_MEM_BASE0x1000 -#define AR71XX_PCI_MEM_SIZE0x0700 +#define AR71XX_PCI_WIN_COUNT 8 +#define AR71XX_PCI_WIN_SIZE0x0100 +#define AR71XX_PCI_MEM_SIZE(AR71XX_PCI_WIN_COUNT * AR71XX_PCI_WIN_SIZE) #define AR71XX_PCI_WIN0_OFFS 0x1000 #define AR71XX_PCI_WIN1_OFFS 0x1100 @@ -50,7 +52,7 @@ #define AR71XX_PCI_WIN4_OFFS 0x1400 #define AR71XX_PCI_WIN5_OFFS 0x1500 #define AR71XX_PCI_WIN6_OFFS 0x1600 -#define AR71XX_PCI_WIN7_OFFS 0x0700 +#define AR71XX_PCI_WIN7_OFFS 0x1700 #define AR71XX_PCI_CFG_BASE\ (AR71XX_PCI_MEM_BASE + AR71XX_PCI_WIN7_OFFS + 0x1) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] MIPS: ath79: Correctly name the defines for the PLL_FB register
This register is named PLL_FB and is not a divider but a multiplier. To make things less confusing rename the AR_PLL_DIV_SHIFT and AR_PLL_DIV_MASK macros to AR_PLL_FB_SHIFT and AR_PLL_FB_MASK. Signed-off-by: Alban Bedel --- arch/mips/ath79/clock.c| 6 +++--- arch/mips/include/asm/mach-ath79/ar71xx_regs.h | 12 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/mips/ath79/clock.c b/arch/mips/ath79/clock.c index 26479f4..226ddf0 100644 --- a/arch/mips/ath79/clock.c +++ b/arch/mips/ath79/clock.c @@ -62,7 +62,7 @@ static void __init ar71xx_clocks_init(void) pll = ath79_pll_rr(AR71XX_PLL_REG_CPU_CONFIG); - div = ((pll >> AR71XX_PLL_DIV_SHIFT) & AR71XX_PLL_DIV_MASK) + 1; + div = ((pll >> AR71XX_PLL_FB_SHIFT) & AR71XX_PLL_FB_MASK) + 1; freq = div * ref_rate; div = ((pll >> AR71XX_CPU_DIV_SHIFT) & AR71XX_CPU_DIV_MASK) + 1; @@ -96,7 +96,7 @@ static void __init ar724x_clocks_init(void) ref_rate = AR724X_BASE_FREQ; pll = ath79_pll_rr(AR724X_PLL_REG_CPU_CONFIG); - div = ((pll >> AR724X_PLL_DIV_SHIFT) & AR724X_PLL_DIV_MASK); + div = ((pll >> AR724X_PLL_FB_SHIFT) & AR724X_PLL_FB_MASK); freq = div * ref_rate; div = ((pll >> AR724X_PLL_REF_DIV_SHIFT) & AR724X_PLL_REF_DIV_MASK); @@ -132,7 +132,7 @@ static void __init ar913x_clocks_init(void) ref_rate = AR913X_BASE_FREQ; pll = ath79_pll_rr(AR913X_PLL_REG_CPU_CONFIG); - div = ((pll >> AR913X_PLL_DIV_SHIFT) & AR913X_PLL_DIV_MASK); + div = ((pll >> AR913X_PLL_FB_SHIFT) & AR913X_PLL_FB_MASK); freq = div * ref_rate; cpu_rate = freq; diff --git a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h index cd41e93..aa3800c 100644 --- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h +++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h @@ -157,8 +157,8 @@ #define AR71XX_PLL_REG_ETH0_INT_CLOCK 0x10 #define AR71XX_PLL_REG_ETH1_INT_CLOCK 0x14 -#define AR71XX_PLL_DIV_SHIFT 3 -#define AR71XX_PLL_DIV_MASK0x1f +#define AR71XX_PLL_FB_SHIFT3 +#define AR71XX_PLL_FB_MASK 0x1f #define AR71XX_CPU_DIV_SHIFT 16 #define AR71XX_CPU_DIV_MASK0x3 #define AR71XX_DDR_DIV_SHIFT 18 @@ -169,8 +169,8 @@ #define AR724X_PLL_REG_CPU_CONFIG 0x00 #define AR724X_PLL_REG_PCIE_CONFIG 0x18 -#define AR724X_PLL_DIV_SHIFT 0 -#define AR724X_PLL_DIV_MASK0x3ff +#define AR724X_PLL_FB_SHIFT0 +#define AR724X_PLL_FB_MASK 0x3ff #define AR724X_PLL_REF_DIV_SHIFT 10 #define AR724X_PLL_REF_DIV_MASK0xf #define AR724X_AHB_DIV_SHIFT 19 @@ -183,8 +183,8 @@ #define AR913X_PLL_REG_ETH0_INT_CLOCK 0x14 #define AR913X_PLL_REG_ETH1_INT_CLOCK 0x18 -#define AR913X_PLL_DIV_SHIFT 0 -#define AR913X_PLL_DIV_MASK0x3ff +#define AR913X_PLL_FB_SHIFT0 +#define AR913X_PLL_FB_MASK 0x3ff #define AR913X_DDR_DIV_SHIFT 22 #define AR913X_DDR_DIV_MASK0x3 #define AR913X_AHB_DIV_SHIFT 19 -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] MIPS: ath79: Add a missing new line in log message
The memory setup log is missing a new line.
Signed-off-by: Alban Bedel
---
arch/mips/ath79/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index a73c93c..7fc8397 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -225,7 +225,7 @@ void __init plat_time_init(void)
ddr_clk_rate = ath79_get_sys_clk_rate("ddr");
ref_clk_rate = ath79_get_sys_clk_rate("ref");
- pr_info("Clocks: CPU:%lu.%03luMHz, DDR:%lu.%03luMHz, AHB:%lu.%03luMHz,
Ref:%lu.%03luMHz",
+ pr_info("Clocks: CPU:%lu.%03luMHz, DDR:%lu.%03luMHz, AHB:%lu.%03luMHz,
Ref:%lu.%03luMHz\n",
cpu_clk_rate / 100, (cpu_clk_rate / 1000) % 1000,
ddr_clk_rate / 100, (ddr_clk_rate / 1000) % 1000,
ahb_clk_rate / 100, (ahb_clk_rate / 1000) % 1000,
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATH] MIPS: ath79: Various small fix to prepare OF support
This first small serie allow using ZBOOT, fix a few errors in the registers definitions and rework the DDR controller interface. The DDR controller interface patch is mostly to simplify the IRQ controller code before adding OF support. Following this will a be serie that add the OF bindings and code support for the core component of the SoC as well as a DTS for the TL-WR1043ND. -- 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/5] MIPS: ath79: Enable ZBOOT support
ZBOOT is working fine, so allow using it. Signed-off-by: Alban Bedel --- arch/mips/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index a326c4c..cc7f262 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -128,6 +128,7 @@ config ATH79 select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_MIPS16 + select SYS_SUPPORTS_ZBOOT help Support for the Atheros AR71XX/AR724X/AR913X SoCs. -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is it OK to export symbols 'getname' and 'putname'?
Hi Al,
On Sun, Apr 12, 2015 at 02:13:18AM +0100, Al Viro wrote:
>
> BTW, looking at the __getname() callers... Lustre one sure as hell looks
> bogus:
> char *tmp = __getname();
>
> if (!tmp)
> return ERR_PTR(-ENOMEM);
>
> len = strncpy_from_user(tmp, filename, PATH_MAX);
> if (len == 0)
> ret = -ENOENT;
> else if (len > PATH_MAX)
> ret = -ENAMETOOLONG;
>
> if (ret) {
> __putname(tmp);
> tmp = ERR_PTR(ret);
> }
> return tmp;
>
> Note that
> * strncpy_from_user(p, u, n) can return a negative (-EFAULT)
> * strncpy_from_user(p, u, n) cannot return a positive greater than
> n. In case of missing NUL among the n bytes starting at u (and no faults
> accessing those) we get exactly n bytes copied and n returned. In case
> when NUL is there, we copy everything up to and including that NUL and
> return number of non-NUL bytes copied.
>
> IOW, these failure cases had never been tested. Name being too long ends up
> with non-NUL-terminated array of characters returned, and the very first
> caller of ll_getname() feeds it to strlen(). Fault ends up with uninitialized
> array...
>
> AFAICS, the damn thing should just use getname() and quit reinventing the
> wheel, badly.
>
I'm trying to clean that part of code you mentioned, and I found I have
to export the symbols 'getname' and 'putname' as follow to replace that
__getname() caller:
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index a182019..014f51a 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1216,29 +1216,8 @@ out:
return rc;
}
-static char *
-ll_getname(const char __user *filename)
-{
- int ret = 0, len;
- char *tmp = __getname();
-
- if (!tmp)
- return ERR_PTR(-ENOMEM);
-
- len = strncpy_from_user(tmp, filename, PATH_MAX);
- if (len == 0)
- ret = -ENOENT;
- else if (len > PATH_MAX)
- ret = -ENAMETOOLONG;
-
- if (ret) {
- __putname(tmp);
- tmp = ERR_PTR(ret);
- }
- return tmp;
-}
-
-#define ll_putname(filename) __putname(filename)
+#define ll_getname(filename) getname(filename)
+#define ll_putname(name) putname(name)
static long ll_dir_ioctl(struct file *file, unsigned int cmd, unsigned long
arg)
{
@@ -1441,6 +1420,7 @@ free_lmv:
return rc;
}
case LL_IOC_REMOVE_ENTRY: {
+ struct filename *name = NULL;
char*filename = NULL;
int namelen = 0;
int rc;
@@ -1453,20 +1433,17 @@ free_lmv:
if (!(exp_connect_flags(sbi->ll_md_exp) & OBD_CONNECT_LVB_TYPE))
return -ENOTSUPP;
- filename = ll_getname((const char *)arg);
- if (IS_ERR(filename))
- return PTR_ERR(filename);
+ name = ll_getname((const char *)arg);
+ if (IS_ERR(name))
+ return PTR_ERR(name);
+ filename = name->name;
namelen = strlen(filename);
- if (namelen < 1) {
- rc = -EINVAL;
- goto out_rmdir;
- }
rc = ll_rmdir_entry(inode, filename, namelen);
out_rmdir:
- if (filename)
- ll_putname(filename);
+ if (name)
+ ll_putname(name);
return rc;
}
case LL_IOC_LOV_SWAP_LAYOUTS:
@@ -1481,15 +1458,17 @@ out_rmdir:
struct lov_user_md *lump;
struct lov_mds_md *lmm = NULL;
struct mdt_body *body;
+ struct filename *name;
char *filename = NULL;
int lmmsize;
if (cmd == IOC_MDC_GETFILEINFO ||
cmd == IOC_MDC_GETFILESTRIPE) {
- filename = ll_getname((const char *)arg);
- if (IS_ERR(filename))
- return PTR_ERR(filename);
+ name = ll_getname((const char *)arg);
+ if (IS_ERR(name))
+ return PTR_ERR(name);
+ filename = name->name;
rc = ll_lov_getstripe_ea_info(inode, filename, &lmm,
&lmmsize, &request);
} else {
diff --git a/fs/namei.c b/fs/namei.c
index ffab2e0..7a0948c 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -205,6 +205,7 @@ getname(const char __user * filename)
{
return getname_flags(filename, 0, NULL);
}
+EXPORT_SYMBOL(getname);
struct filename *
getname_kernel(const char * filename)
@@ -254,6 +255,7 @@ void putnam
[PATCH] mm: fix mprotect() behaviour on VM_LOCKED VMAs
On mlock(2) we trigger COW on private writable VMA to avoid faults in
future.
mm/gup.c:
840 long populate_vma_page_range(struct vm_area_struct *vma,
841 unsigned long start, unsigned long end, int *nonblocking)
842 {
...
855 * We want to touch writable mappings with a write fault in order
856 * to break COW, except for shared mappings because these don't COW
857 * and we would not want to dirty them for nothing.
858 */
859 if ((vma->vm_flags & (VM_WRITE | VM_SHARED)) == VM_WRITE)
860 gup_flags |= FOLL_WRITE;
But we miss this case when we make VM_LOCKED VMA writeable via
mprotect(2). The test case:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define PAGE_SIZE 4096
int main(int argc, char **argv)
{
struct rusage usage;
long before;
char *p;
int fd;
/* Create a file and populate first page of page cache */
fd = open("/tmp", O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR);
write(fd, "1", 1);
/* Create a *read-only* *private* mapping of the file */
p = mmap(NULL, PAGE_SIZE, PROT_READ, MAP_PRIVATE, fd, 0);
/*
* Since the mapping is read-only, mlock() will populate the
mapping
* with PTEs pointing to page cache without triggering COW.
*/
mlock(p, PAGE_SIZE);
/*
* Mapping became read-write, but it's still populated with PTEs
* pointing to page cache.
*/
mprotect(p, PAGE_SIZE, PROT_READ | PROT_WRITE);
getrusage(RUSAGE_SELF, &usage);
before = usage.ru_minflt;
/* Trigger COW: fault in mlock()ed VMA. */
*p = 1;
getrusage(RUSAGE_SELF, &usage);
printf("faults: %ld\n", usage.ru_minflt - before);
return 0;
}
$ ./test
faults: 1
Let's fix it by triggering populating of VMA in mprotect_fixup() on this
condition. We don't care about population error as we don't in other
similar cases i.e. mremap.
Signed-off-by: Kirill A. Shutemov
---
mm/mprotect.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 88584838e704..911fb9070b2b 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -29,6 +29,8 @@
#include
#include
+#include "internal.h"
+
/*
* For a prot_numa update we only hold mmap_sem for read so there is a
* potential race with faulting where a pmd was temporarily none. This
@@ -322,6 +324,15 @@ success:
change_protection(vma, start, end, vma->vm_page_prot,
dirty_accountable, 0);
+ /*
+* Private VM_LOCKED VMA become writable: trigger COW to avoid major
+* fault on access.
+*/
+ if ((oldflags & (VM_WRITE | VM_SHARED | VM_LOCKED)) == VM_LOCKED &&
+ (newflags & VM_WRITE)) {
+ populate_vma_page_range(vma, start, end, NULL);
+ }
+
vm_stat_account(mm, oldflags, vma->vm_file, -nrpages);
vm_stat_account(mm, newflags, vma->vm_file, nrpages);
perf_event_mmap(vma);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 02/11] slab: add private memory allocator header for arch/lib
On Fri, 17 Apr 2015, Hajime Tazaki wrote: > add header includion for CONFIG_LIB to wrap kmalloc and co. This will > bring malloc(3) based allocator used by arch/lib. Maybe add another allocator insteadl? SLLB which implements memory management using malloc()? -- 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/
[RESEND PATCH V2 0/2] Add OnKey support for DA9063
From: S Twiss This patch set adds OnKey driver support for the Dialog Semiconductor DA9063 PMIC. [PATCH V2 1/2]: kernel driver onkey support [PATCH V2 2/2]: device tree bindings document Thank you, Steve Twiss, Dialog Semiconductor Ltd. S Twiss (2): input: misc: da9063: OnKey driver devicetree: Add bindings for DA9063 OnKey Documentation/devicetree/bindings/mfd/da9063.txt | 22 ++- MAINTAINERS | 2 +- drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile | 1 + drivers/input/misc/da9063-onkey.c| 228 +++ drivers/mfd/da9063-core.c| 55 ++ include/linux/mfd/da9063/pdata.h | 1 + 7 files changed, 316 insertions(+), 3 deletions(-) create mode 100644 drivers/input/misc/da9063-onkey.c -- end-of-patch for RESEND PATCH V2 -- 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/
[RESEND PATCH V2 1/2] input: misc: da9063: OnKey driver
From: Steve Twiss
Add OnKey driver support for DA9063
Signed-off-by: Steve Twiss
---
Changes from PATCH V1 to V2
---
- Remove the circular dependency comment in the main e-mail body
linking PATCH V1 1/2 and 2/2
- Alter the copyright header information to match expected GPLv2
text from http://www.gnu.org/licenses/gpl-2.0.html
This patch applies against linux-next and v4.0-rc6
MAINTAINERS | 2 +-
drivers/input/misc/Kconfig| 10 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/da9063-onkey.c | 228 ++
drivers/mfd/da9063-core.c | 55 +
include/linux/mfd/da9063/pdata.h | 1 +
6 files changed, 296 insertions(+), 1 deletion(-)
create mode 100644 drivers/input/misc/da9063-onkey.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1de6afa..97e20cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3138,7 +3138,7 @@ S:Supported
F: Documentation/hwmon/da90??
F: drivers/gpio/gpio-da90??.c
F: drivers/hwmon/da90??-hwmon.c
-F: drivers/input/misc/da90??_onkey.c
+F: drivers/input/misc/da90???onkey.c
F: drivers/input/touchscreen/da9052_tsi.c
F: drivers/leds/leds-da90??.c
F: drivers/mfd/da903x.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6deb8da..9d7a79d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -586,6 +586,16 @@ config INPUT_DA9055_ONKEY
To compile this driver as a module, choose M here: the module
will be called da9055_onkey.
+config INPUT_DA9063_ONKEY
+ tristate "Dialog DA9063 OnKey"
+ depends on MFD_DA9063
+ help
+ Support the ONKEY of Dialog DA9063 Power Management IC as an
+ input device reporting power button statue.
+
+ To compile this driver as a module, choose M here: the module
+ will be called da9063-onkey.
+
config INPUT_DM355EVM
tristate "TI DaVinci DM355 EVM Keypad and IR Remote"
depends on MFD_DM355EVM_MSP
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 403a1a5..50ae57e 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_INPUT_CMA3000_I2C) +=
cma3000_d0x_i2c.o
obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o
obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o
obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o
+obj-$(CONFIG_INPUT_DA9063_ONKEY) += da9063-onkey.o
obj-$(CONFIG_INPUT_DM355EVM) += dm355evm_keys.o
obj-$(CONFIG_INPUT_E3X0_BUTTON)+= e3x0-button.o
obj-$(CONFIG_INPUT_DRV260X_HAPTICS)+= drv260x.o
diff --git a/drivers/input/misc/da9063-onkey.c
b/drivers/input/misc/da9063-onkey.c
new file mode 100644
index 000..9e41a2d
--- /dev/null
+++ b/drivers/input/misc/da9063-onkey.c
@@ -0,0 +1,228 @@
+/*
+ * da9063-onkey.c - Onkey device driver for DA9063
+ * Copyright (C) 2015 Dialog Semiconductor Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct da9063_onkey {
+ struct da9063 *hw;
+ struct delayed_work work;
+ struct input_dev *input;
+ int irq;
+ bool key_power;
+};
+
+static void da9063_poll_on(struct work_struct *work)
+{
+ struct da9063_onkey *onkey = container_of(work, struct da9063_onkey,
+ work.work);
+ unsigned int val;
+ int fault_log = 0;
+ bool poll = true;
+ int ret;
+
+ /* poll to see when the pin is released */
+ ret = regmap_read(onkey->hw->regmap, DA9063_REG_STATUS_A, &val);
+ if (ret < 0) {
+ dev_err(&onkey->input->dev,
+ "Failed to read ON status: %d\n", ret);
+ goto err_poll;
+ }
+
+ if (!(val & DA9063_NONKEY)) {
+ ret = regmap_update_bits(onkey->hw->regmap,
+DA9063_REG_CONTROL_B,
+DA9063_NONKEY_LOCK, 0);
+ if (ret < 0) {
+ dev_err(&onkey->input->dev,
+ "Failed to reset the Key Delay %d\n", ret);
+ goto err_poll;
+ }
+
+ input_report_key(onkey->input, KEY_POWER, 0);
+ input_sync(onkey->input);
+
[RESEND PATCH V2 2/2] devicetree: Add bindings for DA9063 OnKey
From: Steve Twiss
Add device tree bindings for the DA9063 OnKey driver
Signed-off-by: Steve Twiss
---
Changes from PATCH V1 to V2
---
- Remove the circular dependency comment linking patches in the main e-mail
- Search and replace 'keyword' with 'property' in onkey sub-node description
- Reformat onkey sub-node content to move the description for disable-key-power
into a new optional properties sub-section so it has a more promiment
position
This patch applies against linux-next and v4.0-rc6
Documentation/devicetree/bindings/mfd/da9063.txt | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt
b/Documentation/devicetree/bindings/mfd/da9063.txt
index 42c6fa6..c671784 100644
--- a/Documentation/devicetree/bindings/mfd/da9063.txt
+++ b/Documentation/devicetree/bindings/mfd/da9063.txt
@@ -2,9 +2,10 @@
DA9093 consists of a large and varied group of sub-devices (I2C Only):
-Device Supply NamesDescription
--- ---
+Device Supply NamesDescription
+-- ---
da9063-regulator: : LDOs & BUCKs
+da9063-onkey: : On Key
da9063-rtc : : Real-Time Clock
da9063-watchdog : : Watchdog
@@ -51,6 +52,18 @@ Sub-nodes:
the DA9063. There are currently no entries in this binding, however
compatible = "dlg,da9063-rtc" should be added if a node is created.
+- onkey : This node defines the OnKey settings for controlling the key
+ functionality of the device. The node should contain the compatible property
+ with the value "dlg,da9063-onkey".
+
+ Optional onkey properties:
+
+ - dlg,disable-key-power : Disable power-down using a long key-press. If this
+entry exists the OnKey driver will remove support for the KEY_POWER key
+press. If this entry does not exist then by default the key-press
+triggered power down is enabled and the OnKey will support both KEY_POWER
+and KEY_SLEEP.
+
- watchdog : This node defines settings for the Watchdog timer associated
with the DA9063. There are currently no entries in this binding, however
compatible = "dlg,da9063-watchdog" should be added if a node is created.
@@ -73,6 +86,11 @@ Example:
compatible = "dlg,da9063-watchdog";
};
+ onkey {
+ compatible = "dlg,da9063-onkey";
+ dlg,disable-key-power;
+ };
+
regulators {
DA9063_BCORE1: bcore1 {
regulator-name = "BCORE1";
--
end-of-patch for RESEND PATCH V2
--
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] firmware: dmi_scan: rename dmi_table to dmi_decode_table
Hi Jean, On 17.04.15 13:11, Ivan.khoronzhuk wrote: On 17.04.15 11:54, Jean Delvare wrote: Hi Ivan, On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote: On 16.04.15 11:35, Jean Delvare wrote: On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote: Jean, do you want me to pick this patch up or are you going to? Good question, we need to agree on a strategy. There are 3 patch sets to consider here. 1* My patch fixing the UUID ordering bug. It must go in first and immediately, as it fixes a regression and will have to be backported to stable branches. || V 2* 2 older patches from Ivan which are currently in your efi-next tree if I'm not mistaken. Both were based on an old tree so they do not apply cleanly on kernel v4.0, I had to fix them up manually. I have They are in master tree already. no idea if git would be able to merge them properly, as the fix above changed the context even more. Current efi-next already merged, so you should base your patches on top of last changes. Correct. I looked at the result and the merge looks correct. I'll turn my objections into fixup patches to apply on top, where still worth it. In particular I'll start with the ".x" revert, as it will make backporting the bug fix easier. 3* The 3 new patches from Ivan which I am reviewing now, which are not applied in any public tree AFAIK. It shouldn't happen, I've been verifying just now once again. They are applied on top of linux_next cleanly. Equal as on efi/next. I can't see them at http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=next To clarify: I do not claim that they can't be applied, I'm only saying they're not there yet (which is OK as they were still pending my review.) They do apply just fine, no problem with this. I don't really care who picks these patches up and sends them to Linus, but I think they should all follow the same route so that Linus has as little merge work to do as possible. So either you pick them all, or I do. If I do, you'll have to drop the 2 patches you have in efi-next. Again I'm fine either way, so please let me know what makes your life easier and let's do that. I'm going to base my series "firmware: dmi_scan: add SBMIOS entry point and DMI tables" on top of linux next unless you have already your tree to pick up changes. Please let me know, if you have one. I have no formal tree yet, but my current patch set can be seen at: http://jdelvare.nerim.net/devel/linux-3/jdelvare-dmi/ First 2 patches from you are already upstream. You should rebase your updated patch series on top of upstream + patches 03 and 04, as they will go in first. Thanks, Not sure that's a good idea to base on patches that doesn't path any review and no one cannot apply. At least it be good you send them that I can point on them in commit message. Don't know why your patches don't apply on top of linux next. They looks w/o conflicts. I've applied them by hand. To avoid mess, could you please send them in order I can refer on them in my commit message. -- Regards, Ivan Khoronzhuk -- 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 1/4] fs: Add generic file system event notifications
On Thu 16-04-15 23:56:11, Heinrich Schuchardt wrote: > On 15.04.2015 09:15, Beata Michalska wrote: > > Introduce configurable generic interface for file > > system-wide event notifications to provide file > > systems with a common way of reporting any potential > > issues as they emerge. > > > > The notifications are to be issued through generic > > netlink interface, by a dedicated, for file system > > events, multicast group. The file systems might as > > well use this group to send their own custom messages. > > > > The events have been split into four base categories: > > information, warnings, errors and threshold notifications, > > with some very basic event types like running out of space > > or file system being remounted as read-only. > > > > Threshold notifications have been included to allow > > triggering an event whenever the amount of free space > > drops below a certain level - or levels to be more precise > > as two of them are being supported: the lower and the upper > > range. The notifications work both ways: once the threshold > > level has been reached, an event shall be generated whenever > > the number of available blocks goes up again re-activating > > the threshold. > > > > The interface has been exposed through a vfs. Once mounted, > > it serves as an entry point for the set-up where one can > > register for particular file system events. > > Having a framework for notification for file systems is a great idea. > Your solution covers an important part of the possible application scope. > > Before moving forward I suggest we should analyze if this scope should > be enlarged. > > Many filesystems are remote (e.g. CIFS/Samba) or distributed over many > network nodes (e.g. Lustre). How should file system notification work here? IMO server <-> client notification is fully within the responsibility of a particular protocol. The client can then translate the notification via this interface just fine. So IMHO there's nothing to do in this regard. > How will fuse file systems be served? I similar answer as previously. It's resposibility of each filesystem to provide the notification. You would need some way for userspace to notify the FUSE in kernel which can then relay the information via this interface. So doable but I don't think we have to do it now... > The current point of reference is a single mount point. > Every time I insert an USB stick several file system may be automounted. > I would like to receive events for these automounted file systems. So you'll receive udev / DBus events for the mounts, you can catch these in a userspace daemon and add appropriate rules to receive events (you could even make it part of the mounting procedure of your desktop). I don't think we should magically insert new rules for mounted filesystems since that's a decision that belongs to userspace. > A similar case arises when starting new virtual machines. How will I > receive events on the host system for the file systems of the virtual > machines? IMHO that belongs in userspace and is out of scope for this proposal. > In your implementation events are received via Netlink. > Using Netlink for marking mounts for notification would create a much > more homogenous interface. So why should we use a virtual file system here? Hum, that's an interesting idea. Yes, e.g. networking uses netlink to configure e.g. routing in kernel and in case of this interface, it really might make the interface nicer. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V4.1] Regression: Bluetooth mouse not working.
Hi Jörg, On Fri, Apr 17, 2015 at 12:36 PM, Jörg Otte wrote: > The BT mouse is "death" in v4.1. > The BT mouse has been working in 4.0 and previous kernels, so this > is a regression. > > BT adapter is an intel 8087:07da. The mouse is an MS Notebook Mouse 500. > > It just doesn't work without any errors displayed in dmesg. We might need some logs, bluetoothd logs and btmon trace, to start with, I don't recall any recent changes in HID just in HoG (Bluetooth LE/Smart) which uses uHID. -- Luiz Augusto von Dentz -- 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 1/4] fs: Add generic file system event notifications
On Wed 15-04-15 09:15:44, Beata Michalska wrote: > Introduce configurable generic interface for file > system-wide event notifications to provide file > systems with a common way of reporting any potential > issues as they emerge. > > The notifications are to be issued through generic > netlink interface, by a dedicated, for file system > events, multicast group. The file systems might as > well use this group to send their own custom messages. > > The events have been split into four base categories: > information, warnings, errors and threshold notifications, > with some very basic event types like running out of space > or file system being remounted as read-only. > > Threshold notifications have been included to allow > triggering an event whenever the amount of free space > drops below a certain level - or levels to be more precise > as two of them are being supported: the lower and the upper > range. The notifications work both ways: once the threshold > level has been reached, an event shall be generated whenever > the number of available blocks goes up again re-activating > the threshold. > > The interface has been exposed through a vfs. Once mounted, > it serves as an entry point for the set-up where one can > register for particular file system events. > > Signed-off-by: Beata Michalska Thanks for the patches! Some comments are below. > --- > Documentation/filesystems/events.txt | 254 +++ > fs/Makefile |1 + > fs/events/Makefile |6 + > fs/events/fs_event.c | 775 > ++ > fs/events/fs_event.h | 27 ++ > fs/events/fs_event_netlink.c | 94 + > fs/namespace.c |1 + > include/linux/fs.h |6 +- > include/linux/fs_event.h | 69 +++ > include/uapi/linux/fs_event.h| 62 +++ > include/uapi/linux/genetlink.h |1 + > net/netlink/genetlink.c |7 +- > 12 files changed, 1301 insertions(+), 2 deletions(-) > create mode 100644 Documentation/filesystems/events.txt > create mode 100644 fs/events/Makefile > create mode 100644 fs/events/fs_event.c > create mode 100644 fs/events/fs_event.h > create mode 100644 fs/events/fs_event_netlink.c > create mode 100644 include/linux/fs_event.h > create mode 100644 include/uapi/linux/fs_event.h > > diff --git a/Documentation/filesystems/events.txt > b/Documentation/filesystems/events.txt > new file mode 100644 > index 000..c85dd88 > --- /dev/null > +++ b/Documentation/filesystems/events.txt > @@ -0,0 +1,254 @@ > + > + Generic file system event notification interface > + > +Document created 09 April 2015 by Beata Michalska > + > +1. The reason behind: > += > + > +There are many corner cases when things might get messy with the filesystems. > +And it is not always obvious what and when went wrong. Sometimes you might > +get some subtle hints that there is something going on - but by the time > +you realise it, it might be too late as you are already out-of-space > +or the filesystem has been remounted as read-only (i.e.). The generic > +interface for the filesystem events fills the gap by providing a rather > +easy way of real-time notifications triggered whenever something intreseting > +happens, allowing filesystems to report events in a common way, as they > occur. > + > +2. How does it work: > + > + > +The interface itself has been exposed as fstrace-type Virtual File System, > +primarily to ease the process of setting up the configuration for the file > +system notifications. So for starters it needs to get mounted (obviously): > + > + mount -t fstrace none /sys/fs/events > + > +This will unveil the single fstrace filesystem entry - the 'config' file, > +through which the notification are being set-up. > + > +Activating notifications for particular filesystem is as straightforward > +as writing into the 'config' file. Note that by default all events despite > +the actual filesystem type are being disregarded. Is there a reason to have a special filesystem for this? Do you expect extending it by (many) more files? Why not just creating a file in sysfs or something like that? > +Synopsis of config: > +-- > + > + MOUNT EVENT_TYPE [L1] [L2] > + > + MOUNT : the filesystem's mount point I'm not quite decided but is mountpoint really the right thing to pass via the interface? They aren't unique (filesystem can be mounted in multiple places) and more importantly can change over time. So won't it be better to pass major:minor over the interface? These are stable, unique to the filesystem, and userspace can easily get them by calling stat(2) on the desired path (or directly from /proc/self/mountinfo). That could be also used as an fs identifier instead of assigned ID (and thus we won't need those events about creation of new trace which look somew
Re: [PATCH] blk: optimize blk_trace macros for cgroup case PING..
Hi Jens, do you have any objections against this patch?
Please let me know if you have any and I'll fix it.
Dmitry Monakhov writes:
> Usually blk_trace is not active, but cfq_log_xxx macros unconditionally
> prepare cgroup path via blkg_path() which is suboptimal. This provoke
> significant performance overhead
>
> ## Test
> #modprobe null_blk queue_mode=1
> #echo cfq > /sys/block/nullb0/queue/scheduler
> #fio --ioengine=libaio --direct=1 --group_reporting --filename=/dev/nullb0 \
> --rw=write --iodepth=64 --bs=4k --numjobs=8 --size=4G
> | | baseline | w/ patch | gain |
> | WR iops | 161483 | 189989 | +17% |
> | stddev |14.36 |13.19 | |
>
> Signed-off-by: Dmitry Monakhov
> ---
> block/blk-throttle.c | 17 -
> block/cfq-iosched.c | 22 +-
> include/linux/blktrace_api.h |5 +
> 3 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/block/blk-throttle.c b/block/blk-throttle.c
> index 5b9c6d5..6ce9750 100644
> --- a/block/blk-throttle.c
> +++ b/block/blk-throttle.c
> @@ -238,21 +238,20 @@ static struct throtl_data *sq_to_td(struct
> throtl_service_queue *sq)
> * The messages are prefixed with "throtl BLKG_NAME" if @sq belongs to a
> * throtl_grp; otherwise, just "throtl".
> *
> - * TODO: this should be made a function and name formatting should happen
> - * after testing whether blktrace is enabled.
> */
> #define throtl_log(sq, fmt, args...) do {\
> struct throtl_grp *__tg = sq_to_tg((sq)); \
> struct throtl_data *__td = sq_to_td((sq)); \
> \
> - (void)__td; \
> - if ((__tg)) { \
> - char __pbuf[128]; \
> + if (is_blk_trace_active(__td->queue)) { \
> + if ((__tg)) { \
> + char __pbuf[128]; \
> \
> - blkg_path(tg_to_blkg(__tg), __pbuf, sizeof(__pbuf));\
> - blk_add_trace_msg(__td->queue, "throtl %s " fmt, __pbuf,
> ##args); \
> - } else {\
> - blk_add_trace_msg(__td->queue, "throtl " fmt, ##args); \
> + blkg_path(tg_to_blkg(__tg), __pbuf, sizeof(__pbuf)); \
> + blk_add_trace_msg(__td->queue, "throtl %s " fmt,
> __pbuf, ##args); \
> + } else {\
> + blk_add_trace_msg(__td->queue, "throtl " fmt, ##args); \
> + } \
> } \
> } while (0)
>
> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> index 5da8e6e..7b90897 100644
> --- a/block/cfq-iosched.c
> +++ b/block/cfq-iosched.c
> @@ -625,20 +625,24 @@ static inline void cfqg_put(struct cfq_group *cfqg)
> }
>
> #define cfq_log_cfqq(cfqd, cfqq, fmt, args...) do {
> \
> - char __pbuf[128]; \
> + if (is_blk_trace_active((cfqd)->queue)) { \
> + char __pbuf[128]; \
> \
> - blkg_path(cfqg_to_blkg((cfqq)->cfqg), __pbuf, sizeof(__pbuf)); \
> - blk_add_trace_msg((cfqd)->queue, "cfq%d%c%c %s " fmt, (cfqq)->pid, \
> - cfq_cfqq_sync((cfqq)) ? 'S' : 'A', \
> - cfqq_type((cfqq)) == SYNC_NOIDLE_WORKLOAD ? 'N' : ' ',\
> - __pbuf, ##args); \
> + blkg_path(cfqg_to_blkg((cfqq)->cfqg), __pbuf, sizeof(__pbuf)); \
> + blk_add_trace_msg((cfqd)->queue, "cfq%d%c%c %s " fmt,
> (cfqq)->pid, \
> + cfq_cfqq_sync((cfqq)) ? 'S' : 'A',\
> + cfqq_type((cfqq)) == SYNC_NOIDLE_WORKLOAD ?
> 'N' : ' ', \
> + __pbuf, ##args); \
> + } \
> } while (0)
>
> #define cfq_log_cfqg(cfqd, cfqg, fmt, args...) do {
> \
> - char __pbuf[128]; \
> + if (is_blk_trace_active((cfqd)->queue)) { \
> + char __pbuf[128]; \
> \
> - blkg_path(cfqg_to_blkg(cfqg), __pbuf, sizeof(__pbuf)
Re: [PATCH] vt: Don't check KD_GRAPHICS when binding/unbinding
Hi
On Mon, Apr 13, 2015 at 11:16 AM, Daniel Vetter wrote:
> This was introduced in
>
> commit 6db4063c5b72b46e9793b0f141a7a3984ac6facf
> Author: Antonino A. Daplas
> Date: Mon Jun 26 00:27:12 2006 -0700
>
> [PATCH] VT binding: Add sysfs control to the VT layer
>
> with the justification
>
> "In addition, if any of the consoles are in KD_GRAPHICS mode, binding and
> unbinding will not succeed. KD_GRAPHICS mode usually indicates that the
> underlying console hardware is used for other purposes other than
> displaying
> text (ie X). This feature should prevent binding/unbinding from
> interfering
> with a graphics application using the VT."
>
> I think we should lift this artificial restriction though:
> - KD_GRAPHICS doesn't get cleaned up automatically, which means it's
> easy to have terminals stuck in KD_GRAPHICS when hacking around on
> X.
> - X doesn't really care, especially with drm where kms already blocks
> fbdev (and hence fbcon) when there's an active compositor.
> - This is a root-only interface with a separate .config option and
> it's possible to hang your machine already anyway if you
> unload/reload drivers and don't know what you're doing.
I think it tries to prevent vgacon (or other _hw_ consoles) from being
loaded. However, this was only interesting for UMS drivers, which used
this to prevent the kernel from messing with them. But nowadays we
have kernel drivers which control hand-over and hardware ownership, so
I cannot see why this protection is still needed:
Acked-by: David Herrmann
Thanks
David
> With this patch i915.ko module reloading works again reliably,
> something in the recent fedora upgrades broke things.
>
> Cc: Greg Kroah-Hartman
> Cc: Antonino A. Daplas
> Cc: David Herrmann
> Cc: Peter Hurley
> Cc: Imre Deak
> Signed-off-by: Daniel Vetter
> ---
> drivers/tty/vt/vt.c | 22 ++
> 1 file changed, 2 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 6e00572cbeb9..b84f7d80c8b4 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3185,22 +3185,6 @@ err:
>
>
> #ifdef CONFIG_VT_HW_CONSOLE_BINDING
> -static int con_is_graphics(const struct consw *csw, int first, int last)
> -{
> - int i, retval = 0;
> -
> - for (i = first; i <= last; i++) {
> - struct vc_data *vc = vc_cons[i].d;
> -
> - if (vc && vc->vc_mode == KD_GRAPHICS) {
> - retval = 1;
> - break;
> - }
> - }
> -
> - return retval;
> -}
> -
> /* unlocked version of unbind_con_driver() */
> int do_unbind_con_driver(const struct consw *csw, int first, int last, int
> deflt)
> {
> @@ -3286,8 +3270,7 @@ static int vt_bind(struct con_driver *con)
> const struct consw *defcsw = NULL, *csw = NULL;
> int i, more = 1, first = -1, last = -1, deflt = 0;
>
> - if (!con->con || !(con->flag & CON_DRIVER_FLAG_MODULE) ||
> - con_is_graphics(con->con, con->first, con->last))
> + if (!con->con || !(con->flag & CON_DRIVER_FLAG_MODULE))
> goto err;
>
> csw = con->con;
> @@ -3338,8 +3321,7 @@ static int vt_unbind(struct con_driver *con)
> int i, more = 1, first = -1, last = -1, deflt = 0;
> int ret;
>
> - if (!con->con || !(con->flag & CON_DRIVER_FLAG_MODULE) ||
> - con_is_graphics(con->con, con->first, con->last))
> + if (!con->con || !(con->flag & CON_DRIVER_FLAG_MODULE))
> goto err;
>
> csw = con->con;
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PULL] Documentation for 4.1
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.lwn.net/linux-2.6.git tags/docs-for-linus for you to fetch changes up to 197175427a221fe3200f7727ea35e261727e7228: Documentation/memcg: update memcg/kmem status (2015-04-11 15:23:31 +0200) The documentation tree update for 4.1. Numerous fixes, the overdue removal of the i2o docs, some new Chinese translations, and, hopefully, the README fix that will end the flow of identical patches to that file. Borislav Petkov (1): Documentation/kernel-parameters: Move "eagerfpu" to its right place Chen Gang (1): Documentation: blackfin: Makefile: Typo building issue Ebru Akagunduz (1): doc: add information about max_ptes_none Fu Wei (3): Documentation: Chinese translation of arm64/legacy_instructions.txt Documentation:Update Documentation/zh_CN/arm64/booting.txt Documentation:Update Documentation/zh_CN/arm64/memory.txt Giedrius Statkevičius (1): Documentation/email-clients.txt: Fix one grammar mistake, add extra info about TB Gregory Fong (1): Documentation: arm: Update for DT-only platforms Heinrich Schuchardt (1): Doc/memory-hotplug.txt: corrections and callback function prototype Jeff Kirsher (1): README: Update version number reference Jonathan Corbet (2): Documentation: tweak the maintainers entry docs/completion.txt: Various tweaks and corrections Leonid V. Fedorenchik (1): Documentation: Remove mentioning of block barriers Li Bin (1): kprobes: Update Documentation/kprobes.txt Liviu Dudau (1): Documentation: drm: Use '->' when describing access through pointers. Masanari Iida (2): doc/input : Fix typos in Documentation/input doc:pci: Fix typo in Documentation/PCI Michael Opdenacker (1): DocBook media: fix broken EIA hyperlink Mika Westerberg (1): Documentation: gpio: Update ACPI part of the document to mention _DSD Nicholas Mc Guire (1): doc: completion: context, scope and language fixes Pavel Kretov (2): Documentation/CodingStyle: fix tab-spaces mixture Documentation/CodingStyle: improve text layout Randy Wright (1): Documentation/vm/pagemap.txt: correct location of page-types tool Rasmus Villemoes (1): doc: printk-formats: Fix %pU description Robert P. J. Day (1): Documentation: Add "@" in front of private structure members. Sheng Yong (1): mem-hotplug: fix typo in Documentation/memory-hotplug.txt Sylvain Trias (1): Documentation/memory-barriers.txt: typo fix Tobias Klauser (1): doc: Add guest_nice column to example output of `cat /proc/stat' Valentin Rothberg (1): MSI-HOWTO.txt: remove reference on IRQF_DISABLED Vladimir Davydov (1): Documentation/memcg: update memcg/kmem status Wang Long (2): Documentation: add print bitmap description Documentation: update the CONFIG_DEBUG_PAGEALLOC description Wolfram Sang (1): Documentation: i2o: remove duplicate documentation Yaowei Bai (1): README: Change gzip/bzip2 to xz compression format Documentation/CodingStyle | 149 Documentation/DocBook/drm.tmpl | 2 +- Documentation/DocBook/media/v4l/biblio.xml | 11 +- Documentation/DocBook/media/v4l/dev-sliced-vbi.xml | 2 +- .../DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml | 2 +- Documentation/PCI/MSI-HOWTO.txt| 21 +- Documentation/PCI/pci-error-recovery.txt | 2 +- Documentation/PCI/pcieaer-howto.txt| 4 +- Documentation/arm/Booting | 9 +- Documentation/arm/README | 15 +- Documentation/blackfin/Makefile| 2 +- Documentation/block/biodoc.txt | 36 +- Documentation/cgroups/memory.txt | 8 +- Documentation/email-clients.txt| 11 +- Documentation/filesystems/proc.txt | 6 +- Documentation/gpio/board.txt | 41 ++- Documentation/i2o/README | 63 Documentation/i2o/ioctl| 394 - Documentation/input/alps.txt | 4 +- Documentation/input/event-codes.txt| 2 +- Documentation/input/gpio-tilt.txt | 2 +- Documentation/input/iforce-protocol.txt| 2 +- Documentation/input/walkera0701.txt| 2 +- Documentation/input/yealink.txt| 2 +- Documentation/kernel-parameters.txt| 12 +- Documentation/kmemcheck.txt| 4 +- Documentation/kprobes.txt | 4 +- D
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
Hey Boris, On Fri, Apr 17, 2015 at 10:39:46AM +0200, Boris Brezillon wrote: > On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon > wrote: > > On Mon, 13 Apr 2015 20:11:46 + Jason Cooper > > wrote: > > > > > > > > > I'd appreciate if we'd look into it. I understand from on-list and > > > > > off-list discussion that the rewrite was unavoidable. So I'm willing > > > > > to > > > > > concede that. Giving people time to migrate from old to new while > > > > > still > > > > > being able to update for other security fixes seems reasonable. > > > > > > > > Jason, what do you think of the approach above? > > > > > > I say keep it simple. We shouldn't use the DT changes to trigger one > > > vice the other. We need to be able to build both, but only load one at > > > a time. If that's anything other than simple to do, then we make it a > > > Kconfig binary choice and move on. > > > > Actually I was planning to handle it with a Kconfig dependency rule > > (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends > > on !NEW_DRIVER). > > I don't know how to make it a runtime check without adding new > > compatible strings for the kirkwood, dove and orion platforms, and I'm > > sure sure this is a good idea. > ^ not > > > Do you have any ideas ? I'm kinda wrapped up with dayjob stuff atm... But I'd look at the wireless drivers. eg b43, b43legacy, brcm80211. There are devices they overlap for. So, they need to deconflict in some way. thx, Jason. -- 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] First batch of KVM changes for 4.1
On Fri, Apr 17, 2015 at 12:38:07PM +0200, Paolo Bonzini wrote: > > > On 17/04/2015 12:36, Peter Zijlstra wrote: > > Now you make everybody pay for your crap, x86-64 paravirt or not. Keep > > the cost by those who need it. > > > > Please take it out, ASAP. > > I'll just implement the static key. Can you first show that: preempt_out: int cpu = smp_processor_id(); if (vcpu->cpu != cpu) vcpu->cpu = cpu; preempt_in: int cpu = smp_processor_id(); if (unlikely(vcpu->cpu != cpu)) do_vcpu_migration_callback(cpu); Is actually a measurable performance hit and we actually _need_ the migration callback? Also, it looks like you already do exactly this for other things, look at: kvm_sched_in() kvm_arch_vcpu_load() if (unlikely(vcpu->cpu != cpu) ... ) So no, I don't believe for one second you need this. -- 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] iio: core: Introduce IIO_CHAN_INFO_CALIBREPETITIONS
Some magnetometers can perform a number of repetitions in HW
for each measurement to increase accuracy. One example is
Bosch BMC150:
http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf.
Introduce an interface to set the number of repetitions
for these devices.
Signed-off-by: Irina Tirdea
---
Documentation/ABI/testing/sysfs-bus-iio | 10 ++
drivers/iio/industrialio-core.c | 1 +
include/linux/iio/iio.h | 1 +
3 files changed, 12 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index 866b4ec..74c1444 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1375,3 +1375,13 @@ Description:
The emissivity ratio of the surface in the field of view of the
contactless temperature sensor. Emissivity varies from 0 to 1,
with 1 being the emissivity of a black body.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_calibrepetitions
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_calibrepetitions
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_calibrepetitions
+KernelVersion: 4.2
+Contact: linux-...@vger.kernel.org
+Description:
+ Hardware applied number of repetitions for acquiring one
+ data point. The HW will do [_name]_calibrepetitions
+ measurements and return the average value as output data.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 7c98bc1..9e0da7f 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -129,6 +129,7 @@ static const char * const iio_chan_info_postfix[] = {
[IIO_CHAN_INFO_DEBOUNCE_COUNT] = "debounce_count",
[IIO_CHAN_INFO_DEBOUNCE_TIME] = "debounce_time",
[IIO_CHAN_INFO_CALIBEMISSIVITY] = "calibemissivity",
+ [IIO_CHAN_INFO_CALIBREPETITIONS] = "calibrepetitions",
};
/**
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index b1e46ae..07fbfb2 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -44,6 +44,7 @@ enum iio_chan_info_enum {
IIO_CHAN_INFO_DEBOUNCE_COUNT,
IIO_CHAN_INFO_DEBOUNCE_TIME,
IIO_CHAN_INFO_CALIBEMISSIVITY,
+ IIO_CHAN_INFO_CALIBREPETITIONS,
};
enum iio_shared_by {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] iio: magn: Add support for BMC150 magnetometer
Add support for the Bosh BMC150 Magnetometer. The specification can be downloaded from: http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf. The chip contains both an accelerometer and a magnetometer. This patch adds support only for the magnetometer part. The temperature compensation formulas are based on bmm050_api.c authored by cont...@bosch.sensortec.com. Signed-off-by: Irina Tirdea --- drivers/iio/magnetometer/Kconfig | 14 + drivers/iio/magnetometer/Makefile |2 + drivers/iio/magnetometer/bmc150_magn.c | 1060 3 files changed, 1076 insertions(+) create mode 100644 drivers/iio/magnetometer/bmc150_magn.c diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig index a5d6de7..008baca 100644 --- a/drivers/iio/magnetometer/Kconfig +++ b/drivers/iio/magnetometer/Kconfig @@ -76,4 +76,18 @@ config IIO_ST_MAGN_SPI_3AXIS depends on IIO_ST_MAGN_3AXIS depends on IIO_ST_SENSORS_SPI +config BMC150_MAGN + tristate "Bosch BMC150 Magnetometer Driver" + depends on I2C + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + help + Say yes here to build support for the BMC150 magnetometer. + + Currently this only supports the device via an i2c interface. + + This is a combo module with both accelerometer and magnetometer. + This driver is only implementing magnetometer part, which has + its own address and register map. + endmenu diff --git a/drivers/iio/magnetometer/Makefile b/drivers/iio/magnetometer/Makefile index 0f5d3c9..e2c3459 100644 --- a/drivers/iio/magnetometer/Makefile +++ b/drivers/iio/magnetometer/Makefile @@ -13,3 +13,5 @@ st_magn-$(CONFIG_IIO_BUFFER) += st_magn_buffer.o obj-$(CONFIG_IIO_ST_MAGN_I2C_3AXIS) += st_magn_i2c.o obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o + +obj-$(CONFIG_BMC150_MAGN) += bmc150_magn.o diff --git a/drivers/iio/magnetometer/bmc150_magn.c b/drivers/iio/magnetometer/bmc150_magn.c new file mode 100644 index 000..e970a0c --- /dev/null +++ b/drivers/iio/magnetometer/bmc150_magn.c @@ -0,0 +1,1060 @@ +/* + * Bosch BMC150 three-axis magnetic field sensor driver + * + * Copyright (c) 2015, Intel Corporation. + * + * This code is based on bmm050_api.c authored by cont...@bosch.sensortec.com: + * + * (C) Copyright 2011~2014 Bosch Sensortec GmbH All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define BMC150_MAGN_DRV_NAME "bmc150_magn" +#define BMC150_MAGN_IRQ_NAME "bmc150_magn_event" +#define BMC150_MAGN_GPIO_INT "interrupt" + +#define BMC150_MAGN_REG_CHIP_ID0x40 +#define BMC150_MAGN_CHIP_ID_VAL0x32 + +#define BMC150_MAGN_REG_X_L0x42 +#define BMC150_MAGN_REG_X_M0x43 +#define BMC150_MAGN_REG_Y_L0x44 +#define BMC150_MAGN_REG_Y_M0x45 +#define BMC150_MAGN_SHIFT_XY_L 3 +#define BMC150_MAGN_REG_Z_L0x46 +#define BMC150_MAGN_REG_Z_M0x47 +#define BMC150_MAGN_SHIFT_Z_L 1 +#define BMC150_MAGN_REG_RHALL_L0x48 +#define BMC150_MAGN_REG_RHALL_M0x49 +#define BMC150_MAGN_SHIFT_RHALL_L 2 + +#define BMC150_MAGN_REG_INT_STATUS 0x4A + +#define BMC150_MAGN_REG_POWER 0x4B +#define BMC150_MAGN_MASK_POWER_CTL BIT(0) + +#define BMC150_MAGN_REG_OPMODE_ODR 0x4C +#define BMC150_MAGN_MASK_OPMODEGENMASK(2, 1) +#define BMC150_MAGN_SHIFT_OPMODE 1 +#define BMC150_MAGN_MODE_NORMAL0x00 +#define BMC150_MAGN_MODE_FORCED0x01 +#define BMC150_MAGN_MODE_SLEEP 0x03 +#define BMC150_MAGN_MASK_ODR GENMASK(5, 3) +#define BMC150_MAGN_SHIFT_ODR 3 + +#define BMC150_MAGN_REG_INT0x4D + +#define BMC150_MAGN_REG_INT_DRDY 0x4E +#define BMC150_MAGN_MASK_DRDY_EN BIT(7) +#define BMC150_MAGN_SHIFT_DRDY_EN 7 +#define BMC150_MAGN_MASK_DRDY_INT3 BIT(6) +#define BMC150_MAGN_MASK_DRDY_Z_EN BIT(5) +#define BMC150_MAGN_MASK_DRDY_Y_EN
[PATCH 2/5] clocksource: st_lpc: Add DT bindings documentation for lpc timer
This patch provides the DT bindings documentation for the lpc
timer found on stih407 fanmily SoCs from STMicroelectronics.
Signed-off-by: Peter Griffin
---
Documentation/devicetree/bindings/timer/st,lpc-timer.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/st,lpc-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/st,lpc-timer.txt
b/Documentation/devicetree/bindings/timer/st,lpc-timer.txt
new file mode 100644
index 000..c9ef297
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/st,lpc-timer.txt
@@ -0,0 +1,15 @@
+Binding for LPC Timer on STMicroelectronics STi series SoCs
+
+Required properties:
+- compatible: Should be "st,st_lpc_timer"
+- reg: Base address and length of the LPC Timers registers.
+- clock-names: Set to "lpc_clk".
+- clocks: phandle of the clock used by the LPC Timer
+
+Example:
+ lpc-timer@0x8788000 {
+ compatible = "st,st_lpc_timer";
+ reg = <0x8788000 0x1000>;
+ clock-names = "lpc_clk";
+ clocks = <&clk_s_d3_flexgen CLK_LPC_1>;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] clocksource: st_lpc: Add LPC timer as a clocksource.
This patch adds support for the LPC timer as a clocksource
which is found on stih407 family SoCs.
We wish to use the LPC timer as a clocksource instead of
arm_global_timer, as the latter is tied to CPU frequency, and
that driver currently makes no account for frequency scaling.
Once this driver is merged cpufreq can be enabled for stih407
family SoCs without also effecting sched_clock.
Signed-off-by: Ajit Pal Singh
Signed-off-by: Peter Griffin
---
drivers/clocksource/Kconfig | 16 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/st_lpc.c | 154 +++
3 files changed, 171 insertions(+)
create mode 100644 drivers/clocksource/st_lpc.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a0b036c..29cd67d 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -253,4 +253,20 @@ config CLKSRC_PXA
help
This enables OST0 support available on PXA and SA-11x0
platforms.
+
+config CLKSRC_ST_LPC_CLOCK
+ bool
+ depends on ARCH_STI
+ select CLKSRC_OF if OF
+ help
+ Enable this option to use the Low Power controller timer
+ as clock source.
+
+config CLKSRC_ST_LPC_TIMER_SCHED_CLOCK
+ bool
+ depends on ST_LPC_CLOCK
+ default y
+ help
+ Use Low Power controller timer clock source as sched_clock
+
endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 752d5c7..356d331 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_ARCH_INTEGRATOR_AP) += timer-integrator-ap.o
obj-$(CONFIG_CLKSRC_VERSATILE) += versatile.o
obj-$(CONFIG_CLKSRC_MIPS_GIC) += mips-gic-timer.o
obj-$(CONFIG_ASM9260_TIMER)+= asm9260_timer.o
+obj-$(CONFIG_CLKSRC_ST_LPC_CLOCK) += st_lpc.o
diff --git a/drivers/clocksource/st_lpc.c b/drivers/clocksource/st_lpc.c
new file mode 100644
index 000..f9abded
--- /dev/null
+++ b/drivers/clocksource/st_lpc.c
@@ -0,0 +1,154 @@
+/*
+ * This driver implements a Clocksource using the Low Power Timer in
+ * the Low Power Controller (LPC) in some STMicroelectronics
+ * STi series SoCs
+ *
+ * Copyright (C) 2015 STMicroelectronics Limited
+ * Author: Francesco Virlinzi
+ * Author: Ajit Pal Singh
+ *
+ * May be copied or modified under the terms of the GNU General Public
+ * License. See linux/COPYING for more information.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Low Power Timer */
+#define LPC_LPT_LSB_OFF0x400
+#define LPC_LPT_MSB_OFF0x404
+#define LPC_LPT_START_OFF 0x408
+
+struct st_lpc {
+ struct clk *clk;
+ void __iomem *iomem_cs;
+};
+
+static struct st_lpc *st_lpc;
+
+static u64 notrace st_lpc_counter_read(void)
+{
+ u64 counter;
+ u32 lower;
+ u32 upper, old_upper;
+
+ upper = readl_relaxed(st_lpc->iomem_cs + LPC_LPT_MSB_OFF);
+ do {
+ old_upper = upper;
+ lower = readl_relaxed(st_lpc->iomem_cs + LPC_LPT_LSB_OFF);
+ upper = readl_relaxed(st_lpc->iomem_cs + LPC_LPT_MSB_OFF);
+ } while (upper != old_upper);
+
+ counter = upper;
+ counter <<= 32;
+ counter |= lower;
+ return counter;
+}
+
+static cycle_t st_lpc_clocksource_read(struct clocksource *cs)
+{
+ return st_lpc_counter_read();
+}
+
+static void st_lpc_clocksource_reset(struct clocksource *cs)
+{
+ writel_relaxed(0, st_lpc->iomem_cs + LPC_LPT_START_OFF);
+ writel_relaxed(0, st_lpc->iomem_cs + LPC_LPT_MSB_OFF);
+ writel_relaxed(0, st_lpc->iomem_cs + LPC_LPT_LSB_OFF);
+ writel_relaxed(1, st_lpc->iomem_cs + LPC_LPT_START_OFF);
+}
+
+static struct clocksource st_lpc_clocksource = {
+ .name = "st-lpc clocksource",
+ .rating = 301,
+ .read = st_lpc_clocksource_read,
+ .mask = CLOCKSOURCE_MASK(64),
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+#ifdef CONFIG_CLKSRC_LPC_TIMER_SCHED_CLOCK
+static u64 notrace st_lpc_sched_clock_read(void)
+{
+ return st_lpc_counter_read();
+}
+#endif
+
+static void __init st_lpc_clocksource_init(void)
+{
+ unsigned long rate;
+
+ st_lpc_clocksource_reset(&st_lpc_clocksource);
+
+ rate = clk_get_rate(st_lpc->clk);
+#ifdef CONFIG_CLKSRC_LPC_TIMER_SCHED_CLOCK
+ sched_clock_register(st_lpc_sched_clock_read, 64, rate);
+#endif
+ clocksource_register_hz(&st_lpc_clocksource, rate);
+
+}
+
+static int st_lpc_setup_clk(struct device_node *np)
+{
+ char *clk_name = "lpc_clk";
+ struct clk *clk;
+ int ret;
+
+ clk = of_clk_get_by_name(np, clk_name);
+ if (IS_ERR(clk)) {
+ pr_err("st-lpc: unable to get lpc clock\n");
+ ret = PTR_ERR(clk);
+ return ret;
+ }
+
+ if (clk_prepare_enable(clk)) {
+ pr_err("st-lpc: %s could not be enabled\n",
[PATCH 0/3] Add support for BMC150 magnetometer
This adds support for Bosch BMC150 magnetometer. Irina Tirdea (3): iio: core: Introduce IIO_CHAN_INFO_CALIBREPETITIONS iio: magn: Add support for BMC150 magnetometer iio: magn: bmc150_magn: Add devicetree binding documentation Documentation/ABI/testing/sysfs-bus-iio| 10 + .../bindings/iio/magnetometer/bmc150_magn.txt | 20 + drivers/iio/industrialio-core.c|1 + drivers/iio/magnetometer/Kconfig | 14 + drivers/iio/magnetometer/Makefile |2 + drivers/iio/magnetometer/bmc150_magn.c | 1060 include/linux/iio/iio.h|1 + 7 files changed, 1108 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt create mode 100644 drivers/iio/magnetometer/bmc150_magn.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2 V2] memory-hotplug: remove reset_node_managed_pages() and reset_node_managed_pages() in hotadd_new_pgdat()
After hotadd_new_pgdat()->free_area_init_node(), pgdat's spanned/present are 0,
and zone's spanned/present/managed are 0, so remove reset_node_managed_pages()
and reset_node_managed_pages().
Signed-off-by: Xishi Qiu
---
mm/memory_hotplug.c | 25 -
1 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 457bde5..82c67ee 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1064,16 +1064,6 @@ int __ref online_pages(unsigned long pfn, unsigned long
nr_pages, int online_typ
}
#endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
-static void reset_node_present_pages(pg_data_t *pgdat)
-{
- struct zone *z;
-
- for (z = pgdat->node_zones; z < pgdat->node_zones + MAX_NR_ZONES; z++)
- z->present_pages = 0;
-
- pgdat->node_present_pages = 0;
-}
-
/* we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG */
static pg_data_t __ref *hotadd_new_pgdat(int nid, u64 start)
{
@@ -1108,21 +1098,6 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64
start)
build_all_zonelists(pgdat, NULL);
mutex_unlock(&zonelists_mutex);
- /*
-* zone->managed_pages is set to an approximate value in
-* free_area_init_core(), which will cause
-* /sys/device/system/node/nodeX/meminfo has wrong data.
-* So reset it to 0 before any memory is onlined.
-*/
- reset_node_managed_pages(pgdat);
-
- /*
-* When memory is hot-added, all the memory is in offline state. So
-* clear all zones' present_pages because they will be updated in
-* online_pages() and offline_pages().
-*/
- reset_node_present_pages(pgdat);
-
return pgdat;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] iio: magn: bmc150_magn: Add devicetree binding documentation
Add binding documentation for Bosch BMC150 magnetometer.
Signed-off-by: Irina Tirdea
---
.../bindings/iio/magnetometer/bmc150_magn.txt| 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
b/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
new file mode 100644
index 000..4ed035c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
@@ -0,0 +1,20 @@
+* Bosch BMC150 magnetometer sensor
+
+http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf
+
+Required properties:
+
+ - compatible : should be "bosch,bmc150_magn"
+ - reg : the I2C address of the magnetometer
+
+Optional properties:
+
+ - gpios : should be device tree identifier of the magnetometer DRDY pin
+
+Example:
+
+bmc150_magn@12 {
+compatible = "bosch,bmc150_magn";
+reg = <0x12>;
+interrupt-gpio = <&gpio1 0 1>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] ARM: sti: Always enable CLKSRC_ST_LPC_CLOCK
If available on the SoC we wish to use st_lpc clksrc so that cpufreq can operate without effecting sched_clock. Signed-off-by: Peter Griffin --- arch/arm/mach-sti/Kconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig index 3b1ac46..48767d3 100644 --- a/arch/arm/mach-sti/Kconfig +++ b/arch/arm/mach-sti/Kconfig @@ -2,6 +2,7 @@ menuconfig ARCH_STI bool "STMicroelectronics Consumer Electronics SOCs" if ARCH_MULTI_V7 select ARM_GIC select ARM_GLOBAL_TIMER + select CLKSRC_ST_LPC_CLOCK select PINCTRL select PINCTRL_ST select MFD_SYSCON @@ -15,9 +16,9 @@ menuconfig ARCH_STI select PL310_ERRATA_769419 if CACHE_L2X0 select RESET_CONTROLLER help - Include support for STiH41x SOCs like STiH415/416 using the device tree - for discovery - More information at Documentation/arm/STiH41x and + Include support for STiH4xx SOCs like STiH415/416 and stih407/10 family + using the device tree for discovery + More information at Documentation/arm/sti/ and at Documentation/devicetree -- 1.9.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 5/5] ARM: DT: STi: STiH407: Add DT node for st-lpc timer.
This patch adds the dt node for the st-lpc timer found on
stih407 famliy SoCs. This can then be used as a clocksource.
Signed-off-by: Peter Griffin
---
arch/arm/boot/dts/stih407-family.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index c06a546..59c6a22 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -39,6 +39,13 @@
reg = <0x0876 0x1000>;
};
+ lpc-timer@0x8788000 {
+ compatible = "st,st_lpc_timer";
+ reg = <0x8788000 0x1000>;
+ clock-names = "lpc_clk";
+ clocks = <&clk_s_d3_flexgen CLK_LPC_1>;
+ };
+
timer@08760200 {
interrupt-parent = <&intc>;
compatible = "arm,cortex-a9-global-timer";
--
1.9.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/5] MAINTAINERS: Add st_lpc.c to ARCH/STI section of maintainers
This patch adds the new st_lpc timer driver found on stih407 family SoCs into the ARCH/STI section of the maintainers file. Signed-off-by: Peter Griffin --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index efbcb50..4fe68dc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1465,6 +1465,7 @@ S:Maintained F: arch/arm/mach-sti/ F: arch/arm/boot/dts/sti* F: drivers/clocksource/arm_global_timer.c +F: drivers/clocksource/st_lpc.c F: drivers/i2c/busses/i2c-st.c F: drivers/media/rc/st_rc.c F: drivers/mmc/host/sdhci-st.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 V2] memory-hotplug: fix BUG_ON in move_freepages()
Hot remove nodeXX, then hot add nodeXX. If BIOS report cpu first, it will call hotadd_new_pgdat(nid, 0), this will set pgdat->node_start_pfn to 0. As nodeXX exists at boot time, so pgdat->node_spanned_pages is the same as original. Then free_area_init_core()->memmap_init() will pass a wrong start and a nonzero size. free_area_init_core() memmap_init() memmap_init_zone() early_pfn_in_nid() set_page_links() "if (!early_pfn_in_nid(pfn, nid))" will skip the pfn(memory in section), but it will not skip the pfn(hole in section), this will cover and relink the page to zone/nid, so page_zone() from memory and hole in the same section are different. The following call trace shows the bug. This patch will set the node size to 0 when hotadd a new node(original or new). init_currently_empty_zone() and memmap_init() will be called in add_zone(), so need not to change it. [90476.077469] kernel BUG at mm/page_alloc.c:1042! // move_freepages() -> BUG_ON(page_zone(start_page) != page_zone(end_page)); [90476.077469] invalid opcode: [#1] SMP [90476.077469] Modules linked in: iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack fuse btrfs zlib_deflate raid6_pq xor msdos ext4 mbcache jbd2 binfmt_misc bridge stp llc ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables cfg80211 rfkill sg iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp intel_rapl kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr igb vfat i2c_algo_bit dca fat sb_edac edac_core i2c_i801 lpc_ich i2c_core mfd_core shpchp acpi_pad ipmi_si ipmi_msghandler uinput nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sd_mod crc_t10dif crct10dif_common ahci libahci megaraid_sas tg3 ptp libata pps_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: rasf] [90476.157382] CPU: 2 PID: 322803 Comm: updatedb Tainted: GF W O-- 3.10.0-229.1.2.5.hulk.rc14.x86_64 #1 [90476.157382] Hardware name: HUAWEI TECHNOLOGIES CO.,LTD. Huawei N1/Huawei N1, BIOS V100R001 04/13/2015 [90476.157382] task: 88006a6d5b00 ti: 880068eb8000 task.ti: 880068eb8000 [90476.157382] RIP: 0010:[] [] move_freepages+0x12f/0x140 [90476.157382] RSP: 0018:880068ebb640 EFLAGS: 00010002 [90476.157382] RAX: 880002316cc0 RBX: ea0001bd RCX: 0001 [90476.157382] RDX: 880002476e40 RSI: RDI: 880002316cc0 [90476.157382] RBP: 880068ebb690 R08: 0010 R09: ea0001bd7fc0 [90476.157382] R10: 0006f5ff R11: R12: 0001 [90476.157382] R13: 0003 R14: 880002316eb8 R15: ea0001bd7fc0 [90476.157382] FS: 7f4d3ab95740() GS:880033a0() knlGS: [90476.157382] CS: 0010 DS: ES: CR0: 80050033 [90476.157382] CR2: 7f4d3ae1a808 CR3: 00018907a000 CR4: 001407e0 [90476.157382] DR0: DR1: DR2: [90476.157382] DR3: DR6: fffe0ff0 DR7: 0400 [90476.157382] Stack: [90476.157382] 880068ebb698 880002316cc0 a800b5378098 880068ebb698 [90476.157382] 810b11dc 880002316cc0 0001 0003 [90476.157382] 880002316eb8 ea0001bd6420 880068ebb6a0 8115a003 [90476.157382] Call Trace: [90476.157382] [] ? update_curr+0xcc/0x150 [90476.157382] [] move_freepages_block+0x73/0x80 [90476.157382] [] __rmqueue+0x26a/0x460 [90476.157382] [] ? native_sched_clock+0x13/0x80 [90476.157382] [] get_page_from_freelist+0x7f2/0xd30 [90476.157382] [] ? __switch_to+0x179/0x4a0 [90476.157382] [] ? xfs_iext_bno_to_ext+0xa7/0x1a0 [xfs] [90476.157382] [] __alloc_pages_nodemask+0x1c1/0xc90 [90476.157382] [] ? _xfs_buf_ioapply+0x31c/0x420 [xfs] [90476.157382] [] ? down_trylock+0x2d/0x40 [90476.157382] [] ? xfs_buf_trylock+0x1f/0x80 [xfs] [90476.157382] [] alloc_pages_current+0xa9/0x170 [90476.157382] [] new_slab+0x275/0x300 [90476.157382] [] __slab_alloc+0x315/0x48f [90476.157382] [] ? kmem_zone_alloc+0x77/0x100 [xfs] [90476.157382] [] ? xfs_bmap_search_extents+0x5c/0xc0 [xfs] [90476.157382] [] kmem_cache_alloc+0x193/0x1d0 [90476.157382] [] ? kmem_zone_alloc+0x77/0x100 [xfs] [90476.157382] [] kmem_zone_alloc+0x77/0x100 [xfs] [90476.157382] [] xfs_inode_alloc+0x25/0x250 [xfs] [90476.157382] [] xfs_iget+0x219/0x680 [xfs] [90476.157382] [] xfs_lookup+0xf6/0x120 [xfs] [90476.157382] [] xfs_vn_lookup+0x7b/0xd0 [xfs] [90476.157382] [] lookup_real+0x1d/0x50 [90476.157382] [] __lookup_hash+0x42/0x60 [90476.157382] [] lookup_slow+0x42/0xa7 [90476.157382] [] path_lookupat+0x76b/0x7a0 [90476.157382] [] ? do_last+0x635/0x1260 [90476.157382] [] ? kmem_cache_alloc+0x35/0x1d0 [90476.157382] [] ? getname_flags+0x4f/0x190 [90476.157382] [] filename_lookup+0x2b/
[PATCH 0/5] Add st_lpc clocksource timer driver.
Hi, Following on from the discussion here https://www.mail-archive.com/devicetree@vger.kernel.org/msg68857.html This series adds the st_lpc clocksource driver found on stih407 family silicon. Regardless of whether the change referenced above actually gets merged, adding this alternative clocksource driver is useful so that we can activate cpufreq upstream on stih407 family. regards, Peter. Peter Griffin (5): clocksource: st_lpc: Add LPC timer as a clocksource. clocksource: st_lpc: Add DT bindings documentation for lpc timer MAINTAINERS: Add st_lpc.c to ARCH/STI section of maintainers ARM: sti: Always enable CLKSRC_ST_LPC_CLOCK ARM: DT: STi: STiH407: Add DT node for st-lpc timer. .../devicetree/bindings/timer/st,lpc-timer.txt | 15 ++ MAINTAINERS| 1 + arch/arm/boot/dts/stih407-family.dtsi | 7 + arch/arm/mach-sti/Kconfig | 7 +- drivers/clocksource/Kconfig| 16 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/st_lpc.c | 154 + 7 files changed, 198 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/timer/st,lpc-timer.txt create mode 100644 drivers/clocksource/st_lpc.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: update README
On Thu, 16 Apr 2015 20:06:54 -0400 Justin Keller wrote: > The README file specifics 3.X kernel in different places. The kernel > is now 4.X, no longer 3.X I have an update in the docs tree, pull request coming probably later today. jon -- 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] video/logo: fix use logo after free prevention
Hi, On 04/17/2015 12:48 PM, Manfred Schlaegl wrote: After 92b004d1aa9f367c372511ca0330f58216b25703 the logos disappeared on Freescale i.MX53 and i.MX6 SoC's (detected on linux-3.12.37). This happens because the fb_find_logo function is validly called (initdata still not freed) AFTER newly introduced latecall fb_logo_late_init. Instead of stetting a logos_freed flag somewhere in lateinit, this patch uses system_state==SYSTEM_BOOTING as indication for valid initdata. The kernel init does free_initmem() call before setting the system_state to SYSTEM_RUNNING, so there's a period of time when the logos are freed, but the check in you patch does not catch it. Tomi -- 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] First batch of KVM changes for 4.1
On 17/04/2015 12:36, Peter Zijlstra wrote: > Now you make everybody pay for your crap, x86-64 paravirt or not. Keep > the cost by those who need it. > > Please take it out, ASAP. I'll just implement the static key. Paolo -- 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 kernel v8 17/31] powerpc/iommu/powernv: Release replaced TCE
On 04/16/2015 04:26 PM, David Gibson wrote:
On Fri, Apr 10, 2015 at 04:30:59PM +1000, Alexey Kardashevskiy wrote:
At the moment writing new TCE value to the IOMMU table fails with EBUSY
if there is a valid entry already. However PAPR specification allows
the guest to write new TCE value without clearing it first.
Another problem this patch is addressing is the use of pool locks for
external IOMMU users such as VFIO. The pool locks are to protect
DMA page allocator rather than entries and since the host kernel does
not control what pages are in use, there is no point in pool locks and
exchange()+put_page(oldtce) is sufficient to avoid possible races.
This adds an exchange() callback to iommu_table_ops which does the same
thing as set() plus it returns replaced TCE and DMA direction so
the caller can release the pages afterwards.
The returned old TCE value is a virtual address as the new TCE value.
This is different from tce_clear() which returns a physical address.
This implements exchange() for P5IOC2/IODA/IODA2. This adds a requirement
for a platform to have exchange() implemented in order to support VFIO.
This replaces iommu_tce_build() and iommu_clear_tce() with
a single iommu_tce_xchg().
This makes sure that TCE permission bits are not set in TCE passed to
IOMMU API as those are to be calculated by platform code from DMA direction.
This moves SetPageDirty() to the IOMMU code to make it work for both
VFIO ioctl interface in in-kernel TCE acceleration (when it becomes
available later).
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h| 17 ++--
arch/powerpc/kernel/iommu.c | 53 +---
arch/powerpc/platforms/powernv/pci-ioda.c | 38 ++
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 3 ++
arch/powerpc/platforms/powernv/pci.c| 17
arch/powerpc/platforms/powernv/pci.h| 2 +
drivers/vfio/vfio_iommu_spapr_tce.c | 62 ++---
7 files changed, 130 insertions(+), 62 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index d1f8c6c..bde7ee7 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -44,11 +44,22 @@ extern int iommu_is_off;
extern int iommu_force_on;
struct iommu_table_ops {
+ /* When called with direction==DMA_NONE, it is equal to clear() */
int (*set)(struct iommu_table *tbl,
long index, long npages,
unsigned long uaddr,
enum dma_data_direction direction,
struct dma_attrs *attrs);
+#ifdef CONFIG_IOMMU_API
+ /*
+* Exchanges existing TCE with new TCE plus direction bits;
+* returns old TCE and DMA direction mask
+*/
+ int (*exchange)(struct iommu_table *tbl,
+ long index,
+ unsigned long *tce,
+ enum dma_data_direction *direction);
+#endif
void (*clear)(struct iommu_table *tbl,
long index, long npages);
unsigned long (*get)(struct iommu_table *tbl, long index);
@@ -152,6 +163,8 @@ extern void iommu_register_group(struct iommu_table_group
*table_group,
extern int iommu_add_device(struct device *dev);
extern void iommu_del_device(struct device *dev);
extern int __init tce_iommu_bus_notifier_init(void);
+extern long iommu_tce_xchg(struct iommu_table *tbl, unsigned long entry,
+ unsigned long *tce, enum dma_data_direction *direction);
#else
static inline void iommu_register_group(struct iommu_table_group *table_group,
int pci_domain_number,
@@ -231,10 +244,6 @@ extern int iommu_tce_clear_param_check(struct iommu_table
*tbl,
unsigned long npages);
extern int iommu_tce_put_param_check(struct iommu_table *tbl,
unsigned long ioba, unsigned long tce);
-extern int iommu_tce_build(struct iommu_table *tbl, unsigned long entry,
- unsigned long hwaddr, enum dma_data_direction direction);
-extern unsigned long iommu_clear_tce(struct iommu_table *tbl,
- unsigned long entry);
extern void iommu_flush_tce(struct iommu_table *tbl);
extern int iommu_take_ownership(struct iommu_table_group *table_group);
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 068fe4ff..501e8ee 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -982,9 +982,6 @@ EXPORT_SYMBOL_GPL(iommu_tce_clear_param_check);
int iommu_tce_put_param_check(struct iommu_table *tbl,
unsigned long ioba, unsigned long tce)
{
- if (!(tce & (TCE_PCI_WRITE | TCE_PCI_READ)))
- return -EINVAL;
-
if (tce & ~(IOMMU_PAGE_MASK(tbl) | TCE_PCI_WRITE | TCE_PCI_READ))
return -EINVAL;
@@ -1002,44 +999,20 @@ int iommu_tce_put_param_check(struct i
Re: [GIT PULL] First batch of KVM changes for 4.1
On Fri, Apr 17, 2015 at 12:09:49PM +0200, Paolo Bonzini wrote: > > > On 17/04/2015 11:17, Peter Zijlstra wrote: > > On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote: > >> On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote: > >>> include/linux/sched.h |8 + > >>> kernel/sched/core.c| 15 + > >> > >> Can you please not puke over the scheduler without Acks from at least > >> one maintainer? > > Sorry, this was done while I was not handling the KVM tree. At the very > least the commit message should have included the original hashes of the > commit and the revert. This way one could have found the original Acks: > > commit 582b336ec2c0f0076f5650a029fcc9abd4a906f7 > Author: Marcelo Tosatti > Date: Tue Nov 27 23:28:54 2012 -0200 > > sched: add notifier for cross-cpu migrations > > Originally from Jeremy Fitzhardinge. > > Acked-by: Ingo Molnar > Signed-off-by: Marcelo Tosatti Still not a good reason to sneak it back it now, after I got it taken out. There was a reason it was removed, prior acks (esp. 2 year old ones) do not count one whit _NOW_. Also, Ingo later agreed that is was a mistake, http://marc.info/?l=linux-kernel&m=137346715521978&w=2 which is an effective retract of whatever ACK that was. It was crap code then and its crap code now. > >> I complained about this very thing two years ago: > >> > >> http://marc.info/?l=linux-kernel&m=137345253916751 > >> > >> And now it magically re-appears WTF! > > > > And I really don't understand _why_ you need that extra callback in the > > first place. You already have preempt notifiers, just track if you came > > in on another cpu than you went out on and voila! > > Then you pay for _all_ preemptions of _all_ processes in the guest, > instead of the hopefully rare ones that do a CPU migration. Now you make everybody pay for your crap, x86-64 paravirt or not. Keep the cost by those who need it. Please take it out, ASAP. -- 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] rcu: small rcu_dereference doc update
Make a note stating that repeated calls of rcu_dereference() may not return the same pointer if update happens while in critical section. Reported-by: Jeff Haran Signed-off-by: Milos Vyletel --- Documentation/RCU/whatisRCU.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 88dfce1..82b1b2c 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -256,7 +256,9 @@ rcu_dereference() If you are going to be fetching multiple fields from the RCU-protected structure, using the local variable is of course preferred. Repeated rcu_dereference() calls look - ugly and incur unnecessary overhead on Alpha CPUs. + ugly, do not guarantee that same pointer will be returned + if update happened while in critical section and incur + unnecessary overhead on Alpha CPUs. Note that the value returned by rcu_dereference() is valid only within the enclosing RCU read-side critical section. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 34/39] tick: broadcast-hrtimer: Remove overly clever return value abuse
On 04/15/2015 02:39 AM, Thomas Gleixner wrote:
> The assignment of bc_moved in the conditional construct relies on the
> fact that in the case of hrtimer_start() invocation the return value
> is always 0. It took me a while to understand it.
>
> We want to get rid of the hrtimer_start() return value. Open code the
> logic which makes it readable as well.
>
> Signed-off-by: Thomas Gleixner
> Cc: Preeti U Murthy
> ---
> kernel/time/tick-broadcast-hrtimer.c |8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> Index: tip/kernel/time/tick-broadcast-hrtimer.c
> ===
> --- tip.orig/kernel/time/tick-broadcast-hrtimer.c
> +++ tip/kernel/time/tick-broadcast-hrtimer.c
> @@ -66,9 +66,11 @@ static int bc_set_next(ktime_t expires,
>* hrtimer_{start/cancel} functions call into tracing,
>* calls to these functions must be bound within RCU_NONIDLE.
>*/
> - RCU_NONIDLE(bc_moved = (hrtimer_try_to_cancel(&bctimer) >= 0) ?
> - !hrtimer_start(&bctimer, expires, HRTIMER_MODE_ABS_PINNED) :
> - 0);
> + RCU_NONIDLE({
> + bc_moved = hrtimer_try_to_cancel(&bctimer) >= 0;
> + if (bc_moved)
> + hrtimer_start(&bctimer, expires,
> + HRTIMER_MODE_ABS_PINNED);});
> if (bc_moved) {
> /* Bind the "device" to the cpu */
> bc->bound_on = smp_processor_id();
Reviewed-by: Preeti U Murthy
--
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 11/15] serial: imx: initialized DMA w/o HW flow enabled
On 04/17/2015 11:18 AM, jiwang wrote: > Hello Sebastian Hallo Jiada, >> Please make sure it is tagged stable. There is no hint that this is >> required >> and as of it now, it breaks v4.0. > Due to missing of SDMA firmware, uart sdma mode is broken, > but it is uncovered by this commit on your environment. > >> One question, where do you have the firmware from? I picked the one >> from FSL's >> v3.10 SDK and I ended up with FIFO-overflows so it was clearly the >> wrong one >> (and the built-in SDMA firmware does not work as expected as you >> mentioned). > I got sdma firmware from FSL kernel tree. Can you post a link please? >> Is this firmware only required the imx6 series or also for older >> versions like >> imx5? > the firmware only supports imx6 series, AFAIK, What I meant is if imx5 (and earlier) have a working DMA without the SDMA firmware which seems to be required for IMX6. > I checked with Freescale imx6 support team, due to > licensing issue, I am not entitled to upstream FSL SDMA firmware. > so seems currently disable SDMA support for uart is our only option > at the moment. Disable it please, add a hint in the source so one knows _why_ it has been disabled and push it stable. In future you would need some kind of a hint from the sdma driver to let the uart know that the proper firmware is in place. Is it okay to send a patch against the linux-firmware tree? https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ > > Thanks, > Jiada Sebastian -- 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: AM335x OMAP2 common clock external fixed-clock registration
On Fri, Apr 17, 2015 at 11:12:03AM +0200, Sebastian Hesselbarth wrote: > On 17.04.2015 04:00, Michael Welling wrote: > >On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote: > >>On 17.04.2015 00:09, Michael Welling wrote: > >>>On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote: > On 16.04.2015 18:17, Michael Welling wrote: > [...] > >>>What would be the proper error path? > >>>What cleanup is required? > >> > >>A proper error path would be to release any claimed resource > >>on any error. If you look at the code, the only resources that > >>need to be released are the two clocks in question. > > > >So for every error return in the probe function and in the of si5351_dt_parse > >it needs to clk_put first right? > > Not quite. The driver should clk_put() every clock that it called a > [of_]clk_get() for. The thing is that clocks can be passed by > platform_data and we never claim them. I've always said clocks (as in struct clk) should never be passed through platform data. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver
On 17/04/15 11:00, Duc Dang wrote:
> On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier wrote:
>> On Tue, 14 Apr 2015 19:20:19 +0100
>> Duc Dang wrote:
>>
>>> On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier
>>> wrote:
On 2015-04-11 00:42, Duc Dang wrote:
>
> On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier
> wrote:
>>
>> On 09/04/15 18:05, Duc Dang wrote:
>>>
>>> X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
>>> 16 HW IRQ lines.
>>>
>>> Signed-off-by: Duc Dang
>>> Signed-off-by: Tanmay Inamdar
>>> ---
>>> drivers/pci/host/Kconfig | 6 +
>>> drivers/pci/host/Makefile| 1 +
>>> drivers/pci/host/pci-xgene-msi.c | 407
>>> +++
>>> drivers/pci/host/pci-xgene.c | 21 ++
>>> 4 files changed, 435 insertions(+)
>>> create mode 100644 drivers/pci/host/pci-xgene-msi.c
>>>
>>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>>> index 7b892a9..c9b61fa 100644
>>> --- a/drivers/pci/host/Kconfig
>>> +++ b/drivers/pci/host/Kconfig
>>> @@ -89,11 +89,17 @@ config PCI_XGENE
>>> depends on ARCH_XGENE
>>> depends on OF
>>> select PCIEPORTBUS
>>> + select PCI_MSI_IRQ_DOMAIN if PCI_MSI
>>> + select PCI_XGENE_MSI if PCI_MSI
>>> help
>>> Say Y here if you want internal PCI support on APM
>>> X-Gene SoC. There are 5 internal PCIe ports available. Each port
>>> is GEN3 capable
>>> and have varied lanes from x1 to x8.
>>>
>>> +config PCI_XGENE_MSI
>>> + bool "X-Gene v1 PCIe MSI feature"
>>> + depends on PCI_XGENE && PCI_MSI
>>> +
>>> config PCI_LAYERSCAPE
>>> bool "Freescale Layerscape PCIe controller"
>>> depends on OF && ARM
>>> diff --git a/drivers/pci/host/Makefile
>>> b/drivers/pci/host/Makefile index e61d91c..f39bde3 100644
>>> --- a/drivers/pci/host/Makefile
>>> +++ b/drivers/pci/host/Makefile
>>> @@ -11,5 +11,6 @@ obj-$(CONFIG_PCIE_SPEAR13XX) +=
>>> pcie-spear13xx.o obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o
>>> pci-keystone.o obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
>>> obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>>> +obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
>>> obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
>>> obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>>> diff --git a/drivers/pci/host/pci-xgene-msi.c
>>> b/drivers/pci/host/pci-xgene-msi.c
>>> new file mode 100644
>>> index 000..4f0ff42
>>> --- /dev/null
>>> +++ b/drivers/pci/host/pci-xgene-msi.c
>>> @@ -0,0 +1,407 @@
>>> +/*
>>> + * APM X-Gene MSI Driver
>>> + *
>>> + * Copyright (c) 2014, Applied Micro Circuits Corporation
>>> + * Author: Tanmay Inamdar
>>> + *Duc Dang
>>> + *
>>> + * This program is free software; you can redistribute it
>>> and/or modify it
>>> + * under the terms of the GNU General Public License as
>>> published by the
>>> + * Free Software Foundation; either version 2 of the License,
>>> or (at your
>>> + * option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be
>>> useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty
>>> of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define MSI_INDEX0 0x00
>>> +#define MSI_INT0 0x80
>>> +
>>> +struct xgene_msi_settings {
>>> + u32 index_per_group;
>>> + u32 irqs_per_index;
>>> + u32 nr_msi_vec;
>>> + u32 nr_hw_irqs;
>>> +};
>>> +
>>> +struct xgene_msi {
>>> + struct device_node *node;
>>> + struct msi_controller mchip;
>>> + struct irq_domain *domain;
>>> + struct xgene_msi_settings *settings;
>>> + u32 msi_addr_lo;
>>> + u32 msi_addr_hi;
>>
>>
>> I'd rather see the mailbox address directly, and only do the
>> split when assigning it to the message (you seem to play all kind
>> of tricks on the address anyway).
>
>
> msi_addr_lo and msi_addr_hi store the physical base address of MSI
> controller registers. I will add comment to clarify this.
What I mean is that there is no point in keeping this around as a
pair of 32bit variables. You'd better keep it as a single 64bit,
and do the split when assigning it the the MSI message.
>>>
>>> H
Re: [PATCH kernel v8 15/31] powerpc/iommu: Fix IOMMU ownership control functions
On 04/16/2015 04:10 PM, David Gibson wrote:
On Fri, Apr 10, 2015 at 04:30:57PM +1000, Alexey Kardashevskiy wrote:
This adds missing locks in iommu_take_ownership()/
iommu_release_ownership().
This marks all pages busy in iommu_table::it_map in order to catch
errors if there is an attempt to use this table while ownership over it
is taken.
This only clears TCE content if there is no page marked busy in it_map.
Clearing must be done outside of the table locks as iommu_clear_tce()
called from iommu_clear_tces_and_put_pages() does this.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v5:
* do not store bit#0 value, it has to be set for zero-based table
anyway
* removed test_and_clear_bit
---
arch/powerpc/kernel/iommu.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 7d6089b..068fe4ff 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1052,17 +1052,28 @@ EXPORT_SYMBOL_GPL(iommu_tce_build);
static int iommu_table_take_ownership(struct iommu_table *tbl)
{
- unsigned long sz = (tbl->it_size + 7) >> 3;
+ unsigned long flags, i, sz = (tbl->it_size + 7) >> 3;
+ int ret = 0;
+
+ spin_lock_irqsave(&tbl->large_pool.lock, flags);
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_lock(&tbl->pools[i].lock);
if (tbl->it_offset == 0)
clear_bit(0, tbl->it_map);
if (!bitmap_empty(tbl->it_map, tbl->it_size)) {
pr_err("iommu_tce: it_map is not empty");
- return -EBUSY;
+ ret = -EBUSY;
+ if (tbl->it_offset == 0)
+ set_bit(0, tbl->it_map);
This really needs a comment. Why on earth are you changing the it_map
on a failure case?
Does this explain?
/*
* The platform code reserves zero address in iommu_init_table().
* As we cleared busy bit for page @0 before using bitmap_empty(),
* we are restoring it now.
*/
+ } else {
+ memset(tbl->it_map, 0xff, sz);
}
- memset(tbl->it_map, 0xff, sz);
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_unlock(&tbl->pools[i].lock);
+ spin_unlock_irqrestore(&tbl->large_pool.lock, flags);
return 0;
}
@@ -1095,7 +1106,11 @@ EXPORT_SYMBOL_GPL(iommu_take_ownership);
static void iommu_table_release_ownership(struct iommu_table *tbl)
{
- unsigned long sz = (tbl->it_size + 7) >> 3;
+ unsigned long flags, i, sz = (tbl->it_size + 7) >> 3;
+
+ spin_lock_irqsave(&tbl->large_pool.lock, flags);
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_lock(&tbl->pools[i].lock);
memset(tbl->it_map, 0, sz);
@@ -1103,6 +1118,9 @@ static void iommu_table_release_ownership(struct
iommu_table *tbl)
if (tbl->it_offset == 0)
set_bit(0, tbl->it_map);
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_unlock(&tbl->pools[i].lock);
+ spin_unlock_irqrestore(&tbl->large_pool.lock, flags);
}
extern void iommu_release_ownership(struct iommu_table_group *table_group)
--
Alexey
--
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] firmware: dmi_scan: rename dmi_table to dmi_decode_table
On 17.04.15 11:54, Jean Delvare wrote: Hi Ivan, On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote: On 16.04.15 11:35, Jean Delvare wrote: On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote: Jean, do you want me to pick this patch up or are you going to? Good question, we need to agree on a strategy. There are 3 patch sets to consider here. 1* My patch fixing the UUID ordering bug. It must go in first and immediately, as it fixes a regression and will have to be backported to stable branches. || V 2* 2 older patches from Ivan which are currently in your efi-next tree if I'm not mistaken. Both were based on an old tree so they do not apply cleanly on kernel v4.0, I had to fix them up manually. I have They are in master tree already. no idea if git would be able to merge them properly, as the fix above changed the context even more. Current efi-next already merged, so you should base your patches on top of last changes. Correct. I looked at the result and the merge looks correct. I'll turn my objections into fixup patches to apply on top, where still worth it. In particular I'll start with the ".x" revert, as it will make backporting the bug fix easier. 3* The 3 new patches from Ivan which I am reviewing now, which are not applied in any public tree AFAIK. It shouldn't happen, I've been verifying just now once again. They are applied on top of linux_next cleanly. Equal as on efi/next. I can't see them at http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=next To clarify: I do not claim that they can't be applied, I'm only saying they're not there yet (which is OK as they were still pending my review.) They do apply just fine, no problem with this. I don't really care who picks these patches up and sends them to Linus, but I think they should all follow the same route so that Linus has as little merge work to do as possible. So either you pick them all, or I do. If I do, you'll have to drop the 2 patches you have in efi-next. Again I'm fine either way, so please let me know what makes your life easier and let's do that. I'm going to base my series "firmware: dmi_scan: add SBMIOS entry point and DMI tables" on top of linux next unless you have already your tree to pick up changes. Please let me know, if you have one. I have no formal tree yet, but my current patch set can be seen at: http://jdelvare.nerim.net/devel/linux-3/jdelvare-dmi/ First 2 patches from you are already upstream. You should rebase your updated patch series on top of upstream + patches 03 and 04, as they will go in first. Thanks, Not sure that's a good idea to base on patches that doesn't path any review and no one cannot apply. At least it be good you send them that I can point on them in commit message. -- Regards, Ivan Khoronzhuk -- 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 kernel v8 14/31] vfio: powerpc/spapr: powerpc/powernv/ioda2: Rework IOMMU ownership control
On 04/16/2015 04:07 PM, David Gibson wrote:
On Fri, Apr 10, 2015 at 04:30:56PM +1000, Alexey Kardashevskiy wrote:
At the moment the iommu_table struct has a set_bypass() which enables/
disables DMA bypass on IODA2 PHB. This is exposed to POWERPC IOMMU code
which calls this callback when external IOMMU users such as VFIO are
about to get over a PHB.
The set_bypass() callback is not really an iommu_table function but
IOMMU/PE function. This introduces a iommu_table_group_ops struct and
adds a set_ownership() callback to it which is called when an external
user takes control over the IOMMU.
Do you really need separate ops structures at both the single table
and table group level? The different tables in a group will all
belong to the same basic iommu won't they?
IOMMU tables exist alone in VIO. Also, the platform code uses just a table
(or it is in bypass mode) and does not care about table groups. It looked
more clean for myself to keep them separated. Should I still merge those?
This renames set_bypass() to set_ownership() as it is not necessarily
just enabling bypassing, it can be something else/more so let's give it
more generic name. The bool parameter is inverted.
The callback is implemented for IODA2 only. Other platforms (P5IOC2,
IODA1) will use the old iommu_take_ownership/iommu_release_ownership API.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h | 14 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 30 ++
drivers/vfio/vfio_iommu_spapr_tce.c | 25 +
3 files changed, 56 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index b9e50d3..d1f8c6c 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -92,7 +92,6 @@ struct iommu_table {
unsigned long it_page_shift;/* table iommu page size */
struct iommu_table_group *it_group;
struct iommu_table_ops *it_ops;
- void (*set_bypass)(struct iommu_table *tbl, bool enable);
};
/* Pure 2^n version of get_order */
@@ -127,11 +126,24 @@ extern struct iommu_table *iommu_init_table(struct
iommu_table * tbl,
#define IOMMU_TABLE_GROUP_MAX_TABLES 1
+struct iommu_table_group;
+
+struct iommu_table_group_ops {
+ /*
+* Switches ownership from the kernel itself to an external
+* user. While onwership is enabled, the kernel cannot use IOMMU
+* for itself.
+*/
+ void (*set_ownership)(struct iommu_table_group *table_group,
+ bool enable);
The meaning of "enable" in a function called "set_ownership" is
entirely obscure.
Suggest something better please :) I have nothing better...
+};
+
struct iommu_table_group {
#ifdef CONFIG_IOMMU_API
struct iommu_group *group;
#endif
struct iommu_table tables[IOMMU_TABLE_GROUP_MAX_TABLES];
+ struct iommu_table_group_ops *ops;
};
#ifdef CONFIG_IOMMU_API
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index a964c50..9687731 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1255,10 +1255,8 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb
*phb,
__free_pages(tce_mem, get_order(TCE32_TABLE_SIZE * segs));
}
-static void pnv_pci_ioda2_set_bypass(struct iommu_table *tbl, bool enable)
+static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
{
- struct pnv_ioda_pe *pe = container_of(tbl->it_group, struct pnv_ioda_pe,
- table_group);
uint16_t window_id = (pe->pe_number << 1 ) + 1;
int64_t rc;
@@ -1286,7 +1284,8 @@ static void pnv_pci_ioda2_set_bypass(struct iommu_table
*tbl, bool enable)
* host side.
*/
if (pe->pdev)
- set_iommu_table_base(&pe->pdev->dev, tbl);
+ set_iommu_table_base(&pe->pdev->dev,
+ &pe->table_group.tables[0]);
else
pnv_ioda_setup_bus_dma(pe, pe->pbus, false);
}
@@ -1302,13 +1301,27 @@ static void pnv_pci_ioda2_setup_bypass_pe(struct
pnv_phb *phb,
/* TVE #1 is selected by PCI address bit 59 */
pe->tce_bypass_base = 1ull << 59;
- /* Install set_bypass callback for VFIO */
- pe->table_group.tables[0].set_bypass = pnv_pci_ioda2_set_bypass;
-
/* Enable bypass by default */
- pnv_pci_ioda2_set_bypass(&pe->table_group.tables[0], true);
+ pnv_pci_ioda2_set_bypass(pe, true);
}
+static void pnv_ioda2_set_ownership(struct iommu_table_group *table_group,
+bool enable)
+{
+ struct pnv_ioda_pe *pe = container_of(table_group, struct pnv_ioda_pe,
+
Re: [GIT PULL] First batch of KVM changes for 4.1
On 17/04/2015 11:17, Peter Zijlstra wrote: > On Fri, Apr 17, 2015 at 10:52:38AM +0200, Peter Zijlstra wrote: >> On Fri, Apr 10, 2015 at 05:01:29PM +0200, Paolo Bonzini wrote: >>> include/linux/sched.h |8 + >>> kernel/sched/core.c| 15 + >> >> Can you please not puke over the scheduler without Acks from at least >> one maintainer? Sorry, this was done while I was not handling the KVM tree. At the very least the commit message should have included the original hashes of the commit and the revert. This way one could have found the original Acks: commit 582b336ec2c0f0076f5650a029fcc9abd4a906f7 Author: Marcelo Tosatti Date: Tue Nov 27 23:28:54 2012 -0200 sched: add notifier for cross-cpu migrations Originally from Jeremy Fitzhardinge. Acked-by: Ingo Molnar Signed-off-by: Marcelo Tosatti >> I complained about this very thing two years ago: >> >> http://marc.info/?l=linux-kernel&m=137345253916751 >> >> And now it magically re-appears WTF! > > And I really don't understand _why_ you need that extra callback in the > first place. You already have preempt notifiers, just track if you came > in on another cpu than you went out on and voila! Then you pay for _all_ preemptions of _all_ processes in the guest, instead of the hopefully rare ones that do a CPU migration. Preempt notifiers are registered on current only, this one is global. Of course, adding a static key is a good idea. I can also add a config symbol, selected by paravirt, if you want. Paolo -- 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/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver
On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier wrote:
> On Tue, 14 Apr 2015 19:20:19 +0100
> Duc Dang wrote:
>
>> On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier
>> wrote:
>> > On 2015-04-11 00:42, Duc Dang wrote:
>> >>
>> >> On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier
>> >> wrote:
>> >>>
>> >>> On 09/04/15 18:05, Duc Dang wrote:
>>
>> X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
>> 16 HW IRQ lines.
>>
>> Signed-off-by: Duc Dang
>> Signed-off-by: Tanmay Inamdar
>> ---
>> drivers/pci/host/Kconfig | 6 +
>> drivers/pci/host/Makefile| 1 +
>> drivers/pci/host/pci-xgene-msi.c | 407
>> +++
>> drivers/pci/host/pci-xgene.c | 21 ++
>> 4 files changed, 435 insertions(+)
>> create mode 100644 drivers/pci/host/pci-xgene-msi.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 7b892a9..c9b61fa 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -89,11 +89,17 @@ config PCI_XGENE
>> depends on ARCH_XGENE
>> depends on OF
>> select PCIEPORTBUS
>> + select PCI_MSI_IRQ_DOMAIN if PCI_MSI
>> + select PCI_XGENE_MSI if PCI_MSI
>> help
>> Say Y here if you want internal PCI support on APM
>> X-Gene SoC. There are 5 internal PCIe ports available. Each port
>> is GEN3 capable
>> and have varied lanes from x1 to x8.
>>
>> +config PCI_XGENE_MSI
>> + bool "X-Gene v1 PCIe MSI feature"
>> + depends on PCI_XGENE && PCI_MSI
>> +
>> config PCI_LAYERSCAPE
>> bool "Freescale Layerscape PCIe controller"
>> depends on OF && ARM
>> diff --git a/drivers/pci/host/Makefile
>> b/drivers/pci/host/Makefile index e61d91c..f39bde3 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -11,5 +11,6 @@ obj-$(CONFIG_PCIE_SPEAR13XX) +=
>> pcie-spear13xx.o obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o
>> pci-keystone.o obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
>> obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>> +obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
>> obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
>> obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>> diff --git a/drivers/pci/host/pci-xgene-msi.c
>> b/drivers/pci/host/pci-xgene-msi.c
>> new file mode 100644
>> index 000..4f0ff42
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-xgene-msi.c
>> @@ -0,0 +1,407 @@
>> +/*
>> + * APM X-Gene MSI Driver
>> + *
>> + * Copyright (c) 2014, Applied Micro Circuits Corporation
>> + * Author: Tanmay Inamdar
>> + *Duc Dang
>> + *
>> + * This program is free software; you can redistribute it
>> and/or modify it
>> + * under the terms of the GNU General Public License as
>> published by the
>> + * Free Software Foundation; either version 2 of the License,
>> or (at your
>> + * option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be
>> useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty
>> of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define MSI_INDEX0 0x00
>> +#define MSI_INT0 0x80
>> +
>> +struct xgene_msi_settings {
>> + u32 index_per_group;
>> + u32 irqs_per_index;
>> + u32 nr_msi_vec;
>> + u32 nr_hw_irqs;
>> +};
>> +
>> +struct xgene_msi {
>> + struct device_node *node;
>> + struct msi_controller mchip;
>> + struct irq_domain *domain;
>> + struct xgene_msi_settings *settings;
>> + u32 msi_addr_lo;
>> + u32 msi_addr_hi;
>> >>>
>> >>>
>> >>> I'd rather see the mailbox address directly, and only do the
>> >>> split when assigning it to the message (you seem to play all kind
>> >>> of tricks on the address anyway).
>> >>
>> >>
>> >> msi_addr_lo and msi_addr_hi store the physical base address of MSI
>> >> controller registers. I will add comment to clarify this.
>> >
>> >
>> > What I mean is that there is no point in keeping this around as a
>> > pair of 32bit variables. You'd better keep it as a single 64bit,
>> > and do the split when assigning it the the MSI message.
>>
>> Hi Marc,
>>
>> These came from device-tree (w
Re: [PATCH v3] dmaengine: xgene-dma: Fix sparse wannings and coccinelle warnings
On Friday 17 April 2015 14:41:02 Rameshwar Sahu wrote:
> >>
> >> -static void *xgene_dma_lookup_ext8(u64 *desc, int idx)
> >> +static __le64 *xgene_dma_lookup_ext8(struct xgene_dma_desc_hw *desc, int
> >> idx)
> >> {
> >> - return (idx % 2) ? (desc + idx - 1) : (desc + idx + 1);
> >> + switch (idx) {
> >> + case 0:
> >> + return &desc->m1;
> >> + case 1:
> >> + return &desc->m0;
> >> + case 2:
> >> + return &desc->m3;
> >> + case 3:
> >> + return &desc->m2;
> >> + default:
> >> + pr_err("Invalid dma descriptor index\n");
> >> + }
> >> +
> >> + return NULL;
> >> }
> >>
> > ...
> >
> >> /* Set 1st to 5th source addresses */
> >> for (i = 0; i < src_cnt; i++) {
> >> len = *nbytes;
> >> - xgene_dma_set_src_buffer((i == 0) ? (desc1 + 8) :
> >> + xgene_dma_set_src_buffer((i == 0) ? &desc1->m1 :
> >>xgene_dma_lookup_ext8(desc2, i - 1),
> >>&len, &src[i]);
> >> - XGENE_DMA_DESC_MULTI_SET(desc1, scf[i], i);
> >> + desc1->m2 |= cpu_to_le64((scf[i] << ((i + 1) * 8)));
> >> }
> >
> > If you just unroll this loop, you get code that is smaller and easier to
> > understand:
> >
> > /* Set 1st to 5th source addresses */
> > xgene_dma_set_src_buffer(&desc1->m1, &len, &src[0]);
> > xgene_dma_set_src_buffer(&desc2->m0, &len, &src[1]);
> > xgene_dma_set_src_buffer(&desc2->m3, &len, &src[2]);
> > xgene_dma_set_src_buffer(&desc2->m2, &len, &src[3]);
> > desc1->m2 |= cpu_to_le64(scf[0] | scf[1] << 8 | scf[2] << 16 |
> > scf[3] << 24);
>
> Actually here, in run time src_cnt value can be 2 or 3 upto 5, so we
> can't unroll it.
I see, sorry for misreading the code. The patch is good then as it is.
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/
[PATCH v4 2/4] arm64: dts: Add the device tree entry for the APM X-Gene PCIe MSI node
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
arch/arm64/boot/dts/apm/apm-storm.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index f1ad9c2..4b719c9 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -354,6 +354,28 @@
};
};
+ msi: msi@7900 {
+ compatible = "apm,xgene1-msi";
+ msi-controller;
+ reg = <0x00 0x7900 0x0 0x90>;
+ interrupts = < 0x0 0x10 0x4
+ 0x0 0x11 0x4
+ 0x0 0x12 0x4
+ 0x0 0x13 0x4
+ 0x0 0x14 0x4
+ 0x0 0x15 0x4
+ 0x0 0x16 0x4
+ 0x0 0x17 0x4
+ 0x0 0x18 0x4
+ 0x0 0x19 0x4
+ 0x0 0x1a 0x4
+ 0x0 0x1b 0x4
+ 0x0 0x1c 0x4
+ 0x0 0x1d 0x4
+ 0x0 0x1e 0x4
+ 0x0 0x1f 0x4>;
+ };
+
pcie0: pcie@1f2b {
status = "disabled";
device_type = "pci";
@@ -375,6 +397,7 @@
0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
dma-coherent;
clocks = <&pcie0clk 0>;
+ msi-parent = <&msi>;
};
pcie1: pcie@1f2c {
@@ -398,6 +421,7 @@
0x0 0x0 0x0 0x4 &gic 0x0 0xcb 0x1>;
dma-coherent;
clocks = <&pcie1clk 0>;
+ msi-parent = <&msi>;
};
pcie2: pcie@1f2d {
@@ -421,6 +445,7 @@
0x0 0x0 0x0 0x4 &gic 0x0 0xd1 0x1>;
dma-coherent;
clocks = <&pcie2clk 0>;
+ msi-parent = <&msi>;
};
pcie3: pcie@1f50 {
@@ -444,6 +469,7 @@
0x0 0x0 0x0 0x4 &gic 0x0 0xd7 0x1>;
dma-coherent;
clocks = <&pcie3clk 0>;
+ msi-parent = <&msi>;
};
pcie4: pcie@1f51 {
@@ -467,6 +493,7 @@
0x0 0x0 0x0 0x4 &gic 0x0 0xdd 0x1>;
dma-coherent;
clocks = <&pcie4clk 0>;
+ msi-parent = <&msi>;
};
serial0: serial@1c02 {
--
1.9.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 v4 4/4] PCI: X-Gene: Add the MAINTAINERS entry for APM X-Gene v1 PCIe MSI driver
This patch adds information of maintainers for APM X-Gene v1 PCIe MSI/MSIX termination driver Signed-off-by: Duc Dang Signed-off-by: Tanmay Inamdar --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ddc5a8c..a1b119b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7490,6 +7490,14 @@ L: linux-...@vger.kernel.org S: Maintained F: drivers/pci/host/*spear* +PCI MSI DRIVER FOR APPLIEDMICRO XGENE +M: Duc Dang +L: linux-...@vger.kernel.org +L: linux-arm-ker...@lists.infradead.org +S: Maintained +F: Documentation/devicetree/bindings/pci/xgene-pci-msi.txt +F: drivers/pci/host/pci-xgene-msi.c + PCMCIA SUBSYSTEM P: Linux PCMCIA Team L: linux-pcm...@lists.infradead.org -- 1.9.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 v4 3/4] documentation: dts: Add the device tree binding for APM X-Gene v1 PCIe MSI device tree node
The driver for this binding is under 'drivers/pci/host/pci-xgene-msi.c'
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
.../devicetree/bindings/pci/xgene-pci-msi.txt | 63 ++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci-msi.txt
diff --git a/Documentation/devicetree/bindings/pci/xgene-pci-msi.txt
b/Documentation/devicetree/bindings/pci/xgene-pci-msi.txt
new file mode 100644
index 000..0ffdcb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xgene-pci-msi.txt
@@ -0,0 +1,63 @@
+* AppliedMicro X-Gene PCIe MSI interface
+
+Required properties:
+
+- compatible: should contain "apm,xgene1-msi" to identify the core.
+- msi-controller: indicates that this is X-Gene1 PCIe MSI controller node
+- reg: A list of physical base address and length for each set of controller
+ registers.
+- interrupts: A list of interrupt outputs of the controller.
+
+Each PCIe node needs to have property msi-parent that points to msi controller
node
+
+Examples:
+
+SoC DTSI:
+
+ + MSI node:
+ msi@7900 {
+ compatible = "apm,xgene1-msi";
+ msi-controller;
+ reg = <0x00 0x7900 0x0 0x90>;
+ interrupts = < 0x0 0x10 0x4
+ 0x0 0x11 0x4
+ 0x0 0x12 0x4
+ 0x0 0x13 0x4
+ 0x0 0x14 0x4
+ 0x0 0x15 0x4
+ 0x0 0x16 0x4
+ 0x0 0x17 0x4
+ 0x0 0x18 0x4
+ 0x0 0x19 0x4
+ 0x0 0x1a 0x4
+ 0x0 0x1b 0x4
+ 0x0 0x1c 0x4
+ 0x0 0x1d 0x4
+ 0x0 0x1e 0x4
+ 0x0 0x1f 0x4>;
+ };
+
+ + PCIe controller node with msi-parent property pointing to MSI node:
+ pcie0: pcie@1f2b {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f2b 0x0 0x0001 /* Controller
registers */
+ 0xe0 0xd000 0x0 0x0004>; /* PCI config space */
+ reg-names = "csr", "cfg";
+ ranges = <0x0100 0x00 0x 0xe0 0x1000 0x00
0x0001 /* io */
+ 0x0200 0x00 0x8000 0xe1 0x8000 0x00
0x8000>; /* mem */
+ dma-ranges = <0x4200 0x80 0x 0x80 0x 0x00
0x8000
+ 0x4200 0x00 0x 0x00 0x 0x80
0x>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1
+0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1
+0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1
+0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
+ dma-coherent;
+ clocks = <&pcie0clk 0>;
+ msi-parent= <&msi>;
+ };
--
1.9.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/
[GIT PULL] bulk GPIO changes for the v4.1 cycle
Hi Linus, this is the bulk of GPIO changes queued for v4.1. It's quite a lot of change for being GPIO, tested in linux-next plus I also took a few extra rounds of allmod compilation after the debacle with pin control (which is fixed, by the way). The details are in the signed tag. As you noticed Kconfig is not always my friend so just beat me up if I got something wrong, I'm trying my best. Please pull it in! Yours, Linus Walleij The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-v4.1-1 for you to fetch changes up to 03daa6f82f2b634019fe8261698f6af3c133497f: Revert "gpio: sch: use uapi/linux/pci_ids.h directly" (2015-04-10 11:35:45 +0200) This is the bulk of GPIO changes for the v4.1 development cycle: - A new GPIO hogging mechanism has been added. This can be used on boards that want to drive some GPIO line high, low, or set it as input on boot and then never touch it again. For some embedded systems this is bliss and simplifies things to a great extent. - Some API cleanup and closure: gpiod_get_array() and gpiod_put_array() has been added to get and put GPIOs in bulk as was possible with the non-descriptor API. - Encapsulate cross-calls to the pin control subsystem in . Now this should be the only header any GPIO driver needs to include or something is wrong. Cleanups restricting drivers to this include are welcomed if tested. - Sort the GPIO Kconfig and split it into submenus, as it was becoming and unstructured, illogical and unnavigatable mess. I hope this is easier to follow. Menus that require a certain subsystem like I2C can now be hidden nicely for example, still working on others. - New drivers: - New driver for the Altera Soft GPIO. - The F7188x driver now handles the F71869 and F71869A variants. - The MIPS Loongson driver has been moved to drivers/gpio for consolidation and cleanup. - Cleanups: - The MAX732x is converted to use the GPIOLIB_IRQCHIP infrastructure. - The PCF857x is converted to use the GPIOLIB_IRQCHIP infrastructure. - Radical cleanup of the OMAP driver. - Misc: - Enable the DWAPB GPIO for all architectures. This is a "hard IP" block from Synopsys which has started to turn up in so diverse architectures as X86 Quark, ARC and a slew of ARM systems. So even though it's not an expander, it's generic enough to be available for all. - We add a mock GPIO on Crystalcove PMIC after a long discussion with Daniel Vetter et al, tracing back to the shootout at the kernel summit where DRM drivers and sub-componentization was discussed. In this case a mock GPIO is assumed to be the best compromise gaining some reuse of infrastructure without making DRM drivers overly complex at the same time. Let's see. Aaron Sierra (1): gpio: ich: Implement get_direction function Andreas Bofjall (3): gpio: f7188x: correct spelling of "Fintek" gpio: f7188x: add GPIO support for F71869 gpio: f7188x: add GPIO support for F71869A Andy Shevchenko (1): gpio: dwapb: enable for Quark Axel Lin (2): gpio: mb86s70: Return error if requesting an already assigned gpio gpio: vf610: Replaces comma between expression statements by semicolon Benoit Parrot (2): gpio: add GPIO hogging mechanism gpio: Document GPIO hogging mechanism Dmitry Torokhov (1): gpio: gpio-tb10x: remove incorrect __exit markup Geert Uytterhoeven (5): gpio: pcf857x: Switch to use gpiolib irqchip helpers gpio: pcf857x: Propagate wake-up setting to parent irq controller gpio: rcar: Use local variable gpio_chip in gpio_rcar_probe() gpio: rcar: Add more register documentation gpio: rcar: Prevent module clock disable when wake-up is enabled Gregory CLEMENT (1): gpio: mvebu: Fix mask/unmask managment per irq chip type Grygorii Strashko (9): gpio: omap: irq_shutdown: remove unnecessary call of gpiochip_unlock_as_irq gpio: omap: convert omap_gpio_is_input() to use gpio offset gpio: omap: simplify omap_set_gpio_dataout_x() gpio: omap: convert debounce functions switch to use gpio offset gpio: omap: drop 'gpio' param from omap_gpio_init_irq() gpio: omap: convert gpio irq functions to use GPIO offset gpio: omap: get rid of GPIO_BIT() macro gpio: omap: get rid of omap_irq_to_gpio() gpio: omap: get rid of GPIO_INDEX() macro Huacai Chen (3): MIPS: Cleanup Loongson-2F's gpio driver MIPS: Move Loongson GPIO driver to drivers/gpio gpio: loongson: Add Loongson-3A/3B GPIO driver support Josh Wu (1): gpio: mrvl: docume
[PATCH v4 1/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver
X-Gene v1 SoC supports total 2048 MSI/MSIX vectors coalesced into
16 HW IRQ lines.
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
drivers/pci/host/Kconfig | 6 +
drivers/pci/host/Makefile| 1 +
drivers/pci/host/pci-xgene-msi.c | 410 +++
drivers/pci/host/pci-xgene.c | 21 ++
4 files changed, 438 insertions(+)
create mode 100644 drivers/pci/host/pci-xgene-msi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 7b892a9..c9b61fa 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -89,11 +89,17 @@ config PCI_XGENE
depends on ARCH_XGENE
depends on OF
select PCIEPORTBUS
+ select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+ select PCI_XGENE_MSI if PCI_MSI
help
Say Y here if you want internal PCI support on APM X-Gene SoC.
There are 5 internal PCIe ports available. Each port is GEN3 capable
and have varied lanes from x1 to x8.
+config PCI_XGENE_MSI
+ bool "X-Gene v1 PCIe MSI feature"
+ depends on PCI_XGENE && PCI_MSI
+
config PCI_LAYERSCAPE
bool "Freescale Layerscape PCIe controller"
depends on OF && ARM
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index e61d91c..f39bde3 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -11,5 +11,6 @@ obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
+obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
new file mode 100644
index 000..f53b581e
--- /dev/null
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -0,0 +1,410 @@
+/*
+ * APM X-Gene MSI Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Tanmay Inamdar
+ *Duc Dang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MSI_IR00x00
+#define MSI_INT0 0x80
+
+#define IDX_PER_GROUP 8
+#define IRQS_PER_IDX 16
+#define NR_HW_IRQS 16
+#define NR_MSI_VEC (IDX_PER_GROUP * IRQS_PER_IDX * NR_HW_IRQS)
+
+struct xgene_msi {
+ struct device_node *node;
+ struct msi_controller mchip;
+ struct irq_domain *domain;
+ u64 msi_addr;
+ void __iomem*msi_regs;
+ unsigned long *bitmap;
+ struct mutexbitmap_lock;
+ int *msi_virqs;
+};
+
+static struct irq_chip xgene_msi_top_irq_chip = {
+ .name = "X-Gene1 MSI",
+ .irq_enable = pci_msi_unmask_irq,
+ .irq_disable= pci_msi_mask_irq,
+ .irq_mask = pci_msi_mask_irq,
+ .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info xgene_msi_domain_info = {
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+ MSI_FLAG_PCI_MSIX),
+ .chip = &xgene_msi_top_irq_chip,
+};
+
+/*
+ * X-Gene v1 has 16 groups of MSI termination registers MSInIRx, where
+ * n is group number (0..F), x is index of registers in each group (0..7)
+ * The registers layout is like following:
+ * MSI0IR0 base_addr
+ * MSI0IR1 base_addr + 0x1
+ * ... ...
+ * MSI0IR6 base_addr + 0x6
+ * MSI0IR7 base_addr + 0x7
+ * MSI1IR0 base_addr + 0x8
+ * MSI1IR1 base_addr + 0x9
+ * ... ...
+ * MSI1IR7 base_addr + 0xF
+ * MSI2IR0 base_addr + 0x10
+ * ... ...
+ * MSIFIR0 base_addr + 0x78
+ * MSIFIR1 base_addr + 0x79
+ * ... ...
+ * MSIFIR7 base_addr + 0x7F
+ *
+ * Each index register support 16 MSI vectors (0..15) to generate interrupt.
+ * There are total 16 GIC IRQs assigned for these 16 groups of MSI termination
+ * registers.
+ *
+ * With 2048
[PATCH v4 0/4] PCI: X-Gene: Add APM X-Gene v1 MSI/MSIX termination driver
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC. APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant to GIC V2M specification for MSI Termination. There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This MSI block supports 2048 MSI termination ports coalesced into 16 physical HW IRQ lines and shared across all 5 PCIe ports. v4 changes: 1. Remove affinity setting for each MSI 2. Add description about register layout, MSI termination address and data 3. Correct total number of MSI vectors to 2048 4. Clean up error messages 5. Remove unused module code v3 changes: 1. Implement MSI support using PCI MSI IRQ domain 2. Only use msi_controller to store IRQ domain v2 changes: 1. Use msi_controller structure 2. Remove arch hooks arch_teardown_msi_irqs and arch_setup_msi_irqs .../devicetree/bindings/pci/xgene-pci-msi.txt | 63 MAINTAINERS| 8 + arch/arm64/boot/dts/apm/apm-storm.dtsi | 27 ++ drivers/pci/host/Kconfig | 6 + drivers/pci/host/Makefile | 1 + drivers/pci/host/pci-xgene-msi.c | 410 + drivers/pci/host/pci-xgene.c | 21 ++ 7 files changed, 536 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci-msi.txt create mode 100644 drivers/pci/host/pci-xgene-msi.c -- 1.9.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/
[RFC PATCH v2 04/11] lib: memory management (kernel glue code)
Signed-off-by: Hajime Tazaki
---
arch/lib/slab.c | 203
1 file changed, 203 insertions(+)
create mode 100644 arch/lib/slab.c
diff --git a/arch/lib/slab.c b/arch/lib/slab.c
new file mode 100644
index 000..a08f736
--- /dev/null
+++ b/arch/lib/slab.c
@@ -0,0 +1,203 @@
+/*
+ * glue code for library version of Linux kernel
+ * Copyright (c) 2015 INRIA, Hajime Tazaki
+ *
+ * Author: Mathieu Lacage
+ * Hajime Tazaki
+ */
+
+#include "sim.h"
+#include "sim-assert.h"
+#include
+#include
+#include
+
+/* glues */
+struct kmem_cache *files_cachep;
+
+void kfree(const void *p)
+{
+ unsigned long start;
+
+ if (p == 0)
+ return;
+ start = (unsigned long)p;
+ start -= sizeof(size_t);
+ lib_free((void *)start);
+}
+size_t ksize(const void *p)
+{
+ size_t *psize = (size_t *)p;
+
+ psize--;
+ return *psize;
+}
+void *__kmalloc(size_t size, gfp_t flags)
+{
+ void *p = lib_malloc(size + sizeof(size));
+ unsigned long start;
+
+ if (!p)
+ return NULL;
+
+ if (p != 0 && (flags & __GFP_ZERO))
+ lib_memset(p, 0, size + sizeof(size));
+ lib_memcpy(p, &size, sizeof(size));
+ start = (unsigned long)p;
+ return (void *)(start + sizeof(size));
+}
+
+void *__kmalloc_track_caller(size_t size, gfp_t flags, unsigned long caller)
+{
+ return kmalloc(size, flags);
+}
+
+void *krealloc(const void *p, size_t new_size, gfp_t flags)
+{
+ void *ret;
+
+ if (!new_size) {
+ kfree(p);
+ return ZERO_SIZE_PTR;
+ }
+
+ ret = __kmalloc(new_size, flags);
+ if (ret && p != ret)
+ kfree(p);
+
+ return ret;
+}
+
+struct kmem_cache *
+kmem_cache_create(const char *name, size_t size, size_t align,
+ unsigned long flags, void (*ctor)(void *))
+{
+ struct kmem_cache *cache = kmalloc(sizeof(struct kmem_cache), flags);
+
+ if (!cache)
+ return NULL;
+ cache->name = name;
+ cache->size = size;
+ cache->align = align;
+ cache->flags = flags;
+ cache->ctor = ctor;
+ return cache;
+}
+void kmem_cache_destroy(struct kmem_cache *cache)
+{
+ kfree(cache);
+}
+int kmem_cache_shrink(struct kmem_cache *cache)
+{
+ return 1;
+}
+const char *kmem_cache_name(struct kmem_cache *cache)
+{
+ return cache->name;
+}
+void *kmem_cache_alloc(struct kmem_cache *cache, gfp_t flags)
+{
+ void *p = kmalloc(cache->size, flags);
+
+ if (p == 0)
+ return NULL;
+ if (cache->ctor)
+ (cache->ctor)(p);
+ return p;
+
+}
+void kmem_cache_free(struct kmem_cache *cache, void *p)
+{
+ kfree(p);
+}
+
+struct page *
+__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
+ struct zonelist *zonelist, nodemask_t *nodemask)
+{
+ void *p;
+ struct page *page;
+ unsigned long pointer;
+
+ /* typically, called from networking code by alloc_page or */
+ /* directly with an order = 0. */
+ if (order)
+ return NULL;
+ p = lib_malloc(sizeof(struct page) + (1 << PAGE_SHIFT));
+ page = (struct page *)p;
+
+ atomic_set(&page->_count, 1);
+ page->flags = 0;
+ pointer = (unsigned long)page;
+ pointer += sizeof(struct page);
+ page->virtual = (void *)pointer;
+ return page;
+}
+void __free_pages(struct page *page, unsigned int order)
+{
+ /* typically, called from networking code by __free_page */
+ lib_assert(order == 0);
+ lib_free(page);
+}
+
+void put_page(struct page *page)
+{
+ if (atomic_dec_and_test(&page->_count))
+ lib_free(page);
+}
+unsigned long get_zeroed_page(gfp_t gfp_mask)
+{
+ return __get_free_pages(gfp_mask | __GFP_ZERO, 0);
+}
+
+void *alloc_pages_exact(size_t size, gfp_t gfp_mask)
+{
+ return alloc_pages(gfp_mask, get_order(size));
+}
+
+unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)
+{
+ int size = (1 << order) * PAGE_SIZE;
+ void *p = kmalloc(size, gfp_mask);
+
+ return (unsigned long)p;
+}
+void free_pages(unsigned long addr, unsigned int order)
+{
+ if (addr != 0)
+ kfree((void *)addr);
+}
+
+void *vmalloc(unsigned long size)
+{
+ return lib_malloc(size);
+}
+void *__vmalloc(unsigned long size, gfp_t gfp_mask, pgprot_t prot)
+{
+ return kmalloc(size, gfp_mask);
+}
+void vfree(const void *addr)
+{
+ lib_free((void *)addr);
+}
+void *vmalloc_node(unsigned long size, int node)
+{
+ return lib_malloc(size);
+}
+void vmalloc_sync_all(void)
+{
+}
+void *__alloc_percpu(size_t size, size_t align)
+{
+ return kzalloc(size, GFP_KERNEL);
+}
+void free_percpu(void __percpu *ptr)
+{
+ kfree(ptr);
+}
+void *__alloc_bootmem_nopanic(unsigned long size,
+ unsigned long align,
+
[RFC PATCH v2 09/11] lib: asm-generic files
Signed-off-by: Hajime Tazaki
---
arch/lib/include/asm/Kbuild | 57 +++
arch/lib/include/asm/atomic.h | 50 ++
arch/lib/include/asm/barrier.h| 8 +
arch/lib/include/asm/bitsperlong.h| 12
arch/lib/include/asm/current.h| 7 +
arch/lib/include/asm/elf.h| 10 ++
arch/lib/include/asm/hardirq.h| 8 +
arch/lib/include/asm/page.h | 14 +
arch/lib/include/asm/pgtable.h| 30 ++
arch/lib/include/asm/processor.h | 19
arch/lib/include/asm/ptrace.h | 4 +++
arch/lib/include/asm/segment.h| 6
arch/lib/include/asm/sembuf.h | 4 +++
arch/lib/include/asm/shmbuf.h | 4 +++
arch/lib/include/asm/shmparam.h | 4 +++
arch/lib/include/asm/sigcontext.h | 6
arch/lib/include/asm/slab.h | 21 +
arch/lib/include/asm/stat.h | 4 +++
arch/lib/include/asm/statfs.h | 4 +++
arch/lib/include/asm/swab.h | 7 +
arch/lib/include/asm/thread_info.h| 36 ++
arch/lib/include/asm/uaccess.h| 14 +
arch/lib/include/asm/unistd.h | 4 +++
arch/lib/include/uapi/asm/byteorder.h | 6
24 files changed, 339 insertions(+)
create mode 100644 arch/lib/include/asm/Kbuild
create mode 100644 arch/lib/include/asm/atomic.h
create mode 100644 arch/lib/include/asm/barrier.h
create mode 100644 arch/lib/include/asm/bitsperlong.h
create mode 100644 arch/lib/include/asm/current.h
create mode 100644 arch/lib/include/asm/elf.h
create mode 100644 arch/lib/include/asm/hardirq.h
create mode 100644 arch/lib/include/asm/page.h
create mode 100644 arch/lib/include/asm/pgtable.h
create mode 100644 arch/lib/include/asm/processor.h
create mode 100644 arch/lib/include/asm/ptrace.h
create mode 100644 arch/lib/include/asm/segment.h
create mode 100644 arch/lib/include/asm/sembuf.h
create mode 100644 arch/lib/include/asm/shmbuf.h
create mode 100644 arch/lib/include/asm/shmparam.h
create mode 100644 arch/lib/include/asm/sigcontext.h
create mode 100644 arch/lib/include/asm/slab.h
create mode 100644 arch/lib/include/asm/stat.h
create mode 100644 arch/lib/include/asm/statfs.h
create mode 100644 arch/lib/include/asm/swab.h
create mode 100644 arch/lib/include/asm/thread_info.h
create mode 100644 arch/lib/include/asm/uaccess.h
create mode 100644 arch/lib/include/asm/unistd.h
create mode 100644 arch/lib/include/uapi/asm/byteorder.h
diff --git a/arch/lib/include/asm/Kbuild b/arch/lib/include/asm/Kbuild
new file mode 100644
index 000..c647b1c
--- /dev/null
+++ b/arch/lib/include/asm/Kbuild
@@ -0,0 +1,57 @@
+generic-y += auxvec.h
+generic-y += bitops.h
+generic-y += bug.h
+generic-y += cache.h
+generic-y += cacheflush.h
+generic-y += checksum.h
+generic-y += cputime.h
+generic-y += cmpxchg.h
+generic-y += delay.h
+generic-y += device.h
+generic-y += div64.h
+generic-y += dma.h
+generic-y += exec.h
+generic-y += emergency-restart.h
+generic-y += errno.h
+generic-y += fcntl.h
+generic-y += ftrace.h
+generic-y += io.h
+generic-y += ioctl.h
+generic-y += ioctls.h
+generic-y += ipcbuf.h
+generic-y += irq.h
+generic-y += irqflags.h
+generic-y += irq_regs.h
+generic-y += kdebug.h
+generic-y += kmap_types.h
+generic-y += linkage.h
+generic-y += local.h
+generic-y += mcs_spinlock.h
+generic-y += mman.h
+generic-y += mmu.h
+generic-y += mmu_context.h
+generic-y += module.h
+generic-y += mutex.h
+generic-y += param.h
+generic-y += pci.h
+generic-y += percpu.h
+generic-y += poll.h
+generic-y += posix_types.h
+generic-y += preempt.h
+generic-y += resource.h
+generic-y += scatterlist.h
+generic-y += sections.h
+generic-y += setup.h
+generic-y += signal.h
+generic-y += siginfo.h
+generic-y += socket.h
+generic-y += sockios.h
+generic-y += string.h
+generic-y += termbits.h
+generic-y += termios.h
+generic-y += timex.h
+generic-y += tlbflush.h
+generic-y += types.h
+generic-y += topology.h
+generic-y += trace_clock.h
+generic-y += unaligned.h
diff --git a/arch/lib/include/asm/atomic.h b/arch/lib/include/asm/atomic.h
new file mode 100644
index 000..41a49285
--- /dev/null
+++ b/arch/lib/include/asm/atomic.h
@@ -0,0 +1,50 @@
+#ifndef _ASM_SIM_ATOMIC_H
+#define _ASM_SIM_ATOMIC_H
+
+#include
+
+#if !defined(CONFIG_64BIT)
+typedef struct {
+ volatile long long counter;
+} atomic64_t;
+#endif
+
+#define ATOMIC64_INIT(i) { (i) }
+
+#define atomic64_read(v)(*(volatile long *)&(v)->counter)
+void atomic64_add(long i, atomic64_t *v);
+static inline void atomic64_sub(long i, atomic64_t *v)
+{
+ v->counter -= i;
+}
+static inline void atomic64_inc(atomic64_t *v)
+{
+ v->counter++;
+}
+int atomic64_sub_and_test(long i, atomic64_t *v);
+#define atomic64_dec(v)atomic64_sub(1LL, (v))
+int atomic64_dec_and_test(atomic64_t *v);
+int atomic64_inc_and_test(atomic64_t *v);
+int at
[PATCH] video/logo: fix use logo after free prevention
After 92b004d1aa9f367c372511ca0330f58216b25703 the logos disappeared on
Freescale i.MX53 and i.MX6 SoC's (detected on linux-3.12.37).
This happens because the fb_find_logo function is validly called
(initdata still not freed) AFTER newly introduced latecall
fb_logo_late_init.
Instead of stetting a logos_freed flag somewhere in lateinit, this patch
uses system_state==SYSTEM_BOOTING as indication for valid initdata.
Signed-off-by: Manfred Schlaegl
---
drivers/video/logo/logo.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index 10fbfd8..ad37561 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -21,21 +21,6 @@ static bool nologo;
module_param(nologo, bool, 0);
MODULE_PARM_DESC(nologo, "Disables startup logo");
-/*
- * Logos are located in the initdata, and will be freed in kernel_init.
- * Use late_init to mark the logos as freed to prevent any further use.
- */
-
-static bool logos_freed;
-
-static int __init fb_logo_late_init(void)
-{
- logos_freed = true;
- return 0;
-}
-
-late_initcall(fb_logo_late_init);
-
/* logo's are marked __initdata. Use __init_refok to tell
* modpost that it is intended that this function uses data
* marked __initdata.
@@ -44,7 +29,11 @@ const struct linux_logo * __init_refok fb_find_logo(int
depth)
{
const struct linux_logo *logo = NULL;
- if (nologo || logos_freed)
+ /*
+* Logos are located in the initdata, and will be freed in kernel_init.
+* Use system_state to determine, if initdata is still useable.
+*/
+ if (nologo || system_state != SYSTEM_BOOTING)
return NULL;
if (depth >= 1) {
--
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 1/4] fs: Add generic file system event notifications
Hi, On 04/16/2015 11:56 PM, Heinrich Schuchardt wrote: > On 15.04.2015 09:15, Beata Michalska wrote: >> Introduce configurable generic interface for file >> system-wide event notifications to provide file >> systems with a common way of reporting any potential >> issues as they emerge. >> >> The notifications are to be issued through generic >> netlink interface, by a dedicated, for file system >> events, multicast group. The file systems might as >> well use this group to send their own custom messages. >> >> The events have been split into four base categories: >> information, warnings, errors and threshold notifications, >> with some very basic event types like running out of space >> or file system being remounted as read-only. >> >> Threshold notifications have been included to allow >> triggering an event whenever the amount of free space >> drops below a certain level - or levels to be more precise >> as two of them are being supported: the lower and the upper >> range. The notifications work both ways: once the threshold >> level has been reached, an event shall be generated whenever >> the number of available blocks goes up again re-activating >> the threshold. >> >> The interface has been exposed through a vfs. Once mounted, >> it serves as an entry point for the set-up where one can >> register for particular file system events. > > Having a framework for notification for file systems is a great idea. > Your solution covers an important part of the possible application scope. > > Before moving forward I suggest we should analyze if this scope should > be enlarged. > > Many filesystems are remote (e.g. CIFS/Samba) or distributed over many > network nodes (e.g. Lustre). How should file system notification work here? > > How will fuse file systems be served? > > The current point of reference is a single mount point. > Every time I insert an USB stick several file system may be automounted. > I would like to receive events for these automounted file systems. > > A similar case arises when starting new virtual machines. How will I > receive events on the host system for the file systems of the virtual > machines? > In your implementation events are received via Netlink. > Using Netlink for marking mounts for notification would create a much > more homogenous interface. So why should we use a virtual file system here? > > Best regards > > Heinrich Schuchardt > > I'd be more than happy to extend the scope of suggested changes. I hope I'll be able to collect more comments - in this way there is a chance we might get here smth that is really useful, for everyone. I've tried to make the interface rather flexible, so that new cases can be easily added - so the notification whenever a file system is being mounted is definitely doable. The vfs here merely serves the purpose to configure which type of events and for which filesystems are to be issued. Having this done through netlink is also an option, though it needs some more thoughts. The way notifications are being sent might be extended: so there could be more than one option for this. We might also want to consider if we want to have this widely available - everything for everyone. (?) As for the rest, I must admit I'm not really an fs person, so I assume there will be more comments and questions like yours. This is also why any comments/hints/remarks/doubts/issues etc would me more than just welcomed. I'll try to answer them all, though this will require some time on my side, thus apologies if I have some delays. I'll get beck to this asap. BR Beata -- 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: [dm-devel] [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
On 04/17/2015 09:52 AM, Mike Snitzer wrote: On Thu, Apr 16 2015 at 5:23am -0400, Alex Elsayed wrote: Mike Snitzer wrote: On Thu, Apr 09 2015 at 9:28am -0400, Pali Rohár wrote: On Thursday 09 April 2015 09:12:08 Mike Snitzer wrote: On Mon, Apr 06 2015 at 9:29am -0400, Pali Rohár wrote: On Monday 06 April 2015 15:00:46 Mike Snitzer wrote: On Sun, Apr 05 2015 at 1:20pm -0400, Pali Rohár wrote: This patch series increase security of suspend and hibernate actions. It allows user to safely wipe crypto keys before suspend and hibernate actions starts without race conditions on userspace process with heavy I/O. To automatically wipe cryto key for before hibernate action call: $ dmsetup message 0 key wipe_on_hibernation 1 To automatically wipe cryto key for before suspend action call: $ dmsetup message 0 key wipe_on_suspend 1 (Value 0 after wipe_* string reverts original behaviour - to not wipe key) Can you elaborate on the attack vector your changes are meant to protect against? The user already authorized access, why is it inherently dangerous to _not_ wipe the associated key across these events? Hi, yes, I will try to explain current problems with cryptsetup luksSuspend command and hibernation. First, sometimes it is needed to put machine into other hands. You can still watch other person what is doing with machine, but once if you let machine unlocked (e.g opened luks disk), she/he can access encrypted data. If you turn off machine, it could be safe, because luks disk devices are locked. But if you enter machine into suspend or hibernate state luks devices are still open. And my patches try to achieve similar security as when machine is off (= no crypto keys in RAM or on swap). When doing hibernate on unencrypted swap it is to prevent leaking crypto keys to hibernate image (which is stored in swap). When doing suspend action it is again to prevent leaking crypto keys. E.g when you suspend laptop and put it off (somebody can remove RAMs and do some cold boot attack). The most common situation is: You have mounted partition from dm-crypt device (e.g. /home/), some userspace processes access it (e.g opened firefox which still reads/writes to cache ~/.firefox/) and you want to drop crypto keys from kernel for some time. For that operation there is command cryptsetup luksSuspend, which suspend dm device and then tell kernel to wipe crypto keys. All I/O operations are then stopped and userspace processes which want to do some those I/O operations are stopped too (until you call cryptsetup luksResume and enter correct key). Now if you want to suspend/hiberate your machine (when some of dm devices are suspeneded and some processes are stopped due to pending I/O) it is not possible. Kernel freeze_processes function will fail because userspace processes are still stopped inside some I/O syscall (read/write, etc,...). My patches fixes this problem and do those operations (suspend dm device, wipe crypto keys, enter suspend/hiberate) in correct order and without race condition. dm device is suspended *after* userspace processes are freezed and after that are crypto keys wiped. And then computer/laptop enters into suspend/hibernate state. Wouldn't it be better to fix freeze_processes() to be tolerant of processes that are hung as a side-effect of their backing storage being suspended? A hibernate shouldn't fail simply because a user chose to suspend a DM device. Then this entire problem goes away and the key can be wiped from userspace (like you said above). Still there will be race condition. Before hibernation (and device poweroff) we should have synced disks and filesystems to prevent data lose (or other damage) as more as we can. And if there will be some application which using lot of I/O (e.g normal firefox) then there always will be race condtion. The DM suspend will take care of flushing any pending I/O. So I don't see where the supposed race is... Anything else that is trapped in userspace memory will be there when the machine resumes. So proper way is to wipe luks crypto keys *after* userspace processes are freezed. I know you believe that I'm just not accepting that at face value. Um, pardon me if I'm being naive, but what about the case of hibernation where the swapdev and the root device are both LVs on the same dm_crypt device? The kernel is writing to swap _after_ userspace processes are all frozen; that seems to me like an ordering dependency entirely incompatible with userspace dropping the key... Good point, definitely not compatible with the Pali's approach. Ouch! I'm afraid this effectively killed one of my experiments with dm-crypt suspend. Good to get reminded sooner than later! (but is swap really configured ontop of the same dm-crypt device like this in practice? I've not heard of that being a common pattern but I could just be sheltered) yes. It's one among many perfectly valid setups. (For some the goal here would be to have wh
Re: [PATCH V2 1/6] perf,core: allow invalid context events to be part of sw/hw groups
On Thu, Apr 16, 2015 at 10:23:42PM +0100, Andi Kleen wrote: > > From my PoV that makes sense. One is CPU-affine, the other is not, and > > the two cannot be scheduled in the same PMU transaction by the nature of > > the hardware. Fundamentally, you cannot provide group semantics due to > > this. > > Actually you can. Just use it like a free running counter, and the > different groups sample it. This will work from the different CPUs, > as long as the event is the same everywhere. ... which would give you arbitrary skew, because one counter is free-running and the other is not (when scheduling a context in or out we stop the PMU) >From my PoV that violates group semantics, because now the events aren't always counting at the same time (which would be the reason I grouped them in the first place). > The implemention may not be quite right yet, but the basic concept > should work, and is useful. I can see that associating counts from different PMUs at points in time may be useful, even if they aren't sampled at the precise same time, and you have weaker guarantees than the current group semantics. However, it is the case that you cannot offer group semantics. Mark. -- 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 kernel v8 12/31] powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group
On 04/16/2015 03:55 PM, David Gibson wrote:
On Fri, Apr 10, 2015 at 04:30:54PM +1000, Alexey Kardashevskiy wrote:
Modern IBM POWERPC systems support multiple (currently two) TCE tables
per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
for TCE tables. Right now just one table is supported.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h| 18 +++--
arch/powerpc/kernel/iommu.c | 34
arch/powerpc/platforms/powernv/pci-ioda.c | 38 +
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 17 ++--
arch/powerpc/platforms/powernv/pci.c| 2 +-
arch/powerpc/platforms/powernv/pci.h| 4 +-
arch/powerpc/platforms/pseries/iommu.c | 9 ++-
drivers/vfio/vfio_iommu_spapr_tce.c | 120
8 files changed, 160 insertions(+), 82 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index eb75726..667aa1a 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -90,9 +90,7 @@ struct iommu_table {
struct iommu_pool pools[IOMMU_NR_POOLS];
unsigned long *it_map; /* A simple allocation bitmap for now */
unsigned long it_page_shift;/* table iommu page size */
-#ifdef CONFIG_IOMMU_API
- struct iommu_group *it_group;
-#endif
+ struct iommu_table_group *it_group;
struct iommu_table_ops *it_ops;
void (*set_bypass)(struct iommu_table *tbl, bool enable);
};
@@ -126,14 +124,24 @@ extern void iommu_free_table(struct iommu_table *tbl,
const char *node_name);
*/
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
+
+#define IOMMU_TABLE_GROUP_MAX_TABLES 1
+
+struct iommu_table_group {
#ifdef CONFIG_IOMMU_API
-extern void iommu_register_group(struct iommu_table *tbl,
+ struct iommu_group *group;
+#endif
+ struct iommu_table tables[IOMMU_TABLE_GROUP_MAX_TABLES];
There's nothing to indicate which of the tables are in use at the
current time. I mean, it doesn't matter now because there's only one,
but the patch doesn't make a whole lot of sense without that.
Later in the patchset, the code will look at @it_size to know if the table
is in use.
+};
+
+#ifdef CONFIG_IOMMU_API
+extern void iommu_register_group(struct iommu_table_group *table_group,
int pci_domain_number, unsigned long pe_num);
extern int iommu_add_device(struct device *dev);
extern void iommu_del_device(struct device *dev);
extern int __init tce_iommu_bus_notifier_init(void);
#else
-static inline void iommu_register_group(struct iommu_table *tbl,
+static inline void iommu_register_group(struct iommu_table_group *table_group,
int pci_domain_number,
unsigned long pe_num)
{
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index b39d00a..fd49c8e 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -712,17 +712,20 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
struct iommu_table *iommu_table_alloc(int node)
{
- struct iommu_table *tbl;
+ struct iommu_table_group *table_group;
- tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL, node);
+ table_group = kzalloc_node(sizeof(struct iommu_table_group), GFP_KERNEL,
+ node);
+ table_group->tables[0].it_group = table_group;
- return tbl;
+ return &table_group->tables[0];
}
void iommu_free_table(struct iommu_table *tbl, const char *node_name)
Surely the free function should take a table group rather than a table
as argument.
Please ignore my other response to your reply; I reworked the whole thing
to store iommu_table_group in the pci device node. Thanks.
--
Alexey
--
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/
