[PATCH] Input: elantech - add Fujitsu Lifebook E556 to force crc_enabled

[Dmitry Torokhov]

Another Lifebook machine that needs the same quirk as other similar
models to make the driver working.

Also let's reorder elantech_dmi_force_crc_enabled list so LIfebook enries
are in alphabetical order.

Reported-by: William Linna 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/mouse/elantech.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 37b52f1..db7d1d6 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1517,6 +1517,13 @@ static const struct dmi_system_id 
elantech_dmi_force_crc_enabled[] = {
},
},
{
+   /* Fujitsu LIFEBOOK E544  does not work with crc_enabled == 0 */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E544"),
+   },
+   },
+   {
/* Fujitsu LIFEBOOK E554  does not work with crc_enabled == 0 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
@@ -1524,10 +1531,10 @@ static const struct dmi_system_id 
elantech_dmi_force_crc_enabled[] = {
},
},
{
-   /* Fujitsu LIFEBOOK E544  does not work with crc_enabled == 0 */
+   /* Fujitsu LIFEBOOK E556 does not work with crc_enabled == 0 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
-   DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E544"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E556"),
},
},
{
-- 
2.8.0.rc3.226.g39d4020


-- 
Dmitry

[PATCH] Input: elantech - add Fujitsu Lifebook E556 to force crc_enabled

[Dmitry Torokhov]

Another Lifebook machine that needs the same quirk as other similar
models to make the driver working.

Also let's reorder elantech_dmi_force_crc_enabled list so LIfebook enries
are in alphabetical order.

Reported-by: William Linna 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/mouse/elantech.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 37b52f1..db7d1d6 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1517,6 +1517,13 @@ static const struct dmi_system_id 
elantech_dmi_force_crc_enabled[] = {
},
},
{
+   /* Fujitsu LIFEBOOK E544  does not work with crc_enabled == 0 */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E544"),
+   },
+   },
+   {
/* Fujitsu LIFEBOOK E554  does not work with crc_enabled == 0 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
@@ -1524,10 +1531,10 @@ static const struct dmi_system_id 
elantech_dmi_force_crc_enabled[] = {
},
},
{
-   /* Fujitsu LIFEBOOK E544  does not work with crc_enabled == 0 */
+   /* Fujitsu LIFEBOOK E556 does not work with crc_enabled == 0 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
-   DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E544"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E556"),
},
},
{
-- 
2.8.0.rc3.226.g39d4020


-- 
Dmitry

[GIT] Networking

[David Miller]

Here are the build and merge fixups for the networking
stuff.

Please pull, thanks a lot!

The following changes since commit 41844e36206be90cd4d962ea49b0abc3612a99d0:

  Merge tag 'staging-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging (2016-10-05 
14:50:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to af70c1f92d3567035d2f73f39079459d58c706dc:

  phy: micrel.c: Enable ksz9031 energy-detect power-down mode (2016-10-05 
21:19:06 -0400)


Aaron Conole (2):
  netfilter: Fix potential null pointer dereference
  netfilter: accommodate different kconfig in nf_set_hooks_head

David S. Miller (1):
  Merge git://git.kernel.org/.../pablo/nf-next

Jann Horn (1):
  netfilter: fix namespace handling in nf_log_proc_dostring

Liping Zhang (1):
  netfilter: nft_limit: fix divided by zero panic

Mike Looijmans (1):
  phy: micrel.c: Enable ksz9031 energy-detect power-down mode

Stephen Rothwell (1):
  netfilter: merge fixup for "nf_tables_netdev: remove redundant ip_hdr 
assignment"

Vishwanath Pai (1):
  netfilter: xt_hashlimit: Fix link error in 32bit arch because of 64bit 
division

 drivers/net/phy/micrel.c   | 21 +
 include/net/netfilter/nf_tables_ipv4.h |  1 -
 net/netfilter/core.c   | 17 -
 net/netfilter/nf_log.c |  6 --
 net/netfilter/nft_limit.c  |  4 ++--
 net/netfilter/xt_hashlimit.c   | 15 ---
 6 files changed, 47 insertions(+), 17 deletions(-)

[GIT] Networking

[David Miller]

Here are the build and merge fixups for the networking
stuff.

Please pull, thanks a lot!

The following changes since commit 41844e36206be90cd4d962ea49b0abc3612a99d0:

  Merge tag 'staging-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging (2016-10-05 
14:50:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to af70c1f92d3567035d2f73f39079459d58c706dc:

  phy: micrel.c: Enable ksz9031 energy-detect power-down mode (2016-10-05 
21:19:06 -0400)


Aaron Conole (2):
  netfilter: Fix potential null pointer dereference
  netfilter: accommodate different kconfig in nf_set_hooks_head

David S. Miller (1):
  Merge git://git.kernel.org/.../pablo/nf-next

Jann Horn (1):
  netfilter: fix namespace handling in nf_log_proc_dostring

Liping Zhang (1):
  netfilter: nft_limit: fix divided by zero panic

Mike Looijmans (1):
  phy: micrel.c: Enable ksz9031 energy-detect power-down mode

Stephen Rothwell (1):
  netfilter: merge fixup for "nf_tables_netdev: remove redundant ip_hdr 
assignment"

Vishwanath Pai (1):
  netfilter: xt_hashlimit: Fix link error in 32bit arch because of 64bit 
division

 drivers/net/phy/micrel.c   | 21 +
 include/net/netfilter/nf_tables_ipv4.h |  1 -
 net/netfilter/core.c   | 17 -
 net/netfilter/nf_log.c |  6 --
 net/netfilter/nft_limit.c  |  4 ++--
 net/netfilter/xt_hashlimit.c   | 15 ---
 6 files changed, 47 insertions(+), 17 deletions(-)

Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

[Davidlohr Bueso]

On Wed, 05 Oct 2016, Waiman Long wrote:


diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 05a3785..1e6823a 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -12,6 +12,23 @@
 */
static DEFINE_PER_CPU_SHARED_ALIGNED(struct optimistic_spin_node, 
osq_node);


+enum mbtype {
+acquire,
+release,
+relaxed,
+};


No, please.


+
+static __always_inline int
+_atomic_cmpxchg_(const enum mbtype barrier, atomic_t *v, int old, int new)
+{
+if (barrier == acquire)
+return atomic_cmpxchg_acquire(v, old, new);
+else if (barrier == release)
+return atomic_cmpxchg_release(v, old, new);
+else
+return atomic_cmpxchg_relaxed(v, old, new);
+}


Things like the above are icky. How about something like below? I'm not
crazy about it, but there are other similar macros, ie lockref. We still
provide the osq_lock/unlock to imply acquire/release and the new _relaxed
flavor, as I agree that should be the correct naming

While I have not touched osq_wait_next(), the following are impacted:

- node->locked is now completely without ordering for _relaxed() (currently
its under smp_load_acquire, which does not match and the race is harmless
to begin with as we just iterate again. For the acquire flavor, it is always
formed with ctr dep + smp_rmb().

- If osq_lock() fails we never guarantee any ordering.

What do you think?

Thanks,
Davidlohr


diff --git a/include/linux/osq_lock.h b/include/linux/osq_lock.h
index 703ea5c30a33..183ee51e6e54 100644
--- a/include/linux/osq_lock.h
+++ b/include/linux/osq_lock.h
@@ -29,9 +29,20 @@ static inline void osq_lock_init(struct 
optimistic_spin_queue *lock)
atomic_set(>tail, OSQ_UNLOCKED_VAL);
}

+/*
+ * Versions of osq_lock/unlock that do not imply or guarantee (load)-ACQUIRE
+ * (store)-RELEASE barrier semantics.
+ *
+ * Note that a failed call to either osq_lock() or osq_lock_relaxed() does
+ * not imply barriers... we are next to block.
+ */
+extern bool osq_lock_relaxed(struct optimistic_spin_queue *lock);
+extern void osq_unlock_relaxed(struct optimistic_spin_queue *lock);
+
extern bool osq_lock(struct optimistic_spin_queue *lock);
extern void osq_unlock(struct optimistic_spin_queue *lock);

+
static inline bool osq_is_locked(struct optimistic_spin_queue *lock)
{
return atomic_read(>tail) != OSQ_UNLOCKED_VAL;
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index a70b90db3909..b1bf1e057565 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -316,7 +316,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
 * acquire the mutex all at once, the spinners need to take a
 * MCS (queued) lock first before spinning on the owner field.
 */
-   if (!osq_lock(>osq))
+   if (!osq_lock_relaxed(>osq))
goto done;

while (true) {
@@ -358,7 +358,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
}

mutex_set_owner(lock);
-   osq_unlock(>osq);
+   osq_unlock_relaxed(>osq);
return true;
}

@@ -380,7 +380,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
cpu_relax_lowlatency();
}

-   osq_unlock(>osq);
+   osq_unlock_relaxed(>osq);
done:
/*
 * If we fell out of the spin path because of need_resched(),
diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 05a37857ab55..8c3d57698702 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -28,6 +28,17 @@ static inline struct optimistic_spin_node *decode_cpu(int 
encoded_cpu_val)
return per_cpu_ptr(_node, cpu_nr);
}

+static inline void set_node_locked_release(struct optimistic_spin_node *node)
+{
+   smp_store_release(>locked, 1);
+}
+
+static inline void set_node_locked_relaxed(struct optimistic_spin_node *node)
+{
+   WRITE_ONCE(node->locked, 1);
+
+}
+
/*
 * Get a stable @node->next pointer, either for unlock() or unqueue() purposes.
 * Can return NULL in case we were the last queued and we updated @lock instead.
@@ -81,130 +92,140 @@ osq_wait_next(struct optimistic_spin_queue *lock,
return next;
}

-bool osq_lock(struct optimistic_spin_queue *lock)
-{
-   struct optimistic_spin_node *node = this_cpu_ptr(_node);
-   struct optimistic_spin_node *prev, *next;
-   int curr = encode_cpu(smp_processor_id());
-   int old;
-
-   node->locked = 0;
-   node->next = NULL;
-   node->cpu = curr;
-
-   /*
-* We need both ACQUIRE (pairs with corresponding RELEASE in
-* unlock() uncontended, or fastpath) and RELEASE (to publish
-* the node fields we just initialised) semantics when updating
-* the lock tail.
-*/
-   old = atomic_xchg(>tail, curr);
-   if (old == OSQ_UNLOCKED_VAL)
-   return true;
-
-   prev = decode_cpu(old);
-   

[PATCH] Added Support for STMicroelectronics 16 channels LED7708 LED Driver

[Saurabh Rawat]

---
 .../devicetree/bindings/leds/leds-st.txt   |  105 ++
 KERNEL/Documentation/leds/leds-st7708.txt  |  167 +++
 KERNEL/drivers/leds/leds-st.c  | 1210 
 KERNEL/include/linux/platform_data/leds-st.h   |  170 +++
 patches/defconfig  |3 +-
 5 files changed, 1654 insertions(+), 1 deletion(-)
 create mode 100644 KERNEL/Documentation/devicetree/bindings/leds/leds-st.txt
 create mode 100644 KERNEL/Documentation/leds/leds-st7708.txt
 create mode 100644 KERNEL/drivers/leds/leds-st.c
 create mode 100644 KERNEL/include/linux/platform_data/leds-st.h

diff --git a/KERNEL/Documentation/devicetree/bindings/leds/leds-st.txt 
b/KERNEL/Documentation/devicetree/bindings/leds/leds-st.txt
new file mode 100644
index 000..dde53f9
--- /dev/null
+++ b/KERNEL/Documentation/devicetree/bindings/leds/leds-st.txt
@@ -0,0 +1,105 @@
+STMicroelectronics LED7708 Driver connected to BeagleboneBlack.This can be 
customized for any other
+hardware platform running linux depending on available free GPIOS
+
+Required properties:
+- compatible : should be : "st,st-leds".
+- sdo-gpio :contains a single GPIO specifier for the GPIO which is used for 
master to slave data OUT data.
+- sdi-gpio: contains a single GPIO specifier for the GPIO which is used for 
master to slave data IN data.
+- le-gpios: contains a single GPIO specifier for the GPIO which is used for 
Latch Enable data.
+- lren-gpios: contains a single GPIO specifier for the GPIO which is used for 
Lren data.This has to be High for Device to Operate.
+- sck-gpio: contains a single GPIO specifier for the GPIO which is used for 
the clock pin.
+- chanx :For controlling each LED channel Independently 
+- chan-common: For controlling all the 16 channels in a single shot.
+
+Optional properties:
+ - None
+
+Example:
+
+st-leds {
+compatible = "st,st-leds";
+sdo-gpio = < 16 1>;
+sdi-gpio = < 28 1>;
+le-gpio = < 21 1>;
+lren-gpio = < 19 1>;
+sck-gpio = < 17 1>;
+
+chan1 {
+
+chan-name = "led7708-chan1";
+};
+
+chan2 {
+
+chan-name = "led7708-chan2";
+};
+chan3 {
+
+chan-name = "led7708-chan3";
+};
+
+chan4 {
+
+chan-name = "led7708-chan4";
+};
+chan5 {
+
+chan-name = "led7708-chan5";
+};
+
+chan6 {
+
+chan-name = "led7708-chan6";
+};
+chan7 {
+
+chan-name = "led7708-chan7";
+};
+
+chan8 {
+
+chan-name = "led7708-chan8";
+};
+
+chan9 {
+
+chan-name = "led7708-chan9";
+   };
+   
+   chan10 {
+   
+   chan-name = "led7708-chan10";
+   };
+   chan11 {
+   
+   chan-name = "led7708-chan11";
+   };
+   
+   chan12 {
+   
+   chan-name = "led7708-chan12";
+   };
+   chan13 {
+   
+   chan-name = "led7708-chan13";
+   };
+   
+   chan14 {
+   
+   chan-name = "led7708-chan14";
+   };
+   chan15 {
+   
+   chan-name = "led7708-chan15";
+   };
+   
+   chan16 {
+   
+   chan-name = "led7708-chan16";
+   };
+   
+   chan-common {
+   
+   chan-name = "led7708-chan-comm";
+   };
+};
diff --git a/KERNEL/Documentation/leds/leds-st7708.txt 
b/KERNEL/Documentation/leds/leds-st7708.txt
new file mode 100644
index 000..c1725ab
--- /dev/null
+++ b/KERNEL/Documentation/leds/leds-st7708.txt
@@ -0,0 +1,167 @@
+Kernel driver for led7708
+===
+
+* STMicroelectronics LED7708 Driver
+* Datasheet: www.st.com/resource/en/datasheet/led7708.pdf
+
+Authors: Saurabh Rawat
+Contact: Saurabh Rawat (saurabh.rawat-at-st.com)
+
+Description
+
+LED7708 is a simple 16 channels LED driver hardware from STMicroelectronics. 
Leds can be controlled directly via
+the led class control interface.
+Each channel can be controlled independently in two modes - group-dimming mode 
or gray-scale dimming mode.
+In group dimming mode writing brightness to any one channel will configure the 
brightness of all the channels 
+with the same brightness.This mode is enabled by default in the driver.
+In gray scale dimming mode each channel can be configured to have different 
brightness values and all the channels
+can be controlled in one shot.
+
+Follow these steps to configure the LED7708 channels in goup-dimming mode
+- Either select the channels from the sysfs by channel mask  e.g ff00 -> echo 
ff00 > led_7708_select_channel for 9-16 channels 
+  

Re: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

[Davidlohr Bueso]

On Wed, 05 Oct 2016, Waiman Long wrote:


diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 05a3785..1e6823a 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -12,6 +12,23 @@
 */
static DEFINE_PER_CPU_SHARED_ALIGNED(struct optimistic_spin_node, 
osq_node);


+enum mbtype {
+acquire,
+release,
+relaxed,
+};


No, please.


+
+static __always_inline int
+_atomic_cmpxchg_(const enum mbtype barrier, atomic_t *v, int old, int new)
+{
+if (barrier == acquire)
+return atomic_cmpxchg_acquire(v, old, new);
+else if (barrier == release)
+return atomic_cmpxchg_release(v, old, new);
+else
+return atomic_cmpxchg_relaxed(v, old, new);
+}


Things like the above are icky. How about something like below? I'm not
crazy about it, but there are other similar macros, ie lockref. We still
provide the osq_lock/unlock to imply acquire/release and the new _relaxed
flavor, as I agree that should be the correct naming

While I have not touched osq_wait_next(), the following are impacted:

- node->locked is now completely without ordering for _relaxed() (currently
its under smp_load_acquire, which does not match and the race is harmless
to begin with as we just iterate again. For the acquire flavor, it is always
formed with ctr dep + smp_rmb().

- If osq_lock() fails we never guarantee any ordering.

What do you think?

Thanks,
Davidlohr


diff --git a/include/linux/osq_lock.h b/include/linux/osq_lock.h
index 703ea5c30a33..183ee51e6e54 100644
--- a/include/linux/osq_lock.h
+++ b/include/linux/osq_lock.h
@@ -29,9 +29,20 @@ static inline void osq_lock_init(struct 
optimistic_spin_queue *lock)
atomic_set(>tail, OSQ_UNLOCKED_VAL);
}

+/*
+ * Versions of osq_lock/unlock that do not imply or guarantee (load)-ACQUIRE
+ * (store)-RELEASE barrier semantics.
+ *
+ * Note that a failed call to either osq_lock() or osq_lock_relaxed() does
+ * not imply barriers... we are next to block.
+ */
+extern bool osq_lock_relaxed(struct optimistic_spin_queue *lock);
+extern void osq_unlock_relaxed(struct optimistic_spin_queue *lock);
+
extern bool osq_lock(struct optimistic_spin_queue *lock);
extern void osq_unlock(struct optimistic_spin_queue *lock);

+
static inline bool osq_is_locked(struct optimistic_spin_queue *lock)
{
return atomic_read(>tail) != OSQ_UNLOCKED_VAL;
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index a70b90db3909..b1bf1e057565 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -316,7 +316,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
 * acquire the mutex all at once, the spinners need to take a
 * MCS (queued) lock first before spinning on the owner field.
 */
-   if (!osq_lock(>osq))
+   if (!osq_lock_relaxed(>osq))
goto done;

while (true) {
@@ -358,7 +358,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
}

mutex_set_owner(lock);
-   osq_unlock(>osq);
+   osq_unlock_relaxed(>osq);
return true;
}

@@ -380,7 +380,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
cpu_relax_lowlatency();
}

-   osq_unlock(>osq);
+   osq_unlock_relaxed(>osq);
done:
/*
 * If we fell out of the spin path because of need_resched(),
diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 05a37857ab55..8c3d57698702 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -28,6 +28,17 @@ static inline struct optimistic_spin_node *decode_cpu(int 
encoded_cpu_val)
return per_cpu_ptr(_node, cpu_nr);
}

+static inline void set_node_locked_release(struct optimistic_spin_node *node)
+{
+   smp_store_release(>locked, 1);
+}
+
+static inline void set_node_locked_relaxed(struct optimistic_spin_node *node)
+{
+   WRITE_ONCE(node->locked, 1);
+
+}
+
/*
 * Get a stable @node->next pointer, either for unlock() or unqueue() purposes.
 * Can return NULL in case we were the last queued and we updated @lock instead.
@@ -81,130 +92,140 @@ osq_wait_next(struct optimistic_spin_queue *lock,
return next;
}

-bool osq_lock(struct optimistic_spin_queue *lock)
-{
-   struct optimistic_spin_node *node = this_cpu_ptr(_node);
-   struct optimistic_spin_node *prev, *next;
-   int curr = encode_cpu(smp_processor_id());
-   int old;
-
-   node->locked = 0;
-   node->next = NULL;
-   node->cpu = curr;
-
-   /*
-* We need both ACQUIRE (pairs with corresponding RELEASE in
-* unlock() uncontended, or fastpath) and RELEASE (to publish
-* the node fields we just initialised) semantics when updating
-* the lock tail.
-*/
-   old = atomic_xchg(>tail, curr);
-   if (old == OSQ_UNLOCKED_VAL)
-   return true;
-
-   prev = decode_cpu(old);
-   

[PATCH] Added Support for STMicroelectronics 16 channels LED7708 LED Driver

[Saurabh Rawat]

---
 .../devicetree/bindings/leds/leds-st.txt   |  105 ++
 KERNEL/Documentation/leds/leds-st7708.txt  |  167 +++
 KERNEL/drivers/leds/leds-st.c  | 1210 
 KERNEL/include/linux/platform_data/leds-st.h   |  170 +++
 patches/defconfig  |3 +-
 5 files changed, 1654 insertions(+), 1 deletion(-)
 create mode 100644 KERNEL/Documentation/devicetree/bindings/leds/leds-st.txt
 create mode 100644 KERNEL/Documentation/leds/leds-st7708.txt
 create mode 100644 KERNEL/drivers/leds/leds-st.c
 create mode 100644 KERNEL/include/linux/platform_data/leds-st.h

diff --git a/KERNEL/Documentation/devicetree/bindings/leds/leds-st.txt 
b/KERNEL/Documentation/devicetree/bindings/leds/leds-st.txt
new file mode 100644
index 000..dde53f9
--- /dev/null
+++ b/KERNEL/Documentation/devicetree/bindings/leds/leds-st.txt
@@ -0,0 +1,105 @@
+STMicroelectronics LED7708 Driver connected to BeagleboneBlack.This can be 
customized for any other
+hardware platform running linux depending on available free GPIOS
+
+Required properties:
+- compatible : should be : "st,st-leds".
+- sdo-gpio :contains a single GPIO specifier for the GPIO which is used for 
master to slave data OUT data.
+- sdi-gpio: contains a single GPIO specifier for the GPIO which is used for 
master to slave data IN data.
+- le-gpios: contains a single GPIO specifier for the GPIO which is used for 
Latch Enable data.
+- lren-gpios: contains a single GPIO specifier for the GPIO which is used for 
Lren data.This has to be High for Device to Operate.
+- sck-gpio: contains a single GPIO specifier for the GPIO which is used for 
the clock pin.
+- chanx :For controlling each LED channel Independently 
+- chan-common: For controlling all the 16 channels in a single shot.
+
+Optional properties:
+ - None
+
+Example:
+
+st-leds {
+compatible = "st,st-leds";
+sdo-gpio = < 16 1>;
+sdi-gpio = < 28 1>;
+le-gpio = < 21 1>;
+lren-gpio = < 19 1>;
+sck-gpio = < 17 1>;
+
+chan1 {
+
+chan-name = "led7708-chan1";
+};
+
+chan2 {
+
+chan-name = "led7708-chan2";
+};
+chan3 {
+
+chan-name = "led7708-chan3";
+};
+
+chan4 {
+
+chan-name = "led7708-chan4";
+};
+chan5 {
+
+chan-name = "led7708-chan5";
+};
+
+chan6 {
+
+chan-name = "led7708-chan6";
+};
+chan7 {
+
+chan-name = "led7708-chan7";
+};
+
+chan8 {
+
+chan-name = "led7708-chan8";
+};
+
+chan9 {
+
+chan-name = "led7708-chan9";
+   };
+   
+   chan10 {
+   
+   chan-name = "led7708-chan10";
+   };
+   chan11 {
+   
+   chan-name = "led7708-chan11";
+   };
+   
+   chan12 {
+   
+   chan-name = "led7708-chan12";
+   };
+   chan13 {
+   
+   chan-name = "led7708-chan13";
+   };
+   
+   chan14 {
+   
+   chan-name = "led7708-chan14";
+   };
+   chan15 {
+   
+   chan-name = "led7708-chan15";
+   };
+   
+   chan16 {
+   
+   chan-name = "led7708-chan16";
+   };
+   
+   chan-common {
+   
+   chan-name = "led7708-chan-comm";
+   };
+};
diff --git a/KERNEL/Documentation/leds/leds-st7708.txt 
b/KERNEL/Documentation/leds/leds-st7708.txt
new file mode 100644
index 000..c1725ab
--- /dev/null
+++ b/KERNEL/Documentation/leds/leds-st7708.txt
@@ -0,0 +1,167 @@
+Kernel driver for led7708
+===
+
+* STMicroelectronics LED7708 Driver
+* Datasheet: www.st.com/resource/en/datasheet/led7708.pdf
+
+Authors: Saurabh Rawat
+Contact: Saurabh Rawat (saurabh.rawat-at-st.com)
+
+Description
+
+LED7708 is a simple 16 channels LED driver hardware from STMicroelectronics. 
Leds can be controlled directly via
+the led class control interface.
+Each channel can be controlled independently in two modes - group-dimming mode 
or gray-scale dimming mode.
+In group dimming mode writing brightness to any one channel will configure the 
brightness of all the channels 
+with the same brightness.This mode is enabled by default in the driver.
+In gray scale dimming mode each channel can be configured to have different 
brightness values and all the channels
+can be controlled in one shot.
+
+Follow these steps to configure the LED7708 channels in goup-dimming mode
+- Either select the channels from the sysfs by channel mask  e.g ff00 -> echo 
ff00 > led_7708_select_channel for 9-16 channels 
+  

Re: [PATCH] sparc: migrate exception table users off module.h and onto extable.h

[David Miller]

From: Paul Gortmaker 
Date: Mon, 19 Sep 2016 17:36:29 -0400

> These files were only including module.h for exception table
> related functions.  We've now separated that content out into its
> own file "extable.h" so now move over to that and avoid all the
> extra header content in module.h that we don't really need to compile
> these files.
> 
> Cc: "David S. Miller" 
> Cc: sparcli...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Applied.

Re: [PATCH] sparc: migrate exception table users off module.h and onto extable.h

[David Miller]

From: Paul Gortmaker 
Date: Mon, 19 Sep 2016 17:36:29 -0400

> These files were only including module.h for exception table
> related functions.  We've now separated that content out into its
> own file "extable.h" so now move over to that and avoid all the
> extra header content in module.h that we don't really need to compile
> these files.
> 
> Cc: "David S. Miller" 
> Cc: sparcli...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Applied.

[git pull] Input updates for 4.9-rc0

[Dmitry Torokhov]

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. You will get new driver for
Elan eKTF2127 touchscreen controllers; a new "gpio-decoder" driver to
read and report state of several GPIO lines; an ADC resistor ladder
driver; the ft6326 driver is removed because edt-ft5x06 handles the same
devices just fine. Plus regular slew of driver fixes/enhancements. 

Changelog:
-

Alexandre Belloni (1):
  Input: add ADC resistor ladder driver

Arnd Bergmann (1):
  Input: ektf2127 - mark PM functions as __maybe_unused

Axel Lin (1):
  Input: snvs_pwrkey - drop input_free_device call if input_register_device 
fails

Baoyou Xie (1):
  Input: focaltech - mark focaltech_set_resolution() static

Benjamin Tissoires (1):
  Input: elan_i2c - fix return tests of i2c_smbus_read_block_data()

Bhaktipriya Shridhar (3):
  Input: psmouse - remove deprecated create_singletheread_workqueue
  Input: mc13783_ts - remove deprecated create_singletheread_workqueue
  Input: wm97xx - remove deprecated create_singletheread_workqueue

Dmitry Torokhov (1):
  Input: jornada720_kbd - switch to using dev_dbg

Hans Verkuil (1):
  Input: serio - add hangup support

Hans de Goede (1):
  Input: remove duplicate ft6236 driver

HungNien Chen (1):
  Input: wdt87xx_i2c - fix the flash erase issue

Johnny Chuang (1):
  Input: elants_i2c - get product id on recovery mode for FW update

Krzysztof Kozlowski (1):
  Input: max77693-haptic - change Krzysztof Kozlowski's email to kernel.org

LABBE Corentin (3):
  Input: pixcir_i2c_ts - simplify code with of_device_get_match_data
  Input: pixcir_i2c_ts - remove text about writing to Free Software 
Foundation
  Input: pixcir_i2c_ts - remove a useless blank line

Marcin Niestroj (1):
  Input: tps65218-pwrbutton - add support for tps65217 variant

Martin Kepplinger (1):
  Input: pegasus_notetaker - directly include workqueue header

Russell King (4):
  Input: jornada720_kbd - switch to devm_* APIs
  Input: jornada720_kbd - get rid of mach/irqs.h include
  Input: jornada720_kbd - remove unneeded mach/hardware.h include
  Input: jornada720_ts - get rid of mach/irqs.h and mach/hardware.h includes

Siebren Vroegindeweij (1):
  Input: add support for Elan eKTF2127 touchscreen controller

Vignesh R (1):
  Input: add generic input driver to read encoded GPIO lines

Vladimir Zapolskiy (1):
  Input: gpio-keys-polled - don't use unit-address with button nodes


Diffstat:


 .../devicetree/bindings/input/adc-keys.txt |  49 +++
 .../devicetree/bindings/input/gpio-decoder.txt |  23 ++
 .../devicetree/bindings/input/gpio-keys-polled.txt |   5 +-
 .../bindings/input/touchscreen/edt-ft5x06.txt  |   8 +
 .../bindings/input/touchscreen/ektf2127.txt|  27 ++
 .../input/touchscreen/focaltech-ft6236.txt |  35 ---
 .../bindings/input/tps65218-pwrbutton.txt  |  17 +-
 arch/arm/mach-sa1100/jornada720.c  |  16 +
 drivers/input/keyboard/Kconfig |  15 +
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/adc-keys.c  | 210 +
 drivers/input/keyboard/jornada720_kbd.c|  59 +---
 drivers/input/keyboard/snvs_pwrkey.c   |   1 -
 drivers/input/misc/Kconfig |  16 +-
 drivers/input/misc/Makefile|   1 +
 drivers/input/misc/gpio_decoder.c  | 137 +
 drivers/input/misc/max77693-haptic.c   |   4 +-
 drivers/input/misc/tps65218-pwrbutton.c|  92 --
 drivers/input/mouse/elan_i2c_smbus.c   |  20 +-
 drivers/input/mouse/focaltech.c|   3 +-
 drivers/input/mouse/psmouse-base.c |   2 +-
 drivers/input/serio/serport.c  |  17 +-
 drivers/input/tablet/pegasus_notetaker.c   |   1 +
 drivers/input/touchscreen/Kconfig  |  25 +-
 drivers/input/touchscreen/Makefile |   2 +-
 drivers/input/touchscreen/edt-ft5x06.c |   8 +
 drivers/input/touchscreen/ektf2127.c   | 336 +
 drivers/input/touchscreen/elants_i2c.c |  31 +-
 drivers/input/touchscreen/ft6236.c | 326 
 drivers/input/touchscreen/jornada720_ts.c  |  21 +-
 drivers/input/touchscreen/mc13783_ts.c |  24 +-
 drivers/input/touchscreen/pixcir_i2c_ts.c  |  13 +-
 drivers/input/touchscreen/wdt87xx_i2c.c|   5 +-
 drivers/input/touchscreen/wm97xx-core.c|   2 +-
 34 files changed, 1033 insertions(+), 519 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
 create mode 100644 Documentation/devicetree/bindings/input/gpio-decoder.txt
 create mode 100644 

[git pull] Input updates for 4.9-rc0

[Dmitry Torokhov]

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. You will get new driver for
Elan eKTF2127 touchscreen controllers; a new "gpio-decoder" driver to
read and report state of several GPIO lines; an ADC resistor ladder
driver; the ft6326 driver is removed because edt-ft5x06 handles the same
devices just fine. Plus regular slew of driver fixes/enhancements. 

Changelog:
-

Alexandre Belloni (1):
  Input: add ADC resistor ladder driver

Arnd Bergmann (1):
  Input: ektf2127 - mark PM functions as __maybe_unused

Axel Lin (1):
  Input: snvs_pwrkey - drop input_free_device call if input_register_device 
fails

Baoyou Xie (1):
  Input: focaltech - mark focaltech_set_resolution() static

Benjamin Tissoires (1):
  Input: elan_i2c - fix return tests of i2c_smbus_read_block_data()

Bhaktipriya Shridhar (3):
  Input: psmouse - remove deprecated create_singletheread_workqueue
  Input: mc13783_ts - remove deprecated create_singletheread_workqueue
  Input: wm97xx - remove deprecated create_singletheread_workqueue

Dmitry Torokhov (1):
  Input: jornada720_kbd - switch to using dev_dbg

Hans Verkuil (1):
  Input: serio - add hangup support

Hans de Goede (1):
  Input: remove duplicate ft6236 driver

HungNien Chen (1):
  Input: wdt87xx_i2c - fix the flash erase issue

Johnny Chuang (1):
  Input: elants_i2c - get product id on recovery mode for FW update

Krzysztof Kozlowski (1):
  Input: max77693-haptic - change Krzysztof Kozlowski's email to kernel.org

LABBE Corentin (3):
  Input: pixcir_i2c_ts - simplify code with of_device_get_match_data
  Input: pixcir_i2c_ts - remove text about writing to Free Software 
Foundation
  Input: pixcir_i2c_ts - remove a useless blank line

Marcin Niestroj (1):
  Input: tps65218-pwrbutton - add support for tps65217 variant

Martin Kepplinger (1):
  Input: pegasus_notetaker - directly include workqueue header

Russell King (4):
  Input: jornada720_kbd - switch to devm_* APIs
  Input: jornada720_kbd - get rid of mach/irqs.h include
  Input: jornada720_kbd - remove unneeded mach/hardware.h include
  Input: jornada720_ts - get rid of mach/irqs.h and mach/hardware.h includes

Siebren Vroegindeweij (1):
  Input: add support for Elan eKTF2127 touchscreen controller

Vignesh R (1):
  Input: add generic input driver to read encoded GPIO lines

Vladimir Zapolskiy (1):
  Input: gpio-keys-polled - don't use unit-address with button nodes


Diffstat:


 .../devicetree/bindings/input/adc-keys.txt |  49 +++
 .../devicetree/bindings/input/gpio-decoder.txt |  23 ++
 .../devicetree/bindings/input/gpio-keys-polled.txt |   5 +-
 .../bindings/input/touchscreen/edt-ft5x06.txt  |   8 +
 .../bindings/input/touchscreen/ektf2127.txt|  27 ++
 .../input/touchscreen/focaltech-ft6236.txt |  35 ---
 .../bindings/input/tps65218-pwrbutton.txt  |  17 +-
 arch/arm/mach-sa1100/jornada720.c  |  16 +
 drivers/input/keyboard/Kconfig |  15 +
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/adc-keys.c  | 210 +
 drivers/input/keyboard/jornada720_kbd.c|  59 +---
 drivers/input/keyboard/snvs_pwrkey.c   |   1 -
 drivers/input/misc/Kconfig |  16 +-
 drivers/input/misc/Makefile|   1 +
 drivers/input/misc/gpio_decoder.c  | 137 +
 drivers/input/misc/max77693-haptic.c   |   4 +-
 drivers/input/misc/tps65218-pwrbutton.c|  92 --
 drivers/input/mouse/elan_i2c_smbus.c   |  20 +-
 drivers/input/mouse/focaltech.c|   3 +-
 drivers/input/mouse/psmouse-base.c |   2 +-
 drivers/input/serio/serport.c  |  17 +-
 drivers/input/tablet/pegasus_notetaker.c   |   1 +
 drivers/input/touchscreen/Kconfig  |  25 +-
 drivers/input/touchscreen/Makefile |   2 +-
 drivers/input/touchscreen/edt-ft5x06.c |   8 +
 drivers/input/touchscreen/ektf2127.c   | 336 +
 drivers/input/touchscreen/elants_i2c.c |  31 +-
 drivers/input/touchscreen/ft6236.c | 326 
 drivers/input/touchscreen/jornada720_ts.c  |  21 +-
 drivers/input/touchscreen/mc13783_ts.c |  24 +-
 drivers/input/touchscreen/pixcir_i2c_ts.c  |  13 +-
 drivers/input/touchscreen/wdt87xx_i2c.c|   5 +-
 drivers/input/touchscreen/wm97xx-core.c|   2 +-
 34 files changed, 1033 insertions(+), 519 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
 create mode 100644 Documentation/devicetree/bindings/input/gpio-decoder.txt
 create mode 100644 

[PATCH] x86/unwind: fix oprofile module link error

[Josh Poimboeuf]

When compiling on x86 with CONFIG_OPROFILE=m and CONFIG_FRAME_POINTER=n,
the oprofile module fails to link:

  ERROR: ftrace_graph_ret_addr" [arch/x86/oprofile/oprofile.ko] undefined!

The problem was introduced when oprofile was converted to use the new
x86 unwinder.  When frame pointers are disabled, the "guess" unwinder's
unwind_get_return_address() is an inline function which calls
ftrace_graph_ret_addr(), which is not exported.

Fix it by converting the "guess" version of unwind_get_return_address()
to an exported out-of-line function, just like its frame pointer
counterpart.

Fixes: ec2ad9ccf12d ("oprofile/x86: Convert x86_backtrace() to use the new 
unwinder")
Reported-by: Karl Beldan 
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/include/asm/unwind.h  | 14 ++
 arch/x86/kernel/unwind_guess.c | 10 ++
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/unwind.h b/arch/x86/include/asm/unwind.h
index c4b6d1c..46de9ac 100644
--- a/arch/x86/include/asm/unwind.h
+++ b/arch/x86/include/asm/unwind.h
@@ -23,6 +23,8 @@ void __unwind_start(struct unwind_state *state, struct 
task_struct *task,
 
 bool unwind_next_frame(struct unwind_state *state);
 
+unsigned long unwind_get_return_address(struct unwind_state *state);
+
 static inline bool unwind_done(struct unwind_state *state)
 {
return state->stack_info.type == STACK_TYPE_UNKNOWN;
@@ -48,8 +50,6 @@ unsigned long *unwind_get_return_address_ptr(struct 
unwind_state *state)
return state->bp + 1;
 }
 
-unsigned long unwind_get_return_address(struct unwind_state *state);
-
 #else /* !CONFIG_FRAME_POINTER */
 
 static inline
@@ -58,16 +58,6 @@ unsigned long *unwind_get_return_address_ptr(struct 
unwind_state *state)
return NULL;
 }
 
-static inline
-unsigned long unwind_get_return_address(struct unwind_state *state)
-{
-   if (unwind_done(state))
-   return 0;
-
-   return ftrace_graph_ret_addr(state->task, >graph_idx,
-*state->sp, state->sp);
-}
-
 #endif /* CONFIG_FRAME_POINTER */
 
 #endif /* _ASM_X86_UNWIND_H */
diff --git a/arch/x86/kernel/unwind_guess.c b/arch/x86/kernel/unwind_guess.c
index b5a834c..9298993 100644
--- a/arch/x86/kernel/unwind_guess.c
+++ b/arch/x86/kernel/unwind_guess.c
@@ -5,6 +5,16 @@
 #include 
 #include 
 
+unsigned long unwind_get_return_address(struct unwind_state *state)
+{
+   if (unwind_done(state))
+   return 0;
+
+   return ftrace_graph_ret_addr(state->task, >graph_idx,
+*state->sp, state->sp);
+}
+EXPORT_SYMBOL_GPL(unwind_get_return_address);
+
 bool unwind_next_frame(struct unwind_state *state)
 {
struct stack_info *info = >stack_info;
-- 
2.7.4

[PATCH] x86/unwind: fix oprofile module link error

[Josh Poimboeuf]

When compiling on x86 with CONFIG_OPROFILE=m and CONFIG_FRAME_POINTER=n,
the oprofile module fails to link:

  ERROR: ftrace_graph_ret_addr" [arch/x86/oprofile/oprofile.ko] undefined!

The problem was introduced when oprofile was converted to use the new
x86 unwinder.  When frame pointers are disabled, the "guess" unwinder's
unwind_get_return_address() is an inline function which calls
ftrace_graph_ret_addr(), which is not exported.

Fix it by converting the "guess" version of unwind_get_return_address()
to an exported out-of-line function, just like its frame pointer
counterpart.

Fixes: ec2ad9ccf12d ("oprofile/x86: Convert x86_backtrace() to use the new 
unwinder")
Reported-by: Karl Beldan 
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/include/asm/unwind.h  | 14 ++
 arch/x86/kernel/unwind_guess.c | 10 ++
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/unwind.h b/arch/x86/include/asm/unwind.h
index c4b6d1c..46de9ac 100644
--- a/arch/x86/include/asm/unwind.h
+++ b/arch/x86/include/asm/unwind.h
@@ -23,6 +23,8 @@ void __unwind_start(struct unwind_state *state, struct 
task_struct *task,
 
 bool unwind_next_frame(struct unwind_state *state);
 
+unsigned long unwind_get_return_address(struct unwind_state *state);
+
 static inline bool unwind_done(struct unwind_state *state)
 {
return state->stack_info.type == STACK_TYPE_UNKNOWN;
@@ -48,8 +50,6 @@ unsigned long *unwind_get_return_address_ptr(struct 
unwind_state *state)
return state->bp + 1;
 }
 
-unsigned long unwind_get_return_address(struct unwind_state *state);
-
 #else /* !CONFIG_FRAME_POINTER */
 
 static inline
@@ -58,16 +58,6 @@ unsigned long *unwind_get_return_address_ptr(struct 
unwind_state *state)
return NULL;
 }
 
-static inline
-unsigned long unwind_get_return_address(struct unwind_state *state)
-{
-   if (unwind_done(state))
-   return 0;
-
-   return ftrace_graph_ret_addr(state->task, >graph_idx,
-*state->sp, state->sp);
-}
-
 #endif /* CONFIG_FRAME_POINTER */
 
 #endif /* _ASM_X86_UNWIND_H */
diff --git a/arch/x86/kernel/unwind_guess.c b/arch/x86/kernel/unwind_guess.c
index b5a834c..9298993 100644
--- a/arch/x86/kernel/unwind_guess.c
+++ b/arch/x86/kernel/unwind_guess.c
@@ -5,6 +5,16 @@
 #include 
 #include 
 
+unsigned long unwind_get_return_address(struct unwind_state *state)
+{
+   if (unwind_done(state))
+   return 0;
+
+   return ftrace_graph_ret_addr(state->task, >graph_idx,
+*state->sp, state->sp);
+}
+EXPORT_SYMBOL_GPL(unwind_get_return_address);
+
 bool unwind_next_frame(struct unwind_state *state)
 {
struct stack_info *info = >stack_info;
-- 
2.7.4

Re: [PATCH] Staging:dgnc:dgnc_neo: fixed 80 character line limit coding style issue

[Greg KH]

On Wed, Oct 05, 2016 at 02:53:58PM -0700, Nadim Almas wrote:
> Fixed coding style issue
> 
> Signed-off-by: Nadim Almas 
> ---
>  drivers/staging/dgnc/dgnc_neo.h | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/dgnc/dgnc_neo.h b/drivers/staging/dgnc/dgnc_neo.h
> index abddd48..65994e3 100644
> --- a/drivers/staging/dgnc/dgnc_neo.h
> +++ b/drivers/staging/dgnc/dgnc_neo.h
> @@ -30,7 +30,8 @@
>  struct neo_uart_struct {
>   u8 txrx;/* WR  RHR/THR - Holding Reg */
>   u8 ier; /* WR  IER - Interrupt Enable Reg */
> - u8 isr_fcr; /* WR  ISR/FCR - Interrupt Status Reg/Fifo 
> Control Reg */
> + u8 isr_fcr; /* WR  ISR/FCR - Interrupt Status Reg/Fifo Control */
> + /*Reg */

Does that really look better now than it did before?

I don't think so :(

sorry,

greg k-h

Re: [PATCH] Staging:dgnc:dgnc_neo: fixed 80 character line limit coding style issue

[Greg KH]

On Wed, Oct 05, 2016 at 02:53:58PM -0700, Nadim Almas wrote:
> Fixed coding style issue
> 
> Signed-off-by: Nadim Almas 
> ---
>  drivers/staging/dgnc/dgnc_neo.h | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/dgnc/dgnc_neo.h b/drivers/staging/dgnc/dgnc_neo.h
> index abddd48..65994e3 100644
> --- a/drivers/staging/dgnc/dgnc_neo.h
> +++ b/drivers/staging/dgnc/dgnc_neo.h
> @@ -30,7 +30,8 @@
>  struct neo_uart_struct {
>   u8 txrx;/* WR  RHR/THR - Holding Reg */
>   u8 ier; /* WR  IER - Interrupt Enable Reg */
> - u8 isr_fcr; /* WR  ISR/FCR - Interrupt Status Reg/Fifo 
> Control Reg */
> + u8 isr_fcr; /* WR  ISR/FCR - Interrupt Status Reg/Fifo Control */
> + /*Reg */

Does that really look better now than it did before?

I don't think so :(

sorry,

greg k-h

[PATCH v3 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

Add support for programmable MAC impedance configuration

Signed-off-by: Mugunthan V N 
---
 drivers/net/phy/dp83867.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
 /* Extended Registers */
 #define DP83867_RGMIICTL   0x0032
 #define DP83867_RGMIIDCTL  0x0086
+#define DP83867_IO_MUX_CFG 0x0170
 
 #define DP83867_SW_RESET   BIT(15)
 #define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
 /* RGMIIDCTL bits */
 #define DP83867_RGMII_TX_CLK_DELAY_SHIFT   4
 
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL   0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
+
 struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+   int io_impedance;
 };
 
 static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
 
+   dp83867->io_impedance = -EINVAL;
+
+   /* Optional configuration */
+   if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+   else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
   >rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
 
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
   DP83867_DEVADDR, delay);
+
+   if (dp83867->io_impedance >= 0) {
+   val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR);
+
+   val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   val |= dp83867->io_impedance &
+  DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+  DP83867_DEVADDR, val);
+   }
}
 
return 0;
-- 
2.10.0.372.g6fe1b14

[PATCH v3 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

Add support for programmable MAC impedance configuration

Signed-off-by: Mugunthan V N 
---
 drivers/net/phy/dp83867.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
 /* Extended Registers */
 #define DP83867_RGMIICTL   0x0032
 #define DP83867_RGMIIDCTL  0x0086
+#define DP83867_IO_MUX_CFG 0x0170
 
 #define DP83867_SW_RESET   BIT(15)
 #define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
 /* RGMIIDCTL bits */
 #define DP83867_RGMII_TX_CLK_DELAY_SHIFT   4
 
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL   0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
+
 struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+   int io_impedance;
 };
 
 static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
 
+   dp83867->io_impedance = -EINVAL;
+
+   /* Optional configuration */
+   if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+   else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
   >rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
 
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
   DP83867_DEVADDR, delay);
+
+   if (dp83867->io_impedance >= 0) {
+   val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR);
+
+   val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   val |= dp83867->io_impedance &
+  DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+  DP83867_DEVADDR, val);
+   }
}
 
return 0;
-- 
2.10.0.372.g6fe1b14

[PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control

[Mugunthan V N]

Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.

Signed-off-by: Mugunthan V N 
---
 Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt 
b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
 
+Optional property:
+   - ti,min-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   minimum value (35 ohms).
+   - ti,max-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+  exclusive. When both properties are present ti,max-output-impedance
+  takes precedence.
+
 Default child nodes are standard Ethernet PHY device
 nodes as described in Documentation/devicetree/bindings/net/phy.txt
 
-- 
2.10.0.372.g6fe1b14

[PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control

[Mugunthan V N]

Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.

Signed-off-by: Mugunthan V N 
---
 Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt 
b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
 
+Optional property:
+   - ti,min-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   minimum value (35 ohms).
+   - ti,max-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+  exclusive. When both properties are present ti,max-output-impedance
+  takes precedence.
+
 Default child nodes are standard Ethernet PHY device
 nodes as described in Documentation/devicetree/bindings/net/phy.txt
 
-- 
2.10.0.372.g6fe1b14

[PATCH v3 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings

[Mugunthan V N]

The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..aafb594 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-impedance;
};
 
dp83867_1: ethernet-phy@3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-imepdance;
};
 };
-- 
2.10.0.372.g6fe1b14

[PATCH v3 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm

[Mugunthan V N]

Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.

Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.

Changes from v2:
* Fixed a typo in dts and driver.

Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
  change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.

[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23283056/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v3

Mugunthan V N (4):
  net: phy: dp83867: Add documentation for optional impedance control
  net: phy: dp83867: add support for MAC impedance configuration
  ARM: dts: dra72-evm-revc: add phy impedance settings
  ARM: dts: dra72-evm-revc: fix correct phy delay

 .../devicetree/bindings/net/ti,dp83867.txt | 12 ++
 arch/arm/boot/dts/dra72-evm-revc.dts   | 10 
 drivers/net/phy/dp83867.c  | 28 ++
 3 files changed, 46 insertions(+), 4 deletions(-)

-- 
2.10.0.372.g6fe1b14

[PATCH v3 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay

[Mugunthan V N]

The current delay settings of the phy are not the optimal value,
fix it with correct values.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index aafb594..01e1f39 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
 _mdio {
dp83867_0: ethernet-phy@2 {
reg = <2>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-impedance;
};
 
dp83867_1: ethernet-phy@3 {
reg = <3>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-imepdance;
};
-- 
2.10.0.372.g6fe1b14

[PATCH v3 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings

[Mugunthan V N]

The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..aafb594 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-impedance;
};
 
dp83867_1: ethernet-phy@3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-imepdance;
};
 };
-- 
2.10.0.372.g6fe1b14

[PATCH v3 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm

[Mugunthan V N]

Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.

Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.

Changes from v2:
* Fixed a typo in dts and driver.

Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
  change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.

[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23283056/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v3

Mugunthan V N (4):
  net: phy: dp83867: Add documentation for optional impedance control
  net: phy: dp83867: add support for MAC impedance configuration
  ARM: dts: dra72-evm-revc: add phy impedance settings
  ARM: dts: dra72-evm-revc: fix correct phy delay

 .../devicetree/bindings/net/ti,dp83867.txt | 12 ++
 arch/arm/boot/dts/dra72-evm-revc.dts   | 10 
 drivers/net/phy/dp83867.c  | 28 ++
 3 files changed, 46 insertions(+), 4 deletions(-)

-- 
2.10.0.372.g6fe1b14

[PATCH v3 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay

[Mugunthan V N]

The current delay settings of the phy are not the optimal value,
fix it with correct values.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index aafb594..01e1f39 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
 _mdio {
dp83867_0: ethernet-phy@2 {
reg = <2>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-impedance;
};
 
dp83867_1: ethernet-phy@3 {
reg = <3>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-imepdance;
};
-- 
2.10.0.372.g6fe1b14

[PATCH] Let CONFIG_STRICT_DEVMEM depends on CONFIG_DEVMEM

[Dave Young]

With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless
even if it is set =y, thus let's update the dependency in Kconfig.

Signed-off-by: Dave Young 
---
 lib/Kconfig.debug |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-x86.orig/lib/Kconfig.debug
+++ linux-x86/lib/Kconfig.debug
@@ -1980,7 +1980,7 @@ config ARCH_HAS_DEVMEM_IS_ALLOWED
 
 config STRICT_DEVMEM
bool "Filter access to /dev/mem"
-   depends on MMU
+   depends on MMU && DEVMEM
depends on ARCH_HAS_DEVMEM_IS_ALLOWED
default y if TILE || PPC
---help---

[PATCH] Let CONFIG_STRICT_DEVMEM depends on CONFIG_DEVMEM

[Dave Young]

With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless
even if it is set =y, thus let's update the dependency in Kconfig.

Signed-off-by: Dave Young 
---
 lib/Kconfig.debug |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-x86.orig/lib/Kconfig.debug
+++ linux-x86/lib/Kconfig.debug
@@ -1980,7 +1980,7 @@ config ARCH_HAS_DEVMEM_IS_ALLOWED
 
 config STRICT_DEVMEM
bool "Filter access to /dev/mem"
-   depends on MMU
+   depends on MMU && DEVMEM
depends on ARCH_HAS_DEVMEM_IS_ALLOWED
default y if TILE || PPC
---help---

Re: [GIT] Networking

[Stephen Rothwell]

Hi Dave,

On Wed, 05 Oct 2016 22:56:12 -0400 (EDT) David Miller  
wrote:
>
> Yes, this is where the change got lost.

No worries.

> I have all of the fixups queued up in my net tree and will send in a pull
> request later.

Thanks.

-- 
Cheers,
Stephen Rothwell

Re: [GIT] Networking

[Stephen Rothwell]

Hi Dave,

On Wed, 05 Oct 2016 22:56:12 -0400 (EDT) David Miller  
wrote:
>
> Yes, this is where the change got lost.

No worries.

> I have all of the fixups queued up in my net tree and will send in a pull
> request later.

Thanks.

-- 
Cheers,
Stephen Rothwell

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

[Yinghai Lu]

On Wed, Oct 5, 2016 at 7:04 AM, Thomas Gleixner  wrote:
>> @@ -176,6 +177,11 @@ static int acpi_register_lapic(int id, u
>>  return -EINVAL;
>>  }
>>
>> +if (!enabled && (id == disabled_id)) {
>> +++disabled_cpus;
>> +return -EINVAL;
>> +}
>
> Why would you need that disabled_id thing at all? The proper fix is to let
> the apic driver detect the issue and this boils down to a 5 lines
> change. Does the patch below fix the issue for you?
> 8<
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2076,6 +2076,11 @@ int __generic_processor_info(int apicid,
> bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
> phys_cpu_present_map);
>
> +   if (!apic->apic_id_valid(apicid)) {
> +   disabled_cpus++;
> +   return -EINVAL;
> +   }
> +
> /*
>  * boot_cpu_physical_apicid is designed to have the apicid
>  * returned by read_apic_id(), i.e, the apicid of the
>
>

No, That does not fix the issue.

the system have x2apic pre_enabled from BIOS, so at the time
apic is set to _x2apic_cluster.

early_acpi_boot_init ==> early_acpi_process_madt ==> acpi_parse_madt
==> default_acpi_madt_oem_check

default_acpi_madt_oem_check
  ==> apic_x2apic_cluster/x2apic_acpi_madt_oem_check ==> x2apic_enabled
  ==> apic = _x2apic_cluster

and
static int x2apic_apic_id_valid(int apicid)
{
return 1;
}

To make your change work, may need to update x2apic_apic_id_valid to

static int x2apic_apic_id_valid(int apicid)
{
if (apicid == 0xff || apicid == -1)
return 0;

return 1;
}


Thanks

Yinghai

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

[Yinghai Lu]

On Wed, Oct 5, 2016 at 7:04 AM, Thomas Gleixner  wrote:
>> @@ -176,6 +177,11 @@ static int acpi_register_lapic(int id, u
>>  return -EINVAL;
>>  }
>>
>> +if (!enabled && (id == disabled_id)) {
>> +++disabled_cpus;
>> +return -EINVAL;
>> +}
>
> Why would you need that disabled_id thing at all? The proper fix is to let
> the apic driver detect the issue and this boils down to a 5 lines
> change. Does the patch below fix the issue for you?
> 8<
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2076,6 +2076,11 @@ int __generic_processor_info(int apicid,
> bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
> phys_cpu_present_map);
>
> +   if (!apic->apic_id_valid(apicid)) {
> +   disabled_cpus++;
> +   return -EINVAL;
> +   }
> +
> /*
>  * boot_cpu_physical_apicid is designed to have the apicid
>  * returned by read_apic_id(), i.e, the apicid of the
>
>

No, That does not fix the issue.

the system have x2apic pre_enabled from BIOS, so at the time
apic is set to _x2apic_cluster.

early_acpi_boot_init ==> early_acpi_process_madt ==> acpi_parse_madt
==> default_acpi_madt_oem_check

default_acpi_madt_oem_check
  ==> apic_x2apic_cluster/x2apic_acpi_madt_oem_check ==> x2apic_enabled
  ==> apic = _x2apic_cluster

and
static int x2apic_apic_id_valid(int apicid)
{
return 1;
}

To make your change work, may need to update x2apic_apic_id_valid to

static int x2apic_apic_id_valid(int apicid)
{
if (apicid == 0xff || apicid == -1)
return 0;

return 1;
}


Thanks

Yinghai

Re: Zram for FreeBSD

[Sergey Senozhatsky]

Hi,

On (10/05/16 16:47), Cory Pruce wrote:
>Could one of you tell me why these compression algo’s were chosen,

zram supports more than that.
https://marc.info/?l=linux-kernel=146469777105130


>if they were implemented as a need for zram, and

hm... not all of them (if any at all). lzo, *may be*, was motivated
by "compression/decompression perfromance VS compression ratio", which
is imporatant for zram.


>what the policy is on porting these to FreeBSD?

no idea.

-ss

Re: Zram for FreeBSD

[Sergey Senozhatsky]

Hi,

On (10/05/16 16:47), Cory Pruce wrote:
>Could one of you tell me why these compression algo’s were chosen,

zram supports more than that.
https://marc.info/?l=linux-kernel=146469777105130


>if they were implemented as a need for zram, and

hm... not all of them (if any at all). lzo, *may be*, was motivated
by "compression/decompression perfromance VS compression ratio", which
is imporatant for zram.


>what the policy is on porting these to FreeBSD?

no idea.

-ss

Re: error: 'struct net_device' has no member named 'nf_hooks_ingress'

[Sergey Senozhatsky]

On (10/06/16 06:11), Eric Dumazet wrote:
> On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote:
> 
> > this commit is now in mainline as
> > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build:
> > 
> > net/netfilter/core.c: In function 'nf_set_hooks_head':
> > net/netfilter/core.c:96:3: error: 'struct net_device' has no member 
> > named 'nf_hooks_ingress'
> > 
> > Are the fixes (see below) on the way to mainline too?
> 
> Yes the fixes are already in nf tree and _will_ get pushed.
> 
> Pablo and David are attending netdev 1.2 in Tokyo and have obligations.
> 
> https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/

well, I did my best to avoid it, but the guys didn't even bother to
reply. pushing a knowingly broken patch that
a) kills the build
b) introduces a race
c) requires two "Fixes:" followup patches
to the main line despite the fact that those problems were discovered
at linux-next stage is totally un-cool.

-ss

Re: error: 'struct net_device' has no member named 'nf_hooks_ingress'

[Sergey Senozhatsky]

On (10/06/16 06:11), Eric Dumazet wrote:
> On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote:
> 
> > this commit is now in mainline as
> > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build:
> > 
> > net/netfilter/core.c: In function 'nf_set_hooks_head':
> > net/netfilter/core.c:96:3: error: 'struct net_device' has no member 
> > named 'nf_hooks_ingress'
> > 
> > Are the fixes (see below) on the way to mainline too?
> 
> Yes the fixes are already in nf tree and _will_ get pushed.
> 
> Pablo and David are attending netdev 1.2 in Tokyo and have obligations.
> 
> https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/

well, I did my best to avoid it, but the guys didn't even bother to
reply. pushing a knowingly broken patch that
a) kills the build
b) introduces a race
c) requires two "Fixes:" followup patches
to the main line despite the fact that those problems were discovered
at linux-next stage is totally un-cool.

-ss

Re: [PATCH v3 1/2] config: Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc

[Sam Ravnborg]

On Wed, Oct 05, 2016 at 05:56:16PM -0500, Babu Moger wrote:
> Dave, Gentle reminder to review this patch. Thanks

No need to ping Dave.
It is in patchwork and he will review the patch eventually.

Sam

Re: [PATCH v3 1/2] config: Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc

[Sam Ravnborg]

On Wed, Oct 05, 2016 at 05:56:16PM -0500, Babu Moger wrote:
> Dave, Gentle reminder to review this patch. Thanks

No need to ping Dave.
It is in patchwork and he will review the patch eventually.

Sam

Re: [RFC][PATCH 6/7] printk: use alternative printk buffers

[Sergey Senozhatsky]

On (10/05/16 11:50), Petr Mladek wrote:
[..]
> > well, it solves a number of problems that the existing implementation
> > cannot handle.
> 
> Please, provide a summary. I wonder if these are real life problems.

anything that starts from printk().
I'm trying to address printk() recursion only, by handling the top-most
recursion - printk -> printk, which causes all of the dependent recursions:
printk -> spin_lock(logbuf) -> printk() -> spin_lock(logbuf)
printk -> sem->lock() -> printk() -> sem->lock()
and so on.

I'm not building a lock dependency graph/etc.


the existing recursion detection logic is racy and quite limited in
scope: not only it protects only a tiny bit of printk, but it doesn't
even protect it fully. the very moment we do `logbuf_cpu = UINT_MAX;'
it's over - we still own the lock, but we don't remember it anymore.
a spin_dump() from raw_spin_unlock(_lock) will kill us.


** a very quick list **
// a mixed list of theoretical and real problems can also be found
// in the patch set cover letter.


public reports:

1) some pathces/reports from Byungchul Park

the first one in my mailbox (seems to be)
https://marc.info/?l=linux-kernel=145406977822244
20160129121545.GH31266@X58A-UD3R

or here
https://marc.info/?l=linux-kernel=145570036513749

in his case, I believe, the lock was fine (not corrupted). it just he had
a spin_lock lockup on console semaphore spin_lock coming from:

static void __spin_lock_debug(raw_spinlock_t *lock)
{
u64 i;
u64 loops = loops_per_jiffy * HZ;

for (i = 0; i < loops; i++) {
if (arch_spin_trylock(>raw_lock))
return;
__delay(1);
}
/* lockup suspected: */
spin_dump(lock, "lockup suspected");


which ended up in an infinite recursion.

https://marc.info/?l=linux-kernel=145449014308161



2) a report from Viresh Kumar.

frankly, we were lucky to have Viresh on this: a less experienced developer
would probably give up. So would probably do a developer with no appropriate
hardware: jtag debugger/serial console/etc. and I don't know how much would
we spend on meditations to figure out it was a WARN from timekeeping. we
better be 'more prepared'.


===
reports (unique occurrences only) that I have in internal bugzilla

4) sleeping function called from inside logbuf lock
   which resulted in spin_dump() call from spin_unlock(_lock)
   when:
a) we still owned the logbuf_lock
b) yet logbuf_cpu was already reset, so printk recursion
detection was helpless

   'a + b' leave us no chances to survive.

5) ARM specific
   an imprecise abort 
(http://infocenter.arm.com/help/topic/com.arm.doc.faqs/14809.html)
   hit the CPU while it was holding the printk-related spin-lock.
   that deadlocked the system, because abort handler attempted to
   printk() a message.


6) logbuf_lock corruption
   well, no cookies for us. un-fixable at the moment. we can probably
   do something about it. have a spinlock-debug bool function that would
   tell us whether the lock is corrupted, so we can re-init logbuf_lock,
   perhaps.


> Note that we need to put aside all problems that are solvable
> with printk_deferred(). It seems that printk_deferred() will
> need to stay because it avoids the deadlock caused by
> scheduler/timekeeping code locks.

agree. printk_deferred() takes only one lock and avoids console_unlock()
loop. as long as logbuf_lock is not on it's way printk_deferred() may be
helpful.

> By other words, if there is a missing printk_deferred() we
> need to put it there anyway because the same code might get
> first called outside printk().

right. and I'm not addressing this. there are just too many locks
that can be acquired out of order. not only timekeeping and sched
locks, but any of serial console locks adn so on. we need something
like lockdep locks graph here that would not report the issues (any
printk() can result in deadlock when we detect that at least one of
printk related locks was acquired out of order), but instead would
somehow selectively fix/workaround them.


can we somehow transparently for the rest of the system (just in
printk()) detect that we are in a potentially risky situation? hmm,
I don't know...

something *very* radical?

vprintk_func()
{
if (this_cpu_read(alt_printk_ctx) & ALT_PRINTK_NMI_CONTEXT_MASK)
return vprintk_nmi(fmt, args);

if (in_atomic() ||
/*  */
this_cpu_read(alt_printk_ctx) & ALT_PRINTK_CONTEXT_MASK)
return vprintk_alt(fmt, args);

return vprintk_default(fmt, args);
}

-ss

Re: [RFC][PATCH 6/7] printk: use alternative printk buffers

[Sergey Senozhatsky]

On (10/05/16 11:50), Petr Mladek wrote:
[..]
> > well, it solves a number of problems that the existing implementation
> > cannot handle.
> 
> Please, provide a summary. I wonder if these are real life problems.

anything that starts from printk().
I'm trying to address printk() recursion only, by handling the top-most
recursion - printk -> printk, which causes all of the dependent recursions:
printk -> spin_lock(logbuf) -> printk() -> spin_lock(logbuf)
printk -> sem->lock() -> printk() -> sem->lock()
and so on.

I'm not building a lock dependency graph/etc.


the existing recursion detection logic is racy and quite limited in
scope: not only it protects only a tiny bit of printk, but it doesn't
even protect it fully. the very moment we do `logbuf_cpu = UINT_MAX;'
it's over - we still own the lock, but we don't remember it anymore.
a spin_dump() from raw_spin_unlock(_lock) will kill us.


** a very quick list **
// a mixed list of theoretical and real problems can also be found
// in the patch set cover letter.


public reports:

1) some pathces/reports from Byungchul Park

the first one in my mailbox (seems to be)
https://marc.info/?l=linux-kernel=145406977822244
20160129121545.GH31266@X58A-UD3R

or here
https://marc.info/?l=linux-kernel=145570036513749

in his case, I believe, the lock was fine (not corrupted). it just he had
a spin_lock lockup on console semaphore spin_lock coming from:

static void __spin_lock_debug(raw_spinlock_t *lock)
{
u64 i;
u64 loops = loops_per_jiffy * HZ;

for (i = 0; i < loops; i++) {
if (arch_spin_trylock(>raw_lock))
return;
__delay(1);
}
/* lockup suspected: */
spin_dump(lock, "lockup suspected");


which ended up in an infinite recursion.

https://marc.info/?l=linux-kernel=145449014308161



2) a report from Viresh Kumar.

frankly, we were lucky to have Viresh on this: a less experienced developer
would probably give up. So would probably do a developer with no appropriate
hardware: jtag debugger/serial console/etc. and I don't know how much would
we spend on meditations to figure out it was a WARN from timekeeping. we
better be 'more prepared'.


===
reports (unique occurrences only) that I have in internal bugzilla

4) sleeping function called from inside logbuf lock
   which resulted in spin_dump() call from spin_unlock(_lock)
   when:
a) we still owned the logbuf_lock
b) yet logbuf_cpu was already reset, so printk recursion
detection was helpless

   'a + b' leave us no chances to survive.

5) ARM specific
   an imprecise abort 
(http://infocenter.arm.com/help/topic/com.arm.doc.faqs/14809.html)
   hit the CPU while it was holding the printk-related spin-lock.
   that deadlocked the system, because abort handler attempted to
   printk() a message.


6) logbuf_lock corruption
   well, no cookies for us. un-fixable at the moment. we can probably
   do something about it. have a spinlock-debug bool function that would
   tell us whether the lock is corrupted, so we can re-init logbuf_lock,
   perhaps.


> Note that we need to put aside all problems that are solvable
> with printk_deferred(). It seems that printk_deferred() will
> need to stay because it avoids the deadlock caused by
> scheduler/timekeeping code locks.

agree. printk_deferred() takes only one lock and avoids console_unlock()
loop. as long as logbuf_lock is not on it's way printk_deferred() may be
helpful.

> By other words, if there is a missing printk_deferred() we
> need to put it there anyway because the same code might get
> first called outside printk().

right. and I'm not addressing this. there are just too many locks
that can be acquired out of order. not only timekeeping and sched
locks, but any of serial console locks adn so on. we need something
like lockdep locks graph here that would not report the issues (any
printk() can result in deadlock when we detect that at least one of
printk related locks was acquired out of order), but instead would
somehow selectively fix/workaround them.


can we somehow transparently for the rest of the system (just in
printk()) detect that we are in a potentially risky situation? hmm,
I don't know...

something *very* radical?

vprintk_func()
{
if (this_cpu_read(alt_printk_ctx) & ALT_PRINTK_NMI_CONTEXT_MASK)
return vprintk_nmi(fmt, args);

if (in_atomic() ||
/*  */
this_cpu_read(alt_printk_ctx) & ALT_PRINTK_CONTEXT_MASK)
return vprintk_alt(fmt, args);

return vprintk_default(fmt, args);
}

-ss

Re: [RESEND PATCH v2 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

[Viresh Kumar]

Thanks for accepting all the comments :)

On 05-10-16, 14:04, Markus Mayer wrote:
> Is there an easy way for me to know via the framework whether init is
> being called for the first time vs. init is being called on a
> different core after a previous attempt to initialize on another core
> failed?
> 
> I could use a driver-global variable for the driver to remember if it
> has been initialized, but that seems a bit hacky.

You don't really need to have any special code here, specially for the case that
may never get hit. For example, if we fail to initialize something for CPU0,
cpufreq core will try calling this routine for other CPUs as well. I don't think
there is anything wrong in letting cpufreq core trying that. Why stop it or
return early? It wouldn't happen normally, unless there is a bug in there.

-- 
viresh

Re: [RESEND PATCH v2 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

[Viresh Kumar]

Thanks for accepting all the comments :)

On 05-10-16, 14:04, Markus Mayer wrote:
> Is there an easy way for me to know via the framework whether init is
> being called for the first time vs. init is being called on a
> different core after a previous attempt to initialize on another core
> failed?
> 
> I could use a driver-global variable for the driver to remember if it
> has been initialized, but that seems a bit hacky.

You don't really need to have any special code here, specially for the case that
may never get hit. For example, if we fail to initialize something for CPU0,
cpufreq core will try calling this routine for other CPUs as well. I don't think
there is anything wrong in letting cpufreq core trying that. Why stop it or
return early? It wouldn't happen normally, unless there is a bug in there.

-- 
viresh

[GIT PULL] Mailbox changes for v4.9

[Jassi Brar]

Hi Linus,

The following changes since commit d060e0f603a4156087813d221d818bb39ec91429:

  Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
(2016-09-06 12:33:12 -0700)

are available in the git repository at:

  git://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-for-next

for you to fetch changes up to a649244de727b87d38fe46d86ef98c8d1fc49551:

  dt-bindings: mailbox: Add Amlogic Meson MHU Bindings (2016-09-07
13:07:18 +0530)


- New driver and DT bindings for MHU controller integrated
on Amlogic Meson platform.


Neil Armstrong (2):
  mailbox: Add Platform Message-Handling-Unit variant driver
  dt-bindings: mailbox: Add Amlogic Meson MHU Bindings

 .../devicetree/bindings/mailbox/meson-mhu.txt  |  34 
 drivers/mailbox/Kconfig|  10 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/platform_mhu.c | 205 +
 4 files changed, 251 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
 create mode 100644 drivers/mailbox/platform_mhu.c

[GIT PULL] Mailbox changes for v4.9

[Jassi Brar]

Hi Linus,

The following changes since commit d060e0f603a4156087813d221d818bb39ec91429:

  Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
(2016-09-06 12:33:12 -0700)

are available in the git repository at:

  git://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-for-next

for you to fetch changes up to a649244de727b87d38fe46d86ef98c8d1fc49551:

  dt-bindings: mailbox: Add Amlogic Meson MHU Bindings (2016-09-07
13:07:18 +0530)


- New driver and DT bindings for MHU controller integrated
on Amlogic Meson platform.


Neil Armstrong (2):
  mailbox: Add Platform Message-Handling-Unit variant driver
  dt-bindings: mailbox: Add Amlogic Meson MHU Bindings

 .../devicetree/bindings/mailbox/meson-mhu.txt  |  34 
 drivers/mailbox/Kconfig|  10 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/platform_mhu.c | 205 +
 4 files changed, 251 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
 create mode 100644 drivers/mailbox/platform_mhu.c

linux-next: Tree for Oct 6

[Stephen Rothwell]

Hi all,

There will be no linux-next release tomorrow.

Please do *not* add any v4.10 material to your linux-next included trees
until v4.9-rc1 has been released i.e. the merge window closes.

Changes since 20161005:

The akpm-current tree gained a conflict against the percpu tree.

Non-merge commits (relative to Linus' tree): 9246
 6433 files changed, 53 insertions(+), 234224 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
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

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 (5691f0e9a3e7 Merge tag 'sound-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound)
Merging fixes/master (6e44d367fe87 netfilter: merge fixup for 
"nf_tables_netdev: remove redundant ip_hdr assignment")
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (117e5e9c4cfc ARM: 8618/1: decompressor: reset ttbcr 
fields to use TTBR0 on ARMv7)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (c8d2bc9bc39e Linux 4.8)
Merging net/master (c8d2bc9bc39e Linux 4.8)
Merging ipsec/master (b1f2beb87bb0 Merge tag 'media/v4.8-7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging netfilter/master (c8d2bc9bc39e Linux 4.8)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (f38b7c254753 wlcore: sdio: drop kfree for 
memory allocated with devm_kzalloc)
Merging mac80211/master (c8d2bc9bc39e Linux 4.8)
Merging sound-current/for-linus (eeea8b40cd28 Merge tag 'asoc-v4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next)
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (a3443cda5588 Merge branch 'next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (c758f96a8c34 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (80da44c29d99 crypto: vmx - Fix memory corruption 
caused by p8_ghash)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops in 
error interrupt setup handling)
Merging kselftest-f

linux-next: Tree for Oct 6

[Stephen Rothwell]

Hi all,

There will be no linux-next release tomorrow.

Please do *not* add any v4.10 material to your linux-next included trees
until v4.9-rc1 has been released i.e. the merge window closes.

Changes since 20161005:

The akpm-current tree gained a conflict against the percpu tree.

Non-merge commits (relative to Linus' tree): 9246
 6433 files changed, 53 insertions(+), 234224 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
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

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 (5691f0e9a3e7 Merge tag 'sound-4.9-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound)
Merging fixes/master (6e44d367fe87 netfilter: merge fixup for 
"nf_tables_netdev: remove redundant ip_hdr assignment")
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (117e5e9c4cfc ARM: 8618/1: decompressor: reset ttbcr 
fields to use TTBR0 on ARMv7)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (c8d2bc9bc39e Linux 4.8)
Merging net/master (c8d2bc9bc39e Linux 4.8)
Merging ipsec/master (b1f2beb87bb0 Merge tag 'media/v4.8-7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging netfilter/master (c8d2bc9bc39e Linux 4.8)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (f38b7c254753 wlcore: sdio: drop kfree for 
memory allocated with devm_kzalloc)
Merging mac80211/master (c8d2bc9bc39e Linux 4.8)
Merging sound-current/for-linus (eeea8b40cd28 Merge tag 'asoc-v4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next)
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (a3443cda5588 Merge branch 'next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (c758f96a8c34 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (80da44c29d99 crypto: vmx - Fix memory corruption 
caused by p8_ghash)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops in 
error interrupt setup handling)
Merging kselftest-f

[GIT PULL]: dmaengine updates for 4.9-rc1

[Vinod Koul]

Hello Linus,

Here is the pull request for dmaengine.

One note though, we have dependency between dmaengine tree and tty tree, as
one series was merged thru Greg's tree. To resolve we had merged
'tty-for-dma' tag from greg's tree into dmaengine next.

This merge will show up conflict in drivers/dma/imx-sdma.c. I am sure you
will manage that :)

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-4.9-rc1

for you to fetch changes up to c84750906b4818d4929fbf73a4ae6c113b94f52b:

  async_pq_val: fix DMA memory leak (2016-10-05 06:18:09 +0530)


dmaengine updates for 4.8-rc1

This is bit large pile of code which bring in some nice additions:
 - Error reporting: we have added a new mechanism for users of dmaenegine to
   register a callback_result which tells them the result of the dma
   transaction. Right now only one user ntb is using it.
 - As we discussed on KS mailing list and pointed out NO_IRQ has no place in
   kernel, this also remove NO_IRQ from dmaengine subsystem (both arm and
   ppc users)
 - Support for IOMMU slave transfers and it implementation for arm.
 - To get better build coverage, enable COMPILE_TEST for bunch of driver,
   and fix the warning and sparse complaints on these.
 - Apart from above, usual updates spread across drivers.


Andy Green (4):
  k3dma: Fix hisi burst clipping
  k3dma: Fix dma err offsets
  k3dma: Fix "nobody cared" message seen on any error
  k3dma: Add cyclic mode for audio

Andy Shevchenko (1):
  dmaengine: hsu: refactor hsu_dma_do_irq() to return int

Arnd Bergmann (7):
  dmaengine: moxart: remove NO_IRQ
  dmaengine: mxs: remove NO_IRQ check
  dmaengine: sirf: fix irq number error check
  dmaengine: ipu: remove bogus NO_IRQ reference
  dmaengine: k3dma: use correct format string for debug output
  dmaengine: cppi41: mark PM functions as __maybe_unused
  dmaengine: edma: avoid uninitialized variable use

Arvind Yadav (1):
  dmaengine: fsldma: Unmap region obtained by of_iomap

Baoyou Xie (1):
  dmaengine: virt-dma: move function declarations

Colin Ian King (2):
  dmaengine: coh901318: fix integer overflow when shifting more than 32 
places
  dmaengine: jz4780: fix resource leaks on error exit return

Dave Jiang (46):
  dmaengine: ioatdma: fix uninitialized array usage
  dmaengine: Add helper function to prep for error reporting
  dmaengine: at_hdmac: convert callback to helper function
  dmaengine: at_xdmac: convert callback to helper function
  dmaengine: coh901318: convert callback to helper function
  dmaengine: cppi41: convert callback to helper function
  dmaengine: dw: convert callback to helper function
  dmaengine: ep93xx_dma: convert callback to helper function
  dmaengine: fsl_raid: convert callback to helper function
  dmaengine: fsldma: convert callback to helper function
  dmaengine: imx-dma: convert callback to helper function
  dmaengine: imx-sdma: convert callback to helper function
  dmaengine: ioatdma: convert callback to helper function
  dmaengine: iop-adma: convert callback to helper function
  dmaengine: ipu: convert callback to helper function
  dmaengine: mic_x100_dma: convert callback to helper function
  dmaengine: mmp_pdma: convert callback to helper function
  dmaengine: mmp_tdma: convert callback to helper function
  dmaengine: mpc512x_dma: convert callback to helper function
  dmaengine: mv_xor: convert callback to helper function
  dmaengine: mxs-dma: convert callback to helper function
  dmaengine: nbpfaxi: convert callback to helper function
  dmaengine: pch_dma: convert callback to helper function
  dmaengine: pl330: convert callback to helper function
  dmaengine: ppc4xx_adma: convert callback to helper function
  dmaengine: qcom_hidma: convert callback to helper function
  dmaengine: sh_rcar-dmac: convert callback to helper function
  dmaengine: sirf-dma: convert callback to helper function
  dmaengine: ste_dma40: convert callback to helper function
  dmaengine: tegra20-apb-dma: convert callback to helper function
  dmaengine: timb_dma: convert callback to helper function
  dmaengine: txx9dmac: convert callback to helper function
  dmaengine: virt-dma: convert callback to helper function
  dmaengine: xgene-dma: convert callback to helper function
  dmaengine: add support to provide error result from a DMA transation
  dmaengine: ioatdma: Add error handling to ioat driver
  dmaengine: ioatdma: add error strings to chanerr output
  ntb: add DMA error handling for TX DMA
  ntb: add DMA error handling for RX DMA
  

ERROR: "bad_dma_ops" [drivers/net/ethernet/qualcomm/emac/qcom-emac.ko] undefined!

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   a6930aaee06755d1bdcfd943fbf614e4d92bb0c7
commit: b9b17debc69d27cd55e21ee51a5ba7fc50a426cf net: emac: emac gigabit 
ethernet controller driver
date:   5 weeks ago
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b9b17debc69d27cd55e21ee51a5ba7fc50a426cf
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All errors (new ones prefixed by >>):

   ERROR: "bad_dma_ops" [sound/soc/bcm/snd-soc-cygnus.ko] undefined!
   ERROR: "bad_dma_ops" [sound/core/snd-pcm.ko] undefined!
   ERROR: "dma_common_mmap" [sound/core/snd-pcm.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/qualcomm/emac/qcom-emac.ko] 
>> undefined!
   ERROR: "bad_dma_ops" [drivers/media/platform/mtk-vpu/mtk-vpu.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[GIT PULL]: dmaengine updates for 4.9-rc1

[Vinod Koul]

Hello Linus,

Here is the pull request for dmaengine.

One note though, we have dependency between dmaengine tree and tty tree, as
one series was merged thru Greg's tree. To resolve we had merged
'tty-for-dma' tag from greg's tree into dmaengine next.

This merge will show up conflict in drivers/dma/imx-sdma.c. I am sure you
will manage that :)

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-4.9-rc1

for you to fetch changes up to c84750906b4818d4929fbf73a4ae6c113b94f52b:

  async_pq_val: fix DMA memory leak (2016-10-05 06:18:09 +0530)


dmaengine updates for 4.8-rc1

This is bit large pile of code which bring in some nice additions:
 - Error reporting: we have added a new mechanism for users of dmaenegine to
   register a callback_result which tells them the result of the dma
   transaction. Right now only one user ntb is using it.
 - As we discussed on KS mailing list and pointed out NO_IRQ has no place in
   kernel, this also remove NO_IRQ from dmaengine subsystem (both arm and
   ppc users)
 - Support for IOMMU slave transfers and it implementation for arm.
 - To get better build coverage, enable COMPILE_TEST for bunch of driver,
   and fix the warning and sparse complaints on these.
 - Apart from above, usual updates spread across drivers.


Andy Green (4):
  k3dma: Fix hisi burst clipping
  k3dma: Fix dma err offsets
  k3dma: Fix "nobody cared" message seen on any error
  k3dma: Add cyclic mode for audio

Andy Shevchenko (1):
  dmaengine: hsu: refactor hsu_dma_do_irq() to return int

Arnd Bergmann (7):
  dmaengine: moxart: remove NO_IRQ
  dmaengine: mxs: remove NO_IRQ check
  dmaengine: sirf: fix irq number error check
  dmaengine: ipu: remove bogus NO_IRQ reference
  dmaengine: k3dma: use correct format string for debug output
  dmaengine: cppi41: mark PM functions as __maybe_unused
  dmaengine: edma: avoid uninitialized variable use

Arvind Yadav (1):
  dmaengine: fsldma: Unmap region obtained by of_iomap

Baoyou Xie (1):
  dmaengine: virt-dma: move function declarations

Colin Ian King (2):
  dmaengine: coh901318: fix integer overflow when shifting more than 32 
places
  dmaengine: jz4780: fix resource leaks on error exit return

Dave Jiang (46):
  dmaengine: ioatdma: fix uninitialized array usage
  dmaengine: Add helper function to prep for error reporting
  dmaengine: at_hdmac: convert callback to helper function
  dmaengine: at_xdmac: convert callback to helper function
  dmaengine: coh901318: convert callback to helper function
  dmaengine: cppi41: convert callback to helper function
  dmaengine: dw: convert callback to helper function
  dmaengine: ep93xx_dma: convert callback to helper function
  dmaengine: fsl_raid: convert callback to helper function
  dmaengine: fsldma: convert callback to helper function
  dmaengine: imx-dma: convert callback to helper function
  dmaengine: imx-sdma: convert callback to helper function
  dmaengine: ioatdma: convert callback to helper function
  dmaengine: iop-adma: convert callback to helper function
  dmaengine: ipu: convert callback to helper function
  dmaengine: mic_x100_dma: convert callback to helper function
  dmaengine: mmp_pdma: convert callback to helper function
  dmaengine: mmp_tdma: convert callback to helper function
  dmaengine: mpc512x_dma: convert callback to helper function
  dmaengine: mv_xor: convert callback to helper function
  dmaengine: mxs-dma: convert callback to helper function
  dmaengine: nbpfaxi: convert callback to helper function
  dmaengine: pch_dma: convert callback to helper function
  dmaengine: pl330: convert callback to helper function
  dmaengine: ppc4xx_adma: convert callback to helper function
  dmaengine: qcom_hidma: convert callback to helper function
  dmaengine: sh_rcar-dmac: convert callback to helper function
  dmaengine: sirf-dma: convert callback to helper function
  dmaengine: ste_dma40: convert callback to helper function
  dmaengine: tegra20-apb-dma: convert callback to helper function
  dmaengine: timb_dma: convert callback to helper function
  dmaengine: txx9dmac: convert callback to helper function
  dmaengine: virt-dma: convert callback to helper function
  dmaengine: xgene-dma: convert callback to helper function
  dmaengine: add support to provide error result from a DMA transation
  dmaengine: ioatdma: Add error handling to ioat driver
  dmaengine: ioatdma: add error strings to chanerr output
  ntb: add DMA error handling for TX DMA
  ntb: add DMA error handling for RX DMA
  

ERROR: "bad_dma_ops" [drivers/net/ethernet/qualcomm/emac/qcom-emac.ko] undefined!

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   a6930aaee06755d1bdcfd943fbf614e4d92bb0c7
commit: b9b17debc69d27cd55e21ee51a5ba7fc50a426cf net: emac: emac gigabit 
ethernet controller driver
date:   5 weeks ago
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b9b17debc69d27cd55e21ee51a5ba7fc50a426cf
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All errors (new ones prefixed by >>):

   ERROR: "bad_dma_ops" [sound/soc/bcm/snd-soc-cygnus.ko] undefined!
   ERROR: "bad_dma_ops" [sound/core/snd-pcm.ko] undefined!
   ERROR: "dma_common_mmap" [sound/core/snd-pcm.ko] undefined!
>> ERROR: "bad_dma_ops" [drivers/net/ethernet/qualcomm/emac/qcom-emac.ko] 
>> undefined!
   ERROR: "bad_dma_ops" [drivers/media/platform/mtk-vpu/mtk-vpu.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

web.upgrades

[Sistemas administrador]

ATENCIÓN;

Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por 
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser 
capaz de enviar o recibir correo nuevo hasta que
vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de 
correo, envíe la siguiente información a continuación:

nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:

Si usted no puede revalidar su buzón, el buzón se deshabilitará!

Disculpa las molestias.
Código de verificación:90opp4r56 es: 006524
Correo Soporte Técnico © 2016

¡gracias
Sistemas administrador

web.upgrades

[Sistemas administrador]

ATENCIÓN;

Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por 
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser 
capaz de enviar o recibir correo nuevo hasta que
vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de 
correo, envíe la siguiente información a continuación:

nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:

Si usted no puede revalidar su buzón, el buzón se deshabilitará!

Disculpa las molestias.
Código de verificación:90opp4r56 es: 006524
Correo Soporte Técnico © 2016

¡gracias
Sistemas administrador

Re: linux-next: manual merge of the akpm-current tree with the percpu tree

[Stephen Rothwell]

Hi all,

On Thu, 6 Oct 2016 13:43:57 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/percpu.c
> 
> between commits:
> 
>   93c76b6b2faa ("mm/percpu.c: correct max_distance calculation for 
> pcpu_embed_first_chunk()")
>   9b7396624a7b ("mm/percpu.c: fix potential memory leakage for 
> pcpu_embed_first_chunk()")
> 
> from the percpu tree and commit:
> 
>   567f646230a5 ("mm/percpu.c: correct max_distance calculation for 
> pcpu_embed_first_chunk()")
> 
> from the akpm-current tree.
> 
> There is one small differenve between 567f646230a5 and 9b7396624a7b and
> then further changes in 93c76b6b2faa.

Cut an paste error.  Should have said:

There is one small difference between 567f646230a5 and 93c76b6b2faa and
then further changes in 9b7396624a7b.

-- 
Cheers,
Stephen Rothwell

Re: [GIT] Networking

[David Miller]

From: Stephen Rothwell 
Date: Thu, 6 Oct 2016 13:51:52 +1100

> On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds 
>  wrote:
>>
>> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell  
>> wrote:
>> >
>> > Except that commit effectively moved that function from
>> > net/netfilter/nf_tables_netdev.c to
>> > include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
>> > ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
>> > removed the assignment in the original file (and has been in your tree
>> > since v4.8-rc7) and that is where I originally actually got a conflict.  
>> 
>> Oh, interesting. Why didn't I get the conflict there then?
>> 
>> I'm guessing (but too lazy to actually look up the history), that
>> David ended up doing that merge and that ends up being why I never saw
>> a conflict.
> 
> Yeah, commit b50afd203a5e ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") actually
> merges v4.8 into the net-next tree.

Yes, this is where the change got lost.

I have all of the fixups queued up in my net tree and will send in a pull
request later.

Re: linux-next: manual merge of the akpm-current tree with the percpu tree

[Stephen Rothwell]

Hi all,

On Thu, 6 Oct 2016 13:43:57 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/percpu.c
> 
> between commits:
> 
>   93c76b6b2faa ("mm/percpu.c: correct max_distance calculation for 
> pcpu_embed_first_chunk()")
>   9b7396624a7b ("mm/percpu.c: fix potential memory leakage for 
> pcpu_embed_first_chunk()")
> 
> from the percpu tree and commit:
> 
>   567f646230a5 ("mm/percpu.c: correct max_distance calculation for 
> pcpu_embed_first_chunk()")
> 
> from the akpm-current tree.
> 
> There is one small differenve between 567f646230a5 and 9b7396624a7b and
> then further changes in 93c76b6b2faa.

Cut an paste error.  Should have said:

There is one small difference between 567f646230a5 and 93c76b6b2faa and
then further changes in 9b7396624a7b.

-- 
Cheers,
Stephen Rothwell

Re: [GIT] Networking

[David Miller]

From: Stephen Rothwell 
Date: Thu, 6 Oct 2016 13:51:52 +1100

> On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds 
>  wrote:
>>
>> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell  
>> wrote:
>> >
>> > Except that commit effectively moved that function from
>> > net/netfilter/nf_tables_netdev.c to
>> > include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
>> > ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
>> > removed the assignment in the original file (and has been in your tree
>> > since v4.8-rc7) and that is where I originally actually got a conflict.  
>> 
>> Oh, interesting. Why didn't I get the conflict there then?
>> 
>> I'm guessing (but too lazy to actually look up the history), that
>> David ended up doing that merge and that ends up being why I never saw
>> a conflict.
> 
> Yeah, commit b50afd203a5e ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") actually
> merges v4.8 into the net-next tree.

Yes, this is where the change got lost.

I have all of the fixups queued up in my net tree and will send in a pull
request later.

Re: [GIT] Networking

[Stephen Rothwell]

Hi Linus,

On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds 
 wrote:
>
> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell  
> wrote:
> >
> > Except that commit effectively moved that function from
> > net/netfilter/nf_tables_netdev.c to
> > include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
> > ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
> > removed the assignment in the original file (and has been in your tree
> > since v4.8-rc7) and that is where I originally actually got a conflict.  
> 
> Oh, interesting. Why didn't I get the conflict there then?
> 
> I'm guessing (but too lazy to actually look up the history), that
> David ended up doing that merge and that ends up being why I never saw
> a conflict.

Yeah, commit b50afd203a5e ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") actually
merges v4.8 into the net-next tree.

-- 
Cheers,
Stephen Rothwell

Re: [GIT] Networking

[Stephen Rothwell]

Hi Linus,

On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds 
 wrote:
>
> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell  
> wrote:
> >
> > Except that commit effectively moved that function from
> > net/netfilter/nf_tables_netdev.c to
> > include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
> > ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
> > removed the assignment in the original file (and has been in your tree
> > since v4.8-rc7) and that is where I originally actually got a conflict.  
> 
> Oh, interesting. Why didn't I get the conflict there then?
> 
> I'm guessing (but too lazy to actually look up the history), that
> David ended up doing that merge and that ends up being why I never saw
> a conflict.

Yeah, commit b50afd203a5e ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") actually
merges v4.8 into the net-next tree.

-- 
Cheers,
Stephen Rothwell

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

[Nicolas Pitre]

On Thu, 6 Oct 2016, Fengguang Wu wrote:

> On Tue, Oct 04, 2016 at 09:08:27AM -0400, Nicolas Pitre wrote:
> >On Tue, 4 Oct 2016, Fengguang Wu wrote:
> >
> > > CC Michal. It looks like a microblaze specific error. I'll blacklist
> > > this old error on microblaze if there are no good solutions.
> >
> >It doesn't exhibit any build error on my end.  Which is why I suggested
> >that you verify the integrity of your toolchain on your end.
> 
> OK, let me try upgrade the debian package first.
> What's your toolchain version?

The one that was installed by make.cross from the reproduction 
instructions included in the error report below. Currently:

gcc version 4.9.0
GNU ld (GNU Binutils) 2.24


> > > On Fri, Sep 23, 2016 at 05:11:32PM -0400, Nicolas Pitre wrote:
> > > >On Thu, 22 Sep 2016, kbuild test robot wrote:
> > > >
> > > > > Hi Nicolas,
> > > > >
> > > > > FYI, the error/warning still remains.
> > > > >
> > > > > tree:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > > > master
> > > > > head:   7d1e042314619115153a0f6f06e4552c09a50e13
> > > > > commit: 461a5e51060c93f5844113f4be9dba513cc92830 do_div(): generic
> > > > > optimization for constant divisor on 32-bit machines
> > > > > date:   10 months ago
> > > > > config: microblaze-mmu_defconfig (attached as .config)
> > > > > compiler: microblaze-linux-gcc (GCC) 6.2.0
> > > > > reproduce:
> > > > > wget
> > > > > 
> > > > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > > > > -O ~/bin/make.cross
> > > > > chmod +x ~/bin/make.cross
> > > > > git checkout 461a5e51060c93f5844113f4be9dba513cc92830
> > > > > # save the attached .config to linux build tree
> > > > > make.cross ARCH=microblaze
> > > > >
> > > > > All errors (new ones prefixed by >>):
> > > > >
> > > > >net/built-in.o: In function `rpc_print_iostats':
> > > > > > > net/sunrpc/stats.c:204: undefined reference to
> > > > > > > `_GLOBAL_OFFSET_TABLE_'
> > > > >scripts/link-vmlinux.sh: line 52:  5714 Segmentation fault
> > > > >${LD}
> > > > >${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds}
> > > > >${KBUILD_VMLINUX_INIT}
> > > > >--start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}
> > > >
> > > >The problem must be at your end, especially if the toolchain exhibits
> > > >segmentation faults.
> > > >
> > > >Following exactly the instructions above, I get:
> > > >
> > > >[...]
> > > >  LD  vmlinux
> > > >  SORTEX  vmlinux
> > > >  SYSMAP  System.map
> > > >  OBJCOPY arch/microblaze/boot/linux.bin
> > > >  Building modules, stage 2.
> > > >  MODPOST 3 modules
> > > >  CC  crypto/drbg.mod.o
> > > >  CC  crypto/echainiv.mod.o
> > > >  CC  crypto/jitterentropy_rng.mod.o
> > > >  LD [M]  crypto/jitterentropy_rng.ko
> > > >  LD [M]  crypto/drbg.ko
> > > >  LD [M]  crypto/echainiv.ko
> > > >Kernel: arch/microblaze/boot/linux.bin is ready  (#1)
> > > >
> > > >
> > > >Nicolas
> > >
> 
> 

linux-next: manual merge of the akpm-current tree with the percpu tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/percpu.c

between commits:

  93c76b6b2faa ("mm/percpu.c: correct max_distance calculation for 
pcpu_embed_first_chunk()")
  9b7396624a7b ("mm/percpu.c: fix potential memory leakage for 
pcpu_embed_first_chunk()")

from the percpu tree and commit:

  567f646230a5 ("mm/percpu.c: correct max_distance calculation for 
pcpu_embed_first_chunk()")

from the akpm-current tree.

There is one small differenve between 567f646230a5 and 9b7396624a7b and
then further changes in 93c76b6b2faa.

I fixed it up (using the percpu tree version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

[Nicolas Pitre]

On Thu, 6 Oct 2016, Fengguang Wu wrote:

> On Tue, Oct 04, 2016 at 09:08:27AM -0400, Nicolas Pitre wrote:
> >On Tue, 4 Oct 2016, Fengguang Wu wrote:
> >
> > > CC Michal. It looks like a microblaze specific error. I'll blacklist
> > > this old error on microblaze if there are no good solutions.
> >
> >It doesn't exhibit any build error on my end.  Which is why I suggested
> >that you verify the integrity of your toolchain on your end.
> 
> OK, let me try upgrade the debian package first.
> What's your toolchain version?

The one that was installed by make.cross from the reproduction 
instructions included in the error report below. Currently:

gcc version 4.9.0
GNU ld (GNU Binutils) 2.24


> > > On Fri, Sep 23, 2016 at 05:11:32PM -0400, Nicolas Pitre wrote:
> > > >On Thu, 22 Sep 2016, kbuild test robot wrote:
> > > >
> > > > > Hi Nicolas,
> > > > >
> > > > > FYI, the error/warning still remains.
> > > > >
> > > > > tree:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > > > master
> > > > > head:   7d1e042314619115153a0f6f06e4552c09a50e13
> > > > > commit: 461a5e51060c93f5844113f4be9dba513cc92830 do_div(): generic
> > > > > optimization for constant divisor on 32-bit machines
> > > > > date:   10 months ago
> > > > > config: microblaze-mmu_defconfig (attached as .config)
> > > > > compiler: microblaze-linux-gcc (GCC) 6.2.0
> > > > > reproduce:
> > > > > wget
> > > > > 
> > > > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > > > > -O ~/bin/make.cross
> > > > > chmod +x ~/bin/make.cross
> > > > > git checkout 461a5e51060c93f5844113f4be9dba513cc92830
> > > > > # save the attached .config to linux build tree
> > > > > make.cross ARCH=microblaze
> > > > >
> > > > > All errors (new ones prefixed by >>):
> > > > >
> > > > >net/built-in.o: In function `rpc_print_iostats':
> > > > > > > net/sunrpc/stats.c:204: undefined reference to
> > > > > > > `_GLOBAL_OFFSET_TABLE_'
> > > > >scripts/link-vmlinux.sh: line 52:  5714 Segmentation fault
> > > > >${LD}
> > > > >${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds}
> > > > >${KBUILD_VMLINUX_INIT}
> > > > >--start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}
> > > >
> > > >The problem must be at your end, especially if the toolchain exhibits
> > > >segmentation faults.
> > > >
> > > >Following exactly the instructions above, I get:
> > > >
> > > >[...]
> > > >  LD  vmlinux
> > > >  SORTEX  vmlinux
> > > >  SYSMAP  System.map
> > > >  OBJCOPY arch/microblaze/boot/linux.bin
> > > >  Building modules, stage 2.
> > > >  MODPOST 3 modules
> > > >  CC  crypto/drbg.mod.o
> > > >  CC  crypto/echainiv.mod.o
> > > >  CC  crypto/jitterentropy_rng.mod.o
> > > >  LD [M]  crypto/jitterentropy_rng.ko
> > > >  LD [M]  crypto/drbg.ko
> > > >  LD [M]  crypto/echainiv.ko
> > > >Kernel: arch/microblaze/boot/linux.bin is ready  (#1)
> > > >
> > > >
> > > >Nicolas
> > >
> 
> 

linux-next: manual merge of the akpm-current tree with the percpu tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/percpu.c

between commits:

  93c76b6b2faa ("mm/percpu.c: correct max_distance calculation for 
pcpu_embed_first_chunk()")
  9b7396624a7b ("mm/percpu.c: fix potential memory leakage for 
pcpu_embed_first_chunk()")

from the percpu tree and commit:

  567f646230a5 ("mm/percpu.c: correct max_distance calculation for 
pcpu_embed_first_chunk()")

from the akpm-current tree.

There is one small differenve between 567f646230a5 and 9b7396624a7b and
then further changes in 93c76b6b2faa.

I fixed it up (using the percpu tree version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[PATCH v2] scsi: ufshcd: fix possible unclocked register access

[Subhash Jadavani]

Vendor specific setup_clocks callback may require the clocks managed
by ufshcd driver to be ON. So if the vendor specific setup_clocks callback
is called while the required clocks are turned off, it could result into
unclocked register access.

To prevent possible unclock register access, this change makes sure that
required clocks remain enabled before calling into vendor specific
setup_clocks callback.

Signed-off-by: Subhash Jadavani 
---
Changes from v2:
* Don't call ufshcd_vops_setup_clocks() again for clock off
---
 drivers/scsi/ufs/ufshcd.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 05c7456..c1a77d3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5389,6 +5389,17 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
if (!head || list_empty(head))
goto out;
 
+   /*
+* vendor specific setup_clocks ops may depend on clocks managed by
+* this standard driver hence call the vendor specific setup_clocks
+* before disabling the clocks managed here.
+*/
+   if (!on) {
+   ret = ufshcd_vops_setup_clocks(hba, on);
+   if (ret)
+   return ret;
+   }
+
list_for_each_entry(clki, head, list) {
if (!IS_ERR_OR_NULL(clki->clk)) {
if (skip_ref_clk && !strcmp(clki->name, "ref_clk"))
@@ -5410,7 +5421,16 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
}
}
 
-   ret = ufshcd_vops_setup_clocks(hba, on);
+   /*
+* vendor specific setup_clocks ops may depend on clocks managed by
+* this standard driver hence call the vendor specific setup_clocks
+* after enabling the clocks managed here.
+*/
+   if (on) {
+   ret = ufshcd_vops_setup_clocks(hba, on);
+   if (ret)
+   return ret;
+   }
 out:
if (ret) {
list_for_each_entry(clki, head, list) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2] scsi: ufshcd: fix possible unclocked register access

[Subhash Jadavani]

Vendor specific setup_clocks callback may require the clocks managed
by ufshcd driver to be ON. So if the vendor specific setup_clocks callback
is called while the required clocks are turned off, it could result into
unclocked register access.

To prevent possible unclock register access, this change makes sure that
required clocks remain enabled before calling into vendor specific
setup_clocks callback.

Signed-off-by: Subhash Jadavani 
---
Changes from v2:
* Don't call ufshcd_vops_setup_clocks() again for clock off
---
 drivers/scsi/ufs/ufshcd.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 05c7456..c1a77d3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5389,6 +5389,17 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
if (!head || list_empty(head))
goto out;
 
+   /*
+* vendor specific setup_clocks ops may depend on clocks managed by
+* this standard driver hence call the vendor specific setup_clocks
+* before disabling the clocks managed here.
+*/
+   if (!on) {
+   ret = ufshcd_vops_setup_clocks(hba, on);
+   if (ret)
+   return ret;
+   }
+
list_for_each_entry(clki, head, list) {
if (!IS_ERR_OR_NULL(clki->clk)) {
if (skip_ref_clk && !strcmp(clki->name, "ref_clk"))
@@ -5410,7 +5421,16 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
}
}
 
-   ret = ufshcd_vops_setup_clocks(hba, on);
+   /*
+* vendor specific setup_clocks ops may depend on clocks managed by
+* this standard driver hence call the vendor specific setup_clocks
+* after enabling the clocks managed here.
+*/
+   if (on) {
+   ret = ufshcd_vops_setup_clocks(hba, on);
+   if (ret)
+   return ret;
+   }
 out:
if (ret) {
list_for_each_entry(clki, head, list) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [GIT] Networking

[Linus Torvalds]

On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell  wrote:
>
> Except that commit effectively moved that function from
> net/netfilter/nf_tables_netdev.c to
> include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
> ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
> removed the assignment in the original file (and has been in your tree
> since v4.8-rc7) and that is where I originally actually got a conflict.

Oh, interesting. Why didn't I get the conflict there then?

I'm guessing (but too lazy to actually look up the history), that
David ended up doing that merge and that ends up being why I never saw
a conflict.

   Linus

Re: [GIT] Networking

[Linus Torvalds]

On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell  wrote:
>
> Except that commit effectively moved that function from
> net/netfilter/nf_tables_netdev.c to
> include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
> ("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
> removed the assignment in the original file (and has been in your tree
> since v4.8-rc7) and that is where I originally actually got a conflict.

Oh, interesting. Why didn't I get the conflict there then?

I'm guessing (but too lazy to actually look up the history), that
David ended up doing that merge and that ends up being why I never saw
a conflict.

   Linus

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

[Dave Chinner]

On Wed, Oct 05, 2016 at 01:38:45PM +0200, Michal Hocko wrote:
> On Wed 05-10-16 07:32:02, Dave Chinner wrote:
> > On Tue, Oct 04, 2016 at 10:12:15AM +0200, Michal Hocko wrote:
> > > From: Michal Hocko 
> > > 
> > > compaction has been disabled for GFP_NOFS and GFP_NOIO requests since
> > > the direct compaction was introduced by 56de7263fcf3 ("mm: compaction:
> > > direct compact when a high-order allocation fails"). The main reason
> > > is that the migration of page cache pages might recurse back to fs/io
> > > layer and we could potentially deadlock. This is overly conservative
> > > because all the anonymous memory is migrateable in the GFP_NOFS context
> > > just fine.  This might be a large portion of the memory in many/most
> > > workkloads.
> > > 
> > > Remove the GFP_NOFS restriction and make sure that we skip all fs pages
> > > (those with a mapping) while isolating pages to be migrated. We cannot
> > > consider clean fs pages because they might need a metadata update so
> > > only isolate pages without any mapping for nofs requests.
> > > 
> > > The effect of this patch will be probably very limited in many/most
> > > workloads because higher order GFP_NOFS requests are quite rare,
> > 
> > You say they are rare only because you don't know how to trigger
> > them easily.  :/
> 
> true
> 
> > Try this:
> > 
> > # mkfs.xfs -f -n size=64k 
> > # mount  /mnt/scratch
> > # time ./fs_mark  -D  1  -S0  -n  10  -s  0  -L  32 \
> > -d  /mnt/scratch/0  -d  /mnt/scratch/1 \
> > -d  /mnt/scratch/2  -d  /mnt/scratch/3 \
> > -d  /mnt/scratch/4  -d  /mnt/scratch/5 \
> > -d  /mnt/scratch/6  -d  /mnt/scratch/7 \
> > -d  /mnt/scratch/8  -d  /mnt/scratch/9 \
> > -d  /mnt/scratch/10  -d  /mnt/scratch/11 \
> > -d  /mnt/scratch/12  -d  /mnt/scratch/13 \
> > -d  /mnt/scratch/14  -d  /mnt/scratch/15
> 
> Does this simulate a standard or usual fs workload/configuration?  I am

Unfortunately, there was an era of cargo cult configuration tweaks
in the Ceph community that has resulted in a large number of
production machines with XFS filesystems configured this way. And a
lot of them store large numbers of small files and run under
significant sustained memory pressure.

I slowly working towards getting rid of these high order allocations
and replacing them with the equivalent number of single page
allocations, but I haven't got that (complex) change working yet.

> not questioning that higher order NOFS allocations are non-existent -
> that's why I came with the patch in the first place ;). My observation
> was that they are so rare that the visible effect of this patch might be
> quite low or even hard to notice.

Yup, it's a valid observation that would hold true for the majority
of users.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

[Dave Chinner]

On Wed, Oct 05, 2016 at 01:38:45PM +0200, Michal Hocko wrote:
> On Wed 05-10-16 07:32:02, Dave Chinner wrote:
> > On Tue, Oct 04, 2016 at 10:12:15AM +0200, Michal Hocko wrote:
> > > From: Michal Hocko 
> > > 
> > > compaction has been disabled for GFP_NOFS and GFP_NOIO requests since
> > > the direct compaction was introduced by 56de7263fcf3 ("mm: compaction:
> > > direct compact when a high-order allocation fails"). The main reason
> > > is that the migration of page cache pages might recurse back to fs/io
> > > layer and we could potentially deadlock. This is overly conservative
> > > because all the anonymous memory is migrateable in the GFP_NOFS context
> > > just fine.  This might be a large portion of the memory in many/most
> > > workkloads.
> > > 
> > > Remove the GFP_NOFS restriction and make sure that we skip all fs pages
> > > (those with a mapping) while isolating pages to be migrated. We cannot
> > > consider clean fs pages because they might need a metadata update so
> > > only isolate pages without any mapping for nofs requests.
> > > 
> > > The effect of this patch will be probably very limited in many/most
> > > workloads because higher order GFP_NOFS requests are quite rare,
> > 
> > You say they are rare only because you don't know how to trigger
> > them easily.  :/
> 
> true
> 
> > Try this:
> > 
> > # mkfs.xfs -f -n size=64k 
> > # mount  /mnt/scratch
> > # time ./fs_mark  -D  1  -S0  -n  10  -s  0  -L  32 \
> > -d  /mnt/scratch/0  -d  /mnt/scratch/1 \
> > -d  /mnt/scratch/2  -d  /mnt/scratch/3 \
> > -d  /mnt/scratch/4  -d  /mnt/scratch/5 \
> > -d  /mnt/scratch/6  -d  /mnt/scratch/7 \
> > -d  /mnt/scratch/8  -d  /mnt/scratch/9 \
> > -d  /mnt/scratch/10  -d  /mnt/scratch/11 \
> > -d  /mnt/scratch/12  -d  /mnt/scratch/13 \
> > -d  /mnt/scratch/14  -d  /mnt/scratch/15
> 
> Does this simulate a standard or usual fs workload/configuration?  I am

Unfortunately, there was an era of cargo cult configuration tweaks
in the Ceph community that has resulted in a large number of
production machines with XFS filesystems configured this way. And a
lot of them store large numbers of small files and run under
significant sustained memory pressure.

I slowly working towards getting rid of these high order allocations
and replacing them with the equivalent number of single page
allocations, but I haven't got that (complex) change working yet.

> not questioning that higher order NOFS allocations are non-existent -
> that's why I came with the patch in the first place ;). My observation
> was that they are so rare that the visible effect of this patch might be
> quite low or even hard to notice.

Yup, it's a valid observation that would hold true for the majority
of users.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

On Wed, Oct 5, 2016 at 6:59 PM, Dave Chinner  wrote:
>
> In XFS, we use ASSERT() (could be XFS_BUG_ON() for all
> that the name matters) but we only define that to BUG_ON if
> CONFIG_XFS_DEBUG=y.
>
> For "production debug" kernels we have CONFIG_XFS_WARN=y, which
> turns ASSERT() into WARN_ON(). We get the warnings, but none of the
> crashiness that are desirable in a development context.

Yes. that sounds very much like the right kind of decision.

Forcing crashes can be very useful for the actual developer that is
doing development on the code itself, kind of a "fail fast, fail
hard".

But users (or developers that are developing something _else_ than XFS
;) don't tend to like it.

 Linus

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

On Wed, Oct 5, 2016 at 6:59 PM, Dave Chinner  wrote:
>
> In XFS, we use ASSERT() (could be XFS_BUG_ON() for all
> that the name matters) but we only define that to BUG_ON if
> CONFIG_XFS_DEBUG=y.
>
> For "production debug" kernels we have CONFIG_XFS_WARN=y, which
> turns ASSERT() into WARN_ON(). We get the warnings, but none of the
> crashiness that are desirable in a development context.

Yes. that sounds very much like the right kind of decision.

Forcing crashes can be very useful for the actual developer that is
doing development on the code itself, kind of a "fail fast, fail
hard".

But users (or developers that are developing something _else_ than XFS
;) don't tend to like it.

 Linus

Re: [PATCH] x86/entry/64: Fix context tracking state warning when load_gs_index fails

[Andy Lutomirski]

On Sep 29, 2016 5:43 PM, "Wanpeng Li"  wrote:
>
> 2016-09-30 5:01 GMT+08:00 Andy Lutomirski :
> > On Mon, Sep 26, 2016 at 4:49 AM, Wanpeng Li  wrote:
> >> From: Wanpeng Li 
> >>
> >>  WARNING: CPU: 0 PID: 3331 at arch/x86/entry/common.c:45 
> >> enter_from_user_mode+0x32/0x50
> >>  CPU: 0 PID: 3331 Comm: ldt_gdt_64 Not tainted 4.8.0-rc7+ #13
> >>  Call Trace:
> >>   dump_stack+0x99/0xd0
> >>   __warn+0xd1/0xf0
> >>   warn_slowpath_null+0x1d/0x20
> >>   enter_from_user_mode+0x32/0x50
> >>   error_entry+0x6d/0xc0
> >>   ? general_protection+0x12/0x30
> >>   ? native_load_gs_index+0xd/0x20
> >>   ? do_set_thread_area+0x19c/0x1f0
> >>   SyS_set_thread_area+0x24/0x30
> >>   do_int80_syscall_32+0x7c/0x220
> >>   entry_INT80_compat+0x38/0x50
> >>
> >> This can be reproduced by running the GS testcase of ldt_gdt test unit in
> >> selftests.
> >>
> >> do_int80_syscall_32() will call enter_form_user_mode() to convert context
> >> tracking state from user state to kernel state. The load_gs_index can fail
> >> with user gsbase, gsbase will be fixed up and proceed if this happen.
> >> However, enter_from_user_mode() will be called again in the fixed up path
> >> though it is context tracking kernel state currently.
> >>
> >> This patch fix it by just fixing up gsbase and telling lockdep that IRQs
> >> are off once load_gs_index failed with user gsbase.
> >>
> >> Cc: Thomas Gleixner 
> >> Cc: Ingo Molnar 
> >> Cc: "H. Peter Anvin" 
> >> Cc: Andy Lutomirski 
> >> Cc: Borislav Petkov 
> >> Signed-off-by: Wanpeng Li 
> >> ---
> >>  arch/x86/entry/entry_64.S | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> >> index d172c61..dc1ec23 100644
> >> --- a/arch/x86/entry/entry_64.S
> >> +++ b/arch/x86/entry/entry_64.S
> >> @@ -1045,7 +1045,9 @@ ENTRY(error_entry)
> >>  * gsbase and proceed.  We'll fix up the exception and land in
> >>  * .Lgs_change's error handler with kernel gsbase.
> >>  */
> >> -   jmp .Lerror_entry_from_usermode_swapgs
> >> +   SWAPGS
> >> +   TRACE_IRQS_OFF
> >
> > Let's make this more readable: can you change this to:
> >
> > SWAPGS
> > jmp .Lerror_entry_done
> >
> > and remove the .Lerror_entry_from_usermode_swapgs label as well?
>
> I will do this in v2. Btw, could you point out why the GS testcase in
> tools/testing/selftests/x86/ldt_gdt.c will #GP? SDM said that swapgs
> will #GP if CPL != 0, however, native_load_gs_index() is CPL == 0.

The fault is on MOV, not SWAPGS.

--Andy

Re: [PATCH] tpm: don't destroy chip device prematurely

[Jason Gunthorpe]

On Thu, Oct 06, 2016 at 12:43:13AM +, Winkler, Tomas wrote:

> > You keep asserting that, but it just isn't true at all.
> 
> Okay, let's rephrase, that calling device_del before tpm_transmit is not sane 
> when using runtime_pm.

Maybe, but I haven't heard an explanation from you why that is the case,
and I haven't found one on my own..

> > Sure, but that relationship only maters if something does a PM call on the
> > chip->dev, and AFAIK, nothing does that.
> > 
> > Do you know differently?
> 
> You've pasted that code in in the previous mail, parent is involved on device 
> remove.

I pasted the code to show it didn't seem possible to hit it because
irq_safe should not be true for chip->dev. You never explained how
this code can run.

> > You pointed at something that isn't even run and said it is the source of 
> > the
> > problem.. You really need to set up here and explain exactly what is
> > happening.
> 
> Sorry, lost you here.

You haven't done a good job explaining the problem in detail beyond some general
blame toward PM.

> > > > Even if that pm_runtime_put is happening, why doesn't the
> > > >
> > > > +pm_runtime_get_sync(chip->dev.parent);
> > > >
> > > > The runtime_pm patch adds to tpm_transmit take care of bringing the
> > > > device back?
> > >
> > > Unfortunately not because, because it gets out of sync and what is
> > > actually happening is that idle callback is called and device is put
> > > to idle between send and receive.
> > 
> > What? As far as I understand this PM stuff, I would call that a very 
> > serious bug.
> 
> Maybe, but then you have to find what a bug,  currently it looks
> like wrong usage of the device.

Yes, you actually have to find and explain the bug to fix it.

You still haven't explained at all why device_del on the child causes
pm_runtime_get_sync() on the parent to malfunction. There is certainly
seems to be nothing intrinsic about the PM core that would cause that.

*That* is the really critical bit of explanation that is missing.

Until you can provide it there is no reason to continue discussing.

> > If a PM transition during transmit_cmd causes the TPM to abort/fail command
> > execution then it *MUST* be prevented. Period.
> 
> Or, we can call device_del after tpm2_shutdown. 

What? You haven't even established root cause, how do you know this
bug won't manifest in other cases? It could very well be some kind of
generic race-bug triggered by the proximity of device_del and
pm_runtime_get_sync. Or a HW bug of some kind..

> I will send you the actual trace, anyhow I've respin the original
> version with go_idle and cmd_ready handlers, this is contra
> productive, the time is just not right.

I'm deeply skeptical about all your patches if you can't root-cause
identify why the existing implementation isn't working.

But, you can sort out with Jarkko what to do with crb.

As long at the rest of the drivers and the core subsystem are not
broken by the device_del change. Jarkko - can you confirm you will
drop that patch?

Jason

Re: [PATCH] x86/entry/64: Fix context tracking state warning when load_gs_index fails

[Andy Lutomirski]

On Sep 29, 2016 5:43 PM, "Wanpeng Li"  wrote:
>
> 2016-09-30 5:01 GMT+08:00 Andy Lutomirski :
> > On Mon, Sep 26, 2016 at 4:49 AM, Wanpeng Li  wrote:
> >> From: Wanpeng Li 
> >>
> >>  WARNING: CPU: 0 PID: 3331 at arch/x86/entry/common.c:45 
> >> enter_from_user_mode+0x32/0x50
> >>  CPU: 0 PID: 3331 Comm: ldt_gdt_64 Not tainted 4.8.0-rc7+ #13
> >>  Call Trace:
> >>   dump_stack+0x99/0xd0
> >>   __warn+0xd1/0xf0
> >>   warn_slowpath_null+0x1d/0x20
> >>   enter_from_user_mode+0x32/0x50
> >>   error_entry+0x6d/0xc0
> >>   ? general_protection+0x12/0x30
> >>   ? native_load_gs_index+0xd/0x20
> >>   ? do_set_thread_area+0x19c/0x1f0
> >>   SyS_set_thread_area+0x24/0x30
> >>   do_int80_syscall_32+0x7c/0x220
> >>   entry_INT80_compat+0x38/0x50
> >>
> >> This can be reproduced by running the GS testcase of ldt_gdt test unit in
> >> selftests.
> >>
> >> do_int80_syscall_32() will call enter_form_user_mode() to convert context
> >> tracking state from user state to kernel state. The load_gs_index can fail
> >> with user gsbase, gsbase will be fixed up and proceed if this happen.
> >> However, enter_from_user_mode() will be called again in the fixed up path
> >> though it is context tracking kernel state currently.
> >>
> >> This patch fix it by just fixing up gsbase and telling lockdep that IRQs
> >> are off once load_gs_index failed with user gsbase.
> >>
> >> Cc: Thomas Gleixner 
> >> Cc: Ingo Molnar 
> >> Cc: "H. Peter Anvin" 
> >> Cc: Andy Lutomirski 
> >> Cc: Borislav Petkov 
> >> Signed-off-by: Wanpeng Li 
> >> ---
> >>  arch/x86/entry/entry_64.S | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> >> index d172c61..dc1ec23 100644
> >> --- a/arch/x86/entry/entry_64.S
> >> +++ b/arch/x86/entry/entry_64.S
> >> @@ -1045,7 +1045,9 @@ ENTRY(error_entry)
> >>  * gsbase and proceed.  We'll fix up the exception and land in
> >>  * .Lgs_change's error handler with kernel gsbase.
> >>  */
> >> -   jmp .Lerror_entry_from_usermode_swapgs
> >> +   SWAPGS
> >> +   TRACE_IRQS_OFF
> >
> > Let's make this more readable: can you change this to:
> >
> > SWAPGS
> > jmp .Lerror_entry_done
> >
> > and remove the .Lerror_entry_from_usermode_swapgs label as well?
>
> I will do this in v2. Btw, could you point out why the GS testcase in
> tools/testing/selftests/x86/ldt_gdt.c will #GP? SDM said that swapgs
> will #GP if CPL != 0, however, native_load_gs_index() is CPL == 0.

The fault is on MOV, not SWAPGS.

--Andy

Re: [PATCH] tpm: don't destroy chip device prematurely

[Jason Gunthorpe]

On Thu, Oct 06, 2016 at 12:43:13AM +, Winkler, Tomas wrote:

> > You keep asserting that, but it just isn't true at all.
> 
> Okay, let's rephrase, that calling device_del before tpm_transmit is not sane 
> when using runtime_pm.

Maybe, but I haven't heard an explanation from you why that is the case,
and I haven't found one on my own..

> > Sure, but that relationship only maters if something does a PM call on the
> > chip->dev, and AFAIK, nothing does that.
> > 
> > Do you know differently?
> 
> You've pasted that code in in the previous mail, parent is involved on device 
> remove.

I pasted the code to show it didn't seem possible to hit it because
irq_safe should not be true for chip->dev. You never explained how
this code can run.

> > You pointed at something that isn't even run and said it is the source of 
> > the
> > problem.. You really need to set up here and explain exactly what is
> > happening.
> 
> Sorry, lost you here.

You haven't done a good job explaining the problem in detail beyond some general
blame toward PM.

> > > > Even if that pm_runtime_put is happening, why doesn't the
> > > >
> > > > +pm_runtime_get_sync(chip->dev.parent);
> > > >
> > > > The runtime_pm patch adds to tpm_transmit take care of bringing the
> > > > device back?
> > >
> > > Unfortunately not because, because it gets out of sync and what is
> > > actually happening is that idle callback is called and device is put
> > > to idle between send and receive.
> > 
> > What? As far as I understand this PM stuff, I would call that a very 
> > serious bug.
> 
> Maybe, but then you have to find what a bug,  currently it looks
> like wrong usage of the device.

Yes, you actually have to find and explain the bug to fix it.

You still haven't explained at all why device_del on the child causes
pm_runtime_get_sync() on the parent to malfunction. There is certainly
seems to be nothing intrinsic about the PM core that would cause that.

*That* is the really critical bit of explanation that is missing.

Until you can provide it there is no reason to continue discussing.

> > If a PM transition during transmit_cmd causes the TPM to abort/fail command
> > execution then it *MUST* be prevented. Period.
> 
> Or, we can call device_del after tpm2_shutdown. 

What? You haven't even established root cause, how do you know this
bug won't manifest in other cases? It could very well be some kind of
generic race-bug triggered by the proximity of device_del and
pm_runtime_get_sync. Or a HW bug of some kind..

> I will send you the actual trace, anyhow I've respin the original
> version with go_idle and cmd_ready handlers, this is contra
> productive, the time is just not right.

I'm deeply skeptical about all your patches if you can't root-cause
identify why the existing implementation isn't working.

But, you can sort out with Jarkko what to do with crb.

As long at the rest of the drivers and the core subsystem are not
broken by the device_del change. Jarkko - can you confirm you will
drop that patch?

Jason

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Dave Chinner]

On Tue, Oct 04, 2016 at 08:29:00PM -0700, Linus Torvalds wrote:
> On Tue, Oct 4, 2016 at 7:43 PM, Paul Gortmaker
>  wrote:
> >
> > A couple years ago Ingo had an idea to kill  BUG_ON abuse that I made
> > a 1st pass at.  Back then it seemed nobody cared.  Maybe that has since
> > changed?
> >
> > https://lkml.org/lkml/2014/4/30/359
> 
> So we actually have the checkpatch warning already:
> 
>   # avoid BUG() or BUG_ON()
> if ($line =~ /\b(?:BUG|BUG_ON)\b/) {
> my $msg_type = \
> $msg_type = \ if ($file);
> &{$msg_type}("AVOID_BUG",
>  "Avoid crashing the kernel - try
> using WARN_ON & recovery code rather than BUG() or BUG_ON()\n" .
> $herecurr);
> }
> 
> but it doesn't trigger on VM_BUG_ON().
> 
> And I'm not convinced about replacing things with BUG_ON_AND_HALT(),
> it simply doesn't fix the existing issue we have: people use BUG_ON(),
> and worse, _when_ they use BUG_ON(), they use it instead of error
> handling, so the code _around_ the BUG_ON() tends to then very much
> depend on what the BUG_ON() checks.
> 
> This is actually one way that VM_BUG_ON() is better: it's very much by
> design something that can be compiled away, so at least hopefully
> nobody thinks of it as a security measure. So we could just say that
> we will treat VM_BUG_ON() as a WARN_ON_ONCE(), and just not kill the
> machine.

In XFS, we use ASSERT() (could be XFS_BUG_ON() for all
that the name matters) but we only define that to BUG_ON if
CONFIG_XFS_DEBUG=y.

For "production debug" kernels we have CONFIG_XFS_WARN=y, which
turns ASSERT() into WARN_ON(). We get the warnings, but none of the
crashiness that are desirable in a development context. This is what
distro debug kernels should be using, as it also ensures
we don't build in the real debug code that does things that would
affect prodution systems adversely, like randomly take different
allocator paths to ensure we get code coverage of all the allocator
algorithms...

i.e. production kernels ship with neither set, the debug kernel
ships with CONFIG_XFS_WARN=y, and we do all our development with
CONFIG_XFS_DEBUG=y.

I think this case falls into the "production debug" classification;
we want a warning, but we don't want the system to be taken down

> But apart from the checkpatch thing, it's actually a pretty big change.

Yeah, that's why we added CONFIG_XFS_WARN=y to do this - it was a 20
line change to add XFS_CONFIG_WARN instead of having to audit and
modify ~1800 call sites to do something differently. And because we
know that ASSERT() is not present in all kernels, it isn't ever used
as a replacement for error handling. Perhaps that's the simplest
solution here as well

Just my 2c worth.

-Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Dave Chinner]

On Tue, Oct 04, 2016 at 08:29:00PM -0700, Linus Torvalds wrote:
> On Tue, Oct 4, 2016 at 7:43 PM, Paul Gortmaker
>  wrote:
> >
> > A couple years ago Ingo had an idea to kill  BUG_ON abuse that I made
> > a 1st pass at.  Back then it seemed nobody cared.  Maybe that has since
> > changed?
> >
> > https://lkml.org/lkml/2014/4/30/359
> 
> So we actually have the checkpatch warning already:
> 
>   # avoid BUG() or BUG_ON()
> if ($line =~ /\b(?:BUG|BUG_ON)\b/) {
> my $msg_type = \
> $msg_type = \ if ($file);
> &{$msg_type}("AVOID_BUG",
>  "Avoid crashing the kernel - try
> using WARN_ON & recovery code rather than BUG() or BUG_ON()\n" .
> $herecurr);
> }
> 
> but it doesn't trigger on VM_BUG_ON().
> 
> And I'm not convinced about replacing things with BUG_ON_AND_HALT(),
> it simply doesn't fix the existing issue we have: people use BUG_ON(),
> and worse, _when_ they use BUG_ON(), they use it instead of error
> handling, so the code _around_ the BUG_ON() tends to then very much
> depend on what the BUG_ON() checks.
> 
> This is actually one way that VM_BUG_ON() is better: it's very much by
> design something that can be compiled away, so at least hopefully
> nobody thinks of it as a security measure. So we could just say that
> we will treat VM_BUG_ON() as a WARN_ON_ONCE(), and just not kill the
> machine.

In XFS, we use ASSERT() (could be XFS_BUG_ON() for all
that the name matters) but we only define that to BUG_ON if
CONFIG_XFS_DEBUG=y.

For "production debug" kernels we have CONFIG_XFS_WARN=y, which
turns ASSERT() into WARN_ON(). We get the warnings, but none of the
crashiness that are desirable in a development context. This is what
distro debug kernels should be using, as it also ensures
we don't build in the real debug code that does things that would
affect prodution systems adversely, like randomly take different
allocator paths to ensure we get code coverage of all the allocator
algorithms...

i.e. production kernels ship with neither set, the debug kernel
ships with CONFIG_XFS_WARN=y, and we do all our development with
CONFIG_XFS_DEBUG=y.

I think this case falls into the "production debug" classification;
we want a warning, but we don't want the system to be taken down

> But apart from the checkpatch thing, it's actually a pretty big change.

Yeah, that's why we added CONFIG_XFS_WARN=y to do this - it was a 20
line change to add XFS_CONFIG_WARN instead of having to audit and
modify ~1800 call sites to do something differently. And because we
know that ASSERT() is not present in all kernels, it isn't ever used
as a replacement for error handling. Perhaps that's the simplest
solution here as well

Just my 2c worth.

-Dave.
-- 
Dave Chinner
da...@fromorbit.com

[ANNOUNCE] 3.12.64-rt86

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.12.64-rt86 stable release.


This release is just an update to the new stable 3.12.64 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.12-rt
  Head SHA1: 9e9bb146e1cc72cabbcb1097bf0e0ae58e96862e


Or to build 3.12.64-rt86 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.12.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.12.64.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.64-rt86.patch.xz




Enjoy,

-- Steve

[ANNOUNCE] 3.12.64-rt86

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.12.64-rt86 stable release.


This release is just an update to the new stable 3.12.64 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.12-rt
  Head SHA1: 9e9bb146e1cc72cabbcb1097bf0e0ae58e96862e


Or to build 3.12.64-rt86 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.12.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.12.64.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.64-rt86.patch.xz




Enjoy,

-- Steve

[ANNOUNCE] 4.4.23-rt33

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 4.4.23-rt33 stable release.


This release is just an update to the new stable 4.4.23 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v4.4-rt
  Head SHA1: 914271f643a1d9b39bf9e1968a090bf6e6709424


Or to build 4.4.23-rt33 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz

  http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.23.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/4.4/patch-4.4.23-rt33.patch.xz




Enjoy,

-- Steve

[ANNOUNCE] 4.4.23-rt33

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 4.4.23-rt33 stable release.


This release is just an update to the new stable 4.4.23 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v4.4-rt
  Head SHA1: 914271f643a1d9b39bf9e1968a090bf6e6709424


Or to build 4.4.23-rt33 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz

  http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.23.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/4.4/patch-4.4.23-rt33.patch.xz




Enjoy,

-- Steve

Re: [PATCH] random: Fix early crash in credit_entropy_bits

[Theodore Ts'o]

This was discussed and Linus wanted to fix it a different way.  Please
see this thread:

http://www.gossamer-threads.com/lists/linux/kernel/2525929

Cheers,

- Ted

Re: [PATCH] random: Fix early crash in credit_entropy_bits

[Theodore Ts'o]

This was discussed and Linus wanted to fix it a different way.  Please
see this thread:

http://www.gossamer-threads.com/lists/linux/kernel/2525929

Cheers,

- Ted

Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed

[Shawn Lin]

On 2016/10/6 5:22, Julia Cartwright wrote:

On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote:

On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson  wrote:

On 23 September 2016 at 22:01, Zach Brown  wrote:

Certain board configurations can make highspeed malfunction due to
timing issues. In these cases a way is needed to force the controller
and card into standard speed even if they otherwise appear to be capable
of highspeed.

The sd-broken-highspeed property will let the sdhci driver know that
highspeed will not work.

Signed-off-by: Zach Brown 
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 8a37782..59332ea 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -52,6 +52,8 @@ Optional properties:
 - no-sdio: controller is limited to send sdio cmd during initialization
 - no-sd: controller is limited to send sd cmd during initialization
 - no-mmc: controller is limited to send mmc cmd during initialization
+- sd-broken-highspeed: Highspeed is broken, even if the controller and card
+  themselves claim they support highspeed.


Regarding a broken card, that is managed via the card quirks and not in DT.

If this is about a controller limitation, we already have the option
to describe what it supports, so we don't need an option to tell what
it *not* supports.

For example "cap-sd-highspeed" tells whether the controller supports
SD high-speed, please use that instead.


If a controller has a capability register and it lies (perhaps the
board has limitations that the SoC does not), then you may need to
disable a feature.


That's precisely the case here.  This is a board-level problem, not a
card or controller problem.  As Zach mentioned in the cover letter, the
trace length between controller and card on some of our boards is too
long to meet high-speed timings, even though both card and controller
advertise it.


IIRC, I saw the same problem while using sdhci to bring up a
industrial board for vehicle. The trace length is so long that
I have to limit the max-frequency to make it works properly when
running at hishspeed.

So could you try to limit the max-frequency in your DT to see
if it could work for you? I guess it should work as once reducing
the frequency, the timing per cycle will be large enough to meet
the spec. At least that helped me solve my problem.

For further consideration, I deployed a mechanism called "tuning for
non UHS or non-hs200/400" for my donwstream tree at that time. The basic
concept is to ask devices to send ext_csd(or send status for SD case) 
*repeatedly*. Some hosts, i.e. sdhci-of-arasan or dw_mmc-rockchip, can

manually set rx delay via some clock unit registers to capture the
working sample window and select the middle point of the longest good
phase region. The same for retune. But it is a little complicated, and
could only be applicable to the hosts who could adjust the rx delay
manually when claiming the caps of MMC_CAPS_CAN_TUNING_FOR_HS, whatever
the name is...

I don't know if it is worth to add this, and I don't know if it's
a legit way. Anyway, I just share my thought(experience) for you and
linux-mmc to think more about how to deal with the case you meet rather
than sacrificing the performence by removing highspeed or reducing
frequency..




Thanks,
   Julia
--
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




--
Best Regards
Shawn Lin

Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed

[Shawn Lin]

On 2016/10/6 5:22, Julia Cartwright wrote:

On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote:

On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson  wrote:

On 23 September 2016 at 22:01, Zach Brown  wrote:

Certain board configurations can make highspeed malfunction due to
timing issues. In these cases a way is needed to force the controller
and card into standard speed even if they otherwise appear to be capable
of highspeed.

The sd-broken-highspeed property will let the sdhci driver know that
highspeed will not work.

Signed-off-by: Zach Brown 
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 8a37782..59332ea 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -52,6 +52,8 @@ Optional properties:
 - no-sdio: controller is limited to send sdio cmd during initialization
 - no-sd: controller is limited to send sd cmd during initialization
 - no-mmc: controller is limited to send mmc cmd during initialization
+- sd-broken-highspeed: Highspeed is broken, even if the controller and card
+  themselves claim they support highspeed.


Regarding a broken card, that is managed via the card quirks and not in DT.

If this is about a controller limitation, we already have the option
to describe what it supports, so we don't need an option to tell what
it *not* supports.

For example "cap-sd-highspeed" tells whether the controller supports
SD high-speed, please use that instead.


If a controller has a capability register and it lies (perhaps the
board has limitations that the SoC does not), then you may need to
disable a feature.


That's precisely the case here.  This is a board-level problem, not a
card or controller problem.  As Zach mentioned in the cover letter, the
trace length between controller and card on some of our boards is too
long to meet high-speed timings, even though both card and controller
advertise it.


IIRC, I saw the same problem while using sdhci to bring up a
industrial board for vehicle. The trace length is so long that
I have to limit the max-frequency to make it works properly when
running at hishspeed.

So could you try to limit the max-frequency in your DT to see
if it could work for you? I guess it should work as once reducing
the frequency, the timing per cycle will be large enough to meet
the spec. At least that helped me solve my problem.

For further consideration, I deployed a mechanism called "tuning for
non UHS or non-hs200/400" for my donwstream tree at that time. The basic
concept is to ask devices to send ext_csd(or send status for SD case) 
*repeatedly*. Some hosts, i.e. sdhci-of-arasan or dw_mmc-rockchip, can

manually set rx delay via some clock unit registers to capture the
working sample window and select the middle point of the longest good
phase region. The same for retune. But it is a little complicated, and
could only be applicable to the hosts who could adjust the rx delay
manually when claiming the caps of MMC_CAPS_CAN_TUNING_FOR_HS, whatever
the name is...

I don't know if it is worth to add this, and I don't know if it's
a legit way. Anyway, I just share my thought(experience) for you and
linux-mmc to think more about how to deal with the case you meet rather
than sacrificing the performence by removing highspeed or reducing
frequency..




Thanks,
   Julia
--
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




--
Best Regards
Shawn Lin

Re: [PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode

[David Miller]

From: Mike Looijmans 
Date: Tue,  4 Oct 2016 07:52:04 +0200

> Set bit 0 in register 1C.23 to enable the EDPD feature of the
> KSZ9031 PHY. This reduces power consumption when the link is
> down.
> 
> Signed-off-by: Mike Looijmans 
> ---
> v2: Unconditionally enable EDPD mode

Applied.

Re: [PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode

[David Miller]

From: Mike Looijmans 
Date: Tue,  4 Oct 2016 07:52:04 +0200

> Set bit 0 in register 1C.23 to enable the EDPD feature of the
> KSZ9031 PHY. This reduces power consumption when the link is
> down.
> 
> Signed-off-by: Mike Looijmans 
> ---
> v2: Unconditionally enable EDPD mode

Applied.

Talent Scout

[Camilia Brunnet]

Dear Concern,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Ferdinand (Ferdinand 2017) The Movie is Currently Filming (In
Production) Please Note That There Will Be No Auditions, Traveling or
Any Special / Professional Acting Skills, Since the Production of This
Movie Will Be Done with our State of Art Computer -Generating Imagery
Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For
More Information/Understanding, Please Write us on the E-Mail Below.
CONTACT EMAIL: blueskyfilmstud...@usa.com
All Reply to:  blueskyfilmstud...@usa.com
Note: Only the Response send to this mail will be Given a Prior
Consideration.

Talent Scout
Camilia Brunnet

Talent Scout

[Camilia Brunnet]

Dear Concern,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Ferdinand (Ferdinand 2017) The Movie is Currently Filming (In
Production) Please Note That There Will Be No Auditions, Traveling or
Any Special / Professional Acting Skills, Since the Production of This
Movie Will Be Done with our State of Art Computer -Generating Imagery
Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For
More Information/Understanding, Please Write us on the E-Mail Below.
CONTACT EMAIL: blueskyfilmstud...@usa.com
All Reply to:  blueskyfilmstud...@usa.com
Note: Only the Response send to this mail will be Given a Prior
Consideration.

Talent Scout
Camilia Brunnet

[PATCH] scsi: ufshcd: fix possible unclocked register access

[Subhash Jadavani]

Vendor specific setup_clocks callback may require the clocks managed
by ufshcd driver to be ON. So if the vendor specific setup_clocks callback
is called while the required clocks are turned off, it could result into
unclocked register access.

To prevent possible unclock register access, this change makes sure that
required clocks remain enabled before calling into vendor specific
setup_clocks callback.

Signed-off-by: Subhash Jadavani 
---
 drivers/scsi/ufs/ufshcd.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 05c7456..acee5a3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5389,6 +5389,17 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
if (!head || list_empty(head))
goto out;
 
+   /*
+* vendor specific setup_clocks ops may depend on clocks managed by
+* this standard driver hence call the vendor specific setup_clocks
+* before disabling the clocks managed here.
+*/
+   if (!on) {
+   ret = ufshcd_vops_setup_clocks(hba, on);
+   if (ret)
+   return ret;
+   }
+
list_for_each_entry(clki, head, list) {
if (!IS_ERR_OR_NULL(clki->clk)) {
if (skip_ref_clk && !strcmp(clki->name, "ref_clk"))
@@ -5410,6 +5421,11 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
}
}
 
+   /*
+* vendor specific setup_clocks ops may depend on clocks managed by
+* this standard driver hence call the vendor specific setup_clocks
+* after enabling the clocks managed here.
+*/
ret = ufshcd_vops_setup_clocks(hba, on);
 out:
if (ret) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] scsi: ufshcd: fix possible unclocked register access

[Subhash Jadavani]

Vendor specific setup_clocks callback may require the clocks managed
by ufshcd driver to be ON. So if the vendor specific setup_clocks callback
is called while the required clocks are turned off, it could result into
unclocked register access.

To prevent possible unclock register access, this change makes sure that
required clocks remain enabled before calling into vendor specific
setup_clocks callback.

Signed-off-by: Subhash Jadavani 
---
 drivers/scsi/ufs/ufshcd.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 05c7456..acee5a3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5389,6 +5389,17 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
if (!head || list_empty(head))
goto out;
 
+   /*
+* vendor specific setup_clocks ops may depend on clocks managed by
+* this standard driver hence call the vendor specific setup_clocks
+* before disabling the clocks managed here.
+*/
+   if (!on) {
+   ret = ufshcd_vops_setup_clocks(hba, on);
+   if (ret)
+   return ret;
+   }
+
list_for_each_entry(clki, head, list) {
if (!IS_ERR_OR_NULL(clki->clk)) {
if (skip_ref_clk && !strcmp(clki->name, "ref_clk"))
@@ -5410,6 +5421,11 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
}
}
 
+   /*
+* vendor specific setup_clocks ops may depend on clocks managed by
+* this standard driver hence call the vendor specific setup_clocks
+* after enabling the clocks managed here.
+*/
ret = ufshcd_vops_setup_clocks(hba, on);
 out:
if (ret) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [GIT] Networking

[Stephen Rothwell]

Hi Linus,

On Wed, 5 Oct 2016 15:37:17 -0700 Linus Torvalds 
 wrote:
>
> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell  
> wrote:
> >
> > I have been carrying the following merge fix patch (for the merge of
> > the net-next tree with Linus' tree) for a while now which seems to have
> > got missed:  
> 
> Ugh. It doesn't seem to be a merge error, because that double iph
> assignment came from the original patch that introduced this function:
> commit ddc8b6027ad0 ("netfilter: introduce nft_set_pktinfo_{ipv4,
> ipv6}_validate()").

Except that commit effectively moved that function from
net/netfilter/nf_tables_netdev.c to
include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
removed the assignment in the original file (and has been in your tree
since v4.8-rc7) and that is where I originally actually got a conflict.

> So I wouldn't call it a merge error - it just looks like a bug in the
> network layer. So I'm not going to apply your patch even though it
> looks plausible to me, simply because it's outside my area of
> expertise.

no worries.
-- 
Cheers,
Stephen Rothwell

Re: [GIT] Networking

[Stephen Rothwell]

Hi Linus,

On Wed, 5 Oct 2016 15:37:17 -0700 Linus Torvalds 
 wrote:
>
> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell  
> wrote:
> >
> > I have been carrying the following merge fix patch (for the merge of
> > the net-next tree with Linus' tree) for a while now which seems to have
> > got missed:  
> 
> Ugh. It doesn't seem to be a merge error, because that double iph
> assignment came from the original patch that introduced this function:
> commit ddc8b6027ad0 ("netfilter: introduce nft_set_pktinfo_{ipv4,
> ipv6}_validate()").

Except that commit effectively moved that function from
net/netfilter/nf_tables_netdev.c to
include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011
("netfilter: nf_tables_netdev: remove redundant ip_hdr assignment")
removed the assignment in the original file (and has been in your tree
since v4.8-rc7) and that is where I originally actually got a conflict.

> So I wouldn't call it a merge error - it just looks like a bug in the
> network layer. So I'm not going to apply your patch even though it
> looks plausible to me, simply because it's outside my area of
> expertise.

no worries.
-- 
Cheers,
Stephen Rothwell

RE: [PATCH] tpm: don't destroy chip device prematurely

[Winkler, Tomas]

> On Wed, Oct 05, 2016 at 08:09:17PM +, Winkler, Tomas wrote:
> 
> > It could, but that patch was not merged yet, and I believe even if the
> > issue is exposed only with runtime_pm currently, we have a bug in
> > design even w/o runtime pm.
> 
> Please don't make changes without any justification :(

> 
> > > These are all fine, obviously. Todays kernel retains those values
> > > across device_del and we set those values in tpmm_chip_alloc/etc. So
> > > correct values are present as long as the chip memory exists. tpm
> > > continues to hold a kref on the chip so the memory will be around.
> >
> > I'm not saying they are not, but calling deep into the tpm stack and
> > even to the parent device with unutilized device is not sane.
> 
> You keep asserting that, but it just isn't true at all.

Okay, let's rephrase, that calling device_del before tpm_transmit is not sane 
when using runtime_pm.

> For a long time the tpm subsystem didn't even have a 'struct device'. That is
> something Jarkko and I added.


> The *ONLY* thing it does is act as the anchor for user space - eg it holds the
> sysfs, contains the 'dev' file for the cdev, etc, etc. This was an important 
> clean
> up.
> 
> Internally to the tpm core, and the drivers, the chip->dev does
> *NOTHING* except hold the few variables you pointed out. That is it.
> 
> We could go back to the old code, without the 'dev' and things could still 
> work
> correctly.

You can write the code in one big loop in assembly and it would work as well, 
this is not the point.

> This is why your assertion the struct device needs to be registered makes no
> sense.

But you did change the code to get more benefits but this also comes with more 
dependencies and new rules.
I also can go the simple way and go_idle, cmd_ready callbacks and nothing will 
breaks, but we wanted all those goodies that runtime_pm has (autosuspend and 
sysfs), but the feature  has longer roots. 


> If the runtime_pm patches change this, then we have a very serious problem.
> Removing this assumption is much harder than a one line patch moving
> device_del.

I'm just saying that the  runtime patches only exposed issue in the design.
 
> I actually have no idea how you'd do it, since we call all sorts of tpm ops
> between device_init and device_add - again device_del is the least of the
> problems if runtime pm insists the chip->dev be registered when running
> transmit_cmd.

This has to be revisited as well. 

> 
> So, I again, strongly advise you to give up on this idea, it is too hard for 
> TPM,
> and does not seem technically needed at this time. Even it it does seem to
> make some kind of intuitive sense.

I'm the last one who want to do extra jobs, we need to make our hw working 
asap, but we need to do it right.

> > > Is there some other PM path where dev->parent becomes invovled?
> >
> > Of course, the power management utilize the device hierarch, it
> > assumes there is power dependencies between parents and child devices,
> > such as bus controllers and the devices on that bus.
> 
> Sure, but that relationship only maters if something does a PM call on the
> chip->dev, and AFAIK, nothing does that.
> 
> Do you know differently?

You've pasted that code in in the previous mail, parent is involved on device 
remove.

> 
> You pointed at something that isn't even run and said it is the source of the
> problem.. You really need to set up here and explain exactly what is
> happening.

Sorry, lost you here.
 
> > > Are you just guessing this solves a problem, or were you able to
> > > reproduce Jarkko's report?
> >
> > No, guesses are not my style :), this solves the issue, as you see
> > this was also validated by Jarrko on his setup.
> 
> In the thread you pointed to Jarkko said he could not reproduce the original
> issue. Jarkko can you clarify??

No, he rolled back the runtime_pm patch and the issue disappeared and that's 
how we found the root cause. 
 
> > > Even if that pm_runtime_put is happening, why doesn't the
> > >
> > > +pm_runtime_get_sync(chip->dev.parent);
> > >
> > > The runtime_pm patch adds to tpm_transmit take care of bringing the
> > > device back?
> >
> > Unfortunately not because, because it gets out of sync and what is
> > actually happening is that idle callback is called and device is put
> > to idle between send and receive.
> 
> What? As far as I understand this PM stuff, I would call that a very serious 
> bug.

Maybe, but then you have to find what a bug,  currently it looks like wrong 
usage of the device.
> 

> If a PM transition during transmit_cmd causes the TPM to abort/fail command
> execution then it *MUST* be prevented. Period.

Or, we can call device_del after tpm2_shutdown. 
 
> pm_runtime_get_sync appears to be the correct thing to get the guarentee, so
> I'm very confused by your statement.
> 
> > Now we can find a trick to fix this, but this would be rather w/o
> > while we know what the real issue is.
> 
> don't understand this.. Are you 

RE: [PATCH] tpm: don't destroy chip device prematurely

[Winkler, Tomas]

> On Wed, Oct 05, 2016 at 08:09:17PM +, Winkler, Tomas wrote:
> 
> > It could, but that patch was not merged yet, and I believe even if the
> > issue is exposed only with runtime_pm currently, we have a bug in
> > design even w/o runtime pm.
> 
> Please don't make changes without any justification :(

> 
> > > These are all fine, obviously. Todays kernel retains those values
> > > across device_del and we set those values in tpmm_chip_alloc/etc. So
> > > correct values are present as long as the chip memory exists. tpm
> > > continues to hold a kref on the chip so the memory will be around.
> >
> > I'm not saying they are not, but calling deep into the tpm stack and
> > even to the parent device with unutilized device is not sane.
> 
> You keep asserting that, but it just isn't true at all.

Okay, let's rephrase, that calling device_del before tpm_transmit is not sane 
when using runtime_pm.

> For a long time the tpm subsystem didn't even have a 'struct device'. That is
> something Jarkko and I added.


> The *ONLY* thing it does is act as the anchor for user space - eg it holds the
> sysfs, contains the 'dev' file for the cdev, etc, etc. This was an important 
> clean
> up.
> 
> Internally to the tpm core, and the drivers, the chip->dev does
> *NOTHING* except hold the few variables you pointed out. That is it.
> 
> We could go back to the old code, without the 'dev' and things could still 
> work
> correctly.

You can write the code in one big loop in assembly and it would work as well, 
this is not the point.

> This is why your assertion the struct device needs to be registered makes no
> sense.

But you did change the code to get more benefits but this also comes with more 
dependencies and new rules.
I also can go the simple way and go_idle, cmd_ready callbacks and nothing will 
breaks, but we wanted all those goodies that runtime_pm has (autosuspend and 
sysfs), but the feature  has longer roots. 


> If the runtime_pm patches change this, then we have a very serious problem.
> Removing this assumption is much harder than a one line patch moving
> device_del.

I'm just saying that the  runtime patches only exposed issue in the design.
 
> I actually have no idea how you'd do it, since we call all sorts of tpm ops
> between device_init and device_add - again device_del is the least of the
> problems if runtime pm insists the chip->dev be registered when running
> transmit_cmd.

This has to be revisited as well. 

> 
> So, I again, strongly advise you to give up on this idea, it is too hard for 
> TPM,
> and does not seem technically needed at this time. Even it it does seem to
> make some kind of intuitive sense.

I'm the last one who want to do extra jobs, we need to make our hw working 
asap, but we need to do it right.

> > > Is there some other PM path where dev->parent becomes invovled?
> >
> > Of course, the power management utilize the device hierarch, it
> > assumes there is power dependencies between parents and child devices,
> > such as bus controllers and the devices on that bus.
> 
> Sure, but that relationship only maters if something does a PM call on the
> chip->dev, and AFAIK, nothing does that.
> 
> Do you know differently?

You've pasted that code in in the previous mail, parent is involved on device 
remove.

> 
> You pointed at something that isn't even run and said it is the source of the
> problem.. You really need to set up here and explain exactly what is
> happening.

Sorry, lost you here.
 
> > > Are you just guessing this solves a problem, or were you able to
> > > reproduce Jarkko's report?
> >
> > No, guesses are not my style :), this solves the issue, as you see
> > this was also validated by Jarrko on his setup.
> 
> In the thread you pointed to Jarkko said he could not reproduce the original
> issue. Jarkko can you clarify??

No, he rolled back the runtime_pm patch and the issue disappeared and that's 
how we found the root cause. 
 
> > > Even if that pm_runtime_put is happening, why doesn't the
> > >
> > > +pm_runtime_get_sync(chip->dev.parent);
> > >
> > > The runtime_pm patch adds to tpm_transmit take care of bringing the
> > > device back?
> >
> > Unfortunately not because, because it gets out of sync and what is
> > actually happening is that idle callback is called and device is put
> > to idle between send and receive.
> 
> What? As far as I understand this PM stuff, I would call that a very serious 
> bug.

Maybe, but then you have to find what a bug,  currently it looks like wrong 
usage of the device.
> 

> If a PM transition during transmit_cmd causes the TPM to abort/fail command
> execution then it *MUST* be prevented. Period.

Or, we can call device_del after tpm2_shutdown. 
 
> pm_runtime_get_sync appears to be the correct thing to get the guarentee, so
> I'm very confused by your statement.
> 
> > Now we can find a trick to fix this, but this would be rather w/o
> > while we know what the real issue is.
> 
> don't understand this.. Are you 

Re: callchain map refcounting fixes was Re: [PATCH perf/core] perf script: fix a use after free crash.

[Masami Hiramatsu]

On Wed, 5 Oct 2016 08:45:24 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Sat, Oct 01, 2016 at 08:13:36PM -0700, Krister Johansen escreveu:
> > If dso__load_kcore frees all of the existing maps, but one has already
> > been attached to a callchain cursor node, then we can get a SIGSEGV in
> > any function that happens to try to use this cursor with the invalid
> > map.  Use the existing map refcount mechanism to forestall cleanup of a
> > map until the cursor iterates past the node.
> 
> Seems ok, thanks for working on this! Can you provide a test case that
> causes the SEGV so that I can, in addition to reviewing your changes and
> auditing the code to check if all cases ara plugged, to reproduce the
> problem?
> 
> Frédéric, Namhyung, Ack?
> 
> Masami, is this a case that your refcount validator can catch?

Yes, I think so, it is able to be founded by refcnt debugger.
In case of getting SIGSEGV, we can enhance it to handle the
signal and dump traced data.

Thanks,

> 
> - Arnaldo
>  
> > Signed-off-by: Krister Johansen 
> > ---
> >  tools/perf/util/callchain.c | 12 ++--
> >  tools/perf/util/callchain.h | 20 
> >  tools/perf/util/hist.c  |  4 
> >  3 files changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> > index 07fd30b..15c89b2 100644
> > --- a/tools/perf/util/callchain.c
> > +++ b/tools/perf/util/callchain.c
> > @@ -439,7 +439,7 @@ fill_node(struct callchain_node *node, struct 
> > callchain_cursor *cursor)
> > }
> > call->ip = cursor_node->ip;
> > call->ms.sym = cursor_node->sym;
> > -   call->ms.map = cursor_node->map;
> > +   call->ms.map = map__get(cursor_node->map);
> > list_add_tail(>list, >val);
> >  
> > callchain_cursor_advance(cursor);
> > @@ -464,6 +464,7 @@ add_child(struct callchain_node *parent,
> >  
> > list_for_each_entry_safe(call, tmp, >val, list) {
> > list_del(>list);
> > +   map__zput(call->ms.map);
> > free(call);
> > }
> > free(new);
> > @@ -732,6 +733,7 @@ merge_chain_branch(struct callchain_cursor *cursor,
> > callchain_cursor_append(cursor, list->ip,
> > list->ms.map, list->ms.sym);
> > list_del(>list);
> > +   map__zput(list->ms.map);
> > free(list);
> > }
> >  
> > @@ -780,7 +782,8 @@ int callchain_cursor_append(struct callchain_cursor 
> > *cursor,
> > }
> >  
> > node->ip = ip;
> > -   node->map = map;
> > +   map__zput(node->map);
> > +   node->map = map__get(map);
> > node->sym = sym;
> >  
> > cursor->nr++;
> > @@ -830,6 +833,8 @@ int fill_callchain_info(struct addr_location *al, 
> > struct callchain_cursor_node *
> > goto out;
> > }
> >  
> > +   map__get(al->map);
> > +
> > if (al->map->groups == >machine->kmaps) {
> > if (machine__is_host(al->machine)) {
> > al->cpumode = PERF_RECORD_MISC_KERNEL;
> > @@ -947,11 +952,13 @@ static void free_callchain_node(struct callchain_node 
> > *node)
> >  
> > list_for_each_entry_safe(list, tmp, >parent_val, list) {
> > list_del(>list);
> > +   map__zput(list->ms.map);
> > free(list);
> > }
> >  
> > list_for_each_entry_safe(list, tmp, >val, list) {
> > list_del(>list);
> > +   map__zput(list->ms.map);
> > free(list);
> > }
> >  
> > @@ -1035,6 +1042,7 @@ int callchain_node__make_parent_list(struct 
> > callchain_node *node)
> >  out:
> > list_for_each_entry_safe(chain, new, , list) {
> > list_del(>list);
> > +   map__zput(chain->ms.map);
> > free(chain);
> > }
> > return -ENOMEM;
> > diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
> > index 13e7554..0d944ef 100644
> > --- a/tools/perf/util/callchain.h
> > +++ b/tools/perf/util/callchain.h
> > @@ -5,6 +5,7 @@
> >  #include 
> >  #include 
> >  #include "event.h"
> > +#include "map.h"
> >  #include "symbol.h"
> >  
> >  #define HELP_PAD "\t\t\t\t"
> > @@ -178,8 +179,13 @@ int callchain_merge(struct callchain_cursor *cursor,
> >   */
> >  static inline void callchain_cursor_reset(struct callchain_cursor *cursor)
> >  {
> > +   struct callchain_cursor_node *node;
> > +
> > cursor->nr = 0;
> > cursor->last = >first;
> > +
> > +   for (node = cursor->first; node != NULL; node = node->next)
> > +   map__zput(node->map);
> >  }
> >  
> >  int callchain_cursor_append(struct callchain_cursor *cursor, u64 ip,
> > @@ -238,12 +244,26 @@ int perf_callchain_config(const char *var, const char 
> > *value);
> >  static inline void callchain_cursor_snapshot(struct callchain_cursor *dest,
> >  struct callchain_cursor *src)
> > 

Re: callchain map refcounting fixes was Re: [PATCH perf/core] perf script: fix a use after free crash.

[Masami Hiramatsu]

On Wed, 5 Oct 2016 08:45:24 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Sat, Oct 01, 2016 at 08:13:36PM -0700, Krister Johansen escreveu:
> > If dso__load_kcore frees all of the existing maps, but one has already
> > been attached to a callchain cursor node, then we can get a SIGSEGV in
> > any function that happens to try to use this cursor with the invalid
> > map.  Use the existing map refcount mechanism to forestall cleanup of a
> > map until the cursor iterates past the node.
> 
> Seems ok, thanks for working on this! Can you provide a test case that
> causes the SEGV so that I can, in addition to reviewing your changes and
> auditing the code to check if all cases ara plugged, to reproduce the
> problem?
> 
> Frédéric, Namhyung, Ack?
> 
> Masami, is this a case that your refcount validator can catch?

Yes, I think so, it is able to be founded by refcnt debugger.
In case of getting SIGSEGV, we can enhance it to handle the
signal and dump traced data.

Thanks,

> 
> - Arnaldo
>  
> > Signed-off-by: Krister Johansen 
> > ---
> >  tools/perf/util/callchain.c | 12 ++--
> >  tools/perf/util/callchain.h | 20 
> >  tools/perf/util/hist.c  |  4 
> >  3 files changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> > index 07fd30b..15c89b2 100644
> > --- a/tools/perf/util/callchain.c
> > +++ b/tools/perf/util/callchain.c
> > @@ -439,7 +439,7 @@ fill_node(struct callchain_node *node, struct 
> > callchain_cursor *cursor)
> > }
> > call->ip = cursor_node->ip;
> > call->ms.sym = cursor_node->sym;
> > -   call->ms.map = cursor_node->map;
> > +   call->ms.map = map__get(cursor_node->map);
> > list_add_tail(>list, >val);
> >  
> > callchain_cursor_advance(cursor);
> > @@ -464,6 +464,7 @@ add_child(struct callchain_node *parent,
> >  
> > list_for_each_entry_safe(call, tmp, >val, list) {
> > list_del(>list);
> > +   map__zput(call->ms.map);
> > free(call);
> > }
> > free(new);
> > @@ -732,6 +733,7 @@ merge_chain_branch(struct callchain_cursor *cursor,
> > callchain_cursor_append(cursor, list->ip,
> > list->ms.map, list->ms.sym);
> > list_del(>list);
> > +   map__zput(list->ms.map);
> > free(list);
> > }
> >  
> > @@ -780,7 +782,8 @@ int callchain_cursor_append(struct callchain_cursor 
> > *cursor,
> > }
> >  
> > node->ip = ip;
> > -   node->map = map;
> > +   map__zput(node->map);
> > +   node->map = map__get(map);
> > node->sym = sym;
> >  
> > cursor->nr++;
> > @@ -830,6 +833,8 @@ int fill_callchain_info(struct addr_location *al, 
> > struct callchain_cursor_node *
> > goto out;
> > }
> >  
> > +   map__get(al->map);
> > +
> > if (al->map->groups == >machine->kmaps) {
> > if (machine__is_host(al->machine)) {
> > al->cpumode = PERF_RECORD_MISC_KERNEL;
> > @@ -947,11 +952,13 @@ static void free_callchain_node(struct callchain_node 
> > *node)
> >  
> > list_for_each_entry_safe(list, tmp, >parent_val, list) {
> > list_del(>list);
> > +   map__zput(list->ms.map);
> > free(list);
> > }
> >  
> > list_for_each_entry_safe(list, tmp, >val, list) {
> > list_del(>list);
> > +   map__zput(list->ms.map);
> > free(list);
> > }
> >  
> > @@ -1035,6 +1042,7 @@ int callchain_node__make_parent_list(struct 
> > callchain_node *node)
> >  out:
> > list_for_each_entry_safe(chain, new, , list) {
> > list_del(>list);
> > +   map__zput(chain->ms.map);
> > free(chain);
> > }
> > return -ENOMEM;
> > diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
> > index 13e7554..0d944ef 100644
> > --- a/tools/perf/util/callchain.h
> > +++ b/tools/perf/util/callchain.h
> > @@ -5,6 +5,7 @@
> >  #include 
> >  #include 
> >  #include "event.h"
> > +#include "map.h"
> >  #include "symbol.h"
> >  
> >  #define HELP_PAD "\t\t\t\t"
> > @@ -178,8 +179,13 @@ int callchain_merge(struct callchain_cursor *cursor,
> >   */
> >  static inline void callchain_cursor_reset(struct callchain_cursor *cursor)
> >  {
> > +   struct callchain_cursor_node *node;
> > +
> > cursor->nr = 0;
> > cursor->last = >first;
> > +
> > +   for (node = cursor->first; node != NULL; node = node->next)
> > +   map__zput(node->map);
> >  }
> >  
> >  int callchain_cursor_append(struct callchain_cursor *cursor, u64 ip,
> > @@ -238,12 +244,26 @@ int perf_callchain_config(const char *var, const char 
> > *value);
> >  static inline void callchain_cursor_snapshot(struct callchain_cursor *dest,
> >  struct callchain_cursor *src)
> >  {
> > +   struct callchain_cursor_node 

Re: [GIT] Networking

[David Miller]

From: Pablo Neira Ayuso 
Date: Thu, 6 Oct 2016 02:09:45 +0200

> On Wed, Oct 05, 2016 at 03:37:17PM -0700, Linus Torvalds wrote:
>> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell  
>> wrote:
>> >
>> > I have been carrying the following merge fix patch (for the merge of
>> > the net-next tree with Linus' tree) for a while now which seems to have
>> > got missed:
>> 
>> Ugh. It doesn't seem to be a merge error, because that double iph
>> assignment came from the original patch that introduced this function:
>> commit ddc8b6027ad0 ("netfilter: introduce nft_set_pktinfo_{ipv4,
>> ipv6}_validate()").
>> 
>> So I wouldn't call it a merge error - it just looks like a bug in the
>> network layer. So I'm not going to apply your patch even though it
>> looks plausible to me, simply because it's outside my area of
>> expertise.
>> 
>> David? Pablo?
> 
> This looks good, please take it so we speed up things.
> 
> Acked-by: Pablo Neira Ayuso 

Applied.

Re: [GIT] Networking

[David Miller]

From: Pablo Neira Ayuso 
Date: Thu, 6 Oct 2016 02:09:45 +0200

> On Wed, Oct 05, 2016 at 03:37:17PM -0700, Linus Torvalds wrote:
>> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell  
>> wrote:
>> >
>> > I have been carrying the following merge fix patch (for the merge of
>> > the net-next tree with Linus' tree) for a while now which seems to have
>> > got missed:
>> 
>> Ugh. It doesn't seem to be a merge error, because that double iph
>> assignment came from the original patch that introduced this function:
>> commit ddc8b6027ad0 ("netfilter: introduce nft_set_pktinfo_{ipv4,
>> ipv6}_validate()").
>> 
>> So I wouldn't call it a merge error - it just looks like a bug in the
>> network layer. So I'm not going to apply your patch even though it
>> looks plausible to me, simply because it's outside my area of
>> expertise.
>> 
>> David? Pablo?
> 
> This looks good, please take it so we speed up things.
> 
> Acked-by: Pablo Neira Ayuso 

Applied.

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

[Benjamin Herrenschmidt]

On Tue, 2016-10-04 at 13:02 +0100, John Garry wrote:
> Right, so I think Zhichang can make the necessary generic changes to 
> 8250 OF driver to support IO port as well as MMIO-based.
> 
> However an LPC-based earlycon driver is still required.
> 
> A note on hip07-based D05 (for those unaware): this does not use 
> LPC-based uart. It uses PL011. The hardware guys have managed some 
> trickery where they loopback the serial line around the BMC/CPLD. But we 
> still need it for hip06 D03 and any other boards which want to use LPC 
> bus for uart.
> 
> A question on SBSA: does it propose how to provide serial via BMC for SOL?

Probably another reason to keep 8250 as a legal option ... The (very
popular) Aspeed BMCs tend to do this via a 8250-looking virtual UART on
LPC.

Cheers,
Ben,

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

[Benjamin Herrenschmidt]

On Tue, 2016-10-04 at 13:02 +0100, John Garry wrote:
> Right, so I think Zhichang can make the necessary generic changes to 
> 8250 OF driver to support IO port as well as MMIO-based.
> 
> However an LPC-based earlycon driver is still required.
> 
> A note on hip07-based D05 (for those unaware): this does not use 
> LPC-based uart. It uses PL011. The hardware guys have managed some 
> trickery where they loopback the serial line around the BMC/CPLD. But we 
> still need it for hip06 D03 and any other boards which want to use LPC 
> bus for uart.
> 
> A question on SBSA: does it propose how to provide serial via BMC for SOL?

Probably another reason to keep 8250 as a legal option ... The (very
popular) Aspeed BMCs tend to do this via a 8250-looking virtual UART on
LPC.

Cheers,
Ben,