13 Jan, 2012

1 commit


22 Mar, 2011

1 commit

  • with an PAT-enabled kernel, when using uvesafb or vesafb, these drivers will
    create uncached-minus PAT entries for the framebuffer memory because they use
    ioremap() (not the *_cache or *_wc variants). When the framebuffer memory
    intersects with the video RAM used by Xorg, the complete video RAM will be
    mapped uncached-minus what results in a serve performance penalty.

    Here are the correct MTRR entries created by uvesafb:
    schlicht@netbook:~$ cat /proc/mtrr
    reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
    reg01: base=0x06ff00000 ( 1791MB), size= 1MB, count=1: uncachable
    reg02: base=0x070000000 ( 1792MB), size= 256MB, count=1: uncachable
    reg03: base=0x0d0000000 ( 3328MB), size= 16MB, count=1: write-combining

    And here are the problematic PAT entries:
    schlicht@netbook:~$ sudo cat /sys/kernel/debug/x86/pat_memtype_list
    PAT memtype list:
    write-back @ 0x0-0x1000
    uncached-minus @ 0x6fedd000-0x6fee3000
    uncached-minus @ 0x6fee2000-0x6fee3000
    uncached-minus @ 0x6fee2000-0x6fee3000
    uncached-minus @ 0x6fee2000-0x6fee3000
    uncached-minus @ 0x6fee2000-0x6fee3000
    uncached-minus @ 0x6fee2000-0x6fee3000
    uncached-minus @ 0x6fee2000-0x6fee3000
    uncached-minus @ 0x6fee2000-0x6fee3000
    uncached-minus @ 0x6fee3000-0x6fee4000
    uncached-minus @ 0x6fee3000-0x6fee4000
    uncached-minus @ 0x6fee3000-0x6fee4000
    uncached-minus @ 0xd0000000-0xe0000000
    Signed-off-by: Paul Mundt

    Thomas Schlichter
     

04 Mar, 2011

1 commit

  • Netlink message processing in the kernel is synchronous these days,
    capabilities can be checked directly in security_netlink_recv() from
    the current process.

    Signed-off-by: Patrick McHardy
    Reviewed-by: James Morris
    [chrisw: update to include pohmelfs and uvesafb]
    Signed-off-by: Chris Wright
    Signed-off-by: David S. Miller

    Patrick McHardy
     

11 Aug, 2010

1 commit

  • This is more kernel-ish, saves some space, and also allows us to
    expand the ops without breaking all the callers who are happy for the
    new members to be NULL.

    The few places which defined their own param types are changed to the
    new scheme (more which crept in recently fixed in following patches).

    Since we're touching them anyway, we change get() and set() to take a
    const struct kernel_param (which they really are). This causes some
    harmless warnings until we fix them (in following patches).

    To reduce churn, module_param_call creates the ops struct so the callers
    don't have to change (and casts the functions to reduce warnings).
    The modern version which takes an ops struct is called module_param_cb.

    Signed-off-by: Rusty Russell
    Reviewed-by: Takashi Iwai
    Tested-by: Phil Carmody
    Cc: "David S. Miller"
    Cc: Ville Syrjala
    Cc: Dmitry Torokhov
    Cc: Alessandro Rubini
    Cc: Michal Januszewski
    Cc: Trond Myklebust
    Cc: "J. Bruce Fields"
    Cc: Neil Brown
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-input@vger.kernel.org
    Cc: linux-fbdev-devel@lists.sourceforge.net
    Cc: linux-nfs@vger.kernel.org
    Cc: netdev@vger.kernel.org

    Rusty Russell
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

12 Nov, 2009

1 commit

  • Remove fb_save_state() and fb_restore_state operations from frame buffer layer.
    They are used only in two drivers:
    1. savagefb - and cause bug #11248
    2. uvesafb

    Usage of these operations is misunderstood in both drivers so kill these
    operations, fix the bug #11248 and avoid confusion in the future.

    Tested on Savage 3D/MV card and the patch fixes the bug #11248.

    The frame buffer layer uses these funtions during switch between graphics
    and text mode of the console, but these drivers saves state before
    switching of the frame buffer (in the fb_open) and after releasing it (in
    the fb_release). This defeats the purpose of these operations.

    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11248

    Signed-off-by: Krzysztof Helt
    Reported-by: Jochen Hein
    Tested-by: Jochen Hein
    Cc: Geert Uytterhoeven
    Cc: Michal Januszewski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Krzysztof Helt
     

03 Oct, 2009

2 commits


18 Jul, 2009

1 commit

  • The connector documentation states that the argument to the callback
    function is always a pointer to a struct cn_msg, but rather than encode it
    in the API itself, it uses a void pointer everywhere. This doesn't make
    much sense to encode the pointer in documentation as it prevents proper C
    type checking from occurring and can easily allow people to use the wrong
    pointer type. So convert the argument type to an explicit struct cn_msg
    pointer.

    Signed-off-by: Mike Frysinger
    Signed-off-by: David S. Miller

    Mike Frysinger
     

12 Jun, 2009

1 commit

  • 1) Now module_param(..., invbool, ...) requires a bool, and similarly
    module_param(..., bool, ...) allows it, change pmi_setpal to a bool.
    2) #define param_get_scroll to NULL, since it can never be called (perm
    argument to module_param_named is 0).
    3) Return -EINVAL from param_set_scroll if the value is bad, so it's
    reported.

    Note that I don't think the old fb_get_options() is required for new
    drivers: the parameters automatically work as uvesafb.XXX=... anyway.

    Acked-by: Michał Januszewski
    Signed-off-by: Rusty Russell

    Rusty Russell
     

14 Apr, 2009

1 commit

  • uvesafb incorrectly sets the length of the color fields to 6 bits for
    PSEUDOCOLOR modes, even though 8 bits are always used per pixel. Fix this
    by setting the length to 8.

    The switch of the DAC width from the default 6 bits to 8 bits is retained
    and tracked internally in the driver, but never exposed to userspace.

    Signed-off-by: Michal Januszewski
    Acked-by: Krzysztof Helt
    Cc:
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Januszewski
     

01 Apr, 2009

3 commits


06 Feb, 2009

1 commit

  • Currently, netlink_broadcast() reports errors to the caller if no
    messages at all were delivered:

    1) If, at least, one message has been delivered correctly, returns 0.
    2) Otherwise, if no messages at all were delivered due to skb_clone()
    failure, return -ENOBUFS.
    3) Otherwise, if there are no listeners, return -ESRCH.

    With this patch, the caller knows if the delivery of any of the
    messages to the listeners have failed:

    1) If it fails to deliver any message (for whatever reason), return
    -ENOBUFS.
    2) Otherwise, if all messages were delivered OK, returns 0.
    3) Otherwise, if no listeners, return -ESRCH.

    In the current ctnetlink code and in Netfilter in general, we can add
    reliable logging and connection tracking event delivery by dropping the
    packets whose events were not successfully delivered over Netlink. Of
    course, this option would be settable via /proc as this approach reduces
    performance (in terms of filtered connections per seconds by a stateful
    firewall) but providing reliable logging and event delivery (for
    conntrackd) in return.

    This patch also changes some clients of netlink_broadcast() that
    may report ENOBUFS errors via printk. This error handling is not
    of any help. Instead, the userspace daemons that are listening to
    those netlink messages should resync themselves with the kernel-side
    if they hit ENOBUFS.

    BTW, netlink_broadcast() clients include those that call
    cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they
    internally call netlink_broadcast() and return its error value.

    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: David S. Miller

    Pablo Neira Ayuso
     

17 Oct, 2008

1 commit

  • Some BIOSes return error codes when queried for information about
    modes from their own modelist. uvesafb treats this as an error
    case and bails out.

    Change this behavior so that broken modes do not prevent the driver
    from working. Only the failure to retrieve information about any
    usable video mode is considered to be an error case.

    Signed-off-by: Michal Januszewski
    Cc: Krzysztof Helt
    Cc: "H. Peter Anvin"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Januszewski
     

25 Jul, 2008

1 commit


28 Apr, 2008

2 commits

  • Fix bug identified by Daniel Marjamki: `m' is leaked on the error path.

    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=10452

    Cc: Daniel Marjamki
    Cc: "Antonino A. Daplas"
    Cc: "Randy.Dunlap"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • Don't treat valid modes returned by fb_find_mode() (best-fit modes, default
    modes or the first valid mode) as errors.

    Currently, when fb_find_mode() finds a valid mode belonging to one of the
    above-mentioned classes, uvesafb will ignore it and will try to set a 640x480
    video mode. The expected behaviour (introduced by this patch) would be to use
    the valid mode returned by fb_find_mode() instead.

    Signed-off-by: Michal Januszewski
    Cc: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Januszewski
     

24 Feb, 2008

1 commit

  • Fix following warnings:
    WARNING: drivers/video/built-in.o(.text+0x7c64a): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: drivers/video/built-in.o(.text+0x7c65d): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: drivers/video/built-in.o(.text+0x7c679): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: drivers/video/built-in.o(.text+0x7c699): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: drivers/video/built-in.o(.text+0x7c69f): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: drivers/built-in.o(.text+0xa3676): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: drivers/built-in.o(.text+0xa3689): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: drivers/built-in.o(.text+0xa36a5): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: drivers/built-in.o(.text+0xa36c5): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: drivers/built-in.o(.text+0xa36cb): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: vmlinux.o(.text+0x4a079a): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: vmlinux.o(.text+0x4a07ad): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: vmlinux.o(.text+0x4a07c9): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: vmlinux.o(.text+0x4a07e9): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan
    WARNING: vmlinux.o(.text+0x4a07ef): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan

    Remove __devinitdata annotation from the variable ypan.

    Signed-off-by: Sergio Luis
    Cc: Michal Januszewski
    Cc: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sergio Luis
     

07 Feb, 2008

1 commit

  • Some cleanups in uvesafb:
    - The custom module_param() get/set functions don't need to be inlined
    since it is referred to via a pointer in a struct.
    - don't end a #define with a ';'
    - remove one of the single quote marks in "''ypan'"

    Signed-off-by: Randy Dunlap
    Cc: "Antonino A. Daplas"
    Cc: Michal Januszewski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

15 Jan, 2008

1 commit

  • Mark uvesafb_init_mtrr() as __devinit since its caller is __devinit
    and since it accesses __devinitdata.

    WARNING: vmlinux.o(.text+0x4df80e): Section mismatch: reference to .init.data: (between 'uvesafb_init_mtrr' and 'uvesafb_show_vbe_ver')

    Variable 'blank' cannot be __devinitdata since it is referenced in an
    fb_ops method that could be called at any time.

    WARNING: vmlinux.o(.text+0x4dfc1e): Section mismatch: reference to .init.data:blank (between 'param_set_scroll' and 'vesa_setpalette')
    WARNING: vmlinux.o(.text+0x4dfc24): Section mismatch: reference to .init.data:blank (between 'param_set_scroll' and 'vesa_setpalette')

    Signed-off-by: Randy Dunlap
    Cc: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

15 Nov, 2007

1 commit


17 Oct, 2007

1 commit

  • uvesafb is an enhanced version of vesafb. It uses a userspace helper (v86d)
    to execute calls to the x86 Video BIOS functions. The driver is not limited
    to any specific arch and whether it works on a given arch or not depends on
    that arch being supported by the userspace daemon. It has been tested on
    x86_32 and x86_64.

    A single BIOS call is represented by an instance of the uvesafb_ktask
    structure. This structure contains a buffer, a completion struct and a
    uvesafb_task substructure, containing the values of the x86 registers, a flags
    field and a field indicating the length of the buffer. Whenever a BIOS call
    is made in the driver, uvesafb_exec() builds a message using the uvesafb_task
    substructure and the contents of the buffer. This message is then assigned a
    random ack number and sent to the userspace daemon using the connector
    interface.

    The message's sequence number is used as an index for the uvfb_tasks array,
    which provides a mapping from the messages coming from userspace to the
    in-kernel uvesafb_ktask structs.

    The userspace daemon performs the requested operation and sends a reply in the
    form of a uvesafb_task struct and, optionally, a buffer. The seq and ack
    numbers in the reply should be exactly the same as those in the request.

    Each message from userspace is processed by uvesafb_cn_callback() and after
    passing a few sanity checks leads to the completion of a BIOS call request.

    Signed-off-by: Michal Januszewski
    Signed-off-by: Antonino Daplas
    Cc: Paul Mundt
    Cc: Paulo Marques
    Cc: "H. Peter Anvin"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Januszewski