* Re: [PATCH v2 1/2] ASoC: dt-bindings: imx-hdmi: Add binding doc for hdmi machine driver
From: Mark Brown @ 2020-12-08 17:09 UTC (permalink / raw)
To: Shengjiu Wang, timur, festevam, linux-kernel, alsa-devel,
linuxppc-dev, devicetree, perex, robh+dt, nicoleotsuka, Xiubo.Lee,
lgirdwood, tiwai
In-Reply-To: <1607251319-5821-1-git-send-email-shengjiu.wang@nxp.com>
On Sun, 6 Dec 2020 18:41:58 +0800, Shengjiu Wang wrote:
> Imx-hdmi is a new added machine driver for supporting hdmi devices
> on i.MX platforms. There is HDMI IP or external HDMI modules connect
> with SAI or AUD2HTX interface.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: dt-bindings: imx-hdmi: Add binding doc for hdmi machine driver
commit: e344cf5e4871f99495396f78d4401b8ac4c92465
[2/2] ASoC: fsl: Add imx-hdmi machine driver
commit: 6a5f850aa83a1d844d27e3e53ca2f247e55d438b
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 08/13] powerpc: Increase NR_IRQS range to support more KVM guests
From: Greg Kurz @ 2020-12-08 17:23 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev
In-Reply-To: <20201208151124.1329942-9-clg@kaod.org>
On Tue, 8 Dec 2020 16:11:19 +0100
Cédric Le Goater <clg@kaod.org> wrote:
> PowerNV systems can handle up to 4K guests and 1M interrupt numbers
> per chip. Increase the range of allowed interrupts to support a larger
> number of guests.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
Reviewed-by: Greg Kurz <groug@kaod.org>
> arch/powerpc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 5181872f9452..c250fbd430d1 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -66,7 +66,7 @@ config NEED_PER_CPU_PAGE_FIRST_CHUNK
>
> config NR_IRQS
> int "Number of virtual interrupt numbers"
> - range 32 32768
> + range 32 1048576
> default "512"
> help
> This defines the number of virtual interrupt numbers the kernel
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/smp: Parse ibm,thread-groups with multiple properties
From: Gautham R Shenoy @ 2020-12-08 17:25 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Nathan Lynch, Gautham R. Shenoy, Michael Neuling,
Vaidyanathan Srinivasan, Peter Zijlstra, linux-kernel,
Nicholas Piggin, linuxppc-dev, Valentin Schneider
In-Reply-To: <20201207121042.GH528281@linux.vnet.ibm.com>
Hello Srikar,
Thanks for taking a look at the patch.
On Mon, Dec 07, 2020 at 05:40:42PM +0530, Srikar Dronamraju wrote:
> * Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-04 10:18:45]:
>
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> <snipped>
>
> >
> > static int parse_thread_groups(struct device_node *dn,
> > - struct thread_groups *tg,
> > - unsigned int property)
> > + struct thread_groups_list *tglp)
> > {
> > - int i;
> > - u32 thread_group_array[3 + MAX_THREAD_LIST_SIZE];
> > + int i = 0;
> > + u32 *thread_group_array;
> > u32 *thread_list;
> > size_t total_threads;
> > - int ret;
> > + int ret = 0, count;
> > + unsigned int property_idx = 0;
>
> NIT:
> tglx mentions in one of his recent comments to try keep a reverse fir tree
> ordering of variables where possible.
I suppose you mean moving the longer local variable declarations to to
the top and shorter ones to the bottom. Thanks. Will fix this.
>
> >
> > + count = of_property_count_u32_elems(dn, "ibm,thread-groups");
> > + thread_group_array = kcalloc(count, sizeof(u32), GFP_KERNEL);
> > ret = of_property_read_u32_array(dn, "ibm,thread-groups",
> > - thread_group_array, 3);
> > + thread_group_array, count);
> > if (ret)
> > - return ret;
> > -
> > - tg->property = thread_group_array[0];
> > - tg->nr_groups = thread_group_array[1];
> > - tg->threads_per_group = thread_group_array[2];
> > - if (tg->property != property ||
> > - tg->nr_groups < 1 ||
> > - tg->threads_per_group < 1)
> > - return -ENODATA;
> > + goto out_free;
> >
> > - total_threads = tg->nr_groups * tg->threads_per_group;
> > + while (i < count && property_idx < MAX_THREAD_GROUP_PROPERTIES) {
> > + int j;
> > + struct thread_groups *tg = &tglp->property_tgs[property_idx++];
>
> NIT: same as above.
Ok.
>
> >
> > - ret = of_property_read_u32_array(dn, "ibm,thread-groups",
> > - thread_group_array,
> > - 3 + total_threads);
> > - if (ret)
> > - return ret;
> > + tg->property = thread_group_array[i];
> > + tg->nr_groups = thread_group_array[i + 1];
> > + tg->threads_per_group = thread_group_array[i + 2];
> > + total_threads = tg->nr_groups * tg->threads_per_group;
> > +
> > + thread_list = &thread_group_array[i + 3];
> >
> > - thread_list = &thread_group_array[3];
> > + for (j = 0; j < total_threads; j++)
> > + tg->thread_list[j] = thread_list[j];
> > + i = i + 3 + total_threads;
>
> Can't we simply use memcpy instead?
We could. But this one makes it more explicit.
>
> > + }
> >
> > - for (i = 0 ; i < total_threads; i++)
> > - tg->thread_list[i] = thread_list[i];
> > + tglp->nr_properties = property_idx;
> >
> > - return 0;
> > +out_free:
> > + kfree(thread_group_array);
> > + return ret;
> > }
> >
> > /*
> > @@ -805,24 +827,39 @@ static int get_cpu_thread_group_start(int cpu, struct thread_groups *tg)
> > return -1;
> > }
> >
> > -static int init_cpu_l1_cache_map(int cpu)
> > +static int init_cpu_cache_map(int cpu, unsigned int cache_property)
> >
> > {
> > struct device_node *dn = of_get_cpu_node(cpu, NULL);
> > - struct thread_groups tg = {.property = 0,
> > - .nr_groups = 0,
> > - .threads_per_group = 0};
> > + struct thread_groups *tg = NULL;
> > int first_thread = cpu_first_thread_sibling(cpu);
> > int i, cpu_group_start = -1, err = 0;
> > + cpumask_var_t *mask;
> > + struct thread_groups_list *cpu_tgl = &tgl[cpu];
>
> NIT: same as 1st comment.
Sure, will fix this.
>
> >
> > if (!dn)
> > return -ENODATA;
> >
> > - err = parse_thread_groups(dn, &tg, THREAD_GROUP_SHARE_L1);
> > - if (err)
> > - goto out;
> > + if (!(cache_property == THREAD_GROUP_SHARE_L1))
> > + return -EINVAL;
> >
> > - cpu_group_start = get_cpu_thread_group_start(cpu, &tg);
> > + if (!cpu_tgl->nr_properties) {
> > + err = parse_thread_groups(dn, cpu_tgl);
> > + if (err)
> > + goto out;
> > + }
> > +
> > + for (i = 0; i < cpu_tgl->nr_properties; i++) {
> > + if (cpu_tgl->property_tgs[i].property == cache_property) {
> > + tg = &cpu_tgl->property_tgs[i];
> > + break;
> > + }
> > + }
> > +
> > + if (!tg)
> > + return -EINVAL;
> > +
> > + cpu_group_start = get_cpu_thread_group_start(cpu, tg);
>
> This whole hunk should be moved to a new function and called before
> init_cpu_cache_map. It will simplify the logic to great extent.
I suppose you are referring to the part where we select the correct
tg. Yeah, that can move to a different helper.
>
> >
> > if (unlikely(cpu_group_start == -1)) {
> > WARN_ON_ONCE(1);
> > @@ -830,11 +867,12 @@ static int init_cpu_l1_cache_map(int cpu)
> > goto out;
> > }
> >
> > - zalloc_cpumask_var_node(&per_cpu(cpu_l1_cache_map, cpu),
> > - GFP_KERNEL, cpu_to_node(cpu));
> > + mask = &per_cpu(cpu_l1_cache_map, cpu);
> > +
> > + zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
> >
>
> This hunk (and the next hunk) should be moved to next patch.
>
The next patch is only about introducing THREAD_GROUP_SHARE_L2. Hence
I put in any other code in this patch, since it seems to be a logical
place to collate whatever we have in a generic form.
> > for (i = first_thread; i < first_thread + threads_per_core; i++) {
> > - int i_group_start = get_cpu_thread_group_start(i, &tg);
> > + int i_group_start = get_cpu_thread_group_start(i, tg);
> >
> > if (unlikely(i_group_start == -1)) {
> > WARN_ON_ONCE(1);
> > @@ -843,7 +881,7 @@ static int init_cpu_l1_cache_map(int cpu)
> > }
> >
> > if (i_group_start == cpu_group_start)
> > - cpumask_set_cpu(i, per_cpu(cpu_l1_cache_map, cpu));
> > + cpumask_set_cpu(i, *mask);
> > }
> >
> > out:
> > @@ -924,7 +962,7 @@ static int init_big_cores(void)
> > int cpu;
> >
> > for_each_possible_cpu(cpu) {
> > - int err = init_cpu_l1_cache_map(cpu);
> > + int err = init_cpu_cache_map(cpu, THREAD_GROUP_SHARE_L1);
> >
> > if (err)
> > return err;
> > --
> > 1.9.4
> >
>
> --
> Thanks and Regards
> Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH 09/13] powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_SHIFT_BUG
From: Greg Kurz @ 2020-12-08 17:39 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev
In-Reply-To: <20201208151124.1329942-10-clg@kaod.org>
On Tue, 8 Dec 2020 16:11:20 +0100
Cédric Le Goater <clg@kaod.org> wrote:
> This flag was used to support the PHB4 LSIs on P9 DD1 and we have
> stopped supporting this CPU when DD2 came out. See skiboot commit:
>
> https://github.com/open-power/skiboot/commit/0b0d15e3c170
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
Reviewed-by: Greg Kurz <groug@kaod.org>
Just a minor suggestion in case you need to post a v2. See below.
> arch/powerpc/include/asm/opal-api.h | 2 +-
> arch/powerpc/include/asm/xive.h | 2 +-
> arch/powerpc/kvm/book3s_xive_native.c | 3 ---
> arch/powerpc/kvm/book3s_xive_template.c | 3 ---
> arch/powerpc/sysdev/xive/common.c | 8 --------
> arch/powerpc/sysdev/xive/native.c | 2 --
> 6 files changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
> index 1dffa3cb16ba..48ee604ca39a 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -1091,7 +1091,7 @@ enum {
> OPAL_XIVE_IRQ_TRIGGER_PAGE = 0x00000001,
> OPAL_XIVE_IRQ_STORE_EOI = 0x00000002,
> OPAL_XIVE_IRQ_LSI = 0x00000004,
> - OPAL_XIVE_IRQ_SHIFT_BUG = 0x00000008,
> + OPAL_XIVE_IRQ_SHIFT_BUG = 0x00000008, /* P9 DD1.0 workaround */
Maybe you can even comment the entire line so that any future
tentative to use that flag breaks build ?
> OPAL_XIVE_IRQ_MASK_VIA_FW = 0x00000010,
> OPAL_XIVE_IRQ_EOI_VIA_FW = 0x00000020,
> };
> diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
> index d332dd9a18de..ff805885a028 100644
> --- a/arch/powerpc/include/asm/xive.h
> +++ b/arch/powerpc/include/asm/xive.h
> @@ -60,7 +60,7 @@ struct xive_irq_data {
> };
> #define XIVE_IRQ_FLAG_STORE_EOI 0x01
> #define XIVE_IRQ_FLAG_LSI 0x02
> -#define XIVE_IRQ_FLAG_SHIFT_BUG 0x04
> +#define XIVE_IRQ_FLAG_SHIFT_BUG 0x04 /* P9 DD1.0 workaround */
Same here, with an extra cleanup to stop using it when initializing
xive_irq_flags[] in common.c.
> #define XIVE_IRQ_FLAG_MASK_FW 0x08
> #define XIVE_IRQ_FLAG_EOI_FW 0x10
> #define XIVE_IRQ_FLAG_H_INT_ESB 0x20
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index 9b395381179d..170d1d04e1d1 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -37,9 +37,6 @@ static u8 xive_vm_esb_load(struct xive_irq_data *xd, u32 offset)
> * ordering.
> */
>
> - if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
> - offset |= offset << 4;
> -
> val = in_be64(xd->eoi_mmio + offset);
> return (u8)val;
> }
> diff --git a/arch/powerpc/kvm/book3s_xive_template.c b/arch/powerpc/kvm/book3s_xive_template.c
> index 4ad3c0279458..ece36e024a8f 100644
> --- a/arch/powerpc/kvm/book3s_xive_template.c
> +++ b/arch/powerpc/kvm/book3s_xive_template.c
> @@ -61,9 +61,6 @@ static u8 GLUE(X_PFX,esb_load)(struct xive_irq_data *xd, u32 offset)
> if (offset == XIVE_ESB_SET_PQ_10 && xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
> offset |= XIVE_ESB_LD_ST_MO;
>
> - if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
> - offset |= offset << 4;
> -
> val =__x_readq(__x_eoi_page(xd) + offset);
> #ifdef __LITTLE_ENDIAN__
> val >>= 64-8;
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index 411cba12d73b..a9259470bf9f 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -200,10 +200,6 @@ static notrace u8 xive_esb_read(struct xive_irq_data *xd, u32 offset)
> if (offset == XIVE_ESB_SET_PQ_10 && xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
> offset |= XIVE_ESB_LD_ST_MO;
>
> - /* Handle HW errata */
> - if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
> - offset |= offset << 4;
> -
> if ((xd->flags & XIVE_IRQ_FLAG_H_INT_ESB) && xive_ops->esb_rw)
> val = xive_ops->esb_rw(xd->hw_irq, offset, 0, 0);
> else
> @@ -214,10 +210,6 @@ static notrace u8 xive_esb_read(struct xive_irq_data *xd, u32 offset)
>
> static void xive_esb_write(struct xive_irq_data *xd, u32 offset, u64 data)
> {
> - /* Handle HW errata */
> - if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
> - offset |= offset << 4;
> -
> if ((xd->flags & XIVE_IRQ_FLAG_H_INT_ESB) && xive_ops->esb_rw)
> xive_ops->esb_rw(xd->hw_irq, offset, data, 1);
> else
> diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c
> index 5f1e5aed8ab4..0310783241b5 100644
> --- a/arch/powerpc/sysdev/xive/native.c
> +++ b/arch/powerpc/sysdev/xive/native.c
> @@ -64,8 +64,6 @@ int xive_native_populate_irq_data(u32 hw_irq, struct xive_irq_data *data)
> data->flags |= XIVE_IRQ_FLAG_STORE_EOI;
> if (opal_flags & OPAL_XIVE_IRQ_LSI)
> data->flags |= XIVE_IRQ_FLAG_LSI;
> - if (opal_flags & OPAL_XIVE_IRQ_SHIFT_BUG)
> - data->flags |= XIVE_IRQ_FLAG_SHIFT_BUG;
> if (opal_flags & OPAL_XIVE_IRQ_MASK_VIA_FW)
> data->flags |= XIVE_IRQ_FLAG_MASK_FW;
> if (opal_flags & OPAL_XIVE_IRQ_EOI_VIA_FW)
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/smp: Add support detecting thread-groups sharing L2 cache
From: Gautham R Shenoy @ 2020-12-08 17:42 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Nathan Lynch, Gautham R. Shenoy, Michael Neuling,
Vaidyanathan Srinivasan, Peter Zijlstra, linux-kernel,
Nicholas Piggin, linuxppc-dev, Valentin Schneider
In-Reply-To: <20201207124039.GI528281@linux.vnet.ibm.com>
Hello Srikar,
On Mon, Dec 07, 2020 at 06:10:39PM +0530, Srikar Dronamraju wrote:
> * Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-04 10:18:46]:
>
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > On POWER systems, groups of threads within a core sharing the L2-cache
> > can be indicated by the "ibm,thread-groups" property array with the
> > identifier "2".
> >
> > This patch adds support for detecting this, and when present, populate
> > the populating the cpu_l2_cache_mask of every CPU to the core-siblings
> > which share L2 with the CPU as specified in the by the
> > "ibm,thread-groups" property array.
> >
> > On a platform with the following "ibm,thread-group" configuration
> > 00000001 00000002 00000004 00000000
> > 00000002 00000004 00000006 00000001
> > 00000003 00000005 00000007 00000002
> > 00000002 00000004 00000000 00000002
> > 00000004 00000006 00000001 00000003
> > 00000005 00000007
> >
> > Without this patch, the sched-domain hierarchy for CPUs 0,1 would be
> > CPU0 attaching sched-domain(s):
> > domain-0: span=0,2,4,6 level=SMT
> > domain-1: span=0-7 level=CACHE
> > domain-2: span=0-15,24-39,48-55 level=MC
> > domain-3: span=0-55 level=DIE
> >
> > CPU1 attaching sched-domain(s):
> > domain-0: span=1,3,5,7 level=SMT
> > domain-1: span=0-7 level=CACHE
> > domain-2: span=0-15,24-39,48-55 level=MC
> > domain-3: span=0-55 level=DIE
> >
> > The CACHE domain at 0-7 is incorrect since the ibm,thread-groups
> > sub-array
> > [00000002 00000002 00000004
> > 00000000 00000002 00000004 00000006
> > 00000001 00000003 00000005 00000007]
> > indicates that L2 (Property "2") is shared only between the threads of a single
> > group. There are "2" groups of threads where each group contains "4"
> > threads each. The groups being {0,2,4,6} and {1,3,5,7}.
> >
> > With this patch, the sched-domain hierarchy for CPUs 0,1 would be
> > CPU0 attaching sched-domain(s):
> > domain-0: span=0,2,4,6 level=SMT
> > domain-1: span=0-15,24-39,48-55 level=MC
> > domain-2: span=0-55 level=DIE
> >
> > CPU1 attaching sched-domain(s):
> > domain-0: span=1,3,5,7 level=SMT
> > domain-1: span=0-15,24-39,48-55 level=MC
> > domain-2: span=0-55 level=DIE
> >
> > The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
> > resp.) gets degenerated into the SMT domain. Furthermore, the
> > last-level-cache domain gets correctly set to the SMT sched-domain.
> >
> > Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/kernel/smp.c | 66 +++++++++++++++++++++++++++++++++++++++++------
> > 1 file changed, 58 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > index 6a242a3..a116d2d 100644
> > --- a/arch/powerpc/kernel/smp.c
> > +++ b/arch/powerpc/kernel/smp.c
> > @@ -76,6 +76,7 @@
> > struct task_struct *secondary_current;
> > bool has_big_cores;
> > bool coregroup_enabled;
> > +bool thread_group_shares_l2;
>
> Either keep this as static in this patch or add its declaration
>
This will be used in Patch 3 in kernel/cacheinfo.c, but not any other
place. Hence I am not making it static here.
> >
> > DEFINE_PER_CPU(cpumask_var_t, cpu_sibling_map);
> > DEFINE_PER_CPU(cpumask_var_t, cpu_smallcore_map);
> > @@ -99,6 +100,7 @@ enum {
> >
> > #define MAX_THREAD_LIST_SIZE 8
> > #define THREAD_GROUP_SHARE_L1 1
> > +#define THREAD_GROUP_SHARE_L2 2
> > struct thread_groups {
> > unsigned int property;
> > unsigned int nr_groups;
> > @@ -107,7 +109,7 @@ struct thread_groups {
> > };
> >
> > /* Maximum number of properties that groups of threads within a core can share */
> > -#define MAX_THREAD_GROUP_PROPERTIES 1
> > +#define MAX_THREAD_GROUP_PROPERTIES 2
> >
> > struct thread_groups_list {
> > unsigned int nr_properties;
> > @@ -121,6 +123,13 @@ struct thread_groups_list {
> > */
> > DEFINE_PER_CPU(cpumask_var_t, cpu_l1_cache_map);
> >
> > +/*
> > + * On some big-cores system, thread_group_l2_cache_map for each CPU
> > + * corresponds to the set its siblings within the core that share the
> > + * L2-cache.
> > + */
> > +DEFINE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
> > +
>
> NIT:
> We are trying to confuse ourselves with the names.
> For L1 we have cpu_l2_cache_map to store the tasks from the thread group.
> but cpu_smallcore_map for keeping track of tasks.
>
I suppose you mean cpu_l1_cache_map here. We are using
cpu_smallcore_map, because when the ibm,thread-groups-property=1, it
shares both L1 and the instruction data flow (SMT). We already have a
cpu_smt_map, hence, this was named cpu_smallcore_map a couple of years
ago when I wrote that patch.
> For L2 we have thread_group_l2_cache_map to store the tasks from the thread
> group. but cpu_l2_cache_map for keeping track of tasks.
>
> I think we should do some renaming to keep the names consistent.
> I would say probably say move the current cpu_l2_cache_map to
> cpu_llc_cache_map and move the new aka thread_group_l2_cache_map as
> cpu_l2_cache_map to be somewhat consistent.
Hmm.. cpu_llc_cache_map is still very generic. We want to have
something that defines l2 map.
I agree that we need to keep it consistent. How about renaming
cpu_l1_cache_map to thread_groups_l1_cache_map ?
That way thread_groups_l1_cache_map and thread_groups_l2_cache_map
refer to the corresponding L1 and L2 siblings as discovered from
ibm,thread-groups property.
We have the cpu_smallcore_mask and the cpu_l2_cache_map unchanged as
it was before.
>
> > /* SMP operations for this machine */
> > struct smp_ops_t *smp_ops;
> >
> > @@ -840,7 +851,8 @@ static int init_cpu_cache_map(int cpu, unsigned int cache_property)
> > if (!dn)
> > return -ENODATA;
> >
> > - if (!(cache_property == THREAD_GROUP_SHARE_L1))
> > + if (!(cache_property == THREAD_GROUP_SHARE_L1 ||
> > + cache_property == THREAD_GROUP_SHARE_L2))
> > return -EINVAL;
> >
> > if (!cpu_tgl->nr_properties) {
> > @@ -867,7 +879,10 @@ static int init_cpu_cache_map(int cpu, unsigned int cache_property)
> > goto out;
> > }
> >
> > - mask = &per_cpu(cpu_l1_cache_map, cpu);
> > + if (cache_property == THREAD_GROUP_SHARE_L1)
> > + mask = &per_cpu(cpu_l1_cache_map, cpu);
> > + else if (cache_property == THREAD_GROUP_SHARE_L2)
> > + mask = &per_cpu(thread_group_l2_cache_map, cpu);
> >
> > zalloc_cpumask_var_node(mask, GFP_KERNEL, cpu_to_node(cpu));
> >
> > @@ -973,6 +988,16 @@ static int init_big_cores(void)
> > }
> >
> > has_big_cores = true;
> > +
> > + for_each_possible_cpu(cpu) {
> > + int err = init_cpu_cache_map(cpu, THREAD_GROUP_SHARE_L2);
> > +
> > + if (err)
> > + return err;
> > + }
> > +
> > + thread_group_shares_l2 = true;
>
> Why do we need a separate loop. Why cant we merge this in the above loop
> itself?
No, there are platforms where one THREAD_GROUP_SHARE_L1 exists while
THREAD_GROUP_SHARE_L2 doesn't exist. It becomes easier if these are
separately tracked. Also, what do we gain if we put this in the same
loop? It will be (nr_possible_cpus * 2 * invocations of
init_cpu_cache_map()) as opposed to 2 * (nr_possible_cpus *
invocations of init_cpu_cache_map()). Isn't it ?
>
> > + pr_info("Thread-groups in a core share L2-cache\n");
>
> Can this be moved to a pr_debug? Does it help any regular user/admins to
> know if thread-groups shared l2 cache. Infact it may confuse users on what
> thread groups are and which thread groups dont share cache.
> I would prefer some other name than thread_group_shares_l2 but dont know any
> better alternatives and may be my choices are even worse.
Would you be ok with "L2 cache shared by threads of the small core" ?
>
> > return 0;
> > }
> >
> > @@ -1287,6 +1312,31 @@ static bool update_mask_by_l2(int cpu, cpumask_var_t *mask)
> > if (has_big_cores)
> > submask_fn = cpu_smallcore_mask;
> >
> > +
>
> NIT: extra blank line?
Will remove this.
>
> > + /*
> > + * If the threads in a thread-group share L2 cache, then then
> > + * the L2-mask can be obtained from thread_group_l2_cache_map.
> > + */
> > + if (thread_group_shares_l2) {
> > + /* Siblings that share L1 is a subset of siblings that share L2.*/
> > + or_cpumasks_related(cpu, cpu, submask_fn, cpu_l2_cache_mask);
> > + if (*mask) {
> > + cpumask_andnot(*mask,
> > + per_cpu(thread_group_l2_cache_map, cpu),
> > + cpu_l2_cache_mask(cpu));
> > + } else {
> > + mask = &per_cpu(thread_group_l2_cache_map, cpu);
> > + }
> > +
> > + for_each_cpu(i, *mask) {
> > + if (!cpu_online(i))
> > + continue;
> > + set_cpus_related(i, cpu, cpu_l2_cache_mask);
> > + }
> > +
> > + return true;
> > + }
> > +
>
> Ah this can be simplified to:
> if (thread_group_shares_l2) {
> cpumask_set_cpu(cpu, cpu_l2_cache_mask(cpu));
>
> for_each_cpu(i, per_cpu(thread_group_l2_cache_map, cpu)) {
> if (cpu_online(i))
> set_cpus_related(i, cpu, cpu_l2_cache_mask);
> }
Don't we want to enforce that the siblings sharing L1 be a subset of
the siblings sharing L2 ? Or do you recommend putting in a check for
that somewhere ?
> }
>
> No?
>
> > l2_cache = cpu_to_l2cache(cpu);
> > if (!l2_cache || !*mask) {
> > /* Assume only core siblings share cache with this CPU */
>
> --
> Thanks and Regards
> Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
From: Gautham R Shenoy @ 2020-12-08 17:56 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Nathan Lynch, Gautham R. Shenoy, Michael Neuling,
Vaidyanathan Srinivasan, Peter Zijlstra, linux-kernel,
Nicholas Piggin, linuxppc-dev, Valentin Schneider
In-Reply-To: <20201207131138.GJ528281@linux.vnet.ibm.com>
On Mon, Dec 07, 2020 at 06:41:38PM +0530, Srikar Dronamraju wrote:
> * Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-04 10:18:47]:
>
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> >
> > Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> > ---
> >
> > +extern bool thread_group_shares_l2;
> > /*
> > * On big-core systems, each core has two groups of CPUs each of which
> > * has its own L1-cache. The thread-siblings which share l1-cache with
> > * @cpu can be obtained via cpu_smallcore_mask().
> > + *
> > + * On some big-core systems, the L2 cache is shared only between some
> > + * groups of siblings. This is already parsed and encoded in
> > + * cpu_l2_cache_mask().
> > */
> > static const struct cpumask *get_big_core_shared_cpu_map(int cpu, struct cache *cache)
> > {
> > if (cache->level == 1)
> > return cpu_smallcore_mask(cpu);
> > + if (cache->level == 2 && thread_group_shares_l2)
> > + return cpu_l2_cache_mask(cpu);
> >
> > return &cache->shared_cpu_map;
>
> As pointed with lkp@intel.org, we need to do this only with #CONFIG_SMP,
> even for cache->level = 1 too.
Yes, I have fixed that in the next version.
>
> I agree that we are displaying shared_cpu_map correctly. Should we have also
> update /clear shared_cpu_map in the first place. For example:- If for a P9
> core with CPUs 0-7, the cache->shared_cpu_map for L1 would have 0-7 but
> would display 0,2,4,6.
>
> The drawback of this is even if cpus 0,2,4,6 are released L1 cache will not
> be released. Is this as expected?
cacheinfo populates the cache->shared_cpu_map on the basis of which
CPUs share the common device-tree node for a particular cache. There
is one l1-cache object in the device-tree for a CPU node corresponding
to a big-core. That the L1 is further split between the threads of the
core is shown using ibm,thread-groups.
The ideal thing would be to add a "group_leader" field to "struct
cache" so that we can create separate cache objects , one per thread
group. I will take a stab at this in the v2.
Thanks for the review comments.
>
>
> --
> Thanks and Regards
> Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/rtas: Restrict RTAS requests from userspace
From: Tyrel Datwyler @ 2020-12-08 18:59 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev; +Cc: nathanl, leobras.c, stable, dja
In-Reply-To: <20200820044512.7543-1-ajd@linux.ibm.com>
On 8/19/20 9:45 PM, Andrew Donnellan wrote:
> A number of userspace utilities depend on making calls to RTAS to retrieve
> information and update various things.
>
> The existing API through which we expose RTAS to userspace exposes more
> RTAS functionality than we actually need, through the sys_rtas syscall,
> which allows root (or anyone with CAP_SYS_ADMIN) to make any RTAS call they
> want with arbitrary arguments.
>
> Many RTAS calls take the address of a buffer as an argument, and it's up to
> the caller to specify the physical address of the buffer as an argument. We
> allocate a buffer (the "RMO buffer") in the Real Memory Area that RTAS can
> access, and then expose the physical address and size of this buffer in
> /proc/powerpc/rtas/rmo_buffer. Userspace is expected to read this address,
> poke at the buffer using /dev/mem, and pass an address in the RMO buffer to
> the RTAS call.
>
> However, there's nothing stopping the caller from specifying whatever
> address they want in the RTAS call, and it's easy to construct a series of
> RTAS calls that can overwrite arbitrary bytes (even without /dev/mem
> access).
>
> Additionally, there are some RTAS calls that do potentially dangerous
> things and for which there are no legitimate userspace use cases.
>
> In the past, this would not have been a particularly big deal as it was
> assumed that root could modify all system state freely, but with Secure
> Boot and lockdown we need to care about this.
>
> We can't fundamentally change the ABI at this point, however we can address
> this by implementing a filter that checks RTAS calls against a list
> of permitted calls and forces the caller to use addresses within the RMO
> buffer.
>
> The list is based off the list of calls that are used by the librtas
> userspace library, and has been tested with a number of existing userspace
> RTAS utilities. For compatibility with any applications we are not aware of
> that require other calls, the filter can be turned off at build time.
>
> Reported-by: Daniel Axtens <dja@axtens.net>
> Cc: stable@vger.kernel.org
> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
>
> ---
> v1->v2:
> - address comments from mpe
> - shorten the names of some struct members
> - make the filter array static/ro_after_init, use const char *
> - genericise the fixed buffer size cases
> - simplify/get rid of some of the error printing
> - get rid of rtas_token_name()
> ---
> arch/powerpc/Kconfig | 13 ++++
> arch/powerpc/kernel/rtas.c | 153 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 166 insertions(+)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1f48bbfb3ce9..8dd42b82379b 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -989,6 +989,19 @@ config PPC_SECVAR_SYSFS
> read/write operations on these variables. Say Y if you have
> secure boot enabled and want to expose variables to userspace.
>
> +config PPC_RTAS_FILTER
> + bool "Enable filtering of RTAS syscalls"
> + default y
> + depends on PPC_RTAS
> + help
> + The RTAS syscall API has security issues that could be used to
> + compromise system integrity. This option enforces restrictions on the
> + RTAS calls and arguments passed by userspace programs to mitigate
> + these issues.
> +
> + Say Y unless you know what you are doing and the filter is causing
> + problems for you.
> +
> endmenu
>
> config ISA_DMA_API
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index 806d554ce357..954f41676f69 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -992,6 +992,147 @@ struct pseries_errorlog *get_pseries_errorlog(struct rtas_error_log *log,
> return NULL;
> }
>
> +#ifdef CONFIG_PPC_RTAS_FILTER
> +
> +/*
> + * The sys_rtas syscall, as originally designed, allows root to pass
> + * arbitrary physical addresses to RTAS calls. A number of RTAS calls
> + * can be abused to write to arbitrary memory and do other things that
> + * are potentially harmful to system integrity, and thus should only
> + * be used inside the kernel and not exposed to userspace.
> + *
> + * All known legitimate users of the sys_rtas syscall will only ever
> + * pass addresses that fall within the RMO buffer, and use a known
> + * subset of RTAS calls.
> + *
> + * Accordingly, we filter RTAS requests to check that the call is
> + * permitted, and that provided pointers fall within the RMO buffer.
> + * The rtas_filters list contains an entry for each permitted call,
> + * with the indexes of the parameters which are expected to contain
> + * addresses and sizes of buffers allocated inside the RMO buffer.
> + */
> +struct rtas_filter {
> + const char *name;
> + int token;
> + /* Indexes into the args buffer, -1 if not used */
> + int buf_idx1;
> + int size_idx1;
> + int buf_idx2;
> + int size_idx2;
> +
> + int fixed_size;
> +};
> +
> +static struct rtas_filter rtas_filters[] __ro_after_init = {
> + { "ibm,activate-firmware", -1, -1, -1, -1, -1 },
> + { "ibm,configure-connector", -1, 0, -1, 1, -1, 4096 }, /* Special cased */
> + { "display-character", -1, -1, -1, -1, -1 },
> + { "ibm,display-message", -1, 0, -1, -1, -1 },
> + { "ibm,errinjct", -1, 2, -1, -1, -1, 1024 },
> + { "ibm,close-errinjct", -1, -1, -1, -1, -1 },
> + { "ibm,open-errinct", -1, -1, -1, -1, -1 },
There is a typo here. Should be ibm,open-errinjct.
kernel: [ 1100.408626] sys_rtas: RTAS call blocked - exploit attempt?
kernel: [ 1100.408631] sys_rtas: token=0x26, nargs=0 (called by errinjct)
Which is producing this when trying to invoke the errinjct tool.
I'll send a fixes patch out shortly.
-Tyrel
> + { "ibm,get-config-addr-info2", -1, -1, -1, -1, -1 },
> + { "ibm,get-dynamic-sensor-state", -1, 1, -1, -1, -1 },
> + { "ibm,get-indices", -1, 2, 3, -1, -1 },
> + { "get-power-level", -1, -1, -1, -1, -1 },
> + { "get-sensor-state", -1, -1, -1, -1, -1 },
> + { "ibm,get-system-parameter", -1, 1, 2, -1, -1 },
> + { "get-time-of-day", -1, -1, -1, -1, -1 },
> + { "ibm,get-vpd", -1, 0, -1, 1, 2 },
> + { "ibm,lpar-perftools", -1, 2, 3, -1, -1 },
> + { "ibm,platform-dump", -1, 4, 5, -1, -1 },
> + { "ibm,read-slot-reset-state", -1, -1, -1, -1, -1 },
> + { "ibm,scan-log-dump", -1, 0, 1, -1, -1 },
> + { "ibm,set-dynamic-indicator", -1, 2, -1, -1, -1 },
> + { "ibm,set-eeh-option", -1, -1, -1, -1, -1 },
> + { "set-indicator", -1, -1, -1, -1, -1 },
> + { "set-power-level", -1, -1, -1, -1, -1 },
> + { "set-time-for-power-on", -1, -1, -1, -1, -1 },
> + { "ibm,set-system-parameter", -1, 1, -1, -1, -1 },
> + { "set-time-of-day", -1, -1, -1, -1, -1 },
> + { "ibm,suspend-me", -1, -1, -1, -1, -1 },
> + { "ibm,update-nodes", -1, 0, -1, -1, -1, 4096 },
> + { "ibm,update-properties", -1, 0, -1, -1, -1, 4096 },
> + { "ibm,physical-attestation", -1, 0, 1, -1, -1 },
> +};
> +
> +static bool in_rmo_buf(u32 base, u32 end)
> +{
> + return base >= rtas_rmo_buf &&
> + base < (rtas_rmo_buf + RTAS_RMOBUF_MAX) &&
> + base <= end &&
> + end >= rtas_rmo_buf &&
> + end < (rtas_rmo_buf + RTAS_RMOBUF_MAX);
> +}
> +
> +static bool block_rtas_call(int token, int nargs,
> + struct rtas_args *args)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rtas_filters); i++) {
> + struct rtas_filter *f = &rtas_filters[i];
> + u32 base, size, end;
> +
> + if (token != f->token)
> + continue;
> +
> + if (f->buf_idx1 != -1) {
> + base = be32_to_cpu(args->args[f->buf_idx1]);
> + if (f->size_idx1 != -1)
> + size = be32_to_cpu(args->args[f->size_idx1]);
> + else if (f->fixed_size)
> + size = f->fixed_size;
> + else
> + size = 1;
> +
> + end = base + size - 1;
> + if (!in_rmo_buf(base, end))
> + goto err;
> + }
> +
> + if (f->buf_idx2 != -1) {
> + base = be32_to_cpu(args->args[f->buf_idx2]);
> + if (f->size_idx2 != -1)
> + size = be32_to_cpu(args->args[f->size_idx2]);
> + else if (f->fixed_size)
> + size = f->fixed_size;
> + else
> + size = 1;
> + end = base + size - 1;
> +
> + /*
> + * Special case for ibm,configure-connector where the
> + * address can be 0
> + */
> + if (!strcmp(f->name, "ibm,configure-connector") &&
> + base == 0)
> + return false;
> +
> + if (!in_rmo_buf(base, end))
> + goto err;
> + }
> +
> + return false;
> + }
> +
> +err:
> + pr_err_ratelimited("sys_rtas: RTAS call blocked - exploit attempt?\n");
> + pr_err_ratelimited("sys_rtas: token=0x%x, nargs=%d (called by %s)\n",
> + token, nargs, current->comm);
> + return true;
> +}
> +
> +#else
> +
> +static bool block_rtas_call(int token, int nargs,
> + struct rtas_args *args)
> +{
> + return false;
> +}
> +
> +#endif /* CONFIG_PPC_RTAS_FILTER */
> +
> /* We assume to be passed big endian arguments */
> SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
> {
> @@ -1029,6 +1170,9 @@ SYSCALL_DEFINE1(rtas, struct rtas_args __user *, uargs)
> args.rets = &args.args[nargs];
> memset(args.rets, 0, nret * sizeof(rtas_arg_t));
>
> + if (block_rtas_call(token, nargs, &args))
> + return -EINVAL;
> +
> /* Need to handle ibm,suspend_me call specially */
> if (token == ibm_suspend_me_token) {
>
> @@ -1090,6 +1234,9 @@ void __init rtas_initialize(void)
> unsigned long rtas_region = RTAS_INSTANTIATE_MAX;
> u32 base, size, entry;
> int no_base, no_size, no_entry;
> +#ifdef CONFIG_PPC_RTAS_FILTER
> + int i;
> +#endif
>
> /* Get RTAS dev node and fill up our "rtas" structure with infos
> * about it.
> @@ -1129,6 +1276,12 @@ void __init rtas_initialize(void)
> #ifdef CONFIG_RTAS_ERROR_LOGGING
> rtas_last_error_token = rtas_token("rtas-last-error");
> #endif
> +
> +#ifdef CONFIG_PPC_RTAS_FILTER
> + for (i = 0; i < ARRAY_SIZE(rtas_filters); i++) {
> + rtas_filters[i].token = rtas_token(rtas_filters[i].name);
> + }
> +#endif
> }
>
> int __init early_init_dt_scan_rtas(unsigned long node,
>
^ permalink raw reply
* Re: [PATCH 02/20] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram
From: Li Yang @ 2020-12-08 19:14 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Vladimir Oltean, lkml, Netdev, Jakub Kicinski, linuxppc-dev,
David S. Miller, Zhao Qiang
In-Reply-To: <20201205191744.7847-3-rasmus.villemoes@prevas.dk>
On Sat, Dec 5, 2020 at 1:21 PM Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> Table 8-53 in the QUICC Engine Reference manual shows definitions of
> fields up to a size of 192 bytes, not just 128. But in table 8-111,
> one does find the text
>
> Base Address of the Global Transmitter Parameter RAM Page. [...]
> The user needs to allocate 128 bytes for this page. The address must
> be aligned to the page size.
>
> I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
> they both have this inconsistency (and the table numbers are the
> same).
This does seem to be an inconsistency. I will try to see if I can
find someone who is familiar with this as this is really an old IP.
Figure 8-61 does mention that size = 128 byte + 64 byte if .... But
this part is not clear also. Not sure if the size of the parameter
RAM is really conditional.
>
> Adding a bit of debug printing, on my board the struct
> ucc_geth_tx_global_pram is allocated at offset 0x880, while
> the (opaque) ucc_geth_thread_data_tx gets allocated immediately
> afterwards, at 0x900. So whatever the engine writes into the thread
> data overlaps with the tail of the global tx pram (and devmem says
> that something does get written during a simple ping).
The overlapping does seem to be a problem. Maybe these global
parameters are not sampled at runtime or the parameter RAM is really
only using 128byte depending on the operation mode.
Are you getting useful information by reading from the additional 64
bytes, or getting changed behavior for setting these bytes after your
changes?
>
> I haven't observed any failure that could be attributed to this, but
> it seems to be the kind of thing that would be extremely hard to
> debug. So extend the struct definition so that we do allocate 192
> bytes.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> drivers/net/ethernet/freescale/ucc_geth.h | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
> index 3fe903972195..c80bed2c995c 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.h
> +++ b/drivers/net/ethernet/freescale/ucc_geth.h
> @@ -575,7 +575,14 @@ struct ucc_geth_tx_global_pram {
> u32 vtagtable[0x8]; /* 8 4-byte VLAN tags */
> u32 tqptr; /* a base pointer to the Tx Queues Memory
> Region */
> - u8 res2[0x80 - 0x74];
> + u8 res2[0x78 - 0x74];
> + u64 snums_en;
> + u32 l2l3baseptr; /* top byte consists of a few other bit fields */
> +
> + u16 mtu[8];
> + u8 res3[0xa8 - 0x94];
> + u32 wrrtablebase; /* top byte is reserved */
> + u8 res4[0xc0 - 0xac];
> } __packed;
>
> /* structure representing Extended Filtering Global Parameters in PRAM */
> --
> 2.23.0
>
^ permalink raw reply
* Re: [PATCH] drivers: usb: gadget: prefer pr_*() functions over raw printk()
From: Laurent Pinchart @ 2020-12-08 15:54 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: balbi, linux-usb, linuxppc-dev, linux-kernel, leoyang.li
In-Reply-To: <20201208144403.22097-1-info@metux.net>
Hi Enrico,
Thank you for the patch.
On Tue, Dec 08, 2020 at 03:44:03PM +0100, Enrico Weigelt, metux IT consult wrote:
> Reduce a bit logging boilerplate by using the preferred pr_*()
> macros instead of raw printk().
>
> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ---
> drivers/usb/gadget/function/uvc.h | 2 +-
> drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
> drivers/usb/gadget/udc/fsl_udc_core.c | 4 +--
> drivers/usb/gadget/udc/fsl_usb2_udc.h | 4 +--
> drivers/usb/gadget/udc/fusb300_udc.c | 64 ++++++++++++++++-----------------
> drivers/usb/gadget/udc/goku_udc.c | 2 +-
> drivers/usb/gadget/udc/r8a66597-udc.h | 2 +-
> 7 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/uvc.h b/drivers/usb/gadget/function/uvc.h
> index 23ee25383c1f..d546eb7c348c 100644
> --- a/drivers/usb/gadget/function/uvc.h
> +++ b/drivers/usb/gadget/function/uvc.h
> @@ -49,7 +49,7 @@ extern unsigned int uvc_gadget_trace_param;
> #define uvc_trace(flag, msg...) \
> do { \
> if (uvc_gadget_trace_param & flag) \
> - printk(KERN_DEBUG "uvcvideo: " msg); \
> + pr_debug("uvcvideo: " msg); \
> } while (0)
>
> #define uvcg_dbg(f, fmt, args...) \
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 2b893bceea45..4834fafb3f70 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1573,7 +1573,7 @@ static void usba_control_irq(struct usba_udc *udc, struct usba_ep *ep)
> * generate or receive a reply right away. */
> usba_ep_writel(ep, CLR_STA, USBA_RX_SETUP);
>
> - /* printk(KERN_DEBUG "setup: %d: %02x.%02x\n",
> + /* pr_debug("setup: %d: %02x.%02x\n",
> ep->state, crq.crq.bRequestType,
> crq.crq.bRequest); */
I wonder if this shouldn't be dropped instead, commented-out code isn't
very useful.
>
> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
> index ad6ff9c4188e..cab4def04f9f 100644
> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -1474,7 +1474,7 @@ __acquires(udc->lock)
> mdelay(10);
> tmp = fsl_readl(&dr_regs->portsc1) | (ptc << 16);
> fsl_writel(tmp, &dr_regs->portsc1);
> - printk(KERN_INFO "udc: switch to test mode %d.\n", ptc);
> + pr_info("udc: switch to test mode %d.\n", ptc);
> }
>
> return;
> @@ -1952,7 +1952,7 @@ static int fsl_udc_start(struct usb_gadget *g,
> if (!IS_ERR_OR_NULL(udc_controller->transceiver)) {
> /* Suspend the controller until OTG enable it */
> udc_controller->stopped = 1;
> - printk(KERN_INFO "Suspend udc for OTG auto detect\n");
> + pr_info("Suspend udc for OTG auto detect\n");
>
> /* connect to bus through transceiver */
> if (!IS_ERR_OR_NULL(udc_controller->transceiver)) {
> diff --git a/drivers/usb/gadget/udc/fsl_usb2_udc.h b/drivers/usb/gadget/udc/fsl_usb2_udc.h
> index 4ba651ae9048..b180bf14dd0c 100644
> --- a/drivers/usb/gadget/udc/fsl_usb2_udc.h
> +++ b/drivers/usb/gadget/udc/fsl_usb2_udc.h
> @@ -509,7 +509,7 @@ struct fsl_udc {
> /*-------------------------------------------------------------------------*/
>
> #ifdef DEBUG
> -#define DBG(fmt, args...) printk(KERN_DEBUG "[%s] " fmt "\n", \
> +#define DBG(fmt, args...) pr_debug("[%s] " fmt "\n", \
> __func__, ## args)
> #else
> #define DBG(fmt, args...) do{}while(0)
> @@ -535,7 +535,7 @@ static void dump_msg(const char *label, const u8 * buf, unsigned int length)
> p += 3;
> }
> *p = 0;
> - printk(KERN_DEBUG "%6x: %s\n", start, line);
> + pr_debug("%6x: %s\n", start, line);
> buf += num;
> start += num;
> length -= num;
> diff --git a/drivers/usb/gadget/udc/fusb300_udc.c b/drivers/usb/gadget/udc/fusb300_udc.c
> index 9af8b415f303..c4e7e4b8e46f 100644
> --- a/drivers/usb/gadget/udc/fusb300_udc.c
> +++ b/drivers/usb/gadget/udc/fusb300_udc.c
> @@ -352,24 +352,24 @@ static void fusb300_wrcxf(struct fusb300_ep *ep,
> for (i = length >> 2; i > 0; i--) {
> data = *tmp | *(tmp + 1) << 8 | *(tmp + 2) << 16 |
> *(tmp + 3) << 24;
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> iowrite32(data, fusb300->reg + FUSB300_OFFSET_CXPORT);
> tmp = tmp + 4;
> }
> switch (length % 4) {
> case 1:
> data = *tmp;
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> iowrite32(data, fusb300->reg + FUSB300_OFFSET_CXPORT);
> break;
> case 2:
> data = *tmp | *(tmp + 1) << 8;
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> iowrite32(data, fusb300->reg + FUSB300_OFFSET_CXPORT);
> break;
> case 3:
> data = *tmp | *(tmp + 1) << 8 | *(tmp + 2) << 16;
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> iowrite32(data, fusb300->reg + FUSB300_OFFSET_CXPORT);
> break;
> default:
> @@ -390,7 +390,7 @@ static void fusb300_clear_epnstall(struct fusb300 *fusb300, u8 ep)
> u32 reg = ioread32(fusb300->reg + FUSB300_OFFSET_EPSET0(ep));
>
> if (reg & FUSB300_EPSET0_STL) {
> - printk(KERN_DEBUG "EP%d stall... Clear!!\n", ep);
> + pr_debug("EP%d stall... Clear!!\n", ep);
> reg |= FUSB300_EPSET0_STL_CLR;
> iowrite32(reg, fusb300->reg + FUSB300_OFFSET_EPSET0(ep));
> }
> @@ -402,7 +402,7 @@ static void ep0_queue(struct fusb300_ep *ep, struct fusb300_request *req)
> if (req->req.length) {
> fusb300_wrcxf(ep, req);
> } else
> - printk(KERN_DEBUG "%s : req->req.length = 0x%x\n",
> + pr_debug("%s : req->req.length = 0x%x\n",
> __func__, req->req.length);
> if ((req->req.length == req->req.actual) ||
> (req->req.actual < ep->ep.maxpacket))
> @@ -565,7 +565,7 @@ static void fusb300_rdcxf(struct fusb300 *fusb300,
>
> for (i = (length >> 2); i > 0; i--) {
> data = ioread32(fusb300->reg + FUSB300_OFFSET_CXPORT);
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> *tmp = data & 0xFF;
> *(tmp + 1) = (data >> 8) & 0xFF;
> *(tmp + 2) = (data >> 16) & 0xFF;
> @@ -576,18 +576,18 @@ static void fusb300_rdcxf(struct fusb300 *fusb300,
> switch (length % 4) {
> case 1:
> data = ioread32(fusb300->reg + FUSB300_OFFSET_CXPORT);
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> *tmp = data & 0xFF;
> break;
> case 2:
> data = ioread32(fusb300->reg + FUSB300_OFFSET_CXPORT);
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> *tmp = data & 0xFF;
> *(tmp + 1) = (data >> 8) & 0xFF;
> break;
> case 3:
> data = ioread32(fusb300->reg + FUSB300_OFFSET_CXPORT);
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> *tmp = data & 0xFF;
> *(tmp + 1) = (data >> 8) & 0xFF;
> *(tmp + 2) = (data >> 16) & 0xFF;
> @@ -610,7 +610,7 @@ static void fusb300_rdfifo(struct fusb300_ep *ep,
> req->req.actual += length;
>
> if (req->req.actual > req->req.length)
> - printk(KERN_DEBUG "req->req.actual > req->req.length\n");
> + pr_debug("req->req.actual > req->req.length\n");
>
> for (i = (length >> 2); i > 0; i--) {
> data = ioread32(fusb300->reg +
> @@ -649,7 +649,7 @@ static void fusb300_rdfifo(struct fusb300_ep *ep,
> reg = ioread32(fusb300->reg + FUSB300_OFFSET_IGR1);
> reg &= FUSB300_IGR1_SYNF0_EMPTY_INT;
> if (i)
> - printk(KERN_INFO "sync fifo is not empty!\n");
> + pr_info("sync fifo is not empty!\n");
> i++;
> } while (!reg);
> }
> @@ -677,7 +677,7 @@ static u8 fusb300_get_cxstall(struct fusb300 *fusb300)
> static void request_error(struct fusb300 *fusb300)
> {
> fusb300_set_cxstall(fusb300);
> - printk(KERN_DEBUG "request error!!\n");
> + pr_debug("request error!!\n");
> }
>
> static void get_status(struct fusb300 *fusb300, struct usb_ctrlrequest *ctrl)
> @@ -999,7 +999,7 @@ static void check_device_mode(struct fusb300 *fusb300)
> fusb300->gadget.speed = USB_SPEED_UNKNOWN;
> break;
> }
> - printk(KERN_INFO "dev_mode = %d\n", (reg & FUSB300_GCR_DEVEN_MSK));
> + pr_info("dev_mode = %d\n", (reg & FUSB300_GCR_DEVEN_MSK));
> }
>
>
> @@ -1076,14 +1076,14 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> if (int_grp1 & FUSB300_IGR1_WARM_RST_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_WARM_RST_INT);
> - printk(KERN_INFO"fusb300_warmreset\n");
> + pr_info("fusb300_warmreset\n");
> fusb300_reset();
> }
>
> if (int_grp1 & FUSB300_IGR1_HOT_RST_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_HOT_RST_INT);
> - printk(KERN_INFO"fusb300_hotreset\n");
> + pr_info("fusb300_hotreset\n");
> fusb300_reset();
> }
>
> @@ -1097,13 +1097,13 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> if (int_grp1 & FUSB300_IGR1_CX_COMABT_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_CX_COMABT_INT);
> - printk(KERN_INFO"fusb300_ep0abt\n");
> + pr_info("fusb300_ep0abt\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_VBUS_CHG_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_VBUS_CHG_INT);
> - printk(KERN_INFO"fusb300_vbus_change\n");
> + pr_info("fusb300_vbus_change\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U3_EXIT_FAIL_INT) {
> @@ -1134,25 +1134,25 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> if (int_grp1 & FUSB300_IGR1_U3_EXIT_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U3_EXIT_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U3_EXIT_INT\n");
> + pr_info("FUSB300_IGR1_U3_EXIT_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U2_EXIT_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U2_EXIT_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U2_EXIT_INT\n");
> + pr_info("FUSB300_IGR1_U2_EXIT_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U1_EXIT_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U1_EXIT_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U1_EXIT_INT\n");
> + pr_info("FUSB300_IGR1_U1_EXIT_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U3_ENTRY_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U3_ENTRY_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U3_ENTRY_INT\n");
> + pr_info("FUSB300_IGR1_U3_ENTRY_INT\n");
> fusb300_enable_bit(fusb300, FUSB300_OFFSET_SSCR1,
> FUSB300_SSCR1_GO_U3_DONE);
> }
> @@ -1160,31 +1160,31 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> if (int_grp1 & FUSB300_IGR1_U2_ENTRY_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U2_ENTRY_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U2_ENTRY_INT\n");
> + pr_info("FUSB300_IGR1_U2_ENTRY_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U1_ENTRY_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U1_ENTRY_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U1_ENTRY_INT\n");
> + pr_info("FUSB300_IGR1_U1_ENTRY_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_RESM_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_RESM_INT);
> - printk(KERN_INFO "fusb300_resume\n");
> + pr_info("fusb300_resume\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_SUSP_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_SUSP_INT);
> - printk(KERN_INFO "fusb300_suspend\n");
> + pr_info("fusb300_suspend\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_HS_LPM_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_HS_LPM_INT);
> - printk(KERN_INFO "fusb300_HS_LPM_INT\n");
> + pr_info("fusb300_HS_LPM_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_DEV_MODE_CHG_INT) {
> @@ -1195,11 +1195,11 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
>
> if (int_grp1 & FUSB300_IGR1_CX_COMFAIL_INT) {
> fusb300_set_cxstall(fusb300);
> - printk(KERN_INFO "fusb300_ep0fail\n");
> + pr_info("fusb300_ep0fail\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_CX_SETUP_INT) {
> - printk(KERN_INFO "fusb300_ep0setup\n");
> + pr_info("fusb300_ep0setup\n");
> if (setup_packet(fusb300, &ctrl)) {
> spin_unlock(&fusb300->lock);
> if (fusb300->driver->setup(&fusb300->gadget, &ctrl) < 0)
> @@ -1209,16 +1209,16 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> }
>
> if (int_grp1 & FUSB300_IGR1_CX_CMDEND_INT)
> - printk(KERN_INFO "fusb300_cmdend\n");
> + pr_info("fusb300_cmdend\n");
>
>
> if (int_grp1 & FUSB300_IGR1_CX_OUT_INT) {
> - printk(KERN_INFO "fusb300_cxout\n");
> + pr_info("fusb300_cxout\n");
> fusb300_ep0out(fusb300);
> }
>
> if (int_grp1 & FUSB300_IGR1_CX_IN_INT) {
> - printk(KERN_INFO "fusb300_cxin\n");
> + pr_info("fusb300_cxin\n");
> fusb300_ep0in(fusb300);
> }
>
> diff --git a/drivers/usb/gadget/udc/goku_udc.c b/drivers/usb/gadget/udc/goku_udc.c
> index 3e1267d38774..4f225552861a 100644
> --- a/drivers/usb/gadget/udc/goku_udc.c
> +++ b/drivers/usb/gadget/udc/goku_udc.c
> @@ -1748,7 +1748,7 @@ static int goku_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> int retval;
>
> if (!pdev->irq) {
> - printk(KERN_ERR "Check PCI %s IRQ setup!\n", pci_name(pdev));
> + pr_err("Check PCI %s IRQ setup!\n", pci_name(pdev));
When a pointer to a struct device is available, dev_err() would be much
better. That's however out of scope for this patch, but it would be nice
to address it. This would become
dev_err(&pdev->dev, "Check IRQ setup!\n");
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> retval = -ENODEV;
> goto err;
> }
> diff --git a/drivers/usb/gadget/udc/r8a66597-udc.h b/drivers/usb/gadget/udc/r8a66597-udc.h
> index 9a115caba661..fa4d62c32ea1 100644
> --- a/drivers/usb/gadget/udc/r8a66597-udc.h
> +++ b/drivers/usb/gadget/udc/r8a66597-udc.h
> @@ -247,7 +247,7 @@ static inline u16 get_xtal_from_pdata(struct r8a66597_platdata *pdata)
> clock = XTAL48;
> break;
> default:
> - printk(KERN_ERR "r8a66597: platdata clock is wrong.\n");
> + pr_err("r8a66597: platdata clock is wrong.\n");
> break;
> }
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] powerpc/rtas: fix typo of ibm,open-errinjct in rtas filter
From: Tyrel Datwyler @ 2020-12-08 19:54 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, linux-kernel, Tyrel Datwyler
Commit bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
introduced the following error when invoking the errinjct userspace
tool.
[root@ltcalpine2-lp5 librtas]# errinjct open
[327884.071171] sys_rtas: RTAS call blocked - exploit attempt?
[327884.071186] sys_rtas: token=0x26, nargs=0 (called by errinjct)
errinjct: Could not open RTAS error injection facility
errinjct: librtas: open: Unexpected I/O error
The entry for ibm,open-errinjct in rtas_filter array has a typo where
the "j" is omitted in the rtas call name. After fixing this typo the
errinjct tool functions again as expected.
[root@ltcalpine2-lp5 linux]# errinjct open
RTAS error injection facility open, token = 1
fixes: bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
---
arch/powerpc/kernel/rtas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 954f41676f69..cccb32cf0e08 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1030,7 +1030,7 @@ static struct rtas_filter rtas_filters[] __ro_after_init = {
{ "ibm,display-message", -1, 0, -1, -1, -1 },
{ "ibm,errinjct", -1, 2, -1, -1, -1, 1024 },
{ "ibm,close-errinjct", -1, -1, -1, -1, -1 },
- { "ibm,open-errinct", -1, -1, -1, -1, -1 },
+ { "ibm,open-errinjct", -1, -1, -1, -1, -1 },
{ "ibm,get-config-addr-info2", -1, -1, -1, -1, -1 },
{ "ibm,get-dynamic-sensor-state", -1, 1, -1, -1, -1 },
{ "ibm,get-indices", -1, 2, 3, -1, -1 },
--
2.27.0
^ permalink raw reply related
* Re: [PATCH 02/20] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram
From: Rasmus Villemoes @ 2020-12-08 20:12 UTC (permalink / raw)
To: Li Yang
Cc: Vladimir Oltean, lkml, Netdev, Jakub Kicinski, linuxppc-dev,
David S. Miller, Zhao Qiang
In-Reply-To: <CADRPPNTgqwd37VSqiUcv2otGVr4mnQbuv6r887w_yCp=ha1dvA@mail.gmail.com>
On 08/12/2020 20.14, Li Yang wrote:
> On Sat, Dec 5, 2020 at 1:21 PM Rasmus Villemoes
> <rasmus.villemoes@prevas.dk> wrote:
>>
>> Table 8-53 in the QUICC Engine Reference manual shows definitions of
>> fields up to a size of 192 bytes, not just 128. But in table 8-111,
>> one does find the text
>>
>> Base Address of the Global Transmitter Parameter RAM Page. [...]
>> The user needs to allocate 128 bytes for this page. The address must
>> be aligned to the page size.
>>
>> I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
>> they both have this inconsistency (and the table numbers are the
>> same).
>
> This does seem to be an inconsistency. I will try to see if I can
> find someone who is familiar with this as this is really an old IP.
>
> Figure 8-61 does mention that size = 128 byte + 64 byte if .... But
> this part is not clear also.
Hm, indeed, that sentence is simply cut short, it literally says
"Additional 64 bytes are needed if". The next line contains
"Hierarchical Scheduler, or IP" in a smaller font, but that seems to be
a label for the arrow.
>
> The overlapping does seem to be a problem. Maybe these global
> parameters are not sampled at runtime or the parameter RAM is really
> only using 128byte depending on the operation mode.
Yes, I'm thinking something like that is likely to be the case, since
this hasn't seemed to ever cause any problems. But who knows, maybe a
few frames just get fragmented very occasionally becauces the MTU0 field
spuriously has some random small value.
>
> Are you getting useful information by reading from the additional 64
> bytes,
AFAICT, after the additional allocation, the extra 64 bytes stay at 0,
but that's to be expected; they are supposed to be written by the CPU
and read by the engine AFAIU.
or getting changed behavior for setting these bytes after your
> changes?
No, as I said:
>> I haven't observed any failure that could be attributed to this,
I haven't played around with explicitly writing to those 64 bytes after
initialization. This whole series started because I searched for the
string "MTU" in the manual, but at the end, it didn't seem that I
actually needed to modify those MTU fields.
Rasmus
^ permalink raw reply
* Re: [PATCH 18/20] ethernet: ucc_geth: add helper to replace repeated switch statements
From: Rasmus Villemoes @ 2020-12-08 20:55 UTC (permalink / raw)
To: Christophe Leroy, Li Yang, David S. Miller, Jakub Kicinski
Cc: Vladimir Oltean, Zhao Qiang, linuxppc-dev, linux-kernel, netdev
In-Reply-To: <ed16ea1d-5017-96bd-c1a9-5201f51231fd@csgroup.eu>
On 08/12/2020 16.21, Christophe Leroy wrote:
>
>
> Le 05/12/2020 à 20:17, Rasmus Villemoes a écrit :
>> The translation from the ucc_geth_num_of_threads enum value to the
>> actual count can be written somewhat more compactly with a small
>> lookup table, allowing us to replace the four switch statements.
>>
> I think you would allow GCC to provide a much better optimisation with
> something like:
>
Your version compiles to 120 bytes of object code, mine around 49
(including the 5 byte lookup table). They're about the same in line count.
Rasmus
^ permalink raw reply
* Re: [PATCH v2 0/5] drop unused BACKLIGHT_GENERIC option
From: Arnd Bergmann @ 2020-12-08 21:04 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Alexandre Belloni, Sam Ravnborg, Tony Lindgren,
linux-kernel@vger.kernel.org, James Bottomley, Chen-Yu Tsai,
Thierry Reding, Paul Mackerras, Will Deacon, Daniel Thompson,
Helge Deller, Russell King - ARM Linux, Krzysztof Kozlowski,
Jonathan Hunter, Ludovic Desroches, Catalin Marinas,
open list:BROADCOM NVRAM DRIVER, Arnd Bergmann, Maxime Ripard,
Andrey Zhizhikin, SoC Team, open list:TEGRA ARCHITECTURE SUPPORT,
Lee Jones, linux-omap, Linux ARM, Jernej Skrabec, Parisc List,
Emil Velikov, Nicolas Ferre, linuxppc-dev
In-Reply-To: <20201208170021.GA6168@alpha.franken.de>
On Tue, Dec 8, 2020 at 6:00 PM Thomas Bogendoerfer
<tsbogend@alpha.franken.de> wrote:
> On Tue, Dec 08, 2020 at 05:34:46PM +0100, Arnd Bergmann wrote:
> > [3/5] MIPS: configs: drop unused BACKLIGHT_GENERIC option
> > commit: 2257682282531de45929c6006152f6e2ee881b42
>
> this one is already in mips-next.
Ok, dropped from my tree,
Arnd
^ permalink raw reply
* Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Bjorn Helgaas @ 2020-12-08 21:06 UTC (permalink / raw)
To: Michael Walle
Cc: kw, heiko, shawn.lin, paulus, thomas.petazzoni, jonnyc, toan,
will, robh, lorenzo.pieralisi, michal.simek, linux-rockchip,
bcm-kernel-feedback-list, linux-arm-kernel, linux-pci, Qian Cai,
rjui, f.fainelli, linux-rpi-kernel, Jonathan.Cameron, bhelgaas,
jonathan.derrick, sbranden, wangzhou1, rrichter, linuxppc-dev,
nsaenzjulienne
In-Reply-To: <20201208154150.20978-1-michael@walle.cc>
[+cc Qian]
On Tue, Dec 08, 2020 at 04:41:50PM +0100, Michael Walle wrote:
> Hi Lorenzo, Krzysztof,
>
> >On Sun, 29 Nov 2020 23:07:38 +0000, Krzysztof Wilczyński wrote:
> >> Unify ECAM-related constants into a single set of standard constants
> >> defining memory address shift values for the byte-level address that can
> >> be used when accessing the PCI Express Configuration Space, and then
> >> move native PCI Express controller drivers to use newly introduced
> >> definitions retiring any driver-specific ones.
> >>
> >> The ECAM ("Enhanced Configuration Access Mechanism") is defined by the
> >> PCI Express specification (see PCI Express Base Specification, Revision
> >> 5.0, Version 1.0, Section 7.2.2, p. 676), thus most hardware should
> >> implement it the same way.
> >>
> >> [...]
> >
> >Applied to pci/ecam, thanks!
> >
> >[1/5] PCI: Unify ECAM constants in native PCI Express drivers
> > https://git.kernel.org/lpieralisi/pci/c/f3c07cf692
> >[2/5] PCI: thunder-pem: Add constant for custom ".bus_shift" initialiser
> > https://git.kernel.org/lpieralisi/pci/c/3c38579263
> >[3/5] PCI: iproc: Convert to use the new ECAM constants
> > https://git.kernel.org/lpieralisi/pci/c/333ec9d3cc
> >[4/5] PCI: vmd: Update type of the __iomem pointers
> > https://git.kernel.org/lpieralisi/pci/c/89094c12ea
> >[5/5] PCI: xgene: Removed unused ".bus_shift" initialisers from pci-xgene.c
> > https://git.kernel.org/lpieralisi/pci/c/3dc62532a5
>
> Patch 1/5 breaks LS1028A boards:
I temporarily dropped this series while we figure out what went wrong
here.
Bjorn
^ permalink raw reply
* Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Michael Walle @ 2020-12-08 21:11 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: kw, heiko, shawn.lin, paulus, thomas.petazzoni, jonnyc, toan,
will, robh, lorenzo.pieralisi, michal.simek, linux-rockchip,
bcm-kernel-feedback-list, linux-arm-kernel, linux-pci, Qian Cai,
rjui, f.fainelli, linux-rpi-kernel, Jonathan.Cameron, bhelgaas,
jonathan.derrick, sbranden, wangzhou1, rrichter, linuxppc-dev,
nsaenzjulienne
In-Reply-To: <20201208210613.GA2420289@bjorn-Precision-5520>
Am 2020-12-08 22:06, schrieb Bjorn Helgaas:
> [+cc Qian]
>
> On Tue, Dec 08, 2020 at 04:41:50PM +0100, Michael Walle wrote:
>> Hi Lorenzo, Krzysztof,
>>
>> >On Sun, 29 Nov 2020 23:07:38 +0000, Krzysztof Wilczyński wrote:
>> >> Unify ECAM-related constants into a single set of standard constants
>> >> defining memory address shift values for the byte-level address that can
>> >> be used when accessing the PCI Express Configuration Space, and then
>> >> move native PCI Express controller drivers to use newly introduced
>> >> definitions retiring any driver-specific ones.
>> >>
>> >> The ECAM ("Enhanced Configuration Access Mechanism") is defined by the
>> >> PCI Express specification (see PCI Express Base Specification, Revision
>> >> 5.0, Version 1.0, Section 7.2.2, p. 676), thus most hardware should
>> >> implement it the same way.
>> >>
>> >> [...]
>> >
>> >Applied to pci/ecam, thanks!
>> >
>> >[1/5] PCI: Unify ECAM constants in native PCI Express drivers
>> > https://git.kernel.org/lpieralisi/pci/c/f3c07cf692
>> >[2/5] PCI: thunder-pem: Add constant for custom ".bus_shift" initialiser
>> > https://git.kernel.org/lpieralisi/pci/c/3c38579263
>> >[3/5] PCI: iproc: Convert to use the new ECAM constants
>> > https://git.kernel.org/lpieralisi/pci/c/333ec9d3cc
>> >[4/5] PCI: vmd: Update type of the __iomem pointers
>> > https://git.kernel.org/lpieralisi/pci/c/89094c12ea
>> >[5/5] PCI: xgene: Removed unused ".bus_shift" initialisers from pci-xgene.c
>> > https://git.kernel.org/lpieralisi/pci/c/3dc62532a5
>>
>> Patch 1/5 breaks LS1028A boards:
>
> I temporarily dropped this series while we figure out what went wrong
> here.
Thanks, let me know if I can test something on the board.
-michael
^ permalink raw reply
* Re: [PATCH 14/20] ethernet: ucc_geth: don't statically allocate eight ucc_geth_info
From: Rasmus Villemoes @ 2020-12-08 21:17 UTC (permalink / raw)
To: Christophe Leroy, Li Yang, David S. Miller, Jakub Kicinski
Cc: Vladimir Oltean, Zhao Qiang, linuxppc-dev, linux-kernel, netdev
In-Reply-To: <8259bec3-9343-82e3-a420-a8170cf922a4@csgroup.eu>
On 08/12/2020 16.13, Christophe Leroy wrote:
>
>
> Le 05/12/2020 à 20:17, Rasmus Villemoes a écrit :
>> @@ -3714,25 +3712,23 @@ static int ucc_geth_probe(struct
>> platform_device* ofdev)
>> if ((ucc_num < 0) || (ucc_num > 7))
>> return -ENODEV;
>> - ug_info = &ugeth_info[ucc_num];
>> - if (ug_info == NULL) {
>> - if (netif_msg_probe(&debug))
>> - pr_err("[%d] Missing additional data!\n", ucc_num);
>> - return -ENODEV;
>> - }
>> + ug_info = kmalloc(sizeof(*ug_info), GFP_KERNEL);
>
> Could we use dev_kmalloc() instead, to avoid the freeing on the wait out
> and the err_free_info: path ?
Perhaps, but I don't think mixing ordinary kmalloc() with devm_ versions
in the same driver is a good idea - IIRC there are at least some rules
to obey if one does that, but I don't remember and can't find what they are.
Rasmus
^ permalink raw reply
* [PATCH v2 1/1] powerpc/kvm: Fix mask size for emulated msgsndp
From: Leonardo Bras @ 2020-12-08 21:57 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt
Cc: Leonardo Bras, linuxppc-dev, linux-kernel, kvm-ppc
According to ISAv3.1 and ISAv3.0b, the msgsndp is described to split RB in:
msgtype <- (RB) 32:36
payload <- (RB) 37:63
t <- (RB) 57:63
The current way of getting 'msgtype', and 't' is missing their MSB:
msgtype: ((arg >> 27) & 0xf) : Gets (RB) 33:36, missing bit 32
t: (arg &= 0x3f) : Gets (RB) 58:63, missing bit 57
Fixes this by applying the correct mask.
Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
---
Changes since v1:
- Commit message 's/LSB/MSB/', because ISA ordering is big-endian.
arch/powerpc/kvm/book3s_hv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index e3b1839fc251..5af0a429cee8 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1241,9 +1241,9 @@ static int kvmppc_emulate_doorbell_instr(struct kvm_vcpu *vcpu)
switch (get_xop(inst)) {
case OP_31_XOP_MSGSNDP:
arg = kvmppc_get_gpr(vcpu, rb);
- if (((arg >> 27) & 0xf) != PPC_DBELL_SERVER)
+ if (((arg >> 27) & 0x1f) != PPC_DBELL_SERVER)
break;
- arg &= 0x3f;
+ arg &= 0x7f;
if (arg >= kvm->arch.emul_smt_mode)
break;
tvcpu = kvmppc_find_vcpu(kvm, vcpu->vcpu_id - thr + arg);
@@ -1256,7 +1256,7 @@ static int kvmppc_emulate_doorbell_instr(struct kvm_vcpu *vcpu)
break;
case OP_31_XOP_MSGCLRP:
arg = kvmppc_get_gpr(vcpu, rb);
- if (((arg >> 27) & 0xf) != PPC_DBELL_SERVER)
+ if (((arg >> 27) & 0x1f) != PPC_DBELL_SERVER)
break;
vcpu->arch.vcore->dpdes = 0;
vcpu->arch.doorbell_request = 0;
--
2.25.4
^ permalink raw reply related
* Re: [PATCH v2 01/17] ibmvfc: add vhost fields and defaults for MQ enablement
From: Tyrel Datwyler @ 2020-12-08 22:37 UTC (permalink / raw)
To: Hannes Reinecke, Brian King, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <6ce79011-d288-7a49-3d51-262da58d8486@suse.de>
On 12/7/20 3:56 AM, Hannes Reinecke wrote:
> On 12/4/20 3:26 PM, Brian King wrote:
>> On 12/2/20 11:27 AM, Tyrel Datwyler wrote:
>>> On 12/2/20 7:14 AM, Brian King wrote:
>>>> On 12/1/20 6:53 PM, Tyrel Datwyler wrote:
>>>>> Introduce several new vhost fields for managing MQ state of the adapter
>>>>> as well as initial defaults for MQ enablement.
>>>>>
>>>>> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
>>>>> ---
>>>>> drivers/scsi/ibmvscsi/ibmvfc.c | 9 ++++++++-
>>>>> drivers/scsi/ibmvscsi/ibmvfc.h | 13 +++++++++++--
>>>>> 2 files changed, 19 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
>>>>> index 42e4d35e0d35..f1d677a7423d 100644
>>>>> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
>>>>> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
>>>>> @@ -5161,12 +5161,13 @@ static int ibmvfc_probe(struct vio_dev *vdev, const
>>>>> struct vio_device_id *id)
>>>>> }
>>>>> shost->transportt = ibmvfc_transport_template;
>>>>> - shost->can_queue = max_requests;
>>>>> + shost->can_queue = (max_requests / IBMVFC_SCSI_HW_QUEUES);
>>>>
>>>> This doesn't look right. can_queue is the SCSI host queue depth, not the MQ
>>>> queue depth.
>>>
>>> Our max_requests is the total number commands allowed across all queues. From
>>> what I understand is can_queue is the total number of commands in flight allowed
>>> for each hw queue.
>>>
>>> /*
>>> * In scsi-mq mode, the number of hardware queues supported by the LLD.
>>> *
>>> * Note: it is assumed that each hardware queue has a queue depth of
>>> * can_queue. In other words, the total queue depth per host
>>> * is nr_hw_queues * can_queue. However, for when host_tagset is set,
>>> * the total queue depth is can_queue.
>>> */
>>>
>>> We currently don't use the host wide shared tagset.
>>
>> Ok. I missed that bit... In that case, since we allocate by default only 100
>> event structs. If we slice that across IBMVFC_SCSI_HW_QUEUES (16) queues, then
>> we end up with only about 6 commands that can be outstanding per queue,
>> which is going to really hurt performance... I'd suggest bumping up
>> IBMVFC_MAX_REQUESTS_DEFAULT from 100 to 1000 as a starting point.
>>
> Before doing that I'd rather use the host-wide shared tagset.
> Increasing the number of requests will increase the memory footprint of the
> driver (as each request will be statically allocated).
>
In the case where we use host-wide how do I determine the queue depth per
hardware queue? Is is hypothetically can_queue or is it (can_queue /
nr_hw_queues)? We want to allocate an event pool per-queue which made sense
without host-wide tags since the queue depth per hw queue is exactly can_queue.
-Tyrel
^ permalink raw reply
* Re: [PATCH] arch: fix 'unexpected IRQ trap at vector' warnings
From: Thomas Gleixner @ 2020-12-08 23:01 UTC (permalink / raw)
To: Michael Ellerman, Enrico Weigelt, metux IT consult, linux-kernel
Cc: linux-s390, hpa, linux-parisc, deller, x86, linux-um,
James.Bottomley, mingo, paulus, richard, bp, linuxppc-dev, jdike,
anton.ivanov
In-Reply-To: <877dptt5av.fsf@mpe.ellerman.id.au>
On Tue, Dec 08 2020 at 13:11, Michael Ellerman wrote:
> "Enrico Weigelt, metux IT consult" <info@metux.net> writes:
>> All archs, except Alpha, print out the irq number in hex, but the message
>> looks like it was a decimal number, which is quite confusing. Fixing this
>> by adding "0x" prefix.
>
> Arguably decimal would be better, /proc/interrupts and /proc/irq/ both
> use decimal.
>
> The whole message is very dated IMO, these days the number it prints is
> (possibly) virtualised via IRQ domains, ie. it's not necessarily a
> "vector" if that even makes sense on all arches). Arguably "trap" is the
> wrong term on some arches too.
>
> So it would be better reworded entirely IMO, and also switched to
> decimal to match other sources of information on interrupts.
So much for the theory.
The printk originates from the very early days of i386 Linux where it
was called from the low level entry code when there was no interrupt
assigned to a vector, which is an x86'ism.
That was copied to other architectures without actually thinking about
whether the vector concept made sense on that architecture and at some
point it got completely bonkers because it moved to core code without
thought.
There are a few situations why it is invoked or not:
1) The original x86 usage is not longer using it because it complains
rightfully about a vector being raised which has no interrupt
descriptor associated to it. So the original reason for naming it
vector is gone long ago. It emits:
pr_emerg_ratelimited("%s: %d.%u No irq handler for vector\n",
__func__, smp_processor_id(), vector);
Directly from the x86 C entry point without ever invoking that
function. Pretty popular error message due to some AMD BIOS
wreckage. :)
2) It's invoked when there is an interrupt descriptor installed but
not configured/requested. In that case some architectures need to
ack it in order not to block further interrupt delivery. In that
case 'vector is bogus' and really want's to be 'irqnr' or such
because there is a Linux virq number associated to it.
3) It's invoked from __handle_domain_irq() when the 'hwirq' which is
handed in by the caller does not resolve to a mapped Linux
interrupt which is pretty much the same as the x86 situation above
in #1, but it prints useless data.
It prints 'irq' which is invalid but it does not print the really
interesting 'hwirq' which was handed in by the caller and did
not resolve.
In this case the Linux irq number is uninteresting as it is known
to be invalid and simply is not mapped and therefore does not
exist.
This has to print out 'hwirq' which is kinda the equivalent to the
original 'vector' message.
4) It's invoked from the dummy irq chip which is installed for a
couple of truly virtual interrupts where the invocation of
dummy_irq_chip::irq_ack() is indicating wreckage.
In that case the Linux irq number is the thing which is printed.
So no. It's not just inconsistent it's in some places outright
wrong. What we really want is:
ack_bad_irq(int hwirq, int virq)
{
if (hwirq >= 0)
print_useful_info(hwirq);
if (virq > 0)
print_useful_info(virq);
arch_try_to_ack(hwirq, virq);
}
for this to make sense. Just fixing the existing printk() to be less
wrong is not really an improvement.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/rtas: Restrict RTAS requests from userspace
From: Andrew Donnellan @ 2020-12-08 23:23 UTC (permalink / raw)
To: Tyrel Datwyler, linuxppc-dev; +Cc: nathanl, leobras.c, stable, dja
In-Reply-To: <e58e8c42-d422-1bd7-ab38-9a1fb118fca4@linux.ibm.com>
On 9/12/20 5:59 am, Tyrel Datwyler wrote:
>> + { "ibm,open-errinct", -1, -1, -1, -1, -1 },
>
> There is a typo here. Should be ibm,open-errinjct.
>
> kernel: [ 1100.408626] sys_rtas: RTAS call blocked - exploit attempt?
> kernel: [ 1100.408631] sys_rtas: token=0x26, nargs=0 (called by errinjct)
>
> Which is producing this when trying to invoke the errinjct tool.
>
> I'll send a fixes patch out shortly.
*sigh*
Thanks for picking this up!
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH] drivers: usb: gadget: prefer pr_*() functions over raw printk()
From: Peter Chen @ 2020-12-09 1:48 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: balbi@kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, Leo Li,
laurent.pinchart@ideasonboard.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20201208144403.22097-1-info@metux.net>
On 20-12-08 15:44:03, Enrico Weigelt, metux IT consult wrote:
> Reduce a bit logging boilerplate by using the preferred pr_*()
> macros instead of raw printk().
It is the device driver code, it is better to use dev_info/dev_dbg.
Peter
>
> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ---
> drivers/usb/gadget/function/uvc.h | 2 +-
> drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
> drivers/usb/gadget/udc/fsl_udc_core.c | 4 +--
> drivers/usb/gadget/udc/fsl_usb2_udc.h | 4 +--
> drivers/usb/gadget/udc/fusb300_udc.c | 64 ++++++++++++++++-----------------
> drivers/usb/gadget/udc/goku_udc.c | 2 +-
> drivers/usb/gadget/udc/r8a66597-udc.h | 2 +-
> 7 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/uvc.h b/drivers/usb/gadget/function/uvc.h
> index 23ee25383c1f..d546eb7c348c 100644
> --- a/drivers/usb/gadget/function/uvc.h
> +++ b/drivers/usb/gadget/function/uvc.h
> @@ -49,7 +49,7 @@ extern unsigned int uvc_gadget_trace_param;
> #define uvc_trace(flag, msg...) \
> do { \
> if (uvc_gadget_trace_param & flag) \
> - printk(KERN_DEBUG "uvcvideo: " msg); \
> + pr_debug("uvcvideo: " msg); \
> } while (0)
>
> #define uvcg_dbg(f, fmt, args...) \
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 2b893bceea45..4834fafb3f70 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1573,7 +1573,7 @@ static void usba_control_irq(struct usba_udc *udc, struct usba_ep *ep)
> * generate or receive a reply right away. */
> usba_ep_writel(ep, CLR_STA, USBA_RX_SETUP);
>
> - /* printk(KERN_DEBUG "setup: %d: %02x.%02x\n",
> + /* pr_debug("setup: %d: %02x.%02x\n",
> ep->state, crq.crq.bRequestType,
> crq.crq.bRequest); */
>
> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
> index ad6ff9c4188e..cab4def04f9f 100644
> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -1474,7 +1474,7 @@ __acquires(udc->lock)
> mdelay(10);
> tmp = fsl_readl(&dr_regs->portsc1) | (ptc << 16);
> fsl_writel(tmp, &dr_regs->portsc1);
> - printk(KERN_INFO "udc: switch to test mode %d.\n", ptc);
> + pr_info("udc: switch to test mode %d.\n", ptc);
> }
>
> return;
> @@ -1952,7 +1952,7 @@ static int fsl_udc_start(struct usb_gadget *g,
> if (!IS_ERR_OR_NULL(udc_controller->transceiver)) {
> /* Suspend the controller until OTG enable it */
> udc_controller->stopped = 1;
> - printk(KERN_INFO "Suspend udc for OTG auto detect\n");
> + pr_info("Suspend udc for OTG auto detect\n");
>
> /* connect to bus through transceiver */
> if (!IS_ERR_OR_NULL(udc_controller->transceiver)) {
> diff --git a/drivers/usb/gadget/udc/fsl_usb2_udc.h b/drivers/usb/gadget/udc/fsl_usb2_udc.h
> index 4ba651ae9048..b180bf14dd0c 100644
> --- a/drivers/usb/gadget/udc/fsl_usb2_udc.h
> +++ b/drivers/usb/gadget/udc/fsl_usb2_udc.h
> @@ -509,7 +509,7 @@ struct fsl_udc {
> /*-------------------------------------------------------------------------*/
>
> #ifdef DEBUG
> -#define DBG(fmt, args...) printk(KERN_DEBUG "[%s] " fmt "\n", \
> +#define DBG(fmt, args...) pr_debug("[%s] " fmt "\n", \
> __func__, ## args)
> #else
> #define DBG(fmt, args...) do{}while(0)
> @@ -535,7 +535,7 @@ static void dump_msg(const char *label, const u8 * buf, unsigned int length)
> p += 3;
> }
> *p = 0;
> - printk(KERN_DEBUG "%6x: %s\n", start, line);
> + pr_debug("%6x: %s\n", start, line);
> buf += num;
> start += num;
> length -= num;
> diff --git a/drivers/usb/gadget/udc/fusb300_udc.c b/drivers/usb/gadget/udc/fusb300_udc.c
> index 9af8b415f303..c4e7e4b8e46f 100644
> --- a/drivers/usb/gadget/udc/fusb300_udc.c
> +++ b/drivers/usb/gadget/udc/fusb300_udc.c
> @@ -352,24 +352,24 @@ static void fusb300_wrcxf(struct fusb300_ep *ep,
> for (i = length >> 2; i > 0; i--) {
> data = *tmp | *(tmp + 1) << 8 | *(tmp + 2) << 16 |
> *(tmp + 3) << 24;
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> iowrite32(data, fusb300->reg + FUSB300_OFFSET_CXPORT);
> tmp = tmp + 4;
> }
> switch (length % 4) {
> case 1:
> data = *tmp;
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> iowrite32(data, fusb300->reg + FUSB300_OFFSET_CXPORT);
> break;
> case 2:
> data = *tmp | *(tmp + 1) << 8;
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> iowrite32(data, fusb300->reg + FUSB300_OFFSET_CXPORT);
> break;
> case 3:
> data = *tmp | *(tmp + 1) << 8 | *(tmp + 2) << 16;
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> iowrite32(data, fusb300->reg + FUSB300_OFFSET_CXPORT);
> break;
> default:
> @@ -390,7 +390,7 @@ static void fusb300_clear_epnstall(struct fusb300 *fusb300, u8 ep)
> u32 reg = ioread32(fusb300->reg + FUSB300_OFFSET_EPSET0(ep));
>
> if (reg & FUSB300_EPSET0_STL) {
> - printk(KERN_DEBUG "EP%d stall... Clear!!\n", ep);
> + pr_debug("EP%d stall... Clear!!\n", ep);
> reg |= FUSB300_EPSET0_STL_CLR;
> iowrite32(reg, fusb300->reg + FUSB300_OFFSET_EPSET0(ep));
> }
> @@ -402,7 +402,7 @@ static void ep0_queue(struct fusb300_ep *ep, struct fusb300_request *req)
> if (req->req.length) {
> fusb300_wrcxf(ep, req);
> } else
> - printk(KERN_DEBUG "%s : req->req.length = 0x%x\n",
> + pr_debug("%s : req->req.length = 0x%x\n",
> __func__, req->req.length);
> if ((req->req.length == req->req.actual) ||
> (req->req.actual < ep->ep.maxpacket))
> @@ -565,7 +565,7 @@ static void fusb300_rdcxf(struct fusb300 *fusb300,
>
> for (i = (length >> 2); i > 0; i--) {
> data = ioread32(fusb300->reg + FUSB300_OFFSET_CXPORT);
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> *tmp = data & 0xFF;
> *(tmp + 1) = (data >> 8) & 0xFF;
> *(tmp + 2) = (data >> 16) & 0xFF;
> @@ -576,18 +576,18 @@ static void fusb300_rdcxf(struct fusb300 *fusb300,
> switch (length % 4) {
> case 1:
> data = ioread32(fusb300->reg + FUSB300_OFFSET_CXPORT);
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> *tmp = data & 0xFF;
> break;
> case 2:
> data = ioread32(fusb300->reg + FUSB300_OFFSET_CXPORT);
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> *tmp = data & 0xFF;
> *(tmp + 1) = (data >> 8) & 0xFF;
> break;
> case 3:
> data = ioread32(fusb300->reg + FUSB300_OFFSET_CXPORT);
> - printk(KERN_DEBUG " 0x%x\n", data);
> + pr_debug(" 0x%x\n", data);
> *tmp = data & 0xFF;
> *(tmp + 1) = (data >> 8) & 0xFF;
> *(tmp + 2) = (data >> 16) & 0xFF;
> @@ -610,7 +610,7 @@ static void fusb300_rdfifo(struct fusb300_ep *ep,
> req->req.actual += length;
>
> if (req->req.actual > req->req.length)
> - printk(KERN_DEBUG "req->req.actual > req->req.length\n");
> + pr_debug("req->req.actual > req->req.length\n");
>
> for (i = (length >> 2); i > 0; i--) {
> data = ioread32(fusb300->reg +
> @@ -649,7 +649,7 @@ static void fusb300_rdfifo(struct fusb300_ep *ep,
> reg = ioread32(fusb300->reg + FUSB300_OFFSET_IGR1);
> reg &= FUSB300_IGR1_SYNF0_EMPTY_INT;
> if (i)
> - printk(KERN_INFO "sync fifo is not empty!\n");
> + pr_info("sync fifo is not empty!\n");
> i++;
> } while (!reg);
> }
> @@ -677,7 +677,7 @@ static u8 fusb300_get_cxstall(struct fusb300 *fusb300)
> static void request_error(struct fusb300 *fusb300)
> {
> fusb300_set_cxstall(fusb300);
> - printk(KERN_DEBUG "request error!!\n");
> + pr_debug("request error!!\n");
> }
>
> static void get_status(struct fusb300 *fusb300, struct usb_ctrlrequest *ctrl)
> @@ -999,7 +999,7 @@ static void check_device_mode(struct fusb300 *fusb300)
> fusb300->gadget.speed = USB_SPEED_UNKNOWN;
> break;
> }
> - printk(KERN_INFO "dev_mode = %d\n", (reg & FUSB300_GCR_DEVEN_MSK));
> + pr_info("dev_mode = %d\n", (reg & FUSB300_GCR_DEVEN_MSK));
> }
>
>
> @@ -1076,14 +1076,14 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> if (int_grp1 & FUSB300_IGR1_WARM_RST_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_WARM_RST_INT);
> - printk(KERN_INFO"fusb300_warmreset\n");
> + pr_info("fusb300_warmreset\n");
> fusb300_reset();
> }
>
> if (int_grp1 & FUSB300_IGR1_HOT_RST_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_HOT_RST_INT);
> - printk(KERN_INFO"fusb300_hotreset\n");
> + pr_info("fusb300_hotreset\n");
> fusb300_reset();
> }
>
> @@ -1097,13 +1097,13 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> if (int_grp1 & FUSB300_IGR1_CX_COMABT_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_CX_COMABT_INT);
> - printk(KERN_INFO"fusb300_ep0abt\n");
> + pr_info("fusb300_ep0abt\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_VBUS_CHG_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_VBUS_CHG_INT);
> - printk(KERN_INFO"fusb300_vbus_change\n");
> + pr_info("fusb300_vbus_change\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U3_EXIT_FAIL_INT) {
> @@ -1134,25 +1134,25 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> if (int_grp1 & FUSB300_IGR1_U3_EXIT_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U3_EXIT_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U3_EXIT_INT\n");
> + pr_info("FUSB300_IGR1_U3_EXIT_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U2_EXIT_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U2_EXIT_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U2_EXIT_INT\n");
> + pr_info("FUSB300_IGR1_U2_EXIT_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U1_EXIT_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U1_EXIT_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U1_EXIT_INT\n");
> + pr_info("FUSB300_IGR1_U1_EXIT_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U3_ENTRY_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U3_ENTRY_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U3_ENTRY_INT\n");
> + pr_info("FUSB300_IGR1_U3_ENTRY_INT\n");
> fusb300_enable_bit(fusb300, FUSB300_OFFSET_SSCR1,
> FUSB300_SSCR1_GO_U3_DONE);
> }
> @@ -1160,31 +1160,31 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> if (int_grp1 & FUSB300_IGR1_U2_ENTRY_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U2_ENTRY_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U2_ENTRY_INT\n");
> + pr_info("FUSB300_IGR1_U2_ENTRY_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_U1_ENTRY_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_U1_ENTRY_INT);
> - printk(KERN_INFO "FUSB300_IGR1_U1_ENTRY_INT\n");
> + pr_info("FUSB300_IGR1_U1_ENTRY_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_RESM_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_RESM_INT);
> - printk(KERN_INFO "fusb300_resume\n");
> + pr_info("fusb300_resume\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_SUSP_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_SUSP_INT);
> - printk(KERN_INFO "fusb300_suspend\n");
> + pr_info("fusb300_suspend\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_HS_LPM_INT) {
> fusb300_clear_int(fusb300, FUSB300_OFFSET_IGR1,
> FUSB300_IGR1_HS_LPM_INT);
> - printk(KERN_INFO "fusb300_HS_LPM_INT\n");
> + pr_info("fusb300_HS_LPM_INT\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_DEV_MODE_CHG_INT) {
> @@ -1195,11 +1195,11 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
>
> if (int_grp1 & FUSB300_IGR1_CX_COMFAIL_INT) {
> fusb300_set_cxstall(fusb300);
> - printk(KERN_INFO "fusb300_ep0fail\n");
> + pr_info("fusb300_ep0fail\n");
> }
>
> if (int_grp1 & FUSB300_IGR1_CX_SETUP_INT) {
> - printk(KERN_INFO "fusb300_ep0setup\n");
> + pr_info("fusb300_ep0setup\n");
> if (setup_packet(fusb300, &ctrl)) {
> spin_unlock(&fusb300->lock);
> if (fusb300->driver->setup(&fusb300->gadget, &ctrl) < 0)
> @@ -1209,16 +1209,16 @@ static irqreturn_t fusb300_irq(int irq, void *_fusb300)
> }
>
> if (int_grp1 & FUSB300_IGR1_CX_CMDEND_INT)
> - printk(KERN_INFO "fusb300_cmdend\n");
> + pr_info("fusb300_cmdend\n");
>
>
> if (int_grp1 & FUSB300_IGR1_CX_OUT_INT) {
> - printk(KERN_INFO "fusb300_cxout\n");
> + pr_info("fusb300_cxout\n");
> fusb300_ep0out(fusb300);
> }
>
> if (int_grp1 & FUSB300_IGR1_CX_IN_INT) {
> - printk(KERN_INFO "fusb300_cxin\n");
> + pr_info("fusb300_cxin\n");
> fusb300_ep0in(fusb300);
> }
>
> diff --git a/drivers/usb/gadget/udc/goku_udc.c b/drivers/usb/gadget/udc/goku_udc.c
> index 3e1267d38774..4f225552861a 100644
> --- a/drivers/usb/gadget/udc/goku_udc.c
> +++ b/drivers/usb/gadget/udc/goku_udc.c
> @@ -1748,7 +1748,7 @@ static int goku_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> int retval;
>
> if (!pdev->irq) {
> - printk(KERN_ERR "Check PCI %s IRQ setup!\n", pci_name(pdev));
> + pr_err("Check PCI %s IRQ setup!\n", pci_name(pdev));
> retval = -ENODEV;
> goto err;
> }
> diff --git a/drivers/usb/gadget/udc/r8a66597-udc.h b/drivers/usb/gadget/udc/r8a66597-udc.h
> index 9a115caba661..fa4d62c32ea1 100644
> --- a/drivers/usb/gadget/udc/r8a66597-udc.h
> +++ b/drivers/usb/gadget/udc/r8a66597-udc.h
> @@ -247,7 +247,7 @@ static inline u16 get_xtal_from_pdata(struct r8a66597_platdata *pdata)
> clock = XTAL48;
> break;
> default:
> - printk(KERN_ERR "r8a66597: platdata clock is wrong.\n");
> + pr_err("r8a66597: platdata clock is wrong.\n");
> break;
> }
>
> --
> 2.11.0
>
--
Thanks,
Peter Chen
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/smp: Parse ibm, thread-groups with multiple properties
From: Michael Ellerman @ 2020-12-09 3:59 UTC (permalink / raw)
To: Gautham R Shenoy, Srikar Dronamraju
Cc: Nathan Lynch, Gautham R. Shenoy, Michael Neuling,
Vaidyanathan Srinivasan, Peter Zijlstra, linux-kernel,
Nicholas Piggin, linuxppc-dev, Valentin Schneider
In-Reply-To: <20201208172540.GA14206@in.ibm.com>
Gautham R Shenoy <ego@linux.vnet.ibm.com> writes:
> Hello Srikar,
>
> Thanks for taking a look at the patch.
>
> On Mon, Dec 07, 2020 at 05:40:42PM +0530, Srikar Dronamraju wrote:
>> * Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-04 10:18:45]:
>>
>> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>>
>> <snipped>
>>
>> >
>> > static int parse_thread_groups(struct device_node *dn,
>> > - struct thread_groups *tg,
>> > - unsigned int property)
>> > + struct thread_groups_list *tglp)
>> > {
>> > - int i;
>> > - u32 thread_group_array[3 + MAX_THREAD_LIST_SIZE];
>> > + int i = 0;
>> > + u32 *thread_group_array;
>> > u32 *thread_list;
>> > size_t total_threads;
>> > - int ret;
>> > + int ret = 0, count;
>> > + unsigned int property_idx = 0;
>>
>> NIT:
>> tglx mentions in one of his recent comments to try keep a reverse fir tree
>> ordering of variables where possible.
>
> I suppose you mean moving the longer local variable declarations to to
> the top and shorter ones to the bottom. Thanks. Will fix this.
Yeah. It's called "reverse christmas tree", that's googleable.
I also prefer that style, it makes the locals visually sit with the
beginning of the function body.
cheers
^ permalink raw reply
* Re: [PATCH v1 1/2] KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE (nested case only)
From: Paul Mackerras @ 2020-12-09 4:15 UTC (permalink / raw)
To: Bharata B Rao; +Cc: aneesh.kumar, npiggin, kvm-ppc, linuxppc-dev, David Gibson
In-Reply-To: <20201019112642.53016-2-bharata@linux.ibm.com>
On Mon, Oct 19, 2020 at 04:56:41PM +0530, Bharata B Rao wrote:
> Implements H_RPT_INVALIDATE hcall and supports only nested case
> currently.
>
> A KVM capability KVM_CAP_RPT_INVALIDATE is added to indicate the
> support for this hcall.
I have a couple of questions about this patch:
1. Is this something that is useful today, or is it something that may
become useful in the future depending on future product plans? In
other words, what advantage is there to forcing L2 guests to use this
hcall instead of doing tlbie themselves?
2. Why does it need to be added to the default-enabled hcall list?
There is a concern that if this is enabled by default we could get the
situation where a guest using it gets migrated to a host that doesn't
support it, which would be bad. That is the reason that all new
things like this are disabled by default and only enabled by userspace
(i.e. QEMU) in situations where we can enforce that it is available on
all hosts to which the VM might be migrated.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH v2 4/4] KVM: PPC: Introduce new capability for 2nd DAWR
From: Paul Mackerras @ 2020-12-09 4:36 UTC (permalink / raw)
To: Ravi Bangoria
Cc: christophe.leroy, leobras.c, mikey, kvm, linux-kernel, npiggin,
kvm-ppc, jniethe5, pbonzini, linuxppc-dev
In-Reply-To: <20201124105953.39325-5-ravi.bangoria@linux.ibm.com>
On Tue, Nov 24, 2020 at 04:29:53PM +0530, Ravi Bangoria wrote:
> Introduce KVM_CAP_PPC_DAWR1 which can be used by Qemu to query whether
> kvm supports 2nd DAWR or not.
This should be described in Documentation/virt/kvm/api.rst.
Strictly speaking, it should be a capability which is disabled by
default, so the guest can only do the H_SET_MODE to set DAWR[X]1 if it
has been explicitly permitted to do so by userspace (QEMU). This is
because we want as little as possible of the VM configuration to come
from the host capabilities rather than from what userspace configures.
So what we really need here is for this to be a capability which can
be queried by userspace to find out if it is possible, and then
enabled by userspace if it wants. See how KVM_CAP_PPC_NESTED_HV is
handled for example.
Paul.
^ permalink raw reply
* Re: [PATCH 04/13] powerpc/xive: Use cpu_to_node() instead of ibm, chip-id property
From: Aneesh Kumar K.V @ 2020-12-09 4:39 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev; +Cc: Cédric Le Goater
In-Reply-To: <20201208151124.1329942-5-clg@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> The 'chip_id' field of the XIVE CPU structure is used to choose a
> target for a source located on the same chip when possible. This field
> is assigned on the PowerNV platform using the "ibm,chip-id" property
> on pSeries under KVM when NUMA nodes are defined but it is undefined
> under PowerVM. The XIVE source structure has a similar field
> 'src_chip' which is only assigned on the PowerNV platform.
>
> cpu_to_node() returns a compatible value on all platforms, 0 being the
> default node. It will also give us the opportunity to set the affinity
> of a source on pSeries when we can localize them.
But we should avoid assuming that linux numa node number is equivalent
to chip id [1]. What do we expect this value represents on virtualized
platforms like PowerVM and KVM? Is this used for a hcall?
[1] https://lore.kernel.org/linuxppc-dev/20200817103238.158133-1-aneesh.kumar@linux.ibm.com
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/sysdev/xive/common.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index ee375daf8114..605238ca65e4 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -1342,16 +1342,11 @@ static int xive_prepare_cpu(unsigned int cpu)
>
> xc = per_cpu(xive_cpu, cpu);
> if (!xc) {
> - struct device_node *np;
> -
> xc = kzalloc_node(sizeof(struct xive_cpu),
> GFP_KERNEL, cpu_to_node(cpu));
> if (!xc)
> return -ENOMEM;
> - np = of_get_cpu_node(cpu, NULL);
> - if (np)
> - xc->chip_id = of_get_ibm_chip_id(np);
> - of_node_put(np);
> + xc->chip_id = cpu_to_node(cpu);
> xc->hw_ipi = XIVE_BAD_IRQ;
>
> per_cpu(xive_cpu, cpu) = xc;
> --
> 2.26.2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox