02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

06 Oct, 2016

1 commit

  • Good evening,

    Following LinuxCodingStyle documentation and with the help of Sam, fixed
    severals identation issues in the code, and few others cosmetic changes

    And last and i hope least fixing my name :)

    Signed-off-by : Dominique Carrel
    Acked-by: Sam Ravnborg

    Signed-off-by: David S. Miller

    netmonk@netmonk.org
     

25 Oct, 2014

1 commit

  • Meelis Roos reported that kernels built with gcc-4.9 do not boot, we
    eventually narrowed this down to only impacting machines using
    UltraSPARC-III and derivitive cpus.

    The crash happens right when the first user process is spawned:

    [ 54.451346] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
    [ 54.451346]
    [ 54.571516] CPU: 1 PID: 1 Comm: init Not tainted 3.16.0-rc2-00211-gd7933ab #96
    [ 54.666431] Call Trace:
    [ 54.698453] [0000000000762f8c] panic+0xb0/0x224
    [ 54.759071] [000000000045cf68] do_exit+0x948/0x960
    [ 54.823123] [000000000042cbc0] fault_in_user_windows+0xe0/0x100
    [ 54.902036] [0000000000404ad0] __handle_user_windows+0x0/0x10
    [ 54.978662] Press Stop-A (L1-A) to return to the boot prom
    [ 55.050713] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004

    Further investigation showed that compiling only per_cpu_patch() with
    an older compiler fixes the boot.

    Detailed analysis showed that the function is not being miscompiled by
    gcc-4.9, but it is using a different register allocation ordering.

    With the gcc-4.9 compiled function, something during the code patching
    causes some of the %i* input registers to get corrupted. Perhaps
    we have a TLB miss path into the firmware that is deep enough to
    cause a register window spill and subsequent restore when we get
    back from the TLB miss trap.

    Let's plug this up by doing two things:

    1) Stop using the firmware stack for client interface calls into
    the firmware. Just use the kernel's stack.

    2) As soon as we can, call into a new function "start_early_boot()"
    to put a one-register-window buffer between the firmware's
    deepest stack frame and the top-most initial kernel one.

    Reported-by: Meelis Roos
    Tested-by: Meelis Roos
    Signed-off-by: David S. Miller

    David S. Miller
     

11 Oct, 2014

1 commit

  • Inconsistently, the raw_* IRQ routines do not interact with and update
    the irqflags tracing and lockdep state, whereas the raw_* spinlock
    interfaces do.

    This causes problems in p1275_cmd_direct() because we disable hardirqs
    by hand using raw_local_irq_restore() and then do a raw_spin_lock()
    which triggers a lockdep trace because the CPU's hw IRQ state doesn't
    match IRQ tracing's internal software copy of that state.

    The CPU's irqs are disabled, yet current->hardirqs_enabled is true.

    ====================
    reboot: Restarting system
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3536 check_flags+0x7c/0x240()
    DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
    Modules linked in: openpromfs
    CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G W 3.17.0-dirty #145
    Call Trace:
    [000000000045919c] warn_slowpath_common+0x5c/0xa0
    [0000000000459210] warn_slowpath_fmt+0x30/0x40
    [000000000048f41c] check_flags+0x7c/0x240
    [0000000000493280] lock_acquire+0x20/0x1c0
    [0000000000832b70] _raw_spin_lock+0x30/0x60
    [000000000068f2fc] p1275_cmd_direct+0x1c/0x60
    [000000000068ed28] prom_reboot+0x28/0x40
    [000000000043610c] machine_restart+0x4c/0x80
    [000000000047d2d4] kernel_restart+0x54/0x80
    [000000000047d618] SyS_reboot+0x138/0x200
    [00000000004060b4] linux_sparc_syscall32+0x34/0x60
    ---[ end trace 5c439fe81c05a100 ]---
    possible reason: unannotated irqs-off.
    irq event stamp: 2010267
    hardirqs last enabled at (2010267): [] vprintk_emit+0x4b8/0x580
    hardirqs last disabled at (2010266): [] vprintk_emit+0x68/0x580
    softirqs last enabled at (2010046): [] __do_softirq+0x378/0x4a0
    softirqs last disabled at (2010039): [] do_softirq_own_stack+0x28/0x40
    Resetting ...
    ====================

    Use local_* variables of the hw IRQ interfaces so that IRQ tracing sees
    all of our changes.

    Reported-by: Meelis Roos
    Tested-by: Meelis Roos
    Signed-off-by: David S. Miller

    David S. Miller
     

08 Oct, 2014

1 commit


19 May, 2014

1 commit

  • Fix following warnings:
    smp_64.c:88:6: warning: symbol 'smp_callin' was not declared. Should it be static?
    smp_64.c:133:6: warning: symbol 'cpu_panic' was not declared. Should it be static?
    smp_64.c:187:6: warning: symbol 'smp_synchronize_tick_client' was not declared. Should it be static?
    smp_64.c:821:18: warning: symbol 'smp_call_function_client' was not declared. Should it be static?
    smp_64.c:827:18: warning: symbol 'smp_call_function_single_client' was not declared. Should it be static?
    smp_64.c:964:18: warning: symbol 'smp_new_mmu_context_version_client' was not declared. Should it be static?
    smp_64.c:1149:6: warning: symbol 'smp_capture' was not declared. Should it be static?
    smp_64.c:1171:6: warning: symbol 'smp_release' was not declared. Should it be static?
    smp_64.c:1190:18: warning: symbol 'smp_penguin_jailcell' was not declared. Should it be static?
    smp_64.c:1410:18: warning: symbol 'smp_receive_signal_client' was not declared. Should it be static?

    Add prototypes in kernel.h or asm/smp_64.h as appropriate.
    Delete duplicate function kimage_addr_to_ra(), and
    adapt parameter to const void * to match the broader use.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

29 Jan, 2014

1 commit


19 Jun, 2013

2 commits


27 Jun, 2012

2 commits


12 May, 2012

1 commit

  • Machines with sun4c support are very rare these days, and noone
    is using them for any practical purposes.
    The sun4c support has been know broken for quite some time too.

    So rather than trying to keep it up-to-date, lets get rid of it.
    This allows us to do some very welcome cleanup of sparc32 support.

    Updated the former sun4c specifc nmi (which was also used
    for sun4m UP) to be a generic UP NMI.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

29 Mar, 2012

1 commit


08 Jun, 2011

1 commit


17 Mar, 2011

1 commit

  • The two methods included in tick14.c was nop because
    the static variable linux_lvl14 was always NULL.

    So remove the file and callers.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

11 Jan, 2011

1 commit

  • * 'next-devicetree' of git://git.secretlab.ca/git/linux-2.6: (29 commits)
    of/flattree: forward declare struct device_node in of_fdt.h
    ipmi: explicitly include of_address.h and of_irq.h
    sparc: explicitly cast negative phandle checks to s32
    powerpc/405: Fix missing #{address,size}-cells in i2c node
    powerpc/5200: dts: refactor dts files
    powerpc/5200: dts: Change combatible strings on localbus
    powerpc/5200: dts: remove unused properties
    powerpc/5200: dts: rename nodes to prepare for refactoring dts files
    of/flattree: Update dtc to current mainline.
    of/device: Don't register disabled devices
    powerpc/dts: fix syntax bugs in bluestone.dts
    of: Fixes for OF probing on little endian systems
    of: make drivers depend on CONFIG_OF instead of CONFIG_PPC_OF
    of/flattree: Add of_flat_dt_match() helper function
    of_serial: explicitly include of_irq.h
    of/flattree: Refactor unflatten_device_tree and add fdt_unflatten_tree
    of/flattree: Reorder unflatten_dt_node
    of/flattree: Refactor unflatten_dt_node
    of/flattree: Add non-boottime device tree functions
    of/flattree: Add Kconfig for EARLY_FLATTREE
    ...

    Fix up trivial conflict in arch/sparc/prom/tree_32.c as per Grant.

    Linus Torvalds
     

04 Jan, 2011

2 commits

  • When we switched sparc from using 'int's to 'phandle's (which is a u32), we
    neglected to do anything with the various checks for -1. For those tests,
    explicitly cast the phandles to s32.

    Signed-off-by: Andres Salomon
    Acked-by: David S. Miller
    Signed-off-by: Grant Likely

    Andres Salomon
     
  • Fix following sparse warnings:
    arch/sparc/prom/bootstr_32.c:32:35: warning: Using plain integer as NULL pointer
    arch/sparc/prom/memory.c:61:13: warning: symbol 'prom_meminit' was not declared. Should it be static?
    arch/sparc/prom/misc_32.c:74:1: error: symbol 'prom_halt' redeclared with different type (originally declared at arch/sparc/include/asm/oplib_32.h:67) - different modifiers
    arch/sparc/prom/ranges.c:16:26: warning: symbol 'promlib_obio_ranges' was not declared. Should it be static?
    arch/sparc/prom/ranges.c:17:5: warning: symbol 'num_obio_ranges' was not declared. Should it be static?
    arch/sparc/prom/ranges.c:39:1: warning: symbol 'prom_adjust_ranges' was not declared. Should it be static?
    arch/sparc/prom/ranges.c:69:13: warning: symbol 'prom_ranges_init' was not declared. Should it be static?
    arch/sparc/prom/tree_32.c:286:22: warning: Using plain integer as NULL pointer
    arch/sparc/prom/tree_32.c:286:38: warning: Using plain integer as NULL pointer

    None of the warnings indicated any serious issues.

    We are now sparse clean for 32 bit build in arch/sparc/prom.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: David S. Miller

    Sam Ravnborg
     

03 Jan, 2011

4 commits


13 Dec, 2010

2 commits


01 Dec, 2010

3 commits

  • sparc64 systems have a restriction in that passing in buffer
    addressses above 4GB to prom calls is not reliable.

    We end up violating this when we do prom console writes, because we
    use an on-stack buffer to translate '\n' into '\r\n'.

    So instead, do this translation into an intermediate buffer, which is
    in the kernel image and thus below 4GB, then pass that to the PROM
    console write calls.

    On the 32-bit side we don't have to deal with any of these issues, so
    the new prom_console_write_buf() uses the existing prom_nbputchar()
    implementation. However we can now mark those routines static.

    Since the 64-bit side completely uses new code we can delete the
    putchar bits as they are now completely unused.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • Completely unused.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • This gets us closer to being able to eliminate the use
    of dynamic and stack based buffers, so that we can adhere
    to the "no buffer addresses above 4GB" rule for PROM calls.

    Signed-off-by: David S. Miller

    David S. Miller
     

18 Nov, 2010

1 commit


17 Nov, 2010

5 commits


25 Oct, 2010

1 commit

  • * 'next-devicetree' of git://git.secretlab.ca/git/linux-2.6:
    mtd/m25p80: add support to parse the partitions by OF node
    of/irq: of_irq.c needs to include linux/irq.h
    of/mips: Cleanup some include directives/files.
    of/mips: Add device tree support to MIPS
    of/flattree: Eliminate need to provide early_init_dt_scan_chosen_arch
    of/device: Rework to use common platform_device_alloc() for allocating devices
    of/xsysace: Fix OF probing on little-endian systems
    of: use __be32 types for big-endian device tree data
    of/irq: remove references to NO_IRQ in drivers/of/platform.c
    of/promtree: add package-to-path support to pdt
    of/promtree: add of_pdt namespace to pdt code
    of/promtree: no longer call prom_ functions directly; use an ops structure
    of/promtree: make drivers/of/pdt.c no longer sparc-only
    sparc: break out some PROM device-tree building code out into drivers/of
    of/sparc: convert various prom_* functions to use phandle
    sparc: stop exporting openprom.h header
    powerpc, of_serial: Endianness issues setting up the serial ports
    of: MTD: Fix OF probing on little-endian systems
    of: GPIO: Fix OF probing on little-endian systems

    Linus Torvalds
     

09 Oct, 2010

1 commit


07 Oct, 2010

1 commit

  • Fix the IRQ flag handling naming. In linux/irqflags.h under one configuration,
    it maps:

    local_irq_enable() -> raw_local_irq_enable()
    local_irq_disable() -> raw_local_irq_disable()
    local_irq_save() -> raw_local_irq_save()
    ...

    and under the other configuration, it maps:

    raw_local_irq_enable() -> local_irq_enable()
    raw_local_irq_disable() -> local_irq_disable()
    raw_local_irq_save() -> local_irq_save()
    ...

    This is quite confusing. There should be one set of names expected of the
    arch, and this should be wrapped to give another set of names that are expected
    by users of this facility.

    Change this to have the arch provide:

    flags = arch_local_save_flags()
    flags = arch_local_irq_save()
    arch_local_irq_restore(flags)
    arch_local_irq_disable()
    arch_local_irq_enable()
    arch_irqs_disabled_flags(flags)
    arch_irqs_disabled()
    arch_safe_halt()

    Then linux/irqflags.h wraps these to provide:

    raw_local_save_flags(flags)
    raw_local_irq_save(flags)
    raw_local_irq_restore(flags)
    raw_local_irq_disable()
    raw_local_irq_enable()
    raw_irqs_disabled_flags(flags)
    raw_irqs_disabled()
    raw_safe_halt()

    with type checking on the flags 'arguments', and then wraps those to provide:

    local_save_flags(flags)
    local_irq_save(flags)
    local_irq_restore(flags)
    local_irq_disable()
    local_irq_enable()
    irqs_disabled_flags(flags)
    irqs_disabled()
    safe_halt()

    with tracing included if enabled.

    The arch functions can now all be inline functions rather than some of them
    having to be macros.

    Signed-off-by: David Howells [X86, FRV, MN10300]
    Signed-off-by: Chris Metcalf [Tile]
    Signed-off-by: Michal Simek [Microblaze]
    Tested-by: Catalin Marinas [ARM]
    Acked-by: Thomas Gleixner
    Acked-by: Haavard Skinnemoen [AVR]
    Acked-by: Tony Luck [IA-64]
    Acked-by: Hirokazu Takata [M32R]
    Acked-by: Greg Ungerer [M68K/M68KNOMMU]
    Acked-by: Ralf Baechle [MIPS]
    Acked-by: Kyle McMartin [PA-RISC]
    Acked-by: Paul Mackerras [PowerPC]
    Acked-by: Martin Schwidefsky [S390]
    Acked-by: Chen Liqin [Score]
    Acked-by: Matt Fleming [SH]
    Acked-by: David S. Miller [Sparc]
    Acked-by: Chris Zankel [Xtensa]
    Reviewed-by: Richard Henderson [Alpha]
    Reviewed-by: Yoshinori Sato [H8300]
    Cc: starvik@axis.com [CRIS]
    Cc: jesper.nilsson@axis.com [CRIS]
    Cc: linux-cris-kernel@axis.com

    David Howells
     

24 Aug, 2010

1 commit

  • This is based upon a report by Meelis Roos showing that it's possible
    that we'll try to fetch a property that is 32K in size with some
    devices. With the current fixed 3K buffer we use for moving data in
    and out of the firmware during PROM calls, that simply won't work.

    In fact, it will scramble random kernel data during bootup.

    The reasoning behind the temporary buffer is entirely historical. It
    used to be the case that we had problems referencing dynamic kernel
    memory (including the stack) early in the boot process before we
    explicitly told the firwmare to switch us over to the kernel trap
    table.

    So what we did was always give the firmware buffers that were locked
    into the main kernel image.

    But we no longer have problems like that, so get rid of all of this
    indirect bounce buffering.

    Besides fixing Meelis's bug, this also makes the kernel data about 3K
    smaller.

    It was also discovered during these conversions that the
    implementation of prom_retain() was completely wrong, so that was
    fixed here as well. Currently that interface is not in use.

    Reported-by: Meelis Roos
    Tested-by: Meelis Roos
    Signed-off-by: David S. Miller

    David S. Miller
     

04 Mar, 2010

1 commit


11 Feb, 2010

1 commit


04 Sep, 2009

1 commit

  • Functions invoked early when booting up a cpu can't use
    tracing because mcount requires a valid 'current_thread_info()'
    and TLB mappings to be setup.

    The code path of sun4v_register_mondo_queues --> register_one_mondo
    is one such case. sun4v_register_mondo_queues already has the
    necessary 'notrace' annotation, but register_one_mondo does not.

    Normally register_one_mondo is inlined so the bug doesn't trigger,
    but with some config/compiler combinations, it won't be so we
    must properly mark it notrace.

    While we're here, add 'notrace' annoations to prom_printf and
    prom_halt so that early error handling won't have the same problem.

    Reported-by: Alexander Beregalov
    Reported-by: Leif Sawyer
    Signed-off-by: David S. Miller

    David S. Miller