* Re: linux-2.4-benh compiling error
From: Christian Kujau @ 2004-01-27 23:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20040127194022.GA646@kimdon.org>
David Kimdon wrote:
| I don't know what your build system is, but I had the same error on
| Debian unstable, the bug (and a patch) is here:
|
| http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228852
yes, Debian/unstable here, and it really seems to be that very bug you
pointed out. it´s even said to be fixed in the latest version of
console-tools, so i´ll have to wait until it hits my mirror of choice.
Thanks!
Christian.
- --
BOFH excuse #69:
knot in cables caused data stream to become twisted and kinked
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for
From: Paul Mackerras @ 2004-01-27 23:49 UTC (permalink / raw)
To: davidm; +Cc: Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16406.36741.510353.456578@napali.hpl.hp.com>
David Mosberger writes:
> Paul> Also, I don't think there is enough code there to be worth the
> Paul> bother of trying to abstract the generic routine so you can
> Paul> plug in different compare and move-element routines. The
> Paul> whole sort routine is only 16 lines of code, after all. Why
> Paul> not just have an ia64-specific version of sort_extable?
> Paul> That's what I thought you would do.
>
> Because the Alpha needs exactly the same code.
I really don't like the uglification of lib/extable.c. I think it is
much better to have ~20 lines of code in each of arch/ia64/mm and
arch/alpha/mm than to try to generalize lib/extable.c. Once you add
all the extra definitions you need for your version, I doubt that the
overall savings would be more than a dozen lines or so.
The point is that with lib/extable.c as it is, you can look at one
page of code, and everything you need to understand that code is
there. With your change, I have to hunt around to check what the
macros are doing on each arch, and flip backwards and forwards to
check side effects, calling environment etc. With an ia64-specific
extable.c, you should be able to look at one page of code there and
see that the ia64 version is also correct.
Paul.
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Andrew Morton @ 2004-01-27 23:45 UTC (permalink / raw)
To: Andi Kleen; +Cc: ak, eric, stoffel, Valdis.Kletnieks, bunk, cova, linux-kernel
In-Reply-To: <20040127232950.GA63863@colin2.muc.de>
Andi Kleen <ak@muc.de> wrote:
>
> > I'll turn it on for gcc-3.3 and higher. We can change that if someone has
> > tested earlier compilers.
>
> Earlier compilers never supported -funit-at-a-time. The option
> was first implemented in gcc 3.3-hammer and later merged into 3.4.
OK, then let's use check-gcc again.
> > Also, I do think this should remain a per-arch decision. Other
> > architectures could well have similar problems to this and we don't want to
> > be mysteriously breaking their kernels for them.
>
> That's fine by me. While you're at it could you enable it for x86-64 too?
yup.
diff -puN arch/i386/Makefile~use-funit-at-a-time arch/i386/Makefile
--- 25/arch/i386/Makefile~use-funit-at-a-time Tue Jan 27 15:40:09 2004
+++ 25-akpm/arch/i386/Makefile Tue Jan 27 15:42:26 2004
@@ -73,6 +73,10 @@ cflags-$(CONFIG_X86_ELAN) := -march=i486
GCC_VERSION := $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
cflags-$(CONFIG_REGPARM) += $(shell if [ $(GCC_VERSION) -ge 0300 ] ; then echo "-mregparm=3"; fi ;)
+# Enable unit-at-a-time mode when possible. It shrinks the
+# kernel considerably.
+CFLAGS += $(call check_gcc,-funit-at-a-time,)
+
CFLAGS += $(cflags-y)
# Default subarch .c files
diff -puN arch/x86_64/Makefile~use-funit-at-a-time arch/x86_64/Makefile
--- 25/arch/x86_64/Makefile~use-funit-at-a-time Tue Jan 27 15:42:34 2004
+++ 25-akpm/arch/x86_64/Makefile Tue Jan 27 15:44:44 2004
@@ -52,7 +52,10 @@ CFLAGS += -Wno-sign-compare
ifneq ($(CONFIG_DEBUG_INFO),y)
CFLAGS += -fno-asynchronous-unwind-tables
endif
-#CFLAGS += $(call check_gcc,-funit-at-a-time,)
+
+# Enable unit-at-a-time mode when possible. It shrinks the
+# kernel considerably.
+CFLAGS += $(call check_gcc,-funit-at-a-time,)
head-y := arch/x86_64/kernel/head.o arch/x86_64/kernel/head64.o arch/x86_64/kernel/init_task.o
_
^ permalink raw reply
* Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2004-01-27 23:46 UTC (permalink / raw)
To: vnuorval; +Cc: netfilter-devel, davem, netdev, kuznet, yoshfuji
In-Reply-To: <Pine.LNX.4.58.0401272244360.28384@rhea.tcs.hut.fi>
In article <Pine.LNX.4.58.0401272244360.28384@rhea.tcs.hut.fi> (at Tue, 27 Jan 2004 22:58:02 +0200 (EET)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:
> How about this fix? I think it's cleaner than the one I proposed
> earlier. The down side with it is that all nodes, no matter if they are
:
Well, it seems better to me.
I however think it should be done in ip6_forward()
because "proxying" is done at the router, acting as proxy.
Packets sent to the proxying router are basically forwarded
to the original node even if the destination is link-local.
On performance issue: as IPv4, we may want to have
net.ipv6.conf.<if>.proxy_ndisc sysctl.
We may also want to have another configuration
option (to enable proxy) bacause not all routers require this
feature.
BTW, would you please give me a few days, till my defence over? :-)
--yoshfuji
^ permalink raw reply
* Re: MO: opening for write in cdrom.c
From: Jens Axboe @ 2004-01-27 23:44 UTC (permalink / raw)
To: Pascal Schmidt; +Cc: linux-kernel
In-Reply-To: <E1AlXH3-0000UR-00@neptune.local>
On Tue, Jan 27 2004, Pascal Schmidt wrote:
> On Tue, 27 Jan 2004 17:40:45 +0100, you wrote in linux.kernel:
>
> > I'm surprised the sense messages don't show that it's a write to a write
> > protected disc (xx/27/zz, where xx == 0x07 or 0x05).
>
> Yep, I wasn't precise, that shows up before the error=0x70 line.
Good, so it's catchable easily even for your drive. So mark the disc
write protected when you see this error on write, and print a message
saying so.
--
Jens Axboe
^ permalink raw reply
* Re: [Jfs-discussion] md raid + jfs + jfs_fsck
From: Neil Brown @ 2004-01-27 23:39 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Florian Huber, JFS-Discussion, Linux-Kernel
In-Reply-To: <20040127212243.A20349@infradead.org>
On Tuesday January 27, hch@infradead.org wrote:
>
> You can't partition md devices (yet), but otherwise yes. I think you can
> also create md device without the persistant superblock still, but it
> always was a pain to maintain those.
non-persistent superblock arrays only work for raid0 and linear
(i.e. not redundancy). RAID1 and RAID5 need a superblock.
NeilBrown
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [2.6.1] fbdev console: can't load vga=791 and yes vga=ask!
From: James Simmons @ 2004-01-27 23:37 UTC (permalink / raw)
To: Kiko Piris; +Cc: Xan, Zack Winkles, linux-kernel
In-Reply-To: <20040127225909.GA5271@sacarino.pirispons.net>
> > I did _not_ booted fine. I tried if with vga=795 it booted fine as you and the
> > same result as 791 obtained: black screen until X window appears. When I
> > switch to pty, black screen or color (and deformed) puzzle of X window
> > contain.
>
> In 2.6.1 I could use framebuffer through vesafb just with that parameter
> (vga=795, ie. 1280x10224 16M).
This is very strange.
> In 2.6.2-rc* it does not work for me, just blank screen if I try to use
> vesafb.
I know this is not my recent patch I sent to linus since I just sent it to
him yesterday.
> Zack Winkles pointed me that I could try passing
> video=vesafb:ywrap,pmipal,mtrr,vga=795 to get vesafb working.
>
> Thanks for it. Right now I'm on travel and I can not try it, I will be
> able to do so on thursday.
Give it a try. If you have problems use my patch at
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> Althoug, I would prefer to use radeonfb instead of vesafb (radeonfb
> turns off my monitor and vesafb does not).
>
> Anyone with a Radeon 9200 does use radeonfb ? If yes, any special boot
> parameter?
Try my newest patch. It has a updated radeon driver.
^ permalink raw reply
* Re: [PATCH] i2c driver fixes for 2.6.2-rc2
From: Greg KH @ 2004-01-27 23:34 UTC (permalink / raw)
To: linux-kernel, sensors
In-Reply-To: <1075246453680@kroah.com>
ChangeSet 1.1474.148.2, 2004/01/23 17:14:38-08:00, khali@linux-fr.org
[PATCH] I2C: undo documentation change
Undo a recent change to the i2c documentation. The change belongs to
2.7.
Documentation/i2c/porting-clients | 5 +----
1 files changed, 1 insertion(+), 4 deletions(-)
diff -Nru a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients
--- a/Documentation/i2c/porting-clients Tue Jan 27 15:27:19 2004
+++ b/Documentation/i2c/porting-clients Tue Jan 27 15:27:19 2004
@@ -92,10 +92,7 @@
i2c_get_clientdata(client) instead.
* [Interface] Init function should not print anything. Make sure
- there is a MODULE_LICENSE() line. MODULE_PARM() is replaced
- by module_param(). Note that module_param has a third parameter,
- that you should set to 0 by default. See include/linux/moduleparam.h
- for details.
+ there is a MODULE_LICENSE() line.
Coding policy:
^ permalink raw reply
* Re: [PATCH] i2c driver fixes for 2.6.2-rc2
From: Greg KH @ 2004-01-27 23:34 UTC (permalink / raw)
To: linux-kernel, sensors
In-Reply-To: <1075246453858@kroah.com>
ChangeSet 1.1474.148.3, 2004/01/23 17:14:52-08:00, khali@linux-fr.org
[PATCH] I2C: Fix bus reset in i2c-philips-par
This patch fixes the bus reset in i2c-philips-par when it is loaded with
type!=0. For now, the reset is always made as is type==0. I guess that
this driver will be abandoned in a while, but it probably doesn't hurt
to fix that.
drivers/i2c/busses/i2c-philips-par.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -Nru a/drivers/i2c/busses/i2c-philips-par.c b/drivers/i2c/busses/i2c-philips-par.c
--- a/drivers/i2c/busses/i2c-philips-par.c Tue Jan 27 15:27:08 2004
+++ b/drivers/i2c/busses/i2c-philips-par.c Tue Jan 27 15:27:08 2004
@@ -184,8 +184,8 @@
return;
}
/* reset hardware to sane state */
- bit_lp_setsda(port, 1);
- bit_lp_setscl(port, 1);
+ adapter->bit_lp_data.setsda(port, 1);
+ adapter->bit_lp_data.setscl(port, 1);
parport_release(adapter->pdev);
if (i2c_bit_add_bus(&adapter->adapter) < 0) {
^ permalink raw reply
* Re: [PATCH] i2c driver fixes for 2.6.2-rc2
From: Greg KH @ 2004-01-27 23:34 UTC (permalink / raw)
To: linux-kernel, sensors
In-Reply-To: <10752464533223@kroah.com>
ChangeSet 1.1474.148.4, 2004/01/26 16:58:46-08:00, khali@linux-fr.org
[PATCH] I2C: Add ADM1025EB support to i2c-parport
The following patch adds support for the ADM1025 evaluation board to the
i2c-parport (and i2c-parport-light) driver(s). In fact, it happens that
it was already supported as an ADM1032 evaluation board, so it is just a
matter of documenting it correctly.
drivers/i2c/busses/i2c-parport.h | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff -Nru a/drivers/i2c/busses/i2c-parport.h b/drivers/i2c/busses/i2c-parport.h
--- a/drivers/i2c/busses/i2c-parport.h Tue Jan 27 15:26:57 2004
+++ b/drivers/i2c/busses/i2c-parport.h Tue Jan 27 15:26:57 2004
@@ -67,12 +67,13 @@
.getsda = { 0x40, STAT, 1 },
.getscl = { 0x08, STAT, 1 },
},
- /* type 4: ADM 1032 evaluation board */
+ /* type 4: ADM1025 and ADM1032 evaluation boards */
{
.setsda = { 0x02, DATA, 1 },
.setscl = { 0x01, DATA, 1 },
.getsda = { 0x10, STAT, 1 },
- .init = { 0xf0, DATA, 0 },
+ .init = { 0xf0, DATA, 0 }, /* ADM1025 doesn't need this,
+ but it doesn't hurt */
},
};
@@ -84,4 +85,4 @@
" 1 = home brew teletext adapter\n"
" 2 = Velleman K8000 adapter\n"
" 3 = ELV adapter\n"
- " 4 = ADM 1032 evalulation board\n");
+ " 4 = ADM1025 and ADM1032 evaluation boards\n");
^ permalink raw reply
* Re: [PATCH] i2c driver fixes for 2.6.2-rc2
From: Greg KH @ 2004-01-27 23:34 UTC (permalink / raw)
To: linux-kernel, sensors
In-Reply-To: <10752464532280@kroah.com>
ChangeSet 1.1474.148.5, 2004/01/27 14:38:29-08:00, khali@linux-fr.org
[PATCH] I2C: Bring lm75 and lm78 in compliance with sysfs naming conventions
Here is a patch that brings the lm75 and lm78 drivers in compliance with
sysfs naming conventions. The drivers as found in existing 2.6 kernels
do not have a digit appended to the temperature-related files names as
the sysfs naming conversion recommends (obviously because they each have
a single temperature channel). As a result, libsensors won't find the
files.
It was discussed on the list wether a '1' should be appended in this
case, and our conclusion was that it would be better to do so because it
helps automatic processing of the sysfs exported files. Please apply if
you agree with this.
drivers/i2c/chips/lm75.c | 12 ++++++------
drivers/i2c/chips/lm78.c | 12 ++++++------
2 files changed, 12 insertions(+), 12 deletions(-)
diff -Nru a/drivers/i2c/chips/lm75.c b/drivers/i2c/chips/lm75.c
--- a/drivers/i2c/chips/lm75.c Tue Jan 27 15:26:46 2004
+++ b/drivers/i2c/chips/lm75.c Tue Jan 27 15:26:46 2004
@@ -104,9 +104,9 @@
set(temp_max, LM75_REG_TEMP_OS);
set(temp_hyst, LM75_REG_TEMP_HYST);
-static DEVICE_ATTR(temp_max, S_IWUSR | S_IRUGO, show_temp_max, set_temp_max);
-static DEVICE_ATTR(temp_hyst, S_IWUSR | S_IRUGO, show_temp_hyst, set_temp_hyst);
-static DEVICE_ATTR(temp_input, S_IRUGO, show_temp_input, NULL);
+static DEVICE_ATTR(temp_max1, S_IWUSR | S_IRUGO, show_temp_max, set_temp_max);
+static DEVICE_ATTR(temp_hyst1, S_IWUSR | S_IRUGO, show_temp_hyst, set_temp_hyst);
+static DEVICE_ATTR(temp_input1, S_IRUGO, show_temp_input, NULL);
static int lm75_attach_adapter(struct i2c_adapter *adapter)
{
@@ -197,9 +197,9 @@
lm75_init_client(new_client);
/* Register sysfs hooks */
- device_create_file(&new_client->dev, &dev_attr_temp_max);
- device_create_file(&new_client->dev, &dev_attr_temp_hyst);
- device_create_file(&new_client->dev, &dev_attr_temp_input);
+ device_create_file(&new_client->dev, &dev_attr_temp_max1);
+ device_create_file(&new_client->dev, &dev_attr_temp_hyst1);
+ device_create_file(&new_client->dev, &dev_attr_temp_input1);
return 0;
diff -Nru a/drivers/i2c/chips/lm78.c b/drivers/i2c/chips/lm78.c
--- a/drivers/i2c/chips/lm78.c Tue Jan 27 15:26:46 2004
+++ b/drivers/i2c/chips/lm78.c Tue Jan 27 15:26:46 2004
@@ -369,10 +369,10 @@
return count;
}
-static DEVICE_ATTR(temp_input, S_IRUGO, show_temp, NULL)
-static DEVICE_ATTR(temp_max, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(temp_input1, S_IRUGO, show_temp, NULL)
+static DEVICE_ATTR(temp_max1, S_IRUGO | S_IWUSR,
show_temp_over, set_temp_over)
-static DEVICE_ATTR(temp_hyst, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(temp_hyst1, S_IRUGO | S_IWUSR,
show_temp_hyst, set_temp_hyst)
/* 3 Fans */
@@ -678,9 +678,9 @@
device_create_file(&new_client->dev, &dev_attr_in_input6);
device_create_file(&new_client->dev, &dev_attr_in_min6);
device_create_file(&new_client->dev, &dev_attr_in_max6);
- device_create_file(&new_client->dev, &dev_attr_temp_input);
- device_create_file(&new_client->dev, &dev_attr_temp_max);
- device_create_file(&new_client->dev, &dev_attr_temp_hyst);
+ device_create_file(&new_client->dev, &dev_attr_temp_input1);
+ device_create_file(&new_client->dev, &dev_attr_temp_max1);
+ device_create_file(&new_client->dev, &dev_attr_temp_hyst1);
device_create_file(&new_client->dev, &dev_attr_fan_input1);
device_create_file(&new_client->dev, &dev_attr_fan_min1);
device_create_file(&new_client->dev, &dev_attr_fan_div1);
^ permalink raw reply
* Re: Linux on a Motorola MPC5200 ?
From: Sylvain Munaut @ 2004-01-27 23:37 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20040127191442.3B541C108D@atlas.denx.de>
Hi
>>well, their 'special DMA fancy stuff' ;) ), ATA, DDR, I2S, AC97 mainly.
>>
>>
>
>ATA: OK as long as you don't enable DMA writes (*)
>
>
>
Are DMA Read supported ? ( I mean possible to just use DMA for the reads
? My application is about 95 % reads ;)
What's the performance impact ?
>DDR: OK (use icecube_5200_DDR configuration in U-Boot); the LOWBOOT
> option is not working yet (we are working on this)
>
>I2S: simultaneous reading and writing is impossible (*)
>AC97: ditto
>
>
>
Ok, not a problem for me I only do audio out.
But just in case, if I do In and Out on different PSC, does this works ?
>(*) to fix these issues we're waiting for a bugfix release of the
> BestComm CAPI which might become availabe by mid February.
>
>
Cool !
>> - I'd really like to run a 2.6 kernel on it. If it's not yet ported to
>>
>>
>
>Forget it. Why would you want to do that? Which features do you
>expect from 2.6 which are not available in 2.4?
>
>
>
>
Well things like *:
- Pluggable I/O Scheduler
- Kernel preemption
- Better IPSec / Encryption support
- udev stuff ( in fact userspace but may depend on some kernel
interface, have to check. Primarly done for the 2.6 AFAIK )
- Native ALSA
And also because when I start a new project I like to use "new" stuff ;)
That's were a majority of new nifty features are ...
(*) I'm not sure they are all only and 2.6 and not backported/already in
2.4, I have to check.
>Our current stuff is on our CVS server, in the linuxppc_2_4_devel
>tree. As far as the 5200 is concerned this includes stuff that was
>submitted but not yet added to the linux-2.4-mpc5xxx tree (but Tom
>promised to add our patches).
>
>
>
I've just downloaded it but ran into a problem when compiling the kernel
with the icecube default config.
In arch/ppc/boot/common/misc-simple.c :
- the decompress_kernel routine is used before being defined/declared
- the decompress_kernel defined there takes 3 args, the one used in
load_kernel func ( same file ), gives 4 args to it ...
Sylvain Munaut
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH] i2c driver fixes for 2.6.2-rc2
From: Greg KH @ 2004-01-27 23:34 UTC (permalink / raw)
To: linux-kernel, sensors
In-Reply-To: <1075246453781@kroah.com>
ChangeSet 1.1474.148.6, 2004/01/27 14:46:05-08:00, greg@kroah.com
[PATCH] I2C: remove printk() calls in lm85, and clean up debug logic.
drivers/i2c/chips/lm85.c | 69 ++++++++++++++---------------------------------
1 files changed, 21 insertions(+), 48 deletions(-)
diff -Nru a/drivers/i2c/chips/lm85.c b/drivers/i2c/chips/lm85.c
--- a/drivers/i2c/chips/lm85.c Tue Jan 27 15:26:35 2004
+++ b/drivers/i2c/chips/lm85.c Tue Jan 27 15:26:35 2004
@@ -48,9 +48,6 @@
/* Insmod parameters */
SENSORS_INSMOD_4(lm85b, lm85c, adm1027, adt7463);
-/* Enable debug if true */
-static int lm85debug = 0;
-
/* The LM85 registers */
#define LM85_REG_IN(nr) (0x20 + (nr))
@@ -802,19 +799,15 @@
company = lm85_read_value(new_client, LM85_REG_COMPANY);
verstep = lm85_read_value(new_client, LM85_REG_VERSTEP);
- if (lm85debug) {
- printk("lm85: Detecting device at %d,0x%02x with"
+ dev_dbg(&adapter->dev, "Detecting device at %d,0x%02x with"
" COMPANY: 0x%02x and VERSTEP: 0x%02x\n",
i2c_adapter_id(new_client->adapter), new_client->addr,
company, verstep);
- }
/* If auto-detecting, Determine the chip type. */
if (kind <= 0) {
- if (lm85debug) {
- printk("lm85: Autodetecting device at %d,0x%02x ...\n",
+ dev_dbg(&adapter->dev, "Autodetecting device at %d,0x%02x ...\n",
i2c_adapter_id(adapter), address );
- }
if( company == LM85_COMPANY_NATIONAL
&& verstep == LM85_VERSTEP_LM85C ) {
kind = lm85c ;
@@ -823,8 +816,8 @@
kind = lm85b ;
} else if( company == LM85_COMPANY_NATIONAL
&& (verstep & 0xf0) == LM85_VERSTEP_GENERIC ) {
- printk("lm85: Unrecgonized version/stepping 0x%02x"
- " Defaulting to LM85.\n", verstep );
+ dev_err(&adapter->dev, "Unrecgonized version/stepping 0x%02x"
+ " Defaulting to LM85.\n", verstep);
kind = any_chip ;
} else if( company == LM85_COMPANY_ANALOG_DEV
&& verstep == LM85_VERSTEP_ADM1027 ) {
@@ -834,21 +827,19 @@
kind = adt7463 ;
} else if( company == LM85_COMPANY_ANALOG_DEV
&& (verstep & 0xf0) == LM85_VERSTEP_GENERIC ) {
- printk("lm85: Unrecgonized version/stepping 0x%02x"
- " Defaulting to ADM1027.\n", verstep );
+ dev_err(&adapter->dev, "Unrecgonized version/stepping 0x%02x"
+ " Defaulting to ADM1027.\n", verstep);
kind = adm1027 ;
} else if( kind == 0 && (verstep & 0xf0) == 0x60) {
- printk("lm85: Generic LM85 Version 6 detected\n");
+ dev_err(&adapter->dev, "Generic LM85 Version 6 detected\n");
/* Leave kind as "any_chip" */
} else {
- if (lm85debug) {
- printk("lm85: Autodetection failed\n");
- }
+ dev_dbg(&adapter->dev, "Autodetection failed\n");
/* Not an LM85 ... */
if( kind == 0 ) { /* User used force=x,y */
- printk("lm85: Generic LM85 Version 6 not"
- " found at %d,0x%02x. Try force_lm85c.\n",
- i2c_adapter_id(adapter), address );
+ dev_err(&adapter->dev, "Generic LM85 Version 6 not"
+ " found at %d,0x%02x. Try force_lm85c.\n",
+ i2c_adapter_id(adapter), address );
}
err = 0 ;
goto ERROR1;
@@ -879,12 +870,10 @@
data->valid = 0;
init_MUTEX(&data->update_lock);
- if (lm85debug) {
- printk("lm85: Assigning ID %d to %s at %d,0x%02x\n",
+ dev_dbg(&adapter->dev, "Assigning ID %d to %s at %d,0x%02x\n",
new_client->id, new_client->name,
i2c_adapter_id(new_client->adapter),
new_client->addr);
- }
/* Tell the I2C layer a new client has arrived */
if ((err = i2c_attach_client(new_client)))
@@ -1021,31 +1010,24 @@
int value;
struct lm85_data *data = i2c_get_clientdata(client);
- if (lm85debug) {
- printk("lm85(%d): Initializing device\n", client->id);
- }
+ dev_dbg(&client->dev, "Initializing device\n");
/* Warn if part was not "READY" */
value = lm85_read_value(client, LM85_REG_CONFIG);
- if (lm85debug) {
- printk("lm85(%d): LM85_REG_CONFIG is: 0x%02x\n", client->id, value );
- }
+ dev_dbg(&client->dev, "LM85_REG_CONFIG is: 0x%02x\n", value);
if( value & 0x02 ) {
- printk("lm85(%d): Client (%d,0x%02x) config is locked.\n",
- client->id,
+ dev_err(&client->dev, "Client (%d,0x%02x) config is locked.\n",
i2c_adapter_id(client->adapter), client->addr );
};
if( ! (value & 0x04) ) {
- printk("lm85(%d): Client (%d,0x%02x) is not ready.\n",
- client->id,
+ dev_err(&client->dev, "Client (%d,0x%02x) is not ready.\n",
i2c_adapter_id(client->adapter), client->addr );
};
if( value & 0x10
&& ( data->type == adm1027
|| data->type == adt7463 ) ) {
- printk("lm85(%d): Client (%d,0x%02x) VxI mode is set. "
+ dev_err(&client->dev, "Client (%d,0x%02x) VxI mode is set. "
"Please report this to the lm85 maintainer.\n",
- client->id,
i2c_adapter_id(client->adapter), client->addr );
};
@@ -1061,11 +1043,8 @@
value = lm85_read_value(client, LM85_REG_CONFIG);
/* Try to clear LOCK, Set START, save everything else */
value = (value & ~ 0x02) | 0x01 ;
- if (lm85debug) {
- printk("lm85(%d): Setting CONFIG to: 0x%02x\n", client->id, value );
- }
+ dev_dbg(&client->dev, "Setting CONFIG to: 0x%02x\n", value);
lm85_write_value(client, LM85_REG_CONFIG, value);
-
}
void lm85_update_client(struct i2c_client *client)
@@ -1078,10 +1057,8 @@
if ( !data->valid ||
(jiffies - data->last_reading > LM85_DATA_INTERVAL ) ) {
/* Things that change quickly */
-
- if (lm85debug) {
- printk("lm85(%d): Reading sensor values\n", client->id);
- }
+ dev_dbg(&client->dev, "Reading sensor values\n");
+
/* Have to read extended bits first to "freeze" the
* more significant bits that are read later.
*/
@@ -1125,10 +1102,8 @@
if ( !data->valid ||
(jiffies - data->last_config > LM85_CONFIG_INTERVAL) ) {
/* Things that don't change often */
+ dev_dbg(&client->dev, "Reading config values\n");
- if (lm85debug) {
- printk("lm85(%d): Reading config values\n", client->id);
- }
for (i = 0; i <= 4; ++i) {
data->in_min[i] =
lm85_read_value(client, LM85_REG_IN_MIN(i));
@@ -1234,8 +1209,6 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Philip Pokorny <ppokorny@penguincomputing.com>, Margit Schubert-While <margitsw@t-online.de>");
MODULE_DESCRIPTION("LM85-B, LM85-C driver");
-MODULE_PARM(lm85debug, "i");
-MODULE_PARM_DESC(lm85debug, "Enable debugging statements");
module_init(sm_lm85_init);
module_exit(sm_lm85_exit);
^ permalink raw reply
* [PATCH] simple fix
From: Giuliano Pochini @ 2004-01-27 23:36 UTC (permalink / raw)
To: LinuxPPC-dev
Small patch against linuxppc-2.5-benh rsync tree pulled half hour ago (GMT+1).
--- fs/hfs/extent.c_old Wed Jan 28 00:31:30 2004
+++ fs/hfs/extent.c Wed Jan 28 00:31:56 2004
@@ -470,8 +470,8 @@
if (inode->i_size > HFS_I(inode)->phys_size) {
struct address_space *mapping = inode->i_mapping;
struct page *page;
- size = inode->i_size - 1;
int res;
+ size = inode->i_size - 1;
page = grab_cache_page(mapping, size >> PAGE_CACHE_SHIFT);
if (!page)
--
Giuliano.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [PATCH] i2c driver fixes for 2.6.2-rc2
From: Greg KH @ 2004-01-27 23:34 UTC (permalink / raw)
To: linux-kernel, sensors
In-Reply-To: <20040127233242.GA28891@kroah.com>
ChangeSet 1.1474.148.1, 2004/01/23 17:14:22-08:00, mhoffman@lightlink.com
[PATCH] I2C: i2c-piix4.c bugfix
This patch fixes a "Trying to release non-existent resource" error that
occurs during rmmod when the device isn't actually present. It includes
some other cleanups too: error paths, whitespace, magic numbers, __devinit.
drivers/i2c/busses/i2c-piix4.c | 48 +++++++++++++++++++++++------------------
1 files changed, 27 insertions(+), 21 deletions(-)
diff -Nru a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
--- a/drivers/i2c/busses/i2c-piix4.c Tue Jan 27 15:27:30 2004
+++ b/drivers/i2c/busses/i2c-piix4.c Tue Jan 27 15:27:30 2004
@@ -68,6 +68,9 @@
#define SMBSLVEVT (0xA + piix4_smba)
#define SMBSLVDAT (0xC + piix4_smba)
+/* count for request_region */
+#define SMBIOSIZE 8
+
/* PCI Address Constants */
#define SMBBA 0x090
#define SMBHSTCFG 0x0D2
@@ -112,14 +115,13 @@
static int piix4_transaction(void);
-
static unsigned short piix4_smba = 0;
static struct i2c_adapter piix4_adapter;
/*
* Get DMI information.
*/
-static int ibm_dmi_probe(void)
+static int __devinit ibm_dmi_probe(void)
{
#ifdef CONFIG_X86
extern int is_unsafe_smbus;
@@ -129,9 +131,9 @@
#endif
}
-static int piix4_setup(struct pci_dev *PIIX4_dev, const struct pci_device_id *id)
+static int __devinit piix4_setup(struct pci_dev *PIIX4_dev,
+ const struct pci_device_id *id)
{
- int error_return = 0;
unsigned char temp;
/* match up the function */
@@ -144,8 +146,7 @@
dev_err(&PIIX4_dev->dev, "IBM Laptop detected; this module "
"may corrupt your serial eeprom! Refusing to load "
"module!\n");
- error_return = -EPERM;
- goto END;
+ return -EPERM;
}
/* Determine the address of the SMBus areas */
@@ -163,11 +164,10 @@
}
}
- if (!request_region(piix4_smba, 8, "piix4-smbus")) {
+ if (!request_region(piix4_smba, SMBIOSIZE, "piix4-smbus")) {
dev_err(&PIIX4_dev->dev, "SMB region 0x%x already in use!\n",
piix4_smba);
- error_return = -ENODEV;
- goto END;
+ return -ENODEV;
}
pci_read_config_byte(PIIX4_dev, SMBHSTCFG, &temp);
@@ -214,8 +214,9 @@
} else {
dev_err(&PIIX4_dev->dev,
"Host SMBus controller not enabled!\n");
- error_return = -ENODEV;
- goto END;
+ release_region(piix4_smba, SMBIOSIZE);
+ piix4_smba = 0;
+ return -ENODEV;
}
}
@@ -231,8 +232,7 @@
dev_dbg(&PIIX4_dev->dev, "SMBREV = 0x%X\n", temp);
dev_dbg(&PIIX4_dev->dev, "SMBA = 0x%X\n", piix4_smba);
-END:
- return error_return;
+ return 0;
}
/* Another internally used function */
@@ -465,7 +465,8 @@
{ 0, }
};
-static int __devinit piix4_probe(struct pci_dev *dev, const struct pci_device_id *id)
+static int __devinit piix4_probe(struct pci_dev *dev,
+ const struct pci_device_id *id)
{
int retval;
@@ -479,17 +480,24 @@
snprintf(piix4_adapter.name, I2C_NAME_SIZE,
"SMBus PIIX4 adapter at %04x", piix4_smba);
- retval = i2c_add_adapter(&piix4_adapter);
+ if ((retval = i2c_add_adapter(&piix4_adapter))) {
+ dev_err(&dev->dev, "Couldn't register adapter!\n");
+ release_region(piix4_smba, SMBIOSIZE);
+ piix4_smba = 0;
+ }
return retval;
}
static void __devexit piix4_remove(struct pci_dev *dev)
{
- i2c_del_adapter(&piix4_adapter);
+ if (piix4_smba) {
+ i2c_del_adapter(&piix4_adapter);
+ release_region(piix4_smba, SMBIOSIZE);
+ piix4_smba = 0;
+ }
}
-
static struct pci_driver piix4_driver = {
.name = "piix4-smbus",
.id_table = piix4_ids,
@@ -502,15 +510,13 @@
return pci_module_init(&piix4_driver);
}
-
static void __exit i2c_piix4_exit(void)
{
pci_unregister_driver(&piix4_driver);
- release_region(piix4_smba, 8);
}
-MODULE_AUTHOR
- ("Frodo Looijaard <frodol@dds.nl> and Philip Edelbrock <phil@netroedge.com>");
+MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl> and "
+ "Philip Edelbrock <phil@netroedge.com>");
MODULE_DESCRIPTION("PIIX4 SMBus driver");
MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: (driver model) bus kset list manipulation bug
From: Hollis Blanchard @ 2004-01-27 23:31 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Kernel, mochel, Andrew Morton
In-Reply-To: <401026CD.2030600@us.ibm.com>
On Jan 22, 2004, at 1:38 PM, Hollis Blanchard wrote:
>
> I've found a bug in drivers/base/bus.c, where the
> bus_type.devices.list is treated as a list of device structs.
> bus_type.devices is a kset though, so devices.list should contain
> kobjects rather than devices. Here is the diff I've come up with:
>
[big snip]
> @@ -405,7 +405,7 @@
> if (bus) {
> down_write(&dev->bus->subsys.rwsem);
> pr_debug("bus %s: add device
> %s\n",bus->name,dev->bus_id);
> - list_add_tail(&dev->bus_list,&dev->bus->devices.list);
> +
> list_add_tail(&dev->kobj.entry,&dev->bus->devices.list);
> device_attach(dev);
> up_write(&dev->bus->subsys.rwsem);
Here's the problem: dev->kobj is already in use; it's part of the
global devices_subsys kset.
devices_subsys looks like it's only used for two things: global hotplug
policy and suspend. Of the 3 hotplug functions it provides
(dev_hotplug_filter, dev_hotplug_name, and dev_hotplug), 2 of them
refer to bus data or code anyways.
I'm very surprised to see it's used by device_shutdown(). I thought one
of the points of the device tree was to do depth-first-suspend, so e.g
we don't try to suspend a PCI bridge and *then* try to suspend children
of that bridge. Instead we're walking a global list in the reverse
order they were registered. I guess this works because busses are
discovered from the root down, so going backwards will give you the
deepest first.
I see three options, and I like the last best:
- add another kobject to struct device. This will allow a device to be
registered with the global devices_subsys as well as a bus.devices kset
simultaneously.
- change the kset "bus_type.devices" to a normal "list_head*" (which is
how it's being used today, incorrectly). This will preclude some of the
nice kobject/kset functionality however (e.g. see last paragraph
below).
- remove devices_subsys. The hotplug policy is already entirely
bus-specific anyways. The suspend code can be made to use bus
structures as well instead of a global device list (can it?).
The point of all of this is I want to be able to call
device_find("mydevice", &my_bus_type)
device_find() uses kset_find_obj() on the bus_type.devices kset, and
that doesn't work because bus_type.devices isn't a real kset, and it's
not a real kset because you can't register device kobjects in it, and
you can't because those kobjects have already been registered with
devices_subsys. I could call
device_find("mydevice", &devices_subsys.kset)
instead, but I already know what bus my device is on; no need to search
them all...
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* [BK PATCH] i2c driver fixes for 2.6.2-rc2
From: Greg KH @ 2004-01-27 23:32 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-kernel, sensors
Hi,
Here are some i2c driver fixes for 2.6.2-rc2. It's all a bit of small
bugfixes and documentation updates.
Please pull from: bk://kernel.bkbits.net/gregkh/linux/i2c-2.6
Individual patches will follow, sent to the sensors and linux-kernel
lists.
thanks,
greg k-h
Documentation/i2c/porting-clients | 5 --
drivers/i2c/busses/i2c-parport.h | 7 ++-
drivers/i2c/busses/i2c-philips-par.c | 4 +-
drivers/i2c/busses/i2c-piix4.c | 48 +++++++++++++-----------
drivers/i2c/chips/lm75.c | 12 +++---
drivers/i2c/chips/lm78.c | 12 +++---
drivers/i2c/chips/lm85.c | 69 ++++++++++-------------------------
7 files changed, 67 insertions(+), 90 deletions(-)
-----
Greg Kroah-Hartman:
o I2C: remove printk() calls in lm85, and clean up debug logic
Jean Delvare:
o I2C: Bring lm75 and lm78 in compliance with sysfs naming conventions
o I2C: Add ADM1025EB support to i2c-parport
o I2C: Fix bus reset in i2c-philips-par
o I2C: undo documentation change
Mark M. Hoffman:
o I2C: i2c-piix4.c bugfix
^ permalink raw reply
* [U-Boot-Users] Endianness for MIPS
From: Ed Okerson @ 2004-01-27 23:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <603BA0CFF3788E46A0DB0918D9AA95100A0E2E57@sj580004wcom.int.lantronix.com>
Jerry,
I have already made most of the necessary changes for this to work. So
far all but one are checked into CVS. The one that isn't is related to
reading Compact Flash cards. Wolfgang didn't like the way I did it, and I
have not made a new patch the way he wants yet, but it is on the to-do
list.
Ed Okerson
On Tue, 27 Jan 2004, Jerry Walden wrote:
> Hello -
>
> I am working on the DBAU1X00 version, and the readme says that it was
> created for big endian.
>
> My board (based on the Alchemy eval board) is set for little endian.
> Are the changes I will need to make be extensive?
>
> Beyond the obvious - what things (specifically in the source) should I
> watch out for?
>
> Thanks for any help.
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Andi Kleen @ 2004-01-27 23:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Andi Kleen, eric, stoffel, Valdis.Kletnieks, bunk, cova,
linux-kernel
In-Reply-To: <20040127151644.1fb378c2.akpm@osdl.org>
> I'll turn it on for gcc-3.3 and higher. We can change that if someone has
> tested earlier compilers.
Earlier compilers never supported -funit-at-a-time. The option
was first implemented in gcc 3.3-hammer and later merged into 3.4.
> Also, I do think this should remain a per-arch decision. Other
> architectures could well have similar problems to this and we don't want to
> be mysteriously breaking their kernels for them.
That's fine by me. While you're at it could you enable it for x86-64 too?
-Andi
^ permalink raw reply
* double fault in scheduler()
From: Doug Reiland @ 2004-01-27 23:30 UTC (permalink / raw)
To: linux-kernel
There seems to be a window in scheduler() where we have switch to the new
process's mm, but are running on the old process's stack. This stack might
not be mapped in the new process.
_________________________________________________________________
Get a FREE online virus check for your PC here, from McAfee.
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
^ permalink raw reply
* Re: [uml-devel] Kernel idles in loop after loading IPv4
From: Steven James @ 2004-01-27 23:28 UTC (permalink / raw)
To: Phil Nadeau; +Cc: user-mode-linux-devel
In-Reply-To: <1075236841.15950.10.camel@rocket.innercite.com>
Greetings,
I ran into that as well, but didn't have time to do much about it. As a
further datapoint, if I disable all net support and pass it
init=/bin/bash, I get the bash prompt (ubd filesystems do get
checked/mounted) but then it goes into the idle loop and stays there.
G'day,
sjames
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 2701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
On Tue, 27 Jan 2004, Phil Nadeau wrote:
> Hello UML developers,
>
> I'm trying to use UML to set up a simulator for a high-availability
> cluster. I encounter the following unexpected behavior -
>
> On any kernel that I compile with IPv4 support, the kernel will stop
> intializing drivers after loading IPv4 support. The last message I see
> from the kernel is:
> NET: Registered protocol family 2
>
> Compiling with debug allows me to single-step through the kernel. I've
> traced execution from inet_init(), to synchronize_net(), to
> synchronize_kernel(), to a call to wait_for_completion(), to
> switch_to_tt(), after which the kernel spends all its time in the idle
> loop. This happens whether I'm using SKAS or TT mode.
>
> Host kernel is 2.6.1 with Stephen William's 2.6.1 SKAS patch (thanks
> Stephen). Guest kernel is 2.6.1 with the latest patch from Sourceforge
> (January 15th), without modules, and with nearly everything disabled at
> compile except core functionality and IPv4.
>
> I've tried to find similar cases in the FAQ's and the list archives, but
> I'm not seeing anything. It seems like the kernel is waiting for an
> event related to IPv4 initialization that it never gets, but I'm not
> familiar enough with the kernel proper to know what that might be. Does
> anyone have any ideas?
>
> Thanks in advance.
>
> --
> Phil Nadeau
> Software Services Manager
> phil.nadeau@innercite.com
> (916)932-3200, (800)921-5513
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: Nvidia drivers and 2.6.x kernel
From: Charles Shannon Hendrix @ 2004-01-27 22:49 UTC (permalink / raw)
To: Linux Kernel
In-Reply-To: <200401261024.28998.chakkerz@optusnet.com.au>
Mon, 26 Jan 2004 @ 10:24 +1100, Christian Unger said:
> So ... i'm out of ideas ... i don't get why it ain't doing for me what it is
> doing for everyone else. I am wondering IF something screwed up when i
> upgraded Slackware 9.1 from 9.0 ... and in the interest of testing that
> theory might do a rm -f / later and start from scratch. I haven't decided if
> 2.6 is worth that much yet though.
nVidia has released drivers supporting kernel 2.6 on their website.
They run nicely for me.
Hmmm... why do people say "they" when talking about a "driver"?
--
shannon "AT" widomaker.com -- ["An Irishman is never drunk as long as he
can hold onto one blade of grass and not fall off the face of the earth."]
^ permalink raw reply
* [LARTC] tncg and bandwidth limiting
From: Scott Baker @ 2004-01-27 23:24 UTC (permalink / raw)
To: lartc
I'm trying to do some very simple rate-shaping on an interface. I want to
limit my 100baseT interface to 7 megs both ingress and egress of the
interface. I've been hacking my way through the documentation and some
examples and I've come up with the following configuration for tcng that
seems to do what I want.
I'm curious if some of the other experts out there wouldn't have a "better"
way to do what I'm doing. I'd like to do HTB ingress as well, but it
complains that the the ingress qdisc doesn't allow inside classes or
something like that. I think this will work for me, I just want to make
sure this is the best way to do things.
----------------------------
dev INTERFACE {
egress {
class ( <$all> ) if 1;
htb () {
class ( rate 100Mbps, ceil 100Mbps ) ;
$all = class ( rate 7Mbps, ceil 7Mbps ) ;
}
$o = bucket(rate 7Mbps, burst 200kB, mpu 200B);
class (2) if (conform $o && count $o) || drop;
}
}
/* tcng syntax English equivalent tc syntax
----------- -------------------- ---------
bps bits per second bit
Bps bytes per second bps (!)
kbps kilobits per second kbit
kBps kilobytes per second kbps
Mbps megabits per second ???
*/
Scott Baker - Network Engineer - RHCE
bakers @ web-ster . com - 503.266.8253
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: NGROUPS 2.6.2rc2
From: Dax Kelson @ 2004-01-27 23:25 UTC (permalink / raw)
To: thockin; +Cc: torvalds, Linux Kernel mailing list, rusty
In-Reply-To: <20040127225311.GA9155@sun.com>
On Tue, 2004-01-27 at 15:53, Tim Hockin wrote:
> What think? Can we get rid of this limit at long last? :)
Aren't the Samba folks asking for this as well? People using Samba v3
to replace NT4 domains where commonly users belong to many more than 32
groups.
Dax
^ permalink raw reply
* [BK PATCH] USB update for 2.6.2-rc2
From: Greg KH @ 2004-01-27 23:21 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-usb-devel, linux-kernel
Hi,
Here are some USB patches for 2.6.2-rc2. Here are the main types of
changes:
- a number of small bugfixes
- a usb gadget update including the ability to enable the
drivers to build properly, and a new gadget filesystem driver.
- a new ohci host controller driver for the omap platform.
Please pull from: bk://kernel.bkbits.net/gregkh/linux/usb-2.6
Patches will be posted to linux-usb-devel as a follow-up thread for
those who want to see them.
thanks,
greg k-h
drivers/usb/Kconfig | 2
drivers/usb/core/hub.c | 5
drivers/usb/core/message.c | 37
drivers/usb/core/usb.c | 24
drivers/usb/core/usb.h | 3
drivers/usb/gadget/Kconfig | 207 +
drivers/usb/gadget/Makefile | 5
drivers/usb/gadget/ether.c | 98
drivers/usb/gadget/file_storage.c | 4169 +++++++++++++++++++++++++++++++++++++
drivers/usb/gadget/net2280.c | 489 ++--
drivers/usb/gadget/net2280.h | 6
drivers/usb/gadget/serial.c | 27
drivers/usb/gadget/zero.c | 10
drivers/usb/host/ohci-hcd.c | 6
drivers/usb/host/ohci-omap.c | 673 +++++
drivers/usb/host/ohci-omap.h | 57
drivers/usb/media/dabusb.c | 12
drivers/usb/misc/Kconfig | 2
drivers/usb/misc/auerswald.c | 4
drivers/usb/misc/tiglusb.c | 24
drivers/usb/serial/kobil_sct.c | 2
drivers/usb/serial/whiteheat.c | 27
drivers/usb/storage/scsiglue.c | 39
drivers/usb/storage/unusual_devs.h | 12
include/linux/usb.h | 1
sound/usb/usbaudio.c | 6
26 files changed, 5574 insertions(+), 373 deletions(-)
-----
Alan Stern:
o USB: Update sound/usb/usbaudio.c
o USB: Fix DMA coherence when reading device descriptor
o USB: Don't dereference NULL actconfig
o USB Storage: unusual_devs update
Arjan van de Ven:
o usb: remove some sleep_on's
Dave Jones:
o USB: fix suspicious pointer usage in kobil_sct driver
David Brownell:
o USB gadget: serial driver config update
o USB gadget: ethernet config updates
o USB gadget: zero config updates
o USB gadget: config/build updates
o USB gadget: add File-backed Storage Gadget (FSG)
o USB gadget: net2280 controller updates
Greg Kroah-Hartman:
o USB: add ohci support for OMAP controller
o USB: fix up whiteheat syntax errors from previous patch
o USB: fix up emi drivers Kconfig dependancy
o USB storage: remove info sysfs file as it violates the sysfs 1 value per file rule
Herbert Xu:
o USB Storage: revert freecom dvd-rw fx-50 usb-ide patch
Oliver Neukum:
o USB: fix dma to stack in ti driver
o USB: fix whiteheat doing DMA to stack
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.