SuperHyway bus support
PATCH 1/1 SuperHyway bus support
This adds support for the SuperHyway bus currently used by sh64 and also used by newer sh4a cores. This just adds the common bus support, with things like bus scanning being architecture dependent. sh64 presently makes use of this for its DMAC, with further device support planned.
I've added this under drivers/sh/superhyway/ as there are some other sh-specific buses that I intend to add under drivers/sh/ at a later point. Some of the sh dma code is also intended for consolidation there so sh64 can use it as well.
Against current BK. Comments appreciated.
drivers/Makefile +1 -0
@@ -60,3 +59,4 @@ obj-$(CONFIG_CPU_FREQ) += cpufreq/ obj-$(CONFIG_MMC) += mmc/ obj-y += firmware/ +obj-$(CONFIG_SUPERH) += sh/
drivers/sh/Makefile +6 -0
@@ -0,0 +1,6 @@ +# +# Makefile for the SuperH specific drivers. +# + +obj-$(CONFIG_SUPERHYWAY) += superhyway/ +
drivers/sh/superhyway/Makefile +18 -0
@@ -0,0 +1,18 @@ +# +# Makefile for the SuperHyway bus drivers. +# + +obj-$(CONFIG_SUPERHYWAY) += superhyway.o +obj-$(CONFIG_SYSFS) += superhyway-sysfs.o + +clean-files := devlist.h + +$(obj)/superhyway.o: $(obj)/devlist.h + +quiet_cmd_devlist = GEN $@ + cmd_devlist = sed -e 's/^\#.*$$//g;s/^[ ].*$$//g;/^$$/d; \ + s/\(0x.*\) / { \1, /g;s/$$/ },/' < $< > $@ + +$(obj)/devlist.h: $(src)/superhyway.ids + $(call cmd,devlist) +
drivers/sh/superhyway/superhyway-sysfs.c +50 -0
50 lines not on this page · raw message
drivers/sh/superhyway/superhyway.c +234 -0
234 lines not on this page · raw message
drivers/sh/superhyway/superhyway.ids +13 -0
@@ -0,0 +1,13 @@ +# +# This list is a compilation of SuperHyway module IDs and +# their associated "pretty" names. +# + +0x0183 "SH-5 DMA controller" +0x1823 "SH-5 Debug module" +0x204f "SH-5 PCI bridge" +0x2184 "SH-5 External Memory Interface" +0x2185 "SH-5 Flash ROM Interface" +0x448f "SH-5 Peripheral bridge" +0x51e2 "SH-5 CPU (SH5-101) core" +
include/linux/superhyway.h +96 -0
96 lines not on this page · raw message
Quoted 4 lines · Paul Mundt
This adds support for the SuperHyway bus currently used by sh64 and also used by newer sh4a cores. This just adds the common bus support, with things like bus scanning being architecture dependent. sh64 presently makes use of this for its DMAC, with further device support planned.
So it looks like you are just adding a fake "bus" driver and then manually adding the bus devices to the root device. Why not just complete the conversion and register the real devices properly?
A few other comments on the patch:
Quoted 10 lines
drivers/sh/superhyway/Makefile +7
-0@@ -0,0 +1,18 @@ +# +# Makefile for the SuperHyway bus drivers. +# + +obj-$(CONFIG_SUPERHYWAY) += superhyway.o +obj-$(CONFIG_SYSFS) += superhyway-sysfs.o +
drivers/sh/superhyway/Makefile line 17
Quoted 10 lines
drivers/sh/superhyway/Makefile +10
-0+clean-files := devlist.h + +$(obj)/superhyway.o: $(obj)/devlist.h + +quiet_cmd_devlist = GEN $@ + cmd_devlist = sed -e 's/^\#.*$$//g;s/^[ ].*$$//g;/^$$/d; \ + s/\(0x.*\) / { \1, /g;s/$$/ },/' < $< > $@ + +$(obj)/devlist.h: $(src)/superhyway.ids + $(call cmd,devlist)
We are depreciating device lists within the kernel. The PCI device list will be going away sometime in the future, and we shouldn't be adding new ones. Can't this just be determined from userspace instead like 'lspci' and 'lsusb' do?
drivers/sh/superhyway/Makefile
Quoted 11 lines
drivers/sh/superhyway/Makefile +11
-0+void superhyway_create_sysfs_files(struct superhyway_device *s) +{ + struct device *dev = &s->dev; + + device_create_file(dev, &dev_attr_perr_flags); + device_create_file(dev, &dev_attr_merr_flags); + device_create_file(dev, &dev_attr_mod_vers); + device_create_file(dev, &dev_attr_mod_id); + device_create_file(dev, &dev_attr_bot_mb); + device_create_file(dev, &dev_attr_top_mb); + device_create_file(dev, &dev_attr_resource);
Can you use a default attribute list instead of manually creating the files individually? Also, I don't see the code that removes these attributes. Please don't rely on the sysfs function of automatically cleaning up the attributes when the device is removed, that might not work in the future.
drivers/sh/superhyway/Makefile
Quoted 3 lines
drivers/sh/superhyway/Makefile +3
-0+static struct superhyway_bus superhyway_bus = { + .name = "SuperHyway bus", +};
Please don't add sysfs directories that have spaces in them. How about "superhyway_bus" instead?
Quoted 37 lines
drivers/sh/superhyway/Makefile +37
-0+/** + * superhyway_add_device - Add a SuperHyway module + * @mod_id: Module ID (taken from MODULE.VCR.MOD_ID). + * @base: Physical address where module is mapped. + * @vcr: VCR value. + * + * This is responsible for adding a new SuperHyway module. This sets up a new + * struct superhyway_device for the module being added. Each one of @mod_id, + * @base, and @vcr are registered with the new device for further use + * elsewhere. + * + * Devices are initially added in the order that they are scanned (from the + * top-down of the memory map), and are assigned an ID based on the order that + * they are added. Any manual addition of a module will thus get the ID after + * the devices already discovered regardless of where it resides in memory. + * + * Further work can and should be done in superhyway_scan_bus(), to be sure + * that any new modules are properly discovered and subsequently registered. + */ +int superhyway_add_device(unsigned int mod_id, unsigned long base, + unsigned long long vcr) +{ + struct superhyway_device *dev; + int ret; + + dev = kmalloc(sizeof(struct superhyway_device), GFP_KERNEL); + if (!dev) + return -ENOMEM; + + memset(dev, 0, sizeof(struct superhyway_device)); + + dev->id.id = mod_id; + sprintf(dev->name, "SuperHyway device %04x\n", dev->id.id); + + superhyway_name_device(dev); + + dev->vcr = *((struct vcr_info *)(&vcr));
drivers/sh/superhyway/Makefile
Quoted 10 lines
drivers/sh/superhyway/Makefile +10
-0+ dev->resource.name = dev->name; + dev->resource.start = base; + dev->resource.end = dev->resource.start + 0x01000000; + dev->dev.parent = &superhyway_bus.dev; + dev->dev.bus = &superhyway_bus_type; + + sprintf(dev->dev.bus_id, "%02x", superhyway_devices); + + pr_info(" 0x%04x (%s) control block at 0x%08lx\n", + dev->id.id, dev->pretty_name, dev->resource.start);
Shouldn't this be a debug message?
drivers/sh/superhyway/Makefile
Quoted 8 lines
drivers/sh/superhyway/Makefile +8
-0+static void __exit superhyway_bus_exit(void) +{ + struct superhyway_device *dev; + + list_for_each_entry(dev, &superhyway_bus.devices, node) { + device_unregister(&dev->dev); + kfree(dev); + }
Ick, not good, userspace could still have a reference on the device through sysfs. Don't kfree it here, do it in the release function (which you need to do.)
Also, why have a local list of devices and not just use the list the driver core provides for you?
drivers/sh/superhyway/Makefile
Quoted 5 lines
drivers/sh/superhyway/Makefile +5
-0+struct superhyway_device { + struct list_head node; + + char name[32]; + char pretty_name[64];
Do you need the name and pretty_name?
drivers/sh/superhyway/Makefile
Quoted 5 lines
drivers/sh/superhyway/Makefile +5
-0+struct superhyway_bus { + struct list_head devices; + struct device dev; + char name[16]; +};
Is the name really necessary?
drivers/sh/superhyway/Makefile
Quoted 9 lines
drivers/sh/superhyway/Makefile +9
-0+/* drivers/sh/superhyway/superhyway-sysfs.c */ +#ifdef CONFIG_SYSFS +void superhyway_create_sysfs_files(struct superhyway_device *); +#else +void superhyway_create_sysfs_files(struct superhyway_device *s) +{ + /* Nothing to do */ +} +#endif
Why ifdef this function? That should not be needed.
thanks,
greg k-h
Quoted 4 lines · Greg KH
So it looks like you are just adding a fake "bus" driver and then manually adding the bus devices to the root device. Why not just complete the conversion and register the real devices properly?
Can you elaborate on what you mean by registering the "real devices properly"?
Quoted 5 lines
We are depreciating device lists within the kernel. The PCI device list will be going away sometime in the future, and we shouldn't be adding new ones. Can't this just be determined from userspace instead like 'lspci' and 'lsusb' do?
Yes, this can be done in userspace, so that stuff can be dropped.
Quoted 9 lines
Quoted 9 lines
drivers/sh/superhyway/superhyway-sysfs.c +9
-0+void superhyway_create_sysfs_files (struct superhyway_device *s) +{ +struct device *dev = &s->dev; + +device_create_file (dev, &dev_attr_perr_flags); +device_create_file (dev, &dev_attr_merr_flags); +device_create_file (dev, &dev_attr_mod_vers); +device_create_file (dev, &dev_attr_mod_id); +device_create_file (dev, &dev_attr_bot_mb);
Quoted 9 lines
drivers/sh/superhyway/superhyway-sysfs.c line 48
Quoted 2 lines
drivers/sh/superhyway/superhyway-sysfs.c +2
-0+device_create_file (dev, &dev_attr_top_mb); +device_create_file (dev, &dev_attr_resource);Can you use a default attribute list instead of manually creating the files individually? Also, I don't see the code that removes these attributes. Please don't rely on the sysfs function of automatically cleaning up the attributes when the device is removed, that might not work in the future.
Yes, I can use the dev_attrs for this. Thanks for pointing that out.
Quoted 7 lines
drivers/sh/superhyway/superhyway.c line 33
Quoted 3 lines
drivers/sh/superhyway/superhyway.c +3
-0+static struct superhyway_bus superhyway_bus = { + .name ="SuperHyway bus" , +};Please don't add sysfs directories that have spaces in them. How about "
superhyway_bus" instead?
Ok.
Quoted 5 lines
drivers/sh/superhyway/superhyway.c line 91
Quoted 2 lines
drivers/sh/superhyway/superhyway.c +2
-0+pr_info (" 0x%04x (%s) control block at 0x%08lx\n" , + dev->id.id, dev->pretty_name, dev->resource.start);Shouldn't this be a debug message?
Yes, probably. Though with the devlist in userspace I suppose it's not overly useful to have here anyways.
Quoted 4 lines
Quoted 4 lines
drivers/sh/superhyway/superhyway.c +4
-0+static void __exit superhyway_bus_exit(void) +{ +struct superhyway_device *dev; +
Quoted 9 lines
drivers/sh/superhyway/superhyway.c line 220
Quoted 4 lines
drivers/sh/superhyway/superhyway.c +4
-0+list_for_each_entry (dev, &superhyway_bus.devices, node) { +device_unregister (&dev->dev); +kfree (dev); + }Ick, not good, userspace could still have a reference on the device through sysfs. Don't kfree it here, do it in the release function (which you need to do.)
Ok.
Quoted 3 lines
Also, why have a local list of devices and not just use the list the driver core provides for you?
Probably because I wasn't aware that the driver core provided one. Now that I see the bus_for_each_xxx() stuff I'll drop the list and use that instead.
Quoted 8 lines
include/linux/superhyway.h line 58
Quoted 5 lines
include/linux/superhyway.h +5
-0+struct superhyway_device { +struct list_head node; + +char name[32 ]; +char pretty_name[64 ];Do you need the name and
pretty_name?
No, the pretty_name was only added for the devlist. I'll clean that up.
Quoted 8 lines
include/linux/superhyway.h line 75
Quoted 5 lines
include/linux/superhyway.h +5
-0+struct superhyway_bus { +struct list_head devices; +struct device dev; +char name[16 ]; +};Is the name really necessary?
Probably not. With that and the list gone I can drop this struct entirely and just have the root device as a struct device.
Quoted 12 lines
include/linux/superhyway.h line 93
Quoted 9 lines
include/linux/superhyway.h +9
-0+/* drivers/sh/superhyway/superhyway-sysfs.c */ +#ifdef CONFIG_SYSFS +void superhyway_create_sysfs_files (struct superhyway_device *); +#else +void superhyway_create_sysfs_files (struct superhyway_device *s) +{ +/* Nothing to do */ +} +#endif Why ifdef this function? That should not be needed.
superhyway_add_device() calls this. We don't want to assume that CONFIG_SYSFS will always be enabled. I can move the ifdef in to superhyway_add_device() if you think it would be cleaner. (And this is needed as we happen to have superhyway_create_sysfs_files() defined in superhyway-sysfs.c which is only compiled in when CONFIG_SYSFS is set, and I would rather not link this in unconditionally).
Thanks for looking at this, I'll post a cleaned up version shortly.
Quoted 6 lines · Paul Mundt
Quoted 3 lines
Also, why have a local list of devices and not just use the list the driver core provides for you?
Probably because I wasn't aware that the driver core provided one. Now that I see the
bus_for_each_xxx()stuff I'll drop the list and use that instead.
I dropped this entirely as the release() stuff did what I was looking for..
Quoted 1 line
Thanks for looking at this, I'll post a cleaned up version shortly.
Here it is against current BK.. let me know if you have any other issues.
drivers/Makefile | 1 drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 47 +++++++ drivers/sh/superhyway/superhyway.c | 205 +++++++++++++++++++++++++++++++ 5 files changed, 266 insertions(+)
drivers/Makefile +1 -0
@@ -62,3 +62,4 @@ obj-$(CONFIG_INFINIBAND) += infiniband/ obj-y += firmware/ obj-$(CONFIG_CRYPTO) += crypto/ +obj-$(CONFIG_SUPERH) += sh/
drivers/sh/Makefile +6 -0
@@ -0,0 +1,6 @@ +# +# Makefile for the SuperH specific drivers. +# + +obj-$(CONFIG_SUPERHYWAY) += superhyway/ +
drivers/sh/superhyway/Makefile +7 -0
@@ -0,0 +1,7 @@ +# +# Makefile for the SuperHyway bus drivers. +# + +obj-$(CONFIG_SUPERHYWAY) += superhyway.o +obj-$(CONFIG_SYSFS) += superhyway-sysfs.o +
drivers/sh/superhyway/superhyway.c +205 -0
205 lines not on this page · raw message
drivers/sh/superhyway/superhyway-sysfs.c +47 -0
47 lines not on this page · raw message
Quoted 13 lines · Paul Mundt
Quoted 6 lines · Paul Mundt
Quoted 3 lines
Also, why have a local list of devices and not just use the list the driver core provides for you?
Probably because I wasn't aware that the driver core provided one. Now that I see the
bus_for_each_xxx()stuff I'll drop the list and use that instead.I dropped this entirely as the
release()stuff did what I was looking for..Quoted 1 line
Thanks for looking at this, I'll post a cleaned up version shortly.
Here it is against current BK.. let me know if you have any other issues.
Quoted 7 lines
Signed-off-by Paul Mundt <[email protected]>drivers/Makefile | 1 drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 47 +++++++ drivers/sh/superhyway/superhyway.c | 205 +++++++++++++++++++++++++++++++
No Kconfig file to enable this option?
drivers/sh/superhyway/superhyway.c line 26
Quoted 3 lines
drivers/sh/superhyway/superhyway.c +3
-0+static struct device superhyway_bus_device = { + .bus_id ="superhyway" , +};
This device doesn't have a release function, as it's tied to the module. Are you sure it's race free? :)
drivers/sh/superhyway/superhyway.c line 83
Quoted 3 lines
drivers/sh/superhyway/superhyway.c +3
-0+static int __init superhyway_init (void ) +{ +extern int superhyway_scan_bus (void );
This should go in a .h file somewhere.
drivers/sh/superhyway/superhyway.c line 204
Quoted 4 lines
drivers/sh/superhyway/superhyway.c +4
-0+EXPORT_SYMBOL (superhyway_bus_type); +EXPORT_SYMBOL (superhyway_add_device); +EXPORT_SYMBOL (superhyway_register_driver); +EXPORT_SYMBOL (superhyway_unregister_driver);
Did you forget a .h file with these function prototypes?
Other than that, looks a whole lot better, nice job.
greg k-h
Quoted 8 lines · Greg KH
Quoted 5 lines
drivers/Makefile | 1 drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 47 +++++++ drivers/sh/superhyway/superhyway.c | 205 +++++++++++++++++++++++++++++++No
Kconfigfile to enable this option?
It's in the arch-specific code, it will go in with the next sh64 update. Though I can always add a drivers/sh/Kconfig that does this too (I didn't think it was worth the trouble for a single option at the moment).
Quoted 7 lines
Review
Quoted 3 lines
(quoted diff) +3
-0+static struct device superhyway_bus_device = { + .bus_id = "superhyway", +};This device doesn't have a release function, as it's tied to the module. Are you sure it's race free? :)
I wasn't aware that it needed one. I copied this mostly verbatim from the platform bus code where there is also no release function.
Looking at some of the other bus drivers, I see that w1 makes use of a release function for its bus device, but it does this only for completion handling in a kernel thread, which clearly has no application here.
The only thing I would see a release routine being useful for in this case would be for refcounting, but the driver core already does that for us. Is there something obvious that I'm missing?
Quoted 6 lines
Review
Quoted 3 lines
(quoted diff) +3
-0+static int __init superhyway_init(void) +{ + extern int superhyway_scan_bus(void);This should go in a .h file somewhere.
Done.
Quoted 7 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+EXPORT_SYMBOL(superhyway_bus_type); +EXPORT_SYMBOL(superhyway_add_device); +EXPORT_SYMBOL(superhyway_register_driver); +EXPORT_SYMBOL(superhyway_unregister_driver);Did you forget a .h file with these function prototypes?
Yes, it would seem that way. Here we go again:
drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 45 ++++++ drivers/sh/superhyway/superhyway.c | 201 +++++++++++++++++++++++++++++++ include/linux/superhyway.h | 79 ++++++++++++ 5 files changed, 338 insertions(+)
drivers/sh/Makefile +6 -0
@@ -0,0 +1,6 @@ +# +# Makefile for the SuperH specific drivers. +# + +obj-$(CONFIG_SUPERHYWAY) += superhyway/ +
drivers/sh/superhyway/Makefile +7 -0
@@ -0,0 +1,7 @@ +# +# Makefile for the SuperHyway bus drivers. +# + +obj-$(CONFIG_SUPERHYWAY) += superhyway.o +obj-$(CONFIG_SYSFS) += superhyway-sysfs.o +
drivers/sh/superhyway/superhyway.c +201 -0
201 lines not on this page · raw message
drivers/sh/superhyway/superhyway-sysfs.c +45 -0
45 lines not on this page · raw message
include/linux/superhyway.h +79 -0
79 lines not on this page · raw message
Quoted 4 lines · Paul Mundt
Quoted 2 lines
Did you forget a .h file with these function prototypes?
Yes, it would seem that way. Here we go again:
I haven't heard anything else from you about this since the last update, do you have any more issues with this code? If not, can you merge this?
Quoted 7 lines · Paul Mundt
Quoted 4 lines · Paul Mundt
Quoted 2 lines
Did you forget a .h file with these function prototypes?
Yes, it would seem that way. Here we go again:
I haven't heard anything else from you about this since the last update, do you have any more issues with this code? If not, can you merge this?
I don't have any more issues, it's in my TODO queue, and I should get to it tonight or tomorrow (supposed to be working on my house this week, not merging patches...)
thanks,
greg k-h
Quoted 8 lines · Paul Mundt
Yes, it would seem that way. Here we go again:
drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 45 ++++++ drivers/sh/superhyway/superhyway.c | 201 +++++++++++++++++++++++++++++++ include/linux/superhyway.h | 79 ++++++++++++ 5 files changed, 338 insertions(+)
Sorry for taking so long on this. I've added it to my trees and it will show up in the next -mm releases. After 2.6.11 is out I'll forward it on to Linus.
thanks,
greg k-h
Quoted 6 lines · Greg KH
Quoted 6 lines
drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 45 ++++++ drivers/sh/superhyway/superhyway.c | 201 +++++++++++++++++++++++++++++++ include/linux/superhyway.h | 79 ++++++++++++ 5 files changed, 338 insertions(+)
Why does it need a .h file in include/linux/?
Only use include/linux/* for .h files which is used by other parts of the kernel.
[I've lost the original mail - so cannot see the actual source].
Sam
Quoted 8 lines · Sam Ravnborg
Quoted 6 lines · Greg KH
Quoted 6 lines
drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 45 ++++++ drivers/sh/superhyway/superhyway.c | 201 +++++++++++++++++++++++++++++++ include/linux/superhyway.h | 79 ++++++++++++ 5 files changed, 338 insertions(+)
Quoted 5 lines
Why does it need a .h file in
include/linux/?
Only useinclude/linux/*for .h files which is used by other parts of the kernel.[I've lost the original mail - so cannot see the actual source].
Other parts of the kernel will use that .h file when they register themselves with the sh bus. Right Paul?
thanks,
greg k-h
Quoted 9 lines · Greg KH
Quoted 8 lines · Sam Ravnborg
Quoted 6 lines · Greg KH
Quoted 6 lines
drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 45 ++++++ drivers/sh/superhyway/superhyway.c | 201 +++++++++++++++++++++++++++++++ include/linux/superhyway.h | 79 ++++++++++++ 5 files changed, 338 insertions(+)
Quoted 9 lines
Quoted 5 lines
Why does it need a .h file in
include/linux/?
Only useinclude/linux/*for .h files which is used by other parts of the kernel.[I've lost the original mail - so cannot see the actual source].
Other parts of the kernel will use that .h file when they register themselves with the sh bus. Right Paul?
Yes, that's correct. Any driver with a SuperHyway device will need it, and this will be on multiple architectures (sh and sh64).
Quoted 10 lines · Greg KH
Quoted 8 lines · Paul Mundt
Yes, it would seem that way. Here we go again:
drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 45 ++++++ drivers/sh/superhyway/superhyway.c | 201 +++++++++++++++++++++++++++++++ include/linux/superhyway.h | 79 ++++++++++++ 5 files changed, 338 insertions(+)
Quoted 4 lines
Sorry for taking so long on this. I've added it to my trees and it will show up in the next -mm releases. After 2.6.11 is out I'll forward it on to Linus.
There's an older version of this patch currently still in -mm, so this patch won't actually apply there directly. I can send an incremental -mm patch that gets the current -mm implementation up to date with these changes (or if Andrew can back out the current patch in -mm and apply this one in place, that works too).
Quoted 15 lines · Paul Mundt
Quoted 10 lines · Greg KH
Quoted 8 lines · Paul Mundt
Yes, it would seem that way. Here we go again:
drivers/sh/Makefile | 6 drivers/sh/superhyway/Makefile | 7 + drivers/sh/superhyway/superhyway-sysfs.c | 45 ++++++ drivers/sh/superhyway/superhyway.c | 201 +++++++++++++++++++++++++++++++ include/linux/superhyway.h | 79 ++++++++++++ 5 files changed, 338 insertions(+)Quoted 4 lines
Sorry for taking so long on this. I've added it to my trees and it will show up in the next -mm releases. After 2.6.11 is out I'll forward it on to Linus.
Quoted 5 lines
There's an older version of this patch currently still in -mm, so this patch won't actually apply there directly. I can send an incremental -mm patch that gets the current -mm implementation up to date with these changes (or if Andrew can back out the current patch in -mm and apply this one in place, that works too).
If Andrew could just drop the patch in his tree, he will get this version in through the bk-drivers tree that he pulls into the -mm releases.
thanks,
greg k-h