Re: [PATCH v7 05/16] module: make module_memory_{alloc,free} more self-contained
On 29/4/24 14:16, Mike Rapoport wrote: From: "Mike Rapoport (IBM)" Move the logic related to the memory allocation and freeing into module_memory_alloc() and module_memory_free(). Signed-off-by: Mike Rapoport (IBM) --- kernel/module/main.c | 64 +++- 1 file changed, 39 insertions(+), 25 deletions(-) Nice code simplification. Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v5 11/15] arch: make execmem setup available regardless of CONFIG_MODULES
On 22/4/24 11:44, Mike Rapoport wrote: From: "Mike Rapoport (IBM)" execmem does not depend on modules, on the contrary modules use execmem. To make execmem available when CONFIG_MODULES=n, for instance for kprobes, split execmem_params initialization out from arch/*/kernel/module.c and compile it when CONFIG_EXECMEM=y Signed-off-by: Mike Rapoport (IBM) --- arch/arm/kernel/module.c | 43 -- arch/arm/mm/init.c | 45 +++ arch/arm64/kernel/module.c | 140 - arch/arm64/mm/init.c | 140 + arch/loongarch/kernel/module.c | 19 - arch/loongarch/mm/init.c | 21 + arch/mips/kernel/module.c | 22 -- arch/mips/mm/init.c| 23 ++ arch/nios2/kernel/module.c | 20 - arch/nios2/mm/init.c | 21 + arch/parisc/kernel/module.c| 20 - arch/parisc/mm/init.c | 23 +- arch/powerpc/kernel/module.c | 63 --- arch/powerpc/mm/mem.c | 64 +++ arch/riscv/kernel/module.c | 44 --- arch/riscv/mm/init.c | 45 +++ arch/s390/kernel/module.c | 27 --- arch/s390/mm/init.c| 30 +++ arch/sparc/kernel/module.c | 19 - arch/sparc/mm/Makefile | 2 + arch/sparc/mm/execmem.c| 21 + arch/x86/kernel/module.c | 27 --- arch/x86/mm/init.c | 29 +++ 23 files changed, 463 insertions(+), 445 deletions(-) create mode 100644 arch/sparc/mm/execmem.c Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 2/4] KVM: remove unused argument of kvm_handle_hva_range()
On 5/4/24 13:58, Paolo Bonzini wrote: The only user was kvm_mmu_notifier_change_pte(), which is now gone. Signed-off-by: Paolo Bonzini --- virt/kvm/kvm_main.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 4/4] mm: replace set_pte_at_notify() with just set_pte_at()
On 5/4/24 13:58, Paolo Bonzini wrote: With the demise of the .change_pte() MMU notifier callback, there is no notification happening in set_pte_at_notify(). It is a synonym of set_pte_at() and can be replaced with it. Signed-off-by: Paolo Bonzini --- include/linux/mmu_notifier.h | 2 -- kernel/events/uprobes.c | 5 ++--- mm/ksm.c | 4 ++-- mm/memory.c | 7 +-- mm/migrate_device.c | 8 ++-- 5 files changed, 7 insertions(+), 19 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH] arch: mips: bcm63xx: Spello fix in the file clk.c
Hi Bhaskar,
On Fri, Mar 5, 2021 at 3:06 AM Bhaskar Chowdhury wrote:
>
>
>
> s/revelant/relevant/
Let me recommend you this great post explaining why and how you could
improve your patch subject and description:
https://www.freecodecamp.org/news/writing-good-commit-messages-a-practical-guide/#how-to-write-good-commit-messages
Regards,
Phil.
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> arch/mips/bcm63xx/clk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mips/bcm63xx/clk.c b/arch/mips/bcm63xx/clk.c
> index 164115944a7f..5a3e325275d0 100644
> --- a/arch/mips/bcm63xx/clk.c
> +++ b/arch/mips/bcm63xx/clk.c
> @@ -76,7 +76,7 @@ static struct clk clk_enet_misc = {
> };
>
> /*
> - * Ethernet MAC clocks: only revelant on 6358, silently enable misc
> + * Ethernet MAC clocks: only relevant on 6358, silently enable misc
> * clocks
> */
> static void enetx_set(struct clk *clk, int enable)
> --
> 2.30.1
>
Re: [PATCH V2 mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM
On Fri, Mar 5, 2021 at 11:16 AM Rafał Miłecki wrote: > > Hi, > > On 05.03.2021 10:58, Philippe Mathieu-Daudé wrote: > > On Fri, Mar 5, 2021 at 6:55 AM Rafał Miłecki wrote: > >> > >> From: Rafał Miłecki > >> > >> 1. Use meaningful variable names (e.g. "flash_start", "res_size" instead > >> of e.g. "iobase", "end") > >> 2. Always operate on "offset" instead of mix of start, end, size, etc. > > > > "instead of a mix" > > > >> 3. Add helper checking for NVRAM to avoid duplicating code > >> 4. Use "found" variable instead of goto > >> 5. Use simpler checking of offsets and sizes (2 nested loops with > >> trivial check instead of extra function) > > > > This could be a series of trivial patches, why did you choose to make a > > mixed > > bag harder to review? > > It's a subjective thing and often a matter of maintainer taste. I can > say that after contributing to various Linux subsystems. If you split a > similar patch for MTD subsystem you'll get complains about making > changes too small & too hard to review (sic!). Fine. MTD subsystem developers are probably smarter than I'm :) > This isn't a bomb really: 63 insertions(+), 48 deletions(-) Too many changes at once for my brain stack doesn't mean others are willing to review it. But to me that means each time I'll have to pass over it while bisecting or reviewing git history I'll suffer the same overflow. Anyway, matter of taste as you said. > > That said I admit I don't know MIPS tree habits. Thomas: do you prefer > smaller patches in case like this?
Re: [PATCH 2/2] MIPS: Loongson64: Move loongson_system_configuration to loongson.h
Hi,
On Thu, Mar 4, 2021 at 5:35 PM Qing Zhang wrote:
>
> The purpose of separating loongson_system_configuration from boot_param.h
> is to keep the other structure consistent with the firmware.
This is supposed to be a trivial patch, but the description actually
confuses me.
Why is the move out of "boot_param.h" keeping it consistent with fw?
> Signed-off-by: Jiaxun Yang
> Signed-off-by: Qing Zhang
> ---
> .../include/asm/mach-loongson64/boot_param.h | 18 --
> .../include/asm/mach-loongson64/loongson.h | 18 ++
> drivers/irqchip/irq-loongson-liointc.c | 2 +-
> 3 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h
> b/arch/mips/include/asm/mach-loongson64/boot_param.h
> index 1c1cdf57137e..035b1a69e2d0 100644
> --- a/arch/mips/include/asm/mach-loongson64/boot_param.h
> +++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
> @@ -198,24 +198,6 @@ enum loongson_bridge_type {
> VIRTUAL = 3
> };
>
> -struct loongson_system_configuration {
> - u32 nr_cpus;
> - u32 nr_nodes;
> - int cores_per_node;
> - int cores_per_package;
> - u16 boot_cpu_id;
> - u16 reserved_cpus_mask;
> - enum loongson_cpu_type cputype;
> - enum loongson_bridge_type bridgetype;
> - u64 restart_addr;
> - u64 poweroff_addr;
> - u64 suspend_addr;
> - u64 vgabios_addr;
> - u32 dma_mask_bits;
> - u64 workarounds;
> - void (*early_config)(void);
> -};
> -
> extern struct efi_memory_map_loongson *loongson_memmap;
> extern struct loongson_system_configuration loongson_sysconf;
>
> diff --git a/arch/mips/include/asm/mach-loongson64/loongson.h
> b/arch/mips/include/asm/mach-loongson64/loongson.h
> index ac1c20e172a2..6189deb188cf 100644
> --- a/arch/mips/include/asm/mach-loongson64/loongson.h
> +++ b/arch/mips/include/asm/mach-loongson64/loongson.h
> @@ -12,6 +12,24 @@
> #include
> #include
>
> +/* machine-specific boot configuration */
> +struct loongson_system_configuration {
> + u32 nr_cpus;
> + u32 nr_nodes;
> + int cores_per_node;
> + int cores_per_package;
> + u16 boot_cpu_id;
> + u16 reserved_cpus_mask;
> + enum loongson_cpu_type cputype;
> + enum loongson_bridge_type bridgetype;
> + u64 restart_addr;
> + u64 poweroff_addr;
> + u64 suspend_addr;
> + u64 vgabios_addr;
> + u32 dma_mask_bits;
> + u64 workarounds;
> + void (*early_config)(void);
> +};
>
> /* machine-specific reboot/halt operation */
> extern void mach_prepare_reboot(void);
> diff --git a/drivers/irqchip/irq-loongson-liointc.c
> b/drivers/irqchip/irq-loongson-liointc.c
> index 09b91b81851c..249566a23cc4 100644
> --- a/drivers/irqchip/irq-loongson-liointc.c
> +++ b/drivers/irqchip/irq-loongson-liointc.c
> @@ -16,7 +16,7 @@
> #include
> #include
>
> -#include
> +#include
>
> #define LIOINTC_CHIP_IRQ 32
> #define LIOINTC_NUM_PARENT 4
> --
> 2.20.1
>
Re: [PATCH V2 mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM
Hi Rafał, On Fri, Mar 5, 2021 at 6:55 AM Rafał Miłecki wrote: > > From: Rafał Miłecki > > 1. Use meaningful variable names (e.g. "flash_start", "res_size" instead >of e.g. "iobase", "end") > 2. Always operate on "offset" instead of mix of start, end, size, etc. "instead of a mix" > 3. Add helper checking for NVRAM to avoid duplicating code > 4. Use "found" variable instead of goto > 5. Use simpler checking of offsets and sizes (2 nested loops with >trivial check instead of extra function) This could be a series of trivial patches, why did you choose to make a mixed bag harder to review? > > This change has been tested on BCM4706. Updated code checks the same > offsets as before. Driver still finds & copies NVRAM content. > > Signed-off-by: Rafał Miłecki > --- > V2: Fix comment to match actual function name > Reported-by: kernel test robot > --- > drivers/firmware/broadcom/bcm47xx_nvram.c | 111 -- > 1 file changed, 63 insertions(+), 48 deletions(-)
Re: [PATCH] qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute
On 2/11/21 8:42 PM, Nathan Chancellor wrote:
> fw_cfg_showrev() is called by an indirect call in kobj_attr_show(),
> which violates clang's CFI checking because fw_cfg_showrev()'s second
> parameter is 'struct attribute', whereas the ->show() member of 'struct
> kobj_structure' expects the second parameter to be of type 'struct
> kobj_attribute'.
>
> $ cat /sys/firmware/qemu_fw_cfg/rev
> 3
>
> $ dmesg | grep "CFI failure"
> [ 26.016832] CFI failure (target: fw_cfg_showrev+0x0/0x8):
>
> Fix this by converting fw_cfg_rev_attr to 'struct kobj_attribute' where
> this would have been caught automatically by the incompatible pointer
> types compiler warning. Update fw_cfg_showrev() accordingly.
>
> Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg
> device")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1299
> Signed-off-by: Nathan Chancellor
> ---
> drivers/firmware/qemu_fw_cfg.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 5/5] MIPS: SGI-IP27: fix spelling in Copyright
On Tue, Feb 23, 2021 at 1:33 PM Maciej W. Rozycki wrote: > On Tue, 23 Feb 2021, Philippe Mathieu-Daudé wrote: > > > > diff --git a/arch/mips/sgi-ip27/ip27-timer.c > > > b/arch/mips/sgi-ip27/ip27-timer.c > > > index 79c434fece52..444b5e0e935f 100644 > > > --- a/arch/mips/sgi-ip27/ip27-timer.c > > > +++ b/arch/mips/sgi-ip27/ip27-timer.c > > > @@ -1,7 +1,7 @@ > > > // SPDX-License-Identifier: GPL-2.0 > > > /* > > > - * Copytight (C) 1999, 2000, 05, 06 Ralf Baechle (r...@linux-mips.org) > > > - * Copytight (C) 1999, 2000 Silicon Graphics, Inc. > > > + * Copyright (C) 1999, 2000, 05, 06 Ralf Baechle (r...@linux-mips.org) > > > > If the email isn't valid anymore, why keep it? > > As I noted in an earlier reply and Kurt further confirmed site recovery > is under way. Great. Alternatively the authorship is preserved without the author email (but IANAL): Copyright (C) 1999, 2000, 05, 06 Ralf Baechle > > Maciej
Re: [PATCH 4/5] arch: mips: remove dead references
On Mon, Feb 22, 2021 at 5:22 PM Lukas Bulwahn wrote: > > The domain lookup for linux-mips.org fails for quite some time now. > Further, the two links: > > http://decstation.unix-ag.org/ https://web.archive.org/web/20070609185805/http://decstation.unix-ag.org/ > http://www.computer-refuge.org/classiccmp/ftp.digital.com/pub/DEC/TriAdd/ > > refer to old webpages or contain no further technical information. > > Remove all those dead references. > > Signed-off-by: Lukas Bulwahn > --- > arch/mips/Kconfig | 8 +--- > arch/mips/jazz/Kconfig| 12 +++- > tools/include/nolibc/nolibc.h | 3 +-- > 3 files changed, 5 insertions(+), 18 deletions(-)
Re: [PATCH 5/5] MIPS: SGI-IP27: fix spelling in Copyright
On Mon, Feb 22, 2021 at 5:22 PM Lukas Bulwahn wrote: > > This is a Copyright line, and just a typo slipped through. > > Signed-off-by: Lukas Bulwahn > --- > arch/mips/sgi-ip27/ip27-timer.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/sgi-ip27/ip27-timer.c b/arch/mips/sgi-ip27/ip27-timer.c > index 79c434fece52..444b5e0e935f 100644 > --- a/arch/mips/sgi-ip27/ip27-timer.c > +++ b/arch/mips/sgi-ip27/ip27-timer.c > @@ -1,7 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0 > /* > - * Copytight (C) 1999, 2000, 05, 06 Ralf Baechle (r...@linux-mips.org) > - * Copytight (C) 1999, 2000 Silicon Graphics, Inc. > + * Copyright (C) 1999, 2000, 05, 06 Ralf Baechle (r...@linux-mips.org) If the email isn't valid anymore, why keep it? > + * Copyright (C) 1999, 2000 Silicon Graphics, Inc. > */ > #include > #include > -- > 2.17.1 >
Re: [PATCH 3/5] arch: mips: update references to current linux-mips list
On Mon, Feb 22, 2021 at 5:22 PM Lukas Bulwahn wrote: > > The linux-mips mailing list now lives at kernel.org. Update all references > in the kernel tree. > > Signed-off-by: Lukas Bulwahn > --- > arch/mips/kernel/r4k-bugs64.c | 2 +- > arch/mips/lib/iomap-pci.c | 2 +- > arch/mips/sgi-ip32/ip32-irq.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 2/5] MAINTAINERS: remove linux-mips.org references
On Mon, Feb 22, 2021 at 5:22 PM Lukas Bulwahn wrote: > > The domain lookup for linux-mips.org fails for quite some time now. Hence, > webpages, the patchwork instance and Ralf Baechle's email there is not > reachable anymore. > > Remove all references of webpages from linux-mips.org in MAINTAINERS, and > refer to the kernel.org's linux-mips patchwork instance instead. > > Signed-off-by: Lukas Bulwahn > --- > MAINTAINERS | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index e949e561867d..703a50183301 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4980,7 +4980,6 @@ DECSTATION PLATFORM SUPPORT > M: "Maciej W. Rozycki" > L: linux-m...@vger.kernel.org > S: Maintained > -W: http://www.linux-mips.org/wiki/DECstation Why not use the web archive? The information is still valuable. https://web.archive.org/web/20190704000315/https://www.linux-mips.org/wiki/DECstation > F: arch/mips/dec/ > F: arch/mips/include/asm/dec/ > F: arch/mips/include/asm/mach-dec/ ...
Re: [PATCH] MIPS: boot: Fix unaligned access with CONFIG_MIPS_RAW_APPENDED_DTB
On Thu, Dec 17, 2020 at 12:41 AM Paul Cercueil wrote:
>
> The compressed payload is not necesarily 4-byte aligned, at least when
> compiling with Clang. In that case, the 4-byte value appended to the
> compressed payload that corresponds to the uncompressed kernel image
> size must be read using get_unaligned_le().
>
> This fixes Clang-built kernels not booting on MIPS (tested on a Ingenic
> JZ4770 board).
>
> Fixes: b8f54f2cde78 ("MIPS: ZBOOT: copy appended dtb to the end of the
> kernel")
> Cc: # v4.7
> Signed-off-by: Paul Cercueil
> ---
> arch/mips/boot/compressed/decompress.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH] MIPS: Kconfig: fix a few trivial spelling mistakes
On Wed, Oct 28, 2020 at 9:01 PM Colin King wrote: > > From: Colin Ian King > > There are a few spelling mistakes in the Kconfig, fix these. > > Signed-off-by: Colin Ian King > --- > arch/mips/Kconfig | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH] MIPS: malta: remove unused header file
On Sun, Sep 20, 2020 at 11:09 PM Thomas Bogendoerfer
wrote:
>
> Remove unused heasder file asm/mach-malta/malta-pm.h.
Typo "header".
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> arch/mips/include/asm/mach-malta/malta-pm.h | 33
> -
> 1 file changed, 33 deletions(-)
> delete mode 100644 arch/mips/include/asm/mach-malta/malta-pm.h
>
> diff --git a/arch/mips/include/asm/mach-malta/malta-pm.h
> b/arch/mips/include/asm/mach-malta/malta-pm.h
> deleted file mode 100644
> index 2a5146d79313..
> --- a/arch/mips/include/asm/mach-malta/malta-pm.h
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-or-later */
> -/*
> - * Copyright (C) 2014 Imagination Technologies
> - * Author: Paul Burton
> - */
> -
> -#ifndef __ASM_MIPS_MACH_MALTA_PM_H__
> -#define __ASM_MIPS_MACH_MALTA_PM_H__
> -
> -#include
> -
> -#ifdef CONFIG_MIPS_MALTA_PM
> -
> -/**
> - * mips_pm_suspend - enter a suspend state
> - * @state: the state to enter, one of PIIX4_FUNC3IO_PMCNTRL_SUS_TYP_*
> - *
> - * Enters a suspend state via the Malta's PIIX4. If the state to be entered
> - * is one which loses context (eg. SOFF) then this function will never
> - * return.
> - */
> -extern int mips_pm_suspend(unsigned state);
> -
> -#else /* !CONFIG_MIPS_MALTA_PM */
> -
> -static inline int mips_pm_suspend(unsigned state)
> -{
> - return -EINVAL;
> -}
> -
> -#endif /* !CONFIG_MIPS_MALTA_PM */
> -
> -#endif /* __ASM_MIPS_MACH_MALTA_PM_H__ */
> --
> 2.16.4
>
Re: [PATCH v3 06/15] MIPS: generic: Allow boards to set system type
On Sun, Sep 6, 2020 at 9:31 PM Paul Cercueil wrote:
>
> Check for the (already existing) "system_type" variable in the
> get_system_type() function. If non-NULL, return it as the system type.
Nitpick: It is not already "existing", simply declared in asm/bootinfo.h.
>
> Signed-off-by: Paul Cercueil
> ---
>
> Notes:
> v2: Instead of adding a .get_system_type callback to the mips_machine
> struct, the boards now simply override the "system_type" variable
> when they want to set a custom one.
>
> v3: No change
>
> arch/mips/generic/proc.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/mips/generic/proc.c b/arch/mips/generic/proc.c
> index 4c992809cc3f..cce2fde219a3 100644
> --- a/arch/mips/generic/proc.c
> +++ b/arch/mips/generic/proc.c
> @@ -8,11 +8,16 @@
>
> #include
>
> +char *system_type;
> +
> const char *get_system_type(void)
> {
> const char *str;
> int err;
>
> + if (system_type)
> + return system_type;
> +
> err = of_property_read_string(of_root, "model", );
> if (!err)
> return str;
> --
> 2.28.0
>
Re: [PATCH 4.19 66/81] MIPS: Disable Loongson MMI instructions for kernel build
On Thu, Sep 3, 2020 at 11:28 AM Greg Kroah-Hartman wrote: > > On Wed, Aug 26, 2020 at 02:06:28PM -0700, Guenter Roeck wrote: > > Hi, > > > > On Wed, Oct 16, 2019 at 02:51:17PM -0700, Greg Kroah-Hartman wrote: > > > From: Paul Burton > > > > > > commit 2f2b4fd674cadd8c6b40eb629e140a14db4068fd upstream. > > > > > > GCC 9.x automatically enables support for Loongson MMI instructions when > > > using some -march= flags, and then errors out when -msoft-float is > > > specified with: > > > > > > cc1: error: ‘-mloongson-mmi’ must be used with ‘-mhard-float’ > > > > > > The kernel shouldn't be using these MMI instructions anyway, just as it > > > doesn't use floating point instructions. Explicitly disable them in > > > order to fix the build with GCC 9.x. > > > > > > > I still see this problem when trying to compile fuloong2e_defconfig with > > gcc 9.x or later. Reason seems to be that the patch was applied to > > arch/mips/loongson64/Platform, but fuloong2e_defconfig uses > > arch/mips/loongson2ef/Platform. > > > > Am I missing something ? > > I don't know, sorry, that would be something that Paul understands. > > Paul? Cc'ing Thomas who now maintains this.
Re: [PATCH v4 4/5] MIPS: BCM63xx: refactor board declarations
On Wed, Aug 12, 2020 at 9:53 AM Álvaro Fernández Rojas wrote: > > Current board declarations are a mess. Let's put some order and make them > follow the same structure. What a mess indeed. Patch easier to review using 'git-diff --ignore-all-space'. Reviewed-by: Philippe Mathieu-Daudé > > Signed-off-by: Álvaro Fernández Rojas > Acked-by: Florian Fainelli > --- > v4: split license change to a new patch. > v3: no changes. > v2: switch to SPDX license identifier. > > arch/mips/bcm63xx/boards/board_bcm963xx.c | 615 +++--- > 1 file changed, 305 insertions(+), 310 deletions(-)
Re: [PATCH v4 3/5] MIPS: BCM63xx: enable EHCI for DWV-S0 board
On Wed, Aug 12, 2020 at 9:53 AM Álvaro Fernández Rojas
wrote:
>
> BCM6358 SoCs have OHCI and EHCI controllers that share the same USB ports.
> Therefore, the board should also have EHCI enabled.
>
> Signed-off-by: Álvaro Fernández Rojas
> Acked-by: Florian Fainelli
v3 already reviewed, again:
Reviewed-by: Philippe Mathieu-Daudé
> ---
> v4: no changes.
> v3: Reword commit description to avoid possible confusions.
> v2: no changes.
>
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> index 45f1bc437245..ac9570b66f37 100644
> --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> @@ -645,6 +645,7 @@ static struct board_info __initdata board_DWVS0 = {
> },
>
> .has_ohci0 = 1,
> + .has_ehci0 = 1,
> };
> #endif /* CONFIG_BCM63XX_CPU_6358 */
>
> --
> 2.28.0
>
Re: [PATCH v4 2/5] MIPS: BCM63xx: remove EHCI from BCM6348 boards
On Wed, Aug 12, 2020 at 9:53 AM Álvaro Fernández Rojas
wrote:
>
> There's no EHCI controller on BCM6348.
>
> Signed-off-by: Álvaro Fernández Rojas
> Acked-by: Florian Fainelli
v3 already reviewed, again:
Reviewed-by: Philippe Mathieu-Daudé
> ---
> v4: no changes.
> v3: no changes.
> v2: no changes.
>
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> index 744aa16bab12..45f1bc437245 100644
> --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> @@ -285,7 +285,6 @@ static struct board_info __initdata board_96348gw_10 = {
>
> .has_ohci0 = 1,
> .has_pccard = 1,
> - .has_ehci0 = 1,
>
> .leds = {
> {
> @@ -338,7 +337,6 @@ static struct board_info __initdata board_96348gw_11 = {
>
> .has_ohci0 = 1,
> .has_pccard = 1,
> - .has_ehci0 = 1,
>
> .leds = {
> {
> @@ -441,7 +439,6 @@ static struct board_info __initdata board_FAST2404 = {
>
> .has_ohci0 = 1,
> .has_pccard = 1,
> - .has_ehci0 = 1,
> };
>
> static struct board_info __initdata board_rta1025w_16 = {
> --
> 2.28.0
>
Re: [PATCH v3 4/4] MIPS: BCM63xx: refactor board declarations
On Tue, Aug 11, 2020 at 6:48 PM Philippe Mathieu-Daudé wrote:
> On Tue, Aug 11, 2020 at 5:01 PM Álvaro Fernández Rojas
> wrote:
> >
> > Current board declarations are a mess. Let's put some order and make them
> > follow the same structure. Also board declarations tabs.
> > Switch to SPDX license identifier.
> >
> > Signed-off-by: Álvaro Fernández Rojas
> > Acked-by: Florian Fainelli
> > ---
> > v3: no changes.
> > v2: switch to SPDX license identifier.
> >
> > arch/mips/bcm63xx/boards/board_bcm963xx.c | 620 +++---
> > 1 file changed, 306 insertions(+), 314 deletions(-)
> >
> > diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> > b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> > index ac9570b66f37..01aff80a5967 100644
> > --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> > +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> > @@ -1,8 +1,5 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > /*
> > - * This file is subject to the terms and conditions of the GNU General
> > Public
> > - * License. See the file "COPYING" in the main directory of this archive
> > - * for more details.
> > - *
>
> Sorry for missing this earlier and being picky, but doing license
> change and code
> change in the same commit is not recommended.
Rationale for this is you might revert a code change, but you
certainly don't want to revert a license change.
> Adding a SPDX tag is easy to
> review, removing a license is another story. IANAL so up to the maintainer...
>
> > * Copyright (C) 2008 Maxime Bizon
> > * Copyright (C) 2008 Florian Fainelli
> > */
> > @@ -41,30 +38,28 @@ static struct board_info board;
> > */
> > #ifdef CONFIG_BCM63XX_CPU_3368
> > static struct board_info __initdata board_cvg834g = {
> > - .name = "CVG834G_E15R3921",
> > - .expected_cpu_id= 0x3368,
> > + .name = "CVG834G_E15R3921",
> > + .expected_cpu_id = 0x3368,
> >
> > - .has_uart0 = 1,
> > - .has_uart1 = 1,
> > -
> > - .has_enet0 = 1,
> > - .has_pci= 1,
> > + .ephy_reset_gpio = 36,
> > + .ephy_reset_gpio_flags = GPIOF_INIT_HIGH,
> > + .has_pci = 1,
> > + .has_uart0 = 1,
> > + .has_uart1 = 1,
> >
> > + .has_enet0 = 1,
> > .enet0 = {
> > - .has_phy= 1,
> > - .use_internal_phy = 1,
> > + .has_phy = 1,
> > + .use_internal_phy = 1,
> > },
> >
> > .leds = {
> > {
> > - .name = "CVG834G:green:power",
> > - .gpio = 37,
> > + .name = "CVG834G:green:power",
> > + .gpio = 37,
> > .default_trigger= "default-on",
> > },
> > },
> > -
> > - .ephy_reset_gpio= 36,
> > - .ephy_reset_gpio_flags = GPIOF_INIT_HIGH,
> > };
> > #endif /* CONFIG_BCM63XX_CPU_3368 */
> >
> > @@ -73,44 +68,44 @@ static struct board_info __initdata board_cvg834g = {
> > */
> > #ifdef CONFIG_BCM63XX_CPU_6328
> > static struct board_info __initdata board_96328avng = {
> > - .name = "96328avng",
> > - .expected_cpu_id= 0x6328,
> > + .name = "96328avng",
> > + .expected_cpu_id = 0x6328,
> >
> > - .has_uart0 = 1,
> > - .has_pci= 1,
> > - .has_usbd = 0,
> > + .has_pci = 1,
> > + .has_uart0 = 1,
> >
> > + .has_usbd = 0,
> > .usbd = {
> > - .use_fullspeed = 0,
> > - .port_no= 0,
> > + .use_fullspeed = 0,
> > + .port_no = 0,
> > },
> >
> > .leds = {
> > {
> > - .name = "96328avng::ppp-fail",
> > - .gpio = 2,
> > - .active_low = 1,
> > + .name = "96328avng::ppp-fail",
> > +
Re: [PATCH v3 4/4] MIPS: BCM63xx: refactor board declarations
On Tue, Aug 11, 2020 at 5:01 PM Álvaro Fernández Rojas
wrote:
>
> Current board declarations are a mess. Let's put some order and make them
> follow the same structure. Also board declarations tabs.
> Switch to SPDX license identifier.
>
> Signed-off-by: Álvaro Fernández Rojas
> Acked-by: Florian Fainelli
> ---
> v3: no changes.
> v2: switch to SPDX license identifier.
>
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 620 +++---
> 1 file changed, 306 insertions(+), 314 deletions(-)
>
> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> index ac9570b66f37..01aff80a5967 100644
> --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> @@ -1,8 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> /*
> - * This file is subject to the terms and conditions of the GNU General Public
> - * License. See the file "COPYING" in the main directory of this archive
> - * for more details.
> - *
Sorry for missing this earlier and being picky, but doing license
change and code
change in the same commit is not recommended. Adding a SPDX tag is easy to
review, removing a license is another story. IANAL so up to the maintainer...
> * Copyright (C) 2008 Maxime Bizon
> * Copyright (C) 2008 Florian Fainelli
> */
> @@ -41,30 +38,28 @@ static struct board_info board;
> */
> #ifdef CONFIG_BCM63XX_CPU_3368
> static struct board_info __initdata board_cvg834g = {
> - .name = "CVG834G_E15R3921",
> - .expected_cpu_id= 0x3368,
> + .name = "CVG834G_E15R3921",
> + .expected_cpu_id = 0x3368,
>
> - .has_uart0 = 1,
> - .has_uart1 = 1,
> -
> - .has_enet0 = 1,
> - .has_pci= 1,
> + .ephy_reset_gpio = 36,
> + .ephy_reset_gpio_flags = GPIOF_INIT_HIGH,
> + .has_pci = 1,
> + .has_uart0 = 1,
> + .has_uart1 = 1,
>
> + .has_enet0 = 1,
> .enet0 = {
> - .has_phy= 1,
> - .use_internal_phy = 1,
> + .has_phy = 1,
> + .use_internal_phy = 1,
> },
>
> .leds = {
> {
> - .name = "CVG834G:green:power",
> - .gpio = 37,
> + .name = "CVG834G:green:power",
> + .gpio = 37,
> .default_trigger= "default-on",
> },
> },
> -
> - .ephy_reset_gpio= 36,
> - .ephy_reset_gpio_flags = GPIOF_INIT_HIGH,
> };
> #endif /* CONFIG_BCM63XX_CPU_3368 */
>
> @@ -73,44 +68,44 @@ static struct board_info __initdata board_cvg834g = {
> */
> #ifdef CONFIG_BCM63XX_CPU_6328
> static struct board_info __initdata board_96328avng = {
> - .name = "96328avng",
> - .expected_cpu_id= 0x6328,
> + .name = "96328avng",
> + .expected_cpu_id = 0x6328,
>
> - .has_uart0 = 1,
> - .has_pci= 1,
> - .has_usbd = 0,
> + .has_pci = 1,
> + .has_uart0 = 1,
>
> + .has_usbd = 0,
> .usbd = {
> - .use_fullspeed = 0,
> - .port_no= 0,
> + .use_fullspeed = 0,
> + .port_no = 0,
> },
>
> .leds = {
> {
> - .name = "96328avng::ppp-fail",
> - .gpio = 2,
> - .active_low = 1,
> + .name = "96328avng::ppp-fail",
> + .gpio = 2,
> + .active_low = 1,
> },
> {
> - .name = "96328avng::power",
> - .gpio = 4,
> - .active_low = 1,
> + .name = "96328avng::power",
> + .gpio = 4,
> + .active_low = 1,
> .default_trigger = "default-on",
> },
> {
> - .name = "96328avng::power-fail",
> - .gpio = 8,
> - .active_low = 1,
> + .name = "96328avng::power-fail",
> + .gpio = 8,
> + .active_low = 1,
> },
> {
> - .name = "96328avng::wps",
> - .gpio = 9,
> - .active_low = 1,
> + .name = "96328avng::wps",
> + .gpio = 9,
> + .active_low = 1,
> },
> {
> -
Re: [PATCH v3 2/4] MIPS: BCM63xx: remove EHCI from BCM6348 boards
On Tue, Aug 11, 2020 at 5:05 PM Álvaro Fernández Rojas
wrote:
>
> There's no EHCI controller on BCM6348.
>
> Signed-off-by: Álvaro Fernández Rojas
> Acked-by: Florian Fainelli
Reviewed-by: Philippe Mathieu-Daudé
> ---
> v3: no changes.
> v2: no changes.
>
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> index 744aa16bab12..45f1bc437245 100644
> --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> @@ -285,7 +285,6 @@ static struct board_info __initdata board_96348gw_10 = {
>
> .has_ohci0 = 1,
> .has_pccard = 1,
> - .has_ehci0 = 1,
>
> .leds = {
> {
> @@ -338,7 +337,6 @@ static struct board_info __initdata board_96348gw_11 = {
>
> .has_ohci0 = 1,
> .has_pccard = 1,
> - .has_ehci0 = 1,
>
> .leds = {
> {
> @@ -441,7 +439,6 @@ static struct board_info __initdata board_FAST2404 = {
>
> .has_ohci0 = 1,
> .has_pccard = 1,
> - .has_ehci0 = 1,
> };
>
> static struct board_info __initdata board_rta1025w_16 = {
> --
> 2.28.0
>
Re: [PATCH v3 3/4] MIPS: BCM63xx: enable EHCI for DWV-S0 board
On Tue, Aug 11, 2020 at 5:01 PM Álvaro Fernández Rojas
wrote:
>
> BCM6358 SoCs have OHCI and EHCI controllers that share the same USB ports.
> Therefore, the board should also have EHCI enabled.
>
> Signed-off-by: Álvaro Fernández Rojas
> Acked-by: Florian Fainelli
Reviewed-by: Philippe Mathieu-Daudé
> ---
> v3: Reword commit description to avoid possible confusions.
Thanks!
> v2: no changes.
>
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> index 45f1bc437245..ac9570b66f37 100644
> --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> @@ -645,6 +645,7 @@ static struct board_info __initdata board_DWVS0 = {
> },
>
> .has_ohci0 = 1,
> + .has_ehci0 = 1,
> };
> #endif /* CONFIG_BCM63XX_CPU_6358 */
>
> --
> 2.28.0
>
Re: [PATCH v2 3/4] MIPS: BCM63xx: enable EHCI for DWV-S0 board
Hi Florian, On Tue, Aug 11, 2020 at 4:33 AM Florian Fainelli wrote: > On 8/9/2020 11:49 AM, Philippe Mathieu-Daudé wrote: > > Hi Álvaro, > > > > On Fri, Aug 7, 2020 at 12:05 PM Álvaro Fernández Rojas > > wrote: > >> > >> EHCI and OHCI share the same USB ports. Therefore, if the board has OHCI > >> it should also have EHCI. > > > > This statement isn't correct. OHCI doesn't imply EHCI... > > (although the opposite is almost always true). > > > > Now per 6358-PB01-R the bcm6358 indeed has a EHCI controller. > > > > Do you mind rewording the commit description? > > Is not it that a single USB port is used and we need the EHCI controller > active in order for the correct speed negotiation to occur? Yes. What sounds odd is "if the board has OHCI it should also have EHCI." This is true for this particular board because its chipset is a bcm6358, but I'm worried it might later confuse other developers. For example the bcm6348 has a OHCI controller, but that doesn't imply its port can be used as EHCI. Regards, Phil. > -- > Florian
Re: [PATCH v2 3/4] MIPS: BCM63xx: enable EHCI for DWV-S0 board
Hi Álvaro,
On Fri, Aug 7, 2020 at 12:05 PM Álvaro Fernández Rojas
wrote:
>
> EHCI and OHCI share the same USB ports. Therefore, if the board has OHCI
> it should also have EHCI.
This statement isn't correct. OHCI doesn't imply EHCI...
(although the opposite is almost always true).
Now per 6358-PB01-R the bcm6358 indeed has a EHCI controller.
Do you mind rewording the commit description?
Regards,
Phil.
>
> Signed-off-by: Álvaro Fernández Rojas
> ---
> v2: no changes.
>
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> index 45f1bc437245..ac9570b66f37 100644
> --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> @@ -645,6 +645,7 @@ static struct board_info __initdata board_DWVS0 = {
> },
>
> .has_ohci0 = 1,
> + .has_ehci0 = 1,
> };
> #endif /* CONFIG_BCM63XX_CPU_6358 */
>
> --
> 2.27.0
>
Re: [PATCH v2 1/4] MIPS: BCM63xx: remove duplicated new lines
On Fri, Aug 7, 2020 at 12:06 PM Álvaro Fernández Rojas
wrote:
>
> There are 3 duplicated new lines, let's remove them.
>
> Signed-off-by: Álvaro Fernández Rojas
Reviewed-by: Philippe Mathieu-Daudé
=)
> ---
> v2: no changes.
>
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> index 230bf27c1fb8..744aa16bab12 100644
> --- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> @@ -32,7 +32,6 @@
>
> #include
>
> -
> #define HCS_OFFSET_128K0x2
>
> static struct board_info board;
> @@ -337,7 +336,6 @@ static struct board_info __initdata board_96348gw_11 = {
> .force_duplex_full = 1,
> },
>
> -
> .has_ohci0 = 1,
> .has_pccard = 1,
> .has_ehci0 = 1,
> @@ -580,7 +578,6 @@ static struct board_info __initdata board_96358vw2 = {
> .force_duplex_full = 1,
> },
>
> -
> .has_ohci0 = 1,
> .has_pccard = 1,
> .has_ehci0 = 1,
> --
> 2.27.0
>
Re: [PATCH] CREDITS: remove link: http://www.andante.org
Hi Alexander, On Tue, Jul 14, 2020 at 10:18 PM Alexander A. Klimov wrote: > > Rationale: > A completely white page with just an in the . > > Signed-off-by: Alexander A. Klimov > --- > Yes, I noted that some of the links removed by these "CREDITS: remove link:" > patches have email addresses with the same domain nearby. > > Don't worry, I'll take care of them together with all other > dead email addresses - but not right now. > > > CREDITS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/CREDITS b/CREDITS > index 0787b5872906..ed58df9db15b 100644 > --- a/CREDITS > +++ b/CREDITS > @@ -4113,7 +4113,6 @@ S: Japan > > N: Eric Youngdale > E: e...@andante.org > -W: http://www.andante.org Similarly, this historical information is still available in the Internet Archives: https://web.archive.org/web/20080928071628/http://www.andante.org:80/scsi.html There are thousands of outdated URLs in the source and documentation which are still useful today, in particular the references to datasheets. I consider these outdated links as still valuable source information, and find removing them a loss. My 2 cents. Regards, Phil. > D: General kernel hacker > D: SCSI iso9660 and ELF > S: 6389 Hawk View Lane > -- > 2.27.0 >
Re: [PATCH] CREDITS: remove link http://www.mathematik.uni-stuttgart.de/~floeff
Hi Alexander, On Tue, Jul 14, 2020 at 10:18 PM Alexander A. Klimov wrote: > > Rationale: > The way it redirects looks like a fallback from a dead URL to a generic one. > > Signed-off-by: Alexander A. Klimov > --- > Yes, I noted that some of the links removed by these "CREDITS: remove link:" > patches have email addresses with the same domain nearby. > > Don't worry, I'll take care of them together with all other > dead email addresses - but not right now. > > > CREDITS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/CREDITS b/CREDITS > index 0787b5872906..151083e4245d 100644 > --- a/CREDITS > +++ b/CREDITS > @@ -2241,7 +2241,6 @@ S: France > > N: Siegfried "Frieder" Loeffler (dg1sek) > E: flo...@tunix.mathematik.uni-stuttgart.de, f...@lf.net > -W: http://www.mathematik.uni-stuttgart.de/~floeff One can still use the Internet Archives: https://web.archive.org/web/20070918070711/http://www.mathematik.uni-stuttgart.de:80/~floeff/ > D: Busmaster driver for HP 10/100 Mbit Network Adapters > S: University of Stuttgart, Germany and > S: Ecole Nationale Superieure des Telecommunications, Paris > -- > 2.27.0 >
Re: [PATCH 2/2] clk: bcm63xx-gate: add BCM6318 support
On Wed, Jun 10, 2020 at 5:32 PM Florian Fainelli wrote:
> On 6/10/2020 1:29 AM, Philippe Mathieu-Daudé wrote:
> > Hi,
> >
> > On Wed, Jun 10, 2020 at 8:13 AM Álvaro Fernández Rojas
> > wrote:
> >>
> >> Hi Florian,
> >>
> >>> El 10 jun 2020, a las 4:27, Florian Fainelli
> >>> escribió:
> >>>
> >>>
> >>>
> >>> On 6/9/2020 4:30 AM, Álvaro Fernández Rojas wrote:
> >>>> +static const struct clk_bcm63xx_table_entry bcm6318_clocks[] = {
> >>>> +{ .name = "adsl_asb", .bit = 0, },
> >>>> +{ .name = "usb_asb", .bit = 1, },
> >>>> +{ .name = "mips_asb", .bit = 2, },
> >>>> +{ .name = "pcie_asb", .bit = 3, },
> >>>> +{ .name = "phymips_asb", .bit = 4, },
> >>>> +{ .name = "robosw_asb", .bit = 5, },
> >>>> +{ .name = "sar_asb", .bit = 6, },
> >>>> +{ .name = "sdr_asb", .bit = 7, },
> >>>> +{ .name = "swreg_asb", .bit = 8, },
> >>>> +{ .name = "periph_asb", .bit = 9, },
> >>>> +{ .name = "cpubus160", .bit = 10, },
> >>>> +{ .name = "adsl", .bit = 11, },
> >>>> +{ .name = "sar124", .bit = 12, },
> >>>
> >>> Nit: this should be sar125
> >>
> >> Nice catch, I will fix this in v2.
> >>
> >>>
> >>>> +{ .name = "mips", .bit = 13, .flags = CLK_IS_CRITICAL, },
> >>>> +{ .name = "pcie", .bit = 14, },
> >>>> +{ .name = "robosw250", .bit = 16, },
> >>>> +{ .name = "robosw025", .bit = 17, },
> >>>> +{ .name = "sdr", .bit = 19, .flags = CLK_IS_CRITICAL, },
> >>>> +{ .name = "usb", .bit = 20, },
> >>>
> >>> This should probably be "usbd" to indicate this is the USB device clock
> >>> (not host)
> >>
> >> Ok, I will change it. I got confused by the fact that both (usbd and usbh)
> >> were present on 6318_map_part.h:
> >> #define USBD_CLK_EN (1 << 20)
> >> #define USBH_CLK_EN (1 << 20)
> >
> > Is there a datasheet to verify that?
>
> Not a public one, but I can confirm this is correct given the internal
> datasheet.
OK thank you Florian.
> --
> Florian
Re: [PATCH 2/2] clk: bcm63xx-gate: add BCM6318 support
Hi,
On Wed, Jun 10, 2020 at 8:13 AM Álvaro Fernández Rojas
wrote:
>
> Hi Florian,
>
> > El 10 jun 2020, a las 4:27, Florian Fainelli
> > escribió:
> >
> >
> >
> > On 6/9/2020 4:30 AM, Álvaro Fernández Rojas wrote:
> >> +static const struct clk_bcm63xx_table_entry bcm6318_clocks[] = {
> >> +{ .name = "adsl_asb", .bit = 0, },
> >> +{ .name = "usb_asb", .bit = 1, },
> >> +{ .name = "mips_asb", .bit = 2, },
> >> +{ .name = "pcie_asb", .bit = 3, },
> >> +{ .name = "phymips_asb", .bit = 4, },
> >> +{ .name = "robosw_asb", .bit = 5, },
> >> +{ .name = "sar_asb", .bit = 6, },
> >> +{ .name = "sdr_asb", .bit = 7, },
> >> +{ .name = "swreg_asb", .bit = 8, },
> >> +{ .name = "periph_asb", .bit = 9, },
> >> +{ .name = "cpubus160", .bit = 10, },
> >> +{ .name = "adsl", .bit = 11, },
> >> +{ .name = "sar124", .bit = 12, },
> >
> > Nit: this should be sar125
>
> Nice catch, I will fix this in v2.
>
> >
> >> +{ .name = "mips", .bit = 13, .flags = CLK_IS_CRITICAL, },
> >> +{ .name = "pcie", .bit = 14, },
> >> +{ .name = "robosw250", .bit = 16, },
> >> +{ .name = "robosw025", .bit = 17, },
> >> +{ .name = "sdr", .bit = 19, .flags = CLK_IS_CRITICAL, },
> >> +{ .name = "usb", .bit = 20, },
> >
> > This should probably be "usbd" to indicate this is the USB device clock
> > (not host)
>
> Ok, I will change it. I got confused by the fact that both (usbd and usbh)
> were present on 6318_map_part.h:
> #define USBD_CLK_EN (1 << 20)
> #define USBH_CLK_EN (1 << 20)
Is there a datasheet to verify that?
>
> >
> > With that fixed:
> >
> > Reviewed-by: Florian Fainelli
> > --
> > Florian
>
Re: clean up kernel_{read,write} & friends v2
Hi Linus, On 5/29/20 9:19 PM, Linus Torvalds wrote: > On Fri, May 29, 2020 at 6:08 AM David Laight wrote: >> >> A wide monitor is for looking at lots of files. > > Not necessarily. > > Excessive line breaks are BAD. They cause real and every-day problems. > > They cause problems for things like "grep" both in the patterns and in > the output, since grep (and a lot of other very basic unix utilities) > is fundamentally line-based. > > So the fact is, many of us have long long since skipped the whole > "80-column terminal" model, for the same reason that we have many more > lines than 25 lines visible at a time. > > And honestly, I don't want to see patches that make the kernel reading > experience worse for me and likely for the vast majority of people, > based on the argument that some odd people have small terminal > windows. > > If you or Christoph have 80 character lines, you'll get possibly ugly > wrapped output. Tough. That's _your_ choice. Your hardware limitations > shouldn't be a pain for the rest of us. Unfortunately refreshable braille displays have that "hardware limitations". 80 cells displays are very expensive. Visual impairments is rarely a "choice". Relaxing the 80-char limit make it harder for blind developers to contribute. > Longer lines are fundamentally useful. My monitor is not only a lot > wider than it is tall, my fonts are universally narrower than they are > tall. Long lines are natural. > > When I tile my terminal windows on my display, I can have 6 terminals > visible at one time, and that's because I have them three wide. And I > could still fit 80% of a fourth one side-by-side. > > And guess what? That's with my default "100x50" terminal window (go to > your gnome terminal settings, you'll find that the 80x25 thing is just > an initial default that you can change), not with some 80x25 one. And > that's with a font that has anti-aliasing and isn't some pixelated > mess. > > And most of my terminals actually end up being dragged wider and > taller than that. I checked, and my main one is 142x76 characters > right now, because it turns out that wider (and taller) terminals are > useful not just for source code. > > Have you looked at "ps ax" output lately? Or used "top"? Or done "git > diff --stat" or any number of things where it turns out that 80x25 is > really really limiting, and is simply NO LONGER RELEVANT to most of > us. > > So no. I do not care about somebody with a 80x25 terminal window > getting line wrapping. > > For exactly the same reason I find it completely irrelevant if > somebody says that their kernel compile takes 10 hours because they > are doing kernel development on a Raspberry PI with 4GB of RAM. > > People with restrictive hardware shouldn't make it more inconvenient > for people who have better resources. Yes, we'll accommodate things to > within reasonable limits. But no, 80-column terminals in 2020 isn't > "reasonable" any more as far as I'm concerned. People commonly used > 132-column terminals even back in the 80's, for chrissake, don't try > to make 80 columns some immovable standard. > > If you choose to use a 80-column terminal, you can live with the line > wrapping. It's just that simple. > > And longer lines are simply useful. Part of that is that we aren't > programming in the 80's any more, and our source code is fundamentally > wider as a result. > > Yes, local iteration variables are still called 'i', because more > context just isn't helpful for some anonymous counter. Being concise > is still a good thing, and overly verbose names are not inherently > better. > > But still - it's entirely reasonable to have variable names that are > 10-15 characters and it makes the code more legible. Writing things > out instead of using abbreviations etc. > > And yes, we do use wide tabs, because that makes indentation something > you can visually see in the structure at a glance and on a > whole-function basis, rather than something you have to try to > visually "line up" things for or count spaces. > > So we have lots of fairly fundamental issues that fairly easily make > for longer lines in many circumstances. > > And yes, we do line breaks at some point. But there really isn't any > reason to make that point be 80 columns any more. > > Linus Regards, Phil.
Re: [PATCH] MIPS: ingenic: Add missing include
On Wed, May 20, 2020 at 11:28 AM Thomas Bogendoerfer
wrote:
>
> On Wed, May 20, 2020 at 11:19:49AM +0200, Philippe Mathieu-Daudé wrote:
> > Hi Thomas,
> >
> > On Wed, May 20, 2020 at 8:50 AM Thomas Bogendoerfer
> > wrote:
> > >
> > > On Tue, May 19, 2020 at 11:22:30PM +0200, Paul Cercueil wrote:
> > > > Add missing include which adds the prototype to plat_time_init().
> > > >
> > > > Fixes: f932449c11da ("MIPS: ingenic: Drop obsolete code, merge the rest
> > > > in setup.c")
> > > > Signed-off-by: Paul Cercueil
> > > > Reported-by: kbuild test robot
> > > > ---
> > > > arch/mips/jz4740/setup.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > >
> > > applied to mips-next.
> >
> > Since mips-next is not merged, can you simply squash the fix to the
> > incomplete f932449c11da please?
>
> no, I don't rebase mips-next.
OK. I had the understanding that mips-fixes was the stable branch not rebased,
and mips-next was not considered stable until merged in mainstream.
I took note of the changes, thanks.
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.[ RFC1925, 2.3 ]
Re: [PATCH] MIPS: ingenic: Add missing include
Hi Thomas,
On Wed, May 20, 2020 at 8:50 AM Thomas Bogendoerfer
wrote:
>
> On Tue, May 19, 2020 at 11:22:30PM +0200, Paul Cercueil wrote:
> > Add missing include which adds the prototype to plat_time_init().
> >
> > Fixes: f932449c11da ("MIPS: ingenic: Drop obsolete code, merge the rest in
> > setup.c")
> > Signed-off-by: Paul Cercueil
> > Reported-by: kbuild test robot
> > ---
> > arch/mips/jz4740/setup.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> applied to mips-next.
Since mips-next is not merged, can you simply squash the fix to the
incomplete f932449c11da please?
Thanks,
Phil.
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.[ RFC1925, 2.3 ]
Re: [PATCH] MIPS: include: Mark __xchg as __always_inline
On 10/9/19 12:06 PM, Thomas Bogendoerfer wrote:
Commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
forcibly") allows compiler to uninline functions marked as 'inline'.
In cace of __xchg this would cause to reference function
Typo: "in case of"
__xchg_called_with_bad_pointer, which is an error case
for catching bugs and will not happen for correct code, if
__xchg is inlined.
Ah, this is the equivalent of ARM commit 920fdab7b3c.
Maybe add:
Fixes: ac7c3e4ff401
Signed-off-by: Thomas Bogendoerfer
---
arch/mips/include/asm/cmpxchg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/include/asm/cmpxchg.h b/arch/mips/include/asm/cmpxchg.h
index 012dcf7046ad..f6136871561d 100644
--- a/arch/mips/include/asm/cmpxchg.h
+++ b/arch/mips/include/asm/cmpxchg.h
@@ -77,8 +77,8 @@ extern unsigned long __xchg_called_with_bad_pointer(void)
extern unsigned long __xchg_small(volatile void *ptr, unsigned long val,
unsigned int size);
-static inline unsigned long __xchg(volatile void *ptr, unsigned long x,
- int size)
+static __always_inline
+unsigned long __xchg(volatile void *ptr, unsigned long x, int size)
{
switch (size) {
case 1:
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v8 1/5] nvmem: core: add nvmem_device_find
m);
@@ -780,7 +773,7 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node
*np, const char *id)
if (!nvmem_np)
return ERR_PTR(-EINVAL);
- nvmem = __nvmem_device_get(nvmem_np, NULL);
+ nvmem = __nvmem_device_get(nvmem_np, device_match_of_node);
of_node_put(nvmem_np);
if (IS_ERR(nvmem))
return ERR_CAST(nvmem);
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 8f8be5b00060..02dc4aa992b2 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -89,6 +89,9 @@ void nvmem_del_cell_lookups(struct nvmem_cell_lookup *entries,
int nvmem_register_notifier(struct notifier_block *nb);
int nvmem_unregister_notifier(struct notifier_block *nb);
+struct nvmem_device *nvmem_device_find(void *data,
+ int (*match)(struct device *dev, const void *data));
+
#else
static inline struct nvmem_cell *nvmem_cell_get(struct device *dev,
@@ -204,6 +207,12 @@ static inline int nvmem_unregister_notifier(struct
notifier_block *nb)
return -EOPNOTSUPP;
}
+static inline struct nvmem_device *nvmem_device_find(void *data,
+ int (*match)(struct device *dev, const void *data))
+{
+ return NULL;
+}
+
#endif /* CONFIG_NVMEM */
#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v4 8/9] MIPS: SGI-IP27: fix readb/writeb addressing
Hi Thomas,
On 8/11/19 9:29 AM, Greg Kroah-Hartman wrote:
> On Sat, Aug 10, 2019 at 04:22:23PM +0300, Andy Shevchenko wrote:
>> On Fri, Aug 9, 2019 at 1:34 PM Thomas Bogendoerfer
>> wrote:
>>>
>>> Our chosen byte swapping, which is what firmware already uses, is to
>>> do readl/writel by normal lw/sw intructions (data invariance). This
>>> also means we need to mangle addresses for u8 and u16 accesses. The
>>> mangling for 16bit has been done aready, but 8bit one was missing.
>>> Correcting this causes different addresses for accesses to the
>>> SuperIO and local bus of the IOC3 chip. This is fixed by changing
>>> byte order in ioc3 and m48rtc_rtc structs.
>>
>>> /* serial port register map */
>>> struct ioc3_serialregs {
>>> - uint32_tsscr;
>>> - uint32_tstpir;
>>> - uint32_tstcir;
>>> - uint32_tsrpir;
>>> - uint32_tsrcir;
>>> - uint32_tsrtr;
>>> - uint32_tshadow;
>>> + u32 sscr;
>>> + u32 stpir;
>>> + u32 stcir;
>>> + u32 srpir;
>>> + u32 srcir;
>>> + u32 srtr;
>>> + u32 shadow;
>>> };
>>
>> Isn't it a churn? AFAIU kernel documentation the uint32_t is okay to
>> use, just be consistent inside one module / driver.
>> Am I mistaken?
>
> No, but really it uint* shouldn't be used anywhere in the kernel source
> as it does not make sense.
If you respin your series, please send this cleanup as a separate patch.
Thanks,
Phil.
Re: [PATCH] MIPS: OCTEON: octeon-usb: Mark expected switch fall-through
On Mon, Aug 5, 2019 at 12:42 PM Guenter Roeck wrote:
>
> Since commit a035d552a93b ("Makefile: Globally enable fall-through
> warning"), cavium_octeon_defconfig builds fail with
>
> In file included from
> arch/mips/cavium-octeon/octeon-usb.c:12:
> arch/mips/cavium-octeon/octeon-usb.c: In function 'dwc3_octeon_clocks_start':
> include/linux/device.h:1499:2: error: this statement may fall through
> _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
> ^~
> arch/mips/cavium-octeon/octeon-usb.c:399:3: note:
> in expansion of macro 'dev_err'
> dev_err(dev, "Invalid ref_clk %u, using 1 instead\n",
> ^~~
> arch/mips/cavium-octeon/octeon-usb.c:401:2: note: here
> case 1:
> ^~~
>
> Mark the switch case to expect fall through.
>
> Cc: Gustavo A. R. Silva
> Signed-off-by: Guenter Roeck
Reviewed-by: Philippe Mathieu-Daudé
> ---
> arch/mips/cavium-octeon/octeon-usb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/mips/cavium-octeon/octeon-usb.c
> b/arch/mips/cavium-octeon/octeon-usb.c
> index 1f730ded5224..8a16ab37aa11 100644
> --- a/arch/mips/cavium-octeon/octeon-usb.c
> +++ b/arch/mips/cavium-octeon/octeon-usb.c
> @@ -398,6 +398,7 @@ static int dwc3_octeon_clocks_start(struct device *dev,
> u64 base)
> default:
> dev_err(dev, "Invalid ref_clk %u, using 1 instead\n",
> clock_rate);
> + /* Fall through */
> case 1:
> mpll_mul = 0x19;
> if (ref_clk_sel < 2)
> --
> 2.7.4
>
Re: [Qemu-devel] Running linux on qemu omap
On 5/27/19 5:56 PM, Guenter Roeck wrote: > On 5/26/19 11:32 PM, Tony Lindgren wrote: >> Hi, >> >> * Philippe Mathieu-Daudé [190523 12:01]: >>> What I use as reference for testing ARM boards [*] is the work of >>> Guenter Roeck: >>> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh >>> >> >> I think Guenter also has v2.3.50-local-linaro branch in his >> github repo that has support for few extra boards like Beagleboard. >> Not sure what's the current branch to use though. >> > I'd be happy to use a different (supported) branch, but the Linaro branch > was the only one I could find that supports those boards. Unfortunately, > qemu changed so much since 2.3 that it is all but impossible to merge > the code into mainline qemu without spending a lot of effort on it. Peter commented on that here: https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00137.html "This is not a trivial job (my estimate was that it would be a couple of months work to get the complete set sorted out and upstreamed ..."
Re: [Qemu-devel] Running linux on qemu omap
On 5/23/19 1:27 PM, Thomas Huth wrote: > On 22/05/2019 20.19, Aaro Koskinen wrote: >> Hi, >> >> On Wed, May 22, 2019 at 11:33:41AM +0200, Corentin Labbe wrote: >>> qemu-system-arm -M help |grep OMAP >>> cheetah Palm Tungsten|E aka. Cheetah PDA (OMAP310) >>> n800 Nokia N800 tablet aka. RX-34 (OMAP2420) >>> n810 Nokia N810 tablet aka. RX-44 (OMAP2420) >>> sx1 Siemens SX1 (OMAP310) V2 >>> sx1-v1 Siemens SX1 (OMAP310) V1 >>> > The maximum I can get with omap1_defconfig is > qemu-system-arm -kernel zImage -nographic -machine cheetah -append > 'root=/dev/ram0 console=ttyO0' > Uncompressing Linux... done, booting the kernel. > then nothing more. >> >> With N800/N810 omap2plus_defconfig should be used instead. However, >> I don't think that works either (but haven't tried recently). Also with >> N800/N810 you need to append the DTB file to the kernel image. > > FWIW, Philippe recently posted a mail how to run older kernels on n810: > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg610653.html What I use as reference for testing ARM boards [*] is the work of Guenter Roeck: https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh However I can see than none of the board listed by Corentin are tested ... That reminder me I never succeed at using the Cheetah PDA. So the OMAP310 is probably bitroting in QEMU... [*] and slowly add to upstream patches he sent that fell through the cracks of qemu-devel. Regards, Phil. signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 1/2] firmware: bcm47xx_nvram: Correct size_t printf format
Hi Florian,
On 5/14/19 7:38 PM, Florian Fainelli wrote:
> When building on a 64-bit host, we will get warnings like those:
>
> drivers/firmware/broadcom/bcm47xx_nvram.c:103:3: note: in expansion of macro
> 'pr_err'
>pr_err("nvram on flash (%i bytes) is bigger than the reserved space in
> memory, will just copy the first %i bytes\n",
>^~
> drivers/firmware/broadcom/bcm47xx_nvram.c:103:28: note: format string is
> defined here
>pr_err("nvram on flash (%i bytes) is bigger than the reserved space in
> memory, will just copy the first %i bytes\n",
>~^
>%li
>
> Use %zu instead for that purpose.
>
> Signed-off-by: Florian Fainelli
> ---
> Changes in v2:
> - Use %zu instead of %zi (Joe Perches)
>
> drivers/firmware/broadcom/bcm47xx_nvram.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
> b/drivers/firmware/broadcom/bcm47xx_nvram.c
> index d25f080fcb0d..8698c5dd29d9 100644
> --- a/drivers/firmware/broadcom/bcm47xx_nvram.c
> +++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
> @@ -100,7 +100,7 @@ static int nvram_find_and_copy(void __iomem *iobase, u32
> lim)
> nvram_len = size;
> }
> if (nvram_len >= NVRAM_SPACE) {
> - pr_err("nvram on flash (%i bytes) is bigger than the reserved
> space in memory, will just copy the first %i bytes\n",
> + pr_err("nvram on flash (%zu bytes) is bigger than the reserved
> space in memory, will just copy the first %i bytes\n",
> nvram_len, NVRAM_SPACE - 1);
Why not change the other format too, to stay consistent?
> nvram_len = NVRAM_SPACE - 1;
> }
> @@ -152,7 +152,7 @@ static int nvram_init(void)
> header.len > sizeof(header)) {
> nvram_len = header.len;
> if (nvram_len >= NVRAM_SPACE) {
> - pr_err("nvram on flash (%i bytes) is bigger than the
> reserved space in memory, will just copy the first %i bytes\n",
> + pr_err("nvram on flash (%zu bytes) is bigger than the
> reserved space in memory, will just copy the first %i bytes\n",
> header.len, NVRAM_SPACE);
Ditto.
Regardless:
Reviewed-by: Philippe Mathieu-Daudé
> nvram_len = NVRAM_SPACE - 1;
> }
>
Re: [PATCH] MIPS: scall64-o32: Fix indirect syscall number load
On 4/9/19 4:53 PM, Aurelien Jarno wrote: > Commit 4c21b8fd8f14 (MIPS: seccomp: Handle indirect system calls (o32)) > added indirect syscall detection for O32 processes running on MIPS64, > but it did not work correctly for big endian kernel/processes. The > reason is that the syscall number is loaded from ARG1 using the lw > instruction while this is a 64-bit value, so zero is loaded instead of > the syscall number. > > Fix the code by using the ld instruction instead. When running a 32-bit > processes on a 64 bit CPU, the values are properly sign-extended, so it > ensures the value passed to syscall_trace_enter is correct. > > Recent systemd versions with seccomp enabled whitelist the getpid > syscall for their internal processes (e.g. systemd-journald), but call > it through syscall(SYS_getpid). This fix therefore allows O32 big endian > systems with a 64-bit kernel to run recent systemd versions. > > Signed-off-by: Aurelien Jarno > Cc: # v3.15+ > --- > arch/mips/kernel/scall64-o32.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/mips/kernel/scall64-o32.S b/arch/mips/kernel/scall64-o32.S > index f158c5894a9a..feb2653490df 100644 > --- a/arch/mips/kernel/scall64-o32.S > +++ b/arch/mips/kernel/scall64-o32.S > @@ -125,7 +125,7 @@ trace_a_syscall: > subut1, v0, __NR_O32_Linux > movea1, v0 > bnezt1, 1f /* __NR_syscall at offset 0 */ > - lw a1, PT_R4(sp) /* Arg1 for __NR_syscall case */ > + ld a1, PT_R4(sp) /* Arg1 for __NR_syscall case */ > .setpop > > 1: jal syscall_trace_enter > > Reviewed-by: Philippe Mathieu-Daudé
Re: [Qemu-devel] [PATCH] fw_cfg: use __ATTR_RO_MODE to define rev sysfs
On 2/26/19 5:10 PM, Michael S. Tsirkin wrote:
> On Tue, Feb 26, 2019 at 03:31:59PM +0800, Wei Yang wrote:
>> Leverage __ATTR_RO_MODE to define rev sysfs instead of using open code
>> to define the attribute.
>>
>> Signed-off-by: Wei Yang
>> ---
>> drivers/firmware/qemu_fw_cfg.c | 13 -
>> 1 file changed, 4 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
>> index 039e0f91dba8..a1293cbd7adb 100644
>> --- a/drivers/firmware/qemu_fw_cfg.c
>> +++ b/drivers/firmware/qemu_fw_cfg.c
>> @@ -296,18 +296,13 @@ static int fw_cfg_do_platform_probe(struct
>> platform_device *pdev)
>> return 0;
>> }
>>
>> -static ssize_t fw_cfg_showrev(struct kobject *k, struct attribute *a, char
>> *buf)
>> +static ssize_t fw_cfg_rev_show(struct kobject *k, struct kobj_attribute *a,
>> + char *buf)
>> {
>> return sprintf(buf, "%u\n", fw_cfg_rev);
>> }
>> -
>> -static const struct {
>> -struct attribute attr;
>> -ssize_t (*show)(struct kobject *k, struct attribute *a, char *buf);
>> -} fw_cfg_rev_attr = {
>> -.attr = { .name = "rev", .mode = S_IRUSR },
>> -.show = fw_cfg_showrev,
>> -};
>> +static const struct kobj_attribute fw_cfg_rev_attr =
>> +__ATTR_RO_MODE(fw_cfg_rev, 0400);
>>
>> /* fw_cfg_sysfs_entry type */
>> struct fw_cfg_sysfs_entry {
>
>
> Looks like this will change the name from "rev" to "fw_cfg_rev".
> That's a userspace visible change which we should not do lightly.
We could name the function rev_show but this stay fragile, we'd also
need a comment "don't rename this".
>> --
>> 2.19.1
>
Re: [Qemu-devel] [PATCH] fw_cfg: use __ATTR_RO_MODE to define rev sysfs
Hi Wei,
On 2/26/19 8:31 AM, Wei Yang wrote:
> Leverage __ATTR_RO_MODE to define rev sysfs instead of using open code
> to define the attribute.
>
> Signed-off-by: Wei Yang
> ---
> drivers/firmware/qemu_fw_cfg.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
> index 039e0f91dba8..a1293cbd7adb 100644
> --- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -296,18 +296,13 @@ static int fw_cfg_do_platform_probe(struct
> platform_device *pdev)
> return 0;
> }
>
> -static ssize_t fw_cfg_showrev(struct kobject *k, struct attribute *a, char
> *buf)
> +static ssize_t fw_cfg_rev_show(struct kobject *k, struct kobj_attribute *a,
> +char *buf)
> {
> return sprintf(buf, "%u\n", fw_cfg_rev);
> }
> -
> -static const struct {
> - struct attribute attr;
> - ssize_t (*show)(struct kobject *k, struct attribute *a, char *buf);
> -} fw_cfg_rev_attr = {
> - .attr = { .name = "rev", .mode = S_IRUSR },
> - .show = fw_cfg_showrev,
> -};
> +static const struct kobj_attribute fw_cfg_rev_attr =
> + __ATTR_RO_MODE(fw_cfg_rev, 0400);
Why not keep S_IRUSR?
>
> /* fw_cfg_sysfs_entry type */
> struct fw_cfg_sysfs_entry {
>
Re: [v2,08/12] hwrng: bcm2835-rng: Abstract I/O accessors
On 11/07/2017 09:44 PM, Florian Fainelli wrote:
> In preparation for allowing BCM63xx to use this driver, we abstract I/O
> accessors such that we can easily change those later on.
>
> Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
> Reviewed-by: Eric Anholt <e...@anholt.net>
Reviewed-by: Philippe Mathieu-Daudé <f4...@amsat.org>
> ---
> drivers/char/hw_random/bcm2835-rng.c | 27 +++
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/hw_random/bcm2835-rng.c
> b/drivers/char/hw_random/bcm2835-rng.c
> index 99b56fd5482c..3a607472687d 100644
> --- a/drivers/char/hw_random/bcm2835-rng.c
> +++ b/drivers/char/hw_random/bcm2835-rng.c
> @@ -42,6 +42,17 @@ static inline struct bcm2835_rng_priv *to_rng_priv(struct
> hwrng *rng)
> return container_of(rng, struct bcm2835_rng_priv, rng);
> }
>
> +static inline u32 rng_readl(struct bcm2835_rng_priv *priv, u32 offset)
> +{
> + return readl(priv->base + offset);
> +}
> +
> +static inline void rng_writel(struct bcm2835_rng_priv *priv, u32 val,
> + u32 offset)
> +{
> + writel(val, priv->base + offset);
> +}
> +
> static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
> bool wait)
> {
> @@ -49,18 +60,18 @@ static int bcm2835_rng_read(struct hwrng *rng, void *buf,
> size_t max,
> u32 max_words = max / sizeof(u32);
> u32 num_words, count;
>
> - while ((__raw_readl(priv->base + RNG_STATUS) >> 24) == 0) {
> + while ((rng_readl(priv, RNG_STATUS) >> 24) == 0) {
> if (!wait)
> return 0;
> cpu_relax();
> }
>
> - num_words = readl(priv->base + RNG_STATUS) >> 24;
> + num_words = rng_readl(priv, RNG_STATUS) >> 24;
> if (num_words > max_words)
> num_words = max_words;
>
> for (count = 0; count < num_words; count++)
> - ((u32 *)buf)[count] = readl(priv->base + RNG_DATA);
> + ((u32 *)buf)[count] = rng_readl(priv, RNG_DATA);
>
> return num_words * sizeof(u32);
> }
> @@ -79,14 +90,14 @@ static int bcm2835_rng_init(struct hwrng *rng)
>
> if (priv->mask_interrupts) {
> /* mask the interrupt */
> - val = readl(priv->base + RNG_INT_MASK);
> + val = rng_readl(priv, RNG_INT_MASK);
> val |= RNG_INT_OFF;
> - writel(val, priv->base + RNG_INT_MASK);
> + rng_writel(priv, val, RNG_INT_MASK);
> }
>
> /* set warm-up count & enable */
> - __raw_writel(RNG_WARMUP_COUNT, priv->base + RNG_STATUS);
> - __raw_writel(RNG_RBGEN, priv->base + RNG_CTRL);
> + rng_writel(priv, RNG_WARMUP_COUNT, RNG_STATUS);
> + rng_writel(priv, RNG_RBGEN, RNG_CTRL);
>
> return ret;
> }
> @@ -96,7 +107,7 @@ static void bcm2835_rng_cleanup(struct hwrng *rng)
> struct bcm2835_rng_priv *priv = to_rng_priv(rng);
>
> /* disable rng hardware */
> - __raw_writel(0, priv->base + RNG_CTRL);
> + rng_writel(priv, 0, RNG_CTRL);
>
> if (!IS_ERR(priv->clk))
> clk_disable_unprepare(priv->clk);
>
>
Re: [v2,08/12] hwrng: bcm2835-rng: Abstract I/O accessors
On 11/07/2017 09:44 PM, Florian Fainelli wrote:
> In preparation for allowing BCM63xx to use this driver, we abstract I/O
> accessors such that we can easily change those later on.
>
> Signed-off-by: Florian Fainelli
> Reviewed-by: Eric Anholt
Reviewed-by: Philippe Mathieu-Daudé
> ---
> drivers/char/hw_random/bcm2835-rng.c | 27 +++
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/hw_random/bcm2835-rng.c
> b/drivers/char/hw_random/bcm2835-rng.c
> index 99b56fd5482c..3a607472687d 100644
> --- a/drivers/char/hw_random/bcm2835-rng.c
> +++ b/drivers/char/hw_random/bcm2835-rng.c
> @@ -42,6 +42,17 @@ static inline struct bcm2835_rng_priv *to_rng_priv(struct
> hwrng *rng)
> return container_of(rng, struct bcm2835_rng_priv, rng);
> }
>
> +static inline u32 rng_readl(struct bcm2835_rng_priv *priv, u32 offset)
> +{
> + return readl(priv->base + offset);
> +}
> +
> +static inline void rng_writel(struct bcm2835_rng_priv *priv, u32 val,
> + u32 offset)
> +{
> + writel(val, priv->base + offset);
> +}
> +
> static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
> bool wait)
> {
> @@ -49,18 +60,18 @@ static int bcm2835_rng_read(struct hwrng *rng, void *buf,
> size_t max,
> u32 max_words = max / sizeof(u32);
> u32 num_words, count;
>
> - while ((__raw_readl(priv->base + RNG_STATUS) >> 24) == 0) {
> + while ((rng_readl(priv, RNG_STATUS) >> 24) == 0) {
> if (!wait)
> return 0;
> cpu_relax();
> }
>
> - num_words = readl(priv->base + RNG_STATUS) >> 24;
> + num_words = rng_readl(priv, RNG_STATUS) >> 24;
> if (num_words > max_words)
> num_words = max_words;
>
> for (count = 0; count < num_words; count++)
> - ((u32 *)buf)[count] = readl(priv->base + RNG_DATA);
> + ((u32 *)buf)[count] = rng_readl(priv, RNG_DATA);
>
> return num_words * sizeof(u32);
> }
> @@ -79,14 +90,14 @@ static int bcm2835_rng_init(struct hwrng *rng)
>
> if (priv->mask_interrupts) {
> /* mask the interrupt */
> - val = readl(priv->base + RNG_INT_MASK);
> + val = rng_readl(priv, RNG_INT_MASK);
> val |= RNG_INT_OFF;
> - writel(val, priv->base + RNG_INT_MASK);
> + rng_writel(priv, val, RNG_INT_MASK);
> }
>
> /* set warm-up count & enable */
> - __raw_writel(RNG_WARMUP_COUNT, priv->base + RNG_STATUS);
> - __raw_writel(RNG_RBGEN, priv->base + RNG_CTRL);
> + rng_writel(priv, RNG_WARMUP_COUNT, RNG_STATUS);
> + rng_writel(priv, RNG_RBGEN, RNG_CTRL);
>
> return ret;
> }
> @@ -96,7 +107,7 @@ static void bcm2835_rng_cleanup(struct hwrng *rng)
> struct bcm2835_rng_priv *priv = to_rng_priv(rng);
>
> /* disable rng hardware */
> - __raw_writel(0, priv->base + RNG_CTRL);
> + rng_writel(priv, 0, RNG_CTRL);
>
> if (!IS_ERR(priv->clk))
> clk_disable_unprepare(priv->clk);
>
>
