[PATCH v2 2/2] ASoC: fsl-asoc-card: Add MQS support

2020-06-16 Thread Shengjiu Wang
The MQS codec isn't an i2c device, so use of_find_device_by_node
to get platform device pointer.

Because MQS only support playback, then add a new audio map.

And there maybe "model" property or no "audio-routing" property in
devicetree, so add some enhancement for these two property.

Signed-off-by: Shengjiu Wang 
---
changes in v2
- update according Nicolin's comments.

 sound/soc/fsl/fsl-asoc-card.c | 78 +--
 1 file changed, 57 insertions(+), 21 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 00be73900888..d0543a53764e 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -119,6 +119,13 @@ static const struct snd_soc_dapm_route audio_map_ac97[] = {
{"ASRC-Capture",  NULL, "AC97 Capture"},
 };
 
+static const struct snd_soc_dapm_route audio_map_tx[] = {
+   /* 1st half -- Normal DAPM routes */
+   {"Playback",  NULL, "CPU-Playback"},
+   /* 2nd half -- ASRC DAPM routes */
+   {"CPU-Playback",  NULL, "ASRC-Playback"},
+};
+
 /* Add all possible widgets into here without being redundant */
 static const struct snd_soc_dapm_widget fsl_asoc_card_dapm_widgets[] = {
SND_SOC_DAPM_LINE("Line Out Jack", NULL),
@@ -485,8 +492,9 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
struct platform_device *asrc_pdev = NULL;
struct platform_device *cpu_pdev;
struct fsl_asoc_card_priv *priv;
-   struct i2c_client *codec_dev;
+   struct device *codec_dev = NULL;
const char *codec_dai_name;
+   const char *codec_dev_name;
u32 width;
int ret;
 
@@ -512,10 +520,23 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
}
 
codec_np = of_parse_phandle(np, "audio-codec", 0);
-   if (codec_np)
-   codec_dev = of_find_i2c_device_by_node(codec_np);
-   else
-   codec_dev = NULL;
+   if (codec_np) {
+   struct platform_device *codec_pdev;
+   struct i2c_client *codec_i2c;
+
+   codec_i2c = of_find_i2c_device_by_node(codec_np);
+   if (codec_i2c) {
+   codec_dev = _i2c->dev;
+   codec_dev_name = codec_i2c->name;
+   }
+   if (!codec_dev) {
+   codec_pdev = of_find_device_by_node(codec_np);
+   if (codec_pdev) {
+   codec_dev = _pdev->dev;
+   codec_dev_name = codec_pdev->name;
+   }
+   }
+   }
 
asrc_np = of_parse_phandle(np, "audio-asrc", 0);
if (asrc_np)
@@ -523,7 +544,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 
/* Get the MCLK rate only, and leave it controlled by CODEC drivers */
if (codec_dev) {
-   struct clk *codec_clk = clk_get(_dev->dev, NULL);
+   struct clk *codec_clk = clk_get(codec_dev, NULL);
 
if (!IS_ERR(codec_clk)) {
priv->codec_priv.mclk_freq = clk_get_rate(codec_clk);
@@ -538,6 +559,11 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
/* Assign a default DAI format, and allow each card to overwrite it */
priv->dai_fmt = DAI_FMT_BASE;
 
+   memcpy(priv->dai_link, fsl_asoc_card_dai,
+  sizeof(struct snd_soc_dai_link) * ARRAY_SIZE(priv->dai_link));
+
+   priv->card.dapm_routes = audio_map;
+   priv->card.num_dapm_routes = ARRAY_SIZE(audio_map);
/* Diversify the card configurations */
if (of_device_is_compatible(np, "fsl,imx-audio-cs42888")) {
codec_dai_name = "cs42888";
@@ -573,6 +599,18 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
codec_dai_name = "ac97-hifi";
priv->card.set_bias_level = NULL;
priv->dai_fmt = SND_SOC_DAIFMT_AC97;
+   priv->card.dapm_routes = audio_map_ac97;
+   priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_ac97);
+   } else if (of_device_is_compatible(np, "fsl,imx-audio-mqs")) {
+   codec_dai_name = "fsl-mqs-dai";
+   priv->card.set_bias_level = NULL;
+   priv->dai_fmt = SND_SOC_DAIFMT_LEFT_J |
+   SND_SOC_DAIFMT_CBS_CFS |
+   SND_SOC_DAIFMT_NB_NF;
+   priv->dai_link[1].dpcm_capture = 0;
+   priv->dai_link[2].dpcm_capture = 0;
+   priv->card.dapm_routes = audio_map_tx;
+   priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_tx);
} else {
dev_err(>dev, "unknown Device Tree compatible\n");
ret = -EINVAL;
@@ -601,19 +639,17 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
priv->cpu_priv.sysclk_id[0] = FSL_SAI_CLK_MAST1;
}
 
-   snprintf(priv->name, sizeof(priv->name), 

[PATCH v2 1/2] ASoC: bindings: fsl-asoc-card: Add compatible string for MQS

2020-06-16 Thread Shengjiu Wang
Add compatible string "fsl,imx-audio-mqs" for MQS, and move
"audio-routing" property to be optional for MQS doesn't need
such property.

Signed-off-by: Shengjiu Wang 
---
changes in v2
- Move "audio-routing" to optional.

 .../devicetree/bindings/sound/fsl-asoc-card.txt  | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt 
b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index c60a5732d29c..ca9a3a43adfd 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -34,6 +34,8 @@ The compatible list for this generic sound card currently:
 
  "fsl,imx-audio-wm8960"
 
+ "fsl,imx-audio-mqs"
+
 Required properties:
 
   - compatible : Contains one of entries in the compatible list.
@@ -44,6 +46,11 @@ Required properties:
 
   - audio-codec: The phandle of an audio codec
 
+Optional properties:
+
+  - audio-asrc : The phandle of ASRC. It can be absent if there's no
+ need to add ASRC support via DPCM.
+
   - audio-routing  : A list of the connections between audio components.
  Each entry is a pair of strings, the first being the
  connection's sink, the second being the connection's
@@ -60,11 +67,6 @@ Required properties:
coexisting in order to support the old bindings
of wm8962 and sgtl5000.
 
-Optional properties:
-
-  - audio-asrc : The phandle of ASRC. It can be absent if there's no
- need to add ASRC support via DPCM.
-
 Optional unless SSI is selected as a CPU DAI:
 
   - mux-int-port   : The internal port of the i.MX audio muxer (AUDMUX)
-- 
2.21.0



[PATCH v2 2/2] ASoC: fsl_spdif: Add support for imx6sx platform

2020-06-16 Thread Shengjiu Wang
The one difference on imx6sx platform is that the root clock
is shared with ASRC module, so we add a new flags
"shared_root_clock" which means the root clock is independent,
then we will not do the clk_set_rate and clk_round_rate to avoid
impact ASRC module usage.

As add a new flags, we include the soc specific data struct.

Signed-off-by: Shengjiu Wang 
---
changes in v2
- use shared_root_clk instead ind_root_clk.
- add fsl_spdif_can_set_clk_rate function.

 sound/soc/fsl/fsl_spdif.c | 50 +++
 1 file changed, 46 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 1b2e516f9162..8dc1959d0463 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -42,6 +42,18 @@ static u8 srpc_dpll_locked[] = { 0x0, 0x1, 0x2, 0x3, 0x4, 
0xa, 0xb };
 
 #define DEFAULT_RXCLK_SRC  1
 
+/**
+ * struct fsl_spdif_soc_data: soc specific data
+ *
+ * @imx: for imx platform
+ * @shared_root_clock: flag of sharing a clock source with others;
+ * so the driver shouldn't set root clock rate
+ */
+struct fsl_spdif_soc_data {
+   bool imx;
+   bool shared_root_clock;
+};
+
 /*
  * SPDIF control structure
  * Defines channel status, subcode and Q sub
@@ -89,6 +101,7 @@ struct spdif_mixer_control {
  * @dma_params_rx: DMA parameters for receive channel
  */
 struct fsl_spdif_priv {
+   const struct fsl_spdif_soc_data *soc;
struct spdif_mixer_control fsl_spdif_control;
struct snd_soc_dai_driver cpu_dai_drv;
struct platform_device *pdev;
@@ -110,6 +123,28 @@ struct fsl_spdif_priv {
u32 regcache_srpc;
 };
 
+static struct fsl_spdif_soc_data fsl_spdif_vf610 = {
+   .imx = false,
+   .shared_root_clock = false,
+};
+
+static struct fsl_spdif_soc_data fsl_spdif_imx35 = {
+   .imx = true,
+   .shared_root_clock = false,
+};
+
+static struct fsl_spdif_soc_data fsl_spdif_imx6sx = {
+   .imx = true,
+   .shared_root_clock = true,
+};
+
+/* Check if clk is a root clock that does not share clock source with others */
+static inline bool fsl_spdif_can_set_clk_rate(struct fsl_spdif_priv *spdif,
+ int clk)
+{
+   return (clk == STC_TXCLK_SPDIF_ROOT) && !spdif->soc->shared_root_clock;
+}
+
 /* DPLL locked and lock loss interrupt handler */
 static void spdif_irq_dpll_lock(struct fsl_spdif_priv *spdif_priv)
 {
@@ -421,7 +456,7 @@ static int spdif_set_sample_rate(struct snd_pcm_substream 
*substream,
sysclk_df = spdif_priv->sysclk_df[rate];
 
/* Don't mess up the clocks from other modules */
-   if (clk != STC_TXCLK_SPDIF_ROOT)
+   if (!fsl_spdif_can_set_clk_rate(spdif_priv, clk))
goto clk_set_bypass;
 
/* The S/PDIF block needs a clock of 64 * fs * txclk_df */
@@ -1186,7 +1221,7 @@ static int fsl_spdif_probe_txclk(struct fsl_spdif_priv 
*spdif_priv,
continue;
 
ret = fsl_spdif_txclk_caldiv(spdif_priv, clk, savesub, index,
-i == STC_TXCLK_SPDIF_ROOT);
+
fsl_spdif_can_set_clk_rate(spdif_priv, i));
if (savesub == ret)
continue;
 
@@ -1230,6 +1265,12 @@ static int fsl_spdif_probe(struct platform_device *pdev)
 
spdif_priv->pdev = pdev;
 
+   spdif_priv->soc = of_device_get_match_data(>dev);
+   if (!spdif_priv->soc) {
+   dev_err(>dev, "failed to get soc data\n");
+   return -ENODEV;
+   }
+
/* Initialize this copy of the CPU DAI driver structure */
memcpy(_priv->cpu_dai_drv, _spdif_dai, sizeof(fsl_spdif_dai));
spdif_priv->cpu_dai_drv.name = dev_name(>dev);
@@ -1359,8 +1400,9 @@ static const struct dev_pm_ops fsl_spdif_pm = {
 };
 
 static const struct of_device_id fsl_spdif_dt_ids[] = {
-   { .compatible = "fsl,imx35-spdif", },
-   { .compatible = "fsl,vf610-spdif", },
+   { .compatible = "fsl,imx35-spdif", .data = _spdif_imx35, },
+   { .compatible = "fsl,vf610-spdif", .data = _spdif_vf610, },
+   { .compatible = "fsl,imx6sx-spdif", .data = _spdif_imx6sx, },
{}
 };
 MODULE_DEVICE_TABLE(of, fsl_spdif_dt_ids);
-- 
2.21.0



[PATCH v2 1/2] ASoC: bindings: fsl_spdif: Add new compatible string for imx6sx

2020-06-16 Thread Shengjiu Wang
Add new compatible string "fsl,imx6sx-spdif" in the binding document.
And add compatible string "fsl,vf610-spdif" which was missed before.

Signed-off-by: Shengjiu Wang 
---
 Documentation/devicetree/bindings/sound/fsl,spdif.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt 
b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
index 8b324f82a782..e1365b0ee1e9 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -6,7 +6,11 @@ a fibre cable.
 
 Required properties:
 
-  - compatible : Compatible list, must contain "fsl,imx35-spdif".
+  - compatible : Compatible list, should contain one of the following
+ compatibles:
+ "fsl,imx35-spdif",
+ "fsl,vf610-spdif",
+ "fsl,imx6sx-spdif",
 
   - reg: Offset and length of the register set for the 
device.
 
-- 
2.21.0



Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread Finn Thain
On Tue, 16 Jun 2020, Martin K. Petersen wrote:

> > I haven't used this driver for a long time, but I still own PowerMacs 
> > with firewire, and I know I'm not the only one.
> 

I need to correct what I wrote above. I recall that years ago, when I 
needed to share storage from my Linux box to my PowerBook pismo, I used 
ethernet and the globalSAN iSCSI initiator for Mac OS X (which is no 
longer freely available AFAICS). When I said that I had used the SBP 
target driver before, I misremembered that iSCSI target setup. I've 
actually never used the SBP target driver.

> I also have old 1394 hardware kicking around in the basement. But having 
> worked with FireWire shared storage targets in the past, I have zero 
> desire to ever touch any of that again.
> 
> I could understand an objection if we were to entertain removing sbp2. 
> But really, how many people are setting up FireWire targets?
> 

It's a good question. I don't know the answer.

I have successfully used the Linux sbp2 host driver in the past, and will 
probably need to use it again. Likewise, I can see myself using the sbp 
target driver in the future because that might interoperate with MacOS 9, 
and might provide a bootable device to the PowerMac ROM. iSCSI cannot do 
those things.


Re: [PATCH] powerpc/8xx: use pmd_off() to access a PMD entry in pte_update()

2020-06-16 Thread Mike Rapoport
On Wed, Jun 17, 2020 at 09:21:42AM +1000, Michael Ellerman wrote:
> Andrew Morton  writes:
> > On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport  wrote:
> >
> >> From: Mike Rapoport 
> >> 
> >> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
> >> level to access a PMD entry. Since 8xx has only 2-level page table this can
> >> be simplified with pmd_off() shortcut.
> >> 
> >> Replace explicit unfolding with pmd_off() and drop defines of pgd_index()
> >> and pgd_offset() that are no longer needed.
> >> 
> >> Signed-off-by: Mike Rapoport 
> >> ---
> >> 
> >> I think it's powerpc material, but I won't mind if Andrew picks it up :)
> >
> > Via the powerpc tree would be better, please.
> 
> I'll take it into next for v5.9, unless there's a reason it needs to go
> into v5.8.

I consider it a fixup for 5.8 merge window conflicts. Besides, mering it
now may avoid new conflicts in 5.9 ;-)

> cheers

-- 
Sincerely yours,
Mike.


Re: [PATCH 2/2] ASoC: fsl_spdif: Add support for imx6sx platform

2020-06-16 Thread Shengjiu Wang
On Wed, Jun 17, 2020 at 7:30 AM Nicolin Chen  wrote:
>
> On Tue, Jun 16, 2020 at 02:42:41PM +0800, Shengjiu Wang wrote:
> > The one difference on imx6sx platform is that the root clock
> > is shared with ASRC module, so we add a new flags "ind_root_clk"
> > which means the root clock is independent, then we will not
> > do the clk_set_rate and clk_round_rate to avoid impact ASRC
> > module usage.
> >
> > As add a new flags, we include the soc specific data struct.
> >
> > Signed-off-by: Shengjiu Wang 
> > ---
> >  sound/soc/fsl/fsl_spdif.c | 43 +++
> >  1 file changed, 39 insertions(+), 4 deletions(-)
> >
> > diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
> > index 1b2e516f9162..00e06803d32f 100644
> > --- a/sound/soc/fsl/fsl_spdif.c
> > +++ b/sound/soc/fsl/fsl_spdif.c
> > @@ -42,6 +42,17 @@ static u8 srpc_dpll_locked[] = { 0x0, 0x1, 0x2, 0x3, 
> > 0x4, 0xa, 0xb };
> >
> >  #define DEFAULT_RXCLK_SRC1
> >
> > +/**
> > + * struct fsl_spdif_soc_data: soc specific data
> > + *
> > + * @imx: for imx platform
> > + * @ind_root_clk: flag for round clk rate
> > + */
> > +struct fsl_spdif_soc_data {
> > + bool imx;
> > + bool ind_root_clk;
>
> "ind" doesn't look very straightforward; maybe "shared_root_clock"?
>
> And for its comments:
> * @shared_root_clock: flag of sharing a clock source with others;
> * so the driver shouldn't set root clock rate
>
> > +};
> > +
> >  /*
> >   * SPDIF control structure
> >   * Defines channel status, subcode and Q sub
> > @@ -93,6 +104,7 @@ struct fsl_spdif_priv {
> >   struct snd_soc_dai_driver cpu_dai_drv;
> >   struct platform_device *pdev;
> >   struct regmap *regmap;
> > + const struct fsl_spdif_soc_data *soc;
>
> Looks better if we move it to the top of the list :)
>
> > @@ -421,7 +448,7 @@ static int spdif_set_sample_rate(struct 
> > snd_pcm_substream *substream,
> >   sysclk_df = spdif_priv->sysclk_df[rate];
> >
> >   /* Don't mess up the clocks from other modules */
> > - if (clk != STC_TXCLK_SPDIF_ROOT)
> > + if (clk != STC_TXCLK_SPDIF_ROOT || !spdif_priv->soc->ind_root_clk)
> >   goto clk_set_bypass;
> >
> >   /* The S/PDIF block needs a clock of 64 * fs * txclk_df */
> > @@ -1186,7 +1213,8 @@ static int fsl_spdif_probe_txclk(struct 
> > fsl_spdif_priv *spdif_priv,
> >   continue;
> >
> >   ret = fsl_spdif_txclk_caldiv(spdif_priv, clk, savesub, index,
> > -  i == STC_TXCLK_SPDIF_ROOT);
> > +  i == STC_TXCLK_SPDIF_ROOT &&
> > +  spdif_priv->soc->ind_root_clk);
>
> Having more than one place that checks the condition, we can add:
>
> /* Check if clk is a root clock that does not share clock source with others 
> */
> static inline bool fsl_spdif_can_set_clk_rate(struct fsl_spdif_priv *spdif, 
> int clk)
> {
> return (clk == STC_TXCLK_SPDIF_ROOT) && 
> !spdif->soc->shared_root_clock;
> }

will update them in v2

best regards
wang shengjiu


Re: [PATCH 2/2] ASoC: fsl-asoc-card: Add MQS support

2020-06-16 Thread Shengjiu Wang
On Wed, Jun 17, 2020 at 8:50 AM Nicolin Chen  wrote:
>
> On Tue, Jun 16, 2020 at 03:30:37PM +0800, Shengjiu Wang wrote:
> > The MQS codec isn't an i2c device, so add a new platform device for it.
> >
> > MQS only support playback, so add a new audio map.
> >
> > Add there maybe "model" property or no "audio-routing" property insertions
>
> "Add" => "And"
>
> > devicetree, so add some enhancement for these two property.
> >
> > Signed-off-by: Shengjiu Wang 
> > ---
> >  sound/soc/fsl/fsl-asoc-card.c | 70 ++-
> >  1 file changed, 52 insertions(+), 18 deletions(-)
> >
> > diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> > index 00be73900888..2ac8cb9ddd10 100644
> > --- a/sound/soc/fsl/fsl-asoc-card.c
> > +++ b/sound/soc/fsl/fsl-asoc-card.c
>
> > @@ -482,6 +489,7 @@ static int fsl_asoc_card_probe(struct platform_device 
> > *pdev)
> >  {
> >   struct device_node *cpu_np, *codec_np, *asrc_np;
> >   struct device_node *np = pdev->dev.of_node;
> > + struct platform_device *codec_pdev = NULL; /* used for non i2c 
> > device*/
>
> Having both codec_pdev and codec_dev duplicates things. Actually
> only a couple of places really need "codec_dev" -- most of them
> need codec_dev->dev pointer instead. So we could have a cleanup:
>
> -   struct i2c_client *codec_dev;
> +   struct device *codec_dev = NULL;
>
> > @@ -512,10 +520,13 @@ static int fsl_asoc_card_probe(struct platform_device 
> > *pdev)
> >   }
> >
> >   codec_np = of_parse_phandle(np, "audio-codec", 0);
> > - if (codec_np)
> > + if (codec_np) {
> >   codec_dev = of_find_i2c_device_by_node(codec_np);
> > - else
> > + if (!codec_dev)
> > + codec_pdev = of_find_device_by_node(codec_np);
> > + } else {
> >   codec_dev = NULL;
> > + }
>
> Here can have something like (feel free to simplify):
>
> if (codec_np) {
> struct platform_device *codec_pdev;
> struct i2c_client *codec_i2c;
>
> codec_i2c = of_find_i2c_device_by_node(codec_np);
> if (codec_i2c)
> codec_dev = _i2c->dev;
>
> if (!codec_dev) {
> codec_pdev = of_find_device_by_node(codec_np);
> codec_dev = _pdev->dev;
> }
> }
> >   asrc_np = of_parse_phandle(np, "audio-asrc", 0);
> >   if (asrc_np)
> > @@ -525,6 +536,13 @@ static int fsl_asoc_card_probe(struct platform_device 
> > *pdev)
> >   if (codec_dev) {
> >   struct clk *codec_clk = clk_get(_dev->dev, NULL);
>
> Then here:
>
> -   struct clk *codec_clk = clk_get(_dev->dev, NULL);
> +   struct clk *codec_clk = clk_get(codec_dev, NULL);
>
> > @@ -538,6 +556,11 @@ static int fsl_asoc_card_probe(struct platform_device 
> > *pdev)
> >   /* Assign a default DAI format, and allow each card to overwrite it */
> >   priv->dai_fmt = DAI_FMT_BASE;
> >
> > + memcpy(priv->dai_link, fsl_asoc_card_dai,
> > +sizeof(struct snd_soc_dai_link) * ARRAY_SIZE(priv->dai_link));
>
> > @@ -573,13 +596,25 @@ static int fsl_asoc_card_probe(struct platform_device 
> > *pdev)
> >   codec_dai_name = "ac97-hifi";
> >   priv->card.set_bias_level = NULL;
> >   priv->dai_fmt = SND_SOC_DAIFMT_AC97;
> > + priv->card.dapm_routes = audio_map_ac97;
> > + priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_ac97);
> > + } else if (of_device_is_compatible(np, "fsl,imx-audio-mqs")) {
> > + codec_dai_name = "fsl-mqs-dai";
> > + priv->card.set_bias_level = NULL;
> > + priv->dai_fmt = SND_SOC_DAIFMT_LEFT_J |
> > + SND_SOC_DAIFMT_CBS_CFS |
> > + SND_SOC_DAIFMT_NB_NF;
> > + priv->dai_link[1].dpcm_playback = 1;
> > + priv->dai_link[2].dpcm_playback = 1;
>
> dpcm_playback = 1? That's the default value in fsl_asoc_card_dai.

ah,  should be dpcm_capture = 0.

>
> > @@ -601,19 +636,18 @@ static int fsl_asoc_card_probe(struct platform_device 
> > *pdev)
> >   priv->cpu_priv.sysclk_id[0] = FSL_SAI_CLK_MAST1;
> >   }
> >
> > - snprintf(priv->name, sizeof(priv->name), "%s-audio",
> > -  fsl_asoc_card_is_ac97(priv) ? "ac97" :
> > -  codec_dev->name);
> > -
> >   /* Initialize sound card */
> >   priv->pdev = pdev;
> >   priv->card.dev = >dev;
> > - priv->card.name = priv->name;
> > + ret = snd_soc_of_parse_card_name(>card, "model");
> > + if (ret) {
> > + snprintf(priv->name, sizeof(priv->name), "%s-audio",
> > +  fsl_asoc_card_is_ac97(priv) ? "ac97" :
> > +  (codec_dev ? codec_dev->name : codec_pdev->name));
>
> We can just use dev_name() if codec_dev is struct device *
> Or having a codec_dev_name to cache 

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread Martin K. Petersen


Chris,

> I don't especially want it to be gone, nor can I be sure there are no
> users of what is as far as I can tell a working piece of code. I can
> tell you that I never hear about it (other than the odd patch),
> whereas I do get emails out of the blue for some of my other (much
> smaller) stuff which clearly has users. I'd be just as happy for this
> to be orphaned or for nothing to happen to it.
>
> Honestly, I am totally ambivalent as to what happens to this code.
> Martin, however, clearly cares enough to have asked me to supply a
> patch to remove it.

I love it when people take ownership of old drivers. I think it's
wonderful that Finn and others are on the ball when it comes to the 5380
family. I don't care how old things are as long as they are being
actively used.

I am also very happy to keep things in the tree as long as there is a
healthy community around them. However, keeping code around is not
free. Core interfaces change frequently. Nobody enjoys having to tweak
host templates for 50 devices they have never even heard about. Also, we
now live in a reality where there is a constant barrage of build bots
and code analyzers sending mail. So the effective cost of keeping code
around in the tree is going up. I get a substantial amount of code
analysis mail about drivers nobody have touched in a decade or more.

Consequently, I am much more inclined to remove drivers than I have been
in the past. But I am also very happy to bring them back if somebody
uses them or - even better - are willing to step up and maintain them.

I don't particularly like the notion of a driver being orphaned because
all that really means is that the driver transitions from being (at
least partially) somebody else's problem to being mine and mine alone.

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread Martin K. Petersen


Finn,

> I haven't used this driver for a long time, but I still own PowerMacs
> with firewire, and I know I'm not the only one.

I also have old 1394 hardware kicking around in the basement. But having
worked with FireWire shared storage targets in the past, I have zero
desire to ever touch any of that again.

I could understand an objection if we were to entertain removing
sbp2. But really, how many people are setting up FireWire targets?

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread Finn Thain
On Tue, 16 Jun 2020, Bart Van Assche wrote:

> 
> As far as I know the sbp driver only has had one user ever and that user 
> is no longer user the sbp driver.

So, you estimate the userbase at zero. Can you give a confidence level? 
Actual measurement is hard because when end users encounter breakage, they 
look for quick workarounds before they undertake post mortem, log 
collection, bug reporting, mailing list discussions, analysis etc.

> So why to keep it in the kernel tree?

Answer: for the same reason it was added to the tree.

Here's a different question: "Why remove it from the kernel tree?"

If maintaining this code is a burden, is it not the kind of tax that all 
developers/users pay to all developers/users? Does this driver impose an 
unreasonably high burden for some reason?

The growth of a maintenance burden in general has lead to the invention of 
design patterns and tooling to minize it. So a good argument for removal 
would describe the nature of the problem, because some driver deficiencies 
can be fixed automatically, and some tooling deficiencies can compound an 
otherwise insignificant or common driver deficiency.

There are spin-off benefits from legacy code besides process improvements. 
Building and testing this sort of code has regularly revealed erroneous 
corner cases in commits elsewhere like API changes and refactoring.

Also, legacy code is used by new developers get experience in code 
modernization. And it provides more training material for neural networks 
that need to be taught to recognize patches that raise quality.

Ten or twenty years ago, I doubt that anyone predicted these (and other) 
spin-off benefits. If we can't predict the benefit, how will we project 
the cost, and use that to justify deletion?

Please see also,
http://www.mac.linux-m68k.org/docs/obsolete.php


[PATCH kernel v2] powerpc/powernv/ioda: Return correct error if TCE level allocation failed

2020-06-16 Thread Alexey Kardashevskiy
The iommu_table_ops::xchg_no_kill() callback updates TCE. It is quite
possible that not entire table is allocated if it is huge and multilevel
so xchg may also allocate subtables. If failed, it returns H_HARDWARE
for failed allocation and H_TOO_HARD if it needs it but cannot do because
the alloc parameter is "false" (set when called with MMU=off to force
retry with MMU=on).

The problem is that having separate errors only matters in real mode
(MMU=off) but the only caller with alloc="false" does not check the exact
error code and simply returns H_TOO_HARD; and for every other mode
alloc is "true". Also, the function is also called from the ioctl()
handler of the VFIO SPAPR TCE IOMMU subdriver which does not expect
hypervisor error codes (H_xxx) and will expose them to the userspace.

This converts wrong error codes to -ENOMEM.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v2:
* return -ENOMEM vs. -1
---
 arch/powerpc/platforms/powernv/pci-ioda-tce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c 
b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index f923359d8afc..5218f5da2737 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -166,7 +166,7 @@ int pnv_tce_xchg(struct iommu_table *tbl, long index,
if (!ptce) {
ptce = pnv_tce(tbl, false, idx, alloc);
if (!ptce)
-   return alloc ? H_HARDWARE : H_TOO_HARD;
+   return -ENOMEM;
}
 
if (newtce & TCE_PCI_WRITE)
-- 
2.17.1



Re: [PATCH 2/2] ASoC: fsl-asoc-card: Add MQS support

2020-06-16 Thread Nicolin Chen
On Tue, Jun 16, 2020 at 03:30:37PM +0800, Shengjiu Wang wrote:
> The MQS codec isn't an i2c device, so add a new platform device for it.
> 
> MQS only support playback, so add a new audio map.
> 
> Add there maybe "model" property or no "audio-routing" property insertions

"Add" => "And"

> devicetree, so add some enhancement for these two property.
> 
> Signed-off-by: Shengjiu Wang 
> ---
>  sound/soc/fsl/fsl-asoc-card.c | 70 ++-
>  1 file changed, 52 insertions(+), 18 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> index 00be73900888..2ac8cb9ddd10 100644
> --- a/sound/soc/fsl/fsl-asoc-card.c
> +++ b/sound/soc/fsl/fsl-asoc-card.c

> @@ -482,6 +489,7 @@ static int fsl_asoc_card_probe(struct platform_device 
> *pdev)
>  {
>   struct device_node *cpu_np, *codec_np, *asrc_np;
>   struct device_node *np = pdev->dev.of_node;
> + struct platform_device *codec_pdev = NULL; /* used for non i2c device*/

Having both codec_pdev and codec_dev duplicates things. Actually
only a couple of places really need "codec_dev" -- most of them
need codec_dev->dev pointer instead. So we could have a cleanup:

-   struct i2c_client *codec_dev;
+   struct device *codec_dev = NULL;

> @@ -512,10 +520,13 @@ static int fsl_asoc_card_probe(struct platform_device 
> *pdev)
>   }
>  
>   codec_np = of_parse_phandle(np, "audio-codec", 0);
> - if (codec_np)
> + if (codec_np) {
>   codec_dev = of_find_i2c_device_by_node(codec_np);
> - else
> + if (!codec_dev)
> + codec_pdev = of_find_device_by_node(codec_np);
> + } else {
>   codec_dev = NULL;
> + }

Here can have something like (feel free to simplify):

if (codec_np) {
struct platform_device *codec_pdev;
struct i2c_client *codec_i2c;

codec_i2c = of_find_i2c_device_by_node(codec_np);
if (codec_i2c)
codec_dev = _i2c->dev;

if (!codec_dev) {
codec_pdev = of_find_device_by_node(codec_np);
codec_dev = _pdev->dev;
}
}
>   asrc_np = of_parse_phandle(np, "audio-asrc", 0);
>   if (asrc_np)
> @@ -525,6 +536,13 @@ static int fsl_asoc_card_probe(struct platform_device 
> *pdev)
>   if (codec_dev) {
>   struct clk *codec_clk = clk_get(_dev->dev, NULL);

Then here:

-   struct clk *codec_clk = clk_get(_dev->dev, NULL);
+   struct clk *codec_clk = clk_get(codec_dev, NULL);

> @@ -538,6 +556,11 @@ static int fsl_asoc_card_probe(struct platform_device 
> *pdev)
>   /* Assign a default DAI format, and allow each card to overwrite it */
>   priv->dai_fmt = DAI_FMT_BASE;
>  
> + memcpy(priv->dai_link, fsl_asoc_card_dai,
> +sizeof(struct snd_soc_dai_link) * ARRAY_SIZE(priv->dai_link));

> @@ -573,13 +596,25 @@ static int fsl_asoc_card_probe(struct platform_device 
> *pdev)
>   codec_dai_name = "ac97-hifi";
>   priv->card.set_bias_level = NULL;
>   priv->dai_fmt = SND_SOC_DAIFMT_AC97;
> + priv->card.dapm_routes = audio_map_ac97;
> + priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_ac97);
> + } else if (of_device_is_compatible(np, "fsl,imx-audio-mqs")) {
> + codec_dai_name = "fsl-mqs-dai";
> + priv->card.set_bias_level = NULL;
> + priv->dai_fmt = SND_SOC_DAIFMT_LEFT_J |
> + SND_SOC_DAIFMT_CBS_CFS |
> + SND_SOC_DAIFMT_NB_NF;
> + priv->dai_link[1].dpcm_playback = 1;
> + priv->dai_link[2].dpcm_playback = 1;

dpcm_playback = 1? That's the default value in fsl_asoc_card_dai.

> @@ -601,19 +636,18 @@ static int fsl_asoc_card_probe(struct platform_device 
> *pdev)
>   priv->cpu_priv.sysclk_id[0] = FSL_SAI_CLK_MAST1;
>   }
>  
> - snprintf(priv->name, sizeof(priv->name), "%s-audio",
> -  fsl_asoc_card_is_ac97(priv) ? "ac97" :
> -  codec_dev->name);
> -
>   /* Initialize sound card */
>   priv->pdev = pdev;
>   priv->card.dev = >dev;
> - priv->card.name = priv->name;
> + ret = snd_soc_of_parse_card_name(>card, "model");
> + if (ret) {
> + snprintf(priv->name, sizeof(priv->name), "%s-audio",
> +  fsl_asoc_card_is_ac97(priv) ? "ac97" :
> +  (codec_dev ? codec_dev->name : codec_pdev->name));

We can just use dev_name() if codec_dev is struct device *
Or having a codec_dev_name to cache codec_pdev/i2c->name.

> - ret = snd_soc_of_parse_audio_routing(>card, "audio-routing");
> - if (ret) {
> - dev_err(>dev, "failed to parse audio-routing: %d\n", ret);
> - goto asrc_fail;
> + if (of_property_read_bool(np, "audio-routing")) {
> + ret = 

Re: powerpc/pci: [PATCH 1/1 V3] PCIE PHB reset

2020-06-16 Thread Oliver O'Halloran
On Tue, Jun 16, 2020 at 9:55 PM Michael Ellerman  wrote:
>
> wenxi...@linux.vnet.ibm.com writes:
> > From: Wen Xiong 
> >
> > Several device drivers hit EEH(Extended Error handling) when triggering
> > kdump on Pseries PowerVM. This patch implemented a reset of the PHBs
> > in pci general code when triggering kdump.
>
> Actually it's in pseries specific PCI code, and the reset is done in the
> 2nd kernel as it boots, not when triggering the kdump.
>
> You're doing it as a:
>
>   machine_postcore_initcall(pseries, pseries_phb_reset);
>
> But we do the EEH initialisation in:
>
>   core_initcall_sync(eeh_init);
>
> Which happens first.
>
> So it seems to me that this should be called from pseries_eeh_init().

This happens to use some of the same RTAS calls as EEH, but it's
entirely orthogonal to it. Wedging the two together doesn't make any
real sense IMO since this should be usable even with !CONFIG_EEH.

> That would isolate the code in the right place, and allow you to use the
> existing ibm_get_config_addr_info.
>
> You probably can't use pseries_eeh_get_pe_addr(), because you won't have
> a "pe" structure yet.
>
> Instead you should add a helper that does the core of that logic but
> accepts config_addr/buid as parameters, and then have your code and
> pseries_eeh_get_pe_addr() call that.

I have a patch in my next pile of eeh reworks which kills off
pseries_eeh_get_pe_addr() entirely. It's used to implement
eeh_ops->get_pe_addr for pseries, but the only caller of
->get_pe_addr() is in pseries EEH code and the powernv version is a
stub so I was going to drop it from EEH ops and fold it into the
caller. We could do that in this patch, but it's just going to create
a merge conflict for you to deal with. Up to you.

> *snip*
> > + list_for_each_entry(phb, _list, list_node) {
> > + config_addr = pseries_get_pdn_addr(phb);
> > + if (config_addr == -1)
> > + continue;
> > +
> > + ret = rtas_call(ibm_set_slot_reset, 4, 1, NULL,
> > + config_addr, BUID_HI(phb->buid),
> > + BUID_LO(phb->buid), EEH_RESET_FUNDAMENTAL);
> > +
> > + /* If fundamental-reset not supported, try hot-reset 
> > */
> > + if (ret == -8)
>
> Where does -8 come from?

There's a comment right there.

It could be better explained I suppose, but you need to read
PAPR/LoPAPR to make sense of anything RTAS so what's it really buying
you?

> Oh I see, it's copied from pseries_eeh_reset().
> > + ret = rtas_call(ibm_set_slot_reset, 4, 1, 
> > NULL,
> > + config_addr, BUID_HI(phb->buid),
> > + BUID_LO(phb->buid), EEH_RESET_HOT);
> > +
> > + if (ret) {
> > + pr_err("%s: PHB#%x-PE# failed with rtas_call 
> > activate reset=%d\n",
>   ^
>   again missing PE number.
>
> > + __func__, phb->global_number, ret);
> > + continue;
> > + }
> > + }
> > + msleep(EEH_PE_RST_SETTLE_TIME);
>
> So that loop is basically a copy of pseries_eeh_reset() but with the
> sleep hoisted out of the loop.
>
> I'd really prefer to see that refactored into a helper that takes the
> config_addr and buid and doesn't do the sleep.
>
> Then this loop could call that helper, and so could pseries_eeh_reset().

That's better so long as we're not requiring CONFIG_EEH being
selected. pseries_eeh_reset() uses the rtas token variables
initialised in pseries_eeh_init() which are static to the file so
they'd need to be initialised somewhere common.


Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Matthew Wilcox
On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote:
> On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > >  v4:
> > >   - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > > so that it can be backported to stable.
> > >   - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > > now as there can be a bit more discussion on what is best. It will be
> > > introduced as a separate patch later on after this one is merged.
> > 
> > To this larger audience and last week without reply:
> > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
> > 
> > Are there _any_ fastpath uses of kfree or vfree?
> 
> I'd consider kfree performance critical for cases where it is called
> under locks. If possible the kfree is moved outside of the critical
> section, but we have rbtrees or lists that get deleted under locks and
> restructuring the code to do eg. splice and free it outside of the lock
> is not always possible.

Not just performance critical, but correctness critical.  Since kvfree()
may allocate from the vmalloc allocator, I really think that kvfree()
should assert that it's !in_atomic().  Otherwise we can get into trouble
if we end up calling vfree() and have to take the mutex.


Re: [PATCH kernel] powerpc/powernv/ioda: Return correct error if TCE level allocation failed

2020-06-16 Thread Michael Ellerman
Alexey Kardashevskiy  writes:
> The iommu_table_ops::xchg_no_kill() callback updates TCE. It is quite
> possible that not entire table is allocated if it is huge and multilevel
> so xchg may also allocate subtables. If failed, it returns H_HARDWARE
> for failed allocation and H_TOO_HARD if it needs it but cannot do because
> the alloc parameter is "false" (set when called with MMU=off to force
> retry with MMU=on).
>
> The problem is that having separate errors only matters in real mode
> (MMU=off) but the only caller with alloc="false" does not check the exact
> error code and simply returns H_TOO_HARD; and for every other mode
> alloc is "true". Also, the function is also called from the ioctl()
> handler of the VFIO SPAPR TCE IOMMU subdriver which does not expect
> hypervisor error codes (H_xxx) and will expose them to the userspace.
>
> This converts wrong error codes to a simple -1.
>
> Signed-off-by: Alexey Kardashevskiy 
> ---
>
> I could make it "return alloc ? -ENOMEM : -EBUSY" but
> is EBUSY a good match for H_TOO_HARD?

I think -EAGAIN would be the best match.

But it would be simpler if it just returned -ENOMEM always. In both
cases the problem is that the function needs to allocate memory but
couldn't.

If a caller passes alloc=false, it knows that, so if it sees ENOMEM it
can retry with alloc=true.

cheers


Re: [PATCH 2/2] ASoC: fsl_spdif: Add support for imx6sx platform

2020-06-16 Thread Nicolin Chen
On Tue, Jun 16, 2020 at 02:42:41PM +0800, Shengjiu Wang wrote:
> The one difference on imx6sx platform is that the root clock
> is shared with ASRC module, so we add a new flags "ind_root_clk"
> which means the root clock is independent, then we will not
> do the clk_set_rate and clk_round_rate to avoid impact ASRC
> module usage.
> 
> As add a new flags, we include the soc specific data struct.
> 
> Signed-off-by: Shengjiu Wang 
> ---
>  sound/soc/fsl/fsl_spdif.c | 43 +++
>  1 file changed, 39 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
> index 1b2e516f9162..00e06803d32f 100644
> --- a/sound/soc/fsl/fsl_spdif.c
> +++ b/sound/soc/fsl/fsl_spdif.c
> @@ -42,6 +42,17 @@ static u8 srpc_dpll_locked[] = { 0x0, 0x1, 0x2, 0x3, 0x4, 
> 0xa, 0xb };
>  
>  #define DEFAULT_RXCLK_SRC1
>  
> +/**
> + * struct fsl_spdif_soc_data: soc specific data
> + *
> + * @imx: for imx platform
> + * @ind_root_clk: flag for round clk rate
> + */
> +struct fsl_spdif_soc_data {
> + bool imx;
> + bool ind_root_clk;

"ind" doesn't look very straightforward; maybe "shared_root_clock"?

And for its comments:
* @shared_root_clock: flag of sharing a clock source with others;
* so the driver shouldn't set root clock rate

> +};
> +
>  /*
>   * SPDIF control structure
>   * Defines channel status, subcode and Q sub
> @@ -93,6 +104,7 @@ struct fsl_spdif_priv {
>   struct snd_soc_dai_driver cpu_dai_drv;
>   struct platform_device *pdev;
>   struct regmap *regmap;
> + const struct fsl_spdif_soc_data *soc;

Looks better if we move it to the top of the list :)

> @@ -421,7 +448,7 @@ static int spdif_set_sample_rate(struct snd_pcm_substream 
> *substream,
>   sysclk_df = spdif_priv->sysclk_df[rate];
>  
>   /* Don't mess up the clocks from other modules */
> - if (clk != STC_TXCLK_SPDIF_ROOT)
> + if (clk != STC_TXCLK_SPDIF_ROOT || !spdif_priv->soc->ind_root_clk)
>   goto clk_set_bypass;
>  
>   /* The S/PDIF block needs a clock of 64 * fs * txclk_df */
> @@ -1186,7 +1213,8 @@ static int fsl_spdif_probe_txclk(struct fsl_spdif_priv 
> *spdif_priv,
>   continue;
>  
>   ret = fsl_spdif_txclk_caldiv(spdif_priv, clk, savesub, index,
> -  i == STC_TXCLK_SPDIF_ROOT);
> +  i == STC_TXCLK_SPDIF_ROOT &&
> +  spdif_priv->soc->ind_root_clk);

Having more than one place that checks the condition, we can add:

/* Check if clk is a root clock that does not share clock source with others */
static inline bool fsl_spdif_can_set_clk_rate(struct fsl_spdif_priv *spdif, int 
clk)
{
return (clk == STC_TXCLK_SPDIF_ROOT) && !spdif->soc->shared_root_clock;
}


Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-16 Thread Fenghua Yu
Hi, Peter,

On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
> 
> > Or do you suggest to add a random new flag in struct thread_info instead
> > of a TIF flag?
> 
> Why thread_info? What's wrong with something simple like the below. It
> takes a bit from the 'strictly current' flags word.
> 
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index b62e6aaf28f0..fca830b97055 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -801,6 +801,9 @@ struct task_struct {
>   /* Stalled due to lack of memory */
>   unsignedin_memstall:1;
>  #endif
> +#ifdef CONFIG_PCI_PASID
> + unsignedhas_valid_pasid:1;
> +#endif
>  
>   unsigned long   atomic_flags; /* Flags requiring atomic 
> access. */
>  
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 142b23645d82..10b3891be99e 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -955,6 +955,10 @@ static struct task_struct *dup_task_struct(struct 
> task_struct *orig, int node)
>   tsk->use_memdelay = 0;
>  #endif
>  
> +#ifdef CONFIG_PCI_PASID
> + tsk->has_valid_pasid = 0;
> +#endif
> +
>  #ifdef CONFIG_MEMCG
>   tsk->active_memcg = NULL;
>  #endif

Can I add "Signed-off-by: Peter Zijlstra "
to this patch? I will send this patch in the next version of the series.

Thanks.

-Fenghua


Re: [PATCH] powerpc/8xx: use pmd_off() to access a PMD entry in pte_update()

2020-06-16 Thread Michael Ellerman
Andrew Morton  writes:
> On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport  wrote:
>
>> From: Mike Rapoport 
>> 
>> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
>> level to access a PMD entry. Since 8xx has only 2-level page table this can
>> be simplified with pmd_off() shortcut.
>> 
>> Replace explicit unfolding with pmd_off() and drop defines of pgd_index()
>> and pgd_offset() that are no longer needed.
>> 
>> Signed-off-by: Mike Rapoport 
>> ---
>> 
>> I think it's powerpc material, but I won't mind if Andrew picks it up :)
>
> Via the powerpc tree would be better, please.

I'll take it into next for v5.9, unless there's a reason it needs to go
into v5.8.

cheers


Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread David Sterba
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> >  v4:
> >   - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> >   - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > now as there can be a bit more discussion on what is best. It will be
> > introduced as a separate patch later on after this one is merged.
> 
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
> 
> Are there _any_ fastpath uses of kfree or vfree?

I'd consider kfree performance critical for cases where it is called
under locks. If possible the kfree is moved outside of the critical
section, but we have rbtrees or lists that get deleted under locks and
restructuring the code to do eg. splice and free it outside of the lock
is not always possible.


[powerpc:fixes-test] BUILD SUCCESS 0bdcfa182506526fbe4e088ff9ca86a31b81828d

2020-06-16 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git  
fixes-test
branch HEAD: 0bdcfa182506526fbe4e088ff9ca86a31b81828d  powerpc/64s: Fix KVM 
interrupt using wrong save area

elapsed time: 491m

configs tested: 87
configs skipped: 104

The following configs have been built successfully.
More configs may be tested in the coming days.

arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm axm55xx_defconfig
mips bigsur_defconfig
mips  bmips_stb_defconfig
shmigor_defconfig
i386  allnoconfig
i386defconfig
i386  debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a015-20200615
i386 randconfig-a011-20200615
i386 randconfig-a014-20200615
i386 randconfig-a013-20200615
i386 randconfig-a016-20200615
i386 randconfig-a012-20200615
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64   rhel
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


[powerpc:next-test] BUILD SUCCESS b2f7aff54d10f344bc8424ab98d29e028486ba26

2020-06-16 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git  
next-test
branch HEAD: b2f7aff54d10f344bc8424ab98d29e028486ba26  powerpc/ptdump: Fix 
build failure in hashpagetable.c

elapsed time: 489m

configs tested: 98
configs skipped: 105

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
sh   secureedge5410_defconfig
mips   capcella_defconfig
sparc64  alldefconfig
arm s3c2410_defconfig
arc  axs103_defconfig
powerpc  pasemi_defconfig
mips bigsur_defconfig
arm   cns3420vb_defconfig
i386  allnoconfig
i386defconfig
i386  debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a006-20200615
i386 randconfig-a002-20200615
i386 randconfig-a001-20200615
i386 randconfig-a004-20200615
i386 randconfig-a005-20200615
i386 randconfig-a003-20200615
x86_64   randconfig-a015-20200615
x86_64   randconfig-a011-20200615
x86_64   randconfig-a016-20200615
x86_64   randconfig-a012-20200615
x86_64   randconfig-a014-20200615
x86_64   randconfig-a013-20200615
i386 randconfig-a015-20200615
i386 randconfig-a011-20200615
i386 randconfig-a014-20200615
i386 randconfig-a013-20200615
i386 randconfig-a016-20200615
i386 randconfig-a012-20200615
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
umallnoconfig
um  defconfig
um   allmodconfig
um   allyesconfig
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec
x86_64   rhel
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


[powerpc:merge] BUILD SUCCESS c3405d517d606e965030026daec198d314f20195

2020-06-16 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git  
merge
branch HEAD: c3405d517d606e965030026daec198d314f20195  Automatic merge of 
'master', 'next' and 'fixes' (2020-06-17 00:21)

elapsed time: 490m

configs tested: 108
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm pxa_defconfig
um   x86_64_defconfig
mips  pic32mzda_defconfig
arm   versatile_defconfig
ia64  gensparse_defconfig
mips   ip28_defconfig
mips   ip27_defconfig
c6xevmc6678_defconfig
arm   netwinder_defconfig
sh   se7721_defconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
i386  allnoconfig
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a006-20200615
i386 randconfig-a002-20200615
i386 randconfig-a001-20200615
i386 randconfig-a004-20200615
i386 randconfig-a005-20200615
i386 randconfig-a003-20200615
x86_64   randconfig-a015-20200615
x86_64   randconfig-a011-20200615
x86_64   randconfig-a016-20200615
x86_64   randconfig-a012-20200615
x86_64   randconfig-a014-20200615
x86_64   randconfig-a013-20200615
i386 randconfig-a015-20200615
i386 randconfig-a011-20200615
i386 randconfig-a014-20200615
i386 randconfig-a013-20200615
i386 randconfig-a016-20200615
i386 randconfig-a012-20200615
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64  

Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Matthew Wilcox
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
> 
> Are there _any_ fastpath uses of kfree or vfree?

I worked on adding a 'free' a couple of years ago.  That was capable
of freeing percpu, vmalloc, kmalloc and alloc_pages memory.  I ran into
trouble when I tried to free kmem_cache_alloc memory -- it works for slab
and slub, but not slob (because slob needs the size from the kmem_cache).

My motivation for this was to change kfree_rcu() to just free_rcu().

> To eliminate these mispairings at a runtime cost of four
> comparisons, should the kfree/vfree/kvfree/kfree_const
> functions be consolidated into a single kfree?

I would say to leave kfree() alone and just introduce free() as a new
default.  There's some weird places in the kernel that have a 'free'
symbol of their own, but those should be renamed anyway.


Re: [PATCH] tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes

2020-06-16 Thread Jarkko Sakkinen
On Fri, Jun 05, 2020 at 04:37:19PM +1000, David Gibson wrote:
> The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued,
> which will need the use of the internal command/response buffer.  But,
> we're issuing this *before* we've waited to make sure that buffer is
> allocated.
> 
> This can result in intermittent failures to probe if the hypervisor / TPM
> implementation doesn't respond quickly enough.  I find it fails almost
> every time with an 8 vcpu guest under KVM with software emulated TPM.
> 
> Fixes: 18b3670d79ae9 "tpm: ibmvtpm: Add support for TPM2"

Should be Fixes: 18b3670d79ae ("tpm: ibmvtpm: Add support for TPM2")

Also briefly state what the commit does, not just the problem
description. The code change looks legit.

Please send v2 with these changes.

> Signed-off-by: David Gibson 
> ---
>  drivers/char/tpm/tpm_ibmvtpm.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> index 09fe45246b8c..994385bf37c0 100644
> --- a/drivers/char/tpm/tpm_ibmvtpm.c
> +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> @@ -683,13 +683,6 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
>   if (rc)
>   goto init_irq_cleanup;
>  
> - if (!strcmp(id->compat, "IBM,vtpm20")) {
> - chip->flags |= TPM_CHIP_FLAG_TPM2;
> - rc = tpm2_get_cc_attrs_tbl(chip);
> - if (rc)
> - goto init_irq_cleanup;
> - }
> -
>   if (!wait_event_timeout(ibmvtpm->crq_queue.wq,
>   ibmvtpm->rtce_buf != NULL,
>   HZ)) {
> @@ -697,6 +690,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
>   goto init_irq_cleanup;
>   }
>  
> + if (!strcmp(id->compat, "IBM,vtpm20")) {
> + chip->flags |= TPM_CHIP_FLAG_TPM2;
> + rc = tpm2_get_cc_attrs_tbl(chip);
> + if (rc)
> + goto init_irq_cleanup;
> + }
> +
>   return tpm_chip_register(chip);
>  init_irq_cleanup:
>   do {
> -- 
> 2.26.2
> 

/Jarkko


Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread James Bottomley
On Tue, 2020-06-16 at 14:13 +, Johannes Thumshirn wrote:
> On 16/06/2020 16:09, Bart Van Assche wrote:
> > On 2020-06-16 02:42, Finn Thain wrote:
> > > Martin said, "I'd appreciate a patch to remove it"
> > > 
> > > And Bart said, "do you want to keep this driver in the kernel
> > > tree?"
> > > 
> > > AFAICT both comments are quite ambiguous. I don't see an
> > > actionable request, just an expression of interest from people
> > > doing their jobs.
> > > 
> > > Note well: there is no pay check associated with having a
> > > MAINTAINERS file 
> > > entry.
> > 
> > Hi Finn,
> > 
> > As far as I know the sbp driver only has had one user ever and that
> > user is no longer user the sbp driver. So why to keep it in the
> > kernel tree? Restoring a kernel driver can be easy - the first step
> > is a "git revert".
> 
> Why not move the driver to drivers/staging for 2 or 3 kernel releases
> and if noone steps up, delete it?

Because that's pretty much the worst of all worlds: If the driver is
simply going orphaned it can stay where it is to avoid confusion.  If
it's being removed, it's better to remove it from where it is because
that makes the patch to restore it easy to find.

Chris, the thing is this: if this driver has just one user on a stable
distro who complains about its removal six months to two years from
now, Linus will descend on us from a great height (which won't matter
to you, since you'll be long gone).  This makes everyone very wary of
outright removal.  If you're really, really sure it has no users, it
can be deleted, but if there's the slightest chance it has just one, it
should get orphaned.

James



Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Waiman Long

On 6/16/20 2:53 PM, Joe Perches wrote:

On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:

  v4:
   - Break out the memzero_explicit() change as suggested by Dan Carpenter
 so that it can be backported to stable.
   - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
 now as there can be a bit more discussion on what is best. It will be
 introduced as a separate patch later on after this one is merged.

To this larger audience and last week without reply:
https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/

Are there _any_ fastpath uses of kfree or vfree?

Many patches have been posted recently to fix mispairings
of specific types of alloc and free functions.

To eliminate these mispairings at a runtime cost of four
comparisons, should the kfree/vfree/kvfree/kfree_const
functions be consolidated into a single kfree?

Something like the below:

void kfree(const void *addr)
{
if (is_kernel_rodata((unsigned long)addr))
return;

if (is_vmalloc_addr(addr))
_vfree(addr);
else
_kfree(addr);
}

#define kvfree  kfree
#define vfree   kfree
#define kfree_const kfree


How about adding CONFIG_DEBUG_VM code to check for invalid address 
ranges in kfree() and vfree()? By doing this, we can catch unmatched 
pairing in debug mode, but won't have the overhead when debug mode is off.


Thought?

Cheers,
Longman



Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Jason A. Donenfeld
On Tue, Jun 16, 2020 at 12:54 PM Joe Perches  wrote:
>
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> >  v4:
> >   - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> >   - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> > now as there can be a bit more discussion on what is best. It will be
> > introduced as a separate patch later on after this one is merged.
>
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?

The networking stack has various places where there will be a quick
kmalloc followed by a kfree for an incoming or outgoing packet. One
place that comes to mind would be esp_alloc_tmp, which does a quick
allocation of some temporary kmalloc memory, processes some packet
things inside of that, and then frees it, sometimes in the same
function, and sometimes later in an async callback. I don't know how
"fastpath" you consider this, but usually packet processing is
something people want to do with minimal overhead, considering how
fast NICs are these days.


Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Waiman Long

On 6/16/20 2:53 PM, Joe Perches wrote:

On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:

  v4:
   - Break out the memzero_explicit() change as suggested by Dan Carpenter
 so that it can be backported to stable.
   - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
 now as there can be a bit more discussion on what is best. It will be
 introduced as a separate patch later on after this one is merged.

To this larger audience and last week without reply:
https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/

Are there _any_ fastpath uses of kfree or vfree?


I am not sure about that, but both of them can be slow.




Many patches have been posted recently to fix mispairings
of specific types of alloc and free functions.

To eliminate these mispairings at a runtime cost of four
comparisons, should the kfree/vfree/kvfree/kfree_const
functions be consolidated into a single kfree?

Something like the below:

void kfree(const void *addr)
{
if (is_kernel_rodata((unsigned long)addr))
return;

if (is_vmalloc_addr(addr))
_vfree(addr);
else
_kfree(addr);
}

is_kernel_rodata() is inlined, but is_vmalloc_addr() isn't. So the 
overhead can be a bit bigger.


Cheers,
Longman



Re: [PATCH] powerpc/8xx: use pmd_off() to access a PMD entry in pte_update()

2020-06-16 Thread Andrew Morton
On Mon, 15 Jun 2020 12:22:29 +0300 Mike Rapoport  wrote:

> From: Mike Rapoport 
> 
> The pte_update() implementation for PPC_8xx unfolds page table from the PGD
> level to access a PMD entry. Since 8xx has only 2-level page table this can
> be simplified with pmd_off() shortcut.
> 
> Replace explicit unfolding with pmd_off() and drop defines of pgd_index()
> and pgd_offset() that are no longer needed.
> 
> Signed-off-by: Mike Rapoport 
> ---
> 
> I think it's powerpc material, but I won't mind if Andrew picks it up :)

Via the powerpc tree would be better, please.


Re: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

2020-06-16 Thread Bhupesh Sharma
Hello Bharat,

On Wed, Jun 10, 2020 at 10:17 PM Bharat Gooty  wrote:
>
> Hello Bhupesh,
> V6 patch set on Linux 5.7, did not help.
> I have applied makedump file
> http://lists.infradead.org/pipermail/kexec/2019-November/023963.html changes
> also (makedump-1.6.6). Tried to apply it on makedumpfile 1.6.7.  Patch set_2
> failed. Would like to know, if you have V5 patch set for makedump file
> changes. With makedump 1.6.6, able to collect the vmore file.
> I used latest crash utility
> (https://www.redhat.com/archives/crash-utility/2019-November/msg00014.html
> changes are present)
> When I used crash utility, following is the error:
>
> Thanks,
> -Bharat
>
>
> -Original Message-
> From: Scott Branden [mailto:scott.bran...@broadcom.com]
> Sent: Thursday, April 30, 2020 4:34 AM
> To: Bhupesh Sharma; Amit Kachhap
> Cc: Mark Rutland; x...@kernel.org; Will Deacon; Linux Doc Mailing List;
> Catalin Marinas; Ard Biesheuvel; kexec mailing list; Linux Kernel Mailing
> List; Kazuhito Hagio; James Morse; Dave Anderson; bhupesh linux;
> linuxppc-dev@lists.ozlabs.org; linux-arm-kernel; Steve Capper; Ray Jui;
> Bharat Gooty
> Subject: Re: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ
> in vmcoreinfo
>
> Hi Bhupesh,
>
> On 2020-02-23 10:25 p.m., Bhupesh Sharma wrote:
> > Hi Amit,
> >
> > On Fri, Feb 21, 2020 at 2:36 PM Amit Kachhap  wrote:
> >> Hi Bhupesh,
> >>
> >> On 1/13/20 5:44 PM, Bhupesh Sharma wrote:
> >>> Hi James,
> >>>
> >>> On 01/11/2020 12:30 AM, Dave Anderson wrote:
>  - Original Message -
> > Hi Bhupesh,
> >
> > On 25/12/2019 19:01, Bhupesh Sharma wrote:
> >> On 12/12/2019 04:02 PM, James Morse wrote:
> >>> On 29/11/2019 19:59, Bhupesh Sharma wrote:
>  vabits_actual variable on arm64 indicates the actual VA space size,
>  and allows a single binary to support both 48-bit and 52-bit VA
>  spaces.
> 
>  If the ARMv8.2-LVA optional feature is present, and we are running
>  with a 64KB page size; then it is possible to use 52-bits of
>  address
>  space for both userspace and kernel addresses. However, any kernel
>  binary that supports 52-bit must also be able to fall back to
>  48-bit
>  at early boot time if the hardware feature is not present.
> 
>  Since TCR_EL1.T1SZ indicates the size offset of the memory region
>  addressed by TTBR1_EL1 (and hence can be used for determining the
>  vabits_actual value) it makes more sense to export the same in
>  vmcoreinfo rather than vabits_actual variable, as the name of the
>  variable can change in future kernel versions, but the
>  architectural
>  constructs like TCR_EL1.T1SZ can be used better to indicate
>  intended
>  specific fields to user-space.
> 
>  User-space utilities like makedumpfile and crash-utility, need to
>  read/write this value from/to vmcoreinfo
> >>> (write?)
> >> Yes, also write so that the vmcoreinfo from an (crashing) arm64
> >> system can
> >> be used for
> >> analysis of the root-cause of panic/crash on say an x86_64 host using
> >> utilities like
> >> crash-utility/gdb.
> > I read this as as "User-space [...] needs to write to vmcoreinfo".
> >>> That's correct. But for writing to vmcore dump in the kdump kernel, we
> >>> need to read the symbols from the vmcoreinfo in the primary kernel.
> >>>
>  for determining if a virtual address lies in the linear map range.
> >>> I think this is a fragile example. The debugger shouldn't need to
> >>> know
> >>> this.
> >> Well that the current user-space utility design, so I am not sure we
> >> can
> >> tweak that too much.
> >>
>  The user-space computation for determining whether an address lies
>  in
>  the linear map range is the same as we have in kernel-space:
> 
>   #define __is_lm_address(addr)(!(((u64)addr) &
>  BIT(vabits_actual -
>   1)))
> >>> This was changed with 14c127c957c1 ("arm64: mm: Flip kernel VA
> >>> space"). If
> >>> user-space
> >>> tools rely on 'knowing' the kernel memory layout, they must have to
> >>> constantly be fixed
> >>> and updated. This is a poor argument for adding this to something
> >>> that
> >>> ends up as ABI.
> >> See above. The user-space has to rely on some ABI/guaranteed
> >> hardware-symbols which can be
> >> used for 'determining' the kernel memory layout.
> > I disagree. Everything and anything in the kernel will change. The
> > ABI rules apply to
> > stuff exposed via syscalls and kernel filesystems. It does not apply
> > to kernel internals,
> > like the memory layout we used yesterday. 14c127c957c1 is a case in
> > point.
> >
> > A debugger trying to rely on this sort of thing would have to 

Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Joe Perches
On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
>  v4:
>   - Break out the memzero_explicit() change as suggested by Dan Carpenter
> so that it can be backported to stable.
>   - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
> now as there can be a bit more discussion on what is best. It will be
> introduced as a separate patch later on after this one is merged.

To this larger audience and last week without reply:
https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/

Are there _any_ fastpath uses of kfree or vfree?

Many patches have been posted recently to fix mispairings
of specific types of alloc and free functions.

To eliminate these mispairings at a runtime cost of four
comparisons, should the kfree/vfree/kvfree/kfree_const
functions be consolidated into a single kfree?

Something like the below:

   void kfree(const void *addr)
   {
if (is_kernel_rodata((unsigned long)addr))
return;

if (is_vmalloc_addr(addr))
_vfree(addr);
else
_kfree(addr);
   }

   #define kvfree   kfree
   #define vfreekfree
   #define kfree_const  kfree




Re: [PATCH v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Waiman Long

On 6/16/20 2:09 PM, Andrew Morton wrote:

On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long  wrote:


As said by Linus:

   A symmetric naming is only helpful if it implies symmetries in use.
   Otherwise it's actively misleading.

   In "kzalloc()", the z is meaningful and an important part of what the
   caller wants.

   In "kzfree()", the z is actively detrimental, because maybe in the
   future we really _might_ want to use that "memfill(0xdeadbeef)" or
   something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the
recently added kvfree_sensitive() and make the intention of the API
more explicit. In addition, memzero_explicit() is used to clear the
memory to make sure that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

   git grep -w --name-only kzfree |\
   xargs sed -i 's/\bkzfree\b/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.

...

--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -186,10 +186,12 @@ void memcg_deactivate_kmem_caches(struct mem_cgroup *, 
struct mem_cgroup *);
   */
  void * __must_check krealloc(const void *, size_t, gfp_t);
  void kfree(const void *);
-void kzfree(const void *);
+void kfree_sensitive(const void *);
  size_t __ksize(const void *);
  size_t ksize(const void *);
  
+#define kzfree(x)	kfree_sensitive(x)	/* For backward compatibility */

+

What was the thinking here?  Is this really necessary?

I suppose we could keep this around for a while to ease migration.  But
not for too long, please.

It should be there just for 1 release cycle. I have broken out the btrfs 
patch to the btrfs list and I didn't make the kzfree to kfree_sensitive 
conversion there as that patch was in front in my patch list. So 
depending on which one lands first, there can be a window where the 
compilation may fail without this workaround. I am going to send out 
another patch in the next release cycle to remove it.


Cheers,
Longman



Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread Johannes Thumshirn
On 16/06/2020 16:09, Bart Van Assche wrote:
> On 2020-06-16 02:42, Finn Thain wrote:
>> Martin said, "I'd appreciate a patch to remove it"
>>
>> And Bart said, "do you want to keep this driver in the kernel tree?"
>>
>> AFAICT both comments are quite ambiguous. I don't see an actionable 
>> request, just an expression of interest from people doing their jobs.
>>
>> Note well: there is no pay check associated with having a MAINTAINERS file 
>> entry.
> 
> Hi Finn,
> 
> As far as I know the sbp driver only has had one user ever and that user
> is no longer user the sbp driver. So why to keep it in the kernel tree?
> Restoring a kernel driver can be easy - the first step is a "git revert".

Why not move the driver to drivers/staging for 2 or 3 kernel releases and if
noone steps up, delete it?

Just my 2 Cents,
Johannes


Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support

2020-06-16 Thread Nathan Chancellor
Hi Michal,

On Tue, Jun 16, 2020 at 04:45:20PM +0200, Michal Simek wrote:
> 
> 
> On 16. 06. 20 2:27, Nathan Chancellor wrote:
> > On Thu, May 21, 2020 at 04:55:52PM +, Christophe Leroy wrote:
> >> From: Michal Simek 
> >>
> >> The latest Xilinx design tools called ISE and EDK has been released in
> >> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
> >> These platforms are no longer supported and tested.
> >>
> >> PowerPC 405/440 port is orphan from 2013 by
> >> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
> >> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and 
> >> maintainership")
> >> that's why it is time to remove the support fot these platforms.
> >>
> >> Signed-off-by: Michal Simek 
> >> Acked-by: Arnd Bergmann 
> >> Signed-off-by: Christophe Leroy 
> > 
> > This patch causes qemu-system-ppc to fail to load ppc44x_defconfig:
> > 
> > $ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc-linux- O=out/ppc 
> > distclean ppc44x_defconfig zImage
> > 
> > $ timeout --foreground 30s unbuffer \
> > qemu-system-ppc \
> > -machine bamboo \
> 
> Did you bisect it that you found that this patch is causing problem for
> you on any bamboo machine?
> 
> Or this was caused by the whole series?
> 
> Thanks,
> Michal

Yes, this conclusion was the result of the following bisect:

$ cat test.sh
#!/usr/bin/env bash

cd "${HOME}"/src/linux || exit 125

set -x

PATH=${HOME}/toolchains/gcc/10.1.0/bin:${PATH} \
make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc-linux- O=out/ppc32 
distclean ppc44x_defconfig zImage || exit 125

"${HOME}"/cbl/github/boot-utils/boot-qemu.sh -a ppc32 -k out/ppc32 -t 30s

$ git bisect start v5.8-rc1 v5.7
...

$ git bisect run test.sh
...

$ git bisect log
# bad: [b3a9e3b9622ae10064826dccb4f7a52bd88c7407] Linux 5.8-rc1
# good: [3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162] Linux 5.7
git bisect start 'v5.8-rc1' 'v5.7'
# good: [ee01c4d72adffb7d424535adf630f2955748fa8b] Merge branch 'akpm' (patches 
from Andrew)
git bisect good ee01c4d72adffb7d424535adf630f2955748fa8b
# bad: [6f2dc3d335457d9c815be9f4fd3dc8eff92fcef7] Merge tag 'dma-mapping-5.8-2' 
of git://git.infradead.org/users/hch/dma-mapping
git bisect bad 6f2dc3d335457d9c815be9f4fd3dc8eff92fcef7
# skip: [828f3e18e1cb98c68fc6db4d5113513d4a267775] Merge tag 'arm-drivers-5.8' 
of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect skip 828f3e18e1cb98c68fc6db4d5113513d4a267775
# good: [c46241a370a61f0f264791abb9fc869016e749ce] powerpc/pkeys: Check vma 
before returning key fault error to the user
git bisect good c46241a370a61f0f264791abb9fc869016e749ce
# good: [3f0be4df50a7854a831c80a74d7cf2cfd61f2fde] Merge tag 
'versatile-dts-v5.8-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into 
arm/dt
git bisect good 3f0be4df50a7854a831c80a74d7cf2cfd61f2fde
# bad: [bd55e792de0844631d34487d43eaf3f13294ebfe] powerpc/module_64: Use 
special stub for _mcount() with -mprofile-kernel
git bisect bad bd55e792de0844631d34487d43eaf3f13294ebfe
# good: [303e6a9ddcdc168e92253c78cdb4bbe1e10d78b3] powerpc/watchpoint: Convert 
thread_struct->hw_brk to an array
git bisect good 303e6a9ddcdc168e92253c78cdb4bbe1e10d78b3
# good: [0755e85570a4615ca674ad6489d44d63916f1f3e] powerpc/xive: Do not expose 
a debugfs file when XIVE is disabled
git bisect good 0755e85570a4615ca674ad6489d44d63916f1f3e
# bad: [b4ac18eead28611ff470d0f47a35c4e0ac080d9c] powerpc/perf/hv-24x7: Fix 
inconsistent output values incase multiple hv-24x7 events run
git bisect bad b4ac18eead28611ff470d0f47a35c4e0ac080d9c
# bad: [3aacaa719b7bf135551cabde2480e8f7bfdf7c7d] powerpc/40x: Don't save CR in 
SPRN_SPRG_SCRATCH6
git bisect bad 3aacaa719b7bf135551cabde2480e8f7bfdf7c7d
# bad: [1b5c0967ab8aa9424cdd5108de4e055d8aeaa9d0] powerpc/40x: Remove support 
for IBM 403GCX
git bisect bad 1b5c0967ab8aa9424cdd5108de4e055d8aeaa9d0
# good: [0bdad33d6bd7b80722e2f9e588d3d7c6d6e34978] powerpc/64: Refactor 
interrupt exit irq disabling sequence
git bisect good 0bdad33d6bd7b80722e2f9e588d3d7c6d6e34978
# bad: [2c74e2586bb96012ffc05f1c819b05d9cad86d6e] powerpc/40x: Rework 40x PTE 
access and TLB miss
git bisect bad 2c74e2586bb96012ffc05f1c819b05d9cad86d6e
# bad: [7ade8495dcfd788a76e6877c9ea86f5207369ea4] powerpc: Remove Xilinx 
PPC405/PPC440 support
git bisect bad 7ade8495dcfd788a76e6877c9ea86f5207369ea4
# first bad commit: [7ade8495dcfd788a76e6877c9ea86f5207369ea4] powerpc: Remove 
Xilinx PPC405/PPC440 support


Re: [PATCH v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Andrew Morton
On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long  wrote:

> As said by Linus:
> 
>   A symmetric naming is only helpful if it implies symmetries in use.
>   Otherwise it's actively misleading.
> 
>   In "kzalloc()", the z is meaningful and an important part of what the
>   caller wants.
> 
>   In "kzfree()", the z is actively detrimental, because maybe in the
>   future we really _might_ want to use that "memfill(0xdeadbeef)" or
>   something. The "zero" part of the interface isn't even _relevant_.
> 
> The main reason that kzfree() exists is to clear sensitive information
> that should not be leaked to other future users of the same memory
> objects.
> 
> Rename kzfree() to kfree_sensitive() to follow the example of the
> recently added kvfree_sensitive() and make the intention of the API
> more explicit. In addition, memzero_explicit() is used to clear the
> memory to make sure that it won't get optimized away by the compiler.
> 
> The renaming is done by using the command sequence:
> 
>   git grep -w --name-only kzfree |\
>   xargs sed -i 's/\bkzfree\b/kfree_sensitive/'
> 
> followed by some editing of the kfree_sensitive() kerneldoc and adding
> a kzfree backward compatibility macro in slab.h.
> 
> ...
>
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -186,10 +186,12 @@ void memcg_deactivate_kmem_caches(struct mem_cgroup *, 
> struct mem_cgroup *);
>   */
>  void * __must_check krealloc(const void *, size_t, gfp_t);
>  void kfree(const void *);
> -void kzfree(const void *);
> +void kfree_sensitive(const void *);
>  size_t __ksize(const void *);
>  size_t ksize(const void *);
>  
> +#define kzfree(x)kfree_sensitive(x)  /* For backward compatibility */
> +

What was the thinking here?  Is this really necessary?

I suppose we could keep this around for a while to ease migration.  But
not for too long, please.


Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread Chris Boot
On 16/06/2020 16:34, James Bottomley wrote:
> On Tue, 2020-06-16 at 14:13 +, Johannes Thumshirn wrote:
>> On 16/06/2020 16:09, Bart Van Assche wrote:
>>> On 2020-06-16 02:42, Finn Thain wrote:
 Martin said, "I'd appreciate a patch to remove it"

 And Bart said, "do you want to keep this driver in the kernel
 tree?"

 AFAICT both comments are quite ambiguous. I don't see an
 actionable request, just an expression of interest from people
 doing their jobs.

 Note well: there is no pay check associated with having a
 MAINTAINERS file 
 entry.
>>>
>>> Hi Finn,
>>>
>>> As far as I know the sbp driver only has had one user ever and that
>>> user is no longer user the sbp driver. So why to keep it in the
>>> kernel tree? Restoring a kernel driver can be easy - the first step
>>> is a "git revert".
>>
>> Why not move the driver to drivers/staging for 2 or 3 kernel releases
>> and if noone steps up, delete it?
> 
> Because that's pretty much the worst of all worlds: If the driver is
> simply going orphaned it can stay where it is to avoid confusion.  If
> it's being removed, it's better to remove it from where it is because
> that makes the patch to restore it easy to find.
> 
> Chris, the thing is this: if this driver has just one user on a stable
> distro who complains about its removal six months to two years from
> now, Linus will descend on us from a great height (which won't matter
> to you, since you'll be long gone).  This makes everyone very wary of
> outright removal.  If you're really, really sure it has no users, it
> can be deleted, but if there's the slightest chance it has just one, it
> should get orphaned.

My patch to delete the driver was based on Martin's original request:
https://lore.kernel.org/lkml/yq1img99d4k@ca-mkp.ca.oracle.com/

I don't especially want it to be gone, nor can I be sure there are no
users of what is as far as I can tell a working piece of code. I can
tell you that I never hear about it (other than the odd patch), whereas
I do get emails out of the blue for some of my other (much smaller)
stuff which clearly has users. I'd be just as happy for this to be
orphaned or for nothing to happen to it.

Honestly, I am totally ambivalent as to what happens to this code.
Martin, however, clearly cares enough to have asked me to supply a patch
to remove it.

Cheers,
Chris

-- 
Chris Boot
bo...@boo.tc


Re: [PATCH] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed

2020-06-16 Thread Cédric Le Goater
On 6/12/20 9:02 AM, Cédric Le Goater wrote:
> When a passthrough IO adapter is removed from a pseries machine using
> hash MMU and the XIVE interrupt mode, the POWER hypervisor, pHyp,
> expects the guest OS to have cleared all page table entries related to
> the adapter. If some are still present, the RTAS call which isolates
> the PCI slot returns error 9001 "valid outstanding translations" and
> the removal of the IO adapter fails.
> 
> INTx interrupt numbers need special care because Linux maps the
> interrupts automatically in the Linux interrupt number space. For this
> purpose, record the logical interrupt number of the INTx at the PHB
> level and clear these interrupts when the PCI bus is removed. This
> will also clear all the page table entries of the ESB pages when using
> XIVE.
> 
> Cc: "Oliver O'Halloran" 
> Signed-off-by: Cédric Le Goater 
> ---
> 
>  This deprecates patch :
>  
>  
> http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200429075122.1216388-3-...@kaod.org/

So, this clears the INTx interrupts but, to be more precise, it clears 
4 interrupts that were mapped when the PHB are initialized. These are 
similar to platform interrupts in some ways. They can be of another 
type (GPU, CAPI or OCAPI adapters) and there can be more than 4. 

To cover all cases, we need to analyze the "interrupt-map" properties. 
A v2 is on its way. This feels like I opened a Pandora box..

C. 


 

>  Thanks,
> 
>  arch/powerpc/include/asm/pci-bridge.h |  4 +++
>  arch/powerpc/kernel/pci-common.c  | 45 +++
>  2 files changed, 49 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/pci-bridge.h 
> b/arch/powerpc/include/asm/pci-bridge.h
> index b92e81b256e5..9960dd249079 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -48,6 +48,8 @@ struct pci_controller_ops {
>  
>  /*
>   * Structure of a PCI controller (host bridge)
> + *
> + * @intx: legacy INTx mappings
>   */
>  struct pci_controller {
>   struct pci_bus *bus;
> @@ -127,6 +129,8 @@ struct pci_controller {
>  
>   void *private_data;
>   struct npu *npu;
> +
> + unsigned int intx[PCI_NUM_INTX];
>  };
>  
>  /* These are used for config access before all the PCI probing
> diff --git a/arch/powerpc/kernel/pci-common.c 
> b/arch/powerpc/kernel/pci-common.c
> index be108616a721..8c442627f465 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -353,6 +353,49 @@ struct pci_controller 
> *pci_find_controller_for_domain(int domain_nr)
>   return NULL;
>  }
>  
> +static void pci_intx_register(struct pci_dev *pdev, int virq)
> +{
> + struct pci_controller *phb = pci_bus_to_host(pdev->bus);
> + int i;
> +
> + for (i = 0; i < PCI_NUM_INTX; i++) {
> + /*
> +  * Look for an empty or an equivalent slot, as INTx
> +  * interrupts can be shared between adapters
> +  */
> + if (phb->intx[i] == virq || !phb->intx[i]) {
> + phb->intx[i] = virq;
> + break;
> + }
> + }
> +
> + if (i == PCI_NUM_INTX)
> + pr_err("PCI:%s INTx all mapped\n", pci_name(pdev));
> +}
> +
> +/*
> + * Clearing the mapped INTx interrupts will also clear the underlying
> + * mappings of the ESB pages of the interrupts when under XIVE. It is
> + * a requirement of PowerVM to clear all memory mappings before
> + * removing a PHB.
> + */
> +static void pci_intx_dispose(struct pci_bus *bus)
> +{
> + struct pci_controller *phb = pci_bus_to_host(bus);
> + int i;
> +
> + pr_debug("PCI: Clearing INTx for PHB %04x:%02x...\n",
> +  pci_domain_nr(bus), bus->number);
> + for (i = 0; i < PCI_NUM_INTX; i++)
> + irq_dispose_mapping(phb->intx[i]);
> +}
> +
> +void pcibios_remove_bus(struct pci_bus *bus)
> +{
> + pci_intx_dispose(bus);
> +}
> +EXPORT_SYMBOL_GPL(pcibios_remove_bus);
> +
>  /*
>   * Reads the interrupt pin to determine if interrupt is use by card.
>   * If the interrupt is used, then gets the interrupt line from the
> @@ -401,6 +444,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
>  
>   pci_dev->irq = virq;
>  
> + /* Record all INTx mappings for later removal of a PHB */
> + pci_intx_register(pci_dev, virq);
>   return 0;
>  }
>  
> 



Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

2020-06-16 Thread David Howells
Waiman Long  wrote:

> The kzfree() function is normally used to clear some sensitive
> information, like encryption keys, in the buffer before freeing it back
> to the pool. Memset()

"memset()" is all lowercase.

> is currently used for buffer clearing. However unlikely, there is still a
> non-zero probability

I'd say "a possibility".

> that

and I'd move "in [the] future" here.

> the compiler may choose to optimize away the
> memory clearing especially if LTO is being used in the future. To make sure
> that this optimization will never happen

"in these cases"

> , memzero_explicit(), which is introduced in v3.18, is now used in

"instead of"?

> kzfree() to future-proof it.

Davod



[PATCH v5 1/2] mm/slab: Use memzero_explicit() in kzfree()

2020-06-16 Thread Waiman Long
The kzfree() function is normally used to clear some sensitive
information, like encryption keys, in the buffer before freeing it back
to the pool. Memset() is currently used for buffer clearing. However
unlikely, there is still a non-zero probability that the compiler may
choose to optimize away the memory clearing especially if LTO is being
used in the future. To make sure that this optimization will never
happen, memzero_explicit(), which is introduced in v3.18, is now used
in kzfree() to future-proof it.

Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
Cc: sta...@vger.kernel.org
Acked-by: Michal Hocko 
Signed-off-by: Waiman Long 
---
 mm/slab_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/slab_common.c b/mm/slab_common.c
index 9e72ba224175..37d48a56431d 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1726,7 +1726,7 @@ void kzfree(const void *p)
if (unlikely(ZERO_OR_NULL_PTR(mem)))
return;
ks = ksize(mem);
-   memset(mem, 0, ks);
+   memzero_explicit(mem, ks);
kfree(mem);
 }
 EXPORT_SYMBOL(kzfree);
-- 
2.18.1



[PATCH v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Waiman Long
As said by Linus:

  A symmetric naming is only helpful if it implies symmetries in use.
  Otherwise it's actively misleading.

  In "kzalloc()", the z is meaningful and an important part of what the
  caller wants.

  In "kzfree()", the z is actively detrimental, because maybe in the
  future we really _might_ want to use that "memfill(0xdeadbeef)" or
  something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the
recently added kvfree_sensitive() and make the intention of the API
more explicit. In addition, memzero_explicit() is used to clear the
memory to make sure that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

  git grep -w --name-only kzfree |\
  xargs sed -i 's/\bkzfree\b/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.

Suggested-by: Joe Perches 
Acked-by: David Howells 
Acked-by: Michal Hocko 
Acked-by: Johannes Weiner 
Signed-off-by: Waiman Long 
---
 arch/s390/crypto/prng.c   |  4 +--
 arch/x86/power/hibernate.c|  2 +-
 crypto/adiantum.c |  2 +-
 crypto/ahash.c|  4 +--
 crypto/api.c  |  2 +-
 crypto/asymmetric_keys/verify_pefile.c|  4 +--
 crypto/deflate.c  |  2 +-
 crypto/drbg.c | 10 +++---
 crypto/ecc.c  |  8 ++---
 crypto/ecdh.c |  2 +-
 crypto/gcm.c  |  2 +-
 crypto/gf128mul.c |  4 +--
 crypto/jitterentropy-kcapi.c  |  2 +-
 crypto/rng.c  |  2 +-
 crypto/rsa-pkcs1pad.c |  6 ++--
 crypto/seqiv.c|  2 +-
 crypto/shash.c|  2 +-
 crypto/skcipher.c |  2 +-
 crypto/testmgr.c  |  6 ++--
 crypto/zstd.c |  2 +-
 .../allwinner/sun8i-ce/sun8i-ce-cipher.c  |  2 +-
 .../allwinner/sun8i-ss/sun8i-ss-cipher.c  |  2 +-
 drivers/crypto/amlogic/amlogic-gxl-cipher.c   |  4 +--
 drivers/crypto/atmel-ecc.c|  2 +-
 drivers/crypto/caam/caampkc.c | 28 +++
 drivers/crypto/cavium/cpt/cptvf_main.c|  6 ++--
 drivers/crypto/cavium/cpt/cptvf_reqmanager.c  | 12 +++
 drivers/crypto/cavium/nitrox/nitrox_lib.c |  4 +--
 drivers/crypto/cavium/zip/zip_crypto.c|  6 ++--
 drivers/crypto/ccp/ccp-crypto-rsa.c   |  6 ++--
 drivers/crypto/ccree/cc_aead.c|  4 +--
 drivers/crypto/ccree/cc_buffer_mgr.c  |  4 +--
 drivers/crypto/ccree/cc_cipher.c  |  6 ++--
 drivers/crypto/ccree/cc_hash.c|  8 ++---
 drivers/crypto/ccree/cc_request_mgr.c |  2 +-
 drivers/crypto/marvell/cesa/hash.c|  2 +-
 .../crypto/marvell/octeontx/otx_cptvf_main.c  |  6 ++--
 .../marvell/octeontx/otx_cptvf_reqmgr.h   |  2 +-
 drivers/crypto/mediatek/mtk-aes.c |  2 +-
 drivers/crypto/nx/nx.c|  4 +--
 drivers/crypto/virtio/virtio_crypto_algs.c| 12 +++
 drivers/crypto/virtio/virtio_crypto_core.c|  2 +-
 drivers/md/dm-crypt.c | 32 -
 drivers/md/dm-integrity.c |  6 ++--
 drivers/misc/ibmvmc.c |  6 ++--
 .../hisilicon/hns3/hns3pf/hclge_mbx.c |  2 +-
 .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c|  6 ++--
 drivers/net/ppp/ppp_mppe.c|  6 ++--
 drivers/net/wireguard/noise.c |  4 +--
 drivers/net/wireguard/peer.c  |  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c  |  2 +-
 .../net/wireless/intel/iwlwifi/pcie/tx-gen2.c |  6 ++--
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c  |  6 ++--
 drivers/net/wireless/intersil/orinoco/wext.c  |  4 +--
 drivers/s390/crypto/ap_bus.h  |  4 +--
 drivers/staging/ks7010/ks_hostif.c|  2 +-
 drivers/staging/rtl8723bs/core/rtw_security.c |  2 +-
 drivers/staging/wlan-ng/p80211netdev.c|  2 +-
 drivers/target/iscsi/iscsi_target_auth.c  |  2 +-
 fs/cifs/cifsencrypt.c |  2 +-
 fs/cifs/connect.c | 10 +++---
 fs/cifs/dfs_cache.c   |  2 +-
 fs/cifs/misc.c|  8 ++---
 fs/crypto/keyring.c   |  6 ++--
 fs/crypto/keysetup_v1.c   |  4 +--
 fs/ecryptfs/keystore.c|  4 +--
 fs/ecryptfs/messaging.c 

[PATCH v5 0/2] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Waiman Long
 v5:
  - Break the btrfs patch out as a separate patch to be processed
independently.
  - Update the commit log of patch 1 to make it less scary.
  - Add a kzfree backward compatibility macro in patch 2.

 v4:
  - Break out the memzero_explicit() change as suggested by Dan Carpenter
so that it can be backported to stable.
  - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for
now as there can be a bit more discussion on what is best. It will be
introduced as a separate patch later on after this one is merged.

This patchset makes a global rename of the kzfree() to kfree_sensitive()
to highlight the fact buffer clearing is only needed if the data objects
contain sensitive information like encrpytion key. The fact that kzfree()
uses memset() to do the clearing isn't totally safe either as compiler
may compile out the clearing in their optimizer especially if LTO is
used. Instead, the new kfree_sensitive() uses memzero_explicit() which
won't get compiled out.


Waiman Long (2):
  mm/slab: Use memzero_explicit() in kzfree()
  mm, treewide: Rename kzfree() to kfree_sensitive()

 arch/s390/crypto/prng.c   |  4 +--
 arch/x86/power/hibernate.c|  2 +-
 crypto/adiantum.c |  2 +-
 crypto/ahash.c|  4 +--
 crypto/api.c  |  2 +-
 crypto/asymmetric_keys/verify_pefile.c|  4 +--
 crypto/deflate.c  |  2 +-
 crypto/drbg.c | 10 +++---
 crypto/ecc.c  |  8 ++---
 crypto/ecdh.c |  2 +-
 crypto/gcm.c  |  2 +-
 crypto/gf128mul.c |  4 +--
 crypto/jitterentropy-kcapi.c  |  2 +-
 crypto/rng.c  |  2 +-
 crypto/rsa-pkcs1pad.c |  6 ++--
 crypto/seqiv.c|  2 +-
 crypto/shash.c|  2 +-
 crypto/skcipher.c |  2 +-
 crypto/testmgr.c  |  6 ++--
 crypto/zstd.c |  2 +-
 .../allwinner/sun8i-ce/sun8i-ce-cipher.c  |  2 +-
 .../allwinner/sun8i-ss/sun8i-ss-cipher.c  |  2 +-
 drivers/crypto/amlogic/amlogic-gxl-cipher.c   |  4 +--
 drivers/crypto/atmel-ecc.c|  2 +-
 drivers/crypto/caam/caampkc.c | 28 +++
 drivers/crypto/cavium/cpt/cptvf_main.c|  6 ++--
 drivers/crypto/cavium/cpt/cptvf_reqmanager.c  | 12 +++
 drivers/crypto/cavium/nitrox/nitrox_lib.c |  4 +--
 drivers/crypto/cavium/zip/zip_crypto.c|  6 ++--
 drivers/crypto/ccp/ccp-crypto-rsa.c   |  6 ++--
 drivers/crypto/ccree/cc_aead.c|  4 +--
 drivers/crypto/ccree/cc_buffer_mgr.c  |  4 +--
 drivers/crypto/ccree/cc_cipher.c  |  6 ++--
 drivers/crypto/ccree/cc_hash.c|  8 ++---
 drivers/crypto/ccree/cc_request_mgr.c |  2 +-
 drivers/crypto/marvell/cesa/hash.c|  2 +-
 .../crypto/marvell/octeontx/otx_cptvf_main.c  |  6 ++--
 .../marvell/octeontx/otx_cptvf_reqmgr.h   |  2 +-
 drivers/crypto/mediatek/mtk-aes.c |  2 +-
 drivers/crypto/nx/nx.c|  4 +--
 drivers/crypto/virtio/virtio_crypto_algs.c| 12 +++
 drivers/crypto/virtio/virtio_crypto_core.c|  2 +-
 drivers/md/dm-crypt.c | 32 -
 drivers/md/dm-integrity.c |  6 ++--
 drivers/misc/ibmvmc.c |  6 ++--
 .../hisilicon/hns3/hns3pf/hclge_mbx.c |  2 +-
 .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c|  6 ++--
 drivers/net/ppp/ppp_mppe.c|  6 ++--
 drivers/net/wireguard/noise.c |  4 +--
 drivers/net/wireguard/peer.c  |  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c  |  2 +-
 .../net/wireless/intel/iwlwifi/pcie/tx-gen2.c |  6 ++--
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c  |  6 ++--
 drivers/net/wireless/intersil/orinoco/wext.c  |  4 +--
 drivers/s390/crypto/ap_bus.h  |  4 +--
 drivers/staging/ks7010/ks_hostif.c|  2 +-
 drivers/staging/rtl8723bs/core/rtw_security.c |  2 +-
 drivers/staging/wlan-ng/p80211netdev.c|  2 +-
 drivers/target/iscsi/iscsi_target_auth.c  |  2 +-
 fs/cifs/cifsencrypt.c |  2 +-
 fs/cifs/connect.c | 10 +++---
 fs/cifs/dfs_cache.c   |  2 +-
 fs/cifs/misc.c|  8 ++---
 fs/crypto/keyring.c   |  6 ++--
 fs/crypto/keysetup_v1.c   |  4 +--
 fs/ecryptfs/keystore.c|  4 +--
 fs/ecryptfs/messaging.c   |  2 +-
 include/crypto/aead.h |  2 +-
 include/crypto/akcipher.h  

Re: [PATCH v2 08/12] mm: Define pasid in mm

2020-06-16 Thread Fenghua Yu
Hi, Jean,

On Tue, Jun 16, 2020 at 10:28:19AM +0200, Jean-Philippe Brucker wrote:
> On Fri, Jun 12, 2020 at 05:41:29PM -0700, Fenghua Yu wrote:
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 64ede5f150dc..5778db3aa42d 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -538,6 +538,10 @@ struct mm_struct {
> > atomic_long_t hugetlb_usage;
> >  #endif
> > struct work_struct async_put_work;
> > +
> > +#ifdef CONFIG_PCI_PASID
> 
> Non-PCI devices can also use a PASID (e.g. Arm's SubstreamID). How about
> CONFIG_IOMMU_SUPPORT?

Sure. I will change it to CONFIG_IOMMU_SUPPORT.

Thanks.

-Fenghua


Re: [PATCH v4 2/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Waiman Long

On 6/16/20 10:26 AM, Dan Carpenter wrote:

Last time you sent this we couldn't decide which tree it should go
through.  Either the crypto tree or through Andrew seems like the right
thing to me.

Also the other issue is that it risks breaking things if people add
new kzfree() instances while we are doing the transition.  Could you
just add a "#define kzfree kfree_sensitive" so that things continue to
compile and we can remove it in the next kernel release?

regards,
dan carpenter


Yes, that make sure sense. Will send out v5 later today.

Cheers,
Longman



Re: [PATCH v4 3/3] btrfs: Use kfree() in btrfs_ioctl_get_subvol_info()

2020-06-16 Thread Waiman Long

On 6/16/20 10:48 AM, David Sterba wrote:

On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote:

In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc()
was incorrectly paired with kzfree(). According to David Sterba, there
isn't any sensitive information in the subvol_info that needs to be
cleared before freeing. So kfree_sensitive() isn't really needed,
use kfree() instead.

Reported-by: David Sterba 
Signed-off-by: Waiman Long 
---
  fs/btrfs/ioctl.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index f1dd9e4271e9..e8f7c5f00894 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2692,7 +2692,7 @@ static int btrfs_ioctl_get_subvol_info(struct file *file, 
void __user *argp)
btrfs_put_root(root);
  out_free:
btrfs_free_path(path);
-   kfree_sensitive(subvol_info);
+   kfree(subvol_info);

I would rather merge a patch doing to kzfree -> kfree instead of doing
the middle step to switch it to kfree_sensitive. If it would help
integration of your patchset I can push it to the next rc so there are
no kzfree left in the btrfs code. Treewide change like that can take
time so it would be one less problem to care about for you.


Sure, I will move it forward in the patch series.

Thanks,
Longman



Re: [PATCH v4 3/3] btrfs: Use kfree() in btrfs_ioctl_get_subvol_info()

2020-06-16 Thread David Sterba
On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote:
> In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc()
> was incorrectly paired with kzfree(). According to David Sterba, there
> isn't any sensitive information in the subvol_info that needs to be
> cleared before freeing. So kfree_sensitive() isn't really needed,
> use kfree() instead.
> 
> Reported-by: David Sterba 
> Signed-off-by: Waiman Long 
> ---
>  fs/btrfs/ioctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index f1dd9e4271e9..e8f7c5f00894 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2692,7 +2692,7 @@ static int btrfs_ioctl_get_subvol_info(struct file 
> *file, void __user *argp)
>   btrfs_put_root(root);
>  out_free:
>   btrfs_free_path(path);
> - kfree_sensitive(subvol_info);
> + kfree(subvol_info);

I would rather merge a patch doing to kzfree -> kfree instead of doing
the middle step to switch it to kfree_sensitive. If it would help
integration of your patchset I can push it to the next rc so there are
no kzfree left in the btrfs code. Treewide change like that can take
time so it would be one less problem to care about for you.


Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support

2020-06-16 Thread Michal Simek



On 16. 06. 20 2:27, Nathan Chancellor wrote:
> On Thu, May 21, 2020 at 04:55:52PM +, Christophe Leroy wrote:
>> From: Michal Simek 
>>
>> The latest Xilinx design tools called ISE and EDK has been released in
>> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
>> These platforms are no longer supported and tested.
>>
>> PowerPC 405/440 port is orphan from 2013 by
>> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
>> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and 
>> maintainership")
>> that's why it is time to remove the support fot these platforms.
>>
>> Signed-off-by: Michal Simek 
>> Acked-by: Arnd Bergmann 
>> Signed-off-by: Christophe Leroy 
> 
> This patch causes qemu-system-ppc to fail to load ppc44x_defconfig:
> 
> $ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc-linux- O=out/ppc 
> distclean ppc44x_defconfig zImage
> 
> $ timeout --foreground 30s unbuffer \
> qemu-system-ppc \
> -machine bamboo \

Did you bisect it that you found that this patch is causing problem for
you on any bamboo machine?

Or this was caused by the whole series?

Thanks,
Michal


Re: [PATCH v4 2/3] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-06-16 Thread Dan Carpenter
Last time you sent this we couldn't decide which tree it should go
through.  Either the crypto tree or through Andrew seems like the right
thing to me.

Also the other issue is that it risks breaking things if people add
new kzfree() instances while we are doing the transition.  Could you
just add a "#define kzfree kfree_sensitive" so that things continue to
compile and we can remove it in the next kernel release?

regards,
dan carpenter



Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread Bart Van Assche
On 2020-06-16 02:42, Finn Thain wrote:
> Martin said, "I'd appreciate a patch to remove it"
> 
> And Bart said, "do you want to keep this driver in the kernel tree?"
> 
> AFAICT both comments are quite ambiguous. I don't see an actionable 
> request, just an expression of interest from people doing their jobs.
> 
> Note well: there is no pay check associated with having a MAINTAINERS file 
> entry.

Hi Finn,

As far as I know the sbp driver only has had one user ever and that user
is no longer user the sbp driver. So why to keep it in the kernel tree?
Restoring a kernel driver can be easy - the first step is a "git revert".

Thanks,

Bart.




[PATCH 2/2] powerpc/syscalls: Split SPU-ness out of ABI

2020-06-16 Thread Michael Ellerman
Using the ABI field to encode whether a syscall is usable by SPU
programs or not is a bit of kludge.

The ABI of the syscall doesn't change depending on the SPU-ness, but
in order to make the syscall generation work we have to pretend that
it does.

It also means we have more duplicated syscall lines than we need to,
and the SPU logic is not well contained, instead all of the syscall
generation targets need to know if they are spu or nospu.

So instead add a separate file which contains the information on which
syscalls are available for SPU programs. It's just a list of syscall
numbers with a single "spu" field. If the field has the value "spu"
then the syscall is available to SPU programs, any other value or no
entry entirely means the syscall is not available to SPU programs.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/syscalls/Makefile  |  16 +-
 arch/powerpc/kernel/syscalls/spu.tbl   | 430 +
 arch/powerpc/kernel/syscalls/syscall.tbl   | 195 --
 arch/powerpc/kernel/syscalls/syscalltbl.sh |  10 +-
 4 files changed, 523 insertions(+), 128 deletions(-)
 create mode 100644 arch/powerpc/kernel/syscalls/spu.tbl


I'm inclined to put this in next and ask Linus to pull it before rc2, that seems
like the least disruptive way to get this in, unless anyone objects?

cheers


diff --git a/arch/powerpc/kernel/syscalls/Makefile 
b/arch/powerpc/kernel/syscalls/Makefile
index 27b48954808d..34d39b4a83f7 100644
--- a/arch/powerpc/kernel/syscalls/Makefile
+++ b/arch/powerpc/kernel/syscalls/Makefile
@@ -6,6 +6,7 @@ _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')   
\
  $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
 
 syscall := $(srctree)/$(src)/syscall.tbl
+sputbl := $(srctree)/$(src)/spu.tbl
 syshdr := $(srctree)/$(src)/syscallhdr.sh
 systbl := $(srctree)/$(src)/syscalltbl.sh
 
@@ -19,32 +20,33 @@ quiet_cmd_systbl = SYSTBL  $@
   cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@'   \
   '$(systbl_abis_$(basetarget))'   \
   '$(systbl_abi_$(basetarget))'\
-  '$(systbl_offset_$(basetarget))'
+  '$(systbl_offset_$(basetarget))' \
+   $(sputbl)
 
-syshdr_abis_unistd_32 := common,nospu,32
+syshdr_abis_unistd_32 := common,32
 $(uapi)/unistd_32.h: $(syscall) $(syshdr)
$(call if_changed,syshdr)
 
-syshdr_abis_unistd_64 := common,nospu,64
+syshdr_abis_unistd_64 := common,64
 $(uapi)/unistd_64.h: $(syscall) $(syshdr)
$(call if_changed,syshdr)
 
-systbl_abis_syscall_table_32 := common,nospu,32
+systbl_abis_syscall_table_32 := common,32
 systbl_abi_syscall_table_32 := 32
 $(kapi)/syscall_table_32.h: $(syscall) $(systbl)
$(call if_changed,systbl)
 
-systbl_abis_syscall_table_64 := common,nospu,64
+systbl_abis_syscall_table_64 := common,64
 systbl_abi_syscall_table_64 := 64
 $(kapi)/syscall_table_64.h: $(syscall) $(systbl)
$(call if_changed,systbl)
 
-systbl_abis_syscall_table_c32 := common,nospu,32
+systbl_abis_syscall_table_c32 := common,32
 systbl_abi_syscall_table_c32 := c32
 $(kapi)/syscall_table_c32.h: $(syscall) $(systbl)
$(call if_changed,systbl)
 
-systbl_abis_syscall_table_spu := common,spu
+systbl_abis_syscall_table_spu := common,64
 systbl_abi_syscall_table_spu := spu
 $(kapi)/syscall_table_spu.h: $(syscall) $(systbl)
$(call if_changed,systbl)
diff --git a/arch/powerpc/kernel/syscalls/spu.tbl 
b/arch/powerpc/kernel/syscalls/spu.tbl
new file mode 100644
index ..5eac04919303
--- /dev/null
+++ b/arch/powerpc/kernel/syscalls/spu.tbl
@@ -0,0 +1,430 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# The format is:
+#   
+#
+# To indicate a syscall can be used by SPU programs use "spu" for the spu 
column.
+#
+# Syscalls that are not to be used by SPU programs can be left out of the file
+# entirely, or an entry with a value other than "spu" can be added.
+0  restart_syscall -
+1  exit-
+2  fork-
+3  readspu
+4  write   spu
+5  openspu
+6  close   spu
+7  waitpid spu
+8  creat   spu
+9  linkspu
+10 unlink  spu
+11 execve  -
+12 chdir   spu
+13 timespu
+14 mknod   spu
+15 chmod   spu
+16 lchown  spu
+17 break   -
+18 oldstat -
+19 lseek   spu
+20 getpid  spu
+21 mount   -
+22 umount  -
+23 setuid  spu

[PATCH 1/2] powerpc/syscalls: Use the number when building SPU syscall table

2020-06-16 Thread Michael Ellerman
Currently the macro that inserts entries into the SPU syscall table
doesn't actually use the "nr" (syscall number) parameter.

This does work, but it relies on the exact right number of syscall
entries being emitted in order for the syscal numbers to line up with
the array entries. If for example we had two entries with the same
syscall number we wouldn't get an error, it would just cause all
subsequent syscalls to be off by one in the spu_syscall_table.

So instead change the macro to assign to the specific entry of the
array, meaning any numbering overlap will be caught by the compiler.

Signed-off-by: Michael Ellerman 
Acked-by: Arnd Bergmann 
Link: https://lore.kernel.org/r/20190116132714.20094-1-...@ellerman.id.au
---
 arch/powerpc/platforms/cell/spu_callbacks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/spu_callbacks.c 
b/arch/powerpc/platforms/cell/spu_callbacks.c
index cbee3666da07..abdef9bcf432 100644
--- a/arch/powerpc/platforms/cell/spu_callbacks.c
+++ b/arch/powerpc/platforms/cell/spu_callbacks.c
@@ -35,7 +35,7 @@
  */
 
 static void *spu_syscall_table[] = {
-#define __SYSCALL(nr, entry)   entry,
+#define __SYSCALL(nr, entry) [nr] = entry,
 #include 
 #undef __SYSCALL
 };
-- 
2.25.1



Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

2020-06-16 Thread Waiman Long

On 6/15/20 11:30 PM, Eric Biggers wrote:

On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote:

The kzfree() function is normally used to clear some sensitive
information, like encryption keys, in the buffer before freeing it back
to the pool. Memset() is currently used for the buffer clearing. However,
it is entirely possible that the compiler may choose to optimize away the
memory clearing especially if LTO is being used. To make sure that this
optimization will not happen, memzero_explicit(), which is introduced
in v3.18, is now used in kzfree() to do the clearing.

Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
Cc: sta...@vger.kernel.org
Signed-off-by: Waiman Long 
---
  mm/slab_common.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/slab_common.c b/mm/slab_common.c
index 9e72ba224175..37d48a56431d 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1726,7 +1726,7 @@ void kzfree(const void *p)
if (unlikely(ZERO_OR_NULL_PTR(mem)))
return;
ks = ksize(mem);
-   memset(mem, 0, ks);
+   memzero_explicit(mem, ks);
kfree(mem);
  }
  EXPORT_SYMBOL(kzfree);

This is a good change, but the commit message isn't really accurate.  AFAIK, no
one has found any case where this memset() gets optimized out.  And even with
LTO, it would be virtually impossible due to all the synchronization and global
data structures that kfree() uses.  (Remember that this isn't the C standard
function "free()", so the compiler can't assign it any special meaning.)
Not to mention that LTO support isn't actually upstream yet.

I still agree with the change, but it might be helpful if the commit message
were honest that this is really a hardening measure and about properly conveying
the intent.  As-is this sounds like a critical fix, which might confuse people.


Yes, I agree that the commit log may look a bit scary. How about the 
following:


The kzfree() function is normally used to clear some sensitive
information, like encryption keys, in the buffer before freeing it back
to the pool. Memset() is currently used for buffer clearing. However
unlikely, there is still a non-zero probability that the compiler may
choose to optimize away the memory clearing especially if LTO is being
used in the future. To make sure that this optimization will never
happen, memzero_explicit(), which is introduced in v3.18, is now used
in kzfree() to future-proof it.

Cheers,
Longman



Re: powerpc/pci: [PATCH 1/1 V3] PCIE PHB reset

2020-06-16 Thread Michael Ellerman
wenxi...@linux.vnet.ibm.com writes:
> From: Wen Xiong 
>
> Several device drivers hit EEH(Extended Error handling) when triggering
> kdump on Pseries PowerVM. This patch implemented a reset of the PHBs
> in pci general code when triggering kdump.

Actually it's in pseries specific PCI code, and the reset is done in the
2nd kernel as it boots, not when triggering the kdump.

You're doing it as a:

  machine_postcore_initcall(pseries, pseries_phb_reset);

But we do the EEH initialisation in:

  core_initcall_sync(eeh_init);

Which happens first.

So it seems to me that this should be called from pseries_eeh_init().

That would isolate the code in the right place, and allow you to use the
existing ibm_get_config_addr_info.

You probably can't use pseries_eeh_get_pe_addr(), because you won't have
a "pe" structure yet.

Instead you should add a helper that does the core of that logic but
accepts config_addr/buid as parameters, and then have your code and
pseries_eeh_get_pe_addr() call that.

> PHB reset stop all PCI
> transactions from normal kernel. We have tested the patch in several
> enviroments:
> - direct slot adapters
> - adapters under the switch
> - a VF adapter in PowerVM
> - a VF adapter/adapter in KVM guest.
>
> Signed-off-by: Wen Xiong 
>
> ---
>  arch/powerpc/platforms/pseries/pci.c | 152 +++
>  1 file changed, 152 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/pci.c 
> b/arch/powerpc/platforms/pseries/pci.c
> index 911534b89c85..cb7e4276cf04 100644
> --- a/arch/powerpc/platforms/pseries/pci.c
> +++ b/arch/powerpc/platforms/pseries/pci.c
> @@ -11,6 +11,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -354,3 +356,153 @@ int pseries_root_bridge_prepare(struct pci_host_bridge 
> *bridge)
>  
>   return 0;
>  }
> +
> +/**
> + * pseries_get_pdn_addr - Retrieve PHB address
> + * @pe: EEH PE

There is no "pe" parameter.

Oh but there is in pseries_eeh_get_pe_addr() which this is an almost
verbatim copy of.

> + *
> + * Retrieve the assocated PHB address. Actually, there're 2 RTAS
> + * function calls dedicated for the purpose. We need implement
> + * it through the new function and then the old one. Besides,
> + * you should make sure the config address is figured out from
> + * FDT node before calling the function.
> + *
> + */
> +static int pseries_get_pdn_addr(struct pci_controller *phb)
> +{
> + int ret = -1;
> + int rets[3];
> + int ibm_get_config_addr_info;
> + int ibm_get_config_addr_info2;
> + int config_addr = 0;
> + struct pci_dn *root_pdn, *pdn;
> +
> + ibm_get_config_addr_info2   = rtas_token("ibm,get-config-addr-info2");
> + ibm_get_config_addr_info= rtas_token("ibm,get-config-addr-info");
> +
> + root_pdn = PCI_DN(phb->dn);
> + pdn = list_first_entry(_pdn->child_list, struct pci_dn, list);
> + config_addr = (pdn->busno << 16) | (pdn->devfn << 8);
> +
> + if (ibm_get_config_addr_info2 != RTAS_UNKNOWN_SERVICE) {
> + /*
> +  * First of all, we need to make sure there has one PE
> +  * associated with the device. If option is 1, it
> +  * queries if config address is supported in a PE or not.
> +  * If option is 0, it returns PE config address or config
> +  * address for the PE primary bus.
> +  */
> + ret = rtas_call(ibm_get_config_addr_info2, 4, 2, rets,
> + config_addr, BUID_HI(pdn->phb->buid),
> + BUID_LO(pdn->phb->buid), 1);
> + if (ret || (rets[0] == 0)) {
> + pr_warn("%s: Failed to get address for PHB#%x-PE# 
> option=%d config_addr=%x\n",
> + __func__, pdn->phb->global_number, 1, rets[0]);

Here you've hacked the existing pr_warn() to drop the PE number but left
"-PE#" in the format string.

See the original:
pr_warn("%s: Failed to get address for PHB#%x-PE#%x\n",
__func__, pe->phb->global_number, 
pe->config_addr);


> + return -1;
> + }
> +
> + /* Retrieve the associated PE config address */
> + ret = rtas_call(ibm_get_config_addr_info2, 4, 2, rets,
> + config_addr, BUID_HI(pdn->phb->buid),
> + BUID_LO(pdn->phb->buid), 0);
> + if (ret) {
> + pr_warn("%s: Failed to get address for PHB#%x-PE# 
> option=%d config_addr=%x\n",
 ^
 and 
here

> + __func__, pdn->phb->global_number, 0, rets[0]);
> + return -1;
> + }
> + return rets[0];
> + }
> +
> + if (ibm_get_config_addr_info != RTAS_UNKNOWN_SERVICE) {
> + ret = 

Re: [PATCH v4 6/7] KVM: MIPS: clean up redundant 'kvm_run' parameters

2020-06-16 Thread Tianjia Zhang




On 2020/5/29 17:48, Paolo Bonzini wrote:

On 27/05/20 08:24, Tianjia Zhang wrote:





Hi Huacai,

These two patches(6/7 and 7/7) should be merged into the tree of the
mips architecture separately. At present, there seems to be no good way
to merge the whole architecture patchs.

For this series of patches, some architectures have been merged, some
need to update the patch.


Hi Tianjia, I will take care of this during the merge window.

Thanks,

Paolo



Hi Paolo,

The following individual patch is the v5 version of 5/7 in this group of 
patches.


https://lkml.org/lkml/2020/5/28/106
([v5] KVM: PPC: clean up redundant kvm_run parameters in assembly)

Thanks and best,
Tianjia


Re: [PATCH v3] ASoC: fsl_ssi: Fix bclk calculation for mono channel

2020-06-16 Thread Mark Brown
On Tue, 16 Jun 2020 10:53:48 +0800, Shengjiu Wang wrote:
> For mono channel, SSI will switch to Normal mode.
> 
> In Normal mode and Network mode, the Word Length Control bits
> control the word length divider in clock generator, which is
> different with I2S Master mode (the word length is fixed to
> 32bit), it should be the value of params_width(hw_params).
> 
> [...]

Applied to

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

Thanks!

[1/1] ASoC: fsl_ssi: Fix bclk calculation for mono channel
  commit: ed1220df6e666500ebf58c4f2fccc681941646fb

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


[PATCH kernel] powerpc/powernv/ioda: Return correct error if TCE level allocation failed

2020-06-16 Thread Alexey Kardashevskiy
The iommu_table_ops::xchg_no_kill() callback updates TCE. It is quite
possible that not entire table is allocated if it is huge and multilevel
so xchg may also allocate subtables. If failed, it returns H_HARDWARE
for failed allocation and H_TOO_HARD if it needs it but cannot do because
the alloc parameter is "false" (set when called with MMU=off to force
retry with MMU=on).

The problem is that having separate errors only matters in real mode
(MMU=off) but the only caller with alloc="false" does not check the exact
error code and simply returns H_TOO_HARD; and for every other mode
alloc is "true". Also, the function is also called from the ioctl()
handler of the VFIO SPAPR TCE IOMMU subdriver which does not expect
hypervisor error codes (H_xxx) and will expose them to the userspace.

This converts wrong error codes to a simple -1.

Signed-off-by: Alexey Kardashevskiy 
---

I could make it "return alloc ? -ENOMEM : -EBUSY" but
is EBUSY a good match for H_TOO_HARD?
---
 arch/powerpc/platforms/powernv/pci-ioda-tce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c 
b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index f923359d8afc..59d73fdadeb9 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -166,7 +166,7 @@ int pnv_tce_xchg(struct iommu_table *tbl, long index,
if (!ptce) {
ptce = pnv_tce(tbl, false, idx, alloc);
if (!ptce)
-   return alloc ? H_HARDWARE : H_TOO_HARD;
+   return -1;
}
 
if (newtce & TCE_PCI_WRITE)
-- 
2.17.1



Re: [PATCH 2/2] cpufreq: Specify default governor on command line

2020-06-16 Thread Viresh Kumar
On 16-06-20, 10:48, Quentin Perret wrote:
> ---8<---
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 0f05caedc320..a9219404e07f 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2340,6 +2340,11 @@ int cpufreq_register_governor(struct cpufreq_governor 
> *governor)
>   list_add(>governor_list, _governor_list);
>   }
>  
> + if (!strncasecmp(cpufreq_param_governor, governor->name, 
> CPUFREQ_NAME_LEN))
> + default_governor = governor;
> + else if (!default_governor && cpufreq_default_governor() == governor)
> + default_governor = cpufreq_default_governor();

Instead of the else part here, maybe just do this from
cpufreq_core_init() only once, and so we will always have
default_governor set.

> +
>   mutex_unlock(_governor_mutex);
>   return err;
>  }
> @@ -2368,6 +2373,8 @@ void cpufreq_unregister_governor(struct 
> cpufreq_governor *governor)
>  
>   mutex_lock(_governor_mutex);
>   list_del(>governor_list);
> + if (governor == default_governor)
> + default_governor = cpufreq_default_governor();
>   mutex_unlock(_governor_mutex);
>  }
>  EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
> --->8---
> 
> should do the trick. That removes the unnecessary reference count, and
> feels like a good place to hook things -- that is how cpuidle does it
> too IIRC.
> 
> I'll double check the locking/synchronization, but that shouldn't be too
> bad (famous last words).
> 
> Cheers,
> Quentin

-- 
viresh


Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread Finn Thain
On Mon, 15 Jun 2020, Chris Boot wrote:

> On 15/06/2020 00:28, Finn Thain wrote:
> > On Sun, 14 Jun 2020, Chris Boot wrote:
> > 
> >> I expect that if someone finds this useful it can stick around (but 
> >> that's not my call).
> > 
> > Who's call is that? If the patch had said "From: Martin K. Petersen" 
> > and "This driver is being removed because it has the following 
> > defects..." that would be some indication of a good-faith willingness 
> > to accept users as developers in the spirit of the GPL, which is what 
> > you seem to be alluding to (?).
> 
> If you're asking me, I'd say it was martin's call:
> 
> > SCSI TARGET SUBSYSTEM   
> >
> > M:  "Martin K. Petersen"
> >
> [...]
> > F:  drivers/target/ 
> >
> > F:  include/target/ 
> >
> 

The question I asked you was intended to make you think. I wasn't asking 
you to search MAINTAINERS for "drivers/target" (I had already done so).

Chris, you can find my name in that file too. That's because I see my role 
as custodian of that particular code. That code lives in the kernel.org 
tree because others put it there and because users find it useful -- not 
merely because it happens to please the official glorious MAINTAINER of 
said code.

If you would ask, "who's call is it to delete drivers/nubus? or 
drivers/scsi/NCR5380.c?" my answer is, I have no idea.

> >> I just don't have the time or inclination or hardware to be able to 
> >> maintain it anymore, so someone else would have to pick it up.
> >>
> > 
> > Which is why most drivers get orphaned, right?
> 
> Sure, but that's not what Martin asked me to do, hence this patch.
> 

Martin said, "I'd appreciate a patch to remove it"

And Bart said, "do you want to keep this driver in the kernel tree?"

AFAICT both comments are quite ambiguous. I don't see an actionable 
request, just an expression of interest from people doing their jobs.

Note well: there is no pay check associated with having a MAINTAINERS file 
entry.


Re: [PATCH v2 08/12] mm: Define pasid in mm

2020-06-16 Thread Jean-Philippe Brucker
On Fri, Jun 12, 2020 at 05:41:29PM -0700, Fenghua Yu wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 64ede5f150dc..5778db3aa42d 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -538,6 +538,10 @@ struct mm_struct {
>   atomic_long_t hugetlb_usage;
>  #endif
>   struct work_struct async_put_work;
> +
> +#ifdef CONFIG_PCI_PASID

Non-PCI devices can also use a PASID (e.g. Arm's SubstreamID). How about
CONFIG_IOMMU_SUPPORT?

Thanks,
Jean

> + unsigned int pasid;
> +#endif


Re: [PATCH 2/2] cpufreq: Specify default governor on command line

2020-06-16 Thread Viresh Kumar
On 16-06-20, 09:31, Quentin Perret wrote:
> Right, so the reason I avoided cpufreq_core_init() was because it is
> called at core_initcall() time, which means I can't really assume the
> governors have been loaded by that time. By waiting for the driver to
> probe before detecting the default gov, we get that nice ordering. But
> yes, it feels odd to have it here :/
> 
> Thinking about it more, the natural fit for this would rather be the
> register/unregister path for governors directly. If that sounds good to
> you (?) I'll try to move it there in v2.

There is another problem here which we need to look at. Any governor
which is built as a module and isn't currently used, should be allowed
to unload. And this needs to be tested by you as well, should be easy
enough.

With the current implementation, you take a reference to the default
governor when the driver is registered and drop it only when the
driver goes away. Which means we won't be able to unload the module of
the governor even if it isn't used. Which is wrong. The solution I
proposed had the same issue as well.

You need to figure out a way where we don't need to keep holding the
module hostage even when it isn't used. I see two ways at least for
the same:

- Do that from the existing place: cpufreq_init_policy().

- And I think this can be done from governor-register/unregister as
  well.

Second one sounds good, if it is feasible to do that.

-- 
viresh


Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

2020-06-16 Thread Dan Carpenter
On Tue, Jun 16, 2020 at 08:42:08AM +0200, Michal Hocko wrote:
> On Mon 15-06-20 21:57:16, Waiman Long wrote:
> > The kzfree() function is normally used to clear some sensitive
> > information, like encryption keys, in the buffer before freeing it back
> > to the pool. Memset() is currently used for the buffer clearing. However,
> > it is entirely possible that the compiler may choose to optimize away the
> > memory clearing especially if LTO is being used. To make sure that this
> > optimization will not happen, memzero_explicit(), which is introduced
> > in v3.18, is now used in kzfree() to do the clearing.
> > 
> > Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Waiman Long 
> 
> Acked-by: Michal Hocko 
> 
> Although I am not really sure this is a stable material. Is there any
> known instance where the memset was optimized out from kzfree?

I told him to add the stable.  Otherwise it will just get reported to
me again.  It's a just safer to backport it before we forget.

regards,
dan carpenter



Re: [PATCH V2] powerpc/pseries/svm: Drop unused align argument in alloc_shared_lppaca() function

2020-06-16 Thread Laurent Dufour

Le 12/06/2020 à 16:29, Satheesh Rajendran a écrit :

Argument "align" in alloc_shared_lppaca() was unused inside the
function. Let's drop it and update code comment for page alignment.

Cc: linux-ker...@vger.kernel.org
Cc: Thiago Jung Bauermann 
Cc: Ram Pai 
Cc: Sukadev Bhattiprolu 
Cc: Laurent Dufour 
Cc: Michael Ellerman 
Reviewed-by: Thiago Jung Bauermann 


Reviewed-by: Laurent Dufour 


Signed-off-by: Satheesh Rajendran 
---

V2:
Added reviewed by Thiago.
Dropped align argument as per Michael suggest.
Modified commit msg.

V1: 
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200609113909.17236-1-sathn...@linux.vnet.ibm.com/
---
  arch/powerpc/kernel/paca.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 8d96169c597e..a174d64d9b4d 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -57,8 +57,8 @@ static void *__init alloc_paca_data(unsigned long size, 
unsigned long align,
  
  #define LPPACA_SIZE 0x400
  
-static void *__init alloc_shared_lppaca(unsigned long size, unsigned long align,

-   unsigned long limit, int cpu)
+static void *__init alloc_shared_lppaca(unsigned long size, unsigned long 
limit,
+   int cpu)
  {
size_t shared_lppaca_total_size = PAGE_ALIGN(nr_cpu_ids * LPPACA_SIZE);
static unsigned long shared_lppaca_size;
@@ -68,6 +68,12 @@ static void *__init alloc_shared_lppaca(unsigned long size, 
unsigned long align,
if (!shared_lppaca) {
memblock_set_bottom_up(true);
  
+		/* See Documentation/powerpc/ultravisor.rst for mode details

+*
+* UV/HV data share is in PAGE granularity, In order to
+* minimize the number of pages shared and maximize the
+* use of a page, let's use page align.
+*/
shared_lppaca =
memblock_alloc_try_nid(shared_lppaca_total_size,
   PAGE_SIZE, MEMBLOCK_LOW_LIMIT,
@@ -122,7 +128,7 @@ static struct lppaca * __init new_lppaca(int cpu, unsigned 
long limit)
return NULL;
  
  	if (is_secure_guest())

-   lp = alloc_shared_lppaca(LPPACA_SIZE, 0x400, limit, cpu);
+   lp = alloc_shared_lppaca(LPPACA_SIZE, limit, cpu);
else
lp = alloc_paca_data(LPPACA_SIZE, 0x400, limit, cpu);
  





[PATCH 2/2] ASoC: fsl-asoc-card: Add MQS support

2020-06-16 Thread Shengjiu Wang
The MQS codec isn't an i2c device, so add a new platform device for it.

MQS only support playback, so add a new audio map.

Add there maybe "model" property or no "audio-routing" property in
devicetree, so add some enhancement for these two property.

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/fsl-asoc-card.c | 70 ++-
 1 file changed, 52 insertions(+), 18 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 00be73900888..2ac8cb9ddd10 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -119,6 +119,13 @@ static const struct snd_soc_dapm_route audio_map_ac97[] = {
{"ASRC-Capture",  NULL, "AC97 Capture"},
 };
 
+static const struct snd_soc_dapm_route audio_map_tx[] = {
+   /* 1st half -- Normal DAPM routes */
+   {"Playback",  NULL, "CPU-Playback"},
+   /* 2nd half -- ASRC DAPM routes */
+   {"CPU-Playback",  NULL, "ASRC-Playback"},
+};
+
 /* Add all possible widgets into here without being redundant */
 static const struct snd_soc_dapm_widget fsl_asoc_card_dapm_widgets[] = {
SND_SOC_DAPM_LINE("Line Out Jack", NULL),
@@ -482,6 +489,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 {
struct device_node *cpu_np, *codec_np, *asrc_np;
struct device_node *np = pdev->dev.of_node;
+   struct platform_device *codec_pdev = NULL; /* used for non i2c device*/
struct platform_device *asrc_pdev = NULL;
struct platform_device *cpu_pdev;
struct fsl_asoc_card_priv *priv;
@@ -512,10 +520,13 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
}
 
codec_np = of_parse_phandle(np, "audio-codec", 0);
-   if (codec_np)
+   if (codec_np) {
codec_dev = of_find_i2c_device_by_node(codec_np);
-   else
+   if (!codec_dev)
+   codec_pdev = of_find_device_by_node(codec_np);
+   } else {
codec_dev = NULL;
+   }
 
asrc_np = of_parse_phandle(np, "audio-asrc", 0);
if (asrc_np)
@@ -525,6 +536,13 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
if (codec_dev) {
struct clk *codec_clk = clk_get(_dev->dev, NULL);
 
+   if (!IS_ERR(codec_clk)) {
+   priv->codec_priv.mclk_freq = clk_get_rate(codec_clk);
+   clk_put(codec_clk);
+   }
+   } else if (codec_pdev) {
+   struct clk *codec_clk = clk_get(_pdev->dev, NULL);
+
if (!IS_ERR(codec_clk)) {
priv->codec_priv.mclk_freq = clk_get_rate(codec_clk);
clk_put(codec_clk);
@@ -538,6 +556,11 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
/* Assign a default DAI format, and allow each card to overwrite it */
priv->dai_fmt = DAI_FMT_BASE;
 
+   memcpy(priv->dai_link, fsl_asoc_card_dai,
+  sizeof(struct snd_soc_dai_link) * ARRAY_SIZE(priv->dai_link));
+
+   priv->card.dapm_routes = audio_map;
+   priv->card.num_dapm_routes = ARRAY_SIZE(audio_map);
/* Diversify the card configurations */
if (of_device_is_compatible(np, "fsl,imx-audio-cs42888")) {
codec_dai_name = "cs42888";
@@ -573,13 +596,25 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
codec_dai_name = "ac97-hifi";
priv->card.set_bias_level = NULL;
priv->dai_fmt = SND_SOC_DAIFMT_AC97;
+   priv->card.dapm_routes = audio_map_ac97;
+   priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_ac97);
+   } else if (of_device_is_compatible(np, "fsl,imx-audio-mqs")) {
+   codec_dai_name = "fsl-mqs-dai";
+   priv->card.set_bias_level = NULL;
+   priv->dai_fmt = SND_SOC_DAIFMT_LEFT_J |
+   SND_SOC_DAIFMT_CBS_CFS |
+   SND_SOC_DAIFMT_NB_NF;
+   priv->dai_link[1].dpcm_playback = 1;
+   priv->dai_link[2].dpcm_playback = 1;
+   priv->card.dapm_routes = audio_map_tx;
+   priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_tx);
} else {
dev_err(>dev, "unknown Device Tree compatible\n");
ret = -EINVAL;
goto asrc_fail;
}
 
-   if (!fsl_asoc_card_is_ac97(priv) && !codec_dev) {
+   if (!fsl_asoc_card_is_ac97(priv) && !codec_dev && !codec_pdev) {
dev_err(>dev, "failed to find codec device\n");
ret = -EPROBE_DEFER;
goto asrc_fail;
@@ -601,19 +636,18 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
priv->cpu_priv.sysclk_id[0] = FSL_SAI_CLK_MAST1;
}
 
-   snprintf(priv->name, sizeof(priv->name), "%s-audio",
-fsl_asoc_card_is_ac97(priv) ? "ac97" :
-codec_dev->name);
-

[PATCH 1/2] ASoC: bindings: fsl-asoc-card: Add compatible string for MQS

2020-06-16 Thread Shengjiu Wang
Add compatible string "fsl,imx-audio-mqs" for MQS

Signed-off-by: Shengjiu Wang 
---
 Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt 
b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index c60a5732d29c..6417c5dffa9a 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -34,6 +34,8 @@ The compatible list for this generic sound card currently:
 
  "fsl,imx-audio-wm8960"
 
+ "fsl,imx-audio-mqs"
+
 Required properties:
 
   - compatible : Contains one of entries in the compatible list.
-- 
2.21.0



[PATCH 2/2] ASoC: fsl_spdif: Add support for imx6sx platform

2020-06-16 Thread Shengjiu Wang
The one difference on imx6sx platform is that the root clock
is shared with ASRC module, so we add a new flags "ind_root_clk"
which means the root clock is independent, then we will not
do the clk_set_rate and clk_round_rate to avoid impact ASRC
module usage.

As add a new flags, we include the soc specific data struct.

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/fsl_spdif.c | 43 +++
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 1b2e516f9162..00e06803d32f 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -42,6 +42,17 @@ static u8 srpc_dpll_locked[] = { 0x0, 0x1, 0x2, 0x3, 0x4, 
0xa, 0xb };
 
 #define DEFAULT_RXCLK_SRC  1
 
+/**
+ * struct fsl_spdif_soc_data: soc specific data
+ *
+ * @imx: for imx platform
+ * @ind_root_clk: flag for round clk rate
+ */
+struct fsl_spdif_soc_data {
+   bool imx;
+   bool ind_root_clk;
+};
+
 /*
  * SPDIF control structure
  * Defines channel status, subcode and Q sub
@@ -93,6 +104,7 @@ struct fsl_spdif_priv {
struct snd_soc_dai_driver cpu_dai_drv;
struct platform_device *pdev;
struct regmap *regmap;
+   const struct fsl_spdif_soc_data *soc;
bool dpll_locked;
u32 txrate[SPDIF_TXRATE_MAX];
u8 txclk_df[SPDIF_TXRATE_MAX];
@@ -110,6 +122,21 @@ struct fsl_spdif_priv {
u32 regcache_srpc;
 };
 
+static struct fsl_spdif_soc_data fsl_spdif_vf610 = {
+   .imx = false,
+   .ind_root_clk = true,
+};
+
+static struct fsl_spdif_soc_data fsl_spdif_imx35 = {
+   .imx = true,
+   .ind_root_clk = true,
+};
+
+static struct fsl_spdif_soc_data fsl_spdif_imx6sx = {
+   .imx = true,
+   .ind_root_clk = false,
+};
+
 /* DPLL locked and lock loss interrupt handler */
 static void spdif_irq_dpll_lock(struct fsl_spdif_priv *spdif_priv)
 {
@@ -421,7 +448,7 @@ static int spdif_set_sample_rate(struct snd_pcm_substream 
*substream,
sysclk_df = spdif_priv->sysclk_df[rate];
 
/* Don't mess up the clocks from other modules */
-   if (clk != STC_TXCLK_SPDIF_ROOT)
+   if (clk != STC_TXCLK_SPDIF_ROOT || !spdif_priv->soc->ind_root_clk)
goto clk_set_bypass;
 
/* The S/PDIF block needs a clock of 64 * fs * txclk_df */
@@ -1186,7 +1213,8 @@ static int fsl_spdif_probe_txclk(struct fsl_spdif_priv 
*spdif_priv,
continue;
 
ret = fsl_spdif_txclk_caldiv(spdif_priv, clk, savesub, index,
-i == STC_TXCLK_SPDIF_ROOT);
+i == STC_TXCLK_SPDIF_ROOT &&
+spdif_priv->soc->ind_root_clk);
if (savesub == ret)
continue;
 
@@ -1230,6 +1258,12 @@ static int fsl_spdif_probe(struct platform_device *pdev)
 
spdif_priv->pdev = pdev;
 
+   spdif_priv->soc = of_device_get_match_data(>dev);
+   if (!spdif_priv->soc) {
+   dev_err(>dev, "failed to get soc data\n");
+   return -ENODEV;
+   }
+
/* Initialize this copy of the CPU DAI driver structure */
memcpy(_priv->cpu_dai_drv, _spdif_dai, sizeof(fsl_spdif_dai));
spdif_priv->cpu_dai_drv.name = dev_name(>dev);
@@ -1359,8 +1393,9 @@ static const struct dev_pm_ops fsl_spdif_pm = {
 };
 
 static const struct of_device_id fsl_spdif_dt_ids[] = {
-   { .compatible = "fsl,imx35-spdif", },
-   { .compatible = "fsl,vf610-spdif", },
+   { .compatible = "fsl,imx35-spdif", .data = _spdif_imx35, },
+   { .compatible = "fsl,vf610-spdif", .data = _spdif_vf610, },
+   { .compatible = "fsl,imx6sx-spdif", .data = _spdif_imx6sx, },
{}
 };
 MODULE_DEVICE_TABLE(of, fsl_spdif_dt_ids);
-- 
2.21.0



[PATCH 1/2] ASoC: bindings: fsl_spdif: Add new compatible string for imx6sx

2020-06-16 Thread Shengjiu Wang
Add new compatible string "fsl,imx6sx-spdif" in the binding document.
And add compatible string "fsl,vf610-spdif" which was missed before.

Signed-off-by: Shengjiu Wang 
---
 Documentation/devicetree/bindings/sound/fsl,spdif.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt 
b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
index 8b324f82a782..e1365b0ee1e9 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -6,7 +6,11 @@ a fibre cable.
 
 Required properties:
 
-  - compatible : Compatible list, must contain "fsl,imx35-spdif".
+  - compatible : Compatible list, should contain one of the following
+ compatibles:
+ "fsl,imx35-spdif",
+ "fsl,vf610-spdif",
+ "fsl,imx6sx-spdif",
 
   - reg: Offset and length of the register set for the 
device.
 
-- 
2.21.0



Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

2020-06-16 Thread Michal Hocko
On Mon 15-06-20 21:57:16, Waiman Long wrote:
> The kzfree() function is normally used to clear some sensitive
> information, like encryption keys, in the buffer before freeing it back
> to the pool. Memset() is currently used for the buffer clearing. However,
> it is entirely possible that the compiler may choose to optimize away the
> memory clearing especially if LTO is being used. To make sure that this
> optimization will not happen, memzero_explicit(), which is introduced
> in v3.18, is now used in kzfree() to do the clearing.
> 
> Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Waiman Long 

Acked-by: Michal Hocko 

Although I am not really sure this is a stable material. Is there any
known instance where the memset was optimized out from kzfree?

> ---
>  mm/slab_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 9e72ba224175..37d48a56431d 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1726,7 +1726,7 @@ void kzfree(const void *p)
>   if (unlikely(ZERO_OR_NULL_PTR(mem)))
>   return;
>   ks = ksize(mem);
> - memset(mem, 0, ks);
> + memzero_explicit(mem, ks);
>   kfree(mem);
>  }
>  EXPORT_SYMBOL(kzfree);
> -- 
> 2.18.1
> 

-- 
Michal Hocko
SUSE Labs


Re: [PATCH] powerpc/ptdump: Fix build failure in hashpagetable.c

2020-06-16 Thread Michael Ellerman
Christophe Leroy  writes:
> H_SUCCESS is only defined when CONFIG_PPC_PSERIES is defined.

It's always defined in hvcall.h, but it doesn't always get included via
plpar_wrappers.h.

It looks to be CONFIG_SMP=n that causes that, for SMP=y we get a copy
via asm/spinlock.h

> != H_SUCCESS means != 0. Modify the test accordingly.

I guess that's an OK solution.

> Reported-by: kernel test robot 
> Fixes: 65e701b2d2a8 ("powerpc/ptdump: drop non vital #ifdefs")
> Cc: sta...@vger.kernel.org

I don't think it needs to go to stable, none of the defconfigs hit it,
we don't even really support SMP=n for 64-bit book3s.

cheers

> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/mm/ptdump/hashpagetable.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/ptdump/hashpagetable.c 
> b/arch/powerpc/mm/ptdump/hashpagetable.c
> index a2c33efc7ce8..5b8bd34cd3a1 100644
> --- a/arch/powerpc/mm/ptdump/hashpagetable.c
> +++ b/arch/powerpc/mm/ptdump/hashpagetable.c
> @@ -258,7 +258,7 @@ static int pseries_find(unsigned long ea, int psize, bool 
> primary, u64 *v, u64 *
>   for (i = 0; i < HPTES_PER_GROUP; i += 4, hpte_group += 4) {
>   lpar_rc = plpar_pte_read_4(0, hpte_group, (void *)ptes);
>  
> - if (lpar_rc != H_SUCCESS)
> + if (lpar_rc)
>   continue;
>   for (j = 0; j < 4; j++) {
>   if (HPTE_V_COMPARE(ptes[j].v, want_v) &&
> -- 
> 2.25.0