Applied "ASoC: fsl_esai: Support synchronous mode" to the asoc tree

[Mark Brown]

The patch

   ASoC: fsl_esai: Support synchronous mode

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 1997ee89f36da906efb8e700f1d08368c73883be Mon Sep 17 00:00:00 2001
From: "S.j. Wang" 
Date: Thu, 4 Apr 2019 09:40:56 +
Subject: [PATCH] ASoC: fsl_esai: Support synchronous mode

In ESAI synchronous mode, the clock is generated by Tx, So
we should always set registers of Tx which relate with the
bit clock and frame clock generation (TCCR, TCR, ECR), even
there is only Rx is working.

Signed-off-by: Shengjiu Wang 
Acked-by: Nicolin Chen 
Signed-off-by: Mark Brown 
---
 sound/soc/fsl/fsl_esai.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 3623aa9a6f2e..c7410bbfd2af 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -218,7 +218,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, 
int clk_id,
 {
struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
struct clk *clksrc = esai_priv->extalclk;
-   bool tx = clk_id <= ESAI_HCKT_EXTAL;
+   bool tx = (clk_id <= ESAI_HCKT_EXTAL || esai_priv->synchronous);
bool in = dir == SND_SOC_CLOCK_IN;
u32 ratio, ecr = 0;
unsigned long clk_rate;
@@ -253,7 +253,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, 
int clk_id,
ecr |= ESAI_ECR_ETI;
/* fall through */
case ESAI_HCKR_EXTAL:
-   ecr |= ESAI_ECR_ERI;
+   ecr |= esai_priv->synchronous ? ESAI_ECR_ETI : ESAI_ECR_ERI;
break;
default:
return -EINVAL;
@@ -537,10 +537,18 @@ static int fsl_esai_hw_params(struct snd_pcm_substream 
*substream,
 
bclk = params_rate(params) * slot_width * esai_priv->slots;
 
-   ret = fsl_esai_set_bclk(dai, tx, bclk);
+   ret = fsl_esai_set_bclk(dai, esai_priv->synchronous || tx, bclk);
if (ret)
return ret;
 
+   mask = ESAI_xCR_xSWS_MASK;
+   val = ESAI_xCR_xSWS(slot_width, width);
+
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask, val);
+   /* Recording in synchronous mode needs to set TCR also */
+   if (!tx && esai_priv->synchronous)
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, mask, val);
+
/* Use Normal mode to support monaural audio */
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
   ESAI_xCR_xMOD_MASK, params_channels(params) > 1 ?
@@ -556,10 +564,9 @@ static int fsl_esai_hw_params(struct snd_pcm_substream 
*substream,
 
regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx), mask, val);
 
-   mask = ESAI_xCR_xSWS_MASK | (tx ? ESAI_xCR_PADC : 0);
-   val = ESAI_xCR_xSWS(slot_width, width) | (tx ? ESAI_xCR_PADC : 0);
-
-   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask, val);
+   if (tx)
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
+   ESAI_xCR_PADC, ESAI_xCR_PADC);
 
/* Remove ESAI personal reset by configuring ESAI_PCRC and ESAI_PRRC */
regmap_update_bits(esai_priv->regmap, REG_ESAI_PRRC,
-- 
2.20.1

Re: [PATCH -next] ibmvnic: remove set but not used variable 'netdev'

[David Miller]

From: Yue Haibing 
Date: Wed, 3 Apr 2019 15:54:09 +0800

> From: YueHaibing 
> 
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/ibm/ibmvnic.c: In function '__ibmvnic_reset':
> drivers/net/ethernet/ibm/ibmvnic.c:1971:21: warning: variable 'netdev' set 
> but not used [-Wunused-but-set-variable]
> 
> It's never used since introduction in
> commit ed651a10875f ("ibmvnic: Updated reset handling")
> 
> Signed-off-by: YueHaibing 

Applied.

Re: [PATCH kernel RFC 2/2] vfio-pci-nvlink2: Implement interconnect isolation

[David Gibson]

On Fri, Mar 22, 2019 at 05:10:25PM -0600, Alex Williamson wrote:
> On Fri, 22 Mar 2019 14:08:38 +1100
> David Gibson  wrote:
> 
> > On Thu, Mar 21, 2019 at 12:19:34PM -0600, Alex Williamson wrote:
> > > On Thu, 21 Mar 2019 10:56:00 +1100
> > > David Gibson  wrote:
> > >   
> > > > On Wed, Mar 20, 2019 at 01:09:08PM -0600, Alex Williamson wrote:  
> > > > > On Wed, 20 Mar 2019 15:38:24 +1100
> > > > > David Gibson  wrote:
> > > > > 
> > > > > > On Tue, Mar 19, 2019 at 10:36:19AM -0600, Alex Williamson wrote:
> > > > > > > On Fri, 15 Mar 2019 19:18:35 +1100
> > > > > > > Alexey Kardashevskiy  wrote:
> > > > > > >   
> > > > > > > > The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe 
> > > > > > > > links and
> > > > > > > > (on POWER9) NVLinks. In addition to that, GPUs themselves have 
> > > > > > > > direct
> > > > > > > > peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment 
> > > > > > > > the POWERNV
> > > > > > > > platform puts all interconnected GPUs to the same IOMMU group.
> > > > > > > > 
> > > > > > > > However the user may want to pass individual GPUs to the 
> > > > > > > > userspace so
> > > > > > > > in order to do so we need to put them into separate IOMMU 
> > > > > > > > groups and
> > > > > > > > cut off the interconnects.
> > > > > > > > 
> > > > > > > > Thankfully V100 GPUs implement an interface to do by 
> > > > > > > > programming link
> > > > > > > > disabling mask to BAR0 of a GPU. Once a link is disabled in a 
> > > > > > > > GPU using
> > > > > > > > this interface, it cannot be re-enabled until the secondary bus 
> > > > > > > > reset is
> > > > > > > > issued to the GPU.
> > > > > > > > 
> > > > > > > > This defines a reset_done() handler for V100 NVlink2 device 
> > > > > > > > which
> > > > > > > > determines what links need to be disabled. This relies on 
> > > > > > > > presence
> > > > > > > > of the new "ibm,nvlink-peers" device tree property of a GPU 
> > > > > > > > telling which
> > > > > > > > PCI peers it is connected to (which includes NVLink bridges or 
> > > > > > > > peer GPUs).
> > > > > > > > 
> > > > > > > > This does not change the existing behaviour and instead adds
> > > > > > > > a new "isolate_nvlink" kernel parameter to allow such isolation.
> > > > > > > > 
> > > > > > > > The alternative approaches would be:
> > > > > > > > 
> > > > > > > > 1. do this in the system firmware (skiboot) but for that we 
> > > > > > > > would need
> > > > > > > > to tell skiboot via an additional OPAL call whether or not we 
> > > > > > > > want this
> > > > > > > > isolation - skiboot is unaware of IOMMU groups.
> > > > > > > > 
> > > > > > > > 2. do this in the secondary bus reset handler in the POWERNV 
> > > > > > > > platform -
> > > > > > > > the problem with that is at that point the device is not 
> > > > > > > > enabled, i.e.
> > > > > > > > config space is not restored so we need to enable the device 
> > > > > > > > (i.e. MMIO
> > > > > > > > bit in CMD register + program valid address to BAR0) in order 
> > > > > > > > to disable
> > > > > > > > links and then perhaps undo all this initialization to bring 
> > > > > > > > the device
> > > > > > > > back to the state where pci_try_reset_function() expects it to 
> > > > > > > > be.  
> > > > > > > 
> > > > > > > The trouble seems to be that this approach only maintains the 
> > > > > > > isolation
> > > > > > > exposed by the IOMMU group when vfio-pci is the active driver for 
> > > > > > > the
> > > > > > > device.  IOMMU groups can be used by any driver and the IOMMU 
> > > > > > > core is
> > > > > > > incorporating groups in various ways.  
> > > > > > 
> > > > > > I don't think that reasoning is quite right.  An IOMMU group doesn't
> > > > > > necessarily represent devices which *are* isolated, just devices 
> > > > > > which
> > > > > > *can be* isolated.  There are plenty of instances when we don't need
> > > > > > to isolate devices in different IOMMU groups: passing both groups to
> > > > > > the same guest or userspace VFIO driver for example, or indeed when
> > > > > > both groups are owned by regular host kernel drivers.
> > > > > > 
> > > > > > In at least some of those cases we also don't want to isolate the
> > > > > > devices when we don't have to, usually for performance reasons.
> > > > > 
> > > > > I see IOMMU groups as representing the current isolation of the 
> > > > > device,
> > > > > not just the possible isolation.  If there are ways to break down that
> > > > > isolation then ideally the group would be updated to reflect it.  The
> > > > > ACS disable patches seem to support this, at boot time we can choose 
> > > > > to
> > > > > disable ACS at certain points in the topology to favor peer-to-peer
> > > > > performance over isolation.  This is then reflected in the group
> > > > > composition, because even though ACS *can be* enabled at the given
> > > > > isolation points, it's intentionally not with this option.  Whether or
> > > > > not a 

Re: [RFC PATCH kernel v2] powerpc/powernv: Isolate NVLinks between GV100GL on Witherspoon

[David Gibson]

On Thu, Apr 04, 2019 at 02:22:25PM -0600, Alex Williamson wrote:
> On Thu,  4 Apr 2019 16:23:24 +1100
> Alexey Kardashevskiy  wrote:
> 
> > The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> > (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> > peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
> > platform puts all interconnected GPUs to the same IOMMU group.
> > 
> > However the user may want to pass individual GPUs to the userspace so
> > in order to do so we need to put them into separate IOMMU groups and
> > cut off the interconnects.
> > 
> > Thankfully V100 GPUs implement an interface to do by programming link
> > disabling mask to BAR0 of a GPU. Once a link is disabled in a GPU using
> > this interface, it cannot be re-enabled until the secondary bus reset is
> > issued to the GPU.
> > 
> > This adds an extra step to the secondary bus reset handler (the one used
> > for such GPUs) to block NVLinks to GPUs which do not belong to the same
> > group as the GPU being reset.
> > 
> > This adds a new "isolate_nvlink" kernel parameter to allow GPU isolation;
> > when enabled, every GPU gets its own IOMMU group. The new parameter is off
> > by default to preserve the existing behaviour.
> > 
> > Signed-off-by: Alexey Kardashevskiy 
> > ---
> > Changes:
> > v2:
> > * this is rework of [PATCH kernel RFC 0/2] vfio, powerpc/powernv: Isolate 
> > GV100GL
> > but this time it is contained in the powernv platform
> > ---
> >  arch/powerpc/platforms/powernv/Makefile  |   2 +-
> >  arch/powerpc/platforms/powernv/pci.h |   1 +
> >  arch/powerpc/platforms/powernv/eeh-powernv.c |   1 +
> >  arch/powerpc/platforms/powernv/npu-dma.c |  24 +++-
> >  arch/powerpc/platforms/powernv/nvlinkgpu.c   | 131 +++
> >  5 files changed, 156 insertions(+), 3 deletions(-)
> >  create mode 100644 arch/powerpc/platforms/powernv/nvlinkgpu.c
> > 
> > diff --git a/arch/powerpc/platforms/powernv/Makefile 
> > b/arch/powerpc/platforms/powernv/Makefile
> > index da2e99efbd04..60a10d3b36eb 100644
> > --- a/arch/powerpc/platforms/powernv/Makefile
> > +++ b/arch/powerpc/platforms/powernv/Makefile
> > @@ -6,7 +6,7 @@ obj-y   += opal-msglog.o opal-hmi.o 
> > opal-power.o opal-irqchip.o
> >  obj-y  += opal-kmsg.o opal-powercap.o opal-psr.o 
> > opal-sensor-groups.o
> >  
> >  obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
> > -obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
> > +obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o nvlinkgpu.o
> >  obj-$(CONFIG_CXL_BASE) += pci-cxl.o
> >  obj-$(CONFIG_EEH)  += eeh-powernv.o
> >  obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
> > diff --git a/arch/powerpc/platforms/powernv/pci.h 
> > b/arch/powerpc/platforms/powernv/pci.h
> > index 8e36da379252..9fd3f391482c 100644
> > --- a/arch/powerpc/platforms/powernv/pci.h
> > +++ b/arch/powerpc/platforms/powernv/pci.h
> > @@ -250,5 +250,6 @@ extern void pnv_pci_unlink_table_and_group(struct 
> > iommu_table *tbl,
> >  extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
> > void *tce_mem, u64 tce_size,
> > u64 dma_offset, unsigned int page_shift);
> > +extern void pnv_try_isolate_nvidia_v100(struct pci_dev *gpdev);
> >  
> >  #endif /* __POWERNV_PCI_H */
> > diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c 
> > b/arch/powerpc/platforms/powernv/eeh-powernv.c
> > index f38078976c5d..464b097d9635 100644
> > --- a/arch/powerpc/platforms/powernv/eeh-powernv.c
> > +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
> > @@ -937,6 +937,7 @@ void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
> > pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
> > pnv_eeh_bridge_reset(dev, EEH_RESET_DEACTIVATE);
> > }
> > +   pnv_try_isolate_nvidia_v100(dev);
> >  }
> >  
> >  static void pnv_eeh_wait_for_pending(struct pci_dn *pdn, const char *type,
> > diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
> > b/arch/powerpc/platforms/powernv/npu-dma.c
> > index dc23d9d2a7d9..017eae8197e7 100644
> > --- a/arch/powerpc/platforms/powernv/npu-dma.c
> > +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> > @@ -529,6 +529,23 @@ static void pnv_comp_attach_table_group(struct 
> > npu_comp *npucomp,
> > ++npucomp->pe_num;
> >  }
> >  
> > +static bool isolate_nvlink;
> > +
> > +static int __init parse_isolate_nvlink(char *p)
> > +{
> > +   bool val;
> > +
> > +   if (!p)
> > +   val = true;
> > +   else if (kstrtobool(p, ))
> > +   return -EINVAL;
> > +
> > +   isolate_nvlink = val;
> > +
> > +   return 0;
> > +}
> > +early_param("isolate_nvlink", parse_isolate_nvlink);
> > +
> >  struct iommu_table_group *pnv_try_setup_npu_table_group(struct pnv_ioda_pe 
> > *pe)
> >  {
> > struct iommu_table_group *table_group;
> > @@ -549,7 +566,7 @@ struct iommu_table_group 
> > *pnv_try_setup_npu_table_group(struct pnv_ioda_pe *pe)
> >  
> > hose 

Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

[Steven Rostedt]

On Thu, 4 Apr 2019 21:17:58 +0300
"Dmitry V. Levin"  wrote:

> There are several places listed below where I'd prefer to see more readable
> equivalents, but feel free to leave it to respective arch maintainers.

I was going to do similar changes, but figured I'd do just that (let
the arch maintainers further optimize the code). I made this more about
fixing the interface and less about the optimization and clean ups that
it can allow.

-- Steve

Re: [RFC PATCH kernel v2] powerpc/powernv: Isolate NVLinks between GV100GL on Witherspoon

[Alex Williamson]

On Thu,  4 Apr 2019 16:23:24 +1100
Alexey Kardashevskiy  wrote:

> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> peer to peer NVLinks in groups of 2 to 4 GPUs. At the moment the POWERNV
> platform puts all interconnected GPUs to the same IOMMU group.
> 
> However the user may want to pass individual GPUs to the userspace so
> in order to do so we need to put them into separate IOMMU groups and
> cut off the interconnects.
> 
> Thankfully V100 GPUs implement an interface to do by programming link
> disabling mask to BAR0 of a GPU. Once a link is disabled in a GPU using
> this interface, it cannot be re-enabled until the secondary bus reset is
> issued to the GPU.
> 
> This adds an extra step to the secondary bus reset handler (the one used
> for such GPUs) to block NVLinks to GPUs which do not belong to the same
> group as the GPU being reset.
> 
> This adds a new "isolate_nvlink" kernel parameter to allow GPU isolation;
> when enabled, every GPU gets its own IOMMU group. The new parameter is off
> by default to preserve the existing behaviour.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> Changes:
> v2:
> * this is rework of [PATCH kernel RFC 0/2] vfio, powerpc/powernv: Isolate 
> GV100GL
> but this time it is contained in the powernv platform
> ---
>  arch/powerpc/platforms/powernv/Makefile  |   2 +-
>  arch/powerpc/platforms/powernv/pci.h |   1 +
>  arch/powerpc/platforms/powernv/eeh-powernv.c |   1 +
>  arch/powerpc/platforms/powernv/npu-dma.c |  24 +++-
>  arch/powerpc/platforms/powernv/nvlinkgpu.c   | 131 +++
>  5 files changed, 156 insertions(+), 3 deletions(-)
>  create mode 100644 arch/powerpc/platforms/powernv/nvlinkgpu.c
> 
> diff --git a/arch/powerpc/platforms/powernv/Makefile 
> b/arch/powerpc/platforms/powernv/Makefile
> index da2e99efbd04..60a10d3b36eb 100644
> --- a/arch/powerpc/platforms/powernv/Makefile
> +++ b/arch/powerpc/platforms/powernv/Makefile
> @@ -6,7 +6,7 @@ obj-y += opal-msglog.o opal-hmi.o 
> opal-power.o opal-irqchip.o
>  obj-y+= opal-kmsg.o opal-powercap.o opal-psr.o 
> opal-sensor-groups.o
>  
>  obj-$(CONFIG_SMP)+= smp.o subcore.o subcore-asm.o
> -obj-$(CONFIG_PCI)+= pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
> +obj-$(CONFIG_PCI)+= pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o nvlinkgpu.o
>  obj-$(CONFIG_CXL_BASE)   += pci-cxl.o
>  obj-$(CONFIG_EEH)+= eeh-powernv.o
>  obj-$(CONFIG_PPC_SCOM)   += opal-xscom.o
> diff --git a/arch/powerpc/platforms/powernv/pci.h 
> b/arch/powerpc/platforms/powernv/pci.h
> index 8e36da379252..9fd3f391482c 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -250,5 +250,6 @@ extern void pnv_pci_unlink_table_and_group(struct 
> iommu_table *tbl,
>  extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
>   void *tce_mem, u64 tce_size,
>   u64 dma_offset, unsigned int page_shift);
> +extern void pnv_try_isolate_nvidia_v100(struct pci_dev *gpdev);
>  
>  #endif /* __POWERNV_PCI_H */
> diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c 
> b/arch/powerpc/platforms/powernv/eeh-powernv.c
> index f38078976c5d..464b097d9635 100644
> --- a/arch/powerpc/platforms/powernv/eeh-powernv.c
> +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
> @@ -937,6 +937,7 @@ void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
>   pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
>   pnv_eeh_bridge_reset(dev, EEH_RESET_DEACTIVATE);
>   }
> + pnv_try_isolate_nvidia_v100(dev);
>  }
>  
>  static void pnv_eeh_wait_for_pending(struct pci_dn *pdn, const char *type,
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
> b/arch/powerpc/platforms/powernv/npu-dma.c
> index dc23d9d2a7d9..017eae8197e7 100644
> --- a/arch/powerpc/platforms/powernv/npu-dma.c
> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> @@ -529,6 +529,23 @@ static void pnv_comp_attach_table_group(struct npu_comp 
> *npucomp,
>   ++npucomp->pe_num;
>  }
>  
> +static bool isolate_nvlink;
> +
> +static int __init parse_isolate_nvlink(char *p)
> +{
> + bool val;
> +
> + if (!p)
> + val = true;
> + else if (kstrtobool(p, ))
> + return -EINVAL;
> +
> + isolate_nvlink = val;
> +
> + return 0;
> +}
> +early_param("isolate_nvlink", parse_isolate_nvlink);
> +
>  struct iommu_table_group *pnv_try_setup_npu_table_group(struct pnv_ioda_pe 
> *pe)
>  {
>   struct iommu_table_group *table_group;
> @@ -549,7 +566,7 @@ struct iommu_table_group 
> *pnv_try_setup_npu_table_group(struct pnv_ioda_pe *pe)
>  
>   hose = pci_bus_to_host(npdev->bus);
>  
> - if (hose->npu) {
> + if (hose->npu && !isolate_nvlink) {
>   table_group = >npu->npucomp.table_group;
>  
>   if (!table_group->group) {
> @@ -559,7 +576,10 @@ struct iommu_table_group 
> 

Re: [PATCH RFC 3/5] powerpc/speculation: Add support for 'cpu_spec_mitigations=' cmdline options

[Timothy Pearson]

Will be joining in ~ 5 mins.  Getting Chromium set up here.

- Original Message -
> From: "Jiri Kosina" 
> To: "Josh Poimboeuf" 
> Cc: "Peter Zijlstra" , "Heiko Carstens" 
> , "Paul Mackerras"
> , "H . Peter Anvin" , "Ingo Molnar" 
> , "Andrea Arcangeli"
> , linux-s...@vger.kernel.org, x...@kernel.org, "Will 
> Deacon" , "Linus
> Torvalds" , "Catalin Marinas" 
> , "Waiman Long"
> , linux-a...@vger.kernel.org, "Jon Masters" 
> , "Borislav Petkov" ,
> "Andy Lutomirski" , "Thomas Gleixner" , 
> linux-arm-ker...@lists.infradead.org,
> "Greg Kroah-Hartman" , 
> linux-ker...@vger.kernel.org, "Tyler Hicks" ,
> "Martin Schwidefsky" , linuxppc-dev@lists.ozlabs.org
> Sent: Thursday, April 4, 2019 2:49:05 PM
> Subject: Re: [PATCH RFC 3/5] powerpc/speculation: Add support for 
> 'cpu_spec_mitigations=' cmdline options

> On Thu, 4 Apr 2019, Josh Poimboeuf wrote:
> 
>> Configure powerpc CPU runtime speculation bug mitigations in accordance
>> with the 'cpu_spec_mitigations=' cmdline options.  This affects
>> Meltdown, Spectre v1, Spectre v2, and Speculative Store Bypass.
> [ ... snip ... ]
>> -if (!no_nospec)
>> +if (!no_nospec && cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF)
> 
> '!no_nospec' is something that I am sure will come back to hunt me in my
> bad dreams.
> 
> But that's been there already, and fixing it is out of scope of this
> patch. Other than that, as discussed previously -- I really like this new
> global option. Feel free to add
> 
>   Reviewed-by: Jiri Kosina 
> 
> for the whole set.
> 
> Thanks,
> 
> --
> Jiri Kosina
> SUSE Labs

Re: [PATCH RFC 3/5] powerpc/speculation: Add support for 'cpu_spec_mitigations=' cmdline options

[Jiri Kosina]

On Thu, 4 Apr 2019, Josh Poimboeuf wrote:

> Configure powerpc CPU runtime speculation bug mitigations in accordance
> with the 'cpu_spec_mitigations=' cmdline options.  This affects
> Meltdown, Spectre v1, Spectre v2, and Speculative Store Bypass.
[ ... snip ... ]
> - if (!no_nospec)
> + if (!no_nospec && cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF)

'!no_nospec' is something that I am sure will come back to hunt me in my 
bad dreams.

But that's been there already, and fixing it is out of scope of this 
patch. Other than that, as discussed previously -- I really like this new 
global option. Feel free to add

Reviewed-by: Jiri Kosina 

for the whole set.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

[Max Filippov]

On Mon, Apr 1, 2019 at 6:45 AM Steven Rostedt  wrote:
>
> From: "Steven Rostedt (Red Hat)" 
>
> At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
> function call syscall_get_arguments() implemented in x86 was horribly
> written and not optimized for the standard case of passing in 0 and 6 for
> the starting index and the number of system calls to get. When looking at
> all the users of this function, I discovered that all instances pass in only
> 0 and 6 for these arguments. Instead of having this function handle
> different cases that are never used, simply rewrite it to return the first 6
> arguments of a system call.
>
> This should help out the performance of tracing system calls by ptrace,
> ftrace and perf.

[...]

>  arch/xtensa/include/asm/syscall.h | 16 ++

For xtensa changes:
Acked-by: Max Filippov 

-- 
Thanks.
-- Max

Re: [PATCH 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args

[Max Filippov]

On Mon, Apr 1, 2019 at 6:45 AM Steven Rostedt  wrote:
>
> From: "Steven Rostedt (VMware)" 
>
> After removing the start and count arguments of syscall_get_arguments() it
> seems reasonable to remove them from syscall_set_arguments(). Note, as of
> today, there are no users of syscall_set_arguments(). But we are told that
> there will be soon. But for now, at least make it consistent with
> syscall_get_arguments().

[...]

>  arch/xtensa/include/asm/syscall.h | 17 ++-

For xtensa changes:
Acked-by: Max Filippov 

-- 
Thanks.
-- Max

Re: [PATCH 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args

[Dmitry V. Levin]

On Mon, Apr 01, 2019 at 09:41:10AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> After removing the start and count arguments of syscall_get_arguments() it
> seems reasonable to remove them from syscall_set_arguments(). Note, as of
> today, there are no users of syscall_set_arguments(). But we are told that
> there will be soon. But for now, at least make it consistent with
> syscall_get_arguments().
> 
> Link: http://lkml.kernel.org/r/20190327222014.ga32...@altlinux.org

FWIW, you can add
Reviewed-by: Dmitry V. Levin 
 
There are two places listed below where I'd prefer to see more readable
equivalents, but feel free to leave it to respective arch maintainers.

> diff --git a/arch/nds32/include/asm/syscall.h 
> b/arch/nds32/include/asm/syscall.h
> index 89a6ec8731d8..671ebd357496 100644
> --- a/arch/nds32/include/asm/syscall.h
> +++ b/arch/nds32/include/asm/syscall.h
> @@ -129,39 +129,20 @@ void syscall_get_arguments(struct task_struct *task, 
> struct pt_regs *regs,
>   * syscall_set_arguments - change system call parameter value
>   * @task:task of interest, must be in system call entry tracing
>   * @regs:task_pt_regs() of @task
> - * @i:   argument index [0,5]
> - * @n:   number of arguments; n+i must be [1,6].
>   * @args:array of argument values to store
>   *
> - * Changes @n arguments to the system call starting with the @i'th argument.
> - * Argument @i gets value @args[0], and so on.
> - * An arch inline version is probably optimal when @i and @n are constants.
> + * Changes 6 arguments to the system call. The first argument gets value
> + * @args[0], and so on.
>   *
>   * It's only valid to call this when @task is stopped for tracing on
>   * entry to a system call, due to %TIF_SYSCALL_TRACE or %TIF_SYSCALL_AUDIT.
> - * It's invalid to call this with @i + @n > 6; we only support system calls
> - * taking up to 6 arguments.
>   */
>  void syscall_set_arguments(struct task_struct *task, struct pt_regs *regs,
> -unsigned int i, unsigned int n,
>  const unsigned long *args)
>  {
> - if (n == 0)
> - return;
> -
> - if (i + n > SYSCALL_MAX_ARGS) {
> - pr_warn("%s called with max args %d, handling only %d\n",
> - __func__, i + n, SYSCALL_MAX_ARGS);
> - n = SYSCALL_MAX_ARGS - i;
> - }
> -
> - if (i == 0) {
> - regs->orig_r0 = args[0];
> - args++;
> - i++;
> - n--;
> - }
> + regs->orig_r0 = args[0];
> + args++;
>  
> - memcpy(>uregs[0] + i, args, n * sizeof(args[0]));
> + memcpy(>uregs[0] + 1, args, 5 * sizeof(args[0]));
>  }

A shorter and slightly more readable equivalent of the last memcpy is

memcpy(>uregs[1], args, 5 * sizeof(args[0]));

> diff --git a/arch/s390/include/asm/syscall.h b/arch/s390/include/asm/syscall.h
> index ee0b1f6aa36d..59c3e91f2cdb 100644
> --- a/arch/s390/include/asm/syscall.h
> +++ b/arch/s390/include/asm/syscall.h
> @@ -74,15 +74,14 @@ static inline void syscall_get_arguments(struct 
> task_struct *task,
>  
>  static inline void syscall_set_arguments(struct task_struct *task,
>struct pt_regs *regs,
> -  unsigned int i, unsigned int n,
>const unsigned long *args)
>  {
> - BUG_ON(i + n > 6);
> + unsigned int n = 6;
> +
>   while (n-- > 0)
> - if (i + n > 0)
> - regs->gprs[2 + i + n] = args[n];
> - if (i == 0)
> - regs->orig_gpr2 = args[0];
> + if (n > 0)
> + regs->gprs[2 + n] = args[n];
> + regs->orig_gpr2 = args[0];
>  }

A shorter and slightly more readable equivalent of the loop is

while (--n > 0)
regs->gprs[2 + n] = args[n];


-- 
ldv


signature.asc
Description: PGP signature

Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

[Dmitry V. Levin]

On Mon, Apr 01, 2019 at 09:41:09AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)" 
> 
> At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
> function call syscall_get_arguments() implemented in x86 was horribly
> written and not optimized for the standard case of passing in 0 and 6 for
> the starting index and the number of system calls to get. When looking at
> all the users of this function, I discovered that all instances pass in only
> 0 and 6 for these arguments. Instead of having this function handle
> different cases that are never used, simply rewrite it to return the first 6
> arguments of a system call.
> 
> This should help out the performance of tracing system calls by ptrace,
> ftrace and perf.
> 
> Link: http://lkml.kernel.org/r/20161107213233.754809...@goodmis.org

FWIW, you can add
Reviewed-by: Dmitry V. Levin 

There are several places listed below where I'd prefer to see more readable
equivalents, but feel free to leave it to respective arch maintainers.

> diff --git a/arch/hexagon/include/asm/syscall.h 
> b/arch/hexagon/include/asm/syscall.h
> index 4af9c7b6f13a..ae3a1e24fabd 100644
> --- a/arch/hexagon/include/asm/syscall.h
> +++ b/arch/hexagon/include/asm/syscall.h
> @@ -37,10 +37,8 @@ static inline long syscall_get_nr(struct task_struct *task,
>  
>  static inline void syscall_get_arguments(struct task_struct *task,
>struct pt_regs *regs,
> -  unsigned int i, unsigned int n,
>unsigned long *args)
>  {
> - BUG_ON(i + n > 6);
> - memcpy(args, &(>r00)[i], n * sizeof(args[0]));
> + memcpy(args, &(>r00)[0], 6 * sizeof(args[0]));

A shorter and slightly more readable equivalent is

memcpy(args, >r00, 6 * sizeof(args[0]));

> diff --git a/arch/nds32/include/asm/syscall.h 
> b/arch/nds32/include/asm/syscall.h
> index f7e5e86765fe..89a6ec8731d8 100644
> --- a/arch/nds32/include/asm/syscall.h
> +++ b/arch/nds32/include/asm/syscall.h
> @@ -108,42 +108,21 @@ void syscall_set_return_value(struct task_struct *task, 
> struct pt_regs *regs,
>   * syscall_get_arguments - extract system call parameter values
>   * @task:task of interest, must be blocked
>   * @regs:task_pt_regs() of @task
> - * @i:   argument index [0,5]
> - * @n:   number of arguments; n+i must be [1,6].
>   * @args:array filled with argument values
>   *
> - * Fetches @n arguments to the system call starting with the @i'th argument
> - * (from 0 through 5).  Argument @i is stored in @args[0], and so on.
> - * An arch inline version is probably optimal when @i and @n are constants.
> + * Fetches 6 arguments to the system call (from 0 through 5). The first
> + * argument is stored in @args[0], and so on.
>   *
>   * It's only valid to call this when @task is stopped for tracing on
>   * entry to a system call, due to %TIF_SYSCALL_TRACE or %TIF_SYSCALL_AUDIT.
> - * It's invalid to call this with @i + @n > 6; we only support system calls
> - * taking up to 6 arguments.
>   */
>  #define SYSCALL_MAX_ARGS 6
>  void syscall_get_arguments(struct task_struct *task, struct pt_regs *regs,
> -unsigned int i, unsigned int n, unsigned long *args)
> +unsigned long *args)
>  {
> - if (n == 0)
> - return;
> - if (i + n > SYSCALL_MAX_ARGS) {
> - unsigned long *args_bad = args + SYSCALL_MAX_ARGS - i;
> - unsigned int n_bad = n + i - SYSCALL_MAX_ARGS;
> - pr_warning("%s called with max args %d, handling only %d\n",
> -__func__, i + n, SYSCALL_MAX_ARGS);
> - memset(args_bad, 0, n_bad * sizeof(args[0]));
> - memset(args_bad, 0, n_bad * sizeof(args[0]));
> - }
> -
> - if (i == 0) {
> - args[0] = regs->orig_r0;
> - args++;
> - i++;
> - n--;
> - }
> -
> - memcpy(args, >uregs[0] + i, n * sizeof(args[0]));
> + args[0] = regs->orig_r0;
> + args++;
> + memcpy(args, >uregs[0] + 1, 5 * sizeof(args[0]));
>  }

A shorter and slightly more readable equivalent of the last memcpy is

memcpy(args, >uregs[1], 5 * sizeof(args[0]));

> diff --git a/arch/powerpc/include/asm/syscall.h 
> b/arch/powerpc/include/asm/syscall.h
> index 1a0e7a8b1c81..5c9b9dc82b7e 100644
> --- a/arch/powerpc/include/asm/syscall.h
> +++ b/arch/powerpc/include/asm/syscall.h
> @@ -65,22 +65,20 @@ static inline void syscall_set_return_value(struct 
> task_struct *task,
>  
>  static inline void syscall_get_arguments(struct task_struct *task,
>struct pt_regs *regs,
> -  unsigned int i, unsigned int n,
>unsigned long *args)
>  {
>   unsigned long val, mask = -1UL;
> -
> - BUG_ON(i + n > 6);
> + unsigned int n = 6;
>  
>  #ifdef 

Re: [RFC PATCH] powerpc/mm: Reduce memory usage for mm_context_t for radix

[Christophe Leroy]

Le 04/04/2019 à 18:13, Nicholas Piggin a écrit :

Christophe Leroy's on April 3, 2019 4:31 am:



Le 02/04/2019 à 16:34, Aneesh Kumar K.V a écrit :

Currently, our mm_context_t on book3s64 include all hash specific
context details like slice mask, subpage protection details. We
can skip allocating those on radix. This will help us to save
8K per mm_context with radix translation.

With the patch applied we have

sizeof(mm_context_t)  = 136
sizeof(struct hash_mm_context)  = 8288

Signed-off-by: Aneesh Kumar K.V 
---
NOTE:

If we want to do this, I am still trying to figure out how best we can do this
without all the #ifdef and other overhead for 8xx book3e


   arch/powerpc/include/asm/book3s/64/mmu-hash.h |  2 +-
   arch/powerpc/include/asm/book3s/64/mmu.h  | 48 +++
   arch/powerpc/include/asm/book3s/64/slice.h|  6 +--
   arch/powerpc/kernel/paca.c|  9 ++--
   arch/powerpc/kernel/setup-common.c|  7 ++-
   arch/powerpc/mm/hash_utils_64.c   | 10 ++--
   arch/powerpc/mm/mmu_context_book3s64.c| 16 ++-
   arch/powerpc/mm/slb.c |  2 +-
   arch/powerpc/mm/slice.c   | 48 +--
   arch/powerpc/mm/subpage-prot.c|  8 ++--
   10 files changed, 91 insertions(+), 65 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h 
b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
index a28a28079edb..d801be977623 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
@@ -657,7 +657,7 @@ extern void slb_set_size(u16 size);
   
   /* 4 bits per slice and we have one slice per 1TB */

   #define SLICE_ARRAY_SIZE (H_PGTABLE_RANGE >> 41)
-#define TASK_SLICE_ARRAY_SZ(x) ((x)->context.slb_addr_limit >> 41)
+#define TASK_SLICE_ARRAY_SZ(x) ((x)->context.hash_context->slb_addr_limit >> 
41)
   
   #ifndef __ASSEMBLY__
   
diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h

index a809bdd77322..07e76e304a3b 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -114,6 +114,33 @@ struct slice_mask {
DECLARE_BITMAP(high_slices, SLICE_NUM_HIGH);
   };
   
+struct hash_mm_context {

+
+   u16 user_psize; /* page size index */


Could we keep that in mm_context_t ?


Why do you want it there?


It was just to avoid so many changes and also the pointer complexity for 
just saving 2 bytes. But your suggestion below seems good.






@@ -155,15 +155,15 @@ static struct slice_mask *slice_mask_for_size(struct 
mm_struct *mm, int psize)
   {
   #ifdef CONFIG_PPC_64K_PAGES
if (psize == MMU_PAGE_64K)
-   return >context.mask_64k;
+   return >context.hash_context->mask_64k;


You should take the two patches below, that would help:
https://patchwork.ozlabs.org/patch/1059056/
https://patchwork.ozlabs.org/patch/1059058/


Above patches seem good I think. What I think Aneesh should have is
is a macro or inline that gives a pointer to the hash_mm_context from
an mm_context pointer.


Good idea. But please call it something else, as it has nothing to do 
with hash outside of book3s64 (ie the 8xx is a nohash32).


Christophe



Architectures which always want it should just put the hash struct
in their mm_context struct and that avoids the pointer overhead
completely.

Thanks,
Nick

Re: [PATCH RFC 0/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options

[Waiman Long]

On 04/04/2019 12:44 PM, Josh Poimboeuf wrote:
> Keeping track of the number of mitigations for all the CPU speculation
> bugs has become overwhelming for many users.  It's getting more and more
> complicated to decide which mitigations are needed for a given
> architecture.  Complicating matters is the fact that each arch tends to
> it own custom way to mitigate the same vulnerability.

... tends to "have its" own ... ?

-Longman

Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options

[Josh Poimboeuf]

On Thu, Apr 04, 2019 at 11:44:11AM -0500, Josh Poimboeuf wrote:
> Keeping track of the number of mitigations for all the CPU speculation
> bugs has become overwhelming for many users.  It's getting more and more
> complicated to decide which mitigations are needed for a given
> architecture.  Complicating matters is the fact that each arch tends to
> their own custom way to mitigate the same vulnerability.

... tends to _have_ its own custom way ...

-- 
Josh

[PATCH RFC 5/5] arm64/speculation: Add support for 'cpu_spec_mitigations=' cmdline options

[Josh Poimboeuf]

Configure arm64 runtime CPU speculation bug mitigations in accordance
with the 'cpu_spec_mitigations=' cmdline options.  This affects
Meltdown and Speculative Store Bypass.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf 
---
 Documentation/admin-guide/kernel-parameters.txt | 2 ++
 arch/arm64/kernel/cpu_errata.c  | 4 
 arch/arm64/kernel/cpufeature.c  | 6 ++
 3 files changed, 12 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index e838af96daa4..0b54385ee7a8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2553,11 +2553,13 @@
off
Disable all speculative CPU mitigations.
Equivalent to: nopti [x86, powerpc]
+  kpti=0 [arm64]
   nospectre_v1 [powerpc]
   nospectre_v2 [x86, powerpc, s390]
   spectre_v2_user=off [x86]
   nobp=0 [s390]
   spec_store_bypass_disable=off 
[x86, powerpc]
+  ssbd=force-off [arm64]
   l1tf=off [x86]
 
auto (default)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 9950bb0cbd52..db8d27e3fb1c 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -385,6 +386,9 @@ static bool has_ssbd_mitigation(const struct 
arm64_cpu_capabilities *entry,
return false;
}
 
+   if (cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF)
+   ssbd_state = ARM64_SSBD_FORCE_DISABLE;
+
switch (psci_ops.conduit) {
case PSCI_CONDUIT_HVC:
arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 4061de10cea6..4512b582d50f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -978,6 +979,11 @@ static bool unmap_kernel_at_el0(const struct 
arm64_cpu_capabilities *entry,
__kpti_forced = -1;
}
 
+   if (cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF) {
+   str = "cpu_spec_mitigations=off";
+   __kpti_forced = -1;
+   }
+
/* Forced? */
if (__kpti_forced) {
pr_info_once("kernel page table isolation forced %s by %s\n",
-- 
2.17.2

[PATCH RFC 4/5] s390/speculation: Add support for 'cpu_spec_mitigations=' cmdline options

[Josh Poimboeuf]

Configure s390 runtime CPU speculation bug mitigations in accordance
with the 'cpu_spec_mitigations=' cmdline options.  This affects Spectre
v1 and Spectre v2.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf 
---
 Documentation/admin-guide/kernel-parameters.txt | 7 ---
 arch/s390/kernel/nospec-branch.c| 4 +++-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 0e8eae1e8a25..e838af96daa4 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2554,8 +2554,9 @@
Disable all speculative CPU mitigations.
Equivalent to: nopti [x86, powerpc]
   nospectre_v1 [powerpc]
-  nospectre_v2 [x86]
+  nospectre_v2 [x86, powerpc, s390]
   spectre_v2_user=off [x86]
+  nobp=0 [s390]
   spec_store_bypass_disable=off 
[x86, powerpc]
   l1tf=off [x86]
 
@@ -2567,7 +2568,7 @@
upgrades, or who have other ways of avoiding
SMT-based attacks.
Equivalent to: pti=auto [x86]
-  spectre_v2=auto [x86]
+  spectre_v2=auto [x86, s390]
   spectre_v2_user=auto [x86]
   spec_store_bypass_disable=auto 
[x86, powerpc]
   l1tf=flush [x86]
@@ -2578,7 +2579,7 @@
always want to be fully mitigated, even if it
means losing SMT.
Equivalent to: pti=auto [x86]
-  spectre_v2=auto [x86]
+  spectre_v2=auto [x86, s390]
   spectre_v2_user=auto [x86]
   spec_store_bypass_disable=auto 
[x86, powerpc]
   l1tf=flush,nosmt [x86]
diff --git a/arch/s390/kernel/nospec-branch.c b/arch/s390/kernel/nospec-branch.c
index bdddaae96559..c40eb672b43a 100644
--- a/arch/s390/kernel/nospec-branch.c
+++ b/arch/s390/kernel/nospec-branch.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
+#include 
 #include 
 
 static int __init nobp_setup_early(char *str)
@@ -58,7 +59,8 @@ early_param("nospectre_v2", nospectre_v2_setup_early);
 
 void __init nospec_auto_detect(void)
 {
-   if (test_facility(156)) {
+   if (test_facility(156) ||
+   cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF) {
/*
 * The machine supports etokens.
 * Disable expolines and disable nobp.
-- 
2.17.2

[PATCH RFC 3/5] powerpc/speculation: Add support for 'cpu_spec_mitigations=' cmdline options

[Josh Poimboeuf]

Configure powerpc CPU runtime speculation bug mitigations in accordance
with the 'cpu_spec_mitigations=' cmdline options.  This affects
Meltdown, Spectre v1, Spectre v2, and Speculative Store Bypass.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf 
---
 Documentation/admin-guide/kernel-parameters.txt | 9 +
 arch/powerpc/kernel/security.c  | 6 +++---
 arch/powerpc/kernel/setup_64.c  | 2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 29dc03971630..0e8eae1e8a25 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2552,10 +2552,11 @@
 
off
Disable all speculative CPU mitigations.
-   Equivalent to: nopti [x86]
+   Equivalent to: nopti [x86, powerpc]
+  nospectre_v1 [powerpc]
   nospectre_v2 [x86]
   spectre_v2_user=off [x86]
-  spec_store_bypass_disable=off 
[x86]
+  spec_store_bypass_disable=off 
[x86, powerpc]
   l1tf=off [x86]
 
auto (default)
@@ -2568,7 +2569,7 @@
Equivalent to: pti=auto [x86]
   spectre_v2=auto [x86]
   spectre_v2_user=auto [x86]
-  spec_store_bypass_disable=auto 
[x86]
+  spec_store_bypass_disable=auto 
[x86, powerpc]
   l1tf=flush [x86]
 
auto,nosmt
@@ -2579,7 +2580,7 @@
Equivalent to: pti=auto [x86]
   spectre_v2=auto [x86]
   spectre_v2_user=auto [x86]
-  spec_store_bypass_disable=auto 
[x86]
+  spec_store_bypass_disable=auto 
[x86, powerpc]
   l1tf=flush,nosmt [x86]
 
mminit_loglevel=
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index b33bafb8fcea..5aed4ad729ba 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -57,7 +57,7 @@ void setup_barrier_nospec(void)
enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) &&
 security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR);
 
-   if (!no_nospec)
+   if (!no_nospec && cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF)
enable_barrier_nospec(enable);
 }
 
@@ -116,7 +116,7 @@ static int __init handle_nospectre_v2(char *p)
 early_param("nospectre_v2", handle_nospectre_v2);
 void setup_spectre_v2(void)
 {
-   if (no_spectrev2)
+   if (no_spectrev2 || cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF)
do_btb_flush_fixups();
else
btb_flush_enabled = true;
@@ -300,7 +300,7 @@ void setup_stf_barrier(void)
 
stf_enabled_flush_types = type;
 
-   if (!no_stf_barrier)
+   if (!no_stf_barrier && cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF)
stf_barrier_enable(enable);
 }
 
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index ba404dd9ce1d..d9d796a66a79 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -932,7 +932,7 @@ void setup_rfi_flush(enum l1d_flush_type types, bool enable)
 
enabled_flush_types = types;
 
-   if (!no_rfi_flush)
+   if (!no_rfi_flush || cpu_spec_mitigations != CPU_SPEC_MITIGATIONS_OFF)
rfi_flush_enable(enable);
 }
 
-- 
2.17.2

[PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options

[Josh Poimboeuf]

Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users.  It's getting more and more
complicated to decide which mitigations are needed for a given
architecture.  Complicating matters is the fact that each arch tends to
their own custom way to mitigate the same vulnerability.

Most users fall into a few basic categories:

a) they want all mitigations off;

b) they want all reasonable mitigations on, with SMT enabled even if
   it's vulnerable; or

c) they want all reasonable mitigations on, with SMT disabled if
   vulnerable.

Define a set of curated, arch-independent options, each of which is an
aggregation of existing options:

- cpu_spec_mitigations=off: Disable all mitigations.

- cpu_spec_mitigations=auto: [default] Enable all the default
  mitigations, but leave SMT enabled, even if it's vulnerable.

- cpu_spec_mitigations=auto,nosmt: Enable all the default mitigations,
  disabling SMT if needed by a mitigation.

Currently, these options are placeholders which don't actually do
anything.  They will be fleshed out in upcoming patches.

Signed-off-by: Josh Poimboeuf 
---
 .../admin-guide/kernel-parameters.txt | 23 +++
 include/linux/cpu.h   |  8 +++
 kernel/cpu.c  | 15 
 3 files changed, 46 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index c4d830003b21..ac42e510bd6e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2544,6 +2544,29 @@
in the "bleeding edge" mini2440 support kernel at
http://repo.or.cz/w/linux-2.6/mini2440.git
 
+   cpu_spec_mitigations=
+   [KNL] Control mitigations for CPU speculation
+   vulnerabilities on affected CPUs.  This is a set of
+   curated, arch-independent options, each of which is an
+   aggregation of existing options.
+
+   off
+   Disable all speculative CPU mitigations.
+
+   auto (default)
+   Mitigate all speculative CPU vulnerabilities,
+   but leave SMT enabled, even if it's vulnerable.
+   This is useful for users who don't want to be
+   surprised by SMT getting disabled across kernel
+   upgrades, or who have other ways of avoiding
+   SMT-based attacks.
+
+   auto,nosmt
+   Mitigate all speculative CPU vulnerabilities,
+   disabling SMT if needed.  This is for users who
+   always want to be fully mitigated, even if it
+   means losing SMT.
+
mminit_loglevel=
[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
parameter allows control of the logging verbosity for
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 5041357d0297..3a1740fda2e2 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -187,4 +187,12 @@ static inline void cpu_smt_disable(bool force) { }
 static inline void cpu_smt_check_topology(void) { }
 #endif
 
+enum cpu_spec_mitigations {
+   CPU_SPEC_MITIGATIONS_OFF,
+   CPU_SPEC_MITIGATIONS_AUTO,
+   CPU_SPEC_MITIGATIONS_AUTO_NOSMT,
+};
+
+extern enum cpu_spec_mitigations cpu_spec_mitigations;
+
 #endif /* _LINUX_CPU_H_ */
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 6c959aea0f9e..0a9d66b90a00 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2306,3 +2306,18 @@ void __init boot_cpu_hotplug_init(void)
 #endif
this_cpu_write(cpuhp_state.state, CPUHP_ONLINE);
 }
+
+enum cpu_spec_mitigations cpu_spec_mitigations __ro_after_init = 
CPU_SPEC_MITIGATIONS_AUTO;
+
+static int __init cpu_spec_mitigations_setup(char *arg)
+{
+   if (!strcmp(arg, "off"))
+   cpu_spec_mitigations = CPU_SPEC_MITIGATIONS_OFF;
+   else if (!strcmp(arg, "auto"))
+   cpu_spec_mitigations = CPU_SPEC_MITIGATIONS_AUTO;
+   else if (!strcmp(arg, "auto,nosmt"))
+   cpu_spec_mitigations = CPU_SPEC_MITIGATIONS_AUTO_NOSMT;
+
+   return 0;
+}
+early_param("cpu_spec_mitigations", cpu_spec_mitigations_setup);
-- 
2.17.2

[PATCH RFC 2/5] x86/speculation: Add support for 'cpu_spec_mitigations=' cmdline options

[Josh Poimboeuf]

Configure x86 runtime CPU speculation bug mitigations in accordance with
the 'cpu_spec_mitigations=' cmdline options.  This affects Meltdown,
Spectre v2, Speculative Store Bypass, and L1TF.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf 
---
 .../admin-guide/kernel-parameters.txt | 15 +
 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/kernel/cpu/bugs.c| 32 ---
 arch/x86/kvm/vmx/vmx.c|  2 ++
 arch/x86/mm/pti.c |  4 ++-
 5 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index ac42e510bd6e..29dc03971630 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2552,6 +2552,11 @@
 
off
Disable all speculative CPU mitigations.
+   Equivalent to: nopti [x86]
+  nospectre_v2 [x86]
+  spectre_v2_user=off [x86]
+  spec_store_bypass_disable=off 
[x86]
+  l1tf=off [x86]
 
auto (default)
Mitigate all speculative CPU vulnerabilities,
@@ -2560,12 +2565,22 @@
surprised by SMT getting disabled across kernel
upgrades, or who have other ways of avoiding
SMT-based attacks.
+   Equivalent to: pti=auto [x86]
+  spectre_v2=auto [x86]
+  spectre_v2_user=auto [x86]
+  spec_store_bypass_disable=auto 
[x86]
+  l1tf=flush [x86]
 
auto,nosmt
Mitigate all speculative CPU vulnerabilities,
disabling SMT if needed.  This is for users who
always want to be fully mitigated, even if it
means losing SMT.
+   Equivalent to: pti=auto [x86]
+  spectre_v2=auto [x86]
+  spectre_v2_user=auto [x86]
+  spec_store_bypass_disable=auto 
[x86]
+  l1tf=flush,nosmt [x86]
 
mminit_loglevel=
[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 2bb3a648fc12..7e95b310f869 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -982,6 +982,7 @@ void microcode_check(void);
 
 enum l1tf_mitigations {
L1TF_MITIGATION_OFF,
+   L1TF_MITIGATION_DEFAULT,
L1TF_MITIGATION_FLUSH_NOWARN,
L1TF_MITIGATION_FLUSH,
L1TF_MITIGATION_FLUSH_NOSMT,
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 2da82eff0eb4..65b95fb95ba5 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -308,8 +308,11 @@ spectre_v2_parse_user_cmdline(enum 
spectre_v2_mitigation_cmd v2_cmd)
 
ret = cmdline_find_option(boot_command_line, "spectre_v2_user",
  arg, sizeof(arg));
-   if (ret < 0)
+   if (ret < 0) {
+   if (cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF)
+   return SPECTRE_V2_USER_CMD_NONE;
return SPECTRE_V2_USER_CMD_AUTO;
+   }
 
for (i = 0; i < ARRAY_SIZE(v2_user_options); i++) {
if (match_option(arg, ret, v2_user_options[i].option)) {
@@ -444,8 +447,11 @@ static enum spectre_v2_mitigation_cmd __init 
spectre_v2_parse_cmdline(void)
return SPECTRE_V2_CMD_NONE;
 
ret = cmdline_find_option(boot_command_line, "spectre_v2", arg, 
sizeof(arg));
-   if (ret < 0)
+   if (ret < 0) {
+   if (cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF)
+   return SPECTRE_V2_CMD_NONE;
return SPECTRE_V2_CMD_AUTO;
+   }
 
for (i = 0; i < ARRAY_SIZE(mitigation_options); i++) {
if (!match_option(arg, ret, mitigation_options[i].option))
@@ -677,8 +683,11 @@ static enum ssb_mitigation_cmd __init 
ssb_parse_cmdline(void)
} else {
ret = cmdline_find_option(boot_command_line, 
"spec_store_bypass_disable",
  arg, sizeof(arg));
-   if (ret < 0)
+   if (ret < 0) {
+   if (cpu_spec_mitigations == 

[PATCH RFC 0/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options

[Josh Poimboeuf]

Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users.  It's getting more and more
complicated to decide which mitigations are needed for a given
architecture.  Complicating matters is the fact that each arch tends to
it own custom way to mitigate the same vulnerability.

Most users fall into a few basic categories:

a) they want all CPU speculation mitigations off;

b) they want all reasonable mitigations on, with SMT enabled even if
   it's vulnerable; or

c) they want all reasonable mitigations on, with SMT disabled if
   vulnerable.

Define a set of curated, arch-independent options, each of which is an
aggregation of existing options:

- cpu_spec_mitigations=off: Disable all mitigations.

- cpu_spec_mitigations=auto: [default] Enable all the default
  mitigations, but leave SMT enabled, even if it's vulnerable.

- cpu_spec_mitigations=auto,nosmt: Enable all the default mitigations,
  disabling SMT if needed by a mitigation.


Josh Poimboeuf (5):
  cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options
  x86/speculation: Add support for 'cpu_spec_mitigations=' cmdline
options
  powerpc/speculation: Add support for 'cpu_spec_mitigations=' cmdline
options
  s390/speculation: Add support for 'cpu_spec_mitigations=' cmdline
options
  arm64/speculation: Add support for 'cpu_spec_mitigations=' cmdline
options

 .../admin-guide/kernel-parameters.txt | 42 +++
 arch/arm64/kernel/cpu_errata.c|  4 ++
 arch/arm64/kernel/cpufeature.c|  6 +++
 arch/powerpc/kernel/security.c|  6 +--
 arch/powerpc/kernel/setup_64.c|  2 +-
 arch/s390/kernel/nospec-branch.c  |  4 +-
 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/kernel/cpu/bugs.c| 32 --
 arch/x86/kvm/vmx/vmx.c|  2 +
 arch/x86/mm/pti.c |  4 +-
 include/linux/cpu.h   |  8 
 kernel/cpu.c  | 15 +++
 12 files changed, 116 insertions(+), 10 deletions(-)

-- 
2.17.2

Re: [Qemu-ppc] pseries on qemu-system-ppc64le crashes in doorbell_core_ipi()

[Nicholas Piggin]

Peter Zijlstra's on April 1, 2019 6:38 pm:
> 
> + fweisbec, who did the remote bits
> 
> On Sat, Mar 30, 2019 at 01:10:28PM +1000, Nicholas Piggin wrote:
>> Something like this?
>> 
>> kernel/irq_work: Do not raise an IPI when queueing work on the local CPU
>> 
>> The QEMU powerpc/pseries machine model was not expecting a self-IPI,
>> and it may be a bit surprising thing to do, so have irq_work_queue_on
>> do local queueing when target is current CPU.
> 
> This seems OK to me.
> 
>> Suggested-by: Steven Rostedt 
>> Signed-off-by: Nicholas Piggin 
> 
> Acked-by: Peter Zijlstra (Intel) 

Thanks for taking a look.

Sebastian, are you able to test if this patch solves your problem?

Thanks,
Nick

Re: [RFC PATCH] powerpc/mm: Reduce memory usage for mm_context_t for radix

[Nicholas Piggin]

Christophe Leroy's on April 3, 2019 4:31 am:
> 
> 
> Le 02/04/2019 à 16:34, Aneesh Kumar K.V a écrit :
>> Currently, our mm_context_t on book3s64 include all hash specific
>> context details like slice mask, subpage protection details. We
>> can skip allocating those on radix. This will help us to save
>> 8K per mm_context with radix translation.
>> 
>> With the patch applied we have
>> 
>> sizeof(mm_context_t)  = 136
>> sizeof(struct hash_mm_context)  = 8288
>> 
>> Signed-off-by: Aneesh Kumar K.V 
>> ---
>> NOTE:
>> 
>> If we want to do this, I am still trying to figure out how best we can do 
>> this
>> without all the #ifdef and other overhead for 8xx book3e
>> 
>> 
>>   arch/powerpc/include/asm/book3s/64/mmu-hash.h |  2 +-
>>   arch/powerpc/include/asm/book3s/64/mmu.h  | 48 +++
>>   arch/powerpc/include/asm/book3s/64/slice.h|  6 +--
>>   arch/powerpc/kernel/paca.c|  9 ++--
>>   arch/powerpc/kernel/setup-common.c|  7 ++-
>>   arch/powerpc/mm/hash_utils_64.c   | 10 ++--
>>   arch/powerpc/mm/mmu_context_book3s64.c| 16 ++-
>>   arch/powerpc/mm/slb.c |  2 +-
>>   arch/powerpc/mm/slice.c   | 48 +--
>>   arch/powerpc/mm/subpage-prot.c|  8 ++--
>>   10 files changed, 91 insertions(+), 65 deletions(-)
>> 
>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h 
>> b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> index a28a28079edb..d801be977623 100644
>> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> @@ -657,7 +657,7 @@ extern void slb_set_size(u16 size);
>>   
>>   /* 4 bits per slice and we have one slice per 1TB */
>>   #define SLICE_ARRAY_SIZE   (H_PGTABLE_RANGE >> 41)
>> -#define TASK_SLICE_ARRAY_SZ(x)  ((x)->context.slb_addr_limit >> 41)
>> +#define TASK_SLICE_ARRAY_SZ(x)  
>> ((x)->context.hash_context->slb_addr_limit >> 41)
>>   
>>   #ifndef __ASSEMBLY__
>>   
>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
>> b/arch/powerpc/include/asm/book3s/64/mmu.h
>> index a809bdd77322..07e76e304a3b 100644
>> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
>> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
>> @@ -114,6 +114,33 @@ struct slice_mask {
>>  DECLARE_BITMAP(high_slices, SLICE_NUM_HIGH);
>>   };
>>   
>> +struct hash_mm_context {
>> +
>> +u16 user_psize; /* page size index */
> 
> Could we keep that in mm_context_t ?

Why do you want it there?


>> @@ -155,15 +155,15 @@ static struct slice_mask *slice_mask_for_size(struct 
>> mm_struct *mm, int psize)
>>   {
>>   #ifdef CONFIG_PPC_64K_PAGES
>>  if (psize == MMU_PAGE_64K)
>> -return >context.mask_64k;
>> +return >context.hash_context->mask_64k;
> 
> You should take the two patches below, that would help:
> https://patchwork.ozlabs.org/patch/1059056/
> https://patchwork.ozlabs.org/patch/1059058/

Above patches seem good I think. What I think Aneesh should have is
is a macro or inline that gives a pointer to the hash_mm_context from
an mm_context pointer.

Architectures which always want it should just put the hash struct
in their mm_context struct and that avoids the pointer overhead
completely.

Thanks,
Nick

Re: [PATCH] powerpc/watchdog: Use hrtimers for per-CPU heartbeat

[Nicholas Piggin]

Gautham R Shenoy's on April 4, 2019 9:19 pm:
> Hello Nicholas,
> 
> On Tue, Apr 2, 2019 at 4:57 PM Nicholas Piggin  wrote:
>>
>> Using a jiffies timer creates a dependency on the tick_do_timer_cpu
>> incrementing jiffies. If that CPU has locked up and jiffies is not
>> incrementing, the watchdog heartbeat timer for all CPUs stops and
>> creates false positives and confusing warnings on local CPUs, and
>> also causes the SMP detector to stop, so the root cause is never
>> detected.
>>
>> Fix this by using hrtimer based timers for the watchdog heartbeat,
>> like the generic kernel hardlockup detector.
>>
>> Reported-by: Ravikumar Bangoria 
>> Signed-off-by: Nicholas Piggin 
> 
> [..snip..]
> 
>> @@ -325,19 +325,21 @@ EXPORT_SYMBOL(arch_touch_nmi_watchdog);
>>
>>  static void start_watchdog_timer_on(unsigned int cpu)
>>  {
>> -   struct timer_list *t = per_cpu_ptr(_timer, cpu);
>> +   struct hrtimer *hrtimer = this_cpu_ptr(_hrtimer);
> 
> This function can be called during the initialization via
> 
> watchdog_nmi_start -->
> for_each_online_cpu(cpu)
>start_wd_on_cpu(cpu) -->
>start_watchdog_timer_on(cpu)
> 
> Thus, it is not guarateed that we are always calling
> start_watchdog_timer_on() from the CPU where
> we want to start the watchdog timer.
> 
> Thus, should we be calling this function from start_wd_on_cpu() via an
> smp_call_function_single() ?

Good catch, yes I think we need that change (like kernel/watchdog.c).

I'll resend.

Thanks,
Nick

Re: [PATCH v2] powerpc/vmlinux.lds: Drop binutils < 2.18 workarounds

[Christophe Leroy]

Le 04/04/2019 à 16:53, Segher Boessenkool a écrit :

Hi Joel,

On Thu, Apr 04, 2019 at 12:17:40PM +, Joel Stanley wrote:

On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
 wrote:

On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:

- NOTES :kernel :notes
+ NOTES


I think this still need to be

 NOTES :kernel

or the linker will complain.  Did you try to build ppc64_defconfig?


Yeah, I did build (and boot, in qemu) the ppc64_defconfig. I tried
leaving in/removing the :kernel annotation in a bunch of places and as
long as I had it in the first spot, the kernel linked.

Shall I respin with this added?


Yes please, if only so we are testing the exact same thing :-)

There may be a binutils version difference here.


(And I do not know if there are any tools that expect the notes in a phdr,
or even specifically the second phdr).


^^^ This question remains?


A few days ago while I was investigating 
https://github.com/linuxppc/issues/issues/208 , I had the feeling that 
QEMU expects some sort of NOTES section.


I didn't investigate further though.

Christophe

Re: [PATCH v2] powerpc/vmlinux.lds: Drop binutils < 2.18 workarounds

[Segher Boessenkool]

Hi Joel,

On Thu, Apr 04, 2019 at 12:17:40PM +, Joel Stanley wrote:
> On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
>  wrote:
> > On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
> > > - NOTES :kernel :notes
> > > + NOTES
> >
> > I think this still need to be
> >
> > NOTES :kernel
> >
> > or the linker will complain.  Did you try to build ppc64_defconfig?
> 
> Yeah, I did build (and boot, in qemu) the ppc64_defconfig. I tried
> leaving in/removing the :kernel annotation in a bunch of places and as
> long as I had it in the first spot, the kernel linked.
> 
> Shall I respin with this added?

Yes please, if only so we are testing the exact same thing :-)

There may be a binutils version difference here.

> > (And I do not know if there are any tools that expect the notes in a phdr,
> > or even specifically the second phdr).

^^^ This question remains?


Segher

VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

[Christian Zigotzky]

On 04 April 2019 at 1:23PM, Christian Zigotzky wrote:

On 04 April 2019 at 11:07AM, Christophe Leroy wrote:



On 04/04/2019 08:44 AM, Christian Zigotzky wrote:

On 04 April 2019 at 06:00AM, Christophe Leroy wrote:



Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :

On 03 April 2019 at 07:05AM, Christophe Leroy wrote:

Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :

Please test VLC with the RC3 of kernel 5.1.

The removing of the PowerPC fixes 5.1-3 has solved the VLC 
issue. Another user has already confirmed that [1]. This isn’t 
an April Fool‘s. ;-)


Could you bisect to identify the guilty commit ?

Thanks
Christophe



Thanks

[1] 
http://forum.hyperion-entertainment.com/viewtopic.php?f=58=4256=20#p47561 






Hello Christophe,

I have found the problematic patch. The following patch from the 
PowerPC fixes 5.1-3 is responsible for the VLC issue.


That change is part of the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.1-rc2=b5b4453e7912f056da1ca7572574cada32ecb60c 



Just changing back the type of wtom_clock_sec to 32 bits without 
changing back the loading instruction is likely to give unexpected 
results on PPC64.


Are you using 32 bits or 64 bits powerpc ?

Christophe

64-bit kernel + 32-bit userland for example:

- ubuntu MATE 16.04.6 LTS 32-bit PowerPC with a 64-bit kernel
- Fienix (Debian Sid) 32-bit PowerPC with a 64-bit kernel
- MATE PowerPC Remix (ubuntu MATE 17.04) 32-bit PowerPC with a 
64-bit kernel


Ok, thanks. Can you please try below change:

diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S 
b/arch/powerpc/kernel/vdso32/gettimeofday.S

index 1e0bc5955a40..afd516b572f8 100644
--- a/arch/powerpc/kernel/vdso32/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
@@ -98,7 +98,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
  * can be used, r7 contains NSEC_PER_SEC.
  */

-    lwz    r5,WTOM_CLOCK_SEC(r9)
+    lwz    r5,(WTOM_CLOCK_SEC+LOPART)(r9)
 lwz    r6,WTOM_CLOCK_NSEC(r9)

 /* We now have our offset in r5,r6. We create a fake dependency


Christophe


Hello Christophe,

Your patch works! VLC plays videos without any problems! Thank you!

Cheers,
Christian


Christophe,

I also successfully tested the VLC with the RC3 of kernel 5.1 with your 
patch on openSUSE Tumbleweed PPC64 (64-bit kernel + 64-bit userland) 
today. VLC works without any problems!


Screenshot: 
https://i.pinimg.com/originals/5e/d4/4b/5ed44b324a7ea2fc541185880e21c165.png


Many thanks for your help! :-)

Cheers,
Christian

[PATCH] ASoC: imx-pcm: Switch to SPDX identifier

[Andra Danciu]

Adopt the SPDX license identifier headers to ease license compliance
management.

Signed-off-by: Andra Danciu 
---
 sound/soc/fsl/imx-pcm.h | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index 133c4470acad..3ce2f437e645 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -1,13 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Copyright 2009 Sascha Hauer 
  *
  * This code is based on code copyrighted by Freescale,
  * Liam Girdwood, Javier Martin and probably others.
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
  */
 
 #ifndef _IMX_PCM_H
-- 
2.11.0

[PATCH] ASoC: imx-pcm-dma: Switch to SPDX identifier

[Andra Danciu]

Adopt the SPDX license identifier headers to ease license compliance
management.

Signed-off-by: Andra Danciu 
---
 sound/soc/fsl/imx-pcm-dma.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
index 314814ddd2b0..6c495761f33c 100644
--- a/sound/soc/fsl/imx-pcm-dma.c
+++ b/sound/soc/fsl/imx-pcm-dma.c
@@ -1,16 +1,12 @@
-/*
- * imx-pcm-dma-mx2.c  --  ALSA Soc Audio Layer
- *
- * Copyright 2009 Sascha Hauer 
- *
- * This code is based on code copyrighted by Freescale,
- * Liam Girdwood, Javier Martin and probably others.
- *
- *  This program is free software; you can redistribute  it and/or modify it
- *  under  the terms of  the GNU General  Public License as published by the
- *  Free Software Foundation;  either version 2 of the  License, or (at your
- *  option) any later version.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// imx-pcm-dma-mx2.c  --  ALSA Soc Audio Layer
+//
+// Copyright 2009 Sascha Hauer 
+//
+// This code is based on code copyrighted by Freescale,
+// Liam Girdwood, Javier Martin and probably others.
+
 #include 
 #include 
 #include 
-- 
2.11.0

[PATCH] powerpc/vdso32: fix CLOCK_MONOTONIC on PPC64

[Christophe Leroy]

Commit b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC
inconsistencies across Y2038") changed the type of wtom_clock_sec
to s64 on PPC64. Therefore, VDSO32 needs to read it with a 4 bytes
shift in order to retrieve the lower part of it.

Fixes: b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies 
across Y2038")
Reported-by: Christian Zigotzky 
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/vdso32/gettimeofday.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S 
b/arch/powerpc/kernel/vdso32/gettimeofday.S
index 1e0bc5955a40..afd516b572f8 100644
--- a/arch/powerpc/kernel/vdso32/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
@@ -98,7 +98,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
 * can be used, r7 contains NSEC_PER_SEC.
 */
 
-   lwz r5,WTOM_CLOCK_SEC(r9)
+   lwz r5,(WTOM_CLOCK_SEC+LOPART)(r9)
lwz r6,WTOM_CLOCK_NSEC(r9)
 
/* We now have our offset in r5,r6. We create a fake dependency
-- 
2.13.3

Re: [PATCH v2] powerpc/vmlinux.lds: Drop binutils < 2.18 workarounds

[Joel Stanley]

On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
 wrote:
>
> Hi!
>
> On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
> > - NOTES :kernel :notes
> > + NOTES
>
> I think this still need to be
>
> NOTES :kernel
>
> or the linker will complain.  Did you try to build ppc64_defconfig?

Yeah, I did build (and boot, in qemu) the ppc64_defconfig. I tried
leaving in/removing the :kernel annotation in a bunch of places and as
long as I had it in the first spot, the kernel linked.

Shall I respin with this added?

> (And I do not know if there are any tools that expect the notes in a phdr,
> or even specifically the second phdr).
>
>
> Segher

Re: [PATCH] ASoC: imx-pcm: Switch to SPDX identifier

[Fabio Estevam]

On Thu, Apr 4, 2019 at 9:07 AM Andra Danciu  wrote:
>
> Adopt the SPDX license identifier headers to ease license compliance
> management.
>
> Signed-off-by: Andra Danciu 
> ---
>  sound/soc/fsl/imx-pcm.h | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
> index 133c4470acad..3ce2f437e645 100644
> --- a/sound/soc/fsl/imx-pcm.h
> +++ b/sound/soc/fsl/imx-pcm.h
> @@ -1,13 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

This is not correct...

>  /*
>   * Copyright 2009 Sascha Hauer 
>   *
>   * This code is based on code copyrighted by Freescale,
>   * Liam Girdwood, Javier Martin and probably others.
> - *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.

as it does not match with the original license text.

You should use:

/* SPDX-License-Identifier: GPL-2.0+ */

[PATCH 2/2] powerpc/perf: Add generic compat mode pmu driver

[Madhavan Srinivasan]

Most of the power processor generation performance monitoring
unit (PMU) driver code is bundled in the kernel and one of those
is enabled/registered based on the oprofile_cpu_type check at
the boot.

But things get little tricky incase of "compat" mode boot.
IBM POWER System Server based processors has a compactibility
mode feature, which simpily put is, Nth generation processor
(lets say POWER8) will act and appear in a mode consistent
with an earlier generation (N-1) processor (that is POWER7).
And in this "compat" mode boot, kernel modify the
"oprofile_cpu_type" to be Nth generation (POWER8). If Nth
generation pmu driver is bundled (POWER8), it gets registered.

Key dependency here is to have distro support for latest
processor performance monitoring support. Patch here adds
a generic "compat-mode" performance monitoring driver to
be register in absence of powernv platform specific pmu driver.

Driver supports only "cycles" and "instruction" events.
"0x0001e" used as event code for "cycles" and "0x2"
used as event code for "instruction" events. New file
called "generic-compat-pmu.c" is created to contain the driver
specific code. And base raw event code format modeled
on PPMU_ARCH_207S.

Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/Makefile |   3 +-
 arch/powerpc/perf/core-book3s.c|   2 +-
 arch/powerpc/perf/generic-compat-pmu.c | 241 +
 arch/powerpc/perf/internal.h   |   1 +
 4 files changed, 245 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/perf/generic-compat-pmu.c

diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index ab26df5bacb9..c155dcbb8691 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -5,7 +5,8 @@ obj-$(CONFIG_PERF_EVENTS)   += callchain.o perf_regs.o
 obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o bhrb.o
 obj64-$(CONFIG_PPC_PERF_CTRS)  += ppc970-pmu.o power5-pmu.o \
   power5+-pmu.o power6-pmu.o power7-pmu.o \
-  isa207-common.o power8-pmu.o power9-pmu.o
+  isa207-common.o power8-pmu.o power9-pmu.o \
+  generic-compat-pmu.o
 obj32-$(CONFIG_PPC_PERF_CTRS)  += mpc7450-pmu.o
 
 obj-$(CONFIG_PPC_POWERNV)  += imc-pmu.o
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index a96f9420139c..a66fb9c01c9e 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2318,7 +2318,7 @@ static int __init init_ppc64_pmu(void)
else if (!init_ppc970_pmu())
return 0;
else
-   return -ENODEV;
+   return init_generic_compat_pmu();
 }
 early_initcall(init_ppc64_pmu);
 #endif
diff --git a/arch/powerpc/perf/generic-compat-pmu.c 
b/arch/powerpc/perf/generic-compat-pmu.c
new file mode 100644
index ..5981ef742648
--- /dev/null
+++ b/arch/powerpc/perf/generic-compat-pmu.c
@@ -0,0 +1,241 @@
+/*
+ * Performance counter support.
+ *
+ * Copyright 2019 Madhavan Srinivasan, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or later version.
+ */
+
+#define pr_fmt(fmt)"generic-compat-pmu: " fmt
+
+#include "isa207-common.h"
+
+/*
+ * Raw event encoding:
+ *
+ *60565248444036   
 32
+ * | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - 
- - |
+ *
+ *2824201612 8 4   
  0
+ * | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - 
- - |
+ * [ pmc ]   [unit ]   [ ]   m   [pmcxsel  
  ]
+ * | |
+ * | *- mark
+ * |
+ * |
+ * *- combine
+ *
+ * Below uses IBM bit numbering.
+ *
+ * MMCR1[x:y] = unit(PMCxUNIT)
+ * MMCR1[24]   = pmc1combine[0]
+ * MMCR1[25]   = pmc1combine[1]
+ * MMCR1[26]   = pmc2combine[0]
+ * MMCR1[27]   = pmc2combine[1]
+ * MMCR1[28]   = pmc3combine[0]
+ * MMCR1[29]   = pmc3combine[1]
+ * MMCR1[30]   = pmc4combine[0]
+ * MMCR1[31]   = pmc4combine[1]
+ *
+ */
+
+/*
+ * Some power9 event codes.
+ */
+#define EVENT(_name, _code)_name = _code,
+
+enum {
+EVENT(PM_CYC,  0x0001e)
+EVENT(PM_INST_CMPL,0x2)
+};
+
+#undef EVENT
+
+GENERIC_EVENT_ATTR(cpu-cycles, PM_CYC);
+GENERIC_EVENT_ATTR(instructions,   PM_INST_CMPL);
+
+static struct attribute *generic_compat_events_attr[] 

[PATCH v2 1/2] powerpc/perf: init pmu from core-book3s

[Madhavan Srinivasan]

Currenty pmu driver file for each ppc64 generation processor
has a __init call in itself. Refactor the code by moving the
__init call to core-books.c. This also clean's up compat mode
pmu driver registration.

Suggested-by: Michael Ellerman 
Signed-off-by: Madhavan Srinivasan 
---
Changelog v1:
- Added "internal.h" file and moved the extern definitions to that file

 arch/powerpc/perf/core-book3s.c | 28 
 arch/powerpc/perf/internal.h| 16 
 arch/powerpc/perf/power5+-pmu.c |  4 +---
 arch/powerpc/perf/power5-pmu.c  |  4 +---
 arch/powerpc/perf/power6-pmu.c  |  4 +---
 arch/powerpc/perf/power7-pmu.c  |  4 +---
 arch/powerpc/perf/power8-pmu.c  |  3 +--
 arch/powerpc/perf/power9-pmu.c  |  3 +--
 arch/powerpc/perf/ppc970-pmu.c  |  4 +---
 9 files changed, 51 insertions(+), 19 deletions(-)
 create mode 100644 arch/powerpc/perf/internal.h

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index b0723002a396..a96f9420139c 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -22,6 +22,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_PPC64
+#include "internal.h"
+#endif
+
 #define BHRB_MAX_ENTRIES   32
 #define BHRB_TARGET0x0002
 #define BHRB_PREDICTION0x0001
@@ -2294,3 +2298,27 @@ int register_power_pmu(struct power_pmu *pmu)
  power_pmu_prepare_cpu, NULL);
return 0;
 }
+
+#ifdef CONFIG_PPC64
+static int __init init_ppc64_pmu(void)
+{
+   /* run through all the pmu drivers one at a time */
+   if (!init_power5_pmu())
+   return 0;
+   else if (!init_power5p_pmu())
+   return 0;
+   else if (!init_power6_pmu())
+   return 0;
+   else if (!init_power7_pmu())
+   return 0;
+   else if (!init_power8_pmu())
+   return 0;
+   else if (!init_power9_pmu())
+   return 0;
+   else if (!init_ppc970_pmu())
+   return 0;
+   else
+   return -ENODEV;
+}
+early_initcall(init_ppc64_pmu);
+#endif
diff --git a/arch/powerpc/perf/internal.h b/arch/powerpc/perf/internal.h
new file mode 100644
index ..e54d524d4283
--- /dev/null
+++ b/arch/powerpc/perf/internal.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright 2019 Madhavan Srinivasan, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+extern int init_ppc970_pmu(void);
+extern int init_power5_pmu(void);
+extern int init_power5p_pmu(void);
+extern int init_power6_pmu(void);
+extern int init_power7_pmu(void);
+extern int init_power8_pmu(void);
+extern int init_power9_pmu(void);
diff --git a/arch/powerpc/perf/power5+-pmu.c b/arch/powerpc/perf/power5+-pmu.c
index 0526dac66007..9aa803504cb2 100644
--- a/arch/powerpc/perf/power5+-pmu.c
+++ b/arch/powerpc/perf/power5+-pmu.c
@@ -677,7 +677,7 @@ static struct power_pmu power5p_pmu = {
.cache_events   = _cache_events,
 };
 
-static int __init init_power5p_pmu(void)
+int init_power5p_pmu(void)
 {
if (!cur_cpu_spec->oprofile_cpu_type ||
(strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power5+")
@@ -686,5 +686,3 @@ static int __init init_power5p_pmu(void)
 
return register_power_pmu(_pmu);
 }
-
-early_initcall(init_power5p_pmu);
diff --git a/arch/powerpc/perf/power5-pmu.c b/arch/powerpc/perf/power5-pmu.c
index 4dc99f9f7962..30cb13d081a9 100644
--- a/arch/powerpc/perf/power5-pmu.c
+++ b/arch/powerpc/perf/power5-pmu.c
@@ -618,7 +618,7 @@ static struct power_pmu power5_pmu = {
.flags  = PPMU_HAS_SSLOT,
 };
 
-static int __init init_power5_pmu(void)
+int init_power5_pmu(void)
 {
if (!cur_cpu_spec->oprofile_cpu_type ||
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power5"))
@@ -626,5 +626,3 @@ static int __init init_power5_pmu(void)
 
return register_power_pmu(_pmu);
 }
-
-early_initcall(init_power5_pmu);
diff --git a/arch/powerpc/perf/power6-pmu.c b/arch/powerpc/perf/power6-pmu.c
index 9c9d646b68a1..80ec48632cfe 100644
--- a/arch/powerpc/perf/power6-pmu.c
+++ b/arch/powerpc/perf/power6-pmu.c
@@ -540,7 +540,7 @@ static struct power_pmu power6_pmu = {
.cache_events   = _cache_events,
 };
 
-static int __init init_power6_pmu(void)
+int init_power6_pmu(void)
 {
if (!cur_cpu_spec->oprofile_cpu_type ||
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power6"))
@@ -548,5 +548,3 @@ static int __init init_power6_pmu(void)
 
return register_power_pmu(_pmu);
 }
-
-early_initcall(init_power6_pmu);
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 6dbae9884ec4..bb6efd5d2530 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ 

VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

[Christian Zigotzky]

On 04 April 2019 at 11:07AM, Christophe Leroy wrote:



On 04/04/2019 08:44 AM, Christian Zigotzky wrote:

On 04 April 2019 at 06:00AM, Christophe Leroy wrote:



Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :

On 03 April 2019 at 07:05AM, Christophe Leroy wrote:

Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :

Please test VLC with the RC3 of kernel 5.1.

The removing of the PowerPC fixes 5.1-3 has solved the VLC issue. 
Another user has already confirmed that [1]. This isn’t an April 
Fool‘s. ;-)


Could you bisect to identify the guilty commit ?

Thanks
Christophe



Thanks

[1] 
http://forum.hyperion-entertainment.com/viewtopic.php?f=58=4256=20#p47561 






Hello Christophe,

I have found the problematic patch. The following patch from the 
PowerPC fixes 5.1-3 is responsible for the VLC issue.


That change is part of the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.1-rc2=b5b4453e7912f056da1ca7572574cada32ecb60c 



Just changing back the type of wtom_clock_sec to 32 bits without 
changing back the loading instruction is likely to give unexpected 
results on PPC64.


Are you using 32 bits or 64 bits powerpc ?

Christophe

64-bit kernel + 32-bit userland for example:

- ubuntu MATE 16.04.6 LTS 32-bit PowerPC with a 64-bit kernel
- Fienix (Debian Sid) 32-bit PowerPC with a 64-bit kernel
- MATE PowerPC Remix (ubuntu MATE 17.04) 32-bit PowerPC with a 64-bit 
kernel


Ok, thanks. Can you please try below change:

diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S 
b/arch/powerpc/kernel/vdso32/gettimeofday.S

index 1e0bc5955a40..afd516b572f8 100644
--- a/arch/powerpc/kernel/vdso32/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
@@ -98,7 +98,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
  * can be used, r7 contains NSEC_PER_SEC.
  */

-    lwz    r5,WTOM_CLOCK_SEC(r9)
+    lwz    r5,(WTOM_CLOCK_SEC+LOPART)(r9)
 lwz    r6,WTOM_CLOCK_NSEC(r9)

 /* We now have our offset in r5,r6. We create a fake dependency


Christophe


Hello Christophe,

Your patch works! VLC plays videos without any problems! Thank you!

Cheers,
Christian

Re: [PATCH] powerpc/watchdog: Use hrtimers for per-CPU heartbeat

[Gautham R Shenoy]

Hello Nicholas,

On Tue, Apr 2, 2019 at 4:57 PM Nicholas Piggin  wrote:
>
> Using a jiffies timer creates a dependency on the tick_do_timer_cpu
> incrementing jiffies. If that CPU has locked up and jiffies is not
> incrementing, the watchdog heartbeat timer for all CPUs stops and
> creates false positives and confusing warnings on local CPUs, and
> also causes the SMP detector to stop, so the root cause is never
> detected.
>
> Fix this by using hrtimer based timers for the watchdog heartbeat,
> like the generic kernel hardlockup detector.
>
> Reported-by: Ravikumar Bangoria 
> Signed-off-by: Nicholas Piggin 

[..snip..]

> @@ -325,19 +325,21 @@ EXPORT_SYMBOL(arch_touch_nmi_watchdog);
>
>  static void start_watchdog_timer_on(unsigned int cpu)
>  {
> -   struct timer_list *t = per_cpu_ptr(_timer, cpu);
> +   struct hrtimer *hrtimer = this_cpu_ptr(_hrtimer);

This function can be called during the initialization via

watchdog_nmi_start -->
for_each_online_cpu(cpu)
   start_wd_on_cpu(cpu) -->
   start_watchdog_timer_on(cpu)

Thus, it is not guarateed that we are always calling
start_watchdog_timer_on() from the CPU where
we want to start the watchdog timer.

Thus, should we be calling this function from start_wd_on_cpu() via an
smp_call_function_single() ?


>
> per_cpu(wd_timer_tb, cpu) = get_tb();
>
> -   timer_setup(t, wd_timer_fn, TIMER_PINNED);
> -   wd_timer_reset(cpu, t);
> +   hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> +   hrtimer->function = watchdog_timer_fn;
> +   hrtimer_start(hrtimer, ms_to_ktime(wd_timer_period_ms),
> + HRTIMER_MODE_REL_PINNED);
>  }
>
>  static void stop_watchdog_timer_on(unsigned int cpu)
>  {
> -   struct timer_list *t = per_cpu_ptr(_timer, cpu);
> +   struct hrtimer *hrtimer = this_cpu_ptr(_hrtimer);
>
> -   del_timer_sync(t);
> +   hrtimer_cancel(hrtimer);
>  }
>
>  static int start_wd_on_cpu(unsigned int cpu)
> --
> 2.20.1
>


-- 
Thanks and Regards
gautham.

Re: [PATCH 1/2] cpuidle : auto-promotion for cpuidle states

[Abhishek]

On 04/04/2019 03:51 PM, Daniel Lezcano wrote:

Hi Abhishek,

thanks for taking the time to test the different scenario and give us
the numbers.

On 01/04/2019 07:11, Abhishek wrote:


On 03/22/2019 06:56 PM, Daniel Lezcano wrote:

On 22/03/2019 10:45, Rafael J. Wysocki wrote:

On Fri, Mar 22, 2019 at 8:31 AM Abhishek Goel
 wrote:

Currently, the cpuidle governors (menu /ladder) determine what idle
state
an idling CPU should enter into based on heuristics that depend on the
idle history on that CPU. Given that no predictive heuristic is
perfect,
there are cases where the governor predicts a shallow idle state,
hoping
that the CPU will be busy soon. However, if no new workload is
scheduled
on that CPU in the near future, the CPU will end up in the shallow
state.

In case of POWER, this is problematic, when the predicted state in the
aforementioned scenario is a lite stop state, as such lite states will
inhibit SMT folding, thereby depriving the other threads in the core
from
using the core resources.

I can understand an idle state can prevent other threads to use the core
resources. But why a deeper idle state does not prevent this also?



To address this, such lite states need to be autopromoted. The cpuidle-
core can queue timer to correspond with the residency value of the next
available state. Thus leading to auto-promotion to a deeper idle
state as
soon as possible.

Isn't the tick stopping avoidance sufficient for that?

I was about to ask the same :)





Thanks for the review.
I performed experiments for three scenarios to collect some data.

case 1 :
Without this patch and without tick retained, i.e. in a upstream kernel,
It would spend more than even a second to get out of stop0_lite.

case 2 : With tick retained(as suggested) -

Generally, we have a sched tick at 4ms(CONF_HZ = 250). Ideally I expected
it to take 8 sched tick to get out of stop0_lite. Experimentally,
observation was

===
min            max            99percentile
4ms            12ms          4ms
===
*ms = milliseconds

It would take atleast one sched tick to get out of stop0_lite.

case 2 :  With this patch (not stopping tick, but explicitly queuing a
timer)

min            max              99.5percentile
===
144us       192us              144us
===
*us = microseconds

In this patch, we queue a timer just before entering into a stop0_lite
state. The timer fires at (residency of next available state + exit
latency of next available state * 2).

So for the context, we have a similar issue but from the power
management point of view where a CPU can stay in a shallow state for a
long period, thus consuming a lot of energy.

The window was reduced by preventing stopping the tick when a shallow
state is selected. Unfortunately, if the tick is stopped and we
exit/enter again and we select a shallow state, the situation is the same.

A solution was previously proposed with a timer some years ago, like
this patch does, and merged but there were complains about bad
performance impact, so it has been reverted.


Let's say if next state(stop0) is available which has residency of 20us, it
should get out in as low as (20+2*2)*8 [Based on the forumla (residency +
2xlatency)*history length] microseconds = 192us. Ideally we would expect 8
iterations, it was observed to get out in 6-7 iterations.

Can you explain the formula? I don't get the rational. Why using the
exit latency and why multiply it by 2?

Why the timer is not set to the next state's target residency value ?

The idea behind multiplying by 2 is, entry latency + exit latency = 2* 
exit latency, i.e.,

using exit latency = entry latency
So in effect, we are using target residency + 2 * exit latency for 
timeout of timer.
Latency is generally <=10% of residency. I have tried to be conservative 
by including latency
factor in computation for timeout. Thus, this formula will give slightly 
greater value compared

to directly using residency of target state.

--Abhishek

Re: [PATCH 1/2] cpuidle : auto-promotion for cpuidle states

[Gautham R Shenoy]

Hello Daniel,

On Thu, Apr 4, 2019 at 3:52 PM Daniel Lezcano  wrote:
>
>
> Hi Abhishek,
>
> thanks for taking the time to test the different scenario and give us
> the numbers.
>
> On 01/04/2019 07:11, Abhishek wrote:
> >

[.. snip..]

>
>  In case of POWER, this is problematic, when the predicted state in the
>  aforementioned scenario is a lite stop state, as such lite states will
>  inhibit SMT folding, thereby depriving the other threads in the core
>  from
>  using the core resources.
>
> I can understand an idle state can prevent other threads to use the core
> resources. But why a deeper idle state does not prevent this also?

On POWER9, we have the following classes of platform idle states
(called stop states)

lite: These do not lose any context including the user context. In
this state
   GPRs are also preserved (stop0_lite)

shallow : These lose user context,but not the hypervisor context. So
GPRs are lost but
   not SPRs. (stop0, stop1, stop2)

deep: These lose hypervisor context. (stop4, stop5)

In the case of lite stop state, only instruction dispatch on the CPU thread
is paused. The thread does not  give up its registers set in this state for the
use of its busy sibling threads in the core.  Hence, SMT folding does not
happen in this state.

With respect to shallow and deep states, not only is the instruction dispatch
paused, it also gives up its registers set for the other siblings to use
These stop states are beneficial for SMT folding.

Hence, if a CPU thread remains in a lite state for too long,
its siblings in the core would not be able to utilize the full resources
of the core for that duration, thereby inhibiting single
thread performance. This is not the case with non-lite states.

-- 
Thanks and Regards
gautham.

Re: [PATCH 1/2] cpuidle : auto-promotion for cpuidle states

[Daniel Lezcano]

Hi Abhishek,

thanks for taking the time to test the different scenario and give us
the numbers.

On 01/04/2019 07:11, Abhishek wrote:
> 
> 
> On 03/22/2019 06:56 PM, Daniel Lezcano wrote:
>> On 22/03/2019 10:45, Rafael J. Wysocki wrote:
>>> On Fri, Mar 22, 2019 at 8:31 AM Abhishek Goel
>>>  wrote:
 Currently, the cpuidle governors (menu /ladder) determine what idle
 state
 an idling CPU should enter into based on heuristics that depend on the
 idle history on that CPU. Given that no predictive heuristic is
 perfect,
 there are cases where the governor predicts a shallow idle state,
 hoping
 that the CPU will be busy soon. However, if no new workload is
 scheduled
 on that CPU in the near future, the CPU will end up in the shallow
 state.

 In case of POWER, this is problematic, when the predicted state in the
 aforementioned scenario is a lite stop state, as such lite states will
 inhibit SMT folding, thereby depriving the other threads in the core
 from
 using the core resources.

I can understand an idle state can prevent other threads to use the core
resources. But why a deeper idle state does not prevent this also?


 To address this, such lite states need to be autopromoted. The cpuidle-
 core can queue timer to correspond with the residency value of the next
 available state. Thus leading to auto-promotion to a deeper idle
 state as
 soon as possible.
>>> Isn't the tick stopping avoidance sufficient for that?
>> I was about to ask the same :)
>>
>>
>>
>>
> Thanks for the review.
> I performed experiments for three scenarios to collect some data.
> 
> case 1 :
> Without this patch and without tick retained, i.e. in a upstream kernel,
> It would spend more than even a second to get out of stop0_lite.
> 
> case 2 : With tick retained(as suggested) -
> 
> Generally, we have a sched tick at 4ms(CONF_HZ = 250). Ideally I expected
> it to take 8 sched tick to get out of stop0_lite. Experimentally,
> observation was
> 
> ===
> min            max            99percentile
> 4ms            12ms          4ms
> ===
> *ms = milliseconds
> 
> It would take atleast one sched tick to get out of stop0_lite.
> 
> case 2 :  With this patch (not stopping tick, but explicitly queuing a
> timer)
> 
> min            max              99.5percentile
> ===
> 144us       192us              144us
> ===
> *us = microseconds
> 
> In this patch, we queue a timer just before entering into a stop0_lite
> state. The timer fires at (residency of next available state + exit
> latency of next available state * 2).

So for the context, we have a similar issue but from the power
management point of view where a CPU can stay in a shallow state for a
long period, thus consuming a lot of energy.

The window was reduced by preventing stopping the tick when a shallow
state is selected. Unfortunately, if the tick is stopped and we
exit/enter again and we select a shallow state, the situation is the same.

A solution was previously proposed with a timer some years ago, like
this patch does, and merged but there were complains about bad
performance impact, so it has been reverted.

> Let's say if next state(stop0) is available which has residency of 20us, it
> should get out in as low as (20+2*2)*8 [Based on the forumla (residency +
> 2xlatency)*history length] microseconds = 192us. Ideally we would expect 8
> iterations, it was observed to get out in 6-7 iterations.

Can you explain the formula? I don't get the rational. Why using the
exit latency and why multiply it by 2?

Why the timer is not set to the next state's target residency value ?

> Even if let's say stop2 is next available state(stop0 and stop1 both are
> unavailable), it would take (100+2*10)*8 = 960us to get into stop2.
> 
> So, We are able to get out of stop0_lite generally in 150us(with this
> patch) as
> compared to 4ms(with tick retained). As stated earlier, we do not want
> to get
> stuck into stop0_lite as it inhibits SMT folding for other sibling
> threads, depriving
> them of core resources. Current patch is using auto-promotion only for
> stop0_lite,
> as it gives performance benefit(primary reason) along with lowering down
> power
> consumption. We may extend this model for other states in future.
> 
> --Abhishek
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH V3] ASoC: fsl_esai: Support synchronous mode

[S.j. Wang]

In ESAI synchronous mode, the clock is generated by Tx, So
we should always set registers of Tx which relate with the
bit clock and frame clock generation (TCCR, TCR, ECR), even
there is only Rx is working.

Signed-off-by: Shengjiu Wang 
Acked-by: Nicolin Chen 
---
Changes in v3
- fix the indentation

 sound/soc/fsl/fsl_esai.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 3623aa9a6f2e..c7410bbfd2af 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -218,7 +218,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, 
int clk_id,
 {
struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
struct clk *clksrc = esai_priv->extalclk;
-   bool tx = clk_id <= ESAI_HCKT_EXTAL;
+   bool tx = (clk_id <= ESAI_HCKT_EXTAL || esai_priv->synchronous);
bool in = dir == SND_SOC_CLOCK_IN;
u32 ratio, ecr = 0;
unsigned long clk_rate;
@@ -253,7 +253,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, 
int clk_id,
ecr |= ESAI_ECR_ETI;
/* fall through */
case ESAI_HCKR_EXTAL:
-   ecr |= ESAI_ECR_ERI;
+   ecr |= esai_priv->synchronous ? ESAI_ECR_ETI : ESAI_ECR_ERI;
break;
default:
return -EINVAL;
@@ -537,10 +537,18 @@ static int fsl_esai_hw_params(struct snd_pcm_substream 
*substream,
 
bclk = params_rate(params) * slot_width * esai_priv->slots;
 
-   ret = fsl_esai_set_bclk(dai, tx, bclk);
+   ret = fsl_esai_set_bclk(dai, esai_priv->synchronous || tx, bclk);
if (ret)
return ret;
 
+   mask = ESAI_xCR_xSWS_MASK;
+   val = ESAI_xCR_xSWS(slot_width, width);
+
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask, val);
+   /* Recording in synchronous mode needs to set TCR also */
+   if (!tx && esai_priv->synchronous)
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR, mask, val);
+
/* Use Normal mode to support monaural audio */
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
   ESAI_xCR_xMOD_MASK, params_channels(params) > 1 ?
@@ -556,10 +564,9 @@ static int fsl_esai_hw_params(struct snd_pcm_substream 
*substream,
 
regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx), mask, val);
 
-   mask = ESAI_xCR_xSWS_MASK | (tx ? ESAI_xCR_PADC : 0);
-   val = ESAI_xCR_xSWS(slot_width, width) | (tx ? ESAI_xCR_PADC : 0);
-
-   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask, val);
+   if (tx)
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
+   ESAI_xCR_PADC, ESAI_xCR_PADC);
 
/* Remove ESAI personal reset by configuring ESAI_PCRC and ESAI_PRRC */
regmap_update_bits(esai_priv->regmap, REG_ESAI_PRRC,
-- 
1.9.1

[PATCH 5.0 173/246] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe

[Greg Kroah-Hartman]

5.0-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Signed-off-by: Wen Yang 
Cc: Timur Tabi 
Cc: Nicolin Chen 
Cc: Xiubo Li 
Cc: Fabio Estevam 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 81f2fe2c6d23..60f87a0d99f4 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 asrc_fail:
of_node_put(asrc_np);
of_node_put(codec_np);
+   put_device(_pdev->dev);
 fail:
of_node_put(cpu_np);
 
-- 
2.19.1

[PATCH 5.0 111/246] SoC: imx-sgtl5000: add missing put_device()

[Greg Kroah-Hartman]

5.0-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.

Signed-off-by: Wen Yang 
Cc: Timur Tabi 
Cc: Nicolin Chen 
Cc: Xiubo Li 
Cc: Fabio Estevam 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: NXP Linux Team 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/imx-sgtl5000.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index c29200cf755a..9b9a7ec52905 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -108,6 +108,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
ret = -EPROBE_DEFER;
goto fail;
}
+   put_device(_pdev->dev);
codec_dev = of_find_i2c_device_by_node(codec_np);
if (!codec_dev) {
dev_err(>dev, "failed to find codec platform device\n");
-- 
2.19.1

[PATCH 5.0 057/246] mm/resource: Return real error codes from walk failures

[Greg Kroah-Hartman]

5.0-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 5cd401ace914dc68556c6d2fcae0c349444d5f86 ]

walk_system_ram_range() can return an error code either becuase
*it* failed, or because the 'func' that it calls returned an
error.  The memory hotplug does the following:

ret = walk_system_ram_range(..., func);
if (ret)
return ret;

and 'ret' makes it out to userspace, eventually.  The problem
s, walk_system_ram_range() failues that result from *it* failing
(as opposed to 'func') return -1.  That leads to a very odd
-EPERM (-1) return code out to userspace.

Make walk_system_ram_range() return -EINVAL for internal
failures to keep userspace less confused.

This return code is compatible with all the callers that I
audited.

Signed-off-by: Dave Hansen 
Reviewed-by: Bjorn Helgaas 
Acked-by: Michael Ellerman  (powerpc)
Cc: Dan Williams 
Cc: Dave Jiang 
Cc: Ross Zwisler 
Cc: Vishal Verma 
Cc: Tom Lendacky 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: linux-nvd...@lists.01.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kvack.org
Cc: Huang Ying 
Cc: Fengguang Wu 
Cc: Borislav Petkov 
Cc: Yaowei Bai 
Cc: Takashi Iwai 
Cc: Jerome Glisse 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Keith Busch 
Signed-off-by: Dan Williams 
Signed-off-by: Sasha Levin 
---
 kernel/resource.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 915c02e8e5dd..ca7ed5158cff 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -382,7 +382,7 @@ static int __walk_iomem_res_desc(resource_size_t start, 
resource_size_t end,
 int (*func)(struct resource *, void *))
 {
struct resource res;
-   int ret = -1;
+   int ret = -EINVAL;
 
while (start < end &&
   !find_next_iomem_res(start, end, flags, desc, first_lvl, )) {
@@ -462,7 +462,7 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned 
long nr_pages,
unsigned long flags;
struct resource res;
unsigned long pfn, end_pfn;
-   int ret = -1;
+   int ret = -EINVAL;
 
start = (u64) start_pfn << PAGE_SHIFT;
end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
-- 
2.19.1

Re: VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

[Christophe Leroy]

On 04/04/2019 08:44 AM, Christian Zigotzky wrote:

On 04 April 2019 at 06:00AM, Christophe Leroy wrote:



Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :

On 03 April 2019 at 07:05AM, Christophe Leroy wrote:

Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :

Please test VLC with the RC3 of kernel 5.1.

The removing of the PowerPC fixes 5.1-3 has solved the VLC issue. 
Another user has already confirmed that [1]. This isn’t an April 
Fool‘s. ;-)


Could you bisect to identify the guilty commit ?

Thanks
Christophe



Thanks

[1] 
http://forum.hyperion-entertainment.com/viewtopic.php?f=58=4256=20#p47561 






Hello Christophe,

I have found the problematic patch. The following patch from the 
PowerPC fixes 5.1-3 is responsible for the VLC issue.


That change is part of the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.1-rc2=b5b4453e7912f056da1ca7572574cada32ecb60c 



Just changing back the type of wtom_clock_sec to 32 bits without 
changing back the loading instruction is likely to give unexpected 
results on PPC64.


Are you using 32 bits or 64 bits powerpc ?

Christophe

64-bit kernel + 32-bit userland for example:

- ubuntu MATE 16.04.6 LTS 32-bit PowerPC with a 64-bit kernel
- Fienix (Debian Sid) 32-bit PowerPC with a 64-bit kernel
- MATE PowerPC Remix (ubuntu MATE 17.04) 32-bit PowerPC with a 64-bit 
kernel


Ok, thanks. Can you please try below change:

diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S 
b/arch/powerpc/kernel/vdso32/gettimeofday.S

index 1e0bc5955a40..afd516b572f8 100644
--- a/arch/powerpc/kernel/vdso32/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
@@ -98,7 +98,7 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
 * can be used, r7 contains NSEC_PER_SEC.
 */

-   lwz r5,WTOM_CLOCK_SEC(r9)
+   lwz r5,(WTOM_CLOCK_SEC+LOPART)(r9)
lwz r6,WTOM_CLOCK_NSEC(r9)

/* We now have our offset in r5,r6. We create a fake dependency


Christophe



-- Christian





diff --git a/arch/powerpc/include/asm/vdso_datapage.h 
b/arch/powerpc/include/asm/vdso_datapage.h

index 1afe90ade595..bbc06bd72b1f 100644
--- a/arch/powerpc/include/asm/vdso_datapage.h
+++ b/arch/powerpc/include/asm/vdso_datapage.h
@@ -82,10 +82,10 @@ struct vdso_data {
 __u32 icache_block_size;  /* L1 i-cache block size */
 __u32 dcache_log_block_size;  /* L1 d-cache log block size */
 __u32 icache_log_block_size;  /* L1 i-cache log block size */
-   __s32 wtom_clock_sec; /* Wall to monotonic clock */
-   __s32 wtom_clock_nsec;
-   struct timespec stamp_xtime;   /* xtime as at tb_orig_stamp */
-   __u32 stamp_sec_fraction;   /* fractional seconds of stamp_xtime */
+   __u32 stamp_sec_fraction;  /* fractional seconds of 
stamp_xtime */

+   __s32 wtom_clock_nsec; /* Wall to monotonic clock nsec */
+   __s64 wtom_clock_sec; /* Wall to monotonic clock sec */
+   struct timespec stamp_xtime;  /* xtime as at tb_orig_stamp */
    __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
    __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
  };

-

Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/include/asm/vdso_datapage.h?h=v5.1-rc2=a5ed1e96cafde5ba48638f486bfca0685dc6ddc9 



I created a patch for solving the VLC issue today.

vdso_datapage_vlc.patch:

diff -rupN a/arch/powerpc/include/asm/vdso_datapage.h 
b/arch/powerpc/include/asm/vdso_datapage.h
--- a/arch/powerpc/include/asm/vdso_datapage.h  2019-04-03 
22:56:44.560645936 +0200
+++ b/arch/powerpc/include/asm/vdso_datapage.h  2019-04-04 
02:20:09.479361827 +0200

@@ -82,10 +82,10 @@ struct vdso_data {
 __u32 icache_block_size;    /* L1 i-cache block 
size */
 __u32 dcache_log_block_size;    /* L1 d-cache log 
block size */
 __u32 icache_log_block_size;    /* L1 i-cache log 
block size */
-   __u32 stamp_sec_fraction;   /* fractional seconds 
of stamp_xtime */
-   __s32 wtom_clock_nsec;  /* Wall to monotonic 
clock nsec */
-   __s64 wtom_clock_sec;   /* Wall to monotonic 
clock sec */
-   struct timespec stamp_xtime;    /* xtime as at 
tb_orig_stamp */
+   __s32 wtom_clock_sec;   /* Wall to monotonic 
clock */

+   __s32 wtom_clock_nsec;
+   struct timespec stamp_xtime;    /* xtime as at tb_orig_stamp */
+   __u32 stamp_sec_fraction;   /* fractional seconds of 
stamp_xtime */

 __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
 __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
  };

-

Cheers,
Christian

[PATCH 4.19 131/187] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Signed-off-by: Wen Yang 
Cc: Timur Tabi 
Cc: Nicolin Chen 
Cc: Xiubo Li 
Cc: Fabio Estevam 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 44433b20435c..600d9be9706e 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 asrc_fail:
of_node_put(asrc_np);
of_node_put(codec_np);
+   put_device(_pdev->dev);
 fail:
of_node_put(cpu_np);
 
-- 
2.19.1

[PATCH 4.19 083/187] SoC: imx-sgtl5000: add missing put_device()

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.

Signed-off-by: Wen Yang 
Cc: Timur Tabi 
Cc: Nicolin Chen 
Cc: Xiubo Li 
Cc: Fabio Estevam 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: NXP Linux Team 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/imx-sgtl5000.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index c29200cf755a..9b9a7ec52905 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -108,6 +108,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
ret = -EPROBE_DEFER;
goto fail;
}
+   put_device(_pdev->dev);
codec_dev = of_find_i2c_device_by_node(codec_np);
if (!codec_dev) {
dev_err(>dev, "failed to find codec platform device\n");
-- 
2.19.1

[PATCH 4.14 085/121] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Signed-off-by: Wen Yang 
Cc: Timur Tabi 
Cc: Nicolin Chen 
Cc: Xiubo Li 
Cc: Fabio Estevam 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 2db4d0c80d33..393100edd5fd 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 asrc_fail:
of_node_put(asrc_np);
of_node_put(codec_np);
+   put_device(_pdev->dev);
 fail:
of_node_put(cpu_np);
 
-- 
2.19.1

[PATCH 4.14 058/121] SoC: imx-sgtl5000: add missing put_device()

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.

Signed-off-by: Wen Yang 
Cc: Timur Tabi 
Cc: Nicolin Chen 
Cc: Xiubo Li 
Cc: Fabio Estevam 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: NXP Linux Team 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/imx-sgtl5000.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index b99e0b5e00e9..8e525f7ac08d 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -115,6 +115,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
ret = -EPROBE_DEFER;
goto fail;
}
+   put_device(_pdev->dev);
codec_dev = of_find_i2c_device_by_node(codec_np);
if (!codec_dev) {
dev_err(>dev, "failed to find codec platform device\n");
-- 
2.19.1

[PATCH 4.9 66/91] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Signed-off-by: Wen Yang 
Cc: Timur Tabi 
Cc: Nicolin Chen 
Cc: Xiubo Li 
Cc: Fabio Estevam 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index dffd549a0e2a..705d2524ec31 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 asrc_fail:
of_node_put(asrc_np);
of_node_put(codec_np);
+   put_device(_pdev->dev);
 fail:
of_node_put(cpu_np);
 
-- 
2.19.1

[PATCH 4.9 44/91] SoC: imx-sgtl5000: add missing put_device()

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]

The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.

Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.

Signed-off-by: Wen Yang 
Cc: Timur Tabi 
Cc: Nicolin Chen 
Cc: Xiubo Li 
Cc: Fabio Estevam 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: NXP Linux Team 
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/imx-sgtl5000.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index b99e0b5e00e9..8e525f7ac08d 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -115,6 +115,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
ret = -EPROBE_DEFER;
goto fail;
}
+   put_device(_pdev->dev);
codec_dev = of_find_i2c_device_by_node(codec_np);
if (!codec_dev) {
dev_err(>dev, "failed to find codec platform device\n");
-- 
2.19.1

VLC doesn't play videos anymore since the PowerPC fixes 5.1-3

[Christian Zigotzky]

On 04 April 2019 at 06:00AM, Christophe Leroy wrote:



Le 04/04/2019 à 02:58, Christian Zigotzky a écrit :

On 03 April 2019 at 07:05AM, Christophe Leroy wrote:

Le 03/04/2019 à 05:52, Christian Zigotzky a écrit :

Please test VLC with the RC3 of kernel 5.1.

The removing of the PowerPC fixes 5.1-3 has solved the VLC issue. 
Another user has already confirmed that [1]. This isn’t an April 
Fool‘s. ;-)


Could you bisect to identify the guilty commit ?

Thanks
Christophe



Thanks

[1] 
http://forum.hyperion-entertainment.com/viewtopic.php?f=58=4256=20#p47561 






Hello Christophe,

I have found the problematic patch. The following patch from the 
PowerPC fixes 5.1-3 is responsible for the VLC issue.


That change is part of the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.1-rc2=b5b4453e7912f056da1ca7572574cada32ecb60c 



Just changing back the type of wtom_clock_sec to 32 bits without 
changing back the loading instruction is likely to give unexpected 
results on PPC64.


Are you using 32 bits or 64 bits powerpc ?

Christophe

64-bit kernel + 32-bit userland for example:

- ubuntu MATE 16.04.6 LTS 32-bit PowerPC with a 64-bit kernel
- Fienix (Debian Sid) 32-bit PowerPC with a 64-bit kernel
- MATE PowerPC Remix (ubuntu MATE 17.04) 32-bit PowerPC with a 64-bit kernel

-- Christian





diff --git a/arch/powerpc/include/asm/vdso_datapage.h 
b/arch/powerpc/include/asm/vdso_datapage.h

index 1afe90ade595..bbc06bd72b1f 100644
--- a/arch/powerpc/include/asm/vdso_datapage.h
+++ b/arch/powerpc/include/asm/vdso_datapage.h
@@ -82,10 +82,10 @@ struct vdso_data {
 __u32 icache_block_size;  /* L1 i-cache block size */
 __u32 dcache_log_block_size;  /* L1 d-cache log block size */
 __u32 icache_log_block_size;  /* L1 i-cache log block size */
-   __s32 wtom_clock_sec; /* Wall to monotonic clock */
-   __s32 wtom_clock_nsec;
-   struct timespec stamp_xtime;   /* xtime as at tb_orig_stamp */
-   __u32 stamp_sec_fraction;   /* fractional seconds of stamp_xtime */
+   __u32 stamp_sec_fraction;  /* fractional seconds of 
stamp_xtime */

+   __s32 wtom_clock_nsec; /* Wall to monotonic clock nsec */
+   __s64 wtom_clock_sec; /* Wall to monotonic clock sec */
+   struct timespec stamp_xtime;  /* xtime as at tb_orig_stamp */
    __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
    __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
  };

-

Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/include/asm/vdso_datapage.h?h=v5.1-rc2=a5ed1e96cafde5ba48638f486bfca0685dc6ddc9 



I created a patch for solving the VLC issue today.

vdso_datapage_vlc.patch:

diff -rupN a/arch/powerpc/include/asm/vdso_datapage.h 
b/arch/powerpc/include/asm/vdso_datapage.h
--- a/arch/powerpc/include/asm/vdso_datapage.h  2019-04-03 
22:56:44.560645936 +0200
+++ b/arch/powerpc/include/asm/vdso_datapage.h  2019-04-04 
02:20:09.479361827 +0200

@@ -82,10 +82,10 @@ struct vdso_data {
 __u32 icache_block_size;    /* L1 i-cache block 
size */
 __u32 dcache_log_block_size;    /* L1 d-cache log 
block size */
 __u32 icache_log_block_size;    /* L1 i-cache log 
block size */
-   __u32 stamp_sec_fraction;   /* fractional seconds 
of stamp_xtime */
-   __s32 wtom_clock_nsec;  /* Wall to monotonic 
clock nsec */
-   __s64 wtom_clock_sec;   /* Wall to monotonic 
clock sec */
-   struct timespec stamp_xtime;    /* xtime as at 
tb_orig_stamp */
+   __s32 wtom_clock_sec;   /* Wall to monotonic 
clock */

+   __s32 wtom_clock_nsec;
+   struct timespec stamp_xtime;    /* xtime as at tb_orig_stamp */
+   __u32 stamp_sec_fraction;   /* fractional seconds of 
stamp_xtime */

 __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
 __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
  };

-

Cheers,
Christian

Re: [PATCH 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args

[Thomas Gleixner]

On Mon, 1 Apr 2019, Steven Rostedt wrote:

> From: "Steven Rostedt (VMware)" 
> 
> After removing the start and count arguments of syscall_get_arguments() it
> seems reasonable to remove them from syscall_set_arguments(). Note, as of
> today, there are no users of syscall_set_arguments(). But we are told that
> there will be soon. But for now, at least make it consistent with
> syscall_get_arguments().
> 
> Link: http://lkml.kernel.org/r/20190327222014.ga32...@altlinux.org

For x86:

Reviewed-by: Thomas Gleixner 

Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

[Thomas Gleixner]

On Mon, 1 Apr 2019, Steven Rostedt wrote:

> From: "Steven Rostedt (Red Hat)" 
> 
> At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
> function call syscall_get_arguments() implemented in x86 was horribly
> written and not optimized for the standard case of passing in 0 and 6 for
> the starting index and the number of system calls to get. When looking at
> all the users of this function, I discovered that all instances pass in only
> 0 and 6 for these arguments. Instead of having this function handle
> different cases that are never used, simply rewrite it to return the first 6
> arguments of a system call.
> 
> This should help out the performance of tracing system calls by ptrace,
> ftrace and perf.
> 
> Link: http://lkml.kernel.org/r/20161107213233.754809...@goodmis.org

For x86:

Reviewed-by: Thomas Gleixner 

RE: [PATCH V2] ASoC: fsl_esai: Support synchronous mode

[S.j. Wang]

Hi

> 
> This looks better :)
> 
> On Wed, Apr 03, 2019 at 10:07:40AM +, S.j. Wang wrote:
> > @@ -218,7 +218,7 @@ static int fsl_esai_set_dai_sysclk(struct
> > snd_soc_dai *dai, int clk_id,  {
> > struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
> > struct clk *clksrc = esai_priv->extalclk;
> > -   bool tx = clk_id <= ESAI_HCKT_EXTAL;
> > +   bool tx = (clk_id <= ESAI_HCKT_EXTAL || esai_priv->synchronous);
> > bool in = dir == SND_SOC_CLOCK_IN;
> > u32 ratio, ecr = 0;
> > unsigned long clk_rate;
> > @@ -253,7 +253,7 @@ static int fsl_esai_set_dai_sysclk(struct
> snd_soc_dai *dai, int clk_id,
> > ecr |= ESAI_ECR_ETI;
> > /* fall through */
> 
> Btw, I am also wondering if the fall through here is a bug
> Because I don't recall that there is a specific reason to fall through here.
> Can you please help confirm? Perhaps we need to submit a separate fix as
> well by replacing it with a "break;".
Yes, I think there is issue here, will submit another patch for it.
> 
> > case ESAI_HCKR_EXTAL:
> > -   ecr |= ESAI_ECR_ERI;
> > +   ecr |= esai_priv->synchronous ? ESAI_ECR_ETI :
> ESAI_ECR_ERI;
> > break;
> > default:
> > return -EINVAL;
> 
> > @@ -537,10 +537,18 @@ static int fsl_esai_hw_params(struct
> > snd_pcm_substream *substream,
> >
> > bclk = params_rate(params) * slot_width * esai_priv->slots;
> >
> > -   ret = fsl_esai_set_bclk(dai, tx, bclk);
> > +   ret = fsl_esai_set_bclk(dai, esai_priv->synchronous || tx, bclk);
> > if (ret)
> > return ret;
> >
> > +   mask = ESAI_xCR_xSWS_MASK;
> > +   val = ESAI_xCR_xSWS(slot_width, width);
> > +
> > +   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask,
> val);
> > +   /* Recording in synchronous mode needs to set TCR also */
> > +   if (!tx && esai_priv->synchronous)
> > +   regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> mask, val);
> > +
> > /* Use Normal mode to support monaural audio */
> > regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
> >ESAI_xCR_xMOD_MASK,
> params_channels(params) > 1 ?
> > @@ -556,10 +564,9 @@ static int fsl_esai_hw_params(struct
> > snd_pcm_substream *substream,
> >
> > regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx), mask,
> val);
> >
> > -   mask = ESAI_xCR_xSWS_MASK | (tx ? ESAI_xCR_PADC : 0);
> > -   val = ESAI_xCR_xSWS(slot_width, width) | (tx ? ESAI_xCR_PADC : 0);
> > -
> > -   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx), mask,
> val);
> > +   if (tx)
> > +   regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> > +   ESAI_xCR_PADC, ESAI_xCR_PADC);
> 
> Mind aligning the indentation here like the one below?
>   regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
>  ESAI_xCR_PADC, ESAI_xCR_PADC);

Ok. Will send v3.
> 
> Once you fix the indentation, add this:
> 
> Acked-by: Nicolin Chen 
> 
> Thanks

Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere

[Michael Ellerman]

Jens Axboe  writes:
> On 4/3/19 5:11 AM, Will Deacon wrote:
>> On Wed, Apr 03, 2019 at 01:47:50PM +1100, Michael Ellerman wrote:
>>> Arnd Bergmann  writes:
 diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl 
 b/arch/powerpc/kernel/syscalls/syscall.tbl
 index b18abb0c3dae..00f5a63c8d9a 100644
 --- a/arch/powerpc/kernel/syscalls/syscall.tbl
 +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
 @@ -505,3 +505,7 @@
  421   32  rt_sigtimedwait_time64  sys_rt_sigtimedwait 
 compat_sys_rt_sigtimedwait_time64
  422   32  futex_time64sys_futex   
 sys_futex
  423   32  sched_rr_get_interval_time64
 sys_sched_rr_get_interval   sys_sched_rr_get_interval
 +424   common  pidfd_send_signal   sys_pidfd_send_signal
 +425   common  io_uring_setup  sys_io_uring_setup
 +426   common  io_uring_enter  sys_io_uring_enter
 +427   common  io_uring_register   sys_io_uring_register
>>>
>>> Acked-by: Michael Ellerman  (powerpc)
>>>
>>> Lightly tested.
>>>
>>> The pidfd_test selftest passes.
>> 
>> That reports pass for me too, although it fails to unshare the pid ns, which 
>> I
>> assume is benign.

If you run it as root it should work?

>>> Ran the io_uring example from fio, which prints lots of:
>> 
>> How did you invoke that? I had a play with the tests in:
>
> It's t/io_uring from the fio repo:
>
> git://git.kernel.dk/fio
>
> and you just run it ala:
>
> # make t/io_uring
> # t/io_uring /dev/some_device

Yeah that's all I did.

>> will@autoplooker:~/liburing/test$ ./io_uring_register 
>> RELIMIT_MEMLOCK: 67108864 (67108864)
>> [   35.477875] Unable to handle kernel NULL pointer dereference at virtual 
>> address 0070
>> [   35.478969] Mem abort info:
>> [   35.479296]   ESR = 0x9604
>> [   35.479785]   Exception class = DABT (current EL), IL = 32 bits
>> [   35.480528]   SET = 0, FnV = 0
>> [   35.480980]   EA = 0, S1PTW = 0
>> [   35.481345] Data abort info:
>> [   35.481680]   ISV = 0, ISS = 0x0004
>> [   35.482267]   CM = 0, WnR = 0
>> [   35.482618] user pgtable: 4k pages, 48-bit VAs, pgdp = (ptrval)
>> [   35.483486] [0070] pgd=
>> [   35.484041] Internal error: Oops: 9604 [#1] PREEMPT SMP
>> [   35.484788] Modules linked in:
>> [   35.485311] CPU: 113 PID: 3973 Comm: io_uring_regist Not tainted 
>> 5.1.0-rc3-00012-g40b114779944 #1
>> [   35.486712] Hardware name: linux,dummy-virt (DT)
>> [   35.487450] pstate: 2045 (nzCv daif +PAN -UAO)
>> [   35.488228] pc : link_pwq+0x10/0x60
>> [   35.488794] lr : apply_wqattrs_commit+0xe0/0x118
>> [   35.489550] sp : 17e2bbc0
>
> Huh, this looks odd, it's crashing inside the wq setup.

Looks like you found a bug :)

cheers