headers
Ralf Baechle | 1 Feb 2005 01:02
Favicon

Re: [2.6 patch] move dp83840.h to Documentation/

On Tue, Feb 01, 2005 at 12:41:58AM +0100, Adrian Bunk wrote:

> 
> dp83840.h is included once but none of the definitions it contains is
> actually used.
> 
> Ralf Baechle wants that it stays as documentation, so this patch moves 
> it under Documentation/ .

Under Documentation is certainly not the right place for a piece of code,
so let's do it as David says.

  Ralf
Permalink | Reply | 0 comments |
headers
Matt Domsch | 1 Feb 2005 01:09
Picon
Favicon

[RFC][PATCH 2.6.11-rc2] vmlinux: put built-in module parameter info in vmlinux

Module parameter descriptions are added to loadable modules, but is
omitted from objects built into the kernel itself.  It would be nice
if you could get the list of parameters usable on the kernel command
line by looking at vmlinux.

$ modinfo vmlinux | grep parm:
parm:           thermal.tzp:Thermal zone polling frequency, in 1/10 seconds.
parm:           drm.drm_debug:Enable debug output
parm:           drm.drm_cards_limit:Maximum number of graphics cards
parm:           i8042.debug:Turn i8042 debugging mode on and off
parm:           i8042.noacpi:Do not use ACPI to detect controller settings
parm:           i8042.dumbkbd:Disable the AUX Loopback command while probing for the AUX port
parm:           i8042.dumbkbd:Pretend that controller can only read data from keyboard
parm:           i8042.direct:Put keyboard port into non-translated mode.
parm:           i8042.reset:Reset controller during init and cleanup.
parm:           i8042.unlock:Ignore keyboard lock.
parm:           i8042.nomux:Do not check whether an active multiplexing conrtoller is present.
parm:           i8042.noaux:Do not probe or use AUX (mouse) port.
parm:           8250.probe_rsa:Probe I/O ports for RSA
parm:           8250.share_irqs:Share IRQs with other non-8250/16x50 devices (unsafe)
parm:           rd.rd_blocksize:Blocksize of each RAM disk in bytes.
parm:           rd.rd_size:Size of each RAM disk in kbytes.
parm:           usbcore.use_both_schemes:try the other device initialization scheme if the first one fails
parm:           usbcore.old_scheme_first:start with the old device initialization scheme
parm:           usbcore.blinkenlights:true to cycle leds on hubs
parm:           usbcore.usbfs_snoop:true to log all usbfs traffic
parm:           mousedev.tap_time:Tap time for touchpads in absolute mode (msecs)
parm:           mousedev.yres:Vertical screen resolution
parm:           mousedev.xres:Horizontal screen resolution
parm:           atkbd.extra:Enable extra LEDs and keys on IBM RapidAcces, EzKey and similar keyboards
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrian Bunk | 1 Feb 2005 01:29
Picon

[2.6 patch] remove dp83840.h

On Mon, Jan 31, 2005 at 03:46:07PM -0800, David S. Miller wrote:
> On Tue, 1 Feb 2005 00:41:58 +0100
> Adrian Bunk <bunk <at> stusta.de> wrote:
> 
> > dp83840.h is included once but none of the definitions it contains is
> > actually used.
> > 
> > Ralf Baechle wants that it stays as documentation, so this patch moves 
> > it under Documentation/ .
> 
> No, let's kill this thing altogether.  The only driver in the world
> using the CSCONFIG_* defines in there is the sunhme driver and it
> defines it's own macros in drivers/net/sunhme.h  This header is more
> than useless these days.
> 
> The header still exists in older trees and the revision history.
> So people can still get to it there.

OK, patch below

cu
Adrian

<--  snip  -->

dp83840.h is included once but none of the definitions it contains is
actually used.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bernd Eckenfels | 1 Feb 2005 01:07
Picon

Re: [RFC] "biological parent" pid

In article <Pine.LNX.4.53.0501311923440.18039 <at> gockel.physik3.uni-rostock.de> you wrote:
> I am not aware of concepts in Linux or other unices that apply to this
> case.

Normal process accounting.

If you want to keep the pid of the bio-parent, you also need to keep the
start-time to make it unique. Better would be to have a all-time-unqiue
process handle. But I think it is better to not have that field, but use
audit logs. That is especially needed if you want to track chains, because
it doesnt help you to know the bio parent if you have no idea what that was.

Gruss
Bernd
Permalink | Reply | 1 comment |
headers
Benjamin Herrenschmidt | 1 Feb 2005 01:38

Re: [PATCH] ppc64: Implement a vDSO and use it for signal trampoline


> Also notice that ':=' uses all over. No need to use late evaluation when
> no dynamic references are used ($ $ <at>  etc.).

Hrm... Rusty tells me that you got it backward ;) Anyway, I'll stick
to := for now, it's not really an issue.

Ben.
Permalink | Reply | 4 comments |
headers
Greg KH | 1 Feb 2005 01:15
Gravatar

Re: [PATCH 1/1] pci: Add Citrine quirk

On Fri, Jan 28, 2005 at 08:53:47AM -0600, brking <at> us.ibm.com wrote:
> 
> The IBM Citrine chipset has a feature that if PCI config register
> 0xA0 is read while DMAs are being performed to it, there is the possiblity
> that the parity will be wrong on the PCI bus, causing a parity error and
> a master abort. On this chipset, this register is simply a debug register
> for the chip developers and the registers after it are not defined.
> Patch sets cfg_size to 0xA0 to prevent this problem from being seen.
> 
> Signed-off-by: Brian King <brking <at> us.ibm.com>

Applied, thanks.

greg k-h
Permalink | Reply | 0 comments |
headers
Bill Huey | 1 Feb 2005 01:39

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

On Mon, Jan 31, 2005 at 05:29:10PM -0500, Bill Davidsen wrote:
> The problem hasn't changed in a few decades, neither has the urge of 
> developers to make their app look good at the expense of the rest of the 
> system. Been there and done that myself.
> 
> "Back when" we had no good tools except to raise priority and drop 
> timeslice if a process blocked for i/o and vice-versa if it used the 
> whole timeslice. The amzing thing is that it worked reasonably well as 
> long as no one was there who knew how to cook the books the scheduler 
> used. And the user could hold off interrupts for up to 16ms, just to 
> make it worse.

A lot of this scheduling policy work is going to have to be redone as
badly written apps start getting their crap together and as this patch
is more and more pervasive in the general Linux community. What's
happening now is only the beginning of things to come and it'll require
a solid sample application with even more hooks into the kernel before
we'll see the real benefits of this patch. SCHED_FIFO will have to do
until more development happens with QoS style policies.

bill
Permalink | Reply | 0 comments |
headers
Greg KH | 1 Feb 2005 01:15
Gravatar

Re: [PATCH] sysfs: export the vfs release call of binary attribute

On Thu, Jan 27, 2005 at 09:34:10PM +0100, Kay Sievers wrote:
> On Thu, Jan 27, 2005 at 09:19:23PM +0100, Kay Sievers wrote:
> > Initialize the allocated bin_attribute structure, otherwise unused fields
> > are pointing to random places.
> 
> Sorry, wrong place for the inititalization.
> 
> Signed-off-by: Kay Sievers <kay.sievers <at> vrfy.org>

Applied, thanks.

greg k-h
Permalink | Reply | 0 comments |
headers
Greg KH | 1 Feb 2005 01:18
Gravatar

Re: [PATCH] pci_proc_domain

On Mon, Jan 17, 2005 at 07:23:35PM +0000, Matthew Wilcox wrote:
> 
> There's no need for the architectures to know how to name busses,
> so replace pci_name_bus with pci_proc_domain -- a predicate to allow
> architectures to choose whether domains are included in /proc/bus/pci
> or not.  I've converted all architectures but only tested ia64 and a
> CONFIG_PCI_DOMAINS=n build.

Applied, thanks.

greg k-h
Permalink | Reply | 0 comments |
headers
Greg KH | 1 Feb 2005 01:46
Gravatar

Re: [PATCH][I2C] Marvell mv64xxx i2c driver

On Mon, Jan 31, 2005 at 11:41:28AM -0700, Mark A. Greer wrote:
> Greg KH wrote:
> 
> >On Tue, Jan 25, 2005 at 06:26:45PM -0700, Mark A. Greer wrote:
> > 
> >
> >>+static inline void
> >>+mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
> >>   
> >>
> >
> >This is a much too big of a function to be "inline".  Please change it.
> >Same for your other inline functions, that's not really needed, right?
> >
> > 
> >
> >>+{
> >>+	pr_debug("mv64xxx_i2c_fsm: ENTER--state: %d, status: 0x%x\n",
> >>+		drv_data->state, status);
> >>   
> >>
> >
> >Please use the dev_* calls instead.  It gives you an accurate
> >description of the specific device that emits the messages.  Also use it
> >for all of the printk() calls in the driver too.
> >
> >thanks,
> >
> >greg k-h
> >
(Continue reading)

Permalink | Reply | 0 comments |

Gmane