[PATCH v4 02/12] [media] cxd2880-spi: Add support for CXD2880 SPI interface

[Yasunari.Takiguchi]

From: Yasunari Takiguchi 

This is the SPI adapter part of the driver for the
Sony CXD2880 DVB-T2/T tuner + demodulator.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---

[Change list]
Changes in V4
   drivers/media/spi/cxd2880-spi.c
  -removed Camel case
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}

Changes in V3
   drivers/media/spi/cxd2880-spi.c
  -adjusted of indent spaces
  -removed unnecessary cast
  -changed debugging code
  -changed timeout method
  -modified coding style of if()
  -changed hexadecimal code to lower case. 

Changes in V2
   drivers/media/spi/cxd2880-spi.c
  -Modified PID filter setting.

 drivers/media/spi/cxd2880-spi.c | 695 
 1 file changed, 695 insertions(+)
 create mode 100644 drivers/media/spi/cxd2880-spi.c

diff --git a/drivers/media/spi/cxd2880-spi.c b/drivers/media/spi/cxd2880-spi.c
new file mode 100644
index ..387cb32f90b8
--- /dev/null
+++ b/drivers/media/spi/cxd2880-spi.c
@@ -0,0 +1,695 @@
+/*
+ * cxd2880-spi.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * SPI adapter
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": %s: " fmt, __func__
+
+#include 
+#include 
+
+#include "dvb_demux.h"
+#include "dmxdev.h"
+#include "dvb_frontend.h"
+#include "cxd2880.h"
+
+#define CXD2880_MAX_FILTER_SIZE 32
+#define BURST_WRITE_MAX 128
+#define MAX_TRANS_PACKET 300
+
+struct cxd2880_ts_buf_info {
+   u8 read_ready;
+   u8 almost_full;
+   u8 almost_empty;
+   u8 overflow;
+   u8 underflow;
+   u16 packet_num;
+};
+
+struct cxd2880_pid_config {
+   u8 is_enable;
+   u16 pid;
+};
+
+struct cxd2880_pid_filter_config {
+   u8 is_negative;
+   struct cxd2880_pid_config pid_config[CXD2880_MAX_FILTER_SIZE];
+};
+
+struct cxd2880_dvb_spi {
+   struct dvb_frontend dvb_fe;
+   struct dvb_adapter adapter;
+   struct dvb_demux demux;
+   struct dmxdev dmxdev;
+   struct dmx_frontend dmx_fe;
+   struct task_struct *cxd2880_ts_read_thread;
+   struct spi_device *spi;
+   struct mutex spi_mutex; /* For SPI access exclusive control */
+   int feed_count;
+   int all_pid_feed_count;
+   u8 *ts_buf;
+   struct cxd2880_pid_filter_config filter_config;
+};
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+static int cxd2880_write_spi(struct spi_device *spi, u8 *data, u32 size)
+{
+   struct spi_message msg;
+   struct spi_transfer tx;
+   int ret;
+
+   if ((!spi) || (!data)) {
+   pr_err("invalid arg\n");
+   return -EINVAL;
+   }
+
+   memset(, 0, sizeof(tx));
+   tx.tx_buf = data;
+   tx.len = size;
+
+   spi_message_init();
+   spi_message_add_tail(, );
+   ret = spi_sync(spi, );
+
+   return ret;
+}
+
+static int cxd2880_write_reg(struct spi_device *spi,
+u8 sub_address, const u8 *data, u32 size)
+{
+   u8 send_data[BURST_WRITE_MAX + 4];
+   const u8 *write_data_top = NULL;
+   int ret = 0;
+
+   if ((!spi) || (!data)) {
+   pr_err("invalid arg\n");
+   return -EINVAL;
+   }
+   if (size > BURST_WRITE_MAX) {
+   pr_err("data size > WRITE_MAX\n");
+   return -EINVAL;
+   }
+
+   if (sub_address + size > 0x100) {
+   pr_err("out of range\n");
+   return -EINVAL;
+   }
+
+   

[PATCH v4 02/12] [media] cxd2880-spi: Add support for CXD2880 SPI interface

[Yasunari.Takiguchi]

From: Yasunari Takiguchi 

This is the SPI adapter part of the driver for the
Sony CXD2880 DVB-T2/T tuner + demodulator.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
---

[Change list]
Changes in V4
   drivers/media/spi/cxd2880-spi.c
  -removed Camel case
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}

Changes in V3
   drivers/media/spi/cxd2880-spi.c
  -adjusted of indent spaces
  -removed unnecessary cast
  -changed debugging code
  -changed timeout method
  -modified coding style of if()
  -changed hexadecimal code to lower case. 

Changes in V2
   drivers/media/spi/cxd2880-spi.c
  -Modified PID filter setting.

 drivers/media/spi/cxd2880-spi.c | 695 
 1 file changed, 695 insertions(+)
 create mode 100644 drivers/media/spi/cxd2880-spi.c

diff --git a/drivers/media/spi/cxd2880-spi.c b/drivers/media/spi/cxd2880-spi.c
new file mode 100644
index ..387cb32f90b8
--- /dev/null
+++ b/drivers/media/spi/cxd2880-spi.c
@@ -0,0 +1,695 @@
+/*
+ * cxd2880-spi.c
+ * Sony CXD2880 DVB-T2/T tuner + demodulator driver
+ * SPI adapter
+ *
+ * Copyright (C) 2016, 2017 Sony Semiconductor Solutions Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; version 2 of the License.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": %s: " fmt, __func__
+
+#include 
+#include 
+
+#include "dvb_demux.h"
+#include "dmxdev.h"
+#include "dvb_frontend.h"
+#include "cxd2880.h"
+
+#define CXD2880_MAX_FILTER_SIZE 32
+#define BURST_WRITE_MAX 128
+#define MAX_TRANS_PACKET 300
+
+struct cxd2880_ts_buf_info {
+   u8 read_ready;
+   u8 almost_full;
+   u8 almost_empty;
+   u8 overflow;
+   u8 underflow;
+   u16 packet_num;
+};
+
+struct cxd2880_pid_config {
+   u8 is_enable;
+   u16 pid;
+};
+
+struct cxd2880_pid_filter_config {
+   u8 is_negative;
+   struct cxd2880_pid_config pid_config[CXD2880_MAX_FILTER_SIZE];
+};
+
+struct cxd2880_dvb_spi {
+   struct dvb_frontend dvb_fe;
+   struct dvb_adapter adapter;
+   struct dvb_demux demux;
+   struct dmxdev dmxdev;
+   struct dmx_frontend dmx_fe;
+   struct task_struct *cxd2880_ts_read_thread;
+   struct spi_device *spi;
+   struct mutex spi_mutex; /* For SPI access exclusive control */
+   int feed_count;
+   int all_pid_feed_count;
+   u8 *ts_buf;
+   struct cxd2880_pid_filter_config filter_config;
+};
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+static int cxd2880_write_spi(struct spi_device *spi, u8 *data, u32 size)
+{
+   struct spi_message msg;
+   struct spi_transfer tx;
+   int ret;
+
+   if ((!spi) || (!data)) {
+   pr_err("invalid arg\n");
+   return -EINVAL;
+   }
+
+   memset(, 0, sizeof(tx));
+   tx.tx_buf = data;
+   tx.len = size;
+
+   spi_message_init();
+   spi_message_add_tail(, );
+   ret = spi_sync(spi, );
+
+   return ret;
+}
+
+static int cxd2880_write_reg(struct spi_device *spi,
+u8 sub_address, const u8 *data, u32 size)
+{
+   u8 send_data[BURST_WRITE_MAX + 4];
+   const u8 *write_data_top = NULL;
+   int ret = 0;
+
+   if ((!spi) || (!data)) {
+   pr_err("invalid arg\n");
+   return -EINVAL;
+   }
+   if (size > BURST_WRITE_MAX) {
+   pr_err("data size > WRITE_MAX\n");
+   return -EINVAL;
+   }
+
+   if (sub_address + size > 0x100) {
+   pr_err("out of range\n");
+   return -EINVAL;
+   }
+
+   send_data[0] = 0x0e;
+   write_data_top = data;
+
+   while (size > 0) {
+   send_data[1] = sub_address;
+   if (size > 255)
+   send_data[2] = 255;

[PATCH v4 01/12] [dt-bindings] [media] Add document file for CXD2880 SPI I/F

[Yasunari.Takiguchi]

From: Yasunari Takiguchi 

This is the document file for Sony CXD2880 DVB-T2/T tuner + demodulator.
It contains the description of the SPI adapter binding.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
Acked-by: Rob Herring 
---

No change since version 1.

 .../devicetree/bindings/media/spi/sony-cxd2880.txt | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt

diff --git a/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt 
b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
new file mode 100644
index ..fc5aa263abe5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
@@ -0,0 +1,14 @@
+Sony CXD2880 DVB-T2/T tuner + demodulator driver SPI adapter
+
+Required properties:
+- compatible: Should be "sony,cxd2880".
+- reg: SPI chip select number for the device.
+- spi-max-frequency: Maximum bus speed, should be set to <5500> (55MHz).
+
+Example:
+
+cxd2880@0 {
+   compatible = "sony,cxd2880";
+   reg = <0>; /* CE0 */
+   spi-max-frequency = <5500>; /* 55MHz */
+};
-- 
2.13.0

[PATCH v4 01/12] [dt-bindings] [media] Add document file for CXD2880 SPI I/F

[Yasunari.Takiguchi]

From: Yasunari Takiguchi 

This is the document file for Sony CXD2880 DVB-T2/T tuner + demodulator.
It contains the description of the SPI adapter binding.

Signed-off-by: Yasunari Takiguchi 
Signed-off-by: Masayuki Yamamoto 
Signed-off-by: Hideki Nozawa 
Signed-off-by: Kota Yonezawa 
Signed-off-by: Toshihiko Matsumoto 
Signed-off-by: Satoshi Watanabe 
Acked-by: Rob Herring 
---

No change since version 1.

 .../devicetree/bindings/media/spi/sony-cxd2880.txt | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt

diff --git a/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt 
b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
new file mode 100644
index ..fc5aa263abe5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt
@@ -0,0 +1,14 @@
+Sony CXD2880 DVB-T2/T tuner + demodulator driver SPI adapter
+
+Required properties:
+- compatible: Should be "sony,cxd2880".
+- reg: SPI chip select number for the device.
+- spi-max-frequency: Maximum bus speed, should be set to <5500> (55MHz).
+
+Example:
+
+cxd2880@0 {
+   compatible = "sony,cxd2880";
+   reg = <0>; /* CE0 */
+   spi-max-frequency = <5500>; /* 55MHz */
+};
-- 
2.13.0

Re: [Outreachy kernel] [PATCH] drm: Replace kzalloc with kcalloc

[Julia Lawall]

On Fri, 13 Oct 2017, Harsha Sharma wrote:

> Prefer kcalloc over kzalloc to allocate an array.
> This patch fixes checkcpatch issue.
>
> Signed-off-by: Harsha Sharma 
> ---
>  drivers/gpu/drm/drm_crtc_helper.c  | 4 ++--
>  drivers/gpu/drm/drm_fb_helper.c| 2 +-
>  drivers/gpu/drm/drm_plane_helper.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index eab36a460638..ceb131637e2f 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -562,12 +562,12 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
>* Allocate space for the backup of all (non-pointer) encoder and
>* connector data.
>*/
> - save_encoder_crtcs = kzalloc(dev->mode_config.num_encoder *
> + save_encoder_crtcs = kcalloc(dev->mode_config.num_encoder *
>   sizeof(struct drm_crtc *), GFP_KERNEL);

Doesn't kcalloc take 3 arguments?  You need to compile the code and check
that you have obtained a .o file for the file you modified.

julia

>   if (!save_encoder_crtcs)
>   return -ENOMEM;
>
> - save_connector_encoders = kzalloc(dev->mode_config.num_connector *
> + save_connector_encoders = kcalloc(dev->mode_config.num_connector *
>   sizeof(struct drm_encoder *), GFP_KERNEL);
>   if (!save_connector_encoders) {
>   kfree(save_encoder_crtcs);
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 1b8f013ffa65..68d197df89fd 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2266,7 +2266,7 @@ static int drm_pick_crtcs(struct drm_fb_helper 
> *fb_helper,
>   if (modes[n] == NULL)
>   return best_score;
>
> - crtcs = kzalloc(fb_helper->connector_count *
> + crtcs = kcalloc(fb_helper->connector_count *
>   sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
>   if (!crtcs)
>   return best_score;
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 06aee1741e96..74054653530e 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -354,7 +354,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   /* Find current connectors for CRTC */
>   num_connectors = get_connectors_for_crtc(crtc, NULL, 0);
>   BUG_ON(num_connectors == 0);
> - connector_list = kzalloc(num_connectors * sizeof(*connector_list),
> + connector_list = kcalloc(num_connectors * sizeof(*connector_list),
>GFP_KERNEL);
>   if (!connector_list)
>   return -ENOMEM;
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20171012221758.512-1-harshasharmaiitr%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

Re: [Outreachy kernel] [PATCH] drm: Replace kzalloc with kcalloc

[Julia Lawall]

On Fri, 13 Oct 2017, Harsha Sharma wrote:

> Prefer kcalloc over kzalloc to allocate an array.
> This patch fixes checkcpatch issue.
>
> Signed-off-by: Harsha Sharma 
> ---
>  drivers/gpu/drm/drm_crtc_helper.c  | 4 ++--
>  drivers/gpu/drm/drm_fb_helper.c| 2 +-
>  drivers/gpu/drm/drm_plane_helper.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index eab36a460638..ceb131637e2f 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -562,12 +562,12 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
>* Allocate space for the backup of all (non-pointer) encoder and
>* connector data.
>*/
> - save_encoder_crtcs = kzalloc(dev->mode_config.num_encoder *
> + save_encoder_crtcs = kcalloc(dev->mode_config.num_encoder *
>   sizeof(struct drm_crtc *), GFP_KERNEL);

Doesn't kcalloc take 3 arguments?  You need to compile the code and check
that you have obtained a .o file for the file you modified.

julia

>   if (!save_encoder_crtcs)
>   return -ENOMEM;
>
> - save_connector_encoders = kzalloc(dev->mode_config.num_connector *
> + save_connector_encoders = kcalloc(dev->mode_config.num_connector *
>   sizeof(struct drm_encoder *), GFP_KERNEL);
>   if (!save_connector_encoders) {
>   kfree(save_encoder_crtcs);
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 1b8f013ffa65..68d197df89fd 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2266,7 +2266,7 @@ static int drm_pick_crtcs(struct drm_fb_helper 
> *fb_helper,
>   if (modes[n] == NULL)
>   return best_score;
>
> - crtcs = kzalloc(fb_helper->connector_count *
> + crtcs = kcalloc(fb_helper->connector_count *
>   sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
>   if (!crtcs)
>   return best_score;
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 06aee1741e96..74054653530e 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -354,7 +354,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>   /* Find current connectors for CRTC */
>   num_connectors = get_connectors_for_crtc(crtc, NULL, 0);
>   BUG_ON(num_connectors == 0);
> - connector_list = kzalloc(num_connectors * sizeof(*connector_list),
> + connector_list = kcalloc(num_connectors * sizeof(*connector_list),
>GFP_KERNEL);
>   if (!connector_list)
>   return -ENOMEM;
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20171012221758.512-1-harshasharmaiitr%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

Re: [PATCH] objtool: Fix memory leak in decode_instructions()

[Kamalesh Babulal]

On Friday 13 October 2017 10:36 AM, Josh Poimboeuf wrote:

On Fri, Oct 13, 2017 at 10:14:36AM +0530, Kamalesh Babulal wrote:

On Thursday 12 October 2017 09:40 PM, Josh Poimboeuf wrote:

On Thu, Oct 12, 2017 at 02:32:14PM +0530, Kamalesh Babulal wrote:

free the allocated insn before returning, when an error occurs
before adding insn to file->insn_list.

Signed-off-by: Kamalesh Babulal 


Any chance you're working on porting objtool to ppc64le? :-)

Acked-by: Josh Poimboeuf 



Thanks for the review. I have started working on it :)


Good!  Let me know if you have any questions.


Thank you, I am sure I will have lots of them.



I originally wrote objtool with arch-independence in mind, though with
the new "objtool 2.0" rewrite, it unfortunately became more
x86-specific.

I was hoping to work on making it more arch-independent, and then start
porting it to other arches, but it may be a few months before I have the
time to do so.  So any work you want to there would be great.



Sure, will keep that in mind to abstract arch-independent code in to 
common files and push arch-dependent code into arch/ directory for both 
ppc64le/x86.


--
cheers,
Kamalesh.

Re: [PATCH] objtool: Fix memory leak in decode_instructions()

[Kamalesh Babulal]

On Friday 13 October 2017 10:36 AM, Josh Poimboeuf wrote:

On Fri, Oct 13, 2017 at 10:14:36AM +0530, Kamalesh Babulal wrote:

On Thursday 12 October 2017 09:40 PM, Josh Poimboeuf wrote:

On Thu, Oct 12, 2017 at 02:32:14PM +0530, Kamalesh Babulal wrote:

free the allocated insn before returning, when an error occurs
before adding insn to file->insn_list.

Signed-off-by: Kamalesh Babulal 


Any chance you're working on porting objtool to ppc64le? :-)

Acked-by: Josh Poimboeuf 



Thanks for the review. I have started working on it :)


Good!  Let me know if you have any questions.


Thank you, I am sure I will have lots of them.



I originally wrote objtool with arch-independence in mind, though with
the new "objtool 2.0" rewrite, it unfortunately became more
x86-specific.

I was hoping to work on making it more arch-independent, and then start
porting it to other arches, but it may be a few months before I have the
time to do so.  So any work you want to there would be great.



Sure, will keep that in mind to abstract arch-independent code in to 
common files and push arch-dependent code into arch/ directory for both 
ppc64le/x86.


--
cheers,
Kamalesh.

Re: [PATCH v2] bcache: safeguard a dangerous addressing in closure_queue

[Michael Lyle]

Hi Liang--

Thanks for the quick turnaround.  I've added this to bcache-for-next.

On 10/12/2017 10:30 PM, Liang Chen wrote:
> The use of the union reduces the size of closure struct by taking advantage
> of the current size of its members. The offset of func in work_struct equals
> the size of the first three members, so that work.work_func will just
> reference the forth member - fn.
> 
> This is smart but dangerous. It can be broken if work_struct or the other
> structs get changed, and can be a bit difficult to debug.
> 
> Signed-off-by: Liang Chen 

Reviewed-by: Michael Lyle 

-Mike

Re: [PATCH v2] bcache: safeguard a dangerous addressing in closure_queue

[Michael Lyle]

Hi Liang--

Thanks for the quick turnaround.  I've added this to bcache-for-next.

On 10/12/2017 10:30 PM, Liang Chen wrote:
> The use of the union reduces the size of closure struct by taking advantage
> of the current size of its members. The offset of func in work_struct equals
> the size of the first three members, so that work.work_func will just
> reference the forth member - fn.
> 
> This is smart but dangerous. It can be broken if work_struct or the other
> structs get changed, and can be a bit difficult to debug.
> 
> Signed-off-by: Liang Chen 

Reviewed-by: Michael Lyle 

-Mike

[PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

[Yasunari.Takiguchi]

From: Yasunari Takiguchi 

Hi,

This is the patch series (version 4) of Sony CXD2880 DVB-T2/T tuner + 
demodulator driver.The driver supports DVB-API and interfaces through 
SPI.

We have tested the driver on Raspberry Pi 3 and got picture and sound 
from a media player.

The change history of this patch series is as below.

[Change list]
Changes in V4
(1)Total patch number was changed from 14 to 12.
 We put [PATCH v3 12/14], [PATCH v3 13/14] and [PATCH v3 14/14]
   in [PATCH v4 12/12].

(2)Removed another file.
 These below files were removed because we changed it so that
   demodulator does not wait for locking the signal.

[PATCH v4 09/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.c
  -removed
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.h
  -removed
[PATCH v4 11/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c
  -removed
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.h
  -removed

(3)The detail change items of each files are as below.
[PATCH v4 02/12]
   drivers/media/spi/cxd2880-spi.c
  -removed Camel case
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}

[PATCH v4 03/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_io.c
  -removed unnecessary initialization at variable declaration
  -modified how to write consecutive registers

[PATCH v4 04/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c
  -removed unnecessary initialization at variable declaration

[PATCH v4 05/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c
  -used over 80 columns limit, it makes fine to read codes
  -removed unnecessary initialization at variable declaration
  -modified how to write consecutive registers
  -removed unnecessary brace {}
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.h
  -adjusted of indent spaces of macro
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_driver_version.h
  -updated version information
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.c
  -removed unnecessary brace {}

[PATCH v4 06/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ.c
  -removed unnecessary initialization at variable declaration

[PATCH v4 07/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
  -modified typo "inavlid" to "invalid" at pr_err
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -changed to use cxd2880_dvbt_tune and cxd2880_dvbt2_tune 
   instead of cxd2880_integ_dvbt_tune and cxd2880_integ_dvbt2_tune
(because we changed it so that demodulator does not 
 wait for locking the signal.) 

[PATCH v4 08/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.c
  -used over 80 columns limit, it makes fine to read codes
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -modified how to write consecutive registers

[PATCH v4 09/12]
   #drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.c
  -cxd2880_integ_dvbt.c file was removed from V4.
   #drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.h
  -cxd2880_integ_dvbt.h file was removed from V4.
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt_mon.c
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -changed position of static const (to top part of the file)

[PATCH v4 10/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2.c
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -modified how to write consecutive registers

[PATCH v4 11/12]
   #drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c
  -cxd2880_integ_dvbt2.c file was removed from V4.
   #drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.h
  -cxd2880_integ_dvbt2.h file was removed from V4.
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2_mon.c
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -changed position of static const (to top part of the file)

[PATCH v4 12/12]
   drivers/media/dvb-frontends/cxd2880/Makefile
  -removed cxd2880_integ_dvbt2.o and cxd2880_integ_dvbt.o 

Changes in V3
(1)Total patch number was changed from 15 to 14,
   due to the all files of [PATCH v2 04/15] were removed.
   drivers/media/dvb-frontends/cxd2880/cxd2880_math.c
  -Removed
   drivers/media/dvb-frontends/cxd2880/cxd2880_math.h
  -Removed

(2)Removed another 

[PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

[Yasunari.Takiguchi]

From: Yasunari Takiguchi 

Hi,

This is the patch series (version 4) of Sony CXD2880 DVB-T2/T tuner + 
demodulator driver.The driver supports DVB-API and interfaces through 
SPI.

We have tested the driver on Raspberry Pi 3 and got picture and sound 
from a media player.

The change history of this patch series is as below.

[Change list]
Changes in V4
(1)Total patch number was changed from 14 to 12.
 We put [PATCH v3 12/14], [PATCH v3 13/14] and [PATCH v3 14/14]
   in [PATCH v4 12/12].

(2)Removed another file.
 These below files were removed because we changed it so that
   demodulator does not wait for locking the signal.

[PATCH v4 09/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.c
  -removed
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.h
  -removed
[PATCH v4 11/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c
  -removed
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.h
  -removed

(3)The detail change items of each files are as below.
[PATCH v4 02/12]
   drivers/media/spi/cxd2880-spi.c
  -removed Camel case
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}

[PATCH v4 03/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_io.c
  -removed unnecessary initialization at variable declaration
  -modified how to write consecutive registers

[PATCH v4 04/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_devio_spi.c
  -removed unnecessary initialization at variable declaration

[PATCH v4 05/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.c
  -used over 80 columns limit, it makes fine to read codes
  -removed unnecessary initialization at variable declaration
  -modified how to write consecutive registers
  -removed unnecessary brace {}
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd.h
  -adjusted of indent spaces of macro
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_driver_version.h
  -updated version information
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_mon.c
  -removed unnecessary brace {}

[PATCH v4 06/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_integ.c
  -removed unnecessary initialization at variable declaration

[PATCH v4 07/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_top.c
  -modified typo "inavlid" to "invalid" at pr_err
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -changed to use cxd2880_dvbt_tune and cxd2880_dvbt2_tune 
   instead of cxd2880_integ_dvbt_tune and cxd2880_integ_dvbt2_tune
(because we changed it so that demodulator does not 
 wait for locking the signal.) 

[PATCH v4 08/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt.c
  -used over 80 columns limit, it makes fine to read codes
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -modified how to write consecutive registers

[PATCH v4 09/12]
   #drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.c
  -cxd2880_integ_dvbt.c file was removed from V4.
   #drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt.h
  -cxd2880_integ_dvbt.h file was removed from V4.
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt_mon.c
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -changed position of static const (to top part of the file)

[PATCH v4 10/12]
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2.c
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -modified how to write consecutive registers

[PATCH v4 11/12]
   #drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.c
  -cxd2880_integ_dvbt2.c file was removed from V4.
   #drivers/media/dvb-frontends/cxd2880/cxd2880_integ_dvbt2.h
  -cxd2880_integ_dvbt2.h file was removed from V4.
   drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2_mon.c
  -removed unnecessary initialization at variable declaration
  -removed unnecessary brace {}
  -changed position of static const (to top part of the file)

[PATCH v4 12/12]
   drivers/media/dvb-frontends/cxd2880/Makefile
  -removed cxd2880_integ_dvbt2.o and cxd2880_integ_dvbt.o 

Changes in V3
(1)Total patch number was changed from 15 to 14,
   due to the all files of [PATCH v2 04/15] were removed.
   drivers/media/dvb-frontends/cxd2880/cxd2880_math.c
  -Removed
   drivers/media/dvb-frontends/cxd2880/cxd2880_math.h
  -Removed

(2)Removed another file.
   

Re: [PATCH 4.13 0/2] 4.13.7-stable review

[Greg Kroah-Hartman]

On Thu, Oct 12, 2017 at 05:45:01PM -0600, Shuah Khan wrote:
> On 10/12/2017 03:26 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.13.7 release.
> > There are 2 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Oct 14 21:25:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.7-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.13.y
> > and the diffstat can be found below.
> > 
> 
> Compiled and booted on my test system. No dmesg regressions. 
> kselftest run regression since 4.13.6
> 
> selftests: posix_timers
> 
> selftests: raw_skew
> 
> not ok 1..7 selftests:  raw_skew [FAIL]
> 
> No idea why yet. cc'ing John Stultz to see if he has any ideas.

That's odd, given the small number of patches here...

thanks for testing.

greg k-h

Re: [PATCH 4.13 0/2] 4.13.7-stable review

[Greg Kroah-Hartman]

On Thu, Oct 12, 2017 at 05:45:01PM -0600, Shuah Khan wrote:
> On 10/12/2017 03:26 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.13.7 release.
> > There are 2 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Oct 14 21:25:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.7-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.13.y
> > and the diffstat can be found below.
> > 
> 
> Compiled and booted on my test system. No dmesg regressions. 
> kselftest run regression since 4.13.6
> 
> selftests: posix_timers
> 
> selftests: raw_skew
> 
> not ok 1..7 selftests:  raw_skew [FAIL]
> 
> No idea why yet. cc'ing John Stultz to see if he has any ideas.

That's odd, given the small number of patches here...

thanks for testing.

greg k-h

[PATCH v2] bcache: safeguard a dangerous addressing in closure_queue

[Liang Chen]

The use of the union reduces the size of closure struct by taking advantage
of the current size of its members. The offset of func in work_struct equals
the size of the first three members, so that work.work_func will just
reference the forth member - fn.

This is smart but dangerous. It can be broken if work_struct or the other
structs get changed, and can be a bit difficult to debug.

Signed-off-by: Liang Chen 
---
Replacing all occurences of closure_fn to work_func_fn seems to be an option
but that would end up with a big lenghty and error prone patch.

 drivers/md/bcache/closure.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/md/bcache/closure.h b/drivers/md/bcache/closure.h
index 295b7e4..00fb314 100644
--- a/drivers/md/bcache/closure.h
+++ b/drivers/md/bcache/closure.h
@@ -251,6 +251,12 @@ static inline void set_closure_fn(struct closure *cl, 
closure_fn *fn,
 static inline void closure_queue(struct closure *cl)
 {
struct workqueue_struct *wq = cl->wq;
+   /**
+* Changes made to closure, work_struct, or a couple of other structs
+* may cause work.func not pointing to the right location.
+*/
+   BUILD_BUG_ON(offsetof(struct closure, fn)
+!= offsetof(struct work_struct, func));
if (wq) {
INIT_WORK(>work, cl->work.func);
BUG_ON(!queue_work(wq, >work));
-- 
1.8.3.1

[PATCH v2] bcache: safeguard a dangerous addressing in closure_queue

[Liang Chen]

The use of the union reduces the size of closure struct by taking advantage
of the current size of its members. The offset of func in work_struct equals
the size of the first three members, so that work.work_func will just
reference the forth member - fn.

This is smart but dangerous. It can be broken if work_struct or the other
structs get changed, and can be a bit difficult to debug.

Signed-off-by: Liang Chen 
---
Replacing all occurences of closure_fn to work_func_fn seems to be an option
but that would end up with a big lenghty and error prone patch.

 drivers/md/bcache/closure.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/md/bcache/closure.h b/drivers/md/bcache/closure.h
index 295b7e4..00fb314 100644
--- a/drivers/md/bcache/closure.h
+++ b/drivers/md/bcache/closure.h
@@ -251,6 +251,12 @@ static inline void set_closure_fn(struct closure *cl, 
closure_fn *fn,
 static inline void closure_queue(struct closure *cl)
 {
struct workqueue_struct *wq = cl->wq;
+   /**
+* Changes made to closure, work_struct, or a couple of other structs
+* may cause work.func not pointing to the right location.
+*/
+   BUILD_BUG_ON(offsetof(struct closure, fn)
+!= offsetof(struct work_struct, func));
if (wq) {
INIT_WORK(>work, cl->work.func);
BUG_ON(!queue_work(wq, >work));
-- 
1.8.3.1

Re: [PATCH v9 2/5] x86/cpuid: Add generic table for cpuid dependencies

[Ingo Molnar]

* Thomas Gleixner  wrote:

> On Thu, 12 Oct 2017, Ingo Molnar wrote:
> > 
> > * Andi Kleen  wrote:
> > 
> > > --- /dev/null
> > > +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> > > @@ -0,0 +1,109 @@
> > > +/* Declare dependencies between CPUIDs */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +struct cpuid_dep {
> > > + unsigned short feature;
> > > + unsigned short depends;
> > > +};
> > 
> > Why are these 16-bit fields? 16-bit data types should be avoided as much as 
> > possible, as they generate suboptimal code.
> 
> I was looking at that as well and decided that we preferrably have a
> compressed data structure. The code which walks the table is hardly
> performance critical and the difference in text size is marginal.

So the code should all be __init (once that is fixed), hence data and text size 
literally does not matter - it gets freed.

So the only effect the 16-bit variables have is (marginally) worse boot times.

Thanks,

Ingo

Re: [PATCH v9 2/5] x86/cpuid: Add generic table for cpuid dependencies

[Ingo Molnar]

* Thomas Gleixner  wrote:

> On Thu, 12 Oct 2017, Ingo Molnar wrote:
> > 
> > * Andi Kleen  wrote:
> > 
> > > --- /dev/null
> > > +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> > > @@ -0,0 +1,109 @@
> > > +/* Declare dependencies between CPUIDs */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +struct cpuid_dep {
> > > + unsigned short feature;
> > > + unsigned short depends;
> > > +};
> > 
> > Why are these 16-bit fields? 16-bit data types should be avoided as much as 
> > possible, as they generate suboptimal code.
> 
> I was looking at that as well and decided that we preferrably have a
> compressed data structure. The code which walks the table is hardly
> performance critical and the difference in text size is marginal.

So the code should all be __init (once that is fixed), hence data and text size 
literally does not matter - it gets freed.

So the only effect the 16-bit variables have is (marginally) worse boot times.

Thanks,

Ingo

Re: [lkp-robot] [ipv6] 2b760fcf5c: WARNING:suspicious_RCU_usage

[Wei Wang]

On Thu, Oct 12, 2017 at 7:03 PM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit (built with gcc-6):
>
> commit: 2b760fcf5cfb34e8610df56d83745b2b74ae1379 ("ipv6: hook up exception 
> table to store dst cache")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -m 420M
>
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
>
>
> +---+++
> |   | 38fbcc | 
> 2b760fcf5c |
> +---+++
> | boot_successes| 6  | 2  
> |
> | boot_failures | 2  | 32 
> |
> | BUG:kernel_hang_in_test_stage | 2  |
> |
> | WARNING:suspicious_RCU_usage  | 0  | 32 
> |
> | net/ipv6/route.c:#suspicious_rcu_dereference_check()usage | 0  | 32 
> |
> | WARNING:at_net/ipv6/route.c:#__rt6_find_exception_rcu | 0  | 32 
> |
> +---+++
>
>

This warning should be fixed by later commit 66f5d6ce53e6 ("ipv6:
replace rwlock with rcu and spinlock in fib6_table").
But by this commit, rcu is not yet used in ip6_pol_route(). (Sorry
that I missed this earlier.) Not sure what to do here to fix this
particular warning for this commit.

> [   19.842463] WARNING: suspicious RCU usage
> [   19.843540] 4.14.0-rc3-00907-g2b760fc #58 Not tainted
> [   19.844776] -
> [   19.845854] net/ipv6/route.c:1355 suspicious rcu_dereference_check() usage!
> [   19.847961]
> [   19.847961] other info that might help us debug this:
> [   19.847961]
> [   19.850409]
> [   19.850409] rcu_scheduler_active = 2, debug_locks = 1
> [   19.852220] 2 locks held by odhcpd/3695:
> [   19.853285]  #0:  (sk_lock-AF_INET6){+.+.}, at: [] 
> ip6_datagram_connect+0x1d/0x3f
> [   19.855480]  #1:  (>tb6_lock){++--}, at: [] 
> ip6_pol_route+0x51/0x80c
> [   19.857583]
> [   19.857583] stack backtrace:
> [   19.859115] CPU: 0 PID: 3695 Comm: odhcpd Not tainted 
> 4.14.0-rc3-00907-g2b760fc #58
> [   19.861087] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-1 04/01/2014
> [   19.863123] Call Trace:
> [   19.863963]  dump_stack+0x86/0xc0
> [   19.864926]  lockdep_rcu_suspicious+0xea/0xf3
> [   19.866031]  rt6_find_cached_rt+0x51/0x84
> [   19.867173]  ip6_pol_route+0x21c/0x80c
> [   19.868199]  ip6_pol_route_output+0x16/0x18
> [   19.869287]  fib6_rule_lookup+0x1e/0x55
> [   19.870307]  ip6_route_output_flags+0xb6/0xc2
> [   19.871410]  ip6_dst_lookup_tail+0x4f/0x194
> [   19.872500]  ip6_dst_lookup_flow+0x38/0x78
> [   19.873562]  ip6_datagram_dst_update+0x254/0x482
> [   19.874690]  ? save_stack_trace+0x1b/0x1d
> [   19.875760]  __ip6_datagram_connect+0x20e/0x299
> [   19.876881]  ? __ip6_datagram_connect+0x20e/0x299
> [   19.878054]  ip6_datagram_connect+0x2b/0x3f
> [   19.879160]  ip6_datagram_connect_v6_only+0x14/0x1c
> [   19.880348]  inet_dgram_connect+0x49/0x68
> [   19.881424]  SyS_connect+0x74/0xa1
> [   19.882424]  ? __might_fault+0x7e/0x84
> [   19.883495]  ? _copy_from_user+0x61/0x82
> [   19.884531]  compat_SyS_socketcall+0xfb/0x1fd
> [   19.885644]  ? trace_hardirqs_on_caller+0x17b/0x197
> [   19.886868]  do_int80_syscall_32+0x66/0x15a
> [   19.887979]  entry_INT80_compat+0x32/0x50
> [   19.889037] RIP: 0023:0xf7f5e384
> [   19.889985] RSP: 002b:ffc94db8 EFLAGS: 0296 ORIG_RAX: 
> 0066
> [   19.891958] RAX: ffda RBX: 0003 RCX: 
> ffc94dc8
> [   19.893475] RDX: f7fa4000 RSI: ffc94dc8 RDI: 
> ffc94ee0
> [   19.894946] RBP: ffc94e28 R08:  R09: 
> 
> [   19.896454] R10:  R11:  R12: 
> 
> [   19.897968] R13:  R14:  R15: 
> 
> [   19.899594] [ cut here ]
> [   19.900775] WARNING: CPU: 0 PID: 3695 at net/ipv6/route.c:1208 
> __rt6_find_exception_rcu+0x1b/0x7b
> [   19.903220] Modules linked in:
> [   19.904172] CPU: 0 PID: 3695 Comm: odhcpd Not tainted 
> 4.14.0-rc3-00907-g2b760fc #58
> [   19.906147] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-1 04/01/2014
> [   19.908263] task: a024549f0040 task.stack: aee58081
> [   19.909644] RIP: 0010:__rt6_find_exception_rcu+0x1b/0x7b
> [   19.910973] RSP: :aee580813af0 EFLAGS: 00010246
> [   19.912231] RAX:  RBX: aee580813cf0 RCX: 
> 0001
> [   19.913783] RDX:  RSI: 

Re: [lkp-robot] [ipv6] 2b760fcf5c: WARNING:suspicious_RCU_usage

[Wei Wang]

On Thu, Oct 12, 2017 at 7:03 PM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit (built with gcc-6):
>
> commit: 2b760fcf5cfb34e8610df56d83745b2b74ae1379 ("ipv6: hook up exception 
> table to store dst cache")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -m 420M
>
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
>
>
> +---+++
> |   | 38fbcc | 
> 2b760fcf5c |
> +---+++
> | boot_successes| 6  | 2  
> |
> | boot_failures | 2  | 32 
> |
> | BUG:kernel_hang_in_test_stage | 2  |
> |
> | WARNING:suspicious_RCU_usage  | 0  | 32 
> |
> | net/ipv6/route.c:#suspicious_rcu_dereference_check()usage | 0  | 32 
> |
> | WARNING:at_net/ipv6/route.c:#__rt6_find_exception_rcu | 0  | 32 
> |
> +---+++
>
>

This warning should be fixed by later commit 66f5d6ce53e6 ("ipv6:
replace rwlock with rcu and spinlock in fib6_table").
But by this commit, rcu is not yet used in ip6_pol_route(). (Sorry
that I missed this earlier.) Not sure what to do here to fix this
particular warning for this commit.

> [   19.842463] WARNING: suspicious RCU usage
> [   19.843540] 4.14.0-rc3-00907-g2b760fc #58 Not tainted
> [   19.844776] -
> [   19.845854] net/ipv6/route.c:1355 suspicious rcu_dereference_check() usage!
> [   19.847961]
> [   19.847961] other info that might help us debug this:
> [   19.847961]
> [   19.850409]
> [   19.850409] rcu_scheduler_active = 2, debug_locks = 1
> [   19.852220] 2 locks held by odhcpd/3695:
> [   19.853285]  #0:  (sk_lock-AF_INET6){+.+.}, at: [] 
> ip6_datagram_connect+0x1d/0x3f
> [   19.855480]  #1:  (>tb6_lock){++--}, at: [] 
> ip6_pol_route+0x51/0x80c
> [   19.857583]
> [   19.857583] stack backtrace:
> [   19.859115] CPU: 0 PID: 3695 Comm: odhcpd Not tainted 
> 4.14.0-rc3-00907-g2b760fc #58
> [   19.861087] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-1 04/01/2014
> [   19.863123] Call Trace:
> [   19.863963]  dump_stack+0x86/0xc0
> [   19.864926]  lockdep_rcu_suspicious+0xea/0xf3
> [   19.866031]  rt6_find_cached_rt+0x51/0x84
> [   19.867173]  ip6_pol_route+0x21c/0x80c
> [   19.868199]  ip6_pol_route_output+0x16/0x18
> [   19.869287]  fib6_rule_lookup+0x1e/0x55
> [   19.870307]  ip6_route_output_flags+0xb6/0xc2
> [   19.871410]  ip6_dst_lookup_tail+0x4f/0x194
> [   19.872500]  ip6_dst_lookup_flow+0x38/0x78
> [   19.873562]  ip6_datagram_dst_update+0x254/0x482
> [   19.874690]  ? save_stack_trace+0x1b/0x1d
> [   19.875760]  __ip6_datagram_connect+0x20e/0x299
> [   19.876881]  ? __ip6_datagram_connect+0x20e/0x299
> [   19.878054]  ip6_datagram_connect+0x2b/0x3f
> [   19.879160]  ip6_datagram_connect_v6_only+0x14/0x1c
> [   19.880348]  inet_dgram_connect+0x49/0x68
> [   19.881424]  SyS_connect+0x74/0xa1
> [   19.882424]  ? __might_fault+0x7e/0x84
> [   19.883495]  ? _copy_from_user+0x61/0x82
> [   19.884531]  compat_SyS_socketcall+0xfb/0x1fd
> [   19.885644]  ? trace_hardirqs_on_caller+0x17b/0x197
> [   19.886868]  do_int80_syscall_32+0x66/0x15a
> [   19.887979]  entry_INT80_compat+0x32/0x50
> [   19.889037] RIP: 0023:0xf7f5e384
> [   19.889985] RSP: 002b:ffc94db8 EFLAGS: 0296 ORIG_RAX: 
> 0066
> [   19.891958] RAX: ffda RBX: 0003 RCX: 
> ffc94dc8
> [   19.893475] RDX: f7fa4000 RSI: ffc94dc8 RDI: 
> ffc94ee0
> [   19.894946] RBP: ffc94e28 R08:  R09: 
> 
> [   19.896454] R10:  R11:  R12: 
> 
> [   19.897968] R13:  R14:  R15: 
> 
> [   19.899594] [ cut here ]
> [   19.900775] WARNING: CPU: 0 PID: 3695 at net/ipv6/route.c:1208 
> __rt6_find_exception_rcu+0x1b/0x7b
> [   19.903220] Modules linked in:
> [   19.904172] CPU: 0 PID: 3695 Comm: odhcpd Not tainted 
> 4.14.0-rc3-00907-g2b760fc #58
> [   19.906147] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-1 04/01/2014
> [   19.908263] task: a024549f0040 task.stack: aee58081
> [   19.909644] RIP: 0010:__rt6_find_exception_rcu+0x1b/0x7b
> [   19.910973] RSP: :aee580813af0 EFLAGS: 00010246
> [   19.912231] RAX:  RBX: aee580813cf0 RCX: 
> 0001
> [   19.913783] RDX:  RSI: 9b47f900 RDI: 
> 

Re: [PATCH] objtool: Fix memory leak in decode_instructions()

[Josh Poimboeuf]

On Fri, Oct 13, 2017 at 10:14:36AM +0530, Kamalesh Babulal wrote:
> On Thursday 12 October 2017 09:40 PM, Josh Poimboeuf wrote:
> > On Thu, Oct 12, 2017 at 02:32:14PM +0530, Kamalesh Babulal wrote:
> > > free the allocated insn before returning, when an error occurs
> > > before adding insn to file->insn_list.
> > > 
> > > Signed-off-by: Kamalesh Babulal 
> > 
> > Any chance you're working on porting objtool to ppc64le? :-)
> > 
> > Acked-by: Josh Poimboeuf 
> > 
> 
> Thanks for the review. I have started working on it :)

Good!  Let me know if you have any questions.

I originally wrote objtool with arch-independence in mind, though with
the new "objtool 2.0" rewrite, it unfortunately became more
x86-specific.

I was hoping to work on making it more arch-independent, and then start
porting it to other arches, but it may be a few months before I have the
time to do so.  So any work you want to there would be great.

-- 
Josh

Re: [PATCH] objtool: Fix memory leak in decode_instructions()

[Josh Poimboeuf]

On Fri, Oct 13, 2017 at 10:14:36AM +0530, Kamalesh Babulal wrote:
> On Thursday 12 October 2017 09:40 PM, Josh Poimboeuf wrote:
> > On Thu, Oct 12, 2017 at 02:32:14PM +0530, Kamalesh Babulal wrote:
> > > free the allocated insn before returning, when an error occurs
> > > before adding insn to file->insn_list.
> > > 
> > > Signed-off-by: Kamalesh Babulal 
> > 
> > Any chance you're working on porting objtool to ppc64le? :-)
> > 
> > Acked-by: Josh Poimboeuf 
> > 
> 
> Thanks for the review. I have started working on it :)

Good!  Let me know if you have any questions.

I originally wrote objtool with arch-independence in mind, though with
the new "objtool 2.0" rewrite, it unfortunately became more
x86-specific.

I was hoping to work on making it more arch-independent, and then start
porting it to other arches, but it may be a few months before I have the
time to do so.  So any work you want to there would be great.

-- 
Josh

Re: [PATCH] target: make config_item_type const

[kbuild test robot]

Hi Bhumika,

[auto build test WARNING on target/master]
[also build test WARNING on v4.14-rc4 next-20171009]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bhumika-Goyal/target-make-config_item_type-const/20171013-120027
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git 
master
config: x86_64-randconfig-x012-201741 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/target/target_core_configfs.c:320:15: warning: initialization 
>> discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
   .ci_type = _core_fabrics_item,
  ^
   drivers/target/target_core_configfs.c: In function 
'target_core_alua_create_lu_gp':
>> drivers/target/target_core_configfs.c:2405:4: warning: passing argument 3 of 
>> 'config_group_init_type_name' discards 'const' qualifier from pointer target 
>> type [-Wdiscarded-qualifiers]
   _core_alua_lu_gp_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c: In function 
'target_core_alua_create_tg_pt_gp':
   drivers/target/target_core_configfs.c:2844:4: warning: passing argument 3 of 
'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   _core_alua_tg_pt_gp_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c: In function 'target_core_make_subdev':
   drivers/target/target_core_configfs.c:2975:24: warning: passing argument 3 
of 'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   "default_tg_pt_gp", _core_alua_tg_pt_gp_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c: In function 
'target_core_call_addhbatotarget':
   drivers/target/target_core_configfs.c:3170:4: warning: passing argument 3 of 
'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   _core_hba_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c: In function 
'target_core_init_configfs':
   drivers/target/target_core_configfs.c:3231:4: warning: passing argument 3 of 
'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   _core_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c:3237:51: warning: passing argument 3 
of 'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
 config_group_init_type_name(_group, "alua", _core_alua_cit);
  ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c:3245:4: warning: passing argument 3 of 
'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   _core_alua_lu_gps_cit);
   ^
   In file included from 

Re: [PATCH] target: make config_item_type const

[kbuild test robot]

Hi Bhumika,

[auto build test WARNING on target/master]
[also build test WARNING on v4.14-rc4 next-20171009]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bhumika-Goyal/target-make-config_item_type-const/20171013-120027
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git 
master
config: x86_64-randconfig-x012-201741 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/target/target_core_configfs.c:320:15: warning: initialization 
>> discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
   .ci_type = _core_fabrics_item,
  ^
   drivers/target/target_core_configfs.c: In function 
'target_core_alua_create_lu_gp':
>> drivers/target/target_core_configfs.c:2405:4: warning: passing argument 3 of 
>> 'config_group_init_type_name' discards 'const' qualifier from pointer target 
>> type [-Wdiscarded-qualifiers]
   _core_alua_lu_gp_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c: In function 
'target_core_alua_create_tg_pt_gp':
   drivers/target/target_core_configfs.c:2844:4: warning: passing argument 3 of 
'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   _core_alua_tg_pt_gp_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c: In function 'target_core_make_subdev':
   drivers/target/target_core_configfs.c:2975:24: warning: passing argument 3 
of 'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   "default_tg_pt_gp", _core_alua_tg_pt_gp_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c: In function 
'target_core_call_addhbatotarget':
   drivers/target/target_core_configfs.c:3170:4: warning: passing argument 3 of 
'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   _core_hba_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c: In function 
'target_core_init_configfs':
   drivers/target/target_core_configfs.c:3231:4: warning: passing argument 3 of 
'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   _core_cit);
   ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c:3237:51: warning: passing argument 3 
of 'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
 config_group_init_type_name(_group, "alua", _core_alua_cit);
  ^
   In file included from drivers/target/target_core_configfs.c:37:0:
   include/linux/configfs.h:102:13: note: expected 'struct config_item_type *' 
but argument is of type 'const struct config_item_type *'
extern void config_group_init_type_name(struct config_group *group,
^~~
   drivers/target/target_core_configfs.c:3245:4: warning: passing argument 3 of 
'config_group_init_type_name' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
   _core_alua_lu_gps_cit);
   ^
   In file included from 

Re: [PATCH] bcache: safeguard a dangerous addressing in closure_queue

[Liang Chen]

On Fri, Oct 13, 2017 at 1:44 AM, Michael Lyle  wrote:
> On 10/12/2017 07:37 AM, Liang Chen wrote:
>> The use of the union reduces the size of closure struct by taking advantage
>> of the current size of its members. The offset of func in work_struct equals
>> the size of the first three members, so that work.work_func will just
>> reference the forth member - fn.
>>
>> This is smart but dangerous. It can be broken if work_struct or the other
>> structs get changed, and can be a bit difficult to debug.
>>
>> Signed-off-by: Liang Chen 
>
> So the objective here is to make sure that struct work_struct and the
> anonymous struct remain identical?  I agree that's a potential problem
> for future maintenance.
>
> Could we use BUILD_BUG_ON with offsets and sizes to do the same, to get
> compile-time checking and avoid doing anything at runtime (I know the
> compiler can usually omit the BUG but better to be safe)?  Otherwise a
> kernel that triggered this problem would compile, and it'd only be if
> someone actually used bcache that it would trigger.
>
> Mike

Yeah, the objective here is to make sure the offset of func and fn remains the
same so cl->work.func will just reference cl->fn.

Sure, BUILD_BUG_ON will do the work, and can capture the problem at compile
time. Thanks for the reminding! I will submit another patch soon.

Thanks,
Liang

Re: [PATCH] bcache: safeguard a dangerous addressing in closure_queue

[Liang Chen]

On Fri, Oct 13, 2017 at 1:44 AM, Michael Lyle  wrote:
> On 10/12/2017 07:37 AM, Liang Chen wrote:
>> The use of the union reduces the size of closure struct by taking advantage
>> of the current size of its members. The offset of func in work_struct equals
>> the size of the first three members, so that work.work_func will just
>> reference the forth member - fn.
>>
>> This is smart but dangerous. It can be broken if work_struct or the other
>> structs get changed, and can be a bit difficult to debug.
>>
>> Signed-off-by: Liang Chen 
>
> So the objective here is to make sure that struct work_struct and the
> anonymous struct remain identical?  I agree that's a potential problem
> for future maintenance.
>
> Could we use BUILD_BUG_ON with offsets and sizes to do the same, to get
> compile-time checking and avoid doing anything at runtime (I know the
> compiler can usually omit the BUG but better to be safe)?  Otherwise a
> kernel that triggered this problem would compile, and it'd only be if
> someone actually used bcache that it would trigger.
>
> Mike

Yeah, the objective here is to make sure the offset of func and fn remains the
same so cl->work.func will just reference cl->fn.

Sure, BUILD_BUG_ON will do the work, and can capture the problem at compile
time. Thanks for the reminding! I will submit another patch soon.

Thanks,
Liang

Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

[Josh Poimboeuf]

On Thu, Oct 12, 2017 at 12:05:04PM -0500, Christopher Lameter wrote:
> On Wed, 11 Oct 2017, Josh Poimboeuf wrote:
> 
> > I failed to add the slab maintainers to CC on the last attempt.  Trying
> > again.
> 
> 
> Hmmm... Yea. SLOB is rarely used and tested. Good illustration of a simple
> allocator and the K mechanism that was used in the early kernels.
> 
> > > Adding the slub maintainers.  Is slob still supposed to work?
> 
> Have not seen anyone using it in a decade or so.
> 
> Does the same config with SLUB and slub_debug on the commandline run
> cleanly?
> 
> > > I have no idea how that crypto panic could could be related to slob, but
> > > at least it goes away when I switch to slub.
> 
> Can you run SLUB with full debug? specify slub_debug on the commandline or
> set CONFIG_SLUB_DEBUG_ON

Oddly enough, with CONFIG_SLUB+slub_debug, I get the same crypto panic I
got with CONFIG_SLOB.  The trapping instruction is:

  vmovdqa 0x140(%rdi),%xmm0
  
I'll try to bisect it tomorrow.  It at least goes back to v4.10.  I'm
not really sure whether this panic is related to SLUB or SLOB at all.
(Though the original panic reported upthread by the kernel test robot
*does* look SLOB related.)

  general protection fault:  [#1] PREEMPT SMP
  Modules linked in:
  CPU: 0 PID: 58 Comm: kworker/0:1 Not tainted 4.13.0 #81
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 
04/01/2014
  Workqueue: crypto mcryptd_flusher
  task: 880139108040 task.stack: c982c000
  RIP: 0010:skip_7+0x0/0x67
  RSP: 0018:c982fd88 EFLAGS: 00010246
  RAX: 88013834172c RBX: f7654321 RCX: 0003
  RDX:  RSI: 81d254f9 RDI: 8801381b1a88
  RBP: c982fd90 R08:  R09: 0001
  R10: 0001 R11:  R12: 82392260
  R13: 88013a7e6500 R14: fffb80f5 R15: 
  FS:  () GS:88013a60() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 7f88491ef914 CR3: 01e11000 CR4: 001406f0
  Call Trace:
   sha256_ctx_mgr_flush+0x28/0x30
   sha256_mb_flusher+0x53/0x120
   mcryptd_flusher+0xc4/0xf0
   process_one_work+0x253/0x6b0
   worker_thread+0x4d/0x3b0
   ? preempt_count_sub+0x9b/0x100
   kthread+0x133/0x150
   ? process_one_work+0x6b0/0x6b0
   ? kthread_create_on_node+0x70/0x70
   ret_from_fork+0x2a/0x40
  Code: 89 87 30 01 00 00 c7 87 58 01 00 00 ff ff ff ff 48 83 bf a0 01 00 00 00 
75 11 48 89 87 38 01 00 00 c7 87 5c 01 00 00 ff ff ff ff  f9 6f 87 40 01 00 
00 c5 f9 6f 8f 50 01 00 00 c4 e2 79 3b d1
  RIP: skip_7+0x0/0x67 RSP: c982fd88
  ---[ end trace d89a1613b7d1b8bc ]---
  BUG: sleeping function called from invalid context at 
./include/linux/percpu-rwsem.h:33
  in_atomic(): 1, irqs_disabled(): 0, pid: 58, name: kworker/0:1
  INFO: lockdep is turned off.
  Preemption disabled at:
  [] kernel_fpu_begin+0x13/0x20
  CPU: 0 PID: 58 Comm: kworker/0:1 Tainted: G  D 4.13.0 #81
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 
04/01/2014
  Workqueue: crypto mcryptd_flusher
  Call Trace:
   dump_stack+0x8e/0xcd
   ___might_sleep+0x185/0x260
   __might_sleep+0x4a/0x80
   exit_signals+0x33/0x2d0
   do_exit+0xb4/0xd80
   ? kthread+0x133/0x150
   rewind_stack_do_exit+0x17/0x20
  note: kworker/0:1[58] exited with preempt_count 1
  tsc: Refined TSC clocksource calibration: 2793.538 MHz
  clocksource: tsc: mask: 0x max_cycles: 0x28446877189, 
max_idle_ns: 440795280878 ns

-- 
Josh

Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel

[Josh Poimboeuf]

On Thu, Oct 12, 2017 at 12:05:04PM -0500, Christopher Lameter wrote:
> On Wed, 11 Oct 2017, Josh Poimboeuf wrote:
> 
> > I failed to add the slab maintainers to CC on the last attempt.  Trying
> > again.
> 
> 
> Hmmm... Yea. SLOB is rarely used and tested. Good illustration of a simple
> allocator and the K mechanism that was used in the early kernels.
> 
> > > Adding the slub maintainers.  Is slob still supposed to work?
> 
> Have not seen anyone using it in a decade or so.
> 
> Does the same config with SLUB and slub_debug on the commandline run
> cleanly?
> 
> > > I have no idea how that crypto panic could could be related to slob, but
> > > at least it goes away when I switch to slub.
> 
> Can you run SLUB with full debug? specify slub_debug on the commandline or
> set CONFIG_SLUB_DEBUG_ON

Oddly enough, with CONFIG_SLUB+slub_debug, I get the same crypto panic I
got with CONFIG_SLOB.  The trapping instruction is:

  vmovdqa 0x140(%rdi),%xmm0
  
I'll try to bisect it tomorrow.  It at least goes back to v4.10.  I'm
not really sure whether this panic is related to SLUB or SLOB at all.
(Though the original panic reported upthread by the kernel test robot
*does* look SLOB related.)

  general protection fault:  [#1] PREEMPT SMP
  Modules linked in:
  CPU: 0 PID: 58 Comm: kworker/0:1 Not tainted 4.13.0 #81
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 
04/01/2014
  Workqueue: crypto mcryptd_flusher
  task: 880139108040 task.stack: c982c000
  RIP: 0010:skip_7+0x0/0x67
  RSP: 0018:c982fd88 EFLAGS: 00010246
  RAX: 88013834172c RBX: f7654321 RCX: 0003
  RDX:  RSI: 81d254f9 RDI: 8801381b1a88
  RBP: c982fd90 R08:  R09: 0001
  R10: 0001 R11:  R12: 82392260
  R13: 88013a7e6500 R14: fffb80f5 R15: 
  FS:  () GS:88013a60() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 7f88491ef914 CR3: 01e11000 CR4: 001406f0
  Call Trace:
   sha256_ctx_mgr_flush+0x28/0x30
   sha256_mb_flusher+0x53/0x120
   mcryptd_flusher+0xc4/0xf0
   process_one_work+0x253/0x6b0
   worker_thread+0x4d/0x3b0
   ? preempt_count_sub+0x9b/0x100
   kthread+0x133/0x150
   ? process_one_work+0x6b0/0x6b0
   ? kthread_create_on_node+0x70/0x70
   ret_from_fork+0x2a/0x40
  Code: 89 87 30 01 00 00 c7 87 58 01 00 00 ff ff ff ff 48 83 bf a0 01 00 00 00 
75 11 48 89 87 38 01 00 00 c7 87 5c 01 00 00 ff ff ff ff  f9 6f 87 40 01 00 
00 c5 f9 6f 8f 50 01 00 00 c4 e2 79 3b d1
  RIP: skip_7+0x0/0x67 RSP: c982fd88
  ---[ end trace d89a1613b7d1b8bc ]---
  BUG: sleeping function called from invalid context at 
./include/linux/percpu-rwsem.h:33
  in_atomic(): 1, irqs_disabled(): 0, pid: 58, name: kworker/0:1
  INFO: lockdep is turned off.
  Preemption disabled at:
  [] kernel_fpu_begin+0x13/0x20
  CPU: 0 PID: 58 Comm: kworker/0:1 Tainted: G  D 4.13.0 #81
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 
04/01/2014
  Workqueue: crypto mcryptd_flusher
  Call Trace:
   dump_stack+0x8e/0xcd
   ___might_sleep+0x185/0x260
   __might_sleep+0x4a/0x80
   exit_signals+0x33/0x2d0
   do_exit+0xb4/0xd80
   ? kthread+0x133/0x150
   rewind_stack_do_exit+0x17/0x20
  note: kworker/0:1[58] exited with preempt_count 1
  tsc: Refined TSC clocksource calibration: 2793.538 MHz
  clocksource: tsc: mask: 0x max_cycles: 0x28446877189, 
max_idle_ns: 440795280878 ns

-- 
Josh

[PATCH v2] selftests/exec: include cwd in long path calculation

[Steve Muckle]

When creating a pathname close to PATH_MAX to test execveat, factor in
the current working directory path otherwise we end up with an absolute
path that is longer than PATH_MAX. While execveat() may succeed, subsequent
calls to the kernel from the runtime environment which are required to
successfully execute the test binary/script may fail because of this.

To keep the semantics of the test the same, rework the relative pathname
part of the test to be relative to the root directory so it isn't
decreased by the length of the current working directory path.

Signed-off-by: Steve Muckle 
---
Differences from v1:
 - free allocation from getcwd()
 - update comment in check_execveat_pathmax()

 tools/testing/selftests/exec/execveat.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/exec/execveat.c 
b/tools/testing/selftests/exec/execveat.c
index 8d5d1d2ee7c1..67cd4597db2b 100644
--- a/tools/testing/selftests/exec/execveat.c
+++ b/tools/testing/selftests/exec/execveat.c
@@ -147,7 +147,7 @@ static void exe_cp(const char *src, const char *dest)
 }
 
 #define XX_DIR_LEN 200
-static int check_execveat_pathmax(int dot_dfd, const char *src, int is_script)
+static int check_execveat_pathmax(int root_dfd, const char *src, int is_script)
 {
int fail = 0;
int ii, count, len;
@@ -156,20 +156,30 @@ static int check_execveat_pathmax(int dot_dfd, const char 
*src, int is_script)
 
if (*longpath == '\0') {
/* Create a filename close to PATH_MAX in length */
+   char *cwd = getcwd(NULL, 0);
+
+   if (!cwd) {
+   printf("Failed to getcwd(), errno=%d (%s)\n",
+  errno, strerror(errno));
+   return 2;
+   }
+   strcpy(longpath, cwd);
+   strcat(longpath, "/");
memset(longname, 'x', XX_DIR_LEN - 1);
longname[XX_DIR_LEN - 1] = '/';
longname[XX_DIR_LEN] = '\0';
-   count = (PATH_MAX - 3) / XX_DIR_LEN;
+   count = (PATH_MAX - 3 - strlen(cwd)) / XX_DIR_LEN;
for (ii = 0; ii < count; ii++) {
strcat(longpath, longname);
mkdir(longpath, 0755);
}
-   len = (PATH_MAX - 3) - (count * XX_DIR_LEN);
+   len = (PATH_MAX - 3 - strlen(cwd)) - (count * XX_DIR_LEN);
if (len <= 0)
len = 1;
memset(longname, 'y', len);
longname[len] = '\0';
strcat(longpath, longname);
+   free(cwd);
}
exe_cp(src, longpath);
 
@@ -190,7 +200,7 @@ static int check_execveat_pathmax(int dot_dfd, const char 
*src, int is_script)
}
 
/*
-* Execute as a long pathname relative to ".".  If this is a script,
+* Execute as a long pathname relative to "/".  If this is a script,
 * the interpreter will launch but fail to open the script because its
 * name ("/dev/fd/5/xxx") is bigger than PATH_MAX.
 *
@@ -200,10 +210,10 @@ static int check_execveat_pathmax(int dot_dfd, const char 
*src, int is_script)
 * the exit status shall be 126."), so allow either.
 */
if (is_script)
-   fail += check_execveat_invoked_rc(dot_dfd, longpath, 0,
+   fail += check_execveat_invoked_rc(root_dfd, longpath + 1, 0,
  127, 126);
else
-   fail += check_execveat(dot_dfd, longpath, 0);
+   fail += check_execveat(root_dfd, longpath + 1, 0);
 
return fail;
 }
@@ -218,6 +228,7 @@ static int run_tests(void)
int subdir_dfd_ephemeral = open_or_die("subdir.ephemeral",
   O_DIRECTORY|O_RDONLY);
int dot_dfd = open_or_die(".", O_DIRECTORY|O_RDONLY);
+   int root_dfd = open_or_die("/", O_DIRECTORY|O_RDONLY);
int dot_dfd_path = open_or_die(".", O_DIRECTORY|O_RDONLY|O_PATH);
int dot_dfd_cloexec = open_or_die(".", O_DIRECTORY|O_RDONLY|O_CLOEXEC);
int fd = open_or_die("execveat", O_RDONLY);
@@ -353,8 +364,8 @@ static int run_tests(void)
/* Attempt to execute relative to non-directory => ENOTDIR */
fail += check_execveat_fail(fd, "execveat", 0, ENOTDIR);
 
-   fail += check_execveat_pathmax(dot_dfd, "execveat", 0);
-   fail += check_execveat_pathmax(dot_dfd, "script", 1);
+   fail += check_execveat_pathmax(root_dfd, "execveat", 0);
+   fail += check_execveat_pathmax(root_dfd, "script", 1);
return fail;
 }
 
-- 
2.11.0

[PATCH v2] selftests/exec: include cwd in long path calculation

[Steve Muckle]

When creating a pathname close to PATH_MAX to test execveat, factor in
the current working directory path otherwise we end up with an absolute
path that is longer than PATH_MAX. While execveat() may succeed, subsequent
calls to the kernel from the runtime environment which are required to
successfully execute the test binary/script may fail because of this.

To keep the semantics of the test the same, rework the relative pathname
part of the test to be relative to the root directory so it isn't
decreased by the length of the current working directory path.

Signed-off-by: Steve Muckle 
---
Differences from v1:
 - free allocation from getcwd()
 - update comment in check_execveat_pathmax()

 tools/testing/selftests/exec/execveat.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/exec/execveat.c 
b/tools/testing/selftests/exec/execveat.c
index 8d5d1d2ee7c1..67cd4597db2b 100644
--- a/tools/testing/selftests/exec/execveat.c
+++ b/tools/testing/selftests/exec/execveat.c
@@ -147,7 +147,7 @@ static void exe_cp(const char *src, const char *dest)
 }
 
 #define XX_DIR_LEN 200
-static int check_execveat_pathmax(int dot_dfd, const char *src, int is_script)
+static int check_execveat_pathmax(int root_dfd, const char *src, int is_script)
 {
int fail = 0;
int ii, count, len;
@@ -156,20 +156,30 @@ static int check_execveat_pathmax(int dot_dfd, const char 
*src, int is_script)
 
if (*longpath == '\0') {
/* Create a filename close to PATH_MAX in length */
+   char *cwd = getcwd(NULL, 0);
+
+   if (!cwd) {
+   printf("Failed to getcwd(), errno=%d (%s)\n",
+  errno, strerror(errno));
+   return 2;
+   }
+   strcpy(longpath, cwd);
+   strcat(longpath, "/");
memset(longname, 'x', XX_DIR_LEN - 1);
longname[XX_DIR_LEN - 1] = '/';
longname[XX_DIR_LEN] = '\0';
-   count = (PATH_MAX - 3) / XX_DIR_LEN;
+   count = (PATH_MAX - 3 - strlen(cwd)) / XX_DIR_LEN;
for (ii = 0; ii < count; ii++) {
strcat(longpath, longname);
mkdir(longpath, 0755);
}
-   len = (PATH_MAX - 3) - (count * XX_DIR_LEN);
+   len = (PATH_MAX - 3 - strlen(cwd)) - (count * XX_DIR_LEN);
if (len <= 0)
len = 1;
memset(longname, 'y', len);
longname[len] = '\0';
strcat(longpath, longname);
+   free(cwd);
}
exe_cp(src, longpath);
 
@@ -190,7 +200,7 @@ static int check_execveat_pathmax(int dot_dfd, const char 
*src, int is_script)
}
 
/*
-* Execute as a long pathname relative to ".".  If this is a script,
+* Execute as a long pathname relative to "/".  If this is a script,
 * the interpreter will launch but fail to open the script because its
 * name ("/dev/fd/5/xxx") is bigger than PATH_MAX.
 *
@@ -200,10 +210,10 @@ static int check_execveat_pathmax(int dot_dfd, const char 
*src, int is_script)
 * the exit status shall be 126."), so allow either.
 */
if (is_script)
-   fail += check_execveat_invoked_rc(dot_dfd, longpath, 0,
+   fail += check_execveat_invoked_rc(root_dfd, longpath + 1, 0,
  127, 126);
else
-   fail += check_execveat(dot_dfd, longpath, 0);
+   fail += check_execveat(root_dfd, longpath + 1, 0);
 
return fail;
 }
@@ -218,6 +228,7 @@ static int run_tests(void)
int subdir_dfd_ephemeral = open_or_die("subdir.ephemeral",
   O_DIRECTORY|O_RDONLY);
int dot_dfd = open_or_die(".", O_DIRECTORY|O_RDONLY);
+   int root_dfd = open_or_die("/", O_DIRECTORY|O_RDONLY);
int dot_dfd_path = open_or_die(".", O_DIRECTORY|O_RDONLY|O_PATH);
int dot_dfd_cloexec = open_or_die(".", O_DIRECTORY|O_RDONLY|O_CLOEXEC);
int fd = open_or_die("execveat", O_RDONLY);
@@ -353,8 +364,8 @@ static int run_tests(void)
/* Attempt to execute relative to non-directory => ENOTDIR */
fail += check_execveat_fail(fd, "execveat", 0, ENOTDIR);
 
-   fail += check_execveat_pathmax(dot_dfd, "execveat", 0);
-   fail += check_execveat_pathmax(dot_dfd, "script", 1);
+   fail += check_execveat_pathmax(root_dfd, "execveat", 0);
+   fail += check_execveat_pathmax(root_dfd, "script", 1);
return fail;
 }
 
-- 
2.11.0

Re: [PATCH] objtool: Fix memory leak in decode_instructions()

[Kamalesh Babulal]

On Thursday 12 October 2017 09:40 PM, Josh Poimboeuf wrote:

On Thu, Oct 12, 2017 at 02:32:14PM +0530, Kamalesh Babulal wrote:

free the allocated insn before returning, when an error occurs
before adding insn to file->insn_list.

Signed-off-by: Kamalesh Babulal 


Any chance you're working on porting objtool to ppc64le? :-)

Acked-by: Josh Poimboeuf 



Thanks for the review. I have started working on it :)

--
cheers,
Kamalesh.

Re: [PATCH] objtool: Fix memory leak in decode_instructions()

[Kamalesh Babulal]

On Thursday 12 October 2017 09:40 PM, Josh Poimboeuf wrote:

On Thu, Oct 12, 2017 at 02:32:14PM +0530, Kamalesh Babulal wrote:

free the allocated insn before returning, when an error occurs
before adding insn to file->insn_list.

Signed-off-by: Kamalesh Babulal 


Any chance you're working on porting objtool to ppc64le? :-)

Acked-by: Josh Poimboeuf 



Thanks for the review. I have started working on it :)

--
cheers,
Kamalesh.

[PATCH v2] cpufreq: powernv: Fix the frequency read by /proc/cpuinfo

[Shriya]

The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which
returns the last frequency requested by the kernel, but may not
reflect the actual frequency the processor is running at.
This patch makes a call to cpufreq_get() instead which returns the
current frequency reported by the hardware.

Fixes : commit fb5153d05a7d ("powerpc: powernv: Implement
ppc_md.get_proc_freq()")
Cc: sta...@vger.kernel.org

Signed-off-by: Shriya 
---
 arch/powerpc/platforms/powernv/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index cf52d53..58e7ae5 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -312,7 +312,7 @@ static unsigned long pnv_get_proc_freq(unsigned int cpu)
 {
unsigned long ret_freq;
 
-   ret_freq = cpufreq_quick_get(cpu) * 1000ul;
+   ret_freq = cpufreq_get(cpu) * 1000ul;
 
/*
 * If the backend cpufreq driver does not exist,
-- 
1.9.1

[PATCH v2] cpufreq: powernv: Fix the frequency read by /proc/cpuinfo

[Shriya]

The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which
returns the last frequency requested by the kernel, but may not
reflect the actual frequency the processor is running at.
This patch makes a call to cpufreq_get() instead which returns the
current frequency reported by the hardware.

Fixes : commit fb5153d05a7d ("powerpc: powernv: Implement
ppc_md.get_proc_freq()")
Cc: sta...@vger.kernel.org

Signed-off-by: Shriya 
---
 arch/powerpc/platforms/powernv/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index cf52d53..58e7ae5 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -312,7 +312,7 @@ static unsigned long pnv_get_proc_freq(unsigned int cpu)
 {
unsigned long ret_freq;
 
-   ret_freq = cpufreq_quick_get(cpu) * 1000ul;
+   ret_freq = cpufreq_get(cpu) * 1000ul;
 
/*
 * If the backend cpufreq driver does not exist,
-- 
1.9.1

[PATCH] KVM: LAPIC: Level-sensitive interrupts are not support for LINT1

[Wanpeng Li]

From: Wanpeng Li 

SDM 10.5.1 mentioned:
 Software should always set the trigger mode in the LVT LINT1 register to 0 
(edge
 sensitive). Level-sensitive interrupts are not supported from LINT1.

I can intercept both Linux/windows 7/windows 2016 guests on my hand will set 
Level-sensitive trigger mode to LVT LINT1 register during boot.  

This patch avoids the software too fool to set the level-sensitive trigger mode 
to LVT LINT1 register.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index a778f1a..26593c7 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1758,6 +1758,8 @@ int kvm_lapic_reg_write(struct kvm_lapic *apic, u32 reg, 
u32 val)
val |= APIC_LVT_MASKED;
 
val &= apic_lvt_mask[(reg - APIC_LVTT) >> 4];
+   if (reg == APIC_LVT1)
+   val &= ~APIC_LVT_LEVEL_TRIGGER;
kvm_lapic_set_reg(apic, reg, val);
 
break;
-- 
2.7.4

[PATCH] KVM: LAPIC: Level-sensitive interrupts are not support for LINT1

[Wanpeng Li]

From: Wanpeng Li 

SDM 10.5.1 mentioned:
 Software should always set the trigger mode in the LVT LINT1 register to 0 
(edge
 sensitive). Level-sensitive interrupts are not supported from LINT1.

I can intercept both Linux/windows 7/windows 2016 guests on my hand will set 
Level-sensitive trigger mode to LVT LINT1 register during boot.  

This patch avoids the software too fool to set the level-sensitive trigger mode 
to LVT LINT1 register.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/lapic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index a778f1a..26593c7 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1758,6 +1758,8 @@ int kvm_lapic_reg_write(struct kvm_lapic *apic, u32 reg, 
u32 val)
val |= APIC_LVT_MASKED;
 
val &= apic_lvt_mask[(reg - APIC_LVTT) >> 4];
+   if (reg == APIC_LVT1)
+   val &= ~APIC_LVT_LEVEL_TRIGGER;
kvm_lapic_set_reg(apic, reg, val);
 
break;
-- 
2.7.4

Re: [PATCH v2 3/5] mmc: dw_mmc: Add locking to the CTO timer

[Doug Anderson]

Shawn,

On Thu, Oct 12, 2017 at 6:32 PM, Shawn Lin  wrote:
>
> On 2017/10/13 4:11, Douglas Anderson wrote:
>>
>> This attempts to instill a bit of paranoia to the code dealing with
>> the CTO timer.  It's believed that this will make the CTO timer more
>> robust in the case that we're having very long interrupt latencies.
>>
>
> Ack. It could help fix some problems observed.
>
>
>> Note that I originally thought that perhaps this patch was being
>> overly paranoid and wasn't really needed, but then while I was running
>> mmc_test on an rk3399 board I saw one instance of the message:
>>dwmmc_rockchip fe32.dwmmc: Unexpected interrupt latency
>>
>> I had debug prints in the CTO timer code and I found that it was
>> running CMD 13 at the time.
>>
>> ...so even though this patch seems like it might be overly paranoid,
>> maybe it really isn't?
>>
>> Presumably the bad interrupt latency experienced was due to the fact
>> that I had serial console enabled as serial console is typically where
>> I place blame when I see absurdly large interrupt latencies.  In this
>> particular case there was an (unrelated) printout to the serial
>> console just before I saw the "Unexpected interrupt latency" printout.
>>
>> ...and actually, I managed to even reproduce the problems by running
>> "iw mlan0 scan > /dev/null" while mmc_test was running.  That not only
>> does a bunch of PCIe traffic but it also (on my system) outputs some
>> SELinux log spam.
>> > Fixes: 03de19212ea3 ("mmc: dw_mmc: introduce timer for broken command
>
> transfer over scheme")
>>
>> Tested-by: Emil Renner Berthing 
>> Signed-off-by: Douglas Anderson 
>> ---
>>
>> Changes in v2:
>> - Removed extra "int i"
>>
>>   drivers/mmc/host/dw_mmc.c | 91
>> +--
>>   1 file changed, 81 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 16516c528a88..50148991f30e 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -403,6 +403,7 @@ static inline void dw_mci_set_cto(struct dw_mci *host)
>> unsigned int cto_clks;
>> unsigned int cto_div;
>> unsigned int cto_ms;
>> +   unsigned long irqflags;
>> cto_clks = mci_readl(host, TMOUT) & 0xff;
>> cto_div = (mci_readl(host, CLKDIV) & 0xff) * 2;
>> @@ -413,8 +414,24 @@ static inline void dw_mci_set_cto(struct dw_mci
>> *host)
>> /* add a bit spare time */
>> cto_ms += 10;
>>   - mod_timer(>cto_timer,
>> - jiffies + msecs_to_jiffies(cto_ms) + 1);
>> +   /*
>> +* The durations we're working with are fairly short so we have to
>> be
>> +* extra careful about synchronization here.  Specifically in
>> hardware a
>> +* command timeout is _at most_ 5.1 ms, so that means we expect an
>> +* interrupt (either command done or timeout) to come rather
>> quickly
>> +* after the mci_writel.  ...but just in case we have a long
>> interrupt
>> +* latency let's add a bit of paranoia.
>> +*
>> +* In general we'll assume that at least an interrupt will be
>> asserted
>> +* in hardware by the time the cto_timer runs.  ...and if it
>> hasn't
>> +* been asserted in hardware by that time then we'll assume it'll
>> never
>> +* come.
>> +*/
>> +   spin_lock_irqsave(>irq_lock, irqflags);
>> +   if (!test_bit(EVENT_CMD_COMPLETE, >pending_events))
>> +   mod_timer(>cto_timer,
>> +   jiffies + msecs_to_jiffies(cto_ms) + 1);
>> +   spin_unlock_irqrestore(>irq_lock, irqflags);
>
>
> IIUC, this change is beacuse you move
> mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START) before
> setting up the timer, so there is a timing gap that the cmd_done
> already comes and handled by dw_mci_interrupt->dw_mci_cmd_interrupt.
> At this point, we don't need the cto timer at all.

As per below, if I don't move the mci_writel() before setting up the
timer then there's still a race.  ...and actually that race was harder
for me to write code for, but I invite you to try to see if it's
somehow cleaner.


>>   }
>> static void dw_mci_start_command(struct dw_mci *host,
>> @@ -429,11 +446,11 @@ static void dw_mci_start_command(struct dw_mci
>> *host,
>> wmb(); /* drain writebuffer */
>> dw_mci_wait_while_busy(host, cmd_flags);
>>   + mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START);
>> +
>> /* response expected command only */
>> if (cmd_flags & SDMMC_CMD_RESP_EXP)
>> dw_mci_set_cto(host);
>> -
>> -   mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START);
>
>
>
> But why? If we still keep the original logic, it's always correct
> that cmd_done comes after setting up the cto timer. So could you
> eleborate a bit more to help me understand the real intention here?

No matter which order you put 

Re: [PATCH v2 3/5] mmc: dw_mmc: Add locking to the CTO timer

[Doug Anderson]

Shawn,

On Thu, Oct 12, 2017 at 6:32 PM, Shawn Lin  wrote:
>
> On 2017/10/13 4:11, Douglas Anderson wrote:
>>
>> This attempts to instill a bit of paranoia to the code dealing with
>> the CTO timer.  It's believed that this will make the CTO timer more
>> robust in the case that we're having very long interrupt latencies.
>>
>
> Ack. It could help fix some problems observed.
>
>
>> Note that I originally thought that perhaps this patch was being
>> overly paranoid and wasn't really needed, but then while I was running
>> mmc_test on an rk3399 board I saw one instance of the message:
>>dwmmc_rockchip fe32.dwmmc: Unexpected interrupt latency
>>
>> I had debug prints in the CTO timer code and I found that it was
>> running CMD 13 at the time.
>>
>> ...so even though this patch seems like it might be overly paranoid,
>> maybe it really isn't?
>>
>> Presumably the bad interrupt latency experienced was due to the fact
>> that I had serial console enabled as serial console is typically where
>> I place blame when I see absurdly large interrupt latencies.  In this
>> particular case there was an (unrelated) printout to the serial
>> console just before I saw the "Unexpected interrupt latency" printout.
>>
>> ...and actually, I managed to even reproduce the problems by running
>> "iw mlan0 scan > /dev/null" while mmc_test was running.  That not only
>> does a bunch of PCIe traffic but it also (on my system) outputs some
>> SELinux log spam.
>> > Fixes: 03de19212ea3 ("mmc: dw_mmc: introduce timer for broken command
>
> transfer over scheme")
>>
>> Tested-by: Emil Renner Berthing 
>> Signed-off-by: Douglas Anderson 
>> ---
>>
>> Changes in v2:
>> - Removed extra "int i"
>>
>>   drivers/mmc/host/dw_mmc.c | 91
>> +--
>>   1 file changed, 81 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 16516c528a88..50148991f30e 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -403,6 +403,7 @@ static inline void dw_mci_set_cto(struct dw_mci *host)
>> unsigned int cto_clks;
>> unsigned int cto_div;
>> unsigned int cto_ms;
>> +   unsigned long irqflags;
>> cto_clks = mci_readl(host, TMOUT) & 0xff;
>> cto_div = (mci_readl(host, CLKDIV) & 0xff) * 2;
>> @@ -413,8 +414,24 @@ static inline void dw_mci_set_cto(struct dw_mci
>> *host)
>> /* add a bit spare time */
>> cto_ms += 10;
>>   - mod_timer(>cto_timer,
>> - jiffies + msecs_to_jiffies(cto_ms) + 1);
>> +   /*
>> +* The durations we're working with are fairly short so we have to
>> be
>> +* extra careful about synchronization here.  Specifically in
>> hardware a
>> +* command timeout is _at most_ 5.1 ms, so that means we expect an
>> +* interrupt (either command done or timeout) to come rather
>> quickly
>> +* after the mci_writel.  ...but just in case we have a long
>> interrupt
>> +* latency let's add a bit of paranoia.
>> +*
>> +* In general we'll assume that at least an interrupt will be
>> asserted
>> +* in hardware by the time the cto_timer runs.  ...and if it
>> hasn't
>> +* been asserted in hardware by that time then we'll assume it'll
>> never
>> +* come.
>> +*/
>> +   spin_lock_irqsave(>irq_lock, irqflags);
>> +   if (!test_bit(EVENT_CMD_COMPLETE, >pending_events))
>> +   mod_timer(>cto_timer,
>> +   jiffies + msecs_to_jiffies(cto_ms) + 1);
>> +   spin_unlock_irqrestore(>irq_lock, irqflags);
>
>
> IIUC, this change is beacuse you move
> mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START) before
> setting up the timer, so there is a timing gap that the cmd_done
> already comes and handled by dw_mci_interrupt->dw_mci_cmd_interrupt.
> At this point, we don't need the cto timer at all.

As per below, if I don't move the mci_writel() before setting up the
timer then there's still a race.  ...and actually that race was harder
for me to write code for, but I invite you to try to see if it's
somehow cleaner.


>>   }
>> static void dw_mci_start_command(struct dw_mci *host,
>> @@ -429,11 +446,11 @@ static void dw_mci_start_command(struct dw_mci
>> *host,
>> wmb(); /* drain writebuffer */
>> dw_mci_wait_while_busy(host, cmd_flags);
>>   + mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START);
>> +
>> /* response expected command only */
>> if (cmd_flags & SDMMC_CMD_RESP_EXP)
>> dw_mci_set_cto(host);
>> -
>> -   mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START);
>
>
>
> But why? If we still keep the original logic, it's always correct
> that cmd_done comes after setting up the cto timer. So could you
> eleborate a bit more to help me understand the real intention here?

No matter which order you put things, there's a race one way or the
other.  You need a lock.

Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command

[Brijesh Singh]

On 10/12/17 9:24 PM, Brijesh Singh wrote:
>
> On 10/12/17 2:53 PM, Borislav Petkov wrote:
> ...
>
>> Ok, a couple of things here:
>>
>> * Move the checks first and the allocations second so that you allocate
>> memory only after all checks have been passed and you don't allocate
>> pointlessly.
>
> I assume you mean performing the SEV state check before allocating the
> memory for the CSR blob, right ? In my patches, I typically perform all
> the SW specific checks and allocation before invoking the HW routines.
> Handling the PSP commands will take longer compare to kmalloc() or
> access_ok() etc. If its not a big deal then I would prefer to keep that
> way.
>
>
>> * That:
>>
>> if (state == SEV_STATE_WORKING) {
>> ret = -EBUSY;
>> goto e_free_blob;
>> } else if (state == SEV_STATE_UNINIT) {
>> ret = sev_firmware_init(>error);
>> if (ret)
>> goto e_free_blob;
>> do_shutdown = 1;
>> }
>>
>> is a repeating pattern. Perhaps it should be called
>> sev_firmware_reinit() and called by other functions.
>
>> * The rest is simplifications and streamlining.
>>
>> ---
>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>> index e3ee68afd068..d41f5448a25b 100644
>> --- a/drivers/crypto/ccp/psp-dev.c
>> +++ b/drivers/crypto/ccp/psp-dev.c
>> @@ -302,33 +302,30 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd 
>> *argp)
>>  int ret, state;
>>  void *blob;
>>  
>> -if (copy_from_user(, (void __user *)(uintptr_t)argp->data,
>> -   sizeof(struct sev_user_data_pek_csr)))
>> +if (copy_from_user(, (void __user *)argp->data, sizeof(input)))
>> +return -EFAULT;
>> +
>> +if (!input.address)
>> +return -EINVAL;
>> +


As per the spec, its perfectly legal to pass input.address = 0x0 and
input.length = 0x0. If userspace wants to query CSR length then it will
fill all the fields with. In response, FW will return error
(LENGTH_TO_SMALL) and input.length will be filled with the expected
length. Several command work very similar (e.g PEK_CSR,
PEK_CERT_EXPORT). A typical usage from userspace will be:

- query the length of the blob (call command with all fields set to zero)
- SEV FW will response with expected length
- userspace allocate the blob and retries the command. 


>> +/* allocate a physically contiguous buffer to store the CSR blob */
>> +if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
>> +input.length > SEV_FW_BLOB_MAX_SIZE)
>>  return -EFAULT;
>>  
>>  data = kzalloc(sizeof(*data), GFP_KERNEL);
>>  if (!data)
>>  return -ENOMEM;
>>  
>> -/* allocate a temporary physical contigous buffer to store the CSR blob 
>> */
>> -blob = NULL;
>> -if (input.address) {
>> -if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
>> -input.length > SEV_FW_BLOB_MAX_SIZE) {
>> -ret = -EFAULT;
>> -goto e_free;
>> -}
>> -
>> -blob = kmalloc(input.length, GFP_KERNEL);
>> -if (!blob) {
>> -ret = -ENOMEM;
>> -goto e_free;
>> -}
>> -
>> -data->address = __psp_pa(blob);
>> -data->len = input.length;
>> +blob = kmalloc(input.length, GFP_KERNEL);
>> +if (!blob) {
>> +ret = -ENOMEM;
>> +goto e_free;
>>  }
>>  
>> +data->address = __psp_pa(blob);
>> +data->len = input.length;
>> +
>>  ret = sev_platform_get_state(, >error);
>>  if (ret)
>>  goto e_free_blob;
>> @@ -349,25 +346,23 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd 
>> *argp)
>>  do_shutdown = 1;
>>  }
>>  
>> -ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, >error);
>> +ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, >error);
>>  
>>  input.length = data->len;
>>  
>>  /* copy blob to userspace */
>> -if (blob &&
>> -copy_to_user((void __user *)(uintptr_t)input.address,
>> -blob, input.length)) {
>> +if (copy_to_user((void __user *)input.address, blob, input.length)) {
>>  ret = -EFAULT;
>>  goto e_shutdown;
>>  }
>>  
>> -if (copy_to_user((void __user *)(uintptr_t)argp->data, ,
>> - sizeof(struct sev_user_data_pek_csr)))
>> +if (copy_to_user((void __user *)argp->data, , sizeof(input)))
>>  ret = -EFAULT;
>>  
>>  e_shutdown:
>>  if (do_shutdown)
>> -sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>> +ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>> +
>>  e_free_blob:
>>  kfree(blob);
>>  e_free:
>> @@ -408,10 +403,10 @@ static long sev_ioctl(struct file *file, unsigned int 
>> ioctl, unsigned long arg)
>>  ret = sev_ioctl_pdh_gen();
>>  break;
>>  
>> -case SEV_PEK_CSR: {
>> 

Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command

[Brijesh Singh]

On 10/12/17 9:24 PM, Brijesh Singh wrote:
>
> On 10/12/17 2:53 PM, Borislav Petkov wrote:
> ...
>
>> Ok, a couple of things here:
>>
>> * Move the checks first and the allocations second so that you allocate
>> memory only after all checks have been passed and you don't allocate
>> pointlessly.
>
> I assume you mean performing the SEV state check before allocating the
> memory for the CSR blob, right ? In my patches, I typically perform all
> the SW specific checks and allocation before invoking the HW routines.
> Handling the PSP commands will take longer compare to kmalloc() or
> access_ok() etc. If its not a big deal then I would prefer to keep that
> way.
>
>
>> * That:
>>
>> if (state == SEV_STATE_WORKING) {
>> ret = -EBUSY;
>> goto e_free_blob;
>> } else if (state == SEV_STATE_UNINIT) {
>> ret = sev_firmware_init(>error);
>> if (ret)
>> goto e_free_blob;
>> do_shutdown = 1;
>> }
>>
>> is a repeating pattern. Perhaps it should be called
>> sev_firmware_reinit() and called by other functions.
>
>> * The rest is simplifications and streamlining.
>>
>> ---
>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>> index e3ee68afd068..d41f5448a25b 100644
>> --- a/drivers/crypto/ccp/psp-dev.c
>> +++ b/drivers/crypto/ccp/psp-dev.c
>> @@ -302,33 +302,30 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd 
>> *argp)
>>  int ret, state;
>>  void *blob;
>>  
>> -if (copy_from_user(, (void __user *)(uintptr_t)argp->data,
>> -   sizeof(struct sev_user_data_pek_csr)))
>> +if (copy_from_user(, (void __user *)argp->data, sizeof(input)))
>> +return -EFAULT;
>> +
>> +if (!input.address)
>> +return -EINVAL;
>> +


As per the spec, its perfectly legal to pass input.address = 0x0 and
input.length = 0x0. If userspace wants to query CSR length then it will
fill all the fields with. In response, FW will return error
(LENGTH_TO_SMALL) and input.length will be filled with the expected
length. Several command work very similar (e.g PEK_CSR,
PEK_CERT_EXPORT). A typical usage from userspace will be:

- query the length of the blob (call command with all fields set to zero)
- SEV FW will response with expected length
- userspace allocate the blob and retries the command. 


>> +/* allocate a physically contiguous buffer to store the CSR blob */
>> +if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
>> +input.length > SEV_FW_BLOB_MAX_SIZE)
>>  return -EFAULT;
>>  
>>  data = kzalloc(sizeof(*data), GFP_KERNEL);
>>  if (!data)
>>  return -ENOMEM;
>>  
>> -/* allocate a temporary physical contigous buffer to store the CSR blob 
>> */
>> -blob = NULL;
>> -if (input.address) {
>> -if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
>> -input.length > SEV_FW_BLOB_MAX_SIZE) {
>> -ret = -EFAULT;
>> -goto e_free;
>> -}
>> -
>> -blob = kmalloc(input.length, GFP_KERNEL);
>> -if (!blob) {
>> -ret = -ENOMEM;
>> -goto e_free;
>> -}
>> -
>> -data->address = __psp_pa(blob);
>> -data->len = input.length;
>> +blob = kmalloc(input.length, GFP_KERNEL);
>> +if (!blob) {
>> +ret = -ENOMEM;
>> +goto e_free;
>>  }
>>  
>> +data->address = __psp_pa(blob);
>> +data->len = input.length;
>> +
>>  ret = sev_platform_get_state(, >error);
>>  if (ret)
>>  goto e_free_blob;
>> @@ -349,25 +346,23 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd 
>> *argp)
>>  do_shutdown = 1;
>>  }
>>  
>> -ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, >error);
>> +ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, >error);
>>  
>>  input.length = data->len;
>>  
>>  /* copy blob to userspace */
>> -if (blob &&
>> -copy_to_user((void __user *)(uintptr_t)input.address,
>> -blob, input.length)) {
>> +if (copy_to_user((void __user *)input.address, blob, input.length)) {
>>  ret = -EFAULT;
>>  goto e_shutdown;
>>  }
>>  
>> -if (copy_to_user((void __user *)(uintptr_t)argp->data, ,
>> - sizeof(struct sev_user_data_pek_csr)))
>> +if (copy_to_user((void __user *)argp->data, , sizeof(input)))
>>  ret = -EFAULT;
>>  
>>  e_shutdown:
>>  if (do_shutdown)
>> -sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>> +ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
>> +
>>  e_free_blob:
>>  kfree(blob);
>>  e_free:
>> @@ -408,10 +403,10 @@ static long sev_ioctl(struct file *file, unsigned int 
>> ioctl, unsigned long arg)
>>  ret = sev_ioctl_pdh_gen();
>>  break;
>>  
>> -case SEV_PEK_CSR: {
>> 

[PATCH v3] net: ftgmac100: Request clock and set speed

[Joel Stanley]

According to the ASPEED datasheet, gigabit speeds require a clock of
100MHz or higher. Other speeds require 25MHz or higher. This patch
configures a 100MHz clock if the system has a direct-attached
PHY, or 25MHz if the system is running NC-SI which is limited to 100MHz.

There appear to be no other upstream users of the FTGMAC100 driver it is
hard to know the clocking requirements of other platforms. Therefore a
conservative approach was taken with enabling clocks. If the platform is
not ASPEED, both requesting the clock and configuring the speed is
skipped.

Signed-off-by: Joel Stanley 
---
Andrew, can you please give this one a spin on hardware?

v3:
 - Fix errors from v2
v2:
 - only touch the clocks on Aspeed platforms
 - unconditionally call clk_unprepare_disable

 drivers/net/ethernet/faraday/ftgmac100.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/ethernet/faraday/ftgmac100.c 
b/drivers/net/ethernet/faraday/ftgmac100.c
index 9ed8e4b81530..78db8e62a83f 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -21,6 +21,7 @@
 
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -59,6 +60,9 @@
 /* Min number of tx ring entries before stopping queue */
 #define TX_THRESHOLD   (MAX_SKB_FRAGS + 1)
 
+#define FTGMAC_100MHZ  1
+#define FTGMAC_25MHZ   2500
+
 struct ftgmac100 {
/* Registers */
struct resource *res;
@@ -96,6 +100,7 @@ struct ftgmac100 {
struct napi_struct napi;
struct work_struct reset_task;
struct mii_bus *mii_bus;
+   struct clk *clk;
 
/* Link management */
int cur_speed;
@@ -1734,6 +1739,22 @@ static void ftgmac100_ncsi_handler(struct ncsi_dev *nd)
nd->link_up ? "up" : "down");
 }
 
+static void ftgmac100_setup_clk(struct ftgmac100 *priv)
+{
+   priv->clk = devm_clk_get(priv->dev, NULL);
+   if (IS_ERR(priv->clk))
+   return;
+
+   clk_prepare_enable(priv->clk);
+
+   /* Aspeed specifies a 100MHz clock is required for up to
+* 1000Mbit link speeds. As NCSI is limited to 100Mbit, 25MHz
+* is sufficient
+*/
+   clk_set_rate(priv->clk, priv->use_ncsi ? FTGMAC_25MHZ :
+   FTGMAC_100MHZ);
+}
+
 static int ftgmac100_probe(struct platform_device *pdev)
 {
struct resource *res;
@@ -1830,6 +1851,9 @@ static int ftgmac100_probe(struct platform_device *pdev)
goto err_setup_mdio;
}
 
+   if (priv->is_aspeed)
+   ftgmac100_setup_clk(priv);
+
/* Default ring sizes */
priv->rx_q_entries = priv->new_rx_q_entries = DEF_RX_QUEUE_ENTRIES;
priv->tx_q_entries = priv->new_tx_q_entries = DEF_TX_QUEUE_ENTRIES;
@@ -1883,6 +1907,8 @@ static int ftgmac100_remove(struct platform_device *pdev)
 
unregister_netdev(netdev);
 
+   clk_disable_unprepare(priv->clk);
+
/* There's a small chance the reset task will have been re-queued,
 * during stop, make sure it's gone before we free the structure.
 */
-- 
2.14.1

[PATCH v3] net: ftgmac100: Request clock and set speed

[Joel Stanley]

According to the ASPEED datasheet, gigabit speeds require a clock of
100MHz or higher. Other speeds require 25MHz or higher. This patch
configures a 100MHz clock if the system has a direct-attached
PHY, or 25MHz if the system is running NC-SI which is limited to 100MHz.

There appear to be no other upstream users of the FTGMAC100 driver it is
hard to know the clocking requirements of other platforms. Therefore a
conservative approach was taken with enabling clocks. If the platform is
not ASPEED, both requesting the clock and configuring the speed is
skipped.

Signed-off-by: Joel Stanley 
---
Andrew, can you please give this one a spin on hardware?

v3:
 - Fix errors from v2
v2:
 - only touch the clocks on Aspeed platforms
 - unconditionally call clk_unprepare_disable

 drivers/net/ethernet/faraday/ftgmac100.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/ethernet/faraday/ftgmac100.c 
b/drivers/net/ethernet/faraday/ftgmac100.c
index 9ed8e4b81530..78db8e62a83f 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -21,6 +21,7 @@
 
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -59,6 +60,9 @@
 /* Min number of tx ring entries before stopping queue */
 #define TX_THRESHOLD   (MAX_SKB_FRAGS + 1)
 
+#define FTGMAC_100MHZ  1
+#define FTGMAC_25MHZ   2500
+
 struct ftgmac100 {
/* Registers */
struct resource *res;
@@ -96,6 +100,7 @@ struct ftgmac100 {
struct napi_struct napi;
struct work_struct reset_task;
struct mii_bus *mii_bus;
+   struct clk *clk;
 
/* Link management */
int cur_speed;
@@ -1734,6 +1739,22 @@ static void ftgmac100_ncsi_handler(struct ncsi_dev *nd)
nd->link_up ? "up" : "down");
 }
 
+static void ftgmac100_setup_clk(struct ftgmac100 *priv)
+{
+   priv->clk = devm_clk_get(priv->dev, NULL);
+   if (IS_ERR(priv->clk))
+   return;
+
+   clk_prepare_enable(priv->clk);
+
+   /* Aspeed specifies a 100MHz clock is required for up to
+* 1000Mbit link speeds. As NCSI is limited to 100Mbit, 25MHz
+* is sufficient
+*/
+   clk_set_rate(priv->clk, priv->use_ncsi ? FTGMAC_25MHZ :
+   FTGMAC_100MHZ);
+}
+
 static int ftgmac100_probe(struct platform_device *pdev)
 {
struct resource *res;
@@ -1830,6 +1851,9 @@ static int ftgmac100_probe(struct platform_device *pdev)
goto err_setup_mdio;
}
 
+   if (priv->is_aspeed)
+   ftgmac100_setup_clk(priv);
+
/* Default ring sizes */
priv->rx_q_entries = priv->new_rx_q_entries = DEF_RX_QUEUE_ENTRIES;
priv->tx_q_entries = priv->new_tx_q_entries = DEF_TX_QUEUE_ENTRIES;
@@ -1883,6 +1907,8 @@ static int ftgmac100_remove(struct platform_device *pdev)
 
unregister_netdev(netdev);
 
+   clk_disable_unprepare(priv->clk);
+
/* There's a small chance the reset task will have been re-queued,
 * during stop, make sure it's gone before we free the structure.
 */
-- 
2.14.1

Re: [PATCH V5] clk: qcom: Add spmi_pmic clock divider support

[Tirupathi Reddy T]

Hi Stephen,

Could you please pick the patch ?  All the comments given on older patch 
sets were addressed and the patch is Acked-by Rob Herring.


Thanks
Tirupathi

On 9/19/2017 4:04 PM, Tirupathi Reddy wrote:

Clkdiv module provides a clock output on the PMIC with CXO as
the source. This clock can be routed through PMIC GPIOs. Add
a device driver to configure this clkdiv module.

Signed-off-by: Tirupathi Reddy 
---
  .../bindings/clock/clk-spmi-pmic-div.txt   |  56 
  drivers/clk/qcom/Kconfig   |   9 +
  drivers/clk/qcom/Makefile  |   1 +
  drivers/clk/qcom/clk-spmi-pmic-div.c   | 343 +
  4 files changed, 409 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt
  create mode 100644 drivers/clk/qcom/clk-spmi-pmic-div.c

diff --git a/Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt 
b/Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt
new file mode 100644
index 000..e37a136
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt
@@ -0,0 +1,56 @@
+Qualcomm Technologies, Inc. SPMI PMIC clock divider (clkdiv)
+
+clkdiv configures the clock frequency of a set of outputs on the PMIC.
+These clocks are typically wired through alternate functions on
+gpio pins.
+
+===
+Properties
+===
+
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: must be one of:
+   "qcom,spmi-clkdiv"
+   "qcom,pm8998-clkdiv"
+
+- reg
+   Usage:  required
+   Value type: 
+   Definition: Addresses and sizes for the memory of this CLKDIV
+   peripheral.
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: reference to the xo clock.
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: must be "xo".
+
+- clock-cells:
+   Usage: required
+   Value type: 
+   Definition: shall contain 1.
+
+===
+Example
+===
+
+pm8998_clk_divs: qcom,clock@5b00 {
+   compatible = "qcom,pm8998-clkdiv";
+   reg = <0x5b00>;
+   #clock-cells = <1>;
+   clocks = <_board>;
+   clock-names = "xo";
+
+   assigned-clocks = <_clk_divs 1>,
+ <_clk_divs 2>,
+ <_clk_divs 3>;
+   assigned-clock-rates = <960>,
+  <960>,
+  <960>;
+};
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 9f6c278..dd5b18e 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -196,3 +196,12 @@ config MSM_MMCC_8996
  Support for the multimedia clock controller on msm8996 devices.
  Say Y if you want to support multimedia devices such as display,
  graphics, video encode/decode, camera, etc.
+
+config SPMI_PMIC_CLKDIV
+   tristate "spmi pmic clkdiv driver"
+   depends on (COMMON_CLK_QCOM && SPMI) || COMPILE_TEST
+   help
+ This driver supports the clkdiv functionality on the Qualcomm
+ Technologies, Inc. SPMI PMIC. It configures the frequency of
+ clkdiv outputs on the PMIC. These clocks are typically wired
+ through alternate functions on gpio pins.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 3f3aff2..4d4c62b 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
  obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
  obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
  obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
+obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/clk-spmi-pmic-div.c 
b/drivers/clk/qcom/clk-spmi-pmic-div.c
new file mode 100644
index 000..af343ad
--- /dev/null
+++ b/drivers/clk/qcom/clk-spmi-pmic-div.c
@@ -0,0 +1,343 @@
+/* Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_DIV_CTL1   0x43
+#define DIV_CTL1_DIV_FACTOR_MASK   GENMASK(2, 0)
+
+#define REG_EN_CTL 0x46
+#define REG_EN_MASKBIT(7)
+
+#define ENABLE_DELAY_NS(cxo_ns, div)   ((2 + 3 * div) * cxo_ns)
+#define DISABLE_DELAY_NS(cxo_ns, div)  ((3 * div) 

Re: [PATCH V5] clk: qcom: Add spmi_pmic clock divider support

[Tirupathi Reddy T]

Hi Stephen,

Could you please pick the patch ?  All the comments given on older patch 
sets were addressed and the patch is Acked-by Rob Herring.


Thanks
Tirupathi

On 9/19/2017 4:04 PM, Tirupathi Reddy wrote:

Clkdiv module provides a clock output on the PMIC with CXO as
the source. This clock can be routed through PMIC GPIOs. Add
a device driver to configure this clkdiv module.

Signed-off-by: Tirupathi Reddy 
---
  .../bindings/clock/clk-spmi-pmic-div.txt   |  56 
  drivers/clk/qcom/Kconfig   |   9 +
  drivers/clk/qcom/Makefile  |   1 +
  drivers/clk/qcom/clk-spmi-pmic-div.c   | 343 +
  4 files changed, 409 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt
  create mode 100644 drivers/clk/qcom/clk-spmi-pmic-div.c

diff --git a/Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt 
b/Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt
new file mode 100644
index 000..e37a136
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt
@@ -0,0 +1,56 @@
+Qualcomm Technologies, Inc. SPMI PMIC clock divider (clkdiv)
+
+clkdiv configures the clock frequency of a set of outputs on the PMIC.
+These clocks are typically wired through alternate functions on
+gpio pins.
+
+===
+Properties
+===
+
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: must be one of:
+   "qcom,spmi-clkdiv"
+   "qcom,pm8998-clkdiv"
+
+- reg
+   Usage:  required
+   Value type: 
+   Definition: Addresses and sizes for the memory of this CLKDIV
+   peripheral.
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: reference to the xo clock.
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: must be "xo".
+
+- clock-cells:
+   Usage: required
+   Value type: 
+   Definition: shall contain 1.
+
+===
+Example
+===
+
+pm8998_clk_divs: qcom,clock@5b00 {
+   compatible = "qcom,pm8998-clkdiv";
+   reg = <0x5b00>;
+   #clock-cells = <1>;
+   clocks = <_board>;
+   clock-names = "xo";
+
+   assigned-clocks = <_clk_divs 1>,
+ <_clk_divs 2>,
+ <_clk_divs 3>;
+   assigned-clock-rates = <960>,
+  <960>,
+  <960>;
+};
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 9f6c278..dd5b18e 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -196,3 +196,12 @@ config MSM_MMCC_8996
  Support for the multimedia clock controller on msm8996 devices.
  Say Y if you want to support multimedia devices such as display,
  graphics, video encode/decode, camera, etc.
+
+config SPMI_PMIC_CLKDIV
+   tristate "spmi pmic clkdiv driver"
+   depends on (COMMON_CLK_QCOM && SPMI) || COMPILE_TEST
+   help
+ This driver supports the clkdiv functionality on the Qualcomm
+ Technologies, Inc. SPMI PMIC. It configures the frequency of
+ clkdiv outputs on the PMIC. These clocks are typically wired
+ through alternate functions on gpio pins.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 3f3aff2..4d4c62b 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
  obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
  obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
  obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
+obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/clk-spmi-pmic-div.c 
b/drivers/clk/qcom/clk-spmi-pmic-div.c
new file mode 100644
index 000..af343ad
--- /dev/null
+++ b/drivers/clk/qcom/clk-spmi-pmic-div.c
@@ -0,0 +1,343 @@
+/* Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_DIV_CTL1   0x43
+#define DIV_CTL1_DIV_FACTOR_MASK   GENMASK(2, 0)
+
+#define REG_EN_CTL 0x46
+#define REG_EN_MASKBIT(7)
+
+#define ENABLE_DELAY_NS(cxo_ns, div)   ((2 + 3 * div) * cxo_ns)
+#define DISABLE_DELAY_NS(cxo_ns, div)  ((3 * div) * cxo_ns)
+
+#define 

Re: [PATCH, RFC] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

[Kirill A. Shutemov]

On Thu, Oct 12, 2017 at 06:07:36PM -0500, Eric W. Biederman wrote:
> "Kirill A. Shutemov"  writes:
> 
> > On Mon, Oct 09, 2017 at 09:54:53AM -0700, Dave Hansen wrote:
> >> On 10/09/2017 09:09 AM, Kirill A. Shutemov wrote:
> >> > Apart from trampoline itself we also need place to store top level page
> >> > table in lower memory as we don't have a way to load 64-bit value into
> >> > CR3 from 32-bit mode. We only really need 8-bytes there as we only use
> >> > the very first entry of the page table.
> >> 
> >> Oh, and this is why you have to move "lvl5_pgtable" out of the kernel 
> >> image?
> >
> > Right. I initialize the new location of top level page table directly.
> 
> So just a quick note.  I have a fuzzy memory of people loading their
> kernels above 4G physical because they did not have any memory below
> 4G.
> 
> That might be a very specialized case if my memory is correct because
> cpu startup has to have a trampoline below 1MB.  So I don't know how
> that works.  But I do seem to remember someone mentioning it.
> 
> Is there really no way to switch to 5 level paging other than to drop to
> 32bit mode and disable paging?The x86 architecture does some very
> bizarre things so I can believe it but that seems like a lot of work to
> get somewhere.

The spec[1] is pretty clear on this, see section 2.2.2:

The processor allows software to modify CR4.LA57 only outside of
IA-32e mode. In IA-32e mode, an attempt to modify CR4.LA57 using
the MOV CR instruction causes a general-protection exception
(#GP).

[1] 
https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf

-- 
 Kirill A. Shutemov

Re: [PATCH, RFC] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

[Kirill A. Shutemov]

On Thu, Oct 12, 2017 at 06:07:36PM -0500, Eric W. Biederman wrote:
> "Kirill A. Shutemov"  writes:
> 
> > On Mon, Oct 09, 2017 at 09:54:53AM -0700, Dave Hansen wrote:
> >> On 10/09/2017 09:09 AM, Kirill A. Shutemov wrote:
> >> > Apart from trampoline itself we also need place to store top level page
> >> > table in lower memory as we don't have a way to load 64-bit value into
> >> > CR3 from 32-bit mode. We only really need 8-bytes there as we only use
> >> > the very first entry of the page table.
> >> 
> >> Oh, and this is why you have to move "lvl5_pgtable" out of the kernel 
> >> image?
> >
> > Right. I initialize the new location of top level page table directly.
> 
> So just a quick note.  I have a fuzzy memory of people loading their
> kernels above 4G physical because they did not have any memory below
> 4G.
> 
> That might be a very specialized case if my memory is correct because
> cpu startup has to have a trampoline below 1MB.  So I don't know how
> that works.  But I do seem to remember someone mentioning it.
> 
> Is there really no way to switch to 5 level paging other than to drop to
> 32bit mode and disable paging?The x86 architecture does some very
> bizarre things so I can believe it but that seems like a lot of work to
> get somewhere.

The spec[1] is pretty clear on this, see section 2.2.2:

The processor allows software to modify CR4.LA57 only outside of
IA-32e mode. In IA-32e mode, an attempt to modify CR4.LA57 using
the MOV CR instruction causes a general-protection exception
(#GP).

[1] 
https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf

-- 
 Kirill A. Shutemov

Re: [PATCH] cpufreq: speedstep-lib: mark expected switch fall-through

[Viresh Kumar]

On 12-10-17, 17:41, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/cpufreq/speedstep-lib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/speedstep-lib.c b/drivers/cpufreq/speedstep-lib.c
> index ccab452..8085ec9 100644
> --- a/drivers/cpufreq/speedstep-lib.c
> +++ b/drivers/cpufreq/speedstep-lib.c
> @@ -367,7 +367,7 @@ unsigned int speedstep_detect_processor(void)
>   } else
>   return SPEEDSTEP_CPU_PIII_C;
>   }
> -
> + /* fall through */
>   default:
>   return 0;
>   }

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: speedstep-lib: mark expected switch fall-through

[Viresh Kumar]

On 12-10-17, 17:41, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/cpufreq/speedstep-lib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/speedstep-lib.c b/drivers/cpufreq/speedstep-lib.c
> index ccab452..8085ec9 100644
> --- a/drivers/cpufreq/speedstep-lib.c
> +++ b/drivers/cpufreq/speedstep-lib.c
> @@ -367,7 +367,7 @@ unsigned int speedstep_detect_processor(void)
>   } else
>   return SPEEDSTEP_CPU_PIII_C;
>   }
> -
> + /* fall through */
>   default:
>   return 0;
>   }

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH v2 1/2] block: Treat all read ops as synchronous

[Jeffy Chen]

The comment for op_is_sync() says "Reads are always treated as
synchronous", but it only checks for REQ_OP_READ.

Use op_is_write() to detect read ops and treat them as synchronous.

Fixes: aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space")
Signed-off-by: Jeffy Chen 
---

Changes in v2:
Rewrite commit message.

 include/linux/blk_types.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 3385c89f402e..b6a71c2eec36 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -288,8 +288,7 @@ static inline bool op_is_flush(unsigned int op)
  */
 static inline bool op_is_sync(unsigned int op)
 {
-   return (op & REQ_OP_MASK) == REQ_OP_READ ||
-   (op & (REQ_SYNC | REQ_FUA | REQ_PREFLUSH));
+   return !op_is_write(op) || (op & (REQ_SYNC | REQ_FUA | REQ_PREFLUSH));
 }
 
 typedef unsigned int blk_qc_t;
-- 
2.11.0

[PATCH v2 2/2] block/cfq: Fix memory leak without CFQ_GROUP_IOSCHED

[Jeffy Chen]

Currently we only unref the async cfqqs in cfq_pd_offline, which would
never be called without CONFIG_CFQ_GROUP_IOSCHED enabled.

Kmemleak reported:
unreferenced object 0xffc0cd9fc000 (size 240):
  comm "kworker/3:1", pid 52, jiffies 4294673527 (age 97.149s)
  hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 80 55 13 cf c0 ff ff ff  .U..
10 c0 9f cd c0 ff ff ff 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x58/0x8c
[] kmem_cache_alloc+0x184/0x268
[] cfq_get_queue.isra.11+0x144/0x2e0
[] cfq_set_request+0x1bc/0x444
[] elv_set_request+0x88/0x9c
[] get_request+0x494/0x914
[] blk_get_request+0xdc/0x160
[] scsi_execute+0x70/0x23c
[] scsi_test_unit_ready+0xf4/0x1ec

Fixes: 60a837077e2b ("cfq-iosched: charge async IOs to the appropriate blkcg's 
instead of the root")
Signed-off-by: Jeffy Chen 
---

Changes in v2:
Rewrite commit message and rename api.

 block/cfq-iosched.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 9f342ef1ad42..d182e81a07af 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -401,6 +401,7 @@ struct cfq_data {
 
 static struct cfq_group *cfq_get_next_cfqg(struct cfq_data *cfqd);
 static void cfq_put_queue(struct cfq_queue *cfqq);
+static void cfq_put_async_queues(struct cfq_group *cfqg);
 
 static struct cfq_rb_root *st_for(struct cfq_group *cfqg,
enum wl_class_t class,
@@ -1638,17 +1639,8 @@ static void cfq_pd_init(struct blkg_policy_data *pd)
 static void cfq_pd_offline(struct blkg_policy_data *pd)
 {
struct cfq_group *cfqg = pd_to_cfqg(pd);
-   int i;
-
-   for (i = 0; i < IOPRIO_BE_NR; i++) {
-   if (cfqg->async_cfqq[0][i])
-   cfq_put_queue(cfqg->async_cfqq[0][i]);
-   if (cfqg->async_cfqq[1][i])
-   cfq_put_queue(cfqg->async_cfqq[1][i]);
-   }
 
-   if (cfqg->async_idle_cfqq)
-   cfq_put_queue(cfqg->async_idle_cfqq);
+   cfq_put_async_queues(cfqg);
 
/*
 * @blkg is going offline and will be ignored by
@@ -3741,6 +3733,21 @@ static void cfq_init_cfqq(struct cfq_data *cfqd, struct 
cfq_queue *cfqq,
cfqq->pid = pid;
 }
 
+static void cfq_put_async_queues(struct cfq_group *cfqg)
+{
+   int i;
+
+   for (i = 0; i < IOPRIO_BE_NR; i++) {
+   if (cfqg->async_cfqq[0][i])
+   cfq_put_queue(cfqg->async_cfqq[0][i]);
+   if (cfqg->async_cfqq[1][i])
+   cfq_put_queue(cfqg->async_cfqq[1][i]);
+   }
+
+   if (cfqg->async_idle_cfqq)
+   cfq_put_queue(cfqg->async_idle_cfqq);
+}
+
 #ifdef CONFIG_CFQ_GROUP_IOSCHED
 static void check_blkcg_changed(struct cfq_io_cq *cic, struct bio *bio)
 {
@@ -4564,6 +4571,7 @@ static void cfq_exit_queue(struct elevator_queue *e)
 #ifdef CONFIG_CFQ_GROUP_IOSCHED
blkcg_deactivate_policy(q, _policy_cfq);
 #else
+   cfq_put_async_queues(cfqd->root_group);
kfree(cfqd->root_group);
 #endif
kfree(cfqd);
-- 
2.11.0

[PATCH v2 1/2] block: Treat all read ops as synchronous

[Jeffy Chen]

The comment for op_is_sync() says "Reads are always treated as
synchronous", but it only checks for REQ_OP_READ.

Use op_is_write() to detect read ops and treat them as synchronous.

Fixes: aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space")
Signed-off-by: Jeffy Chen 
---

Changes in v2:
Rewrite commit message.

 include/linux/blk_types.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 3385c89f402e..b6a71c2eec36 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -288,8 +288,7 @@ static inline bool op_is_flush(unsigned int op)
  */
 static inline bool op_is_sync(unsigned int op)
 {
-   return (op & REQ_OP_MASK) == REQ_OP_READ ||
-   (op & (REQ_SYNC | REQ_FUA | REQ_PREFLUSH));
+   return !op_is_write(op) || (op & (REQ_SYNC | REQ_FUA | REQ_PREFLUSH));
 }
 
 typedef unsigned int blk_qc_t;
-- 
2.11.0

[PATCH v2 2/2] block/cfq: Fix memory leak without CFQ_GROUP_IOSCHED

[Jeffy Chen]

Currently we only unref the async cfqqs in cfq_pd_offline, which would
never be called without CONFIG_CFQ_GROUP_IOSCHED enabled.

Kmemleak reported:
unreferenced object 0xffc0cd9fc000 (size 240):
  comm "kworker/3:1", pid 52, jiffies 4294673527 (age 97.149s)
  hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 80 55 13 cf c0 ff ff ff  .U..
10 c0 9f cd c0 ff ff ff 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x58/0x8c
[] kmem_cache_alloc+0x184/0x268
[] cfq_get_queue.isra.11+0x144/0x2e0
[] cfq_set_request+0x1bc/0x444
[] elv_set_request+0x88/0x9c
[] get_request+0x494/0x914
[] blk_get_request+0xdc/0x160
[] scsi_execute+0x70/0x23c
[] scsi_test_unit_ready+0xf4/0x1ec

Fixes: 60a837077e2b ("cfq-iosched: charge async IOs to the appropriate blkcg's 
instead of the root")
Signed-off-by: Jeffy Chen 
---

Changes in v2:
Rewrite commit message and rename api.

 block/cfq-iosched.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 9f342ef1ad42..d182e81a07af 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -401,6 +401,7 @@ struct cfq_data {
 
 static struct cfq_group *cfq_get_next_cfqg(struct cfq_data *cfqd);
 static void cfq_put_queue(struct cfq_queue *cfqq);
+static void cfq_put_async_queues(struct cfq_group *cfqg);
 
 static struct cfq_rb_root *st_for(struct cfq_group *cfqg,
enum wl_class_t class,
@@ -1638,17 +1639,8 @@ static void cfq_pd_init(struct blkg_policy_data *pd)
 static void cfq_pd_offline(struct blkg_policy_data *pd)
 {
struct cfq_group *cfqg = pd_to_cfqg(pd);
-   int i;
-
-   for (i = 0; i < IOPRIO_BE_NR; i++) {
-   if (cfqg->async_cfqq[0][i])
-   cfq_put_queue(cfqg->async_cfqq[0][i]);
-   if (cfqg->async_cfqq[1][i])
-   cfq_put_queue(cfqg->async_cfqq[1][i]);
-   }
 
-   if (cfqg->async_idle_cfqq)
-   cfq_put_queue(cfqg->async_idle_cfqq);
+   cfq_put_async_queues(cfqg);
 
/*
 * @blkg is going offline and will be ignored by
@@ -3741,6 +3733,21 @@ static void cfq_init_cfqq(struct cfq_data *cfqd, struct 
cfq_queue *cfqq,
cfqq->pid = pid;
 }
 
+static void cfq_put_async_queues(struct cfq_group *cfqg)
+{
+   int i;
+
+   for (i = 0; i < IOPRIO_BE_NR; i++) {
+   if (cfqg->async_cfqq[0][i])
+   cfq_put_queue(cfqg->async_cfqq[0][i]);
+   if (cfqg->async_cfqq[1][i])
+   cfq_put_queue(cfqg->async_cfqq[1][i]);
+   }
+
+   if (cfqg->async_idle_cfqq)
+   cfq_put_queue(cfqg->async_idle_cfqq);
+}
+
 #ifdef CONFIG_CFQ_GROUP_IOSCHED
 static void check_blkcg_changed(struct cfq_io_cq *cic, struct bio *bio)
 {
@@ -4564,6 +4571,7 @@ static void cfq_exit_queue(struct elevator_queue *e)
 #ifdef CONFIG_CFQ_GROUP_IOSCHED
blkcg_deactivate_policy(q, _policy_cfq);
 #else
+   cfq_put_async_queues(cfqd->root_group);
kfree(cfqd->root_group);
 #endif
kfree(cfqd);
-- 
2.11.0

Re: [PATCH] PCI: dwc: designware: don't sleep in atomic context

[Pankaj Dubey]

On 10/12/2017 04:09 PM, David Laight wrote:

From: Pankaj Dubey

Sent: 12 October 2017 08:55
In pcie-designware.c many places we are calling "usleep_range" which
are in atomic context. This patch fixes these potential BUGs and
replaces "usleep_range" with mdelay calls.

Signed-off-by: Pankaj Dubey 
---
  drivers/pci/dwc/pcie-designware.c | 8 
  drivers/pci/dwc/pcie-designware.h | 3 +--
  2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..35d19b9 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -138,7 +138,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;

-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}

Spinning for 9ms (possibly 10 times) isn't really a good idea.


Yes. It may not be a good idea, however in our experiment it never hit 
maximum retry count.
I just converted usleep_range to mdelay keeping min time limitation as 
it is, though I
am not sure, how do we arrived on these numbers in original code, may be 
Joao Pinto
from Synopsys have some idea, I will try to do few experiment and try to 
find out what

is sufficient minimum time in our hardware for these mdelay.

Thanks,
Pankaj Dubey

David

Re: [PATCH] PCI: dwc: designware: don't sleep in atomic context

[Pankaj Dubey]

On 10/12/2017 04:09 PM, David Laight wrote:

From: Pankaj Dubey

Sent: 12 October 2017 08:55
In pcie-designware.c many places we are calling "usleep_range" which
are in atomic context. This patch fixes these potential BUGs and
replaces "usleep_range" with mdelay calls.

Signed-off-by: Pankaj Dubey 
---
  drivers/pci/dwc/pcie-designware.c | 8 
  drivers/pci/dwc/pcie-designware.h | 3 +--
  2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 88abddd..35d19b9 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -138,7 +138,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;

-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   mdelay(LINK_WAIT_IATU_MIN);
}

Spinning for 9ms (possibly 10 times) isn't really a good idea.


Yes. It may not be a good idea, however in our experiment it never hit 
maximum retry count.
I just converted usleep_range to mdelay keeping min time limitation as 
it is, though I
am not sure, how do we arrived on these numbers in original code, may be 
Joao Pinto
from Synopsys have some idea, I will try to do few experiment and try to 
find out what

is sufficient minimum time in our hardware for these mdelay.

Thanks,
Pankaj Dubey

David

[PATCH] of: dynamic: fix memory leak related to properties of __of_node_dup

[Lixin Wang]

Hello,

Sorry It was my fault that used the wrong sign off name in last email.
Here I correct it.
Thanks
---

It is possible a node was dynamically allocated but without any
property. The properies will be got from devices and added to the
node when devices got connected.
When release this node, all properties of which had been moved to
deadprops.
In this case, the properties in the deadprops list are never
deallocated.

Signed-off-by: Lixin Wang 
---
 drivers/of/dynamic.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 301b6db..465d43b 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -335,6 +335,10 @@ void of_node_release(struct kobject *kobj)
if (!of_node_check_flag(node, OF_DYNAMIC))
return;
 
+   if (!prop) {
+   prop = node->deadprops;
+   node->deadprops = NULL;
+   }
while (prop) {
struct property *next = prop->next;
kfree(prop->name);
-- 
2.6.2

[PATCH] of: dynamic: fix memory leak related to properties of __of_node_dup

[Lixin Wang]

Hello,

Sorry It was my fault that used the wrong sign off name in last email.
Here I correct it.
Thanks
---

It is possible a node was dynamically allocated but without any
property. The properies will be got from devices and added to the
node when devices got connected.
When release this node, all properties of which had been moved to
deadprops.
In this case, the properties in the deadprops list are never
deallocated.

Signed-off-by: Lixin Wang 
---
 drivers/of/dynamic.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 301b6db..465d43b 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -335,6 +335,10 @@ void of_node_release(struct kobject *kobj)
if (!of_node_check_flag(node, OF_DYNAMIC))
return;
 
+   if (!prop) {
+   prop = node->deadprops;
+   node->deadprops = NULL;
+   }
while (prop) {
struct property *next = prop->next;
kfree(prop->name);
-- 
2.6.2

Re: [PATCH 0/3] PCI: rockchip: assert PERST# in S3

[Bjorn Helgaas]

On Thu, Oct 12, 2017 at 01:52:17PM -0700, Brian Norris wrote:
> Hi,
> 
> This patch series should mostly be self-descriptive, but it's motivated by the
> fact that I've found differing requirements from PCIe endpoint makers 
> regarding
> the state of PERST# when in system suspend (S3). Additionally, some existing
> boards are not especially well suited for holding PERST# low in S3 (e.g., the
> pin is driven by a non-PMU GPIO, so it's hard or impossible to keep it
> asserted). So the solution is...give it a device tree property!

How do ACPI systems solve this problem?

Can you point to any relevant sections in the PCI specs?

Is this a hole in those specs?  Is this something that needs to be
clarified by the PCI-SIG to improve interoperability?

Why is this problem only showing up now?

> Brian Norris (3):
>   Documentation/devicetree: Add pcie-reset-suspend property
>   of/pci: Add of_pci_get_pcie_reset_suspend() to parse
> pcie-reset-suspend
>   PCI: rockchip: Support configuring PERST# state via DT
> 
>  Documentation/devicetree/bindings/pci/pci.txt | 11 +++
>  drivers/of/of_pci.c   | 25 +
>  drivers/pci/host/pcie-rockchip.c  |  7 +++
>  include/linux/of_pci.h|  7 +++
>  4 files changed, 50 insertions(+)
> 
> -- 
> 2.15.0.rc0.271.g36b669edcc-goog
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] PCI: rockchip: assert PERST# in S3

[Bjorn Helgaas]

On Thu, Oct 12, 2017 at 01:52:17PM -0700, Brian Norris wrote:
> Hi,
> 
> This patch series should mostly be self-descriptive, but it's motivated by the
> fact that I've found differing requirements from PCIe endpoint makers 
> regarding
> the state of PERST# when in system suspend (S3). Additionally, some existing
> boards are not especially well suited for holding PERST# low in S3 (e.g., the
> pin is driven by a non-PMU GPIO, so it's hard or impossible to keep it
> asserted). So the solution is...give it a device tree property!

How do ACPI systems solve this problem?

Can you point to any relevant sections in the PCI specs?

Is this a hole in those specs?  Is this something that needs to be
clarified by the PCI-SIG to improve interoperability?

Why is this problem only showing up now?

> Brian Norris (3):
>   Documentation/devicetree: Add pcie-reset-suspend property
>   of/pci: Add of_pci_get_pcie_reset_suspend() to parse
> pcie-reset-suspend
>   PCI: rockchip: Support configuring PERST# state via DT
> 
>  Documentation/devicetree/bindings/pci/pci.txt | 11 +++
>  drivers/of/of_pci.c   | 25 +
>  drivers/pci/host/pcie-rockchip.c  |  7 +++
>  include/linux/of_pci.h|  7 +++
>  4 files changed, 50 insertions(+)
> 
> -- 
> 2.15.0.rc0.271.g36b669edcc-goog
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2] media: uvcvideo: Fix uvc dev reference management

[Jeffy Chen]

Remove the kref_get() in uvc_register_video(), which is not needed as
the kref_init() already initializes refcount to 1 for us.

Fixes: 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic variable to 
a reference count")
Signed-off-by: Jeffy Chen 
---

Changes in v2:
Rewrite commit message.

 drivers/media/usb/uvc/uvc_driver.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 6d22b22cb35b..dd6106411eb0 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1939,7 +1939,6 @@ static int uvc_register_video(struct uvc_device *dev,
else
stream->chain->caps |= V4L2_CAP_VIDEO_OUTPUT;
 
-   kref_get(>ref);
return 0;
 }
 
-- 
2.11.0

[PATCH v2] media: uvcvideo: Fix uvc dev reference management

[Jeffy Chen]

Remove the kref_get() in uvc_register_video(), which is not needed as
the kref_init() already initializes refcount to 1 for us.

Fixes: 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic variable to 
a reference count")
Signed-off-by: Jeffy Chen 
---

Changes in v2:
Rewrite commit message.

 drivers/media/usb/uvc/uvc_driver.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 6d22b22cb35b..dd6106411eb0 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1939,7 +1939,6 @@ static int uvc_register_video(struct uvc_device *dev,
else
stream->chain->caps |= V4L2_CAP_VIDEO_OUTPUT;
 
-   kref_get(>ref);
return 0;
 }
 
-- 
2.11.0

Re: [PATCH] ARM: dts: imx: ventana: remove container node from iomuxc nodes

[Shawn Guo]

On Mon, Sep 18, 2017 at 01:11:01PM -0700, Tim Harvey wrote:
> The container node in the iomuxc node is no longer necessary and causes
> pinctl errors on the Ventana boards with analog video capture
> since aa12693e4156adafdef80a8bd134123a6419621b:
> 
> pinctrl core: initialized pinctrl subsystem
> imx6q-pinctrl 20e.iomuxc: no groups defined in 
> /soc/aips-bus@0200/iomuxc@020e/adv7180grp
> imx6q-pinctrl 20e.iomuxc: no groups defined in 
> /soc/aips-bus@0200/iomuxc@020e/ipu2_csi1grp
> imx6q-pinctrl 20e.iomuxc: initialized IMX pinctrl driver
> imx6q-pinctrl 20e.iomuxc: function 'iomuxc' not supported
> imx6q-pinctrl 20e.iomuxc: invalid function iomuxc in map table
> imx6q-pinctrl 20e.iomuxc: function 'iomuxc' not supported
> imx6q-pinctrl 20e.iomuxc: invalid function iomuxc in map table
> 
> Signed-off-by: Tim Harvey 

Applied, thanks.

Re: [PATCH] ARM: dts: imx: ventana: remove container node from iomuxc nodes

[Shawn Guo]

On Mon, Sep 18, 2017 at 01:11:01PM -0700, Tim Harvey wrote:
> The container node in the iomuxc node is no longer necessary and causes
> pinctl errors on the Ventana boards with analog video capture
> since aa12693e4156adafdef80a8bd134123a6419621b:
> 
> pinctrl core: initialized pinctrl subsystem
> imx6q-pinctrl 20e.iomuxc: no groups defined in 
> /soc/aips-bus@0200/iomuxc@020e/adv7180grp
> imx6q-pinctrl 20e.iomuxc: no groups defined in 
> /soc/aips-bus@0200/iomuxc@020e/ipu2_csi1grp
> imx6q-pinctrl 20e.iomuxc: initialized IMX pinctrl driver
> imx6q-pinctrl 20e.iomuxc: function 'iomuxc' not supported
> imx6q-pinctrl 20e.iomuxc: invalid function iomuxc in map table
> imx6q-pinctrl 20e.iomuxc: function 'iomuxc' not supported
> imx6q-pinctrl 20e.iomuxc: invalid function iomuxc in map table
> 
> Signed-off-by: Tim Harvey 

Applied, thanks.

[PATCH] of: overlay: fix memory leak related to duplicated property

[Lixin Wang]

From: alawang 

Hello,

Sorry It was my fault in last email that wrote the wrong subject and sign off 
name.
Correct them this time.
Thanks

Function of_changeset_add_property or of_changeset_update_property may
fails. In this case the property just allocated is never deallocated.

Signed-off-by: Lixin Wang 
---
 drivers/of/overlay.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 8ecfee3..af3b9a1 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -162,6 +162,7 @@ static int of_overlay_apply_single_property(struct 
of_overlay *ov,
bool is_symbols_node)
 {
struct property *propn = NULL, *tprop;
+   int ret = 0;
 
/* NOTE: Multiple changes of single properties not supported */
tprop = of_find_property(target, prop->name, NULL);
@@ -186,10 +187,16 @@ static int of_overlay_apply_single_property(struct 
of_overlay *ov,
 
/* not found? add */
if (tprop == NULL)
-   return of_changeset_add_property(>cset, target, propn);
-
-   /* found? update */
-   return of_changeset_update_property(>cset, target, propn);
+   ret = of_changeset_add_property(>cset, target, propn);
+   else /* found? update */
+   ret = of_changeset_update_property(>cset, target, propn);
+
+   if (ret) {
+   kfree(propn->name);
+   kfree(propn->value);
+   kfree(propn);
+   }
+   return ret;
 }
 
 static int of_overlay_apply_single_device_node(struct of_overlay *ov,
-- 
2.6.2

[PATCH] of: overlay: fix memory leak related to duplicated property

[Lixin Wang]

From: alawang 

Hello,

Sorry It was my fault in last email that wrote the wrong subject and sign off 
name.
Correct them this time.
Thanks

Function of_changeset_add_property or of_changeset_update_property may
fails. In this case the property just allocated is never deallocated.

Signed-off-by: Lixin Wang 
---
 drivers/of/overlay.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 8ecfee3..af3b9a1 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -162,6 +162,7 @@ static int of_overlay_apply_single_property(struct 
of_overlay *ov,
bool is_symbols_node)
 {
struct property *propn = NULL, *tprop;
+   int ret = 0;
 
/* NOTE: Multiple changes of single properties not supported */
tprop = of_find_property(target, prop->name, NULL);
@@ -186,10 +187,16 @@ static int of_overlay_apply_single_property(struct 
of_overlay *ov,
 
/* not found? add */
if (tprop == NULL)
-   return of_changeset_add_property(>cset, target, propn);
-
-   /* found? update */
-   return of_changeset_update_property(>cset, target, propn);
+   ret = of_changeset_add_property(>cset, target, propn);
+   else /* found? update */
+   ret = of_changeset_update_property(>cset, target, propn);
+
+   if (ret) {
+   kfree(propn->name);
+   kfree(propn->value);
+   kfree(propn);
+   }
+   return ret;
 }
 
 static int of_overlay_apply_single_device_node(struct of_overlay *ov,
-- 
2.6.2

Re: [PATCH v5 1/5] ARM: dts: imx6qdl-icore: Add Sound card support

[Shawn Guo]

On Mon, Sep 18, 2017 at 04:58:29PM +0530, Jagan Teki wrote:
> From: Jagan Teki 
> 
> Linux Sound card now uses generic simple-audio-card, so add
> the same along with related audmux and codec(via u2c3) for
> i.CoreM6 QDL module boards.
> 
> Cc: Shawn Guo 
> Cc: Matteo Lisi 
> Cc: Michael Trimarchi 
> Signed-off-by: Jagan Teki 

Applied all, thanks.

Re: [PATCH v5 1/5] ARM: dts: imx6qdl-icore: Add Sound card support

[Shawn Guo]

On Mon, Sep 18, 2017 at 04:58:29PM +0530, Jagan Teki wrote:
> From: Jagan Teki 
> 
> Linux Sound card now uses generic simple-audio-card, so add
> the same along with related audmux and codec(via u2c3) for
> i.CoreM6 QDL module boards.
> 
> Cc: Shawn Guo 
> Cc: Matteo Lisi 
> Cc: Michael Trimarchi 
> Signed-off-by: Jagan Teki 

Applied all, thanks.

Re: [PATCH v5 1/3] PCI: rockchip: Add support for pcie wake irq

[Bjorn Helgaas]

[+cc Rafael, linux-pm]

On Mon, Sep 11, 2017 at 11:10:27PM +0800, Jeffy Chen wrote:
> Add support for PCIE_WAKE pin in rockchip pcie driver.
> 
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v5:
> Rebase
> 
> Changes in v3:
> Fix error handling
> 
> Changes in v2:
> Use dev_pm_set_dedicated_wake_irq
> -- Suggested by Brian Norris 
> 
>  drivers/pci/host/pcie-rockchip.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-rockchip.c 
> b/drivers/pci/host/pcie-rockchip.c
> index 9051c6c8fea4..a8b7272597a7 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -995,6 +996,15 @@ static int rockchip_pcie_setup_irq(struct rockchip_pcie 
> *rockchip)
>   return err;
>   }
>  
> + /* Must init wakeup before setting dedicated wakeup irq. */
> + device_init_wakeup(dev, true);
> + irq = platform_get_irq_byname(pdev, "wakeup");
> + if (irq >= 0) {
> + err = dev_pm_set_dedicated_wake_irq(dev, irq);

I'm a little skeptical about dev_pm_set_dedicated_wake_irq(), not
because I know anything at all about it, but because there are only
five callers in the whole tree, three of which are in UART code, and
none in anything resembling PCI code.

Is Rockchip really that special, or are we going about this the wrong
way?

> + if (err)
> + dev_err(dev, "failed to setup PCIe wakeup IRQ\n");
> + }
> +
>   return 0;

The above could be structured as:

  irq = platform_get_irq_byname(pdev, "wakeup");
  if (irq < 0)
return 0;

  device_init_wakeup(dev, true);
  err = dev_pm_set_dedicated_wake_irq(dev, irq);
  if (err) {
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
  }

  return 0;

to unindent the mainline non-error code.

>  }
>  
> @@ -1542,11 +1552,11 @@ static int rockchip_pcie_probe(struct platform_device 
> *pdev)
>  
>   err = rockchip_pcie_parse_dt(rockchip);
>   if (err)
> - return err;
> + goto err_disable_wake;
>  
>   err = rockchip_pcie_enable_clocks(rockchip);
>   if (err)
> - return err;
> + goto err_disable_wake;
>  
>   err = rockchip_pcie_set_vpcie(rockchip);
>   if (err) {
> @@ -1656,6 +1666,9 @@ static int rockchip_pcie_probe(struct platform_device 
> *pdev)
>   regulator_disable(rockchip->vpcie0v9);
>  err_set_vpcie:
>   rockchip_pcie_disable_clocks(rockchip);
> +err_disable_wake:
> + dev_pm_clear_wake_irq(dev);
> + device_init_wakeup(dev, false);

I think this error cleanup should be done in rockchip_pcie_setup_irq()
as shown above.  There's no real connection between
rockchip_pcie_probe() and the wake setup.

>   return err;
>  }
>  
> @@ -1682,6 +1695,8 @@ static int rockchip_pcie_remove(struct platform_device 
> *pdev)
>   if (!IS_ERR(rockchip->vpcie0v9))
>   regulator_disable(rockchip->vpcie0v9);
>  
> + dev_pm_clear_wake_irq(dev);
> + device_init_wakeup(dev, false);
>   return 0;
>  }
>  
> -- 
> 2.11.0
> 
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 1/3] PCI: rockchip: Add support for pcie wake irq

[Bjorn Helgaas]

[+cc Rafael, linux-pm]

On Mon, Sep 11, 2017 at 11:10:27PM +0800, Jeffy Chen wrote:
> Add support for PCIE_WAKE pin in rockchip pcie driver.
> 
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v5:
> Rebase
> 
> Changes in v3:
> Fix error handling
> 
> Changes in v2:
> Use dev_pm_set_dedicated_wake_irq
> -- Suggested by Brian Norris 
> 
>  drivers/pci/host/pcie-rockchip.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-rockchip.c 
> b/drivers/pci/host/pcie-rockchip.c
> index 9051c6c8fea4..a8b7272597a7 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -995,6 +996,15 @@ static int rockchip_pcie_setup_irq(struct rockchip_pcie 
> *rockchip)
>   return err;
>   }
>  
> + /* Must init wakeup before setting dedicated wakeup irq. */
> + device_init_wakeup(dev, true);
> + irq = platform_get_irq_byname(pdev, "wakeup");
> + if (irq >= 0) {
> + err = dev_pm_set_dedicated_wake_irq(dev, irq);

I'm a little skeptical about dev_pm_set_dedicated_wake_irq(), not
because I know anything at all about it, but because there are only
five callers in the whole tree, three of which are in UART code, and
none in anything resembling PCI code.

Is Rockchip really that special, or are we going about this the wrong
way?

> + if (err)
> + dev_err(dev, "failed to setup PCIe wakeup IRQ\n");
> + }
> +
>   return 0;

The above could be structured as:

  irq = platform_get_irq_byname(pdev, "wakeup");
  if (irq < 0)
return 0;

  device_init_wakeup(dev, true);
  err = dev_pm_set_dedicated_wake_irq(dev, irq);
  if (err) {
dev_pm_clear_wake_irq(dev);
device_init_wakeup(dev, false);
  }

  return 0;

to unindent the mainline non-error code.

>  }
>  
> @@ -1542,11 +1552,11 @@ static int rockchip_pcie_probe(struct platform_device 
> *pdev)
>  
>   err = rockchip_pcie_parse_dt(rockchip);
>   if (err)
> - return err;
> + goto err_disable_wake;
>  
>   err = rockchip_pcie_enable_clocks(rockchip);
>   if (err)
> - return err;
> + goto err_disable_wake;
>  
>   err = rockchip_pcie_set_vpcie(rockchip);
>   if (err) {
> @@ -1656,6 +1666,9 @@ static int rockchip_pcie_probe(struct platform_device 
> *pdev)
>   regulator_disable(rockchip->vpcie0v9);
>  err_set_vpcie:
>   rockchip_pcie_disable_clocks(rockchip);
> +err_disable_wake:
> + dev_pm_clear_wake_irq(dev);
> + device_init_wakeup(dev, false);

I think this error cleanup should be done in rockchip_pcie_setup_irq()
as shown above.  There's no real connection between
rockchip_pcie_probe() and the wake setup.

>   return err;
>  }
>  
> @@ -1682,6 +1695,8 @@ static int rockchip_pcie_remove(struct platform_device 
> *pdev)
>   if (!IS_ERR(rockchip->vpcie0v9))
>   regulator_disable(rockchip->vpcie0v9);
>  
> + dev_pm_clear_wake_irq(dev);
> + device_init_wakeup(dev, false);
>   return 0;
>  }
>  
> -- 
> 2.11.0
> 
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

linux-next: Tree for Oct 12th

[Mark Brown]

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 an arm64 defconfig, 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,
and arm64 allnoconfig 


signature.asc
Description: PGP signature

linux-next: Tree for Oct 12th

[Mark Brown]

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 an arm64 defconfig, 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,
and arm64 allnoconfig 


signature.asc
Description: PGP signature

linux-next: build failure after merge of the akpm-current tree

[Mark Brown]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build
(x86 allmodconfig) failed like this:

  CC [M]  drivers/net/ethernet/netronome/nfp/nfp_app.o
In file included from 
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.c:40:0:
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h: In 
function '__enc_swreg_lm':
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h:301:2: 
error: implicit declaration of function 'WARN_ON' 
[-Werror=implicit-function-declaration]
  WARN_ON(id > 3 || (off && mode != NN_LM_MOD_NONE));
  ^
cc1: some warnings being treated as errors

Caused by some reliance on an implicit include being exposed by a header
reorganization in your tree.  I'll add a patch for this which I'll post,
probably tomorrow morning.


signature.asc
Description: PGP signature

linux-next: build failure after merge of the akpm-current tree

[Mark Brown]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build
(x86 allmodconfig) failed like this:

  CC [M]  drivers/net/ethernet/netronome/nfp/nfp_app.o
In file included from 
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.c:40:0:
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h: In 
function '__enc_swreg_lm':
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h:301:2: 
error: implicit declaration of function 'WARN_ON' 
[-Werror=implicit-function-declaration]
  WARN_ON(id > 3 || (off && mode != NN_LM_MOD_NONE));
  ^
cc1: some warnings being treated as errors

Caused by some reliance on an implicit include being exposed by a header
reorganization in your tree.  I'll add a patch for this which I'll post,
probably tomorrow morning.


signature.asc
Description: PGP signature

[PATCH v2] ALSA: hda/ca0132 - use ARRAY_SIZE

[Jérémy Lefaure]

Using the ARRAY_SIZE macro improves the readability of the code.

Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
 (sizeof(E)@p /sizeof(*E))
|
 (sizeof(E)@p /sizeof(E[...]))
|
 (sizeof(E)@p /sizeof(T))
)

Signed-off-by: Jérémy Lefaure 
---
Changes since v1:
- keep sound/oss untouched

 sound/pci/hda/patch_ca0132.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c
index 3e73d5c6ccfc..768ea8651993 100644
--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "hda_codec.h"
 #include "hda_local.h"
@@ -3605,8 +3606,7 @@ static int ca0132_vnode_switch_set(struct snd_kcontrol 
*kcontrol,
 static int ca0132_voicefx_info(struct snd_kcontrol *kcontrol,
 struct snd_ctl_elem_info *uinfo)
 {
-   unsigned int items = sizeof(ca0132_voicefx_presets)
-   / sizeof(struct ct_voicefx_preset);
+   unsigned int items = ARRAY_SIZE(ca0132_voicefx_presets);
 
uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED;
uinfo->count = 1;
@@ -3635,10 +3635,8 @@ static int ca0132_voicefx_put(struct snd_kcontrol 
*kcontrol,
struct ca0132_spec *spec = codec->spec;
int i, err = 0;
int sel = ucontrol->value.enumerated.item[0];
-   unsigned int items = sizeof(ca0132_voicefx_presets)
-   / sizeof(struct ct_voicefx_preset);
 
-   if (sel >= items)
+   if (sel >= ARRAY_SIZE(ca0132_voicefx_presets))
return 0;
 
codec_dbg(codec, "ca0132_voicefx_put: sel=%d, preset=%s\n",
-- 
2.14.2

[PATCH v2] ALSA: hda/ca0132 - use ARRAY_SIZE

[Jérémy Lefaure]

Using the ARRAY_SIZE macro improves the readability of the code.

Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
 (sizeof(E)@p /sizeof(*E))
|
 (sizeof(E)@p /sizeof(E[...]))
|
 (sizeof(E)@p /sizeof(T))
)

Signed-off-by: Jérémy Lefaure 
---
Changes since v1:
- keep sound/oss untouched

 sound/pci/hda/patch_ca0132.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c
index 3e73d5c6ccfc..768ea8651993 100644
--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "hda_codec.h"
 #include "hda_local.h"
@@ -3605,8 +3606,7 @@ static int ca0132_vnode_switch_set(struct snd_kcontrol 
*kcontrol,
 static int ca0132_voicefx_info(struct snd_kcontrol *kcontrol,
 struct snd_ctl_elem_info *uinfo)
 {
-   unsigned int items = sizeof(ca0132_voicefx_presets)
-   / sizeof(struct ct_voicefx_preset);
+   unsigned int items = ARRAY_SIZE(ca0132_voicefx_presets);
 
uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED;
uinfo->count = 1;
@@ -3635,10 +3635,8 @@ static int ca0132_voicefx_put(struct snd_kcontrol 
*kcontrol,
struct ca0132_spec *spec = codec->spec;
int i, err = 0;
int sel = ucontrol->value.enumerated.item[0];
-   unsigned int items = sizeof(ca0132_voicefx_presets)
-   / sizeof(struct ct_voicefx_preset);
 
-   if (sel >= items)
+   if (sel >= ARRAY_SIZE(ca0132_voicefx_presets))
return 0;
 
codec_dbg(codec, "ca0132_voicefx_put: sel=%d, preset=%s\n",
-- 
2.14.2

Re: [PATCH v5 1/3] PCI: rockchip: Add support for pcie wake irq

[Bjorn Helgaas]

On Thu, Oct 12, 2017 at 06:56:22PM -0700, Brian Norris wrote:
> Hi,
> 
> On Mon, Sep 11, 2017 at 11:10:27PM +0800, Jeffy Chen wrote:
> > Add support for PCIE_WAKE pin in rockchip pcie driver.
> > 
> > Signed-off-by: Jeffy Chen 
> > ---
> > 
> > Changes in v5:
> > Rebase
> > 
> > Changes in v3:
> > Fix error handling
> > 
> > Changes in v2:
> > Use dev_pm_set_dedicated_wake_irq
> > -- Suggested by Brian Norris 
> > 
> >  drivers/pci/host/pcie-rockchip.c | 19 +--
> >  1 file changed, 17 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-rockchip.c 
> > b/drivers/pci/host/pcie-rockchip.c
> > index 9051c6c8fea4..a8b7272597a7 100644
> > --- a/drivers/pci/host/pcie-rockchip.c
> > +++ b/drivers/pci/host/pcie-rockchip.c
> > @@ -37,6 +37,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -995,6 +996,15 @@ static int rockchip_pcie_setup_irq(struct 
> > rockchip_pcie *rockchip)
> > return err;
> > }
> >  
> > +   /* Must init wakeup before setting dedicated wakeup irq. */
> > +   device_init_wakeup(dev, true);
> 
> Am I crazy, or should this go inside the 'irq >= 0' conditional?
> Otherwise, for the whole series:
> 
> Reviewed-by: Brian Norris 
> Tested-by: Brian Norris 
> 
> Bjorn, were you planning to pick this up?

I had already applied this to pci/host-rockchip, but I must have gotten
interrupted before sending the email.

But now that you mention it, I looked at this again and have some
questions.  I'll respond to the original patch.

> Also, the DT binding change conflicts (just simple context) with the
> PERST# series I just sent out. Would be good if we could land one or
> both :)
> 
> Thanks,
> Brian
> 
> > +   irq = platform_get_irq_byname(pdev, "wakeup");
> > +   if (irq >= 0) {
> > +   err = dev_pm_set_dedicated_wake_irq(dev, irq);
> > +   if (err)
> > +   dev_err(dev, "failed to setup PCIe wakeup IRQ\n");
> > +   }
> > +
> > return 0;
> >  }
> >  
> > @@ -1542,11 +1552,11 @@ static int rockchip_pcie_probe(struct 
> > platform_device *pdev)
> >  
> > err = rockchip_pcie_parse_dt(rockchip);
> > if (err)
> > -   return err;
> > +   goto err_disable_wake;
> >  
> > err = rockchip_pcie_enable_clocks(rockchip);
> > if (err)
> > -   return err;
> > +   goto err_disable_wake;
> >  
> > err = rockchip_pcie_set_vpcie(rockchip);
> > if (err) {
> > @@ -1656,6 +1666,9 @@ static int rockchip_pcie_probe(struct platform_device 
> > *pdev)
> > regulator_disable(rockchip->vpcie0v9);
> >  err_set_vpcie:
> > rockchip_pcie_disable_clocks(rockchip);
> > +err_disable_wake:
> > +   dev_pm_clear_wake_irq(dev);
> > +   device_init_wakeup(dev, false);
> > return err;
> >  }
> >  
> > @@ -1682,6 +1695,8 @@ static int rockchip_pcie_remove(struct 
> > platform_device *pdev)
> > if (!IS_ERR(rockchip->vpcie0v9))
> > regulator_disable(rockchip->vpcie0v9);
> >  
> > +   dev_pm_clear_wake_irq(dev);
> > +   device_init_wakeup(dev, false);
> > return 0;
> >  }
> >  
> > -- 
> > 2.11.0
> > 
> > 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 1/3] PCI: rockchip: Add support for pcie wake irq

[Bjorn Helgaas]

On Thu, Oct 12, 2017 at 06:56:22PM -0700, Brian Norris wrote:
> Hi,
> 
> On Mon, Sep 11, 2017 at 11:10:27PM +0800, Jeffy Chen wrote:
> > Add support for PCIE_WAKE pin in rockchip pcie driver.
> > 
> > Signed-off-by: Jeffy Chen 
> > ---
> > 
> > Changes in v5:
> > Rebase
> > 
> > Changes in v3:
> > Fix error handling
> > 
> > Changes in v2:
> > Use dev_pm_set_dedicated_wake_irq
> > -- Suggested by Brian Norris 
> > 
> >  drivers/pci/host/pcie-rockchip.c | 19 +--
> >  1 file changed, 17 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-rockchip.c 
> > b/drivers/pci/host/pcie-rockchip.c
> > index 9051c6c8fea4..a8b7272597a7 100644
> > --- a/drivers/pci/host/pcie-rockchip.c
> > +++ b/drivers/pci/host/pcie-rockchip.c
> > @@ -37,6 +37,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -995,6 +996,15 @@ static int rockchip_pcie_setup_irq(struct 
> > rockchip_pcie *rockchip)
> > return err;
> > }
> >  
> > +   /* Must init wakeup before setting dedicated wakeup irq. */
> > +   device_init_wakeup(dev, true);
> 
> Am I crazy, or should this go inside the 'irq >= 0' conditional?
> Otherwise, for the whole series:
> 
> Reviewed-by: Brian Norris 
> Tested-by: Brian Norris 
> 
> Bjorn, were you planning to pick this up?

I had already applied this to pci/host-rockchip, but I must have gotten
interrupted before sending the email.

But now that you mention it, I looked at this again and have some
questions.  I'll respond to the original patch.

> Also, the DT binding change conflicts (just simple context) with the
> PERST# series I just sent out. Would be good if we could land one or
> both :)
> 
> Thanks,
> Brian
> 
> > +   irq = platform_get_irq_byname(pdev, "wakeup");
> > +   if (irq >= 0) {
> > +   err = dev_pm_set_dedicated_wake_irq(dev, irq);
> > +   if (err)
> > +   dev_err(dev, "failed to setup PCIe wakeup IRQ\n");
> > +   }
> > +
> > return 0;
> >  }
> >  
> > @@ -1542,11 +1552,11 @@ static int rockchip_pcie_probe(struct 
> > platform_device *pdev)
> >  
> > err = rockchip_pcie_parse_dt(rockchip);
> > if (err)
> > -   return err;
> > +   goto err_disable_wake;
> >  
> > err = rockchip_pcie_enable_clocks(rockchip);
> > if (err)
> > -   return err;
> > +   goto err_disable_wake;
> >  
> > err = rockchip_pcie_set_vpcie(rockchip);
> > if (err) {
> > @@ -1656,6 +1666,9 @@ static int rockchip_pcie_probe(struct platform_device 
> > *pdev)
> > regulator_disable(rockchip->vpcie0v9);
> >  err_set_vpcie:
> > rockchip_pcie_disable_clocks(rockchip);
> > +err_disable_wake:
> > +   dev_pm_clear_wake_irq(dev);
> > +   device_init_wakeup(dev, false);
> > return err;
> >  }
> >  
> > @@ -1682,6 +1695,8 @@ static int rockchip_pcie_remove(struct 
> > platform_device *pdev)
> > if (!IS_ERR(rockchip->vpcie0v9))
> > regulator_disable(rockchip->vpcie0v9);
> >  
> > +   dev_pm_clear_wake_irq(dev);
> > +   device_init_wakeup(dev, false);
> > return 0;
> >  }
> >  
> > -- 
> > 2.11.0
> > 
> > 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] drm/rockchip: add PINCTRL dependency for LVDS

[Mark yao]

On 2017年10月05日 20:09, Arnd Bergmann wrote:

The new driver fails to build when CONFIG_PINCTRL is disabled:

drivers/gpu/drm/rockchip/rockchip_lvds.c: In function 
'rockchip_lvds_grf_config':
drivers/gpu/drm/rockchip/rockchip_lvds.c:229:39: error: dereferencing pointer 
to incomplete type 'struct dev_pin_info'
if (lvds->pins && !IS_ERR(lvds->pins->default_state))

This adds the respective Kconfig dependency.

Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Signed-off-by: Arnd Bergmann 


Pushed to drm-misc-next

Thanks
Mark

Re: [PATCH] drm/rockchip: add PINCTRL dependency for LVDS

[Mark yao]

On 2017年10月05日 20:09, Arnd Bergmann wrote:

The new driver fails to build when CONFIG_PINCTRL is disabled:

drivers/gpu/drm/rockchip/rockchip_lvds.c: In function 
'rockchip_lvds_grf_config':
drivers/gpu/drm/rockchip/rockchip_lvds.c:229:39: error: dereferencing pointer 
to incomplete type 'struct dev_pin_info'
if (lvds->pins && !IS_ERR(lvds->pins->default_state))

This adds the respective Kconfig dependency.

Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Signed-off-by: Arnd Bergmann 


Pushed to drm-misc-next

Thanks
Mark

Re: [PATCH] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Jaegeuk Kim]

On 10/13, Yunlong Song wrote:
> Hi, Jay,
> I think it should not happen when need_gc == true but total_freed ==0,
> so I add it as bug_on to let it panic at once. And even CHECK_FS is closed,
> this can also printk WARNING message for notice.

Ah, got it. Merged. :)
Thanks,

> 
> On 2017/10/13 7:23, Jaegeuk Kim wrote:
> > Hi Yunlong,
> > 
> > On 10/11, Yunlong Song wrote:
> > > This can help us to debug on some corner case.
> > > 
> > > Signed-off-by: Yunlong Song 
> > > ---
> > >   fs/f2fs/gc.c | 6 +-
> > >   1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> > > index 197ebf4..960503e 100644
> > > --- a/fs/f2fs/gc.c
> > > +++ b/fs/f2fs/gc.c
> > > @@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
> > >   .ilist = LIST_HEAD_INIT(gc_list.ilist),
> > >   .iroot = RADIX_TREE_INIT(GFP_NOFS),
> > >   };
> > > + bool need_gc = false;
> > >   trace_f2fs_gc_begin(sbi->sb, sync, background,
> > >   get_pages(sbi, F2FS_DIRTY_NODES),
> > > @@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
> > >   if (ret)
> > >   goto stop;
> > >   }
> > > - if (has_not_enough_free_secs(sbi, 0, 0))
> > > + if (has_not_enough_free_secs(sbi, 0, 0)) {
> > >   gc_type = FG_GC;
> > > + need_gc = true;
> > > + }
> > >   }
> > >   /* f2fs_balance_fs doesn't need to do BG_GC in critical path. */
> > > @@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
> > >   goto stop;
> > >   }
> > >   if (!__get_victim(sbi, , gc_type)) {
> > > + f2fs_bug_on(sbi, !total_freed && need_gc);
> > How about this, if this is for debugging purpose?
> > 
> > if (!total_freed && need_gc)
> > f2fs_msg(...);
> > 
> > It's not a good way to define a value for f2fs_bug_on(), since it is only
> > activated by CHECK_FS config.
> > 
> > Thanks,
> > 
> > >   ret = -ENODATA;
> > >   goto stop;
> > >   }
> > > -- 
> > > 1.8.5.2
> > .
> > 
> 
> -- 
> Thanks,
> Yunlong Song
> 

Re: [PATCH] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Jaegeuk Kim]

On 10/13, Yunlong Song wrote:
> Hi, Jay,
> I think it should not happen when need_gc == true but total_freed ==0,
> so I add it as bug_on to let it panic at once. And even CHECK_FS is closed,
> this can also printk WARNING message for notice.

Ah, got it. Merged. :)
Thanks,

> 
> On 2017/10/13 7:23, Jaegeuk Kim wrote:
> > Hi Yunlong,
> > 
> > On 10/11, Yunlong Song wrote:
> > > This can help us to debug on some corner case.
> > > 
> > > Signed-off-by: Yunlong Song 
> > > ---
> > >   fs/f2fs/gc.c | 6 +-
> > >   1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> > > index 197ebf4..960503e 100644
> > > --- a/fs/f2fs/gc.c
> > > +++ b/fs/f2fs/gc.c
> > > @@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
> > >   .ilist = LIST_HEAD_INIT(gc_list.ilist),
> > >   .iroot = RADIX_TREE_INIT(GFP_NOFS),
> > >   };
> > > + bool need_gc = false;
> > >   trace_f2fs_gc_begin(sbi->sb, sync, background,
> > >   get_pages(sbi, F2FS_DIRTY_NODES),
> > > @@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
> > >   if (ret)
> > >   goto stop;
> > >   }
> > > - if (has_not_enough_free_secs(sbi, 0, 0))
> > > + if (has_not_enough_free_secs(sbi, 0, 0)) {
> > >   gc_type = FG_GC;
> > > + need_gc = true;
> > > + }
> > >   }
> > >   /* f2fs_balance_fs doesn't need to do BG_GC in critical path. */
> > > @@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
> > >   goto stop;
> > >   }
> > >   if (!__get_victim(sbi, , gc_type)) {
> > > + f2fs_bug_on(sbi, !total_freed && need_gc);
> > How about this, if this is for debugging purpose?
> > 
> > if (!total_freed && need_gc)
> > f2fs_msg(...);
> > 
> > It's not a good way to define a value for f2fs_bug_on(), since it is only
> > activated by CHECK_FS config.
> > 
> > Thanks,
> > 
> > >   ret = -ENODATA;
> > >   goto stop;
> > >   }
> > > -- 
> > > 1.8.5.2
> > .
> > 
> 
> -- 
> Thanks,
> Yunlong Song
> 

Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command

[Brijesh Singh]

On 10/12/17 2:53 PM, Borislav Petkov wrote:
...

> Ok, a couple of things here:
>
> * Move the checks first and the allocations second so that you allocate
> memory only after all checks have been passed and you don't allocate
> pointlessly.


I assume you mean performing the SEV state check before allocating the
memory for the CSR blob, right ? In my patches, I typically perform all
the SW specific checks and allocation before invoking the HW routines.
Handling the PSP commands will take longer compare to kmalloc() or
access_ok() etc. If its not a big deal then I would prefer to keep that
way.


>
> * That:
>
> if (state == SEV_STATE_WORKING) {
> ret = -EBUSY;
> goto e_free_blob;
> } else if (state == SEV_STATE_UNINIT) {
> ret = sev_firmware_init(>error);
> if (ret)
> goto e_free_blob;
> do_shutdown = 1;
> }
>
> is a repeating pattern. Perhaps it should be called
> sev_firmware_reinit() and called by other functions.


> * The rest is simplifications and streamlining.
>
> ---
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index e3ee68afd068..d41f5448a25b 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -302,33 +302,30 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
>   int ret, state;
>   void *blob;
>  
> - if (copy_from_user(, (void __user *)(uintptr_t)argp->data,
> -sizeof(struct sev_user_data_pek_csr)))
> + if (copy_from_user(, (void __user *)argp->data, sizeof(input)))
> + return -EFAULT;
> +
> + if (!input.address)
> + return -EINVAL;
> +
> + /* allocate a physically contiguous buffer to store the CSR blob */
> + if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
> + input.length > SEV_FW_BLOB_MAX_SIZE)
>   return -EFAULT;
>  
>   data = kzalloc(sizeof(*data), GFP_KERNEL);
>   if (!data)
>   return -ENOMEM;
>  
> - /* allocate a temporary physical contigous buffer to store the CSR blob 
> */
> - blob = NULL;
> - if (input.address) {
> - if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
> - input.length > SEV_FW_BLOB_MAX_SIZE) {
> - ret = -EFAULT;
> - goto e_free;
> - }
> -
> - blob = kmalloc(input.length, GFP_KERNEL);
> - if (!blob) {
> - ret = -ENOMEM;
> - goto e_free;
> - }
> -
> - data->address = __psp_pa(blob);
> - data->len = input.length;
> + blob = kmalloc(input.length, GFP_KERNEL);
> + if (!blob) {
> + ret = -ENOMEM;
> + goto e_free;
>   }
>  
> + data->address = __psp_pa(blob);
> + data->len = input.length;
> +
>   ret = sev_platform_get_state(, >error);
>   if (ret)
>   goto e_free_blob;
> @@ -349,25 +346,23 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
>   do_shutdown = 1;
>   }
>  
> - ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, >error);
> + ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, >error);
>  
>   input.length = data->len;
>  
>   /* copy blob to userspace */
> - if (blob &&
> - copy_to_user((void __user *)(uintptr_t)input.address,
> - blob, input.length)) {
> + if (copy_to_user((void __user *)input.address, blob, input.length)) {
>   ret = -EFAULT;
>   goto e_shutdown;
>   }
>  
> - if (copy_to_user((void __user *)(uintptr_t)argp->data, ,
> -  sizeof(struct sev_user_data_pek_csr)))
> + if (copy_to_user((void __user *)argp->data, , sizeof(input)))
>   ret = -EFAULT;
>  
>  e_shutdown:
>   if (do_shutdown)
> - sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> + ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> +
>  e_free_blob:
>   kfree(blob);
>  e_free:
> @@ -408,10 +403,10 @@ static long sev_ioctl(struct file *file, unsigned int 
> ioctl, unsigned long arg)
>   ret = sev_ioctl_pdh_gen();
>   break;
>  
> - case SEV_PEK_CSR: {
> + case SEV_PEK_CSR:
>   ret = sev_ioctl_pek_csr();
>   break;
> - }
> +
>   default:
>   ret = -EINVAL;
>   goto out;
>

Re: [Part2 PATCH v5.1 12.7/31] crypto: ccp: Implement SEV_PEK_CSR ioctl command

[Brijesh Singh]

On 10/12/17 2:53 PM, Borislav Petkov wrote:
...

> Ok, a couple of things here:
>
> * Move the checks first and the allocations second so that you allocate
> memory only after all checks have been passed and you don't allocate
> pointlessly.


I assume you mean performing the SEV state check before allocating the
memory for the CSR blob, right ? In my patches, I typically perform all
the SW specific checks and allocation before invoking the HW routines.
Handling the PSP commands will take longer compare to kmalloc() or
access_ok() etc. If its not a big deal then I would prefer to keep that
way.


>
> * That:
>
> if (state == SEV_STATE_WORKING) {
> ret = -EBUSY;
> goto e_free_blob;
> } else if (state == SEV_STATE_UNINIT) {
> ret = sev_firmware_init(>error);
> if (ret)
> goto e_free_blob;
> do_shutdown = 1;
> }
>
> is a repeating pattern. Perhaps it should be called
> sev_firmware_reinit() and called by other functions.


> * The rest is simplifications and streamlining.
>
> ---
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index e3ee68afd068..d41f5448a25b 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -302,33 +302,30 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
>   int ret, state;
>   void *blob;
>  
> - if (copy_from_user(, (void __user *)(uintptr_t)argp->data,
> -sizeof(struct sev_user_data_pek_csr)))
> + if (copy_from_user(, (void __user *)argp->data, sizeof(input)))
> + return -EFAULT;
> +
> + if (!input.address)
> + return -EINVAL;
> +
> + /* allocate a physically contiguous buffer to store the CSR blob */
> + if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
> + input.length > SEV_FW_BLOB_MAX_SIZE)
>   return -EFAULT;
>  
>   data = kzalloc(sizeof(*data), GFP_KERNEL);
>   if (!data)
>   return -ENOMEM;
>  
> - /* allocate a temporary physical contigous buffer to store the CSR blob 
> */
> - blob = NULL;
> - if (input.address) {
> - if (!access_ok(VERIFY_WRITE, input.address, input.length) ||
> - input.length > SEV_FW_BLOB_MAX_SIZE) {
> - ret = -EFAULT;
> - goto e_free;
> - }
> -
> - blob = kmalloc(input.length, GFP_KERNEL);
> - if (!blob) {
> - ret = -ENOMEM;
> - goto e_free;
> - }
> -
> - data->address = __psp_pa(blob);
> - data->len = input.length;
> + blob = kmalloc(input.length, GFP_KERNEL);
> + if (!blob) {
> + ret = -ENOMEM;
> + goto e_free;
>   }
>  
> + data->address = __psp_pa(blob);
> + data->len = input.length;
> +
>   ret = sev_platform_get_state(, >error);
>   if (ret)
>   goto e_free_blob;
> @@ -349,25 +346,23 @@ static int sev_ioctl_pek_csr(struct sev_issue_cmd *argp)
>   do_shutdown = 1;
>   }
>  
> - ret = sev_handle_cmd(SEV_CMD_PEK_CSR, data, >error);
> + ret = sev_do_cmd(SEV_CMD_PEK_CSR, data, >error);
>  
>   input.length = data->len;
>  
>   /* copy blob to userspace */
> - if (blob &&
> - copy_to_user((void __user *)(uintptr_t)input.address,
> - blob, input.length)) {
> + if (copy_to_user((void __user *)input.address, blob, input.length)) {
>   ret = -EFAULT;
>   goto e_shutdown;
>   }
>  
> - if (copy_to_user((void __user *)(uintptr_t)argp->data, ,
> -  sizeof(struct sev_user_data_pek_csr)))
> + if (copy_to_user((void __user *)argp->data, , sizeof(input)))
>   ret = -EFAULT;
>  
>  e_shutdown:
>   if (do_shutdown)
> - sev_handle_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> + ret = sev_do_cmd(SEV_CMD_SHUTDOWN, 0, NULL);
> +
>  e_free_blob:
>   kfree(blob);
>  e_free:
> @@ -408,10 +403,10 @@ static long sev_ioctl(struct file *file, unsigned int 
> ioctl, unsigned long arg)
>   ret = sev_ioctl_pdh_gen();
>   break;
>  
> - case SEV_PEK_CSR: {
> + case SEV_PEK_CSR:
>   ret = sev_ioctl_pek_csr();
>   break;
> - }
> +
>   default:
>   ret = -EINVAL;
>   goto out;
>

Re: [PATCH] mmc:host:sdhci-pci:V2-Addition of Arasan PCI controller with integrated phy.

[Atul Garg]

Hi Sekhar,
Thanks for comments.

On Wed, Oct 11, 2017 at 7:23 AM, Sekhar Nori  wrote:
> Hi Atul,
>
> On Tuesday 10 October 2017 11:12 PM, Atul Garg wrote:
>> The Arasan controller is based on a FPGA platform and has integrated phy
>> with specific phy registers used during the initialization and
>> management of different modes. The phy and the controller are integrated
>> and registers are very specific to Arasan.
>>
>> Arasan being an IP provider, licenses these IPs to various companies for
>> integration of IP in custom SOCs. The custom SOCs define own register
>> map depending on how bits are tied inside the SOC for phy registers,
>> depending on SOC memory plan and hence will require own platform drivers.
>>
>> If more details on phy registers are required, an interface document is
>> hosted at https://arasan.com/NF/eMMC5.1 PHY Programming in Linux.pdf.
>>
>> Signed-off-by: Atul Garg 
>> ---
>>  drivers/mmc/host/Makefile   |  18 +-
>>  drivers/mmc/host/sdhci-pci-arasan.c | 325 
>> 
>>  drivers/mmc/host/sdhci-pci-arasan.h |  80 +
>>  drivers/mmc/host/sdhci-pci-core.c   |  16 ++
>>  drivers/mmc/host/sdhci-pci.h|   4 +
>>  5 files changed, 431 insertions(+), 12 deletions(-)
>>  create mode 100644 drivers/mmc/host/sdhci-pci-arasan.c
>>  create mode 100644 drivers/mmc/host/sdhci-pci-arasan.h
>>
>> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
>> index 2b5a813..b9b2c6c 100644
>> --- a/drivers/mmc/host/Makefile
>> +++ b/drivers/mmc/host/Makefile
>> @@ -2,15 +2,14 @@
>>  # Makefile for MMC/SD host controller drivers
>>  #
>>
>> -obj-$(CONFIG_MMC_ARMMMCI) += armmmci.o
>> -armmmci-y := mmci.o
>> -armmmci-$(CONFIG_MMC_QCOM_DML) += mmci_qcom_dml.o
>> +obj-$(CONFIG_MMC_ARMMMCI)+= mmci.o
>> +obj-$(CONFIG_MMC_QCOM_DML)   += mmci_qcom_dml.o
>
> These look like stray changes unrelated to this patch?

Yes will take care of them

>
>>  obj-$(CONFIG_MMC_PXA)+= pxamci.o
>>  obj-$(CONFIG_MMC_MXC)+= mxcmmc.o
>>  obj-$(CONFIG_MMC_MXS)+= mxs-mmc.o
>>  obj-$(CONFIG_MMC_SDHCI)  += sdhci.o
>>  obj-$(CONFIG_MMC_SDHCI_PCI)  += sdhci-pci.o
>> -sdhci-pci-y  += sdhci-pci-core.o sdhci-pci-o2micro.o
>> +sdhci-pci-y  += sdhci-pci-core.o sdhci-pci-o2micro.o 
>> sdhci-pci-arasan.o
>>  obj-$(subst m,y,$(CONFIG_MMC_SDHCI_PCI)) += sdhci-pci-data.o
>>  obj-$(CONFIG_MMC_SDHCI_ACPI) += sdhci-acpi.o
>>  obj-$(CONFIG_MMC_SDHCI_PXAV3)+= sdhci-pxav3.o
>> @@ -37,13 +36,9 @@ obj-$(CONFIG_MMC_S3C)  += s3cmci.o
>>  obj-$(CONFIG_MMC_SDRICOH_CS) += sdricoh_cs.o
>>  obj-$(CONFIG_MMC_TMIO)   += tmio_mmc.o
>>  obj-$(CONFIG_MMC_TMIO_CORE)  += tmio_mmc_core.o
>> -obj-$(CONFIG_MMC_SDHI)   += renesas_sdhi_core.o
>> -ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_SYS_DMAC)),y)
>> -obj-$(CONFIG_MMC_SDHI)   += renesas_sdhi_sys_dmac.o
>> -endif
>> -ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_INTERNAL_DMAC)),y)
>> -obj-$(CONFIG_MMC_SDHI)   += renesas_sdhi_internal_dmac.o
>> -endif
>> +tmio_mmc_core-y  := tmio_mmc_pio.o
>> +tmio_mmc_core-$(subst m,y,$(CONFIG_MMC_SDHI))+= tmio_mmc_dma.o
>> +obj-$(CONFIG_MMC_SDHI)   += sh_mobile_sdhi.o
>
> These too look unrelated to $SUBJECT

will take care of them

>
>>  obj-$(CONFIG_MMC_CB710)  += cb710-mmc.o
>>  obj-$(CONFIG_MMC_VIA_SDMMC)  += via-sdmmc.o
>>  obj-$(CONFIG_SDH_BFIN)   += bfin_sdh.o
>> @@ -89,7 +84,6 @@ obj-$(CONFIG_MMC_SDHCI_MSM) += sdhci-msm.o
>>  obj-$(CONFIG_MMC_SDHCI_ST)   += sdhci-st.o
>>  obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32)  += sdhci-pic32.o
>>  obj-$(CONFIG_MMC_SDHCI_BRCMSTB)  += sdhci-brcmstb.o
>> -obj-$(CONFIG_MMC_SDHCI_OMAP) += sdhci-omap.o
>
> This too is unrelated.

will take care of them

>
>>
>>  ifeq ($(CONFIG_CB710_DEBUG),y)
>>   CFLAGS-cb710-mmc+= -DDEBUG
>> diff --git a/drivers/mmc/host/sdhci-pci-arasan.c 
>> b/drivers/mmc/host/sdhci-pci-arasan.c
>> new file mode 100644
>> index 000..57fbf8f
>> --- /dev/null
>> +++ b/drivers/mmc/host/sdhci-pci-arasan.c
>> @@ -0,0 +1,325 @@
>> +/*
>> + * Copyright (C) 2017 Arasan Chip Systems Inc.,
>> + *
>> + * Authors: Atul Garg 
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +#include "sdhci.h"
>> +#include "sdhci-pci.h"
>> +#include "sdhci-pci-arasan.h"
>> +
>> +static int 

Re: [PATCH] mmc:host:sdhci-pci:V2-Addition of Arasan PCI controller with integrated phy.

[Atul Garg]

Hi Sekhar,
Thanks for comments.

On Wed, Oct 11, 2017 at 7:23 AM, Sekhar Nori  wrote:
> Hi Atul,
>
> On Tuesday 10 October 2017 11:12 PM, Atul Garg wrote:
>> The Arasan controller is based on a FPGA platform and has integrated phy
>> with specific phy registers used during the initialization and
>> management of different modes. The phy and the controller are integrated
>> and registers are very specific to Arasan.
>>
>> Arasan being an IP provider, licenses these IPs to various companies for
>> integration of IP in custom SOCs. The custom SOCs define own register
>> map depending on how bits are tied inside the SOC for phy registers,
>> depending on SOC memory plan and hence will require own platform drivers.
>>
>> If more details on phy registers are required, an interface document is
>> hosted at https://arasan.com/NF/eMMC5.1 PHY Programming in Linux.pdf.
>>
>> Signed-off-by: Atul Garg 
>> ---
>>  drivers/mmc/host/Makefile   |  18 +-
>>  drivers/mmc/host/sdhci-pci-arasan.c | 325 
>> 
>>  drivers/mmc/host/sdhci-pci-arasan.h |  80 +
>>  drivers/mmc/host/sdhci-pci-core.c   |  16 ++
>>  drivers/mmc/host/sdhci-pci.h|   4 +
>>  5 files changed, 431 insertions(+), 12 deletions(-)
>>  create mode 100644 drivers/mmc/host/sdhci-pci-arasan.c
>>  create mode 100644 drivers/mmc/host/sdhci-pci-arasan.h
>>
>> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
>> index 2b5a813..b9b2c6c 100644
>> --- a/drivers/mmc/host/Makefile
>> +++ b/drivers/mmc/host/Makefile
>> @@ -2,15 +2,14 @@
>>  # Makefile for MMC/SD host controller drivers
>>  #
>>
>> -obj-$(CONFIG_MMC_ARMMMCI) += armmmci.o
>> -armmmci-y := mmci.o
>> -armmmci-$(CONFIG_MMC_QCOM_DML) += mmci_qcom_dml.o
>> +obj-$(CONFIG_MMC_ARMMMCI)+= mmci.o
>> +obj-$(CONFIG_MMC_QCOM_DML)   += mmci_qcom_dml.o
>
> These look like stray changes unrelated to this patch?

Yes will take care of them

>
>>  obj-$(CONFIG_MMC_PXA)+= pxamci.o
>>  obj-$(CONFIG_MMC_MXC)+= mxcmmc.o
>>  obj-$(CONFIG_MMC_MXS)+= mxs-mmc.o
>>  obj-$(CONFIG_MMC_SDHCI)  += sdhci.o
>>  obj-$(CONFIG_MMC_SDHCI_PCI)  += sdhci-pci.o
>> -sdhci-pci-y  += sdhci-pci-core.o sdhci-pci-o2micro.o
>> +sdhci-pci-y  += sdhci-pci-core.o sdhci-pci-o2micro.o 
>> sdhci-pci-arasan.o
>>  obj-$(subst m,y,$(CONFIG_MMC_SDHCI_PCI)) += sdhci-pci-data.o
>>  obj-$(CONFIG_MMC_SDHCI_ACPI) += sdhci-acpi.o
>>  obj-$(CONFIG_MMC_SDHCI_PXAV3)+= sdhci-pxav3.o
>> @@ -37,13 +36,9 @@ obj-$(CONFIG_MMC_S3C)  += s3cmci.o
>>  obj-$(CONFIG_MMC_SDRICOH_CS) += sdricoh_cs.o
>>  obj-$(CONFIG_MMC_TMIO)   += tmio_mmc.o
>>  obj-$(CONFIG_MMC_TMIO_CORE)  += tmio_mmc_core.o
>> -obj-$(CONFIG_MMC_SDHI)   += renesas_sdhi_core.o
>> -ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_SYS_DMAC)),y)
>> -obj-$(CONFIG_MMC_SDHI)   += renesas_sdhi_sys_dmac.o
>> -endif
>> -ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_INTERNAL_DMAC)),y)
>> -obj-$(CONFIG_MMC_SDHI)   += renesas_sdhi_internal_dmac.o
>> -endif
>> +tmio_mmc_core-y  := tmio_mmc_pio.o
>> +tmio_mmc_core-$(subst m,y,$(CONFIG_MMC_SDHI))+= tmio_mmc_dma.o
>> +obj-$(CONFIG_MMC_SDHI)   += sh_mobile_sdhi.o
>
> These too look unrelated to $SUBJECT

will take care of them

>
>>  obj-$(CONFIG_MMC_CB710)  += cb710-mmc.o
>>  obj-$(CONFIG_MMC_VIA_SDMMC)  += via-sdmmc.o
>>  obj-$(CONFIG_SDH_BFIN)   += bfin_sdh.o
>> @@ -89,7 +84,6 @@ obj-$(CONFIG_MMC_SDHCI_MSM) += sdhci-msm.o
>>  obj-$(CONFIG_MMC_SDHCI_ST)   += sdhci-st.o
>>  obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32)  += sdhci-pic32.o
>>  obj-$(CONFIG_MMC_SDHCI_BRCMSTB)  += sdhci-brcmstb.o
>> -obj-$(CONFIG_MMC_SDHCI_OMAP) += sdhci-omap.o
>
> This too is unrelated.

will take care of them

>
>>
>>  ifeq ($(CONFIG_CB710_DEBUG),y)
>>   CFLAGS-cb710-mmc+= -DDEBUG
>> diff --git a/drivers/mmc/host/sdhci-pci-arasan.c 
>> b/drivers/mmc/host/sdhci-pci-arasan.c
>> new file mode 100644
>> index 000..57fbf8f
>> --- /dev/null
>> +++ b/drivers/mmc/host/sdhci-pci-arasan.c
>> @@ -0,0 +1,325 @@
>> +/*
>> + * Copyright (C) 2017 Arasan Chip Systems Inc.,
>> + *
>> + * Authors: Atul Garg 
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +#include "sdhci.h"
>> +#include "sdhci-pci.h"
>> +#include "sdhci-pci-arasan.h"
>> +
>> +static int arasan_phy_write(struct sdhci_host *host, u8 data, u8 

[PATCH V1 2/2] usb: serial: f81534: Implement break control

[Ji-Ze Hong (Peter Hong)]

Implement Fintek f81534 break on/off with LCR register.
It's the same with 16550A LCR register layout.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81534.c | 46 +++--
 1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index 3f47afa..9ea407d 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -128,11 +128,13 @@ struct f81534_serial_private {
 
 struct f81534_port_private {
struct mutex mcr_mutex;
+   struct mutex lcr_mutex;
struct work_struct lsr_work;
struct usb_serial_port *port;
unsigned long tx_empty;
spinlock_t msr_lock;
u8 shadow_mcr;
+   u8 shadow_lcr;
u8 shadow_msr;
u8 phy_num;
 };
@@ -465,6 +467,7 @@ static u32 f81534_calc_baud_divisor(u32 baudrate, u32 
clockrate)
 static int f81534_set_port_config(struct usb_serial_port *port, u32 baudrate,
u8 lcr)
 {
+   struct f81534_port_private *port_priv = usb_get_serial_port_data(port);
u32 divisor;
int status;
u8 value;
@@ -493,35 +496,64 @@ static int f81534_set_port_config(struct usb_serial_port 
*port, u32 baudrate,
}
 
divisor = f81534_calc_baud_divisor(baudrate, F81534_MAX_BAUDRATE);
+
+   mutex_lock(_priv->lcr_mutex);
+
value = UART_LCR_DLAB;
status = f81534_set_port_register(port, F81534_LINE_CONTROL_REG,
value);
if (status) {
dev_err(>dev, "%s: set LCR failed\n", __func__);
-   return status;
+   goto final;
}
 
value = divisor & 0xff;
status = f81534_set_port_register(port, F81534_DIVISOR_LSB_REG, value);
if (status) {
dev_err(>dev, "%s: set DLAB LSB failed\n", __func__);
-   return status;
+   goto final;
}
 
value = (divisor >> 8) & 0xff;
status = f81534_set_port_register(port, F81534_DIVISOR_MSB_REG, value);
if (status) {
dev_err(>dev, "%s: set DLAB MSB failed\n", __func__);
-   return status;
+   goto final;
}
 
-   status = f81534_set_port_register(port, F81534_LINE_CONTROL_REG, lcr);
+   value = lcr | (port_priv->shadow_lcr & UART_LCR_SBC);
+   status = f81534_set_port_register(port, F81534_LINE_CONTROL_REG,
+   value);
if (status) {
dev_err(>dev, "%s: set LCR failed\n", __func__);
-   return status;
+   goto final;
}
 
-   return 0;
+   port_priv->shadow_lcr = value;
+final:
+   mutex_unlock(_priv->lcr_mutex);
+   return status;
+}
+
+static void f81534_break_ctl(struct tty_struct *tty, int break_state)
+{
+   struct usb_serial_port *port = tty->driver_data;
+   struct f81534_port_private *port_priv = usb_get_serial_port_data(port);
+   int status;
+
+   mutex_lock(_priv->lcr_mutex);
+
+   if (break_state)
+   port_priv->shadow_lcr |= UART_LCR_SBC;
+   else
+   port_priv->shadow_lcr &= ~UART_LCR_SBC;
+
+   status = f81534_set_port_register(port, F81534_LINE_CONTROL_REG,
+   port_priv->shadow_lcr);
+   if (status)
+   dev_err(>dev, "set break failed: %x\n", status);
+
+   mutex_unlock(_priv->lcr_mutex);
 }
 
 static int f81534_update_mctrl(struct usb_serial_port *port, unsigned int set,
@@ -1193,6 +1225,7 @@ static int f81534_port_probe(struct usb_serial_port *port)
 
spin_lock_init(_priv->msr_lock);
mutex_init(_priv->mcr_mutex);
+   mutex_init(_priv->lcr_mutex);
INIT_WORK(_priv->lsr_work, f81534_lsr_worker);
 
/* Assign logic-to-phy mapping */
@@ -1359,6 +1392,7 @@ static struct usb_serial_driver f81534_device = {
.attach =   f81534_attach,
.port_probe =   f81534_port_probe,
.port_remove =  f81534_port_remove,
+   .break_ctl =f81534_break_ctl,
.dtr_rts =  f81534_dtr_rts,
.process_read_urb = f81534_process_read_urb,
.ioctl =f81534_ioctl,
-- 
2.7.4

[PATCH V1 2/2] usb: serial: f81534: Implement break control

[Ji-Ze Hong (Peter Hong)]

Implement Fintek f81534 break on/off with LCR register.
It's the same with 16550A LCR register layout.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81534.c | 46 +++--
 1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index 3f47afa..9ea407d 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -128,11 +128,13 @@ struct f81534_serial_private {
 
 struct f81534_port_private {
struct mutex mcr_mutex;
+   struct mutex lcr_mutex;
struct work_struct lsr_work;
struct usb_serial_port *port;
unsigned long tx_empty;
spinlock_t msr_lock;
u8 shadow_mcr;
+   u8 shadow_lcr;
u8 shadow_msr;
u8 phy_num;
 };
@@ -465,6 +467,7 @@ static u32 f81534_calc_baud_divisor(u32 baudrate, u32 
clockrate)
 static int f81534_set_port_config(struct usb_serial_port *port, u32 baudrate,
u8 lcr)
 {
+   struct f81534_port_private *port_priv = usb_get_serial_port_data(port);
u32 divisor;
int status;
u8 value;
@@ -493,35 +496,64 @@ static int f81534_set_port_config(struct usb_serial_port 
*port, u32 baudrate,
}
 
divisor = f81534_calc_baud_divisor(baudrate, F81534_MAX_BAUDRATE);
+
+   mutex_lock(_priv->lcr_mutex);
+
value = UART_LCR_DLAB;
status = f81534_set_port_register(port, F81534_LINE_CONTROL_REG,
value);
if (status) {
dev_err(>dev, "%s: set LCR failed\n", __func__);
-   return status;
+   goto final;
}
 
value = divisor & 0xff;
status = f81534_set_port_register(port, F81534_DIVISOR_LSB_REG, value);
if (status) {
dev_err(>dev, "%s: set DLAB LSB failed\n", __func__);
-   return status;
+   goto final;
}
 
value = (divisor >> 8) & 0xff;
status = f81534_set_port_register(port, F81534_DIVISOR_MSB_REG, value);
if (status) {
dev_err(>dev, "%s: set DLAB MSB failed\n", __func__);
-   return status;
+   goto final;
}
 
-   status = f81534_set_port_register(port, F81534_LINE_CONTROL_REG, lcr);
+   value = lcr | (port_priv->shadow_lcr & UART_LCR_SBC);
+   status = f81534_set_port_register(port, F81534_LINE_CONTROL_REG,
+   value);
if (status) {
dev_err(>dev, "%s: set LCR failed\n", __func__);
-   return status;
+   goto final;
}
 
-   return 0;
+   port_priv->shadow_lcr = value;
+final:
+   mutex_unlock(_priv->lcr_mutex);
+   return status;
+}
+
+static void f81534_break_ctl(struct tty_struct *tty, int break_state)
+{
+   struct usb_serial_port *port = tty->driver_data;
+   struct f81534_port_private *port_priv = usb_get_serial_port_data(port);
+   int status;
+
+   mutex_lock(_priv->lcr_mutex);
+
+   if (break_state)
+   port_priv->shadow_lcr |= UART_LCR_SBC;
+   else
+   port_priv->shadow_lcr &= ~UART_LCR_SBC;
+
+   status = f81534_set_port_register(port, F81534_LINE_CONTROL_REG,
+   port_priv->shadow_lcr);
+   if (status)
+   dev_err(>dev, "set break failed: %x\n", status);
+
+   mutex_unlock(_priv->lcr_mutex);
 }
 
 static int f81534_update_mctrl(struct usb_serial_port *port, unsigned int set,
@@ -1193,6 +1225,7 @@ static int f81534_port_probe(struct usb_serial_port *port)
 
spin_lock_init(_priv->msr_lock);
mutex_init(_priv->mcr_mutex);
+   mutex_init(_priv->lcr_mutex);
INIT_WORK(_priv->lsr_work, f81534_lsr_worker);
 
/* Assign logic-to-phy mapping */
@@ -1359,6 +1392,7 @@ static struct usb_serial_driver f81534_device = {
.attach =   f81534_attach,
.port_probe =   f81534_port_probe,
.port_remove =  f81534_port_remove,
+   .break_ctl =f81534_break_ctl,
.dtr_rts =  f81534_dtr_rts,
.process_read_urb = f81534_process_read_urb,
.ioctl =f81534_ioctl,
-- 
2.7.4

[PATCH V1 1/2] usb: serial: f81534: fix hang-up on overrun

[Ji-Ze Hong (Peter Hong)]

The F81532/534 without this patch will hang-up on data overrun.

It's caused by enable LSR interrupt in IER by default and occur data
overrun, the chip will busy for process LSR interrupt but not read LSR
internally. It will not responed for USB control endpoint0 and we can't
read LSR from driver in this situration.

So we'll disable the LSR interrupt in probe() and submit the LSR worker to
clear LSR state when reported LSR error bit with bulk-in data in
f81534_process_per_serial_block().

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81534.c | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index 3d616a2..3f47afa 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -39,9 +39,11 @@
 #define F81534_UART_OFFSET 0x10
 #define F81534_DIVISOR_LSB_REG (0x00 + F81534_UART_BASE_ADDRESS)
 #define F81534_DIVISOR_MSB_REG (0x01 + F81534_UART_BASE_ADDRESS)
+#define F81534_INTERRUPT_ENABLE_REG(0x01 + F81534_UART_BASE_ADDRESS)
 #define F81534_FIFO_CONTROL_REG(0x02 + 
F81534_UART_BASE_ADDRESS)
 #define F81534_LINE_CONTROL_REG(0x03 + 
F81534_UART_BASE_ADDRESS)
 #define F81534_MODEM_CONTROL_REG   (0x04 + F81534_UART_BASE_ADDRESS)
+#define F81534_LINE_STATUS_REG (0x05 + F81534_UART_BASE_ADDRESS)
 #define F81534_MODEM_STATUS_REG(0x06 + 
F81534_UART_BASE_ADDRESS)
 #define F81534_CONFIG1_REG (0x09 + F81534_UART_BASE_ADDRESS)
 
@@ -126,6 +128,8 @@ struct f81534_serial_private {
 
 struct f81534_port_private {
struct mutex mcr_mutex;
+   struct work_struct lsr_work;
+   struct usb_serial_port *port;
unsigned long tx_empty;
spinlock_t msr_lock;
u8 shadow_mcr;
@@ -1015,6 +1019,8 @@ static void f81534_process_per_serial_block(struct 
usb_serial_port *port,
tty_insert_flip_char(>port, 0,
TTY_OVERRUN);
}
+
+   schedule_work(_priv->lsr_work);
}
 
if (port->port.console && port->sysrq) {
@@ -1162,6 +1168,20 @@ static int f81534_attach(struct usb_serial *serial)
return 0;
 }
 
+static void f81534_lsr_worker(struct work_struct *work)
+{
+   struct f81534_port_private *port_priv =
+   container_of(work, struct f81534_port_private,
+   lsr_work);
+   struct usb_serial_port *port = port_priv->port;
+   int status;
+   u8 tmp;
+
+   status = f81534_get_port_register(port, F81534_LINE_STATUS_REG, );
+   if (status)
+   dev_warn(>dev, "read LSR failed: %x\n", status);
+}
+
 static int f81534_port_probe(struct usb_serial_port *port)
 {
struct f81534_port_private *port_priv;
@@ -1173,6 +1193,7 @@ static int f81534_port_probe(struct usb_serial_port *port)
 
spin_lock_init(_priv->msr_lock);
mutex_init(_priv->mcr_mutex);
+   INIT_WORK(_priv->lsr_work, f81534_lsr_worker);
 
/* Assign logic-to-phy mapping */
ret = f81534_logic_to_phy_port(port->serial, port);
@@ -1180,10 +1201,30 @@ static int f81534_port_probe(struct usb_serial_port 
*port)
return ret;
 
port_priv->phy_num = ret;
+   port_priv->port = port;
usb_set_serial_port_data(port, port_priv);
dev_dbg(>dev, "%s: port_number: %d, phy_num: %d\n", __func__,
port->port_number, port_priv->phy_num);
 
+   /*
+* The F81532/534 will hang-up when enable LSR interrupt in IER and
+* occur data overrun. So we'll disable the LSR interrupt in probe()
+* and submit the LSR worker to clear LSR state when reported LSR error
+* bit with bulk-in data in f81534_process_per_serial_block().
+*/
+   ret = f81534_set_port_register(port, F81534_INTERRUPT_ENABLE_REG,
+   UART_IER_RDI | UART_IER_THRI | UART_IER_MSI);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int f81534_port_remove(struct usb_serial_port *port)
+{
+   struct f81534_port_private *port_priv = usb_get_serial_port_data(port);
+
+   flush_work(_priv->lsr_work);
return 0;
 }
 
@@ -1317,6 +1358,7 @@ static struct usb_serial_driver f81534_device = {
.calc_num_ports =   f81534_calc_num_ports,
.attach =   f81534_attach,
.port_probe =   f81534_port_probe,
+   .port_remove =  f81534_port_remove,
.dtr_rts =  f81534_dtr_rts,
.process_read_urb = f81534_process_read_urb,
.ioctl =f81534_ioctl,
-- 
2.7.4

[PATCH V1 1/2] usb: serial: f81534: fix hang-up on overrun

[Ji-Ze Hong (Peter Hong)]

The F81532/534 without this patch will hang-up on data overrun.

It's caused by enable LSR interrupt in IER by default and occur data
overrun, the chip will busy for process LSR interrupt but not read LSR
internally. It will not responed for USB control endpoint0 and we can't
read LSR from driver in this situration.

So we'll disable the LSR interrupt in probe() and submit the LSR worker to
clear LSR state when reported LSR error bit with bulk-in data in
f81534_process_per_serial_block().

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81534.c | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index 3d616a2..3f47afa 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -39,9 +39,11 @@
 #define F81534_UART_OFFSET 0x10
 #define F81534_DIVISOR_LSB_REG (0x00 + F81534_UART_BASE_ADDRESS)
 #define F81534_DIVISOR_MSB_REG (0x01 + F81534_UART_BASE_ADDRESS)
+#define F81534_INTERRUPT_ENABLE_REG(0x01 + F81534_UART_BASE_ADDRESS)
 #define F81534_FIFO_CONTROL_REG(0x02 + 
F81534_UART_BASE_ADDRESS)
 #define F81534_LINE_CONTROL_REG(0x03 + 
F81534_UART_BASE_ADDRESS)
 #define F81534_MODEM_CONTROL_REG   (0x04 + F81534_UART_BASE_ADDRESS)
+#define F81534_LINE_STATUS_REG (0x05 + F81534_UART_BASE_ADDRESS)
 #define F81534_MODEM_STATUS_REG(0x06 + 
F81534_UART_BASE_ADDRESS)
 #define F81534_CONFIG1_REG (0x09 + F81534_UART_BASE_ADDRESS)
 
@@ -126,6 +128,8 @@ struct f81534_serial_private {
 
 struct f81534_port_private {
struct mutex mcr_mutex;
+   struct work_struct lsr_work;
+   struct usb_serial_port *port;
unsigned long tx_empty;
spinlock_t msr_lock;
u8 shadow_mcr;
@@ -1015,6 +1019,8 @@ static void f81534_process_per_serial_block(struct 
usb_serial_port *port,
tty_insert_flip_char(>port, 0,
TTY_OVERRUN);
}
+
+   schedule_work(_priv->lsr_work);
}
 
if (port->port.console && port->sysrq) {
@@ -1162,6 +1168,20 @@ static int f81534_attach(struct usb_serial *serial)
return 0;
 }
 
+static void f81534_lsr_worker(struct work_struct *work)
+{
+   struct f81534_port_private *port_priv =
+   container_of(work, struct f81534_port_private,
+   lsr_work);
+   struct usb_serial_port *port = port_priv->port;
+   int status;
+   u8 tmp;
+
+   status = f81534_get_port_register(port, F81534_LINE_STATUS_REG, );
+   if (status)
+   dev_warn(>dev, "read LSR failed: %x\n", status);
+}
+
 static int f81534_port_probe(struct usb_serial_port *port)
 {
struct f81534_port_private *port_priv;
@@ -1173,6 +1193,7 @@ static int f81534_port_probe(struct usb_serial_port *port)
 
spin_lock_init(_priv->msr_lock);
mutex_init(_priv->mcr_mutex);
+   INIT_WORK(_priv->lsr_work, f81534_lsr_worker);
 
/* Assign logic-to-phy mapping */
ret = f81534_logic_to_phy_port(port->serial, port);
@@ -1180,10 +1201,30 @@ static int f81534_port_probe(struct usb_serial_port 
*port)
return ret;
 
port_priv->phy_num = ret;
+   port_priv->port = port;
usb_set_serial_port_data(port, port_priv);
dev_dbg(>dev, "%s: port_number: %d, phy_num: %d\n", __func__,
port->port_number, port_priv->phy_num);
 
+   /*
+* The F81532/534 will hang-up when enable LSR interrupt in IER and
+* occur data overrun. So we'll disable the LSR interrupt in probe()
+* and submit the LSR worker to clear LSR state when reported LSR error
+* bit with bulk-in data in f81534_process_per_serial_block().
+*/
+   ret = f81534_set_port_register(port, F81534_INTERRUPT_ENABLE_REG,
+   UART_IER_RDI | UART_IER_THRI | UART_IER_MSI);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int f81534_port_remove(struct usb_serial_port *port)
+{
+   struct f81534_port_private *port_priv = usb_get_serial_port_data(port);
+
+   flush_work(_priv->lsr_work);
return 0;
 }
 
@@ -1317,6 +1358,7 @@ static struct usb_serial_driver f81534_device = {
.calc_num_ports =   f81534_calc_num_ports,
.attach =   f81534_attach,
.port_probe =   f81534_port_probe,
+   .port_remove =  f81534_port_remove,
.dtr_rts =  f81534_dtr_rts,
.process_read_urb = f81534_process_read_urb,
.ioctl =f81534_ioctl,
-- 
2.7.4

[PATCH] f2fs: avoid stale fi->gdirty_list pointer

[Jaegeuk Kim]

When doing fault injection test, f2fs_evict_inode() didn't remove gdirty_list
which incurs a kernel panic due to wrong pointer access.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/inode.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index f6db9d533ca4..1ae5396c97d6 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -535,6 +535,8 @@ void f2fs_evict_inode(struct inode *inode)
 
if (!is_set_ckpt_flags(sbi, CP_ERROR_FLAG))
f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE));
+   else
+   f2fs_inode_synced(inode);
 
/* ino == 0, if f2fs_new_inode() was failed t*/
if (inode->i_ino)
-- 
2.14.0.rc1.383.gd1ce394fe2-goog

[PATCH] f2fs: avoid stale fi->gdirty_list pointer

[Jaegeuk Kim]

When doing fault injection test, f2fs_evict_inode() didn't remove gdirty_list
which incurs a kernel panic due to wrong pointer access.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/inode.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index f6db9d533ca4..1ae5396c97d6 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -535,6 +535,8 @@ void f2fs_evict_inode(struct inode *inode)
 
if (!is_set_ckpt_flags(sbi, CP_ERROR_FLAG))
f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE));
+   else
+   f2fs_inode_synced(inode);
 
/* ino == 0, if f2fs_new_inode() was failed t*/
if (inode->i_ino)
-- 
2.14.0.rc1.383.gd1ce394fe2-goog

Re: [PATCH net-next 1/2] mqprio: Add a new hardware offload type in mqprio

[Yunsheng Lin]

Hi, Yuval

On 2017/10/13 4:10, Yuval Mintz wrote:
>> When a driver supports both dcb and hardware offloaded mqprio, and
>> user is running mqprio and dcb tool concurrently, the configuration
>> set by each tool may be conflicted with each other because the dcb
> (for second 'each') s/each/the
> 

Will do, Thanks

>> and mqprio may be using the same hardwere offload component and share
> s/hardwere/hardware

Will do, Thanks

> 
>> the tc system in the network stack.
>>
>> This patch adds a new offload type to indicate that the underlying
>> driver offload prio mapping as part of DCB. If the driver would be
> 'should' offload

Will do, Thanks

> 
>> incapable of that it would refuse the offload. User would then have
>> to explicitly request that qdisc offload.
> 
> 
> 

Re: [PATCH net-next 1/2] mqprio: Add a new hardware offload type in mqprio

[Yunsheng Lin]

Hi, Yuval

On 2017/10/13 4:10, Yuval Mintz wrote:
>> When a driver supports both dcb and hardware offloaded mqprio, and
>> user is running mqprio and dcb tool concurrently, the configuration
>> set by each tool may be conflicted with each other because the dcb
> (for second 'each') s/each/the
> 

Will do, Thanks

>> and mqprio may be using the same hardwere offload component and share
> s/hardwere/hardware

Will do, Thanks

> 
>> the tc system in the network stack.
>>
>> This patch adds a new offload type to indicate that the underlying
>> driver offload prio mapping as part of DCB. If the driver would be
> 'should' offload

Will do, Thanks

> 
>> incapable of that it would refuse the offload. User would then have
>> to explicitly request that qdisc offload.
> 
> 
> 

Re: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver

[Yunsheng Lin]

Hi, Yuval

On 2017/10/13 4:21, Yuval Mintz wrote:
>> This patchset adds a new hardware offload type in mqprio before adding
>> mqprio hardware offload support in hns3 driver.
> 
> I think one of the biggest issues in tying this to DCB configuration is the
> non-immediate [and possibly non persistent] configuration.
> 
> Scenario #1:
> User is configuring mqprio offloaded with 3 TCs while device is in willing 
> mode.
> Would you expect the driver to immediately respond with a success or instead
> delay the return until the DCBx negotiation is complete and the operational
> num of TCs is actually 3?

Well, when user requsts the mqprio offloaded by a hardware shared by DCB, I 
expect
the user is not using the dcb tool.
If user is still using dcb tool, then result is undefined.

The scenario you mention maybe can be enforced by setting willing to zero when 
user
is requesting the mqprio offload, and restore the willing bit when unloaded the 
mqprio
offload.
But I think the real issue is that dcb and mqprio shares the tc system in the 
stack,
the problem may be better to be fixed in the stack rather than in the driver, 
as you
suggested in the DCB patchset. What do you think?

> 
> Scenario #2:
> Assume user explicitly offloaded mqprio with 3 TCs, but now DCB configuration
> has changed on the peer side and 4 TCs is the new negotiated operational 
> value.
> Your current driver logic would change the number of TCs underneath the user
> configuration [and it would actually probably work due to mqprio being a 
> crappy
> qdisc]. But was that the user actual intention?
> [I think the likely answer in this scenario is 'yes' since the alternative is 
> no better.
> But I still thought it was worth mentioning]

You are right, the problem also have something to do with mqprio and dcb sharing
the tc in the stack.

Druing testing, when user explicitly offloaded mqprio with 3 TCs, all
queue has a default pfifo mqprio attached, after DCB changes the tc num to 4,
using tc qdisc shows some queue does not have a default pfifo mqprio attached.

Maybe we can add a callback to notify mqprio the configuration has changed.

Thanks
Yunsheng Lin

> 
> Cheers,
> Yuval
> 
>>
>> Yunsheng Lin (2):
>>   mqprio: Add a new hardware offload type in mqprio
>>   net: hns3: Add mqprio hardware offload support in hns3 driver
>>
>>  drivers/net/ethernet/hisilicon/hns3/hnae3.h|  1 +
>>  .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++
>>  .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46 ++-
>> ---
>>  include/uapi/linux/pkt_sched.h |  1 +
>>  4 files changed, 55 insertions(+), 16 deletions(-)
>>
>> --
>> 1.9.1
> 
> 
> 

Re: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver

[Yunsheng Lin]

Hi, Yuval

On 2017/10/13 4:21, Yuval Mintz wrote:
>> This patchset adds a new hardware offload type in mqprio before adding
>> mqprio hardware offload support in hns3 driver.
> 
> I think one of the biggest issues in tying this to DCB configuration is the
> non-immediate [and possibly non persistent] configuration.
> 
> Scenario #1:
> User is configuring mqprio offloaded with 3 TCs while device is in willing 
> mode.
> Would you expect the driver to immediately respond with a success or instead
> delay the return until the DCBx negotiation is complete and the operational
> num of TCs is actually 3?

Well, when user requsts the mqprio offloaded by a hardware shared by DCB, I 
expect
the user is not using the dcb tool.
If user is still using dcb tool, then result is undefined.

The scenario you mention maybe can be enforced by setting willing to zero when 
user
is requesting the mqprio offload, and restore the willing bit when unloaded the 
mqprio
offload.
But I think the real issue is that dcb and mqprio shares the tc system in the 
stack,
the problem may be better to be fixed in the stack rather than in the driver, 
as you
suggested in the DCB patchset. What do you think?

> 
> Scenario #2:
> Assume user explicitly offloaded mqprio with 3 TCs, but now DCB configuration
> has changed on the peer side and 4 TCs is the new negotiated operational 
> value.
> Your current driver logic would change the number of TCs underneath the user
> configuration [and it would actually probably work due to mqprio being a 
> crappy
> qdisc]. But was that the user actual intention?
> [I think the likely answer in this scenario is 'yes' since the alternative is 
> no better.
> But I still thought it was worth mentioning]

You are right, the problem also have something to do with mqprio and dcb sharing
the tc in the stack.

Druing testing, when user explicitly offloaded mqprio with 3 TCs, all
queue has a default pfifo mqprio attached, after DCB changes the tc num to 4,
using tc qdisc shows some queue does not have a default pfifo mqprio attached.

Maybe we can add a callback to notify mqprio the configuration has changed.

Thanks
Yunsheng Lin

> 
> Cheers,
> Yuval
> 
>>
>> Yunsheng Lin (2):
>>   mqprio: Add a new hardware offload type in mqprio
>>   net: hns3: Add mqprio hardware offload support in hns3 driver
>>
>>  drivers/net/ethernet/hisilicon/hns3/hnae3.h|  1 +
>>  .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++
>>  .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46 ++-
>> ---
>>  include/uapi/linux/pkt_sched.h |  1 +
>>  4 files changed, 55 insertions(+), 16 deletions(-)
>>
>> --
>> 1.9.1
> 
> 
> 

[lkp-robot] [tools] a45112af2b: stderr.util/symbol.c:#:#:error:implicit_declaration_of_function'rb_erase_init';did_you_mean'rb_erase'?[-Werror=implicit-function-declaration]

[kernel test robot]

FYI, we noticed the following commit (built with gcc-6):

commit: a45112af2bdfb51c42a89d181147776b0e4a631e ("tools: Update rbtree files")
url: 
https://github.com/0day-ci/linux/commits/David-Ahern/tools-Update-rbtree-files/20171001-202148


in testcase: perf-sanity-tests
with following parameters:




on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


[   71.717428] util/symbol.c: In function 'dso__split_kallsyms_for_kcore':
[   71.717434] 
[   71.724793] util/symbol.c:713:3: error: implicit declaration of function 
'rb_erase_init'; did you mean 'rb_erase'? 
[-Werror=implicit-function-declaration]
[   71.724796] 
[   71.737088]rb_erase_init(>rb_node, _root);
[   71.737092] 
[   71.739473]^
[   71.739475] 
[   71.757873]rb_erase
[   71.757888] 
[   71.772929] util/symbol.c:713:3: error: nested extern declaration of 
'rb_erase_init' [-Werror=nested-externs]
[   71.772935] 
[   71.858097]   CC   builtin-kmem.o
[   71.858125] 
[   72.905235] cc1: all warnings being treated as errors
[   72.905241] 
[   72.916127] mv: cannot stat 'util/.symbol.o.tmp': No such file or directory
[   72.916131] 
[   72.922305] make[4]: *** [util/symbol.o] Error 1
[   72.922309] 
[   72.925182] make[3]: *** [util] Error 2
[   72.925184] 
[   72.927779] make[2]: *** [libperf-in.o] Error 2
[   72.927781] 
[   72.934104] make[2]: *** Waiting for unfinished jobs


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.14.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set

[lkp-robot] [tools] a45112af2b: stderr.util/symbol.c:#:#:error:implicit_declaration_of_function'rb_erase_init';did_you_mean'rb_erase'?[-Werror=implicit-function-declaration]

[kernel test robot]

FYI, we noticed the following commit (built with gcc-6):

commit: a45112af2bdfb51c42a89d181147776b0e4a631e ("tools: Update rbtree files")
url: 
https://github.com/0day-ci/linux/commits/David-Ahern/tools-Update-rbtree-files/20171001-202148


in testcase: perf-sanity-tests
with following parameters:




on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


[   71.717428] util/symbol.c: In function 'dso__split_kallsyms_for_kcore':
[   71.717434] 
[   71.724793] util/symbol.c:713:3: error: implicit declaration of function 
'rb_erase_init'; did you mean 'rb_erase'? 
[-Werror=implicit-function-declaration]
[   71.724796] 
[   71.737088]rb_erase_init(>rb_node, _root);
[   71.737092] 
[   71.739473]^
[   71.739475] 
[   71.757873]rb_erase
[   71.757888] 
[   71.772929] util/symbol.c:713:3: error: nested extern declaration of 
'rb_erase_init' [-Werror=nested-externs]
[   71.772935] 
[   71.858097]   CC   builtin-kmem.o
[   71.858125] 
[   72.905235] cc1: all warnings being treated as errors
[   72.905241] 
[   72.916127] mv: cannot stat 'util/.symbol.o.tmp': No such file or directory
[   72.916131] 
[   72.922305] make[4]: *** [util/symbol.o] Error 1
[   72.922309] 
[   72.925182] make[3]: *** [util] Error 2
[   72.925184] 
[   72.927779] make[2]: *** [libperf-in.o] Error 2
[   72.927781] 
[   72.934104] make[2]: *** Waiting for unfinished jobs


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.14.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set

[PATCH 3/5] drm: Add drm_object lease infrastructure [v4]

[Keith Packard]

This provides new data structures to hold "lease" information about
drm mode setting objects, and provides for creating new drm_masters
which have access to a subset of the available drm resources.

An 'owner' is a drm_master which is not leasing the objects from
another drm_master, and hence 'owns' them.

A 'lessee' is a drm_master which is leasing objects from some other
drm_master. Each lessee holds the set of objects which it is leasing
from the lessor.

A 'lessor' is a drm_master which is leasing objects to another
drm_master. This is the same as the owner in the current code.

The set of objects any drm_master 'controls' is limited to the set of
objects it leases (for lessees) or all objects (for owners).

Objects not controlled by a drm_master cannot be modified through the
various state manipulating ioctls, and any state reported back to user
space will be edited to make them appear idle and/or unusable. For
instance, connectors always report 'disconnected', while encoders
report no possible crtcs or clones.

The full list of lessees leasing objects from an owner (either
directly, or indirectly through another lessee), can be searched from
an idr in the drm_master of the owner.

Changes for v2 as suggested by Daniel Vetter :

* Sub-leasing has been disabled.

* BUG_ON for lock checking replaced with lockdep_assert_held

* 'change' ioctl has been removed.

* Leased objects can always be controlled by the lessor; the
  'mask_lease' flag has been removed

* Checking for leased status has been simplified, replacing
  the drm_lease_check function with drm_lease_held.

Changes in v3, some suggested by Dave Airlie 

* Add revocation. This allows leases to be effectively revoked by
  removing all of the objects they have access to. The lease itself
  hangs around as it's hanging off a file.

* Free the leases IDR when the master is destroyed

* _drm_lease_held should look at lessees, not lessor

* Allow non-master files to check for lease status

Changes in v4, suggested by Dave Airlie 

* Formatting and whitespace changes

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_auth.c|  29 +++-
 drivers/gpu/drm/drm_lease.c   | 339 ++
 include/drm/drm_auth.h|  20 +++
 include/drm/drm_lease.h   |  36 +
 include/drm/drm_mode_object.h |   1 +
 6 files changed, 425 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_lease.c
 create mode 100644 include/drm/drm_lease.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a3fdc5a68dff..81ff79336623 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
-   drm_syncobj.o
+   drm_syncobj.o drm_lease.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 7ff697389d74..541177c71d51 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -31,6 +31,7 @@
 #include 
 #include "drm_internal.h"
 #include "drm_legacy.h"
+#include 
 
 /**
  * DOC: master and authentication
@@ -93,7 +94,7 @@ int drm_authmagic(struct drm_device *dev, void *data,
return file ? 0 : -EINVAL;
 }
 
-static struct drm_master *drm_master_create(struct drm_device *dev)
+struct drm_master *drm_master_create(struct drm_device *dev)
 {
struct drm_master *master;
 
@@ -107,6 +108,14 @@ static struct drm_master *drm_master_create(struct 
drm_device *dev)
idr_init(>magic_map);
master->dev = dev;
 
+   /* initialize the tree of output resource lessees */
+   master->lessor = NULL;
+   master->lessee_id = 0;
+   INIT_LIST_HEAD(>lessees);
+   INIT_LIST_HEAD(>lessee_list);
+   idr_init(>leases);
+   idr_init(>lessee_idr);
+
return master;
 }
 
@@ -189,6 +198,12 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
goto out_unlock;
}
 
+   if (file_priv->master->lessor != NULL) {
+   DRM_DEBUG_LEASE("Attempt to set lessee %d as master\n", 
file_priv->master->lessee_id);
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+
ret = drm_set_master(dev, file_priv, false);
 out_unlock:
mutex_unlock(>master_mutex);
@@ -270,6 +285,13 @@ void drm_master_release(struct drm_file *file_priv)
if (dev->master == file_priv->master)
drm_drop_master(dev, file_priv);
 out:
+   if (file_priv->is_master) {
+   /* Revoke any leases held by this or lessees, but only if
+* this is the 

[PATCH 3/5] drm: Add drm_object lease infrastructure [v4]

[Keith Packard]

This provides new data structures to hold "lease" information about
drm mode setting objects, and provides for creating new drm_masters
which have access to a subset of the available drm resources.

An 'owner' is a drm_master which is not leasing the objects from
another drm_master, and hence 'owns' them.

A 'lessee' is a drm_master which is leasing objects from some other
drm_master. Each lessee holds the set of objects which it is leasing
from the lessor.

A 'lessor' is a drm_master which is leasing objects to another
drm_master. This is the same as the owner in the current code.

The set of objects any drm_master 'controls' is limited to the set of
objects it leases (for lessees) or all objects (for owners).

Objects not controlled by a drm_master cannot be modified through the
various state manipulating ioctls, and any state reported back to user
space will be edited to make them appear idle and/or unusable. For
instance, connectors always report 'disconnected', while encoders
report no possible crtcs or clones.

The full list of lessees leasing objects from an owner (either
directly, or indirectly through another lessee), can be searched from
an idr in the drm_master of the owner.

Changes for v2 as suggested by Daniel Vetter :

* Sub-leasing has been disabled.

* BUG_ON for lock checking replaced with lockdep_assert_held

* 'change' ioctl has been removed.

* Leased objects can always be controlled by the lessor; the
  'mask_lease' flag has been removed

* Checking for leased status has been simplified, replacing
  the drm_lease_check function with drm_lease_held.

Changes in v3, some suggested by Dave Airlie 

* Add revocation. This allows leases to be effectively revoked by
  removing all of the objects they have access to. The lease itself
  hangs around as it's hanging off a file.

* Free the leases IDR when the master is destroyed

* _drm_lease_held should look at lessees, not lessor

* Allow non-master files to check for lease status

Changes in v4, suggested by Dave Airlie 

* Formatting and whitespace changes

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_auth.c|  29 +++-
 drivers/gpu/drm/drm_lease.c   | 339 ++
 include/drm/drm_auth.h|  20 +++
 include/drm/drm_lease.h   |  36 +
 include/drm/drm_mode_object.h |   1 +
 6 files changed, 425 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_lease.c
 create mode 100644 include/drm/drm_lease.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a3fdc5a68dff..81ff79336623 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
-   drm_syncobj.o
+   drm_syncobj.o drm_lease.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 7ff697389d74..541177c71d51 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -31,6 +31,7 @@
 #include 
 #include "drm_internal.h"
 #include "drm_legacy.h"
+#include 
 
 /**
  * DOC: master and authentication
@@ -93,7 +94,7 @@ int drm_authmagic(struct drm_device *dev, void *data,
return file ? 0 : -EINVAL;
 }
 
-static struct drm_master *drm_master_create(struct drm_device *dev)
+struct drm_master *drm_master_create(struct drm_device *dev)
 {
struct drm_master *master;
 
@@ -107,6 +108,14 @@ static struct drm_master *drm_master_create(struct 
drm_device *dev)
idr_init(>magic_map);
master->dev = dev;
 
+   /* initialize the tree of output resource lessees */
+   master->lessor = NULL;
+   master->lessee_id = 0;
+   INIT_LIST_HEAD(>lessees);
+   INIT_LIST_HEAD(>lessee_list);
+   idr_init(>leases);
+   idr_init(>lessee_idr);
+
return master;
 }
 
@@ -189,6 +198,12 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
goto out_unlock;
}
 
+   if (file_priv->master->lessor != NULL) {
+   DRM_DEBUG_LEASE("Attempt to set lessee %d as master\n", 
file_priv->master->lessee_id);
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+
ret = drm_set_master(dev, file_priv, false);
 out_unlock:
mutex_unlock(>master_mutex);
@@ -270,6 +285,13 @@ void drm_master_release(struct drm_file *file_priv)
if (dev->master == file_priv->master)
drm_drop_master(dev, file_priv);
 out:
+   if (file_priv->is_master) {
+   /* Revoke any leases held by this or lessees, but only if
+* this is the "real" master
+*/
+   _drm_lease_revoke(master);
+   

[PATCH 2/5] drm: Add new LEASE debug level

[Keith Packard]

Separate out lease debugging from the core.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_drv.c | 3 ++-
 include/drm/drmP.h| 4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index c0292e5d7281..a934fd5e7e55 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -57,7 +57,8 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit 
enables a debug cat
 "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
 "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
 "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
-"\t\tBit 5 (0x20) will enable VBL messages (vblank code)");
+"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
+"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)");
 module_param_named(debug, drm_debug, int, 0600);
 
 static DEFINE_SPINLOCK(drm_minor_lock);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 7277783a4ff0..59be1232d005 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -136,6 +136,7 @@ struct pci_controller;
 #define DRM_UT_ATOMIC  0x10
 #define DRM_UT_VBL 0x20
 #define DRM_UT_STATE   0x40
+#define DRM_UT_LEASE   0x80
 
 /***/
 /** \name DRM template customization defaults */
@@ -250,6 +251,9 @@ struct pci_controller;
 #define DRM_DEBUG_VBL(fmt, ...)\
drm_printk(KERN_DEBUG, DRM_UT_VBL, fmt, ##__VA_ARGS__)
 
+#define DRM_DEBUG_LEASE(fmt, ...)  \
+   drm_printk(KERN_DEBUG, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
+
 #define _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, level, fmt, args...)\
 ({ \
static DEFINE_RATELIMIT_STATE(_rs,  \
-- 
2.15.0.rc0

[PATCH 0/5]: drm: Add drm mode object leases

[Keith Packard]

New since last time:

 * Don't lease encoders
 * Do lease planes
 * Automatically lease primary and cursor planes for
   apps which don't set universal_planes
 * Restrict leases to only contain objects which
   are actually leasable (connectors, crtcs and planes)
 * Drop the patch which changes permissions on get resources
   ioctls