Re: [patch 1/3] ps3: Disk Storage Driver
Andreas Schwab wrote: Jeff Garzik [EMAIL PROTECTED] writes: Andy Whitcroft wrote: Andrew Morton wrote: + start_sector = req-sector*priv-blocking_factor; + sectors = req-nr_sectors*priv-blocking_factor; s/*/ * /. checkpatch missed this. Ok, this is something we need to decide on. Currently we only ask for consistent spacing on all the mathematic operators. This is mostly as we do see a large number of non-spaced uses in defines and the like. I am happy to expand these tests so they are always spaced on both sides style if that is the preference. That is most definitely the preference: spaces surround operators. ^binary Yes. :) Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
On Tue, 24 Jul 2007 08:37:09 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Andy Whitcroft wrote: Andrew Morton wrote: + start_sector = req-sector*priv-blocking_factor; + sectors = req-nr_sectors*priv-blocking_factor; s/*/ * /. checkpatch missed this. Ok, this is something we need to decide on. Currently we only ask for consistent spacing on all the mathematic operators. This is mostly as we do see a large number of non-spaced uses in defines and the like. I am happy to expand these tests so they are always spaced on both sides style if that is the preference. That is most definitely the preference: spaces surround operators. I must say that I find it hard to object to start = radix_tree_next_hole(mapping-page_tree, offset, max+1); but when the expression is more complex the spaces help. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
Andy Whitcroft writes: Ok, this is something we need to decide on. Currently we only ask for consistent spacing on all the mathematic operators. This is mostly as we do see a large number of non-spaced uses in defines and the like. I am happy to expand these tests so they are always spaced on both sides style if that is the preference. It depends very much on the context - on the precedence and relative importance of one operator with respect to other operators and the statement as a whole. In general I prefer spaces around binary operators, but there are situations where not putting spaces around some operators can enhance the readability of the statement as a whole. If checkpatch.pl starts whinging about operators without spaces that will just be yet another reason not to use it IMHO. Also, I prefer the style where the ? and : operators have a space after them but not before them, rather than a space either side. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
On Wed, 25 Jul 2007 11:09:21 +1000 Paul Mackerras [EMAIL PROTECTED] wrote: Also, I prefer the style where the ? and : operators have a space after them but not before them, rather than a space either side. Could I point out that your likes and dislikes are immaterial? The whole point here is to get kernel code looking consistent. That means that basically everyone ends up doing things which they'd prefer not to do. That certainly applies to me. The idea is that the benefit of making things consistent exceeds the costs of some individuals adopting styles which they are less used to. So telling people what you do and don't like is simply irrelevant, except for when it is used as an input in determining what the standard kernel style is to be. (And that is largely determined by observing what we have now). And sure, major subsytems can and do go off and do their own thing - ia64 for example has done a lot of that, pretty consistently. The world hasn't ended as a result. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
On Thu, 19 Jul 2007, Jens Axboe wrote: On Wed, Jul 18 2007, Andrew Morton wrote: On Mon, 16 Jul 2007 18:15:40 +0200 Geert Uytterhoeven [EMAIL PROTECTED] wrote: From: Geert Uytterhoeven [EMAIL PROTECTED] Add a Disk Storage Driver for the PS3: Your patchset significantly hits powerpc, scsi and block. So who gets to merge this? Jens? James? Paul? Me, I guess ;) I think Paul was going to take it, or at least Geert hinted as such. Yep, but as I heard Paul is on holidays, I was just going to send it to Andrew anyway. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
Hi Andrew,
On Wed, 18 Jul 2007, Andrew Morton wrote:
On Mon, 16 Jul 2007 18:15:40 +0200
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
From: Geert Uytterhoeven [EMAIL PROTECTED]
Add a Disk Storage Driver for the PS3:
Your patchset significantly hits powerpc, scsi and block. So who gets to
merge this? Jens? James? Paul?
Me, I guess ;)
As Paul is on holidays, please take it. The PS3 storage driver core support is
already in mainline, but the actual drivers aren't, as Paul was waiting for
acks from the maintainers.
BTW, do you prefer incremental patches for the comments below, or an update of
the full patchset?
+#define KERNEL_SECTOR_SIZE 512
Sigh. We have at least ten separate definitions of SECTOR_SIZE none of
them in the right place. Cleanup opportunity for someone.
Will replace by 512 resp. 9, as per Jens' suggestion.
+struct ps3disk_private {
+ spinlock_t lock;/* Request queue spinlock */
+ struct request_queue *queue;
+ struct gendisk *gendisk;
+ unsigned int blocking_factor;
+ struct request *req;
+ u64 raw_capacity;
+ unsigned char model[ATA_ID_PROD_LEN+1];
+};
+#define ps3disk_priv(dev) ((dev)-sbd.core.driver_data)
hm, this code has ata all over it and actually uses a libata #define (at
least) but there is no Kconfig dependency on ATA. Fair enough, I guess,
but a bit funny-looking.
I needed the definitions just for drive identification.
+static void ps3disk_scatter_gather(struct ps3_storage_device *dev,
+ struct request *req, int gather)
+{
+ unsigned int sectors = 0, offset = 0;
Local variable `sectors' doesn't do anything.
Good catch!
+static int ps3disk_submit_request_sg(struct ps3_storage_device *dev,
+struct request *req)
+{
+ struct ps3disk_private *priv = ps3disk_priv(dev);
+ int write = rq_data_dir(req), res;
+ const char *op = write ? write : read;
+ u64 start_sector, sectors;
+ unsigned int region_id = dev-regions[dev-region_idx].id;
So we're ignoring the sector_t stuff. I guess it's 64-bit only. Still, it
might be nice to use sector_t for consistency, readability and possible
future 32-bitness?
I used u64 as they're directly passed to hypervisor calls and that's what the
hypervisor calls take.
BTW, Cell will never support a 32-bit kernel, as lots of on-chip stuff lies
outside the 32-bit address space.
+#ifdef DEBUG
+ unsigned int n = 0;
+ struct bio *bio;
+ rq_for_each_bio(bio, req)
+ n++;
I'm surprised that the block core doesn't have a helper to count the number
of bios in a request.
Please prefer to put a blank line between end-of-locals and start-of-code.
Done.
+ dev_dbg(dev-sbd.core,
+ %s:%u: %s req has %u bios for %lu sectors %lu hard sectors\n,
+ __func__, __LINE__, op, n, req-nr_sectors,
+ req-hard_nr_sectors);
+#endif
+
+ start_sector = req-sector*priv-blocking_factor;
+ sectors = req-nr_sectors*priv-blocking_factor;
s/*/ * /. checkpatch missed this.
Will change (yes, checkpatch missed it).
I suspect you didn't run cehckpatch anyway.
I did ;-)
Please run checkpatch.
All it complains about is (bogus) asm/firmware.h and a single too long line I
don't want to break.
+/* ATA helpers copied from drivers/ata/libata-core.c */
ooh, bad person.
I didn't have much choice, as most of it was static and I don't need the full
libata core anyway.
If I would factor it out, any good suggestion where to put the factored out
code?
+ ps3disk_identify(dev);
ps3disk_identify() can return an error?
Sending storage commands may fail, but being unable to identify the disk isn't
fatal, as it's just for informational purposes.
+static int ps3disk_remove(struct ps3_system_bus_device *_dev)
+{
+ struct ps3_storage_device *dev = to_ps3_storage_device(_dev-core);
+ struct ps3disk_private *priv = ps3disk_priv(dev);
+
+ __clear_bit(priv-gendisk-first_minor / PS3DISK_MINORS,
+ ps3disk_mask);
I see no locking here which makes this __clear_bit and the above __set_bit
non-racy?
Were .probe()/.remove() made concurrent again? I thought that idea was dropped
because it caused too many problems?
+ kfree(priv);
+ ps3disk_priv(dev) = NULL;
I suspect this nulling here will just hide any bugs? If we're going to
write anything there, probably 0xdeadbeef would be better?
Hmm, earlier reviewers explicitly asked for putting it there...
Thanks for your comments!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division
Re: [patch 1/3] ps3: Disk Storage Driver
On Thu, 19 Jul 2007 10:57:53 +0200 (CEST) Geert Uytterhoeven [EMAIL
PROTECTED] wrote:
Hi Andrew,
On Wed, 18 Jul 2007, Andrew Morton wrote:
On Mon, 16 Jul 2007 18:15:40 +0200
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
From: Geert Uytterhoeven [EMAIL PROTECTED]
Add a Disk Storage Driver for the PS3:
Your patchset significantly hits powerpc, scsi and block. So who gets to
merge this? Jens? James? Paul?
Me, I guess ;)
As Paul is on holidays, please take it.
OK.
The PS3 storage driver core support is
already in mainline, but the actual drivers aren't, as Paul was waiting for
acks from the maintainers.
BTW, do you prefer incremental patches for the comments below, or an update of
the full patchset?
Incremental is preferred, but I convert replacement patches into
incremental patches at about 10Hz nowadays. Whatever's easier.
(Actually, if it's a replacement patch then only I get to see the
incremental patch, and the incremental patch is more reviewer-friendly).
I didn't have much choice, as most of it was static and I don't need the full
libata core anyway.
If I would factor it out, any good suggestion where to put the factored out
code?
Take it up with Jeff, please. If you're keen. It isn't a lot of code.
+static int ps3disk_remove(struct ps3_system_bus_device *_dev)
+{
+ struct ps3_storage_device *dev = to_ps3_storage_device(_dev-core);
+ struct ps3disk_private *priv = ps3disk_priv(dev);
+
+ __clear_bit(priv-gendisk-first_minor / PS3DISK_MINORS,
+ ps3disk_mask);
I see no locking here which makes this __clear_bit and the above __set_bit
non-racy?
Were .probe()/.remove() made concurrent again? I thought that idea was dropped
because it caused too many problems?
I don't _think_ there's any global exclusion on -probe calls. For a
particular driver instance it's hard to see how these thigns can run
concurrently, dunno. I guess two hotunplugs coud happen concurrently.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
On Thu, 19 Jul 2007 10:57:53 +0200 (CEST), Geert Uytterhoeven [EMAIL PROTECTED] wrote: Were .probe()/.remove() made concurrent again? I thought that idea was dropped because it caused too many problems? Well, for a given device, -probe()/-remove() are locked by dev-sem, so that there cannot be two probes/removes for the same device at the same time. However, if you have multiple hotplug events pending at the same time, it depends on your bus whether it does some serialization or whether it allows multiple probes/removes running for different devices. (Initial probing of a bus and probing of all devices with a new driver is done serialized again, I think that's what you're referring to.) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
On Thu, 19 Jul 2007 11:36:31 +0200 (CEST), Geert Uytterhoeven [EMAIL PROTECTED] wrote: We have a probe thread that checks for new storage devices and adds them to the bus with ps3_system_bus_device_register(), which calls device_register(). I guess the actual bus probe() routine gets called through the notifier call chain? That's where I got lost... No, -probe() is called from device_register() directly. If you just have one probe thread, you should have enough serialization. (Unless you're doing something interesting from the bus_notifier, which is called via the notifier chain before -probe()...) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
On Thu, 19 Jul 2007 14:13:33 +0200 (CEST), Geert Uytterhoeven [EMAIL PROTECTED] wrote: Any chance this will change? I already added a mutex to ps3disk to protect against this. Probably not in the near future. A mutex looks like a good idea though, since one never knows (and the driver core generally doesn't make many guarantees regarding serialization). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
On Jul 16 2007 18:15, Geert Uytterhoeven wrote: Add a Disk Storage Driver for the PS3: - Implemented as a block device driver with a dynamic major - Disk names (and partitions) are of the format ps3d%c(%u) - Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor doesn't support scatter-gather I wonder what virtualization has to do with a block device driver? Jan -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
On Wed, 18 Jul 2007, Jan Engelhardt wrote: On Jul 16 2007 18:15, Geert Uytterhoeven wrote: Add a Disk Storage Driver for the PS3: - Implemented as a block device driver with a dynamic major - Disk names (and partitions) are of the format ps3d%c(%u) - Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor doesn't support scatter-gather I wonder what virtualization has to do with a block device driver? On the PS3, storage devices are virtualized by the hypervisor (yes, the PS3 runs all OSes under a hypervisor). With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/3] ps3: Disk Storage Driver
On Mon, 16 Jul 2007 18:15:40 +0200
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
From: Geert Uytterhoeven [EMAIL PROTECTED]
Add a Disk Storage Driver for the PS3:
Your patchset significantly hits powerpc, scsi and block. So who gets to
merge this? Jens? James? Paul?
Me, I guess ;)
- Implemented as a block device driver with a dynamic major
- Disk names (and partitions) are of the format ps3d%c(%u)
- Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
doesn't support scatter-gather
...
--- /dev/null
+++ b/drivers/block/ps3disk.c
@@ -0,0 +1,624 @@
+/*
+ * PS3 Disk Storage Driver
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include linux/ata.h
+#include linux/blkdev.h
+
+#include asm/lv1call.h
+#include asm/ps3stor.h
+#include asm/firmware.h
+
+
+#define DEVICE_NAME ps3disk
+
+#define BOUNCE_SIZE (64*1024)
+
+#define PS3DISK_MAX_DISKS16
+#define PS3DISK_MINORS 16
+
+#define KERNEL_SECTOR_SIZE 512
Sigh. We have at least ten separate definitions of SECTOR_SIZE none of
them in the right place. Cleanup opportunity for someone.
+
+#define PS3DISK_NAME ps3d%c
+
+
+struct ps3disk_private {
+ spinlock_t lock;/* Request queue spinlock */
+ struct request_queue *queue;
+ struct gendisk *gendisk;
+ unsigned int blocking_factor;
+ struct request *req;
+ u64 raw_capacity;
+ unsigned char model[ATA_ID_PROD_LEN+1];
+};
+#define ps3disk_priv(dev)((dev)-sbd.core.driver_data)
hm, this code has ata all over it and actually uses a libata #define (at
least) but there is no Kconfig dependency on ATA. Fair enough, I guess,
but a bit funny-looking.
+static void ps3disk_scatter_gather(struct ps3_storage_device *dev,
+struct request *req, int gather)
+{
+ unsigned int sectors = 0, offset = 0;
+ struct bio *bio;
+ sector_t sector;
+ struct bio_vec *bvec;
+ unsigned int i = 0, j;
+ size_t size;
+ void *buf;
+
+ rq_for_each_bio(bio, req) {
+ sector = bio-bi_sector;
+ dev_dbg(dev-sbd.core,
+ %s:%u: bio %u: %u segs %u sectors from %lu\n,
+ __func__, __LINE__, i, bio_segments(bio),
+ bio_sectors(bio), sector);
+ bio_for_each_segment(bvec, bio, j) {
+ size = bio_cur_sectors(bio)*KERNEL_SECTOR_SIZE;
+ buf = __bio_kmap_atomic(bio, j, KM_IRQ0);
+ if (gather)
+ memcpy(dev-bounce_buf+offset, buf, size);
+ else
+ memcpy(buf, dev-bounce_buf+offset, size);
+ offset += size;
+ flush_kernel_dcache_page(bio_iovec_idx(bio,
j)-bv_page);
+ __bio_kunmap_atomic(bio, KM_IRQ0);
+ }
+ sectors += bio_sectors(bio);
+ i++;
+ }
+}
Local variable `sectors' doesn't do anything.
+static int ps3disk_submit_request_sg(struct ps3_storage_device *dev,
+ struct request *req)
+{
+ struct ps3disk_private *priv = ps3disk_priv(dev);
+ int write = rq_data_dir(req), res;
+ const char *op = write ? write : read;
+ u64 start_sector, sectors;
+ unsigned int region_id = dev-regions[dev-region_idx].id;
So we're ignoring the sector_t stuff. I guess it's 64-bit only. Still, it
might be nice to use sector_t for consistency, readability and possible
future 32-bitness?
+#ifdef DEBUG
+ unsigned int n = 0;
+ struct bio *bio;
+ rq_for_each_bio(bio, req)
+ n++;
I'm surprised that the block core doesn't have a helper to count the number
of bios in a request.
Please prefer to put a blank line between end-of-locals and start-of-code.
+ dev_dbg(dev-sbd.core,
+ %s:%u: %s req has %u bios for %lu sectors %lu hard sectors\n,
+ __func__, __LINE__, op, n, req-nr_sectors,
+ req-hard_nr_sectors);
+#endif
+
+ start_sector = req-sector*priv-blocking_factor;
+ sectors = req-nr_sectors*priv-blocking_factor;
[patch 1/3] ps3: Disk Storage Driver
From: Geert Uytterhoeven [EMAIL PROTECTED]
Add a Disk Storage Driver for the PS3:
- Implemented as a block device driver with a dynamic major
- Disk names (and partitions) are of the format ps3d%c(%u)
- Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
doesn't support scatter-gather
CC: Geoff Levand [EMAIL PROTECTED]
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
Acked-by: Jens Axboe [EMAIL PROTECTED]
---
v4:
- Replace KM_USER0 by KM_IRQ0 (all kmap routines are either called from an
interrupt handler or from .request_fn())
- Add a call to flush_kernel_dcache_page() before kunmap in routines that
write to buffers
v3:
- Cleanup #includes
- Kill PS3DISK_MAJOR, always use zero to obtain a dynamic major
- Group LV1 API related stuff
- Kill empty ps3disk_open
- Reset ps3disk_priv(dev) to NULL during cleanup
- Move call to put_disk() down
- Pass the interrupt handler to ps3stor_setup(), so it doesn't have to be
overridden later
- Fold ps3disk_read_write_sectors() into ps3disk_submit_request_sg()
- Identify the hard drive capacity and model name during probing
v2:
- Don't use `default y' in Kconfig
- Remove the thread for handling requests
- Set up sysfs links between block device and PS3 system device:
o /sys/block/ps3da/device - ../../devices/ps3_system/sb_02
o /sys/devices/ps3_system/sb_02/block:ps3da - ../../../block/ps3da
- Fix all FIXMEs
- Implement proper barrier support
- Call add_disk_randomness()
- Add a test to verify we are running on a PS3
- Fix error path in ps3disk_init()
- Fix cleanup order in ps3disk_exit()
arch/powerpc/platforms/ps3/Kconfig | 10
drivers/block/Makefile |1
drivers/block/ps3disk.c| 624 +
3 files changed, 635 insertions(+)
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -102,4 +102,14 @@ config PS3_STORAGE
depends on PPC_PS3
tristate
+config PS3_DISK
+ tristate PS3 Disk Storage Driver
+ depends on PPC_PS3 BLOCK
+ select PS3_STORAGE
+ help
+ Include support for the PS3 Disk Storage.
+
+ This support is required to access the PS3 hard disk.
+ In general, all users will say Y or M.
+
endmenu
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_VIODASD) += viodasd.o
obj-$(CONFIG_BLK_DEV_SX8) += sx8.o
obj-$(CONFIG_BLK_DEV_UB) += ub.o
+obj-$(CONFIG_PS3_DISK) += ps3disk.o
--- /dev/null
+++ b/drivers/block/ps3disk.c
@@ -0,0 +1,624 @@
+/*
+ * PS3 Disk Storage Driver
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include linux/ata.h
+#include linux/blkdev.h
+
+#include asm/lv1call.h
+#include asm/ps3stor.h
+#include asm/firmware.h
+
+
+#define DEVICE_NAMEps3disk
+
+#define BOUNCE_SIZE(64*1024)
+
+#define PS3DISK_MAX_DISKS 16
+#define PS3DISK_MINORS 16
+
+#define KERNEL_SECTOR_SIZE 512
+
+
+#define PS3DISK_NAME ps3d%c
+
+
+struct ps3disk_private {
+ spinlock_t lock;/* Request queue spinlock */
+ struct request_queue *queue;
+ struct gendisk *gendisk;
+ unsigned int blocking_factor;
+ struct request *req;
+ u64 raw_capacity;
+ unsigned char model[ATA_ID_PROD_LEN+1];
+};
+#define ps3disk_priv(dev) ((dev)-sbd.core.driver_data)
+
+
+#define LV1_STORAGE_SEND_ATA_COMMAND (2)
+#define LV1_STORAGE_ATA_HDDOUT (0x23)
+
+struct lv1_ata_cmnd_block {
+ u16 features;
+ u16 sector_count;
+ u16 LBA_low;
+ u16 LBA_mid;
+ u16 LBA_high;
+ u8 device;
+ u8 command;
+ u32 is_ext;
+ u32 proto;
+ u32 in_out;
+ u32 size;
+ u64 buffer;
+ u32 arglen;
+};
+
+enum lv1_ata_proto {
+ NON_DATA_PROTO = 0,
+ PIO_DATA_IN_PROTO = 1,
+ PIO_DATA_OUT_PROTO = 2,
+ DMA_PROTO = 3
+};
+
+enum lv1_ata_in_out {
+ DIR_WRITE = 0, /* memory - device */
+ DIR_READ = 1/* device - memory */
+};
+
+static int ps3disk_major;
+
+
+static struct
