[PATCH 2.6] scx200_acb: Use PCI I/O resource when appropriate

The CS5535 and CS5536 both define the I/O base for the SMBUS device in a 
PCI header.  This patch uses that header for the I/O base rather then 
using the MSR backdoor.

This patch isn't as urgent as the other one, so it can probably take the 
usual trip up through Greg's tree.

-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>

[PATCH] scx200_acb:  Use PCI I/O resource when appropriate

From: Jordan Crouse <jordan.crouse <at> amd.com>

On the CS5535 and CS5536, the I/O resource is allocated through PCI,
so use that instead of using the MSR backdoor.

Signed-off-by: Jordan Crouse <jordan.crouse <at> amd.com>
---

 drivers/i2c/busses/scx200_acb.c |  114 +++++++++++++++++++++++++++------------
 1 files changed, 78 insertions(+), 36 deletions(-)

diff --git a/drivers/i2c/busses/scx200_acb.c b/drivers/i2c/busses/scx200_acb.c
index e7a2225..454492f 100644
--- a/drivers/i2c/busses/scx200_acb.c

2.6.16.1 (1) vs ieee1394 (0) HELP! (I told the missus I could do this)

Greetings all;

I may have found a gotcha in the 2.6.16.1 and NDI how far back it goes 
because I haven't used anything ieee1394 in months.

Anyway, I plugged in my camera, a Sony DCR-TVR460 and fired up kino, 
fully expecting to see the viewfinders image on screen as soon as I 
switched kino to the capture screen.

Unforch, its blank and kino is locked up, needing kde's emergency kill 
the process to kill it when I click on the closing x.

From the logs, I get this is 4 or 5 lines.

Mar 31 17:30:16 coyote ieee1394.agent[8925]: ... no drivers for IEEE1394 
product 0x/0x/0x
Mar 31 17:30:16 coyote ieee1394.agent[8921]: ... no drivers for IEEE1394 
product 0x/0x/0x
Mar 31 17:30:16 coyote kernel: ieee1394: raw1394: /dev/raw1394 device 
initialized

And about 6 or 7 lines of gconf verbosy later, this:

Mar 31 17:31:28 coyote kernel: ohci1394: fw-host0: Waking dma ctx=0 ... 
processing is probably too slow

then:

[root <at> coyote linux-2.6.16.1]# lsmod |grep 1394
raw1394                24172  0

Re: [RESEND][2.6.15] New ATA error messages on upgrade to 2.6.15

On Mar 31, 2006, at 17:21:16, Eric D. Mudama wrote:
> can you please post your dmesg?

Dmesg below.  Thanks for taking a look!

Cheers,
Kyle Moffett

Total memory = 832MB; using 2048kB for hash table (at c0400000)
Linux version 2.6.15-1-powerpc (Debian 2.6.15-3) (horms <at> verge.net.au)  
(gcc version 4.0.3 20060115 (prerelease) (Debian 4.0.2-7)) #2 Thu Jan  
19 03:51:42 UTC 2006
Found UniNorth memory controller & host bridge, revision: 7
Mapped at 0xfdf00000
Found a Keylargo mac-io controller, rev: 2, mapped at 0xfde80000
Processor NAP mode on idle enabled.
PowerMac motherboard: PowerMac G4 AGP Graphics
Found UniNorth PCI host bridge at 0xf0000000. Firmware bus number: 0->0
Found UniNorth PCI host bridge at 0xf2000000. Firmware bus number: 0->1
Found UniNorth PCI host bridge at 0xf4000000. Firmware bus number: 0->0
via-pmu: Server Mode is disabled
PMU driver 2 initialized for Core99, firmware: 0c
nvram: Checking bank 0...
nvram: gen0=366, gen1=367
nvram: Active bank is: 1
nvram: OF partition at 0x210
nvram: XP partition at 0x1220
nvram: NR partition at 0x1320
On node 0 totalpages: 212992
   DMA zone: 196608 pages, LIFO batch:31

Re: [PATCH] splice exports

Jens Axboe wrote:
> On Fri, Mar 31 2006, Jeff Garzik wrote:
>> Jens Axboe wrote:
>>> On Fri, Mar 31 2006, Arjan van de Ven wrote:
>>>> On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
>>>>> Woe be unto he who builds their filesystems as modules.
>>>> since splice support is highly linux specific and new.. shouldn't these
>>>> be _GPL exports?
>>> Yes they should, I'll add that to the current splice tree.
>> Why?  We don't usually restrict filesystems in such ways...  I would 
>> rather a binary-only module reference generic_file_splice_read() than 
>> create its own.
> 
> You could use that very same argument for any piece of the kernel, then,
> so I don't think that adds much value to _not_ exporting it GPL.

Not really, because I'm considering the Real World(tm) users, not 
abstract theory :)  The other filesystem junk is exported non-GPL, and 
existing binary-only filesystems use that stuff.

IOW its a bit rude to say "oh you can have your BO filesystem, just not 
splice support."

	Jeff

Re: [ck] Re: Staircase test patch

On Saturday 01 April 2006 07:31, Thorsten Will wrote:
> On Friday 31 March 2006 23:07 +1000, Con Kolivas wrote:
> >Hi Thorsten et al
>
> Hi, Con.
>
> >Thorsten could you please test to see if this fixes the problem for you?
>
> Oh boy, oh boy, oh boy.
>
> Against a bash loop:
> |# dd bs=1M count=2048 </dev/hdb >/dev/null
> |2048+0 records in
> |2048+0 records out
> |2147483648 bytes transferred in 35.497603 seconds (60496582 bytes/sec)
>
> Yes! Success! And the crowd goes wild! 
>
> I think you finally nailed it. Thank you so much!

No, thank _you_ for bringing it to my attention and testing :)

Cheers,
Con

Re: [V9fs-developer] [PATCH] 9p: cleanup unused functions

Hmm, the fact that they are not used currently doesn't mean that they are
not going to be used soon. Please don't remove them, I'll have to add them
back again :)

Thanks,
	Lucho

On Fri, Mar 31, 2006 at 09:25:49PM +0000, Eric Van Hensbergen said:
> >From nobody Mon Sep 17 00:00:00 2001
> From: Eric Van Hensbergen <ericvh <at> gmail.com>
> Date: Fri Mar 31 15:20:06 2006 -0600
> Subject: [PATCH] 9p: remove unused functions
> 
> This patch just removes some unused functions that were previously
> 
> Signed-off-by: Eric Van Hensbergen <ericvh <at> gmail.com>
> 
> ---
> 
>  fs/9p/conv.c  |   26 --------------------------
>  fs/9p/fcall.c |   25 -------------------------
>  fs/9p/mux.c   |   26 --------------------------
>  3 files changed, 0 insertions(+), 77 deletions(-)
> 
> 6b9742bbf5beb884dd9a1f285d04da8b14c6a09d
> diff --git a/fs/9p/conv.c b/fs/9p/conv.c
> index a767e05..63311ef 100644
> --- a/fs/9p/conv.c
> +++ b/fs/9p/conv.c
>  <at>  <at>  -535,32 +535,6  <at>  <at>  struct v9fs_fcall *v9fs_create_tversion(

RE: IDE CMD 64x PCI driver

Hello,

>I am having difficultly getting the IDE CMD 64x PCI driver to work for the
>CMD PCI-648 device.  I have decided to dig through kernel and driver code
>to find out why and hopefully correct the problem.

It seems nobody maintains the CMD64x driver.

Best Regards
Komuro

[PATCH] net: Broadcast ARP packets on link local addresses

From: David Daney

Greetings,

When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927.  There are several user space daemons available that implement
most of the protocol (zcip, busybox, ...).  The kernel's APR driver
should function in the normal manner except that it is required to
broadcast all ARP packets that it originates in the link local address
space (169.254.0.0/16).  RFC 3927 section 2.5 explains the requirement.

The current ARP code is non-compliant because it does not broadcast
some ARP packets as required by RFC 3927.

This patch to net/ipv4/arp.c checks the source address of all ARP
packets and if the fall in 169.254.0.0/16, they are broadcast instead
of unicast.  I would like to thank Freek Dijkstra wrote the first
version of the patch.  He was kind enough to sign off on it in his
(off-list) e-mail to me:

>David Daney wrote:
>
>
>> For the linux kernel the requirements for contributing are quite easy.
>> All people who wrote the patch simply affirm that they are have the
>> right to contribute and that they are doing so.  See section 11 of
>> Documentation/SubmittingPatches in the kernel source tree.
>
>

2.6.16.1 (1) vs ieee1394 (0) HELP! (I told the missus I could do this)

Greetings all;

I sent this once, but it hasn't come back in about 20 minutes, sorry if 
it hits twice.

I may have found a gotcha in the 2.6.16.1 and NDI how far back it goes 
because I haven't used anything ieee1394 in months.

Anyway, I plugged in my camera, a Sony DCR-TVR460 and fired up kino, 
fully expecting to see the viewfinders image on screen as soon as I 
switched kino to the capture screen.

Unforch, its blank and kino is locked up, needing kde's emergency kill 
the process to kill it when I click on the closing x.

From the logs, I get this is 4 or 5 lines.

Mar 31 17:30:16 coyote ieee1394.agent[8925]: ... no drivers for IEEE1394 
product 0x/0x/0x
Mar 31 17:30:16 coyote ieee1394.agent[8921]: ... no drivers for IEEE1394 
product 0x/0x/0x
Mar 31 17:30:16 coyote kernel: ieee1394: raw1394: /dev/raw1394 device 
initialized

And about 6 or 7 lines of gconf verbosy later, this:

Mar 31 17:31:28 coyote kernel: ohci1394: fw-host0: Waking dma ctx=0 ... 
processing is probably too slow

then:

Re: Semantics of smp_mb() [was : Re: [PATCH] Fix RCU race in access of nohz_cpu_mask ]

[Unknown author]
> > > From comments by jejb, we're looking at modifying the mmiowb
> > > API by adding an argument which would be a register to read
> > > from if the architecture in question needs ordering in this
> > > way but does not have a lighter weight mechanism like the Altix
> > > mmiowb.  Since there will now need to be a width indication,
> > > mmiowb will be replaced with mmiowb[bwlq].
> >
> > Any progress on this front?  I figured that I would wait to update
> > the ordering document until after this change happened, but if it
> > is going to be awhile, I should proceed with the current API.

I avoided doing this initially on the premise that I shouldn't do things 
'just because we might need it in the future' since that way seems to 
lead to madness.  Is there actual hardware that needs an argument to 
mmiowb() (i.e. that can't just do a read from the system's single bridge 
or something)?

Jesse