Re: [PATCH 1/3] ARM: dts: imx: Change sdhci node name on i.MX27/i.MX31 SoCs
On Tue, Jun 02, 2020 at 02:24:50PM +0800, Anson Huang wrote: > Change i.MX27/i.MX31 node name from sdhci to mmc to be compliant > with yaml schema, it requires the nodename to be "mmc". > > Signed-off-by: Anson Huang Applied all, thanks.
Re: [PATCH] thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power
Hi Finley,
Please use versioning (v2) when resending a patch.
On Fri, Jun 19, 2020 at 2:39 PM Finley Xiao wrote:
>
> The function cpu_power_to_freq is used to find a frequency and set the
> cooling device to consume at most the power to be converted. For example,
> if the power to be converted is 80mW, and the em table is as follow.
> struct em_cap_state table[] = {
> /* KHz mW */
> { 1008000, 36, 0 },
> { 120, 49, 0 },
> { 1296000, 59, 0 },
> { 1416000, 72, 0 },
> { 1512000, 86, 0 },
> };
> The target frequency should be 1416000KHz, not 1512000KHz.
>
> Fixes: 349d39dc5739 ("thermal: cpu_cooling: merge frequency and power tables")
> Cc: # v4.13+
> Signed-off-by: Finley Xiao
> Acked-by: Viresh Kumar
Reviewed-by: Amit Kucheria
> ---
> drivers/thermal/cpufreq_cooling.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/cpufreq_cooling.c
> b/drivers/thermal/cpufreq_cooling.c
> index 9e124020519f..6c0e1b053126 100644
> --- a/drivers/thermal/cpufreq_cooling.c
> +++ b/drivers/thermal/cpufreq_cooling.c
> @@ -123,12 +123,12 @@ static u32 cpu_power_to_freq(struct
> cpufreq_cooling_device *cpufreq_cdev,
> {
> int i;
>
> - for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
> - if (power > cpufreq_cdev->em->table[i].power)
> + for (i = cpufreq_cdev->max_level; i >= 0; i--) {
> + if (power >= cpufreq_cdev->em->table[i].power)
> break;
> }
>
> - return cpufreq_cdev->em->table[i + 1].frequency;
> + return cpufreq_cdev->em->table[i].frequency;
> }
>
> /**
> --
> 2.11.0
>
>
>
[PATCH V2 2/3] arm64: dts: imx8qxp: add i2c aliases
From: Peng Fan The devices could be enumerated properly with aliases. Signed-off-by: Peng Fan --- arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi index 33363c127478..3b2fada99c09 100644 --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi @@ -27,6 +27,10 @@ gpio5 = &lsio_gpio5; gpio6 = &lsio_gpio6; gpio7 = &lsio_gpio7; + i2c0 = &adma_i2c0; + i2c1 = &adma_i2c1; + i2c2 = &adma_i2c2; + i2c3 = &adma_i2c3; mmc0 = &usdhc1; mmc1 = &usdhc2; mmc2 = &usdhc3; -- 2.16.4
[PATCH V2 3/3] arm64: dts: imx8qxp: Add ethernet alias
From: Peng Fan
Add ethernet alias, so bootloader code can use this to find the
primary ethernet device, and set the MAC address.
Signed-off-by: Peng Fan
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 3b2fada99c09..e46faac1fe71 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -19,6 +19,8 @@
#size-cells = <2>;
aliases {
+ ethernet0 = &fec1;
+ ethernet1 = &fec2;
gpio0 = &lsio_gpio0;
gpio1 = &lsio_gpio1;
gpio2 = &lsio_gpio2;
--
2.16.4
Re: [PATCH RFC v8 02/11] vhost: use batched get_vq_desc version
On Tue, Jun 23, 2020 at 4:51 AM Jason Wang wrote:
>
>
> On 2020/6/23 上午12:00, Michael S. Tsirkin wrote:
> > On Wed, Jun 17, 2020 at 11:19:26AM +0800, Jason Wang wrote:
> >> On 2020/6/11 下午7:34, Michael S. Tsirkin wrote:
> >>>static void vhost_vq_free_iovecs(struct vhost_virtqueue *vq)
> >>>{
> >>> kfree(vq->descs);
> >>> @@ -394,6 +400,9 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev
> >>> *dev)
> >>> for (i = 0; i < dev->nvqs; ++i) {
> >>> vq = dev->vqs[i];
> >>> vq->max_descs = dev->iov_limit;
> >>> + if (vhost_vq_num_batch_descs(vq) < 0) {
> >>> + return -EINVAL;
> >>> + }
> >> This check breaks vdpa which set iov_limit to zero. Consider iov_limit is
> >> meaningless to vDPA, I wonder we can skip the test when device doesn't use
> >> worker.
> >>
> >> Thanks
> > It doesn't need iovecs at all, right?
> >
> > -- MST
>
>
> Yes, so we may choose to bypass the iovecs as well.
>
> Thanks
>
I think that the kmalloc_array returns ZERO_SIZE_PTR for all of them
in that case, so I didn't bother to skip the kmalloc_array parts.
Would you prefer to skip them all and let them NULL? Or have I
misunderstood what you mean?
Thanks!
[PATCH V2 0/3] arm64: dts: imx8qxp: dtb aliases fix/update
From: Peng Fan V2: Fix order in patch 2/3, no other changes Minor patchset to fix and update alias for i.MX8QXP Peng Fan (3): arm64: dts: imx8qxp: add alias for lsio MU arm64: dts: imx8qxp: add i2c aliases arm64: dts: imx8qxp: Add ethernet alias arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 10 ++ 1 file changed, 10 insertions(+) -- 2.16.4
[PATCH V2 1/3] arm64: dts: imx8qxp: add alias for lsio MU
From: Peng Fan Add lsio mu alias for all lsio MUs that could communicate with SCU, imx_scu_enable_general_irq_channel will parse the alias to get the mu resource id, if using other MU, not MU1, the `mu_resource_id` is not what we expect, so add alias to fix this issue. Signed-off-by: Peng Fan --- arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi index d1c3c98e4b39..33363c127478 100644 --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi @@ -30,7 +30,11 @@ mmc0 = &usdhc1; mmc1 = &usdhc2; mmc2 = &usdhc3; + mu0 = &lsio_mu0; mu1 = &lsio_mu1; + mu2 = &lsio_mu2; + mu3 = &lsio_mu3; + mu4 = &lsio_mu4; serial0 = &adma_lpuart0; serial1 = &adma_lpuart1; serial2 = &adma_lpuart2; -- 2.16.4
Re: [v1,net-next 1/4] net: qos: add tc police offloading action with max frame size limit
On Tue, Jun 23, 2020 at 02:34:09PM +0800, Po Liu wrote:
> From: Po Liu
>
> Current police offloading support the 'burst'' and 'rate_bytes_ps'. Some
s/support/supports/
s/'burst''/'burst'/
> hardware own the capability to limit the frame size. If the frame size
> larger than the setting, the frame would be dropped. For the police
> action itself already accept the 'mtu' parameter in tc command. But not
s/accept/accepts/
> extend to tc flower offloading. So extend 'mtu' to tc flower offloading.
Throughout the submission you are always using the term 'flower
offloading', but this has nothing to do with flower. Flower is the
classifier, whereas you are extending police action which can be tied to
any classifier.
>
> Signed-off-by: Po Liu
> ---
> continue the thread 20200306125608.11717-7-po@nxp.com for the police
> action offloading.
For a patch set you need a cover letter (patch 0). It should include
necessary background, motivation and overview of the patches. You can
mention there that some of the patches were sent as RFC back in March
and provide a link:
https://lore.kernel.org/netdev/20200306125608.11717-1-po@nxp.com/
The code itself looks good to me.
>
> include/net/flow_offload.h | 1 +
> include/net/tc_act/tc_police.h | 10 ++
> net/sched/cls_api.c| 1 +
> 3 files changed, 12 insertions(+)
>
> diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
> index 00c15f14c434..c2ef19c6b27d 100644
> --- a/include/net/flow_offload.h
> +++ b/include/net/flow_offload.h
> @@ -234,6 +234,7 @@ struct flow_action_entry {
> struct {/* FLOW_ACTION_POLICE */
> s64 burst;
> u64 rate_bytes_ps;
> + u32 mtu;
> } police;
> struct {/* FLOW_ACTION_CT */
> int action;
> diff --git a/include/net/tc_act/tc_police.h b/include/net/tc_act/tc_police.h
> index f098ad4424be..cd973b10ae8c 100644
> --- a/include/net/tc_act/tc_police.h
> +++ b/include/net/tc_act/tc_police.h
> @@ -69,4 +69,14 @@ static inline s64 tcf_police_tcfp_burst(const struct
> tc_action *act)
> return params->tcfp_burst;
> }
>
> +static inline u32 tcf_police_tcfp_mtu(const struct tc_action *act)
> +{
> + struct tcf_police *police = to_police(act);
> + struct tcf_police_params *params;
> +
> + params = rcu_dereference_protected(police->params,
> +lockdep_is_held(&police->tcf_lock));
> + return params->tcfp_mtu;
> +}
> +
> #endif /* __NET_TC_POLICE_H */
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index a00a203b2ef5..6aba7d5ba1ec 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -3658,6 +3658,7 @@ int tc_setup_flow_action(struct flow_action
> *flow_action,
> entry->police.burst = tcf_police_tcfp_burst(act);
> entry->police.rate_bytes_ps =
> tcf_police_rate_bytes_ps(act);
> + entry->police.mtu = tcf_police_tcfp_mtu(act);
> } else if (is_tcf_ct(act)) {
> entry->id = FLOW_ACTION_CT;
> entry->ct.action = tcf_ct_action(act);
> --
> 2.17.1
>
Re: [PATCH v4] coccinelle: misc: add array_size_dup script to detect missed overflow checks
I don't agree with any of these comments. julia On Tue, 23 Jun 2020, Markus Elfring wrote: > > Changes in v2: > … > > - assignment operator used > > I prefer the distinction for the application of corresponding metavariables. > > > > Changes in v3: > … > > - \(&E1\|&E2\) changed to &\(E1\|E2\) > > Would it be more helpful to mention the movement of the ampersand > before SmPL disjunctions? > > > … > >+/// Three types of patterns for these functions: > > Will another adjustment be needed according to your information “duplicates > warning removed”? > > > … > > +virtual context > > +virtual report > > +virtual org > > Can the following SmPL code variant ever become more attractive? > > +virtual context, report, org > > > … > > +expression subE1 <= as.E1; > > +expression subE2 <= as.E2; > > +expression as.E1, as.E2, E3; > > How do you think about the following SmPL code variant? > > +expression subE1 <= as.E1, > + subE2 <= as.E2, > + as.E1, as.E2, E3; > > > … > > +msg = "WARNING: array_size is used later (line %s) to compute the same > > size" % (p2[0].line) > > +coccilib.report.print_report(p1[0], msg) > > Please omit the extra Python variable “msg” for the passing of such simple > message objects. > > What does hinder you to take the proposed script variants better into account? > > Regards, > Markus >
Re: [PATCH v2] Revert "zram: convert remaining CLASS_ATTR() to CLASS_ATTR_RO()"
On Wed, Jun 17, 2020 at 01:49:46PM +0200, Greg Kroah-Hartman wrote:
> From: Wade Mealing
>
> Turns out that the permissions for 0400 really are what we want here,
> otherwise any user can read from this file.
>
> [fixed formatting, added changelog, and made attribute static - gregkh]
>
> Reported-by: Wade Mealing
> Cc: stable
> Fixes: f40609d1591f ("zram: convert remaining CLASS_ATTR() to
> CLASS_ATTR_RO()")
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1847832
> Signed-off-by: Greg Kroah-Hartman
Acked-by: Minchan Kim
[PATCH 1/2] ASoC: fsl-asoc-card: Add WM8524 support
WM8524 only supports playback mode, and only works at
slave mode.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl-asoc-card.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index d0543a53764e..57ea1b072326 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -611,6 +611,15 @@ static int fsl_asoc_card_probe(struct platform_device
*pdev)
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 if (of_device_is_compatible(np, "fsl,imx-audio-wm8524")) {
+ codec_dai_name = "wm8524-hifi";
+ priv->card.set_bias_level = NULL;
+ priv->dai_fmt |= SND_SOC_DAIFMT_CBS_CFS;
+ priv->dai_link[1].dpcm_capture = 0;
+ priv->dai_link[2].dpcm_capture = 0;
+ priv->cpu_priv.slot_width = 32;
+ priv->card.dapm_routes = audio_map_tx;
+ priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_tx);
} else {
dev_err(&pdev->dev, "unknown Device Tree compatible\n");
ret = -EINVAL;
@@ -760,6 +769,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = {
{ .compatible = "fsl,imx-audio-wm8962", },
{ .compatible = "fsl,imx-audio-wm8960", },
{ .compatible = "fsl,imx-audio-mqs", },
+ { .compatible = "fsl,imx-audio-wm8524", },
{}
};
MODULE_DEVICE_TABLE(of, fsl_asoc_card_dt_ids);
--
2.21.0
Re: [PATCH] ARM: dts: imx6sll: Make ssi node name same as other platforms
On Tue, Jun 02, 2020 at 06:44:50PM +0800, Shengjiu Wang wrote: > In imx6sll.dtsi, the ssi node name is different with other > platforms (imx6qdl, imx6sl, imx6sx), but the > sound/soc/fsl/fsl-asoc-card.c machine driver needs to check > ssi node name for audmux configuration, then different ssi > node name causes issue on imx6sll platform. > > So we change ssi node name to make all platforms have same > name. > > Signed-off-by: Shengjiu Wang Applied, thanks.
[PATCH 2/2] ASoC: bindings: fsl-asoc-card: Add compatible string for wm8524
In order to support wm8524 codec with fsl-asoc-card machine driver, add compatible string "fsl,imx-audio-wm8524". 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 ca9a3a43adfd..133d7e14a4d0 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt @@ -36,6 +36,8 @@ The compatible list for this generic sound card currently: "fsl,imx-audio-mqs" + "fsl,imx-audio-wm8524" + Required properties: - compatible : Contains one of entries in the compatible list. -- 2.21.0
Re: [PATCH] cpufreq: cppc: Reorder code and remove apply_hisi_workaround variable
Hi Viresh,
On 2020/6/23 13:15, Viresh Kumar wrote:
> With the current approach we have an extra check in the
> cppc_cpufreq_get_rate() callback, which checks if hisilicon's get rate
> implementation should be used instead. While it works fine, the approach
> isn't very straight forward, over that we have an extra check in the
> routine.
>
> Rearrange code and update the cpufreq driver's get() callback pointer
> directly for the hisilicon case. This gets the extra variable is removed
> and the extra check isn't required anymore as well.
>
> Signed-off-by: Viresh Kumar
> ---
> Xiongfeng Wang, will it be possible for you to give this a try as I
> can't really test it locally.
I have tested it on D05. It works well.
Tested-by: Xiongfeng Wang
Thanks,
Xiongfeng
>
> drivers/cpufreq/cppc_cpufreq.c | 91 --
> 1 file changed, 42 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 257d726a4456..03a21daddbec 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -45,8 +45,6 @@ struct cppc_workaround_oem_info {
> u32 oem_revision;
> };
>
> -static bool apply_hisi_workaround;
> -
> static struct cppc_workaround_oem_info wa_info[] = {
> {
> .oem_id = "HISI ",
> @@ -59,50 +57,6 @@ static struct cppc_workaround_oem_info wa_info[] = {
> }
> };
>
> -static unsigned int cppc_cpufreq_perf_to_khz(struct cppc_cpudata *cpu,
> - unsigned int perf);
> -
> -/*
> - * HISI platform does not support delivered performance counter and
> - * reference performance counter. It can calculate the performance using the
> - * platform specific mechanism. We reuse the desired performance register to
> - * store the real performance calculated by the platform.
> - */
> -static unsigned int hisi_cppc_cpufreq_get_rate(unsigned int cpunum)
> -{
> - struct cppc_cpudata *cpudata = all_cpu_data[cpunum];
> - u64 desired_perf;
> - int ret;
> -
> - ret = cppc_get_desired_perf(cpunum, &desired_perf);
> - if (ret < 0)
> - return -EIO;
> -
> - return cppc_cpufreq_perf_to_khz(cpudata, desired_perf);
> -}
> -
> -static void cppc_check_hisi_workaround(void)
> -{
> - struct acpi_table_header *tbl;
> - acpi_status status = AE_OK;
> - int i;
> -
> - status = acpi_get_table(ACPI_SIG_PCCT, 0, &tbl);
> - if (ACPI_FAILURE(status) || !tbl)
> - return;
> -
> - for (i = 0; i < ARRAY_SIZE(wa_info); i++) {
> - if (!memcmp(wa_info[i].oem_id, tbl->oem_id, ACPI_OEM_ID_SIZE) &&
> - !memcmp(wa_info[i].oem_table_id, tbl->oem_table_id,
> ACPI_OEM_TABLE_ID_SIZE) &&
> - wa_info[i].oem_revision == tbl->oem_revision) {
> - apply_hisi_workaround = true;
> - break;
> - }
> - }
> -
> - acpi_put_table(tbl);
> -}
> -
> /* Callback function used to retrieve the max frequency from DMI */
> static void cppc_find_dmi_mhz(const struct dmi_header *dm, void *private)
> {
> @@ -402,9 +356,6 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int
> cpunum)
> struct cppc_cpudata *cpu = all_cpu_data[cpunum];
> int ret;
>
> - if (apply_hisi_workaround)
> - return hisi_cppc_cpufreq_get_rate(cpunum);
> -
> ret = cppc_get_perf_ctrs(cpunum, &fb_ctrs_t0);
> if (ret)
> return ret;
> @@ -455,6 +406,48 @@ static struct cpufreq_driver cppc_cpufreq_driver = {
> .name = "cppc_cpufreq",
> };
>
> +/*
> + * HISI platform does not support delivered performance counter and
> + * reference performance counter. It can calculate the performance using the
> + * platform specific mechanism. We reuse the desired performance register to
> + * store the real performance calculated by the platform.
> + */
> +static unsigned int hisi_cppc_cpufreq_get_rate(unsigned int cpunum)
> +{
> + struct cppc_cpudata *cpudata = all_cpu_data[cpunum];
> + u64 desired_perf;
> + int ret;
> +
> + ret = cppc_get_desired_perf(cpunum, &desired_perf);
> + if (ret < 0)
> + return -EIO;
> +
> + return cppc_cpufreq_perf_to_khz(cpudata, desired_perf);
> +}
> +
> +static void cppc_check_hisi_workaround(void)
> +{
> + struct acpi_table_header *tbl;
> + acpi_status status = AE_OK;
> + int i;
> +
> + status = acpi_get_table(ACPI_SIG_PCCT, 0, &tbl);
> + if (ACPI_FAILURE(status) || !tbl)
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(wa_info); i++) {
> + if (!memcmp(wa_info[i].oem_id, tbl->oem_id, ACPI_OEM_ID_SIZE) &&
> + !memcmp(wa_info[i].oem_table_id, tbl->oem_table_id,
> ACPI_OEM_TABLE_ID_SIZE) &&
> + wa_info[i].oem_revision == tbl->oem_revision) {
> + /* Overwrite the get() callback */
> + cppc_cpufreq_driver.get = hisi_cppc_cp
RE: [PATCH 2/3] arm64: dts: imx8qxp: add i2c aliases
Hi Shawn,
> Subject: Re: [PATCH 2/3] arm64: dts: imx8qxp: add i2c aliases
>
> On Mon, Jun 01, 2020 at 10:06:19AM +0800, peng@nxp.com wrote:
> > From: Peng Fan
> >
> > The devices could be enumerated properly with aliases.
> >
> > Signed-off-by: Peng Fan
> > ---
> > arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > index 33363c127478..8ce997110cd6 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > @@ -19,6 +19,10 @@
> > #size-cells = <2>;
> >
> > aliases {
> > + i2c0 = &adma_i2c0;
> > + i2c1 = &adma_i2c1;
> > + i2c2 = &adma_i2c2;
> > + i2c3 = &adma_i2c3;
>
> Had a second look. It breaks alphabetical order. So dropped the series.
V2 has this addressed.
https://patchwork.kernel.org/cover/11619867/
Thanks,
Peng.
>
> Shawn
>
> > gpio0 = &lsio_gpio0;
> > gpio1 = &lsio_gpio1;
> > gpio2 = &lsio_gpio2;
> > --
> > 2.16.4
> >
[PATCH v2 06/15] scripts/kernel-doc: handle function pointer prototypes
There are some function pointer prototypes inside the net
includes, like this one:
int (*pcs_config)(struct phylink_config *config, unsigned int mode,
phy_interface_t interface, const unsigned long
*advertising);
There's nothing wrong using it with kernel-doc, but we need to
add a rule for it to parse such kind of prototype.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kernel-doc | 5 +
1 file changed, 5 insertions(+)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 43b8312363a5..e991d7f961e9 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1771,6 +1771,11 @@ sub process_proto_function($$) {
$prototype =~ s@/\*.*?\*/@@gos; # strip comments.
$prototype =~ s@[\r\n]+@ @gos; # strip newlines/cr's.
$prototype =~ s@^\s+@@gos; # strip leading spaces
+
+# Handle prototypes for function pointers like:
+# int (*pcs_config)(struct foo)
+ $prototype =~ s@^(\S+\s+)\(\s*\*(\S+)\)@$1$2@gos;
+
if ($prototype =~ /SYSCALL_DEFINE/) {
syscall_munge();
}
--
2.26.2
Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading
On Tue, Jun 23, 2020 at 02:34:11PM +0800, Po Liu wrote:
> From: Po Liu
>
> Hardware may own many entries for police flow. So that make one(or
> multi) flow to be policed by one hardware entry. This patch add the
> police action index provide to the driver side make it mapping the
> driver hardware entry index.
Maybe first mention that it is possible for multiple filters in software
to share the same policer. Something like:
"
It is possible for several tc filters to share the same police action by
specifying the action's index when installing the filters.
Propagate this index to device drivers through the flow offload
intermediate representation, so that drivers could share a single
hardware policer between multiple filters.
"
>
> Signed-off-by: Po Liu
> ---
> include/net/flow_offload.h | 1 +
> net/sched/cls_api.c| 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
> index c2ef19c6b27d..eed98075b1ae 100644
> --- a/include/net/flow_offload.h
> +++ b/include/net/flow_offload.h
> @@ -232,6 +232,7 @@ struct flow_action_entry {
> booltruncate;
> } sample;
> struct {/* FLOW_ACTION_POLICE */
> + u32 index;
> s64 burst;
> u64 rate_bytes_ps;
> u32 mtu;
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 6aba7d5ba1ec..fdc4c89ca1fa 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -3659,6 +3659,7 @@ int tc_setup_flow_action(struct flow_action
> *flow_action,
> entry->police.rate_bytes_ps =
> tcf_police_rate_bytes_ps(act);
> entry->police.mtu = tcf_police_tcfp_mtu(act);
> + entry->police.index = act->tcfa_index;
> } else if (is_tcf_ct(act)) {
> entry->id = FLOW_ACTION_CT;
> entry->ct.action = tcf_ct_action(act);
> --
> 2.17.1
>
[PATCH v2 15/15] docs: fs: proc.rst: convert a new chapter to ReST
A new chapter was added to proc.rst. Adjust the markups
to avoid this warning:
Documentation/filesystems/proc.rst:2194: WARNING: Inconsistent literal
block quoting.
And to properly mark the code-blocks there.
Fixes: 37e7647a7212 ("docs: proc: add documentation for "hidepid=4" and
"subset=pid" options and new mount behavior")
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Kees Cook
---
Documentation/filesystems/proc.rst | 44 ++
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/Documentation/filesystems/proc.rst
b/Documentation/filesystems/proc.rst
index 53a0230a08e2..cc0fd2685562 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -2179,46 +2179,44 @@ subset=pid hides all top level files and directories in
the procfs that
are not related to tasks.
5 Filesystem behavior
-
+---
Originally, before the advent of pid namepsace, procfs was a global file
system. It means that there was only one procfs instance in the system.
When pid namespace was added, a separate procfs instance was mounted in
each pid namespace. So, procfs mount options are global among all
-mountpoints within the same namespace.
+mountpoints within the same namespace::
-::
+ # grep ^proc /proc/mounts
+ proc /proc proc rw,relatime,hidepid=2 0 0
-# grep ^proc /proc/mounts
-proc /proc proc rw,relatime,hidepid=2 0 0
+ # strace -e mount mount -o hidepid=1 -t proc proc /tmp/proc
+ mount("proc", "/tmp/proc", "proc", 0, "hidepid=1") = 0
+ +++ exited with 0 +++
-# strace -e mount mount -o hidepid=1 -t proc proc /tmp/proc
-mount("proc", "/tmp/proc", "proc", 0, "hidepid=1") = 0
-+++ exited with 0 +++
-
-# grep ^proc /proc/mounts
-proc /proc proc rw,relatime,hidepid=2 0 0
-proc /tmp/proc proc rw,relatime,hidepid=2 0 0
+ # grep ^proc /proc/mounts
+ proc /proc proc rw,relatime,hidepid=2 0 0
+ proc /tmp/proc proc rw,relatime,hidepid=2 0 0
and only after remounting procfs mount options will change at all
-mountpoints.
+mountpoints::
-# mount -o remount,hidepid=1 -t proc proc /tmp/proc
+ # mount -o remount,hidepid=1 -t proc proc /tmp/proc
-# grep ^proc /proc/mounts
-proc /proc proc rw,relatime,hidepid=1 0 0
-proc /tmp/proc proc rw,relatime,hidepid=1 0 0
+ # grep ^proc /proc/mounts
+ proc /proc proc rw,relatime,hidepid=1 0 0
+ proc /tmp/proc proc rw,relatime,hidepid=1 0 0
This behavior is different from the behavior of other filesystems.
The new procfs behavior is more like other filesystems. Each procfs mount
creates a new procfs instance. Mount options affect own procfs instance.
It means that it became possible to have several procfs instances
-displaying tasks with different filtering options in one pid namespace.
+displaying tasks with different filtering options in one pid namespace::
-# mount -o hidepid=invisible -t proc proc /proc
-# mount -o hidepid=noaccess -t proc proc /tmp/proc
-# grep ^proc /proc/mounts
-proc /proc proc rw,relatime,hidepid=invisible 0 0
-proc /tmp/proc proc rw,relatime,hidepid=noaccess 0 0
+ # mount -o hidepid=invisible -t proc proc /proc
+ # mount -o hidepid=noaccess -t proc proc /tmp/proc
+ # grep ^proc /proc/mounts
+ proc /proc proc rw,relatime,hidepid=invisible 0 0
+ proc /tmp/proc proc rw,relatime,hidepid=noaccess 0 0
--
2.26.2
[PATCH v2 14/15] docs: fix references for DMA*.txt files
As we moved those files to core-api, fix references to point to their newer locations. Signed-off-by: Mauro Carvalho Chehab --- Documentation/PCI/pci.rst | 6 +++--- Documentation/block/biodoc.rst | 2 +- Documentation/bus-virt-phys-mapping.txt| 2 +- Documentation/core-api/dma-api.rst | 6 +++--- Documentation/core-api/dma-isa-lpc.rst | 2 +- Documentation/driver-api/usb/dma.rst | 6 +++--- .../translations/ko_KR/memory-barriers.txt | 6 +++--- arch/ia64/hp/common/sba_iommu.c| 12 ++-- arch/parisc/kernel/pci-dma.c | 2 +- arch/x86/include/asm/dma-mapping.h | 4 ++-- arch/x86/kernel/amd_gart_64.c | 2 +- drivers/parisc/sba_iommu.c | 14 +++--- include/linux/dma-mapping.h| 2 +- include/media/videobuf-dma-sg.h| 2 +- kernel/dma/debug.c | 2 +- 15 files changed, 35 insertions(+), 35 deletions(-) diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index 8c016d8c9862..d10d3fe604c5 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -265,7 +265,7 @@ Set the DMA mask size - .. note:: If anything below doesn't make sense, please refer to - Documentation/DMA-API.txt. This section is just a reminder that + :doc:`/core-api/dma-api`. This section is just a reminder that drivers need to indicate DMA capabilities of the device and is not an authoritative source for DMA interfaces. @@ -291,7 +291,7 @@ Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are Setup shared control data - Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared) -memory. See Documentation/DMA-API.txt for a full description of +memory. See :doc:`/core-api/dma-api` for a full description of the DMA APIs. This section is just a reminder that it needs to be done before enabling DMA on the device. @@ -421,7 +421,7 @@ owners if there is one. Then clean up "consistent" buffers which contain the control data. -See Documentation/DMA-API.txt for details on unmapping interfaces. +See :doc:`/core-api/dma-api` for details on unmapping interfaces. Unregister from other subsystems diff --git a/Documentation/block/biodoc.rst b/Documentation/block/biodoc.rst index b964796ec9c7..ba7f45d0271c 100644 --- a/Documentation/block/biodoc.rst +++ b/Documentation/block/biodoc.rst @@ -196,7 +196,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address do not have a corresponding kernel virtual address space mapping) and low-memory pages. -Note: Please refer to Documentation/DMA-API-HOWTO.txt for a discussion +Note: Please refer to :doc:`/core-api/dma-api-howto` for a discussion on PCI high mem DMA aspects and mapping of scatter gather lists, and support for 64 bit PCI. diff --git a/Documentation/bus-virt-phys-mapping.txt b/Documentation/bus-virt-phys-mapping.txt index 4bb07c2f3e7d..c7bc99cd2e21 100644 --- a/Documentation/bus-virt-phys-mapping.txt +++ b/Documentation/bus-virt-phys-mapping.txt @@ -8,7 +8,7 @@ How to access I/O mapped memory from within device drivers The virt_to_bus() and bus_to_virt() functions have been superseded by the functionality provided by the PCI DMA interface - (see Documentation/DMA-API-HOWTO.txt). They continue + (see :doc:`/core-api/dma-api-howto`). They continue to be documented below for historical purposes, but new code must not use them. --davidm 00/12/12 diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst index 2d8d2fed7317..63b4a2f20867 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -5,7 +5,7 @@ Dynamic DMA mapping using the generic device :Author: James E.J. Bottomley This document describes the DMA API. For a more gentle introduction -of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt. +of the API (and actual examples), see :doc:`/core-api/dma-api-howto`. This API is split into two pieces. Part I describes the basic API. Part II describes extensions for supporting non-consistent memory @@ -471,7 +471,7 @@ without the _attrs suffixes, except that they pass an optional dma_attrs. The interpretation of DMA attributes is architecture-specific, and -each attribute should be documented in Documentation/DMA-attributes.txt. +each attribute should be documented in :doc:`/core-api/dma-attributes`. If dma_attrs are 0, the semantics of each of these functions is identical to those of the corresponding function @@ -484,7 +484,7 @@ for DMA:: #include /* DMA_ATTR_FOO should be defined in linux/dma-mapping.h and - * documented in Documentation/DMA-attributes.txt
[PATCH v2 09/15] selftests/vm/keys: fix a broken reference at protection_keys.c
Changeset 1eecbcdca2bd ("docs: move protection-keys.rst to the core-api book")
from Jun 7, 2019 converted protection-keys.txt file to ReST.
A recent change at protection_keys.c partially reverted such
changeset, causing it to point to a non-existing file:
- * Tests x86 Memory Protection Keys (see
Documentation/core-api/protection-keys.rst)
+ * Tests Memory Protection Keys (see
Documentation/vm/protection-keys.txt)
It sounds to me that the changeset that introduced such change
4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a generic
name")
could also have other side effects, as it sounds that it was not
generated against uptream code, but, instead, against a version
older than Jun 7, 2019.
Fixes: 4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a
generic name")
Signed-off-by: Mauro Carvalho Chehab
---
tools/testing/selftests/vm/protection_keys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/vm/protection_keys.c
b/tools/testing/selftests/vm/protection_keys.c
index fc19addcb5c8..fdbb602ecf32 100644
--- a/tools/testing/selftests/vm/protection_keys.c
+++ b/tools/testing/selftests/vm/protection_keys.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Tests Memory Protection Keys (see Documentation/vm/protection-keys.txt)
+ * Tests Memory Protection Keys (see
Documentation/core-api/protection-keys.rst)
*
* There are examples in here of:
* * how to set protection keys on memory
--
2.26.2
[PATCH v2 01/15] mm: vmalloc.c: remove a kernel-doc annotation from a removed parameter
The prot argument was removed. Drop it als from the kernel-doc
markup.
Fixes: 3c8ce1be43d3 ("mm: remove the prot argument from vm_map_ram")
Signed-off-by: Mauro Carvalho Chehab
---
mm/vmalloc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 963db1037f61..c3b3f94e08da 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1809,7 +1809,6 @@ EXPORT_SYMBOL(vm_unmap_ram);
* @pages: an array of pointers to the pages to be mapped
* @count: number of pages
* @node: prefer to allocate data structures on this node
- * @prot: memory protection to use. PAGE_KERNEL for regular RAM
*
* If you use this function for less than VMAP_MAX_ALLOC pages, it could be
* faster than vmap so it's good. But if you mix long-life and short-life
--
2.26.2
[PATCH v2 10/15] docs: hugetlbpage.rst: fix some warnings
Some new command line parameters were added at hugetlbpage.rst.
Adjust them in order to properly parse that part of the file,
avoiding those warnings:
Documentation/admin-guide/mm/hugetlbpage.rst:105: WARNING: Unexpected
indentation.
Documentation/admin-guide/mm/hugetlbpage.rst:108: WARNING: Unexpected
indentation.
Documentation/admin-guide/mm/hugetlbpage.rst:109: WARNING: Block quote ends
without a blank line; unexpected unindent.
Documentation/admin-guide/mm/hugetlbpage.rst:112: WARNING: Block quote ends
without a blank line; unexpected unindent.
Documentation/admin-guide/mm/hugetlbpage.rst:120: WARNING: Unexpected
indentation.
Documentation/admin-guide/mm/hugetlbpage.rst:121: WARNING: Block quote ends
without a blank line; unexpected unindent.
Documentation/admin-guide/mm/hugetlbpage.rst:132: WARNING: Unexpected
indentation.
Documentation/admin-guide/mm/hugetlbpage.rst:135: WARNING: Block quote ends
without a blank line; unexpected unindent.
Fixes: cd9fa28b5351 ("hugetlbfs: clean up command line processing")
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/mm/hugetlbpage.rst | 23 +++-
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst
b/Documentation/admin-guide/mm/hugetlbpage.rst
index 5026e58826e2..015a5f7d7854 100644
--- a/Documentation/admin-guide/mm/hugetlbpage.rst
+++ b/Documentation/admin-guide/mm/hugetlbpage.rst
@@ -101,37 +101,48 @@ be specified in bytes with optional scale suffix
[kKmMgG]. The default huge
page size may be selected with the "default_hugepagesz=" boot parameter.
Hugetlb boot command line parameter semantics
-hugepagesz - Specify a huge page size. Used in conjunction with hugepages
+
+hugepagesz
+ Specify a huge page size. Used in conjunction with hugepages
parameter to preallocate a number of huge pages of the specified
size. Hence, hugepagesz and hugepages are typically specified in
- pairs such as:
+ pairs such as::
+
hugepagesz=2M hugepages=512
+
hugepagesz can only be specified once on the command line for a
specific huge page size. Valid huge page sizes are architecture
dependent.
-hugepages - Specify the number of huge pages to preallocate. This typically
+hugepages
+ Specify the number of huge pages to preallocate. This typically
follows a valid hugepagesz or default_hugepagesz parameter. However,
if hugepages is the first or only hugetlb command line parameter it
implicitly specifies the number of huge pages of default size to
allocate. If the number of huge pages of default size is implicitly
specified, it can not be overwritten by a hugepagesz,hugepages
parameter pair for the default size.
- For example, on an architecture with 2M default huge page size:
+
+ For example, on an architecture with 2M default huge page size::
+
hugepages=256 hugepagesz=2M hugepages=512
+
will result in 256 2M huge pages being allocated and a warning message
indicating that the hugepages=512 parameter is ignored. If a hugepages
parameter is preceded by an invalid hugepagesz parameter, it will
be ignored.
-default_hugepagesz - Specify the default huge page size. This parameter can
+default_hugepagesz
+ pecify the default huge page size. This parameter can
only be specified once on the command line. default_hugepagesz can
optionally be followed by the hugepages parameter to preallocate a
specific number of huge pages of default size. The number of default
sized huge pages to preallocate can also be implicitly specified as
mentioned in the hugepages section above. Therefore, on an
- architecture with 2M default huge page size:
+ architecture with 2M default huge page size::
+
hugepages=256
default_hugepagesz=2M hugepages=256
hugepages=256 default_hugepagesz=2M
+
will all result in 256 2M huge pages being allocated. Valid default
huge page size is architecture dependent.
--
2.26.2
[PATCH v2 02/15] net: dev: add a missing kernel-doc annotation
The dev argument was not listed at kernel-doc markup: ./net/core/dev.c:7878: warning: Function parameter or member 'dev' not described in 'netdev_get_xmit_slave' Signed-off-by: Mauro Carvalho Chehab --- net/core/dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/dev.c b/net/core/dev.c index 3a46b86cbd67..cc57347b11c5 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -7908,6 +7908,7 @@ EXPORT_SYMBOL(netdev_bonding_info_change); /** * netdev_get_xmit_slave - Get the xmit slave of master device + * @dev: device * @skb: The packet * @all_slaves: assume all the slaves are active * -- 2.26.2
[PATCH v2 03/15] net: netdevice.h: add a description for napi_defer_hard_irqs
Changeset 6f8b12d661d0 ("net: napi: add hard irqs deferral feature")
added a new element at struct net_device.
Add a description for it, based on what's described at the changeset
which added such feature.
Fixes: 6f8b12d661d0 ("net: napi: add hard irqs deferral feature")
Signed-off-by: Mauro Carvalho Chehab
---
include/linux/netdevice.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 39e28e11863c..027df84f0f59 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1742,6 +1742,8 @@ enum netdev_priv_flags {
* @real_num_rx_queues:Number of RX queues currently active in device
* @xdp_prog: XDP sockets filter program pointer
* @gro_flush_timeout: timeout for GRO layer in NAPI
+ * @napi_defer_hard_irqs: If not zero, provides a counter that would
+ * allow to avoid NIC hard IRQ, on busy queues.
*
* @rx_handler:handler for received packets
* @rx_handler_data: XXX: need comments on this one
--
2.26.2
[PATCH v2 13/15] docs: ABI: fix a typo when pointing to w1-generic.rst
There's a typo there:
w1_generic.rst -> w1-generic.rst
Causing the document reference to point to the wrong place.
Fixes: e2c94d6f5720 ("w1_therm: adding alarm sysfs entry")
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/testing/sysfs-driver-w1_therm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm
b/Documentation/ABI/testing/sysfs-driver-w1_therm
index 076659d506f2..9b488c0afdfa 100644
--- a/Documentation/ABI/testing/sysfs-driver-w1_therm
+++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
@@ -8,7 +8,7 @@ Description:
to device min/max capabilities. Values are integer as they are
stored in a 8bit register in the device. Lowest value is
automatically put to TL. Once set, alarms could be search at
- master level, refer to Documentation/w1/w1_generic.rst for
+ master level, refer to Documentation/w1/w1-generic.rst for
detailed information
Users: any user space application which wants to communicate with
w1_term device
--
2.26.2
[PATCH v2 11/15] docs: powerpc: fix some issues at vas-api.rst
There are a few issues on this document, when built via the
building with ``make htmldocs``:
Documentation/powerpc/vas-api.rst:116: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:116: WARNING: Inline emphasis
start-string without end-string.
Documentation/powerpc/vas-api.rst:117: WARNING: Block quote ends without a
blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:117: WARNING: Inline emphasis
start-string without end-string.
Documentation/powerpc/vas-api.rst:120: WARNING: Definition list ends
without a blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:124: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:133: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:135: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:150: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:151: WARNING: Block quote ends without a
blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:161: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:176: WARNING: Definition list ends
without a blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:253: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:253: WARNING: Inline emphasis
start-string without end-string.
Documentation/powerpc/vas-api.rst:259: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:261: WARNING: Block quote ends without a
blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:266: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:267: WARNING: Block quote ends without a
blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:270: WARNING: Definition list ends
without a blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:271: WARNING: Definition list ends
without a blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:273: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:274: WARNING: Block quote ends without a
blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:277: WARNING: Definition list ends
without a blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:278: WARNING: Definition list ends
without a blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:280: WARNING: Unexpected indentation.
Documentation/powerpc/vas-api.rst:287: WARNING: Block quote ends without a
blank line; unexpected unindent.
Documentation/powerpc/vas-api.rst:289: WARNING: Block quote ends without a
blank line; unexpected unindent.
Fixes: c12e38b1d52e ("Documentation/powerpc: VAS API")
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/powerpc/vas-api.rst | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/Documentation/powerpc/vas-api.rst
b/Documentation/powerpc/vas-api.rst
index 1217c2f1595e..b7fdbe560010 100644
--- a/Documentation/powerpc/vas-api.rst
+++ b/Documentation/powerpc/vas-api.rst
@@ -87,6 +87,7 @@ Applications may chose a specific instance of the NX
co-processor using
the vas_id field in the VAS_TX_WIN_OPEN ioctl as detailed below.
A userspace library libnxz is available here but still in development:
+
https://github.com/abalib/power-gzip
Applications that use inflate / deflate calls can link with libnxz
@@ -110,6 +111,7 @@ Applications should use the VAS_TX_WIN_OPEN ioctl as
follows to establish
a connection with NX co-processor engine:
::
+
struct vas_tx_win_open_attr {
__u32 version;
__s16 vas_id; /* specific instance of vas or -1
@@ -119,8 +121,10 @@ a connection with NX co-processor engine:
__u64 reserved2[6];
};
- version: The version field must be currently set to 1.
- vas_id: If '-1' is passed, kernel will make a best-effort attempt
+ version:
+ The version field must be currently set to 1.
+ vas_id:
+ If '-1' is passed, kernel will make a best-effort attempt
to assign an optimal instance of NX for the process. To
select the specific VAS instance, refer
"Discovery of available VAS engines" section below.
@@ -129,7 +133,8 @@ a connection with NX co-processor engine:
and must be set to 0.
The attributes attr for the VAS_TX_WIN_OPEN ioctl are defined as
- follows:
+ follows::
+
#define VAS_MAGIC 'v'
#define VAS_TX_WIN_OPEN _IOW(VAS_MAGIC, 1,
struct vas_tx_win_open_attr)
@@ -141,6 +146,8 @@ a connection with NX co-processor engine:
returns -1 and sets the errno variable to indicate the error.
Error conditions:
+
+ ==
[PATCH v2 07/15] fs: fs.h: fix a kernel-doc parameter description
Changeset 3b0311e7ca71 ("vfs: track per-sb writeback errors and report them to
syncfs")
added a variant of filemap_sample_wb_err(), but it forgot to
rename the arguments at the kernel-doc markup. Fix it.
Fix those warnings:
./include/linux/fs.h:2845: warning: Function parameter or member 'file'
not described in 'file_sample_sb_err'
./include/linux/fs.h:2845: warning: Excess function parameter 'mapping'
description in 'file_sample_sb_err'
Fixes: 3b0311e7ca71 ("vfs: track per-sb writeback errors and report them to
syncfs")
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jan Kara
---
include/linux/fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 633c50cd24aa..523705fd8146 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2852,7 +2852,7 @@ static inline errseq_t filemap_sample_wb_err(struct
address_space *mapping)
/**
* file_sample_sb_err - sample the current errseq_t to test for later errors
- * @mapping: mapping to be sampled
+ * @file: file pointer to be sampled
*
* Grab the most current superblock-level errseq_t value for the given
* struct file.
--
2.26.2
[PATCH v2 05/15] net: pylink.h: add kernel-doc descriptions for new fields at phylink_config
Some fields were moved from struct phylink into phylink_config.
Update the kernel-doc markups for the config struct accordingly
Fixes: 5c05c1dbb177 ("net: phylink, dsa: eliminate phylink_fixed_state_cb()")
Signed-off-by: Mauro Carvalho Chehab
---
include/linux/phylink.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index cc5b452a184e..02ff1419d4be 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -62,6 +62,10 @@ enum phylink_op_type {
* @dev: a pointer to a struct device associated with the MAC
* @type: operation type of PHYLINK instance
* @pcs_poll: MAC PCS cannot provide link change interrupt
+ * @poll_fixed_state: if true, starts link_poll,
+ * if MAC link is at %MLO_AN_FIXED mode.
+ * @get_fixed_state: callback to execute to determine the fixed link state,
+ * if MAC link is at %MLO_AN_FIXED mode.
*/
struct phylink_config {
struct device *dev;
--
2.26.2
[PATCH v2 12/15] docs: driver-model: remove a duplicated markup at driver.rst
The "::" markup is there twice, causing a warning: Documentation/driver-api/driver-model/driver.rst:233: WARNING: Inline emphasis start-string without end-string. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/driver-model/driver.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/Documentation/driver-api/driver-model/driver.rst b/Documentation/driver-api/driver-model/driver.rst index 7d5040f6a3d8..06f818b1d622 100644 --- a/Documentation/driver-api/driver-model/driver.rst +++ b/Documentation/driver-api/driver-model/driver.rst @@ -228,8 +228,6 @@ over management of devices from the bootloader, the usage of sync_state() is not restricted to that. Use it whenever it makes sense to take an action after all the consumers of a device have probed:: -:: - int (*remove) (struct device *dev); remove is called to unbind a driver from a device. This may be -- 2.26.2
[PATCH v2 08/15] kcsan: fix a kernel-doc warning
One of the kernel-doc markups there have two "note" sections:
./include/linux/kcsan-checks.h:346: warning: duplicate section name
'Note'
While this is not the case here, duplicated sections can cause
build issues on Sphinx. So, let's change the notes section
to use, instead, a list for those 2 notes at the same function.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Marco Elver
---
include/linux/kcsan-checks.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/kcsan-checks.h b/include/linux/kcsan-checks.h
index 7b0b9c44f5f3..c5f6c1dcf7e3 100644
--- a/include/linux/kcsan-checks.h
+++ b/include/linux/kcsan-checks.h
@@ -337,11 +337,13 @@ static inline void __kcsan_disable_current(void) { }
* release_for_reuse(obj);
* }
*
- * Note: ASSERT_EXCLUSIVE_ACCESS_SCOPED(), if applicable, performs more
thorough
- * checking if a clear scope where no concurrent accesses are expected exists.
+ * Note:
*
- * Note: For cases where the object is freed, `KASAN `_ is a better
- * fit to detect use-after-free bugs.
+ * 1. ASSERT_EXCLUSIVE_ACCESS_SCOPED(), if applicable, performs more thorough
+ *checking if a clear scope where no concurrent accesses are expected
exists.
+ *
+ * 2. For cases where the object is freed, `KASAN `_ is a better
+ *fit to detect use-after-free bugs.
*
* @var: variable to assert on
*/
--
2.26.2
[PATCH v2 04/15] scripts/kernel-doc: parse __ETHTOOL_DECLARE_LINK_MODE_MASK
The __ETHTOOL_DECLARE_LINK_MODE_MASK macro is a variant of
DECLARE_BITMAP(), used by phylink.h. As we have already a
parser for DECLARE_BITMAP(), let's add one for this macro,
in order to avoid such warnings:
./include/linux/phylink.h:54: warning: Function parameter or member
'__ETHTOOL_DECLARE_LINK_MODE_MASK(advertising' not described in
'phylink_link_state'
./include/linux/phylink.h:54: warning: Function parameter or member
'__ETHTOOL_DECLARE_LINK_MODE_MASK(lp_advertising' not described in
'phylink_link_state'
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kernel-doc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index b4c963f8364e..43b8312363a5 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1083,7 +1083,9 @@ sub dump_struct($$) {
$members =~ s/\s*__packed\s*/ /gos;
$members =~ s/\s*CRYPTO_MINALIGN_ATTR/ /gos;
$members =~ s/\s*cacheline_aligned_in_smp/ /gos;
+
# replace DECLARE_BITMAP
+ $members =~
s/__ETHTOOL_DECLARE_LINK_MODE_MASK\s*\(([^\)]+)\)/DECLARE_BITMAP($1,
__ETHTOOL_LINK_MODE_MASK_NBITS)/gos;
$members =~ s/DECLARE_BITMAP\s*\(([^,)]+),\s*([^,)]+)\)/unsigned long
$1\[BITS_TO_LONGS($2)\]/gos;
# replace DECLARE_HASHTABLE
$members =~ s/DECLARE_HASHTABLE\s*\(([^,)]+),\s*([^,)]+)\)/unsigned
long $1\[1 << (($2) - 1)\]/gos;
--
2.26.2
Re: [PATCH v4] page_alloc: consider highatomic reserve in watermark fast
On Mon 22-06-20 17:25:01, Mel Gorman wrote:
> On Mon, Jun 22, 2020 at 04:23:04PM +0200, Michal Hocko wrote:
> > On Mon 22-06-20 11:04:39, Mel Gorman wrote:
> > > On Mon, Jun 22, 2020 at 06:40:20PM +0900, ? wrote:
> > > > >But more importantly, I have hard time to follow why we need both
> > > > >zone_watermark_fast and zone_watermark_ok now. They should be
> > > > >essentially the same for anything but order == 0. For order 0 the
> > > > >only difference between the two is that zone_watermark_ok checks for
> > > > >ALLOC_HIGH resp ALLOC_HARDER, ALLOC_OOM. So what is exactly fast about
> > > > >the former and why do we need it these days?
> > > > >
> > > >
> > > > I think the author, Mel, may ansewr. But I think the wmark_fast may
> > > > fast by 1) not checking more condition about wmark and 2) using inline
> > > > rather than function. According to description on commit 48ee5f3696f6,
> > > > it seems to bring about 4% improvement.
> > > >
> > >
> > > The original intent was that watermark checks were expensive as some of
> > > the
> > > calculations are only necessary when a zone is relatively low on memory
> > > and the check does not always have to be 100% accurate. This is probably
> > > still true given that __zone_watermark_ok() makes a number of calculations
> > > depending on alloc flags even if a zone is almost completely free.
> >
> > OK, so we are talking about
> > if (alloc_flags & ALLOC_HIGH)
> > min -= min / 2;
> >
> > if (unlikely((alloc_flags & (ALLOC_HARDER|ALLOC_OOM))) {
> > /*
> > * OOM victims can try even harder than normal ALLOC_HARDER
> > * users on the grounds that it's definitely going to be in
> > * the exit path shortly and free memory. Any allocation it
> > * makes during the free path will be small and short-lived.
> > */
> > if (alloc_flags & ALLOC_OOM)
> > min -= min / 2;
> > else
> > min -= min / 4;
> > }
> >
> > Is this something even measurable and something that would justify a
> > complex code? If we really want to keep it even after these changes
> > which are making the two closer in the cost then can we have it
> > documented at least?
>
> It was originally documented as being roughly 4% for a page allocator
> micro-benchmark but that was 4 years ago and I do not even remember what
> type of machine that was on. Chances are the relative cost is different
> now but I haven't measured it as the microbenchmark in question doesn't
> even compile with recent kernels.
Thanks for the clarification.
> For many allocations, the bulk of the
> allocation cost is zeroing the page so I have no particular objection
> to zone_watermark_fast being removed if it makes the code easier to
> read. While I have not looked recently, the cost of allocation in general
> and the increasing scope of the zone->lock with larger NUMA nodes for
> high-order allocations like THP are more of a concern than two branches
> and potentially two minor calculations.
OK, then I would rather go with the code simplification for the future
maintainability. If somebody can test this and provide good numbers then
we can reintroduce a fast check.
Thanks!
--
Michal Hocko
SUSE Labs
RE: [PATCH 1/3] mfd: ds1374: Introduce Dallas/Maxim DS1374 MFD core driver
Hi, > On 22/06/2020 07:26:56-0700, Guenter Roeck wrote: > > On Mon, Jun 22, 2020 at 12:14:13PM +0100, Lee Jones wrote: > > > On Mon, 22 Jun 2020, Johnson CH Chen (陳昭勳) wrote: > > > > > > > Dallas/Maxim DS1374 is a counter designed to continuously count > > > > time in seconds. It provides an I2C interface to the host to > > > > access RTC clock or Alarm/Watchdog timer. > > > > > > > > Add MFD Core driver, supporting the I2C communication to RTC and > > > > Watchdog devices. > > > > > > > > Signed-off-by: Johnson Chen > > > > --- > > > > drivers/mfd/Kconfig | 11 + > > > > drivers/mfd/Makefile | 2 + > > > > drivers/mfd/ds1374.c | 101 > > > > +++ > > > > 3 files changed, 114 insertions(+) create mode 100644 > > > > drivers/mfd/ds1374.c > > > > > > Not sure I see the point of this driver. > > > > > > > Not entirely sure either. Seems to me the idea is to use the watchdog > > subsystem for watchdog functionality, but that is just a guess and not > > really necessary (the conversion could be done in the rtc driver). > > I don't think the code as written works - the rtc code uses a mutex > > which the watchdog driver obviously isn't aware of. The mutex would > > have to be moved into the mfd code, with respective access functions. > > > > Overall this adds a lot of complexity, and it seems the > > interdependencies between rtc and watchdog functionality are not well > > understood. Plus, other watchdog drivers have recently been added to > > other rtc clock chips, so this adds some inconsistencies in the rtc > > subsystem. Are we going to see this change for all those combined > rtc/watchdog drivers ? > > If so, it might make sense to communicate that now to ensure consistency. > > > > I read the datasheet again and I agree the watchdog part can live in the rtc > driver. As only the RTC alarm and the watchdog are mutually exclusive. I don't > think an MFD driver is necessary. Converting the current driver to the > watchdog subsystem seems to be the correct way forward. > Thanks for your good thinking. If we want to add watchdog function such as "nowayout" to the driver, it's good to try to upstream this in rtc-ds1374.c in rtc subsystem? It seems like more complexity if we want to separate rtc and watchdog for one chip supports. For one chip which supports rtc/alarm and watchdog, can we upstream rtc/alarm and watchdog functions to these driver no matter where it's in rtc or watchdog subsystem? > -- > Alexandre Belloni, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Best regards, Johnson
Re: [PATCH] soc: imx: scu: use devm_kasprintf
On Wed, Jun 03, 2020 at 05:29:32PM +0800, peng@nxp.com wrote: > From: Peng Fan > > Use devm_kasprintf to simplify code > > Signed-off-by: Peng Fan Applied, thanks.
Re: [PATCH RFC v8 02/11] vhost: use batched get_vq_desc version
On 2020/6/23 下午3:00, Eugenio Perez Martin wrote:
On Tue, Jun 23, 2020 at 4:51 AM Jason Wang wrote:
On 2020/6/23 上午12:00, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2020 at 11:19:26AM +0800, Jason Wang wrote:
On 2020/6/11 下午7:34, Michael S. Tsirkin wrote:
static void vhost_vq_free_iovecs(struct vhost_virtqueue *vq)
{
kfree(vq->descs);
@@ -394,6 +400,9 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
for (i = 0; i < dev->nvqs; ++i) {
vq = dev->vqs[i];
vq->max_descs = dev->iov_limit;
+ if (vhost_vq_num_batch_descs(vq) < 0) {
+ return -EINVAL;
+ }
This check breaks vdpa which set iov_limit to zero. Consider iov_limit is
meaningless to vDPA, I wonder we can skip the test when device doesn't use
worker.
Thanks
It doesn't need iovecs at all, right?
-- MST
Yes, so we may choose to bypass the iovecs as well.
Thanks
I think that the kmalloc_array returns ZERO_SIZE_PTR for all of them
in that case, so I didn't bother to skip the kmalloc_array parts.
Would you prefer to skip them all and let them NULL? Or have I
misunderstood what you mean?
I'm ok with either approach, but my understanding is that Michael wants
to skip them all.
Thanks
Thanks!
Re: [PATCH v4 3/4] drivers: soc: Add MSM8936 SMD RPM compatible
On Sat 13 Jun 00:27 PDT 2020, Vincent Knecht wrote:
> From: Konrad Dybcio
>
> Signed-off-by: Konrad Dybcio
> Signed-off-by: Vincent Knecht
Patch 3 and 4 applied.
Thanks,
Bjorn
> ---
> drivers/soc/qcom/smd-rpm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
> index 005dd30c58fa..8f290c67cb47 100644
> --- a/drivers/soc/qcom/smd-rpm.c
> +++ b/drivers/soc/qcom/smd-rpm.c
> @@ -231,6 +231,7 @@ static void qcom_smd_rpm_remove(struct rpmsg_device
> *rpdev)
> static const struct of_device_id qcom_smd_rpm_of_match[] = {
> { .compatible = "qcom,rpm-apq8084" },
> { .compatible = "qcom,rpm-msm8916" },
> + { .compatible = "qcom,rpm-msm8936" },
> { .compatible = "qcom,rpm-msm8974" },
> { .compatible = "qcom,rpm-msm8976" },
> { .compatible = "qcom,rpm-msm8996" },
> --
> 2.25.4
>
>
Re: [RFC PATCH v5 2/3] docs: scheduler: Add scheduler overview documentation
On Fri, May 29, 2020 at 2:00 PM Peter Zijlstra wrote: > > On Thu, May 14, 2020 at 12:26:36PM +0300, john mathew wrote: > > > += > > +CFS Overview > > += > > + > > +Linux 2.6.23 introduced a modular scheduler core and a Completely Fair > > +Scheduler (CFS) implemented as a scheduling module. A brief overview of the > > +CFS design is provided in :doc:`sched-design-CFS` > > + > > +In addition there have been many improvements to the CFS, a few of which > > are > > + > > +**Thermal Pressure**: > > I find these attached headers really hard to read. And what's with the > ** stuff ? > > Other files in this same patch use a different style: > > Header > -- > test goes here, > > Which I find a lot more readable. Use it here too? > > > +Scale CPU capacity mechanism for CFS so it knows how much CPU capacity is > > left > > +for its use after higher priority sched classes (RT, DL), IRQs and > > +'Thermal Pressure' have reduced the 'original' CPU capacity. > > +Thermal pressure on a CPU means the maximum possible capacity is > > +unavailable due to thermal events. > > + > > +** Optimizations to NUMA balancing**: > ^ iconsistent spacing (although I think it's more readable without > the ** crap attached). > > > +When gathering NUMA statistics, information about whether a core is Idle > > +is also cached. In case of an imbalance, instead of doing a second scan of > > +the node runqueues, the idle core is used as the migration target. When > > +doing so multiple tasks can attempt to select an idle CPU but fail, because > > +a NUMA balance is active on that CPU. In this case an alternative idle CPU > > +scanned. Another optimization is to terminate the search for swap candidate > > +when a reasonable one is found instead of searching all the CPUs on the > > +target domain. > > ^^ that makes no sense to me. That's very much not what numa balancing > is about. > > > + > > +**Asymmetric CPU capacity wakeup scan**: > > +Previous assumption that CPU capacities within an SD_SHARE_PKG_RESOURCES > > +domain (sd_llc) are homogeneous didn't hold for newer generations of > > big.LITTLE > > +systems (DynamIQ) which can accommodate CPUs of different compute capacity > > +within a single LLC domain. A new idle sibling helper function was added > > +which took CPU capacity into account. The policy is to pick the first idle > > +CPU which is big enough for the task (task_util * margin < cpu_capacity). > > +If no idle CPU is big enough, the idle CPU with the highest capacity is > > +picked. > > + > > +**Optimized idle core selection**: > > +Skipped looping through all the threads of a core to evaluate if the > > +core is idle or not. If a thread of a core is not idle, evaluation of > > +other threads of the core can be skipped. > > + > > +**Load balance aggressively for SCHED_IDLE CPUs**: > > +Newly-woken task is preferred to be enqueued on a SCHED_IDLE CPU instead > > +of other busy or idle CPUs. Also load balancer is made to migrate tasks > > more > > +aggressively to a SCHED_IDLE CPU. Fair scheduler now does the next > > +load balance soon after the last non-SCHED_IDLE task is dequeued from a > > +runqueue, i.e. making the CPU SCHED_IDLE. Also the the busy_factor > > +used with the balance interval to prevent frequent load balancing > > +is ignored for such CPU's. > > + > > +**Load balancing algorithm Reworked**: > > +Some heuristics in the load balancing algorithm became meaningless because > > +of the rework of the scheduler's metrics like the introduction of PELT. > > +Those heuristics were removed. The new load balancing algorithm also fixes > > +several pending wrong tasks placement > > + > > + * the 1 task per CPU case with asymmetric system > > + * the case of CFS task preempted by other class > > + * the case of tasks not evenly spread on groups with spare capacity > > + > > +Also the load balance decisions have been consolidated in the 3 separate > > +functions. > > +* update_sd_pick_busiest() select the busiest sched_group. > > +* find_busiest_group() checks if there is an imbalance between local and > > +busiest group. > > +* calculate_imbalance() decides what have to be moved. > > This all reads like a changelog; why do we care about the old stuff? > That is, rephrase it to describe the current situation. > > > + > > +**Energy-aware wake-ups speeded up**: > > +Algorithmic complexity of the EAS was reduced from O(n^2) to O(n). > > +Previous algorithm resulted in prohibitively high wake-up latencies on > > +systems with complex energy models, such as systems with per-CPU DVFS. > > +The EAS wake-up path was re-factored to compute the energy 'delta' on a > > +per-performance domain basis, rather than the whole system. > > Idem; describe what EAS does and how. Nobody cares about what it once > might have been. > > > +**Selection of an energy-efficient CPU on task wake-up**: > > +An Energy efficient CPU is found by estimating the impact on system-level > > +active energy resulting from
[tip: sched/urgent] sched: s/WF_ON_RQ/WQ_ON_CPU/
The following commit has been merged into the sched/urgent branch of tip: Commit-ID: 38d8705bb63d19747eb6259c22c54d18cc47e4f7 Gitweb: https://git.kernel.org/tip/38d8705bb63d19747eb6259c22c54d18cc47e4f7 Author:Peter Zijlstra AuthorDate:Mon, 22 Jun 2020 12:01:24 +02:00 Committer: Peter Zijlstra CommitterDate: Mon, 22 Jun 2020 20:51:06 +02:00 sched: s/WF_ON_RQ/WQ_ON_CPU/ Avoids confusion... Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mel Gorman Link: https://lkml.kernel.org/r/20200622100825.785115...@infradead.org --- kernel/sched/core.c | 4 ++-- kernel/sched/sched.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 3328c29..019db7a 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2376,7 +2376,7 @@ static inline bool ttwu_queue_cond(int cpu, int wake_flags) * the soon-to-be-idle CPU as the current CPU is likely busy. * nr_running is checked to avoid unnecessary task stacking. */ - if ((wake_flags & WF_ON_RQ) && cpu_rq(cpu)->nr_running <= 1) + if ((wake_flags & WF_ON_CPU) && cpu_rq(cpu)->nr_running <= 1) return true; return false; @@ -2636,7 +2636,7 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags) * scheduling. */ if (smp_load_acquire(&p->on_cpu) && - ttwu_queue_wakelist(p, task_cpu(p), wake_flags | WF_ON_RQ)) + ttwu_queue_wakelist(p, task_cpu(p), wake_flags | WF_ON_CPU)) goto unlock; /* diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 1d4e94c..877fb08 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -1682,7 +1682,7 @@ static inline int task_on_rq_migrating(struct task_struct *p) #define WF_SYNC0x01/* Waker goes to sleep after wakeup */ #define WF_FORK0x02/* Child wakeup after fork */ #define WF_MIGRATED0x04/* Internal use, task got migrated */ -#define WF_ON_RQ 0x08/* Wakee is on_rq */ +#define WF_ON_CPU 0x08/* Wakee is on_cpu */ /* * To aid in avoiding the subversion of "niceness" due to uneven distribution
[tip: sched/urgent] smp, irq_work: Continue smp_call_function*() and irq_work*() integration
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: ad6567b439016f9ffd01bbb25276ee363d9a106a
Gitweb:
https://git.kernel.org/tip/ad6567b439016f9ffd01bbb25276ee363d9a106a
Author:Peter Zijlstra
AuthorDate:Mon, 22 Jun 2020 12:01:25 +02:00
Committer: Peter Zijlstra
CommitterDate: Mon, 22 Jun 2020 20:51:06 +02:00
smp, irq_work: Continue smp_call_function*() and irq_work*() integration
Instead of relying on BUG_ON() to ensure the various data structures
line up, use a bunch of horrible unions.
Much of the union magic is to ensure irq_work and smp_call_function do
not (yet) see the members of their respective data structures change
name.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Frederic Weisbecker
Link: https://lkml.kernel.org/r/20200622100825.844455...@infradead.org
---
include/linux/irq_work.h | 26 ---
include/linux/sched.h | 5 +---
include/linux/smp.h | 23 -
include/linux/smp_types.h | 66 ++-
kernel/sched/core.c | 6 +--
kernel/smp.c | 18 +--
6 files changed, 86 insertions(+), 58 deletions(-)
create mode 100644 include/linux/smp_types.h
diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index 2735da5..3082378 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -2,7 +2,7 @@
#ifndef _LINUX_IRQ_WORK_H
#define _LINUX_IRQ_WORK_H
-#include
+#include
/*
* An entry can be in one of four states:
@@ -13,24 +13,14 @@
* busy NULL, 2 -> {free, claimed} : callback in progress, can be claimed
*/
-/* flags share CSD_FLAG_ space */
-
-#define IRQ_WORK_PENDING BIT(0)
-#define IRQ_WORK_BUSY BIT(1)
-
-/* Doesn't want IPI, wait for tick: */
-#define IRQ_WORK_LAZY BIT(2)
-/* Run hard IRQ context, even on RT */
-#define IRQ_WORK_HARD_IRQ BIT(3)
-
-#define IRQ_WORK_CLAIMED (IRQ_WORK_PENDING | IRQ_WORK_BUSY)
-
-/*
- * structure shares layout with single_call_data_t.
- */
struct irq_work {
- struct llist_node llnode;
- atomic_t flags;
+ union {
+ struct __call_single_node node;
+ struct {
+ struct llist_node llnode;
+ atomic_t flags;
+ };
+ };
void (*func)(struct irq_work *);
};
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 59caeb9..0376588 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -653,11 +653,8 @@ struct task_struct {
unsigned intptrace;
#ifdef CONFIG_SMP
- struct {
- struct llist_node wake_entry;
- unsigned intwake_entry_type;
- };
int on_cpu;
+ struct __call_single_node wake_entry;
#ifdef CONFIG_THREAD_INFO_IN_TASK
/* Current CPU: */
unsigned intcpu;
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 7ee202a..80d557e 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -12,29 +12,22 @@
#include
#include
#include
-#include
+#include
typedef void (*smp_call_func_t)(void *info);
typedef bool (*smp_cond_func_t)(int cpu, void *info);
-enum {
- CSD_FLAG_LOCK = 0x01,
-
- /* IRQ_WORK_flags */
-
- CSD_TYPE_ASYNC = 0x00,
- CSD_TYPE_SYNC = 0x10,
- CSD_TYPE_IRQ_WORK = 0x20,
- CSD_TYPE_TTWU = 0x30,
- CSD_FLAG_TYPE_MASK = 0xF0,
-};
-
/*
* structure shares (partial) layout with struct irq_work
*/
struct __call_single_data {
- struct llist_node llist;
- unsigned int flags;
+ union {
+ struct __call_single_node node;
+ struct {
+ struct llist_node llist;
+ unsigned int flags;
+ };
+ };
smp_call_func_t func;
void *info;
};
diff --git a/include/linux/smp_types.h b/include/linux/smp_types.h
new file mode 100644
index 000..364b3ae
--- /dev/null
+++ b/include/linux/smp_types.h
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_SMP_TYPES_H
+#define __LINUX_SMP_TYPES_H
+
+#include
+
+enum {
+ CSD_FLAG_LOCK = 0x01,
+
+ IRQ_WORK_PENDING= 0x01,
+ IRQ_WORK_BUSY = 0x02,
+ IRQ_WORK_LAZY = 0x04, /* No IPI, wait for tick */
+ IRQ_WORK_HARD_IRQ = 0x08, /* IRQ context on PREEMPT_RT */
+
+ IRQ_WORK_CLAIMED= (IRQ_WORK_PENDING | IRQ_WORK_BUSY),
+
+ CSD_TYPE_ASYNC = 0x00,
+ CSD_TYPE_SYNC = 0x10,
+ CSD_TYPE_IRQ_WORK = 0x20,
+ CSD_TYPE_TTWU = 0x30,
+
+ CSD_FLAG_TYPE_MASK = 0xF0,
+};
+
+/*
+ * struct __call_single_node is the primary type on
+ * smp.c:call_single_queue.
+ *
+ * flush_smp_call_function_queue() only r
[tip: sched/urgent] sched: Fix ttwu() race
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: dcb623b51fb9d424471da9acbd2cfa618ecf9a09
Gitweb:
https://git.kernel.org/tip/dcb623b51fb9d424471da9acbd2cfa618ecf9a09
Author:Peter Zijlstra
AuthorDate:Mon, 22 Jun 2020 12:01:23 +02:00
Committer: Peter Zijlstra
CommitterDate: Mon, 22 Jun 2020 20:51:06 +02:00
sched: Fix ttwu() race
Paul reported rcutorture occasionally hitting a NULL deref:
sched_ttwu_pending()
ttwu_do_wakeup()
check_preempt_curr() := check_preempt_wakeup()
find_matching_se()
is_same_group()
if (se->cfs_rq == pse->cfs_rq) <-- *BOOM*
Debugging showed that this only appears to happen when we take the new
code-path from commit:
2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is
descheduling")
and only when @cpu == smp_processor_id(). Something which should not
be possible, because p->on_cpu can only be true for remote tasks.
Similarly, without the new code-path from commit:
c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu")
this would've unconditionally hit:
smp_cond_load_acquire(&p->on_cpu, !VAL);
and if: 'cpu == smp_processor_id() && p->on_cpu' is possible, this
would result in an instant live-lock (with IRQs disabled), something
that hasn't been reported.
The NULL deref can be explained however if the task_cpu(p) load at the
beginning of try_to_wake_up() returns an old value, and this old value
happens to be smp_processor_id(). Further assume that the p->on_cpu
load accurately returns 1, it really is still running, just not here.
Then, when we enqueue the task locally, we can crash in exactly the
observed manner because p->se.cfs_rq != rq->cfs_rq, because p's cfs_rq
is from the wrong CPU, therefore we'll iterate into the non-existant
parents and NULL deref.
The closest semi-plausible scenario I've managed to contrive is
somewhat elaborate (then again, actual reproduction takes many CPU
hours of rcutorture, so it can't be anything obvious):
X->cpu = 1
rq(1)->curr = X
CPU0CPU1CPU2
// switch away from X
LOCK rq(1)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 9
switch_to(Z)
X->on_cpu = 0
UNLOCK rq(1)->lock
//
migrate X to cpu 0
LOCK
rq(1)->lock
dequeue_task(X)
set_task_cpu(X, 0)
X->cpu = 0
UNLOCK
rq(1)->lock
LOCK
rq(0)->lock
enqueue_task(X)
X->on_rq = 1
UNLOCK
rq(0)->lock
// switch to X
LOCK rq(0)->lock
smp_mb__after_spinlock
switch_to(X)
X->on_cpu = 1
UNLOCK rq(0)->lock
// X goes sleep
X->state = TASK_UNINTERRUPTIBLE
smp_mb(); // wake X
ttwu()
LOCK X->pi_lock
smp_mb__after_spinlock
if (p->state)
cpu = X->cpu; // =? 1
smp_rmb()
// X calls schedule()
LOCK rq(0)->lock
smp_mb__after_spinlock
dequeue_task(X)
X->on_rq = 0
if (p->on_rq)
smp_rmb();
if (p->on_cpu &&
ttwu_queue_wakelist(..)) [*]
smp_cond_load_acquire(&p->on_cpu,
!VAL)
cpu = select_task_rq(X, X->wake_cpu,
...)
if (X->cpu != cpu)
switch_to(Y)
X->on_cpu = 0
UNLOCK rq(0)->lock
However I'm having trouble convincing myself that's actually possible
on x86_64 -- after all, every LOCK implies an smp_mb there, so if ttwu
[tip: sched/urgent] sched: __set_cpus_allowed_ptr(): Check cpus_mask, not cpus_ptr
The following commit has been merged into the sched/urgent branch of tip: Commit-ID: a51dde512a93959d1df3a915fa3e3df68b1fc94d Gitweb: https://git.kernel.org/tip/a51dde512a93959d1df3a915fa3e3df68b1fc94d Author:Scott Wood AuthorDate:Wed, 17 Jun 2020 14:17:42 +02:00 Committer: Peter Zijlstra CommitterDate: Mon, 22 Jun 2020 20:51:05 +02:00 sched: __set_cpus_allowed_ptr(): Check cpus_mask, not cpus_ptr This function is concerned with the long-term cpu mask, not the transitory mask the task might have while migrate disabled. Before this patch, if a task was migrate disabled at the time __set_cpus_allowed_ptr() was called, and the new mask happened to be equal to the cpu that the task was running on, then the mask update would be lost. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Scott Wood Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200617121742.cpxppyi7twxmp...@linutronix.de --- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 8298b2c..9f8aa34 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1637,7 +1637,7 @@ static int __set_cpus_allowed_ptr(struct task_struct *p, goto out; } - if (cpumask_equal(p->cpus_ptr, new_mask)) + if (cpumask_equal(&p->cpus_mask, new_mask)) goto out; /*
[tip: sched/urgent] sched/deadline: Initialize dl_boosted
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 5bf857422d6b36b1edff43348054edd3379d069d
Gitweb:
https://git.kernel.org/tip/5bf857422d6b36b1edff43348054edd3379d069d
Author:Juri Lelli
AuthorDate:Wed, 17 Jun 2020 09:29:19 +02:00
Committer: Peter Zijlstra
CommitterDate: Mon, 22 Jun 2020 20:51:05 +02:00
sched/deadline: Initialize dl_boosted
syzbot reported the following warning:
WARNING: CPU: 0 PID: 6973 at kernel/sched/deadline.c:593 setup_new_dl_entity
/kernel/sched/deadline.c:594 [inline]
WARNING: CPU: 0 PID: 6973 at kernel/sched/deadline.c:593 enqueue_dl_entity
/kernel/sched/deadline.c:1370 [inline]
WARNING: CPU: 0 PID: 6973 at kernel/sched/deadline.c:593
enqueue_task_dl+0x1c17/0x2ba0 /kernel/sched/deadline.c:1441
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 6973 Comm: syz-executor366 Not tainted 4.14.133 #28
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack /lib/dump_stack.c:17 [inline]
dump_stack+0x138/0x19c /lib/dump_stack.c:53
panic+0x1f2/0x426 /kernel/panic.c:182
__warn.cold+0x2f/0x36 /kernel/panic.c:546
report_bug+0x216/0x254 /lib/bug.c:186
fixup_bug /arch/x86/kernel/traps.c:177 [inline]
fixup_bug /arch/x86/kernel/traps.c:172 [inline]
do_error_trap+0x1bb/0x310 /arch/x86/kernel/traps.c:295
do_invalid_op+0x1b/0x20 /arch/x86/kernel/traps.c:314
invalid_op+0x1b/0x40 /arch/x86/entry/entry_64.S:960
RIP: 0010:setup_new_dl_entity /kernel/sched/deadline.c:593 [inline]
RIP: 0010:enqueue_dl_entity /kernel/sched/deadline.c:1370 [inline]
RIP: 0010:enqueue_task_dl+0x1c17/0x2ba0 /kernel/sched/deadline.c:1441
RSP: 0018:888098a3fcd8 EFLAGS: 00010002
RAX: RBX: 87ab2780 RCX: 11101041413a
RDX: 000ad48fb497 RSI: 8880aee2c518 RDI: 8880820a09d0
RBP: 888098a3fd48 R08: 8880820a09cc R09: 8880820a09c0
R10: 8880820a073c R11: 0001 R12: 8880820a0700
R13: 8880aee2c500 R14: 8880820a0978 R15: 8880aee2c500
enqueue_task /kernel/sched/core.c:762 [inline]
__sched_setscheduler+0xd17/0x2510 /kernel/sched/core.c:4227
sched_setattr /kernel/sched/core.c:4285 [inline]
SYSC_sched_setattr /kernel/sched/core.c:4456 [inline]
SyS_sched_setattr+0x1f8/0x300 /kernel/sched/core.c:4435
do_syscall_64+0x1e8/0x640 /arch/x86/entry/common.c:292
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x446749
RSP: 002b:7ff022092db8 EFLAGS: 0246 ORIG_RAX: 013a
RAX: ffda RBX: 006dbc38 RCX: 00446749
RDX: RSI: 2000 RDI:
RBP: 006dbc30 R08: 7ff022093700 R09:
R10: 7ff022093700 R11: 0246 R12: 006dbc3c
R13: 7ffdbf86bf7f R14: 7ff0220939c0 R15:
This happens because dl_boosted flag is currently not initialized by
__dl_clear_params() (unlike the other flags) and setup_new_dl_entity()
finds complains about it.
Initialize dl_boosted to 0.
Fixes: 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance logic")
Reported-by: syzbot+5ac8bac25f95e8b22...@syzkaller.appspotmail.com
Signed-off-by: Juri Lelli
Signed-off-by: Peter Zijlstra (Intel)
Tested-by: Daniel Wagner
Link: https://lkml.kernel.org/r/20200617072919.818409-1-juri.le...@redhat.com
---
kernel/sched/deadline.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 504d2f5..f63f337 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -2692,6 +2692,7 @@ void __dl_clear_params(struct task_struct *p)
dl_se->dl_bw= 0;
dl_se->dl_density = 0;
+ dl_se->dl_boosted = 0;
dl_se->dl_throttled = 0;
dl_se->dl_yielded = 0;
dl_se->dl_non_contending= 0;
[tip: sched/urgent] sched/core: Fix PI boosting between RT and DEADLINE
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 195819207674143c790809f97f96102c7fada077
Gitweb:
https://git.kernel.org/tip/195819207674143c790809f97f96102c7fada077
Author:Juri Lelli
AuthorDate:Mon, 19 Nov 2018 16:32:01 +01:00
Committer: Peter Zijlstra
CommitterDate: Mon, 22 Jun 2020 20:51:06 +02:00
sched/core: Fix PI boosting between RT and DEADLINE
syzbot reported the following warning:
WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628
enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
PM: Basic memory bitmaps freed
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 6351 Comm: syz-executor0 Not tainted 4.20.0-rc2+ #338
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x244/0x39d lib/dump_stack.c:113
panic+0x2ad/0x55c kernel/panic.c:188
__warn.cold.8+0x20/0x45 kernel/panic.c:540
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
RIP: 0010:enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
Code: ff 48 8b 8d c8 fe ff ff 48 c1 e6 2a 4c 8b 9d d0 fe ff ff 8b 95 d8 fe
ff ff 48 8b 85 e0 fe ff ff e9 16 e4 ff ff e8 16 d0 ea ff <0f> 0b e9 17 f1
ff ff 48 8b bd e8 fe ff ff 4c 89 95 c8 fe ff ff 48
RSP: 0018:8881ba39fa18 EFLAGS: 00010002
RAX: RBX: 8881b9d6c000 RCX: 8881b9d6c278
RDX: 8881b9d6c03c RSI: 0002 RDI: 8881daf2d710
RBP: 8881ba39fb78 R08: 0001 R09: 8881daf0
R10: 001a4d4f1987 R11: 8881daf2db3b R12: 111037473f4e
R13: 8881b9d6c2cc R14: 8881daf2ccc0 R15: 8881daf2ccc0
enqueue_task+0x184/0x390 kernel/sched/core.c:730
__sched_setscheduler+0xe99/0x2190 kernel/sched/core.c:4336
sched_setattr kernel/sched/core.c:4394 [inline]
__do_sys_sched_setattr kernel/sched/core.c:4570 [inline]
__se_sys_sched_setattr kernel/sched/core.c:4549 [inline]
__x64_sys_sched_setattr+0x1b2/0x2f0 kernel/sched/core.c:4549
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f05ce0a2c78 EFLAGS: 0246 ORIG_RAX: 013a
RAX: ffda RBX: 0003 RCX: 00457569
RDX: RSI: 2000 RDI:
RBP: 0072bfa0 R08: R09:
R10: R11: 0246 R12: 7f05ce0a36d4
R13: 004c369f R14: 004d5730 R15:
At deadline.c:628 we have:
623 static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
624 {
625struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
626struct rq *rq = rq_of_dl_rq(dl_rq);
627
628WARN_ON(dl_se->dl_boosted);
629WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline));
[...]
}
Which means that setup_new_dl_entity() has been called on a task
currently boosted. This shouldn't happen though, as setup_new_
dl_entity() is only called when the 'dynamic' deadline of the new entity
is in the past w.r.t. rq_clock and boosted tasks shouldn't verify this
condition.
Digging through PI code I noticed that what above might in fact happen
if an RT tasks blocks on an rt_mutex hold by a DEADLINE task. In the
first branch of boosting conditions we check only if a pi_task 'dynamic'
deadline is earlier than mutex holder's and in this case we set mutex
holder to be dl_boosted. However, since RT 'dynamic' deadlines are only
initialized if such tasks get boosted at some point (or if they become
DEADLINE of course), in general RT 'dynamic' deadlines are usually equal
to 0 and this verifies the aforementioned condition.
Fix it by checking that the potential donor task is actually (even if
temporary because in turn boosted) running at DEADLINE priority before
using its 'dynamic' deadline value.
Fixes: 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance logic")
Reported-by: syzbot+119ba87189432ead0...@syzkaller.appspotmail.com
Signed-off-by: Juri Lelli
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Daniel Bristot de Oliveira
Tested-by: Daniel Wagner
Link: https://lkml.kernel.org/r/20181119153201.GB2119@localhost.localdomain
---
kernel/sched/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9f8aa34..1f79d76 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4534,7 +4534,8 @@ void rt_mutex_setprio(struct task_struct *p, struct
ta
Re: [PATCH v2 14/15] docs: fix references for DMA*.txt files
On Tue, Jun 23, 2020 at 09:09:10AM +0200, Mauro Carvalho Chehab wrote: > As we moved those files to core-api, fix references to point > to their newer locations. Can we please just revert the RST conversion that I didn't ACK?
Re: [PULL REQUEST] i2c for 5.8
On Tue, Jun 23, 2020 at 5:05 AM John Stultz wrote: > On Sat, Jun 13, 2020 at 4:36 AM Wolfram Sang wrote: ... > > Andy Shevchenko (17): > ... > > i2c: designware: Move ACPI parts into common module > > Just as a heads up. I'm seeing a regression from this merge that I > bisected down to the patch above (f9288fcc5c615), with the HiKey > board. It seems the adv7511 (HDMI bridge) driver isn't probing, which > causes graphics to fail. > > I've just bisected it down and haven't managed to do much debugging, > but I wanted to raise a flag on this. Let me know if there is anything > you'd like me to try right off. Thank you for the report! The above change was purely clean up / refactoring to get PCI enumerated devices used to ACPI additional data. I bet your patch is correct, but I will look closer and see what is the real root cause of such behaviour. I'll comment on your patch separately. -- With Best Regards, Andy Shevchenko
Re: New mode DM-Verity error handling
On 23/06/2020 01:53, JeongHyeon Lee wrote: > > For what reason isn't panic better? I did not say panic is better, I said that while we have restart already in mainline dm-verity code, panic() is almost the same, so I see no problem in merging this patch. Stopping system this way could create more damage if it is not configured properly, but I think it is quite common to stop the system as fast as possible if data system integrity is violated... > If when i suggested new patch, i will send you a patch that increased > minor version. I think Mike can fold-in version increase, if the patch is accepted. But please include these version changes with every new feature. Actually I am tracking it here for dm-verity as part of veritysetup userspace documentation: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity Thanks, Milan > On 22/06/2020 16:58, Milan Broz wrote: >> On 18/06/2020 19:09, Mike Snitzer wrote: >>> On Thu, Jun 18 2020 at 12:50pm -0400, >>> Sami Tolvanen wrote: >>> On Thu, Jun 18, 2020 at 11:44:45AM -0400, Mike Snitzer wrote: > I do not accept that panicing the system because of verity failure is > reasonable. > > In fact, even rebooting (via DM_VERITY_MODE_RESTART) looks very wrong. > > The device should be put in a failed state and left for admin recovery. That's exactly how the restart mode works on some Android devices. The bootloader sees the verification error and puts the device in recovery mode. Using the restart mode on systems without firmware support won't make sense, obviously. >>> OK, so I need further justification from Samsung why they are asking for >>> this panic mode. >> I think when we have reboot already, panic is not much better :-) >> >> Just please note that dm-verity is used not only in Android world (with own >> tooling) >> but in normal Linux distributions, and I need to modify userspace >> (veritysetup) to support >> and recognize this flag. >> >> Please *always* increase minor dm-verity target version when adding a new >> feature >> - we can then provide some better hint if it is not supported. >> >> Thanks, >> Milan >> >>
Re: [PATCH v3 7/7] mailbox: qcom: Add sdm660 hmss compatible
On Mon 22 Jun 12:25 PDT 2020, Konrad Dybcio wrote:
> The Qualcomm SDM660 platform has a APCS HMSS GLOBAL block, add the
> compatible for this.
>
> Signed-off-by: Konrad Dybcio
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> .../devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml | 1 +
> drivers/mailbox/qcom-apcs-ipc-mailbox.c | 5 +
> 2 files changed, 6 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
> b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
> index 12eff942708d..b4501c6b5c6f 100644
> --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
> @@ -22,6 +22,7 @@ properties:
>- qcom,msm8998-apcs-hmss-global
>- qcom,qcs404-apcs-apps-global
>- qcom,sc7180-apss-shared
> + - qcom,sdm660-apcs-hmss-global
>- qcom,sdm845-apss-shared
>- qcom,sm8150-apss-shared
>
> diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> index cec34f0af6ce..ab0275869434 100644
> --- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> +++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c
> @@ -49,6 +49,10 @@ static const struct qcom_apcs_ipc_data msm8998_apcs_data =
> {
> .offset = 8, .clk_name = NULL
> };
>
> +static const struct qcom_apcs_ipc_data sdm660_apcs_data = {
> + .offset = 8, .clk_name = NULL
> +};
> +
> static const struct qcom_apcs_ipc_data apps_shared_apcs_data = {
> .offset = 12, .clk_name = NULL
> };
> @@ -150,6 +154,7 @@ static const struct of_device_id qcom_apcs_ipc_of_match[]
> = {
> { .compatible = "qcom,msm8998-apcs-hmss-global", .data =
> &msm8998_apcs_data },
> { .compatible = "qcom,qcs404-apcs-apps-global", .data =
> &msm8916_apcs_data },
> { .compatible = "qcom,sc7180-apss-shared", .data =
> &apps_shared_apcs_data },
> + { .compatible = "qcom,sdm660-apcs-hmss-global", .data =
> &sdm660_apcs_data },
> { .compatible = "qcom,sdm845-apss-shared", .data =
> &apps_shared_apcs_data },
> { .compatible = "qcom,sm8150-apss-shared", .data =
> &apps_shared_apcs_data },
> {}
> --
> 2.27.0
>
[PATCH v2] mm, kcsan: Instrument SLAB/SLUB free with "ASSERT_EXCLUSIVE_ACCESS"
Provide the necessary KCSAN checks to assist with debugging racy use-after-frees. While KASAN is more reliable at generally catching such use-after-frees (due to its use of a quarantine), it can be difficult to debug racy use-after-frees. If a reliable reproducer exists, KCSAN can assist in debugging such issues. Note: ASSERT_EXCLUSIVE_ACCESS is a convenience wrapper if the size is simply sizeof(var). Instead, here we just use __kcsan_check_access() explicitly to pass the correct size. Signed-off-by: Marco Elver --- v2: * SLAB_TYPESAFE_BY_RCU allows racy use after free within RCU grace period. If slab is SLAB_TYPESAFE_BY_RCU do not check access. --- mm/slab.c | 5 + mm/slub.c | 5 + 2 files changed, 10 insertions(+) diff --git a/mm/slab.c b/mm/slab.c index 9350062ffc1a..cba71d88e89c 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3426,6 +3426,11 @@ static __always_inline void __cache_free(struct kmem_cache *cachep, void *objp, if (kasan_slab_free(cachep, objp, _RET_IP_)) return; + /* Use KCSAN to help debug racy use-after-free. */ + if (!(cachep->flags & SLAB_TYPESAFE_BY_RCU)) + __kcsan_check_access(objp, cachep->object_size, +KCSAN_ACCESS_WRITE | KCSAN_ACCESS_ASSERT); + ___cache_free(cachep, objp, caller); } diff --git a/mm/slub.c b/mm/slub.c index b8f798b50d44..4a9d43fda669 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1470,6 +1470,11 @@ static __always_inline bool slab_free_hook(struct kmem_cache *s, void *x) if (!(s->flags & SLAB_DEBUG_OBJECTS)) debug_check_no_obj_freed(x, s->object_size); + /* Use KCSAN to help debug racy use-after-free. */ + if (!(s->flags & SLAB_TYPESAFE_BY_RCU)) + __kcsan_check_access(x, s->object_size, +KCSAN_ACCESS_WRITE | KCSAN_ACCESS_ASSERT); + /* KASAN might put x into memory quarantine, delaying its reuse */ return kasan_slab_free(s, x, _RET_IP_); } -- 2.27.0.111.gc72c7da667-goog
Re: [PATCH v3 1/7] pinctrl: qcom: spmi-gpio: Add pm660(l) compatibility
On Mon 22 Jun 12:25 PDT 2020, Konrad Dybcio wrote:
> Add support for pm660(l) SPMI GPIOs. The PMICs feature
> 13 and 12 GPIOs respectively, though with a lot of
> holes inbetween.
>
> Signed-off-by: Konrad Dybcio
Didn't I ack this change in v2? If so please remember to add such tags
when you resubmit the change...
Acked-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> index fe0be8a6ebb7..95ca66e24e7c 100644
> --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> @@ -1118,6 +1118,10 @@ static const struct of_device_id pmic_gpio_of_match[]
> = {
> { .compatible = "qcom,pma8084-gpio", .data = (void *) 22 },
> /* pms405 has 12 GPIOs with holes on 1, 9, and 10 */
> { .compatible = "qcom,pms405-gpio", .data = (void *) 12 },
> + /* pm660 has 13 GPIOs with holes on 1, 5, 6, 7, 8 and 10 */
> + { .compatible = "qcom,pm660-gpio", .data = (void *) 13 },
> + /* pm660l has 12 GPIOs with holes on 1, 2, 10, 11 and 12 */
> + { .compatible = "qcom,pm660l-gpio", .data = (void *) 12 },
> /* pm8150 has 10 GPIOs with holes on 2, 5, 7 and 8 */
> { .compatible = "qcom,pm8150-gpio", .data = (void *) 10 },
> /* pm8150b has 12 GPIOs with holes on 3, r and 7 */
> --
> 2.27.0
>
Re: [PATCH v3 2/7] Documentation: Document pm660(l) SPMI GPIOs compatible
On Mon 22 Jun 12:25 PDT 2020, Konrad Dybcio wrote: Reviewed-by: Bjorn Andersson > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > index 7be5de8d253f..c3d1914381ae 100644 > --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt > @@ -23,6 +23,8 @@ PMIC's from Qualcomm. > "qcom,pmi8994-gpio" > "qcom,pmi8998-gpio" > "qcom,pms405-gpio" > + "qcom,pm660-gpio" > + "qcom,pm660l-gpio" > "qcom,pm8150-gpio" > "qcom,pm8150b-gpio" > "qcom,pm6150-gpio" > -- > 2.27.0 >
Re: [PATCH 0/8] remove unicore32 support
On Tue, Jun 23, 2020 at 8:57 AM Mike Rapoport wrote: > > From: Mike Rapoport > > The unicore32 port do not seem maintained for a long time now, there is no > upstream toolchain that can create unicore32 binaries and all the links to > prebuilt toolchains for unicore32 are dead. Even compilers that were > available are not supported by the kernel anymore. Peter Maydell also brought this up recently, since there is also a stale qemu port. I agree in principle that this port is about as dead as it gets and presumably nobody has attempted running a kernel later than linux-4.9 nor will they do that in the future. I see that the hardware support was never fully completed either, with at least the "PKUnity-v3-UMAL" ethernet driver getting submitted in 2011 but never merged and no public information on a driver for the "PKUnity-v3-MMC" device that presumably holds the rootfs and the "PKUnity-v3-UART" device. However, it's worth pointing out two arguments against removal: - Guan Xuetao is still listed as maintainer and asked for the port to be kept around the last time I suggested removing it two years ago. He promised that there would be compiler sources (llvm I think), but has not made those available since. - https://github.com/gxt has patches to linux-4.9 and qemu-2.7, both released in 2016, with patches dated early 2019. These patches mainly restore a syscall ABI that was never part of mainline Linux but apparently used in production. qemu-2.8 removed support for that ABI and newer kernels (4.19+) as you say can no longer be built with the old toolchain, so I would guess there will not be any future updates to that git tree. With that information added to the pull request and the maintainer added to Cc: Acked-by: Arnd Bergmann
Scheduler wakeup path tuning surface: Use-Cases and Requirements
Since last year's OSPM Summit we started conceiving the idea that task wakeup path could be better tuned for certain classes of workloads and usage scenarios. Various people showed interest for a possible tuning interface for the scheduler wakeup path. .:: The Problem === The discussions we had so far [1] have not been effective in clearly identifying if a common tuning surface is possible. The last discussion at this year's OSPM Summit [2,3] was also kind of inconclusive and left us with the message: start by collecting the requirements and then see what interface fits them the best. General consensus is that a unified interface can be challenging and maybe not feasible. However, generalisation is also a value and we should strive for it whenever it's possible. Someone might think that we did not put enough effort in the analysis of requirements. Perhaps what we missed so far is also a structured and organised way to collect requirements which also can help in factoring out the things they have in common. .:: The Proposal This thread aims at providing a guided template for the description of different task wakeup use-cases. It does that by setting a series of questions aimed at precisely describing what's "currently broken", what we would like to have instead and how we could achieve it. What we propose here is that, for each wakeup use-case, we start by replying to this email to provide the required details/comments for a predefined list of questions. This will generate independent discussion threads. Each thread will be free to focus on a specific proposal but still all the thread will be reasoning around a common set of fundamental concepts. The hope is that, by representing all the use-cases as sufficiently detailed responses to a common set of questions, once the discussion settles down, we can more easily verify if there are common things surfacing which then can be naturally wrapped into a unified user-space API. A first use-case description, following the template guidelines, will be posted shortly after this message. This also will provide an example for how to use the template. NOTE: Whenever required, pseudo-code or simplified C can be used. I hope this can drive a fruitful discussion in preparation for LPC! Best, Patrick ---8<--- For templates submissions: reply only to the following ---8<--- .:: Scheduler Wakeup Path Requirements Collection Template == A) Name: unique one-liner name for the proposed use-case B) Target behaviour: one paragraph to describe the wakeup path issue C) Existing control paths: reference to code paths to justify B) Assuming v5.6 as the reference kernel, this section should provide links to code paths such as, e.g. fair.c:3917 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/fair.c?h=v5.6#n3917 Alternatively code snippets can be added inline, e.g. /* * The 'current' period is already promised to the current tasks, * however the extra weight of the new task will slow them down a * little, place the new task so that it fits in the slot that * stays open at the end. */ if (initial && sched_feat(START_DEBIT)) vruntime += sched_vslice(cfs_rq, se); NOTE: if the use-case exists only outside the mainline Linux kernel this section can stay empty D) Desired behaviour: one paragraph to describe the desired update NOTE: the current mainline expression is assumed to be correct for existing use-cases. Thus, here we are looking for run-time tuning of those existing features. E) Existing knobs (if any): reference to whatever existing tunable Some features can already be tuned, but perhaps only via compile time knobs, SCHED_FEATs or system wide tunable. If that's the case, we should document them here and explain how they currently work and what are (if any) the implicit assumptions, e.g. what is the currently implemented scheduling policy/heuristic. F) Existing knobs (if any): one paragraph description of the limitations If the existing knobs are not up to the job for this use-case, shortly explain here why. It could be because a tuning surface is already there but it's hardcoded (e.g. compile time knob) or too coarse grained (e.g. a SCHED_FEAT). G) Proportionality Analysis: check the nature of the target behavior Goal here is to verify and discuss if the behaviour (B) has a proportional nature: different values of the control knobs (E) are expected to produce different effects for (B). Special care should be taken to check if the target behaviour has an intrinsically "binary nature", i.e. only two values make really sense. In this case it would be very useful to argument why a generalisation towards a non-binary behaviours does NOT make sense. H) Range A
[PATCH V7 1/7] iio: adc: Convert the QCOM SPMI ADC bindings to .yaml format
Convert the adc bindings from .txt to .yaml format. Signed-off-by: Jishnu Prakash Reviewed-by: Amit Kucheria Reviewed-by: Rob Herring Acked-by: Linus Walleij --- .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 173 -- .../bindings/iio/adc/qcom,spmi-vadc.yaml | 252 + 2 files changed, 252 insertions(+), 173 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt deleted file mode 100644 index c878768..000 --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt +++ /dev/null @@ -1,173 +0,0 @@ -Qualcomm's SPMI PMIC ADC - -- SPMI PMIC voltage ADC (VADC) provides interface to clients to read - voltage. The VADC is a 15-bit sigma-delta ADC. -- SPMI PMIC5 voltage ADC (ADC) provides interface to clients to read - voltage. The VADC is a 16-bit sigma-delta ADC. - -VADC node: - -- compatible: -Usage: required -Value type: -Definition: Should contain "qcom,spmi-vadc". -Should contain "qcom,spmi-adc5" for PMIC5 ADC driver. -Should contain "qcom,spmi-adc-rev2" for PMIC rev2 ADC driver. -Should contain "qcom,pms405-adc" for PMS405 PMIC - -- reg: -Usage: required -Value type: -Definition: VADC base address in the SPMI PMIC register map. - -- #address-cells: -Usage: required -Value type: -Definition: Must be one. Child node 'reg' property should define ADC -channel number. - -- #size-cells: -Usage: required -Value type: -Definition: Must be zero. - -- #io-channel-cells: -Usage: required -Value type: -Definition: Must be one. For details about IIO bindings see: -Documentation/devicetree/bindings/iio/iio-bindings.txt - -- interrupts: -Usage: optional -Value type: -Definition: End of conversion interrupt. - -Channel node properties: - -- reg: -Usage: required -Value type: -Definition: ADC channel number. -See include/dt-bindings/iio/qcom,spmi-vadc.h - -- label: -Usage: required for "qcom,spmi-adc5" and "qcom,spmi-adc-rev2" -Value type: -Definition: ADC input of the platform as seen in the schematics. -For thermistor inputs connected to generic AMUX or GPIO inputs -these can vary across platform for the same pins. Hence select -the platform schematics name for this channel. - -- qcom,decimation: -Usage: optional -Value type: -Definition: This parameter is used to decrease ADC sampling rate. -Quicker measurements can be made by reducing decimation ratio. -- For compatible property "qcom,spmi-vadc", valid values are - 512, 1024, 2048, 4096. If property is not found, default value - of 512 will be used. -- For compatible property "qcom,spmi-adc5", valid values are 250, 420 - and 840. If property is not found, default value of 840 is used. -- For compatible property "qcom,spmi-adc-rev2", valid values are 256, - 512 and 1024. If property is not present, default value is 1024. - -- qcom,pre-scaling: -Usage: optional -Value type: -Definition: Used for scaling the channel input signal before the signal is -fed to VADC. The configuration for this node is to know the -pre-determined ratio and use it for post scaling. Select one from -the following options. -<1 1>, <1 3>, <1 4>, <1 6>, <1 20>, <1 8>, <10 81>, <1 10> -If property is not found default value depending on chip will be used. - -- qcom,ratiometric: -Usage: optional -Value type: -Definition: Channel calibration type. -- For compatible property "qcom,spmi-vadc", if this property is - specified VADC will use the VDD reference (1.8V) and GND for - channel calibration. If property is not found, channel will be - calibrated with 0.625V and 1.25V reference channels, also - known as absolute calibration. -- For compatible property "qcom,spmi-adc5" and "qcom,spmi-adc-rev2", - if this property is specified VADC will use the VDD reference - (1.875V) and GND for channel calibration. If property is not found, - channel will be calibrated with 0V and 1.25V reference channels, - also known as absolute calibration. - -- qcom,hw-settle-time: -Usage: optional -Value type: -Definition: Time between AMUX getting configured and the ADC starting -conversion. The 'hw_settle_time' is an index used from valid values -and programmed in hardware to achieve the hardware settling delay. -
[PATCH V7 0/7] iio: adc: Add support for QCOM SPMI PMIC7 ADC
The following changes are made in V7: In the seventh patch, the function pointer is defined using typedef instead of struct, to address a review comment. There are no changes in any other patches, from V6. Jishnu Prakash (7): iio: adc: Convert the QCOM SPMI ADC bindings to .yaml format iio: adc: Add PMIC7 ADC bindings iio: adc: Add info property under adc_data iio: adc: Add support for PMIC7 ADC iio: adc: Update return value checks iio: adc: Update debug prints iio: adc: Combine read functions for PMIC5 and PMIC7 .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 173 - .../bindings/iio/adc/qcom,spmi-vadc.yaml | 278 + drivers/iio/adc/qcom-spmi-adc5.c | 242 -- drivers/iio/adc/qcom-vadc-common.c | 262 +++ drivers/iio/adc/qcom-vadc-common.h | 15 ++ include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h| 67 + include/dt-bindings/iio/qcom,spmi-adc7-pm8350b.h | 88 +++ include/dt-bindings/iio/qcom,spmi-adc7-pmk8350.h | 46 include/dt-bindings/iio/qcom,spmi-adc7-pmr735a.h | 28 +++ include/dt-bindings/iio/qcom,spmi-adc7-pmr735b.h | 28 +++ include/dt-bindings/iio/qcom,spmi-vadc.h | 78 +- 11 files changed, 1109 insertions(+), 196 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pm8350b.h create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pmk8350.h create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pmr735a.h create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pmr735b.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH V7 3/7] iio: adc: Add info property under adc_data
Add info property under adc_data to support adding ADC variants
which may use different iio_info than the one defined for PMIC5.
Signed-off-by: Jishnu Prakash
---
drivers/iio/adc/qcom-spmi-adc5.c | 4 +++-
drivers/iio/adc/qcom-vadc-common.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c
index 21fdcde..0fa1d37 100644
--- a/drivers/iio/adc/qcom-spmi-adc5.c
+++ b/drivers/iio/adc/qcom-spmi-adc5.c
@@ -629,6 +629,7 @@ static const struct adc5_data adc5_data_pmic = {
.full_scale_code_volt = 0x70e4,
.full_scale_code_cur = 0x2710,
.adc_chans = adc5_chans_pmic,
+ .info = &adc5_info,
.decimation = (unsigned int [ADC5_DECIMATION_SAMPLES_MAX])
{250, 420, 840},
.hw_settle_1 = (unsigned int [VADC_HW_SETTLE_SAMPLES_MAX])
@@ -643,6 +644,7 @@ static const struct adc5_data adc5_data_pmic_rev2 = {
.full_scale_code_volt = 0x4000,
.full_scale_code_cur = 0x1800,
.adc_chans = adc5_chans_rev2,
+ .info = &adc5_info,
.decimation = (unsigned int [ADC5_DECIMATION_SAMPLES_MAX])
{256, 512, 1024},
.hw_settle_1 = (unsigned int [VADC_HW_SETTLE_SAMPLES_MAX])
@@ -777,7 +779,7 @@ static int adc5_probe(struct platform_device *pdev)
indio_dev->dev.of_node = node;
indio_dev->name = pdev->name;
indio_dev->modes = INDIO_DIRECT_MODE;
- indio_dev->info = &adc5_info;
+ indio_dev->info = adc->data->info;
indio_dev->channels = adc->iio_chans;
indio_dev->num_channels = adc->nchannels;
diff --git a/drivers/iio/adc/qcom-vadc-common.h
b/drivers/iio/adc/qcom-vadc-common.h
index e074902a..6a7553f 100644
--- a/drivers/iio/adc/qcom-vadc-common.h
+++ b/drivers/iio/adc/qcom-vadc-common.h
@@ -136,6 +136,7 @@ struct adc5_data {
const u32 full_scale_code_volt;
const u32 full_scale_code_cur;
const struct adc5_channels *adc_chans;
+ const struct iio_info *info;
unsigned int*decimation;
unsigned int*hw_settle_1;
unsigned int*hw_settle_2;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH V7 2/7] iio: adc: Add PMIC7 ADC bindings
Add documentation for PMIC7 ADC peripheral.
For the PMIC7-type PMICs, ADC peripheral is present in HW for the
following PMICs: PMK8350, PM8350, PM8350b, PMR735a and PMR735b.
Of these, only the ADC peripheral on PMK8350 is exposed directly to SW.
If SW needs to communicate with ADCs on other PMICs, it specifies the
PMIC to PMK8350 through the newly added SID register and communication
between PMK8350 ADC and other PMIC ADCs is carried out through
PBS(Programmable Boot Sequence) at the firmware level.
In addition, add definitions for ADC channels and virtual channel
definitions (combination of ADC channel number and PMIC SID number)
per PMIC, to be used by ADC clients for PMIC7.
Signed-off-by: Jishnu Prakash
Reviewed-by: Amit Kucheria
Reviewed-by: Rob Herring
---
.../bindings/iio/adc/qcom,spmi-vadc.yaml | 38 --
include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h| 67
include/dt-bindings/iio/qcom,spmi-adc7-pm8350b.h | 88 ++
include/dt-bindings/iio/qcom,spmi-adc7-pmk8350.h | 46 +++
include/dt-bindings/iio/qcom,spmi-adc7-pmr735a.h | 28 +++
include/dt-bindings/iio/qcom,spmi-adc7-pmr735b.h | 28 +++
include/dt-bindings/iio/qcom,spmi-vadc.h | 78 ++-
7 files changed, 366 insertions(+), 7 deletions(-)
create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h
create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pm8350b.h
create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pmk8350.h
create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pmr735a.h
create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pmr735b.h
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
index de8d243..e6263b6 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
@@ -13,7 +13,7 @@ maintainers:
description: |
SPMI PMIC voltage ADC (VADC) provides interface to clients to read
voltage. The VADC is a 15-bit sigma-delta ADC.
- SPMI PMIC5 voltage ADC (ADC) provides interface to clients to read
+ SPMI PMIC5/PMIC7 voltage ADC (ADC) provides interface to clients to read
voltage. The VADC is a 16-bit sigma-delta ADC.
properties:
@@ -28,6 +28,7 @@ properties:
- qcom,spmi-vadc
- qcom,spmi-adc5
- qcom,spmi-adc-rev2
+ - qcom,spmi-adc7
reg:
description: VADC base address in the SPMI PMIC register map
@@ -70,6 +71,8 @@ patternProperties:
description: |
ADC channel number.
See include/dt-bindings/iio/qcom,spmi-vadc.h
+ For PMIC7 ADC, the channel numbers are specified separately per PMIC
+ in the PMIC-specific files in include/dt-bindings/iio/.
label:
$ref: /schemas/types.yaml#/definitions/string
@@ -113,11 +116,11 @@ patternProperties:
channel calibration. If property is not found, channel will be
calibrated with 0.625V and 1.25V reference channels, also
known as absolute calibration.
-- For compatible property "qcom,spmi-adc5" and
"qcom,spmi-adc-rev2",
- if this property is specified VADC will use the VDD reference
(1.875V)
- and GND for channel calibration. If property is not found,
channel
- will be calibrated with 0V and 1.25V reference channels, also
known
- as absolute calibration.
+- For compatible property "qcom,spmi-adc5", "qcom,spmi-adc7" and
+ "qcom,spmi-adc-rev2", if this property is specified VADC will use
+ the VDD reference (1.875V) and GND for channel calibration. If
+ property is not found, channel will be calibrated with 0V and
1.25V
+ reference channels, also known as absolute calibration.
type: boolean
qcom,hw-settle-time:
@@ -208,6 +211,29 @@ allOf:
enum: [ 1, 2, 4, 8, 16 ]
default: 1
+ - if:
+ properties:
+compatible:
+ contains:
+const: qcom,spmi-adc7
+
+then:
+ patternProperties:
+"^.*@[0-9a-f]+$":
+ properties:
+qcom,decimation:
+ enum: [ 85, 340, 1360 ]
+ default: 1360
+
+qcom,hw-settle-time:
+ enum: [ 15, 100, 200, 300, 400, 500, 600, 700, 1000, 2000, 4000,
+ 8000, 16000, 32000, 64000, 128000 ]
+ default: 15
+
+qcom,avg-samples:
+ enum: [ 1, 2, 4, 8, 16 ]
+ default: 1
+
examples:
- |
spmi_bus {
diff --git a/include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h
b/include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h
new file mode 100644
index 000..9426f27
--- /dev/null
+++ b/include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier:
[PATCH V7 7/7] iio: adc: Combine read functions for PMIC5 and PMIC7
Add a common function used for read_raw callback for both PMIC5
and PMIC7 ADCs.
Signed-off-by: Jishnu Prakash
---
drivers/iio/adc/qcom-spmi-adc5.c | 49
1 file changed, 19 insertions(+), 30 deletions(-)
diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c
index 0f9af66..88efadb 100644
--- a/drivers/iio/adc/qcom-spmi-adc5.c
+++ b/drivers/iio/adc/qcom-spmi-adc5.c
@@ -449,6 +449,11 @@ static int adc7_do_conversion(struct adc5_chip *adc,
return ret;
}
+typedef int (*adc_do_conversion)(struct adc5_chip *adc,
+ struct adc5_channel_prop *prop,
+ struct iio_chan_spec const *chan,
+ u16 *data_volt, u16 *data_cur);
+
static irqreturn_t adc5_isr(int irq, void *dev_id)
{
struct adc5_chip *adc = dev_id;
@@ -487,9 +492,9 @@ static int adc7_of_xlate(struct iio_dev *indio_dev,
return -EINVAL;
}
-static int adc5_read_raw(struct iio_dev *indio_dev,
+static int adc_read_raw_common(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan, int *val, int *val2,
-long mask)
+long mask, adc_do_conversion do_conv)
{
struct adc5_chip *adc = iio_priv(indio_dev);
struct adc5_channel_prop *prop;
@@ -500,8 +505,8 @@ static int adc5_read_raw(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_PROCESSED:
- ret = adc5_do_conversion(adc, prop, chan,
- &adc_code_volt, &adc_code_cur);
+ ret = do_conv(adc, prop, chan,
+ &adc_code_volt, &adc_code_cur);
if (ret)
return ret;
@@ -518,36 +523,20 @@ static int adc5_read_raw(struct iio_dev *indio_dev,
}
}
-static int adc7_read_raw(struct iio_dev *indio_dev,
+static int adc5_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan, int *val, int *val2,
long mask)
{
- struct adc5_chip *adc = iio_priv(indio_dev);
- struct adc5_channel_prop *prop;
- u16 adc_code_volt, adc_code_cur;
- int ret;
-
- prop = &adc->chan_props[chan->address];
-
- switch (mask) {
- case IIO_CHAN_INFO_PROCESSED:
- ret = adc7_do_conversion(adc, prop, chan,
- &adc_code_volt, &adc_code_cur);
- if (ret)
- return ret;
-
- ret = qcom_adc5_hw_scale(prop->scale_fn_type,
- &adc5_prescale_ratios[prop->prescale],
- adc->data,
- adc_code_volt, val);
-
- if (ret)
- return ret;
+ return adc_read_raw_common(indio_dev, chan, val, val2,
+ mask, adc5_do_conversion);
+}
- return IIO_VAL_INT;
- default:
- return -EINVAL;
- }
+static int adc7_read_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan, int *val, int *val2,
+long mask)
+{
+ return adc_read_raw_common(indio_dev, chan, val, val2,
+ mask, adc7_do_conversion);
}
static const struct iio_info adc5_info = {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH V7 5/7] iio: adc: Update return value checks
Clean up some return value checks to make code more compact.
Signed-off-by: Jishnu Prakash
---
drivers/iio/adc/qcom-spmi-adc5.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c
index dcc7599..3022313 100644
--- a/drivers/iio/adc/qcom-spmi-adc5.c
+++ b/drivers/iio/adc/qcom-spmi-adc5.c
@@ -301,7 +301,7 @@ static int adc5_configure(struct adc5_chip *adc,
/* Read registers 0x42 through 0x46 */
ret = adc5_read(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
- if (ret < 0)
+ if (ret)
return ret;
/* Digital param selection */
@@ -388,7 +388,7 @@ static int adc5_do_conversion(struct adc5_chip *adc,
if (adc->poll_eoc) {
ret = adc5_poll_wait_eoc(adc);
- if (ret < 0) {
+ if (ret) {
pr_err("EOC bit not set\n");
goto unlock;
}
@@ -398,7 +398,7 @@ static int adc5_do_conversion(struct adc5_chip *adc,
if (!ret) {
pr_debug("Did not get completion timeout.\n");
ret = adc5_poll_wait_eoc(adc);
- if (ret < 0) {
+ if (ret) {
pr_err("EOC bit not set\n");
goto unlock;
}
@@ -516,8 +516,6 @@ static int adc5_read_raw(struct iio_dev *indio_dev,
default:
return -EINVAL;
}
-
- return 0;
}
static int adc7_read_raw(struct iio_dev *indio_dev,
@@ -761,7 +759,7 @@ static int adc5_get_dt_channel_data(struct adc5_chip *adc,
ret = adc5_read(adc, ADC5_USR_REVISION1, dig_version,
sizeof(dig_version));
- if (ret < 0) {
+ if (ret) {
dev_err(dev, "Invalid dig version read %d\n", ret);
return ret;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH V7 6/7] iio: adc: Update debug prints
Change pr_err/pr_debug statements to dev_err/dev_dbg for
increased clarity.
Signed-off-by: Jishnu Prakash
Reviewed-by: Andy Shevchenko
---
drivers/iio/adc/qcom-spmi-adc5.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c
index 3022313..0f9af66 100644
--- a/drivers/iio/adc/qcom-spmi-adc5.c
+++ b/drivers/iio/adc/qcom-spmi-adc5.c
@@ -246,11 +246,11 @@ static int adc5_read_voltage_data(struct adc5_chip *adc,
u16 *data)
*data = (rslt_msb << 8) | rslt_lsb;
if (*data == ADC5_USR_DATA_CHECK) {
- pr_err("Invalid data:0x%x\n", *data);
+ dev_err(adc->dev, "Invalid data:0x%x\n", *data);
return -EINVAL;
}
- pr_debug("voltage raw code:0x%x\n", *data);
+ dev_dbg(adc->dev, "voltage raw code:0x%x\n", *data);
return 0;
}
@@ -382,24 +382,24 @@ static int adc5_do_conversion(struct adc5_chip *adc,
ret = adc5_configure(adc, prop);
if (ret) {
- pr_err("ADC configure failed with %d\n", ret);
+ dev_err(adc->dev, "ADC configure failed with %d\n", ret);
goto unlock;
}
if (adc->poll_eoc) {
ret = adc5_poll_wait_eoc(adc);
if (ret) {
- pr_err("EOC bit not set\n");
+ dev_err(adc->dev, "EOC bit not set\n");
goto unlock;
}
} else {
ret = wait_for_completion_timeout(&adc->complete,
ADC5_CONV_TIMEOUT);
if (!ret) {
- pr_debug("Did not get completion timeout.\n");
+ dev_dbg(adc->dev, "Did not get completion timeout.\n");
ret = adc5_poll_wait_eoc(adc);
if (ret) {
- pr_err("EOC bit not set\n");
+ dev_err(adc->dev, "EOC bit not set\n");
goto unlock;
}
}
@@ -721,7 +721,7 @@ static int adc5_get_dt_channel_data(struct adc5_chip *adc,
channel_name = of_get_property(node,
"label", NULL) ? : node->name;
if (!channel_name) {
- pr_err("Invalid channel name\n");
+ dev_err(dev, "Invalid channel name\n");
return -EINVAL;
}
prop->datasheet_name = channel_name;
@@ -764,7 +764,7 @@ static int adc5_get_dt_channel_data(struct adc5_chip *adc,
return ret;
}
- pr_debug("dig_ver:minor:%d, major:%d\n", dig_version[0],
+ dev_dbg(dev, "dig_ver:minor:%d, major:%d\n", dig_version[0],
dig_version[1]);
/* Digital controller >= 5.3 have hw_settle_2 option */
if ((dig_version[0] >= ADC5_HW_SETTLE_DIFF_MINOR &&
@@ -966,7 +966,7 @@ static int adc5_probe(struct platform_device *pdev)
ret = adc5_get_dt_data(adc, node);
if (ret) {
- pr_err("adc get dt data failed\n");
+ dev_err(dev, "adc get dt data failed\n");
return ret;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH V7 4/7] iio: adc: Add support for PMIC7 ADC
The ADC architecture on PMIC7 is changed as compared to PMIC5. The
major change from PMIC5 is that all SW communication to ADC goes through
PMK8350, which communicates with other PMICs through PBS when the ADC
on PMK8350 works in master mode. The SID register is used to identify the
PMICs with which the PBS needs to communicate. Add support for the same.
Signed-off-by: Jishnu Prakash
Reviewed-by: Andy Shevchenko
---
drivers/iio/adc/qcom-spmi-adc5.c | 215 +-
drivers/iio/adc/qcom-vadc-common.c | 262 +
drivers/iio/adc/qcom-vadc-common.h | 14 ++
3 files changed, 488 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c
index 0fa1d37..dcc7599 100644
--- a/drivers/iio/adc/qcom-spmi-adc5.c
+++ b/drivers/iio/adc/qcom-spmi-adc5.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2018, 2020, The Linux Foundation. All rights reserved.
*/
#include
@@ -23,6 +23,7 @@
#define ADC5_USR_REVISION1 0x0
#define ADC5_USR_STATUS1 0x8
+#define ADC5_USR_STATUS1_CONV_FAULTBIT(7)
#define ADC5_USR_STATUS1_REQ_STS BIT(1)
#define ADC5_USR_STATUS1_EOC BIT(0)
#define ADC5_USR_STATUS1_REQ_STS_EOC_MASK 0x3
@@ -65,6 +66,9 @@
#define ADC5_USR_IBAT_DATA10x53
+#define ADC_CHANNEL_OFFSET 0x8
+#define ADC_CHANNEL_MASK GENMASK(7, 0)
+
/*
* Conversion time varies based on the decimation, clock rate, fast average
* samples and measurements queued across different VADC peripherals.
@@ -79,6 +83,11 @@
#define ADC5_HW_SETTLE_DIFF_MINOR 3
#define ADC5_HW_SETTLE_DIFF_MAJOR 5
+/* For PMIC7 */
+#define ADC_APP_SID0x40
+#define ADC_APP_SID_MASK GENMASK(3, 0)
+#define ADC7_CONV_TIMEOUT msecs_to_jiffies(10)
+
enum adc5_cal_method {
ADC5_NO_CAL = 0,
ADC5_RATIOMETRIC_CAL,
@@ -96,6 +105,7 @@ enum adc5_cal_val {
* @cal_method: calibration method.
* @cal_val: calibration value
* @decimation: sampling rate supported for the channel.
+ * @sid: slave id of PMIC owning the channel, for PMIC7.
* @prescale: channel scaling performed on the input signal.
* @hw_settle_time: the time between AMUX being configured and the
* start of conversion.
@@ -110,6 +120,7 @@ struct adc5_channel_prop {
enum adc5_cal_methodcal_method;
enum adc5_cal_val cal_val;
unsigned intdecimation;
+ unsigned intsid;
unsigned intprescale;
unsigned inthw_settle_time;
unsigned intavg_samples;
@@ -165,6 +176,11 @@ static int adc5_write(struct adc5_chip *adc, u16 offset,
u8 *data, int len)
return regmap_bulk_write(adc->regmap, adc->base + offset, data, len);
}
+static int adc5_masked_write(struct adc5_chip *adc, u16 offset, u8 mask, u8
val)
+{
+ return regmap_update_bits(adc->regmap, adc->base + offset, mask, val);
+}
+
static int adc5_prescaling_from_dt(u32 num, u32 den)
{
unsigned int pre;
@@ -314,6 +330,47 @@ static int adc5_configure(struct adc5_chip *adc,
return adc5_write(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
}
+static int adc7_configure(struct adc5_chip *adc,
+ struct adc5_channel_prop *prop)
+{
+ int ret;
+ u8 conv_req = 0, buf[4];
+
+ ret = adc5_masked_write(adc, ADC_APP_SID, ADC_APP_SID_MASK, prop->sid);
+ if (ret)
+ return ret;
+
+ ret = adc5_read(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
+ if (ret)
+ return ret;
+
+ /* Digital param selection */
+ adc5_update_dig_param(adc, prop, &buf[0]);
+
+ /* Update fast average sample value */
+ buf[1] &= ~ADC5_USR_FAST_AVG_CTL_SAMPLES_MASK;
+ buf[1] |= prop->avg_samples;
+
+ /* Select ADC channel */
+ buf[2] = prop->channel;
+
+ /* Select HW settle delay for channel */
+ buf[3] &= ~ADC5_USR_HW_SETTLE_DELAY_MASK;
+ buf[3] |= prop->hw_settle_time;
+
+ /* Select CONV request */
+ conv_req = ADC5_USR_CONV_REQ_REQ;
+
+ if (!adc->poll_eoc)
+ reinit_completion(&adc->complete);
+
+ ret = adc5_write(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
+ if (ret)
+ return ret;
+
+ return adc5_write(adc, ADC5_USR_CONV_REQ, &conv_req, 1);
+}
+
static int adc5_do_conversion(struct adc5_chip *adc,
struct adc5_channel_prop *prop,
struct iio_chan_spec const *chan,
@@ -355,6 +412,43 @@ static int adc5_do_conversion(struct adc5_chip *adc,
return ret;
}
+static int adc7_do_conversion(struct adc5_chip *adc,
+
Re: ARM: imx6: add missing put_device() call in imx6q_suspend_init()
On Fri, Jun 05, 2020 at 12:15:32PM +0200, Markus Elfring wrote: > >> Do you find a previous update suggestion useful? > >> > >> ARM: imx6: Add missing put_device() call in imx6q_suspend_init() > >> https://lore.kernel.org/linux-arm-kernel/5acd7308-f6e1-4b1e-c744-bb2e5fdca...@web.de/ > >> https://lore.kernel.org/patchwork/patch/1151158/ > >> https://lkml.org/lkml/2019/11/9/125 > … > > It is useful indeed. > > Thanks for your positive feedback. > > > > Although I didn't run cocci script, since it can produce too many false > > result > > which is hard to filter out. > > Would you like to clarify any corresponding software analysis options? > > > > BTW, I see you haver done the work already, I guess I won't send any patches > > related to 'missing put_device after of_find_device_by_node()'. > > You may continue also with contributions in such a direction. > I would like to point out that other developers occasionally got into the mood > to improve implementation details in similar ways already. > > > > Any idea why these pathes didn't get applied ? > > I can make assumptions about the reasons for the possibly questionable > handling > of such patches. Markus, Could you resend it to my kernel.org address? Shawn
Re: [PATCH 2/6] arm64/vdso: Zap vvar pages when switching to a time namespace
On Fri, Jun 19, 2020 at 05:38:12PM +0200, Christian Brauner wrote:
> On Tue, Jun 16, 2020 at 12:55:41AM -0700, Andrei Vagin wrote:
> > The VVAR page layout depends on whether a task belongs to the root or
> > non-root time namespace. Whenever a task changes its namespace, the VVAR
> > page tables are cleared and then they will be re-faulted with a
> > corresponding layout.
> >
> > Reviewed-by: Vincenzo Frascino
> > Reviewed-by: Dmitry Safonov
> > Signed-off-by: Andrei Vagin
> > ---
> > arch/arm64/kernel/vdso.c | 32
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> > index b0aec4e8c9b4..df4bb736d28a 100644
> > --- a/arch/arm64/kernel/vdso.c
> > +++ b/arch/arm64/kernel/vdso.c
> > @@ -125,6 +125,38 @@ static int __vdso_init(enum vdso_abi abi)
> > return 0;
> > }
> >
> > +#ifdef CONFIG_TIME_NS
> > +/*
> > + * The vvar page layout depends on whether a task belongs to the root or
> > + * non-root time namespace. Whenever a task changes its namespace, the VVAR
> > + * page tables are cleared and then they will re-faulted with a
> > + * corresponding layout.
> > + * See also the comment near timens_setup_vdso_data() for details.
> > + */
> > +int vdso_join_timens(struct task_struct *task, struct time_namespace *ns)
> > +{
> > + struct mm_struct *mm = task->mm;
> > + struct vm_area_struct *vma;
> > +
> > + if (mmap_write_lock_killable(mm))
> > + return -EINTR;
>
> Hey,
>
> Just a heads-up I'm about to plumb CLONE_NEWTIME support into setns()
Hmm. I am not sure that I unserstand what you mean. I think setns(nsfd,
CLONE_NEWTIME) works now. For example, we use it in
tools/testing/selftests/timens/timens.c. Do you mean setns(pidfd,
CLONE_NEWTIME | CLONE_something)?
> which would mean that vdso_join_timens() ould not be allowed to fail
> anymore to make it easy to switch to multiple namespaces atomically. So
> this would probably need to be changed to mmap_write_lock() which I've
> already brought up upstream:
> https://lore.kernel.org/lkml/2020060221.pgd3r5qkjrjmfqa2@wittgenstein/
> (Assuming that people agree. I just sent the series and most people here
> are Cced.)
>
> Thanks!
> Christian
Re: [PATCH v2 1/2] ASoC: fsl_mqs: Don't check clock is NULL before calling clk API
> In-Reply-To: I guess that it should be sufficient to specify such a field once for the header information. > Because clk_prepare_enable and clk_disable_unprepare should > check input clock parameter is NULL or not internally, I find this change description unclear. > then we don't need to check them before calling the function. Please use an imperative wording for the commit message. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=dd0d718152e4c65b173070d48ea9dfc06894c3e5#n151 Regards, Markus
Re: [PATCH v3 5/7] arm64: dts: qcom: Add support for Sony Xperia XA2/Plus/Ultra (Nile platform)
On Mon 22 Jun 12:25 PDT 2020, Konrad Dybcio wrote:
> Add device tree support for the Sony Xperia XA2, XA2 Plus and
> XA2 Ultra smartphones. They are all based on the Sony Nile
> platform (sdm630) and share a lot of common code. The
> differences are really minor, so a Nile-common DTSI
> has been created to reduce clutter.
>
> XA2 - Pioneer
> XA2 Plus - Voyager
> XA2 Ultra - Discovery
>
> The boards currently support:
> * Screen console
> * SDHCI
> * I2C
> * pstore log dump
> * GPIO keys
> * PSCI idle states
>
> Signed-off-by: Konrad Dybcio
> Tested-by: ??ukasz Patron
> ---
> arch/arm64/boot/dts/qcom/Makefile | 3 +
> .../sdm630-sony-xperia-nile-discovery.dts | 13 ++
> .../qcom/sdm630-sony-xperia-nile-pioneer.dts | 13 ++
> .../qcom/sdm630-sony-xperia-nile-voyager.dts | 20 +++
> .../dts/qcom/sdm630-sony-xperia-nile.dtsi | 136 ++
> 5 files changed, 185 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-discovery.dts
> create mode 100644
> arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-pioneer.dts
> create mode 100644
> arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-voyager.dts
> create mode 100644 arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile
> index 0f2c33d611df..1cad7cb07574 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -16,6 +16,9 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8998-hp-envy-x2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8998-lenovo-miix-630.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8998-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sc7180-idp.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += sdm630-sony-xperia-nile-discovery.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += sdm630-sony-xperia-nile-pioneer.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += sdm630-sony-xperia-nile-voyager.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm660-xiaomi-lavender.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-discovery.dts
> b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-discovery.dts
> new file mode 100644
> index ..8fca0b69fa01
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-discovery.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2020, Konrad Dybcio
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm630-sony-xperia-nile.dtsi"
> +
> +/ {
> + model = "Sony Xperia XA2 Ultra";
> + compatible = "sony,discovery-row", "qcom,sdm630";
> +};
> diff --git a/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-pioneer.dts
> b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-pioneer.dts
> new file mode 100644
> index ..90dcd4ebaaed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-pioneer.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2020, Konrad Dybcio
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm630-sony-xperia-nile.dtsi"
> +
> +/ {
> + model = "Sony Xperia XA2";
> + compatible = "sony,pioneer-row", "qcom,sdm630";
> +};
> diff --git a/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-voyager.dts
> b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-voyager.dts
> new file mode 100644
> index ..fae5f1bb6834
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile-voyager.dts
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2020, Konrad Dybcio
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm630-sony-xperia-nile.dtsi"
> +
> +/ {
> + model = "Sony Xperia XA2 Plus";
> + compatible = "sony,voyager-row", "qcom,sdm630";
> +
> + chosen {
> + framebuffer@9d40 {
> + reg = <0 0x9d40 0 (2160 * 1080 * 4)>;
> + height = <2160>;
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile.dtsi
> b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile.dtsi
> new file mode 100644
> index ..9ba359c848d0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile.dtsi
> @@ -0,0 +1,136 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2020, Konrad Dybcio
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm630.dtsi"
> +#include "pm660.dtsi"
> +#include "pm660l.dtsi"
> +#include
> +#include
> +#include
> +
> +/ {
> + /* required for bootloader to select correct board */
> + qcom,msm-id = <318 0>;
> + qcom,board-id = <8 1>;
> + qcom,pmic-id = <0x1001b 0x101011a 0x00 0x00 0x1001b 0x201011a 0x00
> 0x00>;
> +
> + /* This part enables graphical output via bootloader-enabled display */
> + chosen {
> + bootargs = "earlycon=tty0 console=tty0";
> +
> + #address-cells = <2>;
> + #s
Re: [PATCH V3 0/3] firmware: imx: fix/update cm4 and add resource check
On Fri, Jun 05, 2020 at 09:59:29AM +0800, peng@nxp.com wrote: > From: Peng Fan > > V3: > Fix comments > Add R-b tag > > V2: > Add R-b tag > Drop patch 3/4 from V1 > Add comments and update Copyright for patch 2/3 > keep code consistency in Patch 3/3 > > V1: > https://patchwork.kernel.org/cover/11505045/ > > Fix cm40 power domain, update to add more cm4 resources > Add resource owner check, to not register if not owned by Linux. > > Peng Fan (3): > firmware: imx: scu-pd: fix cm40 power domain > firmware: imx: add resource management api > firmware: imx: scu-pd: add more cm4 resources Applied all, thanks.
Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote: > > Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe: > > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: > >>> I still have my doubts about allowing fence waiting from within shrinkers. > >>> IMO ideally they should use a trywait approach, in order to allow memory > >>> allocation during command submission for drivers that > >>> publish fences before command submission. (Since early reservation object > >>> release requires that). > >> Yeah it is a bit annoying, e.g. for drm/scheduler I think we'll end up > >> with a mempool to make sure it can handle it's allocations. > >> > >>> But since drivers are already waiting from within shrinkers and I take > >>> your > >>> word for HMM requiring this, > >> Yeah the big trouble is HMM and mmu notifiers. That's the really awkward > >> one, the shrinker one is a lot less established. > > I really question if HW that needs something like DMA fence should > > even be using mmu notifiers - the best use is HW that can fence the > > DMA directly without having to get involved with some command stream > > processing. > > > > Or at the very least it should not be a generic DMA fence but a > > narrowed completion tied only into the same GPU driver's command > > completion processing which should be able to progress without > > blocking. > > > > The intent of notifiers was never to endlessly block while vast > > amounts of SW does work. > > > > Going around and switching everything in a GPU to GFP_ATOMIC seems > > like bad idea. > > > >> I've pinged a bunch of armsoc gpu driver people and ask them how much this > >> hurts, so that we have a clear answer. On x86 I don't think we have much > >> of a choice on this, with userptr in amd and i915 and hmm work in nouveau > >> (but nouveau I think doesn't use dma_fence in there). > > Soon nouveau will get company. We're working on a recoverable page fault > implementation for HMM in amdgpu where we'll need to update page tables > using the GPUs SDMA engine and wait for corresponding fences in MMU > notifiers. Can you pls cc these patches to dri-devel when they show up? Depending upon how your hw works there's and endless amount of bad things that can happen. Also I think (again depending upon how the hw exactly works) this stuff would be a perfect example for the dma_fence annotations. The worst case is if your hw cannot preempt while a hw page fault is pending. That means none of the dma_fence will ever signal (the amdkfd preempt ctx fences wont, and the classic fences from amdgpu might be also stall). At least when you're unlucky and the fence you're waiting on somehow (anywhere in its dependency chain really) need the engine that's currently blocked waiting for the hw page fault. That in turn means anything you do in your hw page fault handler is in the critical section for dma fence signalling, which has far reaching implications. -Daniel > > Regards, > Felix > > > > Right, nor will RDMA ODP. > > > > Jason > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
RE: [EXT] Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading
Hi Ido,
> -Original Message-
> From: Ido Schimmel
> Sent: 2020年6月23日 15:10
> To: Po Liu
> Cc: da...@davemloft.net; linux-kernel@vger.kernel.org;
> net...@vger.kernel.org; j...@resnulli.us; vinicius.go...@intel.com;
> v...@buslov.dev; Claudiu Manoil ; Vladimir
> Oltean ; Alexandru Marginean
> ; michael.c...@broadcom.com;
> vis...@chelsio.com; sae...@mellanox.com; l...@kernel.org;
> j...@mellanox.com; ido...@mellanox.com;
> alexandre.bell...@bootlin.com; unglinuxdri...@microchip.com;
> k...@kernel.org; j...@mojatatu.com; xiyou.wangc...@gmail.com;
> simon.hor...@netronome.com; pa...@netfilter.org;
> mo...@mellanox.com; m-kariche...@ti.com;
> andre.gue...@linux.intel.com; step...@networkplumber.org
> Subject: [EXT] Re: [v1,net-next 3/4] net: qos: police action add index for tc
> flower offloading
>
> Caution: EXT Email
>
> On Tue, Jun 23, 2020 at 02:34:11PM +0800, Po Liu wrote:
> > From: Po Liu
> >
> > Hardware may own many entries for police flow. So that make one(or
> > multi) flow to be policed by one hardware entry. This patch add the
> > police action index provide to the driver side make it mapping the
> > driver hardware entry index.
>
> Maybe first mention that it is possible for multiple filters in software to
> share the same policer. Something like:
>
> "
> It is possible for several tc filters to share the same police action by
> specifying the action's index when installing the filters.
>
> Propagate this index to device drivers through the flow offload
> intermediate representation, so that drivers could share a single hardware
> policer between multiple filters.
> "
>
> >
> > Signed-off-by: Po Liu
> > ---
> > include/net/flow_offload.h | 1 +
> > net/sched/cls_api.c| 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
> > index c2ef19c6b27d..eed98075b1ae 100644
> > --- a/include/net/flow_offload.h
> > +++ b/include/net/flow_offload.h
> > @@ -232,6 +232,7 @@ struct flow_action_entry {
> > booltruncate;
> > } sample;
> > struct {/* FLOW_ACTION_POLICE
> > */
> > + u32 index;
> > s64 burst;
> > u64 rate_bytes_ps;
> > u32 mtu;
> > diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c index
> > 6aba7d5ba1ec..fdc4c89ca1fa 100644
> > --- a/net/sched/cls_api.c
> > +++ b/net/sched/cls_api.c
> > @@ -3659,6 +3659,7 @@ int tc_setup_flow_action(struct flow_action
> *flow_action,
> > entry->police.rate_bytes_ps =
> > tcf_police_rate_bytes_ps(act);
> > entry->police.mtu = tcf_police_tcfp_mtu(act);
> > + entry->police.index = act->tcfa_index;
> > } else if (is_tcf_ct(act)) {
> > entry->id = FLOW_ACTION_CT;
> > entry->ct.action = tcf_ct_action(act);
> > --
> > 2.17.1
> >
Re: [PATCH v2 1/3] mm/shuffle: don't move pages between zones and don't read garbage memmaps
> Hmm.. I thought this is the behavior for early section, while it looks current > code doesn't work like this: > >if (section_is_early && memmap) >free_map_bootmem(memmap); >else > depopulate_section_memmap(pfn, nr_pages, altmap); > > section_is_early is always "true" for early section, while memmap is not-NULL > only when sub-section map is empty. > > If my understanding is correct, when we remove a sub-section in early section, > the code would call depopulate_section_memmap(), which in turn free related > memmap. By removing the memmap, the return value from pfn_to_online_page() is > not a valid one. I think you're right, and pfn_valid() would also return true, as it is an early section. This looks broken. > > Maybe we want to write the code like this: > >if (section_is_early) >if (memmap) >free_map_bootmem(memmap); >else > depopulate_section_memmap(pfn, nr_pages, altmap); > I guess that should be the way to go @Dan, I think what Wei proposes here is correct, right? Or how does it work in the VMEMMAP case with early sections? -- Thanks, David / dhildenb
Re: [PATCH v2] kvm: Fix false positive RCU usage warning
On 16/05/20 10:22, madhuparnabhowmi...@gmail.com wrote: > From: Madhuparna Bhowmik > > Fix the following false positive warnings: > > [ 9403.765413][T61744] = > [ 9403.786541][T61744] WARNING: suspicious RCU usage > [ 9403.807865][T61744] 5.7.0-rc1-next-20200417 #4 Tainted: G L > [ 9403.838945][T61744] - > [ 9403.860099][T61744] arch/x86/kvm/mmu/page_track.c:257 RCU-list traversed > in non-reader section!! > > and > > [ 9405.859252][T61751] = > [ 9405.859258][T61751] WARNING: suspicious RCU usage > [ 9405.880867][T61755] - > [ 9405.911936][T61751] 5.7.0-rc1-next-20200417 #4 Tainted: G L > [ 9405.911942][T61751] - > [ 9405.911950][T61751] arch/x86/kvm/mmu/page_track.c:232 RCU-list traversed > in non-reader section!! > > Since srcu read lock is held, these are false positive warnings. > Therefore, pass condition srcu_read_lock_held() to > list_for_each_entry_rcu(). > > Reported-by: kernel test robot > Signed-off-by: Madhuparna Bhowmik > --- > v2: > -Rebase v5.7-rc5 > > arch/x86/kvm/mmu/page_track.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c > index ddc1ec3bdacd..1ad79c7aa05b 100644 > --- a/arch/x86/kvm/mmu/page_track.c > +++ b/arch/x86/kvm/mmu/page_track.c > @@ -229,7 +229,8 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t > gpa, const u8 *new, > return; > > idx = srcu_read_lock(&head->track_srcu); > - hlist_for_each_entry_rcu(n, &head->track_notifier_list, node) > + hlist_for_each_entry_rcu(n, &head->track_notifier_list, node, > + srcu_read_lock_held(&head->track_srcu)) > if (n->track_write) > n->track_write(vcpu, gpa, new, bytes, n); > srcu_read_unlock(&head->track_srcu, idx); > @@ -254,7 +255,8 @@ void kvm_page_track_flush_slot(struct kvm *kvm, struct > kvm_memory_slot *slot) > return; > > idx = srcu_read_lock(&head->track_srcu); > - hlist_for_each_entry_rcu(n, &head->track_notifier_list, node) > + hlist_for_each_entry_rcu(n, &head->track_notifier_list, node, > + srcu_read_lock_held(&head->track_srcu)) > if (n->track_flush_slot) > n->track_flush_slot(kvm, slot, n); > srcu_read_unlock(&head->track_srcu, idx); > Hi, sorry for the delay in reviewing this patch. I would like to ask Paul about it. While you're correctly fixing a false positive, hlist_for_each_entry_rcu would have a false _negative_ if you called it under rcu_read_lock/unlock and the data structure was protected by SRCU. This is why for example srcu_dereference is used instead of rcu_dereference_check, and why srcu_dereference uses __rcu_dereference_check (with the two underscores) instead of rcu_dereference_check. Using rcu_dereference_check would add an "|| rcu_read_lock_held()" to the condition which is wrong. I think instead you should add hlist_for_each_srcu and hlist_for_each_entry_srcu macro to include/linux/rculist.h. There is no need for equivalents of hlist_for_each_entry_continue_rcu and hlist_for_each_entry_from_rcu, because they use rcu_dereference_raw. However, it's not documented why they do so. Paul, do you have any objections to the idea? Thanks, Paolo
Re: [RFC] Bypass filesystems for reading cached pages
On Tue, Jun 23, 2020 at 2:52 AM Dave Chinner wrote:
> On Mon, Jun 22, 2020 at 04:35:05PM +0200, Andreas Gruenbacher wrote:
> > On Mon, Jun 22, 2020 at 2:32 AM Dave Chinner wrote:
> > > On Fri, Jun 19, 2020 at 08:50:36AM -0700, Matthew Wilcox wrote:
> > > >
> > > > This patch lifts the IOCB_CACHED idea expressed by Andreas to the VFS.
> > > > The advantage of this patch is that we can avoid taking any filesystem
> > > > lock, as long as the pages being accessed are in the cache (and we don't
> > > > need to readahead any pages into the cache). We also avoid an indirect
> > > > function call in these cases.
> > >
> > > What does this micro-optimisation actually gain us except for more
> > > complexity in the IO path?
> > >
> > > i.e. if a filesystem lock has such massive overhead that it slows
> > > down the cached readahead path in production workloads, then that's
> > > something the filesystem needs to address, not unconditionally
> > > bypass the filesystem before the IO gets anywhere near it.
> >
> > I'm fine with not moving that functionality into the VFS. The problem
> > I have in gfs2 is that taking glocks is really expensive. Part of that
> > overhead is accidental, but we definitely won't be able to fix it in
> > the short term. So something like the IOCB_CACHED flag that prevents
> > generic_file_read_iter from issuing readahead I/O would save the day
> > for us. Does that idea stand a chance?
>
> I have no problem with a "NOREADAHEAD" flag being passed to
> generic_file_read_iter(). It's not a "already cached" flag though,
> it's a "don't start any IO" directive, just like the NOWAIT flag is
> a "don't block on locks or IO in progress" directive and not an
> "already cached" flag. Readahead is something we should be doing,
> unless a filesystem has a very good reason not to, such as the gfs2
> locking case here...
The requests coming in can have the IOCB_NOWAIT flag set or cleared.
The idea was to have an additional flag that implies IOCB_NOWAIT so
that you can do:
iocb->ki_flags |= IOCB_NOIO;
generic_file_read_iter()
if ("failed because of IOCB_NOIO") {
if ("failed because of IOCB_NOWAIT")
return -EAGAIN;
iocb->ki_flags &= ~IOCB_NOIO;
"locking"
generic_file_read_iter()
"unlocking"
}
without having to save iocb->ki_flags. The alternative would be:
int flags = iocb->ki_flags;
iocb->ki_flags |= IOCB_NOIO | IOCB_NOWAIT;
ret = generic_file_read_iter()
if ("failed because of IOCB_NOIO or IOCB_NOWAIT") {
if ("failed because of IOCB_NOWAIT" && (flags & IOCB_NOWAIT))
return -EAGAIN;
iocb->ki_flags &= ~IOCB_NOIO;
"locking"
generic_file_read_iter()
"unlocking"
}
Andreas
RE:Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading
Hi Ido,
Sorry, ignore previous email.
> -Original Message-
> From: Ido Schimmel
> Sent: 2020年6月23日 15:10
> To: Po Liu
> Cc: da...@davemloft.net; linux-kernel@vger.kernel.org;
> net...@vger.kernel.org; j...@resnulli.us; vinicius.go...@intel.com;
> v...@buslov.dev; Claudiu Manoil ; Vladimir
> Oltean ; Alexandru Marginean
> ; michael.c...@broadcom.com;
> vis...@chelsio.com; sae...@mellanox.com; l...@kernel.org;
> j...@mellanox.com; ido...@mellanox.com;
> alexandre.bell...@bootlin.com; unglinuxdri...@microchip.com;
> k...@kernel.org; j...@mojatatu.com; xiyou.wangc...@gmail.com;
> simon.hor...@netronome.com; pa...@netfilter.org;
> mo...@mellanox.com; m-kariche...@ti.com;
> andre.gue...@linux.intel.com; step...@networkplumber.org
> Subject: Re: [v1,net-next 3/4] net: qos: police action add index for tc
> flower offloading
>
> On Tue, Jun 23, 2020 at 02:34:11PM +0800, Po Liu wrote:
> > From: Po Liu
> >
> > Hardware may own many entries for police flow. So that make one(or
> > multi) flow to be policed by one hardware entry. This patch add the
> > police action index provide to the driver side make it mapping the
> > driver hardware entry index.
>
> Maybe first mention that it is possible for multiple filters in software to
> share the same policer. Something like:
>
> "
> It is possible for several tc filters to share the same police action by
> specifying the action's index when installing the filters.
>
> Propagate this index to device drivers through the flow offload
> intermediate representation, so that drivers could share a single hardware
> policer between multiple filters.
> "
>
Thanks, I would change this commit message.
> >
> > Signed-off-by: Po Liu
> > ---
> > include/net/flow_offload.h | 1 +
> > net/sched/cls_api.c| 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
> > index c2ef19c6b27d..eed98075b1ae 100644
> > --- a/include/net/flow_offload.h
> > +++ b/include/net/flow_offload.h
> > @@ -232,6 +232,7 @@ struct flow_action_entry {
> > booltruncate;
> > } sample;
> > struct {/* FLOW_ACTION_POLICE
> > */
> > + u32 index;
> > s64 burst;
> > u64 rate_bytes_ps;
> > u32 mtu;
> > diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c index
> > 6aba7d5ba1ec..fdc4c89ca1fa 100644
> > --- a/net/sched/cls_api.c
> > +++ b/net/sched/cls_api.c
> > @@ -3659,6 +3659,7 @@ int tc_setup_flow_action(struct flow_action
> *flow_action,
> > entry->police.rate_bytes_ps =
> > tcf_police_rate_bytes_ps(act);
> > entry->police.mtu = tcf_police_tcfp_mtu(act);
> > + entry->police.index = act->tcfa_index;
> > } else if (is_tcf_ct(act)) {
> > entry->id = FLOW_ACTION_CT;
> > entry->ct.action = tcf_ct_action(act);
> > --
> > 2.17.1
> >
Br,
Po Liu
[PATCH v2 2/2] net: phy: call phy_disable_interrupts() in phy_init_hw()
Call phy_disable_interrupts() in phy_init_hw() to "have a defined init
state as we don't know in which state the PHY is if the PHY driver is
loaded. We shouldn't assume that it's the chip power-on defaults, BIOS
or boot loader could have changed this. Or in case of dual-boot
systems the other OS could leave the PHY in whatever state." as pointed
out by Heiner.
Suggested-by: Heiner Kallweit
Signed-off-by: Jisheng Zhang
---
drivers/net/phy/phy_device.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 04946de74fa0..f17d397ba689 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1090,10 +1090,13 @@ int phy_init_hw(struct phy_device *phydev)
if (ret < 0)
return ret;
- if (phydev->drv->config_init)
+ if (phydev->drv->config_init) {
ret = phydev->drv->config_init(phydev);
+ if (ret < 0)
+ return ret;
+ }
- return ret;
+ return phy_disable_interrupts(phydev);
}
EXPORT_SYMBOL(phy_init_hw);
--
2.27.0
[PATCH v2 0/2] net: phy: call phy_disable_interrupts() in phy_init_hw()
We face an issue with rtl8211f, a pin is shared between INTB and PMEB, and the PHY Register Accessible Interrupt is enabled by default, so the INTB/PMEB pin is always active in polling mode case. As Heiner pointed out "I was thinking about calling phy_disable_interrupts() in phy_init_hw(), to have a defined init state as we don't know in which state the PHY is if the PHY driver is loaded. We shouldn't assume that it's the chip power-on defaults, BIOS or boot loader could have changed this. Or in case of dual-boot systems the other OS could leave the PHY in whatever state." patch1 exports phy_disable_interrupts() so that it could be used in phy_init_hw() to have a defined init state. patch2 calls phy_disable_interrupts() in phy_init_hw() to have a defined init state. Since v1: - EXPORT the correct symbol Jisheng Zhang (2): net: phy: export phy_disable_interrupts() net: phy: call phy_disable_interrupts() in phy_init_hw() drivers/net/phy/phy.c| 3 ++- drivers/net/phy/phy_device.c | 7 +-- include/linux/phy.h | 1 + 3 files changed, 8 insertions(+), 3 deletions(-) -- 2.27.0
Re: [PATCH] net: ath10k: fix memcpy size from untrusted input
Zekun Shen wrote: > A compromized ath10k peripheral is able to control the size argument > of memcpy in ath10k_pci_hif_exchange_bmi_msg. > > The min result from previous line is not used as the size argument > for memcpy. Instead, xfer.resp_len comes from untrusted stream dma > input. The value comes from "nbytes" in ath10k_pci_bmi_recv_data, > which is set inside _ath10k_ce_completed_recv_next_nolock with the line > > nbytes = __le16_to_cpu(sdesc.nbytes); > > sdesc is a stream dma region which device can write to. > > Signed-off-by: Zekun Shen > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. aed95297250f ath10k: pci: fix memcpy size of bmi response -- https://patchwork.kernel.org/patch/11607461/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH v2 1/2] net: phy: export phy_disable_interrupts()
We face an issue with rtl8211f, a pin is shared between INTB and PMEB,
and the PHY Register Accessible Interrupt is enabled by default, so
the INTB/PMEB pin is always active in polling mode case.
As Heiner pointed out "I was thinking about calling
phy_disable_interrupts() in phy_init_hw(), to have a defined init
state as we don't know in which state the PHY is if the PHY driver is
loaded. We shouldn't assume that it's the chip power-on defaults, BIOS
or boot loader could have changed this. Or in case of dual-boot
systems the other OS could leave the PHY in whatever state."
Export phy_disable_interrupts() so that it could be used in
phy_init_hw() to have a defined init state.
Suggested-by: Heiner Kallweit
Signed-off-by: Jisheng Zhang
---
drivers/net/phy/phy.c | 3 ++-
include/linux/phy.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 1de3938628f4..cd2dbbdba235 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -840,7 +840,7 @@ static void phy_error(struct phy_device *phydev)
* phy_disable_interrupts - Disable the PHY interrupts from the PHY side
* @phydev: target phy_device struct
*/
-static int phy_disable_interrupts(struct phy_device *phydev)
+int phy_disable_interrupts(struct phy_device *phydev)
{
int err;
@@ -852,6 +852,7 @@ static int phy_disable_interrupts(struct phy_device *phydev)
/* Clear the interrupt */
return phy_clear_interrupt(phydev);
}
+EXPORT_SYMBOL_GPL(phy_disable_interrupts);
/**
* phy_interrupt - PHY interrupt handler
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 8c05d0fb5c00..b693b609b2f5 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1416,6 +1416,7 @@ int phy_ethtool_ksettings_set(struct phy_device *phydev,
int phy_mii_ioctl(struct phy_device *phydev, struct ifreq *ifr, int cmd);
int phy_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd);
int phy_do_ioctl_running(struct net_device *dev, struct ifreq *ifr, int cmd);
+int phy_disable_interrupts(struct phy_device *phydev);
void phy_request_interrupt(struct phy_device *phydev);
void phy_free_interrupt(struct phy_device *phydev);
void phy_print_status(struct phy_device *phydev);
--
2.27.0
[PATCH] Revert "usb: dwc3: exynos: Add support for Exynos5422 suspend clk"
This reverts commit 07f6842341abe978e6375078f84506ec3280ece5.
Since SCLK_SCLK_USBD300 suspend clock need to be configured
for phy module, I wrongly mapped this clock to DWC3 code.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Signed-off-by: Anand Moon
---
drivers/usb/dwc3/dwc3-exynos.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 48b68b6f0dc8..90bb022737da 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -162,12 +162,6 @@ static const struct dwc3_exynos_driverdata
exynos5250_drvdata = {
.suspend_clk_idx = -1,
};
-static const struct dwc3_exynos_driverdata exynos5420_drvdata = {
- .clk_names = { "usbdrd30", "usbdrd30_susp_clk"},
- .num_clks = 2,
- .suspend_clk_idx = 1,
-};
-
static const struct dwc3_exynos_driverdata exynos5433_drvdata = {
.clk_names = { "aclk", "susp_clk", "pipe_pclk", "phyclk" },
.num_clks = 4,
@@ -184,9 +178,6 @@ static const struct of_device_id exynos_dwc3_match[] = {
{
.compatible = "samsung,exynos5250-dwusb3",
.data = &exynos5250_drvdata,
- }, {
- .compatible = "samsung,exynos5420-dwusb3",
- .data = &exynos5420_drvdata,
}, {
.compatible = "samsung,exynos5433-dwusb3",
.data = &exynos5433_drvdata,
--
2.27.0
Re: [PATCH 2/7] tty: serial: Add poll_get_irq() to the polling interface
On Mon, 22 Jun 2020 at 21:26, Daniel Thompson
wrote:
>
> On Mon, Jun 22, 2020 at 07:56:19PM +0530, Sumit Garg wrote:
> > From: Daniel Thompson
>
> Sumit, to some extent this mail is me yelling at myself two years ago
> although, in my defence, at the time I choose not to post it because I
> knew it wasn't right.
>
> I'm a bit concerned to see the TODO: comment critiquing this interface
> being removed (from patch 3) without this patch being changed to
> address that comment.
>
I did consider that comment but I couldn't think of a normal scenario
where request_irq() should fail. And in case it fails as well, I did
put in "WARN_ON(res);" so that the user is notified of that particular
error scenario.
>
> > Add new API: poll_get_irq() to the polling interface in order for user
> > of polling interface to retrieve allocated IRQ corresponding to
> > underlying serial device.
> >
> > Although, serial interface still works in polling mode but interrupt
> > associated with serial device can be leveraged for special purposes like
> > debugger(kgdb) entry.
> >
> > Signed-off-by: Daniel Thompson
> > Signed-off-by: Sumit Garg
> > ---
> > drivers/tty/serial/serial_core.c | 18 ++
> > include/linux/serial_core.h | 1 +
> > include/linux/tty_driver.h | 1 +
> > 3 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/tty/serial/serial_core.c
> > b/drivers/tty/serial/serial_core.c
> > index 66a5e2f..1bb033c 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -2470,6 +2470,23 @@ static void uart_poll_put_char(struct tty_driver
> > *driver, int line, char ch)
> > port->ops->poll_put_char(port, ch);
> > uart_port_deref(port);
> > }
> > +
> > +static int uart_poll_get_irq(struct tty_driver *driver, int line)
> > +{
> > + struct uart_driver *drv = driver->driver_state;
> > + struct uart_state *state = drv->state + line;
> > + struct uart_port *port;
> > + int ret = -ENODEV;
> > +
> > + port = uart_port_ref(state);
> > + if (port && port->ops->poll_get_irq) {
> > + ret = port->ops->poll_get_irq(port);
> > + uart_port_deref(port);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > #endif
> >
> > static const struct tty_operations uart_ops = {
> > @@ -2505,6 +2522,7 @@ static const struct tty_operations uart_ops = {
> > .poll_init = uart_poll_init,
> > .poll_get_char = uart_poll_get_char,
> > .poll_put_char = uart_poll_put_char,
> > + .poll_get_irq = uart_poll_get_irq,
>
> The TODO comments claimed this API was bogus because it doesn't permit
> a free and that can cause interoperation problems with the real serial
> driver. I'll cover some of that in a reply to patch 3 but for now.
>
> Anyhow, for this patch, what are the expected semantics for
> uart_poll_get_irq().
Currently, the expected use for this API is to enable uart RX
interrupts and return corresponding IRQ id.
Although, we can make this interface modular as follows:
.poll_get_irq
.poll_enable_rx_int
.poll_disable_rx_int
Your views?
>
> In particular how do they ensure correct interlocking with the real
> serial driver underlying it (if kgdb_nmi is active on a serial port
> then the underlying driver better not be active at the same time).
>
AFAIU kgdb_nmi feature, it registers a new tty driver (ttyNMI0) which
is expected to work alongside underlying tty driver (eg. ttyAMA0 with
amba-pl011). So ttyAMA0 will only become active if user-space tries to
interact with /dev/ttyAMA0 like:
# echo "Hello World!" > /dev/ttyAMA0
So I would like to understand the downsides of having both of them
active at the same time using shared IRQ (although that won't be
possible with NMI as that doesn't support shared mode)?
-Sumit
>
> Daniel.
>
>
> > #endif
> > };
> >
> > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> > index 92f5eba..8b132e6 100644
> > --- a/include/linux/serial_core.h
> > +++ b/include/linux/serial_core.h
> > @@ -78,6 +78,7 @@ struct uart_ops {
> > int (*poll_init)(struct uart_port *);
> > void(*poll_put_char)(struct uart_port *, unsigned char);
> > int (*poll_get_char)(struct uart_port *);
> > + int (*poll_get_irq)(struct uart_port *);
> > #endif
> > };
> >
> > diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
> > index 3584462..d6da5c5 100644
> > --- a/include/linux/tty_driver.h
> > +++ b/include/linux/tty_driver.h
> > @@ -295,6 +295,7 @@ struct tty_operations {
> > int (*poll_init)(struct tty_driver *driver, int line, char *options);
> > int (*poll_get_char)(struct tty_driver *driver, int line);
> > void (*poll_put_char)(struct tty_driver *driver, int line, char ch);
> > + int (*poll_get_irq)(struct tty_driver *driver, int line);
> > #endif
> > int (*proc_show)(struct seq_file *, void *);
> > } __randomize_layout;
> > --
> > 2
Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
Hi, Joerg On 2020/6/22 下午7:55, Joerg Roedel wrote: On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote: +++ b/drivers/iommu/iommu.c @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode, fwspec->iommu_fwnode = iommu_fwnode; fwspec->ops = ops; dev_iommu_fwspec_set(dev, fwspec); + + if (dev_is_pci(dev)) + pci_fixup_device(pci_fixup_final, to_pci_dev(dev)); + That's not going to fly, I don't think we should run the fixups twice, and they should not be run from IOMMU code. Is the only reason for this second pass that iommu_fwspec is not yet allocated when it runs the first time? I ask because it might be easier to just allocate the struct earlier then. Thanks for looking this. Yes, it is the only reason calling fixup secondly after iommu_fwspec is allocated. The first time fixup final is very early in pci_bus_add_device. If allocating iommu_fwspec earlier, it maybe in pci_alloc_dev. And assigning ops still in iommu_fwspec_init. Have tested it works. Not sure is it acceptable? Alternatively, adding can_stall to struct pci_dev is simple but ugly too, since pci does not know stall now. Thanks
[PATCH v2 1/1] PCI: cadence-ep: Remove obsolete path from comment
This comment still refers to the old driver pathname, when all PCI drivers were located directly under the drivers/pci directory. Anyway the function name itself is enough, so we can remove the overabundant path reference. Signed-off-by: Flavio Suligoi --- v1: - after the suggestion of Bjorn, remove the whole comment line related to the wrong path - add: Acked-by: Bjorn Helgaas V2: - change the subject line according to the previous commits of the same file - remove wrong "Acked-by ..." drivers/pci/controller/cadence/pcie-cadence-ep.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c index 1c15c8352125..690eefd328ea 100644 --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c @@ -276,7 +276,6 @@ static int cdns_pcie_ep_send_legacy_irq(struct cdns_pcie_ep *ep, u8 fn, u8 intx) cdns_pcie_ep_assert_intx(ep, fn, intx, true); /* * The mdelay() value was taken from dra7xx_pcie_raise_legacy_irq() -* from drivers/pci/dwc/pci-dra7xx.c */ mdelay(1); cdns_pcie_ep_assert_intx(ep, fn, intx, false); -- 2.17.1
[SchedulerWakeupLatency] Per-task vruntime wakeup bonus
On Tue, Jun 23, 2020 at 09:29:03 +0200, Patrick Bellasi
wrote...
> .:: Scheduler Wakeup Path Requirements Collection Template
> ==
>
> A) Name
Runtime tunable vruntime wakeup bonus.
> B) Target behavior
All SCHED_OTHER tasks get the same (max) vruntime wakeup bonus. This
bonus affects the chance the task has to preempt the currently running
task. Some tasks, which are (known to be) latency tolerant, should have
a smaller chance to preempt a (known to be) latency sensitive task. To
the contrary, latency sensitive tasks should have a higher chance to
preempt a currently running latency tolerant task.
This task specific distinction is not provided by the current
implementation and all SCHED_OTHER tasks are handled according to the
same simple, system-wide and not run-time tunable policy.
> C) Existing control paths
Assuming:
C: CFS task currently running on CPUx
W: CFS task waking up on the same CPUx
And considering the overall simplified workflow:
core::try_to_wake_up()
// 1) Select on which CPU W will run
core::select_task_rq()
fair::select_task_rq_fair()
// 2) Enqueue W on the selected CPU
core::ttwu_queue()
core::ttwu_do_activate()
core::activate_task()
core::enqueue_task()
fair::enqueue_task_fair()
fair::enqueue_entity()
// 3) Set W's vruntime bonus
fair::place_entity()
se->vruntime = ...
// 4) Check if C can be preempted by W
core::ttwu_do_wakeup()
core::check_preempt_curr()
fair::check_preempt_curr()
fair::check_preempt_wakeup(curr, se)
fair::wakeup_preempt_entity(curr, se)
vdiff = curr.vruntime - se.vruntime
return vdiff > wakeup_gran(se)
We see that W preempts C iff:
vdiff > wakeup_gran(se)
Since:
enqueue_entity(cfs_rq, se, flags)
place_entity(cfs_rq, se, initial=0)
thresh = sysctl_sched_latency / (GENTLE_FAIR_SLEEPERS ? 2 : 1)
vruntime = cfs_rq->min_vruntime - thresh
se->vruntime = max_vruntime(se->vruntime, vruntime)
a waking task's W.vruntime can get a "vruntime bonus" up to:
- 1 scheduler latency (w/ GENTLE_FAIR_SLEEPERS)
- 1/2 scheduler latency (w/o GENTLE_FAIR_SLEEPERS)
> D) Desired behavior
The "vruntime bonus" (thresh) computed in place_entity() should have a
per-task definition, which defaults to the current implementation.
A bigger vruntime bonus can be configured for latency sensitive tasks.
A smaller vruntime bonus can be configured for latency tolerant tasks.
TL;DR
The "vruntime bonus" is meant to give sleepers a compensation for the
service deficit due to them not having (possibly) fully consumed their
assigned fair CPU quota within the current sched_latency interval, see:
commit 51e0304ce6e5 ("sched: Implement a gentler fair-sleepers feature")
The scheduler does that based on a conservative assumption: when a task
sleeps it gives up a portion (P) of its fair CPU bandwidth share in the
current sched_latency period.
Willing to be FAIR, i.e. each task gets a FAIR quota of the CPU in each
sched_latency period, the scheduler wants to give back P to waking
tasks.
However, striving to minimize overheads and complexity, the CFS
scheduler does that using a simple heuristic: each task waking up gets a
bonus, which is capped at one sched_latency period, independently from
"its nature".
What the scheduler completely disregards is that being completely FAIR
is not always necessary. Depending on the nature of a task, not all
tasks require a bonus. To the contrary:
- a GENTLE_FAIR_SLEEPERS bonus given to a background task could result
in preempting a latency sensitive currently running task
- giving only 1/2 scheduler latency bonus to a latency sensitive task
could result in that task being preempted before it completes its
current activation.
> E) Existing knobs
The SCHED_FEAT(GENTLE_FAIR_SLEEPERS, true) defined vruntime bonus value
can be considered the current mainline default value.
This means that "all" CFS tasks waking up will get a
0.5 * sysctl_sched_latency
vruntime bonus wrt the cfs_rq->min_vruntime.
> F) Existing knobs limitations
GENTLE_FAIR_SLEEPERS is a system-wide knob and it's not run-time
tunable on production systems (being a SCHED_DEBUG feature).
Thus, the sched_feature should be removed and replaced by a per-task
knob.
> G) Proportionality Analysis
The value of the vruntime bonus directly affects the chance a task has
to preempt the currently running task.
Indeed, from the code analysis in C:
thresh = sysctl_sched_latency / (GENTLE_FAIR_SLEEPERS ? 2 : 1)
is the "wakeup bonus", which is used as:
vruntime = cfs_rq->min_vruntime - thresh
se->vruntime = max_vruntime(se->vruntime, vruntime)
vdiff = curr.vruntime - se.vruntime
preempt condition: vdiff > wakeup_gran(se)
> H) Range Analysis
The new per-task knob can cover the range [0..sysctl_sched
Re: ARM: imx6: add missing put_device() call in imx6q_suspend_init()
Do you find a previous update suggestion useful? ARM: imx6: Add missing put_device() call in imx6q_suspend_init() https://lore.kernel.org/linux-arm-kernel/5acd7308-f6e1-4b1e-c744-bb2e5fdca...@web.de/ https://lore.kernel.org/patchwork/patch/1151158/ https://lkml.org/lkml/2019/11/9/125 >> … >>> It is useful indeed. … >>> Any idea why these pathes didn't get applied ? >> >> I can make assumptions about the reasons for the possibly questionable >> handling >> of such patches. > > Markus, > > Could you resend it to my kernel.org address? You can get relevant information from the referenced message archive interfaces, can't you? Regards, Markus
Re: [PATCH 03/11] arm64: dts: renesas: hihope-common: Separate out Rev.2.0 specific into hihope-common-rev2.dtsi file
Hi Geert,
On Mon, Jun 8, 2020 at 3:59 PM Lad, Prabhakar
wrote:
>
> Hi Geert,
>
> On Mon, Jun 8, 2020 at 3:47 PM Geert Uytterhoeven
> wrote:
> >
> > Hi Prabhakar,
> >
> > On Sun, Jun 7, 2020 at 8:41 PM Lad Prabhakar
> > wrote:
> > > Separate out Rev.2.0 specific hardware changes into
> > > hihope-common-rev2.dtsi file so that hihope-common.dtsi can be used
> > > by all the variants for RZ/G2M[N] boards.
> > >
> > > Signed-off-by: Lad Prabhakar
> > > Reviewed-by: Marian-Cristian Rotariu
> > >
> >
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/renesas/hihope-common-rev2.dtsi
> >
> > Perhaps just hihope-rev2.dtsi, i.e. without the "common-"?
> >
> Yes makes sense.
>
> > > @@ -0,0 +1,101 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Device Tree Source for the HiHope RZ/G2[MN] main board Rev.2.0 common
> > > + * parts
> > > + *
> > > + * Copyright (C) 2020 Renesas Electronics Corp.
> > > + */
> > > +
> > > +#include
> > > +
> > > +/ {
> > > + leds {
> > > + compatible = "gpio-leds";
> > > +
> > > + bt_active_led {
> > > + label = "blue:bt";
> > > + gpios = <&gpio7 0 GPIO_ACTIVE_HIGH>;
> > > + linux,default-trigger = "hci0-power";
> > > + default-state = "off";
> > > + };
> > > +
> > > + led0 {
> > > + gpios = <&gpio6 11 GPIO_ACTIVE_HIGH>;
> > > + };
> > > +
> > > + led1 {
> > > + gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
> > > + };
> > > +
> > > + led2 {
> > > + gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
> > > + };
> > > +
> > > + led3 {
> > > + gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> > > + };
> >
> > led1, led2, and led3 are present on both, so I'd keep them in
> > hihope-common.dtsi.
> >
> The leds defined in hihope-common-rev4.dtsi are as per the label names
> on the schematics/board so that it's easier to identify the LED's by
> name.
>
I was waiting on the above to be confirmed.
Cheers,
--Prabhakar
> > > +
> > > + wlan_active_led {
> > > + label = "yellow:wlan";
> > > + gpios = <&gpio7 1 GPIO_ACTIVE_HIGH>;
> > > + linux,default-trigger = "phy0tx";
> > > + default-state = "off";
> > > + };
> > > + };
> > > +
> > > + wlan_en_reg: regulator-wlan_en {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "wlan-en-regulator";
> > > + regulator-min-microvolt = <180>;
> > > + regulator-max-microvolt = <180>;
> > > + startup-delay-us = <7>;
> > > +
> > > + gpio = <&gpio_expander 1 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > + };
> >
> > Same for the WLAN regulator, especially as it is referenced from
> > hihope-common.dtsi.
> > As the GPIO line differs between the two variants, you just need
> > to add the gpio property in the revision-specific file.
> >
> Agreed will move this to common.
>
> > > +};
> > > +
> > > +&hscif0 {
> > > + bluetooth {
> > > + compatible = "ti,wl1837-st";
> > > + enable-gpios = <&gpio_expander 2 GPIO_ACTIVE_HIGH>;
> > > + };
> > > +};
> >
> > As node is small, and the GPIO line differs from the two variants,
> > I think duplicating it in both revision-specific files is fine, though.
> >
> Agreed.
>
> Cheers,
> --Prabhakar
>
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > ge...@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like
> > that.
> > -- Linus Torvalds
Re: [PATCH v2] USB: Serial: cypress_M8: Enable Simply Automated UPB PIM
On Mon, Jun 22, 2020 at 11:04:09AM -0600, James Hilliard wrote: > On Mon, Jun 22, 2020 at 2:53 AM Johan Hovold wrote: > > > > On Tue, Jun 16, 2020 at 04:04:03PM -0600, James Hilliard wrote: > > > This is a UPB(Universal Powerline Bus) PIM(Powerline Interface Module) > > > which allows for controlling multiple UPB compatible devices from > > > Linux using the standard serial interface. > > > > > > Based on vendor application source code there are two different models > > > of USB based PIM devices in addition to a number of RS232 based PIM's. > > > > > > The vendor UPB application source contains the following USB ID's: > > > #define USB_PCS_VENDOR_ID 0x04b4 > > > #define USB_PCS_PIM_PRODUCT_ID 0x5500 > > > > > > #define USB_SAI_VENDOR_ID 0x17dd > > > #define USB_SAI_PIM_PRODUCT_ID 0x5500 > > > > > > The first set of ID's correspond to the PIM variant sold by Powerline > > > Control Systems while the second corresponds to the Simply Automated > > > Incorporated PIM. As the product ID for both of these match the default > > > cypress HID->COM RS232 product ID it assumed that they both use an > > > internal variant of this HID->COM RS232 converter hardware. However > > > as the vendor ID for the Simply Automated variant is different we need > > > to also add it to the cypress_M8 driver so that it is properly > > > detected. > > > > > > Signed-off-by: James Hilliard > > > --- > > > Changes v1 -> v2: > > > - Add more detailed commit message. > > > > Now applied, thanks. > > > > Would you mind posting the output of "lsusb -v" for this device for > > completeness? > Bus 001 Device 004: ID 17dd:5500 > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 1.00 > bDeviceClass0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x17dd > idProduct 0x5500 > bcdDevice0.00 > iManufacturer 1 Simply Automated Inc. > iProduct2 USB to Serial > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x0029 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 4 Sample HID > bmAttributes 0x80 > (Bus Powered) > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 3 > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > HID Device Descriptor: > bLength 9 > bDescriptorType33 > bcdHID 1.00 > bCountryCode0 Not supported > bNumDescriptors 1 > bDescriptorType34 Report > wDescriptorLength 37 > Report Descriptors: >** UNAVAILABLE ** Thanks for posting this. Don't you need to add this device to the HID driver's ignore list to prevent it from claiming the device (see hid_ignore_list) just like for the Cypress VID? Johan
Re: [PATCH v2] USB: Serial: cypress_M8: Enable Simply Automated UPB PIM
On Mon, Jun 22, 2020 at 11:09:51AM -0600, James Hilliard wrote: > On Mon, Jun 22, 2020 at 2:53 AM Johan Hovold wrote: > > > > On Tue, Jun 16, 2020 at 04:04:03PM -0600, James Hilliard wrote: > > > This is a UPB(Universal Powerline Bus) PIM(Powerline Interface Module) > > > which allows for controlling multiple UPB compatible devices from > > > Linux using the standard serial interface. > > > > > > Based on vendor application source code there are two different models > > > of USB based PIM devices in addition to a number of RS232 based PIM's. > > > > > > The vendor UPB application source contains the following USB ID's: > > > #define USB_PCS_VENDOR_ID 0x04b4 > > > #define USB_PCS_PIM_PRODUCT_ID 0x5500 > > > > > > #define USB_SAI_VENDOR_ID 0x17dd > > > #define USB_SAI_PIM_PRODUCT_ID 0x5500 > > > > > > The first set of ID's correspond to the PIM variant sold by Powerline > > > Control Systems while the second corresponds to the Simply Automated > > > Incorporated PIM. As the product ID for both of these match the default > > > cypress HID->COM RS232 product ID it assumed that they both use an > > > internal variant of this HID->COM RS232 converter hardware. However > > > as the vendor ID for the Simply Automated variant is different we need > > > to also add it to the cypress_M8 driver so that it is properly > > > detected. > > > > > > Signed-off-by: James Hilliard > > > --- > > > Changes v1 -> v2: > > > - Add more detailed commit message. > > > > Now applied, thanks. > > Oh, FYI I think part of the comment got dropped when you amended the > patch > I don't see the defines in the comment here: > https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/commit/?h=usb-linus&id=7527d963dff544b0ddfba4319824c50f2a892aeb > > I think I had to temporarily change my git config with this to make it not > drop > the defines: > git config core.commentchar "*" Thanks for catching that! I added a leading tab to prevent those lines from being discarded. Johan
Re: [PATCH v2 1/3] mm/shuffle: don't move pages between zones and don't read garbage memmaps
On 23.06.20 09:39, David Hildenbrand wrote: >> Hmm.. I thought this is the behavior for early section, while it looks >> current >> code doesn't work like this: >> >>if (section_is_early && memmap) >>free_map_bootmem(memmap); >>else >> depopulate_section_memmap(pfn, nr_pages, altmap); >> >> section_is_early is always "true" for early section, while memmap is not-NULL >> only when sub-section map is empty. >> >> If my understanding is correct, when we remove a sub-section in early >> section, >> the code would call depopulate_section_memmap(), which in turn free related >> memmap. By removing the memmap, the return value from pfn_to_online_page() is >> not a valid one. > > I think you're right, and pfn_valid() would also return true, as it is > an early section. This looks broken. > >> >> Maybe we want to write the code like this: >> >>if (section_is_early) >>if (memmap) >>free_map_bootmem(memmap); >>else >> depopulate_section_memmap(pfn, nr_pages, altmap); >> > > I guess that should be the way to go > > @Dan, I think what Wei proposes here is correct, right? Or how does it > work in the VMEMMAP case with early sections? > Especially, if you would re-hot-add, section_activate() would assume there is a memmap, it must not be removed. @Wei, can you send a patch? -- Thanks, David / dhildenb
Re: [PATCH] media: media-request: Fix crash if memory allocation fails
On Sun, Jun 21, 2020 at 02:30:40PM +0300, Tuomas Tynkkynen wrote:
> Syzbot reports a NULL-ptr deref in the kref_put() call:
>
> BUG: KASAN: null-ptr-deref in media_request_put
> drivers/media/mc/mc-request.c:81 [inline]
> kref_put include/linux/kref.h:64 [inline]
> media_request_put drivers/media/mc/mc-request.c:81 [inline]
> media_request_close+0x4d/0x170 drivers/media/mc/mc-request.c:89
> __fput+0x2ed/0x750 fs/file_table.c:281
> task_work_run+0x147/0x1d0 kernel/task_work.c:123
> tracehook_notify_resume include/linux/tracehook.h:188 [inline]
> exit_to_usermode_loop arch/x86/entry/common.c:165 [inline]
> prepare_exit_to_usermode+0x48e/0x600 arch/x86/entry/common.c:196
>
> What led to this crash was an injected memory allocation failure in
> media_request_alloc():
>
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> should_failslab+0x5/0x20
> kmem_cache_alloc_trace+0x57/0x300
> ? anon_inode_getfile+0xe5/0x170
> media_request_alloc+0x339/0x440
> media_device_request_alloc+0x94/0xc0
> media_device_ioctl+0x1fb/0x330
> ? do_vfs_ioctl+0x6ea/0x1a00
> ? media_ioctl+0x101/0x120
> ? __media_device_usb_init+0x430/0x430
> ? media_poll+0x110/0x110
> __se_sys_ioctl+0xf9/0x160
> do_syscall_64+0xf3/0x1b0
>
> When that allocation fails, filp->private_data is left uninitialized
> which media_request_close() does not expect and crashes.
>
> To avoid this, reorder media_request_alloc() such that
> allocating the struct file happens as the last step thus
> media_request_close() will no longer get called for a partially created
> media request.
>
> Reported-by: syzbot+6bed2d543cf7e48b8...@syzkaller.appspotmail.com
> Cc: sta...@vger.kernel.org
> Signed-off-by: Tuomas Tynkkynen
Thanks a lot!
I'm adding this tag:
Fixes: 10905d70d788 ("media: media-request: implement media requests")
FYI: in the future, to get patches to the stable trees, please do add the
Cc: stable... tag, but not actually send the patch to stable@vger e-mail
address.
--
Kind regards,
Sakari Ailus
arch/x86/purgatory/purgatory.c:76:6: warning: no previous prototype for 'warn'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: dd0d718152e4c65b173070d48ea9dfc06894c3e5
commit: b059f801a937d164e03b33c1848bb3dca67c0b04 x86/purgatory: Use
CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
date: 11 months ago
config: x86_64-randconfig-r015-20200623 (attached as .config)
compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
reproduce (this is a W=1 build):
git checkout b059f801a937d164e03b33c1848bb3dca67c0b04
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> arch/x86/purgatory/purgatory.c:76:6: warning: no previous prototype for
>> 'warn' [-Wmissing-prototypes]
void warn(const char *msg) {}
^
--
In file included from arch/x86/boot/compressed/string.c:11:0:
>> arch/x86/boot/compressed/../string.c:43:5: warning: no previous prototype
>> for 'bcmp' [-Wmissing-prototypes]
int bcmp(const void *s1, const void *s2, size_t len)
^
>> arch/x86/boot/compressed/../string.c:146:6: warning: no previous prototype
>> for 'simple_strtol' [-Wmissing-prototypes]
long simple_strtol(const char *cp, char **endp, unsigned int base)
^
>> arch/x86/boot/compressed/string.c:53:7: warning: no previous prototype for
>> 'memmove' [-Wmissing-prototypes]
void *memmove(void *dest, const void *src, size_t n)
^
vim +/warn +76 arch/x86/purgatory/purgatory.c
4ce97317f41d385 Nick Desaulniers 2019-08-07 71
4ce97317f41d385 Nick Desaulniers 2019-08-07 72 /*
4ce97317f41d385 Nick Desaulniers 2019-08-07 73 * Defined in order to reuse
memcpy() and memset() from
4ce97317f41d385 Nick Desaulniers 2019-08-07 74 *
arch/x86/boot/compressed/string.c
4ce97317f41d385 Nick Desaulniers 2019-08-07 75 */
4ce97317f41d385 Nick Desaulniers 2019-08-07 @76 void warn(const char *msg) {}
:: The code at line 76 was first introduced by commit
:: 4ce97317f41d38584fb93578e922fcd19e535f5b x86/purgatory: Do not use
__builtin_memcpy and __builtin_memset
:: TO: Nick Desaulniers
:: CC: Thomas Gleixner
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] i2c: designware: Fix functionality in !CONFIG_ACPI case
Hi
On 6/23/20 5:51 AM, John Stultz wrote:
On the HiKey board, where CONFIG_ACPI is not set, we started
to see a graphics regression where the adv7511 HDMI bridge driver
wasn't probing. This was due to the i2c bus failing to start up.
I bisected the problem down to commit f9288fcc5c615 ("i2c:
designware: Move ACPI parts into common module") and after
looking at it a bit, I realized that change moved some
initialization into i2c_dw_acpi_adjust_bus_speed(). However,
i2c_dw_acpi_adjust_bus_speed() is only functional if CONFIG_ACPI
is set.
This patch pulls i2c_dw_acpi_adjust_bus_speed() out of the
ifdef CONFIG_ACPI conditional, and gets the board working again.
Cc: Andy Shevchenko
Cc: Jarkko Nikula
Cc: Wolfram Sang
Cc: linux-...@vger.kernel.org
Fixes: f9288fcc5c615 ("i2c: designware: Move ACPI parts into common module")
Signed-off-by: John Stultz
---
drivers/i2c/busses/i2c-designware-common.c | 4 ++--
drivers/i2c/busses/i2c-designware-core.h | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-common.c
b/drivers/i2c/busses/i2c-designware-common.c
index e3a8640db7da..33de185e15f2 100644
--- a/drivers/i2c/busses/i2c-designware-common.c
+++ b/drivers/i2c/busses/i2c-designware-common.c
@@ -286,6 +286,8 @@ int i2c_dw_acpi_configure(struct device *device)
}
EXPORT_SYMBOL_GPL(i2c_dw_acpi_configure);
+#endif /* CONFIG_ACPI */
+
I think the regression is in these lines below that were moved from
probe to i2c_dw_acpi_adjust_bus_speed() and cause that neither
"cloock-frequency" device property or I2C_MAX_FAST_MODE_FREQ affect the
bus speed when CONFIG_ACPI is not set.
+ /*
+* Find bus speed from the "clock-frequency" device property, ACPI
+* or by using fast mode if neither is set.
+*/
+ if (acpi_speed && t->bus_freq_hz)
+ t->bus_freq_hz = min(t->bus_freq_hz, acpi_speed);
+ else if (acpi_speed || t->bus_freq_hz)
+ t->bus_freq_hz = max(t->bus_freq_hz, acpi_speed);
+ else
+ t->bus_freq_hz = I2C_MAX_FAST_MODE_FREQ;
Andy: what you think should the i2c_dw_acpi_adjust_bus_speed() fixed to
return adjusted speed or zero if not found (also for !CONFIG_ACPI) and
move above lines back to probe? It looks more clear to me that way and
should fix the regression I think.
--
Jarkko
Re: [PATCH] trivial: fix kerneldoc comments
On Mon, 22 Jun 2020, Joe Perches wrote:
> On Mon, 2020-06-22 at 21:37 +0200, Julia Lawall wrote:
> > Fix the parameter names in the comment to correspond to those in the
> > function header.
> >
> > Drop comments about return values when there is no return value.
>
> Done by hand or script?
Found by script but done by hand. Unfortuntely, I can't figure even a
hackish way to get Coccinelle to modify comments. I guess I could have
used Coccinelle to print out a patch and then run that, but since the
result has to be checked anyway, I just made the changes by hand.
>
> []
> > diff --git a/arch/mips/cavium-octeon/executive/cvmx-spi.c
> > b/arch/mips/cavium-octeon/executive/cvmx-spi.c
> []
> > @@ -69,9 +69,7 @@ static cvmx_spi_callbacks_t cvmx_spi_callbacks = {
> > /**
> > * Get current SPI4 initialization callbacks
> > *
> > - * @callbacks: Pointer to the callbacks structure.to fill
> > - *
> > - * Returns Pointer to cvmx_spi_callbacks_t structure.
> > + * @callbacks: Pointer to the callbacks structure, to fill.
>
> If scripted, odd comma after structure
Hmm, maybe I interpreted the words slightly differently. t looks like it
would be fine without the comma.
>
> > diff --git a/drivers/crypto/bcm/spu.c b/drivers/crypto/bcm/spu.c
> []
> > @@ -519,7 +519,7 @@ u32 spum_assoc_resp_len(enum spu_cipher_mode
> > cipher_mode,
> > * spu_aead_ivlen() - Calculate the length of the AEAD IV to be included
> > * in a SPU request after the AAD and before the payload.
> > * @cipher_mode: cipher mode
> > - * @iv_ctr_len: initialization vector length in bytes
> > + * @iv_len: initialization vector length in bytes
> > *
> > * In Linux ~4.2 and later, the assoc_data sg includes the IV. So no need
> > * to include the IV as a separate field in the SPU request msg.
> > @@ -917,7 +917,7 @@ u16 spum_cipher_req_init(u8 *spu_hdr, struct
> > spu_cipher_parms *cipher_parms)
> > * setkey() time in spu_cipher_req_init().
> > * @spu_hdr: Start of the request message header (MH field)
> > * @spu_req_hdr_len: Length in bytes of the SPU request header
> > - * @isInbound: 0 encrypt, 1 decrypt
> > + * @is_inbound: 0 encrypt, 1 decrypt
>
> odd alignments
Sorry to have missed these.
> etc...
Are there a lot of other such problems? I did look through the whole
patch several times by hand, but perhaps it is just too big to see
everything.
julia
Re: [PATCH V7 3/7] iio: adc: Add info property under adc_data
On Tue, Jun 23, 2020 at 10:31 AM Jishnu Prakash wrote:
>
> Add info property under adc_data to support adding ADC variants
> which may use different iio_info than the one defined for PMIC5.
>
FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Jishnu Prakash
> ---
> drivers/iio/adc/qcom-spmi-adc5.c | 4 +++-
> drivers/iio/adc/qcom-vadc-common.h | 1 +
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-adc5.c
> b/drivers/iio/adc/qcom-spmi-adc5.c
> index 21fdcde..0fa1d37 100644
> --- a/drivers/iio/adc/qcom-spmi-adc5.c
> +++ b/drivers/iio/adc/qcom-spmi-adc5.c
> @@ -629,6 +629,7 @@ static const struct adc5_data adc5_data_pmic = {
> .full_scale_code_volt = 0x70e4,
> .full_scale_code_cur = 0x2710,
> .adc_chans = adc5_chans_pmic,
> + .info = &adc5_info,
> .decimation = (unsigned int [ADC5_DECIMATION_SAMPLES_MAX])
> {250, 420, 840},
> .hw_settle_1 = (unsigned int [VADC_HW_SETTLE_SAMPLES_MAX])
> @@ -643,6 +644,7 @@ static const struct adc5_data adc5_data_pmic_rev2 = {
> .full_scale_code_volt = 0x4000,
> .full_scale_code_cur = 0x1800,
> .adc_chans = adc5_chans_rev2,
> + .info = &adc5_info,
> .decimation = (unsigned int [ADC5_DECIMATION_SAMPLES_MAX])
> {256, 512, 1024},
> .hw_settle_1 = (unsigned int [VADC_HW_SETTLE_SAMPLES_MAX])
> @@ -777,7 +779,7 @@ static int adc5_probe(struct platform_device *pdev)
> indio_dev->dev.of_node = node;
> indio_dev->name = pdev->name;
> indio_dev->modes = INDIO_DIRECT_MODE;
> - indio_dev->info = &adc5_info;
> + indio_dev->info = adc->data->info;
> indio_dev->channels = adc->iio_chans;
> indio_dev->num_channels = adc->nchannels;
>
> diff --git a/drivers/iio/adc/qcom-vadc-common.h
> b/drivers/iio/adc/qcom-vadc-common.h
> index e074902a..6a7553f 100644
> --- a/drivers/iio/adc/qcom-vadc-common.h
> +++ b/drivers/iio/adc/qcom-vadc-common.h
> @@ -136,6 +136,7 @@ struct adc5_data {
> const u32 full_scale_code_volt;
> const u32 full_scale_code_cur;
> const struct adc5_channels *adc_chans;
> + const struct iio_info *info;
> unsigned int*decimation;
> unsigned int*hw_settle_1;
> unsigned int*hw_settle_2;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement
On Tue, 2020-06-23 at 08:02 +0200, Greg Kroah-Hartman wrote: > On Tue, Jun 23, 2020 at 01:09:08PM +0800, Ian Kent wrote: > > On Mon, 2020-06-22 at 20:03 +0200, Greg Kroah-Hartman wrote: > > > On Mon, Jun 22, 2020 at 01:48:45PM -0400, Tejun Heo wrote: > > > > Hello, Ian. > > > > > > > > On Sun, Jun 21, 2020 at 12:55:33PM +0800, Ian Kent wrote: > > > > > > > They are used for hotplugging and partitioning memory. > > > > > > > The > > > > > > > size of > > > > > > > the > > > > > > > segments (and thus the number of them) is dictated by the > > > > > > > underlying > > > > > > > hardware. > > > > > > > > > > > > This sounds so bad. There gotta be a better interface for > > > > > > that, > > > > > > right? > > > > > > > > > > I'm still struggling a bit to grasp what your getting at but > > > > > ... > > > > > > > > I was more trying to say that the sysfs device interface with > > > > per- > > > > object > > > > directory isn't the right interface for this sort of usage at > > > > all. > > > > Are these > > > > even real hardware pieces which can be plugged in and out? > > > > While > > > > being a > > > > discrete piece of hardware isn't a requirement to be a device > > > > model > > > > device, > > > > the whole thing is designed with such use cases on mind. It > > > > definitely isn't > > > > the right design for representing six digit number of logical > > > > entities. > > > > > > > > It should be obvious that representing each consecutive memory > > > > range with a > > > > separate directory entry is far from an optimal way of > > > > representing > > > > something like this. It's outright silly. > > > > > > I agree. And again, Ian, you are just "kicking the problem down > > > the > > > road" if we accept these patches. Please fix this up properly so > > > that > > > this interface is correctly fixed to not do looney things like > > > this. > > > > Fine, mitigating this problem isn't the end of the story, and you > > don't want to do accept a change to mitigate it because that could > > mean no further discussion on it and no further work toward solving > > it. > > > > But it seems to me a "proper" solution to this will cross a number > > of areas so this isn't just "my" problem and, as you point out, > > it's > > likely to become increasingly problematic over time. > > > > So what are your ideas and recommendations on how to handle hotplug > > memory at this granularity for this much RAM (and larger amounts)? > > First off, this is not my platform, and not my problem, so it's funny > you ask me :) Sorry, but I don't think it's funny at all. It's not "my platform" either, I'm just the poor old sole that took this on because, on the face of it, it's a file system problem as claimed by others that looked at it and promptly washed their hands of it. I don't see how asking for your advice is out of order at all. > > Anyway, as I have said before, my first guesses would be: > - increase the granularity size of the "memory chunks", > reducing > the number of devices you create. Yes, I didn't get that from your initial comments but you've said it a couple of times recently and I do get it now. I'll try and find someone appropriate to consult about that and see where it goes. > - delay creating the devices until way after booting, or do it > on a totally different path/thread/workqueue/whatever to > prevent delay at booting When you first said this it sounded like a ugly workaround to me. But perhaps it isn't (I'm not really convinced it is TBH), so it's probably worth trying to follow up on too. > > And then there's always: > - don't create them at all, only only do so if userspace asks > you to. At first glance the impression I get from this is that it's an even uglier work around than delaying it but it might actually the most sensible way to handle this, as it's been called, silliness. We do have the inode flag S_AUTOMOUNT that will cause the dcache flag DCACHE_NEED_AUTOMOUNT to be set on the dentry and that will cause the dentry op ->d_automount() to be called on access so, from a path walk perspective, the dentries could just appear when needed. The question I'd need to answer is do the kernfs nodes exist so ->d_automount() can discover if the node lookup is valid, and I think the answer might be yes (but we would need to suppress udev notifications for S_AUTOMOUNT nodes). The catch will be that this is "not" mounting per-se, so anything I do would probably be seen as an ugly hack that subverts the VFS automount support. If I could find a way to reconcile that I could probably do this. Al, what say you on this? > > You all have the userspace tools/users for this interface and know it > best to know what will work for them. If you don't, then hey, let's > just delete the whole thing and see who screams :) Please, no joking, I'm finding it hard enough to cope with this disappointment as it is, ;) Ian
[PATCH] riscv: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
AT_VECTOR_SIZE_ARCH should be defined with the maximum number of NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined for RISC-V at all even though ARCH_DLINFO will contain one NEW_AUX_ENT for the VDSO address. Signed-off-by: Zong Li --- arch/riscv/include/uapi/asm/auxvec.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/riscv/include/uapi/asm/auxvec.h b/arch/riscv/include/uapi/asm/auxvec.h index d86cb17bbabe..22e0ae888406 100644 --- a/arch/riscv/include/uapi/asm/auxvec.h +++ b/arch/riscv/include/uapi/asm/auxvec.h @@ -10,4 +10,7 @@ /* vDSO location */ #define AT_SYSINFO_EHDR 33 +/* entries in ARCH_DLINFO */ +#define AT_VECTOR_SIZE_ARCH1 + #endif /* _UAPI_ASM_RISCV_AUXVEC_H */ -- 2.27.0
Re: [PATCH RESEND] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()
On 06/23/2020 12:09 PM, David Miller wrote: Networking changes must be submitted with net...@vger.kernel.org Thanks for your reply, sorry for that. I will resend this patch. Thank you.
Re: [PATCH v3 1/7] pinctrl: qcom: spmi-gpio: Add pm660(l) compatibility
Yes, you did. This was a mistake on my end and I realized it after sending the v3, but I figured there's no point in sending it yet again exclusively for this reason. Hope you don't mind. Regards Konrad
Re: [Resend PATCH net] bridge: uapi: mrp: Fix MRP_PORT_ROLE
The 06/22/2020 16:07, David Miller wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> From: Horatiu Vultur
> Date: Sat, 20 Jun 2020 15:14:03 +0200
>
> > Currently the MRP_PORT_ROLE_NONE has the value 0x2 but this is in conflict
> > with the IEC 62439-2 standard. The standard defines the following port
> > roles: primary (0x0), secondary(0x1), interconnect(0x2).
> > Therefore remove the port role none.
> >
> > Fixes: 4714d13791f831 ("bridge: uapi: mrp: Add mrp attributes.")
> > Signed-off-by: Horatiu Vultur
>
> The code accepts arbitrary 32-bit values for the role in a configuration
> but only PRIMARY and SECONDARY seem to be valid.
>
> There is no validation that the value used makes sense.
>
> In the future if we handle type interconnect, and we add checks, it will
> break any existing applications. Because they can validly pass any
> non-zero valid and the code treats that as SECONDARY currently.
>
> So you really can't just remove NONE, you have to add validation code
> too so we don't run into problem in the future.
Thanks for the explanation. I will add some code that checks
specifically for primary(0x0) and secondary(0x1) values and for any
other value to return -EINVAL.
Then in the future when we handle the type interconnect(0x2), we will
just extend this code to check for this value.
>
> Thanks.
--
/Horatiu
Re: PC speaker
Hello. On Thu, Jun 18, 2020 at 01:49:37PM -0400, R.F. Burns wrote: > Is it possible to write a kernel module which, when loaded, will blow > the PC speaker? 1) where have you been starting from 2011 till 2015? 2) why does the posting date of this letter varies a little bit? 3) why June (but July in 2008)? 4) are you a robot? 5) if you are a robot, what's your setup? 6) if you are not a robot, blink. I'm eagerly waiting for this email each year, but it's a shame you neither reveal any details nor respond to questions. We are intrigued! Please uncover this great LKML mystery. We'd like to know you closer. Thanks. -- Best regards, Oleksandr Natalenko (post-factum) Principal Software Maintenance Engineer
Re: [PATCH V7 5/7] iio: adc: Update return value checks
On Tue, Jun 23, 2020 at 10:31 AM Jishnu Prakash wrote:
>
> Clean up some return value checks to make code more compact.
>
FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Jishnu Prakash
> ---
> drivers/iio/adc/qcom-spmi-adc5.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-adc5.c
> b/drivers/iio/adc/qcom-spmi-adc5.c
> index dcc7599..3022313 100644
> --- a/drivers/iio/adc/qcom-spmi-adc5.c
> +++ b/drivers/iio/adc/qcom-spmi-adc5.c
> @@ -301,7 +301,7 @@ static int adc5_configure(struct adc5_chip *adc,
>
> /* Read registers 0x42 through 0x46 */
> ret = adc5_read(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
> - if (ret < 0)
> + if (ret)
> return ret;
>
> /* Digital param selection */
> @@ -388,7 +388,7 @@ static int adc5_do_conversion(struct adc5_chip *adc,
>
> if (adc->poll_eoc) {
> ret = adc5_poll_wait_eoc(adc);
> - if (ret < 0) {
> + if (ret) {
> pr_err("EOC bit not set\n");
> goto unlock;
> }
> @@ -398,7 +398,7 @@ static int adc5_do_conversion(struct adc5_chip *adc,
> if (!ret) {
> pr_debug("Did not get completion timeout.\n");
> ret = adc5_poll_wait_eoc(adc);
> - if (ret < 0) {
> + if (ret) {
> pr_err("EOC bit not set\n");
> goto unlock;
> }
> @@ -516,8 +516,6 @@ static int adc5_read_raw(struct iio_dev *indio_dev,
> default:
> return -EINVAL;
> }
> -
> - return 0;
> }
>
> static int adc7_read_raw(struct iio_dev *indio_dev,
> @@ -761,7 +759,7 @@ static int adc5_get_dt_channel_data(struct adc5_chip *adc,
>
> ret = adc5_read(adc, ADC5_USR_REVISION1, dig_version,
> sizeof(dig_version));
> - if (ret < 0) {
> + if (ret) {
> dev_err(dev, "Invalid dig version read %d\n", ret);
> return ret;
> }
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
With Best Regards,
Andy Shevchenko
Re: [kbuild-all] Re: ld.lld: warning: drivers/built-in.a(misc/ds1682.o):(.data..compoundliteral) is being placed in '.data..compoundliteral'
On 6/20/20 12:32 AM, Nick Desaulniers wrote: On Fri, Jun 19, 2020 at 6:24 AM Christophe Leroy wrote: Le 18/06/2020 à 03:12, kernel test robot a écrit : tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1b5044021070efa3259f3e9548dc35d1eb6aa844 commit: 74016701fe5f873ae23bf02835407227138d874d powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG I'm really having hard time understanding the link between this commit and the issue reported below. Can Clang people help understand what the problem might be ? For randconfigs, it might be the case that we're not clean in the first place. + Philip to provide more info on how the bisection pinpoints commits? (Is the same randconfig used repeatedly as part of a bisection?) Hi, The commit is not the root cause, bisection stopped at a wrong commit because parent commit failed earlier before the ld.lld error, we're going to optimize the bisect logic to avoid false positive. Best Regards, Rong Chen + Kees, idk if this is the warning from the orphan section placement, if any of those patches have landed? + Fangrui, who might know more about this warning from LLD. Christophe date: 2 weeks ago config: powerpc-randconfig-r032-20200617 (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 487ca07fcc75d52755c9fe2ee05bcb3b6c44) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu git checkout 74016701fe5f873ae23bf02835407227138d874d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>, old ones prefixed by <<): ld.lld: warning: drivers/built-in.a(misc/ds1682.o):(.data..compoundliteral) is being placed in '.data..compoundliteral' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral) is being placed in '.data..compoundliteral' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.29) is being placed in '.data..compoundliteral.29' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.31) is being placed in '.data..compoundliteral.31' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.33) is being placed in '.data..compoundliteral.33' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.bss..compoundliteral.35) is being placed in '.bss..compoundliteral.35' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.37) is being placed in '.data..compoundliteral.37' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.39) is being placed in '.data..compoundliteral.39' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.41) is being placed in '.data..compoundliteral.41' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.43) is being placed in '.data..compoundliteral.43' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.45) is being placed in '.data..compoundliteral.45' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.47) is being placed in '.data..compoundliteral.47' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.49) is being placed in '.data..compoundliteral.49' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.51) is being placed in '.data..compoundliteral.51' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.53) is being placed in '.data..compoundliteral.53' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.55) is being placed in '.data..compoundliteral.55' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.57) is being placed in '.data..compoundliteral.57' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.59) is being placed in '.data..compoundliteral.59' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.61) is being placed in '.data..compoundliteral.61' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.63) is being placed in '.data..compoundliteral.63' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.65) is being placed in '.data..compoundliteral.65' ld.lld: warning: drivers/built-in.a(net/phy/mdio_bus.o):(.data..compoundliteral.67) is being placed in '.data..compoundliteral.67' ld.lld: warning: drivers
[PATCH] Revert "kbuild: Create directory for target DTB"
This reverts commit 77479b38e2f58890eb221a0418357502a5b41cd6.
Since commit 8a78756eb545 ("kbuild: create object directories simpler
and faster"), all directories for 'targets' are created.
'mkdir -p $(dir ${dtc-tmp})' is no longer needed.
Signed-off-by: Masahiro Yamada
---
scripts/Makefile.lib | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 99ac59c59826..94da02a57780 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -298,8 +298,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb FORCE
$(call if_changed,dt_S_dtb)
quiet_cmd_dtc = DTC $@
-cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
- $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
+cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $<
; \
$(DTC) -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \
$(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \
-d $(depfile).dtc.tmp $(dtc-tmp) ; \
--
2.25.1
Re: [PATCH v3 5/7] arm64: dts: qcom: Add support for Sony Xperia XA2/Plus/Ultra (Nile platform)
Thanks for applying them. In case I have some updates to these DTs, (they are being rapidly developed!) could I submit them now, or should I want for the next merge window? I saw that they are already applied to qcom/for-next, so I guess the former? Regards Konrad
