Re: [PATCH] i2c: i2c-cadence: Don't register the adapter until it's ready
On 06-01-17 22:34, Vladimir Zapolskiy wrote: Hello Mike, On 01/05/2017 12:47 PM, Mike Looijmans wrote: The driver calls i2c_add_adapter before writing to config registers, resulting in dmesg output like this, where devices fail to initialize: cdns-i2c ff03.i2c: timeout waiting on completion pca953x 1-0041: failed reading register pca953x: probe of 1-0041 failed with error -110 at24 1-0050: 512 byte 24c04 EEPROM, writable, 1 bytes/write cdns-i2c ff03.i2c: 100 kHz mmio ff03 irq 197 The adapter is being used before it completed the "probe". To fix this, make "i2c_add_adapter" the last thing it calls in probe. It also makes sense to show the adapter initialization before the devices on the bus. commonly "it also" in a commit message means a change, which should be done separately, and this is the case here as well. Because the adapter registration i2c_add_adapter() can fail, information about the adapter initialization would be expected only in case of successful registration. I would argue that the "info" message means "the I2C adapter is ready for transaction now, and we'll start initializing devices on the bus". That is the case before it calls i2c_add_adapter(). When i2c_add_adapter() runs, it will start probing devices on the bus. This yields very confusing output, as it will output things in a reversed order: - device X on I2C bus - device Y on I2C bus - cdns-i2c ff03.i2c: 100 kHz mmio ff03 irq 197 This is especially confusing if there are multiple I2C adapters with muxes behind them, the order then becomes like this: - Device X on bus 0 - Mux A on bus 0 registering bus 2, 3 and 4 - I2C controller for bus 0 - Device Y on bus 1 - I2C controller for bus 1 - Device Z on bus 2 - etc.. The information sent to the kernel log buffer here is quite trivial, probably dev_info() can be just removed, but in any case it should be a separate change. Fine with me too. Signed-off-by: Mike Looijmans -- With best wishes, Vladimir Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail
Re: sysfs deferred_probe attribute
On 01/12/2017 07:26 PM, Ben Hutchings wrote: > On Thu, 2017-01-12 at 18:41 +0100, Greg Kroah-Hartman wrote: >> On Thu, Jan 12, 2017 at 11:27:01AM -0600, Rob Herring wrote: >>> I just noticed that we have a new device attribute 'deferred_probe' >>> added in 4.10 with this commit: >>> >>> commit 6751667a29d6fd64afb9ce30567ad616b68ed789 >>> Author: Ben Hutchings >>> Date: Tue Aug 16 14:34:18 2016 +0100 >>> >>> driver core: Add deferred_probe attribute to devices in sysfs >>> >>> It is sometimes useful to know that a device is on the deferred probe >>> list rather than, say, not having a driver available. Expose this >>> information to user-space. >>> >>> Signed-off-by: Ben Hutchings >>> Signed-off-by: Greg Kroah-Hartman >>> >>> >>> It seems like a bad idea to add an ABI for an internal kernel feature. >>> When/if we replace deferred probe with something better based on >>> functional dependencies are we going to keep this attr around? Or >>> remove it and assume no userspace uses it? > > It should be removed then (and replaced with some kind of representation > of dependencies). > >>> Perhaps it should be hidden >>> behind CONFIG_DEBUG or just make a debugfs file that lists the >>> deferred list. Then you wouldn't have to hunt for what got deferred. >> >> Ah, debugfs would be nice, I'd much prefer that. I don't know how Ben >> is using this, but I think that would make more sense to me. > > I'm not using it any programmatic way, and don't intend to. debugfs > would be OK, but attaching it to devices was easy to do and seemed to > make sense. Russell King started work on printing those devices in the deferred queue at late_initcall, not sure why it didn't land. But note that without proper dependency information, you cannot know for sure if a device deferred its probe just because a dependency doesn't have a matching driver. Regards, Tomeu
[PATCH v3 1/3] Documentation: devicetree: move shared property used by rc into a common place
From: Sean Wang Most IR drivers uses the same label to identify the scancdoe/key table they used by multiple bindings and lack explanation well. So move the shared property into a common place and give better explanation. Signed-off-by: Sean Wang --- .../devicetree/bindings/media/gpio-ir-receiver.txt | 3 +- .../devicetree/bindings/media/hix5hd2-ir.txt | 2 +- Documentation/devicetree/bindings/media/rc.txt | 116 + .../devicetree/bindings/media/sunxi-ir.txt | 2 +- 4 files changed, 120 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/rc.txt diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt index 56e726e..58261fb 100644 --- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt @@ -5,7 +5,8 @@ Required properties: - gpios: specifies GPIO used for IR signal reception. Optional properties: - - linux,rc-map-name: Linux specific remote control map name. + - linux,rc-map-name: see rc.txt file in the same + directory. Example node: diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt index 54e1bed..13ebc0f 100644 --- a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt +++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt @@ -10,7 +10,7 @@ Required properties: - clocks: clock phandle and specifier pair. Optional properties: - - linux,rc-map-name : Remote control map name. + - linux,rc-map-name: see rc.txt file in the same directory. - hisilicon,power-syscon: DEPRECATED. Don't use this in new dts files. Provide correct clocks instead. diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt new file mode 100644 index 000..0d16d14 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rc.txt @@ -0,0 +1,116 @@ +The following properties are common to the infrared remote controllers: + +- linux,rc-map-name: string, specifies the scancode/key mapping table + defined in-kernel for the remote controller. Support values are: + * "rc-adstech-dvb-t-pci" + * "rc-alink-dtu-m" + * "rc-anysee" + * "rc-apac-viewcomp" + * "rc-asus-pc39" + * "rc-asus-ps3-100" + * "rc-ati-tv-wonder-hd-600" + * "rc-ati-x10" + * "rc-avermedia-a16d" + * "rc-avermedia-cardbus" + * "rc-avermedia-dvbt" + * "rc-avermedia-m135a" + * "rc-avermedia-m733a-rm-k6" + * "rc-avermedia-rm-ks" + * "rc-avermedia" + * "rc-avertv-303" + * "rc-azurewave-ad-tu700" + * "rc-behold-columbus" + * "rc-behold" + * "rc-budget-ci-old" + * "rc-cec" + * "rc-cinergy-1400" + * "rc-cinergy" + * "rc-delock-61959" + * "rc-dib0700-nec" + * "rc-dib0700-rc5" + * "rc-digitalnow-tinytwin" + * "rc-digittrade" + * "rc-dm1105-nec" + * "rc-dntv-live-dvbt-pro" + * "rc-dntv-live-dvb-t" + * "rc-dtt200u" + * "rc-dvbsky" + * "rc-empty" + * "rc-em-terratec" + * "rc-encore-enltv2" + * "rc-encore-enltv-fm53" + * "rc-encore-enltv" + * "rc-evga-indtube" + * "rc-eztv" + * "rc-flydvb" + * "rc-flyvideo" + * "rc-fusionhdtv-mce" + * "rc-gadmei-rm008z" + * "rc-genius-tvgo-a11mce" + * "rc-gotview7135" + * "rc-hauppauge" + * "rc-imon-mce" + * "rc-imon-pad" + * "rc-iodata-bctv7e" + * "rc-it913x-v1" + * "rc-it913x-v2" + * "rc-kaiomy" + * "rc-kworld-315u" + * "rc-kworld-pc150u" + * "rc-kworld-plus-tv-analog" + * "rc-leadtek-y04g0051" + * "rc-lirc" + * "rc-lme2510" + * "rc-manli" + * "rc-medion-x10" + * "rc-medion-x10-digitainer" + * "rc-medion-x10-or2x" + * "rc-msi-digivox-ii" + * "rc-msi-digivox-iii" + * "rc-msi-tvanywhere-plus" + * "rc-msi-tvanywhere" + * "rc-nebula" + * "rc-nec-terratec-cinergy-xs" + * "rc-norwood" + * "rc-npgtech" + * "rc-pctv-sedna" + * "rc-pinnacle-color" + * "rc-pinnacle-grey" + * "rc-pinnacle-pctv-hd" + * "rc-pixelview-new" + * "rc-pixelview" + * "rc-pixelview-002t" + * "rc-pixelview-mk12" + * "rc-powercolor-real-angel" + * "rc-proteus-2309" + * "rc-purpletv" + * "rc-pv951" + * "rc-hauppauge" + * "rc-rc5-tv" + * "rc-rc6-mce" + * "rc-real-audio-220-32-keys" + * "rc-reddo" + * "rc-snapstream-firefly" + * "rc-streamzap" + * "rc-tbs-nec" + * "rc-technisat-ts35" + * "rc-technisat-usb2" + * "rc-terratec-cinergy-c-pci" + * "rc-terratec-cinergy-s2-hd" + * "rc-terratec-cinergy-xs" + * "rc-terratec-slim" + * "rc-terratec-slim-2" + * "rc-tevii-nec" + * "rc-tivo" + * "rc-total-media-in-hand" + * "rc-total-media-in-hand-02" + * "rc-trekstor" + * "rc-tt-1500" + * "rc-twinhan-dtv-cab-ci" + * "rc-twinhan1027" + * "rc-videomate-k100" + * "rc-videomate-s350" + * "rc-videomate-tv-pvr" + * "rc-winfast" + * "rc-winfast-usbii-deluxe" + * "rc-su3000" diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Document
[PATCH v3 0/3] media: rc: add support for IR receiver on MT7623 SoC
From: Sean Wang This patchset introduces consumer IR (CIR) support on MT7623 SoC that also works on other similar SoCs and implements raw mode for more compatibility with different protocols. The driver simply reports the duration of pulses and spaces to rc-core logic to decode. Changes since v1: - change compatible string from "mediatek,mt7623-ir" into "mediatek,mt7623-cir" - use KBUILD_MODNAME to provide consistent device name used in driver. - remove unused fields in struct mtk_ir. - use synchronize_irq to give protection between IRQ handler and remove handler. - use devm_rc_allocate_device based on Andi Shyti's work. - simplify error handling patch with devm_rc_register_device and devm_rc_allocate_device. - remove unused spinlock. - add comments about hardware limitation and related workarounds. - enhance the caculation of sampling period for easiler assigned specific value. - refine git description. - fix IR message handling between IR hardware and rc-core. Changes since v2: - remove extra rc_unregister_device to avoid double frees issue since rc_unregister_device was used. - enhance comments description - remove redundant mtk irq disable/enable pair inside the IRQ handler - move keymap table property document into a common place Sean Wang (3): Documentation: devicetree: move shared property used by rc into a common place Documentation: devicetree: Add document bindings for mtk-cir media: rc: add driver for IR remote receiver on MT7623 SoC .../devicetree/bindings/media/gpio-ir-receiver.txt | 3 +- .../devicetree/bindings/media/hix5hd2-ir.txt | 2 +- .../devicetree/bindings/media/mtk-cir.txt | 23 ++ Documentation/devicetree/bindings/media/rc.txt | 116 .../devicetree/bindings/media/sunxi-ir.txt | 2 +- drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile | 1 + drivers/media/rc/mtk-cir.c | 330 + 8 files changed, 485 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt create mode 100644 Documentation/devicetree/bindings/media/rc.txt create mode 100644 drivers/media/rc/mtk-cir.c -- 1.9.1
Re: + mm-vmscan-add-mm_vmscan_inactive_list_is_low-tracepoint.patch added to -mm tree
On Fri 13-01-17 10:37:24, Minchan Kim wrote: > Hello, > > On Thu, Jan 12, 2017 at 10:10:17AM +0100, Michal Hocko wrote: > > On Thu 12-01-17 17:48:13, Minchan Kim wrote: > > > On Thu, Jan 12, 2017 at 09:15:54AM +0100, Michal Hocko wrote: > > > > On Thu 12-01-17 14:12:47, Minchan Kim wrote: > > > > > Hello, > > > > > > > > > > On Wed, Jan 11, 2017 at 04:52:39PM +0100, Michal Hocko wrote: > > > > > > On Wed 11-01-17 08:52:50, Minchan Kim wrote: > > > > > > [...] > > > > > > > > @@ -2055,8 +2055,8 @@ static bool inactive_list_is_low(struct > > > > > > > > if (!file && !total_swap_pages) > > > > > > > > return false; > > > > > > > > > > > > > > > > - inactive = lruvec_lru_size(lruvec, file * LRU_FILE); > > > > > > > > - active = lruvec_lru_size(lruvec, file * LRU_FILE + > > > > > > > > LRU_ACTIVE); > > > > > > > > + total_inactive = inactive = lruvec_lru_size(lruvec, > > > > > > > > file * LRU_FILE); > > > > > > > > + total_active = active = lruvec_lru_size(lruvec, file * > > > > > > > > LRU_FILE + LRU_ACTIVE); > > > > > > > > > > > > > > > > > > > > > > the decision of deactivating is based on eligible zone's LRU size, > > > > > > > not whole zone so why should we need to get a trace of all > > > > > > > zones's LRU? > > > > > > > > > > > > Strictly speaking, the total_ counters are not necessary for making > > > > > > the > > > > > > decision. I found reporting those numbers useful regardless because > > > > > > this > > > > > > will give us also an information how large is the eligible portion > > > > > > of > > > > > > the LRU list. We do not have any other tracepoint which would report > > > > > > that. > > > > > > > > > > The patch doesn't say anything why it's useful. Could you tell why > > > > > it's > > > > > useful and inactive_list_is_low should be right place? > > > > > > > > > > Don't get me wrong, please. I don't want to bother you. > > > > > I really don't want to add random stuff although it's tracepoint for > > > > > debugging. > > > > > > > > This doesn't sounds random to me. We simply do not have a full picture > > > > on 32b systems without this information. Especially when memcgs are > > > > involved and global numbers spread over different LRUs. > > > > > > Could you elaborate it? > > > > The problem with 32b systems is that you only can consider a part of the > > LRU for the lowmem requests. While we have global counters to see how > > much lowmem inactive/active pages we have, those get distributed to > > memcg LRUs. And that distribution is impossible to guess. So my thinking > > is that it can become a real head scratcher to realize why certain > > active LRUs are aged while others are not. This was the case when I was > > debugging the last issue which triggered all this. All of the sudden I > > have seen many invocations when inactive and active were zero which > > sounded weird, until I realized that those are memcg's lruvec which is > > what total numbers told me... > > Hmm, it seems I miss something. AFAIU, what you need is just memcg > identifier, not all lru size. If it isn't, please tell more detail > usecase of all lru size in that particular tracepoint. Having memcg id would be definitely helpful but that alone wouldn't tell us how is the lowmem distributed. To be honest I really fail to see why this bothers you all that much. [...] > > > > I am not sure I am following. Why is the additional parameter a problem? > > > > > > Well, to me, it's not a elegance. Is it? If we need such boolean variable > > > to control show the trace, it means it's not a good place or think > > > refactoring. > > > > But, even when you refactor the code there will be other callers of > > inactive_list_is_low outside of shrink_active_list... > > Yes, that's why I said "it's okay if you love your version". However, > we can do refactoring to remove "bool trace" and even, it makes code > more readable, I believe. > > >From 06eb7201d781155a8dee7e72fbb8423ec8175223 Mon Sep 17 00:00:00 2001 > From: Minchan Kim > Date: Fri, 13 Jan 2017 10:13:36 +0900 > Subject: [PATCH] mm: refactoring inactive_list_is_low > > Recently, Michal Hocko added tracepoint into inactive_list_is_low > for catching why VM decided to age the active list to know > active/inacive balancing problem. With that, unfortunately, it > added "bool trace" to inactlive_list_is_low to control some place > should be prohibited tracing. It is not elegant to me so this patch > try to clean it up. > > Normally, most inactive_list_is_low is used for deciding active list > demotion but one site(i.e., get_scan_count) uses for other purpose > which reclaim file LRU forcefully. Sites for deactivation calls it > with shrink_active_list. It means inactive_list_is_low could be > located in shrink_active_list. > > One more thing this patch does is to remove "ratio" in the tracepoint > because we can get it by post processing in script via simple math. > > Signed-off-by: Mincha
[PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Sean Wang
This patch adds documentation for devicetree bindings for
consumer Mediatek IR controller.
Signed-off-by: Sean Wang
---
.../devicetree/bindings/media/mtk-cir.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt
b/Documentation/devicetree/bindings/media/mtk-cir.txt
new file mode 100644
index 000..2be2005
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
@@ -0,0 +1,24 @@
+Device-Tree bindings for Mediatek consumer IR controller
+found in Mediatek SoC family
+
+Required properties:
+- compatible : "mediatek,mt7623-cir"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "clk" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : see rc.txt file in the same directory.
+
+Example:
+
+cir: cir@10013000 {
+ compatible = "mediatek,mt7623-cir";
+ reg = <0 0x10013000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_IRRX>;
+ clock-names = "clk";
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
1.9.1
[PATCH v3 3/3] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Wang
This patch adds driver for IR controller on MT7623 SoC.
and should also work on similar Mediatek SoC. Currently
testing successfully on NEC and SONY remote controller
only but it should work on others (lirc, rc-5 and rc-6).
Signed-off-by: Sean Wang
Reviewed-by: Sean Young
---
drivers/media/rc/Kconfig | 11 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 329 +
3 files changed, 341 insertions(+)
create mode 100644 drivers/media/rc/mtk-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca..9228479 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -235,6 +235,17 @@ config IR_MESON
To compile this driver as a module, choose M here: the
module will be called meson-ir.
+config IR_MTK
+ tristate "Mediatek IR remote receiver"
+ depends on RC_CORE
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ ---help---
+ Say Y if you want to use the IR remote receiver available
+ on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-cir.
+
config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
depends on PNP
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee..a78570b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_RC_ST) += st_rc.o
obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
obj-$(CONFIG_IR_SERIAL) += serial_ir.o
+obj-$(CONFIG_IR_MTK) += mtk-cir.o
diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
new file mode 100644
index 000..fbe7fd9
--- /dev/null
+++ b/drivers/media/rc/mtk-cir.c
@@ -0,0 +1,329 @@
+/*
+ * Driver for Mediatek IR Receiver Controller
+ *
+ * Copyright (C) 2017 Sean Wang
+ *
+ * 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
+
+#define MTK_IR_DEV KBUILD_MODNAME
+
+/* Register to enable PWM and IR */
+#define MTK_CONFIG_HIGH_REG 0x0c
+/* Enable IR pulse width detection */
+#define MTK_PWM_EN BIT(13)
+/* Enable IR hardware function */
+#define MTK_IR_ENBIT(0)
+
+/* Register to setting sample period */
+#define MTK_CONFIG_LOW_REG0x10
+/* Field to set sample period */
+#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
+ MTK_IR_CLK_PERIOD)
+#define MTK_CHK_PERIOD(((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
+#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
+
+/* Register to clear state of state machine */
+#define MTK_IRCLR_REG 0x20
+/* Bit to restart IR receiving */
+#define MTK_IRCLRBIT(0)
+
+/* Register containing pulse width data */
+#define MTK_CHKDATA_REG(i)(0x88 + 4 * (i))
+#define MTK_WIDTH_MASK (GENMASK(7, 0))
+
+/* Register to enable IR interrupt */
+#define MTK_IRINT_EN_REG 0xcc
+/* Bit to enable interrupt */
+#define MTK_IRINT_EN BIT(0)
+
+/* Register to ack IR interrupt */
+#define MTK_IRINT_CLR_REG 0xd0
+/* Bit to clear interrupt status */
+#define MTK_IRINT_CLRBIT(0)
+
+/* Maximum count of samples */
+#define MTK_MAX_SAMPLES 0xff
+/* Indicate the end of IR message */
+#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
+/* Number of registers to record the pulse width */
+#define MTK_CHKDATA_SZ 17
+/* Source clock frequency */
+#define MTK_IR_BASE_CLK 27300
+/* Frequency after IR internal divider */
+#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
+/* Period for MTK_IR_CLK in ns*/
+#define MTK_IR_CLK_PERIODDIV_ROUND_CLOSEST(10ul, \
+ MTK_IR_CLK_FREQ)
+/* Sample period in ns */
+#define MTK_IR_SAMPLE(MTK_IR_CLK_PERIOD * 0xc00)
+
+/* struct mtk_ir - This is the main datasructure for holding the state
+ * of the driver
+ * @dev: The device pointer
+ * @rc:The rc instrance
+ * @irq: The IRQ that we are using
+ * @base: The mapped register i/o base
+ * @clk: The clock that we are using
+ */
+struct mtk_ir {
+ struct device *dev;
+ struct rc_dev *rc;
+ void __iome
Re: [PATCH 2/5] staging/lustre/mgc: Combine two seq_printf() calls into one call in lprocfs_mgc_rd_ir_state()
On Fri, Jan 13, 2017 at 01:58:37AM -0500, Oleg Drokin wrote: > > On Jan 1, 2017, at 11:35 AM, SF Markus Elfring wrote: Oleg, please realize that I have blacklisted this patch author, and don't take contributions from them, unless you, or someone else wishes to properly review and pass them on. I've found that personally, it's just a waste of time working with them, but you are free to do whatever you wish... good luck! greg k-h
[PATCH] checkpatch: update $logFunctions
From: Miles Chen
Currently checkpatch.pl does not recognize printk_deferred* functions as
log functions and complains about the line length of printk_deferred*
functoins. Add printk_deferred* to logFunctions to fix it.
Signed-off-by: Miles Chen
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 982c52c..2b63f12 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -425,7 +425,7 @@ our $zero_initializer =
qr{(?:(?:0[xX])?0+$Int_type?|NULL|false)\b};
our $logFunctions = qr{(?x:
printk(?:_ratelimited|_once|)|
-
(?:[a-z0-9]+_){1,2}(?:printk|emerg|alert|crit|err|warning|warn|notice|info|debug|dbg|vdbg|devel|cont|WARN)(?:_ratelimited|_once|)|
+
(?:[a-z0-9]+_){1,2}(?:printk|emerg|alert|crit|err|warning|warn|notice|info|debug|dbg|vdbg|devel|cont|WARN|deferred)(?:_ratelimited|_once|)|
WARN(?:_RATELIMIT|_ONCE|)|
panic|
MODULE_[A-Z_]+|
--
1.9.1
Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn
at 04:00 on Fri 13-Jan-2017 Al Viro (v...@zeniv.linux.org.uk) wrote: > That, and check if it is reproducible on commit 523ac9afc73a with > commit 8e54cadab447 cherry-picked on top of that. $ git checkout 523ac9afc73a $ git cherry-pick 8e54cadab447 [detached HEAD 3826f27f6830] fix default_file_splice_read() Author: Al Viro Date: Sat Nov 26 20:05:42 2016 -0500 1 file changed, 2 insertions(+), 1 deletion(-) $ uname -a Linux frodo 4.8.0-rc8-00011-g3826f27f6830 #1 SMP PREEMPT Fri Jan 13 07:30:06 GMT 2017 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux # ps axfu | grep -A10 cron root 982 0.0 0.0 18764 1948 ?Ss 07:32 0:00 /usr/sbin/cron root 1593 0.0 0.0 27340 2164 ?S07:35 0:00 \_ /usr/sbin/cron root 1594 0.0 0.0 9840 2572 ?Ss 07:35 0:00 \_ /bin/bash -c date; /work/chroot-shared/test.sh; date root 1597 0.0 0.0 9840 2668 ?S07:35 0:00 | \_ /bin/bash /work/chroot-shared/test.sh root 1596 0.0 0.0 76156 5496 ?S07:35 0:00 \_ /usr/sbin/sendmail -FCronDaemon -odi -oem -oi -t root 1600 0.0 0.0 76140 5440 ?S07:35 0:00 \_ /usr/sbin/postdrop -r Still hangs -- Alan J. Wylie http://www.wylie.me.uk/ Dance like no-one's watching. / Encrypt like everyone is. Security is inversely proportional to convenience
[PATCH v1 1/2] Documentation: mtk-quadspi: update DT bindings
Add "mediatek,mt2701-nor" for nor flash node's compatible. Signed-off-by: Guochun Mao --- .../devicetree/bindings/mtd/mtk-quadspi.txt|4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt index fb314f0..f83d31d 100644 --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt @@ -1,7 +1,9 @@ * Serial NOR flash controller for MTK MT81xx (and similar) Required properties: -- compatible:should be "mediatek,mt8173-nor"; +- compatible:should contain: + "mediatek,mt2701-nor" for MT2701, + "mediatek,mt8173-nor" for MT8173. - reg: physical base address and length of the controller's register - clocks:the phandle of the clocks needed by the nor controller - clock-names: the names of the clocks -- 1.7.9.5
[PATCH v1 0/2] add nor flash node for mt2701
This patch series based on v4.10-rc2, include MT2701 spinor node and bindings. Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1]. [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html Guochun Mao (2): Documentation: mtk-quadspi: update DT bindings arm: dts: mt2701: add nor flash node .../devicetree/bindings/mtd/mtk-quadspi.txt| 4 +++- arch/arm/boot/dts/mt2701-evb.dts | 25 ++ arch/arm/boot/dts/mt2701.dtsi | 12 +++ 3 files changed, 40 insertions(+), 1 deletion(-) -- 1.8.1.1.dirty
Re: [RFC 2/6] perf/core: add a rb-tree index to inactive_groups
On Thu, Jan 12, 2017 at 3:47 AM, Mark Rutland wrote:
> On Tue, Jan 10, 2017 at 12:20:00PM -0800, David Carrillo-Cisneros wrote:
>> On Tue, Jan 10, 2017 at 6:14 AM, Mark Rutland wrote:
>> > On Tue, Jan 10, 2017 at 02:24:58AM -0800, David Carrillo-Cisneros wrote:
>> > For example, on a big.LITTLE system, big and little CPU PMUs share the
>> > same context, but their events are mutually incompatible. On big CPUs we
>> > only want to consider the sub-tree of big events, and on little CPUs we
>> > only want to consider little events. Hence, we need to be abel to search
>> > by PMU.
>>
>> I see it now. So, if PMU were added to the rb-tree keys. How can the
>> generic code know what's the PMU of the current CPU?
>
> I'm not immediately sure.
>
> We might need to augment struct pmu or perf_event_context with
> information such that we can determine that. That's not something I'd
> considered in great detail, and I'm not sure if peter had something in
> mind.
On second thought, I think the pmu pointer or id can be retrieved from
the event since the tree key only needs to be calculated when an event
is to be inserted.
>
>> > For SW PMUs, pmu::add() should never fail, and regardless of the order
>> > of the list we should be able to pmu::add() all events. Given that, why
>> > does the manner in which rotation occurs matter for SW PMUs?
>> >
>> >> Another complicatino is that using ctx->time (or timestamp) implies that
>> >> groups added during the same context switch may not have unique key.
>> >> This increases the complexity of that finds all events in the rb-tree
>> >> that are within a time interval.
>> >
>> > Could you elaborate on this? I don't understand what the problem is
>> > here. If we need uniqueness where {pmu,cpu,runtime} are equal, can't we
>> > extend the comparison to {pmu,cpu,runtime,event pointer}? That way
>> > everything we need is already implicit in the event, and we don't need
>> > perf_event::rbtree_key nor do we need
>> > perf_event_context::nr_inactive_added.
>>
>> Yes, we could extend the comparison. But I am trying to keep the key a
>> u64 to speed up things.
>>
>> I found it easier to simply create a counter and use it as an equivalent to
>> (timestamp, unique id). Both ways induce the same order of events.
>
> As I mentioned before, I believe that Peter's intent was to consider
> runtime, rather than a last-scheduled timestamp, so I don't think the
> counter is equivalent. It might be that either way is fine; I'll leave
> it to Peter to weigh in.
Also, if there is no real need for an timestamp and or runtime, and it's enough
to keep insertion order (so rotation occurs naturally). Then the rb-tree could
be simplified to only contain either {cpu,pmu,flexible} or {cgroup,flexible} in
its key and each node in the tree would be a sorted list of events.
In this series, the only search operations I do in the rb-tree are
"find first event
and "find last event" in each {cpu,pmu,flexible}/{cgroup,flexible} group. This
could be done faster with a list and we'd save the tree rebalancing.
>
> Do we have any benchmark figures either way?
I haven't measured anything yet.
>
> Thanks,
> Mark.
Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn
at 15:28 on Thu 12-Jan-2017 Linus Torvalds (torva...@linux-foundation.org)
wrote:
> So assuming Al hasn't figured it out by the time you get back, can
> you try to send us the same strace for the working case?
Full output at https://wylie.me.uk/tmp/strace1.txt
# uname -a
Linux frodo 4.8.17 #1 SMP PREEMPT Fri Jan 13 06:54:26 GMT 2017 x86_64 AMD
FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux
1738 close(2) = 0
1738 exit_group(0) = ?
1738 +++ exited with 0 +++
1735 <... epoll_wait resumed> [{EPOLLIN, {u32=1570273664,
u64=94155843336576}}], 7, -1) = 1
1735 clock_gettime(CLOCK_BOOTTIME, {292, 912429255}) = 0
1735 read(13,
"\21\0\0\0\0\0\0\0\1\0\0\0\312\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 128)
= 128
1735 epoll_ctl(11, EPOLL_CTL_DEL, 1, NULL) = 0
1735 epoll_ctl(11, EPOLL_CTL_DEL, 5, NULL) = 0
1735 signalfd4(13, [INT TERM CHLD], 8, SFD_CLOEXEC|SFD_NONBLOCK) = 13
1735 fcntl(0, F_GETFL) = 0 (flags O_RDONLY)
1735 fcntl(1, F_GETFL) = 0x1 (flags O_WRONLY)
1735 kill(1738, SIGKILL) = 0
1735 waitid(P_PID, 1738, {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1738,
si_uid=0, si_status=0, si_utime=0, si_stime=0}, WEXITED, NULL) = 0
1735 close(6) = 0
1735 close(7) = 0
1735 close(8) = 0
1735 close(9) = 0
1735 close(18) = 0
1735 close(16) = 0
1735 close(14) = 0
1735 close(10) = 0
1735 copy_file_range(5, NULL, 1, NULL, 9223372036854775807, 0) = -1 EXDEV
(Invalid cross-device link)
1735 sendfile(1, 5, NULL, 9223372036854775807) = -1 EINVAL (Invalid argument)
1735 splice(5, NULL, 1, NULL, 9223372036854775807, 0) = -1 EAGAIN (Resource
temporarily unavailable)
1735 open("/run/systemd/nspawn/propagate/chroot.32",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC) = 6
1735 fstatfs(6, {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=1020314,
f_bfree=1015930, f_bavail=1015930, f_files=1020314, f_ffree=1019308, f_fsid={0,
0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NODEV}) = 0
1735 fstat(6, {st_mode=S_IFDIR|0600, st_size=40, ...}) = 0
1735 fcntl(6, F_GETFL) = 0x78800 (flags
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME)
1735 fcntl(6, F_SETFD, FD_CLOEXEC) = 0
1735 getdents(6, /* 2 entries */, 32768) = 48
1735 getdents(6, /* 0 entries */, 32768) = 0
1735 close(6) = 0
1735 rmdir("/run/systemd/nspawn/propagate/chroot.32") = 0
1735 unlink("/work/.#chroot.32.lck") = 0
1735 close(3) = 0
1735 unlink("/run/systemd/nspawn/locks/inode-65035:24641537") = 0
1735 close(4) = 0
1735 close(5) = 0
1735 exit_group(0) = ?
1735 +++ exited with 0 +++
>From within the systemd-nspawn (no KVM or similar virtualisation involved):
Fri Jan 13 07:08:01 GMT 2017
+ date
Fri Jan 13 07:08:01 GMT 2017
+ cat /proc/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=4039360k,nr_inodes=1009840,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup
+rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
/dev/mapper/vg0-root / ext4 rw,relatime,data=ordered 0 0
/dev/mapper/vg0-usr /usr ext4 rw,relatime,data=ordered 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs
rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
/dev/mapper/vg1-work /work ext4 rw,relatime,data=ordered 0 0
/dev/mapper/vg1-home /home ext4 rw,relatime,data=ordered 0 0
/dev/sda1 /boot ext4 rw,relatime,data=ordered 0 0
/dev/mapper/vg0-var /var ext4 rw,relatime,data=ordered 0 0
/dev/mapper/vg0-srv /srv ext4 rw,relatime,data=ordered 0 0
tmpfs /run/user/1000 tmpfs
rw,nosuid,nodev,relatime,size=816248k,mode=700,uid=1000,gid=100
Re: [PATCH v3 1/2] tpm: implement TPM 2.0 capability to get active PCR banks
On 01/12/2017 11:55 PM, Jarkko Sakkinen wrote:
On Thu, Jan 12, 2017 at 11:58:09AM -0500, Nayna Jain wrote:
This patch implements the TPM 2.0 capability TPM_CAP_PCRS to
retrieve the active PCR banks from the TPM. This is needed
to enable extending all active banks as recommended by TPM 2.0
TCG Specification.
Signed-off-by: Nayna Jain
---
drivers/char/tpm/tpm.h | 4 +++
drivers/char/tpm/tpm2-cmd.c | 59 +
2 files changed, 63 insertions(+)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 1ae9768..573 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -127,6 +127,7 @@ enum tpm2_permanent_handles {
};
enum tpm2_capabilities {
+ TPM2_CAP_PCRS = 5,
TPM2_CAP_TPM_PROPERTIES = 6,
};
@@ -187,6 +188,8 @@ struct tpm_chip {
const struct attribute_group *groups[3];
unsigned int groups_cnt;
+
+ u16 active_banks[7];
#ifdef CONFIG_ACPI
acpi_handle acpi_dev_handle;
char ppi_version[TPM_PPI_VERSION_LEN + 1];
@@ -545,4 +548,5 @@ int tpm2_auto_startup(struct tpm_chip *chip);
void tpm2_shutdown(struct tpm_chip *chip, u16 shutdown_type);
unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
int tpm2_probe(struct tpm_chip *chip);
+ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
#endif
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 6eda239..87388921 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -83,6 +83,12 @@ struct tpm2_get_tpm_pt_out {
__be32 value;
} __packed;
+struct tpm2_tpms_pcr_selection {
+ __be16 hash_alg;
+ u8 size_of_select;
+ u8 pcr_select[3];
+} __packed;
Please move this right before tpm2_get_pcr_allocation.
Drop 'tpms_'.
Sure, will do this. But didn't understand why. I think all structs are
defined in start of file..
Thanks & Regards,
- Nayna
+
struct tpm2_get_random_in {
__be16 size;
} __packed;
@@ -993,8 +999,61 @@ int tpm2_auto_startup(struct tpm_chip *chip)
}
}
+ rc = tpm2_get_pcr_allocation(chip);
+
Please have this call in the commit where you actually use it
Does not make any sense here
out:
if (rc > 0)
rc = -ENODEV;
return rc;
}
+
+/**
+ * tpm2_get_pcr_allocation() - get TPM active PCR banks.
+ *
+ * @chip: TPM chip to use.
+ *
+ * Return: Same as with tpm_transmit_cmd.
+ */
+ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
+{
+ struct tpm2_tpms_pcr_selection pcr_selection;
+ struct tpm_buf buf;
+ void *marker;
+ unsigned int count = 0;
+ int rc;
+ int i;
+
+ rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_CAPABILITY);
+ if (rc)
+ return rc;
+
+ tpm_buf_append_u32(&buf, TPM2_CAP_PCRS);
+ tpm_buf_append_u32(&buf, 0);
+ tpm_buf_append_u32(&buf, 1);
+
+ rc = tpm_transmit_cmd(chip, buf.data, PAGE_SIZE, 0,
+ "get tpm pcr allocation");
+ if (rc < 0)
+ goto out;
+
+ count = be32_to_cpup(
+ (__be32 *) &buf.data[TPM_HEADER_SIZE + 5]);
Please do not add a space after cast. This has been an issue in your
previous patches too so try to do it right next time.
+
+ if (count > ARRAY_SIZE(chip->active_banks))
+ return -ENODEV;
+
+ marker = &buf.data[TPM_HEADER_SIZE + 9];
+ for (i = 0; i < count; i++) {
+ memcpy(&pcr_selection, marker, sizeof(pcr_selection));
+ chip->active_banks[i] = be16_to_cpu(pcr_selection.hash_alg);
+ marker = marker + sizeof(struct tpm2_tpms_pcr_selection);
+ }
+
+out:
+ if (count < ARRAY_SIZE(chip->active_banks))
+ chip->active_banks[count] = 0;
+
+ tpm_buf_destroy(&buf);
+
+ return rc;
+}
--
2.5.0
/Jarkko
Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
Hello, On Thu, Jan 12, 2017 at 10:28:20PM +0100, M'boumba Cedric Madianga wrote: > Please see below a quote from datasheet that clearly described how to handle > For 2-byte reception: > ● Wait until ADDR = 1 (SCL stretched low until the ADDR flag is cleared) > ● Set ACK low, set POS high > ● Clear ADDR flag > ● Wait until BTF = 1 (Data 1 in DR, Data2 in shift register, SCL > stretched low until a data1 is read) > ● Set STOP high > ● Read data 1 and 2 The problem is that you only know that you have a 2 byte transfer after you read the first byte (and it's a 1). (But note that this is irrelevant for the patch as the driver doesn't claim to support this kind of transfer.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v4 1/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
On Fri, Jan 13, 2017 at 01:54:17AM +0300, Serge Semin wrote:
> On Wed, Jan 11, 2017 at 09:21:19AM +0100, Greg KH
> wrote:
> > > + /* Return failure if root directory doesn't exist */
> > > + if (!csr_dbgdir) {
> > > + dev_dbg(dev, "No Debugfs root directory");
> > > + return -EINVAL;
> > > + }
> >
> > If debugfs is not enabled, don't error out, just keep going, it should
> > never stop kernel code from running properly.
> >
> > Also, this test isn't really doing what you think it is doing...
> >
>
> I see, it must be replaced with IS_ERR_OR_NULL() test.
No! That's a pain, when the debugfs interface was created its goal was
to make it _easy_ to use, not hard. IS_ERR_OR_NULL() is hard, and
messy, don't do that.
> But I don't think,
> it would be good to get rid of dev_dbg() completely here. In case if
> debugging is enabled, user would understand why csr-node isn't created within
> DebugFS directory. I don't see the reasoning why one shouldn't know a source
> of possible problems.
> (See the next comment as continue of the discussion)
Why would a user care about debugfs?
> > > + /* Create Debugfs directory for CSR file */
> > > + snprintf(fname, CSRNAME_LEN, "%d-%04hx", cli->adapter->nr, cli->addr);
> > > + pdev->csr_dir = debugfs_create_dir(fname, csr_dbgdir);
> > > + if (IS_ERR_OR_NULL(pdev->csr_dir)) {
> > > + dev_err(dev, "Failed to create CSR node directory");
> > > + return -EINVAL;
> >
> > Again, don't do this, you really don't care if debugfs worked or not.
> >
>
> Actually the driver doesn't stop the kernel code from running, if it finds out
> any problem with DebugFS CSR-node creation. The function just logs the error
> and return error status. Take a look the place the method is called:
> 1489/* Create debugfs files */
> 1490(void)idt_create_dbgfs_files(pdev);
> The initialization code doesn't check the return value at all, so the driver
> will proceed with further code.
> Why did I make the function with return value? Because it's a good style to
> always return a status of function code execution if it may fail, but only
> caller will decide whether to check the return value or not.
There is only one type of error that a debugfs call can return, and that
is if debugfs is not enabled in the build. That's it, you don't need to
care about any of that.
> Regarding the error printing. In case if the code gets to this check, one can
> be sure the DebugFS works properly, so in case if the driver failed to create
> the corresponding sub-directory or node, it is really error to have any
> failure
> at this point, and a user should be notified. But still the driver won't stop
> functioning, since the caller doesn't check the return value.
>
> Hopefully you'll understand my point.
Please understand mine, debugfs is supposed to be easy to use, you are
not testing things properly here, and when you are, it doesn't matter.
Just call the functions, save the return results if you need to (for
dentries and the like), and move on. No error handling needed AT ALL!
Yes, it feels "odd" for kernel code, but remember, this is only for
debugging. Your code should not have any different codepaths for if the
debugging logic worked or not. It doesn't care at all. So please, make
it simple.
> > > + dev_dbg(dev, "Debugfs-files created");
> >
> > You do know about ftrace, right? Please remove all of these
> > "trace-like" debugging lines, they aren't needed for anyone.
> >
>
> Ok, I'll remove all these prints, even though I do find these prints being
> handy to have initialization process printed on debugging stage.
Then use ftrace, that is what it is there for, don't roll your own
driver-specific-functionality please.
thanks,
greg k-h
[PATCH v1 2/2] arm: dts: mt2701: add nor flash node
Add Mediatek nor flash node.
Signed-off-by: Guochun Mao
---
arch/arm/boot/dts/mt2701-evb.dts | 25 +
arch/arm/boot/dts/mt2701.dtsi| 12
2 files changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 082ca88..85e5ae8 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -24,6 +24,31 @@
};
};
+&nor_flash {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nor_pins_default>;
+ status = "okay";
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+};
+
+&pio {
+ nor_pins_default: nor {
+ pins1 {
+ pinmux = ,
+,
+,
+,
+,
+;
+ drive-strength = ;
+ bias-pull-up;
+ };
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..1eefce4 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,18 @@
status = "disabled";
};
+ nor_flash: spi@11014000 {
+ compatible = "mediatek,mt2701-nor",
+"mediatek,mt8173-nor";
+ reg = <0 0x11014000 0 0xe0>;
+ clocks = <&pericfg CLK_PERI_FLASH>,
+<&topckgen CLK_TOP_FLASH_SEL>;
+ clock-names = "spi", "sf";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mmsys: syscon@1400 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
--
1.7.9.5
Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
On 2017/1/13 13:29, Matt Ranostay wrote:
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren
Cc: Ulf Hansson
Signed-off-by: Matt Ranostay
---
drivers/mmc/core/Kconfig | 10
drivers/mmc/core/Makefile| 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++
3 files changed, 128 insertions(+)
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
I don't like this way, as we have a chance to list lots
configure options here. wifi A,B,C,D...Z, all of them need a
new section here if needed?
Instead, could you just extent pwrseq_simple.c and add you
.compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay
+ *
+ * Based on the original work pwrseq_simple.c
+ * Copyright (C) 2014 Linaro Ltd
+ * Author: Ulf Hansson
+ *
+ * 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 "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+ struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+ msleep(300);
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+ .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+ .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+ { .compatible = "mmc-pwrseq-sd8787",},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq;
+ struct device *dev = &pdev->dev;
+
+ pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+ if (!pwrseq)
+ return -ENOMEM;
+
+ pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->pwrdn_gpio))
+ return PTR_ERR(pwrseq->pwrdn_gpio);
+
+ pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->reset_gpio))
+ return PTR_ERR(pwr
Re: [PATCH v2 18/18] insert build break
On Thu, Jan 12, 2017 at 04:37:35PM -0600, christopher.lee.bos...@gmail.com wrote: > From: Chris Bostic > > Signed-off-by: Chris Bostic I can not accept patches that have no changelog text, and this one is very odd: > --- > drivers/fsi/fsi-core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c > index 28b82d1..db09836 100644 > --- a/drivers/fsi/fsi-core.c > +++ b/drivers/fsi/fsi-core.c > @@ -42,6 +42,7 @@ > > static DEFINE_IDA(master_ida); > > + Huh? Did something go wrong with your scripts? greg k-h
Re: [PATCH] mm: extend zero pages to same element pages for zram
On (01/13/17 15:47), Minchan Kim wrote: [..] > > > Could you elaborate a bit? Do you mean this? > > > > > > ret = scnprintf(buf, PAGE_SIZE, > > > "%8llu %8llu %8llu %8lu %8ld %8llu %8lu\n", > > > orig_size << PAGE_SHIFT, > > > (u64)atomic64_read(&zram->stats.compr_data_size), > > > mem_used << PAGE_SHIFT, > > > zram->limit_pages << PAGE_SHIFT, > > > max_used << PAGE_SHIFT, > > > // (u64)atomic64_read(&zram->stats.zero_pages), > > > (u64)atomic64_read(&zram->stats.same_pages), > > > pool_stats.pages_compacted); > > > > yes, correct. > > > > do we need to export it as two different stats (zero_pages and > > same_pages), if those are basically same thing internally? > > So, let summary up. > > 1. replace zero_page stat into same page stat in mm_stat > 2. s/zero_pages/same_pages/Documentation/blockdev/zram.txt > 3. No need to warn to "cat /sys/block/zram0/mm_stat" user to see zero_pages >about semantic change 1) account zero_page and same_pages in one attr. this already is in the patch. 2) do not rename zero_pages attr. we can't do this so fast, I think. > 3. No need to warn to "cat /sys/block/zram0/mm_stat" user to see zero_pages >about semantic change yes. we just _may_ have more pages (depending on data pattern) which we treat as "zero" pages internally. this results in lower memory consumption. I don't think warn users about this change is necessary; they won't be able to do anything about it anyway. zero_pages stat is pretty much just a fun number to know. isn't it? or do you think that we should account it in separate stats? -ss
Re: [PATCH 4/5] staging/lustre/obdclass: Combine two seq_printf() calls into one call in lprocfs_rd_state()
On Jan 1, 2017, at 11:38 AM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 1 Jan 2017 16:26:36 +0100
>
> Some data were printed into a sequence by two separate function calls.
> Print the same data by a single function call instead.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/staging/lustre/lustre/obdclass/lprocfs_status.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> index 3f6fcab5a1fc..a167cbe8a50e 100644
> --- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> +++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> @@ -853,10 +853,8 @@ int lprocfs_rd_state(struct seq_file *m, void *data)
> return rc;
>
> imp = obd->u.cli.cl_import;
> -
> - seq_printf(m, "current_state: %s\n",
> + seq_printf(m, "current_state: %s\nstate_history:\n",
> ptlrpc_import_state_name(imp->imp_state));
> - seq_printf(m, "state_history:\n");
same as in that other patch - this actually makes the code a bit harder to read,
what's the perceived benefit to make a change like this?
> k = imp->imp_state_hist_idx;
> for (j = 0; j < IMP_STATE_HIST_LEN; j++) {
> struct import_state_hist *ish =
> --
> 2.11.0
Re: [PATCH 2/5] staging/lustre/mgc: Combine two seq_printf() calls into one call in lprocfs_mgc_rd_ir_state()
On Jan 1, 2017, at 11:35 AM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 1 Jan 2017 15:40:29 +0100
>
> Some data were printed into a sequence by two separate function calls.
> Print the same data by a single function call instead.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/staging/lustre/lustre/mgc/mgc_request.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c
> b/drivers/staging/lustre/lustre/mgc/mgc_request.c
> index b9c522a3c7a4..a6ca48d7e96b 100644
> --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
> +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
> @@ -460,11 +460,8 @@ int lprocfs_mgc_rd_ir_state(struct seq_file *m, void
> *data)
>
> imp = obd->u.cli.cl_import;
> ocd = &imp->imp_connect_data;
> -
> - seq_printf(m, "imperative_recovery: %s\n",
> + seq_printf(m, "imperative_recovery: %s\nclient_state:\n",
> OCD_HAS_FLAG(ocd, IMP_RECOV) ? "ENABLED" : "DISABLED");
> - seq_printf(m, "client_state:\n");
> -
Ugh, do we really need this?
I know it saves one call to seq_printf, but this is not a super
performance-critical
code, and two calls are actually easier to read, don't you think?
> spin_lock(&config_list_lock);
> list_for_each_entry(cld, &config_llog_list, cld_list_chain) {
> if (!cld->cld_recover)
> --
> 2.11.0
Re: [v2 2/2] vfio iommu type1: fix the testing of capability for remote task
Looks good to me
Reviewed by: Kirti Wankhede
On 1/13/2017 3:52 AM, James Morris wrote:
> On Thu, 12 Jan 2017, Jike Song wrote:
>
>> Before the mdev enhancement type1 iommu used capable() to test the
>> capability of current task; in the course of mdev development a
>> new requirement, testing for another task other than current, was
>> raised. ns_capable() was used for this purpose, however it still
>> tests current, the only difference is, in a specified namespace.
>>
>> Fix it by using has_capability() instead, which tests the cap for
>> specified task in init_user_ns, the same namespace as capable().
>>
>> Cc: Alex Williamson
>> Cc: Kirti Wankhede
>> Cc: Gerd Hoffmann
>> Signed-off-by: Jike Song
>
>
> Reviewed-by: James Morris
>
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c
>> index 9266271..77373e5 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -495,8 +495,7 @@ static int vfio_pin_page_external(struct vfio_dma *dma,
>> unsigned long vaddr,
>>unsigned long *pfn_base, bool do_accounting)
>> {
>> unsigned long limit;
>> -bool lock_cap = ns_capable(task_active_pid_ns(dma->task)->user_ns,
>> - CAP_IPC_LOCK);
>> +bool lock_cap = has_capability(dma->task, CAP_IPC_LOCK);
>> struct mm_struct *mm;
>> int ret;
>> bool rsvd;
>>
>
RE: [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
Hi Vinod, Thanks for the review... [Snip] > > > Btw how and when does DMA stop, assuming it is circular it never > > > would, isn't there a valid/stop flag associated with a descriptor > > > which tells DMA engine what to do next > > > > There are two registers that controls the DMA transfers. > > Current descriptor and tail descriptor register. > > When current descriptor reaches tail descriptor dma engine will pause. > > > > When reprogramming the tail descriptor the DMA engine will starts fetching > descriptors again. > > > > But with the existing driver flow if we reprogram the tail descriptor > > The tail descriptor next descriptor field is pointing to an invalid > > location Causing data corruption... > > So the solution is..? This patch. I mean if we have a set of descriptors in chain (in circular manner last descriptor points to first descriptor) It always points to valid descriptors. Will update the patch commit description in the next version... > > > > Btw there is something wrong with your MUA perhaps line are > > > titlecased for no reason. This is typically behavious of non linux > > > tool which may not be great tool for this work. > > > > Thanks for pointing it out. > > I usually replies from outlook from a windows machine. > > Will check with others in my team how they configured their mail client. > > Yeah that isnt right tool for the job. See Documentation/process/email- > clients.rst > > FWIW, I use mutt, vim as editor with exchange servers, seems to work well for > me now. Thanks for pointing it out will go through it. Will install mutt in my Linux machine will start replying from that Regards, Kedar. > > -- > ~Vinod
Re: [PATCH] mm: extend zero pages to same element pages for zram
On Fri, Jan 13, 2017 at 03:36:14PM +0900, Sergey Senozhatsky wrote: > On (01/13/17 15:23), Minchan Kim wrote: > [..] > > > > Please add same_pages to tail of the stat > > > > > > sounds ok to me. and yes, can deprecate zero_pages. > > > > > > seems that with that patch the concept of ZRAM_ZERO disappears. both > > > ZERO and SAME_ELEMENT pages are considered to be the same thing now. > > > > Right. > > > > > which is fine and makes sense to me, I think. and if ->.same_pages will > > > replace ->.zero_pages in mm_stat() then I'm also OK. yes, we will see > > > increased number in the last column of mm_stat file, but I don't tend > > > to see any issues here. Minchan, what do you think? > > > > Could you elaborate a bit? Do you mean this? > > > > ret = scnprintf(buf, PAGE_SIZE, > > "%8llu %8llu %8llu %8lu %8ld %8llu %8lu\n", > > orig_size << PAGE_SHIFT, > > (u64)atomic64_read(&zram->stats.compr_data_size), > > mem_used << PAGE_SHIFT, > > zram->limit_pages << PAGE_SHIFT, > > max_used << PAGE_SHIFT, > > // (u64)atomic64_read(&zram->stats.zero_pages), > > (u64)atomic64_read(&zram->stats.same_pages), > > pool_stats.pages_compacted); > > yes, correct. > > do we need to export it as two different stats (zero_pages and > same_pages), if those are basically same thing internally? So, let summary up. 1. replace zero_page stat into same page stat in mm_stat 2. s/zero_pages/same_pages/Documentation/blockdev/zram.txt 3. No need to warn to "cat /sys/block/zram0/mm_stat" user to see zero_pages about semantic change ?
Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save
Greg Kroah-Hartman writes:
> On Tue, Jan 10, 2017 at 10:51:56PM +0100, Willy Tarreau wrote:
>> On Tue, Jan 10, 2017 at 03:23:27PM -0600, l...@pengaru.com wrote:
>> > On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote:
>> > > On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
>> > > > Hello, this patch causes a kernel panic with the rtl8192cu driver.
>> > >
>> > > Ick, not good! Does this cause a problem in Linus's tree as well?
>> > >
>> >
>> > http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00228.html
>>
>> OK the pending patch is here and not yet upstream :
>>
>> http://marc.info/?l=linux-wireless&m=148234081512703&w=2
>>
>> It fixes ba9f93f82aba (patch 3/116) so better postpone it until
>> the patch above gets merged.
>
> Yes, I've reverted this now and will wait for this fixup to hit Linus's
> tree. Larry, can you remind me to include the original patch in the
> stable tree when this fixup is merged?
Linus pulled it now:
commit 60f59ce0278557f7896d5158ae6d12a4855a72cc
Author: Larry Finger
Date: Wed Dec 21 11:18:55 2016 -0600
rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
These drivers need to be able to reference "struct ieee80211_hw"
from
the driver's private data, and vice versa. The USB driver failed to
store the address of ieee80211_hw in the private data. Although this
bug has been present for a long time, it was not exposed until
commit ba9f93f82aba ("rtlwifi: Fix enter/exit power_save").
Fixes: ba9f93f82aba ("rtlwifi: Fix enter/exit power_save")
Signed-off-by: Larry Finger
Signed-off-by: Kalle Valo
--
Kalle Valo
Re: [PATCH] mm: extend zero pages to same element pages for zram
Hi Sergey,
On Fri, Jan 13, 2017 at 01:24:44PM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> sorry, was mostly offline for the past few days, now catching up.
>
> On (01/10/17 08:41), Minchan Kim wrote:
> > > the idea is that without doing more calculations we extend zero pages
> > > to same element pages for zram. zero page is special case of
> > > same element page with zero element.
> > >
>
> interesting idea.
>
> [..]
> > > flush_dcache_page(page);
> > > @@ -431,7 +479,7 @@ static ssize_t mm_stat_show(struct device *dev,
> > > mem_used << PAGE_SHIFT,
> > > zram->limit_pages << PAGE_SHIFT,
> > > max_used << PAGE_SHIFT,
> > > - (u64)atomic64_read(&zram->stats.zero_pages),
> > > + (u64)atomic64_read(&zram->stats.same_pages),
> >
> > Unfortunately, we cannot replace zero pages stat with same pages's one right
> > now due to compatibility problem. Please add same_pages to tail of the stat
> > and we should warn deprecated zero_pages stat so we finally will remove it
> > two year later. Please reference Documentation/ABI/obsolete/sysfs-block-zram
> > And add zero-pages to the document.
> >
> > For example,
> >
> > ... mm_stat_show()
> > {
> > pr_warn_once("zero pages was deprecated so it will be removed at
> > 2019 Jan");
> > }
> >
> > Sergey, what's your opinion?
>
> oh, I was going to ask you whether you have any work in progress at
> the moment or not. because deprecated attrs are scheduled to be removed
> in 4.11. IOW, we must send the clean up patch, well, right now. so I can
> prepare the patch, but it can conflict with someone's 'more serious/relevant'
> work.
I think deprecating attrs is top priority to me so go ahead. :)
>
> we also have zram hot/addd sysfs attr, which must be deprecated and
> converted to a char device. per Greg KH.
>
> > Please add same_pages to tail of the stat
>
> sounds ok to me. and yes, can deprecate zero_pages.
>
> seems that with that patch the concept of ZRAM_ZERO disappears. both
> ZERO and SAME_ELEMENT pages are considered to be the same thing now.
Right.
> which is fine and makes sense to me, I think. and if ->.same_pages will
> replace ->.zero_pages in mm_stat() then I'm also OK. yes, we will see
> increased number in the last column of mm_stat file, but I don't tend
> to see any issues here. Minchan, what do you think?
Could you elaborate a bit? Do you mean this?
ret = scnprintf(buf, PAGE_SIZE,
"%8llu %8llu %8llu %8lu %8ld %8llu %8lu\n",
orig_size << PAGE_SHIFT,
(u64)atomic64_read(&zram->stats.compr_data_size),
mem_used << PAGE_SHIFT,
zram->limit_pages << PAGE_SHIFT,
max_used << PAGE_SHIFT,
// (u64)atomic64_read(&zram->stats.zero_pages),
(u64)atomic64_read(&zram->stats.same_pages),
pool_stats.pages_compacted);
[PATCH 3/4] selftest: cpufreq: Add support to test cpufreq modules
This patch adds support for cpufreq modules like cpufreq drivers and
cpufreq governors. The tests will insert the modules in different orders
and them perform basic cpufreq tests. The modules are then removed from
the kernel.
Signed-off-by: Viresh Kumar
---
tools/testing/selftests/cpufreq/Makefile | 2 +-
tools/testing/selftests/cpufreq/main.sh | 45 +-
tools/testing/selftests/cpufreq/module.sh | 243 ++
3 files changed, 284 insertions(+), 6 deletions(-)
create mode 100755 tools/testing/selftests/cpufreq/module.sh
diff --git a/tools/testing/selftests/cpufreq/Makefile
b/tools/testing/selftests/cpufreq/Makefile
index f5c6bb1965a1..80c8727dcec1 100644
--- a/tools/testing/selftests/cpufreq/Makefile
+++ b/tools/testing/selftests/cpufreq/Makefile
@@ -1,7 +1,7 @@
all:
TEST_PROGS := main.sh
-TEST_FILES := cpu.sh cpufreq.sh governor.sh
+TEST_FILES := cpu.sh cpufreq.sh governor.sh module.sh
include ../lib.mk
diff --git a/tools/testing/selftests/cpufreq/main.sh
b/tools/testing/selftests/cpufreq/main.sh
index 9ff662f67ea4..2515867ac9de 100755
--- a/tools/testing/selftests/cpufreq/main.sh
+++ b/tools/testing/selftests/cpufreq/main.sh
@@ -3,6 +3,7 @@
source cpu.sh
source cpufreq.sh
source governor.sh
+source module.sh
FUNC=basic # do basic tests by default
OUTFILE=cpufreq_selftest
@@ -12,12 +13,15 @@ CPUFREQROOT=
helpme()
{
- printf "Usage: $0 [-h] [-to args]
+ printf "Usage: $0 [-h] [-todg args]
[-h ]
[-o ]
[-t ]
+hibernate: hibernate/resume,
+modtest: test driver or governor modules. Only to be used with -d
or -g options>]
+ [-d \"]
+ [-g \"]
\n"
exit 2
}
@@ -56,14 +60,14 @@ prerequisite()
parse_arguments()
{
- while getopts ht:o: arg
+ while getopts ht:o:d:g: arg
do
case $arg in
h) # --help
helpme
;;
- t) # --func_type (Function to perform: basic, suspend,
hibernate (default: basic))
+ t) # --func_type (Function to perform: basic, suspend,
hibernate, modtest (default: basic))
FUNC=$OPTARG
;;
@@ -71,6 +75,14 @@ parse_arguments()
OUTFILE=$OPTARG
;;
+ d) # --driver-mod-name (Name of the driver module)
+ DRIVER_MOD=$OPTARG
+ ;;
+
+ g) # --governor-mod-name (Name of the governor module)
+ GOVERNOR_MOD=$OPTARG
+ ;;
+
\?)
helpme
;;
@@ -83,7 +95,7 @@ do_test()
# Check if CPUs are managed by cpufreq or not
count=$(count_cpufreq_managed_cpus)
- if [ $count = 0 ]; then
+ if [ $count = 0 -a $FUNC != "modtest" ]; then
echo "No cpu is managed by cpufreq core, exiting"
exit 2;
fi
@@ -101,6 +113,29 @@ do_test()
do_suspend "hibernate" 1
;;
+ "modtest")
+ # Do we have modules in place?
+ if [ -z $DRIVER_MOD ] && [ -z $GOVERNOR_MOD ]; then
+ echo "No driver or governor module passed with -d or -g"
+ exit 2;
+ fi
+
+ if [ $DRIVER_MOD ]; then
+ if [ $GOVERNOR_MOD ]; then
+ module_test $DRIVER_MOD $GOVERNOR_MOD
+ else
+ module_driver_test $DRIVER_MOD
+ fi
+ else
+ if [ $count = 0 ]; then
+ echo "No cpu is managed by cpufreq core,
exiting"
+ exit 2;
+ fi
+
+ module_governor_test $GOVERNOR_MOD
+ fi
+ ;;
+
*)
echo "Invalid [-f] function type"
helpme
diff --git a/tools/testing/selftests/cpufreq/module.sh
b/tools/testing/selftests/cpufreq/module.sh
new file mode 100755
index ..8ff2244a33a1
--- /dev/null
+++ b/tools/testing/selftests/cpufreq/module.sh
@@ -0,0 +1,243 @@
+#!/bin/bash
+#
+# Modules specific tests cases
+
+# protect against multiple inclusion
+if [ $FILE_MODULE ]; then
+ return 0
+else
+ FILE_MODULE=DONE
+fi
+
+source cpu.sh
+source cpufreq.sh
+source governor.sh
+
+# Check basic insmod/rmmod
+# $1: module
+test_basic_insmod_rmmod()
+{
+ printf "** Test: Running ${FUNCNAME[0]} **\n\n"
+
+ printf "Inserting $1 module\n"
+ # insert module
+ insmod $1
+ if [ $? != 0 ]; then
+ printf "Insmod $1 failed\n"
+
[PATCH 4/4] selftest: cpufreq: Add special tests
This patch adds support for special tests which were reported on the PM
list over the years, which helped catching core bugs by several
developers.
Signed-off-by: Viresh Kumar
---
tools/testing/selftests/cpufreq/Makefile | 2 +-
tools/testing/selftests/cpufreq/governor.sh | 7 ++
tools/testing/selftests/cpufreq/main.sh | 25 -
tools/testing/selftests/cpufreq/special-tests.sh | 115 +++
4 files changed, 146 insertions(+), 3 deletions(-)
create mode 100755 tools/testing/selftests/cpufreq/special-tests.sh
diff --git a/tools/testing/selftests/cpufreq/Makefile
b/tools/testing/selftests/cpufreq/Makefile
index 80c8727dcec1..3955cd96f3a2 100644
--- a/tools/testing/selftests/cpufreq/Makefile
+++ b/tools/testing/selftests/cpufreq/Makefile
@@ -1,7 +1,7 @@
all:
TEST_PROGS := main.sh
-TEST_FILES := cpu.sh cpufreq.sh governor.sh module.sh
+TEST_FILES := cpu.sh cpufreq.sh governor.sh module.sh special-tests.sh
include ../lib.mk
diff --git a/tools/testing/selftests/cpufreq/governor.sh
b/tools/testing/selftests/cpufreq/governor.sh
index 2e42432892ab..def645103555 100755
--- a/tools/testing/selftests/cpufreq/governor.sh
+++ b/tools/testing/selftests/cpufreq/governor.sh
@@ -71,6 +71,13 @@ __switch_governor()
echo $2 > $CPUFREQROOT/$1/scaling_governor
}
+# param:
+# $1: cpu, $2: governor
+__switch_governor_for_cpu()
+{
+ echo $2 > $CPUROOT/$1/cpufreq/scaling_governor
+}
+
# SWITCH GOVERNORS
# $1: cpu, $2: governor
diff --git a/tools/testing/selftests/cpufreq/main.sh
b/tools/testing/selftests/cpufreq/main.sh
index 2515867ac9de..01bac76ac0ec 100755
--- a/tools/testing/selftests/cpufreq/main.sh
+++ b/tools/testing/selftests/cpufreq/main.sh
@@ -4,6 +4,7 @@ source cpu.sh
source cpufreq.sh
source governor.sh
source module.sh
+source special-tests.sh
FUNC=basic # do basic tests by default
OUTFILE=cpufreq_selftest
@@ -19,7 +20,11 @@ helpme()
[-t ]
+modtest: test driver or governor modules. Only to be used with -d
or -g options,
+sptest1: Simple governor switch to produce lockdep.
+sptest2: Concurrent governor switch to produce lockdep.
+sptest3: Governor races, shuffle between governors quickly.
+sptest4: CPU hotplugs with updates to cpufreq files.>]
[-d \"]
[-g \"]
\n"
@@ -67,7 +72,7 @@ parse_arguments()
helpme
;;
- t) # --func_type (Function to perform: basic, suspend,
hibernate, modtest (default: basic))
+ t) # --func_type (Function to perform: basic, suspend,
hibernate, modtest, sptest1/2/3/4 (default: basic))
FUNC=$OPTARG
;;
@@ -136,6 +141,22 @@ do_test()
fi
;;
+ "sptest1")
+ simple_lockdep
+ ;;
+
+ "sptest2")
+ concurrent_lockdep
+ ;;
+
+ "sptest3")
+ governor_race
+ ;;
+
+ "sptest4")
+ hotplug_with_updates
+ ;;
+
*)
echo "Invalid [-f] function type"
helpme
diff --git a/tools/testing/selftests/cpufreq/special-tests.sh
b/tools/testing/selftests/cpufreq/special-tests.sh
new file mode 100755
index ..58b730f23ef7
--- /dev/null
+++ b/tools/testing/selftests/cpufreq/special-tests.sh
@@ -0,0 +1,115 @@
+#!/bin/bash
+#
+# Special test cases reported by people
+
+# Testcase 1: Reported here: http://marc.info/?l=linux-pm&m=140618592709858&w=2
+
+# protect against multiple inclusion
+if [ $FILE_SPECIAL ]; then
+ return 0
+else
+ FILE_SPECIAL=DONE
+fi
+
+source cpu.sh
+source cpufreq.sh
+source governor.sh
+
+# Test 1
+# $1: policy
+__simple_lockdep()
+{
+ # switch to ondemand
+ __switch_governor $1 "ondemand"
+
+ # cat ondemand files
+ local ondir=$(find_gov_directory $1 "ondemand")
+ if [ -z $ondir ]; then
+ printf "${FUNCNAME[0]}Ondemand directory not created, quit"
+ return
+ fi
+
+ cat $ondir/*
+
+ # switch to conservative
+ __switch_governor $1 "conservative"
+}
+
+simple_lockdep()
+{
+ printf "** Test: Running ${FUNCNAME[0]} **\n"
+
+ for_each_policy __simple_lockdep
+}
+
+# Test 2
+# $1: policy
+__concurrent_lockdep()
+{
+ for i in `seq 0 100`; do
+ __simple_lockdep $1
+ done
+}
+
+concurrent_lockdep()
+{
+ printf "** Test: Running ${FUNCNAME[0]} **\n"
+
+ for_each_policy_concurrent __concurrent_lockdep
+}
+
+# Test 3
+quick_shuffle()
+{
+ # this is called concurrently from governor_race
+ for I in `seq 1000`
+ do
+ echo ondemand | sudo tee $CPUFREQROOT/policy*/scaling_governor &
+ echo userspace | sudo tee $CPUFREQROOT/poli
[PATCH 2/4] selftest: cpufreq: Add suspend/resume/hibernate support
This patch adds support to test basic suspend/resume and hibernation to
the cpufreq selftests.
Signed-off-by: Viresh Kumar
---
tools/testing/selftests/cpufreq/cpufreq.sh | 40 ++
tools/testing/selftests/cpufreq/main.sh| 14 +--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/cpufreq/cpufreq.sh
b/tools/testing/selftests/cpufreq/cpufreq.sh
index 2b8b05aaa874..1ed3832030b4 100755
--- a/tools/testing/selftests/cpufreq/cpufreq.sh
+++ b/tools/testing/selftests/cpufreq/cpufreq.sh
@@ -199,3 +199,43 @@ cpufreq_basic_tests()
# Test all governors
shuffle_governors_for_all_cpus 1
}
+
+# Suspend/resume
+# $1: "suspend" or "hibernate", $2: loop count
+do_suspend()
+{
+ printf "** Test: Running ${FUNCNAME[0]}: Trying $1 for $2 loops **\n\n"
+
+ # Is the directory available
+ if [ ! -d $SYSFS/power/ -o ! -f $SYSFS/power/state ]; then
+ printf "$SYSFS/power/state not available\n"
+ return 1
+ fi
+
+ if [ $1 = "suspend" ]; then
+ filename="mem"
+ elif [ $1 = "hibernate" ]; then
+ filename="disk"
+ else
+ printf "$1 is not a valid option\n"
+ return 1
+ fi
+
+ if [ -n $filename ]; then
+ present=$(cat $SYSFS/power/state | grep $filename)
+
+ if [ -z "$present" ]; then
+ printf "Tried to $1 but $filename isn't present in
$SYSFS/power/state\n"
+ return 1;
+ fi
+
+ for i in `seq 1 $2`; do
+ printf "Starting $1\n"
+ echo $filename > $SYSFS/power/state
+ printf "Came out of $1\n"
+
+ printf "Do basic tests after finishing $1 to verify
cpufreq state\n\n"
+ cpufreq_basic_tests
+ done
+ fi
+}
diff --git a/tools/testing/selftests/cpufreq/main.sh
b/tools/testing/selftests/cpufreq/main.sh
index 3224652ccbd4..9ff662f67ea4 100755
--- a/tools/testing/selftests/cpufreq/main.sh
+++ b/tools/testing/selftests/cpufreq/main.sh
@@ -15,7 +15,9 @@ helpme()
printf "Usage: $0 [-h] [-to args]
[-h ]
[-o ]
- [-t ]
+ [-t ]
\n"
exit 2
}
@@ -61,7 +63,7 @@ parse_arguments()
helpme
;;
- t) # --func_type (Function to perform: basic (default:
basic))
+ t) # --func_type (Function to perform: basic, suspend,
hibernate (default: basic))
FUNC=$OPTARG
;;
@@ -91,6 +93,14 @@ do_test()
cpufreq_basic_tests
;;
+ "suspend")
+ do_suspend "suspend" 1
+ ;;
+
+ "hibernate")
+ do_suspend "hibernate" 1
+ ;;
+
*)
echo "Invalid [-f] function type"
helpme
--
2.7.1.410.g6faf27b
[PATCH 0/4] selftest: cpufreq: Add support for cpufreq framework
Hi, This patchset adds support for cpufreq selftests to the kernel selftest framework. More details can be found on individual patches. These are all tested after installation of selftests on ARM Dual A15 core Exynos platform. The content of the output file for the basic tests looks like this: http://pastebin.com/nBY9AfD5 . -- viresh Viresh Kumar (4): selftest: cpufreq: Add support for cpufreq tests selftest: cpufreq: Add suspend/resume/hibernate support selftest: cpufreq: Add support to test cpufreq modules selftest: cpufreq: Add special tests tools/testing/selftests/Makefile | 1 + tools/testing/selftests/cpufreq/Makefile | 8 + tools/testing/selftests/cpufreq/cpu.sh | 84 tools/testing/selftests/cpufreq/cpufreq.sh | 241 ++ tools/testing/selftests/cpufreq/governor.sh | 153 ++ tools/testing/selftests/cpufreq/main.sh | 194 ++ tools/testing/selftests/cpufreq/module.sh| 243 +++ tools/testing/selftests/cpufreq/special-tests.sh | 115 +++ 8 files changed, 1039 insertions(+) create mode 100644 tools/testing/selftests/cpufreq/Makefile create mode 100755 tools/testing/selftests/cpufreq/cpu.sh create mode 100755 tools/testing/selftests/cpufreq/cpufreq.sh create mode 100755 tools/testing/selftests/cpufreq/governor.sh create mode 100755 tools/testing/selftests/cpufreq/main.sh create mode 100755 tools/testing/selftests/cpufreq/module.sh create mode 100755 tools/testing/selftests/cpufreq/special-tests.sh -- 2.7.1.410.g6faf27b
[PATCH 1/4] selftest: cpufreq: Add support for cpufreq tests
This patch adds supports for basic cpufreq tests, which can be performed
independent of any platform.
It does basic tests for now, like
- reading all cpufreq files
- trying to update them
- switching frequencies
- switching governors
This can be extended to have more specific tests later on.
Signed-off-by: Viresh Kumar
---
tools/testing/selftests/Makefile| 1 +
tools/testing/selftests/cpufreq/Makefile| 8 ++
tools/testing/selftests/cpufreq/cpu.sh | 84
tools/testing/selftests/cpufreq/cpufreq.sh | 201
tools/testing/selftests/cpufreq/governor.sh | 146
tools/testing/selftests/cpufreq/main.sh | 128 ++
6 files changed, 568 insertions(+)
create mode 100644 tools/testing/selftests/cpufreq/Makefile
create mode 100755 tools/testing/selftests/cpufreq/cpu.sh
create mode 100755 tools/testing/selftests/cpufreq/cpufreq.sh
create mode 100755 tools/testing/selftests/cpufreq/governor.sh
create mode 100755 tools/testing/selftests/cpufreq/main.sh
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 71b05891a6a1..a5a70e06b012 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -1,6 +1,7 @@
TARGETS = bpf
TARGETS += breakpoints
TARGETS += capabilities
+TARGETS += cpufreq
TARGETS += cpu-hotplug
TARGETS += efivarfs
TARGETS += exec
diff --git a/tools/testing/selftests/cpufreq/Makefile
b/tools/testing/selftests/cpufreq/Makefile
new file mode 100644
index ..f5c6bb1965a1
--- /dev/null
+++ b/tools/testing/selftests/cpufreq/Makefile
@@ -0,0 +1,8 @@
+all:
+
+TEST_PROGS := main.sh
+TEST_FILES := cpu.sh cpufreq.sh governor.sh
+
+include ../lib.mk
+
+clean:
diff --git a/tools/testing/selftests/cpufreq/cpu.sh
b/tools/testing/selftests/cpufreq/cpu.sh
new file mode 100755
index ..8e08a83d65f2
--- /dev/null
+++ b/tools/testing/selftests/cpufreq/cpu.sh
@@ -0,0 +1,84 @@
+#!/bin/bash
+#
+# CPU helpers
+
+# protect against multiple inclusion
+if [ $FILE_CPU ]; then
+ return 0
+else
+ FILE_CPU=DONE
+fi
+
+source cpufreq.sh
+
+for_each_cpu()
+{
+ cpus=$(ls $CPUROOT | grep "cpu[0-9].*")
+ for cpu in $cpus; do
+ $@ $cpu
+ done
+}
+
+for_each_non_boot_cpu()
+{
+ cpus=$(ls $CPUROOT | grep "cpu[1-9].*")
+ for cpu in $cpus; do
+ $@ $cpu
+ done
+}
+
+#$1: cpu
+offline_cpu()
+{
+ printf "Offline $1\n"
+ echo 0 > $CPUROOT/$1/online
+}
+
+#$1: cpu
+online_cpu()
+{
+ printf "Online $1\n"
+ echo 1 > $CPUROOT/$1/online
+}
+
+#$1: cpu
+reboot_cpu()
+{
+ offline_cpu $1
+ online_cpu $1
+}
+
+# Reboot CPUs
+# param: number of times we want to run the loop
+reboot_cpus()
+{
+ printf "** Test: Running ${FUNCNAME[0]} for $1 loops **\n\n"
+
+ for i in `seq 1 $1`; do
+ for_each_non_boot_cpu offline_cpu
+ for_each_non_boot_cpu online_cpu
+ printf "\n"
+ done
+
+ printf "\n%s\n\n" ""
+}
+
+# Prints warning for all CPUs with missing cpufreq directory
+print_unmanaged_cpus()
+{
+ for_each_cpu cpu_should_have_cpufreq_directory
+}
+
+# Counts CPUs with cpufreq directories
+count_cpufreq_managed_cpus()
+{
+ count=0;
+
+ for cpu in `ls $CPUROOT | grep "cpu[0-9].*"`; do
+ if [ -d $CPUROOT/$cpu/cpufreq ]; then
+ let count=count+1;
+ fi
+ done
+
+ echo $count;
+}
diff --git a/tools/testing/selftests/cpufreq/cpufreq.sh
b/tools/testing/selftests/cpufreq/cpufreq.sh
new file mode 100755
index ..2b8b05aaa874
--- /dev/null
+++ b/tools/testing/selftests/cpufreq/cpufreq.sh
@@ -0,0 +1,201 @@
+#!/bin/bash
+
+# protect against multiple inclusion
+if [ $FILE_CPUFREQ ]; then
+ return 0
+else
+ FILE_CPUFREQ=DONE
+fi
+
+source cpu.sh
+
+
+# $1: cpu
+cpu_should_have_cpufreq_directory()
+{
+ if [ ! -d $CPUROOT/$1/cpufreq ]; then
+ printf "Warning: No cpufreq directory present for $1\n"
+ fi
+}
+
+cpu_should_not_have_cpufreq_directory()
+{
+ if [ -d $CPUROOT/$1/cpufreq ]; then
+ printf "Warning: cpufreq directory present for $1\n"
+ fi
+}
+
+for_each_policy()
+{
+ policies=$(ls $CPUFREQROOT| grep "policy[0-9].*")
+ for policy in $policies; do
+ $@ $policy
+ done
+}
+
+for_each_policy_concurrent()
+{
+ policies=$(ls $CPUFREQROOT| grep "policy[0-9].*")
+ for policy in $policies; do
+ $@ $policy &
+ done
+}
+
+# $1: Path
+read_cpufreq_files_in_dir()
+{
+ local files=`ls $1`
+
+ printf "Printing directory: $1\n\n"
+
+ for file in $files; do
+ if [ -f $1/$file ]; then
+ printf "$file:"
+ cat $1/$file
+ else
+ printf "\n"
+
Re: [PATCH] mm: extend zero pages to same element pages for zram
On (01/13/17 15:23), Minchan Kim wrote: [..] > > > Please add same_pages to tail of the stat > > > > sounds ok to me. and yes, can deprecate zero_pages. > > > > seems that with that patch the concept of ZRAM_ZERO disappears. both > > ZERO and SAME_ELEMENT pages are considered to be the same thing now. > > Right. > > > which is fine and makes sense to me, I think. and if ->.same_pages will > > replace ->.zero_pages in mm_stat() then I'm also OK. yes, we will see > > increased number in the last column of mm_stat file, but I don't tend > > to see any issues here. Minchan, what do you think? > > Could you elaborate a bit? Do you mean this? > > ret = scnprintf(buf, PAGE_SIZE, > "%8llu %8llu %8llu %8lu %8ld %8llu %8lu\n", > orig_size << PAGE_SHIFT, > (u64)atomic64_read(&zram->stats.compr_data_size), > mem_used << PAGE_SHIFT, > zram->limit_pages << PAGE_SHIFT, > max_used << PAGE_SHIFT, > // (u64)atomic64_read(&zram->stats.zero_pages), > (u64)atomic64_read(&zram->stats.same_pages), > pool_stats.pages_compacted); yes, correct. do we need to export it as two different stats (zero_pages and same_pages), if those are basically same thing internally? -ss
[PATCH] virtio-crypto: adjust priority of algorithm
Some hardware accelerators (like intel aseni or the s390
cpacf functions) have lower priorities than virtio
crypto, and those drivers are faster than the same in
the host via virtio. So let's lower the priority of
virtio-crypto's algorithm, make it's higher than sofeware
implimentations but lower than the hardware ones.
Suggested-by: Christian Borntraeger
Signed-off-by: Gonglei
---
drivers/crypto/virtio/virtio_crypto_algs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
b/drivers/crypto/virtio/virtio_crypto_algs.c
index 6f40a42..4de4740 100644
--- a/drivers/crypto/virtio/virtio_crypto_algs.c
+++ b/drivers/crypto/virtio/virtio_crypto_algs.c
@@ -498,7 +498,7 @@ void virtio_crypto_ablkcipher_finalize_req(
static struct crypto_alg virtio_crypto_algs[] = { {
.cra_name = "cbc(aes)",
.cra_driver_name = "virtio_crypto_aes_cbc",
- .cra_priority = 501,
+ .cra_priority = 150,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct virtio_crypto_ablkcipher_ctx),
--
1.8.3.1
[PATCH] arm64/mm: use phys_addr_t
From: Miles Chen
Use phys_addr_t instead of unsigned long for the
return value of __pa(), make code easy to understand.
Signed-off-by: Miles Chen
---
arch/arm64/mm/mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 17243e4..7eb7c21 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -359,8 +359,8 @@ static void create_mapping_late(phys_addr_t phys, unsigned
long virt,
static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t
end)
{
- unsigned long kernel_start = __pa(_text);
- unsigned long kernel_end = __pa(__init_begin);
+ phys_addr_t kernel_start = __pa(_text);
+ phys_addr_t kernel_end = __pa(__init_begin);
/*
* Take care not to create a writable alias for the
--
1.9.1
Re: [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
On Fri, Jan 13, 2017 at 06:00:44AM +, Appana Durga Kedareswara Rao wrote: > Hi Vinod, > > Thanks for the review... > > [Snip] > > > > > > > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote: > > > > > When driver is handling AXI DMA SoftIP When user submits multiple > > > > > descriptors back to back on the S2MM(recv) side with the current > > > > > driver flow the last buffer descriptor next bd points to a invalid > > > > > location resulting the invalid data or errors in the DMA engine. > > > > > > > > Can you rephrase this, it a bit hard to understand. > > > > > > When DMA is receiving packets h/w expects the descriptors Should be in > > > the form of a ring (I mean h/w buffer descriptor Next descriptor field > > > should always point to valid address So that when DMA engine go and > > > fetch that next descriptor it always Sees a valid address). > > > > > > > > > But with the current driver implementation when user queues Multiple > > > descriptors the last descriptor next descriptor field Pointing to an > > > invalid location causing data corruption or Errors from the DMA h/w > > > engine... > > > > > > To avoid this issue creating a Buffer descriptor Chain during Channel > > > allocation and using those buffer descriptors for processing User > > > requested data. > > > > Is it not doable to to modify the next pointer to point to subsequent > > transaction. > > IOW you are modifying tail descriptor to point to subsequent descriptor. > > > > Btw how and when does DMA stop, assuming it is circular it never would, > > isn't > > there a valid/stop flag associated with a descriptor which tells DMA engine > > what > > to do next > > There are two registers that controls the DMA transfers. > Current descriptor and tail descriptor register. > When current descriptor reaches tail descriptor dma engine will pause. > > When reprogramming the tail descriptor the DMA engine will starts fetching > descriptors again. > > But with the existing driver flow if we reprogram the tail descriptor > The tail descriptor next descriptor field is pointing to an invalid location > Causing data corruption... So the solution is..? > > Btw there is something wrong with your MUA perhaps line are titlecased for > > no > > reason. This is typically behavious of non linux tool which may not be > > great tool > > for this work. > > Thanks for pointing it out. > I usually replies from outlook from a windows machine. > Will check with others in my team how they configured their mail client. Yeah that isnt right tool for the job. See Documentation/process/email-clients.rst FWIW, I use mutt, vim as editor with exchange servers, seems to work well for me now. -- ~Vinod
Re: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol
Hi Arnd,
On Tue, Jan 10, 2017 at 01:16:58PM +0100, Arnd Bergmann wrote:
> If CONFIG_INPUT=m, we get a build error for the rmi4-f03 driver,
> added in linux-4.10:
>
> drivers/input/built-in.o: In function `rmi_f03_attention':
> rmi_f03.c:(.text+0xcfe0): undefined reference to `serio_interrupt'
> rmi_f03.c:(.text+0xd055): undefined reference to `serio_interrupt'
> drivers/input/built-in.o: In function `rmi_f03_remove':
> rmi_f03.c:(.text+0xd115): undefined reference to `serio_unregister_port'
> drivers/input/built-in.o: In function `rmi_f03_probe':
> rmi_f03.c:(.text+0xd209): undefined reference to `__serio_register_port'
>
> If we make the driver itself a 'tristate' instead of 'bool' symbol,
> Kconfig ensures that it can only be a loadable module in this case,
> which avoids the problem.
>
> Fixes: c5e8848fc98e ("Input: synaptics-rmi4 - add support for F03")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/input/rmi4/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
> index 30cc627a4f45..ad945b25722c 100644
> --- a/drivers/input/rmi4/Kconfig
> +++ b/drivers/input/rmi4/Kconfig
> @@ -40,7 +40,7 @@ config RMI4_SMB
> called rmi_smbus.
>
> config RMI4_F03
> -bool "RMI4 Function 03 (PS2 Guest)"
> +tristate "RMI4 Function 03 (PS2 Guest)"
> depends on RMI4_CORE && SERIO
> help
>Say Y here if you want to add support for RMI4 function 03.
> --
> 2.9.0
>
As it was explained townthread we can't [currently] make functions
modules, in the meantime I have d7ddad0acc4add42567f7879b116a0b9eea31860
that should fix this issue (and I just sent pull request for it).
Thanks.
--
Dmitry
Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points
Hi!
On 01/13/2017 12:22 PM, Junxiao Bi wrote:
On 01/05/2017 11:31 PM, Eric Ren wrote:
Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
results in a deadlock, as the author "Tariq Saeed" realized shortly
after the patch was merged. The discussion happened here
(https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html).
The reason why taking cluster inode lock at vfs entry points opens up
a self deadlock window, is explained in the previous patch of this
series.
So far, we have seen two different code paths that have this issue.
1. do_sys_open
may_open
inode_permission
ocfs2_permission
ocfs2_inode_lock() <=== take PR
generic_permission
get_acl
ocfs2_iop_get_acl
ocfs2_inode_lock() <=== take PR
2. fchmod|fchmodat
chmod_common
notify_change
ocfs2_setattr <=== take EX
posix_acl_chmod
get_acl
ocfs2_iop_get_acl <=== take PR
ocfs2_iop_set_acl <=== take EX
Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
Signed-off-by: Eric Ren
---
fs/ocfs2/acl.c | 39 ++-
fs/ocfs2/file.c | 44 ++--
2 files changed, 68 insertions(+), 15 deletions(-)
diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
index bed1fcb..c539890 100644
--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -284,16 +284,31 @@ int ocfs2_iop_set_acl(struct inode *inode, struct
posix_acl *acl, int type)
{
struct buffer_head *bh = NULL;
int status = 0;
-
- status = ocfs2_inode_lock(inode, &bh, 1);
+ int arg_flags = 0, has_locked;
+ struct ocfs2_holder oh;
+ struct ocfs2_lock_res *lockres;
+
+ lockres = &OCFS2_I(inode)->ip_inode_lockres;
+ has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+ if (has_locked)
+ arg_flags = OCFS2_META_LOCK_GETBH;
+ status = ocfs2_inode_lock_full(inode, &bh, 1, arg_flags);
if (status < 0) {
if (status != -ENOENT)
mlog_errno(status);
return status;
}
+ if (!has_locked)
+ ocfs2_add_holder(lockres, &oh);
+
status = ocfs2_set_acl(NULL, inode, bh, type, acl, NULL, NULL);
- ocfs2_inode_unlock(inode, 1);
+
+ if (!has_locked) {
+ ocfs2_remove_holder(lockres, &oh);
+ ocfs2_inode_unlock(inode, 1);
+ }
brelse(bh);
+
return status;
}
@@ -303,21 +318,35 @@ struct posix_acl *ocfs2_iop_get_acl(struct inode *inode, int type)
struct buffer_head *di_bh = NULL;
struct posix_acl *acl;
int ret;
+ int arg_flags = 0, has_locked;
+ struct ocfs2_holder oh;
+ struct ocfs2_lock_res *lockres;
osb = OCFS2_SB(inode->i_sb);
if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
return NULL;
- ret = ocfs2_inode_lock(inode, &di_bh, 0);
+
+ lockres = &OCFS2_I(inode)->ip_inode_lockres;
+ has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+ if (has_locked)
+ arg_flags = OCFS2_META_LOCK_GETBH;
+ ret = ocfs2_inode_lock_full(inode, &di_bh, 0, arg_flags);
if (ret < 0) {
if (ret != -ENOENT)
mlog_errno(ret);
return ERR_PTR(ret);
}
+ if (!has_locked)
+ ocfs2_add_holder(lockres, &oh);
acl = ocfs2_get_acl_nolock(inode, type, di_bh);
- ocfs2_inode_unlock(inode, 0);
+ if (!has_locked) {
+ ocfs2_remove_holder(lockres, &oh);
+ ocfs2_inode_unlock(inode, 0);
+ }
brelse(di_bh);
+
return acl;
}
diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index c488965..62be75d 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1138,6 +1138,9 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr
*attr)
handle_t *handle = NULL;
struct dquot *transfer_to[MAXQUOTAS] = { };
int qtype;
+ int arg_flags = 0, had_lock;
+ struct ocfs2_holder oh;
+ struct ocfs2_lock_res *lockres;
trace_ocfs2_setattr(inode, dentry,
(unsigned long long)OCFS2_I(inode)->ip_blkno,
@@ -1173,13 +1176,20 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr
*attr)
}
}
- status = ocfs2_inode_lock(inode, &bh, 1);
+ lockres = &OCFS2_I(inode)->ip_inode_lockres;
+ had_lock = (ocfs2_is_locked_by_me(lockres) != NULL);
If had_lock==true, it is a bug? I think we should BUG_ON for it, that
can help us catch bug at the first time.
Good idea! But I'm not sure if "ocfs2_setattr" is always the first one who takes the cluster
lock.
It's harder for me to name all the possible paths;-/
+ if (had_lock)
+ arg_flags = OCFS2_META_LOCK_G
Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock
Hi Junxiao!
On 01/13/2017 11:59 AM, Junxiao Bi wrote:
On 01/05/2017 11:31 PM, Eric Ren wrote:
We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been taken by a
precess already.
Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard to handle the routines that
are invoked directly by vfs code. For instance:
const struct inode_operations ocfs2_file_iops = {
.permission = ocfs2_permission,
.get_acl= ocfs2_iop_get_acl,
.set_acl= ocfs2_iop_set_acl,
};
Both ocfs2_permission() and ocfs2_iop_get_acl() call ocfs2_inode_lock(PR):
do_sys_open
may_open
inode_permission
ocfs2_permission
ocfs2_inode_lock() <=== first time
generic_permission
get_acl
ocfs2_iop_get_acl
ocfs2_inode_lock() <=== recursive one
A deadlock will occur if a remote EX request comes in between two
of ocfs2_inode_lock(). Briefly describe how the deadlock is formed:
On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in
BAST(ocfs2_generic_handle_bast) when downconvert is started
on behalf of the remote EX lock request. Another hand, the recursive
cluster lock (the second one) will be blocked in in __ocfs2_cluster_lock()
because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, why?
because there is no chance for the first cluster lock on this node to be
unlocked - we block ourselves in the code path.
The idea to fix this issue is mostly taken from gfs2 code.
1. introduce a new field: struct ocfs2_lock_res.l_holders, to
keep track of the processes' pid who has taken the cluster lock
of this lock resource;
2. introduce a new flag for ocfs2_inode_lock_full: OCFS2_META_LOCK_GETBH;
it means just getting back disk inode bh for us if we've got cluster lock.
3. export a helper: ocfs2_is_locked_by_me() is used to check if we
have got the cluster lock in the upper code path.
The tracking logic should be used by some of the ocfs2 vfs's callbacks,
to solve the recursive locking issue cuased by the fact that vfs routines
can call into each other.
The performance penalty of processing the holder list should only be seen
at a few cases where the tracking logic is used, such as get/set acl.
You may ask what if the first time we got a PR lock, and the second time
we want a EX lock? fortunately, this case never happens in the real world,
as far as I can see, including permission check, (get|set)_(acl|attr), and
the gfs2 code also do so.
Signed-off-by: Eric Ren
---
fs/ocfs2/dlmglue.c | 47 ---
fs/ocfs2/dlmglue.h | 18 ++
fs/ocfs2/ocfs2.h | 1 +
3 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 83d576f..500bda4 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -532,6 +532,7 @@ void ocfs2_lock_res_init_once(struct ocfs2_lock_res *res)
init_waitqueue_head(&res->l_event);
INIT_LIST_HEAD(&res->l_blocked_list);
INIT_LIST_HEAD(&res->l_mask_waiters);
+ INIT_LIST_HEAD(&res->l_holders);
}
void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,
@@ -749,6 +750,45 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res *res)
res->l_flags = 0UL;
}
+inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
+ struct ocfs2_holder *oh)
+{
+ INIT_LIST_HEAD(&oh->oh_list);
+ oh->oh_owner_pid = get_pid(task_pid(current));
struct pid(oh->oh_owner_pid) looks complicated here, why not use
task_struct(current) or pid_t(current->pid) directly? Also i didn't see
the ref count needs to be considered.
This is learned from gfs2 code, which is tested by practice. So, I think it's
not bad
to keep it;-)
+
+ spin_lock(&lockres->l_lock);
+ list_add_tail(&oh->oh_list, &lockres->l_holders);
+ spin_unlock(&lockres->l_lock);
+}
+
+inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
+ struct ocfs2_holder *oh)
+{
+ spin_lock(&lockres->l_lock);
+ list_del(&oh->oh_list);
+ spin_unlock(&lockres->l_lock);
+
+ put_pid(oh->oh_owner_pid);
same the above
+}
+
+inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res
*lockres)
Agree with Joseph, return bool looks better. I didn't see how that help
debug since the return value is not used.
+{
+ struct ocfs2_holder *oh;
+ struct pid *pid;
+
+ /* look in the list of holders for one with the current task as owner */
+ spin_lock(&lockres->l_lock);
+ pid = task_pid(current);
+ list_for_each_entry(oh, &lockres->l_holders, oh_list) {
+ if (oh->oh_owner_pid == pid)
+ goto out;
+ }
+ oh = NULL;
+out:
+ spin_unlock(&lockres->l_lock);
+ return oh;
+}
+
static inline void ocfs2_inc_holders(struct ocfs2_lo
Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure
Thanks for your replying.
I understand this bug is more complicated than I expected.
I classify error cases under submit_extent_page() below
A: ENOMEM error at btrfs_bio_alloc() in submit_extent_page()
I first assumed this case and sent the mail.
When bio_ret is NULL, submit_extent_page() calls btrfs_bio_alloc().
Then, btrfs_bio_alloc() may fail and submit_extent_page() returns -ENOMEM.
In this case, bio_endio() is not called and the page's writeback bit
remains.
So, there is a need to call end_page_writeback() in the error handling.
B: errors under submit_one_bio() of submit_extent_page()
Errors that occur under submit_one_bio() handles at bio_endio(), and
bio_endio() would call end_page_writeback().
Therefore, as you mentioned in the last mail, simply adding
end_page_writeback() like my last email and commit 55e3bd2e0c2e1 can
conflict in the case of B.
To avoid such conflict, one easy solution is adding PageWriteback()
check too.
How do you think of this solution?
Sincerely,
On 2016/12/22 15:20, Liu Bo wrote:
On Fri, Dec 16, 2016 at 03:41:50PM +0900, Takafumi Kubota wrote:
This is actually inspired by Filipe's patch(55e3bd2e0c2e1).
When submit_extent_page() in __extent_writepage_io() fails,
Btrfs misses clearing a writeback bit of the failed page.
This causes the false under-writeback page.
Then, another sync task hangs in filemap_fdatawait_range(),
because it waits the false under-writeback page.
CPU0CPU1
__extent_writepage_io()
ret = submit_extent_page() // fail
if (ret)
SetPageError(page)
// miss clearing the writeback bit
sync()
...
filemap_fdatawait_range()
wait_on_page_writeback(page);
// wait the false under-writeback page
Signed-off-by: Takafumi Kubota
---
fs/btrfs/extent_io.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1e67723..ef9793b 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3443,8 +3443,10 @@ static noinline_for_stack int
__extent_writepage_io(struct inode *inode,
bdev, &epd->bio, max_nr,
end_bio_extent_writepage,
0, 0, 0, false);
- if (ret)
+ if (ret) {
SetPageError(page);
+ end_page_writeback(page);
+ }
OK...this could be complex as we don't know which part in
submit_extent_page gets the error, if the page has been added into bio
and bio_end would call end_page_writepage(page) as well, so whichever
comes later, the BUG() in end_page_writeback() would complain.
Looks like commit 55e3bd2e0c2e1 also has the same problem although I
gave it my reviewed-by.
Thanks,
-liubo
cur = cur + iosize;
pg_offset += iosize;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Keio University
System Software Laboratory
Takafumi Kubota
takafumi.kubota1...@sslab.ics.keio.jp
[PATCH] x86 tsc: Add the Intel Denverton Processor to native_calibrate_tsc()
From: Len Brown The Intel Denverton microserver uses a 25 MHz TSC crystal, so we can derive its exact * TSC frequency using CPUID and some arithmetic, eg. TSC: 1800 MHz (2500 Hz * 216 / 3 / 100) * 'exact' is only as good as the crystal, which should be +/- 20ppm Signed-off-by: Len Brown --- arch/x86/kernel/tsc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index 46b2f41f8b05..b3e397a0f29d 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -694,6 +694,7 @@ unsigned long native_calibrate_tsc(void) crystal_khz = 24000;/* 24.0 MHz */ break; case INTEL_FAM6_SKYLAKE_X: + case INTEL_FAM6_ATOM_DENVERTON: crystal_khz = 25000;/* 25.0 MHz */ break; case INTEL_FAM6_ATOM_GOLDMONT: -- 2.11.0.161.g6610af872
Re: blk_queue_bounce_limit() broken for mask=0xffffffff on 64bit archs
>> There is a use cases when architecture is 64-bit but hardware supports >> only DMA to lower 4G of address space. E.g. NVMe device on RCar PCIe host. >> >> For such cases, it looks proper to call blk_queue_bounce_limit() with >> mask set to 0x - thus making block layer to use bounce buffers >> for any addresses beyond 4G. To support that, architecture provides >> GFP_DMA zone that covers exactly low 4G on arm64. >> >> However setting this limit does not work: >> >> if (b_pfn < (min_t(u64, 0xUL, BLK_BOUNCE_HIGH) >> PAGE_SHIFT)) >> dma = 1; >> >> When mask is 0x that condition is false > > That should have been true in your case, since the b_pfn is smaller than > 0x. b_pfn is exactly 0xUL >> SHIFT, thus contition is false >> q->limits.bounce_pfn = max(max_low_pfn, b_pfn); >> >> this line is executed and replaces any limit with end of memory (on >> 64bit arch all memory is low). > > I don't understand why max() is used? And why not min()? > > Looks the above line just disables bounce for 64bit arch, doesn't it? Effectively yes. And I don't understand logic behind this code. Nikita
Re: blk_queue_bounce_limit() broken for mask=0xffffffff on 64bit archs
Hi, On Tue, Jan 10, 2017 at 4:48 AM, Nikita Yushchenko wrote: > Hi > > There is a use cases when architecture is 64-bit but hardware supports > only DMA to lower 4G of address space. E.g. NVMe device on RCar PCIe host. > > For such cases, it looks proper to call blk_queue_bounce_limit() with > mask set to 0x - thus making block layer to use bounce buffers > for any addresses beyond 4G. To support that, architecture provides > GFP_DMA zone that covers exactly low 4G on arm64. > > However setting this limit does not work: > > if (b_pfn < (min_t(u64, 0xUL, BLK_BOUNCE_HIGH) >> PAGE_SHIFT)) > dma = 1; > > When mask is 0x that condition is false That should have been true in your case, since the b_pfn is smaller than 0x. > > q->limits.bounce_pfn = max(max_low_pfn, b_pfn); > > this line is executed and replaces any limit with end of memory (on > 64bit arch all memory is low). I don't understand why max() is used? And why not min()? Looks the above line just disables bounce for 64bit arch, doesn't it? Thanks, Ming > > > Not sure how to fix this properly. Any hints? > -- > To unsubscribe from this list: send the line "unsubscribe linux-block" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ming Lei
Re: linux-next: build failure after merge of the akpm-current tree
Hi, On 01/13/2017 11:42 AM, Stephen Rothwell wrote: Hi Eric, On Thu, 12 Jan 2017 13:06:01 +0800 Eric Ren wrote: Thanks for your report and the fix for it. The 0-day project has reported several days ago, but this patch set is still in discussion, so I am waiting for more days to see if other developers have any other questions. I am confused that how to deal with your patch if I need to work out the V2 patch set. Perhaps, pick up your fix and add your efforts in the change log? If you had already fixed the problem, then just submit your new version. You only need to give credit when you use someone's work. If you want to give credit, then maybe a line like: [s...@canb.auug.org.au remove some inlines] among the Signed-off-by: lines Sure! I always keep it in mind;-) Thanks, Eric
RE: [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
Hi Vinod, Thanks for the review... [Snip] > > > > > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote: > > > > When driver is handling AXI DMA SoftIP When user submits multiple > > > > descriptors back to back on the S2MM(recv) side with the current > > > > driver flow the last buffer descriptor next bd points to a invalid > > > > location resulting the invalid data or errors in the DMA engine. > > > > > > Can you rephrase this, it a bit hard to understand. > > > > When DMA is receiving packets h/w expects the descriptors Should be in > > the form of a ring (I mean h/w buffer descriptor Next descriptor field > > should always point to valid address So that when DMA engine go and > > fetch that next descriptor it always Sees a valid address). > > > > > > But with the current driver implementation when user queues Multiple > > descriptors the last descriptor next descriptor field Pointing to an > > invalid location causing data corruption or Errors from the DMA h/w > > engine... > > > > To avoid this issue creating a Buffer descriptor Chain during Channel > > allocation and using those buffer descriptors for processing User > > requested data. > > Is it not doable to to modify the next pointer to point to subsequent > transaction. > IOW you are modifying tail descriptor to point to subsequent descriptor. > > Btw how and when does DMA stop, assuming it is circular it never would, isn't > there a valid/stop flag associated with a descriptor which tells DMA engine > what > to do next There are two registers that controls the DMA transfers. Current descriptor and tail descriptor register. When current descriptor reaches tail descriptor dma engine will pause. When reprogramming the tail descriptor the DMA engine will starts fetching descriptors again. But with the existing driver flow if we reprogram the tail descriptor The tail descriptor next descriptor field is pointing to an invalid location Causing data corruption... > > > Btw there is something wrong with your MUA perhaps line are titlecased for no > reason. This is typically behavious of non linux tool which may not be great > tool > for this work. Thanks for pointing it out. I usually replies from outlook from a windows machine. Will check with others in my team how they configured their mail client. > > > > > Please let me know if the above explanation is not clear will explain in > > detail > > > > > > > > > > > > > This patch fixes this issue by creating a BD Chain during > > > > > > whats a BD? > > > > Buffer descriptor. > > Thats nowhere mentioned.. Yep sorry I should have been mentioned it... Regards, Kedar.
Re: [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
FYI, here is my tree (based on linux-next): https://github.com/aospan/linux-next-bcm4708-edgecore-ecw7220-l/commits/master last patches adding defconfig and dts I'm using for this device. This files are draft yet. 2017-01-12 19:22 GMT-05:00 Florian Fainelli : > On 01/12/2017 04:20 PM, Abylay Ospan wrote: >> pcie->dev->of_node not always defined (NULL) and can cause crash: >> >> [ 19.053195] Unable to handle kernel NULL pointer dereference at >> virtual address 0020 >> [] (of_n_addr_cells) from [] >> (iproc_pcie_setup+0x30c/0xce0) >> >> this patch adds sanity check to prevent crash. > > Humm, how can it not be defined based on your earlier comment that you > are using this on NSP which is Device Tree exclusively? I would agree if > this was seen on e.g: MIPS/BCMA (47xx). > >> >> Signed-off-by: Abylay Ospan >> --- >> drivers/pci/host/pcie-iproc.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c >> index 3ebc025..f2836a9 100644 >> --- a/drivers/pci/host/pcie-iproc.c >> +++ b/drivers/pci/host/pcie-iproc.c >> @@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct >> of_pci_range_parser *parser, >> const int na = 3, ns = 2; >> int rlen; >> >> + if (!node) >> + return -ENOENT; >> + >> parser->node = node; >> parser->pna = of_n_addr_cells(node); >> parser->np = parser->pna + na + ns; >> > > > -- > Florian -- Abylay Ospan, NetUP Inc. http://www.netup.tv
arm64: dts: mt8173: add node for thermal calibration
From: "dawei.ch...@mediatek.com"
Add this for supporting thermal calibration by e-fuse data.
Signed-off-by: Dawei Chien
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..adfac1e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -401,6 +401,11 @@
efuse: efuse@10206000 {
compatible = "mediatek,mt8173-efuse";
reg = <0 0x10206000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ thermal_calibration: calib@528 {
+ reg = <0x528 0xc>;
+ };
};
apmixedsys: clock-controller@10209000 {
@@ -574,6 +579,8 @@
resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
mediatek,auxadc = <&auxadc>;
mediatek,apmixedsys = <&apmixedsys>;
+ nvmem-cells = <&thermal_calibration>;
+ nvmem-cell-names = "calibration-data";
};
nor_flash: spi@1100d000 {
--
1.9.1
[git pull] Input updates for 4.10-rc3
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem - small driver fixups. Changelog: - Andy Shevchenko (1): Input: adxl34x - make it enumerable in ACPI environment Aniroop Mathur (1): Input: synaptics_i2c - change msleep to usleep_range for small msecs Corentin Labbe (1): Input: joydev - remove unused linux/miscdevice.h include Dmitry Torokhov (1): Input: synaptics-rmi4 - fix F03 build error when serio is module Guenter Roeck (1): Input: elants_i2c - avoid divide by 0 errors on bad touchscreen data Marcos Paulo de Souza (1): Input: i8042 - add Pegatron touchpad to noloop table Paul Donohue (1): Input: ALPS - fix TrackStick Y axis handling for SS5 hardware Pavel Rojtberg (1): Input: xpad - use correct product id for x360w controllers Diffstat: drivers/input/joydev.c | 1 - drivers/input/joystick/xpad.c | 6 ++ drivers/input/misc/adxl34x-i2c.c | 4 +--- drivers/input/mouse/alps.h | 2 +- drivers/input/mouse/synaptics_i2c.c| 4 ++-- drivers/input/rmi4/Kconfig | 3 ++- drivers/input/serio/i8042-x86ia64io.h | 6 ++ drivers/input/touchscreen/elants_i2c.c | 4 ++-- 8 files changed, 20 insertions(+), 10 deletions(-) -- Dmitry
[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options
Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 ++
.../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..1b658351629b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: contains a reset GPIO specifier.
+
+Example:
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-sd8787";
+ pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
+ reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
+ }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
--
This node provides properties for controlling the Marvell SDIO/PCIE wireless
device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain
condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Changes from v2: * fix rookie mistake missing the main source file and docs Matt Ranostay (2): devicetree: document new marvell-8xxx and pwrseq-sd8787 options mmc: pwrseq: add support for Marvell SD8787 chip .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++ .../bindings/net/wireless/marvell-8xxx.txt | 7 +- drivers/mmc/core/Kconfig | 10 ++ drivers/mmc/core/Makefile | 1 + drivers/mmc/core/pwrseq_sd8787.c | 117 + 5 files changed, 148 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt create mode 100644 drivers/mmc/core/pwrseq_sd8787.c -- 2.10.2
[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Changes from v2: * fix rookie mistake missing the main source file and docs Matt Ranostay (2): devicetree: document new marvell-8xxx and pwrseq-sd8787 options mmc: pwrseq: add support for Marvell SD8787 chip .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++ .../bindings/net/wireless/marvell-8xxx.txt | 7 +- drivers/mmc/core/Kconfig | 10 ++ drivers/mmc/core/Makefile | 1 + drivers/mmc/core/pwrseq_sd8787.c | 117 + 5 files changed, 148 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt create mode 100644 drivers/mmc/core/pwrseq_sd8787.c -- 2.10.2
[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren
Cc: Ulf Hansson
Signed-off-by: Matt Ranostay
---
drivers/mmc/core/Kconfig | 10
drivers/mmc/core/Makefile| 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++
3 files changed, 128 insertions(+)
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay
+ *
+ * Based on the original work pwrseq_simple.c
+ * Copyright (C) 2014 Linaro Ltd
+ * Author: Ulf Hansson
+ *
+ * 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 "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+ struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+ msleep(300);
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+ .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+ .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+ { .compatible = "mmc-pwrseq-sd8787",},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq;
+ struct device *dev = &pdev->dev;
+
+ pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+ if (!pwrseq)
+ return -ENOMEM;
+
+ pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->pwrdn_gpio))
+ return PTR_ERR(pwrseq->pwrdn_gpio);
+
+ pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->reset_gpio))
+ return PTR_ERR(pwrseq->reset_gpio);
+
+ pwrseq->pwrseq.dev = dev;
+ pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
+ pwrseq->pwrseq.owner = THIS_MODULE;
+ platform_set_drvdata(pdev, pwrseq);
+
+ return mmc_pwrseq_register(&pwrseq->pwrseq);
+}
+
+static int mmc_pwrseq_sd8787_remove(struct platform_
Re: [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
On Thu, Jan 12, 2017 at 02:19:49PM +, Appana Durga Kedareswara Rao wrote: > Hi Vinod, > > Thanks for the review... > > > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote: > > > When driver is handling AXI DMA SoftIP When user submits multiple > > > descriptors back to back on the S2MM(recv) side with the current > > > driver flow the last buffer descriptor next bd points to a invalid > > > location resulting the invalid data or errors in the DMA engine. > > > > Can you rephrase this, it a bit hard to understand. > > When DMA is receiving packets h/w expects the descriptors > Should be in the form of a ring (I mean h/w buffer descriptor > Next descriptor field should always point to valid address > So that when DMA engine go and fetch that next descriptor it always > Sees a valid address). > > > But with the current driver implementation when user queues > Multiple descriptors the last descriptor next descriptor field > Pointing to an invalid location causing data corruption or > Errors from the DMA h/w engine... > > To avoid this issue creating a Buffer descriptor Chain during > Channel allocation and using those buffer descriptors for processing > User requested data. Is it not doable to to modify the next pointer to point to subsequent transaction. IOW you are modifying tail descriptor to point to subsequent descriptor. Btw how and when does DMA stop, assuming it is circular it never would, isn't there a valid/stop flag associated with a descriptor which tells DMA engine what to do next Btw there is something wrong with your MUA perhaps line are titlecased for no reason. This is typically behavious of non linux tool which may not be great tool for this work. > > Please let me know if the above explanation is not clear will explain in > detail > > > > > > > > > This patch fixes this issue by creating a BD Chain during > > > > whats a BD? > > Buffer descriptor. Thats nowhere mentioned.. > > > > > > channel allocation itself and use those BD's. > > > > > > Signed-off-by: Kedareswara rao Appana > > > --- > > > > > > drivers/dma/xilinx/xilinx_dma.c | 133 > > > +--- > > > 1 file changed, 83 insertions(+), 50 deletions(-) > > > > > > diff --git a/drivers/dma/xilinx/xilinx_dma.c > > > b/drivers/dma/xilinx/xilinx_dma.c index 0e9c02e..af2159d 100644 > > > --- a/drivers/dma/xilinx/xilinx_dma.c > > > +++ b/drivers/dma/xilinx/xilinx_dma.c > > > @@ -163,6 +163,7 @@ > > > #define XILINX_DMA_BD_SOPBIT(27) > > > #define XILINX_DMA_BD_EOPBIT(26) > > > #define XILINX_DMA_COALESCE_MAX 255 > > > +#define XILINX_DMA_NUM_DESCS 255 > > > > why 255? > > It is not an h/w limitation > Allocating 255 descriptors (Each descriptor is capable of sending 7MB data) > So roughly using allocated descriptors DMA engine can transfer 1GB data > And in the driver we are reusing the allocated descriptors when they are free. > > Regards, > Kedar. -- ~Vinod
Re: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
On Fri, Jan 13, 2017 at 04:28:11AM +, Appana Durga Kedareswara Rao wrote: > Hi Vinod, > > Thanks for the review... > > > > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote: > > > Add channel idle state to ensure that dma descriptor is not > > > submitted when VDMA engine is in progress. > > > > any reason why you want to make your own varible and not use the HW to > > query > > as done earlier. It is not clear to me why that is removed from description > > We need to poll for a bit in the status register to know the dma state. > We are currently doing that in the driver hot path > To avoid this using own variables. It would be worthwhile to document these, down the line people may not remeber the motivation -- ~Vinod
RE: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
Hi Vinod, Thanks for the review... > > On Fri, Jan 13, 2017 at 04:28:11AM +, Appana Durga Kedareswara Rao > wrote: > > Hi Vinod, > > > > Thanks for the review... > > > > > > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote: > > > > Add channel idle state to ensure that dma descriptor is not > > > > submitted when VDMA engine is in progress. > > > > > > any reason why you want to make your own varible and not use the HW > > > to query as done earlier. It is not clear to me why that is removed > > > from description > > > > We need to poll for a bit in the status register to know the dma state. > > We are currently doing that in the driver hot path To avoid this using > > own variables. > > It would be worthwhile to document these, down the line people may not > remeber the motivation Sure will add comments during the variable initialization In the driver... Regards, Kedar. > > > -- > ~Vinod
Re: [PATCH] PCI: iproc: fix resource allocation for BCMA PCIe
Hi Ray,
i'm not sure but looks so. Following drivers is doing same allocation on stack:
drivers/pci/host/pcie-designware.c
drivers/pci/host/pcie-rockchip.c
drivers/pci/host/pcie-xilinx.c
drivers/pci/host/pcie-xilinx-nwl.c
drivers/pci/host/pci-host-common.c
-> drivers/pci/host/pci-thunder-ecam.c
-> drivers/pci/host/pci-thunder-pem.c
-> drivers/pci/host/pci-host-generic.c
drivers/pci/host/pci-versatile.c
drivers/pci/host/pci-xgene.c
other drivers is ok. But need to double-check.
Below is more detailed description of the problem.
Problem is visible when second PCIe bridge registering (but can cause
kernel crash with only one PCIe bridge because broken pointer
introduced to 'iomem_resource' anyway). Here is my global
'iomem_resource' list dump:
after first PCIe bridge registered:
[3.578650] iomem_resource child=cb039d40 name=PCIe MEM space start=0800
[3.585811] iomem_resource child=cb41da80 name=serial start=18000300
[3.592267] iomem_resource child=cb15ce80 name=serial start=18000400
[3.598719] iomem_resource child=cb57df00 name=nand start=18028000
[3.605001] iomem_resource child=cb57dc80 name=iproc-ext start=18028f00
[3.611723] iomem_resource child=cb57da00 name=iproc-idm start=1811a408
[3.618433] iomem_resource child=cbfffe80 name=System RAM start=8000
this dump looks good but before registering second PCIe same dump looks broken:
[3.669225] iomem_resource child=cb039d40 name=PCIe MEM space start=4000
[3.676395] iomem_resource child=cb5e3410 name=bcma0:8 start=cb0f6e10
[3.682948] iomem_resource child=cb061080 name= start=c1604b04
and second PCIe registration fail with:
[3.694207] pcie_iproc_bcma bcma0:8: resource collision: [mem
0x4000-0x47ff] conflicts with PCIe MEM space [mem
0x4000-0x47ff]
[3.707024] pcie_iproc_bcma bcma0:8: PCIe controller setup failed
address 0xcb039d40 from this dumps is allocated on stack and is not
valid after 'iproc_pcie_bcma_probe' exit.
Proposed patch is fixing this issue.
2017-01-12 19:40 GMT-05:00 Ray Jui :
> Hi Abylay,
>
> On 1/12/2017 3:58 PM, Abylay Ospan wrote:
>> Resource allocated on stack was saved by 'devm_request_resource' to
>> global 'iomem_resource' but become invalid after 'iproc_pcie_bcma_probe'
>> exit.
>> So the global 'iomem_resource' was poisoned. This may cause kernel crash
>> or second PCIe bridge registration failure.
>>
>> Tested on Broadcom NorthStar machine ('Edgecore ECW7220-L') with two PCIe
>> wifi
>> adapters (b43 BCM4331 and ath10k QCA988X).
>>
>> Signed-off-by: Abylay Ospan
>
> I have not yet looked into this in great details. But if what you
> claimed is true, do we have the same problem with multiple PCIe host
> drivers that all have their resource allocated on the stack and have
> 'devm_request_resource' called to save it?
>
> Thanks,
>
> Ray
>
>> ---
>> drivers/pci/host/pcie-iproc-bcma.c | 18 --
>> drivers/pci/host/pcie-iproc.h | 2 ++
>> 2 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/pci/host/pcie-iproc-bcma.c
>> b/drivers/pci/host/pcie-iproc-bcma.c
>> index bd4c9ec..28f9b89 100644
>> --- a/drivers/pci/host/pcie-iproc-bcma.c
>> +++ b/drivers/pci/host/pcie-iproc-bcma.c
>> @@ -44,8 +44,6 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
>> {
>> struct device *dev = &bdev->dev;
>> struct iproc_pcie *pcie;
>> - LIST_HEAD(res);
>> - struct resource res_mem;
>> int ret;
>>
>> pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
>> @@ -62,21 +60,21 @@ static int iproc_pcie_bcma_probe(struct bcma_device
>> *bdev)
>> }
>>
>> pcie->base_addr = bdev->addr;
>> + INIT_LIST_HEAD(&pcie->resources);
>>
>> - res_mem.start = bdev->addr_s[0];
>> - res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
>> - res_mem.name = "PCIe MEM space";
>> - res_mem.flags = IORESOURCE_MEM;
>> - pci_add_resource(&res, &res_mem);
>> + pcie->res_mem.start = bdev->addr_s[0];
>> + pcie->res_mem.end = bdev->addr_s[0] + SZ_128M - 1;
>> + pcie->res_mem.name = "PCIe MEM space";
>> + pcie->res_mem.flags = IORESOURCE_MEM;
>> + pcie->res_mem.child = NULL;
>> + pci_add_resource(&pcie->resources, &pcie->res_mem);
>>
>> pcie->map_irq = iproc_pcie_bcma_map_irq;
>>
>> - ret = iproc_pcie_setup(pcie, &res);
>> + ret = iproc_pcie_setup(pcie, &pcie->resources);
>> if (ret)
>> dev_err(dev, "PCIe controller setup failed\n");
>>
>> - pci_free_resource_list(&res);
>> -
>> bcma_set_drvdata(bdev, pcie);
>> return ret;
>> }
>> diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
>> index 04fed8e..866d649 100644
>> --- a/drivers/pci/host/pcie-iproc.h
>> +++ b/drivers/pci/host/pcie-iproc.h
>> @@ -105,6 +105,8 @@ struct iproc_pcie {
>>
>> bool need_msi_steer;
>> struct iproc_msi *msi;
>> + struct resource res_mem;
>> + struct list_head resources;
>> };
>>
>> int iproc_pcie_s
Re: [PATCH] PCI: iproc: fix kernel crash if dev->of_node not defined
Hi Florian,
> Still, upstream Linux support for Northstar is Device Tree, and BCMA bus
> should fill in of_nodes accordingly, if not, that's a bug that must be
> fixed at the BCMA layer.
yes, this is a source of the problem. Devices allocated in
'bcma_bus_scan' but of_node doesn't assigned.
Is some code missing in drivers/bcma/ which should assign of_node ?
I can suggest following "hacky" patch for this (works for me):
Author: Abylay Ospan
Date: Fri Jan 13 07:24:13 2017 +0300
bcma: force assign 'of_node' for devices on the bus
prevent other code to fail if no 'of_node' defined
Signed-off-by: Abylay Ospan
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 2c1798e..4fe1c92 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -301,6 +301,11 @@ void bcma_init_bus(struct bcma_bus *bus)
static void bcma_register_core(struct bcma_bus *bus, struct bcma_device *core)
{
int err;
+ struct device * dev;
+
+ dev = bcma_bus_get_host_dev(bus);
+ if (dev && !core->dev.of_node)
+ core->dev.of_node = dev->of_node;
if it's ok I will send this patch in separate email.
>
>>
>>>
Signed-off-by: Abylay Ospan
---
drivers/pci/host/pcie-iproc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 3ebc025..f2836a9 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -952,6 +952,9 @@ static int pci_dma_range_parser_init(struct
of_pci_range_parser *parser,
const int na = 3, ns = 2;
int rlen;
+ if (!node)
+ return -ENOENT;
+
parser->node = node;
parser->pna = of_n_addr_cells(node);
parser->np = parser->pna + na + ns;
>>>
>>>
>
>
> --
> Florian
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
Re: [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
On Thu, Jan 12, 2017 at 9:22 PM, Matt Ranostay wrote: > Allow power sequencing for the Marvell SD8787 Wifi/BT chip. > This can be abstracted to other chipsets if needed in the future. Er crap seems how the main patch file got dropped out. Resubmitting in a minute... sorry! > > Cc: Tony Lindgren > Cc: Ulf Hansson > Signed-off-by: Matt Ranostay > --- > drivers/mmc/core/Kconfig | 10 ++ > drivers/mmc/core/Makefile | 1 + > 2 files changed, 11 insertions(+) > > diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig > index cdfa8520a4b1..fc1ecdaaa9ca 100644 > --- a/drivers/mmc/core/Kconfig > +++ b/drivers/mmc/core/Kconfig > @@ -12,6 +12,16 @@ config PWRSEQ_EMMC > This driver can also be built as a module. If so, the module > will be called pwrseq_emmc. > > +config PWRSEQ_SD8787 > + tristate "HW reset support for SD8787 BT + Wifi module" > + depends on OF && (MWIFIEX || BT_MRVL_SDIO) > + help > + This selects hardware reset support for the SD8787 BT + Wifi > + module. By default this option is set to n. > + > + This driver can also be built as a module. If so, the module > + will be called pwrseq_sd8787. > + > config PWRSEQ_SIMPLE > tristate "Simple HW reset support for MMC" > default y > diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile > index b2a257dc644f..0f81464fa824 100644 > --- a/drivers/mmc/core/Makefile > +++ b/drivers/mmc/core/Makefile > @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \ >quirks.o slot-gpio.o > mmc_core-$(CONFIG_OF) += pwrseq.o > obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o > +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o > obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o > mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o > obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o > -- > 2.10.2 >
[PATCH v2 1/2] devicetree: document vmmc-supply and mmc-pwrseq options
Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay
---
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
--
This node provides properties for controlling the Marvell SDIO/PCIE wireless
device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain
condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
[PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf Hansson Signed-off-by: Matt Ranostay --- drivers/mmc/core/Kconfig | 10 ++ drivers/mmc/core/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig index cdfa8520a4b1..fc1ecdaaa9ca 100644 --- a/drivers/mmc/core/Kconfig +++ b/drivers/mmc/core/Kconfig @@ -12,6 +12,16 @@ config PWRSEQ_EMMC This driver can also be built as a module. If so, the module will be called pwrseq_emmc. +config PWRSEQ_SD8787 + tristate "HW reset support for SD8787 BT + Wifi module" + depends on OF && (MWIFIEX || BT_MRVL_SDIO) + help + This selects hardware reset support for the SD8787 BT + Wifi + module. By default this option is set to n. + + This driver can also be built as a module. If so, the module + will be called pwrseq_sd8787. + config PWRSEQ_SIMPLE tristate "Simple HW reset support for MMC" default y diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile index b2a257dc644f..0f81464fa824 100644 --- a/drivers/mmc/core/Makefile +++ b/drivers/mmc/core/Makefile @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \ quirks.o slot-gpio.o mmc_core-$(CONFIG_OF) += pwrseq.o obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o -- 2.10.2
[PATCH v2 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Matt Ranostay (2): devicetree: document vmmc-supply and mmc-pwrseq options mmc: pwrseq: add support for Marvell SD8787 chip .../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++- drivers/mmc/core/Kconfig | 10 ++ drivers/mmc/core/Makefile | 1 + 3 files changed, 17 insertions(+), 1 deletion(-) -- 2.10.2
Re: [PATCH 2/2] printk: always report lost messages on serial console
Hi, On (01/11/17 17:50), Petr Mladek wrote: > Hi Sergey, > > first, thanks a lot for the detailed description. I have finally > understood what was important on the "non-important" messages > and how you used them. I am sorry that I was not able to get > it earlier. sure, no prob. I was mostly offline for the past few days for personal reasons but now I'm back. [..] > > now, if the loss of messages was caused by: > > > > a) flood of suppressed loglevel messages > >then printing at least some of those messages makes *a lot* of sense. > > > > b) flood of visible loglevel messages > >then may be those messages are not so important. there a whole logbuf of > >them. per my experience, it is quite hard to overflow the logbuf with > >really important, unique, sensible messages of 'visible' loglevel with > >active loglevel filtering. > > Just for record, I guess that the same is true also for the messages > with lower level. I mean that they are repeating as well. right. those are 100% reproducible, quick to spot and easy to fix, I guess. a spontaneous explosion is a different/bigger problem. though the end result is the same -- we lose messages, may be very important ones. our best effort/goal is to print logbuf content. that's why we are playing with nmi/safe printk; zap locks; ignore locks state in some cases; and so on and on. but when we lose messages that were meant to be printed even _before_ we try to print them out, then our best effort is sort of void/undefined. > It would be great to make it easier to throttle the same messages or > do it a generic way. But this a food for the future work. yes. syslog tracks "duplicate messages". but I kinda couldn't understand how helpful it will be in vprintk_emit() /* because it's too late to track duplicates in console_unlock(). duplicates should not be stored in multiple instances in the first place */. backtraces are hard to suppress, besides we shouldn't suppress backtraces I think. log_store() would have to strcmp() or "hash+compare hashes" current message and the most recent logbuf message. but bigger concern is -- do people see dropped messages that often to add duplicate messages tracker to vprintk_emit()? I see dropped messages quite a lot, but that's just my setup. > #define KERN_EMERGKERN_SOH "0"/* system is unusable */ > #define KERN_ALERTKERN_SOH "1"/* action must be taken immediately */ > #define KERN_CRIT KERN_SOH "2"/* critical conditions */ > #define KERN_ERR KERN_SOH "3"/* error conditions */ > > The flood of messages usually means something pretty wrong. But > it might also be caused by too many or forgotten debug messages. well. it's still really a lot of forgotten messages. so much that we have to drop other messages. so I'd say the root cause is less important (if important at all) as long as the result is "lost messages". > It think that lost messages belong to the level "2". Note that > the warning about lost NMI messages and recent printk recursion > were printed with loglevel '2' as well. > > Would it make sense and be acceptable to ignore the log level > only when console_level allows to show KERN_CRIT messages? need to think. what will it improve? // I'm catching up with the emails, it'll take some time. -ss
Re: [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
On 01/11/2017 06:39 AM, Uwe Kleine-König wrote: On Wed, Jan 11, 2017 at 01:31:47PM +0100, Marc Gonzalez wrote: On 11/01/2017 11:52, Guenter Roeck wrote: On 01/11/2017 01:07 AM, Marc Gonzalez wrote: @@ -134,12 +134,15 @@ static int tangox_wdt_probe(struct platform_device *pdev) err = clk_prepare_enable(dev->clk); if (err) return err; + err = devm_add_action_or_reset(&pdev->dev, + (void(*)(void *))clk_disable_unprepare, + dev->clk); + if (err) + return err; This looks wrong. There is no clk_unprepare_disable when devm_add_action_or_reset fails. Hello Guenter, I would rather avoid the function pointer cast. How about defining an auxiliary function for the cleanup action? clk_disable_unprepare() is static inline, so gcc will have to define an auxiliary function either way. What do you think? Not really. It would just make it more complicated to replace the call with devm_clk_prepare_enable(), should it ever find its way into the light of day. More complicated, because the cleanup function will have to be deleted later? The compiler will warn if someone forgets to do that. In my opinion, it's not a good idea to rely on the fact that casting void(*)(struct clk *clk) to void(*)(void *) is likely to work as expected on most platforms. (It has undefined behavior, strictly speaking.) I would expect it to work on all (Linux) platforms. Anyhow, I wonder if there couldn't be found a better solution. If in the end it looks like the following that would be good I think: clk = devm_clk_get(...); if (IS_ERR(clk)) ... ret = devm_clk_prepare_enable(clk) if (ret) return ret; It turns out that at least one static analyzer complains about different parameter pointer types in situations like this, and at least one embedded compiler manages to create function names with embedded parameter type (eg it appends an 'i' to the function name for each integer parameter). With that, I consider the typecast to be too risky after all. It may work for all of today's Linux architectures and compilers, but who knows if I get flooded with static analyzer warnings, and who knows if gcc version 18.0 or binutils 35.0 makes it truly incompatible (following the logic of "we can, therefore we do"). Since I also dislike the stub function solution, at least in this situation, I'll drop all patches touching clk_prepare_enable(), and wait for devm_clk_prepare_enable() to be available. Guenter
Re: x86-64: Maintain 16-byte stack alignment
On Thu, Jan 12, 2017 at 08:37:18PM -0800, Linus Torvalds wrote:
> On Jan 12, 2017 8:28 PM, "Josh Poimboeuf" wrote:
>
>
> The stack frame was always 16-byte aligned regardless of whether the
> buf array size was even or odd.
>
>
> Including with -fomit-frame-pointer?
>
> With frame pointers, stack frames really are naturally 16 bytes, and then
> keeping the frame 16-byte aligned is just a matter of making any extra
> frame allocations or push/pop sequences that you do also be a multiple of
> 16 bytes.
>
> But *without* frame pointers, the"native" frame size is just 8 bytes, and a
> function that doesn't need any other local storage and then calls another
> function (think various trivial wrapper functions that just add an argument
> and then munge the return value) would thus naturally cause the frame to
> become misaligned.
>
> So then the compiler actually needs to start adding useless instructions
> just to keep the stack 16-byte aligned.
Disabling frame pointers didn't seem to help, but I finally got it to
misalign with a different test case. I think it had been aligning the
array, so instead I made it push a register.
void otherfunc(void);
static inline void bar(int f)
{
register void *__sp asm(_ASM_SP);
asm volatile("call otherfunc" : "+r" (__sp) : "b"(f));
}
void foo(void)
{
bar(5);
}
20f0 :
20f0: 55 push %rbp
20f1: 48 89 e5mov%rsp,%rbp
20f4: 53 push %rbx
20f5: bb 05 00 00 00 mov$0x5,%ebx
20fa: e8 00 00 00 00 callq 20ff
20fb: R_X86_64_PC32 otherfunc-0x4
20ff: 5b pop%rbx
2100: 5d pop%rbp
2101: c3 retq
2102: 0f 1f 40 00 nopl 0x0(%rax)
2106: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
210d: 00 00 00
--
Josh
Re: [PATCH v4 07/15] lockdep: Implement crossrelease feature
On Fri, Jan 13, 2017 at 12:39:04PM +0800, Lai Jiangshan wrote:
> > +
> > +/*
> > + * No contention. Irq disable is only required.
> > + */
> > +static int same_context_plock(struct pend_lock *plock)
> > +{
> > + struct task_struct *curr = current;
> > + int cpu = smp_processor_id();
> > +
> > + /* In the case of hardirq context */
> > + if (curr->hardirq_context) {
> > + if (plock->hardirq_id != per_cpu(hardirq_id, cpu) ||
> > + plock->hardirq_context != curr->hardirq_context)
> > + return 0;
> > + /* In the case of softriq context */
> > + } else if (curr->softirq_context) {
> > + if (plock->softirq_id != per_cpu(softirq_id, cpu) ||
> > + plock->softirq_context != curr->softirq_context)
> > + return 0;
> > + /* In the case of process context */
> > + } else {
> > + if (plock->hardirq_context != 0 ||
> > + plock->softirq_context != 0)
> > + return 0;
> > + }
> > + return 1;
> > +}
> >
>
> I have not read the code yet...
> but different work functions in workqueues are different "contexts" IMO,
> does commit operation work well in work functions?
Hello,
Yes. I also think it should be considered since each work might be run in
different context from another, thanks to concurrency support of workqueue.
I will reflect it.
Thanks,
Byungchul
Re: eMMC boot problem: switch to bus width 8 ddr failed
Hi Shawn, On Fri, Jan 13, 2017 at 12:03 PM, Shawn Lin wrote: [...] > >> 2) root cause, in __mmc_switch, the process is send CMD6 --> set DDR52 >> timing --> polling for busy. >> For the DDR52 timing setting, we call set_ios(), in the set_ios, we first >> set DDR_EN to config sdhc in ddr mode, >> and then config the sd clock again. Here it is, after CMD6 complete, we >> find data0 still low, which means card >> busy. At this time, if we set DDR_EN, there is a risk. For i.MX usdhc, >> DDR_EN setting becomes active only when >> the DATA and CMD line are idle. So, at this time for HW, DDR_EN do not >> active, but software think DDR_EN already >> active, and set the clock again to 49.5MHz, but actually the HW out put >> the clock as 198MHz. So there is clock glitch. >> This is the root cause--set DDR_EN when card is still busy. >> > > Make sense. But it makes me more worried about the problem. > Does it impact other controllers if changing timing settings when > it's in busy state? It seems very likely possible. So I'm afraid > that we now just break hs_ddr mode for your platform but on the > contrary your case exposes this potention risk here. Thought? > Yes, i got the same concern as i replied in my last email. Not sure if any other controllers exposes the same issue since the kernel having this issue is quite new. Regards Dong Aisheng >> The following method can fix this issue >> a) change the HW behavior, DDR_EN setting becomes active at once no matter >> what the state of the DATA and >> CMD line are. This can fix this issue, but our IC guys do not prefer >> this, this method still not safe enough. >> >> b) add 1ms delay before DDR_EN to wait bus idle. But we still not know >> whether the time 1ms is appropriate. Better >> to poll for busy before set DDR_EN. >> >> c) set DDR52 timing after CMD6 and pull for busy. This is what Shawn's >> patch do. >> >> Hi Aisheng, >> Correct me if anything wrong. >> >> My suggestion is that, in __mmc_switch(), move the mmc_set_timing() after >> the function mmc_poll_for_busy(). >> >> >> Best Regards >> Haibo Chen >> >> >> if that can be done. So I will give Haibo/Dong etc a couple of more days to investigate, before applying Shawn Lin's fix for the core. Hope that approach is okay with all of you? Kind regards Uffe >>> >>> >>> -- >>> Best Regards >>> Shawn Lin >> >> > > > -- > Best Regards > Shawn Lin > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: eMMC boot problem: switch to bus width 8 ddr failed
On Fri, Jan 13, 2017 at 11:12 AM, Bough Chen wrote:
>> -Original Message-
>> From: Shawn Lin [mailto:shawn@rock-chips.com]
>> Sent: Friday, January 13, 2017 10:11 AM
>> To: Ulf Hansson ; Clemens Gruber
>>
>> Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
>> ; Adrian Hunter ; A.S.
>> Dong ; linux-kernel@vger.kernel.org; Bough Chen
>> ; Gary Bisson ;
>> Fabio Estevam ; Shawn Guo
>> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
>>
>> On 2017/1/13 0:51, Ulf Hansson wrote:
>> > + Haibo, Gary, Fabio, Shawn Gou
>> >
>> > On 6 January 2017 at 16:56, Clemens Gruber
>> wrote:
>> >> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
>> >>> On 2017/1/6 8:41, Clemens Gruber wrote:
>> Hi,
>>
>> with the current mainline 4.10-rc2 kernel, I can no longer boot
>> from the eMMC on my i.MX6Q board.
>>
>> Details:
>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
>> supports eMMC 4.41 features and we did not implement voltage
>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
>> of the mmc-ddr or mmc-hs
>> options) to the device tree. The bus-width is 8.
>>
>> With 4.9 the board booted fine, now with the current mainline 4.10
>> tree, I get the following (repeating) errors at boot:
>>
>> [4.326834] Waiting for root device /dev/mmcblk0p2...
>> [ 14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>> [ 14.569619] sdhci: === REGISTER DUMP
>> (mmc0)===
>> [ 14.575461] sdhci: Sys addr: 0x4e726000 | Version: 0x0002
>> [ 14.581300] sdhci: Blk size: 0x0200 | Blk cnt: 0x0001
>> [ 14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> [ 14.592979] sdhci: Present: 0x01fd8009 | Host ctl: 0x0031
>> [ 14.598816] sdhci: Power:0x0002 | Blk gap: 0x0080
>> [ 14.604654] sdhci: Wake-up: 0x0008 | Clock:0x001f
>> [ 14.610493] sdhci: Timeout: 0x008f | Int stat: 0x
>> [ 14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> [ 14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>> [ 14.628007] sdhci: Caps: 0x07eb | Caps_1: 0xa007
>> [ 14.633845] sdhci: Cmd: 0x0d1a | Max curr: 0x00ff
>> >>>
>> >>> it shows you always fail to get resp of sending status within the
>> >>> expected period of time.
>> >>>
>> >>>
>> [ 14.639682] sdhci: Host ctl2: 0x
>> [ 14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>> [ 14.649447] sdhci:
>> ===
>>
>> This repeats a few times, then more information is shown at the bottom:
>>
>> [ 86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>> [ 86.899615] sdhci: === REGISTER DUMP
>> (mmc0)===
>> [ 86.905453] sdhci: Sys addr: 0x | Version: 0x0002
>> [ 86.911291] sdhci: Blk size: 0x0200 | Blk cnt: 0x0001
>> [ 86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> [ 86.922967] sdhci: Present: 0x01fd8009 | Host ctl: 0x0031
>> [ 86.928804] sdhci: Power:0x0002 | Blk gap: 0x0080
>> [ 86.934642] sdhci: Wake-up: 0x0008 | Clock:0x001f
>> [ 86.940479] sdhci: Timeout: 0x008f | Int stat: 0x
>> [ 86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> [ 86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>> [ 86.957992] sdhci: Caps: 0x07eb | Caps_1: 0xa007
>> [ 86.963830] sdhci: Cmd: 0x0d1a | Max curr: 0x00ff
>> [ 86.969668] sdhci: Host ctl2: 0x
>> [ 86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>> [ 86.979433] sdhci:
>> ===
>> [ 86.986356] mmc0: switch to bus width 8 ddr failed
>> [ 86.991163] mmc0: error -110 whilst initialising MMC card
>> [ 97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>>
>> --
>>
>> After looking through the latest commits to mmc/core, I found the
>> culprit:
>> Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core:
>> Update
>> CMD13 polling policy when switch to HS DDR mode")
>>
>> Reverting it fixes the problem. But I am unsure if that's the right
>> course of action?
>>
>> Feel free to send me patches for testing!
>> >>>
>> >>> By looking the changes itself, it should be good from the view of spec.
>> >>> Maybe you could try the patch below, but don't beat me if that
>> >>> doesn't help at all. :)
>> >>>
>> >>> --- a/drivers/mmc/core/mmc.c
>> >>> +++ b/drivers/mmc/core/mmc.c
>> >>> @@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card
>> *card)
>> >>>EXT_C
Re: [PATCH v4 07/15] lockdep: Implement crossrelease feature
> +
> +/*
> + * No contention. Irq disable is only required.
> + */
> +static int same_context_plock(struct pend_lock *plock)
> +{
> + struct task_struct *curr = current;
> + int cpu = smp_processor_id();
> +
> + /* In the case of hardirq context */
> + if (curr->hardirq_context) {
> + if (plock->hardirq_id != per_cpu(hardirq_id, cpu) ||
> + plock->hardirq_context != curr->hardirq_context)
> + return 0;
> + /* In the case of softriq context */
> + } else if (curr->softirq_context) {
> + if (plock->softirq_id != per_cpu(softirq_id, cpu) ||
> + plock->softirq_context != curr->softirq_context)
> + return 0;
> + /* In the case of process context */
> + } else {
> + if (plock->hardirq_context != 0 ||
> + plock->softirq_context != 0)
> + return 0;
> + }
> + return 1;
> +}
>
I have not read the code yet...
but different work functions in workqueues are different "contexts" IMO,
does commit operation work well in work functions?
Re: [PATCH] lockdep: Make a stack_trace instance passed to check_prev_add as an arg
On Fri, Jan 13, 2017 at 01:09:41PM +0900, Byungchul Park wrote:
> Like this. Right?
Ignore this. We need to make save_trace work in different way first.
>
> ->8-
> >From c6173f29ff9bf801649f3cbeb80a914fdf1b998b Mon Sep 17 00:00:00 2001
> From: Byungchul Park
> Date: Fri, 13 Jan 2017 12:02:02 +0900
> Subject: [PATCH] lockdep: Make a stack_trace instance passed to check_prev_add
> as an arg
>
> Saving stack_trace within check_prev_add needs many tricky codes. To
> avoid these, this patch makes the stack_trace instance created out of
> check_prev_add, but by caller and passed as an argument.
>
> Signed-off-by: Byungchul Park
> ---
> kernel/locking/lockdep.c | 30 +-
> 1 file changed, 9 insertions(+), 21 deletions(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 2081c31..049fc71 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -1797,20 +1797,13 @@ static inline void inc_chains(void)
> */
> static int
> check_prev_add(struct task_struct *curr, struct held_lock *prev,
> -struct held_lock *next, int distance, int *stack_saved)
> +struct held_lock *next, int distance,
> +struct stack_trace *trace)
> {
> struct lock_list *entry;
> int ret;
> struct lock_list this;
> struct lock_list *uninitialized_var(target_entry);
> - /*
> - * Static variable, serialized by the graph_lock().
> - *
> - * We use this static variable to save the stack trace in case
> - * we call into this function multiple times due to encountering
> - * trylocks in the held lock stack.
> - */
> - static struct stack_trace trace;
>
> /*
>* Prove that the new -> dependency would not
> @@ -1858,26 +1851,20 @@ static inline void inc_chains(void)
> }
> }
>
> - if (!*stack_saved) {
> - if (!save_trace(&trace))
> - return 0;
> - *stack_saved = 1;
> - }
> -
> /*
>* Ok, all validations passed, add the new lock
>* to the previous lock's dependency list:
>*/
> ret = add_lock_to_list(hlock_class(prev), hlock_class(next),
> &hlock_class(prev)->locks_after,
> -next->acquire_ip, distance, &trace);
> +next->acquire_ip, distance, trace);
>
> if (!ret)
> return 0;
>
> ret = add_lock_to_list(hlock_class(next), hlock_class(prev),
> &hlock_class(next)->locks_before,
> -next->acquire_ip, distance, &trace);
> +next->acquire_ip, distance, trace);
> if (!ret)
> return 0;
>
> @@ -1885,8 +1872,6 @@ static inline void inc_chains(void)
>* Debugging printouts:
>*/
> if (verbose(hlock_class(prev)) || verbose(hlock_class(next))) {
> - /* We drop graph lock, so another thread can overwrite trace. */
> - *stack_saved = 0;
> graph_unlock();
> printk("\n new dependency: ");
> print_lock_name(hlock_class(prev));
> @@ -1909,8 +1894,8 @@ static inline void inc_chains(void)
> check_prevs_add(struct task_struct *curr, struct held_lock *next)
> {
> int depth = curr->lockdep_depth;
> - int stack_saved = 0;
> struct held_lock *hlock;
> + struct stack_trace trace;
>
> /*
>* Debugging checks.
> @@ -1927,6 +1912,9 @@ static inline void inc_chains(void)
> curr->held_locks[depth-1].irq_context)
> goto out_bug;
>
> + if (!save_trace(&trace))
> + return 0;
> +
> for (;;) {
> int distance = curr->lockdep_depth - depth + 1;
> hlock = curr->held_locks + depth - 1;
> @@ -1936,7 +1924,7 @@ static inline void inc_chains(void)
>*/
> if (hlock->read != 2 && hlock->check) {
> if (!check_prev_add(curr, hlock, next,
> - distance, &stack_saved))
> + distance, &trace))
> return 0;
> /*
>* Stop after the first non-trylock entry,
> --
> 1.9.1
Re: getting oom/stalls for ltp test cpuset01 with latest/4.9 kernel
On Thu, Jan 12, 2017 at 4:40 PM, Vlastimil Babka wrote: > On 01/11/2017 05:46 PM, Michal Hocko wrote: >> >> On Wed 11-01-17 21:52:29, Ganapatrao Kulkarni wrote: >> >>> [ 2398.169391] Node 1 Normal: 951*4kB (UME) 1308*8kB (UME) 1034*16kB >>> (UME) 742*32kB (UME) 581*64kB (UME) 450*128kB (UME) 362*256kB (UME) >>> 275*512kB (ME) 189*1024kB (UM) 117*2048kB (ME) 2742*4096kB (M) = 12047196kB >> >> >> Most of the memblocks are marked Unmovable (except for the 4MB bloks) > > > No, UME here means that e.g. 4kB blocks are available on unmovable, movable > and reclaimable lists. > >> which shouldn't matter because we can fallback to unmovable blocks for >> movable allocation AFAIR so we shouldn't really fail the request. I >> really fail to see what is going on there but it smells really >> suspicious. > > > Perhaps there's something wrong with zonelists and we are skipping the Node > 1 Normal zone. Or there's some race with cpuset operations (but can't see > how). > > The question is, how reproducible is this? And what exactly the test > cpuset01 does? Is it doing multiple things in a loop that could be reduced > to a single testcase? IIUC, this test does node change to cpuset.mems in loop in parent process in loop and child processes(equal to no of cpus) keeps on allocation and freeing 10 pages till the execution time is over. more details at https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/cpuset/cpuset01.c thanks Ganapat > >
RE: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
Hi Vinod, Thanks for the review... > > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote: > > Add channel idle state to ensure that dma descriptor is not > > submitted when VDMA engine is in progress. > > any reason why you want to make your own varible and not use the HW to > query > as done earlier. It is not clear to me why that is removed from description We need to poll for a bit in the status register to know the dma state. We are currently doing that in the driver hot path To avoid this using own variables. Regards, Kedar.
Re: x86-64: Maintain 16-byte stack alignment
On Thu, Jan 12, 2017 at 07:23:18PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 12, 2017 at 7:11 PM, Josh Poimboeuf wrote:
> > On Thu, Jan 12, 2017 at 05:46:55PM -0800, Andy Lutomirski wrote:
> >> On Thu, Jan 12, 2017 at 12:15 PM, Josh Poimboeuf
> >> wrote:
> >> > On Thu, Jan 12, 2017 at 12:08:07PM -0800, Andy Lutomirski wrote:
> >> >> On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds
> >> >> wrote:
> >> >> > On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf
> >> >> > wrote:
> >> >> >>
> >> >> >> Just to clarify, I think you're asking if, for versions of gcc which
> >> >> >> don't support -mpreferred-stack-boundary=3, objtool can analyze all C
> >> >> >> functions to ensure their stacks are 16-byte aligned.
> >> >> >>
> >> >> >> It's certainly possible, but I don't see how that solves the problem.
> >> >> >> The stack will still be misaligned by entry code. Or am I missing
> >> >> >> something?
> >> >> >
> >> >> > I think the argument is that we *could* try to align things, if we
> >> >> > just had some tool that actually then verified that we aren't missing
> >> >> > anything.
> >> >> >
> >> >> > I'm not entirely happy with checking the generated code, though,
> >> >> > because as Ingo says, you have a 50:50 chance of just getting it right
> >> >> > by mistake. So I'd much rather have some static tool that checks
> >> >> > things at a code level (ie coccinelle or sparse).
> >> >>
> >> >> What I meant was checking the entry code to see if it aligns stack
> >> >> frames, and good luck getting sparse to do that. Hmm, getting 16-byte
> >> >> alignment for real may actually be entirely a lost cause. After all,
> >> >> I think we have some inline functions that do asm volatile ("call
> >> >> ..."), and I don't see any credible way of forcing alignment short of
> >> >> generating an entirely new stack frame and aligning that.
> >> >
> >> > Actually we already found all such cases and fixed them by forcing a new
> >> > stack frame, thanks to objtool. For example, see 55a76b59b5fe.
> >>
> >> What I mean is: what guarantees that the stack is properly aligned for
> >> the subroutine call? gcc promises to set up a stack frame, but does
> >> it promise that rsp will be properly aligned to call a C function?
> >
> > Yes, I did an experiment and you're right. I had naively assumed that
> > all stack frames would be aligned.
>
> Just to check: did you do your experiment with -mpreferred-stack-boundary=4?
Yes, but it's too late for me to be doing hard stuff and I think my
first experiment was bogus. I didn't use all the other kernel-specific
gcc options.
I tried again with all the kernel gcc options, except with
-mpreferred-stack-boundary=4 instead of 3, and actually came up with the
opposite conclusion.
I used the following code:
void otherfunc(void);
static inline void bar(long *f)
{
asm volatile("call otherfunc" : : "m" (f) : );
}
void foo(void)
{
long buf[3] = {0, 0, 0};
bar(buf);
}
The stack frame was always 16-byte aligned regardless of whether the
buf array size was even or odd.
So my half-asleep brain is telling me that my original assumption was
right.
--
Josh
Re: [PATCH] mm: extend zero pages to same element pages for zram
Hello,
sorry, was mostly offline for the past few days, now catching up.
On (01/10/17 08:41), Minchan Kim wrote:
> > the idea is that without doing more calculations we extend zero pages
> > to same element pages for zram. zero page is special case of
> > same element page with zero element.
> >
interesting idea.
[..]
> > flush_dcache_page(page);
> > @@ -431,7 +479,7 @@ static ssize_t mm_stat_show(struct device *dev,
> > mem_used << PAGE_SHIFT,
> > zram->limit_pages << PAGE_SHIFT,
> > max_used << PAGE_SHIFT,
> > - (u64)atomic64_read(&zram->stats.zero_pages),
> > + (u64)atomic64_read(&zram->stats.same_pages),
>
> Unfortunately, we cannot replace zero pages stat with same pages's one right
> now due to compatibility problem. Please add same_pages to tail of the stat
> and we should warn deprecated zero_pages stat so we finally will remove it
> two year later. Please reference Documentation/ABI/obsolete/sysfs-block-zram
> And add zero-pages to the document.
>
> For example,
>
> ... mm_stat_show()
> {
> pr_warn_once("zero pages was deprecated so it will be removed at 2019
> Jan");
> }
>
> Sergey, what's your opinion?
oh, I was going to ask you whether you have any work in progress at
the moment or not. because deprecated attrs are scheduled to be removed
in 4.11. IOW, we must send the clean up patch, well, right now. so I can
prepare the patch, but it can conflict with someone's 'more serious/relevant'
work.
we also have zram hot/addd sysfs attr, which must be deprecated and
converted to a char device. per Greg KH.
> Please add same_pages to tail of the stat
sounds ok to me. and yes, can deprecate zero_pages.
seems that with that patch the concept of ZRAM_ZERO disappears. both
ZERO and SAME_ELEMENT pages are considered to be the same thing now.
which is fine and makes sense to me, I think. and if ->.same_pages will
replace ->.zero_pages in mm_stat() then I'm also OK. yes, we will see
increased number in the last column of mm_stat file, but I don't tend
to see any issues here. Minchan, what do you think?
> -ZRAM_ATTR_RO(zero_pages);
> +ZRAM_ATTR_RO(same_pages);
this part is a no-no-no-no :) we can't simply rename the user space
visible attrs.
-ss
Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points
On 01/05/2017 11:31 PM, Eric Ren wrote:
> Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
> results in a deadlock, as the author "Tariq Saeed" realized shortly
> after the patch was merged. The discussion happened here
> (https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html).
>
> The reason why taking cluster inode lock at vfs entry points opens up
> a self deadlock window, is explained in the previous patch of this
> series.
>
> So far, we have seen two different code paths that have this issue.
> 1. do_sys_open
> may_open
> inode_permission
>ocfs2_permission
> ocfs2_inode_lock() <=== take PR
> generic_permission
> get_acl
>ocfs2_iop_get_acl
> ocfs2_inode_lock() <=== take PR
> 2. fchmod|fchmodat
> chmod_common
> notify_change
> ocfs2_setattr <=== take EX
>posix_acl_chmod
> get_acl
> ocfs2_iop_get_acl <=== take PR
> ocfs2_iop_set_acl <=== take EX
>
> Fixes them by adding the tracking logic (in the previous patch) for
> these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
> ocfs2_setattr().
>
> Signed-off-by: Eric Ren
> ---
> fs/ocfs2/acl.c | 39 ++-
> fs/ocfs2/file.c | 44 ++--
> 2 files changed, 68 insertions(+), 15 deletions(-)
>
> diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
> index bed1fcb..c539890 100644
> --- a/fs/ocfs2/acl.c
> +++ b/fs/ocfs2/acl.c
> @@ -284,16 +284,31 @@ int ocfs2_iop_set_acl(struct inode *inode, struct
> posix_acl *acl, int type)
> {
> struct buffer_head *bh = NULL;
> int status = 0;
> -
> - status = ocfs2_inode_lock(inode, &bh, 1);
> + int arg_flags = 0, has_locked;
> + struct ocfs2_holder oh;
> + struct ocfs2_lock_res *lockres;
> +
> + lockres = &OCFS2_I(inode)->ip_inode_lockres;
> + has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
> + if (has_locked)
> + arg_flags = OCFS2_META_LOCK_GETBH;
> + status = ocfs2_inode_lock_full(inode, &bh, 1, arg_flags);
> if (status < 0) {
> if (status != -ENOENT)
> mlog_errno(status);
> return status;
> }
> + if (!has_locked)
> + ocfs2_add_holder(lockres, &oh);
> +
> status = ocfs2_set_acl(NULL, inode, bh, type, acl, NULL, NULL);
> - ocfs2_inode_unlock(inode, 1);
> +
> + if (!has_locked) {
> + ocfs2_remove_holder(lockres, &oh);
> + ocfs2_inode_unlock(inode, 1);
> + }
> brelse(bh);
> +
> return status;
> }
>
> @@ -303,21 +318,35 @@ struct posix_acl *ocfs2_iop_get_acl(struct inode
> *inode, int type)
> struct buffer_head *di_bh = NULL;
> struct posix_acl *acl;
> int ret;
> + int arg_flags = 0, has_locked;
> + struct ocfs2_holder oh;
> + struct ocfs2_lock_res *lockres;
>
> osb = OCFS2_SB(inode->i_sb);
> if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
> return NULL;
> - ret = ocfs2_inode_lock(inode, &di_bh, 0);
> +
> + lockres = &OCFS2_I(inode)->ip_inode_lockres;
> + has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
> + if (has_locked)
> + arg_flags = OCFS2_META_LOCK_GETBH;
> + ret = ocfs2_inode_lock_full(inode, &di_bh, 0, arg_flags);
> if (ret < 0) {
> if (ret != -ENOENT)
> mlog_errno(ret);
> return ERR_PTR(ret);
> }
> + if (!has_locked)
> + ocfs2_add_holder(lockres, &oh);
>
> acl = ocfs2_get_acl_nolock(inode, type, di_bh);
>
> - ocfs2_inode_unlock(inode, 0);
> + if (!has_locked) {
> + ocfs2_remove_holder(lockres, &oh);
> + ocfs2_inode_unlock(inode, 0);
> + }
> brelse(di_bh);
> +
> return acl;
> }
>
> diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
> index c488965..62be75d 100644
> --- a/fs/ocfs2/file.c
> +++ b/fs/ocfs2/file.c
> @@ -1138,6 +1138,9 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr
> *attr)
> handle_t *handle = NULL;
> struct dquot *transfer_to[MAXQUOTAS] = { };
> int qtype;
> + int arg_flags = 0, had_lock;
> + struct ocfs2_holder oh;
> + struct ocfs2_lock_res *lockres;
>
> trace_ocfs2_setattr(inode, dentry,
> (unsigned long long)OCFS2_I(inode)->ip_blkno,
> @@ -1173,13 +1176,20 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr
> *attr)
> }
> }
>
> - status = ocfs2_inode_lock(inode, &bh, 1);
> + lockres = &OCFS2_I(inode)->ip_inode_lockres;
> + had_lock = (ocfs2_is_locked_by_me(lockres) != NULL);
If had_lock==true, it is a bug? I think we should BUG_ON for it, that
can help us catch bug at the first time.
> + if (had_lock)
> + arg_flags = OCFS2_META_LOCK_GETBH;
> + status = ocfs2_inode_lock_full(inode, &bh, 1, arg_flags);
>
[RFC/PATCH] ftrace: Allow to change size of function graph filters
It's currently fixed to 32 and it ignores when user gives a pattern
which match to functions more than the size. So filtering like all
system calls or many functions with common prefix cannot be set all.
Not sure this is right though.
This patch adds 'graph_filter_size' file in the tracefs to adjust the
size. It can be changed only if the current tracer is not set.
Signed-off-by: Namhyung Kim
---
kernel/trace/ftrace.c | 151 +++---
kernel/trace/trace.c | 8 +++
kernel/trace/trace.h | 9 ++-
3 files changed, 157 insertions(+), 11 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 356bb70d071e..f8440b2bf546 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4525,8 +4525,11 @@ static DEFINE_MUTEX(graph_lock);
int ftrace_graph_count;
int ftrace_graph_notrace_count;
-unsigned long ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
-unsigned long ftrace_graph_notrace_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
+int ftrace_graph_funcs_size = FTRACE_GRAPH_MAX_FUNCS;
+unsigned long __ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
+unsigned long __ftrace_graph_notrace_funcs[FTRACE_GRAPH_MAX_FUNCS]
__read_mostly;
+unsigned long *ftrace_graph_funcs = __ftrace_graph_funcs;
+unsigned long *ftrace_graph_notrace_funcs = __ftrace_graph_notrace_funcs;
struct ftrace_graph_data {
unsigned long *table;
@@ -4558,6 +4561,12 @@ static void *g_start(struct seq_file *m, loff_t *pos)
mutex_lock(&graph_lock);
+ /* it might be changed, reload the pointers */
+ if (fgd->count == &ftrace_graph_count)
+ fgd->table = ftrace_graph_funcs;
+ else
+ fgd->table = ftrace_graph_notrace_funcs;
+
/* Nothing, tell g_show to print all functions are enabled */
if (!*fgd->count && !*pos)
return (void *)1;
@@ -4605,13 +4614,11 @@ __ftrace_graph_open(struct inode *inode, struct file
*file,
{
int ret = 0;
- mutex_lock(&graph_lock);
if ((file->f_mode & FMODE_WRITE) &&
(file->f_flags & O_TRUNC)) {
*fgd->count = 0;
memset(fgd->table, 0, fgd->size * sizeof(*fgd->table));
}
- mutex_unlock(&graph_lock);
if (file->f_mode & FMODE_READ) {
ret = seq_open(file, fgd->seq_ops);
@@ -4629,6 +4636,7 @@ static int
ftrace_graph_open(struct inode *inode, struct file *file)
{
struct ftrace_graph_data *fgd;
+ int ret;
if (unlikely(ftrace_disabled))
return -ENODEV;
@@ -4637,18 +4645,26 @@ ftrace_graph_open(struct inode *inode, struct file
*file)
if (fgd == NULL)
return -ENOMEM;
+ mutex_lock(&graph_lock);
+
fgd->table = ftrace_graph_funcs;
- fgd->size = FTRACE_GRAPH_MAX_FUNCS;
+ fgd->size = ftrace_graph_funcs_size;
fgd->count = &ftrace_graph_count;
fgd->seq_ops = &ftrace_graph_seq_ops;
- return __ftrace_graph_open(inode, file, fgd);
+ ret = __ftrace_graph_open(inode, file, fgd);
+ if (ret < 0)
+ kfree(fgd);
+
+ mutex_unlock(&graph_lock);
+ return ret;
}
static int
ftrace_graph_notrace_open(struct inode *inode, struct file *file)
{
struct ftrace_graph_data *fgd;
+ int ret;
if (unlikely(ftrace_disabled))
return -ENODEV;
@@ -4657,12 +4673,19 @@ ftrace_graph_notrace_open(struct inode *inode, struct
file *file)
if (fgd == NULL)
return -ENOMEM;
+ mutex_lock(&graph_lock);
+
fgd->table = ftrace_graph_notrace_funcs;
- fgd->size = FTRACE_GRAPH_MAX_FUNCS;
+ fgd->size = ftrace_graph_funcs_size;
fgd->count = &ftrace_graph_notrace_count;
fgd->seq_ops = &ftrace_graph_seq_ops;
- return __ftrace_graph_open(inode, file, fgd);
+ ret = __ftrace_graph_open(inode, file, fgd);
+ if (ret < 0)
+ kfree(fgd);
+
+ mutex_unlock(&graph_lock);
+ return ret;
}
static int
@@ -4767,6 +4790,13 @@ ftrace_graph_write(struct file *file, const char __user
*ubuf,
mutex_lock(&graph_lock);
+ /* it might be changed, reload the pointers */
+ if (fgd->count == &ftrace_graph_count)
+ fgd->table = ftrace_graph_funcs;
+ else
+ fgd->table = ftrace_graph_notrace_funcs;
+ fgd->size = ftrace_graph_funcs_size;
+
/* we allow only one expression at a time */
ret = ftrace_set_func(fgd->table, fgd->count, fgd->size,
parser.buffer);
@@ -4782,6 +4812,102 @@ ftrace_graph_write(struct file *file, const char __user
*ubuf,
return ret;
}
+static ssize_t
+ftrace_graph_funcs_size_read(struct file *filp, char __user *ubuf,
+size_t cnt, loff_t *ppos)
+{
+ char buf[64
[PATCH V2 4/6] gpio: davinci: Add support for multiple GPIO controllers
Update GPIO driver to support Multiple GPIO controllers by updating
the base of subsequent GPIO chips with total of previous chips
gpio count so that gpio_add_chip gets unique numbers.
Signed-off-by: Keerthy
---
drivers/gpio/gpio-davinci.c| 4 +++-
include/linux/platform_data/gpio-davinci.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index a527e88..2a5ae04 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -186,7 +186,7 @@ static int davinci_gpio_of_xlate(struct gpio_chip *gc,
static int davinci_gpio_probe(struct platform_device *pdev)
{
- static int ctrl_num;
+ static int ctrl_num, bank_base;
int gpio, bank;
unsigned ngpio, nbank;
struct davinci_gpio_controller *chips;
@@ -240,6 +240,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
chips->chip.set = davinci_gpio_set;
chips->chip.ngpio = ngpio;
+ chips->chip.base = bank_base;
#ifdef CONFIG_OF_GPIO
chips->chip.of_gpio_n_cells = 2;
@@ -248,6 +249,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
chips->chip.of_node = dev->of_node;
#endif
spin_lock_init(&chips->lock);
+ bank_base += ngpio;
for (gpio = 0, bank = 0; gpio < ngpio; gpio += 32, bank++)
chips->regs[bank] = gpio_base + offset_array[bank];
diff --git a/include/linux/platform_data/gpio-davinci.h
b/include/linux/platform_data/gpio-davinci.h
index c62a943..90ae19c 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -42,6 +42,7 @@ struct davinci_gpio_controller {
void __iomem*regs[MAX_REGS_BANKS];
int gpio_unbanked;
unsigned intbase_irq;
+ unsigned intbase;
};
/*
--
1.9.1
[PATCH V2 0/6] gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip
The Davinci GPIO driver is implemented to work with one monolithic Davinci GPIO platform device which may have up to Y(144) gpios. The Davinci GPIO driver instantiates number of GPIO chips with max 32 gpio pins per each during initialization and one IRQ domain. So, the current GPIO's opjects structure is: Davinci GPIO controller |- --| ...|--- irq_domain (hwirq [0..143]) |- --| Current driver creates one chip for every 32 GPIOs in a controller. This was a limitation earlier now there is no need for that. Hence redesigning the driver to create one gpio chip for all the ngpio in the controller. |- --|--- irq_domain (hwirq [0..143]). The previous discussion on this can be found here: https://www.spinics.net/lists/linux-omap/msg132869.html The series is posted on top of: https://lkml.org/lkml/2017/1/4/94 Changes in v2: * Optimized the re-design patch. * Added couple of code clean ups after the re-design. * Included v2 of https://patchwork.ozlabs.org/patch/710855/ Keerthy (6): gpio: davinci: Remove gpio2regs function to accommodate multi instances gpio: davinci: Remove unwanted blank line gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip gpio: davinci: Add support for multiple GPIO controllers gpio: davinci: Remove custom .xlate gpio: davinci: Remove redundant macros drivers/gpio/gpio-davinci.c| 174 + include/linux/platform_data/gpio-davinci.h | 20 ++-- 2 files changed, 90 insertions(+), 104 deletions(-) -- 1.9.1
[PATCH V2 6/6] gpio: davinci: Remove redundant macros
Some of the macros were needed as per old driver design.
With the current implementation they are unwanted. Hence remove
them.
Signed-off-by: Keerthy
---
include/linux/platform_data/gpio-davinci.h | 8
1 file changed, 8 deletions(-)
diff --git a/include/linux/platform_data/gpio-davinci.h
b/include/linux/platform_data/gpio-davinci.h
index 90ae19c..f922601 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -45,14 +45,6 @@ struct davinci_gpio_controller {
unsigned intbase;
};
-/*
- * basic gpio routines
- */
-#defineGPIO(X) (X) /* 0 <= X <= (DAVINCI_N_GPIO - 1) */
-
-/* Convert GPIO signal to GPIO pin number */
-#define GPIO_TO_PIN(bank, gpio)(16 * (bank) + (gpio))
-
static inline u32 __gpio_mask(unsigned gpio)
{
return 1 << (gpio % 32);
--
1.9.1
[PATCH V2 3/6] gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip
The Davinci GPIO driver is implemented to work with one monolithic
Davinci GPIO platform device which may have up to Y(144) gpios.
The Davinci GPIO driver instantiates number of GPIO chips with
max 32 gpio pins per each during initialization and one IRQ domain.
So, the current GPIO's opjects structure is:
Davinci GPIO controller
|- --|
...|--- irq_domain (hwirq [0..143])
|- --|
Current driver creates one chip for every 32 GPIOs in a controller.
This was a limitation earlier now there is no need for that. Hence
redesigning the driver to create one gpio chip for all the ngpio
in the controller.
|- --|--- irq_domain (hwirq [0..143]).
The previous discussion on this can be found here:
https://www.spinics.net/lists/linux-omap/msg132869.html
Signed-off-by: Keerthy
---
Changes in v2:
* Optimized irqdata allocation logic to use a single pointer
instead of array of pointers.
* Removed a redundant Macro.
* Used __gpio_mask instead of hardcoding every single time.
* MAX_BANKS changed to MAX_REGS_BANKS
drivers/gpio/gpio-davinci.c| 127 +
include/linux/platform_data/gpio-davinci.h | 12 ++-
2 files changed, 83 insertions(+), 56 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index bb47de3..a527e88 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -63,11 +63,13 @@ static inline int __davinci_direction(struct gpio_chip
*chip,
unsigned offset, bool out, int value)
{
struct davinci_gpio_controller *d = gpiochip_get_data(chip);
- struct davinci_gpio_regs __iomem *g = d->regs;
+ struct davinci_gpio_regs __iomem *g;
unsigned long flags;
u32 temp;
- u32 mask = 1 << offset;
+ int bank = offset / 32;
+ u32 mask = __gpio_mask(offset);
+ g = d->regs[bank];
spin_lock_irqsave(&d->lock, flags);
temp = readl_relaxed(&g->dir);
if (out) {
@@ -103,9 +105,12 @@ static int davinci_direction_in(struct gpio_chip *chip,
unsigned offset)
static int davinci_gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct davinci_gpio_controller *d = gpiochip_get_data(chip);
- struct davinci_gpio_regs __iomem *g = d->regs;
+ struct davinci_gpio_regs __iomem *g;
+ int bank = offset / 32;
- return !!((1 << offset) & readl_relaxed(&g->in_data));
+ g = d->regs[bank];
+
+ return !!(__gpio_mask(offset) & readl_relaxed(&g->in_data));
}
/*
@@ -115,9 +120,13 @@ static int davinci_gpio_get(struct gpio_chip *chip,
unsigned offset)
davinci_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
{
struct davinci_gpio_controller *d = gpiochip_get_data(chip);
- struct davinci_gpio_regs __iomem *g = d->regs;
+ struct davinci_gpio_regs __iomem *g;
+ int bank = offset / 32;
- writel_relaxed((1 << offset), value ? &g->set_data : &g->clr_data);
+ g = d->regs[bank];
+
+ writel_relaxed(__gpio_mask(offset),
+ value ? &g->set_data : &g->clr_data);
}
static struct davinci_gpio_platform_data *
@@ -165,7 +174,7 @@ static int davinci_gpio_of_xlate(struct gpio_chip *gc,
if (gpiospec->args[0] > pdata->ngpio)
return -EINVAL;
- if (gc != &chips[gpiospec->args[0] / 32].chip)
+ if (gc != &chips->chip)
return -EINVAL;
if (flags)
@@ -177,11 +186,11 @@ static int davinci_gpio_of_xlate(struct gpio_chip *gc,
static int davinci_gpio_probe(struct platform_device *pdev)
{
- int i, base;
+ static int ctrl_num;
+ int gpio, bank;
unsigned ngpio, nbank;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
- struct davinci_gpio_regs __iomem *regs;
struct device *dev = &pdev->dev;
struct resource *res;
char label[MAX_LABEL_SIZE];
@@ -220,38 +229,30 @@ static int davinci_gpio_probe(struct platform_device
*pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
- for (i = 0, base = 0; base < ngpio; i++, base += 32) {
- snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", i);
- chips[i].chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
- if (!chips[i].chip.label)
+ snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
+ chips->chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
+ if (!chips->chip.label)
return -ENOMEM;
- chips[i].chip.direction_input = davinci_direction_in;
- chips[i].chip.get = davinci_gpio_get;
- chips[i].chip.direction_output = davinci_direction_out;
- chips[i].chip.set = davinci_gpio_set;
+ chips->chip.direction_input = davinci_direction_in;
+ chips->chip.get = davinci_gpio_get;
+ chips->chip.direction_
[PATCH V2 5/6] gpio: davinci: Remove custom .xlate
With the current redesign of driver it's not necessary to have
custom .xlate() as the gpiolib will assign default of_gpio_simple_xlate().
Suggested-by: Grygorii Strashko
Signed-off-by: Keerthy
---
drivers/gpio/gpio-davinci.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 2a5ae04..86b4950 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -163,27 +163,6 @@ static int davinci_gpio_get(struct gpio_chip *chip,
unsigned offset)
return NULL;
}
-#ifdef CONFIG_OF_GPIO
-static int davinci_gpio_of_xlate(struct gpio_chip *gc,
-const struct of_phandle_args *gpiospec,
-u32 *flags)
-{
- struct davinci_gpio_controller *chips = dev_get_drvdata(gc->parent);
- struct davinci_gpio_platform_data *pdata = dev_get_platdata(gc->parent);
-
- if (gpiospec->args[0] > pdata->ngpio)
- return -EINVAL;
-
- if (gc != &chips->chip)
- return -EINVAL;
-
- if (flags)
- *flags = gpiospec->args[1];
-
- return gpiospec->args[0] % 32;
-}
-#endif
-
static int davinci_gpio_probe(struct platform_device *pdev)
{
static int ctrl_num, bank_base;
@@ -244,7 +223,6 @@ static int davinci_gpio_probe(struct platform_device *pdev)
#ifdef CONFIG_OF_GPIO
chips->chip.of_gpio_n_cells = 2;
- chips->chip.of_xlate = davinci_gpio_of_xlate;
chips->chip.parent = dev;
chips->chip.of_node = dev->of_node;
#endif
--
1.9.1
[PATCH V2 1/6] gpio: davinci: Remove gpio2regs function to accommodate multi instances
gpio2regs is written making an assumption that driver supports only
one instance of gpio controller. Removing this and adding a generic
array so as to support multiple instances of gpio controllers.
Signed-off-by: Keerthy
---
Changes in v2:
* Added a comment to explain divide by 2 logic for register sets.
drivers/gpio/gpio-davinci.c | 35 +++
1 file changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 163f81e..bb47de3 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -43,25 +43,7 @@ struct davinci_gpio_regs {
#define MAX_LABEL_SIZE 20
static void __iomem *gpio_base;
-
-static struct davinci_gpio_regs __iomem *gpio2regs(unsigned gpio)
-{
- void __iomem *ptr;
-
- if (gpio < 32 * 1)
- ptr = gpio_base + 0x10;
- else if (gpio < 32 * 2)
- ptr = gpio_base + 0x38;
- else if (gpio < 32 * 3)
- ptr = gpio_base + 0x60;
- else if (gpio < 32 * 4)
- ptr = gpio_base + 0x88;
- else if (gpio < 32 * 5)
- ptr = gpio_base + 0xb0;
- else
- ptr = NULL;
- return ptr;
-}
+static unsigned int offset_array[5] = {0x10, 0x38, 0x60, 0x88, 0xb0};
static inline struct davinci_gpio_regs __iomem *irq2regs(struct irq_data *d)
{
@@ -262,7 +244,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
#endif
spin_lock_init(&chips[i].lock);
- regs = gpio2regs(base);
+ regs = gpio_base + offset_array[i];
if (!regs)
return -ENXIO;
chips[i].regs = regs;
@@ -417,7 +399,9 @@ static int gpio_irq_type_unbanked(struct irq_data *data,
unsigned trigger)
davinci_gpio_irq_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
- struct davinci_gpio_regs __iomem *g = gpio2regs(hw);
+ struct davinci_gpio_controller *chips =
+ (struct davinci_gpio_controller *)d->host_data;
+ struct davinci_gpio_regs __iomem *g = chips[hw / 32].regs;
irq_set_chip_and_handler_name(irq, &gpio_irqchip, handle_simple_irq,
"davinci_gpio");
@@ -554,7 +538,7 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
irq_chip->irq_set_type = gpio_irq_type_unbanked;
/* default trigger: both edges */
- g = gpio2regs(0);
+ g = chips[0].regs;
writel_relaxed(~0, &g->set_falling);
writel_relaxed(~0, &g->set_rising);
@@ -573,8 +557,11 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
* then chain through our own handler.
*/
for (gpio = 0, bank = 0; gpio < ngpio; bank++, bank_irq++, gpio += 16) {
- /* disabled by default, enabled only as needed */
- g = gpio2regs(gpio);
+ /* disabled by default, enabled only as needed
+* There are register sets for 32 GPIOs. 2 banks of 16
+* GPIOs are covered by each set of registers hence divide by 2
+*/
+ g = chips[bank / 2].regs;
writel_relaxed(~0, &g->clr_falling);
writel_relaxed(~0, &g->clr_rising);
--
1.9.1
[PATCH V2 2/6] gpio: davinci: Remove unwanted blank line
Remove redundant blank line.
Signed-off-by: Keerthy
---
include/linux/platform_data/gpio-davinci.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/platform_data/gpio-davinci.h
b/include/linux/platform_data/gpio-davinci.h
index 44ca530..18127c4 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -26,7 +26,6 @@ struct davinci_gpio_platform_data {
u32 gpio_unbanked;
};
-
struct davinci_gpio_controller {
struct gpio_chipchip;
struct irq_domain *irq_domain;
--
1.9.1
Re: [PATCH net-next v2 05/10] drivers: base: Add device_find_class()
From: Florian Fainelli Date: Thu, 12 Jan 2017 14:50:39 -0800 > Well, this is really so that we don't need to cast the arguments passed > to device_find_child(), which takes a void *data as well. Aha, I didn't catch that, my bad.
linux-next: Tree for Jan 13
Hi all, Changes since 20170112: The akpm-current tree lost its build failure. Non-merge commits (relative to Linus' tree): 3176 4027 files changed, 124734 insertions(+), 67998 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 251 trees (counting Linus' and 36 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (e28ac1fc3129 Merge tag 'xfs-for-linus-4.10-rc4-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux) Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP defines before declaring the functions) Merging arc-current/for-curr (e51d5d02f688 ARCv2: IRQ: Call entry/exit functions for chained handlers in MCIP) Merging arm-current/fixes (ddc37832a134 ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs) Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in atari_get_hardware_list()) Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally) Merging powerpc-fixes/fixes (69973b830859 Linux 4.9) Merging sparc/master (4bbc84ffd137 sparc: use symbolic names for tsb indexing) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (7aa4865506a2 net: thunderx: acpi: fix LMAC initialization) Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in mpls-sysctl) Merging netfilter/master (bf99b4ded5f8 tcp: fix mark propagation with fwmark_reflect enabled) Merging ipvs/master (045169816b31 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging wireless-drivers/master (60f59ce02785 rtlwifi: rtl_usb: Fix missing entry in USB driver's private data) Merging mac80211/master (c38c39bf7cc0 mac80211: Fix headroom allocation when forwarding mesh pkt) Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (27d3eef42093 Revert "PCI: Add runtime PM support for PCIe ports") Merging driver-core.current/driver-core-linus (a121103c9228 Linux 4.10-rc3) Merging tty.current/tty-linus (802c03881f29 sysrq: attach sysrq handler correctly for 32-bit kernel) Merging usb.current/usb-linus (97f9c5f211d1 Merge tag 'usb-serial-4.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus) Merging usb-gadget-fixes/fixes (43aef5c2ca90 usb: gadget: Fix copy/pasted error message) Merging usb-serial-fixes/usb-linus (2d5a9c72d0c4 USB: serial: ch341: fix control-message error handling) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1) Merging staging.current/staging-linus (a121103c9228 Linux 4.10-rc3) Merging char-misc.current/char-misc-linus (c8a6a09c1c61 vme: Fix wrong pointer utilization in ca91cx42_slave_get) Merging input-current/for-linus (1c3415a06b10 Input: elants_i2c - avoid divide by 0 errors on bad touchscreen data) Merging crypto-current/master (07825f0acd85 crypto: aesni - Fix failure when built-in with modular p
[PATCH] lockdep: Make a stack_trace instance passed to check_prev_add as an arg
Like this. Right?
->8-
>From c6173f29ff9bf801649f3cbeb80a914fdf1b998b Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Fri, 13 Jan 2017 12:02:02 +0900
Subject: [PATCH] lockdep: Make a stack_trace instance passed to check_prev_add
as an arg
Saving stack_trace within check_prev_add needs many tricky codes. To
avoid these, this patch makes the stack_trace instance created out of
check_prev_add, but by caller and passed as an argument.
Signed-off-by: Byungchul Park
---
kernel/locking/lockdep.c | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 2081c31..049fc71 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1797,20 +1797,13 @@ static inline void inc_chains(void)
*/
static int
check_prev_add(struct task_struct *curr, struct held_lock *prev,
- struct held_lock *next, int distance, int *stack_saved)
+ struct held_lock *next, int distance,
+ struct stack_trace *trace)
{
struct lock_list *entry;
int ret;
struct lock_list this;
struct lock_list *uninitialized_var(target_entry);
- /*
-* Static variable, serialized by the graph_lock().
-*
-* We use this static variable to save the stack trace in case
-* we call into this function multiple times due to encountering
-* trylocks in the held lock stack.
-*/
- static struct stack_trace trace;
/*
* Prove that the new -> dependency would not
@@ -1858,26 +1851,20 @@ static inline void inc_chains(void)
}
}
- if (!*stack_saved) {
- if (!save_trace(&trace))
- return 0;
- *stack_saved = 1;
- }
-
/*
* Ok, all validations passed, add the new lock
* to the previous lock's dependency list:
*/
ret = add_lock_to_list(hlock_class(prev), hlock_class(next),
&hlock_class(prev)->locks_after,
- next->acquire_ip, distance, &trace);
+ next->acquire_ip, distance, trace);
if (!ret)
return 0;
ret = add_lock_to_list(hlock_class(next), hlock_class(prev),
&hlock_class(next)->locks_before,
- next->acquire_ip, distance, &trace);
+ next->acquire_ip, distance, trace);
if (!ret)
return 0;
@@ -1885,8 +1872,6 @@ static inline void inc_chains(void)
* Debugging printouts:
*/
if (verbose(hlock_class(prev)) || verbose(hlock_class(next))) {
- /* We drop graph lock, so another thread can overwrite trace. */
- *stack_saved = 0;
graph_unlock();
printk("\n new dependency: ");
print_lock_name(hlock_class(prev));
@@ -1909,8 +1894,8 @@ static inline void inc_chains(void)
check_prevs_add(struct task_struct *curr, struct held_lock *next)
{
int depth = curr->lockdep_depth;
- int stack_saved = 0;
struct held_lock *hlock;
+ struct stack_trace trace;
/*
* Debugging checks.
@@ -1927,6 +1912,9 @@ static inline void inc_chains(void)
curr->held_locks[depth-1].irq_context)
goto out_bug;
+ if (!save_trace(&trace))
+ return 0;
+
for (;;) {
int distance = curr->lockdep_depth - depth + 1;
hlock = curr->held_locks + depth - 1;
@@ -1936,7 +1924,7 @@ static inline void inc_chains(void)
*/
if (hlock->read != 2 && hlock->check) {
if (!check_prev_add(curr, hlock, next,
- distance, &stack_saved))
+ distance, &trace))
return 0;
/*
* Stop after the first non-trylock entry,
--
1.9.1
Re: [RFC] [PATCH] audit: log 32-bit socketcalls
On 2017-01-12 16:32, Paul Moore wrote:
> On Thu, Jan 12, 2017 at 7:36 AM, Richard Guy Briggs wrote:
> > 32-bit socketcalls were not being logged by audit on x86_64 systems.
> > Log them.
> >
> > See: https://github.com/linux-audit/audit-kernel/issues/14
> >
> > Signed-off-by: Richard Guy Briggs
> > ---
> > net/compat.c | 18 --
> > 1 files changed, 16 insertions(+), 2 deletions(-)
>
> You should CC netdev on this patch; I'd also mention that you are
> simply duplicating the normal socketcall() auditing in the compat
> version (the only real difference being the argument size handling
> workaround).
D'ho! Completely forgot about netdev.
I thought of mentioning the size handling in the description, but
figured it was somewhat obvious right in the code. I'll add a comment.
> > diff --git a/net/compat.c b/net/compat.c
> > index 1cd2ec0..86cacab 100644
> > --- a/net/compat.c
> > +++ b/net/compat.c
> > @@ -22,6 +22,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > @@ -781,14 +782,27 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct
> > compat_mmsghdr __user *, mmsg,
> >
> > COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
> > {
> > + unsigned int len, i;
> > int ret;
> > - u32 a[6];
> > + u32 a[AUDITSC_ARGS];
> > + unsigned long aa[AUDITSC_ARGS];
> > u32 a0, a1;
> >
> > if (call < SYS_SOCKET || call > SYS_SENDMMSG)
> > return -EINVAL;
> > - if (copy_from_user(a, args, nas[call]))
> > + len = nas[call];
> > + if (len > sizeof(a))
> > + return -EINVAL;
> > +
> > + if (copy_from_user(a, args, len))
> > return -EFAULT;
> > +
> > + for (i=0; i < len/sizeof(a[0]); i++)
> > + aa[i] = (unsigned long)a[i];
>
> It will be interesting to see if you get push back on this loop
> outside of audit_socketcall(); folks may want to see it wrapped up
> inside a audit_socketcall_compat() (or similar) function so it isn't
> needlessly called in a number of cases. However, considering it is
> compat code, and not the common case it may be okay.
I thought about this, and was thinking a check of !audit_dummy_context()
here might be a solution, but audit_socketcall_compat is a much cleaner
idea. I did also consider that it is compat code that won't have a lot
of performance nerds screaming, but that's no excuse...
> > + ret = audit_socketcall(len/sizeof(a[0]), aa);
> > + if (ret)
> > + return ret;
> > +
> > a0 = a[0];
> > a1 = a[1];
> >
> > --
> > 1.7.1
>
> --
> paul moore
> www.paul-moore.com
- RGB
--
Richard Guy Briggs
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
Re: eMMC boot problem: switch to bus width 8 ddr failed
On 2017/1/13 11:12, Bough Chen wrote:
-Original Message-
From: Shawn Lin [mailto:shawn@rock-chips.com]
Sent: Friday, January 13, 2017 10:11 AM
To: Ulf Hansson ; Clemens Gruber
Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
; Adrian Hunter ; A.S.
Dong ; linux-kernel@vger.kernel.org; Bough Chen
; Gary Bisson ;
Fabio Estevam ; Shawn Guo
Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
On 2017/1/13 0:51, Ulf Hansson wrote:
+ Haibo, Gary, Fabio, Shawn Gou
On 6 January 2017 at 16:56, Clemens Gruber
wrote:
On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
On 2017/1/6 8:41, Clemens Gruber wrote:
Hi,
with the current mainline 4.10-rc2 kernel, I can no longer boot
from the eMMC on my i.MX6Q board.
Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
supports eMMC 4.41 features and we did not implement voltage
switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.
With 4.9 the board booted fine, now with the current mainline 4.10
tree, I get the following (repeating) errors at boot:
[4.326834] Waiting for root device /dev/mmcblk0p2...
[ 14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[ 14.569619] sdhci: === REGISTER DUMP
(mmc0)===
[ 14.575461] sdhci: Sys addr: 0x4e726000 | Version: 0x0002
[ 14.581300] sdhci: Blk size: 0x0200 | Blk cnt: 0x0001
[ 14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[ 14.592979] sdhci: Present: 0x01fd8009 | Host ctl: 0x0031
[ 14.598816] sdhci: Power:0x0002 | Blk gap: 0x0080
[ 14.604654] sdhci: Wake-up: 0x0008 | Clock:0x001f
[ 14.610493] sdhci: Timeout: 0x008f | Int stat: 0x
[ 14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[ 14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[ 14.628007] sdhci: Caps: 0x07eb | Caps_1: 0xa007
[ 14.633845] sdhci: Cmd: 0x0d1a | Max curr: 0x00ff
it shows you always fail to get resp of sending status within the
expected period of time.
[ 14.639682] sdhci: Host ctl2: 0x
[ 14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[ 14.649447] sdhci:
===
This repeats a few times, then more information is shown at the bottom:
[ 86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[ 86.899615] sdhci: === REGISTER DUMP
(mmc0)===
[ 86.905453] sdhci: Sys addr: 0x | Version: 0x0002
[ 86.911291] sdhci: Blk size: 0x0200 | Blk cnt: 0x0001
[ 86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[ 86.922967] sdhci: Present: 0x01fd8009 | Host ctl: 0x0031
[ 86.928804] sdhci: Power:0x0002 | Blk gap: 0x0080
[ 86.934642] sdhci: Wake-up: 0x0008 | Clock:0x001f
[ 86.940479] sdhci: Timeout: 0x008f | Int stat: 0x
[ 86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[ 86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[ 86.957992] sdhci: Caps: 0x07eb | Caps_1: 0xa007
[ 86.963830] sdhci: Cmd: 0x0d1a | Max curr: 0x00ff
[ 86.969668] sdhci: Host ctl2: 0x
[ 86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[ 86.979433] sdhci:
===
[ 86.986356] mmc0: switch to bus width 8 ddr failed
[ 86.991163] mmc0: error -110 whilst initialising MMC card
[ 97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
--
After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core:
Update
CMD13 polling policy when switch to HS DDR mode")
Reverting it fixes the problem. But I am unsure if that's the right
course of action?
Feel free to send me patches for testing!
By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that
doesn't help at all. :)
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card
*card)
EXT_CSD_BUS_WIDTH,
ext_csd_bits,
card->ext_csd.generic_cmd6_time,
- MMC_TIMING_MMC_DDR52,
+ 0,
true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n", @@
-1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
if (err)
err = __mmc_set_signal_voltage(host,
MMC_SIGNAL_VOLTAGE_330);
+ if (!err)
+ mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
+
Hi,
thank you. This patch solves the problem! :)
Tested-by: Clemens Gruber
Regards,
Clemens
Everybody inv
Re: [Lsf-pc] [LSF/MM TOPIC] [LSF/MM ATTEND] md raid general discussion
On 2017/1/12 下午11:09, Sagi Grimberg wrote: > Hey Coly, > >> Also I receive reports from users that raid1 performance is desired when >> it is built on NVMe SSDs as a cache (maybe bcache or dm-cache). I am >> working on some raid1 performance improvement (e.g. new raid1 I/O >> barrier and lockless raid1 I/O submit), and have some more ideas to >> discuss. > > Do you have some performance measurements to share? > > Mike used null devices to simulate very fast devices which > led to nice performance enhancements in dm-multipath code. I have several performance data of raid1 and raid0, which is still work in progress. - md raid1 Current md raid1 read performance is not ideal. A raid1 with 2 NVMe SSD, only observe 2.6GB/s throughput for multi I/O and depth reading. Most of the time spending on I/O barrier locking. Now I am working on a lockless I/O submit patch (the original idea is from Hannes Reinecke), which improves reading throughput to 4.7~5GB/s. When using md raid1 as a cache device, reading performance improvement is critical. On my hardware, the ideal reading throughput of 2 NVMe is 6GB/s, currently the reading performance number is 4.7~5GB/s, still have a little some space to improve. - md raid0 People reports on linux-raid mailing list that DISCARD/TRIM performance on raid0 is slow. In my reproducing, a raid0 built by 4x3TB NVMe SSD, formatting a XFS volume on top of it takes 306 seconds. Most of the time is inside md raid0 code to issue DISCARD/TRIM request in chunk size range. I compose a POC patch to re-combine a large DISCARD/TRIM command into per-device request, which reduces the formatting time to 15 seconds. Now I work on patch simplifying by the suggestions from upstream maintainers. For raid1, currently most of feed backs are from read performance. Coly
Re: 4.9.0 regression in pipe-backed iov_iter with systemd-nspawn
On Thu, Jan 12, 2017 at 03:28:32PM -0800, Linus Torvalds wrote: > On Thu, Jan 12, 2017 at 2:46 PM, Alan J. Wylie wrote: > > > > I'm off to bed now with a stinking head cold I'm afraid. > > So assuming Al hasn't figured it out by the time you get back, can you > try to send us the same strace for the working case? That, and check if it is reproducible on commit 523ac9afc73a with commit 8e54cadab447 cherry-picked on top of that.
Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock
On 01/05/2017 11:31 PM, Eric Ren wrote:
> We are in the situation that we have to avoid recursive cluster locking,
> but there is no way to check if a cluster lock has been taken by a
> precess already.
>
> Mostly, we can avoid recursive locking by writing code carefully.
> However, we found that it's very hard to handle the routines that
> are invoked directly by vfs code. For instance:
>
> const struct inode_operations ocfs2_file_iops = {
> .permission = ocfs2_permission,
> .get_acl= ocfs2_iop_get_acl,
> .set_acl= ocfs2_iop_set_acl,
> };
>
> Both ocfs2_permission() and ocfs2_iop_get_acl() call ocfs2_inode_lock(PR):
> do_sys_open
> may_open
> inode_permission
>ocfs2_permission
> ocfs2_inode_lock() <=== first time
> generic_permission
> get_acl
>ocfs2_iop_get_acl
> ocfs2_inode_lock() <=== recursive one
>
> A deadlock will occur if a remote EX request comes in between two
> of ocfs2_inode_lock(). Briefly describe how the deadlock is formed:
>
> On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in
> BAST(ocfs2_generic_handle_bast) when downconvert is started
> on behalf of the remote EX lock request. Another hand, the recursive
> cluster lock (the second one) will be blocked in in __ocfs2_cluster_lock()
> because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, why?
> because there is no chance for the first cluster lock on this node to be
> unlocked - we block ourselves in the code path.
>
> The idea to fix this issue is mostly taken from gfs2 code.
> 1. introduce a new field: struct ocfs2_lock_res.l_holders, to
> keep track of the processes' pid who has taken the cluster lock
> of this lock resource;
> 2. introduce a new flag for ocfs2_inode_lock_full: OCFS2_META_LOCK_GETBH;
> it means just getting back disk inode bh for us if we've got cluster lock.
> 3. export a helper: ocfs2_is_locked_by_me() is used to check if we
> have got the cluster lock in the upper code path.
>
> The tracking logic should be used by some of the ocfs2 vfs's callbacks,
> to solve the recursive locking issue cuased by the fact that vfs routines
> can call into each other.
>
> The performance penalty of processing the holder list should only be seen
> at a few cases where the tracking logic is used, such as get/set acl.
>
> You may ask what if the first time we got a PR lock, and the second time
> we want a EX lock? fortunately, this case never happens in the real world,
> as far as I can see, including permission check, (get|set)_(acl|attr), and
> the gfs2 code also do so.
>
> Signed-off-by: Eric Ren
> ---
> fs/ocfs2/dlmglue.c | 47 ---
> fs/ocfs2/dlmglue.h | 18 ++
> fs/ocfs2/ocfs2.h | 1 +
> 3 files changed, 63 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
> index 83d576f..500bda4 100644
> --- a/fs/ocfs2/dlmglue.c
> +++ b/fs/ocfs2/dlmglue.c
> @@ -532,6 +532,7 @@ void ocfs2_lock_res_init_once(struct ocfs2_lock_res *res)
> init_waitqueue_head(&res->l_event);
> INIT_LIST_HEAD(&res->l_blocked_list);
> INIT_LIST_HEAD(&res->l_mask_waiters);
> + INIT_LIST_HEAD(&res->l_holders);
> }
>
> void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,
> @@ -749,6 +750,45 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res *res)
> res->l_flags = 0UL;
> }
>
> +inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
> +struct ocfs2_holder *oh)
> +{
> + INIT_LIST_HEAD(&oh->oh_list);
> + oh->oh_owner_pid = get_pid(task_pid(current));
struct pid(oh->oh_owner_pid) looks complicated here, why not use
task_struct(current) or pid_t(current->pid) directly? Also i didn't see
the ref count needs to be considered.
> +
> + spin_lock(&lockres->l_lock);
> + list_add_tail(&oh->oh_list, &lockres->l_holders);
> + spin_unlock(&lockres->l_lock);
> +}
> +
> +inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
> +struct ocfs2_holder *oh)
> +{
> + spin_lock(&lockres->l_lock);
> + list_del(&oh->oh_list);
> + spin_unlock(&lockres->l_lock);
> +
> + put_pid(oh->oh_owner_pid);
same the above
> +}
> +
> +inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res
> *lockres)
Agree with Joseph, return bool looks better. I didn't see how that help
debug since the return value is not used.
> +{
> + struct ocfs2_holder *oh;
> + struct pid *pid;
> +
> + /* look in the list of holders for one with the current task as owner */
> + spin_lock(&lockres->l_lock);
> + pid = task_pid(current);
> + list_for_each_entry(oh, &lockres->l_holders, oh_list) {
> + if (oh->oh_owner_pid == pid)
> + goto out;
> + }
> + oh = NULL;
> +out:
> + spin_unlock(&lockres->l_lock);
> + return oh;
> +}
> +
> static inline void ocfs2_inc_holders(struct ocfs2_lock_res
Re: [PATCH 2/2] gpio: davinci: Remove gpio2regs function to accommodate multi instances
On Wednesday 11 January 2017 09:23 PM, Linus Walleij wrote: On Wed, Jan 11, 2017 at 1:40 PM, Keerthy wrote: On Wednesday 11 January 2017 04:34 PM, Linus Walleij wrote: On Wed, Jan 4, 2017 at 9:26 AM, Keerthy wrote: gpio2regs is written making an assumption that driver supports only one instance of gpio controller. Removing this and adding a generic array so as to support multiple instances of gpio controllers. Signed-off-by: Keerthy - regs = gpio2regs(base); + regs = gpio_base + offset_array[i]; I understand this. - struct davinci_gpio_regs __iomem *g = gpio2regs(hw); + struct davinci_gpio_controller *chips = + (struct davinci_gpio_controller *)d->host_data; + struct davinci_gpio_regs __iomem *g = chips[hw / 32].regs; And this, if each instans has 32 GPIOs. - g = gpio2regs(0); + g = chips[0].regs; Also makes sense. - g = gpio2regs(gpio); + g = chips[bank / 2].regs; But what is this? I don't understand that /2 at all. Please insert a comment explaining it so I can figure it out. Are there two banks per instance? Yes! There are register sets for 32 GPIOs. 2 banks of 16 GPIOs are covered by each set of registers hence /2. Shall i add a comment and send this patch alone separately? Yeah. I am currently confused by several patch sets for davinci in my inbox, can you rebase on my devel branch when I push it and resend *all* you have cooking for DaVinci? I am assuming that Patch 1 from this is applied. I will club this one along with my latest series and send a new v2 series so that all are in one place. Thanks, Keerthy Yours, Linus Walleij
Re: [PATCH] mm/page_alloc: Wait for oom_lock before retrying.
On (01/13/17 11:52), Sergey Senozhatsky wrote: [..] > and we really don't want to cond_resched() when we are in panic. > that's why console_flush_on_panic() sets it to zero explicitly. > > console_trylock() checks oops_in_progress, so re-taking the semaphore > when we are in > > panic() >console_flush_on_panic() > console_unlock() >console_trylock() > > should be OK. as well as doing get_console_conditional_schedule() somewhere > in console driver code. d'oh... no, this is false. console_flush_on_panic() is called after we bust_spinlocks(0), BUT with local IRQs disabled. so console_trylock() would still set console_may_schedule to 0. -ss
Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300
On Fri, Jan 13, 2017 at 2:44 PM, Gautham R Shenoy wrote: > On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote: >> On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote: >> > From: "Gautham R. Shenoy" >> > >> > Balbir pointed out that in idle_book3s.S and powernv/idle.c some >> > functions and variables had power9 in their names while some others >> > had arch300. >> > >> >> I would prefer power9 to arch300 >> > > > I don't have a strong preference for arch300 vs power9, will change it > to power9 if that looks better. Personally I think we should be as descriptive as possible and use power_9_arch_300_the_bikeshed_is_red_dammit. Oliver
Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300
On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote: > On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote: > > From: "Gautham R. Shenoy" > > > > Balbir pointed out that in idle_book3s.S and powernv/idle.c some > > functions and variables had power9 in their names while some others > > had arch300. > > > > I would prefer power9 to arch300 > I don't have a strong preference for arch300 vs power9, will change it to power9 if that looks better. -- Thanks and Regards gautham.
Re: [PATCH] power: reset: Add MAX77620 support
Hi Thierry,
I have a few comments inline.
On Thu, Jan 12, 2017 at 05:15:07PM +0100, Thierry Reding wrote:
> The Maxim MAX77620 PMIC has the ability to power off and restart the
> system. Add a driver that supports power off (via pm_power_off()) and
> restart (via arm_pm_restart() on 32-bit and 64-bit ARM).
>
> Based on work by Chaitanya Bandi .
>
> Cc: Chaitanya Bandi
> Signed-off-by: Thierry Reding
> ---
> drivers/power/reset/Kconfig | 6 ++
> drivers/power/reset/Makefile| 1 +
> drivers/power/reset/max77620-poweroff.c | 146
>
> 3 files changed, 153 insertions(+)
> create mode 100644 drivers/power/reset/max77620-poweroff.c
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index abeb77217a21..f0d0c20632f8 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -98,6 +98,12 @@ config POWER_RESET_IMX
> say N here or disable in dts to make sure pm_power_off never be
> overwrote wrongly by this driver.
>
> +config POWER_RESET_MAX77620
> + bool "Maxim MAX77620 PMIC power-off driver"
> + depends on MFD_MAX77620
> + help
> + Power off and restart support for Maxim MAX77620 PMICs.
> +
> config POWER_RESET_MSM
> bool "Qualcomm MSM power-off driver"
> depends on ARCH_QCOM
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 11dae3b56ff9..74511d2f037a 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
> obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
> obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
> +obj-$(CONFIG_POWER_RESET_MAX77620) += max77620-poweroff.o
> obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
> obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
> diff --git a/drivers/power/reset/max77620-poweroff.c
> b/drivers/power/reset/max77620-poweroff.c
> new file mode 100644
> index ..4f2682d10925
> --- /dev/null
> +++ b/drivers/power/reset/max77620-poweroff.c
> @@ -0,0 +1,146 @@
> +/*
> + * Power off driver for Maxim MAX77620 device.
> + *
> + * Copyright (c) 2014-2016, NVIDIA CORPORATION. All rights reserved.
> + *
> + * Based on work by Chaitanya Bandi .
> + *
> + * 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 version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
> + * whether express or implied; 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
> +
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> +#include
> +#endif
> +
> +struct max77620_power {
> + struct regmap *regmap;
> + struct device *dev;
> +};
> +
> +static struct max77620_power *system_power_controller = NULL;
> +
> +static void max77620_pm_power_off(void)
> +{
> + struct max77620_power *power = system_power_controller;
> + unsigned int value;
> + int err;
> +
> + if (!power)
> + return;
> +
> + /* clear power key interrupts */
> + err = regmap_read(power->regmap, MAX77620_REG_ONOFFIRQ, &value);
> + if (err < 0)
> + dev_err(power->dev, "failed to clear power key interrupts:
> %d\n", err);
> +
> + /* clear RTC interrupts */
> + /*
> + err = regmap_read(power->regmap, MAX77620_REG_RTCINT, &value);
> + if (err < 0)
> + dev_err(power->dev, "failed to clear RTC interrupts: %d\n",
> err);
> + */
> +
> + /* clear TOP interrupts */
> + err = regmap_read(power->regmap, MAX77620_REG_IRQTOP, &value);
> + if (err < 0)
> + dev_err(power->dev, "failed to clear interrupts: %d\n", err);
> +
> + err = regmap_update_bits(power->regmap, MAX77620_REG_ONOFFCNFG2,
> + MAX77620_ONOFFCNFG2_SFT_RST_WK, 0);
> + if (err < 0)
> + dev_err(power->dev, "failed to clear SFT_RST_WK: %d\n", err);
> +
> + err = regmap_update_bits(power->regmap, MAX77620_REG_ONOFFCNFG1,
> + MAX77620_ONOFFCNFG1_SFT_RST,
> + MAX77620_ONOFFCNFG1_SFT_RST);
> + if (err < 0)
> + dev_err(power->dev, "failed to set SFT_RST: %d\n", err);
> +}
> +
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> +static void max77620_pm_restart(enum reboot_mode mode, const char *cmd)
> +{
> + struct max77620_power *power = system_power_controller;
> + int err;
> +
> + if (!power)
> + return;
> +
> + err
Re: [PATCH 2/3] gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip
On Friday 13 January 2017 12:36 AM, Grygorii Strashko wrote: On 01/11/2017 08:00 PM, Keerthy wrote: On Wednesday 11 January 2017 11:23 PM, Grygorii Strashko wrote: On 01/10/2017 11:00 PM, Keerthy wrote: The Davinci GPIO driver is implemented to work with one monolithic Davinci GPIO platform device which may have up to Y(144) gpios. The Davinci GPIO driver instantiates number of GPIO chips with max 32 gpio pins per each during initialization and one IRQ domain. So, the current GPIO's opjects structure is: Davinci GPIO controller |- --| ...|--- irq_domain (hwirq [0..143]) |- --| Current driver creates one chip for every 32 GPIOs in a controller. This was a limitation earlier now there is no need for that. Hence redesigning the driver to create one gpio chip for all the ngpio in the controller. |- --|--- irq_domain (hwirq [0..143]). The previous discussion on this can be found here: https://www.spinics.net/lists/linux-omap/msg132869.html nice rework. Thanks! Signed-off-by: Keerthy --- Boot tested on Davinci platform. drivers/gpio/gpio-davinci.c| 127 + [...] #ifdef CONFIG_OF_GPIO -chips[i].chip.of_gpio_n_cells = 2; -chips[i].chip.of_xlate = davinci_gpio_of_xlate; -chips[i].chip.parent = dev; -chips[i].chip.of_node = dev->of_node; +chips->chip.of_gpio_n_cells = 2; +chips->chip.of_xlate = davinci_gpio_of_xlate; I think It's not necessary to have custom .xlate() and it can be removed, then gpiolib will assign default one of_gpio_simple_xlate(). Okay. Can i do that as a separate patch? I think it's ok. +chips->chip.parent = dev; +chips->chip.of_node = dev->of_node; #endif -spin_lock_init(&chips[i].lock); - [...] irq_set_chip_and_handler_name(irq, &gpio_irqchip, handle_simple_irq, "davinci_gpio"); @@ -459,6 +468,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev) struct irq_domain*irq_domain = NULL; const struct of_device_id *match; struct irq_chip *irq_chip; +struct davinci_gpio_irq_data *irqdata[MAX_BANKED_IRQS]; You declare irqdata as array here but it has not been used anywhere except for assignment. Could you remove this array and MAX_BANKED_IRQS define? irq_set_chained_handler_and_data(bank_irq, gpio_irq_handler, &chips[gpio / 32]); irqdata[bank]); That is hooked as data for each bank. As there is only one controller now and the differentiating parameters per bank is the irqdata data structure with the registers pointer and the bank number. This structure makes it very easy in the irq handler to identify the register sets that need to be modified and the bank irqs. That I understood, but why do you need array here? Seems you can just use struct davinci_gpio_irq_data *irqdata; why can't you use (see below): struct davinci_gpio_irq_data *irqdata; Understood your comment now thanks for clarifying. I will do like you have suggested. gpio_get_irq_chip_cb_t gpio_get_irq_chip; /* @@ -514,10 +524,8 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev) * IRQs, while the others use banked IRQs, would need some setup * tweaks to recognize hardware which can do that. */ [...] @@ -567,8 +575,19 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev) * gpio irqs. Pass the irq bank's corresponding controller to * the chained irq handler. */ +irqdata[bank] = devm_kzalloc(&pdev->dev, + sizeof(struct +davinci_gpio_irq_data), + GFP_KERNEL); irqdata = devm_kzalloc(&pdev->dev, sizeof(struct davinci_gpio_irq_data), GFP_KERNEL); Okay. +if (!irqdata[bank]) +return -ENOMEM; + +irqdata[bank]->regs = g; +irqdata[bank]->bank_num = bank; +irqdata[bank]->chip = chips; + irq_set_chained_handler_and_data(bank_irq, gpio_irq_handler, - &chips[gpio / 32]); + irqdata[bank]); irq_set_chained_handler_and_data(bank_irq, gpio_irq_handler, irqdata); I will post the new set with the above changes. [...]
Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy
On Thu, Jan 12, 2017 at 12:03:28PM -0500, Theodore Ts'o wrote: > On Thu, Jan 12, 2017 at 04:00:16PM +0800, zhangyi (F) wrote: > > > > At the same time, I think other file systems may have the same problem, do > > you think we should put these detections on the VFS layer? Thus other file > > systems no need to do the same things, but the disadvantage is that we can > > not call ext4_error to report ext4 inconsistency. > > There are file systems which don't have inodes per-se where the > i_nlinks could be a something which is simulated by the file system. > So it's not *necessarily* an on-disk inconsistency. > > We'll have to see if Al and other file system developers are > agreeable, but one thing that we could do is to do the detection in > the VFS layer (which it is actually easier to do), and if they find an > issue, they can just pass a report via a callback function found in > the struct_operations structure. If there isn't such a function > defined, or the function returns 0, the VFS could just do nothing; if > it returns an error code, then that would get reflected back up to > userspace, plus whatever other action the file system sees fit to do. Detection of what? Zero ->i_nlink on inode of dentry that passes e.g. may_delete()?
Re: linux-next: build failure after merge of the akpm-current tree
Hi Eric, On Thu, 12 Jan 2017 13:06:01 +0800 Eric Ren wrote: > > Thanks for your report and the fix for it. The 0-day project has reported > several days ago, > but this patch set is still in discussion, so I am waiting for more days to > see if other > developers > have any other questions. > > I am confused that how to deal with your patch if I need to work out the V2 > patch set. Perhaps, > pick up your fix and add your efforts in the change log? If you had already fixed the problem, then just submit your new version. You only need to give credit when you use someone's work. If you want to give credit, then maybe a line like: [s...@canb.auug.org.au remove some inlines] among the Signed-off-by: lines -- Cheers, Stephen Rothwell
[PATCH] libfc: Fix variable name in fc_set_wwpn
The parameter name should be wwpn instead of wwnn.
Signed-off-by: Fam Zheng
---
include/scsi/libfc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/scsi/libfc.h b/include/scsi/libfc.h
index 96dd0b3..da5033d 100644
--- a/include/scsi/libfc.h
+++ b/include/scsi/libfc.h
@@ -809,11 +809,11 @@ static inline void fc_set_wwnn(struct fc_lport *lport,
u64 wwnn)
/**
* fc_set_wwpn() - Set the World Wide Port Name of a local port
* @lport: The local port whose WWPN is to be set
- * @wwnn: The new WWPN
+ * @wwpn: The new WWPN
*/
-static inline void fc_set_wwpn(struct fc_lport *lport, u64 wwnn)
+static inline void fc_set_wwpn(struct fc_lport *lport, u64 wwpn)
{
- lport->wwpn = wwnn;
+ lport->wwpn = wwpn;
}
/**
--
2.9.3
