Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

[Pavel Tikhomirov]

Great news, that it works for you!

Thanks a lot!
Pavel

On 11/22/2017 03:49 AM, Stuart Hayes wrote:

My apologies... yes, your patch also fixes my issue.  I was looking at the two 
new places from which you were calling scsi_eh_wakeup(), and didn't notice that 
you moved the spinlock in scsi_device_unbusy()... moving the spinlock in 
scsi_device_unbusy() also should the issue I'm seeing, given that 
scsi_eh_scmd_add() also uses the spinlock.

I tested your patch on my issue, and it did indeed fix my issue.

So you can add...

Tested-by: Stuart Hayes 

Thanks
Stuart


On 11/21/2017 2:09 AM, Pavel Tikhomirov wrote:

My patch should also fix your issue too, please see explanation in reply to 
your patch. Do your testing show that it doesn't?

Thanks, Pavel.

On 11/21/2017 09:10 AM, Stuart Hayes wrote:

Pavel,

It turns out that the error handler on our systems was not getting woken up for 
a different reason... I submitted a patch earlier today that fixes the issue I 
were seeing (I CCed you on the patch).

Before I got my hands on the failing system and was able to root cause it, I 
was pretty sure that your patch was going to fix our issue, because after I 
examined the code paths, I couldn't find any other reason that the error 
handler would not get woken up.  I tried forcing the bug that your patch fixes 
to occur, by compiling in some mdelay()s in a key place or two in the scsi 
code, but it never failed for me that way.  With my patch, several systems that 
previously failed in 10 minutes or less successfully ran for many days.

Thanks,
Stuart

On 11/9/2017 8:54 AM, Pavel Tikhomirov wrote:

Are there any issues with this patch 
(https://patchwork.kernel.org/patch/9938919/) that Pavel Tikhomirov submitted 
back in September?  I am willing to help if there's anything I can do to help 
get it accepted.


Hi, Stuart, I asked James Bottomley about the patch status offlist and it seems 
that the problem is - patch lacks testing and review. I would highly appreciate 
review from your side and anyone who wants to participate!

And if you can confirm that the patch solves the problem on your environment with no side 
effects please add "Tested-by:" tag also.

Thanks, Pavel

On 09/05/2017 03:54 PM, Pavel Tikhomirov wrote:

We have a problem on several our nodes with scsi EH. Imagine such an
order of execution of two threads:

CPU1 scsi_eh_scmd_add    CPU2 scsi_host_queue_ready
/* shost->host_busy == 1 initialy */

  if (shost->shost_state == SHOST_RECOVERY)
  /* does not get here */
  return 0;

lock(shost->host_lock);
shost->shost_state = SHOST_RECOVERY;

  busy = shost->host_busy++;
  /* host->can_queue == 1 initialy, busy == 1
   * - go to starved label */
  lock(shost->host_lock) /* wait */

shost->host_failed++;
/* shost->host_busy == 2, shost->host_failed == 1 */
call scsi_eh_wakeup(shost) {
  if (host_busy == host_failed) {
  /* does not get here */
  wake_up_process(shost->ehandler)
  }
}
unlock(shost->host_lock)

  /* acquire lock */
  shost->host_busy--;

Finaly we do not wakeup scsi_error_handler and all other commands
coming will hang as we are in never ending recovery state as there
is no one left to wakeup handler.

So scsi disc in these host becomes unresponsive and all bio on node
hangs. (We trigger these problem when scsi cmnds to DVD drive timeout.)

Main idea of the fix is to try to do wake up every time we decrement
host_busy or increment host_failed(the latter is already OK).

Now the very *last* one of busy threads getting host_lock after
decrementing host_busy will see all write operations on host's
shost_state, host_busy and host_failed completed thanks to implied
memory barriers on spin_lock/unlock, so at the time of busy==failed
we will trigger wakeup in at least one thread. (Thats why putting
recovery and failed checks under lock)

Signed-off-by: Pavel Tikhomirov 
---
    drivers/scsi/scsi_lib.c | 21 +
    1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f6097b89d5d3..6c99221d60aa 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -320,12 +320,11 @@ void scsi_device_unbusy(struct scsi_device *sdev)
    if (starget->can_queue > 0)
    atomic_dec(>target_busy);
    +    spin_lock_irqsave(shost->host_lock, flags);
    if (unlikely(scsi_host_in_recovery(shost) &&
- (shost->host_failed || shost->host_eh_scheduled))) {
-    spin_lock_irqsave(shost->host_lock, flags);
+ (shost->host_failed || shost->host_eh_scheduled)))
    scsi_eh_wakeup(shost);
-    spin_unlock_irqrestore(shost->host_lock, flags);
-    }
+    spin_unlock_irqrestore(shost->host_lock, flags);
      atomic_dec(>device_busy);
    

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

[Christophe LEROY]

Le 22/11/2017 à 00:07, Balbir Singh a écrit :

On Wed, Nov 22, 2017 at 1:28 AM, Christophe Leroy
 wrote:

On powerpc32, patch_instruction() is called by apply_feature_fixups()
which is called from early_init()

There is the following note in front of early_init():
  * Note that the kernel may be running at an address which is different
  * from the address that it was linked at, so we must use RELOC/PTRRELOC
  * to access static data (including strings).  -- paulus

Therefore, slab_is_available() cannot be called yet, and
text_poke_area must be addressed with PTRRELOC()

Fixes: 37bc3e5fd764f ("powerpc/lib/code-patching: Use alternate map
for patch_instruction()")
Reported-by: Meelis Roos 
Cc: Balbir Singh 
Signed-off-by: Christophe Leroy 
---
  v2: Added missing asm/setup.h

  arch/powerpc/lib/code-patching.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index c9de03e0c1f1..d469224c4ada 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 

  static int __patch_instruction(unsigned int *addr, unsigned int instr)
  {
@@ -146,11 +147,8 @@ int patch_instruction(unsigned int *addr, unsigned int 
instr)
  * During early early boot patch_instruction is called
  * when text_poke_area is not ready, but we still need
  * to allow patching. We just do the plain old patching
-* We use slab_is_available and per cpu read * via this_cpu_read
-* of text_poke_area. Per-CPU areas might not be up early
-* this can create problems with just using this_cpu_read()
  */
-   if (!slab_is_available() || !this_cpu_read(text_poke_area))
+   if (!this_cpu_read(*PTRRELOC(_poke_area)))
 return __patch_instruction(addr, instr);


On ppc64, we call apply_feature_fixups() in early_setup() after we've
relocated ourselves. Sorry for missing the ppc32 case. I would like to
avoid PTRRELOC when unnecessary.


What do you suggest then ?

Some #ifdef PPC32 around that ?

Christophe




Balbir Singh.

RE: [PATCH] nvmem: uniphier: change access unit from 32bit to 8bit

[Keiji Hayashibara]

Reviewed-by: Keiji Hayashibara 

Thanks.

-
Best Regards,
Keiji Hayashibara

> -Original Message-
> From: Kunihiko Hayashi [mailto:hayashi.kunih...@socionext.com]
> Sent: Wednesday, November 22, 2017 2:15 PM
> To: Srinivas Kandagatla 
> Cc: Yamada, Masahiro/山田 真弘 ; Hayashibara, 
> Keiji/林原 啓二
> ; masami.hirama...@linaro.org; 
> jaswinder.si...@linaro.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Hayashi, 
> Kunihiko/林 邦彦
> 
> Subject: [PATCH] nvmem: uniphier: change access unit from 32bit to 8bit
> 
> The efuse on UniPhier allows 8bit access according to the specification.
> Since bit offset of nvmem is limited to 0-7, it is desiable to change access 
> unit of nvmem to 8bit.
> 
> Signed-off-by: Kunihiko Hayashi 
> ---
>  drivers/nvmem/uniphier-efuse.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c 
> index 2bb45c4..fac3122 100644
> --- a/drivers/nvmem/uniphier-efuse.c
> +++ b/drivers/nvmem/uniphier-efuse.c
> @@ -27,11 +27,11 @@ static int uniphier_reg_read(void *context,
>unsigned int reg, void *_val, size_t bytes)  {
>   struct uniphier_efuse_priv *priv = context;
> - u32 *val = _val;
> + u8 *val = _val;
>   int offs;
> 
> - for (offs = 0; offs < bytes; offs += sizeof(u32))
> - *val++ = readl(priv->base + reg + offs);
> + for (offs = 0; offs < bytes; offs += sizeof(u8))
> + *val++ = readb(priv->base + reg + offs);
> 
>   return 0;
>  }
> @@ -53,8 +53,8 @@ static int uniphier_efuse_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(priv->base))
>   return PTR_ERR(priv->base);
> 
> - econfig.stride = 4;
> - econfig.word_size = 4;
> + econfig.stride = 1;
> + econfig.word_size = 1;
>   econfig.read_only = true;
>   econfig.reg_read = uniphier_reg_read;
>   econfig.size = resource_size(res);
> --
> 2.7.4

RE: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance

[Alexander.Steffen]

> > > On 10/20/2017 08:12 PM, alexander.stef...@infineon.com wrote:
> > > >> The TPM burstcount status indicates the number of bytes that can
> > > >> be sent to the TPM without causing bus wait states.  Effectively,
> > > >> it is the number of empty bytes in the command FIFO.
> > > >>
> > > >> This patch optimizes the tpm_tis_send_data() function by checking
> > > >> the burstcount only once. And if the burstcount is valid, it writes
> > > >> all the bytes at once, permitting wait state.
> > > >>
> > > >> After this change, performance on a TPM 1.2 with an 8 byte
> > > >> burstcount for 1000 extends improved from ~41sec to ~14sec.
> > > >>
> > > >> Suggested-by: Ken Goldman  in
> > > >> conjunction with the TPM Device Driver work group.
> > > >> Signed-off-by: Nayna Jain
> > > >> Acked-by: Mimi Zohar
> > > >> ---
> > > >>   drivers/char/tpm/tpm_tis_core.c | 42 +++--
> --
> > --
> > > 
> > > >> 
> > > >>   1 file changed, 15 insertions(+), 27 deletions(-)
> > > >>
> > > >> diff --git a/drivers/char/tpm/tpm_tis_core.c
> > > >> b/drivers/char/tpm/tpm_tis_core.c
> > > >> index b33126a35694..993328ae988c 100644
> > > >> --- a/drivers/char/tpm/tpm_tis_core.c
> > > >> +++ b/drivers/char/tpm/tpm_tis_core.c
> > > >> @@ -316,7 +316,6 @@ static int tpm_tis_send_data(struct tpm_chip
> > > *chip,
> > > >> u8 *buf, size_t len)
> > > >>   {
> > > >>struct tpm_tis_data *priv = dev_get_drvdata(>dev);
> > > >>int rc, status, burstcnt;
> > > >> -  size_t count = 0;
> > > >>bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND;
> > > >>
> > > >>status = tpm_tis_status(chip);
> > > >> @@ -330,35 +329,24 @@ static int tpm_tis_send_data(struct
> tpm_chip
> > > *chip,
> > > >> u8 *buf, size_t len)
> > > >>}
> > > >>}
> > > >>
> > > >> -  while (count < len - 1) {
> > > >> -  burstcnt = get_burstcount(chip);
> > > >> -  if (burstcnt < 0) {
> > > >> -  dev_err(>dev, "Unable to read
> burstcount\n");
> > > >> -  rc = burstcnt;
> > > >> -  goto out_err;
> > > >> -  }
> > > >> -  burstcnt = min_t(int, burstcnt, len - count - 1);
> > > >> -  rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv-
> > > >>> locality),
> > > >> -   burstcnt, buf + count);
> > > >> -  if (rc < 0)
> > > >> -  goto out_err;
> > > >> -
> > > >> -  count += burstcnt;
> > > >> -
> > > >> -  if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip-
> > > >>> timeout_c,
> > > >> -  >int_queue, false) < 0) {
> > > >> -  rc = -ETIME;
> > > >> -  goto out_err;
> > > >> -  }
> > > >> -  status = tpm_tis_status(chip);
> > > >> -  if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0)
> {
> > > >> -  rc = -EIO;
> > > >> -  goto out_err;
> > > >> -  }
> > > >> +  /*
> > > >> +   * Get the initial burstcount to ensure TPM is ready to
> > > >> +   * accept data.
> > > >> +   */
> > > >> +  burstcnt = get_burstcount(chip);
> > > >> +  if (burstcnt < 0) {
> > > >> +  dev_err(>dev, "Unable to read burstcount\n");
> > > >> +  rc = burstcnt;
> > > >> +  goto out_err;
> > > >>}
> > > >>
> > > >> +  rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv-
> >locality),
> > > >> +  len - 1, buf);
> > > >> +  if (rc < 0)
> > > >> +  goto out_err;
> > > >> +
> > > >>/* write last byte */
> > > >> -  rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality),
> > > >> buf[count]);
> > > >> +  rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality),
> buf[len-
> > > >> 1]);
> > > >>if (rc < 0)
> > > >>goto out_err;
> > > >>
> > > >> --
> > > >> 2.13.3
> > > > This seems to fail reliably with my SPI TPM 2.0. I get EIO when trying 
> > > > to
> > > send large amounts of data, e.g. with TPM2_Hash, and subsequent tests
> > > seem to take an unusual amount of time. More analysis probably has to
> > wait
> > > until November, since I am going to be in Prague next week.
> > >
> > > Thanks Alex for testing these.. Did you get the chance to do any further
> > > analysis ?
> >
> > I am working on that now. Ken's suggestion seems reasonable, so I am
> going
> > to test whether correctly waiting for the flags to change fixes the problem.
> If
> > it does, I'll send the patches.
> 
> Sorry for the delay, I had to take care of some device tree changes in v4.14
> that broke my ARM test machines.
> 
> I've implemented some patches that fix the issue that Ken pointed out and
> rebased your patch 2/4 ("ignore burstcount") on top. While doing 

Re: [PATCH 24/30] staging: rts5208: deprecate pci_get_bus_and_slot()

[Greg Kroah-Hartman]

On Wed, Nov 22, 2017 at 12:31:09AM -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
> 
> Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
> extract the domain number. Other places, use the actual domain number from
> the device.
> 
> Signed-off-by: Sinan Kaya 
> ---
>  drivers/staging/rts5208/rtsx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
> index 89e2cfe..13b14fe 100644
> --- a/drivers/staging/rts5208/rtsx.c
> +++ b/drivers/staging/rts5208/rtsx.c
> @@ -281,7 +281,7 @@ int rtsx_read_pci_cfg_byte(u8 bus, u8 dev, u8 func, u8 
> offset, u8 *val)
>   u8 data;
>   u8 devfn = (dev << 3) | func;
>  
> - pdev = pci_get_bus_and_slot(bus, devfn);
> + pdev = pci_get_domain_bus_and_slot(0, bus, devfn);

Ugh, this whole function should go away, but it's good enough for now,
I'll queue it up after -rc1 is out.

thanks,

greg k-h

Re: [PATCH v6 25/37] tracing: Add support for 'field variables'

[Namhyung Kim]

On Fri, Nov 17, 2017 at 02:33:04PM -0600, Tom Zanussi wrote:
> @@ -1387,6 +1405,8 @@ static struct trace_event_file *find_var_file(struct 
> trace_array *tr,
>   list_for_each_entry(var_data, >hist_vars, list) {
>   var_hist_data = var_data->hist_data;
>   file = var_hist_data->event_file;
> + if (file == found)
> + continue;

Shouldn't it be moved to the patch 22?

Thanks,
Namhyung


>   call = file->event_call;
>   name = trace_event_name(call);
>  

Re: [PATCH v2 06/18] x86/kasan/64: Teach KASAN about the cpu_entry_area

[Ingo Molnar]

* Andy Lutomirski  wrote:

> The cpu_entry_area will contain stacks.  Make sure that KASAN has
> appropriate shadow mappings for them.
> 
> Cc: Andrey Ryabinin 
> Cc: Alexander Potapenko 
> Cc: Dmitry Vyukov 
> Cc: kasan-...@googlegroups.com
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/mm/kasan_init_64.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
> index 99dfed6dfef8..43d376687315 100644
> --- a/arch/x86/mm/kasan_init_64.c
> +++ b/arch/x86/mm/kasan_init_64.c
> @@ -330,7 +330,14 @@ void __init kasan_init(void)
> early_pfn_to_nid(__pa(_stext)));
>  
>   kasan_populate_zero_shadow(kasan_mem_to_shadow((void *)MODULES_END),
> - (void *)KASAN_SHADOW_END);
> +kasan_mem_to_shadow((void 
> *)(__fix_to_virt(FIX_CPU_ENTRY_AREA_BOTTOM;
> +
> + kasan_populate_shadow((unsigned long)kasan_mem_to_shadow((void 
> *)(__fix_to_virt(FIX_CPU_ENTRY_AREA_BOTTOM))),
> +   (unsigned long)kasan_mem_to_shadow((void 
> *)(__fix_to_virt(FIX_CPU_ENTRY_AREA_TOP) + PAGE_SIZE)),
> + 0);
> +
> + kasan_populate_zero_shadow(kasan_mem_to_shadow((void 
> *)(__fix_to_virt(FIX_CPU_ENTRY_AREA_TOP) + PAGE_SIZE)),
> +(void *)KASAN_SHADOW_END);

Note, this commit has a dependency on:

  d17a1d97dc20: x86/mm/kasan: don't use vmemmap_populate() to initialize shadow

which got merged upstream outside the x86 tree, so it has a whole bunch of 
merge 
window dependencies.

To make testing+backporting to v4.14 easier I've cherry-picked d17a1d97dc20 
into 
x86/urgent.

( I've Cc:-ed Linus, just in case this kind of preemptive cherry-picking is 
  frowned upon. )

Thanks,

Ingo

Re: [PATCH v2 00/18] Entry stack switching

[Ingo Molnar]

* Ingo Molnar  wrote:

> 
> * Andy Lutomirski  wrote:
> 
> > This sets up stack switching, including for SYSCALL.  I think it's
> > in decent shape.
> > 
> > Known issues:
> >  - I think we're going to want a way to turn the stack switching on and
> >off either at boot time or at runtime.  It should be fairly 
> > straightforward
> >to make it work.
> > 
> >  - I think the ORC unwinder isn't so good at dealing with stack overflows.
> >It bails too early (I think), resulting in lots of ? entries.  This
> >isn't a regression with this series -- it's just something that could
> >be improved.
> > 
> > Ingo, patch 1 may be tip/urgent material.  It fixes what I think is
> > a bug in Xen.  I'm having a hard time testing because it's being
> > masked by a bigger unrelated bug that's keeping Xen from booting
> > when configured to hit the bug I'm fixing.  (The latter bug goes at
> > least back to v4.13, I think I know roughtly what's wrong, and I've
> > reported it to the maintainers.)
> 
> Hm, with this series the previous IRQ vector bug appears again:
> 
> [   51.156370] do_IRQ: 16.34 No irq handler for vector
> [   57.511030] do_IRQ: 16.34 No irq handler for vector
> [   57.528335] do_IRQ: 16.34 No irq handler for vector
> [   57.533256] do_IRQ: 16.34 No irq handler for vector
> [   63.991913] do_IRQ: 16.34 No irq handler for vector
> [   63.996810] do_IRQ: 16.34 No irq handler for vector
> 
> I've attached the reproducer config. Note that the system appears to be 
> working to 
> a certain extent (I could ssh to it and extract its config), but produces 
> these 
> warnings sporadically.
> 
> Also note that this is the same AMD system tha had irq-tracing/lockdep 
> troubles 
> yesterday. So maybe this warning is related and we either have broken 
> lockdep, or 
> these IRQ vector warnings.

Yeah, so I just double checked, if from the latest series I revert:

  x86/entry/64: Fix entry_SYSCALL_64_after_hwframe() IRQ tracing

then I (no surprise) get the bootup lockdep warning - but don't get the IRQ 
vector 
warnings.

Thanks,

Ingo

[rcu:rcu/dev 62/62] kernel/rcu/rcuperf.c:649:7: error: too many arguments to function 'torture_init_begin'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
rcu/dev
head:   b151f93a71fc9fecb560e823a92402d882516483
commit: b151f93a71fc9fecb560e823a92402d882516483 [62/62] torture: Eliminate 
torture_runnable
config: i386-randconfig-x001-201747 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout b151f93a71fc9fecb560e823a92402d882516483
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/rcu/rcuperf.c: In function 'rcu_perf_init':
>> kernel/rcu/rcuperf.c:649:7: error: too many arguments to function 
>> 'torture_init_begin'
 if (!torture_init_begin(perf_type, verbose, _runnable))
  ^~
   In file included from kernel/rcu/rcuperf.c:48:0:
   include/linux/torture.h:82:6: note: declared here
bool torture_init_begin(char *ttype, bool v);
 ^~

vim +/torture_init_begin +649 kernel/rcu/rcuperf.c

8704baab9 Paul E. McKenney 2015-12-31  638  
8704baab9 Paul E. McKenney 2015-12-31  639  static int __init
8704baab9 Paul E. McKenney 2015-12-31  640  rcu_perf_init(void)
8704baab9 Paul E. McKenney 2015-12-31  641  {
8704baab9 Paul E. McKenney 2015-12-31  642  long i;
8704baab9 Paul E. McKenney 2015-12-31  643  int firsterr = 0;
8704baab9 Paul E. McKenney 2015-12-31  644  static struct rcu_perf_ops 
*perf_ops[] = {
f60cb4d4c Paul E. McKenney 2017-04-19  645  _ops, _bh_ops, 
_ops, _ops, _ops,
f1dbc54b9 Paul E. McKenney 2017-05-25  646  _ops,
8704baab9 Paul E. McKenney 2015-12-31  647  };
8704baab9 Paul E. McKenney 2015-12-31  648  
8704baab9 Paul E. McKenney 2015-12-31 @649  if 
(!torture_init_begin(perf_type, verbose, _runnable))
8704baab9 Paul E. McKenney 2015-12-31  650  return -EBUSY;
8704baab9 Paul E. McKenney 2015-12-31  651  
8704baab9 Paul E. McKenney 2015-12-31  652  /* Process args and tell the 
world that the perf'er is on the job. */
8704baab9 Paul E. McKenney 2015-12-31  653  for (i = 0; i < 
ARRAY_SIZE(perf_ops); i++) {
8704baab9 Paul E. McKenney 2015-12-31  654  cur_ops = perf_ops[i];
8704baab9 Paul E. McKenney 2015-12-31  655  if (strcmp(perf_type, 
cur_ops->name) == 0)
8704baab9 Paul E. McKenney 2015-12-31  656  break;
8704baab9 Paul E. McKenney 2015-12-31  657  }
8704baab9 Paul E. McKenney 2015-12-31  658  if (i == ARRAY_SIZE(perf_ops)) {
8704baab9 Paul E. McKenney 2015-12-31  659  pr_alert("rcu-perf: 
invalid perf type: \"%s\"\n",
8704baab9 Paul E. McKenney 2015-12-31  660   perf_type);
8704baab9 Paul E. McKenney 2015-12-31  661  pr_alert("rcu-perf 
types:");
8704baab9 Paul E. McKenney 2015-12-31  662  for (i = 0; i < 
ARRAY_SIZE(perf_ops); i++)
8704baab9 Paul E. McKenney 2015-12-31  663  pr_alert(" %s", 
perf_ops[i]->name);
8704baab9 Paul E. McKenney 2015-12-31  664  pr_alert("\n");
8704baab9 Paul E. McKenney 2015-12-31  665  firsterr = -EINVAL;
8704baab9 Paul E. McKenney 2015-12-31  666  goto unwind;
8704baab9 Paul E. McKenney 2015-12-31  667  }
8704baab9 Paul E. McKenney 2015-12-31  668  if (cur_ops->init)
8704baab9 Paul E. McKenney 2015-12-31  669  cur_ops->init();
8704baab9 Paul E. McKenney 2015-12-31  670  
8704baab9 Paul E. McKenney 2015-12-31  671  nrealwriters = 
compute_real(nwriters);
8704baab9 Paul E. McKenney 2015-12-31  672  nrealreaders = 
compute_real(nreaders);
8704baab9 Paul E. McKenney 2015-12-31  673  
atomic_set(_rcu_perf_reader_started, 0);
8704baab9 Paul E. McKenney 2015-12-31  674  
atomic_set(_rcu_perf_writer_started, 0);
8704baab9 Paul E. McKenney 2015-12-31  675  
atomic_set(_rcu_perf_writer_finished, 0);
8704baab9 Paul E. McKenney 2015-12-31  676  
rcu_perf_print_module_parms(cur_ops, "Start of test");
8704baab9 Paul E. McKenney 2015-12-31  677  
8704baab9 Paul E. McKenney 2015-12-31  678  /* Start up the kthreads. */
8704baab9 Paul E. McKenney 2015-12-31  679  
8704baab9 Paul E. McKenney 2015-12-31  680  if (shutdown) {
8704baab9 Paul E. McKenney 2015-12-31  681  
init_waitqueue_head(_wq);
8704baab9 Paul E. McKenney 2015-12-31  682  firsterr = 
torture_create_kthread(rcu_perf_shutdown, NULL,
8704baab9 Paul E. McKenney 2015-12-31  683  
  shutdown_task);
8704baab9 Paul E. McKenney 2015-12-31  684  if (firsterr)
8704baab9 Paul E. McKenney 2015-12-31  685  goto unwind;
8704baab9 Paul E. McKenney 2015-12-31  686  
schedule_timeout_uninterruptible(1);
8704baab9 Paul E. McKenney 2015-12-31  687  }
8704baab9 Paul E. McKenney 2015-12-31  688  reader_tasks = 
kcalloc(nrealreaders, sizeof(reader_tasks[0]),
8704baab9 Paul E. McKenney 2015-12-31  689 
GFP_KERNEL);

[rcu:rcu/dev 62/62] kernel/rcu/rcuperf.c:649:2: note: in expansion of macro 'if'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
rcu/dev
head:   b151f93a71fc9fecb560e823a92402d882516483
commit: b151f93a71fc9fecb560e823a92402d882516483 [62/62] torture: Eliminate 
torture_runnable
config: i386-randconfig-x008-201747 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout b151f93a71fc9fecb560e823a92402d882516483
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from kernel/rcu/rcuperf.c:22:
   kernel/rcu/rcuperf.c: In function 'rcu_perf_init':
   kernel/rcu/rcuperf.c:649:7: error: too many arguments to function 
'torture_init_begin'
 if (!torture_init_begin(perf_type, verbose, _runnable))
  ^
   include/linux/compiler.h:156:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/rcu/rcuperf.c:649:2: note: in expansion of macro 'if'
 if (!torture_init_begin(perf_type, verbose, _runnable))
 ^~
   In file included from kernel/rcu/rcuperf.c:48:0:
   include/linux/torture.h:82:6: note: declared here
bool torture_init_begin(char *ttype, bool v);
 ^~
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from kernel/rcu/rcuperf.c:22:
   kernel/rcu/rcuperf.c:649:7: error: too many arguments to function 
'torture_init_begin'
 if (!torture_init_begin(perf_type, verbose, _runnable))
  ^
   include/linux/compiler.h:156:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/rcu/rcuperf.c:649:2: note: in expansion of macro 'if'
 if (!torture_init_begin(perf_type, verbose, _runnable))
 ^~
   In file included from kernel/rcu/rcuperf.c:48:0:
   include/linux/torture.h:82:6: note: declared here
bool torture_init_begin(char *ttype, bool v);
 ^~
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from kernel/rcu/rcuperf.c:22:
   kernel/rcu/rcuperf.c:649:7: error: too many arguments to function 
'torture_init_begin'
 if (!torture_init_begin(perf_type, verbose, _runnable))
  ^
   include/linux/compiler.h:167:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> kernel/rcu/rcuperf.c:649:2: note: in expansion of macro 'if'
 if (!torture_init_begin(perf_type, verbose, _runnable))
 ^~
   In file included from kernel/rcu/rcuperf.c:48:0:
   include/linux/torture.h:82:6: note: declared here
bool torture_init_begin(char *ttype, bool v);
 ^~
   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from kernel/rcu/rcuperf.c:22:
   kernel/rcu/rcuperf.c: At top level:
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strcpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:421:2: note: in expansion of macro 'if'
 if (p_size == (size_t)-1 && q_size == (size_t)-1)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'kmemdup' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:411:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'kmemdup' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro 

WARNING: can't dereference registers at ffffc90004dfff60 for ip error_entry+0x7d/0xd0 (Re: [PATCH v2 00/18] Entry stack switching)

[Ingo Molnar]

* Andy Lutomirski  wrote:

> This sets up stack switching, including for SYSCALL.  I think it's
> in decent shape.
> 
> Known issues:
>  - I think we're going to want a way to turn the stack switching on and
>off either at boot time or at runtime.  It should be fairly straightforward
>to make it work.
> 
>  - I think the ORC unwinder isn't so good at dealing with stack overflows.
>It bails too early (I think), resulting in lots of ? entries.  This
>isn't a regression with this series -- it's just something that could
>be improved.

Note that with the attached config on an Intel testbox I get the following new 
ORC 
unwinder warning during bootup:

[   12.200554] calling  ghash_pclmulqdqni_mod_init+0x0/0x54 @ 1
[   12.209536] WARNING: can't dereference registers at c90004dfff60 for ip 
error_entry+0x7d/0xd0
[   12.231388] initcall ghash_pclmulqdqni_mod_init+0x0/0x54 returned 0 after 
23480 usecs

Thanks,

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

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

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

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

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
# CONFIG_TICK_CPU_ACCOUNTING is not set
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_CPU_ISOLATION is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_CONTEXT_TRACKING=y
CONFIG_CONTEXT_TRACKING_FORCE=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=m
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=18
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y

Re: [PATCH v1] scripts: leaking_addresses.pl: add support for 32-bit kernel addresses

[Kaiwan N Billimoria]

Thanks Tobin, for your detailed comments.

On Wed, Nov 22, 2017 at 5:29 AM, Tobin C. Harding  wrote:
> You don't typically need [xxx v1] for version 1, the v1 is implicit.
>
> Please use the git brief description prefix that is already in use i.e
>
> leaking_addresses: add support for 32-bit kernel addresses

Ok..

> On Tue, Nov 21, 2017 at 01:28:14PM +0530, kaiwan.billimo...@gmail.com wrote:
>> - support for ARM-32
>
> Sure, we can do this later.

Righto

>
>> - programatically query and set the PAGE_OFFSET based on arch (it's currently
>> hard-coded)
>
> Let's do this straight away, it will be much nicer.

Yes, will work on it..

>> 2. Minor edit:
>> the '--raw', '--suppress-dmesg', '--squash-by-path' and
>> '--squash-by-filename' option switches are only meaningful
>> when the 'input-raw=' option is used. So, indent the 'Help' screen lines
>> to reflect the fact.
>
> This is a different change to the architecture stuff so should be in a
> separate patch. You could do both as a series if you like. Off the top
> of my head I have never seen options output like this, but if you have,
> I'm willing to accept your view. You are correct that the options
> mentioned are only use in conjuncture with '--input-raw' so some way of
> showing this would be nice.

I realize this; so, yeah, will make the next one a series and put this
in the 2nd..

>>
>> +my $bit_size = 64;   # Check 64-bit kernel addresses by default
>
> This global is unnecessary. You already have is_ix86_32() so you can just
> use that.

>From your later comments, I think you see that using this global is necessary.

> Please use kernel coding style
>
> $bit_size = 32;

Ok..

> Bonus points, you uncovered a bug in the current script `if (is_x86_64)`
> was missing the parenthesis!

Yeah :-)

>
>> + if ($match =~ '\b(0x)?(f|F){8}\b') {
>> + return 1;
>> + }
>
> So, may_leak_address() and is_false_positive() are tightly coupled and
> not really that nice. Once we add 32 bit support it gets worse. Going
> forwards, we can either add your 32 bit work then refactor both
> functions or you can refactor them as you add the 32 bit stuff. I'm open
> to either.

Yes I agree. Having said that, I'll leave it on the back burner for now..

>Some things to note
>
> - The mask stuff (all 1's) should have an all 0's regex also.

Well, once we determine the address is >= PAGE_OFFSET, it's
automatically apparent that it's not 0, yes?

> - The mask stuff should probably be closer to the mask stuff for 64
>   bit. It's not immediately apparent a clean way to do this though.
> - It's not immediately apparent if an address less that PAGE_OFFSET is a
>   false positive or should be caught in leaks_address().

Hmm only thing I can think of offhand- on many ARM-32's, the kernel
module space is below
PAGE_OFFSET; we'd have to take that into consideration of course.
Anything else < PAGE_OFFSET and a kernel address? Anyone?

> - Do we need 32 bit equivalents for
>
> if ($line =~ '\bKEY=[[:xdigit:]]{14} [[:xdigit:]]{16} 
> [[:xdigit:]]{16}\b' or
> $line =~ '\b[[:xdigit:]]{14} [[:xdigit:]]{16} 
> [[:xdigit:]]{16}\b') {
>
Ok am unclear on what exactly the above achieves.. could you pl throw
some light on it, thanks..

>
> Your patch did not apply, the problem looks to be in the code section
> above. You can see that there is no removed line. For next spin please
> check your patch applies on top of the 'leaks' branch (which now
> includes the fix for the bug you found).

Yes, sorry about that; will do..

> I have one more comment that should have been at the top but I did not
> want to confuse things. Typically, the git brief description should be
> limited to 50 characters. If you do decide to split this patch into two
> and use the prefix suggested you may like to change the git brief
> description but don't feel you have to. If you do decide to do this, your
> next patch set will be a version 1 again. I may be wrong but I never
> increment a patch version if the subject line changes (excluding
> contents of [] ).

Right. I plan to send the next one as a 2 patch series; will keep the
git prefix you suggest
(and as Sub changes, will not label the version).
>
> thanks,
> Tobin.

Thanks,
Kaiwan.

Re: [PATCH] nvmem: uniphier: change access unit from 32bit to 8bit

[Masahiro Yamada]

2017-11-22 14:14 GMT+09:00 Kunihiko Hayashi :
> The efuse on UniPhier allows 8bit access according to the specification.
> Since bit offset of nvmem is limited to 0-7, it is desiable to change
> access unit of nvmem to 8bit.
>
> Signed-off-by: Kunihiko Hayashi 


Tested on LD4, sLD8, Pro4, PXs2, LD11, LD20, and PXs3.
All worked for me.

Tested-by: Masahiro Yamada 

Thanks.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 2/5] media: dt-bindings: Add bindings for TDA1997X

[Sakari Ailus]

Hi Tim,

On Thu, Nov 09, 2017 at 10:45:33AM -0800, Tim Harvey wrote:
> Cc: Rob Herring 
> Signed-off-by: Tim Harvey 
> ---
> v3:
>  - fix typo
> 
> v2:
>  - add vendor prefix and remove _ from vidout-portcfg
>  - remove _ from labels
>  - remove max-pixel-rate property
>  - describe and provide example for single output port
>  - update to new audio port bindings
> ---
>  .../devicetree/bindings/media/i2c/tda1997x.txt | 179 
> +
>  1 file changed, 179 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt 
> b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> new file mode 100644
> index 000..dd37f14
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> @@ -0,0 +1,179 @@
> +Device-Tree bindings for the NXP TDA1997x HDMI receiver
> +
> +The TDA19971/73 are HDMI video receivers.
> +
> +The TDA19971 Video port output pins can be used as follows:
> + - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
> + - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
> + - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
> + - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
> + - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] 
> CbCr[11:0]
> + - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
> + - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The TDA19973 Video port output pins can be used as follows:
> + - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
> + - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
> + - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The Video port output pins are mapped via 4-bit 'pin groups' allowing
> +for a variety of connection possibilities including swapping pin order within
> +pin groups. The video_portcfg device-tree property consists of register 
> mapping
> +pairs which map a chip-specific VP output register to a 4-bit pin group. If
> +the pin group needs to be bit-swapped you can use the *_S pin-group defines.
> +
> +Required Properties:
> + - compatible  :
> +  - "nxp,tda19971" for the TDA19971
> +  - "nxp,tda19973" for the TDA19973
> + - reg : I2C slave address
> + - interrupts  : The interrupt number
> + - DOVDD-supply: Digital I/O supply
> + - DVDD-supply : Digital Core supply
> + - AVDD-supply : Analog supply
> + - nxp,vidout-portcfg  : array of pairs mapping VP output pins to pin groups.
> +
> +Optional Properties:
> + - nxp,audout-format   : DAI bus format: "i2s" or "spdif".
> + - nxp,audout-width: width of audio output data bus (1-4).
> + - nxp,audout-layout   : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
> + - nxp,audout-mclk-fs  : Multiplication factor between stream rate and codec
> + mclk.
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.

Could you add that this port has one endpoint node as well? (Unless you
support multiple, that is.)

> +
> +Optional Endpoint Properties:
> +  The following three properties are defined in video-interfaces.txt and
> +  are valid for source endpoints only:

Transmitters? Don't you have an endpoint only in the port representing the
transmitter?

> +  - hsync-active: Horizontal synchronization polarity. Defaults to active 
> high.
> +  - vsync-active: Vertical synchronization polarity. Defaults to active high.
> +  - data-active: Data polarity. Defaults to active high.
> +
> +Examples:
> + - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
> +   16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
> + hdmi-receiver@48 {
> + compatible = "nxp,tda19971";
> + pinctrl-names = "default";
> + pinctrl-0 = <_tda1997x>;
> + reg = <0x48>;
> + interrupt-parent = <>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + DOVDD-supply = <_3p3v>;
> + AVDD-supply = <_1p8v>;
> + DVDD-supply = <_1p8v>;
> + /* audio */
> + #sound-dai-cells = <0>;
> + nxp,audout-format = "i2s";
> + nxp,audout-layout = <0>;
> + nxp,audout-width = <16>;
> + nxp,audout-mclk-fs = <128>;
> + /*
> +  * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
> +  * and Y[11:4] across 16bits in the same pixclk cycle.
> + 

Re: [PATCH v2 00/18] Entry stack switching

[Ingo Molnar]

* Andy Lutomirski  wrote:

> This sets up stack switching, including for SYSCALL.  I think it's
> in decent shape.
> 
> Known issues:
>  - I think we're going to want a way to turn the stack switching on and
>off either at boot time or at runtime.  It should be fairly straightforward
>to make it work.
> 
>  - I think the ORC unwinder isn't so good at dealing with stack overflows.
>It bails too early (I think), resulting in lots of ? entries.  This
>isn't a regression with this series -- it's just something that could
>be improved.
> 
> Ingo, patch 1 may be tip/urgent material.  It fixes what I think is
> a bug in Xen.  I'm having a hard time testing because it's being
> masked by a bigger unrelated bug that's keeping Xen from booting
> when configured to hit the bug I'm fixing.  (The latter bug goes at
> least back to v4.13, I think I know roughtly what's wrong, and I've
> reported it to the maintainers.)

Hm, with this series the previous IRQ vector bug appears again:

[   51.156370] do_IRQ: 16.34 No irq handler for vector
[   57.511030] do_IRQ: 16.34 No irq handler for vector
[   57.528335] do_IRQ: 16.34 No irq handler for vector
[   57.533256] do_IRQ: 16.34 No irq handler for vector
[   63.991913] do_IRQ: 16.34 No irq handler for vector
[   63.996810] do_IRQ: 16.34 No irq handler for vector

I've attached the reproducer config. Note that the system appears to be working 
to 
a certain extent (I could ssh to it and extract its config), but produces these 
warnings sporadically.

Also note that this is the same AMD system tha had irq-tracing/lockdep troubles 
yesterday. So maybe this warning is related and we either have broken lockdep, 
or 
these IRQ vector warnings.

Thanks,

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

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

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

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

#
# CPU/Task time and stats accounting
#

Re: [tegra186]: emmc resume failing after booting from snapshot image

[Pintu Kumar]

Hi,

I am trying to bring up suspend-to-disk (snapshot boot) on jetson-tx2
board (nvidia tegra186).
Suspend is working fine, but during boot with snapshot image, emmc
resume is failing.
Kernel version: 4.4
Repo: https://nv-tegra.nvidia.com/gitweb/?p=linux-4.4.git;a=summary
repo: tegra-l4t-r27.1


It returns with:
mmc0: error -110 during resume (card was removed?)

Please see the complete logs below.

I tried to add some prints in mmc driver to check the cause.
It seems that mmc is not responding during resume.
[  137.125314] mmc_sleep: ERROR: mmc_wait_for_cmd, ret: -110
When I check more, I found that CMD5 (Sleep/Awake) is failing to response.
It is not able to wakeup the mmc from sleep.

What could be cause of this problem?
Any pointers or suggestions about this issue will be really helpful

When I see the linux kernel mainline kernel-4.14 (latest), I could see
that there are some patches in drivers/mmc/core/* which are missing in
jetson tx2 kernel version-4.4.
Do you think any of the latest patches may help to solve this issue?
If yes, can you point to some of relevant once?


Please help.


Thanks,
Pintu

LOGS:
---
## Booting ...
[ 117.079061] sdhci-tegra 340.sdhci: Tuning already done,
restoring the best tap value : 112
[ 117.081179] xhci-tegra 353.xhci: exiting ELPG
[ 117.081798] xhci-tegra 353.xhci: Firmware timestamp: 2016-09-01
11:32:41 UTC, Version: 55.05 release
[ 117.085202] xhci-tegra 353.xhci: exiting ELPG done
[ 117.085204] xhci-tegra 353.xhci: entering ELPG
[ 117.087770] xhci-tegra 353.xhci: entering ELPG done
[ 117.087775] Wake76 for irq=199
[ 117.08] Wake77 for irq=199
[ 117.087778] Wake78 for irq=199
[ 117.087779] Wake79 for irq=199
[ 117.087780] Wake80 for irq=199
[ 117.087781] Wake81 for irq=199
[ 117.087782] Wake82 for irq=199
[ 117.087784] Enabling wake76
[ 117.087785] Enabling wake77
[ 117.087786] Enabling wake78
[ 117.087787] Enabling wake79
[ 117.087788] Enabling wake80
[ 117.087789] Enabling wake81
[ 117.087790] Enabling wake82
[ 117.087891] tegra186-cam-rtcpu b00.rtcpu: sce gets halted
[ 117.090012] Wake24 for irq=241
[ 117.090015] Enabling wake24
[ 117.090598] nct1008_nct72 7-004c: success in disabling tmp451 VDD rail
[ 117.090654] gpio tegra-gpio-aon wake29 for gpio=56(FF:0)
[ 117.090655] Enabling wake29
[ 117.090774] gpio tegra-gpio wake53 for gpio=159(X:5)
[ 117.090775] Enabling wake53
[ 117.111219] tegradc 1521.nvdisplay: suspend
[ 117.111422] Wake73 for irq=42
[ 117.111424] Enabling wake73
[ 117.111597] bcm54xx_low_power_mode(): put phy in iddq-lp mode
[ 117.113533] gpio tegra-gpio wake71 for gpio=125(P:6)
[ 117.113535] Enabling wake71
[ 117.113632] PM: suspend of devices complete after 34.680 msecs
[ 117.114829] host1x 13e1.host1x: suspended
[ 117.114898] PM: late suspend of devices complete after 1.262 msecs
[ 117.133746] PM: noirq suspend of devices complete after 18.841 msecs
[ 117.133971] Disabling non-boot CPUs ...
[ 117.134249] CPU3: shutdown
[ 117.148582] psci: Retrying again to check for CPU kill
[ 117.148586] psci: CPU3 killed.
[ 117.149097] CPU4: shutdown
[ 117.164584] psci: Retrying again to check for CPU kill
[ 117.164589] psci: CPU4 killed.
[ 117.165041] CPU5: shutdown
[ 117.180572] psci: Retrying again to check for CPU kill
[ 117.180576] psci: CPU5 killed.
[ 117.180834] Entered SC7
[ 117.180834] Wake[31-0] level=0x4000
[ 117.180834] Wake[63-32] level=0x0
[ 117.180834] Wake[95-64] level=0x7f2a0
[ 117.180834] Wake[31-0] enable=0x2100
[ 117.180834] Wake[63-32] enable=0x20
[ 117.180834] Wake[95-64] enable=0x7f280
[ 117.180834] Wake[31-0] route=0x2100
[ 117.180834] Wake[63-32] route=0x20
[ 117.180834] Wake[95-64] route=0x7f280

[ 117.180834] Wake[32:0] status=0x0
[ 117.180834] Wake[64:32] status=0x0
[ 117.180834] Wake[96:64] status=0x0
[ 117.180834] Exited SC7
[ 117.180834] bpmp: waiting for handshake
[ 117.180834] bpmp: synchronizing channels
[ 117.180834] bpmp: channels synchronized
[ 117.180869] Enabling non-boot CPUs ...
[ 117.181067] CPU3: Booted secondary processor [411fd073]
[ 117.181198] CPU3 is up
[ 117.181353] CPU4: Booted secondary processor [411fd073]
[ 117.181455] CPU4 is up
[ 117.181609] CPU5: Booted secondary processor [411fd073]
[ 117.181721] CPU5 is up
[ 117.182740] xhci-tegra 353.xhci: exiting ELPG
[ 117.183221] xhci-tegra 353.xhci: Firmware timestamp: 2016-09-01
11:32:41 UTC, Version: 55.05 release
[ 117.381630] xhci-tegra 353.xhci: XHCI Controller not ready.
Falcon state: 0x10
[ 117.381633] xhci-tegra 353.xhci: exiting ELPG failed
[ 117.381643] dpm_run_callback(): tegra_xhci_resume_noirq+0x0/0x48 returns -14
[ 117.381653] PM: Device 353.xhci failed to resume noirq: error -14
[ 117.381724] PM: noirq resume of devices complete after 199.999 msecs
[ 117.383100] PM: early resume of devices complete after 1.236 msecs
[ 117.390964] gpio tegra-gpio wake71 for gpio=125(P:6)
[ 117.390966] Disabling wake71
[ 

Re: [PATCH v1 3/9] perf util: Reconstruct rblist for supporting per-thread shadow stats

[Jin, Yao]

On 11/22/2017 2:31 PM, Ravi Bangoria wrote:


On 11/20/2017 08:13 PM, Jin Yao wrote:
@@ -76,6 +97,17 @@ static struct rb_node *saved_value_new(struct 
rblist *rblist __maybe_unused,

  return >rb_node;
  }

+static void saved_value_delete(struct rblist *rblist __maybe_unused,
+   struct rb_node *rb_node)
+{
+    struct saved_value *v = container_of(rb_node,
+ struct saved_value,
+ rb_node);
+
+    if (v)
+    free(v);
+}


Do we really need if(v) ?

Thanks,
Ravi



Hi Ravi,

Looks it doesn't need if(v).

I put if(v) here is from my coding habits (checking pointer before free).

It's OK for me if you think the code should be removed.

Thanks
Jin Yao

Re: [PATCH v2] staging: comedi: add missing MODULE_DESCRIPTION/LICENSE

[Matthew Giassa]

* Ian Abbott  [2017-11-20 10:46:36 +]:


On 20/11/17 10:29, Ian Abbott wrote:

On 20/11/17 07:50, Jesse Chan wrote:

This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in 
drivers/staging/comedi/drivers/ni_atmio.o

see include/linux/module.h for more information

This adds the license as "GPL", which matches the header of the file.

MODULE_DESCRIPTION is also added.

Signed-off-by: Jesse Chan 
---
  drivers/staging/comedi/drivers/ni_atmio.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/staging/comedi/drivers/ni_atmio.c 
b/drivers/staging/comedi/drivers/ni_atmio.c

index 2d62a8c57332..b61d56367773 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -361,3 +361,6 @@ static struct comedi_driver ni_atmio_driver = {
  .detach    = ni_atmio_detach,
  };
  module_comedi_driver(ni_atmio_driver);
+
+MODULE_DESCRIPTION("Comedi low-level driver");
+MODULE_LICENSE("GPL");


Thanks!  I wonder how I managed to miss out this driver in commit 
3c323c01b6bd ("Staging: comedi: Add MODULE_LICENSE and similar to NI 
modules")?


Reviewed-by: Ian Abbott 


Despite my above comment, we should probably give precedence to 
Matthew Giassa's patch for the same issue, since it was sent earlier.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-


--

Thanks. Also, this one should probably include the MODULE_AUTHOR macro
as well.

Cheers!

Re: WARNING: can't dereference registers at ffffc90004dfff60 for ip error_entry+0x7d/0xd0 (Re: [PATCH v2 00/18] Entry stack switching)

[Ingo Molnar]

* Ingo Molnar  wrote:

> 
> * Andy Lutomirski  wrote:
> 
> > This sets up stack switching, including for SYSCALL.  I think it's
> > in decent shape.
> > 
> > Known issues:
> >  - I think we're going to want a way to turn the stack switching on and
> >off either at boot time or at runtime.  It should be fairly 
> > straightforward
> >to make it work.
> > 
> >  - I think the ORC unwinder isn't so good at dealing with stack overflows.
> >It bails too early (I think), resulting in lots of ? entries.  This
> >isn't a regression with this series -- it's just something that could
> >be improved.
> 
> Note that with the attached config on an Intel testbox I get the following 
> new ORC 
> unwinder warning during bootup:
> 
> [   12.200554] calling  ghash_pclmulqdqni_mod_init+0x0/0x54 @ 1
> [   12.209536] WARNING: can't dereference registers at c90004dfff60 for 
> ip error_entry+0x7d/0xd0
> [   12.231388] initcall ghash_pclmulqdqni_mod_init+0x0/0x54 returned 0 after 
> 23480 usecs
> 
> Thanks,

Also note that the ORC warning goes away if CONFIG_PROVE_LOCKING is disabled.

Thanks,

Ingo

[PATCH v4 1/1] perf/bench/numa: Fixup discontiguous/sparse numa nodes

[sathnaga]

From: Satheesh Rajendran 

Certain systems are designed to have sparse/discontiguous nodes.
On such systems, perf bench numa hangs, shows wrong number of nodes
and shows values for non-existent nodes. Handle this by only
taking nodes that are exposed by kernel to userspace.

Cc: Arnaldo Carvalho de Melo 
Cc: Naveen N. Rao 
Reviewed-by: Srikar Dronamraju 
Signed-off-by: Satheesh Rajendran 
Signed-off-by: Balamuruhan S 
---
 tools/perf/bench/numa.c | 57 +++--
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index d95fdcc..ed7db12 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -216,6 +216,47 @@ static const char * const numa_usage[] = {
NULL
 };
 
+/*
+ * To get number of numa nodes present.
+ */
+static int nr_numa_nodes(void)
+{
+   int i, nr_nodes = 0;
+
+   for (i = 0; i < g->p.nr_nodes; i++) {
+   if (numa_bitmask_isbitset(numa_nodes_ptr, i))
+   nr_nodes++;
+   }
+
+   return nr_nodes;
+}
+
+/*
+ * To check if given numa node is present.
+ */
+static int is_node_present(int node)
+{
+   return numa_bitmask_isbitset(numa_nodes_ptr, node);
+}
+
+/*
+ * To check given numa node has cpus.
+ */
+static bool node_has_cpus(int node)
+{
+   struct bitmask *cpu = numa_allocate_cpumask();
+   unsigned int i;
+
+   if (cpu && !numa_node_to_cpus(node, cpu)) {
+   for (i = 0; i < cpu->size; i++) {
+   if (numa_bitmask_isbitset(cpu, i))
+   return true;
+   }
+   }
+
+   return false; /* lets fall back to nocpus safely */
+}
+
 static cpu_set_t bind_to_cpu(int target_cpu)
 {
cpu_set_t orig_mask, mask;
@@ -244,12 +285,12 @@ static cpu_set_t bind_to_cpu(int target_cpu)
 
 static cpu_set_t bind_to_node(int target_node)
 {
-   int cpus_per_node = g->p.nr_cpus/g->p.nr_nodes;
+   int cpus_per_node = g->p.nr_cpus / nr_numa_nodes();
cpu_set_t orig_mask, mask;
int cpu;
int ret;
 
-   BUG_ON(cpus_per_node*g->p.nr_nodes != g->p.nr_cpus);
+   BUG_ON(cpus_per_node * nr_numa_nodes() != g->p.nr_cpus);
BUG_ON(!cpus_per_node);
 
ret = sched_getaffinity(0, sizeof(orig_mask), _mask);
@@ -649,7 +690,7 @@ static int parse_setup_node_list(void)
int i;
 
for (i = 0; i < mul; i++) {
-   if (t >= g->p.nr_tasks) {
+   if (t >= g->p.nr_tasks || 
!node_has_cpus(bind_node)) {
printf("\n# NOTE: ignoring bind NODEs 
starting at NODE#%d\n", bind_node);
goto out;
}
@@ -964,13 +1005,14 @@ static void calc_convergence(double runtime_ns_max, 
double *convergence)
sum = 0;
 
for (node = 0; node < g->p.nr_nodes; node++) {
+   if (!is_node_present(node))
+   continue;
nr = nodes[node];
nr_min = min(nr, nr_min);
nr_max = max(nr, nr_max);
sum += nr;
}
BUG_ON(nr_min > nr_max);
-
BUG_ON(sum > g->p.nr_tasks);
 
if (0 && (sum < g->p.nr_tasks))
@@ -984,8 +1026,11 @@ static void calc_convergence(double runtime_ns_max, 
double *convergence)
process_groups = 0;
 
for (node = 0; node < g->p.nr_nodes; node++) {
-   int processes = count_node_processes(node);
+   int processes;
 
+   if (!is_node_present(node))
+   continue;
+   processes = count_node_processes(node);
nr = nodes[node];
tprintf(" %2d/%-2d", nr, processes);
 
@@ -1291,7 +1336,7 @@ static void print_summary(void)
 
printf("\n ###\n");
printf(" # %d %s will execute (on %d nodes, %d CPUs):\n",
-   g->p.nr_tasks, g->p.nr_tasks == 1 ? "task" : "tasks", 
g->p.nr_nodes, g->p.nr_cpus);
+   g->p.nr_tasks, g->p.nr_tasks == 1 ? "task" : "tasks", 
nr_numa_nodes(), g->p.nr_cpus);
printf(" #  %5dx %5ldMB global  shared mem operations\n",
g->p.nr_loops, g->p.bytes_global/1024/1024);
printf(" #  %5dx %5ldMB process shared mem operations\n",
-- 
2.7.4

Re: [PATCH 30/30] PCI: remove pci_get_bus_and_slot() function

[Timur Tabi]

On 11/21/17 11:55 PM, Sinan Kaya wrote:

For places where domain number information is available, I extracted domain 
number
and added into pci_get_domain_bus_and_slot() call such as xen or bn drivers.


My suggestion is that you restrict your first patch set to only these 
patches.



The assumption at this point is for pci_get_bus_and_slot() usages to be caught
in code-review.


How about this:

static inline struct pci_dev * __deprecated 
pci_get_bus_and_slot(unsigned int bus,

   unsigned int devfn)
{
return pci_get_domain_bus_and_slot(0, bus, devfn);
}


--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

[Christoph Hellwig]

Jens, please don't just revert the commit in your for-linus tree.

On its own this will totally mess up the interrupt assignments.  Give
me a bit of time to sort this out properly.

Re: [PATCH] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

[kbuild test robot]

Hi Jesse,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Jesse-Chan/media-mtk-vcodec-add-missing-MODULE_LICENSE-DESCRIPTION/20171122-124620
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

>> drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c:55:16: error: expected 
>> declaration specifiers or '...' before string constant
MODULE_LICENSE("GPL v2");
   ^
   drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c:56:20: error: expected 
declaration specifiers or '...' before string constant
MODULE_DESCRIPTION("Mediatek video codec driver");
   ^

vim +55 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c

54  
  > 55  MODULE_LICENSE("GPL v2");

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


.config.gz
Description: application/gzip

Re: [PATCH V14 07/24] mmc: block: Use data timeout in card_busy_detect()

[Adrian Hunter]

On 21/11/17 17:39, Ulf Hansson wrote:
> On 21 November 2017 at 14:42, Adrian Hunter  wrote:
>> card_busy_detect() has a 10 minute timeout. However the correct timeout is
>> the data timeout. Change card_busy_detect() to use the data timeout.
> 
> Unfortunate I don't think there is "correct" timeout for this case.
> 
> The data->timeout_ns is to indicate for the host to how long the
> maximum time it's allowed to take between blocks that are written to
> the data lines.
> 
> I haven't found a definition of the busy timeout, after the data write
> has completed. The spec only mentions that the device moves to
> programming state and pulls DAT0 to indicate busy.

To me it reads more like the timeout is for each block, including the last
i.e. the same timeout for "busy".  Note the card is also busy between blocks.

Equally it is the timeout we give the host controller.  So either the host
controller does not have a timeout for "busy" - which begs the question why
it has a timeout at all - or it invents its own "busy" timeout - which begs
the question why it isn't in the spec.

> 
> Sure, 10 min seems crazy, perhaps something along the lines of 10-20 s
> is more reasonable. What do you think?

We give SD cards a generous 3 seconds for writes.  SDHCI has long had a 10
second software timer for the whole request, which strongly suggests that
requests have always completed within 10 seconds.  So that puts the range of
an arbitrary timeout 3-10 s.

Re: [PATCH 3.16 105/133] mm/vmstat.c: fix wrong comment

[Vlastimil Babka]

On 11/22/2017 02:58 AM, Ben Hutchings wrote:
> 3.16.51-rc1 review patch.  If anyone has any objections, please let me know.

I don't really care much in the end, but is "fix wrong comment" really a
stable patch material these days? :)

> --
> 
> From: SeongJae Park 
> 
> commit f113e64121ba9f4791332248b315d9f57ee33a6b upstream.
> 
> Comment for pagetypeinfo_showblockcount() is mistakenly duplicated from
> pagetypeinfo_show_free()'s comment.  This commit fixes it.
> 
> Link: http://lkml.kernel.org/r/20170809185816.11244-1-sj38.p...@gmail.com
> Fixes: 467c996c1e19 ("Print out statistics in relation to fragmentation 
> avoidance to /proc/pagetypeinfo")
> Signed-off-by: SeongJae Park 
> Cc: Michal Hocko 
> Cc: Vlastimil Babka 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> Signed-off-by: Ben Hutchings 
> ---
>  mm/vmstat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -975,7 +975,7 @@ static void pagetypeinfo_showblockcount_
>   seq_putc(m, '\n');
>  }
>  
> -/* Print out the free pages at each order for each migratetype */
> +/* Print out the number of pageblocks for each migratetype */
>  static int pagetypeinfo_showblockcount(struct seq_file *m, void *arg)
>  {
>   int mtype;
> 

[PATCH v4 0/1] Fixup for discontiguous/sparse numa nodes

[sathnaga]

From: Satheesh Rajendran 

Certain systems would have sparse/discontinguous
numa nodes.
perf bench numa doesnt work well on such nodes.
1. It shows wrong values.
2. It can hang.
3. It can show redundant information for non-existant nodes.

 #numactl -H
available: 2 nodes (0,8)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 61352 MB
node 0 free: 57168 MB
node 8 cpus: 8 9 10 11 12 13 14 15
node 8 size: 65416 MB
node 8 free: 36593 MB
node distances:
node   0   8
  0:  10  40
  8:  40  10

Scenario 1:

Before Fix:
 # perf bench numa mem --no-data_rand_walk -p 2 -t 20 -G 0 -P 3072 -T 0 -l 50 
-c -s 1000
...
...
 # 40 tasks will execute (on 9 nodes, 16 CPUs): > Wrong number of nodes
...
 #2.0%  [0.2 mins]  1/1   0/0   0/0   0/0   0/0   0/0   0/0   0/0   4/1  [ 
4/2 ] l:  0-0   (  0) > Shows info on non-existant nodes.

After Fix:
 # ./perf bench numa mem --no-data_rand_walk -p 2 -t 20 -G 0 -P 3072 -T 0 -l 50 
-c -s 1000
...
...
 # 40 tasks will execute (on 2 nodes, 16 CPUs):
... 
 #2.0%  [0.2 mins]  9/1   0/0  [ 9/1 ] l:  0-0   (  0)
 #4.0%  [0.4 mins] 21/2  19/1  [ 2/3 ] l:  0-1   (  1) {1-2}

Scenario 2:

Before Fix:
 # perf bench numa all
 # Running numa/mem benchmark...

...
 # Running RAM-bw-remote, "perf bench numa mem -p 1 -t 1 -P 1024 -C 0 -M 1 -s 
20 -zZq --thp  1 --no-data_rand_walk"
perf: bench/numa.c:306: bind_to_memnode: Assertion `!(ret)' failed. 
> Got hung

After Fix:
 # ./perf bench numa all
 # Running numa/mem benchmark...

...
 # Running RAM-bw-remote, "perf bench numa mem -p 1 -t 1 -P 1024 -C 0 -M 1 -s 
20 -zZq --thp  1 --no-data_rand_walk"

 # NOTE: ignoring bind NODEs starting at NODE#1
 # NOTE: 0 tasks mem-bound, 1 tasks unbound
 20.017 secs slowest (max) thread-runtime
 20.000 secs fastest (min) thread-runtime
 20.006 secs average thread-runtime
  0.043 % difference between max/avg runtime
413.794 GB data processed, per thread
413.794 GB data processed, total
  0.048 nsecs/byte/thread runtime
 20.672 GB/sec/thread speed
 20.672 GB/sec total speed

Changes in v2:
Fixed review comments for function names and alloc failure handle

Changes in v3:
Coding Style fixes.

Changes in v4:
Address review comments from Naveen and Arnaldo.
Merge two commits into single.


Satheesh Rajendran (1):
  perf/bench/numa: Handle discontiguous/sparse numa nodes

 tools/perf/bench/numa.c | 57 +++--
 1 file changed, 51 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH] KVM: VMX: Fix vmx->nested freeing when no SMI handler

[Wanpeng Li]

From: Wanpeng Li 

Reported by syzkaller:

[ cut here ]
WARNING: CPU: 5 PID: 2939 at arch/x86/kvm/vmx.c:3844 
free_loaded_vmcs+0x77/0x80 [kvm_intel]
CPU: 5 PID: 2939 Comm: repro Not tainted 4.14.0+ #26
RIP: 0010:free_loaded_vmcs+0x77/0x80 [kvm_intel]
Call Trace:
 vmx_free_vcpu+0xda/0x130 [kvm_intel]
 kvm_arch_destroy_vm+0x192/0x290 [kvm]
 kvm_put_kvm+0x262/0x560 [kvm]
 kvm_vm_release+0x2c/0x30 [kvm]
 __fput+0x190/0x370
 task_work_run+0xa1/0xd0
 do_exit+0x4d2/0x13e0
 do_group_exit+0x89/0x140
 get_signal+0x318/0xb80
 do_signal+0x8c/0xb40
 exit_to_usermode_loop+0xe4/0x140
 syscall_return_slowpath+0x206/0x230
 entry_SYSCALL_64_fastpath+0x98/0x9a

The syzkaller testcase will execute VMXON/VMLAUCH instructions, so the 
vmx->nested stuff is populated, it will also issue KVM_SMI ioctl. However, 
the testcase is just a simple c program and not be lauched by something 
like seabios which implements smi_handler. Commit 05cade71cf (KVM: nSVM: 
fix SMI injection in guest mode) gets out of guest mode and set nested.vmxon 
to false for the duration of SMM according to SDM 34.14.1 "leave VMX 
operation" upon entering SMM. We can't alloc/free the vmx->nested stuff 
each time when entering/exiting SMM since it will induce more overhead. So 
the function vmx_pre_enter_smm() marks nested.vmxon false even if vmx->nested 
stuff is still populated. What it expected is em_rsm() can mark nested.vmxon 
to be true again. However, the smi_handler/rsm will not execute since there 
is no something like seabios in this scenario. The function free_nested() 
fails to free the vmx->nested stuff since the vmx->nested.vmxon is false 
which results in the above warning.

This patch fixes it by also considering the no SMI handler case, luckily 
vmx->nested.smm.vmxon is marked according to the value of vmx->nested.vmxon 
in vmx_pre_enter_smm(), we can take advantage of it and free vmx->nested 
stuff when L1 goes down.

Reported-by: Dmitry Vyukov 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Dmitry Vyukov 
Fixes: 05cade71cf (KVM: nSVM: fix SMI injection in guest mode)
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index dccc0f7..ed22425 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7372,7 +7372,7 @@ static inline void nested_release_vmcs12(struct vcpu_vmx 
*vmx)
  */
 static void free_nested(struct vcpu_vmx *vmx)
 {
-   if (!vmx->nested.vmxon)
+   if (!vmx->nested.vmxon && !vmx->nested.smm.vmxon)
return;
 
vmx->nested.vmxon = false;
-- 
2.7.4

Re: [PATCH v1 3/9] perf util: Reconstruct rblist for supporting per-thread shadow stats

[Ravi Bangoria]

On 11/20/2017 08:13 PM, Jin Yao wrote:

@@ -76,6 +97,17 @@ static struct rb_node *saved_value_new(struct rblist *rblist 
__maybe_unused,
return >rb_node;
  }

+static void saved_value_delete(struct rblist *rblist __maybe_unused,
+  struct rb_node *rb_node)
+{
+   struct saved_value *v = container_of(rb_node,
+struct saved_value,
+rb_node);
+
+   if (v)
+   free(v);
+}


Do we really need if(v) ?

Thanks,
Ravi

Re: [PATCH] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

[Randy Dunlap]

On 11/21/17 23:41, kbuild test robot wrote:
> Hi Jesse,
> 
> Thank you for the patch! Yet something to improve:

missing
#include 

Jesse, did you build all of these driver changes?


> [auto build test ERROR on linuxtv-media/master]
> [also build test ERROR on v4.14 next-20171121]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Jesse-Chan/media-mtk-vcodec-add-missing-MODULE_LICENSE-DESCRIPTION/20171122-124620
> base:   git://linuxtv.org/media_tree.git master
> config: xtensa-allmodconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 4.9.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=xtensa 
> 
> All errors (new ones prefixed by >>):
> 
>>> drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c:55:16: error: expected 
>>> declaration specifiers or '...' before string constant
> MODULE_LICENSE("GPL v2");
>^
>drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c:56:20: error: expected 
> declaration specifiers or '...' before string constant
> MODULE_DESCRIPTION("Mediatek video codec driver");
>^
> 
> vim +55 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
> 
> 54
>   > 55MODULE_LICENSE("GPL v2");
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 


-- 
~Randy

Re: [PATCH 30/30] PCI: remove pci_get_bus_and_slot() function

[Greg KH]

On Wed, Nov 22, 2017 at 12:08:45AM -0600, Timur Tabi wrote:
> On 11/21/17 11:55 PM, Sinan Kaya wrote:
> > For places where domain number information is available, I extracted domain 
> > number
> > and added into pci_get_domain_bus_and_slot() call such as xen or bn drivers.
> 
> My suggestion is that you restrict your first patch set to only these
> patches.
> 
> > The assumption at this point is for pci_get_bus_and_slot() usages to be 
> > caught
> > in code-review.
> 
> How about this:
> 
> static inline struct pci_dev * __deprecated pci_get_bus_and_slot(unsigned
> int bus,
>  unsigned int devfn)
> {
>   return pci_get_domain_bus_and_slot(0, bus, devfn);
> }

Ick, no, why?  What is wrong with removing this function as is?  Don't
mark something as __depreciated if there are no in-kernel users, just
delete it and move on.

If you have out-of-tree drivers, then yes, they can make a wrapper for
this function like this if they really feel the need, or they can get
their code merged :)

thanks,

greg k-h

[PATCH v3] staging: fsl-mc: use 32bits to support 64K size mc-portals

[Bharat Bhushan]

As per APIs each mc-portal is of 64K size while currently
16bits (type u16) is used to store size of mc-portal.
In these cases upper bit of portal size gets truncated.

Signed-off-by: Bharat Bhushan 
---
v2->v3:
 - v2 patch: https://patchwork.kernel.org/patch/10067661/
 - Changes patch subject and description

v1->v2:
 - v1 patch: https://patchwork.kernel.org/patch/10067657/
 - replace uin32_t to u32 in patch subject/description

 drivers/staging/fsl-mc/include/mc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fsl-mc/include/mc.h 
b/drivers/staging/fsl-mc/include/mc.h
index aafe63a..2cf15b0 100644
--- a/drivers/staging/fsl-mc/include/mc.h
+++ b/drivers/staging/fsl-mc/include/mc.h
@@ -325,7 +325,7 @@ static inline void mc_cmd_read_api_version(struct 
mc_command *cmd,
 struct fsl_mc_io {
struct device *dev;
u16 flags;
-   u16 portal_size;
+   u32 portal_size;
phys_addr_t portal_phys_addr;
void __iomem *portal_virt_addr;
struct fsl_mc_device *dpmcp_dev;
-- 
1.9.3

[tip:x86/urgent] x86/entry/64: Fix entry_SYSCALL_64_after_hwframe() IRQ tracing

[tip-bot for Andy Lutomirski]

Commit-ID:  548c3050ea8d16997ae27f9e080a8338a606fc93
Gitweb: https://git.kernel.org/tip/548c3050ea8d16997ae27f9e080a8338a606fc93
Author: Andy Lutomirski 
AuthorDate: Tue, 21 Nov 2017 20:43:56 -0800
Committer:  Ingo Molnar 
CommitDate: Wed, 22 Nov 2017 06:35:48 +0100

x86/entry/64: Fix entry_SYSCALL_64_after_hwframe() IRQ tracing

When I added entry_SYSCALL_64_after_hwframe(), I left TRACE_IRQS_OFF
before it.  This means that users of entry_SYSCALL_64_after_hwframe()
were responsible for invoking TRACE_IRQS_OFF, and the one and only
user (Xen, added in the same commit) got it wrong.

I think this would manifest as a warning if a Xen PV guest with
CONFIG_DEBUG_LOCKDEP=y were used with context tracking.  (The
context tracking bit is to cause lockdep to get invoked before we
turn IRQs back on.)  I haven't tested that for real yet because I
can't get a kernel configured like that to boot at all on Xen PV.

Move TRACE_IRQS_OFF below the label.

Signed-off-by: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: sta...@vger.kernel.org
Fixes: 8a9949bc71a7 ("x86/xen/64: Rearrange the SYSCALL entries")
Link: 
http://lkml.kernel.org/r/9150aac013b7b95d62c2336751d5b6e91d2722aa.1511325444.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/entry_64.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index a2b30ec..5063ed1 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -148,8 +148,6 @@ ENTRY(entry_SYSCALL_64)
movq%rsp, PER_CPU_VAR(rsp_scratch)
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
 
-   TRACE_IRQS_OFF
-
/* Construct struct pt_regs on stack */
pushq   $__USER_DS  /* pt_regs->ss */
pushq   PER_CPU_VAR(rsp_scratch)/* pt_regs->sp */
@@ -170,6 +168,8 @@ GLOBAL(entry_SYSCALL_64_after_hwframe)
sub $(6*8), %rsp/* pt_regs->bp, bx, r12-15 not 
saved */
UNWIND_HINT_REGS extra=0
 
+   TRACE_IRQS_OFF
+
/*
 * If we need to do entry work or if we guess we'll need to do
 * exit work, go straight to the slow path.

Re: [PATCH 29/30] i7300_idle: deprecate pci_get_bus_and_slot()

[Greg Kroah-Hartman]

On Wed, Nov 22, 2017 at 12:31:14AM -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
> 
> Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
> extract the domain number. Other places, use the actual domain number from
> the device.
> 
> Signed-off-by: Sinan Kaya 
> ---
>  include/linux/i7300_idle.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/i7300_idle.h b/include/linux/i7300_idle.h
> index 4dbe651..58cd9c6 100644
> --- a/include/linux/i7300_idle.h
> +++ b/include/linux/i7300_idle.h
> @@ -48,7 +48,7 @@ static inline int i7300_idle_platform_probe(struct pci_dev 
> **fbd_dev,
>   int i;
>   struct pci_dev *memdev, *dmadev;
>  
> - memdev = pci_get_bus_and_slot(MEMCTL_BUS, MEMCTL_DEVFN);
> + memdev = pci_get_domain_bus_and_slot(0, MEMCTL_BUS, MEMCTL_DEVFN);

You have a pci_dev, why can't you use it here to get the domain?

>   if (!memdev)
>   return -ENODEV;
>  
> @@ -61,7 +61,7 @@ static inline int i7300_idle_platform_probe(struct pci_dev 
> **fbd_dev,
>   if (pci_tbl[i].vendor == 0)
>   return -ENODEV;
>  
> - dmadev = pci_get_bus_and_slot(IOAT_BUS, IOAT_DEVFN);
> + dmadev = pci_get_domain_bus_and_slot(0, IOAT_BUS, IOAT_DEVFN);

Same here.

thanks,

greg k-h

[tip:x86/urgent] x86/mm/kasan: Don't use vmemmap_populate() to initialize shadow

[tip-bot for Andrey Ryabinin]

Commit-ID:  f68d62a56708b0c19dca7a998f408510f2fbc3a8
Gitweb: https://git.kernel.org/tip/f68d62a56708b0c19dca7a998f408510f2fbc3a8
Author: Andrey Ryabinin 
AuthorDate: Wed, 15 Nov 2017 17:36:35 -0800
Committer:  Ingo Molnar 
CommitDate: Wed, 22 Nov 2017 07:18:35 +0100

x86/mm/kasan: Don't use vmemmap_populate() to initialize shadow

[ Note, this commit is a cherry-picked version of:

d17a1d97dc20: ("x86/mm/kasan: don't use vmemmap_populate() to initialize 
shadow")

  ... for easier x86 entry code testing and back-porting. ]

The KASAN shadow is currently mapped using vmemmap_populate() since that
provides a semi-convenient way to map pages into init_top_pgt.  However,
since that no longer zeroes the mapped pages, it is not suitable for
KASAN, which requires zeroed shadow memory.

Add kasan_populate_shadow() interface and use it instead of
vmemmap_populate().  Besides, this allows us to take advantage of
gigantic pages and use them to populate the shadow, which should save us
some memory wasted on page tables and reduce TLB pressure.

Link: http://lkml.kernel.org/r/20171103185147.2688-2-pasha.tatas...@oracle.com
Signed-off-by: Andrey Ryabinin 
Signed-off-by: Pavel Tatashin 
Cc: Andy Lutomirski 
Cc: Steven Sistare 
Cc: Daniel Jordan 
Cc: Bob Picco 
Cc: Michal Hocko 
Cc: Alexander Potapenko 
Cc: Ard Biesheuvel 
Cc: Catalin Marinas 
Cc: Christian Borntraeger 
Cc: David S. Miller 
Cc: Dmitry Vyukov 
Cc: Heiko Carstens 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Mark Rutland 
Cc: Matthew Wilcox 
Cc: Mel Gorman 
Cc: Michal Hocko 
Cc: Sam Ravnborg 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig|   2 +-
 arch/x86/mm/kasan_init_64.c | 143 +---
 2 files changed, 137 insertions(+), 8 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a0623f0..09dcc94 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -110,7 +110,7 @@ config X86
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HUGE_VMAP  if X86_64 || X86_PAE
select HAVE_ARCH_JUMP_LABEL
-   select HAVE_ARCH_KASAN  if X86_64 && SPARSEMEM_VMEMMAP
+   select HAVE_ARCH_KASAN  if X86_64
select HAVE_ARCH_KGDB
select HAVE_ARCH_KMEMCHECK
select HAVE_ARCH_MMAP_RND_BITS  if MMU
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 2b60dc6..99dfed6 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -4,12 +4,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,7 +20,134 @@ extern struct range pfn_mapped[E820_MAX_ENTRIES];
 
 static p4d_t tmp_p4d_table[PTRS_PER_P4D] __initdata __aligned(PAGE_SIZE);
 
-static int __init map_range(struct range *range)
+static __init void *early_alloc(size_t size, int nid)
+{
+   return memblock_virt_alloc_try_nid_nopanic(size, size,
+   __pa(MAX_DMA_ADDRESS), BOOTMEM_ALLOC_ACCESSIBLE, nid);
+}
+
+static void __init kasan_populate_pmd(pmd_t *pmd, unsigned long addr,
+ unsigned long end, int nid)
+{
+   pte_t *pte;
+
+   if (pmd_none(*pmd)) {
+   void *p;
+
+   if (boot_cpu_has(X86_FEATURE_PSE) &&
+   ((end - addr) == PMD_SIZE) &&
+   IS_ALIGNED(addr, PMD_SIZE)) {
+   p = early_alloc(PMD_SIZE, nid);
+   if (p && pmd_set_huge(pmd, __pa(p), PAGE_KERNEL))
+   return;
+   else if (p)
+   memblock_free(__pa(p), PMD_SIZE);
+   }
+
+   p = early_alloc(PAGE_SIZE, nid);
+   pmd_populate_kernel(_mm, pmd, p);
+   }
+
+   pte = pte_offset_kernel(pmd, addr);
+   do {
+   pte_t entry;
+   void *p;
+
+   if (!pte_none(*pte))
+   continue;
+
+   p = early_alloc(PAGE_SIZE, nid);
+   entry = pfn_pte(PFN_DOWN(__pa(p)), PAGE_KERNEL);
+   set_pte_at(_mm, addr, pte, entry);
+   } while (pte++, addr += PAGE_SIZE, addr != end);
+}
+
+static void 

Re: Regression with a91d66129fb9 ("ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal")

[Takashi Iwai]

On Tue, 21 Nov 2017 17:25:05 +0100,
Takashi Iwai wrote:
> 
> On Tue, 21 Nov 2017 17:14:42 +0100,
> Laura Abbott wrote:
> > 
> > Hi,
> > 
> > Fedora got a bug report 
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1512853)
> > that Line Out stopped working between 4.13.9 and 4.13.10. Reverting
> > 82d745a55779 ("ALSA: hda - Fix incorrect TLV callback check introduced 
> > during set_fs() removal")
> > fixed the problem. I didn't ask the reporter to test on 4.14 since I didn't 
> > see
> > anything explicitly tagged as fixing the issue. Any ideas?
> 
> It might be that the formerly saved asound.state brought the
> inconsistency.  Try to remove the saved state (either
> /var/lib/alsa/asound.state or /etc/asound.state) after unloading the
> sound driver modules and reboot/retest.
> 
> In anyway, give alsa-info.sh output with the affected machine.
> Run the script with --no-upload option, and attach the generated
> file.

BTW, having the output of alsa-info.sh with a bug report helps
analysis and debugging quite a lot.

So it'd be appreciated if you can ask it always as the first step for
a bug report on Fedora regarding sound.  Especially when it's a
regression, the outputs on both working and non-working cases would be
nice, so that we can compare more precisely.


thanks,

Takashi

Re: [PATCH 12/30] Drivers: ide: deprecate pci_get_bus_and_slot()

[Greg KH]

On Wed, Nov 22, 2017 at 12:30:57AM -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
> 
> Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
> extract the domain number. Other places, use the actual domain number from
> the device.

While this is a great generic text, you might want to make it a bit more
custom to each specific patch.  For example, you don't use a domain of 0
in this one, so the text is a bit wrong and confusing if you look at it
stand-alone.

I like the series and the idea, just fix up this text in some of the
patches and you should be fine.

thanks,

greg k-h

Re: [PATCH v4 4/4] drivers/fsi: sbefifo: Add in-kernel API

[kbuild test robot]

Hi Edward,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Eddie-James/drivers-fsi-Add-SBEFIFO-client-driver/20171121-024602
config: um-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   WARNING: "memcpy" [drivers/net/ppp/ppp_generic.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/ppp/ppp_async.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/phy/xilinx_gmii2rgmii.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/phy/micrel.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/phy/mdio-gpio.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/phy/marvell.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/phy/bcm-phy-lib.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/netconsole.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/macvlan.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/macsec.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/ipvlan/ipvlan.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/hamradio/yam.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/hamradio/mkiss.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/hamradio/hdlcdrv.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/hamradio/bpqether.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/hamradio/6pack.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/geneve.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/ethernet/qualcomm/rmnet/rmnet.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/ethernet/qualcomm/qcauart.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/ethernet/mellanox/mlxsw/mlxsw_i2c.ko] has no 
CRC!
   WARNING: "memcpy" [drivers/net/ethernet/mellanox/mlxsw/mlxsw_core.ko] has no 
CRC!
   WARNING: "memcpy" [drivers/net/dummy.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/dsa/mv88e6xxx/mv88e6xxx.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/dsa/microchip/ksz_common.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/dsa/dsa_loop.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/dsa/b53/b53_common.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/can/slcan.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/can/can-dev.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/caif/caif_serial.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/caif/caif_hsi.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/bonding/bonding.ko] has no CRC!
   WARNING: "memcpy" [drivers/net/appletalk/ipddp.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/ubi/ubi.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/tests/mtd_pagetest.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/tests/mtd_nandecctest.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/tests/mtd_nandbiterrs.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/spi-nor/spi-nor.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/sm_ftl.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/nftl.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/nand/nandsim.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/nand/nand.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/mtdswap.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/mtdblock.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/mtd.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/lpddr/qinfo_probe.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/lpddr/lpddr_cmds.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/inftl.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/chips/map_rom.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/chips/map_ram.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/chips/jedec_probe.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/chips/gen_probe.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/chips/cfi_util.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/chips/cfi_probe.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/chips/cfi_cmdset_0020.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/chips/cfi_cmdset_0002.ko] has no CRC!
   WARNING: "memcpy" [drivers/mtd/chips/cfi_cmdset_0001.ko] has no CRC!
   WARNING: "memcpy" [drivers/misc/ti-st/st_drv.ko] has no CRC!
   WARNING: "memcpy" [drivers/misc/lkdtm.ko] has no CRC!
   WARNING: "memcpy&

Re: [PATCHv2] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[Hans Verkuil]

On 11/21/2017 07:48 AM, Laurent Pinchart wrote:
> Hi Hans,
> 
> Thank you for the patch.
> 
> On Monday, 20 November 2017 22:57:34 EET Hans Verkuil wrote:
>> If the device tree for a board did not specify a cec clock, then
>> adv7511_cec_init would return an error, which would cause adv7511_probe()
>> to fail and thus there is no HDMI output.
>>
>> There is no need to have adv7511_probe() fail if the CEC initialization
>> fails, so just change adv7511_cec_init() to a void function. In addition,
>> adv7511_cec_init() should just return silently if the cec clock isn't
>> found and show a message for any other errors.
> 
> I don't think that's correct. You at least need to defer probing if the clock 
> is specified in DT but has no provider available yet. For other errors I 
> agree 
> that we can still initialize the ADV7511 in a degraded mode without CEC 
> support, although I would prefer to also error out in case of invalid DT to 
> ensure that DT errors are caught as early as possible.

Ah yes, probe deferring, I forgot about that. I'll make a v3.
The only other possible error is ENOENT for when no CEC clock is defined,
which just means it should continue without CEC (i.e. this is not an error).

I'll make a v3, also incorporating your other comments below.

Regards,

Hans

> 
>> An otherwise correct cleanup patch from Dan Carpenter turned this broken
>> failure handling into a kernel Oops, so bisection points to commit
>> 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL") rather
>> than 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support").
>>
>> Based on earlier patches from Arnd and John.
>>
>> Reported-by: Naresh Kamboju 
>> Cc: Xinliang Liu 
>> Cc: Dan Carpenter 
>> Cc: Sean Paul 
>> Cc: Archit Taneja 
>> Cc: John Stultz 
>> Link: https://bugs.linaro.org/show_bug.cgi?id=3345
>> Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
>> Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
>> Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
>> Signed-off-by: Hans Verkuil 
>> Tested-by: Hans Verkuil 
>> ---
>> This rework of Arnd and John's patches goes a bit further and makes
>> cec_init a void function and just silently exits if there is no cec clock
>> defined in the dts. I'm sure that's the reason why the kirin board failed
>> on this. BTW: if the kirin board DOES support cec, then it would be nice
>> if it can be hooked up in the dts!
>>
>> Tested with my Dragonboard and Renesas Koelsch board.
>>
>> Change since my previous RFC PATCH:
>>
>> - added static inline adv7511_cec_init to avoid #ifdef in the probe function
>> as suggested by John Stultz.
>>
>> Regards,
>>
>>  Hans
>> ---
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index 543a5eb91624..16051bfa5578
>> 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -374,9 +374,17 @@ struct adv7511 {
>>  };
>>
>>  #ifdef CONFIG_DRM_I2C_ADV7511_CEC
>> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
>> - unsigned int offset);
>> +void adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
>> +  unsigned int offset);
>>  void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
>> +#else
>> +static inline void adv7511_cec_init(struct device *dev,
>> +struct adv7511 *adv7511,
>> +unsigned int offset)
>> +{
>> +regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
>> + ADV7511_CEC_CTRL_POWER_DOWN);
>> +}
>>  #endif
>>
>>  #ifdef CONFIG_DRM_I2C_ADV7533
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c index
>> b33d730e4d73..c1cd471d31fa 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
>> @@ -300,18 +300,20 @@ static int adv7511_cec_parse_dt(struct device *dev,
>> struct adv7511 *adv7511) return 0;
>>  }
>>
>> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
>> - unsigned int offset)
>> +void adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
>> +  unsigned int offset)
>>  {
>>  int ret = adv7511_cec_parse_dt(dev, adv7511);
>>
>>  if (ret)
>> -return ret;
>> +goto disable_cec;
>>
>>  adv7511->cec_adap = cec_allocate_adapter(_cec_adap_ops,
>>  adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
>> -if (IS_ERR(adv7511->cec_adap))
>> -return PTR_ERR(adv7511->cec_adap);
>> +if (IS_ERR(adv7511->cec_adap)) {
>> +ret = PTR_ERR(adv7511->cec_adap);
>> 

Re: [PATCH] c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt

[Patrice CHOTARD]

Hi Gustavo

On 11/20/2017 03:00 PM, Gustavo A. R. Silva wrote:
> _channel_ is being dereferenced before it is null checked, hence there is a
> potential null pointer dereference. Fix this by moving the pointer dereference
> after _channel_ has been null checked.
> 
> This issue was detected with the help of Coccinelle.
> 
> Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>   drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c 
> b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> index 59280ac..23d0ced 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> @@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(unsigned long 
> ac8sectpfei)
>   static void channel_swdemux_tsklet(unsigned long data)
>   {
>   struct channel_info *channel = (struct channel_info *)data;
> - struct c8sectpfei *fei = channel->fei;
> + struct c8sectpfei *fei;
>   unsigned long wp, rp;
>   int pos, num_packets, n, size;
>   u8 *buf;
> @@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsigned long data)
>   if (unlikely(!channel || !channel->irec))
>   return;
>   
> + fei = channel->fei;
> +
>   wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0));
>   rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0));
>   
> 

Acked-by: Patrice Chotard 

Thanks

[PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink

[Jeffy Chen]

The rt5514 dsp captures pcm data through spi directly, so we should not
use rockchip-i2s as it's cpu dai like other codecs.

Use dummy_dai for rt5514 dsp dailink to make voice wakeup work again.

Reported-by: Jimmy Cheng-Yi Chiang 
Fixes: (72cfb0f20c75 ASoC: rockchip: Use codec of_node and dai_name for rt5514 
dsp)
Signed-off-by: Jeffy Chen 
---

 sound/soc/rockchip/rk3399_gru_sound.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index d64fbbd50544..aa8ffd035377 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -367,7 +367,8 @@ static const struct snd_soc_dai_link rockchip_dais[] = {
[DAILINK_RT5514_DSP] = {
.name = "RT5514 DSP",
.stream_name = "Wake on Voice",
-   .codec_dai_name = "rt5514-dsp-cpu-dai",
+   .codec_name = "snd-soc-dummy",
+   .codec_dai_name = "snd-soc-dummy-dai",
},
 };
 
@@ -528,7 +529,18 @@ static int rockchip_sound_of_parse_dais(struct device *dev,
if (index < 0)
continue;
 
-   np_cpu = (index == DAILINK_CDNDP) ? np_cpu1 : np_cpu0;
+   switch (index) {
+   case DAILINK_CDNDP:
+   np_cpu = np_cpu1;
+   break;
+   case DAILINK_RT5514_DSP:
+   np_cpu = np_codec;
+   break;
+   default:
+   np_cpu = np_cpu0;
+   break;
+   }
+
if (!np_cpu) {
dev_err(dev, "Missing 'rockchip,cpu' for %s\n",
rockchip_dais[index].name);
@@ -538,7 +550,8 @@ static int rockchip_sound_of_parse_dais(struct device *dev,
dai = >dai_link[card->num_links++];
*dai = rockchip_dais[index];
 
-   dai->codec_of_node = np_codec;
+   if (!dai->codec_name)
+   dai->codec_of_node = np_codec;
dai->platform_of_node = np_cpu;
dai->cpu_of_node = np_cpu;
 
-- 
2.11.0

[tip:x86/urgent] x86/umip: Print a warning into the syslog if UMIP-protected instructions are used

[tip-bot for Ricardo Neri]

Commit-ID:  fd11a6496e12848d4eeb21029c2c288bbc638048
Gitweb: https://git.kernel.org/tip/fd11a6496e12848d4eeb21029c2c288bbc638048
Author: Ricardo Neri 
AuthorDate: Mon, 20 Nov 2017 19:04:36 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 21 Nov 2017 08:13:43 +0100

x86/umip: Print a warning into the syslog if UMIP-protected instructions are 
used

Print a rate-limited warning when a user-space program attempts to execute
any of the instructions that UMIP protects (i.e., SGDT, SIDT, SLDT, STR
and SMSW).

This is useful, because when CONFIG_X86_INTEL_UMIP=y is selected and
supported by the hardware, user space programs that try to execute such
instructions will receive a SIGSEGV signal that they might not expect.

In the specific cases for which emulation is provided (instructions SGDT,
SIDT and SMSW in protected and virtual-8086 modes), no signal is
generated. However, a warning is helpful to encourage updates in such
programs to avoid the use of such instructions.

Warnings are printed via a customized printk() function that also provides
information about the program that attempted to use the affected
instructions.

Utility macros are defined to wrap umip_printk() for the error and warning
kernel log levels.

While here, replace an existing call to the generic rate-limited pr_err()
with the new umip_pr_err().

Suggested-by: Linus Torvalds 
Signed-off-by: Ricardo Neri 
Reviewed-by: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Tony Luck 
Cc: ricardo.n...@intel.com
Link: 
http://lkml.kernel.org/r/1511233476-17088-1-git-send-email-ricardo.neri-calde...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/umip.c | 62 ++
 1 file changed, 58 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
index 1f1f2d5..dabbac3 100644
--- a/arch/x86/kernel/umip.c
+++ b/arch/x86/kernel/umip.c
@@ -82,6 +82,57 @@
 #defineUMIP_INST_SLDT  3   /* 0F 00 /0 */
 #defineUMIP_INST_STR   4   /* 0F 00 /1 */
 
+const char * const umip_insns[5] = {
+   [UMIP_INST_SGDT] = "SGDT",
+   [UMIP_INST_SIDT] = "SIDT",
+   [UMIP_INST_SMSW] = "SMSW",
+   [UMIP_INST_SLDT] = "SLDT",
+   [UMIP_INST_STR] = "STR",
+};
+
+#define umip_pr_err(regs, fmt, ...) \
+   umip_printk(regs, KERN_ERR, fmt, ##__VA_ARGS__)
+#define umip_pr_warning(regs, fmt, ...) \
+   umip_printk(regs, KERN_WARNING, fmt,  ##__VA_ARGS__)
+
+/**
+ * umip_printk() - Print a rate-limited message
+ * @regs:  Register set with the context in which the warning is printed
+ * @log_level: Kernel log level to print the message
+ * @fmt:   The text string to print
+ *
+ * Print the text contained in @fmt. The print rate is limited to bursts of 5
+ * messages every two minutes. The purpose of this customized version of
+ * printk() is to print messages when user space processes use any of the
+ * UMIP-protected instructions. Thus, the printed text is prepended with the
+ * task name and process ID number of the current task as well as the
+ * instruction and stack pointers in @regs as seen when entering kernel mode.
+ *
+ * Returns:
+ *
+ * None.
+ */
+static __printf(3, 4)
+void umip_printk(const struct pt_regs *regs, const char *log_level,
+const char *fmt, ...)
+{
+   /* Bursts of 5 messages every two minutes */
+   static DEFINE_RATELIMIT_STATE(ratelimit, 2 * 60 * HZ, 5);
+   struct task_struct *tsk = current;
+   struct va_format vaf;
+   va_list args;
+
+   if (!__ratelimit())
+   return;
+
+   va_start(args, fmt);
+   vaf.fmt = fmt;
+   vaf.va = 
+   printk("%s" pr_fmt("%s[%d] ip:%lx sp:%lx: %pV"), log_level, tsk->comm,
+  task_pid_nr(tsk), regs->ip, regs->sp, );
+   va_end(args);
+}
+
 /**
  * identify_insn() - Identify a UMIP-protected instruction
  * @insn:  Instruction structure with opcode and ModRM byte.
@@ -236,10 +287,8 @@ static void force_sig_info_umip_fault(void __user *addr, 
struct pt_regs *regs)
if (!(show_unhandled_signals && unhandled_signal(tsk, SIGSEGV)))
return;
 
-   pr_err_ratelimited("%s[%d] umip emulation segfault ip:%lx sp:%lx 
error:%x in %lx\n",
-  tsk->comm, task_pid_nr(tsk), regs->ip,
-  regs->sp, X86_PF_USER | X86_PF_WRITE,
-  regs->ip);
+   umip_pr_err(regs, 

[PATCH 2/2] perf intel-pt: Bring instruction decoder files into line with the kernel

[Adrian Hunter]

There are just a few new defines which do not affect perf tools.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt-decoder/inat.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/perf/util/intel-pt-decoder/inat.h 
b/tools/perf/util/intel-pt-decoder/inat.h
index 125ecd2a300d..52dc8d911173 100644
--- a/tools/perf/util/intel-pt-decoder/inat.h
+++ b/tools/perf/util/intel-pt-decoder/inat.h
@@ -97,6 +97,16 @@
 #define INAT_MAKE_GROUP(grp)   ((grp << INAT_GRP_OFFS) | INAT_MODRM)
 #define INAT_MAKE_IMM(imm) (imm << INAT_IMM_OFFS)
 
+/* Identifiers for segment registers */
+#define INAT_SEG_REG_IGNORE0
+#define INAT_SEG_REG_DEFAULT   1
+#define INAT_SEG_REG_CS2
+#define INAT_SEG_REG_SS3
+#define INAT_SEG_REG_DS4
+#define INAT_SEG_REG_ES5
+#define INAT_SEG_REG_FS6
+#define INAT_SEG_REG_GS7
+
 /* Attribute search APIs */
 extern insn_attr_t inat_get_opcode_attribute(insn_byte_t opcode);
 extern int inat_get_last_prefix_id(insn_byte_t last_pfx);
-- 
1.9.1

Re: [patch V2 02/11] LICENSES: Add the GPL 2.0 license

[Jonas Oberg]

Hi Alan,

> Which raises another question. If there are multiple GPL 2.0 texts which
> are *supposedly* legally identical but this has never been tested in law
> -that implies SPDX is wrong in tagging them identically in case they turn
> out not to be...

For the cases, and the differences we're talking about now, I believe the
current approach is fine. In the general case though, the FSFE's REUSE
recommendations are that for situations where the license in use differ
from the one included in SPDX, you make use of a local reference to the
license file instead of the SPDX identifier.

This is sometimes the case with the umpteen versions of the BSD licenses.
The way we recommend doing this is you define an identifier of the form
LicenseRef- (consistent with the SPDX specification).
Source code files would be marked up with:

   SPDX-License-Identifier: LicenseRef-MyBSD4

and the corresponding license file in LICENSES/ with:

   Valid-License-Identifier: LicenseRef-MyBSD4
   License-Text:
 ...


Best,

-- 
Jonas Öberg
Executive Director

FSFE e.V. - keeping the power of technology in your hands. Your
support enables our work, please join us today http://fsfe.org/join

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk

[Christian Borntraeger]

On 11/20/2017 09:52 PM, Jens Axboe wrote:
> On 11/20/2017 01:49 PM, Christian Borntraeger wrote:
>>
>>
>> On 11/20/2017 08:42 PM, Jens Axboe wrote:
>>> On 11/20/2017 12:29 PM, Christian Borntraeger wrote:


 On 11/20/2017 08:20 PM, Bart Van Assche wrote:
> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote:
>> This is 
>>
>> b7a71e66d (Jens Axboe2017-08-01 09:28:24 -0600 1141) 
>> * are mapped to it.
>> b7a71e66d (Jens Axboe2017-08-01 09:28:24 -0600 1142) 
>> */
>> 6a83e74d2 (Bart Van Assche   2016-11-02 10:09:51 -0600 1143)
>> WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) &&
>> 6a83e74d2 (Bart Van Assche   2016-11-02 10:09:51 -0600 1144) 
>>cpu_online(hctx->next_cpu));
>> 6a83e74d2 (Bart Van Assche   2016-11-02 10:09:51 -0600 1145) 
>> b7a71e66d (Jens Axboe2017-08-01 09:28:24 -0600 1146)
>> /*
>
> Did you really try to figure out when the code that reported the warning
> was introduced? I think that warning was introduced through the following
> commit:

 This was more a cut'n'paste to show which warning triggered since line 
 numbers are somewhat volatile.

>
> commit fd1270d5df6a005e1248e87042159a799cc4b2c9
> Date:   Wed Apr 16 09:23:48 2014 -0600
>
> blk-mq: don't use preempt_count() to check for right CPU
>  
> UP or CONFIG_PREEMPT_NONE will return 0, and what we really
> want to check is whether or not we are on the right CPU.
> So don't make PREEMPT part of this, just test the CPU in
> the mask directly.
>
> Anyway, I think that warning is appropriate and useful. So the next step
> is to figure out what work item was involved and why that work item got
> executed on the wrong CPU.

 It seems to be related to virtio-blk (is triggered by fio on such disks). 
 Your comment basically
 says: "no this is not a known issue" then :-)
 I will try to take a dump to find out the work item
>>>
>>> blk-mq does not attempt to freeze/sync existing work if a CPU goes away,
>>> and we reconfigure the mappings. So I don't think the above is unexpected,
>>> if you are doing CPU hot unplug while running a fio job.
>>
>> I did a cpu hot plug (adding a CPU) and I started fio AFTER that.
> 
> OK, that's different, we should not be triggering a warning for that.
> What does your machine/virtblk topology look like in terms of CPUS,
> nr of queues for virtblk, etc?

FWIW, 4.11 does work, 4.12 and later is broken.

> 
> You can probably get this info the easiest by just doing a:
> 
> # find /sys/kernel/debug/block/virtX
> 
> replace virtX with your virtblk device name. Generate this info both
> before and after the hotplug event.

It happens in all variants (1 cpu to 2 or 16 to 17 and independent of the
number of disks).

What I can see is that the block layer does not yet sees the new CPU:

[root@zhyp137 ~]# find /sys/kernel/debug/block/vd* 
/sys/kernel/debug/block/vda
/sys/kernel/debug/block/vda/hctx0
/sys/kernel/debug/block/vda/hctx0/cpu0
/sys/kernel/debug/block/vda/hctx0/cpu0/completed
/sys/kernel/debug/block/vda/hctx0/cpu0/merged
/sys/kernel/debug/block/vda/hctx0/cpu0/dispatched
/sys/kernel/debug/block/vda/hctx0/cpu0/rq_list
/sys/kernel/debug/block/vda/hctx0/active
/sys/kernel/debug/block/vda/hctx0/run
/sys/kernel/debug/block/vda/hctx0/queued
/sys/kernel/debug/block/vda/hctx0/dispatched
/sys/kernel/debug/block/vda/hctx0/io_poll
/sys/kernel/debug/block/vda/hctx0/sched_tags_bitmap
/sys/kernel/debug/block/vda/hctx0/sched_tags
/sys/kernel/debug/block/vda/hctx0/tags_bitmap
/sys/kernel/debug/block/vda/hctx0/tags
/sys/kernel/debug/block/vda/hctx0/ctx_map
/sys/kernel/debug/block/vda/hctx0/busy
/sys/kernel/debug/block/vda/hctx0/dispatch
/sys/kernel/debug/block/vda/hctx0/flags
/sys/kernel/debug/block/vda/hctx0/state
/sys/kernel/debug/block/vda/sched
/sys/kernel/debug/block/vda/sched/dispatch
/sys/kernel/debug/block/vda/sched/starved
/sys/kernel/debug/block/vda/sched/batching
/sys/kernel/debug/block/vda/sched/write_next_rq
/sys/kernel/debug/block/vda/sched/write_fifo_list
/sys/kernel/debug/block/vda/sched/read_next_rq
/sys/kernel/debug/block/vda/sched/read_fifo_list
/sys/kernel/debug/block/vda/write_hints
/sys/kernel/debug/block/vda/state
/sys/kernel/debug/block/vda/requeue_list
/sys/kernel/debug/block/vda/poll_stat

--> in host virsh setvcpu zhyp137 2

[root@zhyp137 ~]# chcpu -e 1
CPU 1 enabled
[root@zhyp137 ~]# find /sys/kernel/debug/block/vd* 
/sys/kernel/debug/block/vda
/sys/kernel/debug/block/vda/hctx0
/sys/kernel/debug/block/vda/hctx0/cpu0
/sys/kernel/debug/block/vda/hctx0/cpu0/completed
/sys/kernel/debug/block/vda/hctx0/cpu0/merged
/sys/kernel/debug/block/vda/hctx0/cpu0/dispatched
/sys/kernel/debug/block/vda/hctx0/cpu0/rq_list
/sys/kernel/debug/block/vda/hctx0/active

Re: [PATCH 1/2] perf intel-pt: Improve build messages for files that differ from the kernel

[Ingo Molnar]

* Adrian Hunter  wrote:

> Print file names of files that differ. For example, instead of:
> 
>   Warning: Intel PT: x86 instruction decoder differs from kernel
> 
> print:
> 
>   Warning: Intel PT: x86 instruction decoder header at 
> 'tools/perf/util/intel-pt-decoder/inat.h' differs from latest version at 
> 'arch/x86/include/asm/inat.h'
> 
> Signed-off-by: Adrian Hunter 
> ---
>  tools/perf/util/intel-pt-decoder/Build | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/perf/util/intel-pt-decoder/Build 
> b/tools/perf/util/intel-pt-decoder/Build
> index 10e0814bb8d2..1b704fbea9de 100644
> --- a/tools/perf/util/intel-pt-decoder/Build
> +++ b/tools/perf/util/intel-pt-decoder/Build
> @@ -11,15 +11,21 @@ $(OUTPUT)util/intel-pt-decoder/inat-tables.c: 
> $(inat_tables_script) $(inat_table
>  
>  $(OUTPUT)util/intel-pt-decoder/intel-pt-insn-decoder.o: 
> util/intel-pt-decoder/intel-pt-insn-decoder.c util/intel-pt-decoder/inat.c 
> $(OUTPUT)util/intel-pt-decoder/inat-tables.c
>   @(diff -I 2>&1 | grep -q 'option requires an argument' && \
> - test -d ../../kernel -a -d ../../tools -a -d ../perf && (( \
> - diff -B -I'^#include' util/intel-pt-decoder/insn.c 
> ../../arch/x86/lib/insn.c >/dev/null && \
> - diff -B -I'^#include' util/intel-pt-decoder/inat.c 
> ../../arch/x86/lib/inat.c >/dev/null && \
> - diff -B util/intel-pt-decoder/x86-opcode-map.txt 
> ../../arch/x86/lib/x86-opcode-map.txt >/dev/null && \
> - diff -B util/intel-pt-decoder/gen-insn-attr-x86.awk 
> ../../arch/x86/tools/gen-insn-attr-x86.awk >/dev/null && \
> - diff -B -I'^#include' util/intel-pt-decoder/insn.h 
> ../../arch/x86/include/asm/insn.h >/dev/null && \
> - diff -B -I'^#include' util/intel-pt-decoder/inat.h 
> ../../arch/x86/include/asm/inat.h >/dev/null && \
> - diff -B -I'^#include' util/intel-pt-decoder/inat_types.h 
> ../../arch/x86/include/asm/inat_types.h >/dev/null) \
> - || echo "Warning: Intel PT: x86 instruction decoder differs from 
> kernel" >&2 )) || true
> + test -d ../../kernel -a -d ../../tools -a -d ../perf && ( \
> + ((diff -B -I'^#include' util/intel-pt-decoder/insn.c 
> ../../arch/x86/lib/insn.c >/dev/null) || \
> + (echo "Warning: Intel PT: x86 instruction decoder C file at 
> 'tools/perf/util/intel-pt-decoder/insn.c' differs from latest version at 
> 'arch/x86/lib/insn.c'" >&2)) && \
> + ((diff -B -I'^#include' util/intel-pt-decoder/inat.c 
> ../../arch/x86/lib/inat.c >/dev/null) || \
> + (echo "Warning: Intel PT: x86 instruction decoder C file at 
> 'tools/perf/util/intel-pt-decoder/inat.c' differs from latest version at 
> 'arch/x86/lib/inat.c'" >&2)) && \
> + ((diff -B util/intel-pt-decoder/x86-opcode-map.txt 
> ../../arch/x86/lib/x86-opcode-map.txt >/dev/null) || \
> + (echo "Warning: Intel PT: x86 instruction decoder map file at 
> 'tools/perf/util/intel-pt-decoder/x86-opcode-map.txt' differs from latest 
> version at 'arch/x86/lib/x86-opcode-map.txt'" >&2)) && \
> + ((diff -B util/intel-pt-decoder/gen-insn-attr-x86.awk 
> ../../arch/x86/tools/gen-insn-attr-x86.awk >/dev/null) || \
> + (echo "Warning: Intel PT: x86 instruction decoder script at 
> 'tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk' differs from latest 
> version at 'arch/x86/tools/gen-insn-attr-x86.awk'" >&2)) && \
> + ((diff -B -I'^#include' util/intel-pt-decoder/insn.h 
> ../../arch/x86/include/asm/insn.h >/dev/null) || \
> + (echo "Warning: Intel PT: x86 instruction decoder header at 
> 'tools/perf/util/intel-pt-decoder/insn.h' differs from latest version at 
> 'arch/x86/include/asm/insn.h'" >&2)) && \
> + ((diff -B -I'^#include' util/intel-pt-decoder/inat.h 
> ../../arch/x86/include/asm/inat.h >/dev/null) || \
> + (echo "Warning: Intel PT: x86 instruction decoder header at 
> 'tools/perf/util/intel-pt-decoder/inat.h' differs from latest version at 
> 'arch/x86/include/asm/inat.h'" >&2)) && \
> + ((diff -B -I'^#include' util/intel-pt-decoder/inat_types.h 
> ../../arch/x86/include/asm/inat_types.h >/dev/null) || \
> + (echo "Warning: Intel PT: x86 instruction decoder header at 
> 'tools/perf/util/intel-pt-decoder/inat_types.h' differs from latest version 
> at 'arch/x86/include/asm/inat_types.h'" >&2 || true
>   $(call rule_mkdir)
>   $(call if_changed_dep,cc_o_c)

Could we please factor this out into a helper, sharing more code with 
tools/perf/check-headers.sh?

Also, I'd suggest removing this from check-headers.sh:

  opts="--ignore-blank-lines --ignore-space-change"

as the easiest policy is to just follow the upstream UAPI header version 100%. 
Pure space-only changes are comparatively rare.

I.e. something like the patch below?

Thanks,

Ingo

---
Signed-off-by: Ingo Molnar 

 tools/perf/check-headers.sh | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/check-headers.sh 

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

[Daniel Vetter]

On Tue, Nov 21, 2017 at 08:58:51AM +0100, Greg KH wrote:
> On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote:
> > Of course our CI is open, so if someone is supremely bored and wants to
> > backport more stuff for drm/i915, they could do that. But atm it doesn't
> > happen, and then having to deal with the fallout is not really great (like
> > I said, we don't really have anyone dedicated, and I much prefer we
> > fix/improve upstream).
> 
> Any reason you can't add the stable -rc tree to your CI system?

The problem is looking at results and making sure nothing breaks and
sending mails out that patches shouldn't be applied and all that. Keeping
the machines busy is the easy part.

For Linus' -rc/-fixes we do that (including human review of all the stuff
the scripts suggests we need to cherry-pick as fixes), but that's because
we have someone.

Maybe we can/should look into doing the same for the current stable (to
support fedora and other community distros a bit better). But I think
there's no way we can support all the LTS kernels out there and more than
just minimal backports.

> > For the actual products we're shipping we have dedicated teams doing the
> > backports. The upstream stable releases essentially have no value for us
> > from a customer support pov (for drivers, I guess core stuff is an
> > entirely different matter), there's not a single serious customer or
> > bigger user using that. It only costs, by spamming us with mails and bug
> > reports for stuff we didn't even nominate :-)
> 
> Any reason why you aren't sending those backported patches to the stable
> trees so that users of them can benefit from the work you are already
> doing for a limited number of "customers"?

They fail your backporting criteria. Big time, like veeery big time.

Think backporting 1k patches to get some feature. Which then means it's a
frankenkernel without any relation to any shipping stable drm/i915
release, so the backports of the bugfixes are again meaningless and
untested for anything else.

Tbh the easies for us to support is what rhel does for their updates,
which is just copy all of drivers/gpu/ into their old lts kernel and then
fix things up at the seams.

> And if your customers are not using stable kernel releases, what are
> they using for their kernels?

LTS, but with a frankenstein drm/i915. To clarify, all I'm discussing here
is just drm and drm/i915 patches, I think for core code the stable process
works reasonably well (afaiui at least).

> It sounds like you don't want to deal with the "automated" patches for
> the i915 drivers, so that's fine, we will blacklist them and ignore
> them and only deal with the patches you explicitly ask to be backported.
> As it seems like those are hard enough for you all to deal with, given
> the recent regression :)

Yeah that would at least not make it worse.

On the entire problem (that we share with amd folks, see Alex' reply) of
how to ship gpu kernel driver updates to people who care, but don't want
to track latest upstream releases, I'd love to have a solution. I just
don't see one (except tons of manual backport work).

Fundamentally the problem is that the product freeze cycle for core kernel
code (measured in years often) is just plain unsuitable for gfx drivers
(where in userspace we often end up shipping well-tested points from
master because the quarterly releases are too slow).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

active bugs in the first week of 4.15 merge window

[Fengguang Wu]

Hi Linus,

We see the below boot error IDs in 0day testing on your pre-RC1
merge commits. Most of them are not new regressions, and some are
known problems that have fixup patches planned for the upcoming -RC1.

In this thread, I'll show details and reproduce information for some
of them, hoping to shake off more old boot errors in mainline kernel.

BUG:kernel-hang-in-boot-stage
BUG:kernel-hang-in-test-stage
BUG:kernel-reboot-without-warning-in-test-stage
BUG:sleeping-function-called-from-invalid-context-at-lib-ioremap.c
BUG:unable-to-handle-kernel-NULL-pointer-dereference-at
BUG:unable-to-handle-kernel-NULL-pointer-dereference-at-null
BUG:unable-to-handle-kernel-paging-request-at
BUG:workqueue-lockup-pool
BUG:workqueue-lockup-pool-cpus=-node=-flags=-nice=-stuck-for
EIP:core_kernel_text
EIP:debug_lockdep_rcu_enabled
EIP:ftrace_likely_update
EIP:init_kernel_text
EIP:io_serial_in
EIP:io_serial_out
EIP:kernel_text_address
EIP:kvm_clock_read
EIP:memcmp
EIP:unwind_next_frame
INFO:rcu_preempt-detected-stalls-on-CPUs-tasks:
INFO:rcu_sched-detected-stalls-on-CPUs-tasks:
IP-Config:Auto-configuration-of-network-failed
Kernel-panic-not-syncing:Fatal-exception
Kernel-panic-not-syncing:hung_task:blocked-tasks
Kernel-panic-not-syncing:softlockup:hung-tasks
Oops:
Oops:PREEMPT-SMP
RIP:__asan_load1
RIP:__asan_load8
RIP:__asan_loadN
RIP:__asan_store8
RIP:__d_alloc
RIP:__do_softirq
RIP:__kernel_text_address
RIP:__lock_acquire
RIP:__lockdep_init_map
RIP:__save_stack_trace
RIP:arch_local_irq_restore
RIP:ata_dev_next
RIP:ata_host_detach
RIP:ata_port_detach
RIP:ata_port_wait_eh
RIP:butterfly_chipselect
RIP:check_memory_region
RIP:cpuidle_enter_state
RIP:deref_stack_reg
RIP:ftrace_likely_update
RIP:interval_tree_insert
RIP:interval_tree_remove
RIP:kasan_kmalloc
RIP:kobject_add_internal
RIP:mempool_free
RIP:native_safe_halt
RIP:pci_disable_device
RIP:perf_swevent_add
RIP:queued_spin_lock_slowpath
RIP:set_task_cpu
RIP:strlen
RIP:sysfs_warn_dup
RIP:trace_event_eval_update
RIP:update_event_printk
WARNING:CPU:PID:at-drivers-ata-libata-core.c-ata_host_detach
WARNING:CPU:PID:at-drivers-ata-libata-core.c-ata_port_detach
WARNING:CPU:PID:at-drivers-pci-pci.c-pci_disable_device
WARNING:CPU:PID:at-fs-sysfs-dir.c-sysfs_warn_dup
WARNING:CPU:PID:at-kernel-events-core.c-perf_swevent_add
WARNING:CPU:PID:at-kernel-locking-lockdep.c-__lock_acquire
WARNING:CPU:PID:at-kernel-sched-core.c-set_task_cpu
WARNING:CPU:PID:at-lib-kobject.c-kobject_add_internal
WARNING:possible-circular-locking-dependency-detected
general-protection-fault
genirq:Flags-mismatch-irq-ttyS0-vs.-sir_ir
softdog:Initiating-system-reboot
watchdog:BUG:soft-lockup-CPU-stuck-for-swapper

Regards,
Fengguang

Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails

[Javier Martinez Canillas]

Hello Jarkko,

On 11/21/2017 12:15 AM, Jarkko Sakkinen wrote:
> On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
>> According to the TPM Library Specification, a TPM device must do a command
>> header validation before processing and return a TPM_RC_COMMAND_CODE code
>> if the command is not implemented and the TPM_RC_COMMAND_SIZE code if the
>> command buffer size is not correct.
>>
>> So user-space will expect to handle these response codes as errors, but if
>> the in-kernel resource manager is used (/dev/tpmrm?) then an -EINVAL errno
>> code is returned instead if the command isn't implemented or the buffer
>> size isn't correct. This confuses user-space since doesn't expect that.
>>
>> This is also not consistent with the behavior when not using TPM spaces
>> and accessing the TPM directly (/dev/tpm?), in this case the command is
>> is sent to the TPM anyways and user-space can get an error from the TPM.
>>
>> Instead of returning an -EINVAL errno code when the tpm_validate_command()
>> function fails, allow the command to be sent to the TPM but just don't do
>> any TPM space management. That way the TPM can report back a proper error
>> and the behavior be consistent when using either /dev/tpm? or /dev/tpmrm?.
>>
>> Signed-off-by: Javier Martinez Canillas 
> 
> It is not a virtual TPM so I don't think that matters. It at least

As mentioned, I think this should be documented. I guess most people
would see the in-kernel resource manager as a virtualized TPM, since
the "TSS TAB and Resource Manager Specification" [0] explains the RM
making an analogy with a virtual memory manager: 

"The Resource Manager (RM) manages the TPM context in a manner similar
to a virtual memory manager. It swaps objects, sessions, and sequences
in and out of the limited TPM memory as needed."

And even your latest LPC presentation mention that the handles in the
in-kernel resource manager are virtualized [1].

And I disagree that it does not matter, since the same spec says:

"This layer is mostly transparent to the upper layers of the TSS and is
not required."

But returning -EINVAL instead of a proper TPM command response with a
TPM_RC_COMMAND_CODE code makes it not transparent to the upper layer.

If the TPM spaces infrastructure is not compliant with the spec, then I
think that should also be documented.

> matters less than breaking the sandbox.
>

Yes, sorry for that. It wasn't clear to me that there was a sandbox and my
lack of familiarity with the code was the reason why I posted as a RFC in
the first place.

Do you agree with Jason's suggestion to send a synthesized TPM command in
the that the command isn't supported?

> /Jarkko
>

[0]: 
https://www.trustedcomputinggroup.org/wp-content/uploads/TSS-TAB-and-Resource-Manager-00-91-PublicReview.pdf
[1]: 
http://linuxplumbersconf.com/2017/ocw//system/presentations/4818/original/TPM2-kernel-evnet-app_tricca-sakkinen.pdf

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

[PATCH V7 0/2] clk: qcom: spmi_pmic clock divider support

[Tirupathi Reddy]

The SPMI_PMIC clock divider driver configures the clkdiv modules present
on Qualcomm Technologies, Inc. SPMI PMIC. This driver provides a clock
interface for each clkdiv module and allows clock operations such as enable,
disable, set_rate, recalc_rate and round_rate.

Tirupathi Reddy (2):
  clk: qcom: Add spmi_pmic clock divider support
  dt-bindings: Add qcom spmi_pmic clock divider bindings

 .../bindings/clock/qcom,spmi-pmic-div.txt  |  59 
 drivers/clk/qcom/Kconfig   |   9 +
 drivers/clk/qcom/Makefile  |   1 +
 drivers/clk/qcom/clk-spmi-pmic-div.c   | 302 +
 4 files changed, 371 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/qcom,spmi-pmic-div.txt
 create mode 100644 drivers/clk/qcom/clk-spmi-pmic-div.c

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

[PATCH V7 1/2] clk: qcom: Add spmi_pmic clock divider support

[Tirupathi Reddy]

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

Signed-off-by: Stephen Boyd 
Signed-off-by: Tirupathi Reddy 
---
 drivers/clk/qcom/Kconfig |   9 ++
 drivers/clk/qcom/Makefile|   1 +
 drivers/clk/qcom/clk-spmi-pmic-div.c | 302 +++
 3 files changed, 312 insertions(+)
 create mode 100644 drivers/clk/qcom/clk-spmi-pmic-div.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 9f6c278..20b5d6f 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -196,3 +196,12 @@ config MSM_MMCC_8996
  Support for the multimedia clock controller on msm8996 devices.
  Say Y if you want to support multimedia devices such as display,
  graphics, video encode/decode, camera, etc.
+
+config SPMI_PMIC_CLKDIV
+   tristate "SPMI PMIC clkdiv Support"
+   depends on (COMMON_CLK_QCOM && SPMI) || COMPILE_TEST
+   help
+ This driver supports the clkdiv functionality on the Qualcomm
+ Technologies, Inc. SPMI PMIC. It configures the frequency of
+ clkdiv outputs of the PMIC. These clocks are typically wired
+ through alternate functions on GPIO pins.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 26410d3..602af38 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
 obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
 obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
 obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
+obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/clk-spmi-pmic-div.c 
b/drivers/clk/qcom/clk-spmi-pmic-div.c
new file mode 100644
index 000..8672ab8
--- /dev/null
+++ b/drivers/clk/qcom/clk-spmi-pmic-div.c
@@ -0,0 +1,302 @@
+/* Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_DIV_CTL1   0x43
+#define DIV_CTL1_DIV_FACTOR_MASK   GENMASK(2, 0)
+
+#define REG_EN_CTL 0x46
+#define REG_EN_MASKBIT(7)
+
+struct clkdiv {
+   struct regmap   *regmap;
+   u16 base;
+   spinlock_t  lock;
+
+   struct clk_hw   hw;
+   unsigned intcxo_period_ns;
+};
+
+static inline struct clkdiv *to_clkdiv(struct clk_hw *hw)
+{
+   return container_of(hw, struct clkdiv, hw);
+}
+
+static inline unsigned int div_factor_to_div(unsigned int div_factor)
+{
+   if (!div_factor)
+   div_factor = 1;
+
+   return 1 << (div_factor - 1);
+}
+
+static inline unsigned int div_to_div_factor(unsigned int div)
+{
+   return min(ilog2(div) + 1, 7);
+}
+
+static bool is_spmi_pmic_clkdiv_enabled(struct clkdiv *clkdiv)
+{
+   unsigned int val = 0;
+
+   regmap_read(clkdiv->regmap, clkdiv->base + REG_EN_CTL, );
+
+   return val & REG_EN_MASK;
+}
+
+static int
+__spmi_pmic_clkdiv_set_enable_state(struct clkdiv *clkdiv, bool enable,
+   unsigned int div_factor)
+{
+   int ret;
+   unsigned int ns = clkdiv->cxo_period_ns;
+   unsigned int div = div_factor_to_div(div_factor);
+
+   ret = regmap_update_bits(clkdiv->regmap, clkdiv->base + REG_EN_CTL,
+REG_EN_MASK, enable ? REG_EN_MASK : 0);
+   if (ret)
+   return ret;
+
+   if (enable)
+   ndelay((2 + 3 * div) * ns);
+   else
+   ndelay(3 * div * ns);
+
+   return 0;
+}
+
+static int spmi_pmic_clkdiv_set_enable_state(struct clkdiv *clkdiv, bool 
enable)
+{
+   unsigned int div_factor;
+
+   regmap_read(clkdiv->regmap, clkdiv->base + REG_DIV_CTL1, _factor);
+   div_factor &= DIV_CTL1_DIV_FACTOR_MASK;
+
+   return __spmi_pmic_clkdiv_set_enable_state(clkdiv, enable, div_factor);
+}
+
+static int clk_spmi_pmic_div_enable(struct clk_hw *hw)
+{
+   struct clkdiv *clkdiv = to_clkdiv(hw);
+   unsigned long flags;
+   int ret;
+
+   spin_lock_irqsave(>lock, flags);
+   ret = spmi_pmic_clkdiv_set_enable_state(clkdiv, true);
+   spin_unlock_irqrestore(>lock, flags);
+
+   return ret;
+}
+
+static void 

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

[Tirupathi Reddy T]

On 11/18/2017 5:26 AM, Stephen Boyd wrote:

On 11/17, Tirupathi Reddy wrote:

diff --git a/Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt 
b/Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt
new file mode 100644
index 000..2cf2aba
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt

Please move this to qcom,spmi-clkdiv.txt like other qcom bindings.

Addressed in next patch version[7]



@@ -0,0 +1,59 @@
+Qualcomm Technologies, Inc. SPMI PMIC clock divider (clkdiv)
+
+clkdiv configures the clock frequency of a set of outputs on the PMIC.
+These clocks are typically wired through alternate functions on
+gpio pins.
+
+===
+Properties
+===
+
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: must be "qcom,spmi-clkdiv".
+
+- reg
+   Usage:  required
+   Value type: 
+   Definition: base address of CLKDIV peripherals.
+
+- qcom,num-clkdivs
+   Usage:  required
+   Value type: 
+   Definition: number of CLKDIV peripherals.

Would it work if we read the registers and looked for the clkdiv
subtype ID? If we read something that doesn't match, break and
stop adding clks? Or does reading the next "peripheral" cause
some sort of crash and burn scenario where the device see an
access control violation? Would be interesting to do it that way
and avoid needing a new property in DT.

I feel it is better to go with the current design as we beforehand know the
#div-clk peripherals in a PMIC. Reading the next peripheral might result in
an unknown failure if there is no real peripheral there (PMIC peripherals
are not in contiguous address space).

+
+
+   parent_name = of_clk_get_parent_name(of_node, 0);
+   if (!parent_name) {
+   dev_err(dev, "missing parent clock\n");
+   return -ENODEV;
+   }
+
+   init.parent_names = _name;
+   init.num_parents = 1;
+   init.ops = _spmi_pmic_div_ops;
+
+   for (i = 0, clkdiv = cc->clks; i < nclks; i++) {
+   spin_lock_init([i].lock);
+   clkdiv[i].base = start + i * 0x100;
+   clkdiv[i].regmap = regmap;
+   clkdiv[i].cxo_period_ns = NSEC_PER_SEC / cxo_hz;
+   init.name = kasprintf(GFP_KERNEL, "div_clk%d", i + 1);

Hmm. Maybe we should just have this on the stack. 20 characters
should be plenty?

Addressed in next patch version[7]

+   clkdiv[i].hw.init = 
+
+   ret = devm_clk_hw_register(dev, [i].hw);
+   kfree(init.name); /* clk framework made a copy */
+   if (ret)
+   return ret;
+   }
+
+   return of_clk_add_hw_provider(of_node, spmi_pmic_div_clk_hw_get, cc);
+}
+
+static int spmi_pmic_clkdiv_remove(struct platform_device *pdev)
+{
+   of_clk_del_provider(pdev->dev.of_node);
+
+   return 0;

This can use devm now.

Addressed in next patch version.

+}
+
+static const struct of_device_id spmi_pmic_clkdiv_match_table[] = {
+   { .compatible = "qcom,spmi-clkdiv" },
+   { /* sentinel */ }
+};

Nice!

Thanks

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

[Tirupathi Reddy T]

On 11/18/2017 1:52 AM, Rob Herring wrote:

On Fri, Nov 17, 2017 at 03:18:47PM +0530, Tirupathi Reddy wrote:

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

Signed-off-by: Tirupathi Reddy 
Signed-off-by: Stephen Boyd 

Normally your S-o-B would be last.

Addressed in next patch version [7]



---
  .../bindings/clock/clk-spmi-pmic-div.txt   |  59 

Please split bindings to a separate patch.

Addressed in next patch version [7]


Otherwise,

Acked-by: Rob Herring 


  drivers/clk/qcom/Kconfig   |   9 +
  drivers/clk/qcom/Makefile  |   1 +
  drivers/clk/qcom/clk-spmi-pmic-div.c   | 308 +
  4 files changed, 377 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/clock/clk-spmi-pmic-div.txt
  create mode 100644 drivers/clk/qcom/clk-spmi-pmic-div.c

[PATCH V7 2/2] dt-bindings: Add qcom spmi_pmic clock divider bindings

[Tirupathi Reddy]

This patch adds device tree bindings for Qualcomm SPMI PMIC
clock divider module.

Signed-off-by: Tirupathi Reddy 
---
 .../bindings/clock/qcom,spmi-pmic-div.txt  | 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/qcom,spmi-pmic-div.txt

diff --git a/Documentation/devicetree/bindings/clock/qcom,spmi-pmic-div.txt 
b/Documentation/devicetree/bindings/clock/qcom,spmi-pmic-div.txt
new file mode 100644
index 000..2cf2aba
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,spmi-pmic-div.txt
@@ -0,0 +1,59 @@
+Qualcomm Technologies, Inc. SPMI PMIC clock divider (clkdiv)
+
+clkdiv configures the clock frequency of a set of outputs on the PMIC.
+These clocks are typically wired through alternate functions on
+gpio pins.
+
+===
+Properties
+===
+
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: must be "qcom,spmi-clkdiv".
+
+- reg
+   Usage:  required
+   Value type: 
+   Definition: base address of CLKDIV peripherals.
+
+- qcom,num-clkdivs
+   Usage:  required
+   Value type: 
+   Definition: number of CLKDIV peripherals.
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: reference to the xo clock.
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: must be "xo".
+
+- clock-cells:
+   Usage: required
+   Value type: 
+   Definition: shall contain 1.
+
+===
+Example
+===
+
+pm8998_clk_divs: clock-controller@5b00 {
+   compatible = "qcom,spmi-clkdiv";
+   reg = <0x5b00>;
+   #clock-cells = <1>;
+   qcom,num-clkdivs = <3>;
+   clocks = <_board>;
+   clock-names = "xo";
+
+   assigned-clocks = <_clk_divs 1>,
+ <_clk_divs 2>,
+ <_clk_divs 3>;
+   assigned-clock-rates = <960>,
+  <960>,
+  <960>;
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper

[Mike Galbraith]

On Tue, 2017-11-21 at 09:37 +0100, Thomas Gleixner wrote:
> On Tue, 21 Nov 2017, Mike Galbraith wrote:
> > On Mon, 2017-11-20 at 16:33 -0500, Mikulas Patocka wrote:
> > > 
> > > Is there some specific scenario where you need to call 
> > > blk_schedule_flush_plug from rt_spin_lock_fastlock?
> > 
> > Excellent question.  What's the difference between not getting IO
> > started because you meet a mutex with an rt_mutex under the hood, and
> > not getting IO started because you meet a spinlock with an rt_mutex
> > under the hood?  If just doing the mutex side puts this thing back to
> > sleep, I'm happy.
> 
> Think about it from the mainline POV.
> 
> The spinlock cannot ever go to schedule and therefore cannot create a
> situation which requires an unplug. The RT substitution of the spinlock
> with a rtmutex based sleeping spinlock should not change that at all.
> 
> A regular mutex/rwsem etc. can and will unplug when the lock is contended
> and the caller blocks. The RT conversion of these locks to rtmutex based
> variants creates the problem: Unplug cannot be called when the task has
> pi_blocked_on set because the unplug path might content on yet another
> lock. So unplugging in the slow path before setting pi_blocked_on is the
> right thing to do.

Sure.  What alarms me about IO deadlocks reappearing after all this
time is that at the time I met them, I needed every last bit of that
patchlet I showed to kill them, whether that should have been the case
or not.  'course that tree contained roughly a zillion patches..

Whatever, time will tell if I'm properly alarmed, or merely paranoid :)

-Mike

[PATCH v3 13/16] phy: qcom-qmp: Add support for QMP V3 USB3 PHY

[Manu Gautam]

QMP V3 USB3 PHY is a DisplayPort (DP) and USB combo PHY
with dual RX/TX lanes to support type-c. There is a
separate block DP_COM for configuration related to type-c
or DP. Add support for dp_com region and secondary rx/tx
lanes initialization.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 223 +++-
 1 file changed, 220 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 15a734f..efd187b 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -47,6 +47,21 @@
 /* QPHY_COM_PCS_READY_STATUS bit */
 #define PCS_READY  BIT(0)
 
+/* QPHY_V3_DP_COM_RESET_OVRD_CTRL register bits */
+/* DP PHY soft reset */
+#define SW_DPPHY_RESET BIT(0)
+/* mux to select DP PHY reset control, 0:HW control, 1: software reset */
+#define SW_DPPHY_RESET_MUX BIT(1)
+/* USB3 PHY soft reset */
+#define SW_USB3PHY_RESET   BIT(2)
+/* mux to select USB3 PHY reset control, 0:HW control, 1: software reset */
+#define SW_USB3PHY_RESET_MUX   BIT(3)
+
+/* QPHY_V3_DP_COM_PHY_MODE_CTRL register bits */
+#define USB3_MODE  BIT(0) /* enables USB3 mode */
+#define DP_MODEBIT(1) /* enables DP 
mode */
+
+
 #define PHY_INIT_COMPLETE_TIMEOUT  1000
 #define POWER_DOWN_DELAY_US_MIN10
 #define POWER_DOWN_DELAY_US_MAX11
@@ -122,6 +137,12 @@ enum qphy_reg_layout {
[QPHY_PCS_READY_STATUS] = 0x17c,
 };
 
+static const unsigned int qmp_v3_usb3phy_regs_layout[] = {
+   [QPHY_SW_RESET] = 0x00,
+   [QPHY_START_CTRL]   = 0x08,
+   [QPHY_PCS_READY_STATUS] = 0x174,
+};
+
 static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x1c),
QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10),
@@ -350,6 +371,112 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG_L(QPHY_START_CTRL, 0x3),
 };
 
+static const struct qmp_phy_init_tbl qmp_v3_usb3_serdes_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0x14),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x08),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_RESETSM_CNTRL2, 0x08),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x80),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START1_MODE0, 0xab),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START2_MODE0, 0xea),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START3_MODE0, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE0, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE0, 0xc9),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORECLK_DIV_MODE0, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP3_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x34),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0x15),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_CFG, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_BUF_ENABLE, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_EN_CENTER, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_PER1, 0x31),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_PER2, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_ADJ_PER1, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_ADJ_PER2, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_STEP_SIZE1, 0x85),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_STEP_SIZE2, 0x07),
+};
+
+static const struct qmp_phy_init_tbl qmp_v3_usb3_tx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_HIGHZ_DRVR_EN, 0x10),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RCV_DETECT_LVL_2, 0x12),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_LANE_MODE_1, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_RX, 0x09),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x06),
+};
+
+static const struct qmp_phy_init_tbl 

[PATCH v3 06/16] phy: qcom-qmp: Move SERDES/PCS START after PHY reset

[Manu Gautam]

Driver is currently performing PHY reset after starting
SERDES/PCS. As per hardware datasheet reset must be done
before starting PHY. Hence, update the sequence.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index aa27757..263cf50 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -882,12 +882,12 @@ static int qcom_qmp_phy_init(struct phy *phy)
if (cfg->has_pwrdn_delay)
usleep_range(cfg->pwrdn_delay_min, cfg->pwrdn_delay_max);
 
-   /* start SerDes and Phy-Coding-Sublayer */
-   qphy_setbits(pcs, cfg->regs[QPHY_START_CTRL], cfg->start_ctrl);
-
/* Pull PHY out of reset state */
qphy_clrbits(pcs, cfg->regs[QPHY_SW_RESET], SW_RESET);
 
+   /* start SerDes and Phy-Coding-Sublayer */
+   qphy_setbits(pcs, cfg->regs[QPHY_START_CTRL], cfg->start_ctrl);
+
status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
mask = cfg->mask_pcs_ready;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 09/16] phy: qcom-qusb2: Add support for QUSB2 V2 version

[Manu Gautam]

Use register layout to add additional registers present
on QUSB2 PHY V2 version for PHY initialization.
Other than new registers on V2, following two register's
offset and bit definitions are different: POWERDOWN control
and PLL_STATUS.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index c0c5358..bda1f4c 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -40,15 +40,34 @@
 /* QUSB2PHY_PLL_STATUS register bits */
 #define PLL_LOCKED BIT(5)
 
+/* QUSB2PHY_PLL_COMMON_STATUS_ONE register bits */
+#define CORE_READY_STATUS  BIT(0)
+
 /* QUSB2PHY_PORT_POWERDOWN register bits */
 #define CLAMP_N_EN BIT(5)
 #define FREEZIO_N  BIT(1)
 #define POWER_DOWN BIT(0)
 
+/* QUSB2PHY_PWR_CTRL1 register bits */
+#define PWR_CTRL1_VREF_SUPPLY_TRIM BIT(5)
+#define PWR_CTRL1_CLAMP_N_EN   BIT(1)
+
 #define QUSB2PHY_REFCLK_ENABLE BIT(0)
 
 #define PHY_CLK_SCHEME_SEL BIT(0)
 
+#defineQUSB2PHY_PLL_ANALOG_CONTROLS_TWO0x04
+#defineQUSB2PHY_PLL_CLOCK_INVERTERS0x18c
+#defineQUSB2PHY_PLL_CMODE  0x2c
+#defineQUSB2PHY_PLL_LOCK_DELAY 0x184
+#defineQUSB2PHY_PLL_DIGITAL_TIMERS_TWO 0xb4
+#defineQUSB2PHY_PLL_BIAS_CONTROL_1 0x194
+#defineQUSB2PHY_PLL_BIAS_CONTROL_2 0x198
+#defineQUSB2PHY_PWR_CTRL2  0x214
+#defineQUSB2PHY_IMP_CTRL1  0x220
+#defineQUSB2PHY_IMP_CTRL2  0x224
+#defineQUSB2PHY_CHG_CTRL2  0x23c
+
 struct qusb2_phy_init_tbl {
unsigned int offset;
unsigned int val;
@@ -113,6 +132,38 @@ enum qusb2phy_reg_layout {
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
 };
 
+static const unsigned int qusb2_v2_regs_layout[] = {
+   [QUSB2PHY_PLL_STATUS]   = 0x1a0,
+   [QUSB2PHY_PORT_TUNE1]   = 0x240,
+   [QUSB2PHY_PORT_TUNE2]   = 0x244,
+   [QUSB2PHY_PORT_TUNE3]   = 0x248,
+   [QUSB2PHY_PORT_TUNE4]   = 0x24c,
+   [QUSB2PHY_PORT_TUNE5]   = 0x250,
+   [QUSB2PHY_PORT_TEST2]   = 0x258,
+   [QUSB2PHY_PORT_POWERDOWN]   = 0x210,
+};
+
+static const struct qusb2_phy_init_tbl qusb2_v2_init_tbl[] = {
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_ANALOG_CONTROLS_TWO, 0x03),
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CLOCK_INVERTERS, 0x7c),
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CMODE, 0x80),
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_LOCK_DELAY, 0x0a),
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_DIGITAL_TIMERS_TWO, 0x19),
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_BIAS_CONTROL_1, 0x40),
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_BIAS_CONTROL_2, 0x20),
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_PWR_CTRL2, 0x21),
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_IMP_CTRL1, 0x0),
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_IMP_CTRL2, 0x58),
+
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0x30),
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0x29),
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE3, 0xca),
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0x04),
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE5, 0x03),
+
+   QUSB2_PHY_INIT_CFG(QUSB2PHY_CHG_CTRL2, 0x0),
+};
+
 struct qusb2_phy_cfg {
const struct qusb2_phy_init_tbl *tbl;
/* number of entries in the table */
@@ -139,6 +190,16 @@ struct qusb2_phy_cfg {
.mask_core_ready = PLL_LOCKED,
 };
 
+static const struct qusb2_phy_cfg qusb2_v2_phy_cfg = {
+   .tbl= qusb2_v2_init_tbl,
+   .tbl_num= ARRAY_SIZE(qusb2_v2_init_tbl),
+   .regs   = qusb2_v2_regs_layout,
+
+   .disable_ctrl   = (PWR_CTRL1_VREF_SUPPLY_TRIM | PWR_CTRL1_CLAMP_N_EN |
+  POWER_DOWN),
+   .mask_core_ready = CORE_READY_STATUS,
+};
+
 static const char * const qusb2_phy_vreg_names[] = {
"vdda-pll", "vdda-phy-dpdm",
 };
@@ -419,6 +480,9 @@ static int qusb2_phy_exit(struct phy *phy)
{
.compatible = "qcom,msm8996-qusb2-phy",
.data   = _phy_cfg,
+   }, {
+   .compatible = "qcom,qusb2-v2-phy",
+   .data   = _v2_phy_cfg,
},
{ },
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 15/16] phy: qcom-qusb2: Add support for runtime PM

[Manu Gautam]

Disable clocks and enable DP/DM wakeup interrupts when
suspending PHY.
Core driver should notify speed to PHY driver to enable
appropriate DP/DM wakeup interrupts polarity in suspend state.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 181 ++
 1 file changed, 181 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index bda1f4c..84cce0e 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -56,6 +56,18 @@
 
 #define PHY_CLK_SCHEME_SEL BIT(0)
 
+/* QUSB2PHY_INTR_CTRL register bits */
+#define DMSE_INTR_HIGH_SEL BIT(4)
+#define DPSE_INTR_HIGH_SEL BIT(3)
+#define CHG_DET_INTR_ENBIT(2)
+#define DMSE_INTR_EN   BIT(1)
+#define DPSE_INTR_EN   BIT(0)
+
+/* QUSB2PHY_PLL_CORE_INPUT_OVERRIDE register bits */
+#define CORE_PLL_EN_FROM_RESET BIT(4)
+#define CORE_RESET BIT(5)
+#define CORE_RESET_MUX BIT(6)
+
 #defineQUSB2PHY_PLL_ANALOG_CONTROLS_TWO0x04
 #defineQUSB2PHY_PLL_CLOCK_INVERTERS0x18c
 #defineQUSB2PHY_PLL_CMODE  0x2c
@@ -93,6 +105,7 @@ struct qusb2_phy_init_tbl {
 
 /* set of registers with offsets different per-PHY */
 enum qusb2phy_reg_layout {
+   QUSB2PHY_PLL_CORE_INPUT_OVERRIDE,
QUSB2PHY_PLL_STATUS,
QUSB2PHY_PORT_TUNE1,
QUSB2PHY_PORT_TUNE2,
@@ -112,8 +125,10 @@ enum qusb2phy_reg_layout {
[QUSB2PHY_PORT_TUNE3]   = 0x88,
[QUSB2PHY_PORT_TUNE4]   = 0x8c,
[QUSB2PHY_PORT_TUNE5]   = 0x90,
+   [QUSB2PHY_PORT_TEST1]   = 0xb8,
[QUSB2PHY_PORT_TEST2]   = 0x9c,
[QUSB2PHY_PORT_POWERDOWN]   = 0xb4,
+   [QUSB2PHY_INTR_CTRL]= 0xbc,
 };
 
 static const struct qusb2_phy_init_tbl msm8996_init_tbl[] = {
@@ -133,14 +148,17 @@ enum qusb2phy_reg_layout {
 };
 
 static const unsigned int qusb2_v2_regs_layout[] = {
+   [QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
[QUSB2PHY_PLL_STATUS]   = 0x1a0,
[QUSB2PHY_PORT_TUNE1]   = 0x240,
[QUSB2PHY_PORT_TUNE2]   = 0x244,
[QUSB2PHY_PORT_TUNE3]   = 0x248,
[QUSB2PHY_PORT_TUNE4]   = 0x24c,
[QUSB2PHY_PORT_TUNE5]   = 0x250,
+   [QUSB2PHY_PORT_TEST1]   = 0x254,
[QUSB2PHY_PORT_TEST2]   = 0x258,
[QUSB2PHY_PORT_POWERDOWN]   = 0x210,
+   [QUSB2PHY_INTR_CTRL]= 0x230,
 };
 
 static const struct qusb2_phy_init_tbl qusb2_v2_init_tbl[] = {
@@ -175,9 +193,13 @@ struct qusb2_phy_cfg {
const unsigned int *regs;
unsigned int mask_core_ready;
unsigned int disable_ctrl;
+   unsigned int autoresume_en;
 
/* true if PHY has PLL_TEST register to select clk_scheme */
bool has_pll_test;
+
+   /* true if PHY has PLL_CORE_INPUT_OVERRIDE register to reset PLL */
+   bool has_pll_override;
 };
 
 static const struct qusb2_phy_cfg msm8996_phy_cfg = {
@@ -188,6 +210,7 @@ struct qusb2_phy_cfg {
.has_pll_test   = true,
.disable_ctrl   = (CLAMP_N_EN | FREEZIO_N | POWER_DOWN),
.mask_core_ready = PLL_LOCKED,
+   .autoresume_en   = BIT(3),
 };
 
 static const struct qusb2_phy_cfg qusb2_v2_phy_cfg = {
@@ -198,6 +221,8 @@ struct qusb2_phy_cfg {
.disable_ctrl   = (PWR_CTRL1_VREF_SUPPLY_TRIM | PWR_CTRL1_CLAMP_N_EN |
   POWER_DOWN),
.mask_core_ready = CORE_READY_STATUS,
+   .has_pll_override = true,
+   .autoresume_en= BIT(0),
 };
 
 static const char * const qusb2_phy_vreg_names[] = {
@@ -223,6 +248,8 @@ struct qusb2_phy_cfg {
  *
  * @cfg: phy config data
  * @has_se_clk_scheme: indicate if PHY has single-ended ref clock scheme
+ * @phy_initialized: indicate if PHY has been initialized
+ * @speed: current PHY speed
  */
 struct qusb2_phy {
struct phy *phy;
@@ -239,6 +266,8 @@ struct qusb2_phy {
 
const struct qusb2_phy_cfg *cfg;
bool has_se_clk_scheme;
+   bool phy_initialized;
+   enum phy_speed speed;
 };
 
 static inline void qusb2_setbits(void __iomem *base, u32 offset, u32 val)
@@ -307,6 +336,137 @@ static void qusb2_phy_set_tune2_param(struct qusb2_phy 
*qphy)
qusb2_setbits(qphy->base, QUSB2PHY_PORT_TUNE2, val[0] << 0x4);
 }
 
+static int qusb2_phy_notify_speed(struct phy *phy, enum phy_speed speed)
+{
+   struct qusb2_phy *qphy = phy_get_drvdata(phy);
+
+   qphy->speed = speed;
+
+   return 0;
+}
+
+static enum phy_speed qusb2_phy_get_speed(struct phy *phy)
+{
+   struct qusb2_phy *qphy = phy_get_drvdata(phy);
+
+   return qphy->speed;
+}
+
+static int __maybe_unused qusb2_phy_runtime_suspend(struct device *dev)
+{
+   

[PATCH v3 08/16] dt-bindings: phy-qcom-qusb2: Update binding for QUSB2 V2 version

[Manu Gautam]

Update generic compatible string for QUSB2 V2 PHY. This will allow
all targets using QUSB2 V2 use same string.

Acked-by: Rob Herring 
Signed-off-by: Manu Gautam 
---
 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
index aa0fcb0..42c9742 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -4,7 +4,10 @@ Qualcomm QUSB2 phy controller
 QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
 
 Required properties:
- - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - compatible: compatible list, contains
+  "qcom,msm8996-qusb2-phy" for 14nm PHY on msm8996,
+  "qcom,qusb2-v2-phy" for QUSB2 V2 PHY.
+
  - reg: offset and length of the PHY register set.
  - #phy-cells: must be 0.
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 07/16] phy: qcom-qusb2: Add support for different register layouts

[Manu Gautam]

New version of QUSB2 PHY has some registers offset changed.
Add support to have register layout for a target and update
the same in phy_configuration.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 131 --
 1 file changed, 95 insertions(+), 36 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 4a5b2a1..c0c5358 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -37,17 +37,10 @@
 #define QUSB2PHY_PLL_AUTOPGM_CTL1  0x1c
 #define QUSB2PHY_PLL_PWR_CTRL  0x18
 
-#define QUSB2PHY_PLL_STATUS0x38
+/* QUSB2PHY_PLL_STATUS register bits */
 #define PLL_LOCKED BIT(5)
 
-#define QUSB2PHY_PORT_TUNE10x80
-#define QUSB2PHY_PORT_TUNE20x84
-#define QUSB2PHY_PORT_TUNE30x88
-#define QUSB2PHY_PORT_TUNE40x8c
-#define QUSB2PHY_PORT_TUNE50x90
-#define QUSB2PHY_PORT_TEST20x9c
-
-#define QUSB2PHY_PORT_POWERDOWN0xb4
+/* QUSB2PHY_PORT_POWERDOWN register bits */
 #define CLAMP_N_EN BIT(5)
 #define FREEZIO_N  BIT(1)
 #define POWER_DOWN BIT(0)
@@ -59,6 +52,11 @@
 struct qusb2_phy_init_tbl {
unsigned int offset;
unsigned int val;
+   /*
+* register part of layout ?
+* if yes, then offset gives index in the reg-layout
+*/
+   int in_layout;
 };
 
 #define QUSB2_PHY_INIT_CFG(o, v) \
@@ -67,15 +65,50 @@ struct qusb2_phy_init_tbl {
.val = v,   \
}
 
+#define QUSB2_PHY_INIT_CFG_L(o, v) \
+   {   \
+   .offset = o,\
+   .val = v,   \
+   .in_layout = 1, \
+   }
+
+/* set of registers with offsets different per-PHY */
+enum qusb2phy_reg_layout {
+   QUSB2PHY_PLL_STATUS,
+   QUSB2PHY_PORT_TUNE1,
+   QUSB2PHY_PORT_TUNE2,
+   QUSB2PHY_PORT_TUNE3,
+   QUSB2PHY_PORT_TUNE4,
+   QUSB2PHY_PORT_TUNE5,
+   QUSB2PHY_PORT_TEST1,
+   QUSB2PHY_PORT_TEST2,
+   QUSB2PHY_PORT_POWERDOWN,
+   QUSB2PHY_INTR_CTRL,
+};
+
+static const unsigned int msm8996_regs_layout[] = {
+   [QUSB2PHY_PLL_STATUS]   = 0x38,
+   [QUSB2PHY_PORT_TUNE1]   = 0x80,
+   [QUSB2PHY_PORT_TUNE2]   = 0x84,
+   [QUSB2PHY_PORT_TUNE3]   = 0x88,
+   [QUSB2PHY_PORT_TUNE4]   = 0x8c,
+   [QUSB2PHY_PORT_TUNE5]   = 0x90,
+   [QUSB2PHY_PORT_TEST2]   = 0x9c,
+   [QUSB2PHY_PORT_POWERDOWN]   = 0xb4,
+};
+
 static const struct qusb2_phy_init_tbl msm8996_init_tbl[] = {
-   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE1, 0xf8),
-   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE2, 0xb3),
-   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE3, 0x83),
-   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE4, 0xc0),
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0xf8),
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0xb3),
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE3, 0x83),
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0xc0),
+
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL2, 0x21),
-   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TEST2, 0x14),
+
+   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TEST2, 0x14),
+
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_AUTOPGM_CTL1, 0x9f),
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
 };
@@ -86,11 +119,24 @@ struct qusb2_phy_cfg {
unsigned int tbl_num;
/* offset to PHY_CLK_SCHEME register in TCSR map */
unsigned int clk_scheme_offset;
+
+   /* array of registers with different offsets */
+   const unsigned int *regs;
+   unsigned int mask_core_ready;
+   unsigned int disable_ctrl;
+
+   /* true if PHY has PLL_TEST register to select clk_scheme */
+   bool has_pll_test;
 };
 
 static const struct qusb2_phy_cfg msm8996_phy_cfg = {
-   .tbl = msm8996_init_tbl,
-   .tbl_num = ARRAY_SIZE(msm8996_init_tbl),
+   .tbl= msm8996_init_tbl,
+   .tbl_num= ARRAY_SIZE(msm8996_init_tbl),
+   .regs   = msm8996_regs_layout,
+
+   .has_pll_test   = true,
+   .disable_ctrl   = (CLAMP_N_EN | FREEZIO_N | POWER_DOWN),
+   .mask_core_ready = PLL_LOCKED,
 };
 
 static const char * const qusb2_phy_vreg_names[] = {
@@ -160,12 +206,17 @@ static inline void qusb2_clrbits(void __iomem *base, u32 
offset, u32 val)
 
 static inline
 void qcom_qusb2_phy_configure(void __iomem *base,
+ const unsigned int *regs,
  const struct qusb2_phy_init_tbl tbl[], int num)
 {
int i;
 
-   for (i = 0; i < num; i++)
-   writel(tbl[i].val, base + tbl[i].offset);
+   for (i = 0; i < num; i++) {
+

[PATCH v3 12/16] dt-bindings: phy-qcom-qmp: Update bindings for QMP V3 USB PHY

[Manu Gautam]

Update compatible string and clock names for QMP version V3
USB PHY.

Acked-by: Rob Herring 
Signed-off-by: Manu Gautam 
---
 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index b6a9f2b..dcf1b8f 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -8,7 +8,8 @@ Required properties:
  - compatible: compatible list, contains:
   "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074
   "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
-  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996,
+  "qcom,qmp-v3-usb3-phy" for USB3 QMP V3 phy.
 
  - reg: offset and length of register set for PHY's common serdes block.
 
@@ -25,10 +26,13 @@ Required properties:
  - clock-names: "cfg_ahb" for phy config clock,
"aux" for phy aux clock,
"ref" for 19.2 MHz ref clk,
+   "com_aux" for phy common block aux clock,
For "qcom,msm8996-qmp-pcie-phy" must contain:
"aux", "cfg_ahb", "ref".
For "qcom,msm8996-qmp-usb3-phy" must contain:
"aux", "cfg_ahb", "ref".
+   For "qcom,qmp-v3-usb3-phy" must contain:
+   "aux", "cfg_ahb", "ref", "com_aux".
 
  - resets: a list of phandles and reset controller specifier pairs,
   one for each entry in reset-names.
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

RE: [f2fs-dev] [PATCH RESEND] f2fs: fix concurrent problem for updating free bitmap

[LiFan]

> -Original Message-
> From: Chao Yu [mailto:yuch...@huawei.com]
> Sent: Monday, November 20, 2017 11:00 AM
> To: LiFan; 'Chao Yu'; 'Jaegeuk Kim'
> Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH RESEND] f2fs: fix concurrent problem for 
> updating free bitmap
> 
> Hi,
> 
> > @@ -1870,6 +1895,11 @@ static bool add_free_nid(struct f2fs_sb_info
> > *sbi, nid_t nid, bool build)
> 
> Need to use radix_tree_preload(GFP_NOFS | __GFP_NOFAIL)， otherwise, for 
> out-of-memory case, we may skip bitmap updating.
> 
> Thanks,
> 
> 
Yes, about this, in previous version, if we fail to read the radix, we will 
clear the free bitmap in scan_nat_page,
But fail to read the radix tree indicates that we know nothing about current 
nid, so we probably shouldn't 
change the bitmap, otherwise the status we change into may not be right, so I 
use current patch to correct
that.
But __GFP_NOFAIL may still be useful for __flush_nat_entry_set case where we 
update the free bitmap
Anyway.

> On 2017/11/14 15:28, LiFan wrote:
> > alloc_nid_failed and scan_nat_page can be called at the same time, and
> > we haven't protected add_free_nid and update_free_nid_bitmap with the
> > same nid_list_lock. That could lead to
> >
> > Thread AThread B
> > - __build_free_nids
> >  - scan_nat_page
> >   - add_free_nid
> > - alloc_nid_failed
> >  - update_free_nid_bitmap
> >   - update_free_nid_bitmap
> >
> > scan_nat_page will clear the free bitmap since the nid is
> > PREALLOC_NID, but alloc_nid_failed needs to set the free bitmap. This
> > results in free nid with free bitmap cleared.
> > This patch update the bitmap under the same nid_list_lock in add_free_nid.
> >
> > Signed-off-by: Fan li 
> > ---
> >  fs/f2fs/node.c | 82
> > ++
> >  1 file changed, 42 insertions(+), 40 deletions(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index b965a53..0a217d2
> > 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1811,8 +1811,33 @@ static void __move_free_nid(struct f2fs_sb_info 
> > *sbi, struct free_nid *i,
> > }
> >  }
> >
> > +static void update_free_nid_bitmap(struct f2fs_sb_info *sbi, nid_t nid,
> > +   bool set, bool build)
> > +{
> > +   struct f2fs_nm_info *nm_i = NM_I(sbi);
> > +   unsigned int nat_ofs = NAT_BLOCK_OFFSET(nid);
> > +   unsigned int nid_ofs = nid - START_NID(nid);
> > +
> > +   if (!test_bit_le(nat_ofs, nm_i->nat_block_bitmap))
> > +   return;
> > +
> > +   if (set) {
> > +   if (test_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]))
> > +   return;
> > +   __set_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
> > +   nm_i->free_nid_count[nat_ofs]++;
> > +   } else {
> > +   if (!test_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]))
> > +   return;
> > +   __clear_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
> > +   if (!build)
> > +   nm_i->free_nid_count[nat_ofs]--;
> > +   }
> > +}
> > +
> >  /* return if the nid is recognized as free */ -static bool
> > add_free_nid(struct f2fs_sb_info *sbi, nid_t nid, bool build)
> > +static bool add_free_nid(struct f2fs_sb_info *sbi,
> > +   nid_t nid, bool build, bool update)
> >  {
> > struct f2fs_nm_info *nm_i = NM_I(sbi);
> > struct free_nid *i, *e;
> > @@ -1870,6 +1895,11 @@ static bool add_free_nid(struct f2fs_sb_info *sbi, 
> > nid_t nid, bool build)
> > ret = true;
> > err = __insert_free_nid(sbi, i, FREE_NID);
> >  err_out:
> > +   if (update) {
> > +   update_free_nid_bitmap(sbi, nid, ret, build);
> > +   if (!build)
> > +   nm_i->available_nids++;
> > +   }
> > spin_unlock(_i->nid_list_lock);
> > radix_tree_preload_end();
> >  err:
> > @@ -1896,30 +1926,6 @@ static void remove_free_nid(struct f2fs_sb_info 
> > *sbi, nid_t nid)
> > kmem_cache_free(free_nid_slab, i);
> >  }
> >
> > -static void update_free_nid_bitmap(struct f2fs_sb_info *sbi, nid_t nid,
> > -   bool set, bool build)
> > -{
> > -   struct f2fs_nm_info *nm_i = NM_I(sbi);
> > -   unsigned int nat_ofs = NAT_BLOCK_OFFSET(nid);
> > -   unsigned int nid_ofs = nid - START_NID(nid);
> > -
> > -   if (!test_bit_le(nat_ofs, nm_i->nat_block_bitmap))
> > -   return;
> > -
> > -   if (set) {
> > -   if (test_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]))
> > -   return;
> > -   __set_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
> > -   nm_i->free_nid_count[nat_ofs]++;
> > -   } else {
> > -   if (!test_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]))
> > -   return;
> > -   

Re: [PATCH 2/7] kbuild: Add P= command line flag to run checkpatch

[Knut Omang]

On Mon, 2017-11-20 at 17:00 -0700, Jim Davis wrote:
> On Mon, Nov 20, 2017 at 2:22 PM, Luc Van Oostenryck
>  wrote:
> 
> > Should it be possible to somehow keep the distinction between
> > the flags coming from KBUILD_CFLAGS and the pure CHECKFLAGS?
> 
> Well, the practical problem seems to be that $(CHECK) is called in
> scripts/Makefile.build with both $(CHECKFLAGS) and $(c_flags) as
> arguments, regardless of what $(CHECK) is.  That can be hacked around
> with something inelegant like
> 
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index bb831d49bcfd..102194f9afb9 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -98,14 +98,20 @@ __build: $(if $(KBUILD_BUILTIN),$(builtin-target)
> $(lib-target) $(extra-y)) \
>  $(subdir-ym) $(always)
> @:
> 
> -# Linus' kernel sanity checking tool
> +# Linus' kernel sanity checking tool, or $CHECK program of choice
> +ifneq ($(KBUILD_CHECKSRC),)
> +  add_to_checkflags =
> +  ifeq ($(CHECK),sparse)
> +add_to_checkflags = $(c_flags)
> +  endif
> +endif
>  ifneq ($(KBUILD_CHECKSRC),0)
>ifeq ($(KBUILD_CHECKSRC),2)
>  quiet_cmd_force_checksrc = CHECK   $<
> -  cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< ;
> +  cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(add_to_checkflags) $<
> ;
>else
>quiet_cmd_checksrc = CHECK   $<
> -cmd_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< ;
> +cmd_checksrc = $(CHECK) $(CHECKFLAGS) $(add_to_checkflags) $<
> ;
>endif
>  endif
> 
> and then if I run scripts/checkpatch.pl as $CHECK and pass --quiet
> --file as before it works -- until checkpatch returns with a non-zero
> exit code, which causes the Makefile to bail at that point.

yes, in an earlier version, I added a --no-errors flag to checkpatch to handle
that, but based on feedback this version promotes make -k instead. It seems
however that that only holds to the next linker step. It is useful to be able to
select whether checkpatch should cause make to stop or not. While fixing issues,
failure is a better strategy while to assess the state or generate a report, a
return 0 behavior is better.

> So maybe a wrapper script, with an exit 0 fixup to keep on keeping on
> in case of checkpatch warnings or errors, would be better after all.

I can prepare a v2 based on the wrapper script I have already.

In that version, all added functionality was implemented in the wrapper
(including the configuration file parsing) 

Would you like to keep the checkpatch changes in some form, or would you rather
see everything happening in the wrapper?

A 3rd possibility that strikes me is that maybe what's needed is a general
checker runner that can also take care of running other checks, running multiple
checks, and maybe also handling temporary or decided suppression of sparse
errors in a similar fashion as I implemented for checkpatch errors. But maybe
that can be left to a later change set..

Thanks,
Knut

Re: [PATCHv3] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[Laurent Pinchart]

Hi Hans,

Thank you for the patch.

On Tuesday, 21 November 2017 10:17:43 EET Hans Verkuil wrote:
> If the device tree for a board did not specify a cec clock, then
> adv7511_cec_init would return an error, which would cause adv7511_probe()
> to fail and thus there is no HDMI output.
> 
> There is no need to have adv7511_probe() fail if the CEC initialization
> fails, so just change adv7511_cec_init() to a void function. In addition,
> adv7511_cec_init() should just return silently if the cec clock isn't
> found and show a message for any other errors.
> 
> An otherwise correct cleanup patch from Dan Carpenter turned this broken
> failure handling into a kernel Oops, so bisection points to commit
> 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL") rather
> than 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support").
> 
> Based on earlier patches from Arnd and John.
> 
> Reported-by: Naresh Kamboju 
> Cc: Xinliang Liu 
> Cc: Dan Carpenter 
> Cc: Sean Paul 
> Cc: Archit Taneja 
> Cc: John Stultz 
> Link: https://bugs.linaro.org/show_bug.cgi?id=3345
> Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
> Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
> Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
> Signed-off-by: Hans Verkuil 
> Tested-by: Hans Verkuil 

Reviewed-by: Laurent Pinchart 

> ---
> This rework of Arnd and John's patches goes a bit further and just silently
> exits if there is no cec clock defined in the dts. I'm sure that's the
> reason why the kirin board failed on this. BTW: if the kirin board DOES
> support cec, then it would be nice if it can be hooked up in the dts!
> 
> Tested with my Dragonboard and Renesas Koelsch board. Also tested what
> happens when probing is deferred due to missing cec clock.
> 
> John, can you test this again?
> 
> Changes since v2:
> - reverted adv7511_cec_init back to an int function for EPROBE_DEFER
> - incorporated Laurent's comments
> - moved the adv7511_cec_init call up in the probe function to prevent
>   having to remove the bridge in case of an error.
> 
> Change since my previous RFC PATCH:
> 
> - added static inline adv7511_cec_init to avoid #ifdef in the probe function
> as suggested by John Stultz.
> 
> Regards,
> 
>   Hans
> ---
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index b4efcbabf7f7..d034b2cb5eee
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -372,9 +372,18 @@ struct adv7511 {
>  };
> 
>  #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
> -  unsigned int offset);
> +int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511);
>  void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
> +#else
> +static inline int adv7511_cec_init(struct device *dev, struct adv7511
> *adv7511) +{
> + unsigned int offset = adv7511->type == ADV7533 ?
> + ADV7533_REG_CEC_OFFSET : 0;
> +
> + regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
> +  ADV7511_CEC_CTRL_POWER_DOWN);
> + return 0;
> +}
>  #endif
> 
>  #ifdef CONFIG_DRM_I2C_ADV7533
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c index
> b33d730e4d73..a20a45c0b353 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> @@ -300,18 +300,21 @@ static int adv7511_cec_parse_dt(struct device *dev,
> struct adv7511 *adv7511) return 0;
>  }
> 
> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
> -  unsigned int offset)
> +int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
>  {
> + unsigned int offset = adv7511->type == ADV7533 ?
> + ADV7533_REG_CEC_OFFSET : 0;
>   int ret = adv7511_cec_parse_dt(dev, adv7511);
> 
>   if (ret)
> - return ret;
> + goto err_cec_parse_dt;
> 
>   adv7511->cec_adap = cec_allocate_adapter(_cec_adap_ops,
>   adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
> - if (IS_ERR(adv7511->cec_adap))
> - return PTR_ERR(adv7511->cec_adap);
> + if (IS_ERR(adv7511->cec_adap)) {
> + ret = PTR_ERR(adv7511->cec_adap);
> + goto err_cec_alloc;
> + }
> 
>   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset, 0);
>   /* cec soft reset */
> @@ -329,9 +332,18 @@ int adv7511_cec_init(struct device *dev, struct adv7511
> *adv7511, ((adv7511->cec_clk_freq / 75) - 1) << 2);
> 
>

Re: [PATCH] dt-bindings: trivial-devices: Remove fsl,mc13892

[Jonathan Neuschäfer]

On Mon, Nov 20, 2017 at 03:10:45PM -0600, Rob Herring wrote:
> On Sat, Nov 18, 2017 at 03:22:32AM +0100, Jonathan Neuschäfer wrote:
> > This device's bindings are not trivial: Additional properties are
> > documented in in Documentation/devicetree/bindings/mfd/mc13xxx.txt.
> > 
> > Signed-off-by: Jonathan Neuschäfer 
> > ---
> >  Documentation/devicetree/bindings/trivial-devices.txt | 1 -
> >  1 file changed, 1 deletion(-)
> 
> Applied.

Thanks!


signature.asc
Description: PGP signature

[PATCH v2] ACPI / battery: add quirk for Asus GL502VSK and UX305LA

[Kai-Heng Feng]

From: Kai Heng Feng 

On Asus GL502VSK and UX305LA, ACPI incorrectly reports discharging when
battery is full and AC is plugged.

However rate_now is correct under this circumstance, hence we can use
"rate_now == 0" as a predicate to report battery full status correctly.

BugLink: https://bugs.launchpad.net/bugs/1482390
Signed-off-by: Kai-Heng Feng 
---
v2:
Convert the special case for the quirk to a sub-case for
ACPI_BATTERY_STATE_DISCHARGING.

 drivers/acpi/battery.c | 33 ++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 13e7b56e33ae..428066014897 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -70,6 +70,7 @@ static async_cookie_t async_cookie;
 static bool battery_driver_registered;
 static int battery_bix_broken_package;
 static int battery_notification_delay_ms;
+static int battery_full_discharging;
 static unsigned int cache_time = 1000;
 module_param(cache_time, uint, 0644);
 MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
@@ -214,9 +215,12 @@ static int acpi_battery_get_property(struct power_supply 
*psy,
return -ENODEV;
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
-   if (battery->state & ACPI_BATTERY_STATE_DISCHARGING)
-   val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
-   else if (battery->state & ACPI_BATTERY_STATE_CHARGING)
+   if (battery->state & ACPI_BATTERY_STATE_DISCHARGING) {
+   if (battery_full_discharging && battery->rate_now == 0)
+   val->intval = POWER_SUPPLY_STATUS_FULL;
+   else
+   val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+   } else if (battery->state & ACPI_BATTERY_STATE_CHARGING)
val->intval = POWER_SUPPLY_STATUS_CHARGING;
else if (acpi_battery_is_charged(battery))
val->intval = POWER_SUPPLY_STATUS_FULL;
@@ -1166,6 +1170,13 @@ battery_notification_delay_quirk(const struct 
dmi_system_id *d)
return 0;
 }
 
+static int __init
+battery_full_discharging_quirk(const struct dmi_system_id *d)
+{
+   battery_full_discharging = 1;
+   return 0;
+}
+
 static const struct dmi_system_id bat_dmi_table[] __initconst = {
{
.callback = battery_bix_broken_package_quirk,
@@ -1183,6 +1194,22 @@ static const struct dmi_system_id bat_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Aspire V5-573G"),
},
},
+   {
+   .callback = battery_full_discharging_quirk,
+   .ident = "ASUS GL502VSK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "GL502VSK"),
+   },
+   },
+   {
+   .callback = battery_full_discharging_quirk,
+   .ident = "ASUS UX305LA",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "UX305LA"),
+   },
+   },
{},
 };
 
-- 
2.14.1

Re: [PATCH 2/4] x86, selftests, mpx: fix up weird arrays

[Ingo Molnar]

* Dave Hansen  wrote:

> 
> The MPX hardware data structurse are defined in a weird way: they define
> their size in bytes and then union that with the type with which we want
> to access them.
> 
> Yes, this is weird, but it does work.  But, new GCC's complain that we
> are accessing the array out of bounds.  Just make it a zero-sized array
> so gcc will stop complaining.  There was not really a bug here.

Note, I've added your missing Signed-off-by line.

Thanks,

Ingo

Re: [PATCH 3/4] x86, selftests, protection_keys: rename si_pkey

[Ingo Molnar]

* Dave Hansen  wrote:

> 
> si_pkey is now #defined to be the name of the new siginfo field that
> protection keys uses.  Rename it not to conflict.
> 
> ---

Ditto: added your Signed-off-by which I presume was intended.

Thanks,

Ingo

Re: [PATCH v15 5/5] PCI: Remove PCI pool macro functions

[Romain Perier]

Whoops, my bad. Sorry

Thanks,
Romain

2017-11-20 21:34 GMT+01:00 Bjorn Helgaas :
> On Mon, Nov 20, 2017 at 08:32:47PM +0100, Romain Perier wrote:
>> From: Romain Perier 
>>
>> Now that all the drivers use dma pool API, we can remove the macro
>> functions for PCI pool.
>>
>> Signed-off-by: Romain Perier 
>> Reviewed-by: Peter Senna Tschudin 
>
> I already acked this once on Oct 24.  Please keep that ack and include
> it in any future postings so I don't have to deal with this again.
>
> Acked-by: Bjorn Helgaas 
>
>> ---
>>  include/linux/pci.h | 9 -
>>  1 file changed, 9 deletions(-)
>>
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 96c94980d1ff..d03b4a20033d 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -1324,15 +1324,6 @@ int pci_set_vga_state(struct pci_dev *pdev, bool 
>> decode,
>>  #include 
>>  #include 
>>
>> -#define  pci_pool dma_pool
>> -#define pci_pool_create(name, pdev, size, align, allocation) \
>> - dma_pool_create(name, >dev, size, align, allocation)
>> -#define  pci_pool_destroy(pool) dma_pool_destroy(pool)
>> -#define  pci_pool_alloc(pool, flags, handle) dma_pool_alloc(pool, 
>> flags, handle)
>> -#define  pci_pool_zalloc(pool, flags, handle) \
>> - dma_pool_zalloc(pool, flags, handle)
>> -#define  pci_pool_free(pool, vaddr, addr) dma_pool_free(pool, vaddr, 
>> addr)
>> -
>>  struct msix_entry {
>>   u32 vector; /* kernel uses to write allocated vector */
>>   u16 entry;  /* driver uses to specify entry, OS writes */
>> --
>> 2.14.1
>>

Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

[Pavel Tikhomirov]

JFYI these patch is in Virtuozzo7 kernel from September, and we have no 
issues found with it until now by out testing, and initial problem does 
not reproduce for 2.5 months.

[tip:x86/urgent] x86/pkeys/selftests: Fix protection keys write() warning

[tip-bot for Dave Hansen]

Commit-ID:  7b659ee3e1fe0e8eb39730afb903c64e25490ec4
Gitweb: https://git.kernel.org/tip/7b659ee3e1fe0e8eb39730afb903c64e25490ec4
Author: Dave Hansen 
AuthorDate: Fri, 10 Nov 2017 16:12:32 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 21 Nov 2017 09:34:52 +0100

x86/pkeys/selftests: Fix protection keys write() warning

write() is marked as having a must-check return value.  Check it and
abort if we fail to write an error message from a signal handler.

Signed-off-by: Dave Hansen 
Acked-by: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/2017001232.94813...@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
---
 tools/testing/selftests/x86/pkey-helpers.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/x86/pkey-helpers.h 
b/tools/testing/selftests/x86/pkey-helpers.h
index 3818f25..b3cb767 100644
--- a/tools/testing/selftests/x86/pkey-helpers.h
+++ b/tools/testing/selftests/x86/pkey-helpers.h
@@ -30,6 +30,7 @@ static inline void sigsafe_printf(const char *format, ...)
if (!dprint_in_signal) {
vprintf(format, ap);
} else {
+   int ret;
int len = vsnprintf(dprint_in_signal_buffer,
DPRINT_IN_SIGNAL_BUF_SIZE,
format, ap);
@@ -39,7 +40,9 @@ static inline void sigsafe_printf(const char *format, ...)
 */
if (len > DPRINT_IN_SIGNAL_BUF_SIZE)
len = DPRINT_IN_SIGNAL_BUF_SIZE;
-   write(1, dprint_in_signal_buffer, len);
+   ret = write(1, dprint_in_signal_buffer, len);
+   if (ret < 0)
+   abort();
}
va_end(ap);
 }

[tip:x86/urgent] x86/pkeys/selftests: Rename 'si_pkey' to 'siginfo_pkey'

[tip-bot for Dave Hansen]

Commit-ID:  91c49c2deb96ffc3c461eaae70219d89224076b7
Gitweb: https://git.kernel.org/tip/91c49c2deb96ffc3c461eaae70219d89224076b7
Author: Dave Hansen 
AuthorDate: Fri, 10 Nov 2017 16:12:31 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 21 Nov 2017 09:34:52 +0100

x86/pkeys/selftests: Rename 'si_pkey' to 'siginfo_pkey'

'si_pkey' is now #defined to be the name of the new siginfo field that
protection keys uses.  Rename it not to conflict.

Signed-off-by: Dave Hansen 
Acked-by: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/2017001231.dffc8...@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
---
 tools/testing/selftests/x86/protection_keys.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/x86/protection_keys.c 
b/tools/testing/selftests/x86/protection_keys.c
index 7a1cc0e..bc1b073 100644
--- a/tools/testing/selftests/x86/protection_keys.c
+++ b/tools/testing/selftests/x86/protection_keys.c
@@ -250,7 +250,7 @@ void signal_handler(int signum, siginfo_t *si, void 
*vucontext)
unsigned long ip;
char *fpregs;
u32 *pkru_ptr;
-   u64 si_pkey;
+   u64 siginfo_pkey;
u32 *si_pkey_ptr;
int pkru_offset;
fpregset_t fpregset;
@@ -292,9 +292,9 @@ void signal_handler(int signum, siginfo_t *si, void 
*vucontext)
si_pkey_ptr = (u32 *)(((u8 *)si) + si_pkey_offset);
dprintf1("si_pkey_ptr: %p\n", si_pkey_ptr);
dump_mem(si_pkey_ptr - 8, 24);
-   si_pkey = *si_pkey_ptr;
-   pkey_assert(si_pkey < NR_PKEYS);
-   last_si_pkey = si_pkey;
+   siginfo_pkey = *si_pkey_ptr;
+   pkey_assert(siginfo_pkey < NR_PKEYS);
+   last_si_pkey = siginfo_pkey;
 
if ((si->si_code == SEGV_MAPERR) ||
(si->si_code == SEGV_ACCERR) ||
@@ -306,7 +306,7 @@ void signal_handler(int signum, siginfo_t *si, void 
*vucontext)
dprintf1("signal pkru from xsave: %08x\n", *pkru_ptr);
/* need __rdpkru() version so we do not do shadow_pkru checking */
dprintf1("signal pkru from  pkru: %08x\n", __rdpkru());
-   dprintf1("si_pkey from siginfo: %jx\n", si_pkey);
+   dprintf1("pkey from siginfo: %jx\n", siginfo_pkey);
*(u64 *)pkru_ptr = 0x;
dprintf1("WARNING: set PRKU=0 to allow faulting instruction to 
continue\n");
pkru_faults++;

[tip:x86/urgent] x86/mpx/selftests: Fix up weird arrays

[tip-bot for Dave Hansen]

Commit-ID:  a6400120d042397675fcf694060779d21e9e762d
Gitweb: https://git.kernel.org/tip/a6400120d042397675fcf694060779d21e9e762d
Author: Dave Hansen 
AuthorDate: Fri, 10 Nov 2017 16:12:29 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 21 Nov 2017 09:34:52 +0100

x86/mpx/selftests: Fix up weird arrays

The MPX hardware data structurse are defined in a weird way: they define
their size in bytes and then union that with the type with which we want
to access them.

Yes, this is weird, but it does work.  But, new GCC's complain that we
are accessing the array out of bounds.  Just make it a zero-sized array
so gcc will stop complaining.  There was not really a bug here.

Signed-off-by: Dave Hansen 
Acked-by: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/2017001229.58a79...@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
---
 tools/testing/selftests/x86/mpx-hw.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/x86/mpx-hw.h 
b/tools/testing/selftests/x86/mpx-hw.h
index 3f00939..d1b61ab 100644
--- a/tools/testing/selftests/x86/mpx-hw.h
+++ b/tools/testing/selftests/x86/mpx-hw.h
@@ -52,14 +52,14 @@
 struct mpx_bd_entry {
union {
char x[MPX_BOUNDS_DIR_ENTRY_SIZE_BYTES];
-   void *contents[1];
+   void *contents[0];
};
 } __attribute__((packed));
 
 struct mpx_bt_entry {
union {
char x[MPX_BOUNDS_TABLE_ENTRY_SIZE_BYTES];
-   unsigned long contents[1];
+   unsigned long contents[0];
};
 } __attribute__((packed));
 

Re: [PATCH] clk: fix a panic error caused by accessing NULL pointer

[Chunyan Zhang]

On 21 November 2017 at 03:12, Stephen Boyd  wrote:
> On 11/20, Chunyan Zhang wrote:
>> From: Cai Li 
>>
>> In some cases the clock parent would be set NULL when doing re-parent,
>> it will cause a NULL pointer accessing if clk_set trace event is enabled,
>> since the trace event function would not check the input parameter.
>>
>> Signed-off-by: Cai Li 
>> Signed-off-by: Chunyan Zhang 
>
> Fixes: tag?
>
>> ---
>>  drivers/clk/clk.c | 9 -
>>  1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index c8d83ac..64efaf0 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -1242,13 +1242,12 @@ static int __clk_set_parent(struct clk_core *core, 
>> struct clk_core *parent,
>>
>>   old_parent = __clk_set_parent_before(core, parent);
>>
>> - trace_clk_set_parent(core, parent);
>> -
>>   /* change clock input source */
>> - if (parent && core->ops->set_parent)
>> + if (parent && core->ops->set_parent) {
>> + trace_clk_set_parent(core, parent);
>>   ret = core->ops->set_parent(core->hw, p_index);
>> -
>> - trace_clk_set_parent_complete(core, parent);
>> + trace_clk_set_parent_complete(core, parent);
>> + }
>
> Is the problem that parent may be NULL and the tracepoint
> dereferences it?

Yes, I think that probably is uncommon usage though, it revealed that
the tracepoint could be stronger :)

> Perhaps we need to update the tracepoint code
> instead so that we always see that the tracepoint is called even
> if we don't actually touch the hardware. Something like the patch
> below instead.

Ok, we will cook a new patch according to your comments.

Thanks,
Chunyan

>
> ---8<
> diff --git a/include/trace/events/clk.h b/include/trace/events/clk.h
> index 758607226bfd..5a85ea2090c4 100644
> --- a/include/trace/events/clk.h
> +++ b/include/trace/events/clk.h
> @@ -139,7 +139,7 @@ DECLARE_EVENT_CLASS(clk_parent,
>
> TP_fast_assign(
> __assign_str(name, core->name);
> -   __assign_str(pname, parent->name);
> +   __assign_str(pname, parent ? parent->name : NULL);
> ),
>
> TP_printk("%s %s", __get_str(name), __get_str(pname))
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: KASAN help, please (Re: [PATCH 00/16] Entry stuff, in decent shape now)

[Dmitry Vyukov]

On Mon, Nov 20, 2017 at 10:44 PM, Andy Lutomirski  wrote:
> On Mon, Nov 20, 2017 at 9:07 AM, Andy Lutomirski  wrote:
>> This sets up stack switching, including for SYSCALL.  I think it's
>> in decent shape.
>>
>> Known issues:
>>  - KASAN is likely to be busted.  This could be fixed either by teaching
>>KASAN that cpu_entry_area contains valid stacks (I have no clue how
>>to go about doing this) or by rigging up the IST entry code to switch
>>RSP to point to the direct-mapped copy of the stacks before calling
>>into non-KASAN-excluded C code.
>>
>
> I tried to fix the KASAN issue, and I'm doing something wrong.  I'm
> building this tree:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry_stack=8319677bd04a1ab291ca71fe1da7aa023306e4a9
>
> for 64 bits with KASAN on.  The relevant commit is:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry_stack=a4bdb48c3469708b6b51e5ab90d27bf0c859000c
>
> If I run tools/testing/selftests/single_step_syscall_32, then the
> kernel goes into lala land and infinite loops.  The root cause seems
> to we're hitting do_debug with RSP pointing into the fixmap,
> specifically in the cpu_entry_area's exception stack, with a value of
> roughly 0xff1bd108.  The KASAN instrumentation in do_debug is
> then getting a page fault.  I think my KASAN setup code should be
> populating the KASAN data there and, indeed, gdb seems to be able to
> access the faulting address.  So I'm confused.


Hi,

I don't have any great insights.

You have stack instrumentation turned on, right? And the fault happens
on stack instrumentation?
Stack instrumentation is turned on with gcc7+ I think. And as the
result compiler adds redzones on stack and poisons/unpoisons shadow
for them in function prologue/epilogue.

The fact that KASAN instrumentation faults, but gdb can access it
sounds strange. KASAN instrumentation is no magic, it just does not a
normal memory load. Please check exact faulting address. KASAN can do
accesses with large offset from RSP.

Does the fault happen before/after kasan_early_init? Before that there
is a different bootstrap shadow mapped by kasan_map_early_shadow.

Does the fault happen on read access or write access? Stack
instrumentation does write into shadow, but some parts of shadow are
mapped with a single read-only page. Can gdb write to that address?

Is it possible that the stack has overflowed? I see that we increase
EXCEPTION_STACK_ORDER by order 1 under KASAN (from 4k page to 8k
pages), but it may be not enough. Normal stacks are increased from 16k
to 32k.

Last stupid question: why is it -1 here:
FIX_CPU_ENTRY_AREA_BOTTOM = FIX_CPU_ENTRY_AREA_TOP +
(CPU_ENTRY_AREA_PAGES * NR_CPUS) - 1,
?
Say CPU_ENTRY_AREA_PAGES=1 (we need only 1 page) and NR_CPUS=1, then
the increment will be 0, which looks wrong for any case (must be at
least 1, right?).

[PATCH v3 04/16] phy: qcom-qusb2: Power-on PHY before initialization

[Manu Gautam]

PHY must be powered on before turning ON clocks and
attempting to initialize it. Driver is exposing
separate init and power_on routines for this.
Apparently USB dwc3 core driver performs power-on
after init. Also, poweron and init for QUSB2 PHY
need to be executed together always, hence remove
poweron callback from phy_ops and explicitly perform
this from init, similar changes needed for poweroff.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 47 +++
 1 file changed, 15 insertions(+), 32 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 6c57524..4a5b2a1 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -195,54 +195,31 @@ static void qusb2_phy_set_tune2_param(struct qusb2_phy 
*qphy)
qusb2_setbits(qphy->base, QUSB2PHY_PORT_TUNE2, val[0] << 0x4);
 }
 
-static int qusb2_phy_poweron(struct phy *phy)
+static int qusb2_phy_init(struct phy *phy)
 {
struct qusb2_phy *qphy = phy_get_drvdata(phy);
-   int num = ARRAY_SIZE(qphy->vregs);
+   unsigned int val;
+   unsigned int clk_scheme;
int ret;
 
-   dev_vdbg(>dev, "%s(): Powering-on QUSB2 phy\n", __func__);
+   dev_vdbg(>dev, "%s(): Initializing QUSB2 phy\n", __func__);
 
/* turn on regulator supplies */
-   ret = regulator_bulk_enable(num, qphy->vregs);
+   ret = regulator_bulk_enable(ARRAY_SIZE(qphy->vregs), qphy->vregs);
if (ret)
return ret;
 
ret = clk_prepare_enable(qphy->iface_clk);
if (ret) {
dev_err(>dev, "failed to enable iface_clk, %d\n", ret);
-   regulator_bulk_disable(num, qphy->vregs);
-   return ret;
+   goto poweroff_phy;
}
 
-   return 0;
-}
-
-static int qusb2_phy_poweroff(struct phy *phy)
-{
-   struct qusb2_phy *qphy = phy_get_drvdata(phy);
-
-   clk_disable_unprepare(qphy->iface_clk);
-
-   regulator_bulk_disable(ARRAY_SIZE(qphy->vregs), qphy->vregs);
-
-   return 0;
-}
-
-static int qusb2_phy_init(struct phy *phy)
-{
-   struct qusb2_phy *qphy = phy_get_drvdata(phy);
-   unsigned int val;
-   unsigned int clk_scheme;
-   int ret;
-
-   dev_vdbg(>dev, "%s(): Initializing QUSB2 phy\n", __func__);
-
/* enable ahb interface clock to program phy */
ret = clk_prepare_enable(qphy->cfg_ahb_clk);
if (ret) {
dev_err(>dev, "failed to enable cfg ahb clock, %d\n", ret);
-   return ret;
+   goto disable_iface_clk;
}
 
/* Perform phy reset */
@@ -344,6 +321,11 @@ static int qusb2_phy_init(struct phy *phy)
reset_control_assert(qphy->phy_reset);
 disable_ahb_clk:
clk_disable_unprepare(qphy->cfg_ahb_clk);
+disable_iface_clk:
+   clk_disable_unprepare(qphy->iface_clk);
+poweroff_phy:
+   regulator_bulk_disable(ARRAY_SIZE(qphy->vregs), qphy->vregs);
+
return ret;
 }
 
@@ -361,6 +343,9 @@ static int qusb2_phy_exit(struct phy *phy)
reset_control_assert(qphy->phy_reset);
 
clk_disable_unprepare(qphy->cfg_ahb_clk);
+   clk_disable_unprepare(qphy->iface_clk);
+
+   regulator_bulk_disable(ARRAY_SIZE(qphy->vregs), qphy->vregs);
 
return 0;
 }
@@ -368,8 +353,6 @@ static int qusb2_phy_exit(struct phy *phy)
 static const struct phy_ops qusb2_phy_gen_ops = {
.init   = qusb2_phy_init,
.exit   = qusb2_phy_exit,
-   .power_on   = qusb2_phy_poweron,
-   .power_off  = qusb2_phy_poweroff,
.owner  = THIS_MODULE,
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 10/16] phy: qcom-qmp: Move register offsets to header file

[Manu Gautam]

New revision (v3) of QMP PHY uses different offsets
for almost all of the registers. Hence, move these
definitions to header file so that updated offsets
can be added for QMP v3.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 119 +--
 drivers/phy/qualcomm/phy-qcom-qmp.h | 137 
 2 files changed, 138 insertions(+), 118 deletions(-)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp.h

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 263cf50..15a734f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -31,124 +31,7 @@
 
 #include 
 
-/* QMP PHY QSERDES COM registers */
-#define QSERDES_COM_BG_TIMER   0x00c
-#define QSERDES_COM_SSC_EN_CENTER  0x010
-#define QSERDES_COM_SSC_ADJ_PER1   0x014
-#define QSERDES_COM_SSC_ADJ_PER2   0x018
-#define QSERDES_COM_SSC_PER1   0x01c
-#define QSERDES_COM_SSC_PER2   0x020
-#define QSERDES_COM_SSC_STEP_SIZE1 0x024
-#define QSERDES_COM_SSC_STEP_SIZE2 0x028
-#define QSERDES_COM_BIAS_EN_CLKBUFLR_EN0x034
-#define QSERDES_COM_CLK_ENABLE10x038
-#define QSERDES_COM_SYS_CLK_CTRL   0x03c
-#define QSERDES_COM_SYSCLK_BUF_ENABLE  0x040
-#define QSERDES_COM_PLL_IVCO   0x048
-#define QSERDES_COM_LOCK_CMP1_MODE00x04c
-#define QSERDES_COM_LOCK_CMP2_MODE00x050
-#define QSERDES_COM_LOCK_CMP3_MODE00x054
-#define QSERDES_COM_LOCK_CMP1_MODE10x058
-#define QSERDES_COM_LOCK_CMP2_MODE10x05c
-#define QSERDES_COM_LOCK_CMP3_MODE10x060
-#define QSERDES_COM_BG_TRIM0x070
-#define QSERDES_COM_CLK_EP_DIV 0x074
-#define QSERDES_COM_CP_CTRL_MODE0  0x078
-#define QSERDES_COM_CP_CTRL_MODE1  0x07c
-#define QSERDES_COM_PLL_RCTRL_MODE00x084
-#define QSERDES_COM_PLL_RCTRL_MODE10x088
-#define QSERDES_COM_PLL_CCTRL_MODE00x090
-#define QSERDES_COM_PLL_CCTRL_MODE10x094
-#define QSERDES_COM_BIAS_EN_CTRL_BY_PSM0x0a8
-#define QSERDES_COM_SYSCLK_EN_SEL  0x0ac
-#define QSERDES_COM_RESETSM_CNTRL  0x0b4
-#define QSERDES_COM_RESTRIM_CTRL   0x0bc
-#define QSERDES_COM_RESCODE_DIV_NUM0x0c4
-#define QSERDES_COM_LOCK_CMP_EN0x0c8
-#define QSERDES_COM_LOCK_CMP_CFG   0x0cc
-#define QSERDES_COM_DEC_START_MODE00x0d0
-#define QSERDES_COM_DEC_START_MODE10x0d4
-#define QSERDES_COM_DIV_FRAC_START1_MODE0  0x0dc
-#define QSERDES_COM_DIV_FRAC_START2_MODE0  0x0e0
-#define QSERDES_COM_DIV_FRAC_START3_MODE0  0x0e4
-#define QSERDES_COM_DIV_FRAC_START1_MODE1  0x0e8
-#define QSERDES_COM_DIV_FRAC_START2_MODE1  0x0ec
-#define QSERDES_COM_DIV_FRAC_START3_MODE1  0x0f0
-#define QSERDES_COM_INTEGLOOP_GAIN0_MODE0  0x108
-#define QSERDES_COM_INTEGLOOP_GAIN1_MODE0  0x10c
-#define QSERDES_COM_INTEGLOOP_GAIN0_MODE1  0x110
-#define QSERDES_COM_INTEGLOOP_GAIN1_MODE1  0x114
-#define QSERDES_COM_VCO_TUNE_CTRL  0x124
-#define QSERDES_COM_VCO_TUNE_MAP   0x128
-#define QSERDES_COM_VCO_TUNE1_MODE00x12c
-#define QSERDES_COM_VCO_TUNE2_MODE00x130
-#define QSERDES_COM_VCO_TUNE1_MODE10x134
-#define QSERDES_COM_VCO_TUNE2_MODE10x138
-#define QSERDES_COM_VCO_TUNE_TIMER10x144
-#define QSERDES_COM_VCO_TUNE_TIMER20x148
-#define QSERDES_COM_BG_CTRL0x170
-#define QSERDES_COM_CLK_SELECT 0x174
-#define QSERDES_COM_HSCLK_SEL  0x178
-#define QSERDES_COM_CORECLK_DIV0x184
-#define QSERDES_COM_CORE_CLK_EN0x18c
-#define QSERDES_COM_C_READY_STATUS 0x190
-#define QSERDES_COM_CMN_CONFIG 0x194
-#define QSERDES_COM_SVS_MODE_CLK_SEL   0x19c
-#define QSERDES_COM_DEBUG_BUS0 0x1a0
-#define QSERDES_COM_DEBUG_BUS1 0x1a4
-#define QSERDES_COM_DEBUG_BUS2 0x1a8
-#define QSERDES_COM_DEBUG_BUS3 0x1ac
-#define QSERDES_COM_DEBUG_BUS_SEL  0x1b0
-#define 

[PATCH v3 03/16] phy: qcom-qmp: Power-on PHY before initialization

[Manu Gautam]

PHY must be powered on before turning ON clocks and
attempting to initialize it. Driver is exposing
separate init and power_on routines for this.
Apparently USB dwc3 core driver performs power-on after
init. Also, poweron and init for QMP PHY need to be
executed together always, hence remove poweron callback
from phy_ops and explicitly perform this from com_init,
similar changes needed for poweroff. On similar lines move
clk_enable from init to com_init which can be called once
for multi lane PHYs.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 61 +
 1 file changed, 21 insertions(+), 40 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 90794dd..2f427e3 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -720,33 +720,6 @@ static void qcom_qmp_phy_configure(void __iomem *base,
}
 }
 
-static int qcom_qmp_phy_poweron(struct phy *phy)
-{
-   struct qmp_phy *qphy = phy_get_drvdata(phy);
-   struct qcom_qmp *qmp = qphy->qmp;
-   int num = qmp->cfg->num_vregs;
-   int ret;
-
-   dev_vdbg(>dev, "Powering on QMP phy\n");
-
-   /* turn on regulator supplies */
-   ret = regulator_bulk_enable(num, qmp->vregs);
-   if (ret)
-   dev_err(qmp->dev, "failed to enable regulators, err=%d\n", ret);
-
-   return ret;
-}
-
-static int qcom_qmp_phy_poweroff(struct phy *phy)
-{
-   struct qmp_phy *qphy = phy_get_drvdata(phy);
-   struct qcom_qmp *qmp = qphy->qmp;
-
-   regulator_bulk_disable(qmp->cfg->num_vregs, qmp->vregs);
-
-   return 0;
-}
-
 static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
 {
const struct qmp_phy_cfg *cfg = qmp->cfg;
@@ -759,6 +732,19 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
return 0;
}
 
+   /* turn on regulator supplies */
+   ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
+   if (ret) {
+   mutex_unlock(>phy_mutex);
+   return ret;
+   }
+
+   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
+   if (ret) {
+   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
+   goto err_clk_enable;
+   }
+
for (i = 0; i < cfg->num_resets; i++) {
ret = reset_control_deassert(qmp->resets[i]);
if (ret) {
@@ -803,6 +789,9 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
 err_rst:
while (--i >= 0)
reset_control_assert(qmp->resets[i]);
+   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
+err_clk_enable:
+   regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
mutex_unlock(>phy_mutex);
 
return ret;
@@ -832,6 +821,10 @@ static int qcom_qmp_phy_com_exit(struct qcom_qmp *qmp)
while (--i >= 0)
reset_control_assert(qmp->resets[i]);
 
+   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
+
+   regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
+
mutex_unlock(>phy_mutex);
 
return 0;
@@ -852,15 +845,9 @@ static int qcom_qmp_phy_init(struct phy *phy)
 
dev_vdbg(qmp->dev, "Initializing QMP phy\n");
 
-   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
-   if (ret) {
-   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
-   return ret;
-   }
-
ret = qcom_qmp_phy_com_init(qmp);
if (ret)
-   goto err_com_init;
+   return ret;
 
if (cfg->has_lane_rst) {
ret = reset_control_deassert(qphy->lane_rst);
@@ -915,8 +902,6 @@ static int qcom_qmp_phy_init(struct phy *phy)
reset_control_assert(qphy->lane_rst);
 err_lane_rst:
qcom_qmp_phy_com_exit(qmp);
-err_com_init:
-   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
 
return ret;
 }
@@ -943,8 +928,6 @@ static int qcom_qmp_phy_exit(struct phy *phy)
 
qcom_qmp_phy_com_exit(qmp);
 
-   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
-
return 0;
 }
 
@@ -1057,8 +1040,6 @@ static int phy_pipe_clk_register(struct qcom_qmp *qmp, 
struct device_node *np)
 static const struct phy_ops qcom_qmp_phy_gen_ops = {
.init   = qcom_qmp_phy_init,
.exit   = qcom_qmp_phy_exit,
-   .power_on   = qcom_qmp_phy_poweron,
-   .power_off  = qcom_qmp_phy_poweroff,
.owner  = THIS_MODULE,
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 05/16] phy: qcom-qmp: Fix PHY block reset sequence

[Manu Gautam]

PHY block or asynchronous reset requires signal
to be asserted before de-asserting. Driver is only
de-asserting signal which is already low, hence
reset operation is a no-op. Fix this by asserting
signal first. Also, resetting requires PHY clocks
to be turned ON only after reset is finished. Fix
that as well.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 2f427e3..aa27757 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -739,13 +739,16 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
return ret;
}
 
-   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
-   if (ret) {
-   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
-   goto err_clk_enable;
+   for (i = 0; i < cfg->num_resets; i++) {
+   ret = reset_control_assert(qmp->resets[i]);
+   if (ret) {
+   dev_err(qmp->dev, "%s reset assert failed\n",
+   cfg->reset_list[i]);
+   goto err_rst_assert;
+   }
}
 
-   for (i = 0; i < cfg->num_resets; i++) {
+   for (i = cfg->num_resets - 1; i >= 0; i--) {
ret = reset_control_deassert(qmp->resets[i]);
if (ret) {
dev_err(qmp->dev, "%s reset deassert failed\n",
@@ -754,6 +757,12 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
}
}
 
+   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
+   if (ret) {
+   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
+   goto err_rst;
+   }
+
if (cfg->has_phy_com_ctrl)
qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
 SW_PWRDN);
@@ -778,7 +787,7 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
if (ret) {
dev_err(qmp->dev,
"phy common block init timed-out\n");
-   goto err_rst;
+   goto err_com_init;
}
}
 
@@ -786,11 +795,12 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
 
return 0;
 
+err_com_init:
+   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
 err_rst:
-   while (--i >= 0)
+   while (++i < cfg->num_resets)
reset_control_assert(qmp->resets[i]);
-   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
-err_clk_enable:
+err_rst_assert:
regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
mutex_unlock(>phy_mutex);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 16/16] phy: qcom-qmp: Add support for runtime PM

[Manu Gautam]

Disable clocks and enable PHY autonomous mode to detect
wakeup events when PHY is suspended.
Core driver should notify speed to PHY driver to enable
LFPS and/or RX_DET interrupts.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 185 +++-
 drivers/phy/qualcomm/phy-qcom-qmp.h |   3 +
 2 files changed, 187 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index efd187b..9553741 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -61,6 +61,19 @@
 #define USB3_MODE  BIT(0) /* enables USB3 mode */
 #define DP_MODEBIT(1) /* enables DP 
mode */
 
+/* QPHY_PCS_AUTONOMOUS_MODE_CTRL register bits */
+#define ARCVR_DTCT_EN  BIT(0)
+#define ALFPS_DTCT_EN  BIT(1)
+#define ARCVR_DTCT_EVENT_SEL   BIT(4)
+
+/* QPHY_PCS_LFPS_RXTERM_IRQ_CLEAR register bits */
+#define IRQ_CLEAR  BIT(0)
+
+/* QPHY_PCS_LFPS_RXTERM_IRQ_STATUS register bits */
+#define RCVR_DETECTBIT(0)
+
+/* QPHY_V3_PCS_MISC_CLAMP_ENABLE register bits */
+#define CLAMP_EN   BIT(0) /* enables i/o clamp_n */
 
 #define PHY_INIT_COMPLETE_TIMEOUT  1000
 #define POWER_DOWN_DELAY_US_MIN10
@@ -108,6 +121,9 @@ enum qphy_reg_layout {
QPHY_SW_RESET,
QPHY_START_CTRL,
QPHY_PCS_READY_STATUS,
+   QPHY_PCS_AUTONOMOUS_MODE_CTRL,
+   QPHY_PCS_LFPS_RXTERM_IRQ_CLEAR,
+   QPHY_PCS_LFPS_RXTERM_IRQ_STATUS,
 };
 
 static const unsigned int pciephy_regs_layout[] = {
@@ -135,12 +151,18 @@ enum qphy_reg_layout {
[QPHY_SW_RESET] = 0x00,
[QPHY_START_CTRL]   = 0x08,
[QPHY_PCS_READY_STATUS] = 0x17c,
+   [QPHY_PCS_AUTONOMOUS_MODE_CTRL] = 0x0d4,
+   [QPHY_PCS_LFPS_RXTERM_IRQ_CLEAR]  = 0x0d8,
+   [QPHY_PCS_LFPS_RXTERM_IRQ_STATUS] = 0x178,
 };
 
 static const unsigned int qmp_v3_usb3phy_regs_layout[] = {
[QPHY_SW_RESET] = 0x00,
[QPHY_START_CTRL]   = 0x08,
[QPHY_PCS_READY_STATUS] = 0x174,
+   [QPHY_PCS_AUTONOMOUS_MODE_CTRL] = 0x0d8,
+   [QPHY_PCS_LFPS_RXTERM_IRQ_CLEAR]  = 0x0dc,
+   [QPHY_PCS_LFPS_RXTERM_IRQ_STATUS] = 0x170,
 };
 
 static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
@@ -536,6 +558,7 @@ struct qmp_phy_cfg {
  * @tx: iomapped memory space for lane's tx
  * @rx: iomapped memory space for lane's rx
  * @pcs: iomapped memory space for lane's pcs
+ * @pcs_misc: iomapped memory space for lane's pcs_misc
  * @pipe_clk: pipe lock
  * @index: lane index
  * @qmp: QMP phy to which this lane belongs
@@ -546,6 +569,7 @@ struct qmp_phy {
void __iomem *tx;
void __iomem *rx;
void __iomem *pcs;
+   void __iomem *pcs_misc;
struct clk *pipe_clk;
unsigned int index;
struct qcom_qmp *qmp;
@@ -567,6 +591,8 @@ struct qmp_phy {
  * @phys: array of per-lane phy descriptors
  * @phy_mutex: mutex lock for PHY common block initialization
  * @init_count: phy common block initialization count
+ * @phy_initialized: indicate if PHY has been initialized
+ * @speed: current PHY speed
  */
 struct qcom_qmp {
struct device *dev;
@@ -582,6 +608,8 @@ struct qcom_qmp {
 
struct mutex phy_mutex;
int init_count;
+   bool phy_initialized;
+   enum phy_speed speed;
 };
 
 static inline void qphy_setbits(void __iomem *base, u32 offset, u32 val)
@@ -988,6 +1016,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
dev_err(qmp->dev, "pipe_clk enable failed, err=%d\n", ret);
goto err_pcs_ready;
}
+   qmp->phy_initialized = true;
 
return 0;
 
@@ -1022,6 +1051,135 @@ static int qcom_qmp_phy_exit(struct phy *phy)
 
qcom_qmp_phy_com_exit(qmp);
 
+   qmp->phy_initialized = false;
+
+   return 0;
+}
+
+static int qcom_qmp_phy_notify_speed(struct phy *phy, enum phy_speed speed)
+{
+   struct qmp_phy *qphy = phy_get_drvdata(phy);
+   struct qcom_qmp *qmp = qphy->qmp;
+
+   qmp->speed = speed;
+
+   return 0;
+}
+
+static enum phy_speed qcom_qmp_phy_get_speed(struct phy *phy)
+{
+   struct qmp_phy *qphy = phy_get_drvdata(phy);
+   struct qcom_qmp *qmp = qphy->qmp;
+
+   return qmp->speed;
+}
+
+static void qcom_qmp_phy_enable_autonomous_mode(struct qmp_phy *qphy)
+{
+   struct qcom_qmp *qmp = qphy->qmp;
+   const struct qmp_phy_cfg *cfg = qmp->cfg;
+   void __iomem *pcs = qphy->pcs;
+   void __iomem *pcs_misc = qphy->pcs_misc;
+   u32 intr_mask;
+
+   if (qmp->speed == PHY_SPEED_USB_SS)
+   intr_mask = ARCVR_DTCT_EN | ALFPS_DTCT_EN;
+   else
+   intr_mask = ARCVR_DTCT_EN | 

[PATCH v3 14/16] phy: Add notify_speed callback

[Manu Gautam]

QCOM USB PHYs can monitor resume/remote-wakeup event in
suspended state. However PHY driver must know current
operational speed of PHY in order to set correct polarity of
wakeup events for detection. E.g. QUSB2 PHY monitors DP/DM
signals depending on speed is LS or FS/HS to detect resume.
Similarly QMP USB3 PHY in SS mode should monitor RX
terminations attach/detach and LFPS events depending on
SSPHY is active or not.

Signed-off-by: Manu Gautam 
---
 drivers/phy/phy-core.c  | 30 ++
 include/linux/phy/phy.h | 26 ++
 2 files changed, 56 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b4964b0..03df2be 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -387,6 +387,36 @@ int phy_calibrate(struct phy *phy)
 }
 EXPORT_SYMBOL_GPL(phy_calibrate);
 
+int phy_notify_speed(struct phy *phy, enum phy_speed speed)
+{
+   int ret;
+
+   if (!phy || !phy->ops->notify_speed)
+   return 0;
+
+   mutex_lock(>mutex);
+   ret = phy->ops->notify_speed(phy, speed);
+   mutex_unlock(>mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(phy_notify_speed);
+
+enum phy_speed phy_get_speed(struct phy *phy)
+{
+   enum phy_speed ret;
+
+   if (!phy || !phy->ops->get_speed)
+   return PHY_SPEED_UNKNOWN;
+
+   mutex_lock(>mutex);
+   ret = phy->ops->get_speed(phy);
+   mutex_unlock(>mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(phy_get_speed);
+
 /**
  * _of_phy_get() - lookup and obtain a reference to a phy by phandle
  * @np: device_node for which to get the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 4f8423a..9efd3cd 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -33,6 +33,14 @@ enum phy_mode {
PHY_MODE_UFS_HS_B,
 };
 
+enum phy_speed {
+   PHY_SPEED_UNKNOWN,
+   PHY_SPEED_USB_LS,
+   PHY_SPEED_USB_FS,
+   PHY_SPEED_USB_HS,
+   PHY_SPEED_USB_SS,
+};
+
 /**
  * struct phy_ops - set of function pointers for performing phy operations
  * @init: operation to be performed for initializing phy
@@ -42,6 +50,8 @@ enum phy_mode {
  * @set_mode: set the mode of the phy
  * @reset: resetting the phy
  * @calibrate: calibrate the phy
+ * @notify_speed: notify phy driver of current speed of PHY
+ * @get_speed: get current operational speed of PHY
  * @owner: the module owner containing the ops
  */
 struct phy_ops {
@@ -52,6 +62,8 @@ struct phy_ops {
int (*set_mode)(struct phy *phy, enum phy_mode mode);
int (*reset)(struct phy *phy);
int (*calibrate)(struct phy *phy);
+   int (*notify_speed)(struct phy *phy, enum phy_speed speed);
+   enum phy_speed (*get_speed)(struct phy *phy);
struct module *owner;
 };
 
@@ -146,6 +158,8 @@ static inline void *phy_get_drvdata(struct phy *phy)
 int phy_set_mode(struct phy *phy, enum phy_mode mode);
 int phy_reset(struct phy *phy);
 int phy_calibrate(struct phy *phy);
+int phy_notify_speed(struct phy *phy, enum phy_speed speed);
+enum phy_speed phy_get_speed(struct phy *phy);
 static inline int phy_get_bus_width(struct phy *phy)
 {
return phy->attrs.bus_width;
@@ -274,6 +288,18 @@ static inline int phy_calibrate(struct phy *phy)
return -ENOSYS;
 }
 
+static inline int phy_notify_speed(struct phy *phy, enum phy_speed speed)
+{
+   if (!phy)
+   return 0;
+   return -EINVAL;
+}
+
+static inline enum phy_speed phy_get_speed(struct phy *phy)
+{
+   return PHY_SPEED_UNKNOWN;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
return -ENOSYS;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 11/16] phy: qcom-qmp: Add register offsets for QMP V3 PHY

[Manu Gautam]

Registers offsets for QMP V3 PHY are changed from
previous versions (1/2), update same in header file.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.h | 149 
 1 file changed, 149 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h 
b/drivers/phy/qualcomm/phy-qcom-qmp.h
index d930ca7..f7d4c2a 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
@@ -134,4 +134,153 @@
 #define QPHY_L1SS_WAKEUP_DLY_TIME_AUXCLK_LSB   0x1DC
 #define QPHY_L1SS_WAKEUP_DLY_TIME_AUXCLK_MSB   0x1E0
 
+/* Only for QMP V3 PHY - DP COM registers */
+#define QPHY_V3_DP_COM_PHY_MODE_CTRL   0x00
+#define QPHY_V3_DP_COM_SW_RESET0x04
+#define QPHY_V3_DP_COM_POWER_DOWN_CTRL 0x08
+#define QPHY_V3_DP_COM_SWI_CTRL0x0c
+#define QPHY_V3_DP_COM_TYPEC_CTRL  0x10
+#define QPHY_V3_DP_COM_TYPEC_PWRDN_CTRL0x14
+#define QPHY_V3_DP_COM_RESET_OVRD_CTRL 0x1c
+
+/* Only for QMP V3 PHY - QSERDES COM registers */
+#define QSERDES_V3_COM_BG_TIMER0x00c
+#define QSERDES_V3_COM_SSC_EN_CENTER   0x010
+#define QSERDES_V3_COM_SSC_ADJ_PER10x014
+#define QSERDES_V3_COM_SSC_ADJ_PER20x018
+#define QSERDES_V3_COM_SSC_PER10x01c
+#define QSERDES_V3_COM_SSC_PER20x020
+#define QSERDES_V3_COM_SSC_STEP_SIZE1  0x024
+#define QSERDES_V3_COM_SSC_STEP_SIZE2  0x028
+#define QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN 0x034
+#define QSERDES_V3_COM_CLK_ENABLE1 0x038
+#define QSERDES_V3_COM_SYS_CLK_CTRL0x03c
+#define QSERDES_V3_COM_SYSCLK_BUF_ENABLE   0x040
+#define QSERDES_V3_COM_PLL_IVCO0x048
+#define QSERDES_V3_COM_LOCK_CMP1_MODE0 0x098
+#define QSERDES_V3_COM_LOCK_CMP2_MODE0 0x09c
+#define QSERDES_V3_COM_LOCK_CMP3_MODE0 0x0a0
+#define QSERDES_V3_COM_LOCK_CMP1_MODE1 0x0a4
+#define QSERDES_V3_COM_LOCK_CMP2_MODE1 0x0a8
+#define QSERDES_V3_COM_LOCK_CMP3_MODE1 0x0ac
+#define QSERDES_V3_COM_CLK_EP_DIV  0x05c
+#define QSERDES_V3_COM_CP_CTRL_MODE0   0x060
+#define QSERDES_V3_COM_CP_CTRL_MODE1   0x064
+#define QSERDES_V3_COM_PLL_RCTRL_MODE0 0x068
+#define QSERDES_V3_COM_PLL_RCTRL_MODE1 0x06c
+#define QSERDES_V3_COM_PLL_CCTRL_MODE0 0x070
+#define QSERDES_V3_COM_PLL_CCTRL_MODE1 0x074
+#define QSERDES_V3_COM_SYSCLK_EN_SEL   0x080
+#define QSERDES_V3_COM_RESETSM_CNTRL   0x088
+#define QSERDES_V3_COM_RESETSM_CNTRL2  0x08c
+#define QSERDES_V3_COM_LOCK_CMP_EN 0x090
+#define QSERDES_V3_COM_LOCK_CMP_CFG0x094
+#define QSERDES_V3_COM_DEC_START_MODE0 0x0b0
+#define QSERDES_V3_COM_DEC_START_MODE1 0x0b4
+#define QSERDES_V3_COM_DIV_FRAC_START1_MODE0   0x0b8
+#define QSERDES_V3_COM_DIV_FRAC_START2_MODE0   0x0bc
+#define QSERDES_V3_COM_DIV_FRAC_START3_MODE0   0x0c0
+#define QSERDES_V3_COM_DIV_FRAC_START1_MODE1   0x0c4
+#define QSERDES_V3_COM_DIV_FRAC_START2_MODE1   0x0c8
+#define QSERDES_V3_COM_DIV_FRAC_START3_MODE1   0x0cc
+#define QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0   0x0d8
+#define QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0   0x0dc
+#define QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE1   0x0e0
+#define QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE1   0x0e4
+#define QSERDES_V3_COM_VCO_TUNE_CTRL   0x0ec
+#define QSERDES_V3_COM_VCO_TUNE_MAP0x0f0
+#define QSERDES_V3_COM_VCO_TUNE1_MODE0 0x0f4
+#define QSERDES_V3_COM_VCO_TUNE2_MODE0 0x0f8
+#define QSERDES_V3_COM_VCO_TUNE1_MODE1 0x0fc
+#define QSERDES_V3_COM_VCO_TUNE2_MODE1 0x100
+#define QSERDES_V3_COM_VCO_TUNE_TIMER1 0x11c
+#define QSERDES_V3_COM_VCO_TUNE_TIMER2 0x120
+#define QSERDES_V3_COM_CLK_SELECT  0x138
+#define QSERDES_V3_COM_HSCLK_SEL   0x13c
+#define QSERDES_V3_COM_CORECLK_DIV_MODE0   0x148
+#define QSERDES_V3_COM_CORECLK_DIV_MODE1   0x14c
+#define QSERDES_V3_COM_CORE_CLK_EN 0x154
+#define QSERDES_V3_COM_C_READY_STATUS  0x158
+#define QSERDES_V3_COM_CMN_CONFIG  0x15c
+#define QSERDES_V3_COM_SVS_MODE_CLK_SEL0x164
+#define QSERDES_V3_COM_DEBUG_BUS0  0x168
+#define QSERDES_V3_COM_DEBUG_BUS1  0x16c

Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails

[Javier Martinez Canillas]

On 11/21/2017 10:07 AM, Javier Martinez Canillas wrote:
> On 11/21/2017 12:15 AM, Jarkko Sakkinen wrote:
> 
>> matters less than breaking the sandbox.
>>
> 
> Yes, sorry for that. It wasn't clear to me that there was a sandbox and my
> lack of familiarity with the code was the reason why I posted as a RFC in
> the first place.
> 
> Do you agree with Jason's suggestion to send a synthesized TPM command in
> the that the command isn't supported?
> 

Sorry, this should had been: send a synthesized TPM response in the case that
the command isn't supported.

Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [PATCH] scsi_error: ensure EH wakes up on error to prevent host getting stuck

[Pavel Tikhomirov]

On 11/20/2017 10:11 PM, Stuart Hayes wrote:

When a command is added to the host's error handler command queue, there is a 
chance that the error handler will not be woken up.  This can happen when one CPU 
is running scsi_eh_scmd_add() at the same time as another CPU is running 
scsi_device_unbusy() for a different command on the same host.  Each function 
changes one value, and then looks at the value of a variable that the other 
function has just changed, but if they both see stale data, neither will actually 
wake up the error handle >
In scsi_eh_scmd_add, host_failed is incremented, then scsi_eh_wakeup() is 
called, which sees that host_busy is still 2, so it doesn't actually wake up 
the handler.  Meanwhile, in scsi_device_unbusy(), host_busy is decremented, and 
then it sees that host_failed is 0, so it doesn't even call scsi_eh_wakeup().


If in scsi_eh_scmd_add() we call scsi_eh_wakeup() it is done under 
spinlock, so we have implied memory barrier here. All stores which we've 
done before we had released the lock will be seen by any other thread in 
same critical section if the thread took spinlock after us. So later 
scsi_device_unbusy() in it's scsi_eh_wakeup() also sees host_failed==1.


Actually the problem is that in scsi_device_unbusy() the check below:

if (unlikely(scsi_host_in_recovery(shost) &&
 (shost->host_failed || shost->host_eh_scheduled))

is not under same spinlock, so that host_failed can be actually be 0 at 
these point and we never get to scsi_eh_wakeup, which my patch "scsi/eh: 
fix hang adding ehandler wakeups after decrementing host_busy" also 
fixes by putting these check under proper lock and thus the implied 
barrier is added and we don't need actual barrier here.


Please see "LOCK ACQUISITION FUNCTIONS" 
Documentation/memory-barriers.txt for further information about implied 
memory barriers.




Signed-off-by: Stuart Hyaes 

---
diff -pur linux-4.14/drivers/scsi/scsi_error.c 
linux-4.14-stu/drivers/scsi/scsi_error.c
--- linux-4.14/drivers/scsi/scsi_error.c2017-11-12 12:46:13.0 
-0600
+++ linux-4.14-stu/drivers/scsi/scsi_error.c2017-11-17 14:22:19.230867923 
-0600
@@ -243,6 +243,10 @@ void scsi_eh_scmd_add(struct scsi_cmnd *
scsi_eh_reset(scmd);
list_add_tail(>eh_entry, >eh_cmd_q);
shost->host_failed++;
+   /*
+* See scsi_device_unbusy() for explanation of smp_mb().
+*/
+   smp_mb();
scsi_eh_wakeup(shost);
spin_unlock_irqrestore(shost->host_lock, flags);
  }
diff -pur linux-4.14/drivers/scsi/scsi_lib.c 
linux-4.14-stu/drivers/scsi/scsi_lib.c
--- linux-4.14/drivers/scsi/scsi_lib.c  2017-11-12 12:46:13.0 -0600
+++ linux-4.14-stu/drivers/scsi/scsi_lib.c  2017-11-17 14:22:15.814867833 
-0600
@@ -325,6 +325,15 @@ void scsi_device_unbusy(struct scsi_devi
unsigned long flags;
  
  	atomic_dec(>host_busy);

+   
+   /* This function changes host_busy and looks at host_failed, while
+* scsi_eh_scmd_add() updates host_failed and looks at host_busy (in
+* scsi_eh_wakeup())... if these happen simultaneously without the smp
+* memory barrier, each can see the old value, such that neither will
+* wake up the error handler, which can cause the host controller to
+* be hung forever.
+*/
+   smp_mb();
if (starget->can_queue > 0)
atomic_dec(>target_busy);
  



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



--
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.

Re: [PATCH] [man-pages] adjtimex.2: document clock_adjtime

[Arnd Bergmann]

On Tue, Nov 21, 2017 at 4:05 AM, Richard Cochran
 wrote:
> On Mon, Nov 20, 2017 at 11:53:02PM +0100, Arnd Bergmann wrote:
>>  .B EINVAL
>> +The
>> +.I clk_id
>> +specified is not supported on this system.
>
> We return EINVAL when the clockid is not valid.  That can mean two
> things.  Either the SYS-V style hard coded positive clockid is out of
> range, or the dynamic negative clockid does not refer to a valid
> instance of a clock object.
>
> Dynamic clocks might also return ENODEV in case a hot-plugable device
> (like USB) has disappeared after its character device was opened.

I copied that line from clock_gettime() man page. I suppose we want to
fix change this in both pages, right? Any suggestions for a good way to
express your explanation in the man page? I suppose we don't want to
go into details of the implementation there but still capture the possible
corner cases.

   Arnd

Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

[Pavel Tikhomirov]

My patch should also fix your issue too, please see explanation in reply 
to your patch. Do your testing show that it doesn't?


Thanks, Pavel.

On 11/21/2017 09:10 AM, Stuart Hayes wrote:

Pavel,

It turns out that the error handler on our systems was not getting woken up for 
a different reason... I submitted a patch earlier today that fixes the issue I 
were seeing (I CCed you on the patch).

Before I got my hands on the failing system and was able to root cause it, I 
was pretty sure that your patch was going to fix our issue, because after I 
examined the code paths, I couldn't find any other reason that the error 
handler would not get woken up.  I tried forcing the bug that your patch fixes 
to occur, by compiling in some mdelay()s in a key place or two in the scsi 
code, but it never failed for me that way.  With my patch, several systems that 
previously failed in 10 minutes or less successfully ran for many days.

Thanks,
Stuart

On 11/9/2017 8:54 AM, Pavel Tikhomirov wrote:

Are there any issues with this patch 
(https://patchwork.kernel.org/patch/9938919/) that Pavel Tikhomirov submitted 
back in September?  I am willing to help if there's anything I can do to help 
get it accepted.


Hi, Stuart, I asked James Bottomley about the patch status offlist and it seems 
that the problem is - patch lacks testing and review. I would highly appreciate 
review from your side and anyone who wants to participate!

And if you can confirm that the patch solves the problem on your environment with no side 
effects please add "Tested-by:" tag also.

Thanks, Pavel

On 09/05/2017 03:54 PM, Pavel Tikhomirov wrote:

We have a problem on several our nodes with scsi EH. Imagine such an
order of execution of two threads:

CPU1 scsi_eh_scmd_add    CPU2 scsi_host_queue_ready
/* shost->host_busy == 1 initialy */

     if (shost->shost_state == SHOST_RECOVERY)
     /* does not get here */
     return 0;

lock(shost->host_lock);
shost->shost_state = SHOST_RECOVERY;

     busy = shost->host_busy++;
     /* host->can_queue == 1 initialy, busy == 1
  * - go to starved label */
     lock(shost->host_lock) /* wait */

shost->host_failed++;
/* shost->host_busy == 2, shost->host_failed == 1 */
call scsi_eh_wakeup(shost) {
 if (host_busy == host_failed) {
     /* does not get here */
     wake_up_process(shost->ehandler)
 }
}
unlock(shost->host_lock)

     /* acquire lock */
     shost->host_busy--;

Finaly we do not wakeup scsi_error_handler and all other commands
coming will hang as we are in never ending recovery state as there
is no one left to wakeup handler.

So scsi disc in these host becomes unresponsive and all bio on node
hangs. (We trigger these problem when scsi cmnds to DVD drive timeout.)

Main idea of the fix is to try to do wake up every time we decrement
host_busy or increment host_failed(the latter is already OK).

Now the very *last* one of busy threads getting host_lock after
decrementing host_busy will see all write operations on host's
shost_state, host_busy and host_failed completed thanks to implied
memory barriers on spin_lock/unlock, so at the time of busy==failed
we will trigger wakeup in at least one thread. (Thats why putting
recovery and failed checks under lock)

Signed-off-by: Pavel Tikhomirov 
---
   drivers/scsi/scsi_lib.c | 21 +
   1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f6097b89d5d3..6c99221d60aa 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -320,12 +320,11 @@ void scsi_device_unbusy(struct scsi_device *sdev)
   if (starget->can_queue > 0)
   atomic_dec(>target_busy);
   +    spin_lock_irqsave(shost->host_lock, flags);
   if (unlikely(scsi_host_in_recovery(shost) &&
- (shost->host_failed || shost->host_eh_scheduled))) {
-    spin_lock_irqsave(shost->host_lock, flags);
+ (shost->host_failed || shost->host_eh_scheduled)))
   scsi_eh_wakeup(shost);
-    spin_unlock_irqrestore(shost->host_lock, flags);
-    }
+    spin_unlock_irqrestore(shost->host_lock, flags);
     atomic_dec(>device_busy);
   }
@@ -1503,6 +1502,13 @@ static inline int scsi_host_queue_ready(struct 
request_queue *q,
   spin_unlock_irq(shost->host_lock);
   out_dec:
   atomic_dec(>host_busy);
+
+    spin_lock_irq(shost->host_lock);
+    if (unlikely(scsi_host_in_recovery(shost) &&
+ (shost->host_failed || shost->host_eh_scheduled)))
+    scsi_eh_wakeup(shost);
+    spin_unlock_irq(shost->host_lock);
+
   return 0;
   }
   @@ -1964,6 +1970,13 @@ static blk_status_t scsi_queue_rq(struct 
blk_mq_hw_ctx *hctx,
     out_dec_host_busy:
   atomic_dec(>host_busy);
+
+    spin_lock_irq(shost->host_lock);
+    if (unlikely(scsi_host_in_recovery(shost) &&
+  

[PATCHv3] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[Hans Verkuil]

If the device tree for a board did not specify a cec clock, then
adv7511_cec_init would return an error, which would cause adv7511_probe()
to fail and thus there is no HDMI output.

There is no need to have adv7511_probe() fail if the CEC initialization
fails, so just change adv7511_cec_init() to a void function. In addition,
adv7511_cec_init() should just return silently if the cec clock isn't
found and show a message for any other errors.

An otherwise correct cleanup patch from Dan Carpenter turned this broken
failure handling into a kernel Oops, so bisection points to commit
7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL") rather
than 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support").

Based on earlier patches from Arnd and John.

Reported-by: Naresh Kamboju 
Cc: Xinliang Liu 
Cc: Dan Carpenter 
Cc: Sean Paul 
Cc: Archit Taneja 
Cc: John Stultz 
Link: https://bugs.linaro.org/show_bug.cgi?id=3345
Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Hans Verkuil 
Tested-by: Hans Verkuil 
---
This rework of Arnd and John's patches goes a bit further and just silently
exits if there is no cec clock defined in the dts. I'm sure that's the
reason why the kirin board failed on this. BTW: if the kirin board DOES
support cec, then it would be nice if it can be hooked up in the dts!

Tested with my Dragonboard and Renesas Koelsch board. Also tested what
happens when probing is deferred due to missing cec clock.

John, can you test this again?

Changes since v2:
- reverted adv7511_cec_init back to an int function for EPROBE_DEFER
- incorporated Laurent's comments
- moved the adv7511_cec_init call up in the probe function to prevent
  having to remove the bridge in case of an error.

Change since my previous RFC PATCH:

- added static inline adv7511_cec_init to avoid #ifdef in the probe function
  as suggested by John Stultz.

Regards,

Hans
---
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index b4efcbabf7f7..d034b2cb5eee 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -372,9 +372,18 @@ struct adv7511 {
 };

 #ifdef CONFIG_DRM_I2C_ADV7511_CEC
-int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
-unsigned int offset);
+int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511);
 void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+#else
+static inline int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
+{
+   unsigned int offset = adv7511->type == ADV7533 ?
+   ADV7533_REG_CEC_OFFSET : 0;
+
+   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
+ADV7511_CEC_CTRL_POWER_DOWN);
+   return 0;
+}
 #endif

 #ifdef CONFIG_DRM_I2C_ADV7533
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
index b33d730e4d73..a20a45c0b353 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
@@ -300,18 +300,21 @@ static int adv7511_cec_parse_dt(struct device *dev, 
struct adv7511 *adv7511)
return 0;
 }

-int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511,
-unsigned int offset)
+int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
 {
+   unsigned int offset = adv7511->type == ADV7533 ?
+   ADV7533_REG_CEC_OFFSET : 0;
int ret = adv7511_cec_parse_dt(dev, adv7511);

if (ret)
-   return ret;
+   goto err_cec_parse_dt;

adv7511->cec_adap = cec_allocate_adapter(_cec_adap_ops,
adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
-   if (IS_ERR(adv7511->cec_adap))
-   return PTR_ERR(adv7511->cec_adap);
+   if (IS_ERR(adv7511->cec_adap)) {
+   ret = PTR_ERR(adv7511->cec_adap);
+   goto err_cec_alloc;
+   }

regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset, 0);
/* cec soft reset */
@@ -329,9 +332,18 @@ int adv7511_cec_init(struct device *dev, struct adv7511 
*adv7511,
 ((adv7511->cec_clk_freq / 75) - 1) << 2);

ret = cec_register_adapter(adv7511->cec_adap, dev);
-   if (ret) {
-   cec_delete_adapter(adv7511->cec_adap);
-   adv7511->cec_adap = NULL;
-   }
-   return ret;
+   if (ret)
+   goto err_cec_register;
+   return 0;
+
+err_cec_register:
+   

Re: [PATCH 1/2 v2] dmaengine: rcar-dmac: ensure CHCR DE bit is actually 0 after clear

[Laurent Pinchart]

On Friday, 17 November 2017 10:41:05 EET Geert Uytterhoeven wrote:
> On Fri, Nov 17, 2017 at 1:10 AM, Kuninori Morimoto wrote:
> >>> +static void rcar_dmac_chcr_de_barrier(struct rcar_dmac_chan *chan)
> >>> +{
> >>> +   u32 chcr;
> >>> +   int i;
> >> 
> >> unsigned int
> >> 
> >>> +
> >>> +   /*
> >>> +* Ensure that the setting of the DE bit is actually 0 after
> >>> +* clearing it.
> >>> +*/
> >>> +   for (i = 0; i < 1024; i++) {
> >>> +   chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
> >>> +   if (!(chcr & RCAR_DMACHCR_DE))
> >>> +   return;
> >>> +   udelay(1);
> >>> +   }
> >> 
> >> What's a typical number of loops needed before DE is really cleared?
> > 
> > It case by case, but I don't want to use while(1) loop
> 
> I understand that, and I agree wholeheartedly with limiting the number
> of cycles.

So do I, but I'd still like to know what the typical values are :-)

-- 
Regards,

Laurent Pinchart

[f2fs-dev] [PATCH RESEND v2] f2fs: fix concurrent problem for updating free bitmap

[LiFan]

alloc_nid_failed and scan_nat_page can be called at the same time,
and we haven't protected add_free_nid and update_free_nid_bitmap
with the same nid_list_lock. That could lead to

Thread AThread B
- __build_free_nids
 - scan_nat_page
  - add_free_nid
- alloc_nid_failed
 - update_free_nid_bitmap
  - update_free_nid_bitmap

scan_nat_page will clear the free bitmap since the nid is PREALLOC_NID,
but alloc_nid_failed needs to set the free bitmap. This results in
free nid with free bitmap cleared.
This patch update the bitmap under the same nid_list_lock in add_free_nid.
And use __GFP_NOFAIL to make sure to update status of free nid correctly.

Signed-off-by: Fan li 
---
 fs/f2fs/node.c | 84 ++
 1 file changed, 43 insertions(+), 41 deletions(-)

diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b965a53..dd299c5 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1811,8 +1811,33 @@ static void __move_free_nid(struct f2fs_sb_info *sbi, 
struct free_nid *i,
}
 }
 
+static void update_free_nid_bitmap(struct f2fs_sb_info *sbi, nid_t nid,
+   bool set, bool build)
+{
+   struct f2fs_nm_info *nm_i = NM_I(sbi);
+   unsigned int nat_ofs = NAT_BLOCK_OFFSET(nid);
+   unsigned int nid_ofs = nid - START_NID(nid);
+
+   if (!test_bit_le(nat_ofs, nm_i->nat_block_bitmap))
+   return;
+
+   if (set) {
+   if (test_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]))
+   return;
+   __set_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
+   nm_i->free_nid_count[nat_ofs]++;
+   } else {
+   if (!test_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]))
+   return;
+   __clear_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
+   if (!build)
+   nm_i->free_nid_count[nat_ofs]--;
+   }
+}
+
 /* return if the nid is recognized as free */
-static bool add_free_nid(struct f2fs_sb_info *sbi, nid_t nid, bool build)
+static bool add_free_nid(struct f2fs_sb_info *sbi,
+   nid_t nid, bool build, bool update)
 {
struct f2fs_nm_info *nm_i = NM_I(sbi);
struct free_nid *i, *e;
@@ -1828,7 +1853,7 @@ static bool add_free_nid(struct f2fs_sb_info *sbi, nid_t 
nid, bool build)
i->nid = nid;
i->state = FREE_NID;
 
-   if (radix_tree_preload(GFP_NOFS))
+   if (radix_tree_preload(GFP_NOFS | __GFP_NOFAIL))
goto err;
 
spin_lock(_i->nid_list_lock);
@@ -1870,6 +1895,11 @@ static bool add_free_nid(struct f2fs_sb_info *sbi, nid_t 
nid, bool build)
ret = true;
err = __insert_free_nid(sbi, i, FREE_NID);
 err_out:
+   if (update) {
+   update_free_nid_bitmap(sbi, nid, ret, build);
+   if (!build)
+   nm_i->available_nids++;
+   }
spin_unlock(_i->nid_list_lock);
radix_tree_preload_end();
 err:
@@ -1896,30 +1926,6 @@ static void remove_free_nid(struct f2fs_sb_info *sbi, 
nid_t nid)
kmem_cache_free(free_nid_slab, i);
 }
 
-static void update_free_nid_bitmap(struct f2fs_sb_info *sbi, nid_t nid,
-   bool set, bool build)
-{
-   struct f2fs_nm_info *nm_i = NM_I(sbi);
-   unsigned int nat_ofs = NAT_BLOCK_OFFSET(nid);
-   unsigned int nid_ofs = nid - START_NID(nid);
-
-   if (!test_bit_le(nat_ofs, nm_i->nat_block_bitmap))
-   return;
-
-   if (set) {
-   if (test_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]))
-   return;
-   __set_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
-   nm_i->free_nid_count[nat_ofs]++;
-   } else {
-   if (!test_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]))
-   return;
-   __clear_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
-   if (!build)
-   nm_i->free_nid_count[nat_ofs]--;
-   }
-}
-
 static void scan_nat_page(struct f2fs_sb_info *sbi,
struct page *nat_page, nid_t start_nid)
 {
@@ -1937,18 +1943,18 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
i = start_nid % NAT_ENTRY_PER_BLOCK;
 
for (; i < NAT_ENTRY_PER_BLOCK; i++, start_nid++) {
-   bool freed = false;
-
if (unlikely(start_nid >= nm_i->max_nid))
break;
 
blk_addr = le32_to_cpu(nat_blk->entries[i].block_addr);
f2fs_bug_on(sbi, blk_addr == NEW_ADDR);
-   if (blk_addr == NULL_ADDR)
-   freed = add_free_nid(sbi, start_nid, true);
-   

Re: [PATCH] docs: add submitting-pull-requests.rst

[Jani Nikula]

On Tue, 21 Nov 2017, "Tobin C. Harding"  wrote:
> On Wed, Nov 15, 2017 at 04:09:32PM +0200, Jani Nikula wrote:
>> On Wed, 15 Nov 2017, "Tobin C. Harding"  wrote:
>> > Original email thread 
>> >
>> > https://lkml.org/lkml/2017/11/14/184
>> 
>> Please use http://lkml.kernel.org/r/20171114110500.ga21...@kroah.com so
>> people can find the messages using the message-id.
>
> How did you generate this URL? Is this the format that should be used
> whenever linking to LKML messages i.e when including links in mail being
> sent to LKML?

See https://lkml.kernel.org/. It's just a base URL + message-id of the
message. (In my MUA, I can just hit a few keys and get the URL stashed
to the clipboard.)

The message-id based URL lets people find the message using their MUA
instead of having to go to some horrendous web site. But it still lets
people who prefer web sites use them.

Moreover, if an archive goes down, this makes it possible to still find
the message.



BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] perf parse events: Fix invalid precise_ip handling

[zhangmengting]

On 2017/11/20 15:33, Jiri Olsa wrote:

On Wed, Nov 15, 2017 at 09:00:03AM +0800, zhangmengting wrote:

Hi Jiri, thanks for your detailed review, please see my comments inline.


On 2017/11/10 18:39, Jiri Olsa wrote:

On Fri, Nov 10, 2017 at 04:28:37PM +0800, Mengting Zhang wrote:

SNIP


diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 39b1596..25225f4 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1369,6 +1369,32 @@ struct event_modifier {
int pinned;
   };
+static int perf_get_max_precise_ip(void)
+{
+   int max_precise_ip = 0;
+   struct perf_event_attr attr = {
+   .type   = PERF_TYPE_HARDWARE,
+   .config = PERF_COUNT_HW_CPU_CYCLES,
+   };
+
+   event_attr_init();
+
+   attr.precise_ip = 3;
+   attr.sample_period = 1;
+
+   while (attr.precise_ip != 0) {
+   int fd = sys_perf_event_open(, 0, -1, -1, 0);
+   if (fd != -1){
+   close(fd);
+   break;
+   }
+   --attr.precise_ip;
+   }
+   max_precise_ip = attr.precise_ip;
+
+   return max_precise_ip;
+}

we already have a function for that, please check 
perf_event_attr__set_max_precise_ip

Yeah, I've checked that function. But perf_event_attr__set_max_precise_ip()
will change attr.precise_ip
into the max precise ip available.

In this case, perf should only check whether the user-specified precise_ip
is greater than the max
precise_ip without changing it into maximum.  Here, introduce
perf_get_max_precise_ip() to return
the max precise ip and do not change attr.precise_ip.

But you reminds me that perf_get_max_precise_ip() can be simplied.

well both do the same.. probe kernel for max precise level,
so we can keep just one function for that


OKay, I will just keep that function for probing max precise level.


also I think the precise level is not generic for all the events,
so you should check it for specific perf_event_attr later, when
the attr is ready, not in modifier parsing

You are right, and I would check it for specific perf_event_attr.

BTW, I have a question. If the user-specified precise_ip is greater than the
max precise_ip, I wonder
whether it is better to adjust the user-specified precise_ip to the maximum
available.

no, I think that user defined precise level should stay the
way the user wants it.. we don't want more angry users ;-)


Humm, I am sorry for being unclear.
If the user defined precise level is greater than the max precise level,
I think there are two ways to deal with it.
1.  return EINVAL to indicate the invalid precise_ip setting;
2.  adjust to the max precise level available and give message to 
indicate the adjustment.


Since we should check user-defined precise level in perf_evsel__config(),
when the attr is ready, I think there is a problem with method 1, if we 
keep the

user defined precise level stay the way the user wants it.

With method 1, we have to let perf_evsel__config() return value and show 
errno.
And this change will affect many related functions, such as 
perf_evlist__config(), and files.


With method 2, we don't need to change the return type of 
perf_evsel__config().


Am I right?


jirka

.

Re: [PATCH 04/16] x86/fixmap: Generalize the GDT fixmap mechanism

[Thomas Gleixner]

On Mon, 20 Nov 2017, Andy Lutomirski wrote:
> On Mon, Nov 20, 2017 at 2:01 PM, Thomas Gleixner  wrote:
> > On Mon, 20 Nov 2017, Andy Lutomirski wrote:
> >> + * to avoid circular header dependencies.
> >
> > :(
> 
> Hmm.  I could probably fix this, but it involves (at least) moving a
> struct definition and adding several new includes, and I'm not sure
> it'll actually converge to something  working.

Yeah, it's include hell. Looked at it and it's major churn.

> >> + */
> >> +struct cpu_entry_area
> >> +{
> >> + char gdt[PAGE_SIZE];
> >> +};
> >> +
> >> +#define CPU_ENTRY_AREA_PAGES (sizeof(struct cpu_entry_area) / PAGE_SIZE)
> >
> >> +static inline unsigned int __get_cpu_entry_area_page_index(int cpu, int 
> >> page)
> >> +{
> >> + BUILD_BUG_ON(sizeof(struct cpu_entry_area) % PAGE_SIZE != 0);
> >> +
> >> + return FIX_CPU_ENTRY_AREA_BOTTOM - cpu*CPU_ENTRY_AREA_PAGES - page;
> >> +}
> >> +
> >> +#define __get_cpu_entry_area_offset_index(cpu, offset) ({\
> >> + BUILD_BUG_ON(offset % PAGE_SIZE != 0);  \
> >> + __get_cpu_entry_area_page_index(cpu, offset / PAGE_SIZE);   \
> >> + })
> >> +
> >> +#define get_cpu_entry_area_index(cpu, field) \
> >> + __get_cpu_entry_area_offset_index((cpu), offsetof(struct 
> >> cpu_entry_area, field))
> >
> > Any reason why those need to be macros?
> 
> The former is a macro because I doubt that BUILD_BUG_ON is valid in
> that context in a function.

Fair enough.

> The latter is a macro because 'field' is a name, not a value.

Bah. right. 

Thanks,

tglx

[tip:sched/urgent] sched/deadline: Don't use dubious signed bitfields

[tip-bot for Dan Carpenter]

Commit-ID:  aa5222e92f8000ed3c1c38dddf11c83222aadfb3
Gitweb: https://git.kernel.org/tip/aa5222e92f8000ed3c1c38dddf11c83222aadfb3
Author: Dan Carpenter 
AuthorDate: Fri, 13 Oct 2017 10:01:22 +0300
Committer:  Ingo Molnar 
CommitDate: Tue, 21 Nov 2017 09:25:01 +0100

sched/deadline: Don't use dubious signed bitfields

It doesn't cause a run-time bug, but these bitfields should be unsigned.
When it's signed ->dl_throttled is set to either 0 or -1, instead of
0 and 1 as expected.

The sched.h file is included into tons of places so Sparse generates
a flood of warnings like this:

  ./include/linux/sched.h:477:54: error: dubious one-bit signed bitfield

Reported-by: Matthew Wilcox 
Reported-by: Xin Long 
Signed-off-by: Dan Carpenter 
Reviewed-by: Luca Abeni 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: kernel-janit...@vger.kernel.org
Cc: luca abeni 
Link: http://lkml.kernel.org/r/20171013070121.dzcncojuj2f4utij@mwanda
Signed-off-by: Ingo Molnar 
---
 include/linux/sched.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index a5dc7c9..21991d6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -473,10 +473,10 @@ struct sched_dl_entity {
 * conditions between the inactive timer handler and the wakeup
 * code.
 */
-   int dl_throttled  : 1;
-   int dl_boosted: 1;
-   int dl_yielded: 1;
-   int dl_non_contending : 1;
+   unsigned intdl_throttled  : 1;
+   unsigned intdl_boosted: 1;
+   unsigned intdl_yielded: 1;
+   unsigned intdl_non_contending : 1;
 
/*
 * Bandwidth enforcement timer. Each -deadline task has its

[PATCH 1/2] perf intel-pt: Improve build messages for files that differ from the kernel

[Adrian Hunter]

Print file names of files that differ. For example, instead of:

  Warning: Intel PT: x86 instruction decoder differs from kernel

print:

  Warning: Intel PT: x86 instruction decoder header at 
'tools/perf/util/intel-pt-decoder/inat.h' differs from latest version at 
'arch/x86/include/asm/inat.h'

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-pt-decoder/Build | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/tools/perf/util/intel-pt-decoder/Build 
b/tools/perf/util/intel-pt-decoder/Build
index 10e0814bb8d2..1b704fbea9de 100644
--- a/tools/perf/util/intel-pt-decoder/Build
+++ b/tools/perf/util/intel-pt-decoder/Build
@@ -11,15 +11,21 @@ $(OUTPUT)util/intel-pt-decoder/inat-tables.c: 
$(inat_tables_script) $(inat_table
 
 $(OUTPUT)util/intel-pt-decoder/intel-pt-insn-decoder.o: 
util/intel-pt-decoder/intel-pt-insn-decoder.c util/intel-pt-decoder/inat.c 
$(OUTPUT)util/intel-pt-decoder/inat-tables.c
@(diff -I 2>&1 | grep -q 'option requires an argument' && \
-   test -d ../../kernel -a -d ../../tools -a -d ../perf && (( \
-   diff -B -I'^#include' util/intel-pt-decoder/insn.c 
../../arch/x86/lib/insn.c >/dev/null && \
-   diff -B -I'^#include' util/intel-pt-decoder/inat.c 
../../arch/x86/lib/inat.c >/dev/null && \
-   diff -B util/intel-pt-decoder/x86-opcode-map.txt 
../../arch/x86/lib/x86-opcode-map.txt >/dev/null && \
-   diff -B util/intel-pt-decoder/gen-insn-attr-x86.awk 
../../arch/x86/tools/gen-insn-attr-x86.awk >/dev/null && \
-   diff -B -I'^#include' util/intel-pt-decoder/insn.h 
../../arch/x86/include/asm/insn.h >/dev/null && \
-   diff -B -I'^#include' util/intel-pt-decoder/inat.h 
../../arch/x86/include/asm/inat.h >/dev/null && \
-   diff -B -I'^#include' util/intel-pt-decoder/inat_types.h 
../../arch/x86/include/asm/inat_types.h >/dev/null) \
-   || echo "Warning: Intel PT: x86 instruction decoder differs from 
kernel" >&2 )) || true
+   test -d ../../kernel -a -d ../../tools -a -d ../perf && ( \
+   ((diff -B -I'^#include' util/intel-pt-decoder/insn.c 
../../arch/x86/lib/insn.c >/dev/null) || \
+   (echo "Warning: Intel PT: x86 instruction decoder C file at 
'tools/perf/util/intel-pt-decoder/insn.c' differs from latest version at 
'arch/x86/lib/insn.c'" >&2)) && \
+   ((diff -B -I'^#include' util/intel-pt-decoder/inat.c 
../../arch/x86/lib/inat.c >/dev/null) || \
+   (echo "Warning: Intel PT: x86 instruction decoder C file at 
'tools/perf/util/intel-pt-decoder/inat.c' differs from latest version at 
'arch/x86/lib/inat.c'" >&2)) && \
+   ((diff -B util/intel-pt-decoder/x86-opcode-map.txt 
../../arch/x86/lib/x86-opcode-map.txt >/dev/null) || \
+   (echo "Warning: Intel PT: x86 instruction decoder map file at 
'tools/perf/util/intel-pt-decoder/x86-opcode-map.txt' differs from latest 
version at 'arch/x86/lib/x86-opcode-map.txt'" >&2)) && \
+   ((diff -B util/intel-pt-decoder/gen-insn-attr-x86.awk 
../../arch/x86/tools/gen-insn-attr-x86.awk >/dev/null) || \
+   (echo "Warning: Intel PT: x86 instruction decoder script at 
'tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk' differs from latest 
version at 'arch/x86/tools/gen-insn-attr-x86.awk'" >&2)) && \
+   ((diff -B -I'^#include' util/intel-pt-decoder/insn.h 
../../arch/x86/include/asm/insn.h >/dev/null) || \
+   (echo "Warning: Intel PT: x86 instruction decoder header at 
'tools/perf/util/intel-pt-decoder/insn.h' differs from latest version at 
'arch/x86/include/asm/insn.h'" >&2)) && \
+   ((diff -B -I'^#include' util/intel-pt-decoder/inat.h 
../../arch/x86/include/asm/inat.h >/dev/null) || \
+   (echo "Warning: Intel PT: x86 instruction decoder header at 
'tools/perf/util/intel-pt-decoder/inat.h' differs from latest version at 
'arch/x86/include/asm/inat.h'" >&2)) && \
+   ((diff -B -I'^#include' util/intel-pt-decoder/inat_types.h 
../../arch/x86/include/asm/inat_types.h >/dev/null) || \
+   (echo "Warning: Intel PT: x86 instruction decoder header at 
'tools/perf/util/intel-pt-decoder/inat_types.h' differs from latest version at 
'arch/x86/include/asm/inat_types.h'" >&2 || true
$(call rule_mkdir)
$(call if_changed_dep,cc_o_c)
 
-- 
1.9.1

[PATCH 0/2] perf intel-pt: Bring instruction decoder files into line with the kernel

[Adrian Hunter]

Hi

Here are 2 patches for Intel PT to improve build messages and bring
instruction decoder files into line with the kernel.


Adrian Hunter (2):
  perf intel-pt: Improve build messages for files that differ from the 
kernel
  perf intel-pt: Bring instruction decoder files into line with the kernel

 tools/perf/util/intel-pt-decoder/Build  | 24 +++-
 tools/perf/util/intel-pt-decoder/inat.h | 10 ++
 2 files changed, 25 insertions(+), 9 deletions(-)


Regards
Adrian

Re: [PATCH 0/4] MPX and Protection Keys Updates

[Ingo Molnar]

* Dave Hansen  wrote:

> Hi Ingo,
> 
> Here are some small updates to Protection Keys documentation, and
> some small fixes to the selftests that we discussed.

Note that even with all the patches applied, a build warning remains:

gcc -m32 -o /home/mingo/tip/tools/testing/selftests/x86/protection_keys_32 -O2 
-g -std=gnu99 -pthread -Wall -no-pie  protection_keys.c -lrt -ldl -lm
protection_keys.c: In function ‘dumpit’:
protection_keys.c:419:3: warning: ignoring return value of ‘write’, declared 
with 
attribute warn_unused_result [-Wunused-result]
   write(1, buf, nr_read);
   ^~

Thanks,

Ingo

Re: [PATCH] lib: test module for find_*_bit() functions

[Geert Uytterhoeven]

Hi Yury,

On Thu, Nov 9, 2017 at 3:07 PM, Yury Norov  wrote:
> find_bit functions are widely used in the kernel, including hot paths.
> This module tests performance of that functions in 2 typical scenarios:
> randomly filled bitmap with relatively equal distribution of set and
> cleared bits, and sparse bitmap which has 1 set bit for 500 cleared bits.

Thanks for your patch!

> On ThunderX machine:
>
>  Start testing find_bit() with random-filled bitmap
> [1032111.632383] find_next_bit: 240043 cycles,  164062 iterations
> [1032111.647236] find_next_zero_bit:312848 cycles,  163619 iterations
> [1032111.661585] find_last_bit: 193748 cycles,  164062 iterations
> [1032113.450517] find_first_bit:177720874 cycles,   164062 
> iterations
> [1032113.462930]
>  Start testing find_bit() with sparse bitmap
> [1032113.477229] find_next_bit: 3633 cycles,656 iterations
> [1032113.494281] find_next_zero_bit:620399 cycles,  327025 iterations
> [1032113.506723] find_last_bit: 3038 cycles,656 iterations
> [1032113.524485] find_first_bit:691407 cycles,  656 iterations

That's what ends up in dmesg, but that's not what it prints on the console:
"\t" prints an ugly placeholder, as TABs are not supported.

> --- /dev/null
> +++ b/lib/test_find_bit.c
> @@ -0,0 +1,141 @@

> +static int __init test_find_first_bit(void *bitmap, unsigned long len)
> +{
> +   unsigned long i, cnt;
> +   cycles_t cycles;
> +
> +   cycles = get_cycles();

get_cycles() returns zero on half of the architectures.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] arm64: kaslr: Fix kaslr end boundary of virt addr

[Chen Feng]

On 2017/11/21 11:44, Chen Feng wrote:
> With kaslr and kasan enable both, I got the follow issue.
> 
> [   16.130523s]kasan: reg->base = 1, phys_end =1c000,start = 
> 4000, end = ffc0
> [   16.142517s]___alloc_bootmem_nopanic:257
> [   16.148284s]__alloc_memory_core_early:63, addr = 197fc7fc0
> [   16.155670s]__alloc_memory_core_early:65, virt = d7fc7fc0
> [   16.163635s]__alloc_memory_core_early:67, toshow = ff8ffaff8ff8
> [   16.171783s]__alloc_memory_core_early:69, show_phy = ffe2649f8ff8
> [   16.180145s]Unable to handle kernel paging request at virtual address 
> ff8ffaff8ff8
> [   16.189971s]pgd = ffad9c507000
> [   16.195220s][ff8ffaff8ff8] *pgd=000197fc8003, *pud=000197fc8003
> 
> *reg->base = 1, phys_end =1c000,start = 4000, end = 
> ffc0*
> 
> memstart_addr 0
> ARM64_MEMSTART_ALIGN 0x4000
> memstart_offset_seed 0xffc7
> PHYS_OFFSET = 0 - memstart_addr = 0 - 3E4000 = FFC1C000
> 
> reg->base = 0x1  -> 0x4000
> phys_end  = 0x1c000  -> 0xffc0  This is confused, end less 
> than start.
> 
> And In memblock it use "start_addr + size" as the end addr. So in function 
> kasan_init,
> if the start >= end, it will not map the hole block address. But the memory 
> in this
> block is valid. And it can be allocated as well.
> 
> So donot use the last memory region. Changing "range = range / 
> ARM64_MEMSTART_ALIGN + 1" to
> range = range / ARM64_MEMSTART_ALIGN;
> 
> Signed-off-by: Chen Feng 
> Signed-off-by: Chen Xiang 
> ---
>  arch/arm64/mm/init.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 716d122..60112c0 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -267,11 +267,8 @@ void __init arm64_memblock_init(void)
>* margin, the size of the region that the available physical
>* memory spans, randomize the linear region as well.
>*/
> - if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
> - range = range / ARM64_MEMSTART_ALIGN + 1;
> - memstart_addr -= ARM64_MEMSTART_ALIGN *
> -  ((range * memstart_offset_seed) >> 16);
> - }
> + if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN)
> + memstart_addr -= (range * memstart_offset_seed) >> 16;
>   }
Sorry, here is not align to ARM64_MEMSTART_ALIGN

Should be:
if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
range = range / ARM64_MEMSTART_ALIGN;
memstart_addr -= ARM64_MEMSTART_ALIGN *
 ((range * memstart_offset_seed) >> 16);
}

>  
>   /*
> 

Re: [PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper

[Thomas Gleixner]

On Tue, 21 Nov 2017, Mike Galbraith wrote:
> On Mon, 2017-11-20 at 16:33 -0500, Mikulas Patocka wrote:
> > 
> > Is there some specific scenario where you need to call 
> > blk_schedule_flush_plug from rt_spin_lock_fastlock?
> 
> Excellent question.  What's the difference between not getting IO
> started because you meet a mutex with an rt_mutex under the hood, and
> not getting IO started because you meet a spinlock with an rt_mutex
> under the hood?  If just doing the mutex side puts this thing back to
> sleep, I'm happy.

Think about it from the mainline POV.

The spinlock cannot ever go to schedule and therefore cannot create a
situation which requires an unplug. The RT substitution of the spinlock
with a rtmutex based sleeping spinlock should not change that at all.

A regular mutex/rwsem etc. can and will unplug when the lock is contended
and the caller blocks. The RT conversion of these locks to rtmutex based
variants creates the problem: Unplug cannot be called when the task has
pi_blocked_on set because the unplug path might content on yet another
lock. So unplugging in the slow path before setting pi_blocked_on is the
right thing to do.

Thanks,

tglx

[tip:x86/urgent] x86/pkeys: Update documentation about availability

[tip-bot for Dave Hansen]

Commit-ID:  c51ff2c7fc45da8b18b28c4f15eca5a9975dfb59
Gitweb: https://git.kernel.org/tip/c51ff2c7fc45da8b18b28c4f15eca5a9975dfb59
Author: Dave Hansen 
AuthorDate: Fri, 10 Nov 2017 16:12:28 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 21 Nov 2017 09:34:52 +0100

x86/pkeys: Update documentation about availability

Now that CPUs that implement Memory Protection Keys are publicly
available we can be a bit less oblique about where it is available.

Signed-off-by: Dave Hansen 
Acked-by: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/2017001228.dc748...@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
---
 Documentation/x86/protection-keys.txt | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/protection-keys.txt 
b/Documentation/x86/protection-keys.txt
index fa46dcb..ecb0d2d 100644
--- a/Documentation/x86/protection-keys.txt
+++ b/Documentation/x86/protection-keys.txt
@@ -1,5 +1,10 @@
-Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature
-which will be found on future Intel CPUs.
+Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature
+which is found on Intel's Skylake "Scalable Processor" Server CPUs.
+It will be avalable in future non-server parts.
+
+For anyone wishing to test or use this feature, it is available in
+Amazon's EC2 C5 instances and is known to work there using an Ubuntu
+17.04 image.
 
 Memory Protection Keys provides a mechanism for enforcing page-based
 protections, but without requiring modification of the page tables