Eric Lee / smarc-fsl-linux-kernel

03 Sep, 2008

1 commit

  • bb8fb4e68   ibft: fix target info parsing in ibft module ... Browse Code »

    I got this patch through Red Hat's bugzilla from the bug submitter and
    patch creator. I have just fixed it up so it applies without fuzz to
    upstream kernels.

    Original patch and description from Shyam kumar Iyer:

    The issue [ibft module not displaying targets with short names] is because
    of an offset calculatation error in the iscsi_ibft.c code. Due to this
    error directory structure for the target in /sys/firmware/ibft does not
    get created and so the initiator is unable to connect to the target.

    Note that this bug surfaced only with an name that had a short section at
    the end. eg: "iqn.1984-05.com.dell:dell". It did not surface when the
    iqn's had a longer section at the end. eg:
    "iqn.2001-04.com.example:storage.disk2.sys1.xyz"

    So, the eot_offset was calculated such that an extra 48 bytes i.e. the
    size of the ibft_header which has already been accounted was subtracted
    twice.

    This was not evident with longer iqn names because they would overshoot
    the total ibft length more than 48 bytes and thus would escape the bug.

    Signed-off-by: Shyam Kumar Iyer
    Signed-off-by: Mike Christie
    Cc: Konrad Rzeszutek
    Cc: Peter Jones
    Cc: James Bottomley
    Cc: Greg Kroah-Hartman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Christie
     

13 Aug, 2008

1 commit

  • 31bad9246   firmware/memmap: cleanup ... Browse Code »

    Various cleanup the drivers/firmware/memmap (after review by AKPM):

    - fix kdoc to conform to the standard
    - move kdoc from header to implementation files
    - remove superfluous WARN_ON() after kmalloc()
    - WARN_ON(x); if (!x) -> if(!WARN_ON(x))
    - improve some comments

    Signed-off-by: Bernhard Walle
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bernhard Walle
     

31 Jul, 2008

1 commit

29 Jul, 2008

1 commit

27 Jul, 2008

1 commit

  • 78681ac08   firmware: fix memmap printk format warnings ... Browse Code »

    Fix firmware/memmap printk format warnings:

    drivers/firmware/memmap.c:156: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'
    drivers/firmware/memmap.c:161: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t'

    Signed-off-by: Randy Dunlap
    Cc: Bernhard Walle
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

26 Jul, 2008

3 commits

19 Jul, 2008

1 commit

  • 65c011845   cpumask: Replace cpumask_of_cpu with cpumask_of_cpu_ptr ... Browse Code »

    * This patch replaces the dangerous lvalue version of cpumask_of_cpu
    with new cpumask_of_cpu_ptr macros. These are patterned after the
    node_to_cpumask_ptr macros.

    In general terms, if there is a cpumask_of_cpu_map[] then a pointer to
    the cpumask_of_cpu_map[cpu] entry is used. The cpumask_of_cpu_map
    is provided when there is a large NR_CPUS count, reducing
    greatly the amount of code generated and stack space used for
    cpumask_of_cpu(). The pointer to the cpumask_t value is needed for
    calling set_cpus_allowed_ptr() to reduce the amount of stack space
    needed to pass the cpumask_t value.

    If there isn't a cpumask_of_cpu_map[], then a temporary variable is
    declared and filled in with value from cpumask_of_cpu(cpu) as well as
    a pointer variable pointing to this temporary variable. Afterwards,
    the pointer is used to reference the cpumask value. The compiler
    will optimize out the extra dereference through the pointer as well
    as the stack space used for the pointer, resulting in identical code.

    A good example of the orthogonal usages is in net/sunrpc/svc.c:

    case SVC_POOL_PERCPU:
    {
    unsigned int cpu = m->pool_to[pidx];
    cpumask_of_cpu_ptr(cpumask, cpu);

    *oldmask = current->cpus_allowed;
    set_cpus_allowed_ptr(current, cpumask);
    return 1;
    }
    case SVC_POOL_PERNODE:
    {
    unsigned int node = m->pool_to[pidx];
    node_to_cpumask_ptr(nodecpumask, node);

    *oldmask = current->cpus_allowed;
    set_cpus_allowed_ptr(current, nodecpumask);
    return 1;
    }

    Signed-off-by: Mike Travis
    Signed-off-by: Ingo Molnar

    Mike Travis
     

15 Jul, 2008

1 commit

10 Jul, 2008

1 commit

08 Jul, 2008

2 commits

  • 69ac9cd62   sysfs: add /sys/firmware/memmap ... Browse Code »

    This patch adds /sys/firmware/memmap interface that represents the BIOS
    (or Firmware) provided memory map. The tree looks like:

    /sys/firmware/memmap/0/start (hex number)
    end (hex number)
    type (string)
    ... /1/start
    end
    type

    With the following shell snippet one can print the memory map in the same form
    the kernel prints itself when booting on x86 (the E820 map).

    --------- 8< --------------------------
    #!/bin/sh
    cd /sys/firmware/memmap
    for dir in * ; do
    start=$(cat $dir/start)
    end=$(cat $dir/end)
    type=$(cat $dir/type)
    printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
    done
    --------- >8 --------------------------

    That patch only provides the needed interface:

    1. The sysfs interface.
    2. The structure and enumeration definition.
    3. The function firmware_map_add() and firmware_map_add_early()
    that should be called from architecture code (E820/EFI, for
    example) to add the contents to the interface.

    If the kernel is compiled without CONFIG_FIRMWARE_MEMMAP, the interface does
    nothing without cluttering the architecture-specific code with #ifdef's.

    The purpose of the new interface is kexec: While /proc/iomem represents
    the *used* memory map (e.g. modified via kernel parameters like 'memmap'
    and 'mem'), the /sys/firmware/memmap tree represents the unmodified memory
    map provided via the firmware. So kexec can:

    - use the original memory map for rebooting,
    - use the /proc/iomem for setting up the ELF core headers for kdump
    case that should only represent the memory of the system.

    The patch has been tested on i386 and x86_64.

    Signed-off-by: Bernhard Walle
    Acked-by: Greg KH
    Acked-by: Vivek Goyal
    Cc: kexec@lists.infradead.org
    Cc: yhlu.kernel@gmail.com
    Signed-off-by: Ingo Molnar

    Bernhard Walle
     
  • 896395c29   Merge branch 'linus' into tmp.x86.mpparse.new Browse Code »
    Ingo Molnar
     

07 Jun, 2008

1 commit

25 May, 2008

1 commit

29 Apr, 2008

3 commits

22 Apr, 2008

2 commits

  • e80ab411e   Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6 ... Browse Code »

    * git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6: (36 commits)
    SCSI: convert struct class_device to struct device
    DRM: remove unused dev_class
    IB: rename "dev" to "srp_dev" in srp_host structure
    IB: convert struct class_device to struct device
    memstick: convert struct class_device to struct device
    driver core: replace remaining __FUNCTION__ occurrences
    sysfs: refill attribute buffer when reading from offset 0
    PM: Remove destroy_suspended_device()
    Firmware: add iSCSI iBFT Support
    PM: Remove legacy PM (fix)
    Kobject: Replace list_for_each() with list_for_each_entry().
    SYSFS: Explicitly include required header file slab.h.
    Driver core: make device_is_registered() work for class devices
    PM: Convert wakeup flag accessors to inline functions
    PM: Make wakeup flags available whenever CONFIG_PM is set
    PM: Fix misuse of wakeup flag accessors in serial core
    Driver core: Call device_pm_add() after bus_add_device() in device_add()
    PM: Handle device registrations during suspend/resume
    block: send disk "change" event for rescan_partitions()
    sysdev: detect multiple driver registrations
    ...

    Fixed trivial conflict in include/linux/memory.h due to semaphore header
    file change (made irrelevant by the change to mutex).

    Linus Torvalds
     
  • 429f731de   Merge branch 'semaphore' of git://git.kernel.org/pub/scm/linux/kernel/git/willy/misc ... Browse Code »

    * 'semaphore' of git://git.kernel.org/pub/scm/linux/kernel/git/willy/misc:
    Deprecate the asm/semaphore.h files in feature-removal-schedule.
    Convert asm/semaphore.h users to linux/semaphore.h
    security: Remove unnecessary inclusions of asm/semaphore.h
    lib: Remove unnecessary inclusions of asm/semaphore.h
    kernel: Remove unnecessary inclusions of asm/semaphore.h
    include: Remove unnecessary inclusions of asm/semaphore.h
    fs: Remove unnecessary inclusions of asm/semaphore.h
    drivers: Remove unnecessary inclusions of asm/semaphore.h
    net: Remove unnecessary inclusions of asm/semaphore.h
    arch: Remove unnecessary inclusions of asm/semaphore.h

    Linus Torvalds
     

20 Apr, 2008

2 commits

  • 138fe4e06   Firmware: add iSCSI iBFT Support ... Browse Code »

    Add /sysfs/firmware/ibft/[initiator|targetX|ethernetX] directories along with
    text properties which export the the iSCSI Boot Firmware Table (iBFT)
    structure.

    What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to
    extract from the machine NICs the iSCSI connection information so that they
    can automagically mount the iSCSI share/target. Currently the iSCSI
    information is hard-coded in the initrd. The /sysfs entries are read-only
    one-name-and-value fields.

    The usual set of data exposed is:

    # for a in `find /sys/firmware/ibft/ -type f -print`; do echo -n "$a: "; cat $a; done
    /sys/firmware/ibft/target0/target-name: iqn.2007.com.intel-sbx44:storage-10gb
    /sys/firmware/ibft/target0/nic-assoc: 0
    /sys/firmware/ibft/target0/chap-type: 0
    /sys/firmware/ibft/target0/lun: 00000000
    /sys/firmware/ibft/target0/port: 3260
    /sys/firmware/ibft/target0/ip-addr: 192.168.79.116
    /sys/firmware/ibft/target0/flags: 3
    /sys/firmware/ibft/target0/index: 0
    /sys/firmware/ibft/ethernet0/mac: 00:11:25:9d:8b:01
    /sys/firmware/ibft/ethernet0/vlan: 0
    /sys/firmware/ibft/ethernet0/gateway: 192.168.79.254
    /sys/firmware/ibft/ethernet0/origin: 0
    /sys/firmware/ibft/ethernet0/subnet-mask: 255.255.252.0
    /sys/firmware/ibft/ethernet0/ip-addr: 192.168.77.41
    /sys/firmware/ibft/ethernet0/flags: 7
    /sys/firmware/ibft/ethernet0/index: 0
    /sys/firmware/ibft/initiator/initiator-name: iqn.2007-07.com:konrad.initiator
    /sys/firmware/ibft/initiator/flags: 3
    /sys/firmware/ibft/initiator/index: 0

    For full details of the IBFT structure please take a look at:
    ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf

    [akpm@linux-foundation.org: fix build]
    Signed-off-by: Konrad Rzeszutek
    Cc: Mike Christie
    Cc: Peter Jones
    Cc: James Bottomley
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Konrad Rzeszutek
     
  • f70316dac   generic: use new set_cpus_allowed_ptr function ... Browse Code »

    * Use new set_cpus_allowed_ptr() function added by previous patch,
    which instead of passing the "newly allowed cpus" cpumask_t arg
    by value, pass it by pointer:

    -int set_cpus_allowed(struct task_struct *p, cpumask_t new_mask)
    +int set_cpus_allowed_ptr(struct task_struct *p, const cpumask_t *new_mask)

    * Modify CPU_MASK_ALL

    Depends on:
    [sched-devel]: sched: add new set_cpus_allowed_ptr function

    Signed-off-by: Mike Travis
    Signed-off-by: Ingo Molnar

    Mike Travis
     

19 Apr, 2008

1 commit

05 Apr, 2008

1 commit

  • abd24df82   ipmi: change device node ordering to reflect probe order ... Browse Code »

    In 2.6.14 a patch was merged which switching the order of the ipmi device
    naming from in-order-of-discovery over to reverse-order-of-discovery.

    So on systems with multiple BMC interfaces, the ipmi device names are being
    created in reverse order relative to how they are discovered on the system
    (e.g. on an IBM x3950 multinode server with N nodes, the device name for the
    BMC in the first node is /dev/ipmiN-1 and the device name for the BMC in the
    last node is /dev/ipmi0, etc.).

    The problem is caused by the list handling routines chosen in dmi_scan.c.
    Using list_add() causes the multiple ipmi devices to be added to the device
    list using a stack-paradigm and so the ipmi driver subsequently pulls them off
    during initialization in LIFO order. This patch changes the
    dmi_save_ipmi_device() list handling paradigm to a queue, thereby allowing the
    ipmi driver to build the ipmi device names in the order in which they are
    found on the system.

    Signed-off-by: Carol Hebert
    Signed-off-by: Corey Minyard
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Carol Hebert
     

24 Feb, 2008

2 commits

  • 43fe105a5   dmi: prevent linked list corruption ... Browse Code »

    Adding the same item to a given linked list more than once is guaranteed
    to break and corrupt the list. This is however what we do in dmi_scan
    since commit 79da4721117fcf188b4b007b775738a530f574da ("x86: fix DMI out
    of memory problems").

    Given that there is absolutely no interest in saving empty OEM strings
    anyway, I propose the simple and efficient fix below: we discard the empty
    OEM strings altogether.

    Signed-off-by: Jean Delvare
    Acked-by: Parag Warudkar
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Matt Domsch
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     
  • f3069ae9d   dmi: don't save the same device twice ... Browse Code »

    Now that we gather on-board devices from both DMI types 10 and 41, there is
    a possibility that we list the same device twice. In order to not confuse
    drivers, and also to save memory, make sure that we do not add duplicate
    devices to the dmi_devices list.

    Signed-off-by: Jean Delvare
    Cc: Wim Van Sebroeck
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     

09 Feb, 2008

1 commit

  • b4bd7d594   SMBIOS/DMI: add type 41 = Onboard Devices Extended Information ... Browse Code »

    From version 2.6 of the SMBIOS standard, type 10 (On Board Devices
    Information) becomes obsolete. The reason for this is that no further
    fields can be added to this structure without adversely affecting existing
    software's ability to properly parse the data.

    Therefore type 41 (Onboard Devices Extended Information) was added.
    The structure is as follows:

    struct smbios_type_41 {
    u8 type;
    u8 length;
    u16 handle;
    u8 reference_designation_string;
    u8 device_type; /* same device type as in type 10 */
    u8 device_type_instance;
    u16 segment_group_number;
    u8 bus_number;
    u8 device_function_number;
    };

    For more info: http://www.dmtf.org/standards/smbios

    Signed-off-by: Wim Van Sebroeck
    Cc: Jean Delvare
    Cc: Len Brown
    Cc: Jeff Garzik
    Cc: Tejun Heo
    Cc: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Wim Van Sebroeck
     

08 Feb, 2008

1 commit

07 Feb, 2008

3 commits

04 Feb, 2008

1 commit

03 Feb, 2008

1 commit

30 Jan, 2008

3 commits

  • 3212bff37   x86: left over fix for leak of early_ioremp in dmi_scan ... Browse Code »

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Yinghai Lu
     
  • 0d64484f7   x86: fix DMI ioremap leak ... Browse Code »

    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Ingo Molnar
     
  • 79da47211   x86: fix DMI out of memory problems ... Browse Code »

    People with HP Desktops (including me) encounter couple of DMI errors
    during boot - dmi_save_oem_strings_devices: out of memory and
    dmi_string: out of memory.

    On some HP desktops the DMI data include OEM strings (type 11) out of
    which only few are meaningful and most other are empty. DMI code
    religiously creates copies of these 27 strings (65 bytes each in my
    case) and goes OOM in dmi_string().

    If DMI_MAX_DATA is bumped up a little then it goes and fails in
    dmi_save_oem_strings while allocating dmi_devices of sizeof(struct
    dmi_device) corresponding to these strings.

    On x86_64 since we cannot use alloc_bootmem this early, the code uses a
    static array of 2048 bytes (DMI_MAX_DATA) for allocating the memory DMI
    needs. It does not survive the creation of empty strings and devices.

    Fix this by detecting and not newly allocating empty strings and instead
    using a one statically defined dmi_empty_string.

    Also do not create a new struct dmi_device for each empty string - use
    one statically define dmi_device with .name=dmi_empty_string and add
    that to the dmi_devices list.

    On x64 this should stop the OOM with same current size of DMI_MAX_DATA
    and on x86 this should save a good amount of (27*65 bytes +
    27*sizeof(struct dmi_device) bootmem.

    Compile and boot tested on both 32-bit and 64-bit x86.

    Signed-off-by: Parag Warudkar
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Parag Warudkar
     

25 Jan, 2008

4 commits