Re: [PATCH] tty: hvc: Don't enable the RISC-V SBI console by default

2024-02-14 Thread Paul Walmsley 
On Wed, 14 Feb 2024, Palmer Dabbelt wrote:

> From: Palmer Dabbelt 
> 
> The new SBI console has the same problem as the old one: there's only
> one shared backing hardware and no synchronization, so the two drivers
> end up stepping on each other.  This was the same issue the old SBI-0.1
> console drivers had, but that was disabled by default when SBI-0.1 was.
> 
> So just mark the new driver as nonportable.
> 
> Reported-by: Emil Renner Berthing 
> Fixes: 88ead68e764c ("tty: Add SBI debug console support to HVC SBI driver")
> Signed-off-by: Palmer Dabbelt 

Reviewed-by: Paul Walmsley 


- Paul

Re: [PATCH 1/2] asm-generic: Make msi.h a mandatory include/asm header

2019-10-24 Thread Paul Walmsley 
On Thu, 24 Oct 2019, Michal Simek wrote:

> msi.h is generic for all architectures expect of x86 which has own version.
> Enabling MSI by including msi.h to architecture Kbuild is just additional
> step which doesn't need to be done.
> The patch was created based on request to enable MSI for Microblaze.
> 
> Suggested-by: Christoph Hellwig 
> Signed-off-by: Michal Simek 
> ---
> 
> https://lore.kernel.org/linux-riscv/20191008154604.ga7...@infradead.org/

[ ... ]

> diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
> index 16970f246860..1efaeddf1e4b 100644
> --- a/arch/riscv/include/asm/Kbuild
> +++ b/arch/riscv/include/asm/Kbuild
> @@ -22,7 +22,6 @@ generic-y += kvm_para.h
>  generic-y += local.h
>  generic-y += local64.h
>  generic-y += mm-arch-hooks.h
> -generic-y += msi.h
>  generic-y += percpu.h
>  generic-y += preempt.h
>  generic-y += sections.h

Acked-by: Paul Walmsley  # arch/riscv
Tested-by: Paul Walmsley  # build only, rv32/rv64

Thanks Michał,


- Paul

Virtual addresses in arch/powerpc/boot/dts/tqm8548*.dts ?

2011-08-30 Thread Paul Walmsley 

Hi,

Looking at some of the PPC DTS files in arch/powerpc/boot/dts, there are 
some files that are mostly identical, except for some strange 
differences.

For example, tqm8548.dts and tqm8548-bigflash.dts differ mostly in that 
the former file claims that the SoC registers start at 0xe000[1], but 
the latter file claims that the SoC registers start at 0xa000[2].

Commit 02b8a3d1eb2ae6353cfbce627ded22e299cf1989 (powerpc/85xx: support 
for the TQM8548 module using the big Flash) claims that:

Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
memory and therefore a modified memory map is required and setup by
the board loader. This patch adds an appropriate DTS file.

So are these addresses virtual?  My (perhaps incorrect) understanding of 
the device tree files was that they were intended to describe the physical 
memory map, rather than the virtual memory map.  Or does this PowerPC 
variant have the ability to dynamically change its own physical address 
decoding?  Or is something else going on?


thanks for any clarification,

- Paul

1. arch/powerpc/boot/dts/tqm8548.dts line 53, as of Linux v3.1-rc3:
   
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548.dts;h=619776f72c904c611e9507d44db4bee1200e6688;hb=HEAD#l53

2. arch/powerpc/boot/dts/tqm8548-bigflash.dts line 53, as of Linux 
   v3.1-rc3:
   
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548-bigflash.dts;h=9452c3c05114e523033eebb278d7f78811890a87;hb=HEAD#l53
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Virtual addresses in arch/powerpc/boot/dts/tqm8548*.dts ?

2011-08-30 Thread Paul Walmsley 
On Tue, 30 Aug 2011, Gary Thomas wrote:

 On 2011-08-30 15:43, Paul Walmsley wrote:
 
  So are these addresses virtual?  My (perhaps incorrect) understanding of
  the device tree files was that they were intended to describe the physical
  memory map, rather than the virtual memory map.  Or does this PowerPC
  variant have the ability to dynamically change its own physical address
  decoding?  Or is something else going on?
 
 These addresses correspond to the internal registers which can be moved. 
 The default address is set by hardware at reset time (check out the 
 documentation on the hardware reset word).  Obviously one board is 
 strapped for the IMMR at one address, another board at a different 
 address.  I almost always configure my boards to use 0xF000 for the 
 IMMR.

Got it.  Thanks Gary.


- Paul
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev