Re: [patch] powerpc/ps3: Use hard coded values for LV1 device type
On Fri, 2009-02-06 at 18:42 -0800, Geoff Levand wrote:
Change the PS3 platform code to use hard coded numbers for its
LV1 device types.
The PS3 platform code was incorrectly using some scsi block
constants for the device type returned from the LV1 hypervisor.
Fixes build errors like these when CONFIG_BLOCK=n:
In file included from include/scsi/scsi.h:12,
from arch/powerpc/platforms/ps3/platform.h:25,
from arch/powerpc/platforms/ps3/setup.c:36:
include/scsi/scsi_cmnd.h:27:25: warning: BLK_MAX_CDB is not defined
include/scsi/scsi_cmnd.h:28:3: error: #error MAX_COMMAND_SIZE can not be
bigger than BLK_MAX_CDB
Signed-off-by: Geoff Levand geoffrey.lev...@am.sony.com
---
Ben,
Please send upstream for 2.6.29.
-Geoff
arch/powerpc/platforms/ps3/platform.h |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -22,8 +22,6 @@
#define _PS3_PLATFORM_H
#include linux/rtc.h
-#include scsi/scsi.h
-
#include asm/ps3.h
/* htab */
@@ -83,12 +81,12 @@ enum ps3_bus_type {
};
enum ps3_dev_type {
- PS3_DEV_TYPE_STOR_DISK = TYPE_DISK, /* 0 */
+ PS3_DEV_TYPE_STOR_DISK = 0, /* TYPE_DISK */
PS3_DEV_TYPE_SB_GELIC = 3,
PS3_DEV_TYPE_SB_USB = 4,
- PS3_DEV_TYPE_STOR_ROM = TYPE_ROM, /* 5 */
+ PS3_DEV_TYPE_STOR_ROM = 5, /* TYPE_ROM */
PS3_DEV_TYPE_SB_GPIO = 6,
- PS3_DEV_TYPE_STOR_FLASH = TYPE_RBC, /* 14 */
+ PS3_DEV_TYPE_STOR_FLASH = 14, /* TYPE_RBC */
This looks like you're just papering over the bug, by hardcoding the
same values that are in the scsi header. Or are they really independent,
in which case I'd say the comments are confusing.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ANN] Introducing new test branch in powerpc.git tree
On Fri, 2009-02-06 at 18:42 +0100, Michel Dänzer wrote: On Thu, 2009-02-05 at 15:58 -0500, Josh Boyer wrote: On Fri, Feb 06, 2009 at 07:56:22AM +1100, Benjamin Herrenschmidt wrote: Which begs the question of what master is for. So far, it's just been a mirror of next from what I can tell. Maybe it should just track Linus' tree? I've been wondering myself what to do with it ... I may just leave it to track linus indeed. Or maybe just delete it. I don't think you can delete it without hosing people who try to clone it. The branch to check out by git clone can be overridden via a special file in the .git directory in the shared repository. Unfortunately though, I don't remember what it's called... According to Julien Cristau of the Debian X Strike Force (none of the Git repos of which have a master branch), it should be .git/HEAD. Some experiments of mine seem to confirm this. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
On Sunday 08 February 2009, Paul Collins wrote: Paul Collins p...@burly.ondioline.org writes: Rafael J. Wysocki r...@sisk.pl writes: On Wednesday 21 January 2009, Paul Collins wrote: Got a couple of these on a PowerBook running 2.6.29-rc2 either during suspend or resume -- it's hard to tell. (The suspend message is timestamped in syslog with the time I resumed, so I guess it was buffered along with the subsequent Badness messages.) Please check if the patch from http://lkml.org/lkml/2009/1/13/144 fixes the problem for you. It does not fix the problem. I'm also getting this warning since 2.6.28.1, which incorporated commit 1c5745aa380efb6417b5681104b007c8612fb496 (sched_clock: prevent scd-clock from moving backwards, take #2) as commit e268dcdd404f4558cdd24c8ecede3e064df8fa33, this being the patch that introduced the WARN_ON(timekeeping_suspended) check. Hm, I thought the timekeeping suspend problem was fixed in this commit. Ingo? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC 0/11] FSL eSDHC support: second call for comments
On Fri, 6 Feb 2009 21:05:20 +0300 Anton Vorontsov avoront...@ru.mvista.com wrote: Hi all, There were only a few comments on the previous version. So, here is the second call for comments. Yeah sorry, haven't really had time for looking over your patches properly. See my first comments to relevant patches now though. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/11] sdhci: Add support for bus-specific IO memory accessors
On Fri, 6 Feb 2009 21:06:45 +0300
Anton Vorontsov avoront...@ru.mvista.com wrote:
Currently the SDHCI driver works with PCI accessors (write{l,b,w} and
read{l,b,w}).
With this patch drivers may change memory accessors, so that we can
support hosts with weird IO memory access requirments.
For example, in FSL eSDHC SDHCI hardware all registers are 32 bit
width, with big-endian addressing. That is, readb(0x2f) should turn
into readb(0x2c), and readw(0x2c) should be translated to
le16_to_cpu(readw(0x2e)).
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
I was hoping we wouldn't have to do a lot of magic in the accessors
since the spec is rather clear on the register interface. :/
Let's see if I've understood this correctly.
1. The CPU is big-endian but the register are little-endian (as the
spec requires). I was under the impression that the read*/write*
accessor handled any endian conversion between the bus and the cpu? How
do e.g. PCI work on Sparc?
2. Register access must be done 32 bits at a time. Now this is just
broken and might cause big problems as some registers cannot just be
read and written back to. OTOH you refer to readw() in your example,
not readl(). What's the deal here?
+static inline void sdhci_writel(struct sdhci_host *host, u32 val, int reg)
+{
+ host-writel(host, val, reg);
+}
Having to override these are worst case scenario as far as I'm
concerned, so I'd prefer something like:
if (!host-ops-writel)
writel(host-ioaddr + reg, val);
else
host-ops-writel(host, val, reg);
and maybe even a likely() up there.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 03/11] sdhci: Add type checking for IO memory accessors
On Fri, 6 Feb 2009 21:06:48 +0300 Anton Vorontsov avoront...@ru.mvista.com wrote: A new restricted integer type introduced: sdhci_reg_t. Header file now specifies registers via sdhci_reg() inline function. Only one place (not counting sdhci_def_*() accessors) need to cast a register back to an offset, i.e. sdhci_finish_command(). From now on sparse tool will warn about IO memory accessors misuses, for exampple: sdhci_writeb(host, SDHCI_TIMEOUT_CONTROL, count); CHECK sdhci.c sdhci.c:614:21: warning: incorrect type in argument 2 (different base types) sdhci.c:614:21:expected unsigned char [unsigned] [usertype] val sdhci.c:614:21:got restricted int sdhci.c:614:44: warning: incorrect type in argument 3 (different base types) sdhci.c:614:44:expected restricted int [usertype] reg sdhci.c:614:44:got unsigned char [unsigned] [assigned] [usertype] count Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- Is this really a problem? It's a lot of noise in the code and I can't really see this as a major issue, or even a minor one. :) Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/11] sdhci: Add support for card-detection polling
On Fri, 6 Feb 2009 21:06:50 +0300 Anton Vorontsov avoront...@ru.mvista.com wrote: This patch adds SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk. When specified, sdhci driver will set MMC_CAP_NEEDS_POLL MMC host capability, and won't enable card insert/remove interrupts. This is needed for hosts with unreliable card detection, such as FSL eSDHC. The original eSDHC driver was tring to debounce card-detection IRQs by reading present state and disabling particular interrupts. But with this debouncing scheme I noticed that sometimes we miss card insertion/removal events. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- I guess you need to fix the check at the start of the request function as well. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index b7a79a0..45c5f1f 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -162,6 +162,9 @@ static void sdhci_init(struct sdhci_host *host) SDHCI_INT_DMA_END | SDHCI_INT_DATA_END | SDHCI_INT_RESPONSE | SDHCI_INT_ADMA_ERROR; + if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + intmask = ~(SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT); + A matter of taste perhaps, but I think it would make more sense to not add them in the first place than to add and then remove them. Card detection interrupts should be handled separately anyway as they should not be enabled before mmc_add_host() returns and should be disabled before calling mmc_remove_host(). Patch welcome. ;) Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 07/11] sdhci: Add quirk to suppress PIO interrupts during DMA transfers
On Fri, 6 Feb 2009 21:06:55 +0300 Anton Vorontsov avoront...@ru.mvista.com wrote: Some hosts (that is, FSL eSDHC) throw PIO interrupts during DMA transfers, this causes tons of unneeded interrupts, and thus highly degraded speed. This patch adds SDHCI_QUIRK_PIO_IRQS_DURING_DMA quirk. When specified, the sdhci driver will disable PIO interrupts during DMA transfers. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- It's probably better to change the interrupt handling to only enable relevant interrupts instead of having everything on constantly. Too many quirks just makes the driver difficult to understand. -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/11] sdhci: Add support for hosts that don't specify clocks in the cap. register
On Fri, 6 Feb 2009 21:06:57 +0300 Anton Vorontsov avoront...@ru.mvista.com wrote: FSL eSDHC hosts don't provide clocks bits in the capabilities register, instead we're getting clocks values from the device tree. There is somewhat similar change[1] from Ben Dooks, the change adds callbacks for getting the clocks. But for eSDHC the callbacks are superfluous, since the clocks are static. [1] http://lkml.org/lkml/2008/12/2/157 Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- As I told Ben, I prefer if we stick to the standard as much as possible. So no external info unless the register is set to zero. And since we know the Samsung chip needs callbacks, we might as well add them here. It's not like this is a performance critical path. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 09/11] sdhci: Add set_clock callback
On Fri, 6 Feb 2009 21:06:59 +0300 Anton Vorontsov avoront...@ru.mvista.com wrote: FSL eSDHC hosts have incompatible register map to manage the SDCLK. This patch adds set_clock callback so that drivers could overwrite set_clock behaviour. Similar patch[1] was posted by Ben Dooks, though in Ben's version the callback is named change_clock, plus the patch has some unrelated bits that makes the patch difficult to reuse. [1] http://lkml.org/lkml/2008/12/2/160 Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- A set_clock() callback is reasonable as there might be a clock source that needs to be set up, but completely overriding the normal routine (i.e. the return) should be quirked IMO. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/11] sdhci: Add quirk for Freescale eSDHC controllers
On Fri, 6 Feb 2009 21:07:01 +0300 Anton Vorontsov avoront...@ru.mvista.com wrote: This patch adds SDHCI_QUIRK_FSL quirk. The quirk is used to instruct the sdhci driver about various FSL eSDHC host incompatibilities: No device quirks please. They should be for specific bugs, not lumping things together like this. Otherwise we'll soon have an unmanageable mess. 1) FSL eSDHC controllers can support maximum block size up to 4096 bytes. The MBL (Maximum Block Length) field in the capabilities register extended by one bit. (Should we implement a dedicated quirk for this? I.e. SDHCI_QUIRK_MAX_BLK_SZ_4096?) Yes please. It would have to mean always support 4096 though, not turn reserved bit 18 into a block length bit. 2) sdhci_init() is needed after error conditions. (Can we safely do this for all controllers?) Please investigate which part of sdhci_init() is needed. How does it break without this? 3) Small udelay is needed to make eSDHC work in PIO mode. Without the delay reading causes endless interrupt storm, and writing corrupts data. The first guess would be that we must wait for some bit in some register, but I didn't find any reliable bits that changes before and after the delay. Though, more investigation on this is in my todo list. Please try to investigate more, but if you cannot improve it further then a specific quirk can be added. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/cell: add missing #include for oprofile
arch/powerpc/oprofile/cell/spu_profiler.c is missing a asm/time.h include which is required for ppc_proc_freq. This can cause compile failures for some config combinations. Signed-off-by: Michael Neuling mi...@neuling.org --- This is against mainline, so should be pushed up soon-ish arch/powerpc/oprofile/cell/spu_profiler.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6-ozlabs/arch/powerpc/oprofile/cell/spu_profiler.c === --- linux-2.6-ozlabs.orig/arch/powerpc/oprofile/cell/spu_profiler.c +++ linux-2.6-ozlabs/arch/powerpc/oprofile/cell/spu_profiler.c @@ -16,6 +16,7 @@ #include linux/smp.h #include linux/slab.h #include asm/cell-pmu.h +#include asm/time.h #include pr_util.h #define SCALE_SHIFT 14 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc/ps3: Use hard coded values for LV1 device type
On Sun, 2009-02-08 at 22:29 +1100, Michael Ellerman wrote:
On Fri, 2009-02-06 at 18:42 -0800, Geoff Levand wrote:
Change the PS3 platform code to use hard coded numbers for its
LV1 device types.
The PS3 platform code was incorrectly using some scsi block
constants for the device type returned from the LV1 hypervisor.
Fixes build errors like these when CONFIG_BLOCK=n:
In file included from include/scsi/scsi.h:12,
from arch/powerpc/platforms/ps3/platform.h:25,
from arch/powerpc/platforms/ps3/setup.c:36:
include/scsi/scsi_cmnd.h:27:25: warning: BLK_MAX_CDB is not defined
include/scsi/scsi_cmnd.h:28:3: error: #error MAX_COMMAND_SIZE can not be
bigger than BLK_MAX_CDB
Adding Jens and James on CC since I think a proper fix lies in blkdev.h
or scsi*.h
So basically, the whole of blkdev.h is inside a big ifdef
CONFIG_BLOCK... which means that scsi_cmnd.h can't build which in turn
makes scsi.h fail.
The PS3 platform code wants to use some of the standard SCSI types from
there though, as they are part of the hypervisor ABI. (And in fact it
can be argued that non-block devices using SCSI do exist, such as
scanners, no ?)
Any reason other than pre-historical to have blkdev.h shielded like
that ?
Cheers,
Ben.
Signed-off-by: Geoff Levand geoffrey.lev...@am.sony.com
---
Ben,
Please send upstream for 2.6.29.
-Geoff
arch/powerpc/platforms/ps3/platform.h |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -22,8 +22,6 @@
#define _PS3_PLATFORM_H
#include linux/rtc.h
-#include scsi/scsi.h
-
#include asm/ps3.h
/* htab */
@@ -83,12 +81,12 @@ enum ps3_bus_type {
};
enum ps3_dev_type {
- PS3_DEV_TYPE_STOR_DISK = TYPE_DISK, /* 0 */
+ PS3_DEV_TYPE_STOR_DISK = 0, /* TYPE_DISK */
PS3_DEV_TYPE_SB_GELIC = 3,
PS3_DEV_TYPE_SB_USB = 4,
- PS3_DEV_TYPE_STOR_ROM = TYPE_ROM, /* 5 */
+ PS3_DEV_TYPE_STOR_ROM = 5, /* TYPE_ROM */
PS3_DEV_TYPE_SB_GPIO = 6,
- PS3_DEV_TYPE_STOR_FLASH = TYPE_RBC, /* 14 */
+ PS3_DEV_TYPE_STOR_FLASH = 14, /* TYPE_RBC */
This looks like you're just papering over the bug, by hardcoding the
same values that are in the scsi header. Or are they really independent,
in which case I'd say the comments are confusing.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/pci: mmap anonymous memory when legacy_mem doesn't exist
The new legacy_mem file in sysfs is causing problems with X on machines
that don't support legacy memory access. The way I initially implemented
it, we would fail with -ENXIO when trying to mmap it, thus exposing to
X that we do support the API but there is no legacy memory.
Unfortunately, X poor error handling is causing it to fail to start when
it gets this error.
This implements a workaround hack that instead maps anonymous memory
instead (using shmem if VM_SHARED is set, just like /dev/zero does).
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
This fixes a regression in .29 and is the less ugly way we found to
sort this problem out. I'll merge it ASAP so holler quick if you
have an objection
arch/powerpc/kernel/pci-common.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2009-02-06
16:23:36.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2009-02-06 16:30:32.0
+1100
@@ -561,8 +561,21 @@ int pci_mmap_legacy_page_range(struct pc
(unsigned long long)(offset + size - 1));
if (mmap_state == pci_mmap_mem) {
- if ((offset + size) hose-isa_mem_size)
- return -ENXIO;
+ /* Hack alert !
+*
+* Because X is lame and can fail starting if it gets an error
trying
+* to mmap legacy_mem (instead of just moving on without legacy
memory
+* access) we fake it here by giving it anonymous memory,
effectively
+* behaving just like /dev/zero
+*/
+ if ((offset + size) hose-isa_mem_size) {
+ printk(KERN_DEBUG
+ Process %s (pid:%d) mapped non-existing PCI
legacy memory for 0%04x:%02x\n,
+ current-comm, current-pid, pci_domain_nr(bus),
bus-number);
+ if (vma-vm_flags VM_SHARED)
+ return shmem_zero_setup(vma);
+ return 0;
+ }
offset += hose-isa_mem_phys;
} else {
unsigned long io_offset = (unsigned long)hose-io_base_virt -
_IO_BASE;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: add missing sparsemem.h include
arch/powerpc/platforms/pseries/hotplug-memory.c uses
remove_section_mapping() but doesn't include sparsemem.h which defines
it. This can cause compilation fails for some configs.
Signed-off-by: Michael Neuling mi...@neuling.org
---
This is against mainline, so should be pushed up soon-ish...
arch/powerpc/platforms/pseries/hotplug-memory.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-memory.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -14,6 +14,7 @@
#include asm/firmware.h
#include asm/machdep.h
#include asm/pSeries_reconfig.h
+#include asm/sparsemem.h
static int pseries_remove_lmb(unsigned long base, unsigned int lmb_size)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc/ps3: Use hard coded values for LV1 device type
On Mon, 2009-02-09 at 11:11 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2009-02-08 at 22:29 +1100, Michael Ellerman wrote:
On Fri, 2009-02-06 at 18:42 -0800, Geoff Levand wrote:
Change the PS3 platform code to use hard coded numbers for its
LV1 device types.
The PS3 platform code was incorrectly using some scsi block
constants for the device type returned from the LV1 hypervisor.
Fixes build errors like these when CONFIG_BLOCK=n:
In file included from include/scsi/scsi.h:12,
from arch/powerpc/platforms/ps3/platform.h:25,
from arch/powerpc/platforms/ps3/setup.c:36:
include/scsi/scsi_cmnd.h:27:25: warning: BLK_MAX_CDB is not defined
include/scsi/scsi_cmnd.h:28:3: error: #error MAX_COMMAND_SIZE can not
be bigger than BLK_MAX_CDB
Adding Jens and James on CC since I think a proper fix lies in blkdev.h
or scsi*.h
And cc'd linux-scsi
So basically, the whole of blkdev.h is inside a big ifdef
CONFIG_BLOCK... which means that scsi_cmnd.h can't build which in turn
makes scsi.h fail.
Well, look at it from our point of view; it's impossible to build SCSI
without block, so a little interdependence is easy to get.
The PS3 platform code wants to use some of the standard SCSI types from
there though, as they are part of the hypervisor ABI. (And in fact it
can be argued that non-block devices using SCSI do exist, such as
scanners, no ?)
Any reason other than pre-historical to have blkdev.h shielded like
that ?
Actually, I think the fix lies in scsi.h ... we can make that into a
nicely independent protocol header file. Your current woes come because
it pulls in scsi_cmnd.h ... perhaps just getting rid of this will fix
it.
Can the rest of linux-scsi verify that the fix below doesn't break
something else?
I found one cockup: block/cmd-filter.c is apparently not including
linuc/blkdev.h directly but via scsi/scsi.h ... I fixed this up.
Cheers,
Ben.
Signed-off-by: Geoff Levand geoffrey.lev...@am.sony.com
---
Ben,
Please send upstream for 2.6.29.
-Geoff
arch/powerpc/platforms/ps3/platform.h |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -22,8 +22,6 @@
#define _PS3_PLATFORM_H
#include linux/rtc.h
-#include scsi/scsi.h
-
#include asm/ps3.h
/* htab */
@@ -83,12 +81,12 @@ enum ps3_bus_type {
};
enum ps3_dev_type {
- PS3_DEV_TYPE_STOR_DISK = TYPE_DISK, /* 0 */
+ PS3_DEV_TYPE_STOR_DISK = 0, /* TYPE_DISK */
PS3_DEV_TYPE_SB_GELIC = 3,
PS3_DEV_TYPE_SB_USB = 4,
- PS3_DEV_TYPE_STOR_ROM = TYPE_ROM, /* 5 */
+ PS3_DEV_TYPE_STOR_ROM = 5, /* TYPE_ROM */
PS3_DEV_TYPE_SB_GPIO = 6,
- PS3_DEV_TYPE_STOR_FLASH = TYPE_RBC, /* 14 */
+ PS3_DEV_TYPE_STOR_FLASH = 14, /* TYPE_RBC */
This looks like you're just papering over the bug, by hardcoding the
same values that are in the scsi header. Or are they really independent,
in which case I'd say the comments are confusing.
cheers
James
---
diff --git a/block/cmd-filter.c b/block/cmd-filter.c
index 504b275..572bbc2 100644
--- a/block/cmd-filter.c
+++ b/block/cmd-filter.c
@@ -22,6 +22,7 @@
#include linux/spinlock.h
#include linux/capability.h
#include linux/bitops.h
+#include linux/blkdev.h
#include scsi/scsi.h
#include linux/cdrom.h
diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
index 80d7f60..084478e 100644
--- a/include/scsi/scsi.h
+++ b/include/scsi/scsi.h
@@ -9,7 +9,8 @@
#define _SCSI_SCSI_H
#include linux/types.h
-#include scsi/scsi_cmnd.h
+
+struct scsi_cmnd;
/*
* The maximum number of SG segments that we will put inside a
@@ -439,22 +440,6 @@ static inline int scsi_is_wlun(unsigned int lun)
#define host_byte(result) (((result) 16) 0xff)
#define driver_byte(result) (((result) 24) 0xff)
-static inline void set_msg_byte(struct scsi_cmnd *cmd, char status)
-{
- cmd-result |= status 8;
-}
-
-static inline void set_host_byte(struct scsi_cmnd *cmd, char status)
-{
- cmd-result |= status 16;
-}
-
-static inline void set_driver_byte(struct scsi_cmnd *cmd, char status)
-{
- cmd-result |= status 24;
-}
-
-
#define sense_class(sense) (((sense) 4) 0x7)
#define sense_error(sense) ((sense) 0xf)
#define sense_valid(sense) ((sense) 0x80);
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index 855bf95..43b50d3 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -291,4 +291,19 @@ static inline struct scsi_data_buffer *scsi_prot(struct
scsi_cmnd *cmd)
#define scsi_for_each_prot_sg(cmd, sg, nseg, __i) \
for_each_sg(scsi_prot_sglist(cmd), sg, nseg, __i)
+static inline void set_msg_byte(struct scsi_cmnd *cmd, char status)
+{
+ cmd-result |= status 8;
+}
+
+static inline void set_host_byte(struct scsi_cmnd *cmd,
2.6.29-rc4-git1 build break : cell/spu_profiler.o
2.6.29-rc4-git1 randconfig build on powerpc fails with CALLarch/powerpc/kernel/prom_init_check.sh CC [M] arch/powerpc/oprofile/cell/spu_profiler.o arch/powerpc/oprofile/cell/spu_profiler.c: In function set_spu_profiling_frequency: arch/powerpc/oprofile/cell/spu_profiler.c:52: error: ppc_proc_freq undeclared (first use in this function) arch/powerpc/oprofile/cell/spu_profiler.c:52: error: (Each undeclared identifier is reported only once arch/powerpc/oprofile/cell/spu_profiler.c:52: error: for each function it appears in.) make[1]: *** [arch/powerpc/oprofile/cell/spu_profiler.o] Error 1 make: *** [arch/powerpc/oprofile] Error 2 .config attached. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - # # Automatically generated make config: don't edit # Linux kernel version: 2.6.29-rc4-git1 # Mon Feb 9 13:45:17 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_POWER4_ONLY=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_VSX=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y # CONFIG_VIRT_CPU_ACCOUNTING is not set CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y # CONFIG_TASK_DELAY_ACCT is not set CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_NS=y # CONFIG_CGROUP_FREEZER is not set # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_MM_OWNER=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=m CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # CONFIG_FREEZER is not set CONFIG_PPC_MSI_BITMAP=y # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_PSERIES is not set CONFIG_LPARCFG=y
Re: 2.6.29-rc4-git1 build break : cell/spu_profiler.o
Hi Sachin, On Mon, 09 Feb 2009 12:13:41 +0530 Sachin P. Sant sach...@in.ibm.com wrote: 2.6.29-rc4-git1 randconfig build on powerpc fails with CALLarch/powerpc/kernel/prom_init_check.sh CC [M] arch/powerpc/oprofile/cell/spu_profiler.o arch/powerpc/oprofile/cell/spu_profiler.c: In function set_spu_profiling_frequency: arch/powerpc/oprofile/cell/spu_profiler.c:52: error: ppc_proc_freq undeclared (first use in this function) arch/powerpc/oprofile/cell/spu_profiler.c:52: error: (Each undeclared identifier is reported only once arch/powerpc/oprofile/cell/spu_profiler.c:52: error: for each function it appears in.) make[1]: *** [arch/powerpc/oprofile/cell/spu_profiler.o] Error 1 make: *** [arch/powerpc/oprofile] Error 2 See http://patchwork.ozlabs.org/patch/22628/ -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpSJ9j3KYky3.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.29-rc4-git1 build break : cell/spu_profiler.o
Stephen Rothwell wrote: See http://patchwork.ozlabs.org/patch/22628/ Thanks Stephen. The above patch fixed this build break. Regards -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/83xx: Fix TSEC0 workability on MPC8313E-RDB boards
On Fri, Feb 6, 2009 at 4:10 AM, Anton Vorontsov avoront...@ru.mvista.com wrote: TSEC0 is connected to Vitesse 7385 5-port switch. The switch isn't connected to any mdio bus, the link to the switch is fixed to Full-duplex 1000 Mb/s (no pause). It's a complex case for RDB boards. The revision A and revision B boards DO always connect TSEC0 to Vitesse switch. While the latest revision C board has one setting to connect TSEC0 to a Marvell PHY and MDIO bus. In BSP we have several DTS's for each setting of the board, shouldn't we do the same for upstream? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
