Re: [PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)
On Wed, Jan 8, 2020 at 9:05 PM Krzysztof Kozlowski wrote:
> The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
> some architectures void *__iomem address argument is a pointer to const,
> on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Suggested-by: Geert Uytterhoeven
> Signed-off-by: Krzysztof Kozlowski
> Reviewed-by: Geert Uytterhoeven
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 4/5] ARC: add support for DSP-enabled userspace applications
Hi Vineet, >From: Vineet Gupta >On 12/27/19 10:03 AM, Eugeniy Paltsev wrote: >> To be able to run DSP-enabled userspace applications we need to >> save and restore following DSP-related registers: >> At IRQ/exception entry/exit: >> * ACC0_GLO, ACC0_GHI, DSP_CTRL >> * ACC0_LO, ACC0_HI (we already save them as r58, r59 pair) >> At context switch: >> * DSP_BFLY0, DSP_FFT_CTRL [snip] >> + >> +#ifndef __ASSEMBLY__ >> + >> +/* some defines to simplify config sanitize in kernel/setup.c */ >> +#if defined(CONFIG_ARC_DSP_KERNEL)|| \ >> +defined(CONFIG_ARC_DSP_USERSPACE) >> +#define ARC_DSP_HANDLED 1 >> +#else >> +#define ARC_DSP_HANDLED 0 >> +#endif > >This is a really bad idea - u r introducing explicit include dependencies which >can change even outside of arch changes ! >We've dealt with enough of these problems with current.h, so best to avoid, >even >if there is some code clutter. Hmm, would it be OK if I add this option as a private kconfig option? I.E (for ARC_DSP_HANDLED): >8-- config ARC_DSP_HANDLED def_bool n choice prompt "DSP support" default ARC_DSP_NONE help Depending on the configuration, CPU can contain DSP registers (ACC0_GLO, ACC0_GHI, DSP_BFLY0, DSP_CTRL, DSP_FFT_CTRL). Bellow is options describing how to handle these registers in interrupt entry / exit and in context switch. config ARC_DSP_NONE bool "No DSP extension presence in HW" help No DSP extension presence in HW config ARC_DSP_KERNEL bool "DSP extension in HW, no support for userspace" select ARC_HAS_ACCL_REGS select ARC_DSP_HANDLED help DSP extension presence in HW, no support for DSP-enabled userspace applications. We don't save / restore DSP registers and only do some minimal preparations so userspace won't be able to break kernel config ARC_DSP_USERSPACE bool "Support DSP for userspace apps" select ARC_HAS_ACCL_REGS select ARC_DSP_HANDLED help DSP extension presence in HW, support save / restore DSP registers to run DSP-enabled userspace applications endchoice >8-- --- Eugeniy Paltsev ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 4/5] ARC: add support for DSP-enabled userspace applications
On 1/9/20 11:01 AM, Eugeniy Paltsev wrote: > Hi Vineet, > >> From: Vineet Gupta >> On 12/27/19 10:03 AM, Eugeniy Paltsev wrote: >>> To be able to run DSP-enabled userspace applications we need to >>> save and restore following DSP-related registers: >>> At IRQ/exception entry/exit: >>> * ACC0_GLO, ACC0_GHI, DSP_CTRL >>> * ACC0_LO, ACC0_HI (we already save them as r58, r59 pair) >>> At context switch: >>> * DSP_BFLY0, DSP_FFT_CTRL > [snip] >>> + >>> +#ifndef __ASSEMBLY__ >>> + >>> +/* some defines to simplify config sanitize in kernel/setup.c */ >>> +#if defined(CONFIG_ARC_DSP_KERNEL)|| \ >>> +defined(CONFIG_ARC_DSP_USERSPACE) >>> +#define ARC_DSP_HANDLED 1 >>> +#else >>> +#define ARC_DSP_HANDLED 0 >>> +#endif >> This is a really bad idea - u r introducing explicit include dependencies >> which >> can change even outside of arch changes ! >> We've dealt with enough of these problems with current.h, so best to avoid, >> even >> if there is some code clutter. > Hmm, would it be OK if I add this option as a private kconfig option? > I.E (for ARC_DSP_HANDLED): Yes that would be good. -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
