Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
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
[PATCH v2 1/2] ASoC: bindings: fsl-asoc-card: Add compatible string for MQS
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
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
Re: [PATCH] powerpc/8xx: use pmd_off() to access a PMD entry in pte_update()
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.
[PATCH v2 1/2] ASoC: bindings: fsl_spdif: Add new compatible string for imx6sx
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 2/2] ASoC: fsl_spdif: Add support for imx6sx platform
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
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
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] scsi: target/sbp: remove firewire SBP target driver
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
[PATCH v2 2/2] ASoC: fsl-asoc-card: Add MQS support
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),
Re: [PATCH V2] powerpc/pseries/svm: Drop unused align argument in alloc_shared_lppaca() function
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);
Re: [PATCH] powerpc/ptdump: Fix build failure in hashpagetable.c
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
Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()
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
[PATCH 1/2] ASoC: bindings: fsl_spdif: Add new compatible string for imx6sx
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
[PATCH 2/2] ASoC: fsl_spdif: Add support for imx6sx platform
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-asoc-card: Add compatible string for MQS
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-asoc-card: Add MQS support
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);
-
Re: [PATCH v2 08/12] mm: Define pasid in mm
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] scsi: target/sbp: remove firewire SBP target driver
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 2/2] cpufreq: Specify default governor on command line
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: powerpc/pci: [PATCH 1/1 V3] PCIE PHB reset
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 2/2] cpufreq: Specify default governor on command line
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()
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
[PATCH kernel] powerpc/powernv/ioda: Return correct error if TCE level allocation failed
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 v3] ASoC: fsl_ssi: Fix bclk calculation for mono channel
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
Re: [PATCH v4 6/7] KVM: MIPS: clean up redundant 'kvm_run' parameters
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
[PATCH v5 0/2] mm, treewide: Rename kzfree() to kfree_sensitive()
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 v4 3/3] btrfs: Use kfree() in btrfs_ioctl_get_subvol_info()
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.
[PATCH v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()
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 1/2] powerpc/syscalls: Use the number when building SPU syscall table
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
[PATCH 2/2] powerpc/syscalls: Split SPU-ness out of ABI
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
Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
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.
Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()
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: [PATCH v2 08/12] mm: Define pasid in mm
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 3/3] btrfs: Use kfree() in btrfs_ioctl_get_subvol_info()
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 2/3] mm, treewide: Rename kzfree() to kfree_sensitive()
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 v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support
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()
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] scsi: target/sbp: remove firewire SBP target driver
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 v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()
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
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] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
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 v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support
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 v4 1/3] mm/slab: Use memzero_explicit() in kzfree()
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()
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
Re: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
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()
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 v5 2/2] mm, treewide: Rename kzfree() to kfree_sensitive()
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 v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
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] tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes
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 v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
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()
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: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
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 v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
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: powerpc/pci: [PATCH 1/1 V3] PCIE PHB reset
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.
[PATCH kernel v2] powerpc/powernv/ioda: Return correct error if TCE level allocation failed
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
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: [PATCH] scsi: target/sbp: remove firewire SBP target driver
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
Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
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()
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 2/2] ASoC: fsl_spdif: Add support for imx6sx platform
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 kernel] powerpc/powernv/ioda: Return correct error if TCE level allocation failed
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 v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
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] scsi: target/sbp: remove firewire SBP target driver
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
[powerpc:merge] BUILD SUCCESS c3405d517d606e965030026daec198d314f20195
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
[powerpc:fixes-test] BUILD SUCCESS 0bdcfa182506526fbe4e088ff9ca86a31b81828d
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
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
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:next-test] BUILD SUCCESS b2f7aff54d10f344bc8424ab98d29e028486ba26
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
