powerpc: add support for ps3 platform

This adds the core platform support for the PS3 game console and other platforms using the PS3 Platform hypervisor.

Signed-off-by Geoff Levand <[email protected]>

---
 MAINTAINERS                             |    7 
 arch/powerpc/Kconfig                    |   11 
 arch/powerpc/platforms/Makefile         |    1 
 arch/powerpc/platforms/ps3pf/Kconfig    |   32 +

Hi,

Just a couple of small comments, I haven't had time to get deeper into the patchset yet. :-)

Quoted 11 lines · On Fri, 10 Nov 2006 12:02:19 -0800 Geoff Levand <[email protected]>…

This adds the core platform support for the PS3 game console and other platforms using the PS3 Platform hypervisor.

Signed-off-by Geoff Levand <[email protected]>

---
 MAINTAINERS                             |    7 
 arch/powerpc/Kconfig                    |   11 
 arch/powerpc/platforms/Makefile         |    1 
 arch/powerpc/platforms/ps3pf/Kconfig    |   32 +

Why are you naming the platform "platform" as in "this is the ps3pf platform" which expands to "this is the ps3 platform platform"? ps3 is quite adequate as the platform name. :-)

Quoted 2 lines

platform" which expands to "this is the ps3 platform platform"? ps3 is quite adequate as the platform name. :-)

I had it as ps3, but I was told to change it to ps3pf.

I had it as ps3, but I was told to change it to ps3pf. I don't like that name though.

The "ps3pf" name is pretty meaningless. =A0I think that, at the very least, the directory name should be arch/powerpc/platforms/ps3. Unless Arnd is prepared to argue strongly to the contrary, I will be rejecting patches that create a platforms/ps3pf directory.

Quoted 4 lines · Paul Mackerras

The "ps3pf" name is pretty meaningless. �I think that, at the very least, the directory name should be arch/powerpc/platforms/ps3. Unless Arnd is prepared to argue strongly to the contrary, I will be rejecting patches that create a platforms/ps3pf directory.

I don't care about the name at all, either way. However, I think it would be good to be consistant with the directory name and the name of identifiers in the code, so the function names should also be changed if the platform is name 'ps3'.

Indeed, and since we don't like changing all of these back and forth, it would be nice to have a definitive decision soon.

Quoted 2 lines · Geert Uytterhoeven

Indeed, and since we don't like changing all of these back and forth, it would be nice to have a definitive decision soon.

Put the ps3 support in arch/powerpc/platforms/ps3. If there are hypervisor-specific routines, they can have a ps3pf_ prefix if you want.

The whole port is hypervisor-specific. =A0It should be called ps3hv or sonyhv (in case the plan for more hardware that's crippled by this hypervisor)=20

ps3 should be left for a bare metal port that people may or may not do=20

Quoted 3 lines · Christoph Hellwig

The whole port is hypervisor-specific. ?It should be called ps3hv or sonyhv (in case the plan for more hardware that's crippled by this hypervisor)

The hypervisor has a name, it's called 'lv1', and the port already uses that identifier for the low-level interfaces.
If the platform is named after the hypervisor, we should not make up a new name but use the one that is already there.

Quoted 1 line

ps3 should be left for a bare metal port that people may or may not do

If there will ever be a native port, that will not need its platform directory but can simply go into into common platforms/cell/ and sysdev directories, with a small file for the ppc_md instance. All the interesting files (page table, iommu, interrupt handling) would be shared with native ports to different hardware.

Quoted 9 lines · Arnd Bergmann

Quoted 3 lines · Christoph Hellwig

The whole port is hypervisor-specific. ?It should be called ps3hv or sonyhv (in case the plan for more hardware that's crippled by this hypervisor)

The hypervisor has a name, it's called 'lv1', and the port already uses that identifier for the low-level interfaces.
If the platform is named after the hypervisor, we should not make up a new name but use the one that is already there.

Actually that makes even more sense, yes.

Quoted 2 lines

Quoted 1 line

ps3 should be left for a bare metal port that people may or may not do

Quoted 5 lines

If there will ever be a native port, that will not need its platform directory but can simply go into into common platforms/cell/ and sysdev directories, with a small file for the ppc_md instance. All the interesting files (page table, iommu, interrupt handling) would be shared with native ports to different hardware.

I guess so, yes. We'd still add a CONFIG_PS3 for it to not bloat kernels that don't want support.

Quoted 1 line · Christoph Hellwig

The whole port is hypervisor-specific. =EF=BF=BDIt should be called ps=

Quoted 2 lines

sonyhv (in case the plan for more hardware that's crippled by this hypervisor)=20

=20
The hypervisor has a name, it's called 'lv1', and the port already uses that identifier for the low-level interfaces.
If the platform is named after the hypervisor, we should not make up a new name but use the one that is already there.

Quoted 8 lines · Paul Mackerras

Quoted 2 lines · Geert Uytterhoeven

Indeed, and since we don't like changing all of these back and forth, it would be nice to have a definitive decision soon.

Put the ps3 support in arch/powerpc/platforms/ps3. If there are hypervisor-specific routines, they can have a ps3pf_ prefix if you want.

The whole port is hypervisor-specific. It should be called ps3hv or sonyhv (in case the plan for more hardware that's crippled by this hypervisor) ps3 should be left for a bare metal port that people may or may not do when they have time at their hands to get rid of the HV that cripples the hardware.

Quoted 9 lines

arch/powerpc/platforms/ps3pf/Kconfig new file +9 -0

+config PS3PF_HTAB_SIZE
+	depends on PS3PF
+	int "PS3 Platform pagetable size"
+	range 18 20
+	default 20
+	help
+	  This option is only for experts who may have the desire to fine
+	  tune the pagetable size on their system.  The value here is
+	  expressed as the log2 of the page table size.  Valid values are

arch/powerpc/platforms/ps3pf/Kconfig line 16

Quoted 4 lines

arch/powerpc/platforms/ps3pf/Kconfig new file +4 -0

+	  18, 19, and 20, corresponding to 256KB, 512KB and 1MB respectively.
+
+	  If unsure, choose the default (20) with the confidence that your
+	  system will have optimal runtime performance.

Wouldn't it be more understandable if you had a "small/medium/large" memory config options (that in itself sets the values) instead of having people pick numbers?

This adds the core platform support for the PS3 game console and other platforms using the PS3 Platform hypervisor.

Quoted 2 lines · Geoff Levand

This adds the core platform support for the PS3 game console and other platforms using the PS3 Platform hypervisor.

Please give the port a less confusing name. I'd expect platforms/ps3 to be the bare metal port once people have revere-engineered the hardware, so your crappy hipervisor code should make it very clear what it is. sonyhv or ps3hv would suite I think.

(quoted diff) +0 -0

@@ -876,7 +885,7 @@

=A0=A0=A0=A0=A0=A0=A0=A0bool "PCI support" if 40x || CPM2 || PPC_83xx || =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|| PPC_MPC52xx || (EMBEDD=

=A0=A0=A0=A0=A0=A0=A0=A0default y if !40x && !CPM2 && !8xx && !APUS && !P=

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0&& !PPC_85xx && !PPC_86xx +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0&& !PPC_85xx && !PPC_86xx &=

=A0=A0=A0=A0=A0=A0=A0=A0default PCI_PERMEDIA if !4xx && !CPM2 && !8xx && =

=A0=A0=A0=A0=A0=A0=A0=A0default PCI_QSPAN if !4xx && !CPM2 && 8xx =A0=A0=A0=A0=A0=A0=A0=A0help

arch/powerpc/platforms/ps3pf/mm.c new file +5 -0

+
+enum allocate_memory {
+	/* bit 63: transferability */
+	LV1_AM_TF_NO = 0x00,
+	LV1_AM_TF_YES = 0x01,

arch/powerpc/platforms/ps3pf/mm.c new file +5 -0

+ * @len: Length in bytes of the area to map.
+ * c_out: A pointer to receive an allocated struct dma_chunk for this area.
+ *
+ * This is the lowest level dma mapping routine, and is the one that will
+ * make the HV call to add the pages into the io controller address space.

Quoted 2 lines

+ * Copyright (C) 2006 Sony Computer Entertainment Inc.
+ * Copyright 2006 Sony Corp.

One with a (C) and one without looks very odd. Who from your corporate mother Sony Corp touched this code anyway?

arch/powerpc/platforms/ps3pf/mm.c line 50

Quoted 12 lines

arch/powerpc/platforms/ps3pf/mm.c new file +12 -0

+enum {
+#if defined(CONFIG_PS3PF_USE_LPAR_ADDR)
+	USE_LPAR_ADDR = 1,
+#else
+	USE_LPAR_ADDR = 0,
+#endif
+#if defined(CONFIG_PS3PF_DYNAMIC_DMA)
+	USE_DYNAMIC_DMA = 1,
+#else
+	USE_DYNAMIC_DMA = 0,
+#endif
+};

This is really ugly. At least dynamic_dma (or as we'd say it iommu) shoud be a runtime feature. So this should just be an

"int ps3hv_use_iommu"

variable initialize to the proper default.

Quoted 9 lines

arch/powerpc/platforms/ps3pf/mm.c new file +9 -0

+enum allocate_memory {
+	/* bit 63: transferability */
+	LV1_AM_TF_NO = 0x00,
+	LV1_AM_TF_YES = 0x01,
+	/* bit 62: destruction scheme */
+	LV1_AM_DS_NO_CONNECTIONS = 0x00,
+	LV1_AM_DS_ANYTIME = 0x02,
+	/* bit 61: fail or alternative */
+	LV1_AM_FA_FAIL = 0x00,

arch/powerpc/platforms/ps3pf/mm.c line 71

Quoted 5 lines

arch/powerpc/platforms/ps3pf/mm.c new file +5 -0

+	LV1_AM_FA_ALTERNATIVE = 0x04,
+	/* bit 60: lpar address */
+	LV1_AM_ADDR_ANY = 0x00,
+	LV1_AM_ADDR_0 = 0x08,
+};

If these are for different its they should be in different enums and use different prefixes.

Quoted 7 lines

arch/powerpc/platforms/ps3pf/mm.c new file +7 -0

+/**
+ * struct mem_region - memory region structure
+ * @base: base address
+ * @size: size in bytes
+ * @offset: difference between base and rm.size
+ */
+

arch/powerpc/platforms/ps3pf/mm.c line 100

Quoted 5 lines

arch/powerpc/platforms/ps3pf/mm.c new file +5 -0

+struct mem_region {
+	unsigned long base;
+	unsigned long size;
+	unsigned long offset;
+};

This seems like a duplication of the iseries lmb, please try to reuse that functionality.

arch/powerpc/platforms/ps3pf/mm.c line 467

Quoted 8 lines

arch/powerpc/platforms/ps3pf/mm.c new file +8 -0

+static int dma_map_pages(struct ps3pf_dma_region *r, unsigned long virt_addr,
+	unsigned long len, struct dma_chunk **c_out)
+{
+	int result;
+	unsigned long phys_addr;
+	struct dma_chunk *c;
+
+	phys_addr = is_kernel_addr(virt_addr) ? __pa(virt_addr) : virt_addr;

When do you ever get non-kernel addresses into the dma calls? I in either case this should move into the caller and the routine should get a simple unsigned long phys_addr argument.

But when looking at this whole dma_map code is looks rather bogus to me. Could it be that you try to pre-map dma regions rather than doing it through the dma API?

arch/powerpc/platforms/ps3pf/platform.h line 22

Quoted 2 lines

arch/powerpc/platforms/ps3pf/platform.h new file +2 -0

+#if !defined(_510B7842_EE09_4B12_BE5C_D217383D50C7)
+#define _510B7842_EE09_4B12_BE5C_D217383D50C7

WTF?

Quoted 5 lines

arch/powerpc/platforms/ps3pf/setup.c new file +5 -0

+#if defined(CONFIG_BLK_DEV_INITRD)
+ 	if (initrd_start)
+ 		ROOT_DEV = Root_RAM0;
+ 	else
+#endif

arch/powerpc/platforms/ps3pf/setup.c line 90

Quoted 5 lines

arch/powerpc/platforms/ps3pf/setup.c new file +5 -0

+#if defined(CONFIG_ROOT_NFS)
+		ROOT_DEV = Root_NFS;
+#else
+ 		ROOT_DEV = Root_HDA1;
+#endif

Please don't put this auto-select root device idiocy into any new ports (Yeah, I'm pretty sure you just copy & pasted it from somewhere..)

arch/powerpc/platforms/ps3pf/smp.c line 39

Quoted 3 lines

arch/powerpc/platforms/ps3pf/smp.c new file +3 -0

+#if !defined(PPC_MSG_MIGRATE_TASK)
+static const int PPC_MSG_MIGRATE_TASK = 2;
+#endif

This looks rather odd, what is it trying to do?

Quoted 1 line

+unsigned long __deprecated ps3pf_legacy_virq_to_outlet(unsigned int virq);

Never put deprecated routines into a new code submission.

Quoted 5 lines · Christoph Hellwig

arch/powerpc/platforms/ps3pf/smp.c line 39

Quoted 3 lines

arch/powerpc/platforms/ps3pf/smp.c new file +3 -0

+#if !defined(PPC_MSG_MIGRATE_TASK)
+static const int PPC_MSG_MIGRATE_TASK = 2;
+#endif

This looks rather odd, what is it trying to do?

For some reason the definition of PPC_MSG_MIGRATE_TASK is sometimes 2, and sometimes not defined, depending on other config options. It makes the code much simpler if it is always defined as 2. Maybe it makes more sense if I change it to this:

#if !defined(PPC_MSG_MIGRATE_TASK)
#define PPC_MSG_MIGRATE_TASK 2
#endif

Quoted 9 lines · Geoff Levand

Quoted 5 lines · Christoph Hellwig

arch/powerpc/platforms/ps3pf/smp.c line 39

Quoted 3 lines

arch/powerpc/platforms/ps3pf/smp.c new file +3 -0

+#if !defined(PPC_MSG_MIGRATE_TASK)
+static const int PPC_MSG_MIGRATE_TASK = 2;
+#endif

This looks rather odd, what is it trying to do?

Quoted 8 lines

For some reason the definition of PPC_MSG_MIGRATE_TASK is sometimes 2, and sometimes not defined, depending on other config options. It makes the code much simpler if it is always defined as 2. Maybe it makes more sense if I change it to this:

#if !defined(PPC_MSG_MIGRATE_TASK)
#define PPC_MSG_MIGRATE_TASK 2
#endif

include/asm-powerpc/smp.h says:

/* This is unused now */
#if 0
#define PPC_MSG_MIGRATE_TASK 2
#endif

So it will never be defined. Why do you need it, you don't seem to use it anywhere?

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines

+ * Copyright (C) 2006 Sony Computer Entertainment Inc.
+ * Copyright 2006 Sony Corp.

One with a (C) and one without looks very odd. Who from your corporate mother Sony Corp touched this code anyway?

Sony Corp. and Sony Computer Entertainment are different companies with different policies. I have no choice here.

I set it up that way so that the optimizer will remove the unused parts. This machine doesn't have much memory, and the dynamic (that's not my name BTW, came from your side) will normally not be used. I don't really want to set it up as a runtime option unless there is a real user need.

Quoted 11 lines

Quoted 11 lines

arch/powerpc/platforms/ps3pf/mm.c new file +9 -0

+enum allocate_memory {
+	/* bit 63: transferability */
+	LV1_AM_TF_NO = 0x00,
+	LV1_AM_TF_YES = 0x01,
+	/* bit 62: destruction scheme */
+	LV1_AM_DS_NO_CONNECTIONS = 0x00,
+	LV1_AM_DS_ANYTIME = 0x02,
+	/* bit 61: fail or alternative */
+	LV1_AM_FA_FAIL = 0x00,

Quoted 8 lines

arch/powerpc/platforms/ps3pf/mm.c line 71

Quoted 5 lines

arch/powerpc/platforms/ps3pf/mm.c new file +5 -0

+	LV1_AM_FA_ALTERNATIVE = 0x04,
+	/* bit 60: lpar address */
+	LV1_AM_ADDR_ANY = 0x00,
+	LV1_AM_ADDR_0 = 0x08,
+};

If these are for different its they should be in different enums and use different prefixes.

These are all flags for lv1_allocate_memory (hence the the LV1_AM_ prefix). The bits are documented there in the comments, bit 60, 61, etc.

Quoted 4 lines

arch/powerpc/platforms/ps3pf/platform.h line 22

Quoted 2 lines

arch/powerpc/platforms/ps3pf/platform.h new file +2 -0

+#if !defined(_510B7842_EE09_4B12_BE5C_D217383D50C7)
+#define _510B7842_EE09_4B12_BE5C_D217383D50C7

WTF?

Considering your criticism earlier in this mail regarding the use of a file name in the file's comments, I'm wondering what your preference is here, since the convention is to use a symbol based on the file name...

BTW, I'm surprised you don't recognize it:
uuidgen | tr 'a-z-' 'A-Z_' | sed -e 's/^/_/'

So did anyone from Sony Corp sactually touch all these files

Quoted 4 lines · Geoff Levand

I set it up that way so that the optimizer will remove the unused parts. This machine doesn't have much memory, and the dynamic (that's not my name BTW, came from your side) will normally not be used. I don't really want to set it up as a runtime option unless there is a real user need.

The optimizer also optimizes away variables that can't be anything but
0. I'm also not sure what "my side" (whatever that may be) has anything to do with that.

Quoted 19 lines

Quoted 17 lines

Quoted 4 lines

arch/powerpc/platforms/ps3pf/mm.c new file +4 -0

+enum allocate_memory {
+	/* bit 63: transferability */
+	LV1_AM_TF_NO = 0x00,
+	LV1_AM_TF_YES = 0x01,

arch/powerpc/platforms/ps3pf/mm.c line 71

Quoted 10 lines

arch/powerpc/platforms/ps3pf/mm.c new file +10 -0

+	/* bit 62: destruction scheme */
+	LV1_AM_DS_NO_CONNECTIONS = 0x00,
+	LV1_AM_DS_ANYTIME = 0x02,
+	/* bit 61: fail or alternative */
+	LV1_AM_FA_FAIL = 0x00,
+	LV1_AM_FA_ALTERNATIVE = 0x04,
+	/* bit 60: lpar address */
+	LV1_AM_ADDR_ANY = 0x00,
+	LV1_AM_ADDR_0 = 0x08,
+};

If these are for different its they should be in different enums and use different prefixes.

Quoted 2 lines

These are all flags for lv1_allocate_memory (hence the the LV1_AM_ prefix). The bits are documented there in the comments, bit 60, 61, etc.

But this is just prone for users to get things wrong. When flags with the same prefix need to go to different locations something is badly wrong.

Quoted 6 lines

Quoted 4 lines

arch/powerpc/platforms/ps3pf/platform.h line 22

Quoted 2 lines

arch/powerpc/platforms/ps3pf/platform.h new file +2 -0

+#if !defined(_510B7842_EE09_4B12_BE5C_D217383D50C7)
+#define _510B7842_EE09_4B12_BE5C_D217383D50C7

WTF?

Quoted 7 lines

Considering your criticism earlier in this mail regarding the use of a file name in the file's comments, I'm wondering what your preference is here, since the convention is to use a symbol based on the file name...

BTW, I'm surprised you don't recognize it:
uuidgen | tr 'a-z-' 'A-Z_' | sed -e 's/^/_/'

There's a good reason we don't use this elsewhere, and if you think it's a good idea propose it for general use on lkml (and get the deserved flames) instead of trying to sneak it in silently. Re the filename comment:
this was mostly a thing for implementation (.c) files that get renamed a lot so it easily gets stale and has no real value. Headers by their nature of beein used from various places tend to stay more stable so this problem is not that bad. And unlike top of file comments inclusion guards actually serve a purpose so we'll have to live with the additional work of renaming them in case.

Quoted 4 lines · Geoff Levand

Quoted 3 lines · Christoph Hellwig

Quoted 2 lines

+ * Copyright (C) 2006 Sony Computer Entertainment Inc.
+ * Copyright 2006 Sony Corp.

Quoted 6 lines

Quoted 2 lines

One with a (C) and one without looks very odd. Who from your corporate mother Sony Corp touched this code anyway?

Sony Corp. and Sony Computer Entertainment are different companies with different policies. I have no choice here.

So did anyone from Sony Corp sactually touch all these files?

arch/powerpc/platforms/ps3pf/mm.c line 56

Quoted 7 lines

arch/powerpc/platforms/ps3pf/mm.c new file +6 -0

+
+enum page_size {
+	page_size_4k = 12U,
+	page_size_64k = 16U,
+	page_size_16m = 24U,
+};

Please use ALL_CAPS for such constants.

Quoted 8 lines

arch/powerpc/platforms/ps3pf/mm.c line 56

Quoted 6 lines

arch/powerpc/platforms/ps3pf/mm.c new file +6 -0

+
+enum page_size {
+	page_size_4k = 12U,
+	page_size_64k = 16U,
+	page_size_16m = 24U,
+};

Please use ALL_CAPS for such constants.

And call them PAGE_SHIFT_* while at it :-)

Quoted 9 lines · Benjamin Herrenschmidt

Quoted 8 lines

arch/powerpc/platforms/ps3pf/mm.c line 56

Quoted 6 lines

arch/powerpc/platforms/ps3pf/mm.c new file +6 -0

+
+enum page_size {
+	page_size_4k = 12U,
+	page_size_64k = 16U,
+	page_size_16m = 24U,
+};

Please use ALL_CAPS for such constants.

Quoted 1 line

And call them PAGE_SHIFT_* while at it :-)

The HV docs call this page size, so that is what I used for the symbol. I'll look at the usage again and reconsider.

Quoted 12 lines · Geoff Levand

Quoted 10 lines · Benjamin Herrenschmidt

Quoted 8 lines

arch/powerpc/platforms/ps3pf/mm.c line 56

Quoted 6 lines

arch/powerpc/platforms/ps3pf/mm.c new file +6 -0

+
+enum page_size {
+	page_size_4k = 12U,
+	page_size_64k = 16U,
+	page_size_16m = 24U,
+};

Please use ALL_CAPS for such constants.

And call them PAGE_SHIFT_* while at it :-)

Quoted 2 lines

The HV docs call this page size, so that is what I used for the symbol. I'll look at the usage again and reconsider.

No need to look at it, it's a shift not a size, the page size is not 12 bytes. Keeping it consistent with the HV docs is a concern, but so is making it consistent with every other part of the kernel - which calls this a shift, see page.h f.e.

Quoted 16 lines · Michael Ellerman

Quoted 14 lines · Geoff Levand

Quoted 10 lines · Benjamin Herrenschmidt

Quoted 8 lines

arch/powerpc/platforms/ps3pf/mm.c line 56

Quoted 6 lines

arch/powerpc/platforms/ps3pf/mm.c new file +6 -0

+
+enum page_size {
+	page_size_4k = 12U,
+	page_size_64k = 16U,
+	page_size_16m = 24U,
+};

Please use ALL_CAPS for such constants.

And call them PAGE_SHIFT_* while at it :-)

The HV docs call this page size, so that is what I used for the symbol. I'll look at the usage again and reconsider.

Quoted 4 lines

No need to look at it, it's a shift not a size, the page size is not 12 bytes. Keeping it consistent with the HV docs is a concern, but so is making it consistent with every other part of the kernel - which calls this a shift, see page.h f.e.

Well, I meant reconsider in more of a broad sense, in like, maybe I can just do something to get rid of it...

Quoted 22 lines · Geoff Levand

Quoted 20 lines · Michael Ellerman

Quoted 10 lines · Geoff Levand

Quoted 9 lines · Benjamin Herrenschmidt

Quoted 8 lines

Review

Quoted 6 lines

(quoted diff) +6 -0

+
+enum page_size {
+	page_size_4k = 12U,
+	page_size_64k = 16U,
+	page_size_16m = 24U,
+};

Please use ALL_CAPS for such constants.

Quoted 4 lines

Quoted 1 line

And call them PAGE_SHIFT_* while at it :-)

The HV docs call this page size, so that is what I used for the symbol. I'll look at the usage again and reconsider.

No need to look at it, it's a shift not a size, the page size is not 12 bytes. Keeping it consistent with the HV docs is a concern, but so is making it consistent with every other part of the kernel - which calls this a shift, see page.h f.e.

Quoted 2 lines

Well, I meant reconsider in more of a broad sense, in like, maybe I can just do something to get rid of it...

Yeah ok, that's always a nice solution. My last post probably could have used a smiley in hindsight :)

arch/powerpc/platforms/ps3pf/setup.c new file +6 -0

+static int __init ps3pf_probe(void)
+{
+=A0=A0=A0=A0=A0=A0=A0unsigned long htab_size;
+
+=A0=A0=A0=A0=A0=A0=A0pr_debug(" -> %s:%d\n", __func__, __LINE__);
+