headers
Adrian Bunk | 1 May 2008 01:01

Ingo, no more kconfig patches

On Wed, Apr 30, 2008 at 11:13:17PM +0200, Ingo Molnar wrote:
> 
> * Dmitry Torokhov <dmitry.torokhov <at> gmail.com> wrote:
> 
> > > which triggers with the following config:
> > > 
> > >  http://redhat.com/~mingo/misc/config-Wed_Apr_30_21_43_17_CEST_2008.bad
> > > 
> > > the reason is dependency on NEW_LEDS that was not spelled out in the 
> > > Kconfig entry of JOYSTICK_XPAD.
> > 
> > Xpad can be compiled without LED support so this dependancy is 
> > incorrect. JOYSTICK_XPAD_LEDS has proper dependancy on LEDS_CLASS, the 
> > rest is Kconfig breakage.
> 
> no, you are wrong, read the current Kconfig rules again. If the user can 
> create a .config that does not build, it is driver breakage. It always 
> was, and has been in the past 15 years.
> 
> Kconfig might be extended to make dependencies easier to manage for 
> developers but until that is implemented you have to craft your driver's 
> dependencies with the current tools in a way that doesnt break the 
> build.

Ingo, there are areas in the kernel you know well.

But kconfig is not among them.

This breakage with your .config is *not* caused by an input bug as you 
wrongly claim (I'll send a correct fix after some testing).
(Continue reading)

Permalink | Reply | 28 comments |
headers
Greg Ungerer | 1 May 2008 01:01

Re: [PATCH] m68knommu: Add info about removing mcfserial


Sebastian Siewior wrote:
> From: Sebastian Siewior <bigeasy <at> linutronix.de>
> 
> Schedule a removal for this driver. Alternative driver is
> available for a while now.
> 
> Signed-off-by: Sebastian Siewior <bigeasy <at> linutronix.de>
> ---
> Greg said [1] and I hope .28 is not too late.
> [1] http://www.mail-archive.com/uclinux-dev <at> uclinux.org/msg04453.html

.28 is ok with me.

Regards
Greg

>  Documentation/feature-removal-schedule.txt |    8 ++++++++
>  drivers/serial/Kconfig                     |    6 +++++-
>  drivers/serial/mcfserial.c                 |    1 +
>  3 files changed, 14 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> index 3c35d45..27c0056 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
>  <at>  <at>  -304,3 +304,11  <at>  <at>  When:	2.6.26
>  Why:	Implementation became generic; users should now include
>  	linux/semaphore.h instead.
>  Who:	Matthew Wilcox <willy <at> linux.intel.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rafael J. Wysocki | 1 May 2008 01:03
Picon
Gravatar

Re: Slow DOWN, please!!!

On Thursday, 1 of May 2008, Linus Torvalds wrote:
> 
> On Thu, 1 May 2008, Rafael J. Wysocki wrote:
> > 
> > > And there's no way to avoid the fact that during the merge window, we will 
> > > get something on the order of ten thousand commits (eg 2.6.24->25-rc1 was 
> > > 9629 commits).
> > 
> > Well, do we _have_ _to_ take that much?  I know we _can_, but is this really
> > necessary?
> 
> Do you want me to stop merging your code?

Well, no, but actually there are only a few of my patches in this merge
window. :-)

Moreover, if the maintainers who took them told me they would be scheduled for
the next merge window, I wouldn't mind.  That actually happended to some of my
patches that are in the Greg's tree at the moment and that's fine (although I
consider the patches as important).

IMO, this is a question of balance.  Of course, a maintainer can take
everything from everyone, but at the same time he can have a look at the
patches and say "Well, I have lots of stuff scheduled for this merge window
already, this stuff of yours will wait for the next merge window.  Please
improve the code or review the others' patches in the meantime".  The only
thing is to give everyone a fair treatment, which may be a challenge.

> Do you think anybody else does?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dmitri Vorobiev | 1 May 2008 01:04
Picon

Re: Slow DOWN, please!!!

Andrew Morton пишет:

[skipped]

>> Finally, while the list is at it, I'd like to make another technical comment.
>> My development zoo is a pretty fast 4-way Xeon server, where I keep a handful
>> of trees, a few cross-toolchains, Qemu, etc. The network setup in our
>> organization is such that I can use git only over http from that server.
> 
> Don't know what to do about that, sorry.  An off-site git->http proxy might
> work, but I doubt if anyone has written the code.

But there is another solution, which I believe is straightforward: have the tree
maintainer set up his tree properly.

Dmitri

> 
>
Permalink | Reply | 1 comment |
headers
Andres Salomon | 1 May 2008 01:12

Re: [PATCH 4/4] power_supply: bump EC version check that we refuse to run with in olpc_battery

On Wed, 30 Apr 2008 14:55:15 -0700
Andrew Morton <akpm <at> linux-foundation.org> wrote:

> On Wed, 30 Apr 2008 16:30:30 -0400
> Andres Salomon <dilinger <at> queued.net> wrote:
> 
> > 
> > Refuse to run with an EC < 0x44.  We're playing it safe, and this is
> > a pretty old EC version.
> > 
> > Also, add a comment about why we're checking the EC version.
> 
> Sigh.  Presantly, the entirety of olpc_battery.c looks very nice
> in an 80-column display.
> 
> > 
> > diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
> > index cb45a67..086b146 100644
> > --- a/drivers/power/olpc_battery.c
> > +++ b/drivers/power/olpc_battery.c
> >  <at>  <at>  -398,7 +398,12  <at>  <at>  static int __init olpc_bat_init(void)
> >  
> >  	if (!olpc_platform_info.ecver)
> >  		return -ENXIO;
> > -	if (olpc_platform_info.ecver < 0x43) {
> > +
> > +	/*
> > +	 * We've seen a number of EC protocol changes; this driver requires
> > +	 * the latest EC protocol, supported by 0x44 and above.
> > +	 */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andres Salomon | 1 May 2008 01:14

Re: [PATCH 2/4] power_supply: add eeprom dump file to olpc_battery's sysfs

On Wed, 30 Apr 2008 14:53:11 -0700
Andrew Morton <akpm <at> linux-foundation.org> wrote:

> On Wed, 30 Apr 2008 16:30:08 -0400
> Andres Salomon <dilinger <at> queued.net> wrote:
> 
> > 
> > This allows you to dump 0x60 bytes from the battery's EEPROM (starting
> > at address 0x20).  Note that it does an EC command for each byte, so
> > it's pretty slow.  OTOH, if you want to grab just a single byte from
> > somewhere in the EEPROM, you can do something like:
> > 
> > dd bs=1 count=1 skip=16 if=/sys/class/power_supply/olpc-battery/eeprom | od -x
> > 
> > Userspace battery collection/logging information needs this.
> > 
> > Signed-off-by: Andres Salomon <dilinger <at> debian.org>
> > ---
> >  drivers/power/olpc_battery.c |   49 ++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 49 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
> > index 9d9dd09..e5ecf27 100644
> > --- a/drivers/power/olpc_battery.c
> > +++ b/drivers/power/olpc_battery.c
> >  <at>  <at>  -283,6 +283,48  <at>  <at>  static enum power_supply_property olpc_bat_props[] = {
> >  	POWER_SUPPLY_PROP_SERIAL_NUMBER,
> >  };
> >  
> > +/* EEPROM reading goes completely around the power_supply API, sadly */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 May 2008 01:11

Re: Slow DOWN, please!!!

On Thu, 1 May 2008 00:53:31 +0200
Mariusz Kozlowski <m.kozlowski <at> tuxland.pl> wrote:

> Hello,
> 
> > > Perhaps we should be clear and simple about what potential testers 
> > > should be running at any given point in time.  With -mm, linux-next, 
> > > linux-2.6, etc, as a newcomer I find it difficult to know where my 
> > > testing time and energy is best directed.
> 
> Speaking of energy and time of a tester. I'd like to know where these resources
> should be directed from the arch point of view. Once I had a plan to buy as
> many arches as I could get and run a farm of test boxes 8-) But that's hard
> because of various reasons (money, time, room, energy). What arches need more
> attention? Which are forgotten? Which are going away? For example does buying
> an alphaserver DS 20 (hey - it's cheap) and running tests on it makes sense
> these days?
> 

gee.

I think to a large extent this problem solves itself - the "more important"
architectures have more people using them, so they get more testing and
more immediate testing.

However there are gaps.  I'd say that arm is one of the more important
architectures, but many people who are interested in arm tend to shy away
from bleeding-edge kernels for various reasons.  Mainly because they have
real products to get out the door, rather than dinking around with mainline
kernel developement.  So testing bleeding-edge on some arm systems would be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Willy Tarreau | 1 May 2008 01:12
Picon
Favicon

Re: Slow DOWN, please!!!

On Thu, May 01, 2008 at 12:39:01AM +0200, Rafael J. Wysocki wrote:
> On Thursday, 1 of May 2008, David Miller wrote:
> > From: Ingo Molnar <mingo <at> elte.hu>
> > Date: Thu, 1 May 2008 00:19:36 +0200
> > 
> > > The same goes in the other direction as well - you were just hit by 
> > > scheduler tree related regressions that were only triggered on your 
> > > 128-way sparc64, but not on our 64way x86 and smaller boxes.
> > 
> > You keep saying this over and over again, but the powerpc folks hit
> > this stuff too.
> 
> Well, I think that some changes need some wider testing anyway.
> 
> They may be correct from the author's point of view and even from the knowledge
> and point of view of the maintainer who takes them into his tree.  That's
> because no one knows everything and it'll always be like this.
> 
> Still, with the current process such "suspicious" changes go in as parts of
> large series of commits and need to be "rediscovered" by the affected testers
> with the help of bisection.  Moreover, many changes of this kind may go in from
> many different sources at the same time and that's really problematic.

That's very true IMHO and is the thing which has been progressively
appearing since we merge large amounts of code at once. In the "good
old days", something did not work, the first one to discover it could
quickly report it on LKML : "hey, my 128-way sparc64 does not boot
anymore, anybody has any clue", and another one immediately found
this mail (better signal/noise ratio on LKML at this time) and say
"oops, I suspect that change, try to revert it".
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alexey Dobriyan | 1 May 2008 02:10
Picon

ACPI vs proc_create_data() mismerge (was Re: proc_dir_entry 'info' already registered)

On Wed, Apr 30, 2008 at 10:38:07PM +0000, Justin Mattock wrote:
> Hello, attached is dmesg of proc_dir_entry 'info' already registered;
> whatever that means. Hopefully this is not that important, just a glitch.
> Also I know I should'nt talk about 3rd party modules, but with the
> latest git, it  breaks fglrx.

ACPI vs proc_create_data() mismerge.

acpi_device_dir() is NULL until all files are createst, so everyting is
created in straight in /proc/ and creation code warns.

Carefully try patch below, I almost sent totally bogus version.

Signed-off-by: Alexey Dobriyan <adobriyan <at> gmail.com>
---

--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
 <at>  <at>  -1070,7 +1070,7  <at>  <at>  static int acpi_video_device_add_fs(struct acpi_device *device)
 	device_dir->owner = THIS_MODULE;

 	/* 'info' [R] */
-	entry = proc_create_data("info", S_IRUGO, acpi_device_dir(device),
+	entry = proc_create_data("info", S_IRUGO, device_dir,
 			&acpi_video_device_info_fops, acpi_driver_data(device));
 	if (!entry)
 		goto err_remove_dir;
 <at>  <at>  -1078,7 +1078,7  <at>  <at>  static int acpi_video_device_add_fs(struct acpi_device *device)
 	/* 'state' [R/W] */
 	acpi_video_device_state_fops.write = acpi_video_device_write_state;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ben Nizette | 1 May 2008 01:14

Re: [patch/rfc 2.6.25-git v2] gpio: sysfs interface


On Wed, 2008-04-30 at 15:47 -0700, Trent Piepho wrote:
> On Wed, 30 Apr 2008, David Brownell wrote:
> > Simple sysfs interface for GPIOs.
> >
> >    /sys/class/gpio
> >    	/control ... to request a GPIO be imported or returned
> >        /gpioN ... for each exported GPIO #N
> > 	    /value ... always readable, writes fail for input GPIOs
> > 	    /direction ... r/w as: in, out (default low); write high, low
> > 	/gpiochipN ... for each gpiochip; #N is its first GPIO
> > 	    /base ... (r/o) same as N
> > 	    /label ... (r/o) descriptive, not necessarily unique
> > 	    /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)
> 
> "simple"?  What I had was a lot simpler.
> 
> So, I want to set gpio 5 on a pcf9557 extender.
> 
> cat 1 > /sys/class/gpio/pcf9557-0:0
> 
> But now I can't do this anymore, it has to be harder.  So how do I do it?

We've discussed the down sides of your model.  It's got up sides, eg
your use case is made very easy, but it ain't all roses.

Now, if the kernel has requested that pin and hasn't exported it you
can't touch it.  This is what we want.

Otherwise you will walk the gpiochips, find your chip's base and use it
(Continue reading)

Permalink | Reply | 1 comment |

Gmane