[PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure

[PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure

[Janusz Krzysztofik]

A call to request_mem_region() has been introduced in the omap-gpio
driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
"gpio/omap: Use devm_ API and add request_mem_region"). This change
prevented the Amstrad Delta NAND driver, which was doing the same in
order to take control over OMAP MPU I/O lines that the NAND device hangs
off, from loading successfully.

There is another driver, omap-keypad, which also manipulates OMAP MPUIO
registers, but has never been calling request_mem_region() on startup,
so it's not affected by the change in the gpio-omap and works correctly.

Drop request_mem_region() call and related bits from ams-delta NAND
driver.

Created and tested against linux-3.4-rc3.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
 drivers/mtd/nand/ams-delta.c |   12 +-----------
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 7341695..af76da3 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -212,18 +212,11 @@ static int __devinit ams_delta_init(struct platform_device *pdev)
 	/* Link the private data with the MTD structure */
 	ams_delta_mtd->priv = this;
 
-	if (!request_mem_region(res->start, resource_size(res),
-			dev_name(&pdev->dev))) {
-		dev_err(&pdev->dev, "request_mem_region failed\n");
-		err = -EBUSY;
-		goto out_free;
-	}
-
 	io_base = ioremap(res->start, resource_size(res));
 	if (io_base == NULL) {
 		dev_err(&pdev->dev, "ioremap failed\n");
 		err = -EIO;
-		goto out_release_io;
+		goto out_free;
 	}
 
 	this->priv = io_base;
@@ -271,8 +264,6 @@ out_gpio:
 	platform_set_drvdata(pdev, NULL);
 	gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
 	iounmap(io_base);
-out_release_io:
-	release_mem_region(res->start, resource_size(res));
 out_free:
 	kfree(ams_delta_mtd);
  out:
@@ -293,7 +284,6 @@ static int __devexit ams_delta_cleanup(struct platform_device *pdev)
 	gpio_free_array(_mandatory_gpio, ARRAY_SIZE(_mandatory_gpio));
 	gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
 	iounmap(io_base);
-	release_mem_region(res->start, resource_size(res));
 
 	/* Free the MTD device structure */
 	kfree(ams_delta_mtd);
-- 
1.7.3.4

Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote:
> A call to request_mem_region() has been introduced in the omap-gpio
> driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
> "gpio/omap: Use devm_ API and add request_mem_region"). This change
> prevented the Amstrad Delta NAND driver, which was doing the same in
> order to take control over OMAP MPU I/O lines that the NAND device hangs
> off, from loading successfully.
> 
> There is another driver, omap-keypad, which also manipulates OMAP MPUIO
> registers, but has never been calling request_mem_region() on startup,
> so it's not affected by the change in the gpio-omap and works correctly.
> 
> Drop request_mem_region() call and related bits from ams-delta NAND
> driver.
> 
> Created and tested against linux-3.4-rc3.
> 
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>

How about race conditions? Where is the guarantee that these 2 drivers
won't affect each other when doing I/O at the same time to the same HW
resources?

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure

[Janusz Krzysztofik]

Dnia środa, 25 kwietnia 2012 18:13:38 Artem Bityutskiy pisze:
> On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote:
> > A call to request_mem_region() has been introduced in the omap-gpio
> > driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
> > "gpio/omap: Use devm_ API and add request_mem_region"). This change
> > prevented the Amstrad Delta NAND driver, which was doing the same in
> > order to take control over OMAP MPU I/O lines that the NAND device 
hangs
> > off, from loading successfully.
> > 
> > There is another driver, omap-keypad, which also manipulates OMAP 
MPUIO
> > registers, but has never been calling request_mem_region() on 
startup,
> > so it's not affected by the change in the gpio-omap and works 
correctly.
> > 
> > Drop request_mem_region() call and related bits from ams-delta NAND
> > driver.
> > 
> > Created and tested against linux-3.4-rc3.
> > 
> > Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> 
> How about race conditions? Where is the guarantee that these 2 drivers
> won't affect each other when doing I/O at the same time to the same HW
> resources?

Both drivers use separate subsets of registers that belong to the OMAP1 
MPU I/O device, but are used for controlling different sets of I/O pins. 
The NAND driver reads/writes the folowing registers:
- OMAP_MPUIO_INPUT_LATCH,
- OMAP_MPUIO_OUTPUT,
- OMAP_MPUIO_IO_CNTL,
while the keypad driver - the following:
- OMAP_MPUIO_KBR_LATCH,
- OMAP_MPUIO_KBC,
- OMAP_MPUIO_KBD_MASKIT
- OMAP_MPUIO_GPIO_DEBOUNCING.
Both subsets are non-overlapping, and we rely on the drivers being free 
of bugs and doing their job correctly, not stepping on each others' 
feet, I guess.

Thanks,
Janusz

Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote:
> Both drivers use separate subsets of registers that belong to the OMAP1 
> MPU I/O device, but are used for controlling different sets of I/O pins. 
> The NAND driver reads/writes the folowing registers:
> - OMAP_MPUIO_INPUT_LATCH,
> - OMAP_MPUIO_OUTPUT,
> - OMAP_MPUIO_IO_CNTL,
> while the keypad driver - the following:
> - OMAP_MPUIO_KBR_LATCH,
> - OMAP_MPUIO_KBC,
> - OMAP_MPUIO_KBD_MASKIT
> - OMAP_MPUIO_GPIO_DEBOUNCING.
> Both subsets are non-overlapping, and we rely on the drivers being free 
> of bugs and doing their job correctly, not stepping on each others' 
> feet, I guess.

First of all, I think this information should be in the commit message.
Also, some sort of comment in the driver code would be nice.

If locking the memory region is too coarse approach, the should have a
small separate omap-specific MPUIO subsystem which will be used by
drivers to access MPUIO?

Another question - should request_mem_region() be also removed from the
omap-gpio driver then? I think it is more sensible to put a comment
there that it is sharing MPIO with other drivers,  instead of having an
illusion of exclusive memory region ownership.

But this is up to the OMAP community - I can take this patch to my
l2-mtd tree if you get an ack from Tony or other OMAP guys.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure

[Janusz Krzysztofik]

Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze:
> On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote:
> > Both drivers use separate subsets of registers that belong to the 
OMAP1 
> > MPU I/O device, but are used for controlling different sets of I/O 
pins. 
> > The NAND driver reads/writes the folowing registers:
> > - OMAP_MPUIO_INPUT_LATCH,
> > - OMAP_MPUIO_OUTPUT,
> > - OMAP_MPUIO_IO_CNTL,
> > while the keypad driver - the following:
> > - OMAP_MPUIO_KBR_LATCH,
> > - OMAP_MPUIO_KBC,
> > - OMAP_MPUIO_KBD_MASKIT
> > - OMAP_MPUIO_GPIO_DEBOUNCING.
> > Both subsets are non-overlapping, and we rely on the drivers being 
free 
> > of bugs and doing their job correctly, not stepping on each others' 
> > feet, I guess.
> 
> First of all, I think this information should be in the commit 
message.
> Also, some sort of comment in the driver code would be nice.
> 
> If locking the memory region is too coarse approach, the should have a
> small separate omap-specific MPUIO subsystem which will be used by
> drivers to access MPUIO?
> 
> Another question - should request_mem_region() be also removed from 
the
> omap-gpio driver then? I think it is more sensible to put a comment
> there that it is sharing MPIO with other drivers,  instead of having 
an
> illusion of exclusive memory region ownership.
> 
> But this is up to the OMAP community - I can take this patch to my
> l2-mtd tree if you get an ack from Tony or other OMAP guys.

Tony,
Would I get your Ack for this fix if I extend the commit message as Artem 
suggested? If not, what do you think should be a correct way to fix the 
regression?

Thanks,
Janusz

Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure

[Tony Lindgren]

Hi,

* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [120430 11:15]:
> Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze:
> > On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote:
> > > Both drivers use separate subsets of registers that belong to the 
> OMAP1 
> > > MPU I/O device, but are used for controlling different sets of I/O 
> pins. 
> > > The NAND driver reads/writes the folowing registers:
> > > - OMAP_MPUIO_INPUT_LATCH,
> > > - OMAP_MPUIO_OUTPUT,
> > > - OMAP_MPUIO_IO_CNTL,
> > > while the keypad driver - the following:
> > > - OMAP_MPUIO_KBR_LATCH,
> > > - OMAP_MPUIO_KBC,
> > > - OMAP_MPUIO_KBD_MASKIT
> > > - OMAP_MPUIO_GPIO_DEBOUNCING.
> > > Both subsets are non-overlapping, and we rely on the drivers being 
> free 
> > > of bugs and doing their job correctly, not stepping on each others' 
> > > feet, I guess.
> > 
> > First of all, I think this information should be in the commit 
> message.
> > Also, some sort of comment in the driver code would be nice.
> > 
> > If locking the memory region is too coarse approach, the should have a
> > small separate omap-specific MPUIO subsystem which will be used by
> > drivers to access MPUIO?
> > 
> > Another question - should request_mem_region() be also removed from 
> the
> > omap-gpio driver then? I think it is more sensible to put a comment
> > there that it is sharing MPIO with other drivers,  instead of having 
> an
> > illusion of exclusive memory region ownership.
> > 
> > But this is up to the OMAP community - I can take this patch to my
> > l2-mtd tree if you get an ack from Tony or other OMAP guys.
> 
> Tony,
> Would I get your Ack for this fix if I extend the commit message as Artem 
> suggested? If not, what do you think should be a correct way to fix the 
> regression?

Well how about adding some exported functions to drivers/gpio/gpio_omap.c
like omap_mpuio_latch?

For the regression fix, if you guys want to do what Janusz is suggesting,
then assuming the patch description also contains some decent long term
plan to properly fix it:

Acked-by: Tony Lindgren <tony@atomide.com>

Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure

[Janusz Krzysztofik]

On Fri, 4 May 2012 10:11:25 Tony Lindgren wrote:
> Hi,
> 
> * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [120430 11:15]:
> > Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze:
> > > On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote:
> > > > Both drivers use separate subsets of registers that belong to 
the 
> > OMAP1 
> > > > MPU I/O device, but are used for controlling different sets of 
I/O 
> > pins. 
> > > > The NAND driver reads/writes the folowing registers:
> > > > - OMAP_MPUIO_INPUT_LATCH,
> > > > - OMAP_MPUIO_OUTPUT,
> > > > - OMAP_MPUIO_IO_CNTL,
> > > > while the keypad driver - the following:
> > > > - OMAP_MPUIO_KBR_LATCH,
> > > > - OMAP_MPUIO_KBC,
> > > > - OMAP_MPUIO_KBD_MASKIT
> > > > - OMAP_MPUIO_GPIO_DEBOUNCING.
> > > > Both subsets are non-overlapping, and we rely on the drivers 
being 
> > free 
> > > > of bugs and doing their job correctly, not stepping on each 
others' 
> > > > feet, I guess.
> > > 
> > > First of all, I think this information should be in the commit 
> > message.
> > > Also, some sort of comment in the driver code would be nice.
> > > 
> > > If locking the memory region is too coarse approach, the should 
have a
> > > small separate omap-specific MPUIO subsystem which will be used by
> > > drivers to access MPUIO?
> > > 
> > > Another question - should request_mem_region() be also removed 
from 
> > the
> > > omap-gpio driver then? I think it is more sensible to put a 
comment
> > > there that it is sharing MPIO with other drivers,  instead of 
having 
> > an
> > > illusion of exclusive memory region ownership.
> > > 
> > > But this is up to the OMAP community - I can take this patch to my
> > > l2-mtd tree if you get an ack from Tony or other OMAP guys.
> > 
> > Tony,
> > Would I get your Ack for this fix if I extend the commit message as 
Artem 
> > suggested? If not, what do you think should be a correct way to fix 
the 
> > regression?
> 
> Well how about adding some exported functions to 
drivers/gpio/gpio_omap.c
> like omap_mpuio_latch?
> 
> For the regression fix, if you guys want to do what Janusz is 
suggesting,
> then assuming the patch description also contains some decent long 
term
> plan to properly fix it:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Thanks. Now that we know you prefer to keep the memory requested from 
inside the gpio-omap, which I was about to suggest to drop back as an 
alternative fix, I'll try to cook a new description for my patch, and 
perhaps add a comment replacing the request_mem_region function removed 
from the ams-delta NAND driver, in order to satisfy both yours and 
Artem's comments in a few days.

Regards,
Janusz

[PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure

[Janusz Krzysztofik]

A call to request_mem_region() has been introduced in the omap-gpio
driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
"gpio/omap: Use devm_ API and add request_mem_region"). This change
prevented the Amstrad Delta NAND driver, which was doing the same in
order to take control over OMAP MPU I/O lines that the NAND device hangs
off, from loading successfully.

The I/O lines and corresponding registers used by the NAND driver are a
subset of those used for the GPIO function. Then, to avoid run time
collisions, all MPUIO GPIO lines should be marked as requested while
initializing the NAND driver, and vice versa, a single MPUIO GPIO line
already requested before the NAND driver initialization is attempted
should prevent the NAND device from being started successfully.

There is another driver, omap-keypad, which also manipulates MPUIO
registers, but has never been calling request_mem_region() on startup,
so it's not affected by the change in the gpio-omap and works correctly.
It uses the depreciated omap_read/write functions for accessing MPUIO
registers. Unlike the NAND driver, these I/O lines and registers are
separate from those used by the GPIO driver. However, both register sets
are non-contiguous and overlapping, so it would be impractical to
request the two sets separately, one from the gpio-omap, the other form
the omap-keypad driver.

In order to solve all these issues correctly, a solution first suggested
by Artem Bityutskiy, then closer specified by Tony Lindgren while they
commented the initial version of this fix, should be implemented. The
gpio-omap driver should export a few functions which would allow the
other two drivers to access MPUIO registers in a safe manner instead of
trying to manage them in parallel to the GPIO driver.  However, such a
big change, affecting 3 drivers all together, is not suitable for the rc
cycle, and should be prepared for the merge window.  Then, an
alternative solution is proposed as a regression fix.

For the ams-delta NAND driver to initialize correctly in coexistence
with the changed GPIO driver, drop the request_mem_region() call from
the former, especially as this call is going to be removed while the
long-term solution is implemented.

Tested on Amstrad Delta.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Acked-by: Tony Lindgren <tony@atomide.com>
---
Artem, Tony,
I hope the changelog message is now good enough to make you satisfied,
and render the Tony's Ack valid.

Changes against initial version:
* a comment replacing the removed function call added,
* more details on the three drivers coexistance and possible interaction
  provided,
* a hopefuly decent long-term plan to properly fix all identified issues
  proposed.

 drivers/mtd/nand/ams-delta.c |   16 ++++++----------
 1 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 7341695..358162a 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -212,18 +212,17 @@ static int __devinit ams_delta_init(struct platform_device *pdev)
 	/* Link the private data with the MTD structure */
 	ams_delta_mtd->priv = this;
 
-	if (!request_mem_region(res->start, resource_size(res),
-			dev_name(&pdev->dev))) {
-		dev_err(&pdev->dev, "request_mem_region failed\n");
-		err = -EBUSY;
-		goto out_free;
-	}
+	/*
+	 * Don't try to request the memory region from here,
+	 * it should have been already requested from the
+	 * gpio-omap driver and requesting it again would fail.
+	 */
 
 	io_base = ioremap(res->start, resource_size(res));
 	if (io_base == NULL) {
 		dev_err(&pdev->dev, "ioremap failed\n");
 		err = -EIO;
-		goto out_release_io;
+		goto out_free;
 	}
 
 	this->priv = io_base;
@@ -271,8 +270,6 @@ out_gpio:
 	platform_set_drvdata(pdev, NULL);
 	gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
 	iounmap(io_base);
-out_release_io:
-	release_mem_region(res->start, resource_size(res));
 out_free:
 	kfree(ams_delta_mtd);
  out:
@@ -293,7 +290,6 @@ static int __devexit ams_delta_cleanup(struct platform_device *pdev)
 	gpio_free_array(_mandatory_gpio, ARRAY_SIZE(_mandatory_gpio));
 	gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
 	iounmap(io_base);
-	release_mem_region(res->start, resource_size(res));
 
 	/* Free the MTD device structure */
 	kfree(ams_delta_mtd);
-- 
1.7.3.4

Re: [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote:
> A call to request_mem_region() has been introduced in the omap-gpio
> driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
> "gpio/omap: Use devm_ API and add request_mem_region"). This change
> prevented the Amstrad Delta NAND driver, which was doing the same in
> order to take control over OMAP MPU I/O lines that the NAND device hangs
> off, from loading successfully.

Aiaiai found out that your patch adds this gcc warning:

--------------------------------------------------------------------------------

Successfully built configuration "l2_omap1_defconfig,arm,arm-unknown-linux-gnueabi-", results:

--- before_patching.log
+++ after_patching.log
@@ @@
+drivers/mtd/nand/ams-delta.c: In function 'ams_delta_cleanup':
+drivers/mtd/nand/ams-delta.c:285:19: warning: unused variable 'res' [-Wunused-variable]

--------------------------------------------------------------------------------


-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Tue, 2012-05-08 at 10:03 +0300, Artem Bityutskiy wrote:
> On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote:
> > A call to request_mem_region() has been introduced in the omap-gpio
> > driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
> > "gpio/omap: Use devm_ API and add request_mem_region"). This change
> > prevented the Amstrad Delta NAND driver, which was doing the same in
> > order to take control over OMAP MPU I/O lines that the NAND device hangs
> > off, from loading successfully.
> 
> Aiaiai found out that your patch adds this gcc warning:
> 
> --------------------------------------------------------------------------------
> 
> Successfully built configuration "l2_omap1_defconfig,arm,arm-unknown-linux-gnueabi-", results:
> 
> --- before_patching.log
> +++ after_patching.log
> @@ @@
> +drivers/mtd/nand/ams-delta.c: In function 'ams_delta_cleanup':
> +drivers/mtd/nand/ams-delta.c:285:19: warning: unused variable 'res' [-Wunused-variable]
> 
> --------------------------------------------------------------------------------

But I've fixed this up and pushed to l2-mtd.git. From the commit message
I have an impression that you are not going to implement that longer
term plan. Dunno if Tony has a plan to force someone to do this by
blocking some changes which are not urgent fixes. Hmm? :-)

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure

[Janusz Krzysztofik]

Dnia wtorek, 8 maja 2012 10:11:46 Artem Bityutskiy pisze:
> On Tue, 2012-05-08 at 10:03 +0300, Artem Bityutskiy wrote:
> > On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote:
> > > A call to request_mem_region() has been introduced in the omap-
gpio
> > > driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
> > > "gpio/omap: Use devm_ API and add request_mem_region"). This 
change
> > > prevented the Amstrad Delta NAND driver, which was doing the same 
in
> > > order to take control over OMAP MPU I/O lines that the NAND device 
hangs
> > > off, from loading successfully.
> > 
> > Aiaiai found out that your patch adds this gcc warning:
> > 
> > 
--------------------------------------------------------------------------------
> > 
> > Successfully built configuration "l2_omap1_defconfig,arm,arm-unknown-
linux-gnueabi-", results:
> > 
> > --- before_patching.log
> > +++ after_patching.log
> > @@ @@
> > +drivers/mtd/nand/ams-delta.c: In function 'ams_delta_cleanup':
> > +drivers/mtd/nand/ams-delta.c:285:19: warning: unused variable 'res' 
[-Wunused-variable]
> > 
> > 
--------------------------------------------------------------------------------
> 
> But I've fixed this up and pushed to l2-mtd.git.

Many thanks for this.

> From the commit message
> I have an impression that you are not going to implement that longer
> term plan.

I just didn't state 'I'll do it for the next merge window' because my 
spare time resources are limited, and I've at least one set of changes 
to the Amstrad Delta code still waiting on my todo list.

I'll try to implement that long term plan as my spare time permits.

Thanks,
Janusz