diff mbox

[1/3] SCSI: Allow platform-specific code to be run against the SCSI tree

Message ID 1247518987-10818-1-git-send-email-mjg@redhat.com
State Not Applicable
Delegated to: David Miller
Headers show

Commit Message

Matthew Garrett July 13, 2009, 9:03 p.m. UTC
In certain cases (such as ACPI) we want to be able to associate
platform-specific data against the SCSI device tree. Handling this
properly requires the ability to run platform code at SCSI init time.
This patch adds stub functions that can be overridden if the platform
defines CONFIG_SCSI_PLATFORM.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
 drivers/scsi/Kconfig     |    4 ++++
 drivers/scsi/scsi.c      |    6 ++++++
 drivers/scsi/scsi_priv.h |    1 -
 include/scsi/scsi.h      |   10 ++++++++++
 4 files changed, 20 insertions(+), 1 deletions(-)

Comments

Matthew Garrett Aug. 10, 2009, 1:38 p.m. UTC | #1
On Mon, Jul 13, 2009 at 10:03:05PM +0100, Matthew Garrett wrote:
> In certain cases (such as ACPI) we want to be able to associate
> platform-specific data against the SCSI device tree. Handling this
> properly requires the ability to run platform code at SCSI init time.
> This patch adds stub functions that can be overridden if the platform
> defines CONFIG_SCSI_PLATFORM.

James, any thoughts on this?
James Bottomley Aug. 10, 2009, 2:55 p.m. UTC | #2
On Mon, 2009-08-10 at 14:38 +0100, Matthew Garrett wrote:
> On Mon, Jul 13, 2009 at 10:03:05PM +0100, Matthew Garrett wrote:
> > In certain cases (such as ACPI) we want to be able to associate
> > platform-specific data against the SCSI device tree. Handling this
> > properly requires the ability to run platform code at SCSI init time.
> > This patch adds stub functions that can be overridden if the platform
> > defines CONFIG_SCSI_PLATFORM.
> 
> James, any thoughts on this?

Sorry, I'd thought this had all moved to libata so I'd stopped paying
attention ... why are extra bits in SCSI necessary?

James


--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Matthew Garrett Aug. 10, 2009, 2:58 p.m. UTC | #3
On Mon, Aug 10, 2009 at 02:55:25PM +0000, James Bottomley wrote:
> On Mon, 2009-08-10 at 14:38 +0100, Matthew Garrett wrote:
> > On Mon, Jul 13, 2009 at 10:03:05PM +0100, Matthew Garrett wrote:
> > > In certain cases (such as ACPI) we want to be able to associate
> > > platform-specific data against the SCSI device tree. Handling this
> > > properly requires the ability to run platform code at SCSI init time.
> > > This patch adds stub functions that can be overridden if the platform
> > > defines CONFIG_SCSI_PLATFORM.
> > 
> > James, any thoughts on this?
> 
> Sorry, I'd thought this had all moved to libata so I'd stopped paying
> attention ... why are extra bits in SCSI necessary?

They're SCSI as far as the device tree is concerned, so the glue 
callbacks have to be registered from the SCSI layer. The only 
implementation so far is for ACPI and only covers libata, but it could 
potentially also be used to tie bay devices to the ofw tree on 
openfirmware systems.
James Bottomley Aug. 10, 2009, 4:03 p.m. UTC | #4
On Mon, 2009-08-10 at 15:58 +0100, Matthew Garrett wrote:
> On Mon, Aug 10, 2009 at 02:55:25PM +0000, James Bottomley wrote:
> > On Mon, 2009-08-10 at 14:38 +0100, Matthew Garrett wrote:
> > > On Mon, Jul 13, 2009 at 10:03:05PM +0100, Matthew Garrett wrote:
> > > > In certain cases (such as ACPI) we want to be able to associate
> > > > platform-specific data against the SCSI device tree. Handling this
> > > > properly requires the ability to run platform code at SCSI init time.
> > > > This patch adds stub functions that can be overridden if the platform
> > > > defines CONFIG_SCSI_PLATFORM.
> > > 
> > > James, any thoughts on this?
> > 
> > Sorry, I'd thought this had all moved to libata so I'd stopped paying
> > attention ... why are extra bits in SCSI necessary?
> 
> They're SCSI as far as the device tree is concerned, so the glue 
> callbacks have to be registered from the SCSI layer. The only 
> implementation so far is for ACPI and only covers libata, but it could 
> potentially also be used to tie bay devices to the ofw tree on 
> openfirmware systems.

It's hard for me to comment without seeing the scsi_platform_register
code, but it strikes me that the only SCSI piece it's using is the
scsi_bus ... what else is SCSI specific in there?

James


--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Matthew Garrett Aug. 10, 2009, 4:11 p.m. UTC | #5
On Mon, Aug 10, 2009 at 11:03:07AM -0500, James Bottomley wrote:
> On Mon, 2009-08-10 at 15:58 +0100, Matthew Garrett wrote:
> > They're SCSI as far as the device tree is concerned, so the glue 
> > callbacks have to be registered from the SCSI layer. The only 
> > implementation so far is for ACPI and only covers libata, but it could 
> > potentially also be used to tie bay devices to the ofw tree on 
> > openfirmware systems.
> 
> It's hard for me to comment without seeing the scsi_platform_register
> code, but it strikes me that the only SCSI piece it's using is the
> scsi_bus ... what else is SCSI specific in there?

http://lkml.org/lkml/2009/7/13/286 is the ACPI implementation. I guess 
that it could be done entirely in libata if the bus structure is 
exported, but that does then limit it to ata - the code would need to be 
duplicated if anyone wants to bind scsi devices. I've no real 
preference, but this was the implementation suggested when I last posted 
this stuff back in 2005 or so.
diff mbox

Patch

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 9c23122..7537d0b 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -34,6 +34,10 @@  config SCSI_DMA
 	bool
 	default n
 
+config SCSI_PLATFORM
+	bool
+	default n
+
 config SCSI_TGT
 	tristate "SCSI target support"
 	depends on SCSI && EXPERIMENTAL
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 2de5f3a..da02f64 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -1332,12 +1332,17 @@  static int __init init_scsi(void)
 	error = scsi_sysfs_register();
 	if (error)
 		goto cleanup_sysctl;
+	error = scsi_platform_register();
+	if (error)
+		goto cleanup_sysfs;
 
 	scsi_netlink_init();
 
 	printk(KERN_NOTICE "SCSI subsystem initialized\n");
 	return 0;
 
+cleanup_sysfs:
+	scsi_sysfs_unregister();
 cleanup_sysctl:
 	scsi_exit_sysctl();
 cleanup_hosts:
@@ -1356,6 +1361,7 @@  cleanup_queue:
 static void __exit exit_scsi(void)
 {
 	scsi_netlink_exit();
+	scsi_platform_unregister();
 	scsi_sysfs_unregister();
 	scsi_exit_sysctl();
 	scsi_exit_hosts();
diff --git a/drivers/scsi/scsi_priv.h b/drivers/scsi/scsi_priv.h
index 021e503..bce4a70 100644
--- a/drivers/scsi/scsi_priv.h
+++ b/drivers/scsi/scsi_priv.h
@@ -131,7 +131,6 @@  extern int scsi_sysfs_target_initialize(struct scsi_device *);
 extern struct scsi_transport_template blank_transport_template;
 extern void __scsi_remove_device(struct scsi_device *);
 
-extern struct bus_type scsi_bus_type;
 extern struct attribute_group *scsi_sysfs_shost_attr_groups[];
 
 /* scsi_netlink.c */
diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
index 084478e..f349c83 100644
--- a/include/scsi/scsi.h
+++ b/include/scsi/scsi.h
@@ -140,6 +140,16 @@  struct scsi_cmnd;
 
 #define SCSI_MAX_VARLEN_CDB_SIZE 260
 
+#ifdef CONFIG_SCSI_PLATFORM
+extern int scsi_platform_register(void);
+extern void scsi_platform_unregister(void);
+#else
+static inline int scsi_platform_register(void) { return 0; };
+static inline void scsi_platform_unregister(void) { };
+#endif
+
+extern struct bus_type scsi_bus_type;
+
 /* defined in T10 SCSI Primary Commands-2 (SPC2) */
 struct scsi_varlen_cdb_hdr {
 	u8 opcode;        /* opcode always == VARIABLE_LENGTH_CMD */