Dan Carpenter | 24 Oct 10:16 2014
Picon

[patch] regulator: max77802: precedence error in max77802_set_suspend_mode()

The "!" operation has higher precedence that the comparison.

Fixes: 2e0eaa1aa008 ('regulator: max77802: Add set suspend mode for BUCKs and simplify code')
Signed-off-by: Dan Carpenter <dan.carpenter <at> oracle.com>

diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 5839c45..57e37fd 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
 <at>  <at>  -179,7 +179,7  <at>  <at>  static int max77802_set_suspend_mode(struct regulator_dev *rdev,
 	 * If the regulator has been disabled for suspend
 	 * then is invalid to try setting a suspend mode.
 	 */
-	if (!max77802->opmode[id] == MAX77802_OFF_PWRREQ) {
+	if (max77802->opmode[id] != MAX77802_OFF_PWRREQ) {
 		dev_warn(&rdev->dev, "%s: is disabled, mode: 0x%x not set\n",
 			 rdev->desc->name, mode);
 		return 0;
Ulrich Windl | 24 Oct 10:09 2014
Picon

RFE: kernel message "rport-2:0-10: blocked FC remote port time out: removing rport"

Hi!

I'd like to point out that the following Fibre CHannel error message is of little practical use, because it
lacks essential information:

kernel: [   68.406963]  rport-2:0-10: blocked FC remote port time out: removing rport
(Seen in the current SLES11 SP3 kernel 3.0.101-0.40-default)

As the logical port is removed (as the message says), you cannot find out what device (i.e. WWN) the problem
message refers to.

For existing ports in /sys/class/fc_remote_ports/ you can query port_id, port_name, port_state, etc.
But once the port is removed, you cannot get any information about it.

In a real environment, you cannot easily guess where the problem might be, especially as there is no other
message about "rport-2:0-10" before it's being removed.

I suggest to include the port ID (you can get the HBA WWN from that) and port WWN (the target device port) in the
erro message if possible.

Regards,
Ulrich Windl

Daniel Kurtz | 24 Oct 09:33 2014

[PATCH v5 3/3] ARM: dts: rk3288: add VOP iommu nodes

Add device nodes for the VOP iommus.
Device nodes for other iommus will be added in later patches.

The iommu nodes use the #iommu-cells property as described in:
  Documentation/devicetree/bindings/iommu/iommu.txt

Signed-off-by: Daniel Kurtz <djkurtz <at> chromium.org>
Signed-off-by: Simon Xue <xxm <at> rock-chips.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..df1170c 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
 <at>  <at>  -271,6 +271,24  <at>  <at> 
 		status = "disabled";
 	};

+	vopb_mmu: iommu <at> ff930300 {
+		compatible = "rockchip,iommu";
+		reg = <0xff930300 0x100>;
+		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "vopb_mmu";
+		#iommu-cells = <0>;
+		status = "disabled";
+	};
+
+	vopl_mmu: iommu <at> ff940300 {
(Continue reading)

Daniel Kurtz | 24 Oct 09:33 2014

[PATCH v5 2/3] dt-bindings: iommu: Add documentation for rockchip iommu

Add binding documentation for Rockchip IOMMU.

Signed-off-by: Daniel Kurtz <djkurtz <at> chromium.org>
Signed-off-by: Simon Xue <xxm <at> rock-chips.com>
---
 .../devicetree/bindings/iommu/rockchip,iommu.txt   | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
new file mode 100644
index 0000000..9a55ac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
 <at>  <at>  -0,0 +1,26  <at>  <at> 
+Rockchip IOMMU
+==============
+
+A Rockchip DRM iommu translates io virtual addresses to physical addresses for
+its master device.  Each slave device is bound to a single master device, and
+shares its clocks, power domain and irq.
+
+Required properties:
+- compatible      : Should be "rockchip,iommu"
+- reg             : Address space for the configuration registers
+- interrupts      : Interrupt specifier for the IOMMU instance
+- interrupt-names : Interrupt name for the IOMMU instance
+- #iommu-cells    : Should be <0>.  This indicates the iommu is a
+                    "single-master" device, and needs no additional information
+                    to associate with its master device.  See:
(Continue reading)

Zhang Rui | 24 Oct 09:30 2014
Picon

[GIT PULL] Thermal management updates for 3.18-rc2

Hi, Linus,

Sorry that I missed the merge window as there is a bug found in the last
minute, and I have to fix it and wait for the code to be tested in
linux-next tree for a few days. Now the buggy patch has been dropped
entirely from my next branch. Thus I hope those changes can still be
merged in 3.18-rc2 as most of them are platform thermal driver changes.

Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
to receive Thermal Management updates for 3.18-rc2 with top-most commit

6ceaf58abe25e86292152005c51169796bad3407:

  Merge branch 'int340x-thermal' of .git into next (2014-10-17 14:30:58
+0800)

on top of commit 52addcf9d6669fa439387610bc65c92fa0980cef:

  Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)

Specifics:

- introduce ACPI INT340X thermal drivers. Newer laptops and tablets may
have thermal sensors and other devices with thermal control capabilities
that are exposed for the OS to use via the ACPI INT340x device objects.
Several drivers are introduced to expose the temperature information and
cooling ability from these objects to user-space via the normal thermal
framework. From: Lu Aaron, Lan Tianyu, Jacob Pan and Zhang Rui.

(Continue reading)

Christophe Leroy | 24 Oct 07:35 2014
Picon

[PATCH resending] splice: sendfile() at once fails for big files

When big files (over 64kbytes) are sent with sendfile(), they are sent by blocks
of 64kbytes. In that case, the target must be informed that the current block is
not the last one, otherwise it might take wrong actions.
The issue was observed while sending a file to an AF_ALG socket for hashing. The
hash was reset at each 64k block.
This patch adds SPLICE_F_MORE to the flags when more data is pending.

Signed-off-by: Christophe Leroy <christophe.leroy <at> c-s.fr>

Index: b/fs/splice.c
===================================================================
--- a/fs/splice.c
+++ b/fs/splice.c
 <at>  <at>  -1171,7 +1171,7  <at>  <at> 
 	long ret, bytes;
 	umode_t i_mode;
 	size_t len;
-	int i, flags;
+	int i, flags, more;

 	/*
 	 * We require the input being a regular file, as we don't want to
 <at>  <at>  -1214,6 +1214,7  <at>  <at> 
 	 * Don't block on output, we have to drain the direct pipe.
 	 */
 	sd->flags &= ~SPLICE_F_NONBLOCK;
+	more = sd->flags & SPLICE_F_MORE;

 	while (len) {
 		size_t read_len;
(Continue reading)

Liliane Bettencourt. | 24 Oct 04:29 2014
Picon

Please Resend Your Message.

I, Liliane authenticate this email to you. You can read about me on:
fr.wikipedia.org/wiki/Liliane_Bettencourt I intend to give to you a portion of my Net-worth which I
have been banking. Click reply for confirmation and more details.

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

John Stultz | 24 Oct 06:22 2014

Re: [PATCH 1/2] time: Fix NTP adjustment mult overflow.

On Wed, Oct 22, 2014 at 5:37 AM, Xunlei Pang <pang.xunlei <at> linaro.org> wrote:
> The mult memember of struct clocksource should always be a large u32 number
> when calculated through
> __clocksource_updatefreq_scale(). The value of (cs->mult+cs->maxadj) may
> have a chance to reach very
> near 0xFFFFFFFF, so it may overflow when doing NTP positive adjustment, see
> the following detail:
> When NTP slewes the clock, kernel goes through
> update_wall_time()->...->timekeeping_apply_adjustment():
> tk->tkr.mult += mult_adj;
> Unfortunately, tk->tkr.mult may overflow after this operation.
>
>
> This patch avoids mult overflow by judging the overflow case before adding
> mult_adj to mult, also adds the
> WARNING message when capturing such case.
>
> Signed-off-by: pang.xunlei <pang.xunlei <at> linaro.org>

I reworded this a bit further, but its in my queue for 3.19.

thanks
-john
vndao | 24 Oct 04:41 2014

[net-next] net: phy: Adding SGMII support for Marvell 88ee1145 driver

From: Viet Nga Dao <vndao <at> altera.com>

Additional code to m88e1145_config_init function to allow the driver to
support SGMII mode.

Signed-off-by: Viet Nga Dao <vndao <at> altera.com>
---
 drivers/net/phy/marvell.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index bd37e45..b14cb10 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
 <at>  <at>  -50,9 +50,13  <at>  <at> 
 #define MII_M1011_PHY_SCR		0x10
 #define MII_M1011_PHY_SCR_AUTO_CROSS	0x0060

+#define MII_M1145_PHY_EXT_SR		0x1b
 #define MII_M1145_PHY_EXT_CR		0x14
 #define MII_M1145_RGMII_RX_DELAY	0x0080
 #define MII_M1145_RGMII_TX_DELAY	0x0002
+#define MII_M1145_HWCFG_MODE_SGMII_NO_CLK	0x4
+#define MII_M1145_HWCFG_MODE_MASK		0xf
+#define MII_M1145_HWCFG_FIBER_COPPER_AUTO	0x8000

 #define MII_M1111_PHY_LED_CONTROL	0x18
 #define MII_M1111_PHY_LED_DIRECT	0x4100
 <at>  <at>  -620,6 +624,7  <at>  <at>  static int m88e1149_config_init(struct phy_device *phydev)
 static int m88e1145_config_init(struct phy_device *phydev)
(Continue reading)

vndao | 24 Oct 04:47 2014

[net-next] net: phy: Adding SGMII support for Marvell 88ee1145 driver

From: Viet Nga Dao <vndao <at> altera.com>

Additional code to m88e1145_config_init function to allow the driver to
support SGMII mode.

Signed-off-by: Viet Nga Dao <vndao <at> altera.com>
---
 drivers/net/phy/marvell.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index bd37e45..b14cb10 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
 <at>  <at>  -50,9 +50,13  <at>  <at> 
 #define MII_M1011_PHY_SCR		0x10
 #define MII_M1011_PHY_SCR_AUTO_CROSS	0x0060

+#define MII_M1145_PHY_EXT_SR		0x1b
 #define MII_M1145_PHY_EXT_CR		0x14
 #define MII_M1145_RGMII_RX_DELAY	0x0080
 #define MII_M1145_RGMII_TX_DELAY	0x0002
+#define MII_M1145_HWCFG_MODE_SGMII_NO_CLK	0x4
+#define MII_M1145_HWCFG_MODE_MASK		0xf
+#define MII_M1145_HWCFG_FIBER_COPPER_AUTO	0x8000

 #define MII_M1111_PHY_LED_CONTROL	0x18
 #define MII_M1111_PHY_LED_DIRECT	0x4100
 <at>  <at>  -620,6 +624,7  <at>  <at>  static int m88e1149_config_init(struct phy_device *phydev)
 static int m88e1145_config_init(struct phy_device *phydev)
(Continue reading)

Wang Nan | 24 Oct 03:45 2014

[PATCH v3] perf tools: makes CPUINFO_PROC to array for different kernel version

After kernel 3.7 (commit b4b8f770eb10a1bccaf8aa0ec1956e2dd7ed1e0a),
/proc/cpuinfo replaces 'Processor' to 'model name'. This patch makes
CPUINFO_PROC to an array and provides two choices for ARM, makes it
compatible for different kernel version.

v1 -> v2: minor changes as suggested by Namhyung Kim:

 - Doesn't pass  <at> h and  <at> evlist to __write_cpudesc;
 - Coding style fix.

v2 -> v3:
  - Rebase:
    git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core

Signed-off-by: Wang Nan <wangnan0 <at> huawei.com>
Acked-by: Namhyung Kim <namhyung <at> kernel.org>
Cc: Arnaldo Carvalho de Melo <acme <at> redhat.com>
---
 tools/perf/perf-sys.h    | 30 +++++++++++++++---------------
 tools/perf/util/header.c | 27 +++++++++++++++++++++------
 2 files changed, 36 insertions(+), 21 deletions(-)

diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h
index 937e432..a3b13d7 100644
--- a/tools/perf/perf-sys.h
+++ b/tools/perf/perf-sys.h
 <at>  <at>  -13,7 +13,7  <at>  <at> 
 #define wmb()		asm volatile("lock; addl $0,0(%%esp)" ::: "memory")
 #define rmb()		asm volatile("lock; addl $0,0(%%esp)" ::: "memory")
 #define cpu_relax()	asm volatile("rep; nop" ::: "memory");
(Continue reading)


Gmane