[PATCH] powerpc: fix typos in comments
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall --- arch/powerpc/boot/cuboot-hotfoot.c |2 +- arch/powerpc/crypto/aes-spe-glue.c |2 +- arch/powerpc/kernel/cputable.c |2 +- arch/powerpc/kernel/dawr.c |2 +- arch/powerpc/kernel/eeh.c |4 ++-- arch/powerpc/kernel/eeh_event.c |2 +- arch/powerpc/kernel/fadump.c| 10 +- arch/powerpc/kernel/module_32.c |2 +- arch/powerpc/kernel/module_64.c |4 ++-- arch/powerpc/kernel/pci-common.c|2 +- arch/powerpc/kernel/pci_of_scan.c |2 +- arch/powerpc/kernel/process.c |4 ++-- arch/powerpc/kernel/prom_init.c |2 +- arch/powerpc/kernel/ptrace/ptrace-view.c|2 +- arch/powerpc/kernel/rtas_flash.c|2 +- arch/powerpc/kernel/setup-common.c |2 +- arch/powerpc/kernel/signal_64.c |2 +- arch/powerpc/kernel/smp.c |2 +- arch/powerpc/kernel/time.c |4 ++-- arch/powerpc/kernel/watchdog.c |2 +- arch/powerpc/kexec/core_64.c|2 +- arch/powerpc/kvm/book3s_64_mmu_hv.c |2 +- arch/powerpc/kvm/book3s_64_vio_hv.c |2 +- arch/powerpc/kvm/book3s_emulate.c |2 +- arch/powerpc/kvm/book3s_hv_p9_entry.c |2 +- arch/powerpc/kvm/book3s_hv_uvmem.c |2 +- arch/powerpc/kvm/book3s_pr.c|2 +- arch/powerpc/kvm/book3s_xics.c |2 +- arch/powerpc/kvm/book3s_xive.c |6 +++--- arch/powerpc/kvm/e500mc.c |2 +- arch/powerpc/mm/book3s64/hash_pgtable.c |2 +- arch/powerpc/mm/book3s64/hash_utils.c |4 ++-- arch/powerpc/mm/book3s64/pgtable.c |2 +- arch/powerpc/mm/book3s64/radix_pgtable.c|2 +- arch/powerpc/mm/book3s64/radix_tlb.c|2 +- arch/powerpc/mm/book3s64/slb.c |4 ++-- arch/powerpc/mm/init_64.c |4 ++-- arch/powerpc/mm/nohash/book3e_hugetlbpage.c |2 +- arch/powerpc/mm/nohash/kaslr_booke.c|2 +- arch/powerpc/mm/pgtable-frag.c |2 +- arch/powerpc/perf/8xx-pmu.c |2 +- arch/powerpc/perf/core-book3s.c |6 +++--- arch/powerpc/perf/imc-pmu.c |4 ++-- arch/powerpc/perf/isa207-common.c |6 +++--- arch/powerpc/platforms/512x/clock-commonclk.c |2 +- arch/powerpc/platforms/512x/mpc512x_shared.c|2 +- arch/powerpc/platforms/52xx/mpc52xx_common.c|2 +- arch/powerpc/platforms/52xx/mpc52xx_gpt.c |2 +- arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |2 +- arch/powerpc/platforms/85xx/mpc85xx_cds.c |2 +- arch/powerpc/platforms/86xx/gef_ppc9a.c |2 +- arch/powerpc/platforms/86xx/gef_sbc310.c|2 +- arch/powerpc/platforms/86xx/gef_sbc610.c|2 +- arch/powerpc/platforms/book3s/vas-api.c |2 +- arch/powerpc/platforms/cell/cbe_regs.c |2 +- arch/powerpc/platforms/cell/iommu.c |2 +- arch/powerpc/platforms/cell/spider-pci.c|2 +- arch/powerpc/platforms/cell/spu_manage.c|2 +- arch/powerpc/platforms/powermac/low_i2c.c |2 +- arch/powerpc/platforms/powernv/eeh-powernv.c| 10 +- arch/powerpc/platforms/powernv/idle.c |4 ++-- arch/powerpc/platforms/powernv/ocxl.c |2 +- arch/powerpc/platforms/powernv/opal-fadump.c|2 +- arch/powerpc/platforms/powernv/opal-lpc.c |2 +- arch/powerpc/platforms/powernv/opal-memory-errors.c |2 +- arch/powerpc/platforms/powernv/pci-sriov.c |2 +- arch/powerpc/platforms/ps3/mm.c |2 +- arch/powerpc/platforms/ps3/system-bus.c |2 +- arch/powerpc/platforms/pseries/eeh_pseries.c|2 +- arch/powerpc/platforms/pseries/iommu.c |2 +- arch/powerpc/platforms/pseries/setup.c |4 ++-- arch/powerpc/platforms/pseries/vas-sysfs.c |2 +- arch/powerpc/platforms/pseries/vas.c|2 +- arch/powerpc/sysdev/fsl_lbc.c |2 +- arch/powerpc/sysdev/fsl_pci.c |2 +- arch/powerpc/sysdev/ge/ge_pic.c |2 +- arch/powerpc/sysdev/mpic_msgr.c
[PATCH] kbuild: drop $(objtree)/ prefix support for clean-files
I think this hack is a bad idea. arch/powerpc/boot/Makefile is the only user. Let's stop doing this. Signed-off-by: Masahiro Yamada --- arch/powerpc/boot/Makefile | 4 ++-- scripts/Makefile.clean | 8 +--- 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 4b4827c475c6..008bf0bff186 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -453,8 +453,8 @@ clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \ clean-kernel-base := vmlinux.strip vmlinux.bin clean-kernel := $(addsuffix .gz,$(clean-kernel-base)) clean-kernel += $(addsuffix .xz,$(clean-kernel-base)) -# If not absolute clean-files are relative to $(obj). -clean-files += $(addprefix $(objtree)/, $(clean-kernel)) +# clean-files are relative to $(obj). +clean-files += $(addprefix ../../../, $(clean-kernel)) WRAPPER_OBJDIR := /usr/lib/kernel-wrapper WRAPPER_DTSDIR := /usr/lib/kernel-wrapper/dts diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean index 74cb1c5c3658..878cec648959 100644 --- a/scripts/Makefile.clean +++ b/scripts/Makefile.clean @@ -36,13 +36,7 @@ __clean-files:= \ __clean-files := $(filter-out $(no-clean-files), $(__clean-files)) -# clean-files is given relative to the current directory, unless it -# starts with $(objtree)/ (which means "./", so do not add "./" unless -# you want to delete a file from the toplevel object directory). - -__clean-files := $(wildcard \ - $(addprefix $(obj)/, $(filter-out $(objtree)/%, $(__clean-files))) \ - $(filter $(objtree)/%, $(__clean-files))) +__clean-files := $(wildcard $(addprefix $(obj)/, $(__clean-files))) # == -- 2.32.0
Re: serial hang in qemu-system-ppc64 -M pseries
On 4/29/22 16:43, Fabiano Rosas wrote: > Rob Landley writes: >> Then paste something longer than 16 characters at the eventual command prompt >> once the kernel finishes booting. > > I suspect this is due to how the tty driver (n_tty.c) interacts with > the console (hvc_console.c) driver's buffer size. > > This is the stack: > > #0 hvc_push <-- calls into KVM/QEMU to write up to 16 bytes > #1 hvc_write > #2 tty_put_char > #3 do_output_char > #4 __process_echoes <-- writes up to tty_write_room() chars > #5 flush_echoes <-- returns early if ~ECHO && ~ECHONL > #6 n_tty_receive_buf_common <-- buffers more than 16 bytes > #7 tty_ldisc_receive_buf > #8 tty_port_default_receive_buf > #9 receive_buf > #10 process_one_work > > In my busybox instance which does not have this issue I can see that > termios.c_lflag = 0x447, so in the stack above #4 is not called (ECHO > is 0x8, ECHONL is 0x10). > > In the bug scenario: termios.c_lflag = 0x5cf, so we go into #4 which > is supposed to write (say) 17 bytes, but ends up writing only 16 > because that is what tty_write_room() returns. I think my init script left the terminal wherever the hardware defaults initialized it to? (I note that sh4 also has a variant of this problem, but instead of the stutter-and-flush behavior it just hard discards everything after the first 16 characters of a paste. Large pastes seemsto work without issue on all the other targets I've tried so far, I.E. x86, arm, mips, powerpc -M g3beige, s390x, and m68k. And by "large" I mean I've fed half a megabyte of uuencode output into uudecode as a single paste.) > What I think is causing this issue is that the hvc_vio.c driver is > configured with hp->outbuf_size = 16. That number comes from the > H_PUT_TERM_CHAR hypercall spec which reads two registers at a > time. However, the hvc_write function supports writes larger than 16 > bytes so it seems we're needlessly propagating the 16 byte limitation > to the upper layer. Looks like the call is: hp = hvc_alloc(termno, vdev->irq, ops, MAX_VIO_PUT_CHARS); MAX_VIO_PUT_CHARS implies it's the maximum allowed write size. Understandable if writes bigger than that didn't get a lot of testing. (There's an identical call in hvc_opal.c, by the way.) > The driver is also not buffering the write, so if it gets called to > write one char at a time (like __process_echoes does) there should be no > limit to how much it can write. > > I think if we increase hp->outbuf_size to a value that is larger than > N_TTY_BUF_SIZE=4096 the echo buffer would drain before reaching this new > hvc driver limit. How is this handled on any of the architectures where it works? (Or do their tty flags just start at different defaults so I don't see it there?) > I tested that and it seems to work, but I'm not sure if it's the right > fix, there are some things I couldn't figure out: Let me know if I can help, although this sounds like it's moved a bit beyond areas I'm familiar with. Thanks, Rob
