Re: [PATCH 1/2] mmc: mediatek: fix SDIO IRQ interrupt handle flow

2019-06-16 Thread jjian zhou
On Fri, 2019-06-14 at 17:46 +0800, Ulf Hansson wrote:
> On Fri, 14 Jun 2019 at 07:26, Jjian Zhou  wrote:
> >
> > From: jjian zhou 
> >
> > SDIO IRQ is triggered by low level. It need disable SDIO IRQ
> > detected function. Otherwise the interrupt register can't be cleared.
> > It will process the interrupt more.
> >
> > Signed-off-by: Jjian Zhou 
> > Signed-off-by: Chaotian Jing 
> > Signed-off-by: Yong Mao 
> > ---
> >  drivers/mmc/host/mtk-sd.c | 13 +++--
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> > index c518cc2..29992ae 100644
> > --- a/drivers/mmc/host/mtk-sd.c
> > +++ b/drivers/mmc/host/mtk-sd.c
> > @@ -1389,10 +1389,12 @@ static void __msdc_enable_sdio_irq(struct mmc_host 
> > *mmc, int enb)
> > struct msdc_host *host = mmc_priv(mmc);
> >
> > spin_lock_irqsave(>lock, flags);
> > -   if (enb)
> > +   if (enb) {
> > sdr_set_bits(host->base + MSDC_INTEN, MSDC_INTEN_SDIOIRQ);
> > -   else
> > +   sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
> > +   } else {
> > sdr_clr_bits(host->base + MSDC_INTEN, MSDC_INTEN_SDIOIRQ);
> 
> Rather than clearing SDC_CFG_SDIOIDE in the irq handler, you need to
> do it here. As otherwise when the mmc core calls
> host->ops->enable_sdio_irq() to disable the SDIO IRQ, it may stay
> enabled.
> 

Thank you for your review.

I remove the spin lock in "__msdc_enable_sdio_irq" and add 
spin lock in "msdc_enable_sdio_irq". The modification of
"__msdc_enable_sdio_irq" and "msdc_enable_sdio_irq" is as following.

static void __msdc_enable_sdio_irq(struct msdc_host *host, int enb)
{
if (enb) {
sdr_set_bits(host->base + MSDC_INTEN, MSDC_INTEN_SDIOIRQ);
sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
} else {
sdr_clr_bits(host->base + MSDC_INTEN, MSDC_INTEN_SDIOIRQ);
sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
}
}

static void msdc_enable_sdio_irq(struct mmc_host *mmc, int enb)
{
unsigned long flags;
struct msdc_host *host = mmc_priv(mmc);
spin_lock_irqsave(>lock, flags);;
__msdc_enable_sdio_irq(host, enb);
spin_unlock_irqrestore(>lock, flags);

if (enb)
pm_runtime_get_noresume(host->dev);
else
pm_runtime_get_noidle(host->dev);
}

> > +   }
> > spin_unlock_irqrestore(>lock, flags);
> >  }
> >
> > @@ -1422,6 +1424,8 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
> > spin_lock_irqsave(>lock, flags);
> > events = readl(host->base + MSDC_INT);
> > event_mask = readl(host->base + MSDC_INTEN);
> > +   if ((events & event_mask) & MSDC_INT_SDIOIRQ)
> > +   sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
> 
> As stated above, I suggest you move this into __msdc_enable_sdio_irq()
> and thus call that function from here instead. Well, that doesn't work
> as is, because of the spin lock, so you rather need to make a
> sub-function of __msdc_enable_sdio_irq, that don't take/releases the
> lock.
> 
> I hope that was clear. If not, I can post a patch to show you what I mean.
> 

I also modify this part handler in msdc_irq.

spin_lock_irqsave(>lock, flags);
events = readl(host->base + MSDC_INT);
event_mask = readl(host->base + MSDC_INTEN);
if ((events & event_mask) & MSDC_INT_SDIOIRQ)
__msdc_enable_sdio_irq(host, 0);
/* clear interrupts */
writel(events & event_mask, host->base + MSDC_INT);

mrq = host->mrq;
cmd = host->cmd;
data = host->data;
spin_unlock_irqrestore(>lock, flags);

if ((events & event_mask) & MSDC_INT_SDIOIRQ)
sdio_signal_irq(host->mmc);

I also will add spin lock in the "msdc_ack_sdio_irq".

Looking forward to your suggestions.
> 
> > /* clear interrupts */
> > writel(events & event_mask, host->base + MSDC_INT);
> >
> > @@ -1572,10 +1576,7 @@ static void msdc_init_hw(struct msdc_host *host)
> > sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIO);
> >
> > /* Config SDIO device detect interrupt function */
> > -   if (host->mmc->caps & MMC_CAP_SDIO_IRQ)
> > -   sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
> > -   else
> > -   sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
> > +   sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
> >
> > /* Configure to default data timeout */
> > sdr_set_field(host->base + SDC_CFG, SDC_CFG_DTOC, 3);
> > --
> > 1.9.1
> >
> 
> Kind regards
> Uffe




Re: [PATCH] fsi: sbefifo: Don't fail operations when in SBE IPL state

2019-06-16 Thread Joel Stanley
On Mon, 17 Jun 2019 at 02:09, Alistair Popple  wrote:
>
> On Monday, 21 January 2019 11:15:58 AM AEST Eddie James wrote:
> > SBE fifo operations should be allowed while the SBE is in any of the
> > "IPL" states. Operations should succeed in this state.
> >
> > Signed-off-by: Eddie James 
>
> This fixed the problem I was having trying to issue istep operations to the
> SBE.
>
> Tested-by: Alistair Popple 

This one slipped through the cracks.

Fixes: 9f4a8a2d7f9d fsi/sbefifo: Add driver for the SBE FIFO
Reviewed-by: Joel Stanley 

Greg, can you please queue this one up for 5.3?

Cheers,

Joel

> > ---
> >  drivers/fsi/fsi-sbefifo.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/fsi/fsi-sbefifo.c b/drivers/fsi/fsi-sbefifo.c
> > index c7d13ac..f7665b3 100644
> > --- a/drivers/fsi/fsi-sbefifo.c
> > +++ b/drivers/fsi/fsi-sbefifo.c
> > @@ -290,11 +290,11 @@ static int sbefifo_check_sbe_state(struct sbefifo
> > *sbefifo) switch ((sbm & CFAM_SBM_SBE_STATE_MASK) >>
> > CFAM_SBM_SBE_STATE_SHIFT) { case SBE_STATE_UNKNOWN:
> >   return -ESHUTDOWN;
> > + case SBE_STATE_DMT:
> > + return -EBUSY;
> >   case SBE_STATE_IPLING:
> >   case SBE_STATE_ISTEP:
> >   case SBE_STATE_MPIPL:
> > - case SBE_STATE_DMT:
> > - return -EBUSY;
> >   case SBE_STATE_RUNTIME:
> >   case SBE_STATE_DUMP: /* Not sure about that one */
> >   break;
>
>


Re: [PATCH v7 18/18] x86/fsgsbase/64: Add documentation for FSGSBASE

2019-06-16 Thread Thomas Gleixner
Chang,

On Mon, 17 Jun 2019, Bae, Chang Seok wrote:

Can you please use proper quoting style?

> On Jun 16, 2019, at 15:00, Thomas Gleixner 
> mailto:t...@linutronix.de>> wrote:
> > 
> > > -GCC version 4.6.4 and newer provide instrinsics for the FSGSBASE
> > > +GCC version 6 and newer provide instrinsics for the FSGSBASE
> > > instructions. Clang supports them as well.
> > > 
> > >   === ===
> > > @@ -141,7 +141,7 @@ code and the compiler option -mfsgsbase has to be 
> > > added.
> > > Compiler support for FS/GS based addressing
> > > ---
> > > 
> > > -GCC version 6 and newer provide support for FS/GS based addressing via
> > > +GCC version 4.6.4 and newer provide support for FS/GS based addressing 
> > > via
> > > Named Address Spaces. GCC implements the following address space
> > > identifiers for x86:
> > > 
> > That's close to what I pushed out earlier into tip WIP.x86/cpu
> >  
> >  Please check against that version including the Clang part about address
> >  spaces close to the end.
> 
> 
> It is actually rebased on the tip branch (WIP.x86/cpu).

I have no idea what you mean with that. That patch you sent (see above) did
not apply against WIP.x86/cpu and claims exactly what I changed and pushed
out. Now you say it's the other way round:

> The point is the two GCC version indications are opposite right now:
>  - Intrinsics support begins from v4.6.4, not v6.
> - Address space identifiers support starts from v6, instead of v4.6.4

Is it really so hard to send proper patches like the below or if that's not
possible write up the facts so someone else can turn it into a proper patch
like the one below:

Thanks,

tglx

8<
diff --git a/Documentation/x86/x86_64/fsgs.rst 
b/Documentation/x86/x86_64/fsgs.rst
index d5588e00b939..380c0b5ccca2 100644
--- a/Documentation/x86/x86_64/fsgs.rst
+++ b/Documentation/x86/x86_64/fsgs.rst
@@ -125,7 +125,7 @@ FSGSBASE instructions enablement
 FSGSBASE instructions compiler support
 ^^
 
-GCC version 6 and newer provide instrinsics for the FSGSBASE
+GCC version 4.6.4 and newer provide instrinsics for the FSGSBASE
 instructions. Clang supports them as well.
 
   === ===
@@ -141,7 +141,7 @@ code and the compiler option -mfsgsbase has to be added.
 Compiler support for FS/GS based addressing
 ---
 
-GCC version 4.6.4 and newer provide support for FS/GS based addressing via
+GCC version 6 and newer provide support for FS/GS based addressing via
 Named Address Spaces. GCC implements the following address space
 identifiers for x86:
 



Gold Bars Purchase/Investment!!

2019-06-16 Thread Emmanuel Akwasi

Greetings

My name is Mr. Emmanuel Akwasi from Odikro Royal Family Upper East 
Region, Ghana. We are a group of local gold Miners and end sellers we 
are looking for a direct buyer or an agent who will help us look for 
buyer on Commission basis.


The Purity of our gold is 93% and 22Carats Plus and our price per kilo 
is affordable. We have 350 Kilos in Stock and we are looking for a buyer 
or an investor who will partner with us to invest in other of our 2 
Concessions. Kindly contact me for me details if you are interested to 
work with us. Hoping to hear from you.


Regards
Emmanuel


[PATCH V7] i2c: tegra: remove BUG, BUG_ON

2019-06-16 Thread Bitan Biswas
Remove BUG, BUG_ON as it makes system usable:
 - Remove redundant BUG_ON calls or replace with WARN_ON_ONCE
   as needed.
 - Remove BUG() and mask Rx interrupt similar as Tx
   for message fully sent case.
 - Add caller error handling and WARN_ON_ONCE check for non-zero
   rx_fifo_avail in tegra_i2c_empty_rx_fifo() after all processing.

Signed-off-by: Bitan Biswas 
---
 drivers/i2c/busses/i2c-tegra.c | 45 ++
 1 file changed, 37 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 4dfb4c1..b155b61 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -73,6 +73,7 @@
 #define I2C_ERR_NO_ACK BIT(0)
 #define I2C_ERR_ARBITRATION_LOST   BIT(1)
 #define I2C_ERR_UNKNOWN_INTERRUPT  BIT(2)
+#define I2C_ERR_RX_BUFFER_OVERFLOW BIT(3)
 
 #define PACKET_HEADER0_HEADER_SIZE_SHIFT   28
 #define PACKET_HEADER0_PACKET_ID_SHIFT 16
@@ -515,7 +516,11 @@ static int tegra_i2c_empty_rx_fifo(struct tegra_i2c_dev 
*i2c_dev)
 * prevent overwriting past the end of buf
 */
if (rx_fifo_avail > 0 && buf_remaining > 0) {
-   BUG_ON(buf_remaining > 3);
+   /*
+* buf_remaining > 3 check not needed as rx_fifo_avail == 0
+* when (words_to_transfer was > rx_fifo_avail) earlier
+* in this function.
+*/
val = i2c_readl(i2c_dev, I2C_RX_FIFO);
val = cpu_to_le32(val);
memcpy(buf, , buf_remaining);
@@ -523,7 +528,15 @@ static int tegra_i2c_empty_rx_fifo(struct tegra_i2c_dev 
*i2c_dev)
rx_fifo_avail--;
}
 
-   BUG_ON(rx_fifo_avail > 0 && buf_remaining > 0);
+   if ((!(i2c_dev->msg_buf_remaining)) &&
+   WARN_ON_ONCE(rx_fifo_avail))
+   return -EINVAL;
+
+   /*
+* buf_remaining > 0 at this point can only have rx_fifo_avail == 0
+* as this corresponds to (words_to_transfer was > rx_fifo_avail)
+* case earlier in this function.
+*/
i2c_dev->msg_buf_remaining = buf_remaining;
i2c_dev->msg_buf = buf;
 
@@ -581,7 +594,11 @@ static int tegra_i2c_fill_tx_fifo(struct tegra_i2c_dev 
*i2c_dev)
 * boundary and fault.
 */
if (tx_fifo_avail > 0 && buf_remaining > 0) {
-   BUG_ON(buf_remaining > 3);
+   /*
+* buf_remaining > 3 check not needed as tx_fifo_avail == 0
+* when (words_to_transfer was > tx_fifo_avail) earlier
+* in this function for non-zero words_to_transfer.
+*/
memcpy(, buf, buf_remaining);
val = le32_to_cpu(val);
 
@@ -847,10 +864,15 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
 
if (!i2c_dev->is_curr_dma_xfer) {
if (i2c_dev->msg_read && (status & I2C_INT_RX_FIFO_DATA_REQ)) {
-   if (i2c_dev->msg_buf_remaining)
-   tegra_i2c_empty_rx_fifo(i2c_dev);
-   else
-   BUG();
+   if (tegra_i2c_empty_rx_fifo(i2c_dev)) {
+   /*
+* Overflow error condition: message fully sent,
+* with no XFER_COMPLETE interrupt but hardware
+* asks to transfer more.
+*/
+   i2c_dev->msg_err |= I2C_ERR_RX_BUFFER_OVERFLOW;
+   goto err;
+   }
}
 
if (!i2c_dev->msg_read && (status & I2C_INT_TX_FIFO_DATA_REQ)) {
@@ -876,7 +898,14 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
if (status & I2C_INT_PACKET_XFER_COMPLETE) {
if (i2c_dev->is_curr_dma_xfer)
i2c_dev->msg_buf_remaining = 0;
-   BUG_ON(i2c_dev->msg_buf_remaining);
+   /*
+* Underflow error condition: XFER_COMPLETE before message
+* fully sent.
+*/
+   if (WARN_ON_ONCE(i2c_dev->msg_buf_remaining)) {
+   i2c_dev->msg_err |= I2C_ERR_UNKNOWN_INTERRUPT;
+   goto err;
+   }
complete(_dev->msg_complete);
}
goto done;
-- 
2.7.4



[PATCH v3 5/7] perf diff: Link same basic blocks among different data

2019-06-16 Thread Jin Yao
The target is to compare the performance difference (cycles
diff) for the same basic blocks in different data files.

The same basic block means same function, same start address
and same end address. This patch finds the same basic blocks
from different data files and link them together and resort
by the cycles diff.

 v3:
 ---
 The block stuffs are maintained by new structure 'block_hist',
 so this patch is update accordingly.

 v2:
 ---
 Since now the basic block hists is changed to per symbol,
 the patch only links the basic block hists for the same
 symbol in different data files.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-diff.c | 90 +++
 1 file changed, 90 insertions(+)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index c6ec84d..5f5a9a9 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -660,6 +660,85 @@ static int process_block_per_sym(struct hist_entry *he)
return 0;
 }
 
+static int block_pair_cmp(struct hist_entry *a, struct hist_entry *b)
+{
+   struct block_info *bi_a = a->block_info;
+   struct block_info *bi_b = b->block_info;
+   int cmp;
+
+   if (!bi_a->sym || !bi_b->sym)
+   return -1;
+
+   if (bi_a->sym->name && bi_b->sym->name) {
+   cmp = strcmp(bi_a->sym->name, bi_b->sym->name);
+   if ((!cmp) && (bi_a->start == bi_b->start) &&
+   (bi_a->end == bi_b->end)) {
+   return 0;
+   }
+   }
+
+   return -1;
+}
+
+static struct hist_entry *get_block_pair(struct hist_entry *he,
+struct hists *hists_pair)
+{
+   struct rb_root_cached *root = hists_pair->entries_in;
+   struct rb_node *next = rb_first_cached(root);
+   int cmp;
+
+   while (next != NULL) {
+   struct hist_entry *he_pair = rb_entry(next, struct hist_entry,
+ rb_node_in);
+
+   next = rb_next(_pair->rb_node_in);
+
+   cmp = block_pair_cmp(he_pair, he);
+   if (!cmp)
+   return he_pair;
+   }
+
+   return NULL;
+}
+
+static void compute_cycles_diff(struct hist_entry *he,
+   struct hist_entry *pair)
+{
+   pair->diff.computed = true;
+   if (pair->block_info->num && he->block_info->num) {
+   pair->diff.cycles =
+   pair->block_info->cycles_aggr / 
pair->block_info->num_aggr -
+   he->block_info->cycles_aggr / he->block_info->num_aggr;
+   }
+}
+
+static void block_hists_match(struct hists *hists_base,
+ struct hists *hists_pair)
+{
+   struct rb_root_cached *root = hists_base->entries_in;
+   struct rb_node *next = rb_first_cached(root);
+
+   while (next != NULL) {
+   struct hist_entry *he = rb_entry(next, struct hist_entry,
+rb_node_in);
+   struct hist_entry *pair = get_block_pair(he, hists_pair);
+
+   next = rb_next(>rb_node_in);
+
+   if (pair) {
+   hist_entry__add_pair(pair, he);
+   compute_cycles_diff(he, pair);
+   }
+   }
+}
+
+static int filter_cb(struct hist_entry *he, void *arg __maybe_unused)
+{
+   /* Skip the calculation of column length in output_resort */
+   he->filtered = true;
+   return 0;
+}
+
 static void hists__precompute(struct hists *hists)
 {
struct rb_root_cached *root;
@@ -672,6 +751,7 @@ static void hists__precompute(struct hists *hists)
 
next = rb_first_cached(root);
while (next != NULL) {
+   struct block_hist *bh, *pair_bh;
struct hist_entry *he, *pair;
struct data__file *d;
int i;
@@ -700,6 +780,16 @@ static void hists__precompute(struct hists *hists)
break;
case COMPUTE_CYCLES:
process_block_per_sym(pair);
+   bh = container_of(he, struct block_hist, he);
+   pair_bh = container_of(pair, struct block_hist,
+  he);
+
+   if (bh->valid && pair_bh->valid) {
+   block_hists_match(>block_hists,
+ 
_bh->block_hists);
+   
hists__output_resort_cb(_bh->block_hists,
+   NULL, 
filter_cb);
+   }
break;
default:
BUG_ON(1);
-- 
2.7.4



[PATCH v3 6/7] perf diff: Print the basic block cycles diff

2019-06-16 Thread Jin Yao
perf record -b ./div
perf record -b ./div

Following is the default perf diff output

 # perf diff

 # Event 'cycles'
 #
 # Baseline  Delta Abs  Shared Object Symbol
 #   .    
 #
 49.03% +0.30%  div   [.] main
 16.29% -0.20%  libc-2.23.so  [.] __random
 18.82% -0.07%  libc-2.23.so  [.] __random_r
  8.11% -0.04%  div   [.] compute_flag
  2.25% +0.01%  div   [.] rand@plt
  0.00% +0.01%  [kernel.vmlinux]  [k] task_tick_fair
  5.46% +0.01%  libc-2.23.so  [.] rand
  0.01% -0.01%  [kernel.vmlinux]  [k] native_irq_return_iret
  0.00% -0.00%  [kernel.vmlinux]  [k] interrupt_entry

This patch creates a new computation selection 'cycles'.

 # perf diff -c cycles

 # Event 'cycles'
 #
 # Baseline Block cycles diff [start:end]  Shared Object Symbol
 #       

 #
 49.03%-9 [ 4ef: 520]  div   [.] main
 49.03% 0 [ 4e8: 4ea]  div   [.] main
 49.03% 0 [ 4ef: 500]  div   [.] main
 49.03% 0 [ 4ef: 51c]  div   [.] main
 49.03% 0 [ 4ef: 535]  div   [.] main
 18.82% 0 [   3ac40:   3ac4d]  libc-2.23.so  [.] 
__random_r
 18.82% 0 [   3ac40:   3ac5c]  libc-2.23.so  [.] 
__random_r
 18.82% 0 [   3ac40:   3ac76]  libc-2.23.so  [.] 
__random_r
 18.82% 0 [   3ac40:   3ac88]  libc-2.23.so  [.] 
__random_r
 18.82% 0 [   3ac90:   3ac9c]  libc-2.23.so  [.] 
__random_r
 16.29%-8 [   3aac0:   3aac0]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3aac0:   3aad2]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3aae0:   3aae7]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3ab03:   3ab0f]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3ab14:   3ab1b]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3ab28:   3ab2e]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3ab4a:   3ab53]  libc-2.23.so  [.] 
__random
  8.11% 0 [ 640: 644]  div   [.] 
compute_flag
  8.11% 0 [ 649: 659]  div   [.] 
compute_flag
  5.46% 0 [   3af60:   3af60]  libc-2.23.so  [.] rand
  5.46% 0 [   3af60:   3af64]  libc-2.23.so  [.] rand
  2.25% 0 [ 490: 490]  div   [.] 
rand@plt
  0.01%26 [  c00a27:  c00a27]  [kernel.vmlinux]  [k] 
native_irq_return_iret
  0.00%  -157 [  2bf9f2:  2bfa63]  [kernel.vmlinux]  [k] 
update_blocked_averages
  0.00%   -56 [  2bf980:  2bf9d3]  [kernel.vmlinux]  [k] 
update_blocked_averages
  0.00%48 [  2bf934:  2bf942]  [kernel.vmlinux]  [k] 
update_blocked_averages
  0.00% 3 [  2bfb38:  2bfb67]  [kernel.vmlinux]  [k] 
update_blocked_averages
  0.00% 0 [  2bf968:  2bf97b]  [kernel.vmlinux]  [k] 
update_blocked_averages

"[start:end]" indicates the basic block range. The output is sorted
by "Baseline" and the basic blocks in the same function are sorted
by cycles diff.

 v3:
 ---
 Cast 'struct hist_entry' to 'struct block_hist' in hist_entry__block_fprintf.
 Use symbol_conf.report_block to check if executing hist_entry__block_fprintf.

 v2:
 ---
 Keep standard perf diff format and display the 'Baseline' and
 'Shared Object'.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-diff.c | 59 ---
 tools/perf/ui/stdio/hist.c| 27 
 tools/perf/util/hist.c| 18 +
 tools/perf/util/hist.h|  3 +++
 tools/perf/util/symbol_conf.h |  1 +
 5 files changed, 104 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 5f5a9a9..a56d941 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -46,6 +46,7 @@ enum {
PERF_HPP_DIFF__WEIGHTED_DIFF,
PERF_HPP_DIFF__FORMULA,
PERF_HPP_DIFF__DELTA_ABS,
+   PERF_HPP_DIFF__CYCLES,
 
PERF_HPP_DIFF__MAX_INDEX
 };
@@ -114,6 +115,7 @@ static int compute_2_hpp[COMPUTE_MAX] = {
[COMPUTE_DELTA_ABS] = PERF_HPP_DIFF__DELTA_ABS,
[COMPUTE_RATIO] = PERF_HPP_DIFF__RATIO,
[COMPUTE_WEIGHTED_DIFF] = PERF_HPP_DIFF__WEIGHTED_DIFF,
+   [COMPUTE_CYCLES]= PERF_HPP_DIFF__CYCLES,
 };
 
 #define MAX_COL_WIDTH 70
@@ -152,6 +154,10 @@ static struct header_column {
[PERF_HPP_DIFF__FORMULA] = {
  

[PATCH v3 7/7] perf diff: Documentation -c cycles option

2019-06-16 Thread Jin Yao
Documentation the new computation selection 'cycles'.

Signed-off-by: Jin Yao 
---
 tools/perf/Documentation/perf-diff.txt | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-diff.txt 
b/tools/perf/Documentation/perf-diff.txt
index facd91e..73903d2 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -90,9 +90,10 @@ OPTIONS
 
 -c::
 --compute::
-Differential computation selection - delta, ratio, wdiff, delta-abs
-(default is delta-abs).  Default can be changed using diff.compute
-config option.  See COMPARISON METHODS section for more info.
+Differential computation selection - delta, ratio, wdiff, cycles,
+delta-abs (default is delta-abs).  Default can be changed using
+diff.compute config option.  See COMPARISON METHODS section for
+more info.
 
 -p::
 --period::
@@ -280,6 +281,13 @@ If specified the 'Weighted diff' column is displayed with 
value 'd' computed as:
 - WEIGHT-A being the weight of the data file
 - WEIGHT-B being the weight of the baseline data file
 
+cycles
+~~
+If specified the 'Block cycles diff [start:end]' column is displayed.
+It displays the cycles difference of same program basic block amongst
+two perf.data. The program basic block is the code block between
+two branches in a function (indicated by [start:end]).
+
 SEE ALSO
 
 linkperf:perf-record[1], linkperf:perf-report[1]
-- 
2.7.4



[PATCH v3 3/7] perf diff: Check if all data files with branch stacks

2019-06-16 Thread Jin Yao
We will expand perf diff to support diff cycles of individual programs
blocks, so it requires all data files having branch stacks.

This patch checks HEADER_BRANCH_STACK in header, and only set the flag
has_br_stack when HEADER_BRANCH_STACK are set in all data files.

 v2:
 ---
 Move check_file_brstack() from __cmd_diff() to cmd_diff().
 Because later patch will check flag 'has_br_stack' before
 ui_init().

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-diff.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 6e79207..a7e0420 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -32,6 +32,7 @@ struct perf_diff {
struct perf_time_interval   *ptime_range;
int  range_size;
int  range_num;
+   bool has_br_stack;
 };
 
 /* Diff command specific HPP columns. */
@@ -873,6 +874,31 @@ static int parse_time_str(struct data__file *d, char 
*abstime_ostr,
return ret;
 }
 
+static int check_file_brstack(void)
+{
+   struct data__file *d;
+   bool has_br_stack;
+   int i;
+
+   data__for_each_file(i, d) {
+   d->session = perf_session__new(>data, false, );
+   if (!d->session) {
+   pr_err("Failed to open %s\n", d->data.path);
+   return -1;
+   }
+
+   has_br_stack = perf_header__has_feat(>session->header,
+HEADER_BRANCH_STACK);
+   perf_session__delete(d->session);
+   if (!has_br_stack)
+   return 0;
+   }
+
+   /* Set only all files having branch stacks */
+   pdiff.has_br_stack = true;
+   return 0;
+}
+
 static int __cmd_diff(void)
 {
struct data__file *d;
@@ -1487,6 +1513,9 @@ int cmd_diff(int argc, const char **argv)
if (data_init(argc, argv) < 0)
return -1;
 
+   if (check_file_brstack() < 0)
+   return -1;
+
if (ui_init() < 0)
return -1;
 
-- 
2.7.4



[PATCH v3 2/7] perf util: Add block_info in hist_entry

2019-06-16 Thread Jin Yao
The block_info contains the program basic block information, i.e,
contains the start address and the end address of this basic block and
how much cycles it takes. We need to compare, sort and even print out
the basic block by some orders, i.e. sort by cycles.

For this purpose, we add block_info field to hist_entry. In order not to
impact current interface, we creates a new function hists__add_entry_block.

Signed-off-by: Jin Yao 
---
 tools/perf/util/hist.c | 22 --
 tools/perf/util/hist.h |  6 ++
 tools/perf/util/sort.h |  1 +
 3 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index fb3271f..680ad93 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -574,6 +574,8 @@ static struct hist_entry *hists__findnew_entry(struct hists 
*hists,
 */
mem_info__zput(entry->mem_info);
 
+   block_info__zput(entry->block_info);
+
/* If the map of an existing hist_entry has
 * become out-of-date due to an exec() or
 * similar, update it.  Otherwise we will
@@ -645,6 +647,7 @@ __hists__add_entry(struct hists *hists,
   struct symbol *sym_parent,
   struct branch_info *bi,
   struct mem_info *mi,
+  struct block_info *block_info,
   struct perf_sample *sample,
   bool sample_self,
   struct hist_entry_ops *ops)
@@ -677,6 +680,7 @@ __hists__add_entry(struct hists *hists,
.hists  = hists,
.branch_info = bi,
.mem_info = mi,
+   .block_info = block_info,
.transaction = sample->transaction,
.raw_data = sample->raw_data,
.raw_size = sample->raw_size,
@@ -699,7 +703,7 @@ struct hist_entry *hists__add_entry(struct hists *hists,
struct perf_sample *sample,
bool sample_self)
 {
-   return __hists__add_entry(hists, al, sym_parent, bi, mi,
+   return __hists__add_entry(hists, al, sym_parent, bi, mi, NULL,
  sample, sample_self, NULL);
 }
 
@@ -712,10 +716,24 @@ struct hist_entry *hists__add_entry_ops(struct hists 
*hists,
struct perf_sample *sample,
bool sample_self)
 {
-   return __hists__add_entry(hists, al, sym_parent, bi, mi,
+   return __hists__add_entry(hists, al, sym_parent, bi, mi, NULL,
  sample, sample_self, ops);
 }
 
+struct hist_entry *hists__add_entry_block(struct hists *hists,
+ struct hist_entry_ops *ops,
+ struct addr_location *al,
+ struct block_info *block_info)
+{
+   struct hist_entry entry = {
+   .ops = ops,
+   .block_info = block_info,
+   .hists = hists,
+   }, *he = hists__findnew_entry(hists, , al, false);
+
+   return he;
+}
+
 static int
 iter_next_nop_entry(struct hist_entry_iter *iter __maybe_unused,
struct addr_location *al __maybe_unused)
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 76ff6c6..c8f7d66 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -16,6 +16,7 @@ struct addr_location;
 struct map_symbol;
 struct mem_info;
 struct branch_info;
+struct block_info;
 struct symbol;
 
 enum hist_filter {
@@ -149,6 +150,11 @@ struct hist_entry *hists__add_entry_ops(struct hists 
*hists,
struct perf_sample *sample,
bool sample_self);
 
+struct hist_entry *hists__add_entry_block(struct hists *hists,
+ struct hist_entry_ops *ops,
+ struct addr_location *al,
+ struct block_info *bi);
+
 int hist_entry_iter__add(struct hist_entry_iter *iter, struct addr_location 
*al,
 int max_stack_depth, void *arg);
 
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index ce376a7..43623fa 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -144,6 +144,7 @@ struct hist_entry {
longtime;
struct hists*hists;
struct mem_info *mem_info;
+   struct block_info   *block_info;
void*raw_data;
u32 raw_size;
int num_res;
-- 
2.7.4



[PATCH v3 4/7] perf diff: Use hists to manage basic blocks per symbol

2019-06-16 Thread Jin Yao
The hist__account_cycles() can account cycles per basic
block. The basic block information is saved in cycles_hist
structure.

This patch processes each symbol, get basic blocks from
cycles_hist and add the basic block entries to a new hists
(in 'struct block_hist'). Using a hists is because
we need to compare, sort and print the basic blocks later.

 v3:
 ---
 1. In v2, we put block stuffs in 'struct hist_entry', but
 it's not a good design. In v3, we create a new
 'struct block_hist' and cast the 'struct hist_entry' to
 'struct block_hist' in some places, which can avoid adding
 new stuffs in 'struct hist_entry'.

 2. abs() -> labs(), in block_cycles_diff_cmp().

 v2:
 ---
 v1 adds the basic block entries to per data-file hists
 but v2 adds the basic block entries to per symbol hists.
 That is to keep current perf-diff format. Will show the
 result in next patches.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-diff.c | 209 +-
 tools/perf/util/sort.h|  12 +++
 2 files changed, 218 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index a7e0420..c6ec84d 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -20,6 +20,7 @@
 #include "util/data.h"
 #include "util/config.h"
 #include "util/time-utils.h"
+#include "util/annotate.h"
 
 #include 
 #include 
@@ -87,11 +88,14 @@ static s64 compute_wdiff_w2;
 static const char  *cpu_list;
 static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
 
+static struct addr_location dummy_al;
+
 enum {
COMPUTE_DELTA,
COMPUTE_RATIO,
COMPUTE_WEIGHTED_DIFF,
COMPUTE_DELTA_ABS,
+   COMPUTE_CYCLES,
COMPUTE_MAX,
 };
 
@@ -100,6 +104,7 @@ const char *compute_names[COMPUTE_MAX] = {
[COMPUTE_DELTA_ABS] = "delta-abs",
[COMPUTE_RATIO] = "ratio",
[COMPUTE_WEIGHTED_DIFF] = "wdiff",
+   [COMPUTE_CYCLES] = "cycles",
 };
 
 static int compute = COMPUTE_DELTA_ABS;
@@ -234,6 +239,8 @@ static int setup_compute(const struct option *opt, const 
char *str,
for (i = 0; i < COMPUTE_MAX; i++)
if (!strcmp(cstr, compute_names[i])) {
*cp = i;
+   if (i == COMPUTE_CYCLES)
+   break;
return setup_compute_opt(option);
}
 
@@ -336,6 +343,31 @@ static int formula_fprintf(struct hist_entry *he, struct 
hist_entry *pair,
return -1;
 }
 
+static void *block_hist_zalloc(size_t size)
+{
+   struct block_hist *bh;
+
+   bh = zalloc(size + sizeof(*bh));
+   if (!bh)
+   return NULL;
+
+   return >he;
+}
+
+static void block_hist_free(void *he)
+{
+   struct block_hist *bh;
+
+   bh = container_of(he, struct block_hist, he);
+   hists__delete_entries(>block_hists);
+   free(bh);
+}
+
+struct hist_entry_ops block_hist_ops = {
+   .new= block_hist_zalloc,
+   .free   = block_hist_free,
+};
+
 static int diff__process_sample_event(struct perf_tool *tool,
  union perf_event *event,
  struct perf_sample *sample,
@@ -363,9 +395,22 @@ static int diff__process_sample_event(struct perf_tool 
*tool,
goto out_put;
}
 
-   if (!hists__add_entry(hists, , NULL, NULL, NULL, sample, true)) {
-   pr_warning("problem incrementing symbol period, skipping 
event\n");
-   goto out_put;
+   if (compute != COMPUTE_CYCLES) {
+   if (!hists__add_entry(hists, , NULL, NULL, NULL, sample,
+ true)) {
+   pr_warning("problem incrementing symbol period, "
+  "skipping event\n");
+   goto out_put;
+   }
+   } else {
+   if (!hists__add_entry_ops(hists, _hist_ops, , NULL,
+ NULL, NULL, sample, true)) {
+   pr_warning("problem incrementing symbol period, "
+  "skipping event\n");
+   goto out_put;
+   }
+
+   hist__account_cycles(sample->branch_stack, , sample, false);
}
 
/*
@@ -475,6 +520,146 @@ static void hists__baseline_only(struct hists *hists)
}
 }
 
+static int64_t block_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
+struct hist_entry *left, struct hist_entry *right)
+{
+   struct block_info *bi_l = left->block_info;
+   struct block_info *bi_r = right->block_info;
+   int cmp;
+
+   if (!bi_l->sym || !bi_r->sym) {
+   if (!bi_l->sym && !bi_r->sym)
+   return 0;
+   else if (!bi_l->sym)
+   return -1;
+   else
+   return 1;
+   }
+
+   if (bi_l->sym == bi_r->sym) {
+   if 

[PATCH v3 1/7] perf util: Create block_info structure

2019-06-16 Thread Jin Yao
perf diff currently can only diff symbols(functions). We should expand it
to diff cycles of individual programs blocks as reported by timed LBR.
This would allow to identify changes in specific code accurately.

We need a new structure to maintain the basic block information, such as,
symbol(function), start/end address of this block, cycles. This patch
creates this structure and with some ops.

Signed-off-by: Jin Yao 
---
 tools/perf/util/symbol.c | 22 ++
 tools/perf/util/symbol.h | 23 +++
 2 files changed, 45 insertions(+)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index f4540f8..4e0a7b3 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -2351,3 +2351,25 @@ struct mem_info *mem_info__new(void)
refcount_set(>refcnt, 1);
return mi;
 }
+
+struct block_info *block_info__get(struct block_info *bi)
+{
+   if (bi)
+   refcount_inc(>refcnt);
+   return bi;
+}
+
+void block_info__put(struct block_info *bi)
+{
+   if (bi && refcount_dec_and_test(>refcnt))
+   free(bi);
+}
+
+struct block_info *block_info__new(void)
+{
+   struct block_info *bi = zalloc(sizeof(*bi));
+
+   if (bi)
+   refcount_set(>refcnt, 1);
+   return bi;
+}
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 9a8fe01..12755b4 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -131,6 +131,17 @@ struct mem_info {
refcount_t  refcnt;
 };
 
+struct block_info {
+   struct symbol   *sym;
+   u64 start;
+   u64 end;
+   u64 cycles;
+   u64 cycles_aggr;
+   int num;
+   int num_aggr;
+   refcount_t  refcnt;
+};
+
 struct addr_location {
struct machine *machine;
struct thread *thread;
@@ -332,4 +343,16 @@ static inline void __mem_info__zput(struct mem_info **mi)
 
 #define mem_info__zput(mi) __mem_info__zput()
 
+struct block_info *block_info__new(void);
+struct block_info *block_info__get(struct block_info *bi);
+void   block_info__put(struct block_info *bi);
+
+static inline void __block_info__zput(struct block_info **bi)
+{
+   block_info__put(*bi);
+   *bi = NULL;
+}
+
+#define block_info__zput(bi) __block_info__zput()
+
 #endif /* __PERF_SYMBOL */
-- 
2.7.4



[PATCH v3 0/7] perf diff: diff cycles at basic block level

2019-06-16 Thread Jin Yao
In some cases small changes in hot loops can show big differences.
But it's difficult to identify these differences.

perf diff currently can only diff symbols (functions). We can also expand
it to diff cycles of individual programs blocks as reported by timed LBR.
This would allow to identify changes in specific code accurately.

With this patch set, for example,

 # perf record -b ./div
 # perf record -b ./div
 # perf diff -c cycles

 # Event 'cycles'
 #
 # Baseline Block cycles diff [start:end]  Shared Object Symbol
 #       

 #
 49.03%-9 [ 4ef: 520]  div   [.] main
 49.03% 0 [ 4e8: 4ea]  div   [.] main
 49.03% 0 [ 4ef: 500]  div   [.] main
 49.03% 0 [ 4ef: 51c]  div   [.] main
 49.03% 0 [ 4ef: 535]  div   [.] main
 18.82% 0 [   3ac40:   3ac4d]  libc-2.23.so  [.] 
__random_r
 18.82% 0 [   3ac40:   3ac5c]  libc-2.23.so  [.] 
__random_r
 18.82% 0 [   3ac40:   3ac76]  libc-2.23.so  [.] 
__random_r
 18.82% 0 [   3ac40:   3ac88]  libc-2.23.so  [.] 
__random_r
 18.82% 0 [   3ac90:   3ac9c]  libc-2.23.so  [.] 
__random_r
 16.29%-8 [   3aac0:   3aac0]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3aac0:   3aad2]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3aae0:   3aae7]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3ab03:   3ab0f]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3ab14:   3ab1b]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3ab28:   3ab2e]  libc-2.23.so  [.] 
__random
 16.29% 0 [   3ab4a:   3ab53]  libc-2.23.so  [.] 
__random
  8.11% 0 [ 640: 644]  div   [.] 
compute_flag
  8.11% 0 [ 649: 659]  div   [.] 
compute_flag
  5.46% 0 [   3af60:   3af60]  libc-2.23.so  [.] rand
  5.46% 0 [   3af60:   3af64]  libc-2.23.so  [.] rand
  2.25% 0 [ 490: 490]  div   [.] 
rand@plt
  0.01%26 [  c00a27:  c00a27]  [kernel.vmlinux]  [k] 
native_irq_return_iret
  0.00%  -157 [  2bf9f2:  2bfa63]  [kernel.vmlinux]  [k] 
update_blocked_averages
  0.00%   -56 [  2bf980:  2bf9d3]  [kernel.vmlinux]  [k] 
update_blocked_averages
  0.00%48 [  2bf934:  2bf942]  [kernel.vmlinux]  [k] 
update_blocked_averages
  0.00% 3 [  2bfb38:  2bfb67]  [kernel.vmlinux]  [k] 
update_blocked_averages

The 'cycles' is a new perf-diff computation selection, which enables
the displaying of cycles difference of same program basic block amongst
two perf.data. The program basic block is the code block between two
branches in a function.

 v3:
 ---
 In v3, the major change is to move most of block stuffs from
 'struct hist_entry' to new structure 'struct block_hist' and
 update the code accordingly. But we still have to keep the 
 block_info in 'struct hist_entry' since we need to compare by 
 block info when inserting new entry to hists.

 Others are minor changes, such as abs() -> labs(), removing
 duplicated ops and etc.

 Changed patches:
  perf diff: Use hists to manage basic blocks per symbol
  perf diff: Link same basic blocks among different data
  perf diff: Print the basic block cycles diff

 v2:
 ---
 Keep standard perf diff format.

 Following is the v1 output.

 # perf diff --basic-block

 # Cycles diff  Basic block (start:end)
 # ...  ...
 #
  -208  hrtimer_interrupt (30b9e0:30ba42)
  -157  update_blocked_averages (2bf9f2:2bfa63)
  -126  interrupt_entry (c00880:c0093a)
   -86  hrtimer_interrupt (30bb29:30bb32)
   -74  hrtimer_interrupt (30ba65:30bac4)
   -56  update_blocked_averages (2bf980:2bf9d3)
48  update_blocked_averages (2bf934:2bf942)
   -35  native_write_msr (267900:26790b)
26  native_irq_return_iret (c00a27:c00a27)
22  rcu_check_callbacks (2febb6:2febdc)
   -21  __hrtimer_run_queues (30b220:30b2a3)
19  pvclock_gtod_notify (14ba0:14c1b)
   -18  task_tick_fair (2c5d29:2c5d41)

Jin Yao (7):
  perf util: Create block_info structure
  perf util: Add block_info in hist_entry
  perf diff: Check if all data files with branch stacks
  perf diff: Use hists to manage basic blocks per symbol
  perf diff: Link same basic blocks among different data
  perf diff: Print the basic block cycles diff
  perf diff: Documentation -c cycles option

 

linux-next: build warnings after merge of the clockevents tree

2019-06-16 Thread Stephen Rothwell
Hi all,

After merging the clockevents tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:

In file included from arch/arm/kernel/vdso.c:30:
arch/arm/include/asm/arch_timer.h: In function 'arch_timer_set_evtstrm_feature':
arch/arm/include/asm/arch_timer.h:131:1: warning: no return statement in 
function returning non-void [-Wreturn-type]
 }
 ^
In file included from drivers/clocksource/arm_arch_timer.c:31:
arch/arm/include/asm/arch_timer.h: In function 'arch_timer_set_evtstrm_feature':
arch/arm/include/asm/arch_timer.h:131:1: warning: no return statement in 
function returning non-void [-Wreturn-type]
 }
 ^

Introduced by commit

  11e34eca5d0a ("clocksource/arm_arch_timer: Extract elf_hwcap use to 
arch-helper")

Look like a missed "return".

-- 
Cheers,
Stephen Rothwell


pgp4ZNXCyYA2a.pgp
Description: OpenPGP digital signature


[PATCH] nvdimm: remove prototypes for nonexistent functions

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

These functions don't exist, so remove the prototypes for them.

Signed-off-by: Alastair D'Silva 
---
 drivers/nvdimm/nd-core.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/nvdimm/nd-core.h b/drivers/nvdimm/nd-core.h
index 391e88de3a29..57d162dbefaa 100644
--- a/drivers/nvdimm/nd-core.h
+++ b/drivers/nvdimm/nd-core.h
@@ -136,11 +136,7 @@ void nd_region_disable(struct nvdimm_bus *nvdimm_bus, 
struct device *dev);
 int nvdimm_bus_create_ndctl(struct nvdimm_bus *nvdimm_bus);
 void nvdimm_bus_destroy_ndctl(struct nvdimm_bus *nvdimm_bus);
 void nd_synchronize(void);
-int nvdimm_bus_register_dimms(struct nvdimm_bus *nvdimm_bus);
-int nvdimm_bus_register_regions(struct nvdimm_bus *nvdimm_bus);
-int nvdimm_bus_init_interleave_sets(struct nvdimm_bus *nvdimm_bus);
 void __nd_device_register(struct device *dev);
-int nd_match_dimm(struct device *dev, void *data);
 struct nd_label_id;
 char *nd_label_gen_id(struct nd_label_id *label_id, u8 *uuid, u32 flags);
 bool nd_is_uuid_unique(struct device *dev, u8 *uuid);
-- 
2.21.0



Re: [PATCH v2 0/2] Add macb support for SiFive FU540-C000

2019-06-16 Thread Yash Shah
On Mon, Jun 17, 2019 at 9:49 AM Yash Shah  wrote:
>
> On FU540, the management IP block is tightly coupled with the Cadence
> MACB IP block. It manages many of the boundary signals from the MACB IP
> This patchset controls the tx_clk input signal to the MACB IP. It
> switches between the local TX clock (125MHz) and PHY TX clocks. This
> is necessary to toggle between 1Gb and 100/10Mb speeds.
>
> Future patches may add support for monitoring or controlling other IP
> boundary signals.
>
> This patchset is mostly based on work done by
> Wesley Terpstra 
>
> This patchset is based on Linux v5.2-rc1 and tested on HiFive Unleashed
> board with additional board related patches needed for testing can be
> found at dev/yashs/ethernet branch of:

Correction in branch name: dev/yashs/ethernet_v2

> https://github.com/yashshah7/riscv-linux.git
>
> Change History:
> V2:
> - Change compatible string from "cdns,fu540-macb" to "sifive,fu540-macb"
> - Add "MACB_SIFIVE_FU540" in Kconfig to support SiFive FU540 in macb
>   driver. This is needed because on FU540, the macb driver depends on
>   SiFive GPIO driver.
> - Avoid writing the result of a comparison to a register.
> - Fix the issue of probe fail on reloading the module reported by:
>   Andreas Schwab 
>
> Yash Shah (2):
>   macb: bindings doc: add sifive fu540-c000 binding
>   macb: Add support for SiFive FU540-C000
>
>  Documentation/devicetree/bindings/net/macb.txt |   3 +
>  drivers/net/ethernet/cadence/Kconfig   |   6 ++
>  drivers/net/ethernet/cadence/macb_main.c   | 129 
> +
>  3 files changed, 138 insertions(+)
>
> --
> 1.9.1
>


[PATCH] ocxl: Allow contexts to be attached with a NULL mm

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

If an OpenCAPI context is to be used directly by a kernel driver, there
may not be a suitable mm to use.

The patch makes the mm parameter to ocxl_context_attach optional.

Signed-off-by: Alastair D'Silva 
---
 drivers/misc/ocxl/context.c |  9 ++---
 drivers/misc/ocxl/link.c| 12 
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c
index bab9c9364184..994563a078eb 100644
--- a/drivers/misc/ocxl/context.c
+++ b/drivers/misc/ocxl/context.c
@@ -69,6 +69,7 @@ static void xsl_fault_error(void *data, u64 addr, u64 dsisr)
 int ocxl_context_attach(struct ocxl_context *ctx, u64 amr, struct mm_struct 
*mm)
 {
int rc;
+   unsigned long pidr = 0;
 
// Locks both status & tidr
mutex_lock(>status_mutex);
@@ -77,9 +78,11 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr, 
struct mm_struct *mm)
goto out;
}
 
-   rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid,
-   mm->context.id, ctx->tidr, amr, mm,
-   xsl_fault_error, ctx);
+   if (mm)
+   pidr = mm->context.id;
+
+   rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid, pidr, ctx->tidr,
+ amr, mm, xsl_fault_error, ctx);
if (rc)
goto out;
 
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index cce5b0d64505..43542f124807 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -523,7 +523,8 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 
pidr, u32 tidr,
pe->amr = cpu_to_be64(amr);
pe->software_state = cpu_to_be32(SPA_PE_VALID);
 
-   mm_context_add_copro(mm);
+   if (mm)
+   mm_context_add_copro(mm);
/*
 * Barrier is to make sure PE is visible in the SPA before it
 * is used by the device. It also helps with the global TLBI
@@ -546,7 +547,8 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 
pidr, u32 tidr,
 * have a reference on mm_users. Incrementing mm_count solves
 * the problem.
 */
-   mmgrab(mm);
+   if (mm)
+   mmgrab(mm);
trace_ocxl_context_add(current->pid, spa->spa_mem, pasid, pidr, tidr);
 unlock:
mutex_unlock(>spa_lock);
@@ -652,8 +654,10 @@ int ocxl_link_remove_pe(void *link_handle, int pasid)
if (!pe_data) {
WARN(1, "Couldn't find pe data when removing PE\n");
} else {
-   mm_context_remove_copro(pe_data->mm);
-   mmdrop(pe_data->mm);
+   if (pe_data->mm) {
+   mm_context_remove_copro(pe_data->mm);
+   mmdrop(pe_data->mm);
+   }
kfree_rcu(pe_data, rcu);
}
 unlock:
-- 
2.21.0



[PATCH 1/5] mm: Trigger bug on if a section is not found in __section_nr

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

If a memory section comes in where the physical address is greater than
that which is managed by the kernel, this function would not trigger the
bug and instead return a bogus section number.

This patch tracks whether the section was actually found, and triggers the
bug if not.

Signed-off-by: Alastair D'Silva 
---
 mm/sparse.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/mm/sparse.c b/mm/sparse.c
index fd13166949b5..104a79fedd00 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -105,20 +105,23 @@ static inline int sparse_index_init(unsigned long 
section_nr, int nid)
 int __section_nr(struct mem_section* ms)
 {
unsigned long root_nr;
-   struct mem_section *root = NULL;
+   struct mem_section *found = NULL;
+   struct mem_section *root;
 
for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) {
root = __nr_to_section(root_nr * SECTIONS_PER_ROOT);
if (!root)
continue;
 
-   if ((ms >= root) && (ms < (root + SECTIONS_PER_ROOT)))
-break;
+   if ((ms >= root) && (ms < (root + SECTIONS_PER_ROOT))) {
+   found = root;
+   break;
+   }
}
 
-   VM_BUG_ON(!root);
+   VM_BUG_ON(!found);
 
-   return (root_nr * SECTIONS_PER_ROOT) + (ms - root);
+   return (root_nr * SECTIONS_PER_ROOT) + (ms - found);
 }
 #else
 int __section_nr(struct mem_section* ms)
-- 
2.21.0



[PATCH 4/5] mm/hotplug: Avoid RCU stalls when removing large amounts of memory

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

When removing sufficiently large amounts of memory, we trigger RCU stall
detection. By periodically calling cond_resched(), we avoid bogus stall
warnings.

Signed-off-by: Alastair D'Silva 
---
 mm/memory_hotplug.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index e096c987d261..382b3a0c9333 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -578,6 +578,9 @@ void __remove_pages(struct zone *zone, unsigned long 
phys_start_pfn,
__remove_section(zone, __pfn_to_section(pfn), map_offset,
 altmap);
map_offset = 0;
+
+   if (!(i & 0x0FFF))
+   cond_resched();
}
 
set_zone_contiguous(zone);
-- 
2.21.0



[PATCH 0/5] mm: Cleanup & allow modules to hotplug memory

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

This series addresses some minor issues found when developing a
persistent memory driver.

As well as cleanup code, it also exports try_online_node so that
it can be called from driver modules that provide access to additional
physical memory.

Alastair D'Silva (5):
  mm: Trigger bug on if a section is not found in __section_nr
  mm: don't hide potentially null memmap pointer in
sparse_remove_one_section
  mm: Don't manually decrement num_poisoned_pages
  mm/hotplug: Avoid RCU stalls when removing large amounts of memory
  mm/hotplug: export try_online_node

 include/linux/memory_hotplug.h |  4 ++--
 kernel/cpu.c   |  2 +-
 mm/memory_hotplug.c| 23 ++-
 mm/sparse.c| 28 +---
 4 files changed, 38 insertions(+), 19 deletions(-)

-- 
2.21.0



[PATCH 5/5] mm/hotplug: export try_online_node

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

If an external driver module supplies physical memory and needs to expose
the memory on a specific NUMA node, it needs to be able to call
try_online_node to allocate the data structures for the node.

The previous assertion that all callers want to online the node, and that
the provided memory address starts at 0 is no longer true, so these
parameters must alse be exposed.

Signed-off-by: Alastair D'Silva 
---
 include/linux/memory_hotplug.h |  4 ++--
 kernel/cpu.c   |  2 +-
 mm/memory_hotplug.c| 20 +++-
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index ae892eef8b82..9272e7955541 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -109,7 +109,7 @@ extern void __online_page_set_limits(struct page *page);
 extern void __online_page_increment_counters(struct page *page);
 extern void __online_page_free(struct page *page);
 
-extern int try_online_node(int nid);
+int try_online_node(int nid, u64 start, bool set_node_online);
 
 extern int arch_add_memory(int nid, u64 start, u64 size,
struct mhp_restrictions *restrictions);
@@ -274,7 +274,7 @@ static inline void register_page_bootmem_info_node(struct 
pglist_data *pgdat)
 {
 }
 
-static inline int try_online_node(int nid)
+static inline int try_online_node(int nid, u64 start, bool set_node_online)
 {
return 0;
 }
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 077fde6fb953..ffe5f7239a5c 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1167,7 +1167,7 @@ static int do_cpu_up(unsigned int cpu, enum cpuhp_state 
target)
return -EINVAL;
}
 
-   err = try_online_node(cpu_to_node(cpu));
+   err = try_online_node(cpu_to_node(cpu), 0, true);
if (err)
return err;
 
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 382b3a0c9333..9c2784f89e60 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1004,7 +1004,7 @@ static void rollback_node_hotadd(int nid)
 
 
 /**
- * try_online_node - online a node if offlined
+ * __try_online_node - online a node if offlined
  * @nid: the node ID
  * @start: start addr of the node
  * @set_node_online: Whether we want to online the node
@@ -1039,18 +1039,28 @@ static int __try_online_node(int nid, u64 start, bool 
set_node_online)
return ret;
 }
 
-/*
- * Users of this function always want to online/register the node
+/**
+ * try_online_node - online a node if offlined
+ * @nid: the node ID
+ * @start: start addr of the node
+ * @set_node_online: Whether we want to online the node
+ * called by cpu_up() to online a node without onlined memory.
+ *
+ * Returns:
+ * 1 -> a new node has been allocated
+ * 0 -> the node is already online
+ * -ENOMEM -> the node could not be allocated
  */
-int try_online_node(int nid)
+int try_online_node(int nid, u64 start, bool set_node_online)
 {
int ret;
 
mem_hotplug_begin();
-   ret =  __try_online_node(nid, 0, true);
+   ret =  __try_online_node(nid, start, set_node_online);
mem_hotplug_done();
return ret;
 }
+EXPORT_SYMBOL_GPL(try_online_node);
 
 static int check_hotplug_memory_range(u64 start, u64 size)
 {
-- 
2.21.0



[PATCH 2/5] mm: don't hide potentially null memmap pointer in sparse_remove_one_section

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

By adding offset to memmap before passing it in to clear_hwpoisoned_pages,
is hides a potentially null memmap from the null check inside
clear_hwpoisoned_pages.

This patch passes the offset to clear_hwpoisoned_pages instead, allowing
memmap to successfully peform it's null check.

Signed-off-by: Alastair D'Silva 
---
 mm/sparse.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/mm/sparse.c b/mm/sparse.c
index 104a79fedd00..66a99da9b11b 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -746,12 +746,14 @@ int __meminit sparse_add_one_section(int nid, unsigned 
long start_pfn,
kfree(usemap);
__kfree_section_memmap(memmap, altmap);
}
+
return ret;
 }
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
 #ifdef CONFIG_MEMORY_FAILURE
-static void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
+static void clear_hwpoisoned_pages(struct page *memmap,
+   unsigned long map_offset, int nr_pages)
 {
int i;
 
@@ -767,7 +769,7 @@ static void clear_hwpoisoned_pages(struct page *memmap, int 
nr_pages)
if (atomic_long_read(_poisoned_pages) == 0)
return;
 
-   for (i = 0; i < nr_pages; i++) {
+   for (i = map_offset; i < nr_pages; i++) {
if (PageHWPoison([i])) {
atomic_long_sub(1, _poisoned_pages);
ClearPageHWPoison([i]);
@@ -775,7 +777,8 @@ static void clear_hwpoisoned_pages(struct page *memmap, int 
nr_pages)
}
 }
 #else
-static inline void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
+static inline void clear_hwpoisoned_pages(struct page *memmap,
+   unsigned long map_offset, int nr_pages)
 {
 }
 #endif
@@ -822,8 +825,7 @@ void sparse_remove_one_section(struct zone *zone, struct 
mem_section *ms,
ms->pageblock_flags = NULL;
}
 
-   clear_hwpoisoned_pages(memmap + map_offset,
-   PAGES_PER_SECTION - map_offset);
+   clear_hwpoisoned_pages(memmap, map_offset, PAGES_PER_SECTION);
free_section_usemap(memmap, usemap, altmap);
 }
 #endif /* CONFIG_MEMORY_HOTREMOVE */
-- 
2.21.0



[PATCH 3/5] mm: Don't manually decrement num_poisoned_pages

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

Use the function written to do it instead.

Signed-off-by: Alastair D'Silva 
---
 mm/sparse.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/sparse.c b/mm/sparse.c
index 66a99da9b11b..e2402937efe4 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "internal.h"
 #include 
@@ -771,7 +773,7 @@ static void clear_hwpoisoned_pages(struct page *memmap,
 
for (i = map_offset; i < nr_pages; i++) {
if (PageHWPoison([i])) {
-   atomic_long_sub(1, _poisoned_pages);
+   num_poisoned_pages_dec();
ClearPageHWPoison([i]);
}
}
-- 
2.21.0



Re: [PATCH v5 4/5] dt-bindings: mtd: Add bindings for TI's AM654 HyperBus memory controller

2019-06-16 Thread Vignesh Raghavendra
Hi,

On 10/06/19 9:55 PM, Sergei Shtylyov wrote:
> Hello!
> 
> On 06/09/2019 01:32 PM, Vignesh Raghavendra wrote:
> 
>> Add binding documentation for TI's HyperBus memory controller present on
>> AM654 SoC.
>>
>> Signed-off-by: Vignesh Raghavendra 
>> ---
>> v5:
>> Update binding example to show MMIO mux
>> Fix reg property for flash slave.
>>
>>  .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 51 +++
>>  MAINTAINERS   |  1 +
>>  2 files changed, 52 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt 
>> b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
>> new file mode 100644
>> index ..c2a2c2b42a92
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
>> @@ -0,0 +1,51 @@
>> +Bindings for HyperBus Memory Controller (HBMC) on TI's K3 family of SoCs
>> +
>> +Required properties:
>> +- compatible : "ti,am654-hbmc" for AM654 SoC
>> +- reg : Two entries:
>> +First entry pointed to the register space of HBMC controller
>> +Second entry pointing to the memory map region dedicated for
>> +MMIO access to attached flash devices
>> +- ranges : Address translation from offset within CS to allocated MMIO
>> +   space in SoC
>> +
>> +Optional properties:
>> +- mux-controls : phandle to the multiplexer that controls selection of
>> + HBMC vs OSPI inside Flash SubSystem. Default is OSPI,
>> + if property is absent.
>> + See Documentation/devicetree/bindings/mux/reg-mux.txt
>> + for mmio-mux binding details
>> +
>> +Example:
>> +
>> +fss: fss@4700 {
> 
>What's FSS?

Flash SubSystem (FSS). Will highlight that in mux control definition above

>Regardless of the answer, the node names should be generic, like 
> "memory-controller@".
> 
>> +compatible = "syscon", "simple-mfd";
> 
>If it's "sycon", the nme should probably be "system-controller".

FSS is like a subchip that has all Flash controllers like Octal SPI
controllers and HyperBus controller within it. Some of their controls
are in the below address range. So I think its more closer to
"system-controller"

> 
>> +reg = <0x0 0x4700 0x0 0x100>;
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +ranges;
>> +
>> +hbmc_mux: hbmc-mux {
> 
>So, just "multiplexor"?

Ok

> 
>> +compatible = "mmio-mux";
>> +#mux-control-cells = <1>;
>> +mux-reg-masks = <0x4 0x2>; /* 0: reg 0x4, bit 1 */
>> +};
>> +
>> +hbmc: hbmc@47034000 {
> 
>Should be named "memory-controller@47034000", according to the DT spec.

IMO, since HyperBus is a bus protocol and has a specification, I think
its should have a separate generic name like SPI etc.

I will change this to "hyperbus@47034000" to common name of spec.

> 
>> +compatible = "ti,am654-hbmc";
>> +reg = <0x0 0x47034000 0x0 0x100>,
>> +<0x5 0x 0x1 0x000>;
>> +power-domains = <_pds 55>;
>> +#address-cells = <2>;
>> +#size-cells = <1>;
>> +ranges = <0x0 0x0 0x5 0x 0x400>, /* CS0 - 
>> 64MB */
>> + <0x1 0x0 0x5 0x0400 0x400>; /* CS1 - 
>> 64MB */
>> +mux-controls = <_mux 0>;
>> +
>> +/* Slave flash node */
>> +flash@0,0 {
>> +compatible = "cypress,hyperflash", "cfi-flash";
>> +reg = <0x0 0x0 0x400>;
>> +};
>> +};
>> +};
> [...]
> 
> MBR, Sergei
> 

-- 
Regards
Vignesh


Re: [PATCH v4 0/5] THP aware uprobe

2019-06-16 Thread Song Liu
On Thu, Jun 13, 2019 at 10:58 AM Song Liu  wrote:
>
> This set makes uprobe aware of THPs.
>
> Currently, when uprobe is attached to text on THP, the page is split by
> FOLL_SPLIT. As a result, uprobe eliminates the performance benefit of THP.
>
> This set makes uprobe THP-aware. Instead of FOLL_SPLIT, we introduces
> FOLL_SPLIT_PMD, which only split PMD for uprobe. After all uprobes within
> the THP are removed, the PTEs are regrouped into huge PMD.
>
> Note that, with uprobes attached, the process runs with PTEs for the huge
> page. The performance benefit of THP is recovered _after_ all uprobes on
> the huge page are detached.
>
> This set (plus a few THP patches) is also available at
>
>https://github.com/liu-song-6/linux/tree/uprobe-thp
>
> Changes since v3:
> 1. Simplify FOLL_SPLIT_PMD case in follow_pmd_mask(), (Kirill A. Shutemov)
> 2. Fix try_collapse_huge_pmd() to match change in follow_pmd_mask().
>
> Changes since v2:
> 1. For FOLL_SPLIT_PMD, populated the page table in follow_pmd_mask().
> 2. Simplify logic in uprobe_write_opcode. (Oleg Nesterov)
> 3. Fix page refcount handling with FOLL_SPLIT_PMD.
> 4. Much more testing, together with THP on ext4 and btrfs (sending in
>separate set).
> 5. Rebased up on Linus's tree:
>commit 35110e38e6c5 ("Merge tag 'media/v5.2-2' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media")
>
> Changes since v1:
> 1. introduces FOLL_SPLIT_PMD, instead of modifying split_huge_pmd*();
> 2. reuse pages_identical() from ksm.c;
> 3. rewrite most of try_collapse_huge_pmd().
>

Hi Kirill and Oleg,

Does this version look good to you? If so, could you please reply with
your Acked-by and/or Reviewed-by?

Thanks,
Song


Re: [PATCH 2/2] pinctrl: qcom: Add SM8150 pinctrl driver

2019-06-16 Thread Bjorn Andersson
On Thu 13 Jun 22:30 PDT 2019, Vinod Koul wrote:

> From: Prasad Sodagudi 
> 
> Add initial pinctrl driver to support pin configuration with
> pinctrl framework for SM8150
> 
> Signed-off-by: Prasad Sodagudi 
> Signed-off-by: Isaac J. Manjarres 

I presume you did stuff to make it fit with my upstream tiling, mention
that here.

[..]
> diff --git a/drivers/pinctrl/qcom/pinctrl-sm8150.c 
> b/drivers/pinctrl/qcom/pinctrl-sm8150.c
[..]
> +static const struct pinctrl_pin_desc sm8150_pins[] = {
[..]
> + PINCTRL_PIN(178, "UFS_RESET"),

Please follow
https://lore.kernel.org/linux-arm-msm/20190606010249.3538-2-bjorn.anders...@linaro.org/
for ufs_reset.

> +};
[..]
> +enum sm8150_functions {
> + msm_mux_phase_flag8,

Please sort these alphabetically and please squash all the phase_flag*
into msm_mux_phase_flag.

> + msm_mux_phase_flag7,
> + msm_mux_emac_pps,
> + msm_mux_qup12,
> + msm_mux_qup16,
> + msm_mux_tsif1_clk,

Please squash all tsif1 into msm_mux_tsif1.

> + msm_mux_qup8,
> + msm_mux_qspi_cs,
> + msm_mux_tgu_ch3,
> + msm_mux_tsif1_en,
> + msm_mux_qspi0,
> + msm_mux_mdp_vsync0,
> + msm_mux_mdp_vsync1,
> + msm_mux_mdp_vsync2,
> + msm_mux_mdp_vsync3,
> + msm_mux_tgu_ch0,
> + msm_mux_tsif1_data,
> + msm_mux_qspi1,
> + msm_mux_sdc4_cmd,

Squash sdc4_cmd, sdc4_clk and sdc4{0,1,2,3} into msm_mux_sdc4.

> + msm_mux_phase_flag31,
> + msm_mux_tgu_ch1,
> + msm_mux_wlan1_adc1,
> + msm_mux_tsif1_sync,
> + msm_mux_qspi2,
> + msm_mux_sdc43,
> + msm_mux_vfr_1,
> + msm_mux_phase_flag30,
> + msm_mux_tgu_ch2,
> + msm_mux_wlan1_adc0,
> + msm_mux_tsif2_clk,

Please squash all tsif2

> + msm_mux_qup11,
> + msm_mux_qspi_clk,
> + msm_mux_sdc4_clk,
> + msm_mux_phase_flag27,
> + msm_mux_wlan2_adc1,
> + msm_mux_tsif2_en,
> + msm_mux_qspi3,
> + msm_mux_sdc42,
> + msm_mux_phase_flag26,
> + msm_mux_wlan2_adc0,
> + msm_mux_tsif2_data,
> + msm_mux_sdc41,
> + msm_mux_phase_flag25,
> + msm_mux_tsif2_sync,
> + msm_mux_sdc40,
> + msm_mux_tsif2_error,
> + msm_mux_phase_flag11,
> + msm_mux_sd_write,
> + msm_mux_tsif1_error,
> + msm_mux_qup7,
> + msm_mux_ddr_bist,
> + msm_mux_ddr_pxi3,
> + msm_mux_atest_usb13,
> + msm_mux_ddr_pxi1,
> + msm_mux_pll_bypassnl,
> + msm_mux_atest_usb12,
> + msm_mux_pll_reset,
> + msm_mux_pci_e1,
> + msm_mux_uim2_data,
> + msm_mux_uim2_clk,
> + msm_mux_uim2_reset,
> + msm_mux_uim2_present,

Please squash uim2.

> + msm_mux_uim1_data,
> + msm_mux_uim1_clk,
> + msm_mux_uim1_reset,
> + msm_mux_uim1_present,

Please squash uim1.

> + msm_mux_uim_batt,
> + msm_mux_usb2phy_ac,
> + msm_mux_aoss_cti,
> + msm_mux_qup1,
> + msm_mux_rgmii_txc,

Please squash all the rmiii_*

> + msm_mux_phase_flag20,
> + msm_mux_rgmii_rxc,
> + msm_mux_phase_flag19,
> + msm_mux_adsp_ext,
> + msm_mux_rgmii_rx,
> + msm_mux_phase_flag18,
> + msm_mux_rgmii_rxd0,
> + msm_mux_phase_flag17,
> + msm_mux_rgmii_rxd1,
> + msm_mux_phase_flag16,
> + msm_mux_qup5,
> + msm_mux_rgmii_rxd2,
> + msm_mux_phase_flag15,
> + msm_mux_rgmii_rxd3,
> + msm_mux_phase_flag14,
> + msm_mux_rgmii_tx,
> + msm_mux_phase_flag13,
> + msm_mux_rgmii_txd0,
> + msm_mux_phase_flag12,
> + msm_mux_atest_usb22,
> + msm_mux_emac_phy,
> + msm_mux_hs3_mi2s,
> + msm_mux_sec_mi2s,
> + msm_mux_qup2,
> + msm_mux_phase_flag9,
> + msm_mux_phase_flag4,
> + msm_mux_phase_flag21,
> + msm_mux_jitter_bist,
> + msm_mux_atest_usb21,
> + msm_mux_pll_bist,
> + msm_mux_atest_usb20,
> + msm_mux_atest_char0,
> + msm_mux_ter_mi2s,
> + msm_mux_gcc_gp1,
> + msm_mux_atest_char1,
> + msm_mux_atest_char2,
> + msm_mux_atest_char3,
> + msm_mux_qua_mi2s,
> + msm_mux_pri_mi2s,
> + msm_mux_qup3,
> + msm_mux_phase_flag29,
> + msm_mux_ddr_pxi0,
> + msm_mux_pri_mi2s_ws,
> + msm_mux_phase_flag28,
> + msm_mux_vsense_trigger,
> + msm_mux_atest_usb1,
> + msm_mux_atest_usb11,
> + msm_mux_ddr_pxi2,
> + msm_mux_dbg_out,
> + msm_mux_atest_usb10,
> + msm_mux_spkr_i2s,
> + msm_mux_audio_ref,
> + msm_mux_lpass_slimbus,
> + msm_mux_tsense_pwm1,
> + msm_mux_tsense_pwm2,
> + msm_mux_btfm_slimbus,
> + msm_mux_hs1_mi2s,
> + msm_mux_cri_trng0,
> + msm_mux_hs2_mi2s,
> + msm_mux_cri_trng1,
> + msm_mux_cri_trng,
> + msm_mux_sp_cmu,
> + msm_mux_prng_rosc,
> + msm_mux_qup0,
> + msm_mux_gpio,
> + msm_mux_qup6,
> + msm_mux_rgmii_txd1,
> + msm_mux_rgmii_txd2,
> + msm_mux_rgmii_txd3,
> + msm_mux_qup_l6,
> + msm_mux_rgmii_mdc,
> + msm_mux_qup_l5,
> + msm_mux_mdp_vsync,
> + msm_mux_edp_lcd,
> + msm_mux_qup10,
> + msm_mux_m_voc,
> + msm_mux_edp_hot,
> + 

[PATCH v2 2/2] macb: Add support for SiFive FU540-C000

2019-06-16 Thread Yash Shah
The management IP block is tightly coupled with the Cadence MACB IP
block on the FU540, and manages many of the boundary signals from the
MACB IP. This patch only controls the tx_clk input signal to the MACB
IP. Future patches may add support for monitoring or controlling other
IP boundary signals.

Signed-off-by: Yash Shah 
---
 drivers/net/ethernet/cadence/Kconfig |   6 ++
 drivers/net/ethernet/cadence/macb_main.c | 129 +++
 2 files changed, 135 insertions(+)

diff --git a/drivers/net/ethernet/cadence/Kconfig 
b/drivers/net/ethernet/cadence/Kconfig
index b998401..d478fae 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -48,4 +48,10 @@ config MACB_PCI
  To compile this driver as a module, choose M here: the module
  will be called macb_pci.
 
+config MACB_SIFIVE_FU540
+   bool "Cadence MACB/GEM support for SiFive FU540 SoC"
+   depends on MACB && GPIO_SIFIVE
+   help
+ Enable the Cadence MACB/GEM support for SiFive FU540 SoC.
+
 endif # NET_VENDOR_CADENCE
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index c049410..275b5e8 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -10,6 +10,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -40,6 +41,15 @@
 #include 
 #include "macb.h"
 
+/* This structure is only used for MACB on SiFive FU540 devices */
+struct sifive_fu540_macb_mgmt {
+   void __iomem *reg;
+   unsigned long rate;
+   struct clk_hw hw;
+};
+
+static struct sifive_fu540_macb_mgmt *mgmt;
+
 #define MACB_RX_BUFFER_SIZE128
 #define RX_BUFFER_MULTIPLE 64  /* bytes */
 
@@ -3903,6 +3913,116 @@ static int at91ether_init(struct platform_device *pdev)
return 0;
 }
 
+static unsigned long fu540_macb_tx_recalc_rate(struct clk_hw *hw,
+  unsigned long parent_rate)
+{
+   return mgmt->rate;
+}
+
+static long fu540_macb_tx_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   if (WARN_ON(rate < 250))
+   return 250;
+   else if (rate == 250)
+   return 250;
+   else if (WARN_ON(rate < 1375))
+   return 250;
+   else if (WARN_ON(rate < 2500))
+   return 2500;
+   else if (rate == 2500)
+   return 2500;
+   else if (WARN_ON(rate < 7500))
+   return 2500;
+   else if (WARN_ON(rate < 12500))
+   return 12500;
+   else if (rate == 12500)
+   return 12500;
+
+   WARN_ON(rate > 12500);
+
+   return 12500;
+}
+
+static int fu540_macb_tx_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+   rate = fu540_macb_tx_round_rate(hw, rate, _rate);
+   if (rate != 12500)
+   iowrite32(1, mgmt->reg);
+   else
+   iowrite32(0, mgmt->reg);
+   mgmt->rate = rate;
+
+   return 0;
+}
+
+static const struct clk_ops fu540_c000_ops = {
+   .recalc_rate = fu540_macb_tx_recalc_rate,
+   .round_rate = fu540_macb_tx_round_rate,
+   .set_rate = fu540_macb_tx_set_rate,
+};
+
+static int fu540_c000_clk_init(struct platform_device *pdev, struct clk **pclk,
+  struct clk **hclk, struct clk **tx_clk,
+  struct clk **rx_clk, struct clk **tsu_clk)
+{
+   struct clk_init_data init;
+   int err = 0;
+
+   err = macb_clk_init(pdev, pclk, hclk, tx_clk, rx_clk, tsu_clk);
+   if (err)
+   return err;
+
+   mgmt = devm_kzalloc(>dev, sizeof(*mgmt), GFP_KERNEL);
+   if (!mgmt)
+   return -ENOMEM;
+
+   init.name = "sifive-gemgxl-mgmt";
+   init.ops = _c000_ops;
+   init.flags = 0;
+   init.num_parents = 0;
+
+   mgmt->rate = 0;
+   mgmt->hw.init = 
+
+   *tx_clk = clk_register(NULL, >hw);
+   if (IS_ERR(*tx_clk))
+   return PTR_ERR(*tx_clk);
+
+   err = clk_prepare_enable(*tx_clk);
+   if (err)
+   dev_err(>dev, "failed to enable tx_clk (%u)\n", err);
+   else
+   dev_info(>dev, "Registered clk switch '%s'\n", init.name);
+
+   return 0;
+}
+
+static int fu540_c000_init(struct platform_device *pdev)
+{
+   struct resource *res;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!res)
+   return -ENODEV;
+
+   mgmt->reg = ioremap(res->start, resource_size(res));
+   if (!mgmt->reg)
+   return -ENOMEM;
+
+   return macb_init(pdev);
+}
+
+static const struct macb_config fu540_c000_config = {
+   .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO |
+   

[PATCH v2 1/2] macb: bindings doc: add sifive fu540-c000 binding

2019-06-16 Thread Yash Shah
Add the compatibility string documentation for SiFive FU540-C
interface.
On the FU540, this driver also needs to read and write registers in a
management IP block that monitors or drives boundary signals for the
GEMGXL IP block that are not directly mapped to GEMGXL registers.
Therefore, add additional range to "reg" property for SiFive GEMGXL
management IP registers.

Signed-off-by: Yash Shah 
---
 Documentation/devicetree/bindings/net/macb.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/macb.txt 
b/Documentation/devicetree/bindings/net/macb.txt
index 9c5e944..63c73fa 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -15,8 +15,11 @@ Required properties:
   Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 
SoCs.
   Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC.
   Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC.
+  Use "sifive,fu540-macb" for SiFive FU540-C000 SoC.
   Or the generic form: "cdns,emac".
 - reg: Address and length of the register set for the device
+   For "sifive,fu540-macb", second range is required to specify the
+   address and length of the registers for GEMGXL Management block.
 - interrupts: Should contain macb interrupt
 - phy-mode: See ethernet.txt file in the same directory.
 - clock-names: Tuple listing input clock names.
-- 
1.9.1



Re: [PATCH 1/2] dt-bindings: pinctrl: qcom: Add SM8150 pinctrl binding

2019-06-16 Thread Bjorn Andersson
On Thu 13 Jun 22:30 PDT 2019, Vinod Koul wrote:

> From: Prasad Sodagudi 
> 
> Add the binding for the TLMM pinctrl block found in the SM8150 platform.
> 
> Signed-off-by: Prasad Sodagudi 
> Signed-off-by: Isaac J. Manjarres 
> Signed-off-by: Vinod Koul 
> ---
>  .../bindings/pinctrl/qcom,sm8150-pinctrl  | 200 ++
>  1 file changed, 200 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl 
> b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl
> new file mode 100644
> index ..4f21d18b0be2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl
> @@ -0,0 +1,200 @@
> +Qualcomm SM8150 TLMM block
> +
> +This binding describes the Top Level Mode Multiplexer block found in the
> +QCS404 platform.
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: must be "qcom,sm8150-pinctrl"
> +
> +- reg:
> + Usage: required
> + Value type: 
> + Definition: the base address and size of the north, south , west

Extra space after south.

> + and east TLMM tiles.
> +
> +- reg-names:
> + Usage: required
> + Value type: 
> + Defintiion: names for the cells of reg, must contain "north", "south"
> + "west" and "east".
> +
> +- interrupts:
> + Usage: required
> + Value type: 
> + Definition: should specify the TLMM summary IRQ.
> +
> +- interrupt-controller:
> + Usage: required
> + Value type: 
> + Definition: identifies this node as an interrupt controller
> +
> +- #interrupt-cells:
> + Usage: required
> + Value type: 
> + Definition: must be 2. Specifying the pin number and flags, as defined
> + in 
> +
> +- gpio-controller:
> + Usage: required
> + Value type: 
> + Definition: identifies this node as a gpio controller
> +
> +- #gpio-cells:
> + Usage: required
> + Value type: 
> + Definition: must be 2. Specifying the pin number and flags, as defined
> + in 
> +

Please also document gpio-ranges and gpio-reserved-ranges.

> +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt 
> for
> +a general description of GPIO and interrupt bindings.
> +
> +Please refer to pinctrl-bindings.txt in this directory for details of the
> +common pinctrl bindings used by client devices, including the meaning of the
> +phrase "pin configuration node".
> +
> +The pin configuration nodes act as a container for an arbitrary number of
> +subnodes. Each of these subnodes represents some desired configuration for a
> +pin, a group, or a list of pins or groups. This configuration can include the
> +mux function to select on those pin(s)/group(s), and various pin 
> configuration
> +parameters, such as pull-up, drive strength, etc.
> +
> +
> +PIN CONFIGURATION NODES:
> +
> +The name of each subnode is not important; all subnodes should be enumerated
> +and processed purely based on their content.
> +
> +Each subnode only affects those parameters that are explicitly listed. In
> +other words, a subnode that lists a mux function but no pin configuration
> +parameters implies no information about any pin configuration parameters.
> +Similarly, a pin subnode that describes a pullup parameter implies no
> +information about e.g. the mux function.
> +
> +
> +The following generic properties as defined in pinctrl-bindings.txt are valid
> +to specify in a pin configuration subnode:
> +
> +- pins:
> + Usage: required
> + Value type: 
> + Definition: List of gpio pins affected by the properties specified in
> + this subnode.
> +
> + Valid pins are:
> +   gpio0-gpio149
> + Supports mux, bias and drive-strength
> +
> +   sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd,
> +   sdc2_data sdc1_rclk
> + Supports bias and drive-strength
> +
> +   ufs_reset
> + Supports bias and drive-strength
> +
> +- function:
> + Usage: required
> + Value type: 
> + Definition: Specify the alternative function to be configured for the
> + specified pins. Functions are only valid for gpio pins.
> + Valid values are:
> +
> + blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens,
> + bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8,
> + qdss_cti_trig_out_b, bimc_dte0, dac_calib1, 
> qdss_cti_trig_in_b,
> + dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, 
> blsp_uart10,
> + blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, 
> atest_usb12,
> + mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11,
> + atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, 
> 

[PATCH v2 0/2] Add macb support for SiFive FU540-C000

2019-06-16 Thread Yash Shah
On FU540, the management IP block is tightly coupled with the Cadence
MACB IP block. It manages many of the boundary signals from the MACB IP
This patchset controls the tx_clk input signal to the MACB IP. It
switches between the local TX clock (125MHz) and PHY TX clocks. This
is necessary to toggle between 1Gb and 100/10Mb speeds.

Future patches may add support for monitoring or controlling other IP
boundary signals.

This patchset is mostly based on work done by
Wesley Terpstra 

This patchset is based on Linux v5.2-rc1 and tested on HiFive Unleashed
board with additional board related patches needed for testing can be
found at dev/yashs/ethernet branch of:
https://github.com/yashshah7/riscv-linux.git

Change History:
V2:
- Change compatible string from "cdns,fu540-macb" to "sifive,fu540-macb"
- Add "MACB_SIFIVE_FU540" in Kconfig to support SiFive FU540 in macb
  driver. This is needed because on FU540, the macb driver depends on
  SiFive GPIO driver.
- Avoid writing the result of a comparison to a register.
- Fix the issue of probe fail on reloading the module reported by:
  Andreas Schwab 

Yash Shah (2):
  macb: bindings doc: add sifive fu540-c000 binding
  macb: Add support for SiFive FU540-C000

 Documentation/devicetree/bindings/net/macb.txt |   3 +
 drivers/net/ethernet/cadence/Kconfig   |   6 ++
 drivers/net/ethernet/cadence/macb_main.c   | 129 +
 3 files changed, 138 insertions(+)

-- 
1.9.1



Re: [PATCH] timers: Fix up get_target_base() to use old base properly

2019-06-16 Thread Peter Xu
On Mon, Jun 03, 2019 at 09:29:44PM +0800, Peter Xu wrote:
> get_target_base() in the timer code is not using the "base" parameter
> at all.  My gut feeling is that instead of removing that extra
> parameter, what we really want to do is "return the old base if it
> does not suite for a new one".

Ping?

Note that as reference hrtimer is using the same logic as in this
patch. 

> 
> CC: Thomas Gleixner 
> CC: John Stultz 
> CC: Stephen Boyd 
> CC: Luiz Capitulino 
> CC: Marcelo Tosatti 
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Peter Xu 
> ---
>  kernel/time/timer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index 343c7ba33b1c..6ff6ffd2c719 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -868,7 +868,7 @@ get_target_base(struct timer_base *base, unsigned tflags)
>   !(tflags & TIMER_PINNED))
>   return get_timer_cpu_base(tflags, get_nohz_timer_target());
>  #endif
> - return get_timer_this_cpu_base(tflags);
> + return base;
>  }
>  
>  static inline void forward_timer_base(struct timer_base *base)
> -- 
> 2.17.1
> 

Regards,

-- 
Peter Xu


Re: [RFC v2 02/11] OPP: Make dev_pm_opp_set_rate() with freq=0 as valid

2019-06-16 Thread Rajendra Nayak




On 6/14/2019 12:02 PM, Viresh Kumar wrote:

On 20-03-19, 15:19, Rajendra Nayak wrote:

For devices with performance state, we use dev_pm_opp_set_rate()
to set the appropriate clk rate and the performance state.
We do need a way to *remove* the performance state vote when
we idle the device and turn the clocks off. Use dev_pm_opp_set_rate()
with freq=0 to achieve this.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Stephen Boyd 
---
  drivers/opp/core.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)


What about this instead ?


yes, this works, thanks for updating the patch.



diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 2fe96c2363a3..9accf8bb6afc 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -711,7 +711,7 @@ static int _set_required_opps(struct device *dev,
  
 /* Single genpd case */

 if (!genpd_virt_devs) {
-   pstate = opp->required_opps[0]->pstate;
+   pstate = likely(opp) ? opp->required_opps[0]->pstate : 0;
 ret = dev_pm_genpd_set_performance_state(dev, pstate);
 if (ret) {
 dev_err(dev, "Failed to set performance state of %s: %d 
(%d)\n",
@@ -729,7 +729,7 @@ static int _set_required_opps(struct device *dev,
 mutex_lock(_table->genpd_virt_dev_lock);
  
 for (i = 0; i < opp_table->required_opp_count; i++) {

-   pstate = opp->required_opps[i]->pstate;
+   pstate = likely(opp) ? opp->required_opps[i]->pstate : 0;
  
 if (!genpd_virt_devs[i])

 continue;
@@ -770,14 +770,13 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
  
 if (unlikely(!target_freq)) {

 if (opp_table->required_opp_tables) {
-   /* drop the performance state vote */
-   dev_pm_genpd_set_performance_state(dev, 0);
-   return 0;
+   ret = _set_required_opps(dev, opp_table, NULL);
 } else {
-   dev_err(dev, "%s: Invalid target frequency %lu\n", 
__func__,
-   target_freq);
-   return -EINVAL;
+   dev_err(dev, "target frequency can't be 0\n");
+   ret = -EINVAL;
 }
+
+   goto put_opp_table;
 }
  
 clk = opp_table->clk;




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


Re: [PATCH v3] kasan: add memory corruption identification for software tag-based mode

2019-06-16 Thread Walter Wu
On Fri, 2019-06-14 at 10:32 +0800, Walter Wu wrote:
> On Fri, 2019-06-14 at 01:46 +0800, Walter Wu wrote:
> > On Thu, 2019-06-13 at 15:27 +0300, Andrey Ryabinin wrote:
> > > 
> > > On 6/13/19 11:13 AM, Walter Wu wrote:
> > > > This patch adds memory corruption identification at bug report for
> > > > software tag-based mode, the report show whether it is "use-after-free"
> > > > or "out-of-bound" error instead of "invalid-access" error.This will make
> > > > it easier for programmers to see the memory corruption problem.
> > > > 
> > > > Now we extend the quarantine to support both generic and tag-based 
> > > > kasan.
> > > > For tag-based kasan, the quarantine stores only freed object information
> > > > to check if an object is freed recently. When tag-based kasan reports an
> > > > error, we can check if the tagged addr is in the quarantine and make a
> > > > good guess if the object is more like "use-after-free" or 
> > > > "out-of-bound".
> > > > 
> > > 
> > > 
> > > We already have all the information and don't need the quarantine to make 
> > > such guess.
> > > Basically if shadow of the first byte of object has the same tag as tag 
> > > in pointer than it's out-of-bounds,
> > > otherwise it's use-after-free.
> > > 
> > > In pseudo-code it's something like this:
> > > 
> > > u8 object_tag = *(u8 *)kasan_mem_to_shadow(nearest_object(cacche, page, 
> > > access_addr));
> > > 
> > > if (access_addr_tag == object_tag && object_tag != KASAN_TAG_INVALID)
> > >   // out-of-bounds
> > > else
> > >   // use-after-free
> > 
> > Thanks your explanation.
> > I see, we can use it to decide corruption type.
> > But some use-after-free issues, it may not have accurate free-backtrace.
> > Unfortunately in that situation, free-backtrace is the most important.
> > please see below example
> > 
> > In generic KASAN, it gets accurate free-backrace(ptr1).
> > In tag-based KASAN, it gets wrong free-backtrace(ptr2). It will make
> > programmer misjudge, so they may not believe tag-based KASAN.
> > So We provide this patch, we hope tag-based KASAN bug report is the same
> > accurate with generic KASAN.
> > 
> > ---
> > ptr1 = kmalloc(size, GFP_KERNEL);
> > ptr1_free(ptr1);
> > 
> > ptr2 = kmalloc(size, GFP_KERNEL);
> > ptr2_free(ptr2);
> > 
> > ptr1[size] = 'x';  //corruption here
> > 
> > 
> > static noinline void ptr1_free(char* ptr)
> > {
> > kfree(ptr);
> > }
> > static noinline void ptr2_free(char* ptr)
> > {
> > kfree(ptr);
> > }
> > ---
> > 
> We think of another question about deciding by that shadow of the first
> byte.
> In tag-based KASAN, it is immediately released after calling kfree(), so
> the slub is easy to be used by another pointer, then it will change
> shadow memory to the tag of new pointer, it will not be the
> KASAN_TAG_INVALID, so there are many false negative cases, especially in
> small size allocation.
> 
> Our patch is to solve those problems. so please consider it, thanks.
> 
Hi, Andrey and Dmitry,

I am sorry to bother you.
Would you tell me what you think about this patch?
We want to use tag-based KASAN, so we hope its bug report is clear and
correct as generic KASAN.

Thanks your review.
Walter



Re: [PATCH v2 2/5] x86: hv: hv_init.c: Add functions to allocate/deallocate page for Hyper-V

2019-06-16 Thread Maya Nakamura
On Wed, Jun 12, 2019 at 12:36:47PM +0200, Vitaly Kuznetsov wrote:
> Maya Nakamura  writes:
> 
> > Introduce two new functions, hv_alloc_hyperv_page() and
> > hv_free_hyperv_page(), to allocate/deallocate memory with the size and
> > alignment that Hyper-V expects as a page. Although currently they are
> > not used, they are ready to be used to allocate/deallocate memory on x86
> > when their ARM64 counterparts are implemented, keeping symmetry between
> > architectures with potentially different guest page sizes.
> >
> > Signed-off-by: Maya Nakamura 
> > ---
> >  arch/x86/hyperv/hv_init.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> > index e4ba467a9fc6..84baf0e9a2d4 100644
> > --- a/arch/x86/hyperv/hv_init.c
> > +++ b/arch/x86/hyperv/hv_init.c
> > @@ -98,6 +98,20 @@ EXPORT_SYMBOL_GPL(hyperv_pcpu_input_arg);
> >  u32 hv_max_vp_index;
> >  EXPORT_SYMBOL_GPL(hv_max_vp_index);
> >  
> > +void *hv_alloc_hyperv_page(void)
> > +{
> > +   BUILD_BUG_ON(!(PAGE_SIZE == HV_HYP_PAGE_SIZE));
> 
> (nit)
> 
> PAGE_SIZE != HV_HYP_PAGE_SIZE ?
> 
> > +
> > +   return (void *)__get_free_page(GFP_KERNEL);
> > +}
> > +EXPORT_SYMBOL_GPL(hv_alloc_hyperv_page);
> > +
> > +void hv_free_hyperv_page(unsigned long addr)
> > +{
> > +   free_page(addr);
> > +}
> > +EXPORT_SYMBOL_GPL(hv_free_hyperv_page);
> > +
> >  static int hv_cpu_init(unsigned int cpu)
> >  {
> > u64 msr_vp_index;
> 
> Reviewed-by: Vitaly Kuznetsov 
> 
> -- 
> Vitaly

Agreed. I will resubmit the patch set with this correction.


[PATCH v5] ASoC: max98090: remove 24-bit format support if RJ is 0

2019-06-16 Thread Yu-Hsuan Hsu
The supported formats are S16_LE and S24_LE now. However, S24_LE is
not supported when TDM is 0 and it is not in the right justified mode.
We should remove 24-bit format in that situation to avoid triggering
error.

Signed-off-by: Yu-Hsuan Hsu 
---
The datasheet said that when TDM=0 and RJ=0, S24_LE is not supported.
So I added a constraint to check TDM. Please take a look. Thanks!

 sound/soc/codecs/max98090.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index 7619ea31ab50..d118cf80b6b2 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -1909,6 +1909,26 @@ static int max98090_configure_dmic(struct max98090_priv 
*max98090,
return 0;
 }
 
+static int max98090_dai_startup(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct snd_soc_component *component = dai->component;
+   struct max98090_priv *max98090 = 
snd_soc_component_get_drvdata(component);
+   unsigned int fmt = max98090->dai_fmt;
+
+   /*
+* When TDM = 0, remove 24-bit format support if it is not in right
+* justified mode.
+*/
+   if (!max98090->tdm_slots &&
+   (fmt & SND_SOC_DAIFMT_FORMAT_MASK) != SND_SOC_DAIFMT_RIGHT_J) {
+   substream->runtime->hw.formats = SNDRV_PCM_FMTBIT_S16_LE;
+   snd_pcm_hw_constraint_msbits(substream->runtime, 0, 16, 16);
+   }
+
+   return 0;
+}
+
 static int max98090_dai_hw_params(struct snd_pcm_substream *substream,
   struct snd_pcm_hw_params *params,
   struct snd_soc_dai *dai)
@@ -2316,6 +2336,7 @@ EXPORT_SYMBOL_GPL(max98090_mic_detect);
 #define MAX98090_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE)
 
 static const struct snd_soc_dai_ops max98090_dai_ops = {
+   .startup = max98090_dai_startup,
.set_sysclk = max98090_dai_set_sysclk,
.set_fmt = max98090_dai_set_fmt,
.set_tdm_slot = max98090_set_tdm_slot,
-- 
2.22.0.410.gd8fdbe21b5-goog



Re: linux-next: manual merge of the mlx5-next tree with Linus' tree

2019-06-16 Thread Leon Romanovsky
On Mon, Jun 17, 2019 at 12:19:59PM +1000, Stephen Rothwell wrote:
> Hi Leon,
>
> Today's linux-next merge of the mlx5-next tree got a conflict in:
>
>   include/linux/mlx5/eswitch.h
>
> between commit:
>
>   02f3afd97556 ("net/mlx5: E-Switch, Correct type to u16 for vport_num and 
> int for vport_index")
>
> from Linus' tree and commit:
>
>   82b11f071936 ("net/mlx5: Expose eswitch encap mode")
>
> from the mlx5-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>

Thanks


Re: [RFC v2 01/11] OPP: Don't overwrite rounded clk rate

2019-06-16 Thread Viresh Kumar
On 14-06-19, 10:57, Viresh Kumar wrote:
> Hmm, so this patch won't break anything and I am inclined to apply it again :)
> 
> Does anyone see any other issues with it, which I might be missing ?

I have updated the commit log a bit more to clarify on things, please let me
know if it looks okay.

opp: Don't overwrite rounded clk rate

The OPP table normally contains 'fmax' values corresponding to the
voltage or performance levels of each OPP, but we don't necessarily want
all the devices to run at fmax all the time. Running at fmax makes sense
for devices like CPU/GPU, which have a finite amount of work to do and
since a specific amount of energy is consumed at an OPP, its better to
run at the highest possible frequency for that voltage value.

On the other hand, we have IO devices which need to run at specific
frequencies only for their proper functioning, instead of maximum
possible frequency.

The OPP core currently roundup to the next possible OPP for a frequency
and select the fmax value. To support the IO devices by the OPP core,
lets do the roundup to fetch the voltage or performance state values,
but not use the OPP frequency value. Rather use the value returned by
clk_round_rate().

The current user, cpufreq, of dev_pm_opp_set_rate() already does the
rounding to the next OPP before calling this routine and it won't
have any side affects because of this change.

Signed-off-by: Stephen Boyd 
Signed-off-by: Rajendra Nayak 
[ Viresh: Massaged changelog and use temp_opp variable instead ]
Signed-off-by: Viresh Kumar 


-- 
viresh


Re: [PATCH 6/6] drm/msm/gpu: add ocmem init/cleanup functions

2019-06-16 Thread Bjorn Andersson
On Sun 16 Jun 17:18 PDT 2019, Brian Masney wrote:

> Hi Bjorn,
> 
> On Sun, Jun 16, 2019 at 11:06:33AM -0700, Bjorn Andersson wrote:
> > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> > > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > index 6f7f4114afcf..e0a9409c8a32 100644
> > > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > > @@ -29,6 +29,10 @@
> > >  #include "msm_gem.h"
> > >  #include "msm_mmu.h"
> > >  
> > > +#ifdef CONFIG_QCOM_OCMEM
> > > +#  include 
> > > +#endif
> > 
> > This file exists (after the previous patch), so no need to make its
> > inclusion conditional.
> > 
> > > +
> > >  static bool zap_available = true;
> > >  
> > >  static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname,
> > > @@ -897,6 +901,43 @@ static int adreno_get_pwrlevels(struct device *dev,
> > >   return 0;
> > >  }
> > >  
> > > +int adreno_gpu_ocmem_init(struct device *dev, struct adreno_gpu 
> > > *adreno_gpu,
> > > +   struct adreno_ocmem *adreno_ocmem)
> > > +{
> > > +#ifdef CONFIG_QCOM_OCMEM
> > 
> > No need to make this conditional.
> 
> I have these #ifdefs for the a5xx and a6xx GPUs that don't have ocmem
> in the SoC. Without the #ifdefs, those systems would need to have the
> ocmem driver in their kernel.
> 

In order to provide the means for compiling a kernel for a[56]xx without
having to compile ocmem you should move these #ifdef to the ocmem
header file and provide static inline dummies for the case when it's
not.

(and use #if IS_ENABLED(CONFIG_FOO))

Don't forget to add
depends on QCOM_OCMEM || QCOM_OCMEM=n

to the DRM_MSM config option, to allow the driver pair to be selected in
all possible ways.

> Thanks for the quick review on the patch set!
> 

Regards,
Bjorn


Re: [PATCH 1/3] x86/resctrl: Get max rmid and occupancy scale directly from CPUID instead of cpuinfo_x86

2019-06-16 Thread Fenghua Yu
On Sun, Jun 16, 2019 at 07:52:33PM +0200, Borislav Petkov wrote:
> On Sun, Jun 16, 2019 at 10:14:08AM -0700, Fenghua Yu wrote:
> > @@ -617,13 +617,20 @@ static void l3_mon_evt_init(struct rdt_resource *r)
> > list_add_tail(_local_event.list, >evt_list);
> >  }
> >  
> > -int rdt_get_mon_l3_config(struct rdt_resource *r)
> > +int __init rdt_get_mon_l3_config(struct rdt_resource *r)
> >  {
> > unsigned int cl_size = boot_cpu_data.x86_cache_size;
> > +   u32 eax, ebx, ecx, edx;
> > int ret;
> >  
> > -   r->mon_scale = boot_cpu_data.x86_cache_occ_scale;
> > -   r->num_rmid = boot_cpu_data.x86_cache_max_rmid + 1;
> > +   /*
> > +* At this point, CQM LLC and one of L3 occupancy, MBM total, and
> > +* MBM local monitoring features must be supported. So sub-leaf
> > +* (EAX=0xf, ECX=1) contains needed information for this resource.
> > +*/
> > +   cpuid_count(0xf, 1, , , , );
> > +   r->num_rmid = ecx + 1;
> > +   r->mon_scale = ebx;
> >  
> > /*
> >  * A reasonable upper limit on the max threshold is the number
> 
> This is simpler than that:
> 
> https://lkml.kernel.org/r/20190614174959.gf198...@romley-ivt3.sc.intel.com
> 
> Why?

After think this code again, ecx and ebx in sub-leaf CPUID.f.1 actually
contains the number of rmid and monitoring scale. The two variables are
always valid if any of L3 occupancy, MBM total, and MBM local monitoring
features is supported. So there is no need to check the features to get
the info.

But seems this patch is not needed according to Thomas?

Should I do the following changes in the next version of patch set?

1. Remove patch #1
2. Change patch #2 to the patch in https://lkml.org/lkml/2019/6/16/274
3. Keep patch #3

Please advice.

Thanks.

-Fenghua




linux-next: manual merge of the imx-drm tree with the v4l-vdb tree

2019-06-16 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the imx-drm tree got a conflict in:

  drivers/staging/media/imx/imx-ic-prpencvf.c

between commits:

  6d01b7ff5233 ("media: staging/imx: Switch to sync registration for IPU 
subdevs")
  34ff38745b16 ("media: staging/imx: Pass device to alloc/free_dma_buf")

from the v4l-vdb tree and commit:

  f208b26e61df ("gpu: ipu-v3: ipu-ic: Fully describe colorspace conversions")

from the imx-drm tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/media/imx/imx-ic-prpencvf.c
index 82bba68c554e,f2fe3c11c70e..
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@@ -460,7 -465,18 +461,18 @@@ static int prp_setup_rotation(struct pr
incc = priv->cc[PRPENCVF_SINK_PAD];
outcc = vdev->cc;
  
+   ret = ipu_ic_calc_csc(,
+ infmt->ycbcr_enc, infmt->quantization,
+ incc->cs,
+ outfmt->ycbcr_enc, outfmt->quantization,
+ outcc->cs);
+   if (ret) {
+   v4l2_err(_priv->sd, "ipu_ic_calc_csc failed, %d\n",
+ret);
+   return ret;
+   }
+ 
 -  ret = imx_media_alloc_dma_buf(priv->md, >rot_buf[0],
 +  ret = imx_media_alloc_dma_buf(ic_priv->ipu_dev, >rot_buf[0],
  outfmt->sizeimage);
if (ret) {
v4l2_err(_priv->sd, "failed to alloc rot_buf[0], %d\n", ret);


pgp9RhyBHzsa6.pgp
Description: OpenPGP digital signature


Re: [PATCH] MAINTAINERS: fpga: hand off maintainership to Moritz

2019-06-16 Thread Moritz Fischer
Hi Alan,

On Sun, Jun 16, 2019 at 10:11:13PM -0500, Alan Tull wrote:
> I'm moving on to a new position and stepping down as FPGA subsystem
> maintainer.  Moritz has graciously agreed to take over the
> maintainership.

Thanks a lot for all the work you put into this, it was good fun working
with you, and I hope you'll be back someday, or at least you'll keep
working on the Linux Kernel in other areas.

All: It'll take me a bit to get everything sorted, since I just switched
jobs and am still getting set up there, too, so please be patient :)

> Signed-off-by: Alan Tull 
Acked-by: Moritz Fischer 
> ---
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 80e2bfa049d7..448730982545 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6266,7 +6266,6 @@ F:  include/linux/ipmi-fru.h
>  K:   fmc_d.*register
>  
>  FPGA MANAGER FRAMEWORK
> -M:   Alan Tull 
>  M:   Moritz Fischer 
>  L:   linux-f...@vger.kernel.org
>  S:   Maintained
> -- 
> 2.21.0
> 

Cheers,
Moritz


Re: [PATCH RESEND v3 2/3] KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

2019-06-16 Thread Xiaoyao Li




On 6/16/2019 5:55 PM, Tao Xu wrote:

UMWAIT and TPAUSE instructions use IA32_UMWAIT_CONTROL at MSR index E1H
to determines the maximum time in TSC-quanta that the processor can reside
in either C0.1 or C0.2.

This patch emulates MSR IA32_UMWAIT_CONTROL in guest and differentiate
IA32_UMWAIT_CONTROL between host and guest. The variable
mwait_control_cached in arch/x86/power/umwait.c caches the MSR value, so
this patch uses it to avoid frequently rdmsr of IA32_UMWAIT_CONTROL.

Co-developed-by: Jingqi Liu 
Signed-off-by: Jingqi Liu 
Signed-off-by: Tao Xu 
---
  arch/x86/kvm/vmx/vmx.c  | 36 
  arch/x86/kvm/vmx/vmx.h  |  3 +++
  arch/x86/power/umwait.c |  3 ++-
  3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b35bfac30a34..f33a25e82cb8 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1679,6 +1679,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
  #endif
case MSR_EFER:
return kvm_get_msr_common(vcpu, msr_info);
+   case MSR_IA32_UMWAIT_CONTROL:
+   if (!vmx_waitpkg_supported())
+   return 1;
+
+   msr_info->data = vmx->msr_ia32_umwait_control;
+   break;
case MSR_IA32_SPEC_CTRL:
if (!msr_info->host_initiated &&
!guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
@@ -1841,6 +1847,15 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
return 1;
vmcs_write64(GUEST_BNDCFGS, data);
break;
+   case MSR_IA32_UMWAIT_CONTROL:
+   if (!vmx_waitpkg_supported())
+   return 1;
+
+   if (!data)
+   break;
+


Why cannot clear it to zero?


+   vmx->msr_ia32_umwait_control = data;
+   break;
case MSR_IA32_SPEC_CTRL:
if (!msr_info->host_initiated &&
!guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
@@ -4126,6 +4141,8 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool 
init_event)
vmx->rmode.vm86_active = 0;
vmx->spec_ctrl = 0;
  
+	vmx->msr_ia32_umwait_control = 0;

+
vcpu->arch.microcode_version = 0x1ULL;
vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
kvm_set_cr8(vcpu, 0);
@@ -6339,6 +6356,23 @@ static void atomic_switch_perf_msrs(struct vcpu_vmx *vmx)
msrs[i].host, false);
  }
  
+static void atomic_switch_ia32_umwait_control(struct vcpu_vmx *vmx)

+{
+   u64 host_umwait_control;
+
+   if (!vmx_waitpkg_supported())
+   return;
+
+   host_umwait_control = umwait_control_cached;
+


It's redundant to define host_umwait_control and this line, we can just 
use umwait_control_cached.



+   if (vmx->msr_ia32_umwait_control != host_umwait_control)
+   add_atomic_switch_msr(vmx, MSR_IA32_UMWAIT_CONTROL,
+ vmx->msr_ia32_umwait_control,
+ host_umwait_control, false);


The bit 1 is reserved, at least, we need to do below to ensure not 
modifying the reserved bit:


guest_val = (vmx->msr_ia32_umwait_control & ~BIT_ULL(1)) |
(host_val & BIT_ULL(1))


+   else
+   clear_atomic_switch_msr(vmx, MSR_IA32_UMWAIT_CONTROL);
+}
+
  static void vmx_arm_hv_timer(struct vcpu_vmx *vmx, u32 val)
  {
vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, val);
@@ -6447,6 +6481,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
  
  	atomic_switch_perf_msrs(vmx);
  
+	atomic_switch_ia32_umwait_control(vmx);

+
vmx_update_hv_timer(vcpu);
  
  	/*

diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 61128b48c503..8485bec7c38a 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -14,6 +14,8 @@
  extern const u32 vmx_msr_index[];
  extern u64 host_efer;
  
+extern u32 umwait_control_cached;

+
  #define MSR_TYPE_R1
  #define MSR_TYPE_W2
  #define MSR_TYPE_RW   3
@@ -194,6 +196,7 @@ struct vcpu_vmx {
  #endif
  
  	u64		  spec_ctrl;

+   u64   msr_ia32_umwait_control;
  
  	u32 vm_entry_controls_shadow;

u32 vm_exit_controls_shadow;
diff --git a/arch/x86/power/umwait.c b/arch/x86/power/umwait.c
index 7fa381e3fd4e..2e6ce4cbccb3 100644
--- a/arch/x86/power/umwait.c
+++ b/arch/x86/power/umwait.c
@@ -9,7 +9,8 @@
   * MSR value. By default, umwait max time is 10 in TSC-quanta and C0.2
   * is enabled
   */
-static u32 umwait_control_cached = 10;
+u32 umwait_control_cached = 10;
+EXPORT_SYMBOL_GPL(umwait_control_cached);
  
  /*

   * Serialize access to umwait_control_cached and IA32_UMWAIT_CONTROL MSR



Re: [PATCH v3, 27/27] drm/mediatek: add support for mediatek SOC MT8183

2019-06-16 Thread CK Hu
Hi, Yongqiang:

On Wed, 2019-06-05 at 19:43 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu 
> 
> This patch add support for mediatek SOC MT8183
> 1.ovl_2l share driver with ovl
> 2.rdma1 share drive with rdma0, but fifo size is different
> 3.add mt8183 mutex private data, and mmsys private data
> 4.add mt8183 main and external path module for crtc create
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  18 +
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  12 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 107 
> 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |   1 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   1 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  47 
>  6 files changed, 186 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 63072d1..efd41aa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -382,11 +382,29 @@ static int mtk_disp_ovl_remove(struct platform_device 
> *pdev)
>   .fmt_rgb565_is_0 = true,
>  };
>  
> +static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 4,
> + .fmt_rgb565_is_0 = true,
> +};
> +
> +static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 2,
> + .fmt_rgb565_is_0 = true,
> +};
> +
>  static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
>   { .compatible = "mediatek,mt2701-disp-ovl",
> .data = _ovl_driver_data},
>   { .compatible = "mediatek,mt8173-disp-ovl",
> .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl",
> +   .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl-2l",
> +   .data = _ovl_2l_driver_data},
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index b0a5cff..5d62588 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -336,11 +336,23 @@ static int mtk_disp_rdma_remove(struct platform_device 
> *pdev)
>   .fifo_size = SZ_8K,
>  };
>  
> +static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
> + .fifo_size = 5 * SZ_1K,
> +};
> +
> +static const struct mtk_disp_rdma_data mt8183_rdma1_driver_data = {
> + .fifo_size = SZ_2K,
> +};
> +
>  static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
>   { .compatible = "mediatek,mt2701-disp-rdma",
> .data = _rdma_driver_data},
>   { .compatible = "mediatek,mt8173-disp-rdma",
> .data = _rdma_driver_data},
> + { .compatible = "mediatek,mt8183-disp-rdma",
> +   .data = _rdma_driver_data},
> + { .compatible = "mediatek,mt8183-disp-rdma1",

"mediatek,mt8183-disp-rdma1" does not exist in binding document.

> +   .data = _rdma1_driver_data},
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 28274d2..eaf2351 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -41,8 +41,36 @@
>  #define DISP_REG_CONFIG_DSI_SEL  0x050
>  #define DISP_REG_CONFIG_DPI_SEL  0x064
>  
> +#define MT8183_DISP_OVL0_MOUT_EN 0xF00
> +#define OVL0_MOUT_EN_DISP_PATH0  BIT(0)
> +#define OVL0_MOUT_EN_OVL0_2L BIT(4)
> +#define MT8183_DISP_OVL0_2L_MOUT_EN  0xF04
> +#define OVL0_2L_MOUT_EN_DISP_PATH0   BIT(0)
> +#define MT8183_DISP_OVL1_2L_MOUT_EN  0xF08
> +#define OVL1_2L_MOUT_EN_RDMA1BIT(4)
> +#define MT8183_DISP_DITHER0_MOUT_EN  0xF0C
> +#define DITHER0_MOUT_IN_DSI0 BIT(0)
> +#define MT8183_DISP_PATH0_SEL_IN 0xF24
> +#define DISP_PATH0_SEL_IN_OVL0   0x0
> +#define DISP_PATH0_SEL_IN_OVL0_2L0x1
> +#define MT8183_DISP_DSI0_SEL_IN  0xF2C
> +#define DSI0_SEL_IN_DITHER   0x0
> +#define DSI0_SEL_IN_RDMA00x1
> +#define MT8183_DSI0_SEL_IN_RDMA1 0x3
> +#define MT8183_DISP_DPI0_SEL_IN  0xF30
> +#define MT8183_DPI0_SEL_IN_RDMA0 0x1
> +#define MT8183_DPI0_SEL_IN_RDMA1 0x2
> +#define MT8183_DISP_RDMA0_SOUT_SEL_IN0xF50
> +#define MT8183_RDMA0_SOUT_DSI0   0x0
> +#define MT8183_RDMA0_SOUT_COLOR0 0x1
> +#define 

Re: [PATCH] clk: Do a DT parent lookup even when index < 0

2019-06-16 Thread Chen-Yu Tsai
On Sat, Jun 15, 2019 at 2:10 AM Stephen Boyd  wrote:
>
> We want to allow the parent lookup to happen even if the index is some
> value less than 0. This may be the case if a clk provider only specifies
> the .name member to match a string in the "clock-names" DT property. We
> shouldn't require that the index be >= 0 to make this use case work.
>
> Fixes: 601b6e93304a ("clk: Allow parents to be specified via clkspec index")
> Reported-by: Alexandre Mergnat 
> Cc: Jerome Brunet 
> Cc: Chen-Yu Tsai 
> Signed-off-by: Stephen Boyd 

FWIW,

Reviewed-by: Chen-Yu Tsai 


Re: [PATCH 1/3] x86/resctrl: Get max rmid and occupancy scale directly from CPUID instead of cpuinfo_x86

2019-06-16 Thread Fenghua Yu
On Sun, Jun 16, 2019 at 10:24:13PM +0200, Thomas Gleixner wrote:
> On Sun, 16 Jun 2019, Fenghua Yu wrote:
> 
> > Although x86_cache_max_rmid and x86_cache_occ_scale are only read once
> > during resctrl initialization, they are always stored in cpuinfo_x86 for
> > each CPU during run time without usage. Even if resctrl is not
> > configured, they still occupy space in cpuinfo_x86.
> 
> And that's a problem because?
> 
> > To save cpuinfo_x86 space and make CPU and resctrl initialization simpler,
> > remove the two fields from cpuinfo_x86 and get max rmid and occupancy
> 
> What is simpler? The fact that more code fiddles with CPUID? That's exactly
> the wrong direction.
> 
> The storage size of struct cpuinfo is largely uninteresting especially as
> long as we keep num_online_cpus copies of the same information around.
> 
> Just grep for places which invoke CPUID and then look how many of them do
> it over and over and even the code in arch/x86/kernel/cpu/ is an
> unpenetrable mess for exactly this reason.
> 
> The right thing to do is to have one instance of the CPUID information
> which is
> 
>   - a proper data structure with named fields and named bits
> 
>   - a single master instance which can be mapped to all CPUs
> 
> This data structure is filled in in one go by reading out all leaves and
> not by the maze we have today which puts together selected parts piecewise
> and never exposes a full and consistent picture.
> 
> This allows to remove all these custom copies of CPUID leaf readouts and
> allows proper filtering/disabling at a central place.
> 
> Making it a proper data structure with fields and bits gets rid of all that
> hex masking/shifting nonsense which is used to decode parts of those
> fields.
> 
> That's not a performance issue because all performance critical code should
> use static_cpu_has() anyway. For non critical code boot_cpu_has() is
> sufficient.
> 
> Upcoming secondary CPUs would do a sanity check on their CPUID content to
> check whether everything is symmetric. We should do that actually today
> because not detecting asymetric features early leads to exactly the issue
> which was fixed recently with loading the micro code earlier than perf.
> But we can't because the information retrieval is done in a gazillion of
> places.
>   
> Now you might argue that the upcoming asymetric processors (SIGH!) will
> require per CPU instances of the feature leafs. Sure that needs some
> thought, but it needs thought even with the current code and I'm absolutely
> not interested to duct tape that stuff into the current code.
> 
> The solution for this with the above scheme is to utilize the feature
> mismatch detection and have a proper classification which features are
> allowed to deviate and which are not. For those which can deviate, we can
> provide separate storage as this information needs to be propagated to
> other entities (fault handlers, placement code, xsave variants etc.). But
> that's a limited amount of information and the bulk will still be the same.
> 
> This mismatch detection is essential for dealing with future asymetric
> CPUs proper. When the kernel detects it, it can disable mismatching
> features which are not yet handled by code which has to be aware of them.
> 
> And disabling them means that with that scheme we can actually trap CPUID
> in userspace and provide it consistent and filtered information instead
> of having the mismatch between kernel view and user space view.
> 
> Borislav has experimented with that already, but thanks to the marvelous
> security features built into Intel (and other) CPUs this is still mostly a
> drawing board exercise.
> 
> Just for the record. Before this cleanup takes place, I'm not even looking
> at any patches which attempt to support asymetric processors. The current
> supply of duct tape engineering horrors is sufficient for bad mood. No need
> for more of that.

I see. Then this patch #1 doesn't make sense.

So in the next version, can I remove the patch #1, change the patch #2 as
follows, and keep the patch #3?

It's a waste for the four X86_FEATURE_CQM_* features to occupy two
pure feature bits words. To better utilize feature words, re-define
word 11 to host scattered features and move the four X86_FEATURE_CQM_*
features into Linux defined word 11. More scattered features can be added
in word 11 in the future.

Leaf 11 in cpuid_leafs is renamed as CPUID_LNX_4 to reflect it's a Linux
defined leaf.

Although word 12 doesn't have any feature now, leaf 12 in cpuid_leafs
still needs to be kept because cpuid_leafs must have NCAPINTS leafs.
Rename leaf 12 as CPUID_DUMMY which will be replaced by a meaningful name
in the next patch when CPUID.7.1:EAX occupies world 12.

KVM doesn't support resctrl now. So it's safe to move the
X86_FEATURE_CQM_* features to scattered features word 11 for KVM.

Signed-off-by: Fenghua Yu 
---
 arch/x86/include/asm/cpufeature.h  |  4 +--
 arch/x86/include/asm/cpufeatures.h | 17 ++
 

Re: linux-next: manual merge of the drm-misc tree with the amdgpu tree

2019-06-16 Thread Stephen Rothwell
Hi all,

On Wed, 12 Jun 2019 11:46:15 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> 
> between commit:
> 
>   c7c7192c56d2 ("drm/amd/display: add audio related regs")
> 
> from the amdgpu tree and commit:
> 
>   4fc4dca8320e ("drm/amd: drop use of drmp.h in os_types.h")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> index d43d5d924c19,9b078a71de2e..
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> @@@ -22,7 -22,9 +22,10 @@@
>* Authors: AMD
>*
>*/
> + 
> + #include 
> + 
>  +#include "../dc.h"
>   #include "reg_helper.h"
>   #include "dce_audio.h"
>   #include "dce/dce_11_0_d.h"

This is now a conflict between the drm tree and the amdgpu tree.

-- 
Cheers,
Stephen Rothwell


pgppYvn_97JNG.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the drm-intel tree with the pci tree

2019-06-16 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_drv.h

between commit:

  151f4e2bdc7a ("docs: power: convert docs to ReST and rename to *.rst")

from the pci tree and commit:

  1bf676cc2dba ("drm/i915: move and rename i915_runtime_pm")

from the drm-intel tree.

I fixed it up (I just removed the struct definition form this files as
the latter did - its comment will need to be fixed up in its new file)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpGc4h3ihEoN.pgp
Description: OpenPGP digital signature


Re: [PATCH 12/19] btrfs: expire submit buffer on timeout

2019-06-16 Thread Damien Le Moal
On 2019/06/13 23:15, Josef Bacik wrote:
> On Fri, Jun 07, 2019 at 10:10:18PM +0900, Naohiro Aota wrote:
>> It is possible to have bios stalled in the submit buffer due to some bug or
>> device problem. In such situation, btrfs stops working waiting for buffered
>> bios completions. To avoid such hang, add a worker that will cancel the
>> stalled bios after a timeout.
>>
> 
> The block layer does this with it's request timeouts right?  So it'll timeout
> and we'll get an EIO?  If that's not working then we need to fix the block
> layer.  Thanks,

Joseph,

The block layer timeout is started only when the request is dispatched. The
timeout is not started on BIO/request allocation and so will not trigger for
bios stalled inside btrfs scheduler.


-- 
Damien Le Moal
Western Digital Research


Re: [PATCH 11/19] btrfs: introduce submit buffer

2019-06-16 Thread Damien Le Moal
Josef,

On 2019/06/13 23:15, Josef Bacik wrote:
> On Fri, Jun 07, 2019 at 10:10:17PM +0900, Naohiro Aota wrote:
>> Sequential allocation is not enough to maintain sequential delivery of
>> write IOs to the device. Various features (async compress, async checksum,
>> ...) of btrfs affect ordering of the IOs. This patch introduces submit
>> buffer to sort WRITE bios belonging to a block group and sort them out
>> sequentially in increasing block address to achieve sequential write
>> sequences with __btrfs_map_bio().
>>
>> Signed-off-by: Naohiro Aota 
> 
> I hate everything about this.  Can't we just use the plugging infrastructure 
> for
> this and then make sure it re-orders the bios before submitting them?  Also
> what's to prevent the block layer scheduler from re-arranging these io's?
> Thanks,

The block I/O scheduler reorders requests in LBA order, but that happens for a
newly inserted request against pending requests. If there are no pending
requests because all requests were already issued, no ordering happen, and even
worse, if the drive queue is not full yet (e.g. there are free tags), then the
newly inserted request will be dispatched almost immediately, preventing
reordering with subsequent incoming write requests to happen.

The other problem is that the mq-deadline scheduler does not track zone WP
position. Write request issuing is done regardless of the current WP value,
solely based on LBA ordering. This means that mq-deadline will not prevent
out-of-order, or rather, unaligned write requests. These will not be detected
and dispatched whenever possible. The reasons for this are that:
1) the disk user (the FS) has to manage zone WP positions anyway. So duplicating
that management at the block IO scheduler level is inefficient.
2) Adding zone WP management at the block IO scheduler level would also need a
write error processing path to resync the WP value in case of failed writes. But
the user/FS also needs that anyway. Again duplicated functionalities.
3) The block layer will need a timeout to force issue or cancel pending
unaligned write requests. This is necessary in case the drive user stops issuing
writes (for whatever reasons) or the scheduler is being switched. This would
unnecessarily cause write I/O errors or cause deadlocks if the request queue
quiesce mode is entered at the wrong time (and I do not see a good way to deal
with that).

blk-mq is already complicated enough. Adding this to the block IO scheduler will
unnecessarily complicate things further for no real benefits. I would like to
point out the dm-zoned device mapper and f2fs which are both already dealing
with write ordering and write error processing directly. Both are fairly
straightforward but completely different and each optimized for their own 
structure.

Naohiro changes to btrfs IO scheduler have the same intent, that is, efficiently
integrate and handle write ordering "a la btrfs". Would creating a different
"hmzoned" btrfs IO scheduler help address your concerns ?

Best regards.


-- 
Damien Le Moal
Western Digital Research


Re: [PATCH, RFC 49/62] mm, x86: export several MKTME variables

2019-06-16 Thread Kai Huang
On Fri, 2019-06-14 at 13:56 +0200, Peter Zijlstra wrote:
> On Wed, May 08, 2019 at 05:44:09PM +0300, Kirill A. Shutemov wrote:
> > From: Kai Huang 
> > 
> > KVM needs those variables to get/set memory encryption mask.
> > 
> > Signed-off-by: Kai Huang 
> > Signed-off-by: Kirill A. Shutemov 
> > ---
> >  arch/x86/mm/mktme.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c
> > index df70651816a1..12f4266cf7ea 100644
> > --- a/arch/x86/mm/mktme.c
> > +++ b/arch/x86/mm/mktme.c
> > @@ -7,13 +7,16 @@
> >  
> >  /* Mask to extract KeyID from physical address. */
> >  phys_addr_t mktme_keyid_mask;
> > +EXPORT_SYMBOL_GPL(mktme_keyid_mask);
> >  /*
> >   * Number of KeyIDs available for MKTME.
> >   * Excludes KeyID-0 which used by TME. MKTME KeyIDs start from 1.
> >   */
> >  int mktme_nr_keyids;
> > +EXPORT_SYMBOL_GPL(mktme_nr_keyids);
> >  /* Shift of KeyID within physical address. */
> >  int mktme_keyid_shift;
> > +EXPORT_SYMBOL_GPL(mktme_keyid_shift);
> >  
> >  DEFINE_STATIC_KEY_FALSE(mktme_enabled_key);
> >  EXPORT_SYMBOL_GPL(mktme_enabled_key);
> 
> NAK, don't export variables. Who owns the values, who enforces this?
> 

Both KVM and IOMMU driver need page_keyid() and mktme_keyid_shift to set page's 
keyID to the right
place in the PTE (of KVM EPT and VT-d DMA page table).

MKTME key type code need to know mktme_nr_keyids in order to alloc/free keyID.

Maybe better to introduce functions instead of exposing variables directly?

Or instead of introducing page_keyid(), we use page_encrypt_mask(), which 
essentially holds
"page_keyid() << mktme_keyid_shift"?

Thanks,
-Kai


linux-next: manual merge of the amdgpu tree with Linus' tree

2019-06-16 Thread Stephen Rothwell
Hi Alex,

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

  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c

between commits:

  192905989302 ("drm/amd/amdgpu: add RLC firmware to support raven1 refresh")
  f3a5231c8f14 ("drm/amdgpu: return 0 by default in 
amdgpu_pm_load_smu_firmware")

from Linus' tree and commits:

  80f41f84ae2c ("drm/amd/amdgpu: add RLC firmware to support raven1 refresh")
  4a39ec6ac5f3 ("drm/amdgpu: fix pm_load_smu_firmware for SR-IOV")
  e9bc1bf7916e ("drm/amdgpu: register pm sysfs for sriov (v2)")
  0079f82e710c ("drm/amdgpu: return 0 by default in 
amdgpu_pm_load_smu_firmware")

from the amdgpu tree.

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



-- 
Cheers,
Stephen Rothwell


pgpmtcjTKFw3n.pgp
Description: OpenPGP digital signature


[PATCH] MAINTAINERS: fpga: hand off maintainership to Moritz

2019-06-16 Thread Alan Tull
I'm moving on to a new position and stepping down as FPGA subsystem
maintainer.  Moritz has graciously agreed to take over the
maintainership.

Signed-off-by: Alan Tull 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 80e2bfa049d7..448730982545 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6266,7 +6266,6 @@ F:include/linux/ipmi-fru.h
 K: fmc_d.*register
 
 FPGA MANAGER FRAMEWORK
-M: Alan Tull 
 M: Moritz Fischer 
 L: linux-f...@vger.kernel.org
 S: Maintained
-- 
2.21.0



Re: [PATCH v2] RISC-V: Break load reservations during switch_to

2019-06-16 Thread Palmer Dabbelt

On Sun, 16 Jun 2019 10:54:06 PDT (-0700), j...@sing.id.au wrote:

On 19-06-07 15:22:22, Palmer Dabbelt wrote:

The comment describes why in detail.  This was found because QEMU never
gives up load reservations, the issue is unlikely to manifest on real
hardware.


Makes sense, however it obviously will not help until qemu actually
clears load reservations on SC (or otherwise handles the interleaved
SC case).


Ya, I wasn't paying close enough attention.  I think this should do it

   diff --git a/target/riscv/insn_trans/trans_rva.inc.c 
b/target/riscv/insn_trans/trans_rva.inc.c
   index f6dbbc065e15..001a68ced005 100644
   --- a/target/riscv/insn_trans/trans_rva.inc.c
   +++ b/target/riscv/insn_trans/trans_rva.inc.c
   @@ -69,6 +69,7 @@ static inline bool gen_sc(DisasContext *ctx, arg_atomic 
*a, TCGMemOp mop)
gen_set_gpr(a->rd, dat);
   
gen_set_label(l2);

   +tcg_gen_movi_tl(load_res, -1);
tcg_temp_free(dat);
tcg_temp_free(src1);
tcg_temp_free(src2);

I'll send the patch out to the QEMU mailing list.


See comment inline.


Thanks to Carlos Eduardo for finding the bug!

Signed-off-by: Palmer Dabbelt 
---
Changes since v1 <20190605231735.26581-1-pal...@sifive.com>:

* REG_SC is now defined as a helper macro, for any code that wants to SC
  a register-sized value.
* The explicit #ifdef to check that TASK_THREAD_RA_RA is 0 has been
  removed.  Instead we rely on the assembler to catch non-zero SC
  offsets.  I've tested this does actually work.

 arch/riscv/include/asm/asm.h |  1 +
 arch/riscv/kernel/entry.S| 11 +++
 2 files changed, 12 insertions(+)

diff --git a/arch/riscv/include/asm/asm.h b/arch/riscv/include/asm/asm.h
index 5ad4cb622bed..946b671f996c 100644
--- a/arch/riscv/include/asm/asm.h
+++ b/arch/riscv/include/asm/asm.h
@@ -30,6 +30,7 @@

 #define REG_L  __REG_SEL(ld, lw)
 #define REG_S  __REG_SEL(sd, sw)
+#define REG_SC __REG_SEL(sc.w, sc.d)


The instructions appear to be inverted here (i.e. "sc.d, sc.w").


Thanks, I'll send a v3.


 #define SZREG  __REG_SEL(8, 4)
 #define LGREG  __REG_SEL(3, 2)

diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 1c1ecc238cfa..af685782af17 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -330,6 +330,17 @@ ENTRY(__switch_to)
add   a3, a0, a4
add   a4, a1, a4
REG_S ra,  TASK_THREAD_RA_RA(a3)
+   /*
+* The Linux ABI allows programs to depend on load reservations being
+* broken on context switches, but the ISA doesn't require that the
+* hardware ever breaks a load reservation.  The only way to break a
+* load reservation is with a store conditional, so we emit one here.
+* Since nothing ever takes a load reservation on TASK_THREAD_RA_RA we
+* know this will always fail, but just to be on the safe side this
+* writes the same value that was unconditionally written by the
+* previous instruction.
+*/
+   REG_SC x0, ra, TASK_THREAD_RA_RA(a3)
REG_S sp,  TASK_THREAD_SP_RA(a3)
REG_S s0,  TASK_THREAD_S0_RA(a3)
REG_S s1,  TASK_THREAD_S1_RA(a3)
--
2.21.0



Re: [PATCH V3 5/5] cpufreq: Add QoS requests for userspace constraints

2019-06-16 Thread Viresh Kumar
On 14-06-19, 10:14, Matthias Kaehlcke wrote:
> Hi Viresh,
> 
> On Mon, Jun 10, 2019 at 04:21:36PM +0530, Viresh Kumar wrote:
> > This implements QoS requests to manage userspace configuration of min
> > and max frequency.
> > 
> > Signed-off-by: Viresh Kumar 
> > ---
> >  drivers/cpufreq/cpufreq.c | 92 +++
> >  include/linux/cpufreq.h   |  8 +---
> >  2 files changed, 47 insertions(+), 53 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 547d221b2ff2..ff754981fcb4 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -720,23 +720,15 @@ static ssize_t show_scaling_cur_freq(struct 
> > cpufreq_policy *policy, char *buf)
> >  static ssize_t store_##file_name   \
> >  (struct cpufreq_policy *policy, const char *buf, size_t count) 
> > \
> >  {  \
> > -   int ret, temp;  \
> > -   struct cpufreq_policy new_policy;   \
> > +   unsigned long val;  \
> > +   int ret;\
> > \
> > -   memcpy(_policy, policy, sizeof(*policy));   \
> > -   new_policy.min = policy->user_policy.min;   \
> > -   new_policy.max = policy->user_policy.max;   \
> > -   \
> > -   ret = sscanf(buf, "%u", _policy.object);\
> > +   ret = sscanf(buf, "%lu", ); \
> > if (ret != 1)   \
> > return -EINVAL; \
> > \
> > -   temp = new_policy.object;   \
> > -   ret = cpufreq_set_policy(policy, _policy);  \
> > -   if (!ret)   \
> > -   policy->user_policy.object = temp;  \
> > -   \
> > -   return ret ? ret : count;   \
> > +   ret = dev_pm_qos_update_request(policy->object##_freq_req, val);\
> > +   return ret && ret != 1 ? ret : count;   \
> 
> nit: I wonder if
> 
>   return (ret >= 0) ? count : ret;
> 
> would be clearer.

Done. Thanks.

> Other than that:
> 
> Reviewed-by: Matthias Kaehlcke 

-- 
viresh


Re: [PATCH v2] soc: aspeed: lpc-ctrl: make parameter optional

2019-06-16 Thread Andrew Jeffery



On Sat, 15 Jun 2019, at 07:11, Vijay Khemka wrote:
> Hi Andrew,
> Any update on this patch or do I need any more rework.

No, no more reworks. I've pinged Joel, he'll pick it up.

Andrew


Re: [PATCH v3, 26/27] drm/mediatek: add clock property check before get it

2019-06-16 Thread CK Hu
Hi, Yongqiang:

On Wed, 2019-06-05 at 19:43 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu 
> 
> This patch add clock property check before get it

In the binding document [1], clock is required property. In this patch,
you change it to optional property. I think you should change the
binding document and describe _WHY_ do you do this.

[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/display/mediatek/mediatek%2Cdisp.txt

Regards,
CK

> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 9986c61..28274d2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -689,10 +689,12 @@ static int mtk_ddp_probe(struct platform_device *pdev)
>   for (i = 0; i < 10; i++)
>   ddp->mutex[i].id = i;
>  
> - ddp->clk = devm_clk_get(dev, NULL);
> - if (IS_ERR(ddp->clk)) {
> - dev_err(dev, "Failed to get clock\n");
> - return PTR_ERR(ddp->clk);
> + if (of_find_property(dev->of_node, "clocks", )) {
> + ddp->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(ddp->clk)) {
> + dev_err(dev, "Failed to get clock\n");
> + return PTR_ERR(ddp->clk);
> + }
>   }
>  
>   regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);




Re: [PATCH V3 4/5] cpufreq: Register notifiers with the PM QoS framework

2019-06-16 Thread Viresh Kumar
On 14-06-19, 09:46, Matthias Kaehlcke wrote:
> Hi Viresh,
> 
> On Mon, Jun 10, 2019 at 04:21:35PM +0530, Viresh Kumar wrote:
> > This registers the notifiers for min/max frequency constraints with the
> > PM QoS framework. The constraints are also taken into consideration in
> > cpufreq_set_policy().
> > 
> > This also relocates cpufreq_policy_put_kobj() as it is required to be
> > called from cpufreq_policy_alloc() now.
> > 
> > No constraints are added until now though.
> > 
> > Signed-off-by: Viresh Kumar 
> > ---
> >  drivers/cpufreq/cpufreq.c | 139 +++---
> >  include/linux/cpufreq.h   |   4 ++
> >  2 files changed, 120 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 85ff958e01f1..547d221b2ff2 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -26,6 +26,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1126,11 +1127,77 @@ static void handle_update(struct work_struct *work)
> > cpufreq_update_policy(cpu);
> >  }
> >  
> > +static void cpufreq_update_freq_work(struct work_struct *work)
> > +{
> > +   struct cpufreq_policy *policy =
> > +   container_of(work, struct cpufreq_policy, req_work);
> > +   struct cpufreq_policy new_policy = *policy;
> > +
> > +   /* We should read constraint values from QoS layer */
> > +   new_policy.min = 0;
> > +   new_policy.max = UINT_MAX;
> > +
> > +   down_write(>rwsem);
> > +
> > +   if (!policy_is_inactive(policy))
> > +   cpufreq_set_policy(policy, _policy);
> > +
> > +   up_write(>rwsem);
> > +}
> > +
> > +static int cpufreq_update_freq(struct cpufreq_policy *policy)
> > +{
> > +   schedule_work(>req_work);
> 
> I think you need to add a cancel_work_sync() in cpufreq_policy_free()
> to make sure the work doesn't run after the policy has been freed.

Right, added this to the commit.

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 547d221b2ff2..878add2cac3c 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1289,6 +1289,8 @@ static void cpufreq_policy_free(struct cpufreq_policy 
*policy)
   DEV_PM_QOS_MAX_FREQUENCY);
dev_pm_qos_remove_notifier(dev, >nb_min,
   DEV_PM_QOS_MIN_FREQUENCY);
+   cancel_work_sync(>req_work);
+
cpufreq_policy_put_kobj(policy);
free_cpumask_var(policy->real_cpus);
free_cpumask_var(policy->related_cpus);

-- 
viresh


Re: WARNING in kvm_arch_vcpu_ioctl_run (3)

2019-06-16 Thread syzbot

syzbot has found a reproducer for the following crash on:

HEAD commit:963172d9 Merge branch 'x86-urgent-for-linus' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11422276a0
kernel config:  https://syzkaller.appspot.com/x/.config?x=fa9f7e1b6a8bb586
dashboard link: https://syzkaller.appspot.com/bug?extid=760a73552f47a8cd0fd9
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=103d3e21a0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1645f956a0

The bug was bisected to:

commit 706249c222f68471b6f8e9e8e9b77665c404b226
Author: Peter Zijlstra 
Date:   Fri Jul 24 13:06:37 2015 +

locking/static_keys: Rework update logic

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=175cc58720
final crash:https://syzkaller.appspot.com/x/report.txt?x=14dcc58720
console output: https://syzkaller.appspot.com/x/log.txt?x=10dcc58720

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+760a73552f47a8cd0...@syzkaller.appspotmail.com
Fixes: 706249c222f6 ("locking/static_keys: Rework update logic")

WARNING: CPU: 1 PID: 9153 at arch/x86/kvm/x86.c:8302  
kvm_arch_vcpu_ioctl_run+0x1d8/0x1740 arch/x86/kvm/x86.c:8302

Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 9153 Comm: syz-executor142 Not tainted 5.2.0-rc4+ #53
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 panic+0x2cb/0x744 kernel/panic.c:219
 __warn.cold+0x20/0x4d kernel/panic.c:576
 report_bug+0x263/0x2b0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:179 [inline]
 fixup_bug arch/x86/kernel/traps.c:174 [inline]
 do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986
RIP: 0010:kvm_arch_vcpu_ioctl_run+0x1d8/0x1740 arch/x86/kvm/x86.c:8302
Code: 80 3c 02 00 0f 85 09 14 00 00 49 8b 9c 24 18 0d 00 00 31 ff 48 89 de  
e8 56 93 62 00 48 85 db 0f 84 77 0c 00 00 e8 a8 91 62 00 <0f> 0b e8 a1 91  
62 00 49 8d 7e 01 48 b8 00 00 00 00 00 fc ff df 48

RSP: 0018:8880a0a6fb30 EFLAGS: 00010293
RAX: 8880863945c0 RBX: 0001 RCX: 810e3c69
RDX:  RSI: 810e2fb8 RDI: 0005
RBP: 8880a0a6fb98 R08: 8880863945c0 R09: ed1015d26be0
R10: ed1015d26bdf R11: 8880ae935efb R12: 8880a4048040
R13:  R14: 8880937c8000 R15: 8880a38d2680
 kvm_vcpu_ioctl+0x4dc/0xf90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2755
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:509 [inline]
 do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696
 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
 __do_sys_ioctl fs/ioctl.c:720 [inline]
 __se_sys_ioctl fs/ioctl.c:718 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x448cb9
Code: e8 8c b0 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 4b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7ff6ad8dcce8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 006ddc58 RCX: 00448cb9
RDX:  RSI: ae80 RDI: 0005
RBP: 006ddc50 R08: 7ff6ad8dd700 R09: 
R10: 7ff6ad8dd700 R11: 0246 R12: 006ddc5c
R13: 7ffdd645a21f R14: 7ff6ad8dd9c0 R15: 20c49ba5e353f7cf
Kernel Offset: disabled
Rebooting in 86400 seconds..



Re: [RFC PATCH v3 00/16] Core scheduling v3

2019-06-16 Thread Aubrey Li
On Thu, Jun 13, 2019 at 11:22 AM Julien Desfossez
 wrote:
>
> On 12-Jun-2019 05:03:08 PM, Subhra Mazumdar wrote:
> >
> > On 6/12/19 9:33 AM, Julien Desfossez wrote:
> > >After reading more traces and trying to understand why only untagged
> > >tasks are starving when there are cpu-intensive tasks running on the
> > >same set of CPUs, we noticed a difference in behavior in ‘pick_task’. In
> > >the case where ‘core_cookie’ is 0, we are supposed to only prefer the
> > >tagged task if it’s priority is higher, but when the priorities are
> > >equal we prefer it as well which causes the starving. ‘pick_task’ is
> > >biased toward selecting its first parameter in case of equality which in
> > >this case was the ‘class_pick’ instead of ‘max’. Reversing the order of
> > >the parameter solves this issue and matches the expected behavior.
> > >
> > >So we can get rid of this vruntime_boost concept.
> > >
> > >We have tested the fix below and it seems to work well with
> > >tagged/untagged tasks.
> > >
> > My 2 DB instance runs with this patch are better with CORESCHED_STALL_FIX
> > than NO_CORESCHED_STALL_FIX in terms of performance, std deviation and
> > idleness. May be enable it by default?
>
> Yes if the fix is approved, we will just remove the option and it will
> always be enabled.
>

sysbench --report-interval option unveiled something.

benchmark setup
-
two cgroups, cpuset.cpus = 1, 53(one core, two siblings)
sysbench cpu mode, one thread in cgroup1
sysbench memory mode, one thread in cgroup2

no core scheduling
--
cpu throughput eps: 405.8, std: 0.14%
mem bandwidth MB/s: 5785.7, std: 0.11%

cgroup1 enable core scheduling(cpu mode)
cgroup2 disable core scheduling(memory mode)
-
cpu throughput eps: 8.7, std: 519.2%
mem bandwidth MB/s: 6263.2, std: 9.3%

cgroup1 disable core scheduling(cpu mode)
cgroup2 enable core scheduling(memory mode)
-
cpu throughput eps: 468.0 , std: 8.7%
mem bandwidth MB/S: 311.6 , std: 169.1%

cgroup1 enable core scheduling(cpu mode)
cgroup2 enable core scheduling(memory mode)

cpu throughput eps: 76.4 , std: 168.0%
mem bandwidth MB/S: 5388.3 , std: 30.9%

The result looks still unfair, and particularly, the variance is too high,
sysbench cpu log 
snip
[ 10s ] thds: 1 eps: 296.00 lat (ms,95%): 2.03
[ 11s ] thds: 1 eps: 0.00 lat (ms,95%): 1170.65
[ 12s ] thds: 1 eps: 1.00 lat (ms,95%): 0.00
[ 13s ] thds: 1 eps: 0.00 lat (ms,95%): 0.00
[ 14s ] thds: 1 eps: 295.91 lat (ms,95%): 2.03
[ 15s ] thds: 1 eps: 1.00 lat (ms,95%): 170.48
[ 16s ] thds: 1 eps: 0.00 lat (ms,95%): 2009.23
[ 17s ] thds: 1 eps: 1.00 lat (ms,95%): 995.51
[ 18s ] thds: 1 eps: 296.00 lat (ms,95%): 2.03
[ 19s ] thds: 1 eps: 1.00 lat (ms,95%): 170.48
[ 20s ] thds: 1 eps: 0.00 lat (ms,95%): 2009.23
snip

Thanks,
-Aubrey


[PATCH v2] perf vendor events: Add Icelake V1.00 event file

2019-06-16 Thread Haiyan Song
Add a Intel event file for perf.

Signed-off-by: Haiyan Song 
---
 tools/perf/pmu-events/arch/x86/icelake/cache.json  | 552 +
 .../arch/x86/icelake/floating-point.json   | 102 +++
 .../perf/pmu-events/arch/x86/icelake/frontend.json | 424 ++
 tools/perf/pmu-events/arch/x86/icelake/memory.json | 410 ++
 tools/perf/pmu-events/arch/x86/icelake/other.json  | 121 +++
 .../perf/pmu-events/arch/x86/icelake/pipeline.json | 892 +
 .../arch/x86/icelake/virtual-memory.json   | 236 ++
 tools/perf/pmu-events/arch/x86/mapfile.csv |   2 +
 8 files changed, 2739 insertions(+)
 create mode 100644 tools/perf/pmu-events/arch/x86/icelake/cache.json
 create mode 100644 tools/perf/pmu-events/arch/x86/icelake/floating-point.json
 create mode 100644 tools/perf/pmu-events/arch/x86/icelake/frontend.json
 create mode 100644 tools/perf/pmu-events/arch/x86/icelake/memory.json
 create mode 100644 tools/perf/pmu-events/arch/x86/icelake/other.json
 create mode 100644 tools/perf/pmu-events/arch/x86/icelake/pipeline.json
 create mode 100644 tools/perf/pmu-events/arch/x86/icelake/virtual-memory.json

diff --git a/tools/perf/pmu-events/arch/x86/icelake/cache.json 
b/tools/perf/pmu-events/arch/x86/icelake/cache.json
new file mode 100644
index ..3529fc338c17
--- /dev/null
+++ b/tools/perf/pmu-events/arch/x86/icelake/cache.json
@@ -0,0 +1,552 @@
+[
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts the number of demand Data Read requests 
that miss L2 cache. Only not rejected loads are counted.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x21",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.DEMAND_DATA_RD_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "Demand Data Read miss L2, no rejects"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts the RFO (Read-for-Ownership) requests 
that miss L2 cache.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x22",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.RFO_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "RFO requests that miss L2 cache"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts L2 cache misses when fetching 
instructions.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x24",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.CODE_RD_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "L2 cache misses when fetching instructions"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts demand requests that miss L2 cache.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x27",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.ALL_DEMAND_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "Demand requests that miss L2 cache"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts Software prefetch requests that miss the 
L2 cache. This event accounts for PREFETCHNTA and PREFETCHT0/1/2 instructions.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x28",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.SWPF_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "SW prefetch requests that miss L2 cache."
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts the number of demand Data Read requests 
initiated by load instructions that hit L2 cache.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0xc1",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.DEMAND_DATA_RD_HIT",
+"SampleAfterValue": "23",
+"BriefDescription": "Demand Data Read requests that hit L2 cache"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts the RFO (Read-for-Ownership) requests 
that hit L2 cache.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0xc2",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.RFO_HIT",
+"SampleAfterValue": "23",
+"BriefDescription": "RFO requests that hit L2 cache"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts L2 cache hits when fetching instructions, 
code reads.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0xc4",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.CODE_RD_HIT",
+"SampleAfterValue": "23",
+"BriefDescription": "L2 cache hits when fetching instructions, code 
reads."
+},
+{
+"CollectPEBSRecord": "2",
+

Re: [PATCH v2 00/19] btrfs zoned block device support

2019-06-16 Thread Damien Le Moal
David,

On 2019/06/13 22:45, David Sterba wrote:
> On Thu, Jun 13, 2019 at 04:59:23AM +, Naohiro Aota wrote:
>> On 2019/06/13 2:50, David Sterba wrote:
>>> On Fri, Jun 07, 2019 at 10:10:06PM +0900, Naohiro Aota wrote:
 btrfs zoned block device support

 This series adds zoned block device support to btrfs.
>>>
>>> The overall design sounds ok.
>>>
>>> I skimmed through the patches and the biggest task I see is how to make
>>> the hmzoned adjustments and branches less visible, ie. there are too
>>> many if (hmzoned) { do something } standing out. But that's merely a
>>> matter of wrappers and maybe an abstraction here and there.
>>
>> Sure. I'll add some more abstractions in the next version.
> 
> Ok, I'll reply to the patches with specific things.
> 
>>> How can I test the zoned devices backed by files (or regular disks)? I
>>> searched for some concrete example eg. for qemu or dm-zoned, but closest
>>> match was a text description in libzbc README that it's possible to
>>> implement. All other howtos expect a real zoned device.
>>
>> You can use tcmu-runer [1] to create an emulated zoned device backed by 
>> a regular file. Here is a setup how-to:
>> http://zonedstorage.io/projects/tcmu-runner/#compilation-and-installation
> 
> That looks great, thanks. I wonder why there's no way to find that, all
> I got were dead links to linux-iscsi.org or tutorials of targetcli that
> were years old and not working.

The site went online 4 days ago :) We will advertise it whenever we can. This is
intended to document all things "zoned block device" including Btrfs support,
when we get it finished :)

> 
> Feeding the textual commands to targetcli is not exactly what I'd
> expect for scripting, but at least it seems to work.

Yes, this is not exactly obvious, but that is how most automation with linux
iscsi is done.

> 
> I tried to pass an emulated ZBC device on host to KVM guest (as a scsi
> device) but lsscsi does not recognize that it as a zonde device (just a
> QEMU harddisk). So this seems the emulation must be done inside the VM.
> 

What driver did you use for the drive ? virtio block ? I have not touch that
driver nor qemu side, so zoned block dev support is likely missing. I will add
it. That would be especially useful for testing with a real drive. In the case
of tcmu runner, the initiator can be started in the guest directly and the
target emulation done either in the guest if loopback is used, or on the host
using iscsi connection. The former is what we use all the time and so is well
tested. I have to admit that testing with iscsi is lacking... Will add that to
the todo list.

Best regards.

-- 
Damien Le Moal
Western Digital Research


Re: [RFC] switch nds32 to use the generic remapping DMA allocator

2019-06-16 Thread Greentime Hu
Christoph Hellwig  於 2019年6月14日 週五 下午8:22寫道:
>
> On Fri, Jun 14, 2019 at 07:35:29PM +0800, Greentime Hu wrote:
> > It looks good to me. I just verified in nds32 platform and it works fine.
> > Should I put it in my next-tree or you will pick it up in your tree? :)
>
> Either way works for me, let me know what you prefer.

I prefer to put in your tree. Thanks. :)


kernel/workqueue.c:3030 __flush_work+0x2c2/0x2d0

2019-06-16 Thread Naresh Kamboju
Kernel warning while running kernel selftest bpf test_sockmap test case on
x86_64 and arm64.
The kernel warning log pops up continuously.

Linux version 5.1.10-rc2

Steps to reproduce:
Boot stable rc 5.1.10-rc2 kernel on x86_64 or arm64
cd selftests/bpf
./test_sockmap

[   37.600406] WARNING: CPU: 3 PID: 57 at
/usr/src/kernel/kernel/workqueue.c:3030 __flush_work+0x2c2/0x2d0
[   37.610034] Modules linked in: x86_pkg_temp_thermal fuse
[   37.615371] CPU: 3 PID: 57 Comm: kworker/3:1 Not tainted 5.1.10-rc2 #1
[   37.615454] WARNING: CPU: 0 PID: 5 at
/usr/src/kernel/kernel/workqueue.c:3030 __flush_work+0x2c2/0x2d0
[   37.621892] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[   37.621895] Workqueue: events sk_psock_destroy_deferred
[   37.631183] Modules linked in: x86_pkg_temp_thermal fuse
[   37.638654] RIP: 0010:__flush_work+0x2c2/0x2d0
[   37.638655] Code: c6 00 31 c0 e9 71 ff ff ff 41 8b 0c 24 49 8b 54
24 08 83 e1 08 49 0f ba 2c 24 03 80 c9 f0 e9 d2 fe ff ff 0f 0b e9 50
ff ff ff <0f> 0b 31 c0 e9 47 ff ff ff e8 90 9d fd ff 0f 1f 44 00 00 55
31 f6
[   37.643879] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.10-rc2 #1
[   37.643880] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[   37.649183] RSP: 0018:b038c1a23ca0 EFLAGS: 00010246
[   37.653630] Workqueue: events sk_psock_destroy_deferred
[   37.672375] RAX:  RBX: 9e73d9492068 RCX: 0006
[   37.672376] RDX: 0006 RSI: 0001 RDI: 9e73d9492068
[   37.678805] RIP: 0010:__flush_work+0x2c2/0x2d0
[   37.678807] Code: c6 00 31 c0 e9 71 ff ff ff 41 8b 0c 24 49 8b 54
24 08 83 e1 08 49 0f ba 2c 24 03 80 c9 f0 e9 d2 fe ff ff 0f 0b e9 50
ff ff ff <0f> 0b 31 c0 e9 47 ff ff ff e8 90 9d fd ff 0f 1f 44 00 00 55
31 f6
[   37.686274] RBP: b038c1a23d68 R08:  R09: 
[   37.686275] R10:  R11:  R12: 9e73d9492068
[   37.691494] RSP: 0018:b038c18fbca0 EFLAGS: 00010246
[   37.696720] R13: 0001 R14: b038c1a23d98 R15: 9a490d40
[   37.696721] FS:  () GS:9e73dfb8()
knlGS:
[   37.703851] RAX:  RBX: 9e73d9490868 RCX: 0006
[   37.703852] RDX: 0006 RSI: 0001 RDI: 9e73d9490868
[   37.710976] CS:  0010 DS:  ES:  CR0: 80050033
[   37.710977] CR2: 7f38680ca8a0 CR3: 0002ee614006 CR4: 003606e0
[   37.715419] RBP: b038c18fbd68 R08:  R09: 
[   37.715420] R10:  R11:  R12: 9e73d9490868
[   37.734156] DR0:  DR1:  DR2: 
[   37.734157] DR3:  DR6: fffe0ff0 DR7: 0400
[   37.741282] R13: 0001 R14: b038c18fbd98 R15: 9a490d40
[   37.741283] FS:  () GS:9e73dfa0()
knlGS:
[   37.748405] Call Trace:
[   37.748410]  ? work_busy+0xc0/0xc0
[   37.753621] CS:  0010 DS:  ES:  CR0: 80050033
[   37.753622] CR2: 7f38680c9788 CR3: 00045454a004 CR4: 003606f0
[   37.760746]  ? mark_held_locks+0x4d/0x80
[   37.768823] DR0:  DR1:  DR2: 
[   37.768824] DR3:  DR6: fffe0ff0 DR7: 0400
[   37.775946]  ? __cancel_work_timer+0x11a/0x1d0
[   37.783071] Call Trace:
[   37.783075]  ? work_busy+0xc0/0xc0
[   37.788808]  ? cancel_delayed_work_sync+0x13/0x20
[   37.788810]  ? lockdep_hardirqs_on+0xf6/0x190
[   37.795934]  ? mark_held_locks+0x4d/0x80
[   37.803055]  ? __cancel_work_timer+0x11a/0x1d0
[   37.803057]  ? work_busy+0xc0/0xc0
[   37.810179]  ? __cancel_work_timer+0x11a/0x1d0
[   37.817303]  __cancel_work_timer+0x134/0x1d0
[   37.824453]  ? cancel_delayed_work_sync+0x13/0x20
[   37.824455]  ? lockdep_hardirqs_on+0xf6/0x190
[   37.831579]  cancel_delayed_work_sync+0x13/0x20
[   37.839654]  ? __cancel_work_timer+0x11a/0x1d0
[   37.839657]  ? work_busy+0xc0/0xc0
[   37.842100]  strp_done+0x1c/0x50
[   37.845497]  __cancel_work_timer+0x134/0x1d0
[   37.851242]  sk_psock_destroy_deferred+0x34/0x1c0
[   37.858372]  cancel_delayed_work_sync+0x13/0x20
[   37.862292]  process_one_work+0x281/0x610
[   37.869415]  strp_done+0x1c/0x50
[   37.876540]  worker_thread+0x3c/0x3f0
[   37.880975]  sk_psock_destroy_deferred+0x34/0x1c0
[   37.883419]  ? __kthread_parkme+0x61/0x90
[   37.886819]  process_one_work+0x281/0x610
[   37.891514]  kthread+0x12c/0x150
[   37.895868]  worker_thread+0x3c/0x3f0
[   37.899783]  ? process_one_work+0x610/0x610
[   37.904221]  kthread+0x12c/0x150
[   37.907615]  ? kthread_park+0x90/0x90
[   37.907618]  ret_from_fork+0x3a/0x50
[   37.912052]  ? process_one_work+0x610/0x610
[   37.916355] irq event stamp: 57860
[   37.921058]  ? kthread_park+0x90/0x90
[   37.921060]  ret_from_fork+0x3a/0x50
[   37.925407] hardirqs last  enabled at 

Re: [PATCH -next] mm/hotplug: skip bad PFNs from pfn_to_online_page()

2019-06-16 Thread Qian Cai



> On Jun 16, 2019, at 11:42 AM, Dan Williams  wrote:
> 
> On Fri, Jun 14, 2019 at 1:43 PM Qian Cai  wrote:
>> 
>> On Fri, 2019-06-14 at 12:48 -0700, Dan Williams wrote:
>>> On Fri, Jun 14, 2019 at 12:40 PM Qian Cai  wrote:
 
 On Fri, 2019-06-14 at 11:57 -0700, Dan Williams wrote:
> On Fri, Jun 14, 2019 at 11:03 AM Dan Williams 
> wrote:
>> 
>> On Fri, Jun 14, 2019 at 7:59 AM Qian Cai  wrote:
>>> 
>>> On Fri, 2019-06-14 at 14:28 +0530, Aneesh Kumar K.V wrote:
 Qian Cai  writes:
 
 
> 1) offline is busted [1]. It looks like test_pages_in_a_zone()
> missed
> the
> same
> pfn_section_valid() check.
> 
> 2) powerpc booting is generating endless warnings [2]. In
> vmemmap_populated() at
> arch/powerpc/mm/init_64.c, I tried to change PAGES_PER_SECTION to
> PAGES_PER_SUBSECTION, but it alone seems not enough.
> 
 
 Can you check with this change on ppc64.  I haven't reviewed this
 series
 yet.
 I did limited testing with change . Before merging this I need to go
 through the full series again. The vmemmap poplulate on ppc64 needs
 to
 handle two translation mode (hash and radix). With respect to vmemap
 hash doesn't setup a translation in the linux page table. Hence we
 need
 to make sure we don't try to setup a mapping for a range which is
 arleady convered by an existing mapping.
>>> 
>>> It works fine.
>> 
>> Strange... it would only change behavior if valid_section() is true
>> when pfn_valid() is not or vice versa. They "should" be identical
>> because subsection-size == section-size on PowerPC, at least with the
>> current definition of SUBSECTION_SHIFT. I suspect maybe
>> free_area_init_nodes() is too late to call subsection_map_init() for
>> PowerPC.
> 
> Can you give the attached incremental patch a try? This will break
> support for doing sub-section hot-add in a section that was only
> partially populated early at init, but that can be repaired later in
> the series. First things first, don't regress.
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 874eb22d22e4..520c83aa0fec 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7286,12 +7286,10 @@ void __init free_area_init_nodes(unsigned long
> *max_zone_pfn)
> 
>/* Print out the early node map */
>pr_info("Early memory node ranges\n");
> -   for_each_mem_pfn_range(i, MAX_NUMNODES, _pfn, _pfn,
> ) {
> +   for_each_mem_pfn_range(i, MAX_NUMNODES, _pfn, _pfn,
> )
>pr_info("  node %3d: [mem %#018Lx-%#018Lx]\n", nid,
>(u64)start_pfn << PAGE_SHIFT,
>((u64)end_pfn << PAGE_SHIFT) - 1);
> -   subsection_map_init(start_pfn, end_pfn - start_pfn);
> -   }
> 
>/* Initialise every node */
>mminit_verify_pageflags_layout();
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 0baa2e55cfdd..bca8e6fa72d2 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -533,6 +533,7 @@ static void __init sparse_init_nid(int nid,
> unsigned long pnum_begin,
>}
>check_usemap_section_nr(nid, usage);
>sparse_init_one_section(__nr_to_section(pnum), pnum,
> map, usage);
> +   subsection_map_init(section_nr_to_pfn(pnum),
> PAGES_PER_SECTION);
>usage = (void *) usage + mem_section_usage_size();
>}
>sparse_buffer_fini();
 
 It works fine except it starts to trigger slab debugging errors during 
 boot.
 Not
 sure if it is related yet.
>>> 
>>> If you want you can give this branch a try if you suspect something
>>> else in -next is triggering the slab warning.
>>> 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git/log/?h=subsect
>>> ion-v9
>>> 
>>> It's the original v9 patchset + dependencies backported to v5.2-rc4.
>>> 
>>> I otherwise don't see how subsections would effect slab caches.
>> 
>> It works fine there.
> 
> Much appreciated Qian!
> 
> Does this change modulate the x86 failures?

Yes, it also fix the kmemleak_scan() and offline issues on x86.



linux-next: manual merge of the mlx5-next tree with Linus' tree

2019-06-16 Thread Stephen Rothwell
Hi Leon,

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

  include/linux/mlx5/eswitch.h

between commit:

  02f3afd97556 ("net/mlx5: E-Switch, Correct type to u16 for vport_num and int 
for vport_index")

from Linus' tree and commit:

  82b11f071936 ("net/mlx5: Expose eswitch encap mode")

from the mlx5-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/mlx5/eswitch.h
index e9a55c0d50fd,174eec0871d9..
--- a/include/linux/mlx5/eswitch.h
+++ b/include/linux/mlx5/eswitch.h
@@@ -61,5 -62,16 +62,16 @@@ void *mlx5_eswitch_uplink_get_proto_dev
  u8 mlx5_eswitch_mode(struct mlx5_eswitch *esw);
  struct mlx5_flow_handle *
  mlx5_eswitch_add_send_to_vport_rule(struct mlx5_eswitch *esw,
 -  int vport, u32 sqn);
 +  u16 vport_num, u32 sqn);
+ 
+ #ifdef CONFIG_MLX5_ESWITCH
+ enum devlink_eswitch_encap_mode
+ mlx5_eswitch_get_encap_mode(const struct mlx5_core_dev *dev);
+ #else  /* CONFIG_MLX5_ESWITCH */
+ static inline enum devlink_eswitch_encap_mode
+ mlx5_eswitch_get_encap_mode(const struct mlx5_core_dev *dev)
+ {
+   return DEVLINK_ESWITCH_ENCAP_MODE_NONE;
+ }
+ #endif /* CONFIG_MLX5_ESWITCH */
  #endif


pgpSwmwNlzDwf.pgp
Description: OpenPGP digital signature


Re: [PATCH] fsi: sbefifo: Don't fail operations when in SBE IPL state

2019-06-16 Thread Alistair Popple
This fixed the problem I was having trying to issue istep operations to the 
SBE.

Tested-by: Alistair Popple 

On Monday, 21 January 2019 11:15:58 AM AEST Eddie James wrote:
> SBE fifo operations should be allowed while the SBE is in any of the
> "IPL" states. Operations should succeed in this state.
> 
> Signed-off-by: Eddie James 
> ---
>  drivers/fsi/fsi-sbefifo.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fsi/fsi-sbefifo.c b/drivers/fsi/fsi-sbefifo.c
> index c7d13ac..f7665b3 100644
> --- a/drivers/fsi/fsi-sbefifo.c
> +++ b/drivers/fsi/fsi-sbefifo.c
> @@ -290,11 +290,11 @@ static int sbefifo_check_sbe_state(struct sbefifo
> *sbefifo) switch ((sbm & CFAM_SBM_SBE_STATE_MASK) >>
> CFAM_SBM_SBE_STATE_SHIFT) { case SBE_STATE_UNKNOWN:
>   return -ESHUTDOWN;
> + case SBE_STATE_DMT:
> + return -EBUSY;
>   case SBE_STATE_IPLING:
>   case SBE_STATE_ISTEP:
>   case SBE_STATE_MPIPL:
> - case SBE_STATE_DMT:
> - return -EBUSY;
>   case SBE_STATE_RUNTIME:
>   case SBE_STATE_DUMP: /* Not sure about that one */
>   break;




[PATCH v3 3/7] lib/hexdump.c: Optionally suppress lines of repeated bytes

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

Some buffers may only be partially filled with useful data, while the rest
is padded (typically with 0x00 or 0xff).

This patch introduces a flag to allow the supression of lines of repeated
bytes, which are replaced with '** Skipped %u bytes of value 0x%x **'

An inline wrapper function is provided for backwards compatibility with
existing code, which maintains the original behaviour.

Signed-off-by: Alastair D'Silva 
---
 include/linux/printk.h | 25 +---
 lib/hexdump.c  | 91 --
 2 files changed, 99 insertions(+), 17 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index cefd374c47b1..d7754799cfe0 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -481,13 +481,18 @@ enum {
DUMP_PREFIX_ADDRESS,
DUMP_PREFIX_OFFSET
 };
+
 extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
  int groupsize, char *linebuf, size_t linebuflen,
  bool ascii);
+
+#define HEXDUMP_ASCII  BIT(0)
+#define HEXDUMP_SUPPRESS_REPEATED  BIT(1)
+
 #ifdef CONFIG_PRINTK
-extern void print_hex_dump(const char *level, const char *prefix_str,
+extern void print_hex_dump_ext(const char *level, const char *prefix_str,
   int prefix_type, int rowsize, int groupsize,
-  const void *buf, size_t len, bool ascii);
+  const void *buf, size_t len, u32 flags);
 #if defined(CONFIG_DYNAMIC_DEBUG)
 #define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
@@ -496,18 +501,28 @@ extern void print_hex_dump_bytes(const char *prefix_str, 
int prefix_type,
 const void *buf, size_t len);
 #endif /* defined(CONFIG_DYNAMIC_DEBUG) */
 #else
-static inline void print_hex_dump(const char *level, const char *prefix_str,
+static inline void print_hex_dump_ext(const char *level, const char 
*prefix_str,
  int prefix_type, int rowsize, int groupsize,
- const void *buf, size_t len, bool ascii)
+ const void *buf, size_t len, u32 flags)
 {
 }
 static inline void print_hex_dump_bytes(const char *prefix_str, int 
prefix_type,
const void *buf, size_t len)
 {
 }
-
 #endif
 
+static __always_inline void print_hex_dump(const char *level,
+  const char *prefix_str,
+  int prefix_type, int rowsize,
+  int groupsize, const void *buf,
+  size_t len, bool ascii)
+{
+   print_hex_dump_ext(level, prefix_str, prefix_type, rowsize, groupsize,
+   buf, len, ascii ? HEXDUMP_ASCII : 0);
+}
+
+
 #if defined(CONFIG_DYNAMIC_DEBUG)
 #define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
 groupsize, buf, len, ascii)\
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 3943507bc0e9..b781f84e 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -212,8 +212,44 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
 EXPORT_SYMBOL(hex_dump_to_buffer);
 
 #ifdef CONFIG_PRINTK
+
+/**
+ * buf_is_all - Check if a buffer contains only a single byte value
+ * @buf: pointer to the buffer
+ * @len: the size of the buffer in bytes
+ * @val: outputs the value if if the bytes are identical
+ */
+static bool buf_is_all(const u8 *buf, size_t len, u8 *val_out)
+{
+   size_t i;
+   u8 val;
+
+   if (len <= 1)
+   return false;
+
+   val = buf[0];
+
+   for (i = 1; i < len; i++) {
+   if (buf[i] != val)
+   return false;
+   }
+
+   *val_out = val;
+   return true;
+}
+
+static void announce_skipped(const char *level, const char *prefix_str,
+  u8 val, size_t count)
+{
+   if (count == 0)
+   return;
+
+   printk("%s%s ** Skipped %lu bytes of value 0x%x **\n",
+  level, prefix_str, count, val);
+}
+
 /**
- * print_hex_dump - print a text hex dump to syslog for a binary blob of data
+ * print_hex_dump_ext - dump a binary blob of data to syslog in hexadecimal
  * @level: kernel log level (e.g. KERN_DEBUG)
  * @prefix_str: string to prefix each line with;
  *  caller supplies trailing spaces for alignment if desired
@@ -224,6 +260,10 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
  * @buf: data blob to dump
  * @len: number of bytes in the @buf
  * @ascii: include ASCII after the hex output
+ * @flags: A bitwise OR of the following flags:
+ * HEXDUMP_ASCII:  include ASCII after the hex output
+ * HEXDUMP_SUPPRESS_REPEATED:  suppress repeated lines of identical

[PATCH v3 6/7] lib/hexdump.c: Allow multiple groups to be separated by spaces

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

Similar to the previous patch, this patch separates groups by 2 spaces for
the hex fields, and 1 space for the ASCII field.

eg.
buf:: 454d414e 43415053  4e495f45 00584544  NAMESPAC E_INDEX.
buf:0010:  0002      

Signed-off-by: Alastair D'Silva 
---
 include/linux/printk.h |  3 ++
 lib/hexdump.c  | 65 +++---
 2 files changed, 52 insertions(+), 16 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index c6b748f66a82..04416e788802 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -487,6 +487,9 @@ enum {
 #define HEXDUMP_2_GRP_LINESBIT(2)
 #define HEXDUMP_4_GRP_LINESBIT(3)
 #define HEXDUMP_8_GRP_LINESBIT(4)
+#define HEXDUMP_2_GRP_SPACES   BIT(5)
+#define HEXDUMP_4_GRP_SPACES   BIT(6)
+#define HEXDUMP_8_GRP_SPACES   BIT(7)
 
 extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
  int groupsize, char *linebuf, size_t linebuflen,
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 4da7d24826fb..dc85ef0dbb0a 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -91,9 +91,37 @@ static const char *group_separator(int group, u64 flags)
if ((flags & HEXDUMP_2_GRP_LINES) && !((group) % 2))
return "|";
 
+   if ((flags & HEXDUMP_8_GRP_SPACES) && !((group) % 8))
+   return "  ";
+
+   if ((flags & HEXDUMP_4_GRP_SPACES) && !((group) % 4))
+   return "  ";
+
+   if ((flags & HEXDUMP_2_GRP_SPACES) && !((group) % 2))
+   return "  ";
+
return " ";
 }
 
+static void separator_parameters(u64 flags, int groupsize, int *sep_chars,
+char *sep)
+{
+   if (flags & (HEXDUMP_2_GRP_LINES | HEXDUMP_2_GRP_SPACES))
+   *sep_chars = groupsize * 2;
+   if (flags & (HEXDUMP_4_GRP_LINES | HEXDUMP_4_GRP_SPACES))
+   *sep_chars = groupsize * 4;
+   if (flags & (HEXDUMP_8_GRP_LINES | HEXDUMP_8_GRP_SPACES))
+   *sep_chars = groupsize * 8;
+
+   if (flags & (HEXDUMP_2_GRP_LINES | HEXDUMP_4_GRP_LINES |
+  HEXDUMP_8_GRP_LINES))
+   *sep = '|';
+
+   if (flags & (HEXDUMP_2_GRP_SPACES | HEXDUMP_4_GRP_SPACES |
+  HEXDUMP_8_GRP_SPACES))
+   *sep = ' ';
+}
+
 /**
  * hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
  * @buf: data blob to dump
@@ -107,6 +135,9 @@ static const char *group_separator(int group, u64 flags)
  * HEXDUMP_2_GRP_LINES:insert a '|' after every 2 groups
  * HEXDUMP_4_GRP_LINES:insert a '|' after every 4 groups
  * HEXDUMP_8_GRP_LINES:insert a '|' after every 8 groups
+ * HEXDUMP_2_GRP_SPACES:   insert a ' ' after every 2 groups
+ * HEXDUMP_4_GRP_SPACES:   insert a ' ' after every 4 groups
+ * HEXDUMP_8_GRP_SPACES:   insert a ' ' after every 8 groups
  *
  * hex_dump_to_buffer() works on one "line" of output at a time, converting
  *  bytes of input to hexadecimal (and optionally printable ASCII)
@@ -138,7 +169,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
int j, lx = 0;
int ascii_column;
int ret;
-   int line_chars = 0;
+   int sep_chars = 0;
+   char sep = 0;
 
if (!is_power_of_2(groupsize) || groupsize > 8)
groupsize = 1;
@@ -152,8 +184,14 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
len = rowsize;
 
ngroups = len / groupsize;
+
ascii_column = rowsize * 2 + rowsize / groupsize + 1;
 
+   // space separators use 2 spaces in the hex output
+   separator_parameters(flags, groupsize, _chars, );
+   if (sep == ' ')
+   ascii_column += rowsize / sep_chars;
+
if (!linebuflen)
goto overflow1;
 
@@ -221,24 +259,17 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
linebuf[lx++] = ' ';
}
 
-   if (flags & HEXDUMP_2_GRP_LINES)
-   line_chars = groupsize * 2;
-   if (flags & HEXDUMP_4_GRP_LINES)
-   line_chars = groupsize * 4;
-   if (flags & HEXDUMP_8_GRP_LINES)
-   line_chars = groupsize * 8;
-
for (j = 0; j < len; j++) {
if (linebuflen < lx + 2)
goto overflow2;
ch = ptr[j];
linebuf[lx++] = (isascii(ch) && isprint(ch)) ? ch : '.';
 
-   if (line_chars && ((j + 1) < len) &&
-   ((j + 1) % line_chars == 0)) {
+   if (sep_chars && ((j + 1) < len) &&
+   ((j + 1) % sep_chars == 0)) {
if (linebuflen < lx + 2)

[PATCH v3 7/7] lib/hexdump.c: Optionally retain byte ordering

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

The behaviour of hexdump groups is to print the data out as if
it was a native-endian number.

This patch tweaks the documentation to make this clear, and also
adds the HEXDUMP_RETAIN_BYTE_ORDER flag to allow groups of
multiple bytes to be printed without affecting the ordering
of the printed bytes.

Signed-off-by: Alastair D'Silva 
---
 include/linux/printk.h |  1 +
 lib/hexdump.c  | 30 +
 lib/test_hexdump.c | 60 +-
 3 files changed, 68 insertions(+), 23 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 04416e788802..ffc94bedd737 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -490,6 +490,7 @@ enum {
 #define HEXDUMP_2_GRP_SPACES   BIT(5)
 #define HEXDUMP_4_GRP_SPACES   BIT(6)
 #define HEXDUMP_8_GRP_SPACES   BIT(7)
+#define HEXDUMP_RETAIN_BYTE_ORDER  BIT(8)
 
 extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
  int groupsize, char *linebuf, size_t linebuflen,
diff --git a/lib/hexdump.c b/lib/hexdump.c
index dc85ef0dbb0a..ce14abc7701f 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -127,7 +127,8 @@ static void separator_parameters(u64 flags, int groupsize, 
int *sep_chars,
  * @buf: data blob to dump
  * @len: number of bytes in the @buf
  * @rowsize: number of bytes to print per line; must be a multiple of groupsize
- * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
+ * @groupsize: number of bytes to convert to a native endian number and print:
+ *1, 2, 4, 8; default = 1
  * @linebuf: where to put the converted data
  * @linebuflen: total size of @linebuf, including space for terminating NUL
  * @flags: A bitwise OR of the following flags:
@@ -138,6 +139,9 @@ static void separator_parameters(u64 flags, int groupsize, 
int *sep_chars,
  * HEXDUMP_2_GRP_SPACES:   insert a ' ' after every 2 groups
  * HEXDUMP_4_GRP_SPACES:   insert a ' ' after every 4 groups
  * HEXDUMP_8_GRP_SPACES:   insert a ' ' after every 8 groups
+ * HEXDUMP_RETAIN_BYTE_ORDER:  Retain the byte ordering of groups
+ * instead of treating each group as a
+ * native-endian number
  *
  * hex_dump_to_buffer() works on one "line" of output at a time, converting
  *  bytes of input to hexadecimal (and optionally printable ASCII)
@@ -171,6 +175,7 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
int ret;
int sep_chars = 0;
char sep = 0;
+   bool big_endian = (flags & HEXDUMP_RETAIN_BYTE_ORDER) ? 1 : 0;
 
if (!is_power_of_2(groupsize) || groupsize > 8)
groupsize = 1;
@@ -202,10 +207,13 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
const u64 *ptr8 = buf;
 
for (j = 0; j < ngroups; j++) {
+   u64 val = big_endian ?
+   be64_to_cpu(get_unaligned(ptr8 + j)) :
+   get_unaligned(ptr8 + j);
ret = snprintf(linebuf + lx, linebuflen - lx,
   "%s%16.16llx",
   j ? group_separator(j, flags) : "",
-  get_unaligned(ptr8 + j));
+  val);
if (ret >= linebuflen - lx)
goto overflow1;
lx += ret;
@@ -214,10 +222,14 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
const u32 *ptr4 = buf;
 
for (j = 0; j < ngroups; j++) {
+   u32 val = big_endian ?
+   be32_to_cpu(get_unaligned(ptr4 + j)) :
+   get_unaligned(ptr4 + j);
+
ret = snprintf(linebuf + lx, linebuflen - lx,
   "%s%8.8x",
   j ? group_separator(j, flags) : "",
-  get_unaligned(ptr4 + j));
+  val);
if (ret >= linebuflen - lx)
goto overflow1;
lx += ret;
@@ -226,10 +238,14 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
const u16 *ptr2 = buf;
 
for (j = 0; j < ngroups; j++) {
+   u16 val = big_endian ?
+   be16_to_cpu(get_unaligned(ptr2 + j)) :
+   get_unaligned(ptr2 + j);
+
ret = snprintf(linebuf + lx, linebuflen - lx,
   "%s%4.4x",
   

[PATCH v3 2/7] lib/hexdump.c: Relax rowsize checks in hex_dump_to_buffer

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

This patch removes the hardcoded row limits and allows for
other lengths. These lengths must still be a multiple of
groupsize.

This allows structs that are not 16/32 bytes to display on
a single line.

This patch also expands the self-tests to test row sizes
up to 64 bytes (though they can now be arbitrarily long).

Signed-off-by: Alastair D'Silva 
---
 lib/hexdump.c  | 48 --
 lib/test_hexdump.c | 52 ++
 2 files changed, 75 insertions(+), 25 deletions(-)

diff --git a/lib/hexdump.c b/lib/hexdump.c
index 81b70ed37209..3943507bc0e9 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 const char hex_asc[] = "0123456789abcdef";
@@ -80,14 +81,15 @@ EXPORT_SYMBOL(bin2hex);
  * hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
  * @buf: data blob to dump
  * @len: number of bytes in the @buf
- * @rowsize: number of bytes to print per line; must be 16 or 32
+ * @rowsize: number of bytes to print per line; must be a multiple of groupsize
  * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
  * @linebuf: where to put the converted data
  * @linebuflen: total size of @linebuf, including space for terminating NUL
  * @ascii: include ASCII after the hex output
  *
- * hex_dump_to_buffer() works on one "line" of output at a time, i.e.,
- * 16 or 32 bytes of input data converted to hex + ASCII output.
+ * hex_dump_to_buffer() works on one "line" of output at a time, converting
+ *  bytes of input to hexadecimal (and optionally printable ASCII)
+ * until  bytes have been emitted.
  *
  * Given a buffer of u8 data, hex_dump_to_buffer() converts the input data
  * to a hex + ASCII dump at the supplied memory location.
@@ -116,16 +118,17 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
int ascii_column;
int ret;
 
-   if (rowsize != 16 && rowsize != 32)
-   rowsize = 16;
-
-   if (len > rowsize)  /* limit to one line at a time */
-   len = rowsize;
if (!is_power_of_2(groupsize) || groupsize > 8)
groupsize = 1;
if ((len % groupsize) != 0) /* no mixed size output */
groupsize = 1;
 
+   if (rowsize % groupsize)
+   rowsize -= rowsize % groupsize;
+
+   if (len > rowsize)  /* limit to one line at a time */
+   len = rowsize;
+
ngroups = len / groupsize;
ascii_column = rowsize * 2 + rowsize / groupsize + 1;
 
@@ -216,7 +219,7 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
  *  caller supplies trailing spaces for alignment if desired
  * @prefix_type: controls whether prefix of an offset, address, or none
  *  is printed (%DUMP_PREFIX_OFFSET, %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_NONE)
- * @rowsize: number of bytes to print per line; must be 16 or 32
+ * @rowsize: number of bytes to print per line; must be a multiple of groupsize
  * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
  * @buf: data blob to dump
  * @len: number of bytes in the @buf
@@ -226,10 +229,9 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
  * to the kernel log at the specified kernel log level, with an optional
  * leading prefix.
  *
- * print_hex_dump() works on one "line" of output at a time, i.e.,
- * 16 or 32 bytes of input data converted to hex + ASCII output.
  * print_hex_dump() iterates over the entire input @buf, breaking it into
- * "line size" chunks to format and print.
+ * lines of rowsize/groupsize groups of input data converted to hex +
+ * (optionally) ASCII output.
  *
  * E.g.:
  *   print_hex_dump(KERN_DEBUG, "raw data: ", DUMP_PREFIX_ADDRESS,
@@ -246,17 +248,29 @@ void print_hex_dump(const char *level, const char 
*prefix_str, int prefix_type,
 {
const u8 *ptr = buf;
int i, linelen, remaining = len;
-   unsigned char linebuf[32 * 3 + 2 + 32 + 1];
+   unsigned char *linebuf;
+   unsigned int linebuf_len;
 
-   if (rowsize != 16 && rowsize != 32)
-   rowsize = 16;
+   if (rowsize % groupsize)
+   rowsize -= rowsize % groupsize;
+
+   /* Worst case line length:
+* 2 hex chars + space per byte in, 2 spaces, 1 char per byte in, NULL
+*/
+   linebuf_len = rowsize * 3 + 2 + rowsize + 1;
+   linebuf = kzalloc(linebuf_len, GFP_KERNEL);
+   if (!linebuf) {
+   printk("%s%shexdump: Could not alloc %u bytes for buffer\n",
+   level, prefix_str, linebuf_len);
+   return;
+   }
 
for (i = 0; i < len; i += rowsize) {
linelen = min(remaining, rowsize);
remaining -= rowsize;
 
hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
-  linebuf, sizeof(linebuf), ascii);
+

[PATCH v3 1/7] lib/hexdump.c: Fix selftests

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

The overflow tests did not account for the situation where no
overflow occurs and len < rowsize.

This patch renames the cryptic variables and accounts for the
above case.

The selftests now pass.

Signed-off-by: Alastair D'Silva 
---
 lib/test_hexdump.c | 47 ++
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/lib/test_hexdump.c b/lib/test_hexdump.c
index 5144899d3c6b..d78ddd62ffd0 100644
--- a/lib/test_hexdump.c
+++ b/lib/test_hexdump.c
@@ -163,45 +163,52 @@ static void __init test_hexdump_overflow(size_t buflen, 
size_t len,
 {
char test[TEST_HEXDUMP_BUF_SIZE];
char buf[TEST_HEXDUMP_BUF_SIZE];
-   int rs = rowsize, gs = groupsize;
-   int ae, he, e, f, r;
-   bool a;
+   int ascii_len, hex_len, expected_len, fill_point, ngroups, rc;
+   bool match;
 
total_tests++;
 
memset(buf, FILL_CHAR, sizeof(buf));
 
-   r = hex_dump_to_buffer(data_b, len, rs, gs, buf, buflen, ascii);
+   rc = hex_dump_to_buffer(data_b, len, rowsize, groupsize, buf, buflen, 
ascii);
 
/*
 * Caller must provide the data length multiple of groupsize. The
 * calculations below are made with that assumption in mind.
 */
-   ae = rs * 2 /* hex */ + rs / gs /* spaces */ + 1 /* space */ + len /* 
ascii */;
-   he = (gs * 2 /* hex */ + 1 /* space */) * len / gs - 1 /* no trailing 
space */;
+   ngroups = rowsize / groupsize;
+   hex_len = (groupsize * 2 /* hex */ + 1 /* spaces */) * ngroups
+ - 1 /* no trailing space */;
+   ascii_len = hex_len + 2 /* space */ + len /* ascii */;
+
+   if (len < rowsize) {
+   ngroups = len / groupsize;
+   hex_len = (groupsize * 2 /* hex */ + 1 /* spaces */) * ngroups
+ - 1 /* no trailing space */;
+   }
 
-   if (ascii)
-   e = ae;
-   else
-   e = he;
+   expected_len = (ascii) ? ascii_len : hex_len;
 
-   f = min_t(int, e + 1, buflen);
+   fill_point = min_t(int, expected_len + 1, buflen);
if (buflen) {
-   test_hexdump_prepare_test(len, rs, gs, test, sizeof(test), 
ascii);
-   test[f - 1] = '\0';
+   test_hexdump_prepare_test(len, rowsize, groupsize, test,
+ sizeof(test), ascii);
+   test[fill_point - 1] = '\0';
}
-   memset(test + f, FILL_CHAR, sizeof(test) - f);
+   memset(test + fill_point, FILL_CHAR, sizeof(test) - fill_point);
 
-   a = r == e && !memcmp(test, buf, TEST_HEXDUMP_BUF_SIZE);
+   match = rc == expected_len && !memcmp(test, buf, TEST_HEXDUMP_BUF_SIZE);
 
buf[sizeof(buf) - 1] = '\0';
 
-   if (!a) {
-   pr_err("Len: %zu buflen: %zu strlen: %zu\n",
-   len, buflen, strnlen(buf, sizeof(buf)));
-   pr_err("Result: %d '%s'\n", r, buf);
-   pr_err("Expect: %d '%s'\n", e, test);
+   if (!match) {
+   pr_err("rowsize: %u groupsize: %u ascii: %d Len: %zu buflen: 
%zu strlen: %zu\n",
+   rowsize, groupsize, ascii, len, buflen,
+   strnlen(buf, sizeof(buf)));
+   pr_err("Result: %d '%-.*s'\n", rc, (int)buflen, buf);
+   pr_err("Expect: %d '%-.*s'\n", expected_len, (int)buflen, test);
failed_tests++;
+
}
 }
 
-- 
2.21.0



[PATCH v3 5/7] lib/hexdump.c: Allow multiple groups to be separated by lines '|'

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

With the wider display format, it can become hard to identify how many
bytes into the line you are looking at.

The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
print vertical lines to separate every N groups of bytes.

eg.
buf:: 454d414e 43415053|4e495f45 00584544  NAMESPAC|E_INDEX.
buf:0010:  0002|   |

Signed-off-by: Alastair D'Silva 
---
 include/linux/printk.h |  3 +++
 lib/hexdump.c  | 59 --
 2 files changed, 54 insertions(+), 8 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 97dd29a2bd77..c6b748f66a82 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -484,6 +484,9 @@ enum {
 
 #define HEXDUMP_ASCII  BIT(0)
 #define HEXDUMP_SUPPRESS_REPEATED  BIT(1)
+#define HEXDUMP_2_GRP_LINESBIT(2)
+#define HEXDUMP_4_GRP_LINESBIT(3)
+#define HEXDUMP_8_GRP_LINESBIT(4)
 
 extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
  int groupsize, char *linebuf, size_t linebuflen,
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 08c6084d7daa..4da7d24826fb 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -77,6 +77,23 @@ char *bin2hex(char *dst, const void *src, size_t count)
 }
 EXPORT_SYMBOL(bin2hex);
 
+static const char *group_separator(int group, u64 flags)
+{
+   if (group == 0)
+   return " ";
+
+   if ((flags & HEXDUMP_8_GRP_LINES) && !((group) % 8))
+   return "|";
+
+   if ((flags & HEXDUMP_4_GRP_LINES) && !((group) % 4))
+   return "|";
+
+   if ((flags & HEXDUMP_2_GRP_LINES) && !((group) % 2))
+   return "|";
+
+   return " ";
+}
+
 /**
  * hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
  * @buf: data blob to dump
@@ -87,6 +104,9 @@ EXPORT_SYMBOL(bin2hex);
  * @linebuflen: total size of @linebuf, including space for terminating NUL
  * @flags: A bitwise OR of the following flags:
  * HEXDUMP_ASCII:  include ASCII after the hex output
+ * HEXDUMP_2_GRP_LINES:insert a '|' after every 2 groups
+ * HEXDUMP_4_GRP_LINES:insert a '|' after every 4 groups
+ * HEXDUMP_8_GRP_LINES:insert a '|' after every 8 groups
  *
  * hex_dump_to_buffer() works on one "line" of output at a time, converting
  *  bytes of input to hexadecimal (and optionally printable ASCII)
@@ -118,6 +138,7 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
int j, lx = 0;
int ascii_column;
int ret;
+   int line_chars = 0;
 
if (!is_power_of_2(groupsize) || groupsize > 8)
groupsize = 1;
@@ -144,7 +165,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
 
for (j = 0; j < ngroups; j++) {
ret = snprintf(linebuf + lx, linebuflen - lx,
-  "%s%16.16llx", j ? " " : "",
+  "%s%16.16llx",
+  j ? group_separator(j, flags) : "",
   get_unaligned(ptr8 + j));
if (ret >= linebuflen - lx)
goto overflow1;
@@ -155,7 +177,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
 
for (j = 0; j < ngroups; j++) {
ret = snprintf(linebuf + lx, linebuflen - lx,
-  "%s%8.8x", j ? " " : "",
+  "%s%8.8x",
+  j ? group_separator(j, flags) : "",
   get_unaligned(ptr4 + j));
if (ret >= linebuflen - lx)
goto overflow1;
@@ -166,7 +189,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
 
for (j = 0; j < ngroups; j++) {
ret = snprintf(linebuf + lx, linebuflen - lx,
-  "%s%4.4x", j ? " " : "",
+  "%s%4.4x",
+  j ? group_separator(j, flags) : "",
   get_unaligned(ptr2 + j));
if (ret >= linebuflen - lx)
goto overflow1;
@@ -196,11 +220,26 @@ int hex_dump_to_buffer(const void *buf, size_t len, int 
rowsize, int groupsize,
goto overflow2;
linebuf[lx++] = ' ';
}
+
+   if (flags & HEXDUMP_2_GRP_LINES)
+   line_chars = groupsize * 2;
+   if (flags & HEXDUMP_4_GRP_LINES)
+   line_chars = groupsize * 4;
+   if (flags & HEXDUMP_8_GRP_LINES)
+   line_chars = 

[PATCH v3 0/7] Hexdump Enhancements

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.

This series enhances hexdump.

These improve the readability of the dumped data in certain situations
(eg. wide terminals are available, many lines of empty bytes exist, etc).

The default behaviour of hexdump is unchanged, however, the prototype
for hex_dump_to_buffer() has changed, and print_hex_dump() has been
renamed to print_hex_dump_ext(), with a wrapper replacing it for
compatibility with existing code, which would have been too invasive to
change.

Hexdump selftests have be run & confirmed passed.

Changelog:
V3:
 - Fix inline documention
 - use BIT macros
 - use u32 rather than u64 for flags
V2:
 - Fix failing selftests
 - Fix precedence bug in 'Replace ascii bool in hex_dump_to_buffer...'
 - Remove hardcoded new lengths & instead relax the checks in
   hex_dump_to_buffer, allocating the buffer from the heap instead of the
   stack.
 - Replace the skipping of lines of 0x00/0xff with skipping lines of
   repeated characters, announcing what has been skipped.
 - Add spaces as an optional N-group separator
 - Allow byte ordering to be maintained when HEXDUMP_RETAIN_BYTE_ORDERING
   is set.
 - Updated selftests to cover 'Relax rowsize checks' &
   'Optionally retain byte ordering'

Alastair D'Silva (7):
  lib/hexdump.c: Fix selftests
  lib/hexdump.c: Relax rowsize checks in hex_dump_to_buffer
  lib/hexdump.c: Optionally suppress lines of repeated bytes
  lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
  lib/hexdump.c: Allow multiple groups to be separated by lines '|'
  lib/hexdump.c: Allow multiple groups to be separated by spaces
  lib/hexdump.c: Optionally retain byte ordering

 drivers/gpu/drm/i915/intel_engine_cs.c|   2 +-
 drivers/isdn/hardware/mISDN/mISDNisar.c   |   6 +-
 drivers/mailbox/mailbox-test.c|   2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c  |   2 +-
 .../net/ethernet/synopsys/dwc-xlgmac-common.c |   2 +-
 drivers/net/wireless/ath/ath10k/debug.c   |   3 +-
 .../net/wireless/intel/iwlegacy/3945-mac.c|   2 +-
 drivers/platform/chrome/wilco_ec/debugfs.c|   2 +-
 drivers/scsi/scsi_logging.c   |   8 +-
 drivers/staging/fbtft/fbtft-core.c|   2 +-
 fs/seq_file.c |   3 +-
 include/linux/printk.h|  34 ++-
 lib/hexdump.c | 260 +++---
 lib/test_hexdump.c| 146 +++---
 14 files changed, 372 insertions(+), 102 deletions(-)

-- 
2.21.0



[PATCH v3 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags

2019-06-16 Thread Alastair D'Silva
From: Alastair D'Silva 

In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.

Signed-off-by: Alastair D'Silva 
---
 drivers/gpu/drm/i915/intel_engine_cs.c|  2 +-
 drivers/isdn/hardware/mISDN/mISDNisar.c   |  6 --
 drivers/mailbox/mailbox-test.c|  2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c  |  2 +-
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c |  2 +-
 drivers/net/wireless/ath/ath10k/debug.c   |  3 ++-
 drivers/net/wireless/intel/iwlegacy/3945-mac.c|  2 +-
 drivers/platform/chrome/wilco_ec/debugfs.c|  2 +-
 drivers/scsi/scsi_logging.c   |  8 +++-
 drivers/staging/fbtft/fbtft-core.c|  2 +-
 fs/seq_file.c |  3 ++-
 include/linux/printk.h|  8 
 lib/hexdump.c | 15 ---
 lib/test_hexdump.c|  5 +++--
 14 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index eea9bec04f1b..5df5fffdb848 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1340,7 +1340,7 @@ static void hexdump(struct drm_printer *m, const void 
*buf, size_t len)
WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
rowsize, sizeof(u32),
line, sizeof(line),
-   false) >= sizeof(line));
+   0) >= sizeof(line));
drm_printf(m, "[%04zx] %s\n", pos, line);
 
prev = buf + pos;
diff --git a/drivers/isdn/hardware/mISDN/mISDNisar.c 
b/drivers/isdn/hardware/mISDN/mISDNisar.c
index fd5c52f37802..ccc0ee9d894f 100644
--- a/drivers/isdn/hardware/mISDN/mISDNisar.c
+++ b/drivers/isdn/hardware/mISDN/mISDNisar.c
@@ -71,7 +71,8 @@ send_mbox(struct isar_hw *isar, u8 his, u8 creg, u8 len, u8 
*msg)
 
while (l < (int)len) {
hex_dump_to_buffer(msg + l, len - l, 32, 1,
-  isar->log, 256, 1);
+  isar->log, 256,
+  HEXDUMP_ASCII);
pr_debug("%s: %s %02x: %s\n", isar->name,
 __func__, l, isar->log);
l += 32;
@@ -100,7 +101,8 @@ rcv_mbox(struct isar_hw *isar, u8 *msg)
 
while (l < (int)isar->clsb) {
hex_dump_to_buffer(msg + l, isar->clsb - l, 32,
-  1, isar->log, 256, 1);
+  1, isar->log, 256,
+  HEXDUMP_ASCII);
pr_debug("%s: %s %02x: %s\n", isar->name,
 __func__, l, isar->log);
l += 32;
diff --git a/drivers/mailbox/mailbox-test.c b/drivers/mailbox/mailbox-test.c
index 4555d678fadd..23c3fbafdcb2 100644
--- a/drivers/mailbox/mailbox-test.c
+++ b/drivers/mailbox/mailbox-test.c
@@ -209,7 +209,7 @@ static ssize_t mbox_test_message_read(struct file *filp, 
char __user *userbuf,
hex_dump_to_buffer(ptr,
   MBOX_BYTES_PER_LINE,
   MBOX_BYTES_PER_LINE, 1, touser + l,
-  MBOX_HEXDUMP_LINE_LEN, true);
+  MBOX_HEXDUMP_LINE_LEN, HEXDUMP_ASCII);
 
ptr += MBOX_BYTES_PER_LINE;
l += MBOX_HEXDUMP_LINE_LEN;
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c 
b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index 3dd0cecddba8..1e26410cf6c2 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -2992,7 +2992,7 @@ void xgbe_print_pkt(struct net_device *netdev, struct 
sk_buff *skb, bool tx_rx)
unsigned int len = min(skb->len - i, 32U);
 
hex_dump_to_buffer(>data[i], len, 32, 1,
-  buffer, sizeof(buffer), false);
+  buffer, sizeof(buffer), 0);
netdev_dbg(netdev, "  %#06x: %s\n", i, buffer);
}
 
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index eb1c6b03c329..b80adfa1f890 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -349,7 +349,7 @@ void xlgmac_print_pkt(struct net_device *netdev,
unsigned int len = min(skb->len - i, 

Re: [PATCH v3, 19/27] drm/mediatek: add function to background color input select for ovl/ovl_2l direct link

2019-06-16 Thread CK Hu
Hi, Yongqiang:

On Wed, 2019-06-05 at 19:42 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu 
> 
> This patch add function to background color input select for ovl/ovl_2l 
> direct link
> for ovl/ovl_2l direct link usecase, we need set background color
> input select for these hardware.
> this is preparation patch for ovl/ovl_2l usecase
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 158c1e5..aa1e183 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -92,6 +92,9 @@ struct mtk_ddp_comp_funcs {
>struct mtk_plane_state *state);
>   void (*gamma_set)(struct mtk_ddp_comp *comp,
> struct drm_crtc_state *state);
> + void (*bgclr_in_on)(struct mtk_ddp_comp *comp,
> + enum mtk_ddp_comp_id prev);

prev is useless, so remove it.

Regards,
CK

> + void (*bgclr_in_off)(struct mtk_ddp_comp *comp);
>  };
>  
>  struct mtk_ddp_comp {
> @@ -173,6 +176,19 @@ static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp 
> *comp,
>   comp->funcs->gamma_set(comp, state);
>  }
>  
> +static inline void mtk_ddp_comp_bgclr_in_on(struct mtk_ddp_comp *comp,
> + enum mtk_ddp_comp_id prev)
> +{
> + if (comp->funcs && comp->funcs->bgclr_in_on)
> + comp->funcs->bgclr_in_on(comp, prev);
> +}
> +
> +static inline void mtk_ddp_comp_bgclr_in_off(struct mtk_ddp_comp *comp)
> +{
> + if (comp->funcs && comp->funcs->bgclr_in_off)
> + comp->funcs->bgclr_in_off(comp);
> +}
> +
>  int mtk_ddp_comp_get_id(struct device_node *node,
>   enum mtk_ddp_comp_type comp_type);
>  int mtk_ddp_comp_init(struct device *dev, struct device_node *comp_node,




linux-next: manual merge of the net-next tree with the net tree

2019-06-16 Thread Stephen Rothwell
Hi all,

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

  net/wireless/nl80211.c

between commit:

  180aa422ef27 ("nl80211: fill all policy .type entries")

from the net tree and commit:

  1a28ed213696 ("nl80211: fill all policy .type entries")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell


pgphZmoo04Fb9.pgp
Description: OpenPGP digital signature


Re: [PATCH v2 1/2] x86/mm: Identify the end of the kernel area to be reserved

2019-06-16 Thread Baoquan He
On 06/14/19 at 09:15pm, Lendacky, Thomas wrote:
> The memory occupied by the kernel is reserved using memblock_reserve()
> in setup_arch(). Currently, the area is from symbols _text to __bss_stop.
> Everything after __bss_stop must be specifically reserved otherwise it
> is discarded. This is not clearly documented.
> 
> Add a new symbol, __end_of_kernel_reserve, that more readily identifies
> what is reserved, along with comments that indicate what is reserved,
> what is discarded and what needs to be done to prevent a section from
> being discarded.
> 
> Cc: Baoquan He 
> Cc: Lianbo Jiang 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/sections.h | 2 ++
>  arch/x86/kernel/setup.c | 8 +++-
>  arch/x86/kernel/vmlinux.lds.S   | 9 -
>  3 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
> index 8ea1cfdbeabc..71b32f2570ab 100644
> --- a/arch/x86/include/asm/sections.h
> +++ b/arch/x86/include/asm/sections.h
> @@ -13,4 +13,6 @@ extern char __end_rodata_aligned[];
>  extern char __end_rodata_hpage_align[];
>  #endif
>  
> +extern char __end_of_kernel_reserve[];
> +
>  #endif   /* _ASM_X86_SECTIONS_H */
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 08a5f4a131f5..32eb70625b3b 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -827,8 +827,14 @@ dump_kernel_offset(struct notifier_block *self, unsigned 
> long v, void *p)
>  
>  void __init setup_arch(char **cmdline_p)
>  {
> + /*
> +  * Reserve the memory occupied by the kernel between _text and
> +  * __end_of_kernel_reserve symbols. Any kernel sections after the
> +  * __end_of_kernel_reserve symbol must be explicity reserved with a
> +  * separate memblock_reserve() or it will be discarded.
> +  */
>   memblock_reserve(__pa_symbol(_text),
> -  (unsigned long)__bss_stop - (unsigned long)_text);
> +  (unsigned long)__end_of_kernel_reserve - (unsigned 
> long)_text);
>  
>   /*
>* Make sure page 0 is always reserved because on systems with
> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> index 0850b5149345..ca2252ca6ad7 100644
> --- a/arch/x86/kernel/vmlinux.lds.S
> +++ b/arch/x86/kernel/vmlinux.lds.S
> @@ -368,6 +368,14 @@ SECTIONS
>   __bss_stop = .;
>   }
>  
> + /*
> +  * The memory occupied from _text to here, __end_of_kernel_reserve, is
> +  * automatically reserved in setup_arch(). Anything after here must be
> +  * explicitly reserved using memblock_reserve() or it will be discarded
> +  * and treated as available memory.
> +  */
> + __end_of_kernel_reserve = .;
> +
>   . = ALIGN(PAGE_SIZE);
>   .brk : AT(ADDR(.brk) - LOAD_OFFSET) {
>   __brk_base = .;
> @@ -382,7 +390,6 @@ SECTIONS
>   STABS_DEBUG
>   DWARF_DEBUG
>  
> - /* Sections to be discarded */
>   DISCARDS
>   /DISCARD/ : {
>   *(.eh_frame)

Looks good to me, thanks. To the series,

Reviewed-by: Baoquan He 

Thanks
Baoquan



linux-next: manual merge of the net-next tree with the net tree

2019-06-16 Thread Stephen Rothwell
Hi all,

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

  net/vmw_vsock/hyperv_transport.c

between commit:

  d424a2afd7da ("hv_sock: Suppress bogus "may be used uninitialized" warnings")

from the net tree and commit:

  ac383f58f3c9 ("hv_sock: perf: Allow the socket buffer size options to 
influence the actual socket buffers")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell


pgpRf5fBv9GDR.pgp
Description: OpenPGP digital signature


RE: [EXT] Re: [v1 1/4] dt-bindings: display: Add DT bindings for LS1028A HDP-TX PHY.

2019-06-16 Thread Wen He


> -Original Message-
> From: Rob Herring 
> Sent: 2019年6月14日 4:08
> To: Wen He 
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; shawn...@kernel.org; Leo Li
> 
> Subject: [EXT] Re: [v1 1/4] dt-bindings: display: Add DT bindings for LS1028A
> HDP-TX PHY.
> 
> Caution: EXT Email
> 
> On Wed, May 08, 2019 at 10:35:25AM +, Wen He wrote:
> > Add DT bindings documentmation for the HDP-TX PHY controller. The
> > describes which could be found on NXP Layerscape ls1028a platform.
> 
> Drop the hard stop (.) from the subject.
> 
> >
> > Signed-off-by: Wen He 
> > ---
> >  .../devicetree/bindings/display/fsl,hdp.txt   | 56 +++
> >  1 file changed, 56 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/fsl,hdp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/fsl,hdp.txt
> > b/Documentation/devicetree/bindings/display/fsl,hdp.txt
> > new file mode 100644
> > index ..36b5687a1261
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/fsl,hdp.txt
> > @@ -0,0 +1,56 @@
> > +NXP Layerscpae ls1028a HDP-TX PHY Controller
> > +
> > +
> > +The following bindings describe the Cadence HDP TX PHY on ls1028a
> > +that offer multi-protocol support of standars such as eDP and
> > +Displayport, supports for 25-600MHz pixel clock and up to 4k2k at 60MHz
> resolution.
> > +The HDP transmitter is a Cadence HDP TX controller IP with a
> > +companion PHY IP.
> 
> I'm confused. This binding covers both blocks or is just one of them?
> 

Hi Rob,

This binding covers both blocks(HDP TX PHY and HDP TX Controller), 
Because they are belong to the one IP.

> > +
> > +Required properties:
> > +  - compatible:   Should be "fsl,ls1028a-dp" for ls1028a.
> > +  - reg:  Physical base address and size of the block of registers
> used
> > +  by the processor.
> > +  - interrupts:   HDP hotplug in/out detect interrupt number
> > +  - clocks:   A list of phandle + clock-specifier pairs, one for each
> entry
> > +  in 'clock-names'
> > +  - clock-names:  A list of clock names. It should contain:
> > +  - "clk_ipg": inter-Integrated circuit clock
> > +  - "clk_core": for the Main Display TX controller clock
> > +  - "clk_pxl": for the pixel clock feeding the output PLL of the 
> > processor
> > +  - "clk_pxl_mux": for the high PerfPLL bypass clock
> > +  - "clk_pxl_link": for the link rate pixel clock
> > +  - "clk_apb": for the APB interface clock
> > +  - "clk_vif": for the Video pixel clock
> 
> The 'clk_' part is redundant.
> 

You mean should I remove these 'clk_' part?

Thanks for the review.

Best Regards,
Wen

> > +
> > +Required sub-nodes:
> > +  - port: The HDP connection to an encoder output port. The connection
> > +is modelled using the OF graph bindings specified in
> > +Documentation/devicetree/bindings/graph.txt
> > +
> > +
> > +Example:
> > +
> > +/ {
> > +...
> > +
> > + hdp: display@f20 {
> > +compatible = "fsl,ls1028a-dp";
> > + reg = <0x0 0xf1f 0x0 0x>,
> > + <0x0 0xf20 0x0 0xf>;
> > +interrupts = <0 221 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <>, <>, <>,
> > + <>, <>, <>, <>;
> > + clock-names = "clk_ipg", "clk_core", "clk_pxl",
> > +  "clk_pxl_mux", "clk_pxl_link", "clk_apb",
> > +  "clk_vif";
> > +
> > + port {
> > + dp1_output: endpoint {
> > + remote-endpoint = <_input>;
> > + };
> > + };
> > +};
> > +
> > +...
> > +};
> > --
> > 2.17.1
> >


linux-next: manual merge of the net-next tree with Linus' tree

2019-06-16 Thread Stephen Rothwell
Hi all,

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

  net/mac80211/cfg.c

between commit:

  28c61a66abd6 ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 
432")

from Linus' tree and commit:

  bd718fc11d5b ("mac80211: use STA info in rate_control_send_low()")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc net/mac80211/cfg.c
index a1973a26c7fc,fcf1dfc3a1cc..
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@@ -5,7 -4,9 +5,7 @@@
   * Copyright 2006-2010Johannes Berg 
   * Copyright 2013-2015  Intel Mobile Communications GmbH
   * Copyright (C) 2015-2017 Intel Deutschland GmbH
-  * Copyright (C) 2018 Intel Corporation
+  * Copyright (C) 2018-2019 Intel Corporation
 - *
 - * This file is GPLv2 as found in COPYING.
   */
  
  #include 


pgpNM26gTZGzk.pgp
Description: OpenPGP digital signature


Re: LTP hugemmap05 test case failure on arm64 with linux-next (next-20190613)

2019-06-16 Thread Qian Cai



> On Jun 16, 2019, at 9:32 PM, Anshuman Khandual  
> wrote:
> 
> Hello Qian,
> 
> On 06/14/2019 05:45 PM, Qian Cai wrote:
>> On Fri, 2019-06-14 at 11:20 +0100, Will Deacon wrote:
>>> Hi Qian,
>>> 
>>> On Thu, Jun 13, 2019 at 05:34:01PM -0400, Qian Cai wrote:
 LTP hugemmap05 test case [1] could not exit itself properly and then 
 degrade
 the
 system performance on arm64 with linux-next (next-20190613). The bisection
 so
 far indicates,
 
 BAD:  30bafbc357f1 Merge remote-tracking branch 'arm64/for-next/core'
 GOOD: 0c3d124a3043 Merge remote-tracking branch 
 'arm64-fixes/for-next/fixes'
>>> 
>>> Did you finish the bisection in the end? Also, what config are you using
>>> (you usually have something fairly esoteric ;)?
>> 
>> No, it is still running.
>> 
>> https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
>> 
> 
> Were you able to bisect the problem till a particular commit ?

Not yet, it turned out the test case needs to run a few times (usually within 
5) to reproduce, so the previous bisection was totally wrong where it assume 
the bad commit will fail every time. Once reproduced, the test case becomes 
unkillable stuck in the D state.

I am still in the middle of running a new round of bisection. The current 
progress is,

35c99ffa20ed GOOD (survived 20 times)
def0fdae813d BAD

linux-next: manual merge of the net-next tree with the sh tree

2019-06-16 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the net-next tree got conflicts in:

  arch/sh/configs/se7712_defconfig
  arch/sh/configs/se7721_defconfig
  arch/sh/configs/titan_defconfig

between commit:

  7c04efc8d2ef ("sh: configs: Remove useless UEVENT_HELPER_PATH")

from the sh tree and commit:

  a51486266c3b ("net: sched: remove NET_CLS_IND config option")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/sh/configs/se7712_defconfig
index 6ac7d362e106,1e116529735f..
--- a/arch/sh/configs/se7712_defconfig
+++ b/arch/sh/configs/se7712_defconfig
@@@ -63,7 -63,7 +63,6 @@@ CONFIG_NET_SCH_NETEM=
  CONFIG_NET_CLS_TCINDEX=y
  CONFIG_NET_CLS_ROUTE4=y
  CONFIG_NET_CLS_FW=y
- CONFIG_NET_CLS_IND=y
 -CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
  CONFIG_MTD=y
  CONFIG_MTD_BLOCK=y
  CONFIG_MTD_CFI=y
diff --cc arch/sh/configs/se7721_defconfig
index ffd15acc2a04,c66e512719ab..
--- a/arch/sh/configs/se7721_defconfig
+++ b/arch/sh/configs/se7721_defconfig
@@@ -62,7 -62,7 +62,6 @@@ CONFIG_NET_SCH_NETEM=
  CONFIG_NET_CLS_TCINDEX=y
  CONFIG_NET_CLS_ROUTE4=y
  CONFIG_NET_CLS_FW=y
- CONFIG_NET_CLS_IND=y
 -CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
  CONFIG_MTD=y
  CONFIG_MTD_BLOCK=y
  CONFIG_MTD_CFI=y
diff --cc arch/sh/configs/titan_defconfig
index 1c1c78e74fbb,171ab05ce4fc..
--- a/arch/sh/configs/titan_defconfig
+++ b/arch/sh/configs/titan_defconfig
@@@ -142,7 -142,7 +142,6 @@@ CONFIG_GACT_PROB=
  CONFIG_NET_ACT_MIRRED=m
  CONFIG_NET_ACT_IPT=m
  CONFIG_NET_ACT_PEDIT=m
- CONFIG_NET_CLS_IND=y
 -CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
  CONFIG_FW_LOADER=m
  CONFIG_CONNECTOR=m
  CONFIG_MTD=m


pgptSG718LfBZ.pgp
Description: OpenPGP digital signature


[PATCH v2 3/3] x86/acpi/cstate: add Zhaoxin processors support for cache flush policy in C3

2019-06-16 Thread Tony W Wang-oc
Same as Intel, Zhaoxin MP CPUs support C3 share cache and on all
recent Zhaoxin platforms ARB_DISABLE is a nop. So set related
flags correctly in the same way as Intel does.

Signed-off-by: Tony W Wang-oc 
---
 arch/x86/kernel/acpi/cstate.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index a5e5484..caf2edc 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -64,6 +64,21 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
c->x86_stepping >= 0x0e))
flags->bm_check = 1;
}
+
+   if (c->x86_vendor == X86_VENDOR_ZHAOXIN) {
+   /*
+* All Zhaoxin CPUs that support C3 share cache.
+* And caches should not be flushed by software while
+* entering C3 type state.
+*/
+   flags->bm_check = 1;
+   /*
+* On all recent Zhaoxin platforms, ARB_DISABLE is a nop.
+* So, set bm_control to zero to indicate that ARB_DISABLE
+* is not required while entering C3 type state.
+*/
+   flags->bm_control = 0;
+   }
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 
-- 
2.7.4


[PATCH v2 2/3] ACPI, x86: add Zhaoxin processors support for NONSTOP TSC

2019-06-16 Thread Tony W Wang-oc
Zhaoxin CPUs have NONSTOP TSC feature, so enable the ACPI
driver support for it.

Signed-off-by: Tony W Wang-oc 
---
 drivers/acpi/acpi_pad.c   | 1 +
 drivers/acpi/processor_idle.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index a47676a..c06306e 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -73,6 +73,7 @@ static void power_saving_mwait_init(void)
case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
+   case X86_VENDOR_ZHAOXIN:
/*
 * AMD Fam10h TSC will tick in all
 * C/P/S0/S1 states when this bit is set.
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 98d4ec5..fa95ce9 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -209,6 +209,7 @@ static void tsc_check_state(int state)
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
case X86_VENDOR_CENTAUR:
+   case X86_VENDOR_ZHAOXIN:
/*
 * AMD Fam10h TSC will tick in all
 * C/P/S0/S1 states when this bit is set.
-- 
2.7.4


Re: LTP hugemmap05 test case failure on arm64 with linux-next (next-20190613)

2019-06-16 Thread Anshuman Khandual
Hello Qian,

On 06/14/2019 05:45 PM, Qian Cai wrote:
> On Fri, 2019-06-14 at 11:20 +0100, Will Deacon wrote:
>> Hi Qian,
>>
>> On Thu, Jun 13, 2019 at 05:34:01PM -0400, Qian Cai wrote:
>>> LTP hugemmap05 test case [1] could not exit itself properly and then degrade
>>> the
>>> system performance on arm64 with linux-next (next-20190613). The bisection
>>> so
>>> far indicates,
>>>
>>> BAD:  30bafbc357f1 Merge remote-tracking branch 'arm64/for-next/core'
>>> GOOD: 0c3d124a3043 Merge remote-tracking branch 'arm64-fixes/for-next/fixes'
>>
>> Did you finish the bisection in the end? Also, what config are you using
>> (you usually have something fairly esoteric ;)?
> 
> No, it is still running.
> 
> https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
> 

Were you able to bisect the problem till a particular commit ?

- Anshuman


答复: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.

2019-06-16 Thread Xiaoxiao Liu
Hi Pali,

Since design architecture change of CS19, input device connection has been 
changed to below architecture, 
Touchpad has been moved to I2C connection.

  kernel/host  <--PS/2-->  EC  <--PS/2-->  external PS/2 mouse
   | |
   |<--PS/2-->  trackstick
   |
<--I2C-->  Touchpad

In the past TrackPoint does not show in the device list because of TrackPoint 
was hidden device of Touchpad.
But from CS19, TrackPoint is directly connecting with PS2 port, 
3 bytes packet does not need to take affect by other vendors Touchpad format. 
So alps.c is no need for CS19 device.

Best Regards
Shona
-邮件原件-
发件人: Pali Rohár  
发送时间: Wednesday, June 12, 2019 1:39 AM
收件人: dmitry.torok...@gmail.com
抄送: Hui Wang ; 劉 曉曉 Xiaoxiao Liu 
; XiaoXiao Liu ; 
peter.hutte...@who-t.net; linux-in...@vger.kernel.org; 
linux-kernel@vger.kernel.org; 曹 曉建 Xiaojian Cao ; 
zhang...@lenovo.com; 斉藤 直樹 Naoki Saito ; 川瀬 英夫 
Hideo Kawase 
主题: Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do 
not work.

On Tuesday 11 June 2019 10:32:28 dmitry.torok...@gmail.com wrote:
> On Tue, Jun 11, 2019 at 07:17:07PM +0200, Pali Rohár wrote:
> > On Tuesday 11 June 2019 10:07:07 dmitry.torok...@gmail.com wrote:
> > > On Tue, Jun 11, 2019 at 09:23:33AM +0200, Pali Rohár wrote:
> > > > On Tuesday 11 June 2019 12:32:33 Hui Wang wrote:
> > > > > On 2019/6/11 上午11:23, Hui Wang wrote:
> > > > > > On 2019/6/11 上午11:05, Xiaoxiao Liu wrote:
> > > > > > > Hi Pali,
> > > > > > > 
> > > > > > > I discussed with our FW team about this problem.
> > > > > > > We think the V8 method means a touchpad feature  and does 
> > > > > > > not fit the CS19 trackpoint device.
> > > > > > > CS19 TrackPoint needn't  use any Absolute (Raw) mode and 
> > > > > > > is usually use standard mouse data.
> > > > > > > CS19 TrackPoint device is a completely different device 
> > > > > > > with DualPoint device of Dell/HP.
> > > > > > > CS19 TrackPoint device is independent  of Touchpad. 
> > > > > > > (Touchpad is connecting by I2C, TrackPoint is directly 
> > > > > > > connecting with PS2 port.) And it has completely another FW.
> > > > > > > 
> > > > > > > So we think it is better to use the mouse mode for CS19 
> > > > > > > trackpoint.
> > > > > > 
> > > > > > Maybe here is some mis-understanding,  the mouse mode here 
> > > > > > doesn't mean we use psmouse-base.c for cs19 (bare ps/2 
> > > > > > mouse), we plan to use trackpoint.c to drive this HW, so 
> > > > > > this trackpoint has all features a trackpoint should have.
> > > > > > 
> > > > > And I sent a patch one month ago to let the the trackpoint.c 
> > > > > to drive this
> > > > > HW: https://www.spinics.net/lists/linux-input/msg61341.html, 
> > > > > maybe that patch is reference.
> > > > 
> > > > So instead of creating blacklist, you should check for 
> > > > TP_VARIANT_ALPS in alps.c and disallow its usage.
> > > > 
> > > > Or maybe better, move trackpoint.c detect code before alsp.c 
> > > > detect code in psmouse-base. And no changes in alps.c are needed.
> > > 
> > > I'd be very cautions of moving around the protocol detection. It 
> > > is very fragile, so if we can detect trackpoint-only case in 
> > > alps.c and skip on to trackpoint I would prefer it.
> > 
> > The main problem is that proposed trackpoint-only check in alps.c is 
> > basically what trackpoint.c is doing for checking if device is 
> > trackpoint (via function trackpoint_start_protocol()).
> > 
> > So I'm not sure now what is the best solution...
> 
> Unfortunately currently trackpoint is being probed only after we tried 
> Elan, Genius, and Logitech PS2++ protocols, and I am not sure if 
> moving trackpoint around will disturb them or not.
> 
> I do not think there is much code duplication by pulling limited 
> version of trackpoint detection code into alps.c and then have it bail 
> out when it sees trackpoint-only device so trackpoint.c can handle it 
> properly.

Ok. Seems that it is the best solution.

The last question is, should be use ALPS or Trackpoint protocol? Because it 
looks like that device can be configured to one or other.

What are pros and cons of these two protocols?

--
Pali Rohár
pali.ro...@gmail.com


Re: [PATCH] staging: iio: adt7316: Add missing include files

2019-06-16 Thread Yuehaibing
On 2019/6/16 21:11, Jonathan Cameron wrote:
> On Fri, 14 Jun 2019 23:28:46 +0800
> YueHaibing  wrote:
> 
>> Fix build error:
>>
>> drivers/staging/iio/addac/adt7316.c: In function adt7316_store_update_DAC:
>> drivers/staging/iio/addac/adt7316.c:949:3: error: implicit declaration of
>>  function gpiod_set_value; did you mean gpio_set_value? 
>> [-Werror=implicit-function-declaration]
>>gpiod_set_value(chip->ldac_pin, 0);
>>
>> drivers/staging/iio/addac/adt7316.c: In function adt7316_setup_irq:
>> drivers/staging/iio/addac/adt7316.c:1807:13: error: implicit declaration of
>>  function irqd_get_trigger_type; did you mean devm_iio_trigger_free? 
>> [-Werror=implicit-function-declaration]
>>   irq_type = irqd_get_trigger_type(irq_get_irq_data(chip->bus.irq));
>>
>> Reported-by: Hulk Robot 
>> Fixes: 7f6b6d553df7 ("Staging: iio: adt7316: Add all irq related code in 
>> adt7316_irq_setup()")
>> Fixes: c63460c4298f ("Staging: iio: adt7316: Use device tree data to set 
>> ldac_pin")
>> Signed-off-by: YueHaibing 
> Hi yuehaibing,
> 
> You were second to send a fix for this. I've had it in my
> fixes branch since last week, but not done a pull request quite yet.
> I'll probably send it out later today.

Sorry, our robot report this again and I forgot this ...

> 
> https://patchwork.kernel.org/patch/10978301/
> 
> Thanks,
> 
> Jonathan
> 
>> ---
>>  drivers/staging/iio/addac/adt7316.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/staging/iio/addac/adt7316.c 
>> b/drivers/staging/iio/addac/adt7316.c
>> index 37ce563..9d3d159 100644
>> --- a/drivers/staging/iio/addac/adt7316.c
>> +++ b/drivers/staging/iio/addac/adt7316.c
>> @@ -16,6 +16,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  
>>  #include 
>>  #include 
> 
> 
> .
> 



Re: [EXTERNAL] Re: [PATCH 1/1] drm/bochs: Fix connector leak during driver unload

2019-06-16 Thread Sam Bobroff
On Tue, May 21, 2019 at 10:10:29AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> The bug is in the driver, so ...
> 
> > Bisecting the issue for commits to drivers/gpu/drm/bochs/ points to:
> > 6579c39594ae ("drm/bochs: atomic: switch planes to atomic, wire up 
> > helpers.")
> > ... but the issue also seems to be due to a change in the generic drm code
> 
> ... this one is the culprit and should be listed.
> 
> > (reverting it separately fixes the issue):
> > 846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in 
> > drm_atomic_remove_fb, v2.")
> > ... so I've included both in the commit.  Is that the right thing to do?
> 
> That only triggers the driver bug.
> 
> I'll fix it up on commit,
>   Gerd

Sorry if I misunderstood, but were you going to take the patch and fix
it up or would you like me to post a v2?

Cheers,
Sam.



signature.asc
Description: PGP signature


Re: [PATCH v8 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function

2019-06-16 Thread CK Hu
Hi, Bibby:

On Wed, 2019-06-12 at 16:53 +0800, Bibby Hsieh wrote:
> GCE cannot know the register base address, this function
> can help cmdq client to get the cmdq_client_reg structure.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c | 24 
>  include/linux/soc/mediatek/mtk-cmdq.h  | 20 
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 70ad4d806fac..fac4d33fd520 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -27,6 +27,30 @@ struct cmdq_instruction {
>   u8 op;
>  };
>  
> +int cmdq_dev_get_client_reg(struct device *dev,
> + struct cmdq_client_reg *client_reg, int idx)
> +{
> + struct of_phandle_args spec;
> +
> + if (!client_reg)
> + return -EINVAL;
> +
> + if (of_parse_phandle_with_args(dev->of_node, "mediatek,gce-client-reg",
> +"#subsys-cells", idx, )) {
> + dev_err(dev, "can't parse gce-client-reg property (%d)", idx);
> +
> + return -EINVAL;

of_parse_phandle_with_args() may return -ENOENT, why do you change it to
-EINVAL?

Regards,
CK

> + }
> +
> + client_reg->subsys = spec.args[0];
> + client_reg->offset = spec.args[1];
> + client_reg->size = spec.args[2];
> + of_node_put(spec.np);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
> +
>  static void cmdq_client_timeout(struct timer_list *t)
>  {
>   struct cmdq_client *client = from_timer(client, t, timer);
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index a345870a6d10..2e2a2274c231 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -15,6 +15,12 @@
>  
>  struct cmdq_pkt;
>  
> +struct cmdq_client_reg {
> + u8 subsys;
> + u16 offset;
> + u16 size;
> +};
> +
>  struct cmdq_client {
>   spinlock_t lock;
>   u32 pkt_cnt;
> @@ -142,4 +148,18 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, 
> cmdq_async_flush_cb cb,
>   */
>  int cmdq_pkt_flush(struct cmdq_pkt *pkt);
>  
> +/**
> + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device node of 
> CMDQ client
> + * @dev: device of CMDQ mailbox clienti
> + * @client_reg: CMDQ client reg pointer
> + * @idx: the index of desired reg
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Help CMDQ client pasing the cmdq client reg
> + * from the device node of CMDQ client.
> + */
> +int cmdq_dev_get_client_reg(struct device *dev,
> + struct cmdq_client_reg *client_reg, int idx);
> +
>  #endif   /* __MTK_CMDQ_H__ */




[PATCH v1 1/2] clocksource/drivers/tegra: Cycles can't be 0

2019-06-16 Thread Dmitry Osipenko
The minimum number of "cycles" is limited to 1 by
clockevents_config_and_register().

Signed-off-by: Dmitry Osipenko 
---
 drivers/clocksource/timer-tegra.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/clocksource/timer-tegra.c 
b/drivers/clocksource/timer-tegra.c
index f6a8eb0d7322..090c85358fe8 100644
--- a/drivers/clocksource/timer-tegra.c
+++ b/drivers/clocksource/timer-tegra.c
@@ -54,9 +54,7 @@ static int tegra_timer_set_next_event(unsigned long cycles,
 {
void __iomem *reg_base = timer_of_base(to_timer_of(evt));
 
-   writel_relaxed(TIMER_PTV_EN |
-  ((cycles > 1) ? (cycles - 1) : 0), /* n+1 scheme */
-  reg_base + TIMER_PTV);
+   writel_relaxed(TIMER_PTV_EN | (cycles - 1), reg_base + TIMER_PTV);
 
return 0;
 }
-- 
2.22.0



[PATCH v1 2/2] clocksource/drivers/tegra: Set up maximum limit properly

2019-06-16 Thread Dmitry Osipenko
Tegra's timer has 29 bits for the counter. The counter's value is smaller
than the actual value by 1, hence the maximum equals to 29 bits + 1.

Signed-off-by: Dmitry Osipenko 
---
 drivers/clocksource/timer-tegra.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/timer-tegra.c 
b/drivers/clocksource/timer-tegra.c
index 090c85358fe8..d0a46e10dbca 100644
--- a/drivers/clocksource/timer-tegra.c
+++ b/drivers/clocksource/timer-tegra.c
@@ -130,7 +130,7 @@ static int tegra_timer_setup(unsigned int cpu)
 
clockevents_config_and_register(>clkevt, timer_of_rate(to),
1, /* min */
-   0x1fff); /* 29 bits */
+   0x2000); /* 29 bits + 1 */
 
return 0;
 }
-- 
2.22.0



[PATCH v4 06/10] dt-bindings: memory: Add binding for NVIDIA Tegra30 External Memory Controller

2019-06-16 Thread Dmitry Osipenko
Add device-tree binding for NVIDIA Tegra30 External Memory Controller.
The binding is based on the Tegra124 EMC binding since hardware is
similar, although there are couple significant differences.

Note that the memory timing description is given in a platform-specific
form because there is no detailed information on how to convert a
typical-common DDR timing into the register values. The timing format is
borrowed from downstream kernel, hence there is no hurdle in regards to
upstreaming of memory timings for the boards.

Signed-off-by: Dmitry Osipenko 
---
 .../memory-controllers/nvidia,tegra30-emc.txt | 249 ++
 1 file changed, 249 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt
new file mode 100644
index ..c2bc1dbcaa07
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt
@@ -0,0 +1,249 @@
+NVIDIA Tegra30 SoC EMC (external memory controller)
+
+
+Required properties :
+- compatible : Should be "nvidia,tegra30-emc".
+- reg : physical base address and length of the controller's registers.
+- #address-cells : Should be 1
+- #size-cells : Should be 0
+- interrupts : Should contain EMC General interrupt.
+- clocks : Should contain EMC clock.
+- nvidia,memory-controller : phandle of the MC driver.
+
+The node should contain a "emc-timings" subnode for each supported RAM type
+(see field RAM_CODE in register PMC_STRAPPING_OPT_A), with its unit address
+being its RAM_CODE.
+
+Required properties for "emc-timings" nodes :
+- nvidia,ram-code : Should contain the value of RAM_CODE this timing set is
+used for.
+
+Each "emc-timings" node should contain a "timing" subnode for every supported
+EMC clock rate. The "timing" subnodes should have the clock rate in Hz as
+their unit address.
+
+Required properties for "timing" nodes :
+- clock-frequency : Should contain the memory clock rate in Hz.
+- The following properties contain EMC timing characterization values
+(specified in the board documentation) :
+  - nvidia,emc-auto-cal-interval : EMC_AUTO_CAL_INTERVAL
+  - nvidia,emc-mode-1 : Mode Register 1
+  - nvidia,emc-mode-2 : Mode Register 2
+  - nvidia,emc-mode-reset : Mode Register 0
+  - nvidia,emc-zcal-cnt-long : EMC_ZCAL_WAIT_CNT after clock change
+  - nvidia,emc-cfg-dyn-self-ref : dynamic self-refresh enabled
+  - nvidia,emc-cfg-periodic-qrst : FBIO "read" FIFO periodic resetting enabled
+- nvidia,emc-configuration : EMC timing characterization data. These are the
+registers (see section "18.13.2 EMC Registers" in the TRM) whose values need to
+be specified, according to the board documentation:
+
+   EMC_RC
+   EMC_RFC
+   EMC_RAS
+   EMC_RP
+   EMC_R2W
+   EMC_W2R
+   EMC_R2P
+   EMC_W2P
+   EMC_RD_RCD
+   EMC_WR_RCD
+   EMC_RRD
+   EMC_REXT
+   EMC_WEXT
+   EMC_WDV
+   EMC_QUSE
+   EMC_QRST
+   EMC_QSAFE
+   EMC_RDV
+   EMC_REFRESH
+   EMC_BURST_REFRESH_NUM
+   EMC_PRE_REFRESH_REQ_CNT
+   EMC_PDEX2WR
+   EMC_PDEX2RD
+   EMC_PCHG2PDEN
+   EMC_ACT2PDEN
+   EMC_AR2PDEN
+   EMC_RW2PDEN
+   EMC_TXSR
+   EMC_TXSRDLL
+   EMC_TCKE
+   EMC_TFAW
+   EMC_TRPAB
+   EMC_TCLKSTABLE
+   EMC_TCLKSTOP
+   EMC_TREFBW
+   EMC_QUSE_EXTRA
+   EMC_FBIO_CFG6
+   EMC_ODT_WRITE
+   EMC_ODT_READ
+   EMC_FBIO_CFG5
+   EMC_CFG_DIG_DLL
+   EMC_CFG_DIG_DLL_PERIOD
+   EMC_DLL_XFORM_DQS0
+   EMC_DLL_XFORM_DQS1
+   EMC_DLL_XFORM_DQS2
+   EMC_DLL_XFORM_DQS3
+   EMC_DLL_XFORM_DQS4
+   EMC_DLL_XFORM_DQS5
+   EMC_DLL_XFORM_DQS6
+   EMC_DLL_XFORM_DQS7
+   EMC_DLL_XFORM_QUSE0
+   EMC_DLL_XFORM_QUSE1
+   EMC_DLL_XFORM_QUSE2
+   EMC_DLL_XFORM_QUSE3
+   EMC_DLL_XFORM_QUSE4
+   EMC_DLL_XFORM_QUSE5
+   EMC_DLL_XFORM_QUSE6
+   EMC_DLL_XFORM_QUSE7
+   EMC_DLI_TRIM_TXDQS0
+   EMC_DLI_TRIM_TXDQS1
+   EMC_DLI_TRIM_TXDQS2
+   EMC_DLI_TRIM_TXDQS3
+   EMC_DLI_TRIM_TXDQS4
+   EMC_DLI_TRIM_TXDQS5
+   EMC_DLI_TRIM_TXDQS6
+   EMC_DLI_TRIM_TXDQS7
+   EMC_DLL_XFORM_DQ0
+   EMC_DLL_XFORM_DQ1
+   EMC_DLL_XFORM_DQ2
+   EMC_DLL_XFORM_DQ3
+   EMC_XM2CMDPADCTRL
+   EMC_XM2DQSPADCTRL2
+   EMC_XM2DQPADCTRL2
+   EMC_XM2CLKPADCTRL
+   EMC_XM2COMPPADCTRL
+   EMC_XM2VTTGENPADCTRL
+   EMC_XM2VTTGENPADCTRL2
+   EMC_XM2QUSEPADCTRL
+   EMC_XM2DQSPADCTRL3
+   EMC_CTT_TERM_CTRL
+   EMC_ZCAL_INTERVAL
+   EMC_ZCAL_WAIT_CNT
+   EMC_MRS_WAIT_CNT
+   EMC_AUTO_CAL_CONFIG
+   EMC_CTT
+   EMC_CTT_DURATION
+   EMC_DYN_SELF_REF_CONTROL
+   EMC_FBIO_SPARE
+   EMC_CFG_RSV
+
+Example:
+
+   

[PATCH v4 10/10] ARM: dts: tegra30: Add External Memory Controller node

2019-06-16 Thread Dmitry Osipenko
Add External Memory Controller node to the device-tree.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index e074258d4518..92c4aeafab29 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -732,6 +732,17 @@
#reset-cells = <1>;
};
 
+   memory-controller@7000f400 {
+   compatible = "nvidia,tegra30-emc";
+   reg = <0x7000f400 0x400>;
+   interrupts = ;
+   clocks = <_car TEGRA30_CLK_EMC>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   nvidia,memory-controller = <>;
+   };
+
fuse@7000f800 {
compatible = "nvidia,tegra30-efuse";
reg = <0x7000f800 0x400>;
-- 
2.22.0



[PATCH v4 04/10] memory: tegra20-emc: Include io.h instead of iopoll.h

2019-06-16 Thread Dmitry Osipenko
The register polling code was gone, but the included header change was
missed. Fix it up for consistency.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index d3e1f898d745..43aef3614b65 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.22.0



[PATCH v4 08/10] memory: tegra: Ensure timing control debug features are disabled

2019-06-16 Thread Dmitry Osipenko
Timing control debug features should be disabled at a boot time, but you
never now and hence it's better to disable them explicitly because some of
those features are crucial for the driver to do a proper thing.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/mc.c | 3 +++
 drivers/memory/tegra/mc.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index eaebe371625c..4c1492c653e1 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -660,6 +660,9 @@ static int tegra_mc_probe(struct platform_device *pdev)
} else
 #endif
{
+   /* ensure that debug features are disabled */
+   mc_writel(mc, 0x, MC_TIMING_CONTROL_DBG);
+
err = tegra_mc_setup_latency_allowance(mc);
if (err < 0) {
dev_err(>dev,
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index 0720a1d2023e..abc565b42225 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -33,6 +33,8 @@
 #define MC_EMEM_ARB_OVERRIDE   0xe8
 #define MC_EMEM_ARB_OVERRIDE_EACK_MASK 0x3
 
+#define MC_TIMING_CONTROL_DBG  0xf8
+
 #define MC_TIMING_CONTROL  0xfc
 #define MC_TIMING_UPDATE   BIT(0)
 
-- 
2.22.0



[PATCH v4 02/10] memory: tegra20-emc: Drop setting EMC rate to max on probe

2019-06-16 Thread Dmitry Osipenko
The memory frequency scaling will be managed by tegra20-devfreq driver
and PM QoS once all the prerequisite patches will get upstreamed.
The parent clock is now managed by the clock driver and we also should
assume that PLLM rate can't be changed on some devices (Galaxy Tab 10.1
for example). Altogether there is no point in touching of clock's rate
from the EMC driver.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 45 --
 1 file changed, 45 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 9ee5bef49e47..55ac3863a354 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -424,41 +424,6 @@ static int emc_setup_hw(struct tegra_emc *emc)
return 0;
 }
 
-static int emc_init(struct tegra_emc *emc, unsigned long rate)
-{
-   int err;
-
-   err = clk_set_parent(emc->emc_mux, emc->backup_clk);
-   if (err) {
-   dev_err(emc->dev,
-   "failed to reparent to backup source: %d\n", err);
-   return err;
-   }
-
-   err = clk_set_rate(emc->pll_m, rate);
-   if (err) {
-   dev_err(emc->dev,
-   "failed to change pll_m rate: %d\n", err);
-   return err;
-   }
-
-   err = clk_set_parent(emc->emc_mux, emc->pll_m);
-   if (err) {
-   dev_err(emc->dev,
-   "failed to reparent to pll_m: %d\n", err);
-   return err;
-   }
-
-   err = clk_set_rate(emc->clk, rate);
-   if (err) {
-   dev_err(emc->dev,
-   "failed to change emc rate: %d\n", err);
-   return err;
-   }
-
-   return 0;
-}
-
 static int tegra_emc_probe(struct platform_device *pdev)
 {
struct device_node *np;
@@ -550,18 +515,8 @@ static int tegra_emc_probe(struct platform_device *pdev)
goto put_backup;
}
 
-   /* set DRAM clock rate to maximum */
-   err = emc_init(emc, emc->timings[emc->num_timings - 1].rate);
-   if (err) {
-   dev_err(>dev, "failed to initialize EMC clock rate: %d\n",
-   err);
-   goto unreg_notifier;
-   }
-
return 0;
 
-unreg_notifier:
-   clk_notifier_unregister(emc->clk, >clk_nb);
 put_backup:
clk_put(emc->backup_clk);
 put_pll_m:
-- 
2.22.0



[PATCH v4 07/10] memory: tegra: Introduce Tegra30 EMC driver

2019-06-16 Thread Dmitry Osipenko
Introduce driver for the External Memory Controller (EMC) found on Tegra30
chips, it controls the external DRAM on the board. The purpose of this
driver is to program memory timing for external memory on the EMC clock
rate change.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig   |   10 +
 drivers/memory/tegra/Makefile  |1 +
 drivers/memory/tegra/mc.c  |9 +-
 drivers/memory/tegra/mc.h  |   30 +-
 drivers/memory/tegra/tegra30-emc.c | 1197 
 drivers/memory/tegra/tegra30.c |   44 +
 include/soc/tegra/mc.h |2 +-
 7 files changed, 1278 insertions(+), 15 deletions(-)
 create mode 100644 drivers/memory/tegra/tegra30-emc.c

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index 4680124ddcab..fbfbaada61a2 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -17,6 +17,16 @@ config TEGRA20_EMC
  This driver is required to change memory timings / clock rate for
  external memory.
 
+config TEGRA30_EMC
+   bool "NVIDIA Tegra30 External Memory Controller driver"
+   default y
+   depends on TEGRA_MC && ARCH_TEGRA_3x_SOC
+   help
+ This driver is for the External Memory Controller (EMC) found on
+ Tegra30 chips. The EMC controls the external DRAM on the board.
+ This driver is required to change memory timings / clock rate for
+ external memory.
+
 config TEGRA124_EMC
bool "NVIDIA Tegra124 External Memory Controller driver"
default y
diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile
index 3971a6b7c487..3d23c4261104 100644
--- a/drivers/memory/tegra/Makefile
+++ b/drivers/memory/tegra/Makefile
@@ -11,5 +11,6 @@ tegra-mc-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o
 obj-$(CONFIG_TEGRA_MC) += tegra-mc.o
 
 obj-$(CONFIG_TEGRA20_EMC)  += tegra20-emc.o
+obj-$(CONFIG_TEGRA30_EMC)  += tegra30-emc.o
 obj-$(CONFIG_TEGRA124_EMC) += tegra124-emc.o
 obj-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o
diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 163b6c69e651..eaebe371625c 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -51,9 +51,6 @@
 #define MC_EMEM_ADR_CFG 0x54
 #define MC_EMEM_ADR_CFG_EMEM_NUMDEV BIT(0)
 
-#define MC_TIMING_CONTROL  0xfc
-#define MC_TIMING_UPDATE   BIT(0)
-
 static const struct of_device_id tegra_mc_of_match[] = {
 #ifdef CONFIG_ARCH_TEGRA_2x_SOC
{ .compatible = "nvidia,tegra20-mc-gart", .data = _mc_soc },
@@ -310,7 +307,7 @@ static int tegra_mc_setup_latency_allowance(struct tegra_mc 
*mc)
return 0;
 }
 
-void tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long rate)
+int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long rate)
 {
unsigned int i;
struct tegra_mc_timing *timing = NULL;
@@ -325,11 +322,13 @@ void tegra_mc_write_emem_configuration(struct tegra_mc 
*mc, unsigned long rate)
if (!timing) {
dev_err(mc->dev, "no memory timing registered for rate %lu\n",
rate);
-   return;
+   return -EINVAL;
}
 
for (i = 0; i < mc->soc->num_emem_regs; ++i)
mc_writel(mc, timing->emem_data[i], mc->soc->emem_regs[i]);
+
+   return 0;
 }
 
 unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc)
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index 392993955c93..0720a1d2023e 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -9,20 +9,32 @@
 #ifndef MEMORY_TEGRA_MC_H
 #define MEMORY_TEGRA_MC_H
 
+#include 
 #include 
 #include 
 
 #include 
 
-#define MC_INT_DECERR_MTS (1 << 16)
-#define MC_INT_SECERR_SEC (1 << 13)
-#define MC_INT_DECERR_VPR (1 << 12)
-#define MC_INT_INVALID_APB_ASID_UPDATE (1 << 11)
-#define MC_INT_INVALID_SMMU_PAGE (1 << 10)
-#define MC_INT_ARBITRATION_EMEM (1 << 9)
-#define MC_INT_SECURITY_VIOLATION (1 << 8)
-#define MC_INT_INVALID_GART_PAGE (1 << 7)
-#define MC_INT_DECERR_EMEM (1 << 6)
+#define MC_INT_DECERR_MTS  BIT(16)
+#define MC_INT_SECERR_SEC  BIT(13)
+#define MC_INT_DECERR_VPR  BIT(12)
+#define MC_INT_INVALID_APB_ASID_UPDATE BIT(11)
+#define MC_INT_INVALID_SMMU_PAGE   BIT(10)
+#define MC_INT_ARBITRATION_EMEMBIT(9)
+#define MC_INT_SECURITY_VIOLATION  BIT(8)
+#define MC_INT_INVALID_GART_PAGE   BIT(7)
+#define MC_INT_DECERR_EMEM BIT(6)
+
+#define MC_EMEM_ARB_OUTSTANDING_REQ0x94
+#define MC_EMEM_ARB_OUTSTANDING_REQ_MAX_MASK   0x1ff
+#define MC_EMEM_ARB_OUTSTANDING_REQ_HOLDOFF_OVERRIDE   BIT(30)
+#define MC_EMEM_ARB_OUTSTANDING_REQ_LIMIT_ENABLE   BIT(31)
+
+#define MC_EMEM_ARB_OVERRIDE   0xe8

[PATCH v4 03/10] memory: tegra20-emc: Adapt for clock driver changes

2019-06-16 Thread Dmitry Osipenko
The emc_mux clock is gone now and EMC driver should provide the clock
rounding functionality.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 55 --
 1 file changed, 45 insertions(+), 10 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 55ac3863a354..d3e1f898d745 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -138,7 +139,6 @@ struct tegra_emc {
struct completion clk_handshake_complete;
struct notifier_block clk_nb;
struct clk *backup_clk;
-   struct clk *emc_mux;
struct clk *pll_m;
struct clk *clk;
void __iomem *regs;
@@ -424,6 +424,44 @@ static int emc_setup_hw(struct tegra_emc *emc)
return 0;
 }
 
+static long emc_round_rate(unsigned long rate,
+  unsigned long min_rate,
+  unsigned long max_rate,
+  void *arg)
+{
+   struct emc_timing *timing = NULL;
+   struct tegra_emc *emc = arg;
+   unsigned int i;
+
+   min_rate = min(min_rate, emc->timings[emc->num_timings - 1].rate);
+
+   for (i = 0; i < emc->num_timings; i++) {
+   if (emc->timings[i].rate < rate && i != emc->num_timings - 1)
+   continue;
+
+   if (emc->timings[i].rate > max_rate) {
+   i = max(i, 1u) - 1;
+
+   if (emc->timings[i].rate < min_rate)
+   break;
+   }
+
+   if (emc->timings[i].rate < min_rate)
+   continue;
+
+   timing = >timings[i];
+   break;
+   }
+
+   if (!timing) {
+   dev_err(emc->dev, "no timing for rate %lu min %lu max %lu\n",
+   rate, min_rate, max_rate);
+   return -EINVAL;
+   }
+
+   return timing->rate;
+}
+
 static int tegra_emc_probe(struct platform_device *pdev)
 {
struct device_node *np;
@@ -480,18 +518,20 @@ static int tegra_emc_probe(struct platform_device *pdev)
return err;
}
 
+   tegra20_clk_set_emc_round_callback(emc_round_rate, emc);
+
emc->clk = devm_clk_get(>dev, "emc");
if (IS_ERR(emc->clk)) {
err = PTR_ERR(emc->clk);
dev_err(>dev, "failed to get emc clock: %d\n", err);
-   return err;
+   goto unset_cb;
}
 
emc->pll_m = clk_get_sys(NULL, "pll_m");
if (IS_ERR(emc->pll_m)) {
err = PTR_ERR(emc->pll_m);
dev_err(>dev, "failed to get pll_m clock: %d\n", err);
-   return err;
+   goto unset_cb;
}
 
emc->backup_clk = clk_get_sys(NULL, "pll_p");
@@ -501,13 +541,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
goto put_pll_m;
}
 
-   emc->emc_mux = clk_get_parent(emc->clk);
-   if (IS_ERR(emc->emc_mux)) {
-   err = PTR_ERR(emc->emc_mux);
-   dev_err(>dev, "failed to get emc_mux clock: %d\n", err);
-   goto put_backup;
-   }
-
err = clk_notifier_register(emc->clk, >clk_nb);
if (err) {
dev_err(>dev, "failed to register clk notifier: %d\n",
@@ -521,6 +554,8 @@ static int tegra_emc_probe(struct platform_device *pdev)
clk_put(emc->backup_clk);
 put_pll_m:
clk_put(emc->pll_m);
+unset_cb:
+   tegra20_clk_set_emc_round_callback(NULL, NULL);
 
return err;
 }
-- 
2.22.0



[PATCH v4 01/10] clk: tegra20/30: Add custom EMC clock implementation

2019-06-16 Thread Dmitry Osipenko
A proper External Memory Controller clock rounding and parent selection
functionality is required by the EMC drivers. It is not available using
the generic clock implementation, hence add a custom one. The clock rate
rounding shall be done by the EMC drivers because they have information
about available memory timings, so the drivers will have to register a
callback that will round the requested rate. EMC clock users won't be able
to request EMC clock by getting -EPROBE_DEFER until EMC driver is probed
and the callback is set up. The functionality is somewhat similar to the
clk-emc.c which serves Tegra124+ SoC's, the later HW generations support
more parent clock sources and the HW configuration and integration with
the EMC drivers differs a tad from the older gens, hence it's not really
worth to try to squash everything into a single source file.

Signed-off-by: Dmitry Osipenko 
---
 drivers/clk/tegra/Makefile  |   2 +
 drivers/clk/tegra/clk-tegra20-emc.c | 305 
 drivers/clk/tegra/clk-tegra20.c |  55 ++---
 drivers/clk/tegra/clk-tegra30.c |  38 +++-
 drivers/clk/tegra/clk.h |   6 +
 include/linux/clk/tegra.h   |  14 ++
 6 files changed, 368 insertions(+), 52 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-tegra20-emc.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index 4812e45c2214..df966ca06788 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -17,7 +17,9 @@ obj-y += clk-tegra-fixed.o
 obj-y  += clk-tegra-super-gen4.o
 obj-$(CONFIG_TEGRA_CLK_EMC)+= clk-emc.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
+obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= clk-tegra20-emc.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
+obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= clk-tegra20-emc.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
 obj-$(CONFIG_ARCH_TEGRA_124_SOC)   += clk-tegra124.o
 obj-$(CONFIG_TEGRA_CLK_DFLL)   += clk-tegra124-dfll-fcpu.o
diff --git a/drivers/clk/tegra/clk-tegra20-emc.c 
b/drivers/clk/tegra/clk-tegra20-emc.c
new file mode 100644
index ..b7f64ad5c04c
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra20-emc.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK GENMASK(7, 0)
+#define CLK_SOURCE_EMC_2X_CLK_SRC_MASK GENMASK(31, 30)
+#define CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT30
+
+#define MC_EMC_SAME_FREQ   BIT(16)
+#define USE_PLLM_UDBIT(29)
+
+#define EMC_SRC_PLL_M  0
+#define EMC_SRC_PLL_C  1
+#define EMC_SRC_PLL_P  2
+#define EMC_SRC_CLK_M  3
+
+static const char * const emc_parent_clk_names[] = {
+   "pll_m", "pll_c", "pll_p", "clk_m",
+};
+
+struct tegra_clk_emc {
+   struct clk_hw hw;
+   void __iomem *reg;
+   bool mc_same_freq;
+   bool want_low_jitter;
+
+   tegra20_clk_emc_round_cb *round_cb;
+   void *cb_arg;
+};
+
+static inline struct tegra_clk_emc *to_tegra_clk_emc(struct clk_hw *hw)
+{
+   return container_of(hw, struct tegra_clk_emc, hw);
+}
+
+static unsigned long emc_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+   struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+   u32 val, div;
+
+   val = readl_relaxed(emc->reg);
+   div = val & CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK;
+
+   return DIV_ROUND_UP(parent_rate * 2, div + 2);
+}
+
+static u8 emc_get_parent(struct clk_hw *hw)
+{
+   struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+
+   return readl_relaxed(emc->reg) >> CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT;
+}
+
+static int emc_set_parent(struct clk_hw *hw, u8 index)
+{
+   struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+   u32 val, div;
+
+   val = readl_relaxed(emc->reg);
+   val &= ~CLK_SOURCE_EMC_2X_CLK_SRC_MASK;
+   val |= index << CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT;
+
+   div = val & CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK;
+
+   if (index == EMC_SRC_PLL_M && div == 0 && emc->want_low_jitter)
+   val |= USE_PLLM_UD;
+   else
+   val &= ~USE_PLLM_UD;
+
+   if (emc->mc_same_freq)
+   val |= MC_EMC_SAME_FREQ;
+   else
+   val &= ~MC_EMC_SAME_FREQ;
+
+   writel_relaxed(val, emc->reg);
+
+   fence_udelay(1, emc->reg);
+
+   return 0;
+}
+
+static int emc_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+   unsigned int index;
+   u32 val, div;
+
+   div = div_frac_get(rate, parent_rate, 8, 1, 0);
+
+   val = readl_relaxed(emc->reg);
+   val &= ~CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK;
+ 

[PATCH v4 05/10] memory: tegra20-emc: Replace clk_get_sys with devm_clk_get

2019-06-16 Thread Dmitry Osipenko
There is no problem for drivers to request pll_m and pll_p clocks for
the device, hence there is no need to use clk_get_sys() and it could be
replaced with devm_clk_get() for consistency.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 43aef3614b65..527aa4b90e95 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -527,33 +527,29 @@ static int tegra_emc_probe(struct platform_device *pdev)
goto unset_cb;
}
 
-   emc->pll_m = clk_get_sys(NULL, "pll_m");
+   emc->pll_m = devm_clk_get(>dev, "pll_m");
if (IS_ERR(emc->pll_m)) {
err = PTR_ERR(emc->pll_m);
dev_err(>dev, "failed to get pll_m clock: %d\n", err);
goto unset_cb;
}
 
-   emc->backup_clk = clk_get_sys(NULL, "pll_p");
+   emc->backup_clk = devm_clk_get(>dev, "pll_p");
if (IS_ERR(emc->backup_clk)) {
err = PTR_ERR(emc->backup_clk);
dev_err(>dev, "failed to get pll_p clock: %d\n", err);
-   goto put_pll_m;
+   goto unset_cb;
}
 
err = clk_notifier_register(emc->clk, >clk_nb);
if (err) {
dev_err(>dev, "failed to register clk notifier: %d\n",
err);
-   goto put_backup;
+   goto unset_cb;
}
 
return 0;
 
-put_backup:
-   clk_put(emc->backup_clk);
-put_pll_m:
-   clk_put(emc->pll_m);
 unset_cb:
tegra20_clk_set_emc_round_callback(NULL, NULL);
 
-- 
2.22.0



  1   2   3   >