[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZnQ/auhuPWb1SGjb@alpha.franken.de>
Date: Thu, 20 Jun 2024 16:40:42 +0200
From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Hauke Mehrtens <hauke@...ke-m.de>,
Rafał Miłecki <zajec5@...il.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Florian Fainelli <florian.fainelli@...adcom.com>,
Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
Álvaro Fernández Rojas <noltari@...il.com>,
linux-mips@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 2/5] mips: bmips: rework and cache CBR addr handling
On Tue, Jun 11, 2024 at 01:35:34PM +0200, Christian Marangi wrote:
> Rework the handling of the CBR address and cache it. This address
> doesn't change and can be cached instead of reading the register every
> time.
>
> This is in preparation of permitting to tweak the CBR address in DT with
> broken SoC or bootloader.
>
> bmips_cbr_addr is defined in smp-bmips.c to keep compatibility with
> legacy brcm47xx/brcm63xx and generic BMIPS target.
>
> Acked-by: Florian Fainelli <florian.fainelli@...adcom.com>
> Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
> ---
> arch/mips/bcm47xx/prom.c | 3 +++
> arch/mips/bcm63xx/prom.c | 3 +++
> arch/mips/bmips/dma.c | 2 +-
> arch/mips/bmips/setup.c | 4 +++-
> arch/mips/include/asm/bmips.h | 1 +
> arch/mips/kernel/smp-bmips.c | 6 ++++--
> 6 files changed, 15 insertions(+), 4 deletions(-)
still problems on a bcm47xx build:
mips64-linux-gnu-ld: arch/mips/bcm47xx/prom.o: in function `prom_init':
/local/tbogendoerfer/korg/linux/arch/mips/bcm47xx/prom.c:(.init.text+0x3c): undefined reference to `bmips_cbr_addr'
mips64-linux-gnu-ld: /local/tbogendoerfer/korg/linux/arch/mips/bcm47xx/prom.c:(.init.text+0x44): undefined reference to `bmips_cbr_addr'
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
Powered by blists - more mailing lists