* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Guennadi Liakhovetski @ 2007-08-05 14:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <200708050135.07753.arnd@arndb.de>
On Sun, 5 Aug 2007, Arnd Bergmann wrote:
> On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
> > I tried using of_serial.c on a (PPC) MPC8241 based system, which has a
> > "16650A" compatible double UART built into the SoC. Using of_serial.c
> > causes the ports to be autoconfigured, and this fails. The loopback test
> > fails, because the MSR register on 824[15] doesn't implement the
> > UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs
> > without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these
> > SOCs to skip the loopback test altogether? The latter is certainly easier
> > and affects much fewer systems, so, I'd go for that.
>
> Yes, that sounds good. Just make sure you test the "compatible" property
> in the device node for something appropriate. In of_platform_serial_probe(),
> you can then do something like
>
> if (of_device_is_compatible(ofdev, "mpc8241-serial"))
> flags |= UPF_SKIP_TEST;
That would be a possibility, but that would mean all 8241/8245 have to
adjust their .dts. Ok, there are not so many of them in the mainline now
(in fact, hardly any apart from linkstation:-)), still. Cannot we use
something already available to just check if we're running on such a CPU?
Worst case - find and parse cpu node, or maybe using some cpu_feature?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* my cpu is MPC860, kernel version is 2.6.20.14, the kernel start info in the mail. why does the kernel panic?
From: poorbeyond @ 2007-08-05 10:54 UTC (permalink / raw)
To: Linux-ppc mail list
[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]
^_^=>bootm 300000
## Booting image at 00300000 ...
Image Name: Linux-2.6.20.14
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1038351 Bytes = 1014 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x01D5DB10 => set upper limit to 0x00800000
No initrd
## Transferring control to Linux (at address 00000000) ...
bootm1
Linux version 2.6.20.14 (root@localhost.localdomain) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #1 PREEMPT Sun Aug 5 18:23:18 CST 2007
I2C/SPI/SMC1 microcode patch installed.
Zone PFN ranges:
DMA 0 -> 2048
Normal 2048 -> 2048
early_node_map[1] active PFN ranges
0: 0 -> 2048
Built 1 zonelists. Total pages: 2032
Kernel command line:
PID hash table entries: 32 (order: 5, 128 bytes)
Decrementer Frequency = 187500000/60
Warning: real time clock seems stuck!
cpm_uart: console: compat mode
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)in
Memory: 5732k available (1592k kernel code, 688k data, 92k init, 0k highmem)
Security Framework v1.0.0 initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
------------[ cut here ]------------
Badness at 00200880 [verbose debug info unavailable]
Call Trace:
[00285E60] [00008E24] (unreliable)
[00285E90] [000EBA14]
[00285EA0] [00003D88]
[00285ED0] [000030EC]
[00285F90] [00202E98]
[00285FA0] [000022DC]
[00285FF0] [00004BA0]
NET: Registered protocol family 16
Generic PHY: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 256 (order: 0, 4096 bytes)
TCP bind hash table entries: 128 (order: -1, 2560 bytes)
TCP: Hash tables configured (established 256 bind 128)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(4160749566.303:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux: Registering netfilter hooks
io scheduler noop registered (default)
Serial: CPM driver $Revision: 0.02 $
cpm_uart: WARNING: no UART devices found on platform bus!
cpm_uart: the driver will guess configuration, but this mode is no longer supported.
ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
LXT970: Registered new driver
LXT971: Registered new driver
fs_enet.c:v1.0 (Aug 8, 2005)
------------[ cut here ]------------
Kernel BUG at 000056a4 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT
NIP: 000056A4 LR: 00005658 CTR: 00000000
REGS: 00285e90 TRAP: 0700 Not tainted (2.6.20.14)
MSR: 00029032 <EE,ME,IR,DR> CR: 44000042 XER: 2000107F
TASK = 00282bd0[1] 'swapper' THREAD: 00284000
GPR00: 00400165 00285F40 00282BD0 0025B104 00000000 00000BDA 00306FFC 00000000
GPR08: 001C1648 00000001 00401000 00400164 00000000 40000001 02000000 00000001
GPR16: 00000000 01FFFA54 FFFFFFFF 00000000 00800000 007FFF00 01FFAA14 00285F78
GPR24: 005FF000 001C0000 00000000 0025B0E0 00001000 00252000 002FF820 0025B0C0
Call Trace:
[00285F40] [00005628] (unreliable)
[00285F70] [0020AAB0]
[00285FA0] [000022DC]
[00285FF0] [00004BA0]
Instruction dump:
38631658 48186b4d 7fc3f378 48055c05 7fe3fb78 7f44d378 48045895 48000078
801d0000 5400066e 3160ffff 7d2b0110 <0f090000> 38000400 7d20f828 7d290378
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
poorbeyond
2007-08-05
[-- Attachment #2: Type: text/html, Size: 10595 bytes --]
^ permalink raw reply
* Re: ML403 / ALSA driver for AC97 Controller
From: Joachim Förster @ 2007-08-05 8:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40707211317q47b12a38jbe05e4d2c89767f4@mail.gmail.com>
Hi Grant,
On Sat, 2007-07-21 at 14:17 -0600, Grant Likely wrote:
> A few initial comments:
> 1. You should post this code as a patch against the kernel tree.
> Links to tarballs are not the best way to get code reviewed. Post
> your patches to both the ALSA and linuxppc-dev mailing lists.
> 2. (get this out of the way quickly) Coding standard doesn't match the
> kernel (indent w/ tabs, keep lines < 80 chars, etc). You should run
> your code through 'scripts/Lindent' in the kernel tree. That will
> sort out many of the whitespace issues.
> 3. In the same vein, c++ style comments need to be scrubbed.
> 4. Do not directly include xparameters.h in your driver. The driver
> should get it's data from the platform bus registration (of the
> of_device registration when we move to arch/powerpc).
> 5. struct 'platform_device devices[]' needs to be moved to
> arch/ppc/sysdev/virtex_devices.c
About a week ago I finished work on the last four issues and in last
days I created several patches against different kernel trees. ATM I
have three patches, against:
tag v2.6.22 (Linus)
branch master (Linus)
branch virtex-dev (your v2.6.22 based branch)
I had to make different patches, because one version didn't apply
cleanly to the other branches, due to differences in a Kconfig file e.g.
and above all in the virtex_devices.c file.
Now, my question is: Which one should I post to the mailing list? (after
testing these patches - I haven't got a chance yet to test them on real
hardware - compilation is ok).
One more thing: I made two parts, one patch adds the driver and the
other one makes the registration with the platform bus. Is this ok? (I
saw this scheme in your virtex-dev branch.)
> 6. Have you looked into the new ALSA infrastructure which separates
> Codecs from controllers (in sound/soc)? It might be a good idea to go
> that route for this driver.
Meanwhile, I had a _very_ short look into ASoC ... and I don't really
know ... My driver already uses the AC97 Layer of ALSA, so in some way
the codec is already separated from the controller. Xilinx' AC97
Controller Reference does have some very bad impact on the codec which
forced me to implement codec register shadowing ... hmmmm, I have to
look at it (ASoC) again - as soon as there is more (free)time ...
Joachim
^ permalink raw reply
* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Stefan Richter @ 2007-08-05 7:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Robert Hancock, linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <1186272926.938.8.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
>>> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
>>> with the DMA implementation on that architecture. There are enough cards
>>> out there that only support 32-bit DMA that this really needs to work..
>> Yes, could the PPC folks please have a look at it? Thanks.
>
> Smells like we may have a bug there. No worries though, all current PPC
> machines have an iommu that will not give out addresses above 32 bits
> anyway, but I'll double check what's up.
>
> Do you see something in dmesg when that happens ?
There was nothing in Olaf's report, except for trouble in sbp2 _after_
the failure. http://lkml.org/lkml/2007/8/1/344 (I don't have a PMac.)
--
Stefan Richter
-=====-=-=== =--- --=-=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: "Badness at kernel/irq/resend.c:70" on boot - via-pmu?
From: Linus Torvalds @ 2007-08-05 4:41 UTC (permalink / raw)
To: Paul Collins, Ingo Molnar; +Cc: paulus, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <87sl6ypsx2.fsf@briny.wgtn.ondioline.org>
On Sun, 5 Aug 2007, Paul Collins wrote:
>
> I got the message below on boot with 2.6.23-rc2 on my PowerBook.
It's a debug message, I think we need to remove it. It's trying to figure
out what goes wrong with one particular machine, and I probably shouldn't
have merged it for mainline.
Ignore it, it will be gone soon enough, and it should happen just once per
boot.
Linus
^ permalink raw reply
* "Badness at kernel/irq/resend.c:70" on boot - via-pmu?
From: Paul Collins @ 2007-08-05 3:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: paulus, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <alpine.LFD.0.999.0708032031480.5037@woody.linux-foundation.org>
Hi Linus,
I got the message below on boot with 2.6.23-rc2 on my PowerBook.
I've Cc'd some powerpc folks because via_pmu_interrupt is in the
Macintosh PMU driver.
Hmm, I just looked back in my logs and I also got that message with
commit 7a883eaf62f4b943ebec738ce3b0796c67ef5d32. Before that I used
6c8dca5d53f95009d4fff00195bf38f277dc4366 and there was no badness
message logged by that one. There's only about 480 commits between
those two, so I can bisect it if necessary.
The call traces differ, so here are both messages.
v2.6.23-rc2:
------------[ cut here ]------------
Badness at kernel/irq/resend.c:70
NIP: c0054ca4 LR: c0054c78 CTR: c00162b0
REGS: c0473d80 TRAP: 0700 Not tainted (2.6.23-rc2-g036acf4f)
MSR: 00021032 <ME,IR,DR> CR: 42000024 XER: 00000000
TASK = c04451e0[0] 'swapper' THREAD: c0472000
GPR00: 00000001 c0473e30 c04451e0 00000178 0000002f 00600000 c0480000 0000002f
GPR08: 000186a0 c0480000 0048002f 00000400 00000000 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 40900000 00d3bbc0 00000000
GPR24: c0444000 c0480000 c0480000 c043b81c 00000001 0000002f 00024408 c044b1bc
NIP [c0054ca4] check_irq_resend+0x5c/0xc0
LR [c0054c78] check_irq_resend+0x30/0xc0
Call Trace:
[c0473e30] [c0054c78] check_irq_resend+0x30/0xc0 (unreliable)
[c0473e50] [c00547d0] enable_irq+0x84/0xa8
[c0473e60] [c0220fec] via_pmu_interrupt+0x3d8/0xac0
[c0473e90] [c0053dfc] handle_IRQ_event+0x4c/0xa0
[c0473eb0] [c0055250] handle_fasteoi_irq+0xac/0x100
[c0473ec0] [c0006528] do_IRQ+0x68/0xa8
[c0473ed0] [c000ffe8] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0x88/0xd0
LR = cpu_idle+0x88/0xd0
[c0473f90] [c00090bc] cpu_idle+0xcc/0xd0 (unreliable)
[c0473fa0] [c0351f9c] rest_init+0x58/0x68
[c0473fb0] [c04189a0] start_kernel+0x260/0x274
[c0473ff0] [00003860] 0x3860
Instruction dump:
4e800421 801f0000 3d20c005 57cb052a 39295030 2f0b0400 7f804800 419e0030
3d20c048 800994e4 7c000034 5400d97e <0f000000> 2f800000 41be0048 38000001
7a883eaf62f4b943ebec738ce3b0796c67ef5d32:
------------[ cut here ]------------
Badness at kernel/irq/resend.c:70
NIP: c0054bfc LR: c0054bd0 CTR: c00162b0
REGS: effc3e60 TRAP: 0700 Not tainted (2.6.23-rc1-g6cc0258f)
MSR: 00021032 <ME,IR,DR> CR: 48000084 XER: 20000000
TASK = effc17f0[1] 'swapper' THREAD: effc2000
GPR00: 00000001 effc3f10 effc17f0 00000178 0000002f 00000000 c0470000 0000002f
GPR08: 000186a0 c0470000 0048002f 00000000 82000022 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 40900000 00d3ad48 00000000
GPR24: c0443000 c0470000 effc2000 c043ef4c 00000001 0000002f 00024008 c044a1bc
NIP [c0054bfc] check_irq_resend+0x5c/0xc0
LR [c0054bd0] check_irq_resend+0x30/0xc0
Call Trace:
[effc3f10] [c0054bd0] check_irq_resend+0x30/0xc0 (unreliable)
[effc3f30] [c0054728] enable_irq+0x84/0xa8
[effc3f40] [c0220e74] via_pmu_interrupt+0x3d8/0xac0
[effc3f70] [c0430f28] via_pmu_start+0x168/0x190
[effc3f80] [c04171e4] kernel_init+0xc8/0x284
[effc3ff0] [c0010800] kernel_thread+0x44/0x60
Instruction dump:
4e800421 801f0000 3d20c005 57cb052a 39294f88 2f0b0400 7f804800 419e0030
3d20c047 800974e4 7c000034 5400d97e <0f000000> 2f800000 41be0048 38000001
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Benjamin Herrenschmidt @ 2007-08-05 0:15 UTC (permalink / raw)
To: Stefan Richter
Cc: Robert Hancock, linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <46B4B7C6.1040107@s5r6.in-berlin.de>
> > If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
> > with the DMA implementation on that architecture. There are enough cards
> > out there that only support 32-bit DMA that this really needs to work..
>
> Yes, could the PPC folks please have a look at it? Thanks.
Smells like we may have a bug there. No worries though, all current PPC
machines have an iommu that will not give out addresses above 32 bits
anyway, but I'll double check what's up.
Do you see something in dmesg when that happens ?
Ben.
^ permalink raw reply
* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Arnd Bergmann @ 2007-08-04 23:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Guennadi Liakhovetski, linux-serial
In-Reply-To: <Pine.LNX.4.60.0708050106270.4299@poirot.grange>
On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
> I tried using of_serial.c on a (PPC) MPC8241 based system, which has a
> "16650A" compatible double UART built into the SoC. Using of_serial.c
> causes the ports to be autoconfigured, and this fails. The loopback test
> fails, because the MSR register on 824[15] doesn't implement the
> UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs
> without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these
> SOCs to skip the loopback test altogether? The latter is certainly easier
> and affects much fewer systems, so, I'd go for that.
Yes, that sounds good. Just make sure you test the "compatible" property
in the device node for something appropriate. In of_platform_serial_probe(),
you can then do something like
if (of_device_is_compatible(ofdev, "mpc8241-serial"))
flags |= UPF_SKIP_TEST;
Arnd <><
^ permalink raw reply
* 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Guennadi Liakhovetski @ 2007-08-04 23:17 UTC (permalink / raw)
To: linux-serial; +Cc: linuxppc-dev
Hi,
I tried using of_serial.c on a (PPC) MPC8241 based system, which has a
"16650A" compatible double UART built into the SoC. Using of_serial.c
causes the ports to be autoconfigured, and this fails. The loopback test
fails, because the MSR register on 824[15] doesn't implement the
UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs
without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these
SOCs to skip the loopback test altogether? The latter is certainly easier
and affects much fewer systems, so, I'd go for that.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Stefan Richter @ 2007-08-04 17:30 UTC (permalink / raw)
To: Robert Hancock; +Cc: linuxppc-dev, Olaf Hering, stable, linux-kernel
In-Reply-To: <46B4B3DC.7020609@shaw.ca>
(Adding Cc: linuxppc-dev, olh)
Robert Hancock wrote:
> Stefan Richter wrote:
>> Date: Wed, 1 Aug 2007 20:30:36 +0200 (CEST)
>> From: Stefan Richter <stefanr@s5r6.in-berlin.de>
>> Subject: ieee1394: revert "sbp2: enforce 32bit DMA mapping"
>>
>> Revert commit 0555659d63c285ceb7ead3115532e1b71b0f27a7 from 2.6.22-rc1.
>> The dma_set_mask call somehow failed on a PowerMac G5, PPC64:
>> http://lkml.org/lkml/2007/8/1/344
>>
>> Should there ever occur a DMA mapping beyond the physical DMA range, a
>> proper SBP-2 firmware will report transport errors. So let's leave it
>> at that.
>
> Isn't this a rather poor workaround? All this means is that if we fail
> to set a 32-bit DMA mask, we're likely to blow up at runtime instead of
> at initialization time, when we get a DMA mapping over 4GB.
I generally agree with you. But since I actually never heard of
problems that could directly be related to sbp2's DMA areas exceeding
the OHCI-1394 physical DMA range (4GB in most OHCI-1394
implementations), I consider this simple reversion good enough for post
2.6.23-rc1 and especially for 2.6.22.y.
My original commit 0555659.. was a violation of "If it ain't (known)
broken, don't fix it".
> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
> with the DMA implementation on that architecture. There are enough cards
> out there that only support 32-bit DMA that this really needs to work..
Yes, could the PPC folks please have a look at it? Thanks.
>> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
>> Tested-by: Olaf Hering <olh@suse.de>
>> ---
>> Same as commit a9c2f18800753c82c45fc13b27bdc148849bdbb2.
>>
>> drivers/ieee1394/sbp2.c | 5 -----
>> 1 file changed, 5 deletions(-)
>>
>> Index: linux-2.6.22/drivers/ieee1394/sbp2.c
>> ===================================================================
>> --- linux-2.6.22.orig/drivers/ieee1394/sbp2.c
>> +++ linux-2.6.22/drivers/ieee1394/sbp2.c
>> @@ -774,11 +774,6 @@ static struct sbp2_lu *sbp2_alloc_device
>> SBP2_ERR("failed to register lower 4GB address range");
>> goto failed_alloc;
>> }
>> -#else
>> - if (dma_set_mask(hi->host->device.parent, DMA_32BIT_MASK)) {
>> - SBP2_ERR("failed to set 4GB DMA mask");
>> - goto failed_alloc;
>> - }
>> #endif
>> }
>>
--
Stefan Richter
-=====-=-=== =--- --=--
http://arcgraph.de/sr/
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Kumar Gala @ 2007-08-04 16:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Alexandros Kostopoulos
In-Reply-To: <20070803201036.GA18229@ld0162-tx32.am.freescale.net>
On Aug 3, 2007, at 3:10 PM, Scott Wood wrote:
> On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos
> wrote:
>> Hi all,
>> in the old arch/ppc tree, there was a function called
>> pq2ads_setup_pci()
>> that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering,
>> where
>> are these registers configured now in arch/powerpc? I can't seem
>> to find
>> these code now.
>
> It's done by the firmware or the bootwrapper.
>> Also, I can see that now bus 0, dev 0 (which I think represents
>> the host
>> bridge, right?) is now excluded using pq2_pci_exclude_device, but it
>> wasn't in older code. Why is that?
>
> The older code probably either excluded all host bridges by class, or
> just lived with the error message that gets printed on boot.
This will change in 2.6.24. I've fixed the reason we excluded the
host bridges on Freescale host bridges.
- k
^ permalink raw reply
* Re: [PATCH v2] cell: move SPU affinity init to spu_management_of_ops
From: Arnd Bergmann @ 2007-08-04 7:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andre Detsch, Paul Mackerras, hch, cbe-oss-dev
In-Reply-To: <46B3DC2A.408@am.sony.com>
On Saturday 04 August 2007, Geoff Levand wrote:
>
> From: Andre Detsch <adetsch@br.ibm.com>
>
> This patch moves affinity initialization code from spu_base.c to a
> new spu_management_of_ops function (init_affinity), which is empty
> in the case of PS3. This fixes a linking problem that was happening
> when compiling for PS3.
> Also, some small code style changes were made.
>
> Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: Trying to use Device Tree...and getting continuous interrupts from attached 88e1145
From: Benjamin Herrenschmidt @ 2007-08-04 2:33 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90108BE44C2@EMPBEDEX.empirix.com>
On Fri, 2007-08-03 at 18:54 -0400, Morrison, Tom wrote:
> Now, that looks OK! Those are what I would expect. And when the
> mdio/phy are probed, configured, and the 88E1145 interrupt (EXT7
> (0x37H)) is enabled, the interrupt never (seemingly) gets cleared,
> and basically hangs the entire box up and eventually it panics!
>
> I don't even have an external phy(SFP) connected to this 88e1148 phy..
>
> I am at a lost - is there something I am missing in device tree?
> Help mr. wizard (Kumar?)...
Double check you got the interrupt sense and polarity right.
Ben.
^ permalink raw reply
* Re: Page faults blowing up ... [was Re: [PATCH] Fix special PTE code for secondary hash bucket
From: Benjamin Herrenschmidt @ 2007-08-04 2:31 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras, benh
In-Reply-To: <20070803193258.GA9613@austin.ibm.com>
On Fri, 2007-08-03 at 14:32 -0500, Linas Vepstas wrote:
> On Fri, Aug 03, 2007 at 06:58:51PM +1000, Paul Mackerras wrote:
> > The code for mapping special 4k pages on kernels using a 64kB base
> > page size was missing the code for doing the RPN (real page number)
> > manipulation when inserting the hardware PTE in the secondary hash
> > bucket. It needs the same code as has already been added to the
> > code that inserts the HPTE in the primary hash bucket. This adds it.
>
> So what are the symptoms of hitting this? Does this affect only
> recent kernels, or old ones too?
Paulus stuff is likely to be unrelated to your bug. Also, whatever blurb
you pasted in this email is totally incomprehensible due to total lack
of context.
Ben.
^ permalink raw reply
* Re: [patch 06/10] 40x decrementer fixes
From: Benjamin Herrenschmidt @ 2007-08-04 2:28 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B3617B.10509@ru.mvista.com>
On Fri, 2007-08-03 at 21:10 +0400, Sergei Shtylyov wrote:
> > Why bother doing this?! This will only warrant you imprecise decrementer
> > interrupts while it should be interrupting at the precise period currently (if
> > you load PIT once)...
>
> I.e. the error will only accumulate. NAK.
No, it won't since the timebase is always used as the reference.
Ben.
^ permalink raw reply
* Re: [patch 06/10] 40x decrementer fixes
From: Benjamin Herrenschmidt @ 2007-08-04 2:28 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B35C07.4090806@ru.mvista.com>
On Fri, 2007-08-03 at 20:47 +0400, Sergei Shtylyov wrote:
> Josh Boyer wrote:
>
> > Allow generic_calibrate_decr to work for 40x platforms. Given that the hardware
> > behavior is identical, this also changes the set_dec function to reload the PIT
> > on 40x to match the behavior 44x currently has.
>
> Why bother doing this?! This will only warrant you imprecise decrementer
> interrupts while it should be interrupting at the precise period currently (if
> you load PIT once)...
Because that's what the kernel timekeeping code expects ? The reference
time is the timebase and it doesn't drift.
The DEC/PIT is commonly used to trigger any timing, such as what is done
for lost interrupts on some platforms. Also, with dynticks, we'll most
certainly want variable reload values as well.
So I'm very happy to have Josh change the code that way. It makes things
more consistent accross the board and removes confusion.
Ben.
^ permalink raw reply
* [PATCH v2] cell: move SPU affinity init to spu_management_of_ops
From: Geoff Levand @ 2007-08-04 1:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: hch, linuxppc-dev, Paul Mackerras, Andre Detsch, cbe-oss-dev
In-Reply-To: <200707252342.50244.adetsch@br.ibm.com>
From: Andre Detsch <adetsch@br.ibm.com>
This patch moves affinity initialization code from spu_base.c to a
new spu_management_of_ops function (init_affinity), which is empty
in the case of PS3. This fixes a linking problem that was happening
when compiling for PS3.
Also, some small code style changes were made.
Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Arnd,
I rebased this to to Paul's powerpc git tree. This needs to go
in for 2.6.23, as it fixes build breakage for PS3-only configs.
Please check and ack.
-Geoff
arch/powerpc/platforms/cell/spu_base.c | 141 --------------------------
arch/powerpc/platforms/cell/spu_manage.c | 163 +++++++++++++++++++++++++++++++
arch/powerpc/platforms/ps3/spu.c | 6 +
include/asm-powerpc/spu_priv1.h | 7 +
4 files changed, 177 insertions(+), 140 deletions(-)
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -36,7 +36,6 @@
#include <asm/spu_priv1.h>
#include <asm/xmon.h>
#include <asm/prom.h>
-#include "spu_priv1_mmio.h"
const struct spu_management_ops *spu_management_ops;
EXPORT_SYMBOL_GPL(spu_management_ops);
@@ -636,138 +635,6 @@ static ssize_t spu_stat_show(struct sys_
static SYSDEV_ATTR(stat, 0644, spu_stat_show, NULL);
-/* Hardcoded affinity idxs for QS20 */
-#define SPES_PER_BE 8
-static int QS20_reg_idxs[SPES_PER_BE] = { 0, 2, 4, 6, 7, 5, 3, 1 };
-static int QS20_reg_memory[SPES_PER_BE] = { 1, 1, 0, 0, 0, 0, 0, 0 };
-
-static struct spu *spu_lookup_reg(int node, u32 reg)
-{
- struct spu *spu;
-
- list_for_each_entry(spu, &cbe_spu_info[node].spus, cbe_list) {
- if (*(u32 *)get_property(spu_devnode(spu), "reg", NULL) == reg)
- return spu;
- }
- return NULL;
-}
-
-static void init_aff_QS20_harcoded(void)
-{
- int node, i;
- struct spu *last_spu, *spu;
- u32 reg;
-
- for (node = 0; node < MAX_NUMNODES; node++) {
- last_spu = NULL;
- for (i = 0; i < SPES_PER_BE; i++) {
- reg = QS20_reg_idxs[i];
- spu = spu_lookup_reg(node, reg);
- if (!spu)
- continue;
- spu->has_mem_affinity = QS20_reg_memory[reg];
- if (last_spu)
- list_add_tail(&spu->aff_list,
- &last_spu->aff_list);
- last_spu = spu;
- }
- }
-}
-
-static int of_has_vicinity(void)
-{
- struct spu* spu;
-
- spu = list_entry(cbe_spu_info[0].spus.next, struct spu, cbe_list);
- return of_find_property(spu_devnode(spu), "vicinity", NULL) != NULL;
-}
-
-static struct spu *aff_devnode_spu(int cbe, struct device_node *dn)
-{
- struct spu *spu;
-
- list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list)
- if (spu_devnode(spu) == dn)
- return spu;
- return NULL;
-}
-
-static struct spu *
-aff_node_next_to(int cbe, struct device_node *target, struct device_node *avoid)
-{
- struct spu *spu;
- const phandle *vic_handles;
- int lenp, i;
-
- list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list) {
- if (spu_devnode(spu) == avoid)
- continue;
- vic_handles = get_property(spu_devnode(spu), "vicinity", &lenp);
- for (i=0; i < (lenp / sizeof(phandle)); i++) {
- if (vic_handles[i] == target->linux_phandle)
- return spu;
- }
- }
- return NULL;
-}
-
-static void init_aff_fw_vicinity_node(int cbe)
-{
- struct spu *spu, *last_spu;
- struct device_node *vic_dn, *last_spu_dn;
- phandle avoid_ph;
- const phandle *vic_handles;
- const char *name;
- int lenp, i, added, mem_aff;
-
- last_spu = list_entry(cbe_spu_info[cbe].spus.next, struct spu, cbe_list);
- avoid_ph = 0;
- for (added = 1; added < cbe_spu_info[cbe].n_spus; added++) {
- last_spu_dn = spu_devnode(last_spu);
- vic_handles = get_property(last_spu_dn, "vicinity", &lenp);
-
- for (i = 0; i < (lenp / sizeof(phandle)); i++) {
- if (vic_handles[i] == avoid_ph)
- continue;
-
- vic_dn = of_find_node_by_phandle(vic_handles[i]);
- if (!vic_dn)
- continue;
-
- name = get_property(vic_dn, "name", NULL);
- if (strcmp(name, "spe") == 0) {
- spu = aff_devnode_spu(cbe, vic_dn);
- avoid_ph = last_spu_dn->linux_phandle;
- }
- else {
- mem_aff = strcmp(name, "mic-tm") == 0;
- spu = aff_node_next_to(cbe, vic_dn, last_spu_dn);
- if (!spu)
- continue;
- if (mem_aff) {
- last_spu->has_mem_affinity = 1;
- spu->has_mem_affinity = 1;
- }
- avoid_ph = vic_dn->linux_phandle;
- }
- list_add_tail(&spu->aff_list, &last_spu->aff_list);
- last_spu = spu;
- break;
- }
- }
-}
-
-static void init_aff_fw_vicinity(void)
-{
- int cbe;
-
- /* sets has_mem_affinity for each spu, as long as the
- * spu->aff_list list, linking each spu to its neighbors
- */
- for (cbe = 0; cbe < MAX_NUMNODES; cbe++)
- init_aff_fw_vicinity_node(cbe);
-}
-
static int __init init_spu_base(void)
{
int i, ret = 0;
@@ -811,13 +678,7 @@ static int __init init_spu_base(void)
mutex_unlock(&spu_full_list_mutex);
spu_add_sysdev_attr(&attr_stat);
- if (of_has_vicinity()) {
- init_aff_fw_vicinity();
- } else {
- long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
- init_aff_QS20_harcoded();
- }
+ spu_init_affinity();
return 0;
--- a/arch/powerpc/platforms/cell/spu_manage.c
+++ b/arch/powerpc/platforms/cell/spu_manage.c
@@ -361,8 +361,171 @@ static int of_destroy_spu(struct spu *sp
return 0;
}
+/* Hardcoded affinity idxs for qs20 */
+#define QS20_SPES_PER_BE 8
+static int qs20_reg_idxs[QS20_SPES_PER_BE] = { 0, 2, 4, 6, 7, 5, 3, 1 };
+static int qs20_reg_memory[QS20_SPES_PER_BE] = { 1, 1, 0, 0, 0, 0, 0, 0 };
+
+static struct spu *spu_lookup_reg(int node, u32 reg)
+{
+ struct spu *spu;
+ u32 *spu_reg;
+
+ list_for_each_entry(spu, &cbe_spu_info[node].spus, cbe_list) {
+ spu_reg = (u32*)of_get_property(spu_devnode(spu), "reg", NULL);
+ if (*spu_reg == reg)
+ return spu;
+ }
+ return NULL;
+}
+
+static void init_affinity_qs20_harcoded(void)
+{
+ int node, i;
+ struct spu *last_spu, *spu;
+ u32 reg;
+
+ for (node = 0; node < MAX_NUMNODES; node++) {
+ last_spu = NULL;
+ for (i = 0; i < QS20_SPES_PER_BE; i++) {
+ reg = qs20_reg_idxs[i];
+ spu = spu_lookup_reg(node, reg);
+ if (!spu)
+ continue;
+ spu->has_mem_affinity = qs20_reg_memory[reg];
+ if (last_spu)
+ list_add_tail(&spu->aff_list,
+ &last_spu->aff_list);
+ last_spu = spu;
+ }
+ }
+}
+
+static int of_has_vicinity(void)
+{
+ struct spu* spu;
+
+ spu = list_first_entry(&cbe_spu_info[0].spus, struct spu, cbe_list);
+ return of_find_property(spu_devnode(spu), "vicinity", NULL) != NULL;
+}
+
+static struct spu *devnode_spu(int cbe, struct device_node *dn)
+{
+ struct spu *spu;
+
+ list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list)
+ if (spu_devnode(spu) == dn)
+ return spu;
+ return NULL;
+}
+
+static struct spu *
+neighbour_spu(int cbe, struct device_node *target, struct device_node *avoid)
+{
+ struct spu *spu;
+ struct device_node *spu_dn;
+ const phandle *vic_handles;
+ int lenp, i;
+
+ list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list) {
+ spu_dn = spu_devnode(spu);
+ if (spu_dn == avoid)
+ continue;
+ vic_handles = of_get_property(spu_dn, "vicinity", &lenp);
+ for (i=0; i < (lenp / sizeof(phandle)); i++) {
+ if (vic_handles[i] == target->linux_phandle)
+ return spu;
+ }
+ }
+ return NULL;
+}
+
+static void init_affinity_node(int cbe)
+{
+ struct spu *spu, *last_spu;
+ struct device_node *vic_dn, *last_spu_dn;
+ phandle avoid_ph;
+ const phandle *vic_handles;
+ const char *name;
+ int lenp, i, added;
+
+ last_spu = list_first_entry(&cbe_spu_info[cbe].spus, struct spu,
+ cbe_list);
+ avoid_ph = 0;
+ for (added = 1; added < cbe_spu_info[cbe].n_spus; added++) {
+ last_spu_dn = spu_devnode(last_spu);
+ vic_handles = of_get_property(last_spu_dn, "vicinity", &lenp);
+
+ /*
+ * Walk through each phandle in vicinity property of the spu
+ * (tipically two vicinity phandles per spe node)
+ */
+ for (i = 0; i < (lenp / sizeof(phandle)); i++) {
+ if (vic_handles[i] == avoid_ph)
+ continue;
+
+ vic_dn = of_find_node_by_phandle(vic_handles[i]);
+ if (!vic_dn)
+ continue;
+
+ /* a neighbour might be spe, mic-tm, or bif0 */
+ name = of_get_property(vic_dn, "name", NULL);
+ if (!name)
+ continue;
+
+ if (strcmp(name, "spe") == 0) {
+ spu = devnode_spu(cbe, vic_dn);
+ avoid_ph = last_spu_dn->linux_phandle;
+ } else {
+ /*
+ * "mic-tm" and "bif0" nodes do not have
+ * vicinity property. So we need to find the
+ * spe which has vic_dn as neighbour, but
+ * skipping the one we came from (last_spu_dn)
+ */
+ spu = neighbour_spu(cbe, vic_dn, last_spu_dn);
+ if (!spu)
+ continue;
+ if (!strcmp(name, "mic-tm")) {
+ last_spu->has_mem_affinity = 1;
+ spu->has_mem_affinity = 1;
+ }
+ avoid_ph = vic_dn->linux_phandle;
+ }
+
+ list_add_tail(&spu->aff_list, &last_spu->aff_list);
+ last_spu = spu;
+ break;
+ }
+ }
+}
+
+static void init_affinity_fw(void)
+{
+ int cbe;
+
+ for (cbe = 0; cbe < MAX_NUMNODES; cbe++)
+ init_affinity_node(cbe);
+}
+
+static int __init init_affinity(void)
+{
+ if (of_has_vicinity()) {
+ init_affinity_fw();
+ } else {
+ long root = of_get_flat_dt_root();
+ if (of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
+ init_affinity_qs20_harcoded();
+ else
+ printk("No affinity configuration found");
+ }
+
+ return 0;
+}
+
const struct spu_management_ops spu_management_of_ops = {
.enumerate_spus = of_enumerate_spus,
.create_spu = of_create_spu,
.destroy_spu = of_destroy_spu,
+ .init_affinity = init_affinity,
};
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -414,10 +414,16 @@ static int __init ps3_enumerate_spus(int
return num_resource_id;
}
+static int ps3_init_affinity(void)
+{
+ return 0;
+}
+
const struct spu_management_ops spu_management_ps3_ops = {
.enumerate_spus = ps3_enumerate_spus,
.create_spu = ps3_create_spu,
.destroy_spu = ps3_destroy_spu,
+ .init_affinity = ps3_init_affinity,
};
/* spu_priv1_ops */
--- a/include/asm-powerpc/spu_priv1.h
+++ b/include/asm-powerpc/spu_priv1.h
@@ -178,6 +178,7 @@ struct spu_management_ops {
int (*enumerate_spus)(int (*fn)(void *data));
int (*create_spu)(struct spu *spu, void *data);
int (*destroy_spu)(struct spu *spu);
+ int (*init_affinity)(void);
};
extern const struct spu_management_ops* spu_management_ops;
@@ -200,6 +201,12 @@ spu_destroy_spu (struct spu *spu)
return spu_management_ops->destroy_spu(spu);
}
+static inline int
+spu_init_affinity (void)
+{
+ return spu_management_ops->init_affinity();
+}
+
/*
* The declarations folowing are put here for convenience
* and only intended to be used by the platform setup code.
^ permalink raw reply
* Trying to use Device Tree...and getting continuous interrupts from attached 88e1145
From: Morrison, Tom @ 2007-08-03 22:54 UTC (permalink / raw)
To: linuxppc-dev
All,
Connected to eth1 (etsec2) of my mpc8548 cpu is a 88E1145 and I=20
am trying to get the core functionality running with the device tree
paradigm - I know the sense of the 88E1145 is active-low for my=20
mpc8548 board and have it working with an older 2.6.11++ kernel. =20
I built this new kernel with the marvell driver - it seemingly=20
does all the same things we did in the 2.6.11 kernel in separate=20
spots...
Here is the appropriate parts of my device tree for this part of the
core...
>> mdio@24520 {
>> #address-cells =3D <1>;
>> #size-cells =3D <0>;
>> device_type =3D "mdio";
>> compatible =3D "gianfar";=09
>> reg =3D <24520 20>;
>> phy1: ethernet-phy@1 {
>> interrupt-parent =3D <&mpic>;
>> interrupts =3D <37 1>;
>> reg =3D <11>;
>> device_type =3D "ethernet-phy";
>> };
>> };=09
>> ethernet@25000 {
>> #address-cells =3D <1>;
>> #size-cells =3D <0>;
>> device_type =3D "network";
>> model =3D "eTSEC";
>> compatible =3D "gianfar";
>> reg =3D <25000 1000>;
>> local-mac-address =3D [ 00 00 00 00 00 00 ];
>> interrupts =3D <23 2 24 2 28 2>;
>> interrupt-parent =3D <&mpic>;
>> phy-handle =3D <&phy1>;
>> };
>> mpic: pic@40000 {
>> clock-frequency =3D <0>;
>> interrupt-controller;
>> #address-cells =3D <0>;
>> #interrupt-cells =3D <2>;
>> reg =3D <40000 40000>;
>> built-in;
>> compatible =3D "chrp,open-pic";
>> device_type =3D "open-pic";
>> big-endian;
>> };
The device tree seems to be parsed OK:
>> of_irq_map_one: dev=3D/soc8548@e0000000/mdio@24520/ethernet-phy@1,
index=3D0
>> intsize=3D2 intlen=3D2
>> of_irq_map_raw: =
par=3D/soc8548@e0000000/pic@40000,intspec=3D[0x00000037
>> 0x00000001...],ointsize=3D2
>> of_irq_map_raw: ipar=3D/soc8548@e0000000/pic@40000, size=3D2
>> mpic: xlate (2 cells: 0x00000037 0x00000001) to line 0x37 sense 0x8
Now, that looks OK! Those are what I would expect. And when the=20
mdio/phy are probed, configured, and the 88E1145 interrupt (EXT7=20
(0x37H)) is enabled, the interrupt never (seemingly) gets cleared,
and basically hangs the entire box up and eventually it panics!
I don't even have an external phy(SFP) connected to this 88e1148 phy..
I am at a lost - is there something I am missing in device tree?=20
Help mr. wizard (Kumar?)...
Tom
^ permalink raw reply
* Re: BusyBox passwd requires root privileges
From: Scott Wood @ 2007-08-03 21:55 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <11991239.post@talk.nabble.com>
khollan wrote:
>
>
> Scott Wood-2 wrote:
>
>>
>>passwd needs to be setuid root.
>>
>>
>
> How do you do that?
Make sure it's owned by root, and chmod 4755 the binary. I'm not sure
how to go about telling busybox to drop suid when invoked as something
else. It'd probably be better to build two busyboxes, one with all suid
commands and the other with the rest.
-Scott
^ permalink raw reply
* RE: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Yoder Stuart-B08248 @ 2007-08-03 21:55 UTC (permalink / raw)
To: Loeliger Jon-LOELIGER, David Gibson; +Cc: linuxppc-dev, Paul Mackerras
> > > > + MPIC: interrupt-controller@d {
> > > > + device_type =3D "open-pic";
> > > >=20
> > > > device_type =3D "interrupt-controller".
> >=20
> > Not according to the binding in booting-without-of.txt
>=20
> My understanding here, though possibly flawed, is that the current
> implementation has "open-pic" but _should_ have "interrupt-controller"
> as that is the officially correct name.
>=20
> I _think_ this means we need a transitional period where we update
> the code to look for "interrupt-controller", and obsoletedly, looks
> for the "open-pic", while we transition to the new, correct name.
"open-pic" is the correct value for the device_type property.
See the binding at:
http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps
That is the definition for open pic interrupt controllers (AFAIK).
I am not aware of any official binding with "interrupt-controller"=20
as the device_type.
However, the interrupt mapping spec says that all interrupt
controller (regardless of device_type) must have a=20
property named "interrupt-controller" to identify
the device node as an interrupt controller and root of
a interrupt tree.
See: http://playground.sun.com/1275/practice/imap/imap0_9d.html
Stuart
^ permalink raw reply
* Re: Page faults blowing up ... [was Re: [PATCH] Fix special PTE code for secondary hash bucket
From: Mike Strosaker @ 2007-08-03 21:54 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras, benh
In-Reply-To: <20070803193258.GA9613@austin.ibm.com>
Linas Vepstas wrote:
> 3:mon> d c0000000077b21e0
> c0000000077b21e0 e00000008004b224 0674100900000080 |.......$.t......|
>
> Well, howdy doody, there's the value that should have been in r3 ....
>
> c0000000077b21f0 c4008e0000000000 0000000049424d00 |............IBM.|
>
> IBM ???
>
> c0000000077b2200 5048003006000000 0000000000000000 |PH.0............|
> c0000000077b2210 0000000000000000 4800000300000000 |........H.......|
> c0000000077b2220 0000000000000000 0000000000000000 |................|
> c0000000077b2230 5548001806000000 1000400000000000 |UH........@.....|
> c0000000077b2240 0000200000000000 4d43002806000000 |.. .....MC.(....|
> c0000000077b2250 0000000000000001 00c3000000000000 |................|
> c0000000077b2260 e00000008004b224 0000000000000000 |.......$........|
> c0000000077b2270 d0000000000d32c0 8000000000101032 |......2........2|
>
> hey .. wait .. d0000000000d32c0 is the faulting adddress; whats it doing here ???
> ... and 8000000000101032 is the value of the MSR ... why is that here ??
That looks like part of an RTAS event. PH indicates a "Main A" section, UH a
"Main B" section, and, probably of most interest to you, MC indicates a "Failing
Memory Address" section. The "Error and Event Notification" chapter of the PAPR
will be useful here. You can use rtas_dump (in either powerpc-utils or
ppc64-utils, depending on the distro) to decode the event in its entirety. A
quick hand-decode of the MC section yields (might be wrong, you'll want to
double-check):
Unrecoverable memory error (UE); transient UE, 64-bit effective address provided
by the log (located at c0000000077b2260), 64-bit logical address of logical page
is not provided by the log; error detected by load/store unit of the processor.
Mike
^ permalink raw reply
* Re: BusyBox passwd requires root privileges
From: khollan @ 2007-08-03 21:39 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46B395B5.1040009@freescale.com>
Scott Wood-2 wrote:
>
>
> passwd needs to be setuid root.
>
>
How do you do that?
--
View this message in context: http://www.nabble.com/BusyBox-passwd-requires-root-privileges-tf4214675.html#a11991239
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] lro: myri10ge example how to use LRO
From: Andrew Gallatin @ 2007-08-03 21:00 UTC (permalink / raw)
To: Kok, Auke
Cc: tklein, jeff, themann, netdev, linux-kernel, linuxppc-dev, raisch,
meder, stefan.roscher, davem
In-Reply-To: <46B39063.6070301@intel.com>
Kok, Auke wrote:
> Andrew Gallatin wrote:
>> To follow up on Jan-Bernd Themann's LRO patch earlier today,
>> this patch shows how the generic LRO interface can be used for
>> page based drivers.
>>
>> Again, many thanks to Jan-Bernd Themann for leading this effort.
>>
>> Drew
>>
>> Singed off by: Andrew Gallatin <gallatin@myri.com>
>>
>
>
> please take a look at my lro patch for ethtool and see if it works for
> you, instead of adding another generic module parameter that doesn't
> need to be there.
That looks very nice, and will indeed work for me.
Thanks,
Drew
^ permalink raw reply
* Re: BusyBox passwd requires root privileges
From: Scott Wood @ 2007-08-03 20:53 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <11990563.post@talk.nabble.com>
khollan wrote:
> I log on as a user and I want to use passwd to change that users password but
> it gives me the
> passwd: applet requires root privileges!
> I can login as root and change all user passwords, but I want individual
> owners to be able to update their passwords. Any ideas?
passwd needs to be setuid root.
-Scott
^ permalink raw reply
* Re: [PATCH v3] Fix ibmvscsi client for multiplatform iSeries+pSeries kernel.
From: Brian King @ 2007-08-03 20:51 UTC (permalink / raw)
To: David Woodhouse; +Cc: Stephen Rothwell, Paul Mackerras, linuxppc-dev
In-Reply-To: <1185882169.3083.93.camel@pmac.infradead.org>
Acked by: Brian King <brking@linux.vnet.ibm.com>
David Woodhouse wrote:
> If you build a multiplatform kernel for iSeries and pSeries, with
> ibmvscsic support, the resulting client doesn't work on iSeries.
>
> This patch should fix that, using the appropriate low-level operations
> for the machine detected at runtime.
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
>
> ---
> This third version of the patch is updated to apply to Linus' current
> git tree following the recent ibmvscsi updates.
>
> diff --git a/drivers/scsi/ibmvscsi/rpa_vscsi.c b/drivers/scsi/ibmvscsi/rpa_vscsi.c
> index 9c14e78..1821461 100644
> --- a/drivers/scsi/ibmvscsi/rpa_vscsi.c
> +++ b/drivers/scsi/ibmvscsi/rpa_vscsi.c
> @@ -42,14 +42,14 @@ static unsigned int partition_number = -1;
> * Routines for managing the command/response queue
> */
> /**
> - * ibmvscsi_handle_event: - Interrupt handler for crq events
> + * rpavscsi_handle_event: - Interrupt handler for crq events
> * @irq: number of irq to handle, not used
> * @dev_instance: ibmvscsi_host_data of host that received interrupt
> *
> * Disables interrupts and schedules srp_task
> * Always returns IRQ_HANDLED
> */
> -static irqreturn_t ibmvscsi_handle_event(int irq, void *dev_instance)
> +static irqreturn_t rpavscsi_handle_event(int irq, void *dev_instance)
> {
> struct ibmvscsi_host_data *hostdata =
> (struct ibmvscsi_host_data *)dev_instance;
> @@ -66,9 +66,9 @@ static irqreturn_t ibmvscsi_handle_event(int irq, void *dev_instance)
> * Frees irq, deallocates a page for messages, unmaps dma, and unregisters
> * the crq with the hypervisor.
> */
> -void ibmvscsi_release_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata,
> - int max_requests)
> +static void rpavscsi_release_crq_queue(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata,
> + int max_requests)
> {
> long rc;
> struct vio_dev *vdev = to_vio_dev(hostdata->dev);
> @@ -108,12 +108,13 @@ static struct viosrp_crq *crq_queue_next_crq(struct crq_queue *queue)
> }
>
> /**
> - * ibmvscsi_send_crq: - Send a CRQ
> + * rpavscsi_send_crq: - Send a CRQ
> * @hostdata: the adapter
> * @word1: the first 64 bits of the data
> * @word2: the second 64 bits of the data
> */
> -int ibmvscsi_send_crq(struct ibmvscsi_host_data *hostdata, u64 word1, u64 word2)
> +static int rpavscsi_send_crq(struct ibmvscsi_host_data *hostdata,
> + u64 word1, u64 word2)
> {
> struct vio_dev *vdev = to_vio_dev(hostdata->dev);
>
> @@ -121,10 +122,10 @@ int ibmvscsi_send_crq(struct ibmvscsi_host_data *hostdata, u64 word1, u64 word2)
> }
>
> /**
> - * ibmvscsi_task: - Process srps asynchronously
> + * rpavscsi_task: - Process srps asynchronously
> * @data: ibmvscsi_host_data of host
> */
> -static void ibmvscsi_task(void *data)
> +static void rpavscsi_task(void *data)
> {
> struct ibmvscsi_host_data *hostdata = (struct ibmvscsi_host_data *)data;
> struct vio_dev *vdev = to_vio_dev(hostdata->dev);
> @@ -190,6 +191,42 @@ static void set_adapter_info(struct ibmvscsi_host_data *hostdata)
> }
>
> /**
> + * reset_crq_queue: - resets a crq after a failure
> + * @queue: crq_queue to initialize and register
> + * @hostdata: ibmvscsi_host_data of host
> + *
> + */
> +static int rpavscsi_reset_crq_queue(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata)
> +{
> + int rc;
> + struct vio_dev *vdev = to_vio_dev(hostdata->dev);
> +
> + /* Close the CRQ */
> + do {
> + rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
> + } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
> +
> + /* Clean out the queue */
> + memset(queue->msgs, 0x00, PAGE_SIZE);
> + queue->cur = 0;
> +
> + set_adapter_info(hostdata);
> +
> + /* And re-open it again */
> + rc = plpar_hcall_norets(H_REG_CRQ,
> + vdev->unit_address,
> + queue->msg_token, PAGE_SIZE);
> + if (rc == 2) {
> + /* Adapter is good, but other end is not ready */
> + dev_warn(hostdata->dev, "Partner adapter not ready\n");
> + } else if (rc != 0) {
> + dev_warn(hostdata->dev, "couldn't register crq--rc 0x%x\n", rc);
> + }
> + return rc;
> +}
> +
> +/**
> * initialize_crq_queue: - Initializes and registers CRQ with hypervisor
> * @queue: crq_queue to initialize and register
> * @hostdata: ibmvscsi_host_data of host
> @@ -198,9 +235,9 @@ static void set_adapter_info(struct ibmvscsi_host_data *hostdata)
> * the crq with the hypervisor.
> * Returns zero on success.
> */
> -int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata,
> - int max_requests)
> +static int rpavscsi_init_crq_queue(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata,
> + int max_requests)
> {
> int rc;
> int retrc;
> @@ -227,7 +264,7 @@ int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> queue->msg_token, PAGE_SIZE);
> if (rc == H_RESOURCE)
> /* maybe kexecing and resource is busy. try a reset */
> - rc = ibmvscsi_reset_crq_queue(queue,
> + rc = rpavscsi_reset_crq_queue(queue,
> hostdata);
>
> if (rc == 2) {
> @@ -240,7 +277,7 @@ int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> }
>
> if (request_irq(vdev->irq,
> - ibmvscsi_handle_event,
> + rpavscsi_handle_event,
> 0, "ibmvscsi", (void *)hostdata) != 0) {
> dev_err(hostdata->dev, "couldn't register irq 0x%x\n",
> vdev->irq);
> @@ -256,7 +293,7 @@ int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> queue->cur = 0;
> spin_lock_init(&queue->lock);
>
> - tasklet_init(&hostdata->srp_task, (void *)ibmvscsi_task,
> + tasklet_init(&hostdata->srp_task, (void *)rpavscsi_task,
> (unsigned long)hostdata);
>
> return retrc;
> @@ -281,8 +318,8 @@ int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> * @hostdata: ibmvscsi_host_data of host
> *
> */
> -int ibmvscsi_reenable_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata)
> +static int rpavscsi_reenable_crq_queue(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata)
> {
> int rc;
> struct vio_dev *vdev = to_vio_dev(hostdata->dev);
> @@ -297,38 +334,10 @@ int ibmvscsi_reenable_crq_queue(struct crq_queue *queue,
> return rc;
> }
>
> -/**
> - * reset_crq_queue: - resets a crq after a failure
> - * @queue: crq_queue to initialize and register
> - * @hostdata: ibmvscsi_host_data of host
> - *
> - */
> -int ibmvscsi_reset_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata)
> -{
> - int rc;
> - struct vio_dev *vdev = to_vio_dev(hostdata->dev);
> -
> - /* Close the CRQ */
> - do {
> - rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
> - } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
> -
> - /* Clean out the queue */
> - memset(queue->msgs, 0x00, PAGE_SIZE);
> - queue->cur = 0;
> -
> - set_adapter_info(hostdata);
> -
> - /* And re-open it again */
> - rc = plpar_hcall_norets(H_REG_CRQ,
> - vdev->unit_address,
> - queue->msg_token, PAGE_SIZE);
> - if (rc == 2) {
> - /* Adapter is good, but other end is not ready */
> - dev_warn(hostdata->dev, "Partner adapter not ready\n");
> - } else if (rc != 0) {
> - dev_warn(hostdata->dev, "couldn't register crq--rc 0x%x\n", rc);
> - }
> - return rc;
> -}
> +struct ibmvscsi_ops rpavscsi_ops = {
> + .init_crq_queue = rpavscsi_init_crq_queue,
> + .release_crq_queue = rpavscsi_release_crq_queue,
> + .reset_crq_queue = rpavscsi_reset_crq_queue,
> + .reenable_crq_queue = rpavscsi_reenable_crq_queue,
> + .send_crq = rpavscsi_send_crq,
> +};
> diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
> index 5870866..ed9b675 100644
> --- a/drivers/scsi/ibmvscsi/ibmvscsi.c
> +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
> @@ -70,6 +70,7 @@
> #include <linux/moduleparam.h>
> #include <linux/dma-mapping.h>
> #include <linux/delay.h>
> +#include <asm/firmware.h>
> #include <asm/vio.h>
> #include <scsi/scsi.h>
> #include <scsi/scsi_cmnd.h>
> @@ -89,6 +90,8 @@ static int max_requests = IBMVSCSI_MAX_REQUESTS_DEFAULT;
>
> #define IBMVSCSI_VERSION "1.5.8"
>
> +static struct ibmvscsi_ops *ibmvscsi_ops;
> +
> MODULE_DESCRIPTION("IBM Virtual SCSI");
> MODULE_AUTHOR("Dave Boutcher");
> MODULE_LICENSE("GPL");
> @@ -512,8 +515,8 @@ static void ibmvscsi_reset_host(struct ibmvscsi_host_data *hostdata)
> atomic_set(&hostdata->request_limit, 0);
>
> purge_requests(hostdata, DID_ERROR);
> - if ((ibmvscsi_reset_crq_queue(&hostdata->queue, hostdata)) ||
> - (ibmvscsi_send_crq(hostdata, 0xC001000000000000LL, 0)) ||
> + if ((ibmvscsi_ops->reset_crq_queue(&hostdata->queue, hostdata)) ||
> + (ibmvscsi_ops->send_crq(hostdata, 0xC001000000000000LL, 0)) ||
> (vio_enable_interrupts(to_vio_dev(hostdata->dev)))) {
> atomic_set(&hostdata->request_limit, -1);
> dev_err(hostdata->dev, "error after reset\n");
> @@ -618,7 +621,7 @@ static int ibmvscsi_send_srp_event(struct srp_event_struct *evt_struct,
> }
>
> if ((rc =
> - ibmvscsi_send_crq(hostdata, crq_as_u64[0], crq_as_u64[1])) != 0) {
> + ibmvscsi_ops->send_crq(hostdata, crq_as_u64[0], crq_as_u64[1])) != 0) {
> list_del(&evt_struct->list);
> del_timer(&evt_struct->timer);
>
> @@ -1222,8 +1225,8 @@ void ibmvscsi_handle_crq(struct viosrp_crq *crq,
> case 0x01: /* Initialization message */
> dev_info(hostdata->dev, "partner initialized\n");
> /* Send back a response */
> - if ((rc = ibmvscsi_send_crq(hostdata,
> - 0xC002000000000000LL, 0)) == 0) {
> + if ((rc = ibmvscsi_ops->send_crq(hostdata,
> + 0xC002000000000000LL, 0)) == 0) {
> /* Now login */
> send_srp_login(hostdata);
> } else {
> @@ -1248,10 +1251,10 @@ void ibmvscsi_handle_crq(struct viosrp_crq *crq,
> /* We need to re-setup the interpartition connection */
> dev_info(hostdata->dev, "Re-enabling adapter!\n");
> purge_requests(hostdata, DID_REQUEUE);
> - if ((ibmvscsi_reenable_crq_queue(&hostdata->queue,
> - hostdata)) ||
> - (ibmvscsi_send_crq(hostdata,
> - 0xC001000000000000LL, 0))) {
> + if ((ibmvscsi_ops->reenable_crq_queue(&hostdata->queue,
> + hostdata)) ||
> + (ibmvscsi_ops->send_crq(hostdata,
> + 0xC001000000000000LL, 0))) {
> atomic_set(&hostdata->request_limit,
> -1);
> dev_err(hostdata->dev, "error after enable\n");
> @@ -1261,10 +1264,10 @@ void ibmvscsi_handle_crq(struct viosrp_crq *crq,
> crq->format);
>
> purge_requests(hostdata, DID_ERROR);
> - if ((ibmvscsi_reset_crq_queue(&hostdata->queue,
> - hostdata)) ||
> - (ibmvscsi_send_crq(hostdata,
> - 0xC001000000000000LL, 0))) {
> + if ((ibmvscsi_ops->reset_crq_queue(&hostdata->queue,
> + hostdata)) ||
> + (ibmvscsi_ops->send_crq(hostdata,
> + 0xC001000000000000LL, 0))) {
> atomic_set(&hostdata->request_limit,
> -1);
> dev_err(hostdata->dev, "error after reset\n");
> @@ -1590,7 +1593,7 @@ static int ibmvscsi_probe(struct vio_dev *vdev, const struct vio_device_id *id)
> atomic_set(&hostdata->request_limit, -1);
> hostdata->host->max_sectors = 32 * 8; /* default max I/O 32 pages */
>
> - rc = ibmvscsi_init_crq_queue(&hostdata->queue, hostdata, max_requests);
> + rc = ibmvscsi_ops->init_crq_queue(&hostdata->queue, hostdata, max_requests);
> if (rc != 0 && rc != H_RESOURCE) {
> dev_err(&vdev->dev, "couldn't initialize crq. rc=%d\n", rc);
> goto init_crq_failed;
> @@ -1611,7 +1614,7 @@ static int ibmvscsi_probe(struct vio_dev *vdev, const struct vio_device_id *id)
> * to fail if the other end is not acive. In that case we don't
> * want to scan
> */
> - if (ibmvscsi_send_crq(hostdata, 0xC001000000000000LL, 0) == 0
> + if (ibmvscsi_ops->send_crq(hostdata, 0xC001000000000000LL, 0) == 0
> || rc == H_RESOURCE) {
> /*
> * Wait around max init_timeout secs for the adapter to finish
> @@ -1637,7 +1640,7 @@ static int ibmvscsi_probe(struct vio_dev *vdev, const struct vio_device_id *id)
> add_host_failed:
> release_event_pool(&hostdata->pool, hostdata);
> init_pool_failed:
> - ibmvscsi_release_crq_queue(&hostdata->queue, hostdata, max_requests);
> + ibmvscsi_ops->release_crq_queue(&hostdata->queue, hostdata, max_requests);
> init_crq_failed:
> scsi_host_put(host);
> scsi_host_alloc_failed:
> @@ -1648,8 +1651,8 @@ static int ibmvscsi_remove(struct vio_dev *vdev)
> {
> struct ibmvscsi_host_data *hostdata = vdev->dev.driver_data;
> release_event_pool(&hostdata->pool, hostdata);
> - ibmvscsi_release_crq_queue(&hostdata->queue, hostdata,
> - max_requests);
> + ibmvscsi_ops->release_crq_queue(&hostdata->queue, hostdata,
> + max_requests);
>
> scsi_remove_host(hostdata->host);
> scsi_host_put(hostdata->host);
> @@ -1679,6 +1682,13 @@ static struct vio_driver ibmvscsi_driver = {
>
> int __init ibmvscsi_module_init(void)
> {
> + if (firmware_has_feature(FW_FEATURE_ISERIES))
> + ibmvscsi_ops = &iseriesvscsi_ops;
> + else if (firmware_has_feature(FW_FEATURE_VIO))
> + ibmvscsi_ops = &rpavscsi_ops;
> + else
> + return -ENODEV;
> +
> return vio_register_driver(&ibmvscsi_driver);
> }
>
> diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.h b/drivers/scsi/ibmvscsi/ibmvscsi.h
> index b19c2e2..46e850e 100644
> --- a/drivers/scsi/ibmvscsi/ibmvscsi.h
> +++ b/drivers/scsi/ibmvscsi/ibmvscsi.h
> @@ -98,21 +98,25 @@ struct ibmvscsi_host_data {
> };
>
> /* routines for managing a command/response queue */
> -int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata,
> - int max_requests);
> -void ibmvscsi_release_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata,
> - int max_requests);
> -int ibmvscsi_reset_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata);
> -
> -int ibmvscsi_reenable_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata);
> -
> void ibmvscsi_handle_crq(struct viosrp_crq *crq,
> struct ibmvscsi_host_data *hostdata);
> -int ibmvscsi_send_crq(struct ibmvscsi_host_data *hostdata,
> - u64 word1, u64 word2);
> +
> +struct ibmvscsi_ops {
> + int (*init_crq_queue)(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata,
> + int max_requests);
> + void (*release_crq_queue)(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata,
> + int max_requests);
> + int (*reset_crq_queue)(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata);
> + int (*reenable_crq_queue)(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata);
> + int (*send_crq)(struct ibmvscsi_host_data *hostdata,
> + u64 word1, u64 word2);
> +};
> +
> +extern struct ibmvscsi_ops iseriesvscsi_ops;
> +extern struct ibmvscsi_ops rpavscsi_ops;
>
> #endif /* IBMVSCSI_H */
> diff --git a/drivers/scsi/ibmvscsi/iseries_vscsi.c b/drivers/scsi/ibmvscsi/iseries_vscsi.c
> index 6aeb5f0..0775fde 100644
> --- a/drivers/scsi/ibmvscsi/iseries_vscsi.c
> +++ b/drivers/scsi/ibmvscsi/iseries_vscsi.c
> @@ -53,7 +53,7 @@ struct srp_lp_event {
> /**
> * standard interface for handling logical partition events.
> */
> -static void ibmvscsi_handle_event(struct HvLpEvent *lpevt)
> +static void iseriesvscsi_handle_event(struct HvLpEvent *lpevt)
> {
> struct srp_lp_event *evt = (struct srp_lp_event *)lpevt;
>
> @@ -74,9 +74,9 @@ static void ibmvscsi_handle_event(struct HvLpEvent *lpevt)
> /* ------------------------------------------------------------
> * Routines for driver initialization
> */
> -int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata,
> - int max_requests)
> +static int iseriesvscsi_init_crq_queue(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata,
> + int max_requests)
> {
> int rc;
>
> @@ -88,7 +88,7 @@ int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> goto viopath_open_failed;
> }
>
> - rc = vio_setHandler(viomajorsubtype_scsi, ibmvscsi_handle_event);
> + rc = vio_setHandler(viomajorsubtype_scsi, iseriesvscsi_handle_event);
> if (rc < 0) {
> printk("vio_setHandler failed with rc %d in open_event_path\n",
> rc);
> @@ -102,9 +102,9 @@ int ibmvscsi_init_crq_queue(struct crq_queue *queue,
> return -1;
> }
>
> -void ibmvscsi_release_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata,
> - int max_requests)
> +static void iseriesvscsi_release_crq_queue(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata,
> + int max_requests)
> {
> vio_clearHandler(viomajorsubtype_scsi);
> viopath_close(viopath_hostLp, viomajorsubtype_scsi, max_requests);
> @@ -117,8 +117,8 @@ void ibmvscsi_release_crq_queue(struct crq_queue *queue,
> *
> * no-op for iSeries
> */
> -int ibmvscsi_reset_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata)
> +static int iseriesvscsi_reset_crq_queue(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata)
> {
> return 0;
> }
> @@ -130,19 +130,20 @@ int ibmvscsi_reset_crq_queue(struct crq_queue *queue,
> *
> * no-op for iSeries
> */
> -int ibmvscsi_reenable_crq_queue(struct crq_queue *queue,
> - struct ibmvscsi_host_data *hostdata)
> +static int iseriesvscsi_reenable_crq_queue(struct crq_queue *queue,
> + struct ibmvscsi_host_data *hostdata)
> {
> return 0;
> }
>
> /**
> - * ibmvscsi_send_crq: - Send a CRQ
> + * iseriesvscsi_send_crq: - Send a CRQ
> * @hostdata: the adapter
> * @word1: the first 64 bits of the data
> * @word2: the second 64 bits of the data
> */
> -int ibmvscsi_send_crq(struct ibmvscsi_host_data *hostdata, u64 word1, u64 word2)
> +static int iseriesvscsi_send_crq(struct ibmvscsi_host_data *hostdata,
> + u64 word1, u64 word2)
> {
> single_host_data = hostdata;
> return HvCallEvent_signalLpEventFast(viopath_hostLp,
> @@ -156,3 +157,11 @@ int ibmvscsi_send_crq(struct ibmvscsi_host_data *hostdata, u64 word1, u64 word2)
> VIOVERSION << 16, word1, word2, 0,
> 0);
> }
> +
> +struct ibmvscsi_ops iseriesvscsi_ops = {
> + .init_crq_queue = iseriesvscsi_init_crq_queue,
> + .release_crq_queue = iseriesvscsi_release_crq_queue,
> + .reset_crq_queue = iseriesvscsi_reset_crq_queue,
> + .reenable_crq_queue = iseriesvscsi_reenable_crq_queue,
> + .send_crq = iseriesvscsi_send_crq,
> +};
> diff --git a/drivers/scsi/ibmvscsi/Makefile b/drivers/scsi/ibmvscsi/Makefile
> index f67d9ef..6ac0633 100644
> --- a/drivers/scsi/ibmvscsi/Makefile
> +++ b/drivers/scsi/ibmvscsi/Makefile
> @@ -1,9 +1,7 @@
> obj-$(CONFIG_SCSI_IBMVSCSI) += ibmvscsic.o
>
> ibmvscsic-y += ibmvscsi.o
> -ifndef CONFIG_PPC_PSERIES
> ibmvscsic-$(CONFIG_PPC_ISERIES) += iseries_vscsi.o
> -endif
> ibmvscsic-$(CONFIG_PPC_PSERIES) += rpa_vscsi.o
>
> obj-$(CONFIG_SCSI_IBMVSCSIS) += ibmvstgt.o
>
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox