[PATCH] Staging : wlan-ng: fix unnecessary parentheses in prism2mgmt.c

[Yash Omer]

This patch fixes up unnecessary parentheses warning found by checkpatch.pl 
script.

Signed-off-by: Yash Omer 
---
 drivers/staging/wlan-ng/prism2mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index 236961e3ba0d..90cc6cd8 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -1065,7 +1065,7 @@ int prism2mgmt_autojoin(struct wlandevice *wlandev, void 
*msgp)
 
/* Set the ssid */
memset(bytebuf, 0, 256);
-   pstr = (struct p80211pstrd *)&(msg->ssid.data);
+   pstr = (struct p80211pstrd *)>ssid.data;
prism2mgmt_pstr2bytestr(p2bytestr, pstr);
result = hfa384x_drvr_setconfig(hw, HFA384x_RID_CNFDESIREDSSID,
bytebuf,
-- 
2.14.3

[PATCH] Staging : wlan-ng: fix unnecessary parentheses in prism2mgmt.c

[Yash Omer]

This patch fixes up unnecessary parentheses warning found by checkpatch.pl 
script.

Signed-off-by: Yash Omer 
---
 drivers/staging/wlan-ng/prism2mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index 236961e3ba0d..90cc6cd8 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -1065,7 +1065,7 @@ int prism2mgmt_autojoin(struct wlandevice *wlandev, void 
*msgp)
 
/* Set the ssid */
memset(bytebuf, 0, 256);
-   pstr = (struct p80211pstrd *)&(msg->ssid.data);
+   pstr = (struct p80211pstrd *)>ssid.data;
prism2mgmt_pstr2bytestr(p2bytestr, pstr);
result = hfa384x_drvr_setconfig(hw, HFA384x_RID_CNFDESIREDSSID,
bytebuf,
-- 
2.14.3

Re: [PATCH] perf report: Fix a memory corrupton issue when enabling --branch-history

[Jiri Olsa]

On Fri, Feb 16, 2018 at 10:25:31AM +0800, Jin, Yao wrote:

SNIP

> >  From my opinion, the option '--max-stack' in perf report looks not very
> > necessary. While it's just my personal opinion, need to hear from more
> > people. :)
> > 
> > Thanks
> > Jin Yao
> > 
> > > thanks,
> > > jirka
> > > 
> > > 
> > > ---
> > > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> > > index b6140950301e..b50b7b70dcca 100644
> > > --- a/tools/perf/util/hist.c
> > > +++ b/tools/perf/util/hist.c
> > > @@ -879,7 +879,7 @@ iter_prepare_cumulative_entry(struct
> > > hist_entry_iter *iter,
> > >    * cumulated only one time to prevent entries more than 100%
> > >    * overhead.
> > >    */
> > > -    he_cache = malloc(sizeof(*he_cache) * (iter->max_stack + 1));
> > > +    he_cache = malloc(sizeof(*he_cache) * (callchain_cursor.nr + 1));
> > >   if (he_cache == NULL)
> > >   return -ENOMEM;
> > > 
> 
> Hi Jiri,
> 
> I guess you will post this patch, right?

yep, later today

jirka

Re: [PATCH] perf report: Fix a memory corrupton issue when enabling --branch-history

[Jiri Olsa]

On Fri, Feb 16, 2018 at 10:25:31AM +0800, Jin, Yao wrote:

SNIP

> >  From my opinion, the option '--max-stack' in perf report looks not very
> > necessary. While it's just my personal opinion, need to hear from more
> > people. :)
> > 
> > Thanks
> > Jin Yao
> > 
> > > thanks,
> > > jirka
> > > 
> > > 
> > > ---
> > > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> > > index b6140950301e..b50b7b70dcca 100644
> > > --- a/tools/perf/util/hist.c
> > > +++ b/tools/perf/util/hist.c
> > > @@ -879,7 +879,7 @@ iter_prepare_cumulative_entry(struct
> > > hist_entry_iter *iter,
> > >    * cumulated only one time to prevent entries more than 100%
> > >    * overhead.
> > >    */
> > > -    he_cache = malloc(sizeof(*he_cache) * (iter->max_stack + 1));
> > > +    he_cache = malloc(sizeof(*he_cache) * (callchain_cursor.nr + 1));
> > >   if (he_cache == NULL)
> > >   return -ENOMEM;
> > > 
> 
> Hi Jiri,
> 
> I guess you will post this patch, right?

yep, later today

jirka

Re: [PATCH 11/12] i2c: qup: reorganization of driver code to remove polling for qup v1

[Sricharan R]

Hi Abhishek,

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> Following are the major issues in current driver code
> 
> 1. The current driver simply assumes the transfer completion
>whenever its gets any non-error interrupts and then simply do the
>polling of available/free bytes in FIFO.
> 2. The block mode is not working properly since no handling in
>being done for OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ.
> 
> Because of above, i2c v1 transfers of size greater than 32 are failing
> with following error message
> 
>   i2c_qup 78b6000.i2c: timeout for fifo out full
> 
> To make block mode working properly and move to use the interrupts
> instead of polling, major code reorganization is required. Following
> are the major changes done in this patch
> 
> 1. Remove the polling of TX FIFO free space and RX FIFO available
>bytes and move to interrupts completely. QUP has QUP_MX_OUTPUT_DONE,
>QUP_MX_INPUT_DONE, OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ
>interrupts to handle FIFO’s properly so check all these interrupts.
> 2. During write, For FIFO mode, TX FIFO can be directly written
>without checking for FIFO space. For block mode, the QUP will generate
>OUT_BLOCK_WRITE_REQ interrupt whenever it has block size of available
>space.
> 3. During read, both TX and RX FIFO will be used. TX will be used
>for writing tags and RX will be used for receiving the data. In QUP,
>TX and RX can operate in separate mode so configure modes accordingly.
> 4. For read FIFO mode, wait for QUP_MX_INPUT_DONE interrupt which
>will be generated after all the bytes have been copied in RX FIFO. For
>read Block mode, QUP will generate IN_BLOCK_READ_REQ interrupts
>whenever it has block size of available data.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 399 
> ---
>  1 file changed, 257 insertions(+), 142 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index edea3b9..af6c21a 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -73,8 +73,11 @@
>  #define QUP_IN_SVC_FLAG  BIT(9)
>  #define QUP_MX_OUTPUT_DONE   BIT(10)
>  #define QUP_MX_INPUT_DONEBIT(11)
> +#define OUT_BLOCK_WRITE_REQ  BIT(12)
> +#define IN_BLOCK_READ_REQBIT(13)
>  
>  /* I2C mini core related values */
> +#define QUP_NO_INPUT BIT(7)
>  #define QUP_CLOCK_AUTO_GATE  BIT(13)
>  #define I2C_MINI_CORE(2 << 8)
>  #define I2C_N_VAL15
> @@ -138,13 +141,51 @@
>  #define DEFAULT_CLK_FREQ 10
>  #define DEFAULT_SRC_CLK 2000
>  
> +/* MAX_OUTPUT_DONE_FLAG has been received */
> +#define QUP_BLK_EVENT_TX_IRQ_DONEBIT(0)
> +/* MAX_INPUT_DONE_FLAG has been received */
> +#define QUP_BLK_EVENT_RX_IRQ_DONEBIT(1)
> +/* All the TX bytes have been written in TX FIFO */
> +#define QUP_BLK_EVENT_TX_DATA_DONE   BIT(2)
> +/* All the RX bytes have been read from RX FIFO */
> +#define QUP_BLK_EVENT_RX_DATA_DONE   BIT(3)
> +
> +/* All the required events to mark a QUP I2C TX transfer completed */
> +#define QUP_BLK_EVENT_TX_DONE(QUP_BLK_EVENT_TX_IRQ_DONE | \
> +  QUP_BLK_EVENT_TX_DATA_DONE)
> +/* All the required events to mark a QUP I2C RX transfer completed */
> +#define QUP_BLK_EVENT_RX_DONE(QUP_BLK_EVENT_TX_DONE | \
> +  QUP_BLK_EVENT_RX_IRQ_DONE | \
> +  QUP_BLK_EVENT_RX_DATA_DONE)
> +
> +/*
> + * count: no of blocks
> + * pos: current block number
> + * tx_tag_len: tx tag length for current block
> + * rx_tag_len: rx tag length for current block
> + * data_len: remaining data length for current message
> + * total_tx_len: total tx length including tag bytes for current QUP transfer
> + * total_rx_len: total rx length including tag bytes for current QUP transfer
> + * tx_fifo_free: number of free bytes in current QUP block write.
> + * fifo_available: number of available bytes in RX FIFO for current
> + *  QUP block read
> + * is_tx_blk_mode: whether tx uses block or FIFO mode in case of non BAM 
> xfer.
> + * is_rx_blk_mode: whether rx uses block or FIFO mode in case of non BAM 
> xfer.
> + * tags: contains tx tag bytes for current QUP transfer
> + */
>  struct qup_i2c_block {
> - int count;
> - int pos;
> - int tx_tag_len;
> - int rx_tag_len;
> - int data_len;
> - u8  tags[6];
> + int count;
> + int pos;
> + int tx_tag_len;
> + int rx_tag_len;
> + int data_len;
> + int total_tx_len;
> + int total_rx_len;
> + int tx_fifo_free;
> + int fifo_available;
> + boolis_tx_blk_mode;
> + bool

Re: [PATCH 11/12] i2c: qup: reorganization of driver code to remove polling for qup v1

[Sricharan R]

Hi Abhishek,

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> Following are the major issues in current driver code
> 
> 1. The current driver simply assumes the transfer completion
>whenever its gets any non-error interrupts and then simply do the
>polling of available/free bytes in FIFO.
> 2. The block mode is not working properly since no handling in
>being done for OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ.
> 
> Because of above, i2c v1 transfers of size greater than 32 are failing
> with following error message
> 
>   i2c_qup 78b6000.i2c: timeout for fifo out full
> 
> To make block mode working properly and move to use the interrupts
> instead of polling, major code reorganization is required. Following
> are the major changes done in this patch
> 
> 1. Remove the polling of TX FIFO free space and RX FIFO available
>bytes and move to interrupts completely. QUP has QUP_MX_OUTPUT_DONE,
>QUP_MX_INPUT_DONE, OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ
>interrupts to handle FIFO’s properly so check all these interrupts.
> 2. During write, For FIFO mode, TX FIFO can be directly written
>without checking for FIFO space. For block mode, the QUP will generate
>OUT_BLOCK_WRITE_REQ interrupt whenever it has block size of available
>space.
> 3. During read, both TX and RX FIFO will be used. TX will be used
>for writing tags and RX will be used for receiving the data. In QUP,
>TX and RX can operate in separate mode so configure modes accordingly.
> 4. For read FIFO mode, wait for QUP_MX_INPUT_DONE interrupt which
>will be generated after all the bytes have been copied in RX FIFO. For
>read Block mode, QUP will generate IN_BLOCK_READ_REQ interrupts
>whenever it has block size of available data.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 399 
> ---
>  1 file changed, 257 insertions(+), 142 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index edea3b9..af6c21a 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -73,8 +73,11 @@
>  #define QUP_IN_SVC_FLAG  BIT(9)
>  #define QUP_MX_OUTPUT_DONE   BIT(10)
>  #define QUP_MX_INPUT_DONEBIT(11)
> +#define OUT_BLOCK_WRITE_REQ  BIT(12)
> +#define IN_BLOCK_READ_REQBIT(13)
>  
>  /* I2C mini core related values */
> +#define QUP_NO_INPUT BIT(7)
>  #define QUP_CLOCK_AUTO_GATE  BIT(13)
>  #define I2C_MINI_CORE(2 << 8)
>  #define I2C_N_VAL15
> @@ -138,13 +141,51 @@
>  #define DEFAULT_CLK_FREQ 10
>  #define DEFAULT_SRC_CLK 2000
>  
> +/* MAX_OUTPUT_DONE_FLAG has been received */
> +#define QUP_BLK_EVENT_TX_IRQ_DONEBIT(0)
> +/* MAX_INPUT_DONE_FLAG has been received */
> +#define QUP_BLK_EVENT_RX_IRQ_DONEBIT(1)
> +/* All the TX bytes have been written in TX FIFO */
> +#define QUP_BLK_EVENT_TX_DATA_DONE   BIT(2)
> +/* All the RX bytes have been read from RX FIFO */
> +#define QUP_BLK_EVENT_RX_DATA_DONE   BIT(3)
> +
> +/* All the required events to mark a QUP I2C TX transfer completed */
> +#define QUP_BLK_EVENT_TX_DONE(QUP_BLK_EVENT_TX_IRQ_DONE | \
> +  QUP_BLK_EVENT_TX_DATA_DONE)
> +/* All the required events to mark a QUP I2C RX transfer completed */
> +#define QUP_BLK_EVENT_RX_DONE(QUP_BLK_EVENT_TX_DONE | \
> +  QUP_BLK_EVENT_RX_IRQ_DONE | \
> +  QUP_BLK_EVENT_RX_DATA_DONE)
> +
> +/*
> + * count: no of blocks
> + * pos: current block number
> + * tx_tag_len: tx tag length for current block
> + * rx_tag_len: rx tag length for current block
> + * data_len: remaining data length for current message
> + * total_tx_len: total tx length including tag bytes for current QUP transfer
> + * total_rx_len: total rx length including tag bytes for current QUP transfer
> + * tx_fifo_free: number of free bytes in current QUP block write.
> + * fifo_available: number of available bytes in RX FIFO for current
> + *  QUP block read
> + * is_tx_blk_mode: whether tx uses block or FIFO mode in case of non BAM 
> xfer.
> + * is_rx_blk_mode: whether rx uses block or FIFO mode in case of non BAM 
> xfer.
> + * tags: contains tx tag bytes for current QUP transfer
> + */
>  struct qup_i2c_block {
> - int count;
> - int pos;
> - int tx_tag_len;
> - int rx_tag_len;
> - int data_len;
> - u8  tags[6];
> + int count;
> + int pos;
> + int tx_tag_len;
> + int rx_tag_len;
> + int data_len;
> + int total_tx_len;
> + int total_rx_len;
> + int tx_fifo_free;
> + int fifo_available;
> + boolis_tx_blk_mode;
> + boolis_rx_blk_mode;
> + u8   

[RFC PATCH] ptr_ring: linked list fallback

[Michael S. Tsirkin]

So pointer rings work fine, but they have a problem:
make them too small and not enough entries fit.
Make them too large and you start flushing your cache
and running out of memory.

This is a new idea of mine: a ring backed by a
linked list. Once you run out of rin entries,
instead of a drop you fall back on a list with
a common lock.

Should work well for the case where the ring is typically sized
correctly, but will help address the fact that some user try to set e.g.
tx queue length to 100.

My hope this will move us closer to direction where e.g. fw codel can
use ptr rings without locking at all.
The API is still very rough, and I really need to take a hard look
at lock nesting.

Completely untested, sending for early feedback/flames.

Signed-off-by: Michael S. Tsirkin 
---
 include/linux/ptr_ring.h | 64 +---
 1 file changed, 61 insertions(+), 3 deletions(-)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index d72b2e7..7bf2b7b 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -31,11 +31,18 @@
 #include 
 #endif
 
+/* entries must start with the following structure */
+struct plist {
+   struct plist *next;
+   struct plist *last; /* only valid in the 1st entry */
+};
+
 struct ptr_ring {
int producer cacheline_aligned_in_smp;
spinlock_t producer_lock;
int consumer_head cacheline_aligned_in_smp; /* next valid entry */
int consumer_tail; /* next entry to invalidate */
+   struct plist *consumer_list;
spinlock_t consumer_lock;
/* Shared consumer/producer data */
/* Read-only by both the producer and the consumer */
@@ -120,10 +127,40 @@ static inline int __ptr_ring_produce(struct ptr_ring *r, 
void *ptr)
 }
 
 /*
- * Note: resize (below) nests producer lock within consumer lock, so if you
- * consume in interrupt or BH context, you must disable interrupts/BH when
- * calling this.
+ * Note: resize API with the _fallback should be used when calling this.
  */
+static inline int ptr_ring_produce_fallback(struct ptr_ring *r, void *ptr)
+{
+   int ret;
+   unsigned long flags;
+   plit *p = ptr;
+
+   p->next = NULL;
+   p->last = p;
+
+   spin_lock_irqsave(>producer_lock, flags);
+   ret = __ptr_ring_produce(r, ptr);
+   if (ret) {
+   spin_lock(>consumer_lock);
+   ret = __ptr_ring_produce(r, ptr);
+   if (ret) {
+   int producer = r->producer ? r->producer - 1 :
+   r->size - 1;
+   plist *first = r->queue[producer];
+
+   BUG_ON(!first);
+
+   first->last->next = p;
+   first->last = p;
+   }
+   spin_unlock(>consumer_lock);
+   }
+
+   spin_unlock_irqrestore(>producer_lock, flags);
+
+   return ret;
+}
+
 static inline int ptr_ring_produce(struct ptr_ring *r, void *ptr)
 {
int ret;
@@ -135,6 +172,7 @@ static inline int ptr_ring_produce(struct ptr_ring *r, void 
*ptr)
return ret;
 }
 
+
 static inline int ptr_ring_produce_irq(struct ptr_ring *r, void *ptr)
 {
int ret;
@@ -359,6 +397,26 @@ static inline void *ptr_ring_consume_bh(struct ptr_ring *r)
return ptr;
 }
 
+static inline void *ptr_ring_consume_fallback(struct ptr_ring *r)
+{
+   unsigned long flags;
+   struct plist *ptr;
+
+   spin_lock_irqsave(>consumer_lock, flags);
+   if (r->consumer_list) {
+   ptr = r->consumer_list;
+   r->consumer_list = ptr->next;
+   } else {
+   ptr = __ptr_ring_consume(r);
+   if (ptr) {
+   r->consumer_list = ptr->next;
+   }
+   }
+   spin_unlock_irqrestore(>consumer_lock, flags);
+
+   return ptr;
+}
+
 static inline int ptr_ring_consume_batched(struct ptr_ring *r,
   void **array, int n)
 {
-- 
MST

[RFC PATCH] ptr_ring: linked list fallback

[Michael S. Tsirkin]

So pointer rings work fine, but they have a problem:
make them too small and not enough entries fit.
Make them too large and you start flushing your cache
and running out of memory.

This is a new idea of mine: a ring backed by a
linked list. Once you run out of rin entries,
instead of a drop you fall back on a list with
a common lock.

Should work well for the case where the ring is typically sized
correctly, but will help address the fact that some user try to set e.g.
tx queue length to 100.

My hope this will move us closer to direction where e.g. fw codel can
use ptr rings without locking at all.
The API is still very rough, and I really need to take a hard look
at lock nesting.

Completely untested, sending for early feedback/flames.

Signed-off-by: Michael S. Tsirkin 
---
 include/linux/ptr_ring.h | 64 +---
 1 file changed, 61 insertions(+), 3 deletions(-)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index d72b2e7..7bf2b7b 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -31,11 +31,18 @@
 #include 
 #endif
 
+/* entries must start with the following structure */
+struct plist {
+   struct plist *next;
+   struct plist *last; /* only valid in the 1st entry */
+};
+
 struct ptr_ring {
int producer cacheline_aligned_in_smp;
spinlock_t producer_lock;
int consumer_head cacheline_aligned_in_smp; /* next valid entry */
int consumer_tail; /* next entry to invalidate */
+   struct plist *consumer_list;
spinlock_t consumer_lock;
/* Shared consumer/producer data */
/* Read-only by both the producer and the consumer */
@@ -120,10 +127,40 @@ static inline int __ptr_ring_produce(struct ptr_ring *r, 
void *ptr)
 }
 
 /*
- * Note: resize (below) nests producer lock within consumer lock, so if you
- * consume in interrupt or BH context, you must disable interrupts/BH when
- * calling this.
+ * Note: resize API with the _fallback should be used when calling this.
  */
+static inline int ptr_ring_produce_fallback(struct ptr_ring *r, void *ptr)
+{
+   int ret;
+   unsigned long flags;
+   plit *p = ptr;
+
+   p->next = NULL;
+   p->last = p;
+
+   spin_lock_irqsave(>producer_lock, flags);
+   ret = __ptr_ring_produce(r, ptr);
+   if (ret) {
+   spin_lock(>consumer_lock);
+   ret = __ptr_ring_produce(r, ptr);
+   if (ret) {
+   int producer = r->producer ? r->producer - 1 :
+   r->size - 1;
+   plist *first = r->queue[producer];
+
+   BUG_ON(!first);
+
+   first->last->next = p;
+   first->last = p;
+   }
+   spin_unlock(>consumer_lock);
+   }
+
+   spin_unlock_irqrestore(>producer_lock, flags);
+
+   return ret;
+}
+
 static inline int ptr_ring_produce(struct ptr_ring *r, void *ptr)
 {
int ret;
@@ -135,6 +172,7 @@ static inline int ptr_ring_produce(struct ptr_ring *r, void 
*ptr)
return ret;
 }
 
+
 static inline int ptr_ring_produce_irq(struct ptr_ring *r, void *ptr)
 {
int ret;
@@ -359,6 +397,26 @@ static inline void *ptr_ring_consume_bh(struct ptr_ring *r)
return ptr;
 }
 
+static inline void *ptr_ring_consume_fallback(struct ptr_ring *r)
+{
+   unsigned long flags;
+   struct plist *ptr;
+
+   spin_lock_irqsave(>consumer_lock, flags);
+   if (r->consumer_list) {
+   ptr = r->consumer_list;
+   r->consumer_list = ptr->next;
+   } else {
+   ptr = __ptr_ring_consume(r);
+   if (ptr) {
+   r->consumer_list = ptr->next;
+   }
+   }
+   spin_unlock_irqrestore(>consumer_lock, flags);
+
+   return ptr;
+}
+
 static inline int ptr_ring_consume_batched(struct ptr_ring *r,
   void **array, int n)
 {
-- 
MST

[PATCH] Staging: wlan-ng: fix unnecessary parantheses in prism2mgmt.c

[Yash Omer]

This patch fixes up a unncessary paratheses warning found by checkpatch.pl 
script.

Signed-off-by: Yash Omer 
---
 drivers/staging/wlan-ng/prism2mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index e47a839f83a6..236961e3ba0d 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -564,7 +564,7 @@ int prism2mgmt_start(struct wlandevice *wlandev, void *msgp)
/*** STATION ***/
/* Set the REQUIRED config items */
/* SSID */
-   pstr = (struct p80211pstrd *)&(msg->ssid.data);
+   pstr = (struct p80211pstrd *)>ssid.data;
prism2mgmt_pstr2bytestr(p2bytestr, pstr);
result = hfa384x_drvr_setconfig(hw, HFA384x_RID_CNFOWNSSID,
bytebuf, HFA384x_RID_CNFOWNSSID_LEN);
-- 
2.14.3

[PATCH] Staging: wlan-ng: fix unnecessary parantheses in prism2mgmt.c

[Yash Omer]

This patch fixes up a unncessary paratheses warning found by checkpatch.pl 
script.

Signed-off-by: Yash Omer 
---
 drivers/staging/wlan-ng/prism2mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index e47a839f83a6..236961e3ba0d 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -564,7 +564,7 @@ int prism2mgmt_start(struct wlandevice *wlandev, void *msgp)
/*** STATION ***/
/* Set the REQUIRED config items */
/* SSID */
-   pstr = (struct p80211pstrd *)&(msg->ssid.data);
+   pstr = (struct p80211pstrd *)>ssid.data;
prism2mgmt_pstr2bytestr(p2bytestr, pstr);
result = hfa384x_drvr_setconfig(hw, HFA384x_RID_CNFOWNSSID,
bytebuf, HFA384x_RID_CNFOWNSSID_LEN);
-- 
2.14.3

Re: [PATCH v3 01/11] watchdog/hpwdt: Remove legacy NMI sourcing.

[Ingo Molnar]

* Jerry Hoemann  wrote:

> Gen8 and prior Proliant systems supported the "CRU" interface
> to firmware.  This interfaces allows linux to "call back" into firmware
> to source the cause of an NMI.  This feature isn't fully utilized
> as the actual source of the NMI isn't printed, the driver only
> indicates that the source couldn't be determined when the call
> fails.
> 
> With the advent of Gen9, iCRU replaces the CRU. The call back
> feature is no longer available in firmware.  To be compatible and
> not attempt to call back into firmware on system not supporting CRU,
> the SMBIOS table is consulted to determine if it is safe to
> make the call back or not.
> 
> This results in about half of the driver code being devoted
> to either making CRU calls or determing if it is safe to make
> CRU calls.  As noted, the driver isn't really using the results of
> the CRU calls.
> 
> As the CRU sourcing of the NMI isn't required for handling the
> NMI, remove the legacy (pre Gen9) NMI sourcing and the DMI code to
> determine if the system had the CRU interface.
> 
> Signed-off-by: Jerry Hoemann 
> ---
>  drivers/watchdog/hpwdt.c | 490 
> +--
>  1 file changed, 8 insertions(+), 482 deletions(-)

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [PATCH v3 01/11] watchdog/hpwdt: Remove legacy NMI sourcing.

[Ingo Molnar]

* Jerry Hoemann  wrote:

> Gen8 and prior Proliant systems supported the "CRU" interface
> to firmware.  This interfaces allows linux to "call back" into firmware
> to source the cause of an NMI.  This feature isn't fully utilized
> as the actual source of the NMI isn't printed, the driver only
> indicates that the source couldn't be determined when the call
> fails.
> 
> With the advent of Gen9, iCRU replaces the CRU. The call back
> feature is no longer available in firmware.  To be compatible and
> not attempt to call back into firmware on system not supporting CRU,
> the SMBIOS table is consulted to determine if it is safe to
> make the call back or not.
> 
> This results in about half of the driver code being devoted
> to either making CRU calls or determing if it is safe to make
> CRU calls.  As noted, the driver isn't really using the results of
> the CRU calls.
> 
> As the CRU sourcing of the NMI isn't required for handling the
> NMI, remove the legacy (pre Gen9) NMI sourcing and the DMI code to
> determine if the system had the CRU interface.
> 
> Signed-off-by: Jerry Hoemann 
> ---
>  drivers/watchdog/hpwdt.c | 490 
> +--
>  1 file changed, 8 insertions(+), 482 deletions(-)

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [PATCH v2 11/16] mmc: sdhci: Program a relatively accurate SW timeout value

[Kishon Vijay Abraham I]

On Monday 05 February 2018 06:20 PM, Kishon Vijay Abraham I wrote:
> sdhci has a 10 second timeout to catch devices that stop responding.
> Instead of programming 10 second arbitrary value, calculate the total time
> it would take for the entire transfer to happen and program the timeout
> value accordingly.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/mmc/host/sdhci.c | 46 +++---
>  drivers/mmc/host/sdhci.h | 10 ++
>  2 files changed, 49 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0489572d1892..d52f9e7eabe2 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -673,6 +673,37 @@ static void sdhci_adma_table_post(struct sdhci_host 
> *host,
>   }
>  }
>  
> +static void sdhci_calc_sw_timeout(struct sdhci_host *host,
> +   struct mmc_command *cmd,
> +   unsigned int target_timeout)
> +{
> + struct mmc_data *data = cmd->data;
> + struct mmc_host *mmc = host->mmc;
> + unsigned long long transfer_time;
> + struct mmc_ios *ios = >ios;
> + unsigned char bus_width = ios->bus_width;

This should have been 1 << ios->bus_width.

-Kishon

Re: [PATCH v2 11/16] mmc: sdhci: Program a relatively accurate SW timeout value

[Kishon Vijay Abraham I]

On Monday 05 February 2018 06:20 PM, Kishon Vijay Abraham I wrote:
> sdhci has a 10 second timeout to catch devices that stop responding.
> Instead of programming 10 second arbitrary value, calculate the total time
> it would take for the entire transfer to happen and program the timeout
> value accordingly.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/mmc/host/sdhci.c | 46 +++---
>  drivers/mmc/host/sdhci.h | 10 ++
>  2 files changed, 49 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0489572d1892..d52f9e7eabe2 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -673,6 +673,37 @@ static void sdhci_adma_table_post(struct sdhci_host 
> *host,
>   }
>  }
>  
> +static void sdhci_calc_sw_timeout(struct sdhci_host *host,
> +   struct mmc_command *cmd,
> +   unsigned int target_timeout)
> +{
> + struct mmc_data *data = cmd->data;
> + struct mmc_host *mmc = host->mmc;
> + unsigned long long transfer_time;
> + struct mmc_ios *ios = >ios;
> + unsigned char bus_width = ios->bus_width;

This should have been 1 << ios->bus_width.

-Kishon

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

[Cyrill Gorcunov]

On Thu, Feb 15, 2018 at 11:29:42PM +, Andy Lutomirski wrote:
...
> >>> +bool pti_handle_segment_not_present(long error_code)
> >>> +{
> >>> +   if (!static_cpu_has(X86_FEATURE_PTI))
> >>> +   return false;
> >>> +
> >>> +   if ((unsigned short)error_code != GDT_ENTRY_DEFAULT_USER_CS << 3)
> >>> +   return false;
> >>> +
> >>> +   pti_reenable();
> >>> +   return true;
> >>> +}
> >>
> >> Please don't.  You're trying to emulate the old behavior here, but
> >> you're emulating it wrong.  In particular, you won't trap on LAR.
> >
> > Yes, I thought I’ll manage to address LAR, but failed. I thought you said
> > this is not a “show-stopper”. I’ll adapt your approach of using prctl, 
> > although
> > it really limits the benefit of this mechanism.
> >
> 
> It's possible we could get away with adding the prctl but making the
> default be that only the bitness that matches the program being run is
> allowed.  After all, it's possible that CRIU is literally the only
> program that switches bitness using the GDT.  (DOSEMU2 definitely does
> cross-bitness stuff, but it uses the LDT as far as I know.)  And I've
> never been entirely sure that CRIU fully counts toward the Linux
> "don't break ABI" guarantee.
> 
> Linus, how would you feel about, by default, preventing 64-bit
> programs from long-jumping to __USER32_CS and vice versa?  I think it
> has some value as a hardening measure.  I've certainly engaged in some
> exploit shenanigans myself that took advantage of the ability to long
> jump/ret to change bitness at will.  This wouldn't affect users of
> modify_ldt() -- 64-bit programs could still create and use their own
> private 32-bit segments with modify_ldt(), and seccomp can (and
> should!) prevent that in sandboxed programs.
> 
> In general, I prefer an approach where everything is explicit to an
> approach where we almost, but not quite, emulate the weird historical
> behavior.
> 
> Pavel and Cyrill, how annoying would it be if CRIU had to do an extra
> arch_prctl() to enable its cross-bitness shenanigans when
> checkpointing and restoring a 32-bit program?

I think this should not be a problem for criu (CC'ing Dima, who has
been working on compat mode support in criu). As far as I remember
we initiate restoring of 32 bit tasks in native 64 bit mode (well,
ia32e to be precise :) mode and then, once everything is ready,
we changing the mode by doing a return to __USER32_CS descriptor.
So this won't be painful to add additional prctl call here.

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

[Cyrill Gorcunov]

On Thu, Feb 15, 2018 at 11:29:42PM +, Andy Lutomirski wrote:
...
> >>> +bool pti_handle_segment_not_present(long error_code)
> >>> +{
> >>> +   if (!static_cpu_has(X86_FEATURE_PTI))
> >>> +   return false;
> >>> +
> >>> +   if ((unsigned short)error_code != GDT_ENTRY_DEFAULT_USER_CS << 3)
> >>> +   return false;
> >>> +
> >>> +   pti_reenable();
> >>> +   return true;
> >>> +}
> >>
> >> Please don't.  You're trying to emulate the old behavior here, but
> >> you're emulating it wrong.  In particular, you won't trap on LAR.
> >
> > Yes, I thought I’ll manage to address LAR, but failed. I thought you said
> > this is not a “show-stopper”. I’ll adapt your approach of using prctl, 
> > although
> > it really limits the benefit of this mechanism.
> >
> 
> It's possible we could get away with adding the prctl but making the
> default be that only the bitness that matches the program being run is
> allowed.  After all, it's possible that CRIU is literally the only
> program that switches bitness using the GDT.  (DOSEMU2 definitely does
> cross-bitness stuff, but it uses the LDT as far as I know.)  And I've
> never been entirely sure that CRIU fully counts toward the Linux
> "don't break ABI" guarantee.
> 
> Linus, how would you feel about, by default, preventing 64-bit
> programs from long-jumping to __USER32_CS and vice versa?  I think it
> has some value as a hardening measure.  I've certainly engaged in some
> exploit shenanigans myself that took advantage of the ability to long
> jump/ret to change bitness at will.  This wouldn't affect users of
> modify_ldt() -- 64-bit programs could still create and use their own
> private 32-bit segments with modify_ldt(), and seccomp can (and
> should!) prevent that in sandboxed programs.
> 
> In general, I prefer an approach where everything is explicit to an
> approach where we almost, but not quite, emulate the weird historical
> behavior.
> 
> Pavel and Cyrill, how annoying would it be if CRIU had to do an extra
> arch_prctl() to enable its cross-bitness shenanigans when
> checkpointing and restoring a 32-bit program?

I think this should not be a problem for criu (CC'ing Dima, who has
been working on compat mode support in criu). As far as I remember
we initiate restoring of 32 bit tasks in native 64 bit mode (well,
ia32e to be precise :) mode and then, once everything is ready,
we changing the mode by doing a return to __USER32_CS descriptor.
So this won't be painful to add additional prctl call here.

Re: [PATCH] usb: musb: fix enumeration after resume

[Andreas Kemnade]

On Wed, 7 Feb 2018 14:37:00 -0600
Bin Liu  wrote:

> On Tue, Feb 06, 2018 at 08:00:24PM +0100, Andreas Kemnade wrote:
> > Hi,
> > 
> > On Tue, 6 Feb 2018 12:46:05 -0600
> > Bin Liu  wrote:
> >   
> > > Hi,
> > > 
> > > On Sat, Jan 27, 2018 at 09:34:03AM +0100, Andreas Kemnade wrote:  
> > > > On dm3730 there are enumeration problems after resume.
> > > > Investigation led to the cause that the MUSB_POWER_SOFTCONN
> > > > bit is not set. If it was set before suspend (because it
> > > > was enabled via musb_pullup()), it is set in
> > > > musb_restore_context() so the pullup is enabled. But then
> > > > musb_start() is called which overwrites MUSB_POWER and
> > > > therefore disables MUSB_POWER_SOFTCONN, so no pullup is
> > > > enabled and the device is not enumerated.
> > >  
> > > Do you see the issue with the v4.15?
> > >   
> > Yes. Tested without other patches. 
> > It was also there in earlier kernels but I had not had motivation enough
> > to debug.  
> 
> Applied to my tree. Thanks.
> 
> > So maybe it deserves a CC: Stable  
> 
> I would prefer it is first tested on each stable tree.
> 
Tested with 4.16-rc1 with and without that patch
The problem still exists and can be fixed by that patch.

Regards,
Andreas


pgpaxewYLXuZf.pgp
Description: OpenPGP digital signature

Re: [PATCH] usb: musb: fix enumeration after resume

[Andreas Kemnade]

On Wed, 7 Feb 2018 14:37:00 -0600
Bin Liu  wrote:

> On Tue, Feb 06, 2018 at 08:00:24PM +0100, Andreas Kemnade wrote:
> > Hi,
> > 
> > On Tue, 6 Feb 2018 12:46:05 -0600
> > Bin Liu  wrote:
> >   
> > > Hi,
> > > 
> > > On Sat, Jan 27, 2018 at 09:34:03AM +0100, Andreas Kemnade wrote:  
> > > > On dm3730 there are enumeration problems after resume.
> > > > Investigation led to the cause that the MUSB_POWER_SOFTCONN
> > > > bit is not set. If it was set before suspend (because it
> > > > was enabled via musb_pullup()), it is set in
> > > > musb_restore_context() so the pullup is enabled. But then
> > > > musb_start() is called which overwrites MUSB_POWER and
> > > > therefore disables MUSB_POWER_SOFTCONN, so no pullup is
> > > > enabled and the device is not enumerated.
> > >  
> > > Do you see the issue with the v4.15?
> > >   
> > Yes. Tested without other patches. 
> > It was also there in earlier kernels but I had not had motivation enough
> > to debug.  
> 
> Applied to my tree. Thanks.
> 
> > So maybe it deserves a CC: Stable  
> 
> I would prefer it is first tested on each stable tree.
> 
Tested with 4.16-rc1 with and without that patch
The problem still exists and can be fixed by that patch.

Regards,
Andreas


pgpaxewYLXuZf.pgp
Description: OpenPGP digital signature

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

[Heiko Stuebner]

Am Mittwoch, 14. Februar 2018, 21:08:59 CET schrieb Jernej Skrabec:
> dw_hdmi shouldn't set drvdata since some drivers might need to store
> it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
> instead to store it in drvdata. This way drivers are responsible to
> store and pass structure when needed.
> 
> Idea was taken from the following commit:
> 8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")
> 
> Cc: p.za...@pengutronix.de
> Cc: narmstr...@baylibre.com
> Cc: laurent.pinch...@ideasonboard.com
> Cc: h...@rock-chips.com
> Cc: he...@sntech.de
> Acked-by: Neil Armstrong 
> Signed-off-by: Jernej Skrabec 

For the Rockchip-part
Tested-by: Heiko Stuebner 
Acked-by: Heiko Stuebner 

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

[Heiko Stuebner]

Am Mittwoch, 14. Februar 2018, 21:08:59 CET schrieb Jernej Skrabec:
> dw_hdmi shouldn't set drvdata since some drivers might need to store
> it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
> instead to store it in drvdata. This way drivers are responsible to
> store and pass structure when needed.
> 
> Idea was taken from the following commit:
> 8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")
> 
> Cc: p.za...@pengutronix.de
> Cc: narmstr...@baylibre.com
> Cc: laurent.pinch...@ideasonboard.com
> Cc: h...@rock-chips.com
> Cc: he...@sntech.de
> Acked-by: Neil Armstrong 
> Signed-off-by: Jernej Skrabec 

For the Rockchip-part
Tested-by: Heiko Stuebner 
Acked-by: Heiko Stuebner 

Re: [PATCH 5/8] lightnvm: implement get log report chunk helpers

[Javier González]

> On 15 Feb 2018, at 04.51, Matias Bjørling  wrote:
> 
> On 02/13/2018 03:06 PM, Javier González wrote:
>> From: Javier González 
>> The 2.0 spec provides a report chunk log page that can be retrieved
>> using the stangard nvme get log page. This replaces the dedicated
>> get/put bad block table in 1.2.
>> This patch implements the helper functions to allow targets retrieve the
>> chunk metadata using get log page
>> Signed-off-by: Javier González 
>> ---
>>  drivers/lightnvm/core.c  | 28 +
>>  drivers/nvme/host/lightnvm.c | 50 
>> 
>>  include/linux/lightnvm.h | 32 
>>  3 files changed, 110 insertions(+)
>> diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
>> index 80492fa6ee76..6857a888544a 100644
>> --- a/drivers/lightnvm/core.c
>> +++ b/drivers/lightnvm/core.c
>> @@ -43,6 +43,8 @@ struct nvm_ch_map {
>>  struct nvm_dev_map {
>>  struct nvm_ch_map *chnls;
>>  int nr_chnls;
>> +int bch;
>> +int blun;
>>  };
> 
> bch/blun should be unnecessary if the map_to_dev / map_to_tgt
> functions are implemented correctly (they can with the ppa_addr order
> update as far as I can see)
> 
> What is the reason they can't be used? I might be missing something.

This is a precalculated value used for the offset on
nvm_get_chunk_log_page() actually, not on map_to_dev and map_to_tgt in
the fast path.

The problem is that since we offset to always start at ch:0,lun:0 on
target creation, we need this value. How would you get the offset otherwise?

> 
>>static struct nvm_target *nvm_find_target(struct nvm_dev *dev, const char 
>> *name)
>> @@ -171,6 +173,9 @@ static struct nvm_tgt_dev *nvm_create_tgt_dev(struct 
>> nvm_dev *dev,
>>  if (!dev_map->chnls)
>>  goto err_chnls;
>>  +   dev_map->bch = bch;
>> +dev_map->blun = blun;
>> +
>>  luns = kcalloc(nr_luns, sizeof(struct ppa_addr), GFP_KERNEL);
>>  if (!luns)
>>  goto err_luns;
>> @@ -561,6 +566,19 @@ static void nvm_unregister_map(struct nvm_dev *dev)
>>  kfree(rmap);
>>  }
>>  +static unsigned long nvm_log_off_tgt_to_dev(struct nvm_tgt_dev *tgt_dev)
>> +{
>> +struct nvm_dev_map *dev_map = tgt_dev->map;
>> +struct nvm_geo *geo = _dev->geo;
>> +int lun_off;
>> +unsigned long off;
>> +
>> +lun_off = dev_map->blun + dev_map->bch * geo->num_lun;
>> +off = lun_off * geo->c.num_chk * sizeof(struct nvm_chunk_log_page);
>> +
>> +return off;
>> +}
>> +
>>  static void nvm_map_to_dev(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *p)
>>  {
>>  struct nvm_dev_map *dev_map = tgt_dev->map;
>> @@ -720,6 +738,16 @@ static void nvm_free_rqd_ppalist(struct nvm_tgt_dev 
>> *tgt_dev,
>>  nvm_dev_dma_free(tgt_dev->parent, rqd->ppa_list, rqd->dma_ppa_list);
>>  }
>>  +int nvm_get_chunk_log_page(struct nvm_tgt_dev *tgt_dev,
>> +   struct nvm_chunk_log_page *log,
>> +   unsigned long off, unsigned long len)
>> +{
>> +struct nvm_dev *dev = tgt_dev->parent;
>> +
>> +off += nvm_log_off_tgt_to_dev(tgt_dev);
>> +
>> +return dev->ops->get_chunk_log_page(tgt_dev->parent, log, off, len);
>> +}
> 
> I think that this should be exported as get_bb and set_bb. Else
> linking fails if pblk is compiled as a module.
> 

It is implemented as get_bb and set_bb. Am I missing anything here?

>>int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas,
>> int nr_ppas, int type)
>> diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
>> index 7bc75182c723..355d9b0cf084 100644
>> --- a/drivers/nvme/host/lightnvm.c
>> +++ b/drivers/nvme/host/lightnvm.c
>> @@ -35,6 +35,10 @@ enum nvme_nvm_admin_opcode {
>>  nvme_nvm_admin_set_bb_tbl   = 0xf1,
>>  };
>>  +enum nvme_nvm_log_page {
>> +NVME_NVM_LOG_REPORT_CHUNK   = 0xCA,
>> +};
>> +
> 
> The convention is to have it as lower-case.

Ok.

> 
>>  struct nvme_nvm_ph_rw {
>>  __u8opcode;
>>  __u8flags;
>> @@ -553,6 +557,50 @@ static int nvme_nvm_set_bb_tbl(struct nvm_dev *nvmdev, 
>> struct ppa_addr *ppas,
>>  return ret;
>>  }
>>  +static int nvme_nvm_get_chunk_log_page(struct nvm_dev *nvmdev,
>> +   struct nvm_chunk_log_page *log,
>> +   unsigned long off,
>> +   unsigned long total_len)
> 
> The chunk_log_page interface are both to be used by targets and the block 
> layer code. Therefore, it is not convenient to have a byte-addressible 
> interface exposed all the way up to a target. Instead, use slba and nlb. That 
> simplifies what a target has to implement, and also allows the offset check 
> to be removed.
> 
> Chunk log page should be defined in the nvme implementation, such that it can 
> be accessed through the traditional 

Re: [PATCH 5/8] lightnvm: implement get log report chunk helpers

[Javier González]

> On 15 Feb 2018, at 04.51, Matias Bjørling  wrote:
> 
> On 02/13/2018 03:06 PM, Javier González wrote:
>> From: Javier González 
>> The 2.0 spec provides a report chunk log page that can be retrieved
>> using the stangard nvme get log page. This replaces the dedicated
>> get/put bad block table in 1.2.
>> This patch implements the helper functions to allow targets retrieve the
>> chunk metadata using get log page
>> Signed-off-by: Javier González 
>> ---
>>  drivers/lightnvm/core.c  | 28 +
>>  drivers/nvme/host/lightnvm.c | 50 
>> 
>>  include/linux/lightnvm.h | 32 
>>  3 files changed, 110 insertions(+)
>> diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
>> index 80492fa6ee76..6857a888544a 100644
>> --- a/drivers/lightnvm/core.c
>> +++ b/drivers/lightnvm/core.c
>> @@ -43,6 +43,8 @@ struct nvm_ch_map {
>>  struct nvm_dev_map {
>>  struct nvm_ch_map *chnls;
>>  int nr_chnls;
>> +int bch;
>> +int blun;
>>  };
> 
> bch/blun should be unnecessary if the map_to_dev / map_to_tgt
> functions are implemented correctly (they can with the ppa_addr order
> update as far as I can see)
> 
> What is the reason they can't be used? I might be missing something.

This is a precalculated value used for the offset on
nvm_get_chunk_log_page() actually, not on map_to_dev and map_to_tgt in
the fast path.

The problem is that since we offset to always start at ch:0,lun:0 on
target creation, we need this value. How would you get the offset otherwise?

> 
>>static struct nvm_target *nvm_find_target(struct nvm_dev *dev, const char 
>> *name)
>> @@ -171,6 +173,9 @@ static struct nvm_tgt_dev *nvm_create_tgt_dev(struct 
>> nvm_dev *dev,
>>  if (!dev_map->chnls)
>>  goto err_chnls;
>>  +   dev_map->bch = bch;
>> +dev_map->blun = blun;
>> +
>>  luns = kcalloc(nr_luns, sizeof(struct ppa_addr), GFP_KERNEL);
>>  if (!luns)
>>  goto err_luns;
>> @@ -561,6 +566,19 @@ static void nvm_unregister_map(struct nvm_dev *dev)
>>  kfree(rmap);
>>  }
>>  +static unsigned long nvm_log_off_tgt_to_dev(struct nvm_tgt_dev *tgt_dev)
>> +{
>> +struct nvm_dev_map *dev_map = tgt_dev->map;
>> +struct nvm_geo *geo = _dev->geo;
>> +int lun_off;
>> +unsigned long off;
>> +
>> +lun_off = dev_map->blun + dev_map->bch * geo->num_lun;
>> +off = lun_off * geo->c.num_chk * sizeof(struct nvm_chunk_log_page);
>> +
>> +return off;
>> +}
>> +
>>  static void nvm_map_to_dev(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *p)
>>  {
>>  struct nvm_dev_map *dev_map = tgt_dev->map;
>> @@ -720,6 +738,16 @@ static void nvm_free_rqd_ppalist(struct nvm_tgt_dev 
>> *tgt_dev,
>>  nvm_dev_dma_free(tgt_dev->parent, rqd->ppa_list, rqd->dma_ppa_list);
>>  }
>>  +int nvm_get_chunk_log_page(struct nvm_tgt_dev *tgt_dev,
>> +   struct nvm_chunk_log_page *log,
>> +   unsigned long off, unsigned long len)
>> +{
>> +struct nvm_dev *dev = tgt_dev->parent;
>> +
>> +off += nvm_log_off_tgt_to_dev(tgt_dev);
>> +
>> +return dev->ops->get_chunk_log_page(tgt_dev->parent, log, off, len);
>> +}
> 
> I think that this should be exported as get_bb and set_bb. Else
> linking fails if pblk is compiled as a module.
> 

It is implemented as get_bb and set_bb. Am I missing anything here?

>>int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas,
>> int nr_ppas, int type)
>> diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
>> index 7bc75182c723..355d9b0cf084 100644
>> --- a/drivers/nvme/host/lightnvm.c
>> +++ b/drivers/nvme/host/lightnvm.c
>> @@ -35,6 +35,10 @@ enum nvme_nvm_admin_opcode {
>>  nvme_nvm_admin_set_bb_tbl   = 0xf1,
>>  };
>>  +enum nvme_nvm_log_page {
>> +NVME_NVM_LOG_REPORT_CHUNK   = 0xCA,
>> +};
>> +
> 
> The convention is to have it as lower-case.

Ok.

> 
>>  struct nvme_nvm_ph_rw {
>>  __u8opcode;
>>  __u8flags;
>> @@ -553,6 +557,50 @@ static int nvme_nvm_set_bb_tbl(struct nvm_dev *nvmdev, 
>> struct ppa_addr *ppas,
>>  return ret;
>>  }
>>  +static int nvme_nvm_get_chunk_log_page(struct nvm_dev *nvmdev,
>> +   struct nvm_chunk_log_page *log,
>> +   unsigned long off,
>> +   unsigned long total_len)
> 
> The chunk_log_page interface are both to be used by targets and the block 
> layer code. Therefore, it is not convenient to have a byte-addressible 
> interface exposed all the way up to a target. Instead, use slba and nlb. That 
> simplifies what a target has to implement, and also allows the offset check 
> to be removed.
> 
> Chunk log page should be defined in the nvme implementation, such that it can 
> be accessed through the traditional LBA path.
> 
> struct nvme_nvm_chk_meta {
>   __u8

Re: [PATCH 4.4 000/108] 4.4.116-stable review

[Greg Kroah-Hartman]

On Thu, Feb 15, 2018 at 07:45:08PM -0700, Nathan Chancellor wrote:
> On Thu, Feb 15, 2018 at 04:15:57PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.116 release.
> > There are 108 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 Feb 17 15:11:36 UTC 2018.
> > 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.4.116-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.4.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> >
> 
> Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.
> 
> The v4l2-ioctl32 commits were interesting to sift through merging... I
> think I got everything correct though, the changes are in my trees under
> temporary tags if anyone cares to check them out:
> 
> https://github.com/nathanchance/wahoo/commits/queue-2.17
> https://github.com/nathanchance/op5/commits/queue-3.10

Thanks for that, yes, those are going to be an "interesting" merge :(

> So far, there have been no visible regressions in dmesg or general
> usage (I focused pretty heavily in the video area since those were the
> biggest changes).

thanks for testing and letting us know.

greg k-h

Re: [PATCH 4.4 000/108] 4.4.116-stable review

[Greg Kroah-Hartman]

On Thu, Feb 15, 2018 at 07:45:08PM -0700, Nathan Chancellor wrote:
> On Thu, Feb 15, 2018 at 04:15:57PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.116 release.
> > There are 108 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 Feb 17 15:11:36 UTC 2018.
> > 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.4.116-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.4.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> >
> 
> Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.
> 
> The v4l2-ioctl32 commits were interesting to sift through merging... I
> think I got everything correct though, the changes are in my trees under
> temporary tags if anyone cares to check them out:
> 
> https://github.com/nathanchance/wahoo/commits/queue-2.17
> https://github.com/nathanchance/op5/commits/queue-3.10

Thanks for that, yes, those are going to be an "interesting" merge :(

> So far, there have been no visible regressions in dmesg or general
> usage (I focused pretty heavily in the video area since those were the
> biggest changes).

thanks for testing and letting us know.

greg k-h

Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

[Greg Kroah-Hartman]

On Thu, Feb 15, 2018 at 06:31:48PM -0800, Brian Norris wrote:
> On Thu, Feb 15, 2018 at 04:17:32PM +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> Consider this an objection:
> 
> I'm currently arguing that this is unnecessarily regressing power
> consumption here:
> 
> https://patchwork.kernel.org/patch/10149195/
> 
> I'll leave it up to you what to do with this, but if this ends up in
> Chromium OS kernels, I'm likely to revert it there...

Is that patch in Linus's tree yet?  If so, I'll be glad to also apply it
here.

thanks,

greg k-h

Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

[Greg Kroah-Hartman]

On Thu, Feb 15, 2018 at 06:31:48PM -0800, Brian Norris wrote:
> On Thu, Feb 15, 2018 at 04:17:32PM +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> Consider this an objection:
> 
> I'm currently arguing that this is unnecessarily regressing power
> consumption here:
> 
> https://patchwork.kernel.org/patch/10149195/
> 
> I'll leave it up to you what to do with this, but if this ends up in
> Chromium OS kernels, I'm likely to revert it there...

Is that patch in Linus's tree yet?  If so, I'll be glad to also apply it
here.

thanks,

greg k-h

Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect

[Javier Gonzalez]

> On 15 Feb 2018, at 05.11, Matias Bjørling  wrote:
> 
> The value of max_phys_sect is always static. Instead of
> defining it in the nvm_dev_ops structure, declare it as a global
> value.
> 
> Signed-off-by: Matias Bjørling 
> ---
> drivers/lightnvm/core.c  | 28 +++-
> drivers/lightnvm/pblk-init.c |  9 -
> drivers/lightnvm/pblk-recovery.c |  8 ++--
> drivers/nvme/host/lightnvm.c |  5 +
> include/linux/lightnvm.h |  5 ++---
> 5 files changed, 16 insertions(+), 39 deletions(-)
> 

The patch looks good, but I have a question. If a target implements the
scalar interface, then it will not be limited to 64 lbas/ppas and it
will not make sense to split the bio base don this value. In fact, it
looks like in time, we will move to a scalar interface in the 2.0 path
to align with the zoned interface, so this value will be dependent on
whether the target is using the scalar or vector interface.

Javier


signature.asc
Description: Message signed with OpenPGP

Re: [PATCH v2 5/6] lightnvm: remove nvm_dev_ops->max_phys_sect

[Javier Gonzalez]

> On 15 Feb 2018, at 05.11, Matias Bjørling  wrote:
> 
> The value of max_phys_sect is always static. Instead of
> defining it in the nvm_dev_ops structure, declare it as a global
> value.
> 
> Signed-off-by: Matias Bjørling 
> ---
> drivers/lightnvm/core.c  | 28 +++-
> drivers/lightnvm/pblk-init.c |  9 -
> drivers/lightnvm/pblk-recovery.c |  8 ++--
> drivers/nvme/host/lightnvm.c |  5 +
> include/linux/lightnvm.h |  5 ++---
> 5 files changed, 16 insertions(+), 39 deletions(-)
> 

The patch looks good, but I have a question. If a target implements the
scalar interface, then it will not be limited to 64 lbas/ppas and it
will not make sense to split the bio base don this value. In fact, it
looks like in time, we will move to a scalar interface in the 2.0 path
to align with the zoned interface, so this value will be dependent on
whether the target is using the scalar or vector interface.

Javier


signature.asc
Description: Message signed with OpenPGP

Re: [PATCH 6/8] lightnvm: pblk: implement get log report chunk

[Javier González]

> On 15 Feb 2018, at 02.59, Matias Bjørling  wrote:
> 
> On 02/13/2018 03:06 PM, Javier González wrote:
>> From: Javier González 
>> In preparation of pblk supporting 2.0, implement the get log report
>> chunk in pblk.
>> This patch only replicates de bad block functionality as the rest of the
>> metadata requires new pblk functionality (e.g., wear-index to implement
>> wear-leveling). This functionality will come in future patches.
>> Signed-off-by: Javier González 
>> ---
>>  drivers/lightnvm/pblk-core.c  | 118 +++
>>  drivers/lightnvm/pblk-init.c  | 186 
>> +++---
>>  drivers/lightnvm/pblk-sysfs.c |  67 +++
>>  drivers/lightnvm/pblk.h   |  20 +
>>  4 files changed, 327 insertions(+), 64 deletions(-)
>> diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c
>> index 519af8b9eab7..01b78ee5c0e0 100644
>> --- a/drivers/lightnvm/pblk-core.c
>> +++ b/drivers/lightnvm/pblk-core.c
>> @@ -44,11 +44,12 @@ static void pblk_line_mark_bb(struct work_struct *work)
>>  }
>>static void pblk_mark_bb(struct pblk *pblk, struct pblk_line *line,
>> - struct ppa_addr *ppa)
>> + struct ppa_addr ppa_addr)
>>  {
>>  struct nvm_tgt_dev *dev = pblk->dev;
>>  struct nvm_geo *geo = >geo;
>> -int pos = pblk_ppa_to_pos(geo, *ppa);
>> +struct ppa_addr *ppa;
>> +int pos = pblk_ppa_to_pos(geo, ppa_addr);
>>  pr_debug("pblk: erase failed: line:%d, pos:%d\n", line->id, pos);
>>  atomic_long_inc(>erase_failed);
>> @@ -58,6 +59,15 @@ static void pblk_mark_bb(struct pblk *pblk, struct 
>> pblk_line *line,
>>  pr_err("pblk: attempted to erase bb: line:%d, pos:%d\n",
>>  line->id, pos);
>>  +   /* Not necessary to mark bad blocks on 2.0 spec. */
>> +if (geo->c.version == NVM_OCSSD_SPEC_20)
>> +return;
>> +
>> +ppa = kmalloc(sizeof(struct ppa_addr), GFP_ATOMIC);
>> +if (!ppa)
>> +return;
>> +
>> +*ppa = ppa_addr;
>>  pblk_gen_run_ws(pblk, NULL, ppa, pblk_line_mark_bb,
>>  GFP_ATOMIC, pblk->bb_wq);
>>  }
>> @@ -69,16 +79,8 @@ static void __pblk_end_io_erase(struct pblk *pblk, struct 
>> nvm_rq *rqd)
>>  line = >lines[pblk_ppa_to_line(rqd->ppa_addr)];
>>  atomic_dec(>left_seblks);
>>  -   if (rqd->error) {
>> -struct ppa_addr *ppa;
>> -
>> -ppa = kmalloc(sizeof(struct ppa_addr), GFP_ATOMIC);
>> -if (!ppa)
>> -return;
>> -
>> -*ppa = rqd->ppa_addr;
>> -pblk_mark_bb(pblk, line, ppa);
>> -}
>> +if (rqd->error)
>> +pblk_mark_bb(pblk, line, rqd->ppa_addr);
>>  atomic_dec(>inflight_io);
>>  }
>> @@ -92,6 +94,47 @@ static void pblk_end_io_erase(struct nvm_rq *rqd)
>>  mempool_free(rqd, pblk->e_rq_pool);
>>  }
>>  +/*
>> + * Get information for all chunks from the device.
>> + *
>> + * The caller is responsible for freeing the returned structure
>> + */
>> +struct nvm_chunk_log_page *pblk_chunk_get_info(struct pblk *pblk)
>> +{
>> +struct nvm_tgt_dev *dev = pblk->dev;
>> +struct nvm_geo *geo = >geo;
>> +struct nvm_chunk_log_page *log;
>> +unsigned long len;
>> +int ret;
>> +
>> +len = geo->all_chunks * sizeof(*log);
>> +log = kzalloc(len, GFP_KERNEL);
>> +if (!log)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +ret = nvm_get_chunk_log_page(dev, log, 0, len);
>> +if (ret) {
>> +pr_err("pblk: could not get chunk log page (%d)\n", ret);
>> +kfree(log);
>> +return ERR_PTR(-EIO);
>> +}
>> +
>> +return log;
>> +}
>> +
>> +struct nvm_chunk_log_page *pblk_chunk_get_off(struct pblk *pblk,
>> +  struct nvm_chunk_log_page *lp,
>> +  struct ppa_addr ppa)
>> +{
>> +struct nvm_tgt_dev *dev = pblk->dev;
>> +struct nvm_geo *geo = >geo;
>> +int ch_off = ppa.m.ch * geo->c.num_chk * geo->num_lun;
>> +int lun_off = ppa.m.lun * geo->c.num_chk;
>> +int chk_off = ppa.m.chk;
>> +
>> +return lp + ch_off + lun_off + chk_off;
>> +}
>> +
>>  void __pblk_map_invalidate(struct pblk *pblk, struct pblk_line *line,
>> u64 paddr)
>>  {
>> @@ -1094,10 +1137,38 @@ static int pblk_line_init_bb(struct pblk *pblk, 
>> struct pblk_line *line,
>>  return 1;
>>  }
>>  +static int pblk_prepare_new_line(struct pblk *pblk, struct pblk_line *line)
>> +{
>> +struct pblk_line_meta *lm = >lm;
>> +struct nvm_tgt_dev *dev = pblk->dev;
>> +struct nvm_geo *geo = >geo;
>> +int blk_to_erase = atomic_read(>blk_in_line);
>> +int i;
>> +
>> +for (i = 0; i < lm->blk_per_line; i++) {
>> +int state = line->chks[i].state;
>> +struct pblk_lun *rlun = >luns[i];
>> +

Re: [PATCH 6/8] lightnvm: pblk: implement get log report chunk

[Javier González]

> On 15 Feb 2018, at 02.59, Matias Bjørling  wrote:
> 
> On 02/13/2018 03:06 PM, Javier González wrote:
>> From: Javier González 
>> In preparation of pblk supporting 2.0, implement the get log report
>> chunk in pblk.
>> This patch only replicates de bad block functionality as the rest of the
>> metadata requires new pblk functionality (e.g., wear-index to implement
>> wear-leveling). This functionality will come in future patches.
>> Signed-off-by: Javier González 
>> ---
>>  drivers/lightnvm/pblk-core.c  | 118 +++
>>  drivers/lightnvm/pblk-init.c  | 186 
>> +++---
>>  drivers/lightnvm/pblk-sysfs.c |  67 +++
>>  drivers/lightnvm/pblk.h   |  20 +
>>  4 files changed, 327 insertions(+), 64 deletions(-)
>> diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c
>> index 519af8b9eab7..01b78ee5c0e0 100644
>> --- a/drivers/lightnvm/pblk-core.c
>> +++ b/drivers/lightnvm/pblk-core.c
>> @@ -44,11 +44,12 @@ static void pblk_line_mark_bb(struct work_struct *work)
>>  }
>>static void pblk_mark_bb(struct pblk *pblk, struct pblk_line *line,
>> - struct ppa_addr *ppa)
>> + struct ppa_addr ppa_addr)
>>  {
>>  struct nvm_tgt_dev *dev = pblk->dev;
>>  struct nvm_geo *geo = >geo;
>> -int pos = pblk_ppa_to_pos(geo, *ppa);
>> +struct ppa_addr *ppa;
>> +int pos = pblk_ppa_to_pos(geo, ppa_addr);
>>  pr_debug("pblk: erase failed: line:%d, pos:%d\n", line->id, pos);
>>  atomic_long_inc(>erase_failed);
>> @@ -58,6 +59,15 @@ static void pblk_mark_bb(struct pblk *pblk, struct 
>> pblk_line *line,
>>  pr_err("pblk: attempted to erase bb: line:%d, pos:%d\n",
>>  line->id, pos);
>>  +   /* Not necessary to mark bad blocks on 2.0 spec. */
>> +if (geo->c.version == NVM_OCSSD_SPEC_20)
>> +return;
>> +
>> +ppa = kmalloc(sizeof(struct ppa_addr), GFP_ATOMIC);
>> +if (!ppa)
>> +return;
>> +
>> +*ppa = ppa_addr;
>>  pblk_gen_run_ws(pblk, NULL, ppa, pblk_line_mark_bb,
>>  GFP_ATOMIC, pblk->bb_wq);
>>  }
>> @@ -69,16 +79,8 @@ static void __pblk_end_io_erase(struct pblk *pblk, struct 
>> nvm_rq *rqd)
>>  line = >lines[pblk_ppa_to_line(rqd->ppa_addr)];
>>  atomic_dec(>left_seblks);
>>  -   if (rqd->error) {
>> -struct ppa_addr *ppa;
>> -
>> -ppa = kmalloc(sizeof(struct ppa_addr), GFP_ATOMIC);
>> -if (!ppa)
>> -return;
>> -
>> -*ppa = rqd->ppa_addr;
>> -pblk_mark_bb(pblk, line, ppa);
>> -}
>> +if (rqd->error)
>> +pblk_mark_bb(pblk, line, rqd->ppa_addr);
>>  atomic_dec(>inflight_io);
>>  }
>> @@ -92,6 +94,47 @@ static void pblk_end_io_erase(struct nvm_rq *rqd)
>>  mempool_free(rqd, pblk->e_rq_pool);
>>  }
>>  +/*
>> + * Get information for all chunks from the device.
>> + *
>> + * The caller is responsible for freeing the returned structure
>> + */
>> +struct nvm_chunk_log_page *pblk_chunk_get_info(struct pblk *pblk)
>> +{
>> +struct nvm_tgt_dev *dev = pblk->dev;
>> +struct nvm_geo *geo = >geo;
>> +struct nvm_chunk_log_page *log;
>> +unsigned long len;
>> +int ret;
>> +
>> +len = geo->all_chunks * sizeof(*log);
>> +log = kzalloc(len, GFP_KERNEL);
>> +if (!log)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +ret = nvm_get_chunk_log_page(dev, log, 0, len);
>> +if (ret) {
>> +pr_err("pblk: could not get chunk log page (%d)\n", ret);
>> +kfree(log);
>> +return ERR_PTR(-EIO);
>> +}
>> +
>> +return log;
>> +}
>> +
>> +struct nvm_chunk_log_page *pblk_chunk_get_off(struct pblk *pblk,
>> +  struct nvm_chunk_log_page *lp,
>> +  struct ppa_addr ppa)
>> +{
>> +struct nvm_tgt_dev *dev = pblk->dev;
>> +struct nvm_geo *geo = >geo;
>> +int ch_off = ppa.m.ch * geo->c.num_chk * geo->num_lun;
>> +int lun_off = ppa.m.lun * geo->c.num_chk;
>> +int chk_off = ppa.m.chk;
>> +
>> +return lp + ch_off + lun_off + chk_off;
>> +}
>> +
>>  void __pblk_map_invalidate(struct pblk *pblk, struct pblk_line *line,
>> u64 paddr)
>>  {
>> @@ -1094,10 +1137,38 @@ static int pblk_line_init_bb(struct pblk *pblk, 
>> struct pblk_line *line,
>>  return 1;
>>  }
>>  +static int pblk_prepare_new_line(struct pblk *pblk, struct pblk_line *line)
>> +{
>> +struct pblk_line_meta *lm = >lm;
>> +struct nvm_tgt_dev *dev = pblk->dev;
>> +struct nvm_geo *geo = >geo;
>> +int blk_to_erase = atomic_read(>blk_in_line);
>> +int i;
>> +
>> +for (i = 0; i < lm->blk_per_line; i++) {
>> +int state = line->chks[i].state;
>> +struct pblk_lun *rlun = >luns[i];
>> +
>> +/* Free chunks should not be erased */
>> 

Re: [PATCH 2/8] lightnvm: show generic geometry in sysfs

[Javier Gonzalez]

> On 15 Feb 2018, at 02.20, Matias Bjørling  wrote:
> 
> On 02/13/2018 03:06 PM, Javier González wrote:
>> From: Javier González 
>> Apart from showing the geometry returned by the different identify
>> commands, provide the generic geometry too, as this is the geometry that
>> targets will use to describe the device.
>> Signed-off-by: Javier González 
>> ---
>>  drivers/nvme/host/lightnvm.c | 146 
>> ---
>>  1 file changed, 97 insertions(+), 49 deletions(-)
>> diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
>> index 97739e668602..7bc75182c723 100644
>> --- a/drivers/nvme/host/lightnvm.c
>> +++ b/drivers/nvme/host/lightnvm.c
>> @@ -944,8 +944,27 @@ static ssize_t nvm_dev_attr_show(struct device *dev,
>>  return scnprintf(page, PAGE_SIZE, "%u.%u\n",
>>  dev_geo->major_ver_id,
>>  dev_geo->minor_ver_id);
>> -} else if (strcmp(attr->name, "capabilities") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.cap);
>> +} else if (strcmp(attr->name, "clba") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.clba);
>> +} else if (strcmp(attr->name, "csecs") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.csecs);
>> +} else if (strcmp(attr->name, "sos") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.sos);
>> +} else if (strcmp(attr->name, "ws_min") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.ws_min);
>> +} else if (strcmp(attr->name, "ws_opt") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.ws_opt);
>> +} else if (strcmp(attr->name, "maxoc") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.maxoc);
>> +} else if (strcmp(attr->name, "maxocpu") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.maxocpu);
>> +} else if (strcmp(attr->name, "mw_cunits") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mw_cunits);
>> +} else if (strcmp(attr->name, "media_capabilities") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mccap);
>> +} else if (strcmp(attr->name, "max_phys_secs") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n",
>> +ndev->ops->max_phys_sect);
>>  } else if (strcmp(attr->name, "read_typ") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.trdt);
>>  } else if (strcmp(attr->name, "read_max") == 0) {
>> @@ -984,19 +1003,8 @@ static ssize_t nvm_dev_attr_show_12(struct device *dev,
>>  attr = >attr;
>>  -   if (strcmp(attr->name, "vendor_opcode") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.vmnt);
>> -} else if (strcmp(attr->name, "device_mode") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.dom);
>> -/* kept for compatibility */
>> -} else if (strcmp(attr->name, "media_manager") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%s\n", "gennvm");
>> -} else if (strcmp(attr->name, "ppa_format") == 0) {
>> +if (strcmp(attr->name, "ppa_format") == 0) {
>>  return nvm_dev_attr_show_ppaf((void *)_geo->c.addrf, page);
>> -} else if (strcmp(attr->name, "media_type") == 0) { /* u8 */
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mtype);
>> -} else if (strcmp(attr->name, "flash_media_type") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.fmtype);
>>  } else if (strcmp(attr->name, "num_channels") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->num_ch);
>>  } else if (strcmp(attr->name, "num_luns") == 0) {
>> @@ -1011,8 +1019,6 @@ static ssize_t nvm_dev_attr_show_12(struct device *dev,
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.fpg_sz);
>>  } else if (strcmp(attr->name, "hw_sector_size") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.csecs);
>> -} else if (strcmp(attr->name, "oob_sector_size") == 0) {/* u32 */
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.sos);
>>  } else if (strcmp(attr->name, "prog_typ") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tprt);
>>  } else if (strcmp(attr->name, "prog_max") == 0) {
>> @@ -1021,13 +1027,21 @@ static ssize_t nvm_dev_attr_show_12(struct device 
>> *dev,
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tbet);
>>  } else if (strcmp(attr->name, "erase_max") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tbem);
>> +} else if (strcmp(attr->name, "vendor_opcode") == 0) {
>> +

Re: [PATCH 2/8] lightnvm: show generic geometry in sysfs

[Javier Gonzalez]

> On 15 Feb 2018, at 02.20, Matias Bjørling  wrote:
> 
> On 02/13/2018 03:06 PM, Javier González wrote:
>> From: Javier González 
>> Apart from showing the geometry returned by the different identify
>> commands, provide the generic geometry too, as this is the geometry that
>> targets will use to describe the device.
>> Signed-off-by: Javier González 
>> ---
>>  drivers/nvme/host/lightnvm.c | 146 
>> ---
>>  1 file changed, 97 insertions(+), 49 deletions(-)
>> diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
>> index 97739e668602..7bc75182c723 100644
>> --- a/drivers/nvme/host/lightnvm.c
>> +++ b/drivers/nvme/host/lightnvm.c
>> @@ -944,8 +944,27 @@ static ssize_t nvm_dev_attr_show(struct device *dev,
>>  return scnprintf(page, PAGE_SIZE, "%u.%u\n",
>>  dev_geo->major_ver_id,
>>  dev_geo->minor_ver_id);
>> -} else if (strcmp(attr->name, "capabilities") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.cap);
>> +} else if (strcmp(attr->name, "clba") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.clba);
>> +} else if (strcmp(attr->name, "csecs") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.csecs);
>> +} else if (strcmp(attr->name, "sos") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.sos);
>> +} else if (strcmp(attr->name, "ws_min") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.ws_min);
>> +} else if (strcmp(attr->name, "ws_opt") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.ws_opt);
>> +} else if (strcmp(attr->name, "maxoc") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.maxoc);
>> +} else if (strcmp(attr->name, "maxocpu") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.maxocpu);
>> +} else if (strcmp(attr->name, "mw_cunits") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mw_cunits);
>> +} else if (strcmp(attr->name, "media_capabilities") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mccap);
>> +} else if (strcmp(attr->name, "max_phys_secs") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n",
>> +ndev->ops->max_phys_sect);
>>  } else if (strcmp(attr->name, "read_typ") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.trdt);
>>  } else if (strcmp(attr->name, "read_max") == 0) {
>> @@ -984,19 +1003,8 @@ static ssize_t nvm_dev_attr_show_12(struct device *dev,
>>  attr = >attr;
>>  -   if (strcmp(attr->name, "vendor_opcode") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.vmnt);
>> -} else if (strcmp(attr->name, "device_mode") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.dom);
>> -/* kept for compatibility */
>> -} else if (strcmp(attr->name, "media_manager") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%s\n", "gennvm");
>> -} else if (strcmp(attr->name, "ppa_format") == 0) {
>> +if (strcmp(attr->name, "ppa_format") == 0) {
>>  return nvm_dev_attr_show_ppaf((void *)_geo->c.addrf, page);
>> -} else if (strcmp(attr->name, "media_type") == 0) { /* u8 */
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.mtype);
>> -} else if (strcmp(attr->name, "flash_media_type") == 0) {
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.fmtype);
>>  } else if (strcmp(attr->name, "num_channels") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->num_ch);
>>  } else if (strcmp(attr->name, "num_luns") == 0) {
>> @@ -1011,8 +1019,6 @@ static ssize_t nvm_dev_attr_show_12(struct device *dev,
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.fpg_sz);
>>  } else if (strcmp(attr->name, "hw_sector_size") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.csecs);
>> -} else if (strcmp(attr->name, "oob_sector_size") == 0) {/* u32 */
>> -return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.sos);
>>  } else if (strcmp(attr->name, "prog_typ") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tprt);
>>  } else if (strcmp(attr->name, "prog_max") == 0) {
>> @@ -1021,13 +1027,21 @@ static ssize_t nvm_dev_attr_show_12(struct device 
>> *dev,
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tbet);
>>  } else if (strcmp(attr->name, "erase_max") == 0) {
>>  return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.tbem);
>> +} else if (strcmp(attr->name, "vendor_opcode") == 0) {
>> +return scnprintf(page, PAGE_SIZE, "%u\n", dev_geo->c.vmnt);

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

[Richard Guy Briggs]

On 2018-02-15 18:19, Richard Guy Briggs wrote:
> On 2018-02-15 18:07, Steve Grubb wrote:
> > On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote:
> > > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > > records to be associated with the init_module and finit_module SYSCALL
> > > records on a few modules when the following rule was in place for
> > > startup:
> > > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> > > 
> > > This happens because the parent inode is not found in the task's
> > > audit_names list and hence treats it as anonymous.  This gives us no
> > > information other than a numerical device number for a device that may
> > > no longer be visible upon log inspeciton, and an inode number.
> > > 
> > > Fill in the partial known pathname from the filesystem mount point to
> > > the leaf node on previously null PATH records from entries that have an
> > > anonymous parent from the child dentry using dentry_path_raw().
> > > 
> > > Make the dentry argument of __audit_inode_child() non-const so that we
> > > can take a reference to it in the case of an anonymous parent with
> > > dget() and dget_parent() to be able to later print a partial path from
> > > the host filesystem rather than null.
> > > 
> > > Since all we are given is an inode of the parent and the dentry of the
> > > child, finding the path from the mount point to the root of the
> > > filesystem is more challenging that would involve searching all
> > > vfsmounts from "/" until a matching dentry is found for that
> > > filesystem's root dentry.  Even if one is found, there may be more than
> > > one mount point.  At this point the gain seems marginal since
> > > knowing the filesystem type and path are a significant help in tracking
> > > down the source of the PATH records and being able to address them.
> > > 
> > > Sample output:
> > > type=PROCTITLE msg=audit(1488317694.446:143):
> > > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634 type=PATH
> > > msg=audit(1488317694.446:143): item=797
> > > name=events/nfs4/nfs4_setclientid/format inode=15969 dev=00:09
> > > mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > > nametype=CREATE cap_fp= cap_fi= cap_fe=0
> > > cap_fver=0 type=PATH msg=audit(1488317694.446:143): item=796
> > > name=events/nfs4/nfs4_setclientid inode=15964 dev=00:09 mode=040755 ouid=0
> > > ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> > > cap_fp= cap_fi= cap_fe=0 cap_fver=0 ...
> > > type=PATH msg=audit(1488317694.446:143): item=1 name=events/nfs4
> > > inode=15571 dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00
> > > obj=system_u:object_r:tracefs_t:s0 nametype=CREATE cap_fp=
> > > cap_fi= cap_fe=0 cap_fver=0 type=PATH
> > > msg=audit(1488317694.446:143): item=0 name=events inode=119 dev=00:09
> > > mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > > nametype=PARENT cap_fp= cap_fi= cap_fe=0
> > > cap_fver=0 type=KERN_MODULE msg=audit(1488317694.446:143): name="nfsv4"
> > > type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313
> > > success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6 pid=528
> > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> > > tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod"
> > > subj=system_u:system_r:insmod_t:s0 key="mod-load"

So, updated sample output is:
type=SYSCALL msg=audit(1518738520.800:264): arch=c03e syscall=313 
success=yes exit=0 a0=8 a1=55c51f395fc6 a2=0 a3=8 items=834 ppid=579 pid=608 
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=1 
comm="modprobe" exe="/usr/bin/kmod" 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="mod-load"
type=KERN_MODULE msg=audit(1518738520.800:264): name="nfsv4"
type=PATH msg=audit(1518738520.800:264): item=0 name="events" inode=127 
dev=00:0b mode=040755 ouid=0 ogid=0 rdev=00:00 
obj=system_u:object_r:tracefs_t:s0 nametype=PARENT_ANON cap_fp= 
cap_fi= cap_fe=0 cap_fver=0 fstype=0x74726163
type=PATH msg=audit(1518738520.800:264): item=1 name="events/nfs4" inode=17795 
dev=00:0b mode=040755 ouid=0 ogid=0 rdev=00:00 
obj=system_u:object_r:tracefs_t:s0 nametype=CREATE_ANON cap_fp= 
cap_fi= cap_fe=0 cap_fver=0 fstype=0x74726163
...
type=PATH msg=audit(1518738520.800:264): item=832 
name="events/nfs4/nfs4_setclientid" inode=18206 dev=00:0b mode=040755 ouid=0 
ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT_ANON 
cap_fp= cap_fi= cap_fe=0 cap_fver=0 
fstype=0x74726163
type=PATH msg=audit(1518738520.800:264): item=833 
name="events/nfs4/nfs4_setclientid/format" inode=18211 dev=00:0b mode=0100444 
ouid=0 ogid=0 rdev=00:00 

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

[Richard Guy Briggs]

On 2018-02-15 18:19, Richard Guy Briggs wrote:
> On 2018-02-15 18:07, Steve Grubb wrote:
> > On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote:
> > > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > > records to be associated with the init_module and finit_module SYSCALL
> > > records on a few modules when the following rule was in place for
> > > startup:
> > > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> > > 
> > > This happens because the parent inode is not found in the task's
> > > audit_names list and hence treats it as anonymous.  This gives us no
> > > information other than a numerical device number for a device that may
> > > no longer be visible upon log inspeciton, and an inode number.
> > > 
> > > Fill in the partial known pathname from the filesystem mount point to
> > > the leaf node on previously null PATH records from entries that have an
> > > anonymous parent from the child dentry using dentry_path_raw().
> > > 
> > > Make the dentry argument of __audit_inode_child() non-const so that we
> > > can take a reference to it in the case of an anonymous parent with
> > > dget() and dget_parent() to be able to later print a partial path from
> > > the host filesystem rather than null.
> > > 
> > > Since all we are given is an inode of the parent and the dentry of the
> > > child, finding the path from the mount point to the root of the
> > > filesystem is more challenging that would involve searching all
> > > vfsmounts from "/" until a matching dentry is found for that
> > > filesystem's root dentry.  Even if one is found, there may be more than
> > > one mount point.  At this point the gain seems marginal since
> > > knowing the filesystem type and path are a significant help in tracking
> > > down the source of the PATH records and being able to address them.
> > > 
> > > Sample output:
> > > type=PROCTITLE msg=audit(1488317694.446:143):
> > > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634 type=PATH
> > > msg=audit(1488317694.446:143): item=797
> > > name=events/nfs4/nfs4_setclientid/format inode=15969 dev=00:09
> > > mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > > nametype=CREATE cap_fp= cap_fi= cap_fe=0
> > > cap_fver=0 type=PATH msg=audit(1488317694.446:143): item=796
> > > name=events/nfs4/nfs4_setclientid inode=15964 dev=00:09 mode=040755 ouid=0
> > > ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> > > cap_fp= cap_fi= cap_fe=0 cap_fver=0 ...
> > > type=PATH msg=audit(1488317694.446:143): item=1 name=events/nfs4
> > > inode=15571 dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00
> > > obj=system_u:object_r:tracefs_t:s0 nametype=CREATE cap_fp=
> > > cap_fi= cap_fe=0 cap_fver=0 type=PATH
> > > msg=audit(1488317694.446:143): item=0 name=events inode=119 dev=00:09
> > > mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > > nametype=PARENT cap_fp= cap_fi= cap_fe=0
> > > cap_fver=0 type=KERN_MODULE msg=audit(1488317694.446:143): name="nfsv4"
> > > type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313
> > > success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6 pid=528
> > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> > > tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod"
> > > subj=system_u:system_r:insmod_t:s0 key="mod-load"

So, updated sample output is:
type=SYSCALL msg=audit(1518738520.800:264): arch=c03e syscall=313 
success=yes exit=0 a0=8 a1=55c51f395fc6 a2=0 a3=8 items=834 ppid=579 pid=608 
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS0 ses=1 
comm="modprobe" exe="/usr/bin/kmod" 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="mod-load"
type=KERN_MODULE msg=audit(1518738520.800:264): name="nfsv4"
type=PATH msg=audit(1518738520.800:264): item=0 name="events" inode=127 
dev=00:0b mode=040755 ouid=0 ogid=0 rdev=00:00 
obj=system_u:object_r:tracefs_t:s0 nametype=PARENT_ANON cap_fp= 
cap_fi= cap_fe=0 cap_fver=0 fstype=0x74726163
type=PATH msg=audit(1518738520.800:264): item=1 name="events/nfs4" inode=17795 
dev=00:0b mode=040755 ouid=0 ogid=0 rdev=00:00 
obj=system_u:object_r:tracefs_t:s0 nametype=CREATE_ANON cap_fp= 
cap_fi= cap_fe=0 cap_fver=0 fstype=0x74726163
...
type=PATH msg=audit(1518738520.800:264): item=832 
name="events/nfs4/nfs4_setclientid" inode=18206 dev=00:0b mode=040755 ouid=0 
ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT_ANON 
cap_fp= cap_fi= cap_fe=0 cap_fver=0 
fstype=0x74726163
type=PATH msg=audit(1518738520.800:264): item=833 
name="events/nfs4/nfs4_setclientid/format" inode=18211 dev=00:0b mode=0100444 
ouid=0 ogid=0 rdev=00:00 

[PATCH v4 0/4] Add DTS for SDM845 SoC and MTP

[Rajendra Nayak]

These are basic device tree files needed to boot a SDM845 MTP
board to a ramfs based serial console shell

Bindings are based on whats proposed for pinctrl/serial/clock
drivers for SDM845 SoC
pinctrl: https://patchwork.kernel.org/patch/10157143/ (This is now pulled
in by Linus Walleij for 4.17)
clocks: https://lkml.org/lkml/2018/1/31/209 (under review)
serial: https://patchwork.ozlabs.org/cover/860251/ (under review)

'PATCH 3/3' is based on v2 of serial patches, will need an update if
v3 (still in the works) has further binding updates

Since 'PATCH 2/3' also adds an ITS node and keeps it disabled, we also depend
on https://lkml.org/lkml/2018/1/29/383

changes in v4:
* pull config changes to uart pins
* License in device tree files is still GPL-2.0

changes in v3:
* split the pinmux/pinconf nodes across SoC/Board files
* Fixes for issues reported with 'make dtbs W=2'
* other minor fixes based on review
 
changes in v2:
* dropped cpu-map
* dropped GIC_CPU_MASK_SIMPLE()
* Added new cpu compatible for kryo385
* added ITS node, marked as disabled

Rajendra Nayak (4):
  dt-bindings: arm: Document kryo385 cpu
  dt-bindings: qcom: Add SDM845 bindings
  arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP
  arm64: dts: sdm845: Add serial console support

 Documentation/devicetree/bindings/arm/cpus.txt |   1 +
 Documentation/devicetree/bindings/arm/qcom.txt |   1 +
 arch/arm64/boot/dts/qcom/Makefile  |   1 +
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts|  54 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi   | 316 +
 5 files changed, 373 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845.dtsi

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 0/4] Add DTS for SDM845 SoC and MTP

[Rajendra Nayak]

These are basic device tree files needed to boot a SDM845 MTP
board to a ramfs based serial console shell

Bindings are based on whats proposed for pinctrl/serial/clock
drivers for SDM845 SoC
pinctrl: https://patchwork.kernel.org/patch/10157143/ (This is now pulled
in by Linus Walleij for 4.17)
clocks: https://lkml.org/lkml/2018/1/31/209 (under review)
serial: https://patchwork.ozlabs.org/cover/860251/ (under review)

'PATCH 3/3' is based on v2 of serial patches, will need an update if
v3 (still in the works) has further binding updates

Since 'PATCH 2/3' also adds an ITS node and keeps it disabled, we also depend
on https://lkml.org/lkml/2018/1/29/383

changes in v4:
* pull config changes to uart pins
* License in device tree files is still GPL-2.0

changes in v3:
* split the pinmux/pinconf nodes across SoC/Board files
* Fixes for issues reported with 'make dtbs W=2'
* other minor fixes based on review
 
changes in v2:
* dropped cpu-map
* dropped GIC_CPU_MASK_SIMPLE()
* Added new cpu compatible for kryo385
* added ITS node, marked as disabled

Rajendra Nayak (4):
  dt-bindings: arm: Document kryo385 cpu
  dt-bindings: qcom: Add SDM845 bindings
  arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP
  arm64: dts: sdm845: Add serial console support

 Documentation/devicetree/bindings/arm/cpus.txt |   1 +
 Documentation/devicetree/bindings/arm/qcom.txt |   1 +
 arch/arm64/boot/dts/qcom/Makefile  |   1 +
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts|  54 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi   | 316 +
 5 files changed, 373 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845.dtsi

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 4/4] arm64: dts: sdm845: Add serial console support

[Rajendra Nayak]

Add the qup uart node and geni se instance needed to
support the serial console on the MTP.

Signed-off-by: Rajendra Nayak 
---
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 39 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi| 39 +
 2 files changed, 78 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 979ab49913f1..2a1ed55b703e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -12,4 +12,43 @@
 / {
model = "Qualcomm Technologies, Inc. SDM845 MTP";
compatible = "qcom,sdm845-mtp";
+
+   aliases {
+   serial0 = _uart2;
+   };
+
+   chosen {
+   stdout-path = "serial0";
+   };
+};
+
+ {
+   geni-se@ac {
+   serial@a84000 {
+   status = "okay";
+   };
+   };
+
+   pinctrl@340 {
+   qup-uart2-default {
+   pinconf_tx {
+   pins = "gpio4";
+   drive-strength = <2>;
+   bias-disable;
+   };
+
+   pinconf_rx {
+   pins = "gpio5";
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+   };
+
+   qup-uart2-sleep {
+   pinconf {
+   pins = "gpio4", "gpio5";
+   bias-pull-down;
+   };
+   };
+   };
 };
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c46e726af621..7b5c16eb63b7 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 
 / {
interrupt-parent = <>;
@@ -195,6 +196,20 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+
+   qup_uart2_default: qup-uart2-default {
+   pinmux {
+   function = "qup9";
+   pins = "gpio4", "gpio5";
+   };
+   };
+
+   qup_uart2_sleep: qup-uart2-sleep {
+   pinmux {
+   function = "gpio";
+   pins = "gpio4", "gpio5";
+   };
+   };
};
 
timer@17c9 {
@@ -273,5 +288,29 @@
#interrupt-cells = <4>;
cell-index = <0>;
};
+
+   geni-se@ac {
+   compatible = "qcom,geni-se-qup";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   reg = <0xac 0x6000>;
+   clocks = < GCC_QUPV3_WRAP_1_M_AHB_CLK>,
+< GCC_QUPV3_WRAP_1_S_AHB_CLK>;
+   clock-names = "m-ahb", "s-ahb";
+
+   qup_uart2: serial@a84000 {
+   compatible = "qcom,geni-debug-uart";
+   reg = <0xa84000 0x4000>;
+   reg-names = "se-phys";
+   clock-names = "se-clk";
+   clocks = < GCC_QUPV3_WRAP1_S1_CLK>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_uart2_default>;
+   pinctrl-1 = <_uart2_sleep>;
+   interrupts = ;
+   status = "disabled";
+   };
+   };
};
 };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 4/4] arm64: dts: sdm845: Add serial console support

[Rajendra Nayak]

Add the qup uart node and geni se instance needed to
support the serial console on the MTP.

Signed-off-by: Rajendra Nayak 
---
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 39 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi| 39 +
 2 files changed, 78 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 979ab49913f1..2a1ed55b703e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -12,4 +12,43 @@
 / {
model = "Qualcomm Technologies, Inc. SDM845 MTP";
compatible = "qcom,sdm845-mtp";
+
+   aliases {
+   serial0 = _uart2;
+   };
+
+   chosen {
+   stdout-path = "serial0";
+   };
+};
+
+ {
+   geni-se@ac {
+   serial@a84000 {
+   status = "okay";
+   };
+   };
+
+   pinctrl@340 {
+   qup-uart2-default {
+   pinconf_tx {
+   pins = "gpio4";
+   drive-strength = <2>;
+   bias-disable;
+   };
+
+   pinconf_rx {
+   pins = "gpio5";
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+   };
+
+   qup-uart2-sleep {
+   pinconf {
+   pins = "gpio4", "gpio5";
+   bias-pull-down;
+   };
+   };
+   };
 };
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c46e726af621..7b5c16eb63b7 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 
 / {
interrupt-parent = <>;
@@ -195,6 +196,20 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+
+   qup_uart2_default: qup-uart2-default {
+   pinmux {
+   function = "qup9";
+   pins = "gpio4", "gpio5";
+   };
+   };
+
+   qup_uart2_sleep: qup-uart2-sleep {
+   pinmux {
+   function = "gpio";
+   pins = "gpio4", "gpio5";
+   };
+   };
};
 
timer@17c9 {
@@ -273,5 +288,29 @@
#interrupt-cells = <4>;
cell-index = <0>;
};
+
+   geni-se@ac {
+   compatible = "qcom,geni-se-qup";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   reg = <0xac 0x6000>;
+   clocks = < GCC_QUPV3_WRAP_1_M_AHB_CLK>,
+< GCC_QUPV3_WRAP_1_S_AHB_CLK>;
+   clock-names = "m-ahb", "s-ahb";
+
+   qup_uart2: serial@a84000 {
+   compatible = "qcom,geni-debug-uart";
+   reg = <0xa84000 0x4000>;
+   reg-names = "se-phys";
+   clock-names = "se-clk";
+   clocks = < GCC_QUPV3_WRAP1_S1_CLK>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_uart2_default>;
+   pinctrl-1 = <_uart2_sleep>;
+   interrupts = ;
+   status = "disabled";
+   };
+   };
};
 };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 2/4] dt-bindings: qcom: Add SDM845 bindings

[Rajendra Nayak]

Add a SoC string 'sdm845' for the qualcomm SDM845 SoC

Signed-off-by: Rajendra Nayak 
---
 Documentation/devicetree/bindings/arm/qcom.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.txt 
b/Documentation/devicetree/bindings/arm/qcom.txt
index 0ed4d39d7fe1..ee532e705d6c 100644
--- a/Documentation/devicetree/bindings/arm/qcom.txt
+++ b/Documentation/devicetree/bindings/arm/qcom.txt
@@ -26,6 +26,7 @@ The 'SoC' element must be one of the following strings:
msm8996
mdm9615
ipq8074
+   sdm845
 
 The 'board' element must be one of the following strings:
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 2/4] dt-bindings: qcom: Add SDM845 bindings

[Rajendra Nayak]

Add a SoC string 'sdm845' for the qualcomm SDM845 SoC

Signed-off-by: Rajendra Nayak 
---
 Documentation/devicetree/bindings/arm/qcom.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.txt 
b/Documentation/devicetree/bindings/arm/qcom.txt
index 0ed4d39d7fe1..ee532e705d6c 100644
--- a/Documentation/devicetree/bindings/arm/qcom.txt
+++ b/Documentation/devicetree/bindings/arm/qcom.txt
@@ -26,6 +26,7 @@ The 'SoC' element must be one of the following strings:
msm8996
mdm9615
ipq8074
+   sdm845
 
 The 'board' element must be one of the following strings:
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 3/4] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP

[Rajendra Nayak]

Add a skeletal sdm845 SoC dtsi and MTP board dts/dtsi files

Signed-off-by: Rajendra Nayak 
Reviewed-by: Doug Anderson 
---
 arch/arm64/boot/dts/qcom/Makefile   |   1 +
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts |  15 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi| 277 
 3 files changed, 293 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile 
b/arch/arm64/boot/dts/qcom/Makefile
index 55ec5ee7f7e8..9319e74b8906 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -6,3 +6,4 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8992-bullhead-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
new file mode 100644
index ..979ab49913f1
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SDM845 MTP board device tree source
+ *
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "sdm845.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. SDM845 MTP";
+   compatible = "qcom,sdm845-mtp";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
new file mode 100644
index ..c46e726af621
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SDM845 SoC device tree source
+ *
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+
+/ {
+   interrupt-parent = <>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   chosen { };
+
+   memory@8000 {
+   device_type = "memory";
+   /* We expect the bootloader to fill in the size */
+   reg = <0 0x8000 0 0>;
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   CPU0: cpu@0 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   next-level-cache = <_0>;
+   L2_0: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   L3_0: l3-cache {
+ compatible = "cache";
+   };
+   };
+   };
+
+   CPU1: cpu@100 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x100>;
+   enable-method = "psci";
+   next-level-cache = <_100>;
+   L2_100: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU2: cpu@200 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x200>;
+   enable-method = "psci";
+   next-level-cache = <_200>;
+   L2_200: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU3: cpu@300 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x300>;
+   enable-method = "psci";
+   next-level-cache = <_300>;
+   L2_300: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU4: cpu@400 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x400>;
+   enable-method = "psci";
+   next-level-cache = <_400>;
+   L2_400: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU5: cpu@500 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x500>;
+

[PATCH v4 1/4] dt-bindings: arm: Document kryo385 cpu

[Rajendra Nayak]

Document the compatible string for the Kryo385 cpus found in qualcomm
SoCs.

Signed-off-by: Rajendra Nayak 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/cpus.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index a0009b72e9be..19611ccb61d9 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -184,6 +184,7 @@ described below.
"nvidia,tegra186-denver"
"qcom,krait"
"qcom,kryo"
+   "qcom,kryo385"
"qcom,scorpion"
- enable-method
Value type: 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 3/4] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP

[Rajendra Nayak]

Add a skeletal sdm845 SoC dtsi and MTP board dts/dtsi files

Signed-off-by: Rajendra Nayak 
Reviewed-by: Doug Anderson 
---
 arch/arm64/boot/dts/qcom/Makefile   |   1 +
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts |  15 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi| 277 
 3 files changed, 293 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile 
b/arch/arm64/boot/dts/qcom/Makefile
index 55ec5ee7f7e8..9319e74b8906 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -6,3 +6,4 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8992-bullhead-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
new file mode 100644
index ..979ab49913f1
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SDM845 MTP board device tree source
+ *
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "sdm845.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. SDM845 MTP";
+   compatible = "qcom,sdm845-mtp";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
new file mode 100644
index ..c46e726af621
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SDM845 SoC device tree source
+ *
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+
+/ {
+   interrupt-parent = <>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   chosen { };
+
+   memory@8000 {
+   device_type = "memory";
+   /* We expect the bootloader to fill in the size */
+   reg = <0 0x8000 0 0>;
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   CPU0: cpu@0 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   next-level-cache = <_0>;
+   L2_0: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   L3_0: l3-cache {
+ compatible = "cache";
+   };
+   };
+   };
+
+   CPU1: cpu@100 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x100>;
+   enable-method = "psci";
+   next-level-cache = <_100>;
+   L2_100: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU2: cpu@200 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x200>;
+   enable-method = "psci";
+   next-level-cache = <_200>;
+   L2_200: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU3: cpu@300 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x300>;
+   enable-method = "psci";
+   next-level-cache = <_300>;
+   L2_300: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU4: cpu@400 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x400>;
+   enable-method = "psci";
+   next-level-cache = <_400>;
+   L2_400: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU5: cpu@500 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x500>;
+   enable-method = "psci";
+  

[PATCH v4 1/4] dt-bindings: arm: Document kryo385 cpu

[Rajendra Nayak]

Document the compatible string for the Kryo385 cpus found in qualcomm
SoCs.

Signed-off-by: Rajendra Nayak 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/cpus.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index a0009b72e9be..19611ccb61d9 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -184,6 +184,7 @@ described below.
"nvidia,tegra186-denver"
"qcom,krait"
"qcom,kryo"
+   "qcom,kryo385"
"qcom,scorpion"
- enable-method
Value type: 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

[Richard Guy Briggs]

On 2018-02-15 18:07, Steve Grubb wrote:
> On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modules when the following rule was in place for
> > startup:
> > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> > 
> > This happens because the parent inode is not found in the task's
> > audit_names list and hence treats it as anonymous.  This gives us no
> > information other than a numerical device number for a device that may
> > no longer be visible upon log inspeciton, and an inode number.
> > 
> > Fill in the partial known pathname from the filesystem mount point to
> > the leaf node on previously null PATH records from entries that have an
> > anonymous parent from the child dentry using dentry_path_raw().
> > 
> > Make the dentry argument of __audit_inode_child() non-const so that we
> > can take a reference to it in the case of an anonymous parent with
> > dget() and dget_parent() to be able to later print a partial path from
> > the host filesystem rather than null.
> > 
> > Since all we are given is an inode of the parent and the dentry of the
> > child, finding the path from the mount point to the root of the
> > filesystem is more challenging that would involve searching all
> > vfsmounts from "/" until a matching dentry is found for that
> > filesystem's root dentry.  Even if one is found, there may be more than
> > one mount point.  At this point the gain seems marginal since
> > knowing the filesystem type and path are a significant help in tracking
> > down the source of the PATH records and being able to address them.
> > 
> > Sample output:
> > type=PROCTITLE msg=audit(1488317694.446:143):
> > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634 type=PATH
> > msg=audit(1488317694.446:143): item=797
> > name=events/nfs4/nfs4_setclientid/format inode=15969 dev=00:09
> > mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > nametype=CREATE cap_fp= cap_fi= cap_fe=0
> > cap_fver=0 type=PATH msg=audit(1488317694.446:143): item=796
> > name=events/nfs4/nfs4_setclientid inode=15964 dev=00:09 mode=040755 ouid=0
> > ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> > cap_fp= cap_fi= cap_fe=0 cap_fver=0 ...
> > type=PATH msg=audit(1488317694.446:143): item=1 name=events/nfs4
> > inode=15571 dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:tracefs_t:s0 nametype=CREATE cap_fp=
> > cap_fi= cap_fe=0 cap_fver=0 type=PATH
> > msg=audit(1488317694.446:143): item=0 name=events inode=119 dev=00:09
> > mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > nametype=PARENT cap_fp= cap_fi= cap_fe=0
> > cap_fver=0 type=KERN_MODULE msg=audit(1488317694.446:143): name="nfsv4"
> > type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313
> > success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6 pid=528
> > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> > tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod"
> > subj=system_u:system_r:insmod_t:s0 key="mod-load"
> 
> Thanks for the samples, but the event above fails the ausearch-test test 
> suite. The "name" field in the PATH record is not properly escaped.

Is the ausearch-test on github yet?  Last I see is v0.6 on your rh
people page.

> -Steve
> 
> > See: https://github.com/linux-audit/audit-kernel/issues/8
> > Test case: https://github.com/linux-audit/audit-testsuite/issues/42
> > 
> > Signed-off-by: Richard Guy Briggs 
> > 
> > ---
> > v4:
> >   fix fullpath memleak
> >   switch from log_format() to audit_log_untrustedstring()
> >   remove leading / from pathname relative to unknown mount point
> > 
> > v3:
> >   fix audit_buffer leak and dname error allocation leak audit_log_name
> >   only put audit_name->dentry if it is being replaced
> > 
> > v2:
> >   deconstify struct dentry*
> >   add hex prefix to fstype
> > ---
> >  include/linux/audit.h |  8 
> >  kernel/audit.c| 28 +++-
> >  kernel/audit.h|  1 +
> >  kernel/auditsc.c  |  8 +++-
> >  4 files changed, 39 insertions(+), 6 deletions(-)
> > 
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index af410d9..2020f1d 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -232,7 +232,7 @@ extern void __audit_inode(struct filename *name, const
> > struct dentry *dentry, unsigned int flags);
> >  extern void __audit_file(const struct file *);
> >  extern void __audit_inode_child(struct inode *parent,
> > -   const struct dentry *dentry,
> > +   struct dentry *dentry,
> > 

Re: [PATCH ghak8 ALT4 V4 1/3] audit: show partial pathname for entries with anonymous parents

[Richard Guy Briggs]

On 2018-02-15 18:07, Steve Grubb wrote:
> On Monday, February 12, 2018 12:02:21 AM EST Richard Guy Briggs wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modules when the following rule was in place for
> > startup:
> > -a always,exit -F arch=x86_64 -S init_module -F key=mod-load
> > 
> > This happens because the parent inode is not found in the task's
> > audit_names list and hence treats it as anonymous.  This gives us no
> > information other than a numerical device number for a device that may
> > no longer be visible upon log inspeciton, and an inode number.
> > 
> > Fill in the partial known pathname from the filesystem mount point to
> > the leaf node on previously null PATH records from entries that have an
> > anonymous parent from the child dentry using dentry_path_raw().
> > 
> > Make the dentry argument of __audit_inode_child() non-const so that we
> > can take a reference to it in the case of an anonymous parent with
> > dget() and dget_parent() to be able to later print a partial path from
> > the host filesystem rather than null.
> > 
> > Since all we are given is an inode of the parent and the dentry of the
> > child, finding the path from the mount point to the root of the
> > filesystem is more challenging that would involve searching all
> > vfsmounts from "/" until a matching dentry is found for that
> > filesystem's root dentry.  Even if one is found, there may be more than
> > one mount point.  At this point the gain seems marginal since
> > knowing the filesystem type and path are a significant help in tracking
> > down the source of the PATH records and being able to address them.
> > 
> > Sample output:
> > type=PROCTITLE msg=audit(1488317694.446:143):
> > proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D006E66737634 type=PATH
> > msg=audit(1488317694.446:143): item=797
> > name=events/nfs4/nfs4_setclientid/format inode=15969 dev=00:09
> > mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > nametype=CREATE cap_fp= cap_fi= cap_fe=0
> > cap_fver=0 type=PATH msg=audit(1488317694.446:143): item=796
> > name=events/nfs4/nfs4_setclientid inode=15964 dev=00:09 mode=040755 ouid=0
> > ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0 nametype=PARENT
> > cap_fp= cap_fi= cap_fe=0 cap_fver=0 ...
> > type=PATH msg=audit(1488317694.446:143): item=1 name=events/nfs4
> > inode=15571 dev=00:09 mode=040755 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:tracefs_t:s0 nametype=CREATE cap_fp=
> > cap_fi= cap_fe=0 cap_fver=0 type=PATH
> > msg=audit(1488317694.446:143): item=0 name=events inode=119 dev=00:09
> > mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tracefs_t:s0
> > nametype=PARENT cap_fp= cap_fi= cap_fe=0
> > cap_fver=0 type=KERN_MODULE msg=audit(1488317694.446:143): name="nfsv4"
> > type=SYSCALL msg=audit(1488317694.446:143): arch=c03e syscall=313
> > success=yes exit=0 a0=1 a1=55d5a35ce106 a2=0 a3=1 items=798 ppid=6 pid=528
> > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> > tty=(none) ses=4294967295 comm="modprobe" exe="/usr/bin/kmod"
> > subj=system_u:system_r:insmod_t:s0 key="mod-load"
> 
> Thanks for the samples, but the event above fails the ausearch-test test 
> suite. The "name" field in the PATH record is not properly escaped.

Is the ausearch-test on github yet?  Last I see is v0.6 on your rh
people page.

> -Steve
> 
> > See: https://github.com/linux-audit/audit-kernel/issues/8
> > Test case: https://github.com/linux-audit/audit-testsuite/issues/42
> > 
> > Signed-off-by: Richard Guy Briggs 
> > 
> > ---
> > v4:
> >   fix fullpath memleak
> >   switch from log_format() to audit_log_untrustedstring()
> >   remove leading / from pathname relative to unknown mount point
> > 
> > v3:
> >   fix audit_buffer leak and dname error allocation leak audit_log_name
> >   only put audit_name->dentry if it is being replaced
> > 
> > v2:
> >   deconstify struct dentry*
> >   add hex prefix to fstype
> > ---
> >  include/linux/audit.h |  8 
> >  kernel/audit.c| 28 +++-
> >  kernel/audit.h|  1 +
> >  kernel/auditsc.c  |  8 +++-
> >  4 files changed, 39 insertions(+), 6 deletions(-)
> > 
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index af410d9..2020f1d 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -232,7 +232,7 @@ extern void __audit_inode(struct filename *name, const
> > struct dentry *dentry, unsigned int flags);
> >  extern void __audit_file(const struct file *);
> >  extern void __audit_inode_child(struct inode *parent,
> > -   const struct dentry *dentry,
> > +   struct dentry *dentry,
> >  

Re: [PATCH 4.15 000/202] 4.15.4-stable review

[Naresh Kamboju]

On 15 February 2018 at 20:45, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.15.4 release.
> There are 202 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 Feb 17 15:16:28 UTC 2018.
> 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.15.4-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
LTP: netns_netlink test fail started from 4.15 on ( armv7 ) beagleboard-x15.
tun: section 3 reloc 18 sym '__memzero': relocation 28 out of range
(0xbf04 -> 0xc10a3ac0)open: No such device
https://bugs.linaro.org/show_bug.cgi?id=3484

Patch is in discussion to fix this problem by,
[PATCHv2] arch/arm/Kconfig: default ARM_MODULE_PLTS to 'y'
https://lkml.org/lkml/2018/1/31/577

Summary

kernel: 4.15.4-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: 01be67fd216daa47afa25bbfdd555eff8a66ce3e
git describe: v4.15.3-204-g01be67fd216d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.3-204-g01be67fd216d


No regressions (compared to build v4.15.3-88-gcc4b654d33e8)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 9, pass: 57,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 151, pass: 999,
* ltp-timers-tests - skip: 1, pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 10, pass: 56,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 148, pass: 1002,
* ltp-timers-tests - skip: 1, pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 12, pass: 53,
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 62, fail: 2
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 97, pass: 1053,
* ltp-timers-tests - skip: 1, pass: 12,

x86_64
* boot - pass: 20,
* kselftest - skip: 10, pass: 71,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 1, pass: 62,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 10,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 118, pass: 1032,
* ltp-timers-tests - skip: 1, pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.15 000/202] 4.15.4-stable review

[Naresh Kamboju]

On 15 February 2018 at 20:45, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.15.4 release.
> There are 202 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 Feb 17 15:16:28 UTC 2018.
> 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.15.4-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.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
LTP: netns_netlink test fail started from 4.15 on ( armv7 ) beagleboard-x15.
tun: section 3 reloc 18 sym '__memzero': relocation 28 out of range
(0xbf04 -> 0xc10a3ac0)open: No such device
https://bugs.linaro.org/show_bug.cgi?id=3484

Patch is in discussion to fix this problem by,
[PATCHv2] arch/arm/Kconfig: default ARM_MODULE_PLTS to 'y'
https://lkml.org/lkml/2018/1/31/577

Summary

kernel: 4.15.4-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: 01be67fd216daa47afa25bbfdd555eff8a66ce3e
git describe: v4.15.3-204-g01be67fd216d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.3-204-g01be67fd216d


No regressions (compared to build v4.15.3-88-gcc4b654d33e8)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 9, pass: 57,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 151, pass: 999,
* ltp-timers-tests - skip: 1, pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 10, pass: 56,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 148, pass: 1002,
* ltp-timers-tests - skip: 1, pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 12, pass: 53,
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 62, fail: 2
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 97, pass: 1053,
* ltp-timers-tests - skip: 1, pass: 12,

x86_64
* boot - pass: 20,
* kselftest - skip: 10, pass: 71,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 1, pass: 62,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 10,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 118, pass: 1032,
* ltp-timers-tests - skip: 1, pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.9 00/88] 4.9.82-stable review

[Naresh Kamboju]

On 15 February 2018 at 20:46, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.82 release.
> There are 88 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 Feb 17 15:11:46 UTC 2018.
> 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.9.82-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
LTP getrusage04 fails intermittently and already have an old open bug.
LKFT: 4.9-rc: x15: LTP getrusage04 failed - stime increased > 6000us
(intermittent)
https://bugs.linaro.org/show_bug.cgi?id=3507

Summary


kernel: 4.9.82-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: d521208d35b18752ce67294386370c0dc6af5316
git describe: v4.9.81-89-gd521208d35b1
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.81-89-gd521208d35b1

No regressions (compared to build v4.9.81-15-ge367c81f224a)



Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 24, pass: 40,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 151, pass: 999,
* ltp-timers-tests - skip: 1, pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 23, pass: 42,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 148, pass: 1002,
* ltp-timers-tests - skip: 1, pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 25, pass: 39,
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 97, pass: 1051, fail: 2
* ltp-timers-tests - skip: 1, pass: 12,

x86_64
* boot - pass: 20,
* kselftest - skip: 27, pass: 54,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 1, pass: 62,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 118, pass: 1032,
* ltp-timers-tests - skip: 1, pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.14 000/195] 4.14.20-stable review

[Naresh Kamboju]

On 15 February 2018 at 20:44, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.20 release.
> There are 195 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 Feb 17 15:16:22 UTC 2018.
> 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.14.20-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.14.20-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: ff1db24d7bfc9f8692fd5da29d531c7cb7992b12
git describe: v4.14.19-197-gff1db24d7bfc
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.19-197-gff1db24d7bfc


No regressions (compared to build v4.14.19-114-g55c6178a2819)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 17, pass: 48,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 151, pass: 999,
* ltp-timers-tests - skip: 1, pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 17, pass: 48,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 148, pass: 1002,
* ltp-timers-tests - skip: 1, pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 19, pass: 45,
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 97, pass: 1053,
* ltp-timers-tests - skip: 1, pass: 12,

x86_64
* boot - pass: 20,
* kselftest - skip: 19, pass: 61,
* libhugetlbfs - skip: 1, pass: 89,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 1, pass: 62,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 118, pass: 1032,
* ltp-timers-tests - skip: 1, pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.9 00/88] 4.9.82-stable review

[Naresh Kamboju]

On 15 February 2018 at 20:46, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.82 release.
> There are 88 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 Feb 17 15:11:46 UTC 2018.
> 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.9.82-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
LTP getrusage04 fails intermittently and already have an old open bug.
LKFT: 4.9-rc: x15: LTP getrusage04 failed - stime increased > 6000us
(intermittent)
https://bugs.linaro.org/show_bug.cgi?id=3507

Summary


kernel: 4.9.82-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: d521208d35b18752ce67294386370c0dc6af5316
git describe: v4.9.81-89-gd521208d35b1
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.81-89-gd521208d35b1

No regressions (compared to build v4.9.81-15-ge367c81f224a)



Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 24, pass: 40,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 151, pass: 999,
* ltp-timers-tests - skip: 1, pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 23, pass: 42,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 148, pass: 1002,
* ltp-timers-tests - skip: 1, pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 25, pass: 39,
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 97, pass: 1051, fail: 2
* ltp-timers-tests - skip: 1, pass: 12,

x86_64
* boot - pass: 20,
* kselftest - skip: 27, pass: 54,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 1, pass: 62,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 118, pass: 1032,
* ltp-timers-tests - skip: 1, pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.14 000/195] 4.14.20-stable review

[Naresh Kamboju]

On 15 February 2018 at 20:44, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.20 release.
> There are 195 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 Feb 17 15:16:22 UTC 2018.
> 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.14.20-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.14.20-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: ff1db24d7bfc9f8692fd5da29d531c7cb7992b12
git describe: v4.14.19-197-gff1db24d7bfc
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.19-197-gff1db24d7bfc


No regressions (compared to build v4.14.19-114-g55c6178a2819)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 17, pass: 48,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 151, pass: 999,
* ltp-timers-tests - skip: 1, pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 17, pass: 48,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 148, pass: 1002,
* ltp-timers-tests - skip: 1, pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 19, pass: 45,
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 97, pass: 1053,
* ltp-timers-tests - skip: 1, pass: 12,

x86_64
* boot - pass: 20,
* kselftest - skip: 19, pass: 61,
* libhugetlbfs - skip: 1, pass: 89,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 1, pass: 62,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 118, pass: 1032,
* ltp-timers-tests - skip: 1, pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

Re: [PATCH 4.4 000/108] 4.4.116-stable review

[Naresh Kamboju]

On 15 February 2018 at 20:45, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 4.4.116 release.
> There are 108 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 Feb 17 15:11:36 UTC 2018.
> 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.4.116-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.4.116-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: f235d122836c25ae9e99721537bcb3f9e01ae7c6
git describe: v4.4.115-109-gf235d122836c
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.115-109-gf235d122836c


No regressions (compared to build v4.4.115-54-g9d137e965a3f)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 31, pass: 32,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 53, pass: 28,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 151, pass: 999,
* ltp-timers-tests - skip: 1, pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 29, pass: 33,
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 98, pass: 1052,
* ltp-timers-tests - skip: 1, pass: 12,

x86_64
* boot - pass: 20,
* kselftest - skip: 31, pass: 48,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 63,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 1, pass: 62,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 119, pass: 1031,
* ltp-timers-tests - skip: 1, pass: 12,

Hikey results summary,

Summary


kernel: 4.4.116-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.116-rc1-hikey-20180215-131
git commit: 4da825751e43ebd33e27ce2b70f1ede852310a87
git describe: 4.4.116-rc1-hikey-20180215-131
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.116-rc1-hikey-20180215-131


No regressions (compared to build 4.4.116-rc1-hikey-20180213-129)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 34, pass: 29,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 53, pass: 28,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 154, pass: 996,
* ltp-timers-tests - skip: 1, pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju <naresh.kamb...@linaro.org>

Re: [PATCH 4.4 000/108] 4.4.116-stable review

[Naresh Kamboju]

On 15 February 2018 at 20:45, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.4.116 release.
> There are 108 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 Feb 17 15:11:36 UTC 2018.
> 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.4.116-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.4.116-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: f235d122836c25ae9e99721537bcb3f9e01ae7c6
git describe: v4.4.115-109-gf235d122836c
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.115-109-gf235d122836c


No regressions (compared to build v4.4.115-54-g9d137e965a3f)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - skip: 31, pass: 32,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 53, pass: 28,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 151, pass: 999,
* ltp-timers-tests - skip: 1, pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - skip: 29, pass: 33,
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 2, pass: 20,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 98, pass: 1052,
* ltp-timers-tests - skip: 1, pass: 12,

x86_64
* boot - pass: 20,
* kselftest - skip: 31, pass: 48,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 63,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 1, pass: 62,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 5, pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 119, pass: 1031,
* ltp-timers-tests - skip: 1, pass: 12,

Hikey results summary,

Summary


kernel: 4.4.116-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.116-rc1-hikey-20180215-131
git commit: 4da825751e43ebd33e27ce2b70f1ede852310a87
git describe: 4.4.116-rc1-hikey-20180215-131
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.116-rc1-hikey-20180215-131


No regressions (compared to build 4.4.116-rc1-hikey-20180213-129)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - skip: 34, pass: 29,
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 53, pass: 28,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 2, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 154, pass: 996,
* ltp-timers-tests - skip: 1, pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju 

[git pull] drm fixes for 4.16-rc2

[Dave Airlie]

Hi Linus,

One nouveau regression fix, one AMD quirk and a full set of i915 fixes.

The i915 fixes are mostly for things caught by their CI system, main
ones being DSI panel fixes and GEM fixes.

Pretty quiet overall.

Dave.

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.16-rc2

for you to fetch changes up to bfad2d08e540b18cfd92694fbb388e7d202df31f:

  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into
drm-fixes (2018-02-16 14:26:01 +1000)


i915 fixes, and single amd and nouveau fix


Chris Wilson (7):
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915: Avoid truncation before clamping userspace's priority value
  drm/i915: Don't wake the device up to check if the engine is asleep
  drm/i915/breadcrumbs: Ignore unsubmitted signalers
  drm/i915: Lock out execlist tasklet while peeking inside for busy-stats
  drm/i915/pmu: Fix building without CONFIG_PM

Dave Airlie (3):
  Merge branch 'drm-next-4.16' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-02-14-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into drm-fixes

Hans de Goede (4):
  drm/i915/vlv: Add cdclk workaround for DSI
  drm/i915: Add intel_bios_cleanup() function
  drm/i915: Free memdup-ed DSI VBT data structures on driver_unload
  drm/i915: Fix DSI panels with v1 MIPI sequences without a
DEASSERT sequence v3

Kai-Heng Feng (1):
  drm/amdgpu: add new device to use atpx quirk

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2018-02-14' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Thierry Reding (1):
  drm/nouveau: Make clock gate support conditional

Tina Zhang (1):
  drm/i915/gvt: Support BAR0 8-byte reads/writes

Tvrtko Ursulin (2):
  drm/i915/pmu: Fix PMU enable vs execlists tasklet race
  drm/i915/pmu: Fix sleep under atomic in RC6 readout

Weinan Li (2):
  drm/i915/gvt: add 0xe4f0 into gen9 render list
  drm/i915/gvt: fix one typo of render_mmio trace

 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c |   1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c |  51 -
 drivers/gpu/drm/i915/gvt/mmio_context.c  |   1 +
 drivers/gpu/drm/i915/gvt/trace.h |   2 +-
 drivers/gpu/drm/i915/i915_drv.c  |  14 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_gem_context.c  |   2 +-
 drivers/gpu/drm/i915/i915_oa_cflgt3.c|   4 +-
 drivers/gpu/drm/i915/i915_oa_cnl.c   |   4 +-
 drivers/gpu/drm/i915/i915_pmu.c  | 231 ++-
 drivers/gpu/drm/i915/i915_pmu.h  |   6 +
 drivers/gpu/drm/i915/intel_bios.c| 105 +++
 drivers/gpu/drm/i915/intel_breadcrumbs.c |  29 +--
 drivers/gpu/drm/i915/intel_cdclk.c   |   8 +
 drivers/gpu/drm/i915/intel_engine_cs.c   |  24 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  14 --
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c |   6 +-
 17 files changed, 350 insertions(+), 154 deletions(-)

[git pull] drm fixes for 4.16-rc2

[Dave Airlie]

Hi Linus,

One nouveau regression fix, one AMD quirk and a full set of i915 fixes.

The i915 fixes are mostly for things caught by their CI system, main
ones being DSI panel fixes and GEM fixes.

Pretty quiet overall.

Dave.

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.16-rc2

for you to fetch changes up to bfad2d08e540b18cfd92694fbb388e7d202df31f:

  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into
drm-fixes (2018-02-16 14:26:01 +1000)


i915 fixes, and single amd and nouveau fix


Chris Wilson (7):
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915/perf: Fix compiler warning for string truncation
  drm/i915: Avoid truncation before clamping userspace's priority value
  drm/i915: Don't wake the device up to check if the engine is asleep
  drm/i915/breadcrumbs: Ignore unsubmitted signalers
  drm/i915: Lock out execlist tasklet while peeking inside for busy-stats
  drm/i915/pmu: Fix building without CONFIG_PM

Dave Airlie (3):
  Merge branch 'drm-next-4.16' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-02-14-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into drm-fixes

Hans de Goede (4):
  drm/i915/vlv: Add cdclk workaround for DSI
  drm/i915: Add intel_bios_cleanup() function
  drm/i915: Free memdup-ed DSI VBT data structures on driver_unload
  drm/i915: Fix DSI panels with v1 MIPI sequences without a
DEASSERT sequence v3

Kai-Heng Feng (1):
  drm/amdgpu: add new device to use atpx quirk

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2018-02-14' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Thierry Reding (1):
  drm/nouveau: Make clock gate support conditional

Tina Zhang (1):
  drm/i915/gvt: Support BAR0 8-byte reads/writes

Tvrtko Ursulin (2):
  drm/i915/pmu: Fix PMU enable vs execlists tasklet race
  drm/i915/pmu: Fix sleep under atomic in RC6 readout

Weinan Li (2):
  drm/i915/gvt: add 0xe4f0 into gen9 render list
  drm/i915/gvt: fix one typo of render_mmio trace

 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c |   1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c |  51 -
 drivers/gpu/drm/i915/gvt/mmio_context.c  |   1 +
 drivers/gpu/drm/i915/gvt/trace.h |   2 +-
 drivers/gpu/drm/i915/i915_drv.c  |  14 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_gem_context.c  |   2 +-
 drivers/gpu/drm/i915/i915_oa_cflgt3.c|   4 +-
 drivers/gpu/drm/i915/i915_oa_cnl.c   |   4 +-
 drivers/gpu/drm/i915/i915_pmu.c  | 231 ++-
 drivers/gpu/drm/i915/i915_pmu.h  |   6 +
 drivers/gpu/drm/i915/intel_bios.c| 105 +++
 drivers/gpu/drm/i915/intel_breadcrumbs.c |  29 +--
 drivers/gpu/drm/i915/intel_cdclk.c   |   8 +
 drivers/gpu/drm/i915/intel_engine_cs.c   |  24 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  14 --
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c |   6 +-
 17 files changed, 350 insertions(+), 154 deletions(-)

Re: [PATCH 10/12] i2c: qup: send NACK for last read sub transfers

[Sricharan R]

Hi Abhishek,

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> According to I2c specification, “If a master-receiver sends a
> repeated START condition, it sends a not-acknowledge (A) just
> before the repeated START condition”. QUP v2 supports sending
> of NACK without stop with QUP_TAG_V2_DATARD_NACK so added the
> same.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index ba717bb..edea3b9 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -113,6 +113,7 @@
>  #define QUP_TAG_V2_DATAWR  0x82
>  #define QUP_TAG_V2_DATAWR_STOP 0x83
>  #define QUP_TAG_V2_DATARD  0x85
> +#define QUP_TAG_V2_DATARD_NACK 0x86
>  #define QUP_TAG_V2_DATARD_STOP 0x87
>  
>  /* Status, Error flags */
> @@ -609,7 +610,9 @@ static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev 
> *qup,
>   tags[len++] = QUP_TAG_V2_DATAWR_STOP;
>   } else {
>   if (msg->flags & I2C_M_RD)
> - tags[len++] = QUP_TAG_V2_DATARD;
> + tags[len++] = qup->blk.pos == (qup->blk.count - 1) ?
> +   QUP_TAG_V2_DATARD_NACK :
> +   QUP_TAG_V2_DATARD;
>   else
>   tags[len++] = QUP_TAG_V2_DATAWR;

 good one. Thanks .

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 10/12] i2c: qup: send NACK for last read sub transfers

[Sricharan R]

Hi Abhishek,

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> According to I2c specification, “If a master-receiver sends a
> repeated START condition, it sends a not-acknowledge (A) just
> before the repeated START condition”. QUP v2 supports sending
> of NACK without stop with QUP_TAG_V2_DATARD_NACK so added the
> same.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index ba717bb..edea3b9 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -113,6 +113,7 @@
>  #define QUP_TAG_V2_DATAWR  0x82
>  #define QUP_TAG_V2_DATAWR_STOP 0x83
>  #define QUP_TAG_V2_DATARD  0x85
> +#define QUP_TAG_V2_DATARD_NACK 0x86
>  #define QUP_TAG_V2_DATARD_STOP 0x87
>  
>  /* Status, Error flags */
> @@ -609,7 +610,9 @@ static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev 
> *qup,
>   tags[len++] = QUP_TAG_V2_DATAWR_STOP;
>   } else {
>   if (msg->flags & I2C_M_RD)
> - tags[len++] = QUP_TAG_V2_DATARD;
> + tags[len++] = qup->blk.pos == (qup->blk.count - 1) ?
> +   QUP_TAG_V2_DATARD_NACK :
> +   QUP_TAG_V2_DATARD;
>   else
>   tags[len++] = QUP_TAG_V2_DATAWR;

 good one. Thanks .

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v4 0/8] ARM: sun9i: SMP and CPU hotplug support

[Chen-Yu Tsai]

On Tue, Feb 13, 2018 at 4:15 PM, Chen-Yu Tsai  wrote:
> Hi Nicolas, Dave,
>
> On Wed, Jan 17, 2018 at 4:46 PM, Chen-Yu Tsai  wrote:
>> This is v4 of my sun9i SMP/hotplug support series which was started
>> over two years ago [1]. We've tried to implement PSCI for both the A80
>> and A83T. Results were not promising. The issue is that these two chips
>> have a broken security extensions implementation. If a specific bit is
>> not burned in its e-fuse, most if not all security protections don't
>> work [2]. Even worse, non-secure access to the GIC become secure. This
>> requires a crazy workaround in the GIC driver which probably doesn't work
>> in all cases [3].
>>
>> Version 3 completely did away with the MCPM framework, instead just
>> implementing a set of smp_ops. Most of the code from the previous
>> version was reused, so the structure still has some traces of MCPM.
>> As our hardware has CCI-400, we still need some sort of MMU/cache
>> disabled trampoline code to enable cache coherency. Code for this
>> was adapted from the MCPM framework. This and the entry code are done
>> in inline assembly. Most of the other sunxi-specific code is derived
>> from Allwinner code and documentation, with some references to the
>> other MCPM implementations, as well as the Cortex's Technical Reference
>> Manuals for the power sequencing stuff.
>>
>> In version 4, all traces of MCPM have been removed, except in the
>> comments for atttributing code sources. Thumb2 mode is also fixed.
>> It failed due to an unaligned word access.
>
> Any more comments on this series? Or is it OK for you guys now that
> there are no traces of MCPM? :)
>
> We'll merge this series later this week for 4.17 if nothing else.

Merged for 4.17.

Thanks

Re: [PATCH v4 0/8] ARM: sun9i: SMP and CPU hotplug support

[Chen-Yu Tsai]

On Tue, Feb 13, 2018 at 4:15 PM, Chen-Yu Tsai  wrote:
> Hi Nicolas, Dave,
>
> On Wed, Jan 17, 2018 at 4:46 PM, Chen-Yu Tsai  wrote:
>> This is v4 of my sun9i SMP/hotplug support series which was started
>> over two years ago [1]. We've tried to implement PSCI for both the A80
>> and A83T. Results were not promising. The issue is that these two chips
>> have a broken security extensions implementation. If a specific bit is
>> not burned in its e-fuse, most if not all security protections don't
>> work [2]. Even worse, non-secure access to the GIC become secure. This
>> requires a crazy workaround in the GIC driver which probably doesn't work
>> in all cases [3].
>>
>> Version 3 completely did away with the MCPM framework, instead just
>> implementing a set of smp_ops. Most of the code from the previous
>> version was reused, so the structure still has some traces of MCPM.
>> As our hardware has CCI-400, we still need some sort of MMU/cache
>> disabled trampoline code to enable cache coherency. Code for this
>> was adapted from the MCPM framework. This and the entry code are done
>> in inline assembly. Most of the other sunxi-specific code is derived
>> from Allwinner code and documentation, with some references to the
>> other MCPM implementations, as well as the Cortex's Technical Reference
>> Manuals for the power sequencing stuff.
>>
>> In version 4, all traces of MCPM have been removed, except in the
>> comments for atttributing code sources. Thumb2 mode is also fixed.
>> It failed due to an unaligned word access.
>
> Any more comments on this series? Or is it OK for you guys now that
> there are no traces of MCPM? :)
>
> We'll merge this series later this week for 4.17 if nothing else.

Merged for 4.17.

Thanks

[PATCH v2 1/1] usb: cdc_acm: prevent race at write to acm while system resumes

[sathyanarayanan . kuppuswamy]

From: Dominik Bozek 

ACM driver may accept data to transmit while system is not fully
resumed. In this case ACM driver buffers data and prepare URBs
on usb anchor list.
There is a little chance that two tasks put a char and initiate
acm_tty_flush_chars(). In such a case, driver will put one URB
twice on usb anchor list.
This patch also reset length of data before resue of a buffer.
This not only prevent sending rubbish, but also lower risc of race.

Without this patch we hit following kernel panic in one of our
stabilty/stress tests.

[   46.884442] *list_add double add*: new=9b2ab7289330, 
prev=9b2ab7289330, next=9b2ab81e28e0.
[   46.884476] Modules linked in: hci_uart btbcm bluetooth rfkill_gpio 
igb_avb(O) cfg80211 snd_soc_sst_bxt_tdf8532 snd_soc_skl snd_soc_skl_ipc 
snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_sst_acpi snd_soc_sst_match 
snd_hda_ext_core snd_hda_core trusty_timer trusty_wall trusty_log trusty_virtio 
trusty_ipc trusty_mem trusty_irq trusty virtio_ring virtio intel_ipu4_mmu_bxtB0 
lib2600_mod_bxtB0 intel_ipu4_isys_mod_bxtB0 lib2600psys_mod_bxtB0 
intel_ipu4_psys_mod_bxtB0 intel_ipu4_mod_bxtB0 intel_ipu4_wrapper_bxtB0 
intel_ipu4_acpi videobuf2_dma_contig as3638 dw9714 lm3643 crlmodule smiapp 
smiapp_pll
[   46.884480] CPU: 1 PID: 33 Comm: kworker/u8:1 Tainted: G U  W  O
4.9.56-quilt-2e5dc0ac-g618ed69ced6e-dirty #4
[   46.884489] Workqueue: events_unbound flush_to_ldisc
[   46.884494]  b98ac012bb08 ad3e82e5 b98ac012bb58 

[   46.884497]  b98ac012bb48 ad0a23d1 0024ad6374dd 
9b2ab7289330
[   46.884500]  9b2ab81e28e0 9b2ab7289330 0002 

[   46.884501] Call Trace:
[   46.884507]  [] dump_stack+0x67/0x92
[   46.884511]  [] __warn+0xd1/0xf0
[   46.884513]  [] warn_slowpath_fmt+0x5f/0x80
[   46.884516]  [] __list_add+0xb3/0xc0
[   46.884521]  [] *usb_anchor_urb*+0x4c/0xa0
[   46.884524]  [] *acm_tty_flush_chars*+0x8f/0xb0
[   46.884527]  [] *acm_tty_put_char*+0x41/0x100
[   46.884530]  [] tty_put_char+0x24/0x40
[   46.884533]  [] do_output_char+0xa5/0x200
[   46.884535]  [] __process_echoes+0x148/0x290
[   46.884538]  [] n_tty_receive_buf_common+0x57c/0xb00
[   46.884541]  [] n_tty_receive_buf2+0x14/0x20
[   46.884543]  [] tty_ldisc_receive_buf+0x22/0x50
[   46.884545]  [] flush_to_ldisc+0xc5/0xe0
[   46.884549]  [] process_one_work+0x148/0x440
[   46.884551]  [] worker_thread+0x69/0x4a0
[   46.884554]  [] ? max_active_store+0x80/0x80
[   46.884556]  [] kthread+0x110/0x130
[   46.884559]  [] ? kthread_park+0x60/0x60
[   46.884563]  [] ret_from_fork+0x27/0x40
[   46.884566] ---[ end trace 3bd599058b8a9eb3 ]---

Signed-off-by: Dominik Bozek 
Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-by: Oliver Neukum 
---
 drivers/usb/class/cdc-acm.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 06b3b54..7b366a6 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -174,6 +174,7 @@ static int acm_wb_alloc(struct acm *acm)
wb = >wb[wbn];
if (!wb->use) {
wb->use = 1;
+   wb->len = 0;
return wbn;
}
wbn = (wbn + 1) % ACM_NW;
@@ -805,16 +806,18 @@ static int acm_tty_write(struct tty_struct *tty,
 static void acm_tty_flush_chars(struct tty_struct *tty)
 {
struct acm *acm = tty->driver_data;
-   struct acm_wb *cur = acm->putbuffer;
+   struct acm_wb *cur;
int err;
unsigned long flags;
 
+   spin_lock_irqsave(>write_lock, flags);
+
+   cur = acm->putbuffer;
if (!cur) /* nothing to do */
-   return;
+   goto out;
 
acm->putbuffer = NULL;
err = usb_autopm_get_interface_async(acm->control);
-   spin_lock_irqsave(>write_lock, flags);
if (err < 0) {
cur->use = 0;
acm->putbuffer = cur;
-- 
2.7.4

[PATCH v2 1/1] usb: cdc_acm: prevent race at write to acm while system resumes

[sathyanarayanan . kuppuswamy]

From: Dominik Bozek 

ACM driver may accept data to transmit while system is not fully
resumed. In this case ACM driver buffers data and prepare URBs
on usb anchor list.
There is a little chance that two tasks put a char and initiate
acm_tty_flush_chars(). In such a case, driver will put one URB
twice on usb anchor list.
This patch also reset length of data before resue of a buffer.
This not only prevent sending rubbish, but also lower risc of race.

Without this patch we hit following kernel panic in one of our
stabilty/stress tests.

[   46.884442] *list_add double add*: new=9b2ab7289330, 
prev=9b2ab7289330, next=9b2ab81e28e0.
[   46.884476] Modules linked in: hci_uart btbcm bluetooth rfkill_gpio 
igb_avb(O) cfg80211 snd_soc_sst_bxt_tdf8532 snd_soc_skl snd_soc_skl_ipc 
snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_sst_acpi snd_soc_sst_match 
snd_hda_ext_core snd_hda_core trusty_timer trusty_wall trusty_log trusty_virtio 
trusty_ipc trusty_mem trusty_irq trusty virtio_ring virtio intel_ipu4_mmu_bxtB0 
lib2600_mod_bxtB0 intel_ipu4_isys_mod_bxtB0 lib2600psys_mod_bxtB0 
intel_ipu4_psys_mod_bxtB0 intel_ipu4_mod_bxtB0 intel_ipu4_wrapper_bxtB0 
intel_ipu4_acpi videobuf2_dma_contig as3638 dw9714 lm3643 crlmodule smiapp 
smiapp_pll
[   46.884480] CPU: 1 PID: 33 Comm: kworker/u8:1 Tainted: G U  W  O
4.9.56-quilt-2e5dc0ac-g618ed69ced6e-dirty #4
[   46.884489] Workqueue: events_unbound flush_to_ldisc
[   46.884494]  b98ac012bb08 ad3e82e5 b98ac012bb58 

[   46.884497]  b98ac012bb48 ad0a23d1 0024ad6374dd 
9b2ab7289330
[   46.884500]  9b2ab81e28e0 9b2ab7289330 0002 

[   46.884501] Call Trace:
[   46.884507]  [] dump_stack+0x67/0x92
[   46.884511]  [] __warn+0xd1/0xf0
[   46.884513]  [] warn_slowpath_fmt+0x5f/0x80
[   46.884516]  [] __list_add+0xb3/0xc0
[   46.884521]  [] *usb_anchor_urb*+0x4c/0xa0
[   46.884524]  [] *acm_tty_flush_chars*+0x8f/0xb0
[   46.884527]  [] *acm_tty_put_char*+0x41/0x100
[   46.884530]  [] tty_put_char+0x24/0x40
[   46.884533]  [] do_output_char+0xa5/0x200
[   46.884535]  [] __process_echoes+0x148/0x290
[   46.884538]  [] n_tty_receive_buf_common+0x57c/0xb00
[   46.884541]  [] n_tty_receive_buf2+0x14/0x20
[   46.884543]  [] tty_ldisc_receive_buf+0x22/0x50
[   46.884545]  [] flush_to_ldisc+0xc5/0xe0
[   46.884549]  [] process_one_work+0x148/0x440
[   46.884551]  [] worker_thread+0x69/0x4a0
[   46.884554]  [] ? max_active_store+0x80/0x80
[   46.884556]  [] kthread+0x110/0x130
[   46.884559]  [] ? kthread_park+0x60/0x60
[   46.884563]  [] ret_from_fork+0x27/0x40
[   46.884566] ---[ end trace 3bd599058b8a9eb3 ]---

Signed-off-by: Dominik Bozek 
Signed-off-by: Kuppuswamy Sathyanarayanan 

Acked-by: Oliver Neukum 
---
 drivers/usb/class/cdc-acm.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 06b3b54..7b366a6 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -174,6 +174,7 @@ static int acm_wb_alloc(struct acm *acm)
wb = >wb[wbn];
if (!wb->use) {
wb->use = 1;
+   wb->len = 0;
return wbn;
}
wbn = (wbn + 1) % ACM_NW;
@@ -805,16 +806,18 @@ static int acm_tty_write(struct tty_struct *tty,
 static void acm_tty_flush_chars(struct tty_struct *tty)
 {
struct acm *acm = tty->driver_data;
-   struct acm_wb *cur = acm->putbuffer;
+   struct acm_wb *cur;
int err;
unsigned long flags;
 
+   spin_lock_irqsave(>write_lock, flags);
+
+   cur = acm->putbuffer;
if (!cur) /* nothing to do */
-   return;
+   goto out;
 
acm->putbuffer = NULL;
err = usb_autopm_get_interface_async(acm->control);
-   spin_lock_irqsave(>write_lock, flags);
if (err < 0) {
cur->use = 0;
acm->putbuffer = cur;
-- 
2.7.4

Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len

[Sricharan R]

Hi Abhishek,

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> The BAM mode requires buffer for start tag data and tx, rx SG
> list. Currently, this is being taken for maximum transfer length
> (65K). But an I2C transfer can have multiple messages and each
> message can be of this maximum length so the buffer overflow will
> happen in this case. Since increasing buffer length won’t be
> feasible since an I2C transfer can contain any number of messages
> so this patch does following changes to make i2c transfers working
> for multiple messages case.
> 
> 1. Calculate the required buffers for 2 maximum length messages
>(65K * 2).
> 2. Split the descriptor formation and descriptor scheduling.
>The idea is to fit as many messages in one DMA transfers for 65K
>threshold value (max_xfer_sg_len). Whenever the sg_cnt is
>crossing this, then schedule the BAM transfer and subsequent
>transfer will again start from zero.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 199 
> +--
>  1 file changed, 118 insertions(+), 81 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index 6df65ea..ba717bb 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -155,6 +155,7 @@ struct qup_i2c_bam {
>   struct  qup_i2c_tag tag;
>   struct  dma_chan *dma;
>   struct  scatterlist *sg;
> + unsigned int sg_cnt;
>  };
>  
>  struct qup_i2c_dev {
> @@ -195,6 +196,8 @@ struct qup_i2c_dev {
>   booluse_dma;
>   /* The threshold length above which DMA will be used */
>   unsigned intdma_threshold;
> + unsigned intmax_xfer_sg_len;
> + unsigned inttag_buf_pos;
>   struct  dma_pool *dpool;
>   struct  qup_i2c_tag start_tag;
>   struct  qup_i2c_bam brx;
> @@ -699,86 +702,86 @@ static int qup_i2c_req_dma(struct qup_i2c_dev *qup)
>   return 0;
>  }
>  
> -static int qup_i2c_bam_do_xfer(struct qup_i2c_dev *qup, struct i2c_msg *msg,
> -int num)
> +static int qup_i2c_bam_make_desc(struct qup_i2c_dev *qup, struct i2c_msg 
> *msg)
> +{
> + int ret = 0, limit = QUP_READ_LIMIT;
> + u32 len = 0, blocks, rem;
> + u32 i = 0, tlen, tx_len = 0;
> + u8 *tags;
> +
> + qup_i2c_set_blk_data(qup, msg);
> +
> + blocks = qup->blk.count;
> + rem = msg->len - (blocks - 1) * limit;
> +
> + if (msg->flags & I2C_M_RD) {
> + while (qup->blk.pos < blocks) {
> + tlen = (i == (blocks - 1)) ? rem : limit;
> + tags = >start_tag.start[qup->tag_buf_pos + len];
> + len += qup_i2c_set_tags(tags, qup, msg);
> + qup->blk.data_len -= tlen;
> +
> + /* scratch buf to read the start and len tags */
> + ret = qup_sg_set_buf(>brx.sg[qup->brx.sg_cnt++],
> +  >brx.tag.start[0],
> +  2, qup, DMA_FROM_DEVICE);
> +
> + if (ret)
> + return ret;
> +
> + ret = qup_sg_set_buf(>brx.sg[qup->brx.sg_cnt++],
> +  >buf[limit * i],
> +  tlen, qup,
> +  DMA_FROM_DEVICE);
> + if (ret)
> + return ret;
> +
> + i++;
> + qup->blk.pos = i;
> + }
> + ret = qup_sg_set_buf(>btx.sg[qup->btx.sg_cnt++],
> +  >start_tag.start[qup->tag_buf_pos],
> +  len, qup, DMA_TO_DEVICE);
> + if (ret)
> + return ret;
> +
> + qup->tag_buf_pos += len;
> + } else {
> + while (qup->blk.pos < blocks) {
> + tlen = (i == (blocks - 1)) ? rem : limit;
> + tags = >start_tag.start[qup->tag_buf_pos + tx_len];
> + len = qup_i2c_set_tags(tags, qup, msg);
> + qup->blk.data_len -= tlen;
> +
> + ret = qup_sg_set_buf(>btx.sg[qup->btx.sg_cnt++],
> +  tags, len,
> +  qup, DMA_TO_DEVICE);
> + if (ret)
> + return ret;
> +
> + tx_len += len;
> + ret = qup_sg_set_buf(>btx.sg[qup->btx.sg_cnt++],
> +  >buf[limit * i],
> +  tlen, qup, DMA_TO_DEVICE);
> + if (ret)
> + return ret;
> + i++;
> + qup->blk.pos = i;
> + 

Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len

[Sricharan R]

Hi Abhishek,

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> The BAM mode requires buffer for start tag data and tx, rx SG
> list. Currently, this is being taken for maximum transfer length
> (65K). But an I2C transfer can have multiple messages and each
> message can be of this maximum length so the buffer overflow will
> happen in this case. Since increasing buffer length won’t be
> feasible since an I2C transfer can contain any number of messages
> so this patch does following changes to make i2c transfers working
> for multiple messages case.
> 
> 1. Calculate the required buffers for 2 maximum length messages
>(65K * 2).
> 2. Split the descriptor formation and descriptor scheduling.
>The idea is to fit as many messages in one DMA transfers for 65K
>threshold value (max_xfer_sg_len). Whenever the sg_cnt is
>crossing this, then schedule the BAM transfer and subsequent
>transfer will again start from zero.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 199 
> +--
>  1 file changed, 118 insertions(+), 81 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index 6df65ea..ba717bb 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -155,6 +155,7 @@ struct qup_i2c_bam {
>   struct  qup_i2c_tag tag;
>   struct  dma_chan *dma;
>   struct  scatterlist *sg;
> + unsigned int sg_cnt;
>  };
>  
>  struct qup_i2c_dev {
> @@ -195,6 +196,8 @@ struct qup_i2c_dev {
>   booluse_dma;
>   /* The threshold length above which DMA will be used */
>   unsigned intdma_threshold;
> + unsigned intmax_xfer_sg_len;
> + unsigned inttag_buf_pos;
>   struct  dma_pool *dpool;
>   struct  qup_i2c_tag start_tag;
>   struct  qup_i2c_bam brx;
> @@ -699,86 +702,86 @@ static int qup_i2c_req_dma(struct qup_i2c_dev *qup)
>   return 0;
>  }
>  
> -static int qup_i2c_bam_do_xfer(struct qup_i2c_dev *qup, struct i2c_msg *msg,
> -int num)
> +static int qup_i2c_bam_make_desc(struct qup_i2c_dev *qup, struct i2c_msg 
> *msg)
> +{
> + int ret = 0, limit = QUP_READ_LIMIT;
> + u32 len = 0, blocks, rem;
> + u32 i = 0, tlen, tx_len = 0;
> + u8 *tags;
> +
> + qup_i2c_set_blk_data(qup, msg);
> +
> + blocks = qup->blk.count;
> + rem = msg->len - (blocks - 1) * limit;
> +
> + if (msg->flags & I2C_M_RD) {
> + while (qup->blk.pos < blocks) {
> + tlen = (i == (blocks - 1)) ? rem : limit;
> + tags = >start_tag.start[qup->tag_buf_pos + len];
> + len += qup_i2c_set_tags(tags, qup, msg);
> + qup->blk.data_len -= tlen;
> +
> + /* scratch buf to read the start and len tags */
> + ret = qup_sg_set_buf(>brx.sg[qup->brx.sg_cnt++],
> +  >brx.tag.start[0],
> +  2, qup, DMA_FROM_DEVICE);
> +
> + if (ret)
> + return ret;
> +
> + ret = qup_sg_set_buf(>brx.sg[qup->brx.sg_cnt++],
> +  >buf[limit * i],
> +  tlen, qup,
> +  DMA_FROM_DEVICE);
> + if (ret)
> + return ret;
> +
> + i++;
> + qup->blk.pos = i;
> + }
> + ret = qup_sg_set_buf(>btx.sg[qup->btx.sg_cnt++],
> +  >start_tag.start[qup->tag_buf_pos],
> +  len, qup, DMA_TO_DEVICE);
> + if (ret)
> + return ret;
> +
> + qup->tag_buf_pos += len;
> + } else {
> + while (qup->blk.pos < blocks) {
> + tlen = (i == (blocks - 1)) ? rem : limit;
> + tags = >start_tag.start[qup->tag_buf_pos + tx_len];
> + len = qup_i2c_set_tags(tags, qup, msg);
> + qup->blk.data_len -= tlen;
> +
> + ret = qup_sg_set_buf(>btx.sg[qup->btx.sg_cnt++],
> +  tags, len,
> +  qup, DMA_TO_DEVICE);
> + if (ret)
> + return ret;
> +
> + tx_len += len;
> + ret = qup_sg_set_buf(>btx.sg[qup->btx.sg_cnt++],
> +  >buf[limit * i],
> +  tlen, qup, DMA_TO_DEVICE);
> + if (ret)
> + return ret;
> + i++;
> + qup->blk.pos = i;
> + }
> +
> +  

Re: [PATCH v4 4/5] x86/apic: Rename variable/function related to x86_io_apic_ops

[kbuild test robot]

Hi Baoquan,

I love your patch! Yet something to improve:

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.16-rc1 next-20180215]
[cannot apply to tip/x86/core]
[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/Baoquan-He/x86-apic-Fix-restoring-boot-irq-mode-in-reboot-and-kexec-kdump/20180216-121305
config: i386-randconfig-x070-201806 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/reboot.c: In function 'native_machine_shutdown':
>> arch/x86/kernel/reboot.c:683:2: error: implicit declaration of function 
>> 'restore_boot_irq_mode'; did you mean 'native_restore_boot_irq_mode'? 
>> [-Werror=implicit-function-declaration]
 restore_boot_irq_mode();
 ^
 native_restore_boot_irq_mode
   cc1: some warnings being treated as errors
--
   arch/x86/kernel/crash.c: In function 'native_machine_crash_shutdown':
>> arch/x86/kernel/crash.c:205:2: error: implicit declaration of function 
>> 'restore_boot_irq_mode'; did you mean 'native_restore_boot_irq_mode'? 
>> [-Werror=implicit-function-declaration]
 restore_boot_irq_mode();
 ^
 native_restore_boot_irq_mode
   cc1: some warnings being treated as errors

vim +683 arch/x86/kernel/reboot.c

^1da177e arch/i386/kernel/reboot.c Linus Torvalds 2005-04-16  681  
^1da177e arch/i386/kernel/reboot.c Linus Torvalds 2005-04-16  682   
lapic_shutdown();
4bfde7d3 arch/x86/kernel/reboot.c  Baoquan He 2018-02-13 @683   
restore_boot_irq_mode();
^1da177e arch/i386/kernel/reboot.c Linus Torvalds 2005-04-16  684  

:: The code at line 683 was first introduced by commit
:: 4bfde7d3821a914fb062d96979559723e5871c3d x86/apic: Fix restoring boot 
irq mode in reboot and kexec/kdump

:: TO: Baoquan He <b...@redhat.com>
:: CC: 0day robot <fengguang...@intel.com>

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


.config.gz
Description: application/gzip

Re: [PATCH v4 4/5] x86/apic: Rename variable/function related to x86_io_apic_ops

[kbuild test robot]

Hi Baoquan,

I love your patch! Yet something to improve:

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.16-rc1 next-20180215]
[cannot apply to tip/x86/core]
[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/Baoquan-He/x86-apic-Fix-restoring-boot-irq-mode-in-reboot-and-kexec-kdump/20180216-121305
config: i386-randconfig-x070-201806 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/reboot.c: In function 'native_machine_shutdown':
>> arch/x86/kernel/reboot.c:683:2: error: implicit declaration of function 
>> 'restore_boot_irq_mode'; did you mean 'native_restore_boot_irq_mode'? 
>> [-Werror=implicit-function-declaration]
 restore_boot_irq_mode();
 ^
 native_restore_boot_irq_mode
   cc1: some warnings being treated as errors
--
   arch/x86/kernel/crash.c: In function 'native_machine_crash_shutdown':
>> arch/x86/kernel/crash.c:205:2: error: implicit declaration of function 
>> 'restore_boot_irq_mode'; did you mean 'native_restore_boot_irq_mode'? 
>> [-Werror=implicit-function-declaration]
 restore_boot_irq_mode();
 ^
 native_restore_boot_irq_mode
   cc1: some warnings being treated as errors

vim +683 arch/x86/kernel/reboot.c

^1da177e arch/i386/kernel/reboot.c Linus Torvalds 2005-04-16  681  
^1da177e arch/i386/kernel/reboot.c Linus Torvalds 2005-04-16  682   
lapic_shutdown();
4bfde7d3 arch/x86/kernel/reboot.c  Baoquan He 2018-02-13 @683   
restore_boot_irq_mode();
^1da177e arch/i386/kernel/reboot.c Linus Torvalds 2005-04-16  684  

:: The code at line 683 was first introduced by commit
:: 4bfde7d3821a914fb062d96979559723e5871c3d x86/apic: Fix restoring boot 
irq mode in reboot and kexec/kdump

:: TO: Baoquan He 
:: CC: 0day robot 

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


.config.gz
Description: application/gzip

Re: [PATCH 1/3] dt-bindings: aspeed-lpc: Document LPC Host Interface Controller

[Andrew Jeffery]

On Mon, 2018-02-12 at 17:38 +1030, Joel Stanley wrote:
> The LPC Host Interface Controller is part of a BMC SoC that is used for
> communication with the host.
> 
> Signed-off-by: Joel Stanley 
> ---
>  .../devicetree/bindings/mfd/aspeed-lpc.txt | 40 
> ++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
> b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> index 514d82ced95b..94a31de109c4 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -109,6 +109,46 @@ lpc: lpc@1e789000 {
>   };
>  };
>  
> +BMC Node Children
> +==
> +
> +LPC Host Interface Controller

This should be under the Host Node Children header given the
function's position in the MMIO layout and the split prescribed by the
bindings.

> +---
> +
> +The LPC Host Interface Controller manages functions exposed to the host such 
> as
> +LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
> +management and bus snoop configuration.
> +
> +Required properties:
> +
> +- compatible:One of:
> + "aspeed,ast2400-lpc-ctrl";
> + "aspeed,ast2500-lpc-ctrl";
> +
> +- reg:   contains offset/length values of the host interface 
> controller
> + memory regions
> +
> +- clocks:contains a phandle to the syscon node describing the clocks.
> + There should then be one cell representing the clock to use
> +
> +- memory-region: A phandle to a reserved_memory region to be used for the LPC
> + to AHB mapping
> +
> +- flash: A phandle to the SPI flash controller containing the flash to
> + be exposed over the LPC to AHB mapping
> +
> +Example:
> +
> +lpc-host@80 {
> + lpc_ctrl: lpc-ctrl@0 {
> + compatible = "aspeed,ast2500-lpc-ctrl";
> + reg = <0x0 0x80>;
> + clocks = < ASPEED_CLK_GATE_LCLK>;
> + memory-region = <_memory>;
> + flash = <>;
> + };
> +};

ACK wrt the content, just need to fix its location.

> +
>  Host Node Children
>  ==
>  

signature.asc
Description: This is a digitally signed message part

Re: [PATCH 1/3] dt-bindings: aspeed-lpc: Document LPC Host Interface Controller

[Andrew Jeffery]

On Mon, 2018-02-12 at 17:38 +1030, Joel Stanley wrote:
> The LPC Host Interface Controller is part of a BMC SoC that is used for
> communication with the host.
> 
> Signed-off-by: Joel Stanley 
> ---
>  .../devicetree/bindings/mfd/aspeed-lpc.txt | 40 
> ++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
> b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> index 514d82ced95b..94a31de109c4 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -109,6 +109,46 @@ lpc: lpc@1e789000 {
>   };
>  };
>  
> +BMC Node Children
> +==
> +
> +LPC Host Interface Controller

This should be under the Host Node Children header given the
function's position in the MMIO layout and the split prescribed by the
bindings.

> +---
> +
> +The LPC Host Interface Controller manages functions exposed to the host such 
> as
> +LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
> +management and bus snoop configuration.
> +
> +Required properties:
> +
> +- compatible:One of:
> + "aspeed,ast2400-lpc-ctrl";
> + "aspeed,ast2500-lpc-ctrl";
> +
> +- reg:   contains offset/length values of the host interface 
> controller
> + memory regions
> +
> +- clocks:contains a phandle to the syscon node describing the clocks.
> + There should then be one cell representing the clock to use
> +
> +- memory-region: A phandle to a reserved_memory region to be used for the LPC
> + to AHB mapping
> +
> +- flash: A phandle to the SPI flash controller containing the flash to
> + be exposed over the LPC to AHB mapping
> +
> +Example:
> +
> +lpc-host@80 {
> + lpc_ctrl: lpc-ctrl@0 {
> + compatible = "aspeed,ast2500-lpc-ctrl";
> + reg = <0x0 0x80>;
> + clocks = < ASPEED_CLK_GATE_LCLK>;
> + memory-region = <_memory>;
> + flash = <>;
> + };
> +};

ACK wrt the content, just need to fix its location.

> +
>  Host Node Children
>  ==
>  

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

dw_hdmi shouldn't set drvdata since some drivers might need to store
it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
instead to store it in drvdata. This way drivers are responsible to
store and pass structure when needed.

Idea was taken from the following commit:
8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")


Reviewed-by: Archit Taneja 



Cc: p.za...@pengutronix.de
Cc: narmstr...@baylibre.com
Cc: laurent.pinch...@ideasonboard.com
Cc: h...@rock-chips.com
Cc: he...@sntech.de
Acked-by: Neil Armstrong 
Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 31 -
  drivers/gpu/drm/imx/dw_hdmi-imx.c   | 13 +---
  drivers/gpu/drm/meson/meson_dw_hdmi.c   | 14 +
  drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 12 +--
  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +---
  include/drm/bridge/dw_hdmi.h| 13 ++--
  6 files changed, 60 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7d80f4b56683..f9802399cc0d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2543,8 +2543,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
  
-	platform_set_drvdata(pdev, hdmi);

-
return hdmi;
  
  err_iahb:

@@ -2594,25 +2592,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
  /* 
-
   * Probe/remove API, used from platforms based on the DRM bridge API.
   */
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
  {
struct dw_hdmi *hdmi;
  
  	hdmi = __dw_hdmi_probe(pdev, plat_data);

if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
  
  	drm_bridge_add(>bridge);
  
-	return 0;

+   return hdmi;
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_probe);
  
-void dw_hdmi_remove(struct platform_device *pdev)

+void dw_hdmi_remove(struct dw_hdmi *hdmi)
  {
-   struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(>bridge);
  
  	__dw_hdmi_remove(hdmi);

@@ -2622,31 +2618,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
  /* 
-
   * Bind/unbind API, used from platforms based on the component framework.
   */
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_hdmi_plat_data *plat_data)
  {
struct dw_hdmi *hdmi;
int ret;
  
  	hdmi = __dw_hdmi_probe(pdev, plat_data);

if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
  
  	ret = drm_bridge_attach(encoder, >bridge, NULL);

if (ret) {
-   dw_hdmi_remove(pdev);
+   dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
-   return ret;
+   return ERR_PTR(ret);
}
  
-	return 0;

+   return hdmi;
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_bind);
  
-void dw_hdmi_unbind(struct device *dev)

+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
  {
-   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..fe6becdcc29e 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -25,6 +25,7 @@
  struct imx_hdmi {
struct device *dev;
struct drm_encoder encoder;
+   struct dw_hdmi *hdmi;
struct regmap *regmap;
  };
  
@@ -239,14 +240,18 @@ static int dw_hdmi_imx_bind(struct device *dev, struct device *master,

drm_encoder_init(drm, encoder, _hdmi_imx_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
  
-	ret = dw_hdmi_bind(pdev, encoder, plat_data);

+   platform_set_drvdata(pdev, hdmi);
+
+   hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
  
  	/*

 * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
 * which would have called the encoder cleanup.  Do it manually.
 */
-   if (ret)
+   if (IS_ERR(hdmi->hdmi)) {
+   ret = PTR_ERR(hdmi->hdmi);

Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

dw_hdmi shouldn't set drvdata since some drivers might need to store
it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
instead to store it in drvdata. This way drivers are responsible to
store and pass structure when needed.

Idea was taken from the following commit:
8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")


Reviewed-by: Archit Taneja 



Cc: p.za...@pengutronix.de
Cc: narmstr...@baylibre.com
Cc: laurent.pinch...@ideasonboard.com
Cc: h...@rock-chips.com
Cc: he...@sntech.de
Acked-by: Neil Armstrong 
Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 31 -
  drivers/gpu/drm/imx/dw_hdmi-imx.c   | 13 +---
  drivers/gpu/drm/meson/meson_dw_hdmi.c   | 14 +
  drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 12 +--
  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +---
  include/drm/bridge/dw_hdmi.h| 13 ++--
  6 files changed, 60 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7d80f4b56683..f9802399cc0d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2543,8 +2543,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
  
-	platform_set_drvdata(pdev, hdmi);

-
return hdmi;
  
  err_iahb:

@@ -2594,25 +2592,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
  /* 
-
   * Probe/remove API, used from platforms based on the DRM bridge API.
   */
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
  {
struct dw_hdmi *hdmi;
  
  	hdmi = __dw_hdmi_probe(pdev, plat_data);

if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
  
  	drm_bridge_add(>bridge);
  
-	return 0;

+   return hdmi;
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_probe);
  
-void dw_hdmi_remove(struct platform_device *pdev)

+void dw_hdmi_remove(struct dw_hdmi *hdmi)
  {
-   struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(>bridge);
  
  	__dw_hdmi_remove(hdmi);

@@ -2622,31 +2618,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
  /* 
-
   * Bind/unbind API, used from platforms based on the component framework.
   */
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_hdmi_plat_data *plat_data)
  {
struct dw_hdmi *hdmi;
int ret;
  
  	hdmi = __dw_hdmi_probe(pdev, plat_data);

if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
  
  	ret = drm_bridge_attach(encoder, >bridge, NULL);

if (ret) {
-   dw_hdmi_remove(pdev);
+   dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
-   return ret;
+   return ERR_PTR(ret);
}
  
-	return 0;

+   return hdmi;
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_bind);
  
-void dw_hdmi_unbind(struct device *dev)

+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
  {
-   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
  }
  EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..fe6becdcc29e 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -25,6 +25,7 @@
  struct imx_hdmi {
struct device *dev;
struct drm_encoder encoder;
+   struct dw_hdmi *hdmi;
struct regmap *regmap;
  };
  
@@ -239,14 +240,18 @@ static int dw_hdmi_imx_bind(struct device *dev, struct device *master,

drm_encoder_init(drm, encoder, _hdmi_imx_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
  
-	ret = dw_hdmi_bind(pdev, encoder, plat_data);

+   platform_set_drvdata(pdev, hdmi);
+
+   hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
  
  	/*

 * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
 * which would have called the encoder cleanup.  Do it manually.
 */
-   if (ret)
+   if (IS_ERR(hdmi->hdmi)) {
+   ret = PTR_ERR(hdmi->hdmi);
drm_encoder_cleanup(encoder);
+   }
  
  	return ret;

  }
@@ -254,7 +259,9 @@ static int 

Re: [PATCH v5 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.

Functions exported here are actually not specific to Synopsys PHYs but
to DWC HDMI controller PHY interface. This means that even if the PHY is
completely custom, i.e. not designed by Synopsys, exported functions can
be useful.


Reviewed-by: Archit Taneja 



Reviewed-by: Neil Armstrong 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +--
  drivers/gpu/drm/meson/meson_dw_hdmi.c |  8 +++---
  include/drm/bridge/dw_hdmi.h  | 11 
  3 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7ca14d7325b5..7d80f4b56683 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi 
*hdmi, u8 enable)
 HDMI_PHY_CONF0_SVSRET_MASK);
  }
  
-static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
 HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
  
-static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
 HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
  
  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)

  {
@@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
  }
  
+void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)

+{
+   /* PHY reset. The reset signal is active high on Gen2 PHYs. */
+   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
+   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
+
+void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
+{
+   hdmi_phy_test_clear(hdmi, 1);
+   hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
+   hdmi_phy_test_clear(hdmi, 0);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
+
  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
  {
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
@@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
  
-	/* PHY reset. The reset signal is active high on Gen2 PHYs. */

-   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
-   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+   dw_hdmi_phy_reset(hdmi);
  
  	hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
  
-	hdmi_phy_test_clear(hdmi, 1);

-   hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
-   HDMI_PHY_I2CM_SLAVE_ADDR);
-   hdmi_phy_test_clear(hdmi, 0);
+   dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
  
  	/* Write to the PHY as configured by the platform */

if (pdata->configure_phy)
@@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
void *data)
dw_hdmi_phy_power_off(hdmi);
  }
  
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,

- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+  void *data)
  {
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
  
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

-  bool force, bool disabled, bool rxsense)
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+   bool force, bool disabled, bool rxsense)
  {
u8 old_mask = hdmi->phy_mask;
  
@@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
  }

Re: [PATCH v5 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.

Functions exported here are actually not specific to Synopsys PHYs but
to DWC HDMI controller PHY interface. This means that even if the PHY is
completely custom, i.e. not designed by Synopsys, exported functions can
be useful.


Reviewed-by: Archit Taneja 



Reviewed-by: Neil Armstrong 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +--
  drivers/gpu/drm/meson/meson_dw_hdmi.c |  8 +++---
  include/drm/bridge/dw_hdmi.h  | 11 
  3 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7ca14d7325b5..7d80f4b56683 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi 
*hdmi, u8 enable)
 HDMI_PHY_CONF0_SVSRET_MASK);
  }
  
-static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
 HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
  
-static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
 HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
  
  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)

  {
@@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
  }
  
+void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)

+{
+   /* PHY reset. The reset signal is active high on Gen2 PHYs. */
+   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
+   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
+
+void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
+{
+   hdmi_phy_test_clear(hdmi, 1);
+   hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
+   hdmi_phy_test_clear(hdmi, 0);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
+
  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
  {
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
@@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
  
-	/* PHY reset. The reset signal is active high on Gen2 PHYs. */

-   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
-   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+   dw_hdmi_phy_reset(hdmi);
  
  	hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
  
-	hdmi_phy_test_clear(hdmi, 1);

-   hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
-   HDMI_PHY_I2CM_SLAVE_ADDR);
-   hdmi_phy_test_clear(hdmi, 0);
+   dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
  
  	/* Write to the PHY as configured by the platform */

if (pdata->configure_phy)
@@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
void *data)
dw_hdmi_phy_power_off(hdmi);
  }
  
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,

- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+  void *data)
  {
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
  
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

-  bool force, bool disabled, bool rxsense)
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+   bool force, bool disabled, bool rxsense)
  {
u8 old_mask = hdmi->phy_mask;
  
@@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
  
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)

+void 

Re: [PATCH v5 03/12] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.

Tests show that one iteration is enough.

Acked-by: Laurent Pinchart 


Reviewed-by: Archit Taneja 


Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..7ca14d7325b5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 * then write one of the FC registers several times.
 *
 * The number of iterations matters and depends on the HDMI TX revision
-* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
-* i.MX6DL (v1.31a) have been identified as needing the workaround, with
-* 4 and 1 iterations respectively.
+* (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
+* (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
+* as needing the workaround, with 4 iterations for v1.30a and 1
+* iteration for others.
 */
  
  	switch (hdmi->version) {

@@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+   case 0x132a:
count = 1;
break;
default:

Re: [PATCH v5 03/12] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

[Archit Taneja]

On Thursday 15 February 2018 01:38 AM, Jernej Skrabec wrote:

Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.

Tests show that one iteration is enough.

Acked-by: Laurent Pinchart 


Reviewed-by: Archit Taneja 


Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..7ca14d7325b5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 * then write one of the FC registers several times.
 *
 * The number of iterations matters and depends on the HDMI TX revision
-* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
-* i.MX6DL (v1.31a) have been identified as needing the workaround, with
-* 4 and 1 iterations respectively.
+* (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
+* (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
+* as needing the workaround, with 4 iterations for v1.30a and 1
+* iteration for others.
 */
  
  	switch (hdmi->version) {

@@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+   case 0x132a:
count = 1;
break;
default:

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

[Nadav Amit]

Andy Lutomirski  wrote:

> On Fri, Feb 16, 2018 at 12:42 AM, Linus Torvalds
>  wrote:
>> On Thu, Feb 15, 2018 at 4:22 PM, Nadav Amit  wrote:
>>> It is not too pretty, I agree, but it should do the work. There is only one
>>> problematic descriptor that can be used to switch from compatibility-mode to
>>> long-mode in the GDT (LDT descriptors always have the L-bit cleared).
>>> Changing the descriptor's present bit on context switch when needed can do
>>> the work.
>> 
>> Sure, I can see it working, but it's some really shady stuff, and now
>> the scheduler needs to save/restore/check one more subtle bit.
>> 
>> And if you get it wrong, things will happily work, except you've now
>> defeated PTI. But you'll never notice, because you won't be testing
>> for it, and the only people who will are the black hats.
>> 
>> This is exactly the "security depends on it being in sync" thing that
>> makes me go "eww" about the whole model. Get one thing wrong, and
>> you'll blow all the PTI code out of the water.
>> 
>> So now you tried to optimize one small case that most people won't
>> use, but the downside is that you may make all our PTI work (and all
>> the overhead for all the _normal_ cases) pointless.
> 
> There's also the fact that, if this stuff goes in, we'll be
> encouraging people to deploy 32-bit binaries.  Then they'll buy
> Meltdown-fixed CPUs (or AMD CPUs!) and they may well continue running
> 32-bit binaries.  Sigh.  I'm not totally a fan of this.

Ok, ok. Stop kicking the dead body...

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

[Nadav Amit]

Andy Lutomirski  wrote:

> On Fri, Feb 16, 2018 at 12:42 AM, Linus Torvalds
>  wrote:
>> On Thu, Feb 15, 2018 at 4:22 PM, Nadav Amit  wrote:
>>> It is not too pretty, I agree, but it should do the work. There is only one
>>> problematic descriptor that can be used to switch from compatibility-mode to
>>> long-mode in the GDT (LDT descriptors always have the L-bit cleared).
>>> Changing the descriptor's present bit on context switch when needed can do
>>> the work.
>> 
>> Sure, I can see it working, but it's some really shady stuff, and now
>> the scheduler needs to save/restore/check one more subtle bit.
>> 
>> And if you get it wrong, things will happily work, except you've now
>> defeated PTI. But you'll never notice, because you won't be testing
>> for it, and the only people who will are the black hats.
>> 
>> This is exactly the "security depends on it being in sync" thing that
>> makes me go "eww" about the whole model. Get one thing wrong, and
>> you'll blow all the PTI code out of the water.
>> 
>> So now you tried to optimize one small case that most people won't
>> use, but the downside is that you may make all our PTI work (and all
>> the overhead for all the _normal_ cases) pointless.
> 
> There's also the fact that, if this stuff goes in, we'll be
> encouraging people to deploy 32-bit binaries.  Then they'll buy
> Meltdown-fixed CPUs (or AMD CPUs!) and they may well continue running
> 32-bit binaries.  Sigh.  I'm not totally a fan of this.

Ok, ok. Stop kicking the dead body...

Re: [RFC 1/2] sched: reduce migration cost between faster caches for idle_balance

[Mike Galbraith]

On Thu, 2018-02-15 at 10:07 -0800, Rohit Jain wrote:
> 
> > Rohit is running more tests with a patch that deletes
> > sysctl_sched_migration_cost from idle_balance, and for his patch but
> > with the 5000 usec mistake corrected back to 500 usec.  So far both
> > give improvements over the baseline, but for different cases, so we
> > need to try more workloads before we draw any conclusions.
> >
> > Rohit, can you share your data so far?
> 
> Results:
> 
> In the following results, "Domain based" approach is as mentioned in the
> RFC sent out with the values fixed (As pointed out by Mike). "No check" is
> the patch where I just remove the check against sysctl_sched_migration_cost
> 
> 1) Hackbench results on 2 socket, 44 core and 88 threads Intel x86 machine
> (lower is better):
> 
> +--+-+--+-+
> |  | Without Patch   |Domain Based  |No Check 
>     |
> +--+---+++-++++
> |Loops | Groups|Average |%Std Dev|Average  |%Std Dev|Average 
> |%Std Dev|
> +--+---+++-++++
> |10| 4 |9.701   |0.78    |7.971  (+17.84%) | 1.34   |8.919  (+8.07%) 
> |1.07    |
> |10| 8 |17.186  |0.77    |16.712 (+2.76%)  | 0.87   |17.043 (+0.83%) 
> |0.83    |
> |10| 16    |30.378  |0.55    |29.780 (+1.97%)  | 0.38   |29.565 (+2.67%) 
> |0.29    |
> |10| 32    |54.712  |0.54    |53.001 (+3.13%)  | 0.19   |52.158 (+4.67%) 
> |0.22    |
> +--+---+++-++++

previous numbers.

+---++---+---+--+
|   ||   | Without patch |With patch|
+---++---+-+-++-+
|Loops  |FD  |Groups | Average |%Std Dev |Average |%Std Dev |
+---++---+-+-++-+
|10 |40  |4  | 9.701   |0.78 |9.623  (+0.81%) |3.67 |
|10 |40  |8  | 17.186  |0.77 |17.068 (+0.68%) |1.89 |
|10 |40  |16 | 30.378  |0.55 |30.072 (+1.52%) |0.46 |
|10 |40  |32 | 54.712  |0.54 |53.588 (+2.28%) |0.21 |
+---++---+-+-++-+

My take on this (not that you have to sell it to me, you don't) when I
squint at these together is submit the one-liner, and take the rest
back to the drawing board.  You've got nothing but high std dev numbers
in (imo) way too finicky/unrealistic hackbench to sell these not so
pretty patches.

I bet you can easily sell that one-liner, because that removes an old
wart (me stealing migration_cost in the first place), instead of making
wart a whole lot harder to intentionally not notice.

-Mike

Re: [PATCH 3/3] taint: Add taint for randstruct

[Alexey Dobriyan]

On Thu, Feb 15, 2018 at 07:37:44PM -0800, Kees Cook wrote:
> + [ TAINT_RANDSTRUCT ]= { 'T', ' ', true },

Something like this, yeah.

Re: [RFC 1/2] sched: reduce migration cost between faster caches for idle_balance

[Mike Galbraith]

On Thu, 2018-02-15 at 10:07 -0800, Rohit Jain wrote:
> 
> > Rohit is running more tests with a patch that deletes
> > sysctl_sched_migration_cost from idle_balance, and for his patch but
> > with the 5000 usec mistake corrected back to 500 usec.  So far both
> > give improvements over the baseline, but for different cases, so we
> > need to try more workloads before we draw any conclusions.
> >
> > Rohit, can you share your data so far?
> 
> Results:
> 
> In the following results, "Domain based" approach is as mentioned in the
> RFC sent out with the values fixed (As pointed out by Mike). "No check" is
> the patch where I just remove the check against sysctl_sched_migration_cost
> 
> 1) Hackbench results on 2 socket, 44 core and 88 threads Intel x86 machine
> (lower is better):
> 
> +--+-+--+-+
> |  | Without Patch   |Domain Based  |No Check 
>     |
> +--+---+++-++++
> |Loops | Groups|Average |%Std Dev|Average  |%Std Dev|Average 
> |%Std Dev|
> +--+---+++-++++
> |10| 4 |9.701   |0.78    |7.971  (+17.84%) | 1.34   |8.919  (+8.07%) 
> |1.07    |
> |10| 8 |17.186  |0.77    |16.712 (+2.76%)  | 0.87   |17.043 (+0.83%) 
> |0.83    |
> |10| 16    |30.378  |0.55    |29.780 (+1.97%)  | 0.38   |29.565 (+2.67%) 
> |0.29    |
> |10| 32    |54.712  |0.54    |53.001 (+3.13%)  | 0.19   |52.158 (+4.67%) 
> |0.22    |
> +--+---+++-++++

previous numbers.

+---++---+---+--+
|   ||   | Without patch |With patch|
+---++---+-+-++-+
|Loops  |FD  |Groups | Average |%Std Dev |Average |%Std Dev |
+---++---+-+-++-+
|10 |40  |4  | 9.701   |0.78 |9.623  (+0.81%) |3.67 |
|10 |40  |8  | 17.186  |0.77 |17.068 (+0.68%) |1.89 |
|10 |40  |16 | 30.378  |0.55 |30.072 (+1.52%) |0.46 |
|10 |40  |32 | 54.712  |0.54 |53.588 (+2.28%) |0.21 |
+---++---+-+-++-+

My take on this (not that you have to sell it to me, you don't) when I
squint at these together is submit the one-liner, and take the rest
back to the drawing board.  You've got nothing but high std dev numbers
in (imo) way too finicky/unrealistic hackbench to sell these not so
pretty patches.

I bet you can easily sell that one-liner, because that removes an old
wart (me stealing migration_cost in the first place), instead of making
wart a whole lot harder to intentionally not notice.

-Mike

Re: [PATCH 3/3] taint: Add taint for randstruct

[Alexey Dobriyan]

On Thu, Feb 15, 2018 at 07:37:44PM -0800, Kees Cook wrote:
> + [ TAINT_RANDSTRUCT ]= { 'T', ' ', true },

Something like this, yeah.

Re: [PATCH 08/12] i2c: qup: change completion timeout according to transfer length

[Sricharan R]

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> Currently the completion timeout is being taken according to
> maximum transfer length which is too high if SCL is operating in
> high frequency. This patch calculates timeout on the basis of
> one-byte transfer time and uses the same for completion timeout.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index a91fc70..6df65ea 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -130,8 +130,8 @@
>  #define MX_TX_RX_LEN SZ_64K
>  #define MX_BLOCKS(MX_TX_RX_LEN / QUP_READ_LIMIT)
>  
> -/* Max timeout in ms for 32k bytes */
> -#define TOUT_MAX 300
> +/* Min timeout for i2c transfers */
> +#define TOUT_MIN 2
>  

 may be you can mention, why is this 2 ?

Regards,
 Sricharan


>  /* Default values. Use these if FW query fails */
>  #define DEFAULT_CLK_FREQ 10
> @@ -172,6 +172,7 @@ struct qup_i2c_dev {
>   int in_blk_sz;
>  
>   unsigned long   one_byte_t;
> + unsigned long   xfer_timeout;
>   struct qup_i2c_blockblk;
>  
>   struct i2c_msg  *msg;
> @@ -845,7 +846,7 @@ static int qup_i2c_bam_do_xfer(struct qup_i2c_dev *qup, 
> struct i2c_msg *msg,
>   dma_async_issue_pending(qup->brx.dma);
>   }
>  
> - if (!wait_for_completion_timeout(>xfer, TOUT_MAX * HZ)) {
> + if (!wait_for_completion_timeout(>xfer, qup->xfer_timeout)) {
>   dev_err(qup->dev, "normal trans timed out\n");
>   ret = -ETIMEDOUT;
>   }
> @@ -1601,6 +1602,8 @@ static int qup_i2c_probe(struct platform_device *pdev)
>*/
>   one_bit_t = (USEC_PER_SEC / clk_freq) + 1;
>   qup->one_byte_t = one_bit_t * 9;
> + qup->xfer_timeout = TOUT_MIN * HZ +
> + usecs_to_jiffies(MX_TX_RX_LEN * qup->one_byte_t);
>  
>   dev_dbg(qup->dev, "IN:block:%d, fifo:%d, OUT:block:%d, fifo:%d\n",
>   qup->in_blk_sz, qup->in_fifo_sz,
> 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 08/12] i2c: qup: change completion timeout according to transfer length

[Sricharan R]

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> Currently the completion timeout is being taken according to
> maximum transfer length which is too high if SCL is operating in
> high frequency. This patch calculates timeout on the basis of
> one-byte transfer time and uses the same for completion timeout.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index a91fc70..6df65ea 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -130,8 +130,8 @@
>  #define MX_TX_RX_LEN SZ_64K
>  #define MX_BLOCKS(MX_TX_RX_LEN / QUP_READ_LIMIT)
>  
> -/* Max timeout in ms for 32k bytes */
> -#define TOUT_MAX 300
> +/* Min timeout for i2c transfers */
> +#define TOUT_MIN 2
>  

 may be you can mention, why is this 2 ?

Regards,
 Sricharan


>  /* Default values. Use these if FW query fails */
>  #define DEFAULT_CLK_FREQ 10
> @@ -172,6 +172,7 @@ struct qup_i2c_dev {
>   int in_blk_sz;
>  
>   unsigned long   one_byte_t;
> + unsigned long   xfer_timeout;
>   struct qup_i2c_blockblk;
>  
>   struct i2c_msg  *msg;
> @@ -845,7 +846,7 @@ static int qup_i2c_bam_do_xfer(struct qup_i2c_dev *qup, 
> struct i2c_msg *msg,
>   dma_async_issue_pending(qup->brx.dma);
>   }
>  
> - if (!wait_for_completion_timeout(>xfer, TOUT_MAX * HZ)) {
> + if (!wait_for_completion_timeout(>xfer, qup->xfer_timeout)) {
>   dev_err(qup->dev, "normal trans timed out\n");
>   ret = -ETIMEDOUT;
>   }
> @@ -1601,6 +1602,8 @@ static int qup_i2c_probe(struct platform_device *pdev)
>*/
>   one_bit_t = (USEC_PER_SEC / clk_freq) + 1;
>   qup->one_byte_t = one_bit_t * 9;
> + qup->xfer_timeout = TOUT_MIN * HZ +
> + usecs_to_jiffies(MX_TX_RX_LEN * qup->one_byte_t);
>  
>   dev_dbg(qup->dev, "IN:block:%d, fifo:%d, OUT:block:%d, fifo:%d\n",
>   qup->in_blk_sz, qup->in_fifo_sz,
> 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH -mm 1/3] proc: randomize "struct pde_opener"

[Alexey Dobriyan]

On Fri, Feb 16, 2018 at 12:13:17AM +, Al Viro wrote:
> On Fri, Feb 16, 2018 at 12:41:13AM +0300, Alexey Dobriyan wrote:
> > On Thu, Feb 15, 2018 at 07:07:13PM +, Al Viro wrote:
> > > On Wed, Feb 14, 2018 at 11:19:35AM +0300, Alexey Dobriyan wrote:
> > > 
> > > > The more the merrier.
> > > 
> > > ITYM "Sanity is overrated anyway."
> > 
> > If you view annotations as debugging option the thing is not that bad.
> 
> Yes, if your goal is to debug gcc.  Look, randomize_layout is a bad idea,
> with worse implementation.  It's security theatre with no real benefits,
> it makes for much harder kernel debugging, it buggers cachelines without
> noticing *AND* it triggers gcc version-dependent miscompiles that
> cheerfully cause memory corruption.

So at least gcc people should all enable it. :^)

Re: [PATCH -mm 1/3] proc: randomize "struct pde_opener"

[Alexey Dobriyan]

On Fri, Feb 16, 2018 at 12:13:17AM +, Al Viro wrote:
> On Fri, Feb 16, 2018 at 12:41:13AM +0300, Alexey Dobriyan wrote:
> > On Thu, Feb 15, 2018 at 07:07:13PM +, Al Viro wrote:
> > > On Wed, Feb 14, 2018 at 11:19:35AM +0300, Alexey Dobriyan wrote:
> > > 
> > > > The more the merrier.
> > > 
> > > ITYM "Sanity is overrated anyway."
> > 
> > If you view annotations as debugging option the thing is not that bad.
> 
> Yes, if your goal is to debug gcc.  Look, randomize_layout is a bad idea,
> with worse implementation.  It's security theatre with no real benefits,
> it makes for much harder kernel debugging, it buggers cachelines without
> noticing *AND* it triggers gcc version-dependent miscompiles that
> cheerfully cause memory corruption.

So at least gcc people should all enable it. :^)

Re: [PATCH -mm 1/3] proc: randomize "struct pde_opener"

[Alexey Dobriyan]

On Thu, Feb 15, 2018 at 04:53:29PM -0800, Kees Cook wrote:
> On Wed, Feb 14, 2018 at 12:19 AM, Alexey Dobriyan  wrote:
> > The more the merrier.
> 
> What made you choose this structure, BTW?

Nothing depends on its layout. No funky memcpy/memset...
It is strange you didn't annotate like 95% of structs.

> > @@ -177,7 +177,7 @@ struct pde_opener {
> > struct list_head lh;
> > bool closing;
> > struct completion *c;
> > -};
> > +} __randomize_layout;

Re: [PATCH -mm 1/3] proc: randomize "struct pde_opener"

[Alexey Dobriyan]

On Thu, Feb 15, 2018 at 04:53:29PM -0800, Kees Cook wrote:
> On Wed, Feb 14, 2018 at 12:19 AM, Alexey Dobriyan  wrote:
> > The more the merrier.
> 
> What made you choose this structure, BTW?

Nothing depends on its layout. No funky memcpy/memset...
It is strange you didn't annotate like 95% of structs.

> > @@ -177,7 +177,7 @@ struct pde_opener {
> > struct list_head lh;
> > bool closing;
> > struct completion *c;
> > -};
> > +} __randomize_layout;

Re: [PATCH] mfd: tps65218: Reorder tps65218_regulator_id enum

[Keerthy]

On Friday 16 February 2018 09:47 AM, Dave Gerlach wrote:
> Commit 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles")
> changes the probe function of drivers/regulator/tps65218-regulator.c so
> that it iterates through all available regulators and assumes that the
> regulator IDs are sequential and match the order present in the enum
> tps65218_regulator_id. However, for some reason the much older commit
> c0ea88b890d6 ("regulator: tps65218: add support for LS3 current
> regulator") updated all arrays with LS3 at the end but added it second
> to last for the enum.
> 
> Because of this long standing mismatch in order between the
> tps65218_regulator_id enum and the regulator_desc array in the tps65218
> regulator driver, the new probe function causes the strobe values to be
> associated with the wrong regulator ID. This causes LDO1 to fail to
> suspend in tps65218_pmic_set_suspend_disable due to not having anything
> probes for its strobe value. Fix the order in the enum so the probe
> function works as the update intended.

Reviewed-by: Keerthy 

> 
> Fixes: 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles")
> Signed-off-by: Dave Gerlach 
> ---
>  include/linux/mfd/tps65218.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
> index f069c518c0ed..c204d9a79436 100644
> --- a/include/linux/mfd/tps65218.h
> +++ b/include/linux/mfd/tps65218.h
> @@ -205,10 +205,10 @@ enum tps65218_regulator_id {
>   TPS65218_DCDC_4,
>   TPS65218_DCDC_5,
>   TPS65218_DCDC_6,
> - /* LS's */
> - TPS65218_LS_3,
>   /* LDOs */
>   TPS65218_LDO_1,
> + /* LS's */
> + TPS65218_LS_3,
>  };
>  
>  #define TPS65218_MAX_REG_ID  TPS65218_LDO_1
> 

Re: [PATCH] mfd: tps65218: Reorder tps65218_regulator_id enum

[Keerthy]

On Friday 16 February 2018 09:47 AM, Dave Gerlach wrote:
> Commit 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles")
> changes the probe function of drivers/regulator/tps65218-regulator.c so
> that it iterates through all available regulators and assumes that the
> regulator IDs are sequential and match the order present in the enum
> tps65218_regulator_id. However, for some reason the much older commit
> c0ea88b890d6 ("regulator: tps65218: add support for LS3 current
> regulator") updated all arrays with LS3 at the end but added it second
> to last for the enum.
> 
> Because of this long standing mismatch in order between the
> tps65218_regulator_id enum and the regulator_desc array in the tps65218
> regulator driver, the new probe function causes the strobe values to be
> associated with the wrong regulator ID. This causes LDO1 to fail to
> suspend in tps65218_pmic_set_suspend_disable due to not having anything
> probes for its strobe value. Fix the order in the enum so the probe
> function works as the update intended.

Reviewed-by: Keerthy 

> 
> Fixes: 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles")
> Signed-off-by: Dave Gerlach 
> ---
>  include/linux/mfd/tps65218.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
> index f069c518c0ed..c204d9a79436 100644
> --- a/include/linux/mfd/tps65218.h
> +++ b/include/linux/mfd/tps65218.h
> @@ -205,10 +205,10 @@ enum tps65218_regulator_id {
>   TPS65218_DCDC_4,
>   TPS65218_DCDC_5,
>   TPS65218_DCDC_6,
> - /* LS's */
> - TPS65218_LS_3,
>   /* LDOs */
>   TPS65218_LDO_1,
> + /* LS's */
> + TPS65218_LS_3,
>  };
>  
>  #define TPS65218_MAX_REG_ID  TPS65218_LDO_1
> 

Re: [PATCH 07/12] i2c: qup: use the complete transfer length to choose DMA mode

[Sricharan R]

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> Currently each message length in complete transfer is being
> checked for determining DMA mode and if any of the message length
> is less than FIFO length then non DMA mode is being used which
> will increase overhead. DMA can be used for any length and it
> should be determined with complete transfer length. Now, this
> patch introduces DMA threshold length and the transfer will be
> done in DMA mode if the total length is greater than this
> threshold length.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index 6227a5c..a91fc70 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -192,6 +192,8 @@ struct qup_i2c_dev {
>   boolis_dma;
>   /* To check if the current transfer is using DMA */
>   booluse_dma;
> + /* The threshold length above which DMA will be used */
> + unsigned intdma_threshold;
>   struct  dma_pool *dpool;
>   struct  qup_i2c_tag start_tag;
>   struct  qup_i2c_bam brx;
> @@ -1294,7 +1296,8 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
>  int num)
>  {
>   struct qup_i2c_dev *qup = i2c_get_adapdata(adap);
> - int ret, len, idx = 0;
> + int ret, idx = 0;
> + unsigned int total_len = 0;
>  
>   qup->bus_err = 0;
>   qup->qup_err = 0;
> @@ -1320,14 +1323,13 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
>   goto out;
>   }
>  
> - len = (msgs[idx].len > qup->out_fifo_sz) ||
> -   (msgs[idx].len > qup->in_fifo_sz);
> -
> - if (is_vmalloc_addr(msgs[idx].buf) || !len)
> + if (is_vmalloc_addr(msgs[idx].buf))
>   break;
> +
> + total_len += msgs[idx].len;
>   }
>  
> - if (idx == num)
> + if (idx == num && total_len > qup->dma_threshold)
>   qup->use_dma = true;
>   }
>  
> @@ -1587,6 +1589,7 @@ static int qup_i2c_probe(struct platform_device *pdev)
>  
>   size = QUP_INPUT_FIFO_SIZE(io_mode);
>   qup->in_fifo_sz = qup->in_blk_sz * (2 << size);
> + qup->dma_threshold = min(qup->out_fifo_sz, qup->in_fifo_sz);

  The patch is fine. small nit, you can avoid this global dma_threshold. Instead
  have it locally in qup_i2c_xfer_v2 itself.

Regards,
 Sricharan


-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 07/12] i2c: qup: use the complete transfer length to choose DMA mode

[Sricharan R]

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> Currently each message length in complete transfer is being
> checked for determining DMA mode and if any of the message length
> is less than FIFO length then non DMA mode is being used which
> will increase overhead. DMA can be used for any length and it
> should be determined with complete transfer length. Now, this
> patch introduces DMA threshold length and the transfer will be
> done in DMA mode if the total length is greater than this
> threshold length.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index 6227a5c..a91fc70 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -192,6 +192,8 @@ struct qup_i2c_dev {
>   boolis_dma;
>   /* To check if the current transfer is using DMA */
>   booluse_dma;
> + /* The threshold length above which DMA will be used */
> + unsigned intdma_threshold;
>   struct  dma_pool *dpool;
>   struct  qup_i2c_tag start_tag;
>   struct  qup_i2c_bam brx;
> @@ -1294,7 +1296,8 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
>  int num)
>  {
>   struct qup_i2c_dev *qup = i2c_get_adapdata(adap);
> - int ret, len, idx = 0;
> + int ret, idx = 0;
> + unsigned int total_len = 0;
>  
>   qup->bus_err = 0;
>   qup->qup_err = 0;
> @@ -1320,14 +1323,13 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
>   goto out;
>   }
>  
> - len = (msgs[idx].len > qup->out_fifo_sz) ||
> -   (msgs[idx].len > qup->in_fifo_sz);
> -
> - if (is_vmalloc_addr(msgs[idx].buf) || !len)
> + if (is_vmalloc_addr(msgs[idx].buf))
>   break;
> +
> + total_len += msgs[idx].len;
>   }
>  
> - if (idx == num)
> + if (idx == num && total_len > qup->dma_threshold)
>   qup->use_dma = true;
>   }
>  
> @@ -1587,6 +1589,7 @@ static int qup_i2c_probe(struct platform_device *pdev)
>  
>   size = QUP_INPUT_FIFO_SIZE(io_mode);
>   qup->in_fifo_sz = qup->in_blk_sz * (2 << size);
> + qup->dma_threshold = min(qup->out_fifo_sz, qup->in_fifo_sz);

  The patch is fine. small nit, you can avoid this global dma_threshold. Instead
  have it locally in qup_i2c_xfer_v2 itself.

Regards,
 Sricharan


-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 06/12] i2c: qup: proper error handling for i2c error in BAM mode

[Sricharan R]

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> Currently the i2c error handling in BAM mode is not working
> properly in stress condition.
> 
> 1. After an error, the FIFO are being written with FLUSH and
>EOT tags which should not be required since already these tags
>have been written in BAM descriptor itself.
> 
> 2. QUP state is being moved to RESET in IRQ handler in case
>of error. When QUP HW encounters an error in BAM mode then it
>moves the QUP STATE to PAUSE state. In this case, I2C_FLUSH
>command needs to be executed while moving to RUN_STATE by writing
>to the QUP_STATE register with the I2C_FLUSH bit set to 1.
> 
> 3. In Error case, sometimes, QUP generates more than one
>interrupt which will trigger the complete again. After an error,
>the flush operation will be scheduled after doing
>reinit_completion which should be triggered by BAM IRQ callback.
>If the second QUP IRQ comes during this time then it will call
>the complete and the transfer function will assume the all the
>BAM HW descriptors have been completed.
> 
> 4. The release DMA is being called after each error which
>will free the DMA tx and rx channels. The error like NACK is very
>common in I2C transfer and every time this will be overhead. Now,
>since the error handling is proper so this release channel can be
>completely avoided.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index 094be6a..6227a5c 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -228,9 +228,24 @@ static irqreturn_t qup_i2c_interrupt(int irq, void *dev)
>   if (bus_err)
>   writel(bus_err, qup->base + QUP_I2C_STATUS);
>  
> + /*
> +  * Check for BAM mode and returns if already error has come for current
> +  * transfer. In Error case, sometimes, QUP generates more than one
> +  * interrupt.
> +  */
> + if (qup->use_dma && (qup->qup_err || qup->bus_err))
> + return IRQ_HANDLED;
> +
>   /* Reset the QUP State in case of error */
>   if (qup_err || bus_err) {
> - writel(QUP_RESET_STATE, qup->base + QUP_STATE);
> + /*
> +  * Don’t reset the QUP state in case of BAM mode. The BAM
> +  * flush operation needs to be scheduled in transfer function
> +  * which will clear the remaining schedule descriptors in BAM
> +  * HW FIFO and generates the BAM interrupt.
> +  */
> + if (!qup->use_dma)
> + writel(QUP_RESET_STATE, qup->base + QUP_STATE);
>   goto done;
>   }
>  
> @@ -841,20 +856,12 @@ static int qup_i2c_bam_do_xfer(struct qup_i2c_dev *qup, 
> struct i2c_msg *msg,
>   goto desc_err;
>   }
>  
> - if (rx_buf)
> - writel(QUP_BAM_INPUT_EOT,
> -qup->base + QUP_OUT_FIFO_BASE);
> -
> - writel(QUP_BAM_FLUSH_STOP, qup->base + QUP_OUT_FIFO_BASE);
> -
>   qup_i2c_flush(qup);
>  
>   /* wait for remaining interrupts to occur */
>   if (!wait_for_completion_timeout(>xfer, HZ))
>   dev_err(qup->dev, "flush timed out\n");
>  
> - qup_i2c_rel_dma(qup);
> -
>   ret =  (qup->bus_err & QUP_I2C_NACK_FLAG) ? -ENXIO : -EIO;
>   }
>  
> 

 Reviewed-by: Sricharan R 

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 06/12] i2c: qup: proper error handling for i2c error in BAM mode

[Sricharan R]

On 2/3/2018 1:28 PM, Abhishek Sahu wrote:
> Currently the i2c error handling in BAM mode is not working
> properly in stress condition.
> 
> 1. After an error, the FIFO are being written with FLUSH and
>EOT tags which should not be required since already these tags
>have been written in BAM descriptor itself.
> 
> 2. QUP state is being moved to RESET in IRQ handler in case
>of error. When QUP HW encounters an error in BAM mode then it
>moves the QUP STATE to PAUSE state. In this case, I2C_FLUSH
>command needs to be executed while moving to RUN_STATE by writing
>to the QUP_STATE register with the I2C_FLUSH bit set to 1.
> 
> 3. In Error case, sometimes, QUP generates more than one
>interrupt which will trigger the complete again. After an error,
>the flush operation will be scheduled after doing
>reinit_completion which should be triggered by BAM IRQ callback.
>If the second QUP IRQ comes during this time then it will call
>the complete and the transfer function will assume the all the
>BAM HW descriptors have been completed.
> 
> 4. The release DMA is being called after each error which
>will free the DMA tx and rx channels. The error like NACK is very
>common in I2C transfer and every time this will be overhead. Now,
>since the error handling is proper so this release channel can be
>completely avoided.
> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/i2c/busses/i2c-qup.c | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index 094be6a..6227a5c 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -228,9 +228,24 @@ static irqreturn_t qup_i2c_interrupt(int irq, void *dev)
>   if (bus_err)
>   writel(bus_err, qup->base + QUP_I2C_STATUS);
>  
> + /*
> +  * Check for BAM mode and returns if already error has come for current
> +  * transfer. In Error case, sometimes, QUP generates more than one
> +  * interrupt.
> +  */
> + if (qup->use_dma && (qup->qup_err || qup->bus_err))
> + return IRQ_HANDLED;
> +
>   /* Reset the QUP State in case of error */
>   if (qup_err || bus_err) {
> - writel(QUP_RESET_STATE, qup->base + QUP_STATE);
> + /*
> +  * Don’t reset the QUP state in case of BAM mode. The BAM
> +  * flush operation needs to be scheduled in transfer function
> +  * which will clear the remaining schedule descriptors in BAM
> +  * HW FIFO and generates the BAM interrupt.
> +  */
> + if (!qup->use_dma)
> + writel(QUP_RESET_STATE, qup->base + QUP_STATE);
>   goto done;
>   }
>  
> @@ -841,20 +856,12 @@ static int qup_i2c_bam_do_xfer(struct qup_i2c_dev *qup, 
> struct i2c_msg *msg,
>   goto desc_err;
>   }
>  
> - if (rx_buf)
> - writel(QUP_BAM_INPUT_EOT,
> -qup->base + QUP_OUT_FIFO_BASE);
> -
> - writel(QUP_BAM_FLUSH_STOP, qup->base + QUP_OUT_FIFO_BASE);
> -
>   qup_i2c_flush(qup);
>  
>   /* wait for remaining interrupts to occur */
>   if (!wait_for_completion_timeout(>xfer, HZ))
>   dev_err(qup->dev, "flush timed out\n");
>  
> - qup_i2c_rel_dma(qup);
> -
>   ret =  (qup->bus_err & QUP_I2C_NACK_FLAG) ? -ENXIO : -EIO;
>   }
>  
> 

 Reviewed-by: Sricharan R 

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

[Andi Kleen]

> > +   wrmsrl(MSR_IA32_PRED_CMD, PRED_CMD_IBPB);
> 
> Should this be wrmsrl_safe? I don't see where we've verified host
> support of this MSR.

In mainline all wrmsr are wrmsrl_safe now.

-Andi

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

[Andi Kleen]

> > +   wrmsrl(MSR_IA32_PRED_CMD, PRED_CMD_IBPB);
> 
> Should this be wrmsrl_safe? I don't see where we've verified host
> support of this MSR.

In mainline all wrmsr are wrmsrl_safe now.

-Andi

[PATCH] mfd: tps65218: Reorder tps65218_regulator_id enum

[Dave Gerlach]

Commit 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles")
changes the probe function of drivers/regulator/tps65218-regulator.c so
that it iterates through all available regulators and assumes that the
regulator IDs are sequential and match the order present in the enum
tps65218_regulator_id. However, for some reason the much older commit
c0ea88b890d6 ("regulator: tps65218: add support for LS3 current
regulator") updated all arrays with LS3 at the end but added it second
to last for the enum.

Because of this long standing mismatch in order between the
tps65218_regulator_id enum and the regulator_desc array in the tps65218
regulator driver, the new probe function causes the strobe values to be
associated with the wrong regulator ID. This causes LDO1 to fail to
suspend in tps65218_pmic_set_suspend_disable due to not having anything
probes for its strobe value. Fix the order in the enum so the probe
function works as the update intended.

Fixes: 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles")
Signed-off-by: Dave Gerlach 
---
 include/linux/mfd/tps65218.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index f069c518c0ed..c204d9a79436 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -205,10 +205,10 @@ enum tps65218_regulator_id {
TPS65218_DCDC_4,
TPS65218_DCDC_5,
TPS65218_DCDC_6,
-   /* LS's */
-   TPS65218_LS_3,
/* LDOs */
TPS65218_LDO_1,
+   /* LS's */
+   TPS65218_LS_3,
 };
 
 #define TPS65218_MAX_REG_IDTPS65218_LDO_1
-- 
2.16.1

[PATCH] mfd: tps65218: Reorder tps65218_regulator_id enum

[Dave Gerlach]

Commit 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles")
changes the probe function of drivers/regulator/tps65218-regulator.c so
that it iterates through all available regulators and assumes that the
regulator IDs are sequential and match the order present in the enum
tps65218_regulator_id. However, for some reason the much older commit
c0ea88b890d6 ("regulator: tps65218: add support for LS3 current
regulator") updated all arrays with LS3 at the end but added it second
to last for the enum.

Because of this long standing mismatch in order between the
tps65218_regulator_id enum and the regulator_desc array in the tps65218
regulator driver, the new probe function causes the strobe values to be
associated with the wrong regulator ID. This causes LDO1 to fail to
suspend in tps65218_pmic_set_suspend_disable due to not having anything
probes for its strobe value. Fix the order in the enum so the probe
function works as the update intended.

Fixes: 2dc4940360d4 ("regulator: tps65218: Remove all the compatibles")
Signed-off-by: Dave Gerlach 
---
 include/linux/mfd/tps65218.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index f069c518c0ed..c204d9a79436 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -205,10 +205,10 @@ enum tps65218_regulator_id {
TPS65218_DCDC_4,
TPS65218_DCDC_5,
TPS65218_DCDC_6,
-   /* LS's */
-   TPS65218_LS_3,
/* LDOs */
TPS65218_LDO_1,
+   /* LS's */
+   TPS65218_LS_3,
 };
 
 #define TPS65218_MAX_REG_IDTPS65218_LDO_1
-- 
2.16.1

Re: [PATCH 8/9] KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL

[Jim Mattson]

On Tue, Feb 6, 2018 at 9:29 AM, David Woodhouse  wrote:

> @@ -8946,6 +9017,27 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
> *vcpu)
>  #endif
>   );
>
> +   /*
> +* We do not use IBRS in the kernel. If this vCPU has used the
> +* SPEC_CTRL MSR it may have left it on; save the value and
> +* turn it off. This is much more efficient than blindly adding
> +* it to the atomic save/restore list. Especially as the former
> +* (Saving guest MSRs on vmexit) doesn't even exist in KVM.
> +*
> +* For non-nested case:
> +* If the L01 MSR bitmap does not intercept the MSR, then we need to
> +* save it.
> +*
> +* For nested case:
> +* If the L02 MSR bitmap does not intercept the MSR, then we need to
> +* save it.
> +*/
> +   if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))
> +   rdmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl);
> +
> +   if (vmx->spec_ctrl)
> +   wrmsrl(MSR_IA32_SPEC_CTRL, 0);
> +

Again, we haven't verified host support for this MSR. Perhaps this
should be something like:

if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)
&& !rdmsrl_safe(MSR_IA32_SPEC_CTRL, >spec_ctrl) && vmx->spec_ctrl)
wrmsrl(MSR_IA32_SPEC_CTRL, 0);

Re: [PATCH 8/9] KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL

[Jim Mattson]

On Tue, Feb 6, 2018 at 9:29 AM, David Woodhouse  wrote:

> @@ -8946,6 +9017,27 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
> *vcpu)
>  #endif
>   );
>
> +   /*
> +* We do not use IBRS in the kernel. If this vCPU has used the
> +* SPEC_CTRL MSR it may have left it on; save the value and
> +* turn it off. This is much more efficient than blindly adding
> +* it to the atomic save/restore list. Especially as the former
> +* (Saving guest MSRs on vmexit) doesn't even exist in KVM.
> +*
> +* For non-nested case:
> +* If the L01 MSR bitmap does not intercept the MSR, then we need to
> +* save it.
> +*
> +* For nested case:
> +* If the L02 MSR bitmap does not intercept the MSR, then we need to
> +* save it.
> +*/
> +   if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))
> +   rdmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl);
> +
> +   if (vmx->spec_ctrl)
> +   wrmsrl(MSR_IA32_SPEC_CTRL, 0);
> +

Again, we haven't verified host support for this MSR. Perhaps this
should be something like:

if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)
&& !rdmsrl_safe(MSR_IA32_SPEC_CTRL, >spec_ctrl) && vmx->spec_ctrl)
wrmsrl(MSR_IA32_SPEC_CTRL, 0);

Re: [PATCH v3] rtc: ac100: Fix ac100 determine rate bug

[Chen-Yu Tsai]

On Fri, Feb 16, 2018 at 1:53 AM, Philipp Rossak  wrote:
>
>
> On 15.02.2018 15:11, Maxime Ripard wrote:
>>
>> On Wed, Feb 14, 2018 at 02:56:12PM +0100, Philipp Rossak wrote:
>>>
>>> This patch fixes a bug, that prevents the Allwinner A83T and the A80
>>> from a successful boot.
>>>
>>> The bug is there since v4.16-rc1 and appeared after the clk branch was
>>> merged.
>>
>>
>> Out of curiosity, which patch has introduced this? I couldn't find any
>> obvious match.
>>
>
> I wasn't also n

To be honest, I'm not sure why this is hitting you and not me.
I have both A83T boards that have assigned-clock-rates set for
the ac100 clock outputs for WiFi. I have them running 4.16-rc1
and have not seen this. The device tree patches that add these
are in 4.15.

>
>>> You can find the shortend trace below:
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address
>>> 
>>> pgd = (ptrval)
>>> [] *pgd=
>>> Internal error: Oops: 5 [#1] SMP ARM
>>> Modules linked in:
>>> CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be
>>> #2
>>> Hardware name: Allwinner sun8i Family
>>> Workqueue: events deferred_probe_work_func
>>> PC is at clk_hw_get_rate+0x0/0x34
>>> LR is at ac100_clkout_determine_rate+0x48/0x19c
>>>
>>> [ ... ]
>>>
>>> (clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c)
>>> (ac100_clkout_determine_rate) from  (clk_core_set_rate_nolock+0x3c/0x1a0)
>>> (clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88)
>>> (clk_set_rate) from (of_clk_set_defaults+0x200/0x364)
>>> (of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0)
>>>
>>> To fix that bug, we first check if the return of the
>>> clk_hw_get_parent_by_index is non zero. If it is zero we skip that
>>> clock parent.
>>>
>>> The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198
>>>
>>> Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support")
>>>
>>> Signed-off-by: Philipp Rossak 
>>> ---
>>>
>>> Changes in v3:
>>> * add information when the bug appeared
>>> * make the comment more clear
>>> Changes in v2:
>>> * add tag Fixes: ... to commit message
>>> * add comment to if statement why we are doing this check
>>>
>>>   drivers/rtc/rtc-ac100.c | 19 ++-
>>>   1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c
>>> index 8ff9dc3fe5bf..2412aa2e8399 100644
>>> --- a/drivers/rtc/rtc-ac100.c
>>> +++ b/drivers/rtc/rtc-ac100.c
>>> @@ -183,7 +183,24 @@ static int ac100_clkout_determine_rate(struct clk_hw
>>> *hw,
>>> for (i = 0; i < num_parents; i++) {
>>> struct clk_hw *parent = clk_hw_get_parent_by_index(hw,
>>> i);
>>> -   unsigned long tmp, prate = clk_hw_get_rate(parent);
>>> +   unsigned long tmp, prate;
>>> +
>>> +   /*
>>> +* The clock has two parents, one is a fixed clock which
>>> is
>>> +* internally registered by the ac100 driver. The other
>>> parent
>>> +* is a clock from the codec side of the chip, which we
>>> +* properly declare and reference in the devicetree and
>>> is
>>> +* not implemented in any driver right now.
>>> +* If the clock core looks for the parent of that second
>>> +* missing clock, it can't one that is registered and
>>> +* returns NULL.
>>> +* Thus we need to check if the parent exists before
>>> +* we get the parent rate.
>>> +*/
>>> +   if (!parent)
>>> +   continue;
>>
>>
>> I'm sorry, but I still don't get it. When you register that clock, you
>> will give it two parents. Why would that change during the life of the
>> clock?
>>
>> This really looks like a workaround rather than an actual fix.
>>
>> Maxime
>>
> I agree this is more a workaround!
> A proper solution/fix would be to define the devicetree correct like this:
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> index 6550bf0e594b..6f56d429f17e 100644
> --- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> +++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> @@ -175,11 +175,18 @@
> compatible = "x-powers,ac100-rtc";
> interrupt-parent = <_intc>;
> interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> -   clocks = <_codec>;
> +   clocks = <_rtc_32k>;
> #clock-cells = <1>;
> clock-output-names = "cko1_rtc",
>  "cko2_rtc",
>  "cko3_rtc";
> +
> +   ac100_rtc_32k: rtc-32k-oscillator {
> +   compatible = "fixed-clock";
> +   

Re: [PATCH v3] rtc: ac100: Fix ac100 determine rate bug

[Chen-Yu Tsai]

On Fri, Feb 16, 2018 at 1:53 AM, Philipp Rossak  wrote:
>
>
> On 15.02.2018 15:11, Maxime Ripard wrote:
>>
>> On Wed, Feb 14, 2018 at 02:56:12PM +0100, Philipp Rossak wrote:
>>>
>>> This patch fixes a bug, that prevents the Allwinner A83T and the A80
>>> from a successful boot.
>>>
>>> The bug is there since v4.16-rc1 and appeared after the clk branch was
>>> merged.
>>
>>
>> Out of curiosity, which patch has introduced this? I couldn't find any
>> obvious match.
>>
>
> I wasn't also n

To be honest, I'm not sure why this is hitting you and not me.
I have both A83T boards that have assigned-clock-rates set for
the ac100 clock outputs for WiFi. I have them running 4.16-rc1
and have not seen this. The device tree patches that add these
are in 4.15.

>
>>> You can find the shortend trace below:
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address
>>> 
>>> pgd = (ptrval)
>>> [] *pgd=
>>> Internal error: Oops: 5 [#1] SMP ARM
>>> Modules linked in:
>>> CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be
>>> #2
>>> Hardware name: Allwinner sun8i Family
>>> Workqueue: events deferred_probe_work_func
>>> PC is at clk_hw_get_rate+0x0/0x34
>>> LR is at ac100_clkout_determine_rate+0x48/0x19c
>>>
>>> [ ... ]
>>>
>>> (clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c)
>>> (ac100_clkout_determine_rate) from  (clk_core_set_rate_nolock+0x3c/0x1a0)
>>> (clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88)
>>> (clk_set_rate) from (of_clk_set_defaults+0x200/0x364)
>>> (of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0)
>>>
>>> To fix that bug, we first check if the return of the
>>> clk_hw_get_parent_by_index is non zero. If it is zero we skip that
>>> clock parent.
>>>
>>> The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198
>>>
>>> Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support")
>>>
>>> Signed-off-by: Philipp Rossak 
>>> ---
>>>
>>> Changes in v3:
>>> * add information when the bug appeared
>>> * make the comment more clear
>>> Changes in v2:
>>> * add tag Fixes: ... to commit message
>>> * add comment to if statement why we are doing this check
>>>
>>>   drivers/rtc/rtc-ac100.c | 19 ++-
>>>   1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c
>>> index 8ff9dc3fe5bf..2412aa2e8399 100644
>>> --- a/drivers/rtc/rtc-ac100.c
>>> +++ b/drivers/rtc/rtc-ac100.c
>>> @@ -183,7 +183,24 @@ static int ac100_clkout_determine_rate(struct clk_hw
>>> *hw,
>>> for (i = 0; i < num_parents; i++) {
>>> struct clk_hw *parent = clk_hw_get_parent_by_index(hw,
>>> i);
>>> -   unsigned long tmp, prate = clk_hw_get_rate(parent);
>>> +   unsigned long tmp, prate;
>>> +
>>> +   /*
>>> +* The clock has two parents, one is a fixed clock which
>>> is
>>> +* internally registered by the ac100 driver. The other
>>> parent
>>> +* is a clock from the codec side of the chip, which we
>>> +* properly declare and reference in the devicetree and
>>> is
>>> +* not implemented in any driver right now.
>>> +* If the clock core looks for the parent of that second
>>> +* missing clock, it can't one that is registered and
>>> +* returns NULL.
>>> +* Thus we need to check if the parent exists before
>>> +* we get the parent rate.
>>> +*/
>>> +   if (!parent)
>>> +   continue;
>>
>>
>> I'm sorry, but I still don't get it. When you register that clock, you
>> will give it two parents. Why would that change during the life of the
>> clock?
>>
>> This really looks like a workaround rather than an actual fix.
>>
>> Maxime
>>
> I agree this is more a workaround!
> A proper solution/fix would be to define the devicetree correct like this:
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> index 6550bf0e594b..6f56d429f17e 100644
> --- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> +++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> @@ -175,11 +175,18 @@
> compatible = "x-powers,ac100-rtc";
> interrupt-parent = <_intc>;
> interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> -   clocks = <_codec>;
> +   clocks = <_rtc_32k>;
> #clock-cells = <1>;
> clock-output-names = "cko1_rtc",
>  "cko2_rtc",
>  "cko3_rtc";
> +
> +   ac100_rtc_32k: rtc-32k-oscillator {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +