[PATCH 0/3] clk: microchip: core: allow driver to be compiled with COMPILE_TEST

[PATCH 0/3] clk: microchip: core: allow driver to be compiled with COMPILE_TEST

[Brian Masney]

Here's a small series that lets us enable COMPILE_TEST for the pic32 clk
driver so that this driver can be compiled on all architectures in the
future to help avoid breakage.

Signed-off-by: Brian Masney <bmasney@redhat.com>
---
Brian Masney (3):
      clk: microchip: core: update to use div64_ul() instead of do_div()
      clk: microchip: core: change asm nop calls to nop()
      clk: microchip: core: allow driver to be compiled with COMPILE_TEST

 drivers/clk/microchip/Kconfig    |  2 +-
 drivers/clk/microchip/clk-core.c | 13 +++++++------
 2 files changed, 8 insertions(+), 7 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260222-clk-microchip-pic32-0e5b00f122a0

Best regards,
-- 
Brian Masney <bmasney@redhat.com>

[PATCH 1/3] clk: microchip: core: update to use div64_ul() instead of do_div()

[Brian Masney]

This driver is currently only compiled on 32-bit MIPS systems. When
compiling on 64-bit systems, the build fails with:

    WARNING: do_div() does a 64-by-32 division, please consider using
    div64_ul instead.

Let's update this to use div64_ul() in preparation for allowing this
driver to be compiled on all architectures.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601160758.bpkN4546-lkp@intel.com/
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
 drivers/clk/microchip/clk-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/microchip/clk-core.c b/drivers/clk/microchip/clk-core.c
index 692152b5094e00bf5acb19a67cf41e6c86b11f35..2e86ad846a66cd5487f5412c09ab0ad25ebe3f79 100644
--- a/drivers/clk/microchip/clk-core.c
+++ b/drivers/clk/microchip/clk-core.c
@@ -341,7 +341,7 @@ static void roclk_calc_div_trim(unsigned long rate,
 		div = parent_rate / (rate << 1);
 		frac = parent_rate;
 		frac <<= 8;
-		do_div(frac, rate);
+		frac = div64_ul(frac, rate);
 		frac -= (u64)(div << 9);
 
 		rodiv = (div > REFO_DIV_MASK) ? REFO_DIV_MASK : div;

-- 
2.53.0

Re: [PATCH 1/3] clk: microchip: core: update to use div64_ul() instead of do_div()

[David Laight]

On Sun, 22 Feb 2026 18:51:04 -0500
Brian Masney <bmasney@redhat.com> wrote:

> This driver is currently only compiled on 32-bit MIPS systems. When
> compiling on 64-bit systems, the build fails with:
> 
>     WARNING: do_div() does a 64-by-32 division, please consider using
>     div64_ul instead.
> 
> Let's update this to use div64_ul() in preparation for allowing this
> driver to be compiled on all architectures.

There are a log of 'long' in that code that hold clock frequencies.
I suspect they should be u32 (I think someone was scared that int might be 16bit).

> 
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601160758.bpkN4546-lkp@intel.com/
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
>  drivers/clk/microchip/clk-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/microchip/clk-core.c b/drivers/clk/microchip/clk-core.c
> index 692152b5094e00bf5acb19a67cf41e6c86b11f35..2e86ad846a66cd5487f5412c09ab0ad25ebe3f79 100644
> --- a/drivers/clk/microchip/clk-core.c
> +++ b/drivers/clk/microchip/clk-core.c
> @@ -341,7 +341,7 @@ static void roclk_calc_div_trim(unsigned long rate,
>  		div = parent_rate / (rate << 1);
>  		frac = parent_rate;
>  		frac <<= 8;
> -		do_div(frac, rate);
> +		frac = div64_ul(frac, rate);
>  		frac -= (u64)(div << 9);

Is that cast in the right place?
I suspect 'div' can't be large enough to need it, but it's presence makes
my wonder ...

	David

>  
>  		rodiv = (div > REFO_DIV_MASK) ? REFO_DIV_MASK : div;
> 

Re: [PATCH 1/3] clk: microchip: core: update to use div64_ul() instead of do_div()

[Brian Masney]

Hi David,

On Mon, Feb 23, 2026 at 09:09:48AM +0000, David Laight wrote:
> On Sun, 22 Feb 2026 18:51:04 -0500
> Brian Masney <bmasney@redhat.com> wrote:
> 
> > This driver is currently only compiled on 32-bit MIPS systems. When
> > compiling on 64-bit systems, the build fails with:
> > 
> >     WARNING: do_div() does a 64-by-32 division, please consider using
> >     div64_ul instead.
> > 
> > Let's update this to use div64_ul() in preparation for allowing this
> > driver to be compiled on all architectures.
> 
> There are a log of 'long' in that code that hold clock frequencies.
> I suspect they should be u32 (I think someone was scared that int might be 16bit).

Instead of calling:

    do_div(frac, rate);

Where frac is a u64, and rate is an unsigned long, I could just cast the
rate to a u32 like this:

    do_div(frac, (u32) rate);

Thoughts?

Brian


> 
> > 
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202601160758.bpkN4546-lkp@intel.com/
> > Signed-off-by: Brian Masney <bmasney@redhat.com>
> > ---
> >  drivers/clk/microchip/clk-core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/clk/microchip/clk-core.c b/drivers/clk/microchip/clk-core.c
> > index 692152b5094e00bf5acb19a67cf41e6c86b11f35..2e86ad846a66cd5487f5412c09ab0ad25ebe3f79 100644
> > --- a/drivers/clk/microchip/clk-core.c
> > +++ b/drivers/clk/microchip/clk-core.c
> > @@ -341,7 +341,7 @@ static void roclk_calc_div_trim(unsigned long rate,
> >  		div = parent_rate / (rate << 1);
> >  		frac = parent_rate;
> >  		frac <<= 8;
> > -		do_div(frac, rate);
> > +		frac = div64_ul(frac, rate);
> >  		frac -= (u64)(div << 9);
> 
> Is that cast in the right place?
> I suspect 'div' can't be large enough to need it, but it's presence makes
> my wonder ...
> 
> 	David
> 
> >  
> >  		rodiv = (div > REFO_DIV_MASK) ? REFO_DIV_MASK : div;
> > 
> 

Re: [PATCH 1/3] clk: microchip: core: update to use div64_ul() instead of do_div()

[David Laight]

On Tue, 24 Feb 2026 11:56:03 -0500
Brian Masney <bmasney@redhat.com> wrote:

> Hi David,
> 
> On Mon, Feb 23, 2026 at 09:09:48AM +0000, David Laight wrote:
> > On Sun, 22 Feb 2026 18:51:04 -0500
> > Brian Masney <bmasney@redhat.com> wrote:
> >   
> > > This driver is currently only compiled on 32-bit MIPS systems. When
> > > compiling on 64-bit systems, the build fails with:
> > > 
> > >     WARNING: do_div() does a 64-by-32 division, please consider using
> > >     div64_ul instead.
> > > 
> > > Let's update this to use div64_ul() in preparation for allowing this
> > > driver to be compiled on all architectures.  
> > 
> > There are a log of 'long' in that code that hold clock frequencies.
> > I suspect they should be u32 (I think someone was scared that int might be 16bit).  
> 
> Instead of calling:
> 
>     do_div(frac, rate);
> 
> Where frac is a u64, and rate is an unsigned long, I could just cast the
> rate to a u32 like this:
> 
>     do_div(frac, (u32) rate);
> 
> Thoughts?

That cast is horrid :-)

On x86 (32bit or 64bit) I'm not sure it makes any difference whether
you use do_div() or div64_ul().
Other architectures will be different.

I originally thought that do_div() was a simpler wrapper on the x86
divide instruction - so required that both the quotient and remainder
be 32bits. But Linus corrected me saying it had always generated a
64bit quotient.
So on 32bit div64_ul() is pretty much the same code with the same timings.
The 'optimised' (and unusual) parameter rules are also pretty much
a waste of time, div takes 38/41 clocks on a '386 (I happen to have the
book on my desk!) an extra register move wouldn't matter.

Divide doesn't get much faster, 64 by 32 speeds up a bit, but you
have to get to cannon lake or zen3 to get a significant improvement.

zen3+ execute the 128 by 64 divide only slightly slower than 64 by 32.
64bit Intel is another matter entirely.
Even coffee lake has:
                                    reciprocal
         u-ops  -- ports -- latency throughput
DIV r32  10 10  p0 p1 p5 p6   26        6
DIV r64  36 36  p0 p1 p5 p6  35-88    21-83
So the r64 (128 by 64) divide is a lot slower, and especially so
when it isn't really needed.

Both do_div() and div64_ul() do a 128 by 64 divide.
Even though do_div() would be likely faster using the 32bit sequence.
(Especially if the condition were fixed to that it used two divides
less often.)

Still not sure of the numeric domain of 'frac'.

	David

> 
> Brian
> 
> 
> >   
> > > 
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202601160758.bpkN4546-lkp@intel.com/
> > > Signed-off-by: Brian Masney <bmasney@redhat.com>
> > > ---
> > >  drivers/clk/microchip/clk-core.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/clk/microchip/clk-core.c b/drivers/clk/microchip/clk-core.c
> > > index 692152b5094e00bf5acb19a67cf41e6c86b11f35..2e86ad846a66cd5487f5412c09ab0ad25ebe3f79 100644
> > > --- a/drivers/clk/microchip/clk-core.c
> > > +++ b/drivers/clk/microchip/clk-core.c
> > > @@ -341,7 +341,7 @@ static void roclk_calc_div_trim(unsigned long rate,
> > >  		div = parent_rate / (rate << 1);
> > >  		frac = parent_rate;
> > >  		frac <<= 8;
> > > -		do_div(frac, rate);
> > > +		frac = div64_ul(frac, rate);
> > >  		frac -= (u64)(div << 9);  
> > 
> > Is that cast in the right place?
> > I suspect 'div' can't be large enough to need it, but it's presence makes
> > my wonder ...
> > 
> > 	David
> >   
> > >  
> > >  		rodiv = (div > REFO_DIV_MASK) ? REFO_DIV_MASK : div;
> > >   
> >   
> 

[PATCH 2/3] clk: microchip: core: change asm nop calls to nop()

[Brian Masney]

In preparation for allowing this driver to be compiled on all
architectures, convert the direct asm nop calls to use the
nop() function that's available.

Signed-off-by: Brian Masney <bmasney@redhat.com>
---
 drivers/clk/microchip/clk-core.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/microchip/clk-core.c b/drivers/clk/microchip/clk-core.c
index 2e86ad846a66cd5487f5412c09ab0ad25ebe3f79..4e90988f47d5d3a370bd1a8e74c5778e4f071038 100644
--- a/drivers/clk/microchip/clk-core.c
+++ b/drivers/clk/microchip/clk-core.c
@@ -3,6 +3,7 @@
  * Purna Chandra Mandal,<purna.mandal@microchip.com>
  * Copyright (C) 2015 Microchip Technology Inc.  All rights reserved.
  */
+#include <asm/barrier.h>
 #include <linux/clk-provider.h>
 #include <linux/delay.h>
 #include <linux/device.h>
@@ -77,11 +78,11 @@ static struct clk_hw *pic32_sclk_hw;
 /* add instruction pipeline delay while CPU clock is in-transition. */
 #define cpu_nop5()			\
 do {					\
-	__asm__ __volatile__("nop");	\
-	__asm__ __volatile__("nop");	\
-	__asm__ __volatile__("nop");	\
-	__asm__ __volatile__("nop");	\
-	__asm__ __volatile__("nop");	\
+	nop();				\
+	nop();				\
+	nop();				\
+	nop();				\
+	nop();				\
 } while (0)
 
 /* Perpheral bus clocks */

-- 
2.53.0

[PATCH 3/3] clk: microchip: core: allow driver to be compiled with COMPILE_TEST

[Brian Masney]

This driver currently only supports builds against a PIC32 target. To
avoid future breakage in the future, let's update the Kconfig and the
driver so that it can be built with COMPILE_TEST enabled.

Signed-off-by: Brian Masney <bmasney@redhat.com>
---
 drivers/clk/microchip/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/microchip/Kconfig b/drivers/clk/microchip/Kconfig
index 0c03b14699bf083361bb5be8be3cf5305c311549..2864250dcaf8e720695c5a884a5aaf2efde15a1a 100644
--- a/drivers/clk/microchip/Kconfig
+++ b/drivers/clk/microchip/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
 config COMMON_CLK_PIC32
-	def_bool COMMON_CLK && MACH_PIC32
+	def_bool COMMON_CLK && (MACH_PIC32 || COMPILE_TEST)
 
 config MCHP_CLK_MPFS
 	bool "Clk driver for PolarFire SoC"

-- 
2.53.0

Re: [PATCH 0/3] clk: microchip: core: allow driver to be compiled with COMPILE_TEST

[Conor Dooley]

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

On Sun, Feb 22, 2026 at 06:51:03PM -0500, Brian Masney wrote:
> Here's a small series that lets us enable COMPILE_TEST for the pic32 clk
> driver so that this driver can be compiled on all architectures in the
> future to help avoid breakage.

Why do you care about this platform? Originally I thought you cared cos
you were getting involved in clock subsystem stuff, but I see you doing
stuff with it in pinctrl etc. Is that just general cleanup work, or do
you actually have an interest in the platform?

Also, seeing "clk: microchip: core" in my inbox triggers me, cos the
stuff I work on uses "microchip: core" a lot for FPGA IP cores. Can we
do:

-- >8 --
From 5e972ac119c87257ce141382019f2b58ebd53359 Mon Sep 17 00:00:00 2001
From: Conor Dooley <conor.dooley@microchip.com>
Date: Tue, 24 Feb 2026 16:59:53 +0000
Subject: [PATCH] clk: microchip: rename clk-core to clk-pic32

clk-core is a confusingly generic name, since it is only used by a
single platform and it uses very similar naming to the "soft" IP cores
for use in FPGA fabric (CoreClock or similar is what that would be
called, although nothing like that exists right now) that the FPGA
business unit produces. Rename it to clk-pic32, matching the prefix
used by most functions in the driver. As far as I can tell, impact
on whatever users may (or may not...) exist for the platform is minimal
as it's built-in only and the functions are called directly from
clk-pic32mzda.c

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 drivers/clk/microchip/Makefile                    | 2 +-
 drivers/clk/microchip/{clk-core.c => clk-pic32.c} | 2 +-
 drivers/clk/microchip/{clk-core.h => clk-pic32.h} | 0
 drivers/clk/microchip/clk-pic32mzda.c             | 2 +-
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename drivers/clk/microchip/{clk-core.c => clk-pic32.c} (99%)
 rename drivers/clk/microchip/{clk-core.h => clk-pic32.h} (100%)

diff --git a/drivers/clk/microchip/Makefile b/drivers/clk/microchip/Makefile
index 13250e04e46cf..8e60bc1a03ae7 100644
--- a/drivers/clk/microchip/Makefile
+++ b/drivers/clk/microchip/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_COMMON_CLK_PIC32) += clk-core.o
+obj-$(CONFIG_COMMON_CLK_PIC32) += clk-pic32.o
 obj-$(CONFIG_PIC32MZDA) += clk-pic32mzda.o
 obj-$(CONFIG_MCHP_CLK_MPFS) += clk-mpfs.o
 obj-$(CONFIG_MCHP_CLK_MPFS) += clk-mpfs-ccc.o
diff --git a/drivers/clk/microchip/clk-core.c b/drivers/clk/microchip/clk-pic32.c
similarity index 99%
rename from drivers/clk/microchip/clk-core.c
rename to drivers/clk/microchip/clk-pic32.c
index 692152b5094e0..9d128fba2cdea 100644
--- a/drivers/clk/microchip/clk-core.c
+++ b/drivers/clk/microchip/clk-pic32.c
@@ -11,7 +11,7 @@
 #include <linux/iopoll.h>
 #include <linux/platform_data/pic32.h>
 
-#include "clk-core.h"
+#include "clk-pic32.h"
 
 /* OSCCON Reg fields */
 #define OSC_CUR_MASK		0x07
diff --git a/drivers/clk/microchip/clk-core.h b/drivers/clk/microchip/clk-pic32.h
similarity index 100%
rename from drivers/clk/microchip/clk-core.h
rename to drivers/clk/microchip/clk-pic32.h
diff --git a/drivers/clk/microchip/clk-pic32mzda.c b/drivers/clk/microchip/clk-pic32mzda.c
index 27599829ea40a..e11cbdd982a61 100644
--- a/drivers/clk/microchip/clk-pic32mzda.c
+++ b/drivers/clk/microchip/clk-pic32mzda.c
@@ -14,7 +14,7 @@
 #include <linux/platform_device.h>
 #include <asm/traps.h>
 
-#include "clk-core.h"
+#include "clk-pic32.h"
 
 /* FRC Postscaler */
 #define OSC_FRCDIV_MASK		0x07
-- 
2.51.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 0/3] clk: microchip: core: allow driver to be compiled with COMPILE_TEST

[Brian Masney]

On Tue, Feb 24, 2026 at 05:10:42PM +0000, Conor Dooley wrote:
> On Sun, Feb 22, 2026 at 06:51:03PM -0500, Brian Masney wrote:
> > Here's a small series that lets us enable COMPILE_TEST for the pic32 clk
> > driver so that this driver can be compiled on all architectures in the
> > future to help avoid breakage.
> 
> Why do you care about this platform? Originally I thought you cared cos
> you were getting involved in clock subsystem stuff, but I see you doing
> stuff with it in pinctrl etc. Is that just general cleanup work, or do
> you actually have an interest in the platform?

My sole interest is to clean up the clk driver, which spilled into
larger work to clean the include header to allow this driver to be
compiled on other architectures. If I was going to do this for the
clk driver, it wasn't that much work to do the other pic32 driver
cleanups while I was there.

Honestly, I hope to done with all of these pic32 drivers after what I
posted this week has been merged.

> Also, seeing "clk: microchip: core" in my inbox triggers me, cos the
> stuff I work on uses "microchip: core" a lot for FPGA IP cores. Can we
> do:
> 
> -- >8 --
> From 5e972ac119c87257ce141382019f2b58ebd53359 Mon Sep 17 00:00:00 2001
> From: Conor Dooley <conor.dooley@microchip.com>
> Date: Tue, 24 Feb 2026 16:59:53 +0000
> Subject: [PATCH] clk: microchip: rename clk-core to clk-pic32
> 
> clk-core is a confusingly generic name, since it is only used by a
> single platform and it uses very similar naming to the "soft" IP cores
> for use in FPGA fabric (CoreClock or similar is what that would be
> called, although nothing like that exists right now) that the FPGA
> business unit produces. Rename it to clk-pic32, matching the prefix
> used by most functions in the driver. As far as I can tell, impact
> on whatever users may (or may not...) exist for the platform is minimal
> as it's built-in only and the functions are called directly from
> clk-pic32mzda.c
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

That sounds good to me. Please post that as a separate patch.

Brian

Re: [PATCH 0/3] clk: microchip: core: allow driver to be compiled with COMPILE_TEST

[Conor Dooley]

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

On Tue, Feb 24, 2026 at 12:27:27PM -0500, Brian Masney wrote:
> On Tue, Feb 24, 2026 at 05:10:42PM +0000, Conor Dooley wrote:
> > On Sun, Feb 22, 2026 at 06:51:03PM -0500, Brian Masney wrote:
> > > Here's a small series that lets us enable COMPILE_TEST for the pic32 clk
> > > driver so that this driver can be compiled on all architectures in the
> > > future to help avoid breakage.
> > 
> > Why do you care about this platform? Originally I thought you cared cos
> > you were getting involved in clock subsystem stuff, but I see you doing
> > stuff with it in pinctrl etc. Is that just general cleanup work, or do
> > you actually have an interest in the platform?
> 
> My sole interest is to clean up the clk driver, which spilled into
> larger work to clean the include header to allow this driver to be
> compiled on other architectures. If I was going to do this for the
> clk driver, it wasn't that much work to do the other pic32 driver
> cleanups while I was there.
> 
> Honestly, I hope to done with all of these pic32 drivers after what I
> posted this week has been merged.

Not to pooh pooh your efforts, but I asking as I am wondering whether
the whole platform should be deleted. I'm gonna ask internally about it,
but none of the authors are around anymore and seeing
| git log --grep "pic32" --author="@microchip.com" --pretty="%h%x09%an%x09%ad%x09%s" -n 2 --date=short
| 5e972ac119c87   Conor Dooley    2026-02-24      clk: microchip: rename clk-core to clk-pic32
| a726f1d2dd4fe   Purna Chandra Mandal    2016-06-02      MIPS: pic32mzda: Fix linker error for pic32_get_pbclk()
is bad omen.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 0/3] clk: microchip: core: allow driver to be compiled with COMPILE_TEST

[Brian Masney]

On Tue, Feb 24, 2026 at 05:36:25PM +0000, Conor Dooley wrote:
> On Tue, Feb 24, 2026 at 12:27:27PM -0500, Brian Masney wrote:
> > On Tue, Feb 24, 2026 at 05:10:42PM +0000, Conor Dooley wrote:
> > > On Sun, Feb 22, 2026 at 06:51:03PM -0500, Brian Masney wrote:
> > > > Here's a small series that lets us enable COMPILE_TEST for the pic32 clk
> > > > driver so that this driver can be compiled on all architectures in the
> > > > future to help avoid breakage.
> > > 
> > > Why do you care about this platform? Originally I thought you cared cos
> > > you were getting involved in clock subsystem stuff, but I see you doing
> > > stuff with it in pinctrl etc. Is that just general cleanup work, or do
> > > you actually have an interest in the platform?
> > 
> > My sole interest is to clean up the clk driver, which spilled into
> > larger work to clean the include header to allow this driver to be
> > compiled on other architectures. If I was going to do this for the
> > clk driver, it wasn't that much work to do the other pic32 driver
> > cleanups while I was there.
> > 
> > Honestly, I hope to done with all of these pic32 drivers after what I
> > posted this week has been merged.
> 
> Not to pooh pooh your efforts, but I asking as I am wondering whether
> the whole platform should be deleted. I'm gonna ask internally about it,
> but none of the authors are around anymore and seeing
> | git log --grep "pic32" --author="@microchip.com" --pretty="%h%x09%an%x09%ad%x09%s" -n 2 --date=short
> | 5e972ac119c87   Conor Dooley    2026-02-24      clk: microchip: rename clk-core to clk-pic32
> | a726f1d2dd4fe   Purna Chandra Mandal    2016-06-02      MIPS: pic32mzda: Fix linker error for pic32_get_pbclk()
> is bad omen.

Yea, that's not a good sign. No objections from me.

Brian