- 23 Aug, 2004 40 commits
-
-
Raphael Zimmerer authored
Here's a minimal patch to support the Exar Corp. XR17C158 Octal UART Chip (PCI). Signed-off-by:
Raphael Zimmerer <killekulla@rdrz.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Roger Luethi authored
If you win the race with a starting process, you can read its environment. Signed-off-by:
-
Andrea Arcangeli authored
A trap gate shouldn't affect the irq status at all, so we don't need to test whether the trapping code had interrupts enabled. Signed-off-by:
-
Jan Blunck authored
If the whole directory is read, ext2_readdir() sets the f_pos to a multiple of the page size (because of the conditions of the outer for loop). This sets the wrong f_pos for directory inodes on ext2 partitions with a block size differing from the page size. Signed-off-by:
Jan Blunck <j.blunck@tu-harburg.de> Signed-off-by:
-
Jesper Juhl authored
drivers/net/wan/dscc4.c: In function `dscc4_found1': drivers/net/wan/dscc4.c:369: sorry, unimplemented: inlining failed in call to 'dscc4_set_quartz': function body not available drivers/net/wan/dscc4.c:898: sorry, unimplemented: called from here Signed-off-by:
Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by:
-
Jesper Juhl authored
This patch fixes the following build error (in 2.6.8-rc2-mm1) when using gcc 3.4.0 drivers/scsi/aic7xxx/aic79xx_osm.c: In function `ahd_linux_dv_transition': drivers/scsi/aic7xxx/aic79xx_osm.c:522: sorry, unimplemented: inlining failed in call to 'ahd_linux_dv_fallback': function body not available drivers/scsi/aic7xxx/aic79xx_osm.c:3070: sorry, unimplemented: called from here drivers/scsi/aic7xxx/aic79xx_osm.c:522: sorry, unimplemented: inlining failed in call to 'ahd_linux_dv_fallback': function body not available drivers/scsi/aic7xxx/aic79xx_osm.c:3093: sorry, unimplemented: called from here drivers/scsi/aic7xxx/aic79xx_osm.c:522: sorry, unimplemented: inlining failed in call to 'ahd_linux_dv_fallback': function body not available drivers/scsi/aic7xxx/aic79xx_osm.c:3144: sorry, unimplemented: called from here drivers/scsi/aic7xxx/aic79xx_osm.c:522: sorry, unimplemented: inlining failed in call to 'ahd_linux_dv_fallback': function body not available drivers/scsi/aic7xxx/aic79xx_osm.c:3257: sorry, unimplemented: called from here drivers/scsi/aic7xxx/aic79xx_osm.c:522: sorry, unimplemented: inlining failed in call to 'ahd_linux_dv_fallback': function body not available drivers/scsi/aic7xxx/aic79xx_osm.c:3288: sorry, unimplemented: called from here drivers/scsi/aic7xxx/aic79xx_osm.c:522: sorry, unimplemented: inlining failed in call to 'ahd_linux_dv_fallback': function body not available drivers/scsi/aic7xxx/aic79xx_osm.c:3317: sorry, unimplemented: called from here It first removes a duplicate forward declaration of ahd_linux_dv_fallback and then moves the function before its first use so inlining can succeed. Signed-off-by:
-
Adrian Bunk authored
CC drivers/media/radio/radio-maestro.o drivers/media/radio/radio-maestro.c: In function `maestro_radio_init': drivers/media/radio/radio-maestro.c:273: sorry, unimplemented: inlining failed in call to 'radio_install': function body not available drivers/media/radio/radio-maestro.c:291: sorry, unimplemented: called from here drivers/media/radio/radio-maestro.c:273: sorry, unimplemented: inlining failed in call to 'radio_install': function body not available drivers/media/radio/radio-maestro.c:295: sorry, unimplemented: called from here make[3]: *** [drivers/media/radio/radio-maestro.o] Error 1 Signed-off-by:
Adrian Bunk <bunk@fs.tum.de> Signed-off-by:
-
Adrian Bunk authored
CC drivers/char/mxser.o drivers/char/mxser.c: In function `mxser_interrupt': drivers/char/mxser.c:352: sorry, unimplemented: inlining failed in call to 'mxser_receive_chars': function body not available drivers/char/mxser.c:1347: sorry, unimplemented: called from here drivers/char/mxser.c:354: sorry, unimplemented: inlining failed in call to 'mxser_check_modem_status': function body not available drivers/char/mxser.c:1350: sorry, unimplemented: called from here drivers/char/mxser.c:353: sorry, unimplemented: inlining failed in call to 'mxser_transmit_chars': function body not available drivers/char/mxser.c:1355: sorry, unimplemented: called from here make[2]: *** [drivers/char/mxser.o] Error 1 Signed-off-by:
-
Adrian Bunk authored
CC drivers/char/istallion.o drivers/char/istallion.c: In function `stli_init': drivers/char/istallion.c:4603: sorry, unimplemented: inlining failed in call to 'stli_getbrdnr': function not considered for inlining drivers/char/istallion.c:4577: sorry, unimplemented: called from here drivers/char/istallion.c: At top level: drivers/char/istallion.c:422: warning: 'istallion_pci_tbl' defined but not used make[2]: *** [drivers/char/istallion.o] Error 1 Signed-off-by:
-
Antonino Daplas authored
Took code from James' tree to be hopefully included in the mm tree so it can receive more testing. Signed-off-by:
Antonino Daplas <adaplas@pol.net> Signed-off-by:
-
Antonino Daplas authored
Took code from James' tree to be hopefully included in the mm tree so it can receive more testing. Signed-off-by:
-
Antonino Daplas authored
Took code from James' tree to be hopefully included in the mm tree so it can receive more testing. Signed-off-by:
-
Antonino Daplas authored
This patch was submitted by James Hoover < ch@hpl.hp.com> to James a long time ago (2.5 development) which ports the epson driver to 2.6. Took the code from James tree to be hopefully included in the mm tree so it can get more testing. Signed-off-by:
-
Antonino Daplas authored
Although the rivafb advertises its capability as DirectColor, the hardware is actually set in Truecolor (CLUT cannot be altered). This mismatch occasionally produces wrong colors, such as wrong logo colors at 32bpp and gamma utilities (such as xgamma) does not work at all. Changes: 1. Fixes the above problems by setting the hardware to accept changing of the CLUT. 2. Fixes color problems for NV_ARCH_03 (Riva128) 3. Build a private modelist from the EDID (for use by fbcon) 4. Mark several functions/data as __devinit/__initdata 5. Remove unused fields from struct riva_par Signed-off-by:
-
Antonino Daplas authored
The patch adds the ability for vesafb to switch the DAC from 6-bit to 8-bit at kernel boot. Besides fixing the failure to draw the 224-color logo, an 8-bit DAC will also provide a wider color range for user applications. Signed-off-by:
-
Antonino Daplas authored
This patch adds support for the bold attribute for monochrome framebuffers. This fixes a regression from 2.4 where bold, underline and reverse attributes are supported. Signed-off-by:
-
Antonino Daplas authored
If a request for deletion of an entry in the mode database is requested, do it at core fbdev level instead of doing it at the console level. Signed-off-by:
-
Antonino Daplas authored
This patch is entirely optional. Its only advantage is reduction of kernel size by ~5-6K. a. Mark modedb as __init. b. Add CONFIG_FB_MODE_HELPERS. Unselecting this will uninclude the code for Generalized Timing Formula and the EDID parser on kernel compilation. These are used only by radeonfb, rivafb and i810fb. Signed-off-by:
-
Antonino Daplas authored
This is optional but applying it should enhance fbdev functionality. The patch allows removal of entries to the mode list. This is done by setting the var->activate field to FB_ACTIVATE_INV_MODE. Only modes that are not in use by any of the console or by the current var will be deleted. Signed-off-by:
-
Antonino Daplas authored
This patch adds the following: a. convert struct fb_var_screeninfo to struct display and vice versa b. save settings of graphics card to struct display c. save settings of display to struct display as a pointer to a struct fb_videomode d. check var in fb_set_var for modes, and if unique, add them to the mode list. Signed-off-by:
-
Antonino Daplas authored
The patch adds support for a mode database in a linked list form. Included in the patch are exportable functions that will: a. convert struct fb_videomode to struct fb_var_screeninfo and vice versa b. search the mode list for matching or best-fit modes c. add/delete entries to the database d. convert a mode array to a mode list e. destroy the entire list d. compare 2 modes Signed-off-by:
-
Luca Tettamanti authored
radeonfb, rivafb and i810fb need CONFIG_FB_MODE_HELPERS. Signed-off-by:
-
Luca Risolia authored
This avoids compiler errors about undefined "__user" macros when including "videodev.h" in userspace applications. Signed-off-by:
-
Guido Guenther authored
Kill riva_chips_info and riva_chips and replace the NV_ARCH_ determination with a less error prone one. We better use the driver_data for something more interesting later. From: "Antonino A. Daplas" <adaplas@hotpop.com> 1. modified patch so it's in -p1 form 2. killed compile warning when CONFIG_FB_RIVA_I2C is not set 3. changed U032 to u32 in riva_get_arch() Signed-of-by:
Guido Guenther <agx@sigxcpu.org> Signed-off-by:
-
Antonino Daplas authored
Current algorithm does not choose correct logo type for directcolor < 24 bpp. It chooses logo_224, but this is too deep for bpp < 24. This should fix the problem. Signed-off-by:
-
Antonino Daplas authored
1. Fixed cursor corruption if acceleration is enabled 2. Round up fields in var instead of rounding down 3. Set capabilities flags 4. Added myself to the MAINTAINERS file for i810fb 5. Make i810fb depend on X86 but not X86_64 6. Fixed typo in i810_init_monspecs(). Reported by Manuel Lauss <slauss@resi.at>. Signed-off-by:
-
Antonino Daplas authored
Do not tap VGA ports if arch is not X86. Signed-off-by:
-
Antonino Daplas authored
With David Eger's patch for advertising hardware capabilities to fbcon, only a few drivers so far have been converted to do just that. As a result, scrolling speed of some drivers will not be optimal (SCROLL_REDRAW). The patch adds the correct flags for all drivers (except for matroxfb -leave this to Petr-, and a few drivers that are not ported yet to 2.6). *Majority of changes is FBINFO_FLAG_DEFAULT -> FBINFO_DEFAULT Signed-off-by:
-
Antonino Daplas authored
Although the depth can be correctly inferred from bits_per_pixel (if bits_per_pixel == 1), for the sake of consistency, drivers should still set the color fields correctly. True even if the first patch is not applied. (I've combined everything in a single diff since there is only 1 logical change) Signed-off-by:
-
Antonino Daplas authored
1. If you remember this thread (HP300 support checked in), one concern was how to support framebuffers with bpp == 8 but color depth < 8 (chunky layout). I suggested to use the fields in var->{red|green|blue} to differentiate between bits_per_pixel and depth. Included is a patch that does that. (The above assumes background/foreground of 0/1. If hardware needs a different value, such as 0 - black, 0xff - white, just indicate TRUECOLOR or DIRECTCOLOR and set info->pseudopalette correctly in xxxfb_setcolreg().) The patch will break the following drivers when in monochrome since they do not set the proper color bitfields. I've included a fix in patch #2. 68328fb bw2fb cirrusfb dnfb macfb stifb tx3912fb 2. Besides the change above, support for the inverse and underline attribute is added in monochrome mode. One should get text which are underlined/reversed if the corresponding attribute is set. 3. Because vt.c uses a 16-color palette, use fbcon_default_cmap if framebuffer can do less than 16 colors. In 4 colors, display will be grayscaled. In 8 colors, display should have the same colors as a 16-color console but will lack brightness/ intensity. 4. Fix monochrome logo drawing. 5. Reduce code of fbcon_putc so it just calls fbcon_putcs. Signed-off-by: -
Antonino Daplas authored
1. Created a database of broken displays and their associated fixes. Original patch from Brian S. Julin <bri@tull.umassp.edu>. Only the monitor manufacturer and model is checked, perhaps we can also check for the serial number? 2. Added an all_null check in edid_checksum since the checksum will also be zero if the entire block is zeroed. Signed-off-by:
-
Nicolas Boichat authored
The I2C busses opened by rivafb were deleted immediately after reading the EDID, but they should be kept open, so user-space applications can use them. They are now deleted when the driver is unloaded. Signed-off-by:
-
David Eger authored
Very similar to Francois Romieu's fixes for cirrusfb, here we: * Provide meaningful error values from radeonfb_pci_register() * Fix unbalanced pci_enable_device() * Fix unbalanced fb_alloc_cmap() * Fix a failure-case bug where we accidentally memset_io(0, 0, size); * Use pci_request_regions() instead of request_mem_region() Signed-off-by:
David Eger <eger@havoc.gtf.org> Signed-off-by:
-
Dave Hansen authored
The following patch removes the individual free area initialization from free_area_init_core(), and puts it in a new function zone_init_free_lists(). It also creates pages_to_bitmap_size(), which is then used in zone_init_free_lists() as well as several times in my free area bitmap resizing patch. First of all, I think it looks nicer this way, but it's also necessary to have this if you want to initialize a zone after system boot, like if a NUMA node was hot-added. In any case, it should be functionally equivalent to the old code. Compiles and boots on x86. I've been running with this for a few weeks, and haven't seen any problems with it yet. Signed-off-by:
-
Nick Piggin authored
Use an rwsem to protect the shrinker list instead of a regular semaphore. Modifications to the list are now done under the write lock, shrink_slab takes the read lock, and access to shrinker->nr becomes racy (which is no different to how the page lru scanner is implemented). The shrinker functions become concurrent. Previously, having the slab scanner get preempted or scheduling while holding the semaphore would cause other tasks to skip putting pressure on the slab. Also, make shrink_icache_memory return -1 if it can't do anything in order to hold pressure on this cache and prevent useless looping in shrink_slab. Signed-off-by:
Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Mark Broadbent authored
The APIC and IO-APIC code is very verbose on startup especially on SMP machines. This patch allows the verbosity of the APIC code to be controlled through the boot-time option apic= using three levels: quiet, verbose and debug. The default level is quiet. Signed-off-by:
Mark Broadbent <markb@wetlettuce.com> Signed-off-by:
-
Zwane Mwaikambo authored
Now that things got cleaned up a bit, there is no real reason why the pit initialisation code has to be in i8259.c. Move it to timer_pit.ca Signed-off-by:
Zwane Mwaikambo <zwane@fsmlabs.com> Signed-off-by:
-
Dimitri Sivanich authored
Here is another cache_reap optimization that reduces latency when applied after the 'Move cache_reap out of timer context' patch I submitted on 7/14 (for inclusion in -mm next week). Signed-off-by:
Dimitri Sivanich <sivanich@sgi.com> Signed-off-by:
-
Bálint Márton authored
At boot time, get_random_bytes always returns the same random data, as if there were a constant random seed. For example, if I use the kernel level ip autoconfiguration with dhcp, the kernel will create a dhcp request packet with always the same transaction ID. (If you have more than one computers, and they are booting at the same time, then this is a big problem) That happens, because only the primary entropy pool is initialized with the system time, in function rand_initialize. The secondary pool is only cleared. In this early stage of booting, there is usually no user interaction, or usable disk interrupts, so the kernel can't add any real random bytes to the primary pool. And altough the system time is in the primary pool, the kernel does not consider it real random data, so you can't read from the primary pool, before at least a part of it will be filled with some real randomness (interrupt timing). Therefore all random data will come from the secondary pool, and the kernel cannot reseed the secondary pool, because there is no real randomness in the primary one. The solution is simple: Initialize not just the primary, but also the secondary pool with the system time. Signed-off-by:
-
Samuel Thibault authored
There's something wrong in cdrom.c: cdrom_get_last_written() for instance calls cdrom_get_disc_info() and cdrom_get_track_info() to get information about tracks, but these functions don't ensure that all the track_information or disc_information structure is filled: /* (buflen was first set to 8 to get track_information_length field) */ if ((ret = cdo->generic_packet(cdi, &cgc))) return ret; cgc.buflen = be16_to_cpu(ti->track_information_length) + sizeof(ti->track_information_length); if (cgc.buflen > sizeof(track_information)) cgc.buflen = sizeof(track_information); cgc.cmd[8] = cgc.buflen; return cdo->generic_packet(cdi, &cgc); The second test ensures that at least we won't overflow the structure, but nothing ensures that all the structure will be filled. And indeed, we have a drive here that won't fill it all: the returned track_information_length field will be *less than* sizeof(track_information) - sizeof(ti->track_information_length), so that cdrom_get_last_written() reads values that weren't filled in! As a result, we are sometimes unable to read some parts of CDROMs, depending on the uninitialized state of the structure... Here is a patch that adds filling checks: cdrom_get_disc_info() and cdrom_get_track_info() return the actual filled length, and it's up to the caller to check that this is enough for him to get the values it wants. Note: adding something like a #define spanof(TYPE, MEMBER) ((size_t) ((&((TYPE *)0)->MEMBER)+1)) definition just near that of offsetof() in include/linux/stddef.h would make it more pretty, but still it won't help for bitfields :/ Signed-off-by:
-
