[PATCH 0/2] gpio/omap: few code realignment and update of missing code

[PATCH 0/2] gpio/omap: few code realignment and update of missing code

[Tarun Kanti DebBarma]

This is in reponse to comments provided to [gpio/omap: add clk_prepare
and clk_unprepare] and is available here for reference:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/105762.html

Patch-1 moves the debounce clock handle initialization from gpio_debounce()
to omap_gpio_mod_init(). Since this is a one time initialization it makes
sense to keep it here. Though proposal was to keep in omap_gpio_chip_init()
I found more appropriate to keep in omap_gpio_mod_init() because it is more
related to bank specific initialization.

Patch-2 adds *.remove* callback which is missing in current implementation.
Along with other cleanup operations this function is used for releasing the
clock handle and of course calling clk_unprepare().

Reference:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Commit: bd0a521e88aa7a06ae7aabaed7ae196ed4ad867a (Linux 3.5-rc6)

Tested on: OMAP3630/ZOOM3, BLAZE

Tarun Kanti DebBarma (2):
  gpio/omap: move bank->dbck initialization to omap_gpio_mod_init()
  gpio/omap: add *remove* callback in platform_driver

 drivers/gpio/gpio-omap.c |   40 ++++++++++++++++++++++++++++++++++------
 1 files changed, 34 insertions(+), 6 deletions(-)

[PATCH 1/2] gpio/omap: move bank->dbck initialization to omap_gpio_mod_init()

[Tarun Kanti DebBarma]

Since the bank->dbck initialization in a one time operation there
is no need to keep this within gpio_debounce(). Therefore, moving
clk_get(bank->dbck) to omap_gpio_mod_init(). Since the value of
bank->dbck would be NULL at the beginning, this check has been
removed.

Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Reported-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 drivers/gpio/gpio-omap.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c4ed172..afecdcc 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -889,12 +889,6 @@ static int gpio_debounce(struct gpio_chip *chip, unsigned offset,
 
 	bank = container_of(chip, struct gpio_bank, chip);
 
-	if (!bank->dbck) {
-		bank->dbck = clk_get(bank->dev, "dbclk");
-		if (IS_ERR(bank->dbck))
-			dev_err(bank->dev, "Could not get gpio dbck\n");
-	}
-
 	spin_lock_irqsave(&bank->lock, flags);
 	_set_gpio_debounce(bank, offset, debounce);
 	spin_unlock_irqrestore(&bank->lock, flags);
@@ -966,6 +960,10 @@ static void omap_gpio_mod_init(struct gpio_bank *bank)
 	 /* Initialize interface clk ungated, module enabled */
 	if (bank->regs->ctrl)
 		__raw_writel(0, base + bank->regs->ctrl);
+
+	bank->dbck = clk_get(bank->dev, "dbclk");
+	if (IS_ERR(bank->dbck))
+		dev_err(bank->dev, "Could not get gpio dbck\n");
 }
 
 static __devinit void
-- 
1.7.0.4

[PATCH 1/2] gpio/omap: move bank->dbck initialization to omap_gpio_mod_init()

[Paul Walmsley]

On Wed, 11 Jul 2012, Tarun Kanti DebBarma wrote:

> Since the bank->dbck initialization in a one time operation there
> is no need to keep this within gpio_debounce(). Therefore, moving
> clk_get(bank->dbck) to omap_gpio_mod_init(). Since the value of
> bank->dbck would be NULL at the beginning, this check has been
> removed.
> 
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Reviewed-by: Jon Hunter <jon-hunter@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Cousson, Benoit <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
>  drivers/gpio/gpio-omap.c |   10 ++++------
>  1 files changed, 4 insertions(+), 6 deletions(-)

Reviewed-by: Paul Walmsley <paul@pwsan.com>

These drivers are maintained by Grant Likely and Linus Walleij:

GPIO SUBSYSTEM
M:      Grant Likely <grant.likely@secretlab.ca>
M:      Linus Walleij <linus.walleij@stericsson.com>
S:      Maintained
T:      git git://git.secretlab.ca/git/linux-2.6.git
F:      Documentation/gpio.txt
F:      drivers/gpio/
F:      include/linux/gpio*

So you'll want to cc them.  They are probably also who should merge these.


- Paul

[PATCH 1/2] gpio/omap: move bank->dbck initialization to omap_gpio_mod_init()

[DebBarma, Tarun Kanti]

On Wed, Jul 11, 2012 at 11:21 PM, Paul Walmsley <paul@pwsan.com> wrote:
> On Wed, 11 Jul 2012, Tarun Kanti DebBarma wrote:
>
>> Since the bank->dbck initialization in a one time operation there
>> is no need to keep this within gpio_debounce(). Therefore, moving
>> clk_get(bank->dbck) to omap_gpio_mod_init(). Since the value of
>> bank->dbck would be NULL at the beginning, this check has been
>> removed.
>>
>> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
>> Reported-by: Paul Walmsley <paul@pwsan.com>
>> Reviewed-by: Jon Hunter <jon-hunter@ti.com>
>> Cc: Kevin Hilman <khilman@ti.com>
>> Cc: Rajendra Nayak <rnayak@ti.com>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Cousson, Benoit <b-cousson@ti.com>
>> Cc: Paul Walmsley <paul@pwsan.com>
>> ---
>>  drivers/gpio/gpio-omap.c |   10 ++++------
>>  1 files changed, 4 insertions(+), 6 deletions(-)
>
> Reviewed-by: Paul Walmsley <paul@pwsan.com>
>
> These drivers are maintained by Grant Likely and Linus Walleij:
>
> GPIO SUBSYSTEM
> M:      Grant Likely <grant.likely@secretlab.ca>
> M:      Linus Walleij <linus.walleij@stericsson.com>
> S:      Maintained
> T:      git git://git.secretlab.ca/git/linux-2.6.git
> F:      Documentation/gpio.txt
> F:      drivers/gpio/
> F:      include/linux/gpio*
>
> So you'll want to cc them.  They are probably also who should merge these.
Ok, I wanted Kevin to have a look first. Anyways, I have cc'ed.
Thanks.
--
Tarun
>
>
> - Paul

[PATCH 1/2] gpio/omap: move bank->dbck initialization to omap_gpio_mod_init()

[Linus Walleij]

On Wed, Jul 11, 2012 at 11:13 AM, Tarun Kanti DebBarma
<tarun.kanti@ti.com> wrote:

> Since the bank->dbck initialization in a one time operation there
> is no need to keep this within gpio_debounce(). Therefore, moving
> clk_get(bank->dbck) to omap_gpio_mod_init(). Since the value of
> bank->dbck would be NULL at the beginning, this check has been
> removed.
>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>

Applied with Pauld reviewed-by.

Thanks,
Linus Walleij

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Tarun Kanti DebBarma]

Add *remove* callback so that necessary cleanup operations are
performed when device is unregistered. The device is deleted
from the list and associated clock handle is released by
calling clk_put() and irq descriptor is released using the
irq_free_desc() api.

Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Reported-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 drivers/gpio/gpio-omap.c |   30 ++++++++++++++++++++++++++++++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index afecdcc..08929d5 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1140,6 +1140,35 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
 	return ret;
 }
 
+/**
+ * omap_gpio_remove - cleanup a registered gpio device
+ * @pdev:       pointer to current gpio platform device
+ *
+ * Called by driver framework whenever a gpio device is unregistered.
+ * GPIO is deleted from the list and associated clock handle freed.
+ */
+static int __devexit omap_gpio_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct gpio_bank *bank;
+	unsigned long flags;
+	int ret = -EINVAL;
+
+	list_for_each_entry(bank, &omap_gpio_list, node) {
+		spin_lock_irqsave(&bank->lock, flags);
+		if (bank->dev == dev) {
+			list_del(&bank->node);
+			clk_put(bank->dbck);
+			irq_free_desc(bank->irq_base);
+			ret = 0;
+			spin_unlock_irqrestore(&bank->lock, flags);
+			break;
+		}
+		spin_unlock_irqrestore(&bank->lock, flags);
+	}
+	return ret;
+}
+
 #ifdef CONFIG_ARCH_OMAP2PLUS
 
 #if defined(CONFIG_PM_RUNTIME)
@@ -1466,6 +1495,7 @@ MODULE_DEVICE_TABLE(of, omap_gpio_match);
 
 static struct platform_driver omap_gpio_driver = {
 	.probe		= omap_gpio_probe,
+	.remove = __devexit_p(omap_gpio_remove),
 	.driver		= {
 		.name	= "omap_gpio",
 		.pm	= &gpio_pm_ops,
-- 
1.7.0.4

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Linus Walleij]

On Wed, Jul 11, 2012 at 11:13 AM, Tarun Kanti DebBarma
<tarun.kanti@ti.com> wrote:

> Add *remove* callback so that necessary cleanup operations are
> performed when device is unregistered. The device is deleted
> from the list and associated clock handle is released by
> calling clk_put() and irq descriptor is released using the
> irq_free_desc() api.
>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>

Looks good, applied.

Yours,
Linus Walleij

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Kevin Hilman]

Tarun Kanti DebBarma <tarun.kanti@ti.com> writes:

> Add *remove* callback so that necessary cleanup operations are
> performed when device is unregistered. 

How was this tested?  on what platforms?  

> The device is deleted
> from the list and associated clock handle is released by
> calling clk_put() and irq descriptor is released using the
> irq_free_desc() api.

There is quite a bit of other things to do in remove to properly cleanup
what is done in probe.

Also, what happens when a 'remove' is triwhen there are GPIOs that 
are still requested and in use, especially if they are GPIO IRQs.

Also, what about runtime PM?

In short, this seems very premature and I suspect untested.

Kevin

> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Reviewed-by: Jon Hunter <jon-hunter@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Cousson, Benoit <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
>  drivers/gpio/gpio-omap.c |   30 ++++++++++++++++++++++++++++++
>  1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index afecdcc..08929d5 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1140,6 +1140,35 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>  	return ret;
>  }
>  
> +/**
> + * omap_gpio_remove - cleanup a registered gpio device
> + * @pdev:       pointer to current gpio platform device
> + *
> + * Called by driver framework whenever a gpio device is unregistered.
> + * GPIO is deleted from the list and associated clock handle freed.
> + */
> +static int __devexit omap_gpio_remove(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct gpio_bank *bank;
> +	unsigned long flags;
> +	int ret = -EINVAL;
> +
> +	list_for_each_entry(bank, &omap_gpio_list, node) {
> +		spin_lock_irqsave(&bank->lock, flags);
> +		if (bank->dev == dev) {
> +			list_del(&bank->node);
> +			clk_put(bank->dbck);
> +			irq_free_desc(bank->irq_base);
> +			ret = 0;
> +			spin_unlock_irqrestore(&bank->lock, flags);
> +			break;
> +		}
> +		spin_unlock_irqrestore(&bank->lock, flags);
> +	}
> +	return ret;
> +}
> +
>  #ifdef CONFIG_ARCH_OMAP2PLUS
>  
>  #if defined(CONFIG_PM_RUNTIME)
> @@ -1466,6 +1495,7 @@ MODULE_DEVICE_TABLE(of, omap_gpio_match);
>  
>  static struct platform_driver omap_gpio_driver = {
>  	.probe		= omap_gpio_probe,
> +	.remove = __devexit_p(omap_gpio_remove),
>  	.driver		= {
>  		.name	= "omap_gpio",
>  		.pm	= &gpio_pm_ops,

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Linus Walleij]

On Thu, Jul 12, 2012 at 1:25 AM, Kevin Hilman <khilman@ti.com> wrote:

> There is quite a bit of other things to do in remove to properly cleanup
> what is done in probe.

OK I'm dropping this patch for now...

Yours,
Linus Walleij

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Kevin Hilman]

Hi Linus,

Linus Walleij <linus.walleij@linaro.org> writes:

> On Thu, Jul 12, 2012 at 1:25 AM, Kevin Hilman <khilman@ti.com> wrote:
>
>> There is quite a bit of other things to do in remove to properly cleanup
>> what is done in probe.
>
> OK I'm dropping this patch for now...
>

Thanks.

For future reference...  as one of the OMAP maintainers, I request that
you not pull/merge OMAP GPIO patches unless they've had a bit of review
and exposure.  Unfortunately, we have a history with this driver where
regressions have been introduced and the maintainers end up having to
find and fix them.  

In the case of OMAP GPIO, unless it's an obvious fix, I would recommend
you wait at least until you see some acks/tested tags from any of

- Santosh Shilimkar <santosh.shilimkar@ti.com>
- Rajendra Nayak <rnayak@ti.com>
- Benoit Cousson <b-cousson@ti.com>

or Tony, Paul or myself.

For major series, I have been collecting/queueing them for Grant after
ensuring they have been well reviewed and well tested (although I am
eagerly hoping to hand off this role to someone else.)

Thanks,

Kevin

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Linus Walleij]

On Thu, Jul 12, 2012 at 7:48 PM, Kevin Hilman <khilman@ti.com> wrote:

> In the case of OMAP GPIO, unless it's an obvious fix, I would recommend
> you wait at least until you see some acks/tested tags from any of
>
> - Santosh Shilimkar <santosh.shilimkar@ti.com>
> - Rajendra Nayak <rnayak@ti.com>
> - Benoit Cousson <b-cousson@ti.com>
>
> or Tony, Paul or myself.

Instead of trying to store this information in my and Grants brains and
us forgetting it, what about patching MAINTAINERS to reflect the fact
instead? That's better I think, plus I use that file a lot.

> For major series, I have been collecting/queueing them for Grant after
> ensuring they have been well reviewed and well tested (although I am
> eagerly hoping to hand off this role to someone else.)

Listing it under your GIT tree in MAINTAINERS for this driver will make
this work better I think.

One path for OMAP GPIO patches, simple. It's obviously the
ambiguity that cause the trouble. Then you can also decide
on each cycle whether to send these to GPIO or ARM SoC
etc.

Yours,
Linus Walleij

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Kevin Hilman]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Thu, Jul 12, 2012 at 7:48 PM, Kevin Hilman <khilman@ti.com> wrote:
>
>> In the case of OMAP GPIO, unless it's an obvious fix, I would recommend
>> you wait at least until you see some acks/tested tags from any of
>>
>> - Santosh Shilimkar <santosh.shilimkar@ti.com>
>> - Rajendra Nayak <rnayak@ti.com>
>> - Benoit Cousson <b-cousson@ti.com>
>>
>> or Tony, Paul or myself.
>
> Instead of trying to store this information in my and Grants brains and
> us forgetting it, what about patching MAINTAINERS to reflect the fact
> instead? That's better I think, plus I use that file a lot.
>
>> For major series, I have been collecting/queueing them for Grant after
>> ensuring they have been well reviewed and well tested (although I am
>> eagerly hoping to hand off this role to someone else.)
>
> Listing it under your GIT tree in MAINTAINERS for this driver will make
> this work better I think.
>
> One path for OMAP GPIO patches, simple. It's obviously the
> ambiguity that cause the trouble. Then you can also decide
> on each cycle whether to send these to GPIO or ARM SoC
> etc.

Yeah, I understand the process, but I've been avoiding doing that
because, well, I don't want the job.  I have been trying to get someone
else at TI to maintain this driver, but have not been successful.

So, until that happens, feel free to queue up the patch below.

Santosh, note that I've put you as co-maintainer of this driver.

Kevin


>From c429e2e98ea7add98b85a47483ca7126284b22e6 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@ti.com>
Date: Mon, 16 Jul 2012 10:05:07 -0700
Subject: [PATCH] MAINTAINERS: add entry OMAP GPIO driver

Since I've been maintaining this, making it official at the request of the
GPIO maintainers.

Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
 MAINTAINERS |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 03df1d1..61d117a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4943,6 +4943,13 @@ S:	Maintained
 F:	drivers/usb/*/*omap*
 F:	arch/arm/*omap*/usb*
 
+OMAP GPIO DRIVER
+M:	Santosh Shilimkar <santosh.shilimkar@ti.com>
+M:	Kevin Hilman <khilman@ti.com>
+L:	linux-omap at vger.kernel.org
+S:	Maintained
+F:	drivers/gpio/gpio.omap.c
+
 OMFS FILESYSTEM
 M:	Bob Copeland <me@bobcopeland.com>
 L:	linux-karma-devel at lists.sourceforge.net
-- 
1.7.9.2

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Linus Walleij]

On Mon, Jul 16, 2012 at 7:10 PM, Kevin Hilman <khilman@ti.com> wrote:

> Subject: [PATCH] MAINTAINERS: add entry OMAP GPIO driver
>
> Since I've been maintaining this, making it official at the request of the
> GPIO maintainers.
>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Kevin Hilman <khilman@ti.com>

Thank! Applied, but:

> +F:     drivers/gpio/gpio.omap.c

I replaced the period with a dash:
drivers/gpio/gpio-omap.c

Yours,
Linus Walleij

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Kevin Hilman]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Mon, Jul 16, 2012 at 7:10 PM, Kevin Hilman <khilman@ti.com> wrote:
>
>> Subject: [PATCH] MAINTAINERS: add entry OMAP GPIO driver
>>
>> Since I've been maintaining this, making it official at the request of the
>> GPIO maintainers.
>>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Signed-off-by: Kevin Hilman <khilman@ti.com>
>
> Thank! Applied, but:
>
>> +F:     drivers/gpio/gpio.omap.c
>
> I replaced the period with a dash:
> drivers/gpio/gpio-omap.c

Ah, you caught me again trying to avoid getting mail for that driver. ;)

Kevin

[PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Shilimkar, Santosh]

On Mon, Jul 16, 2012 at 10:40 PM, Kevin Hilman <khilman@ti.com> wrote:
>
> Linus Walleij <linus.walleij@linaro.org> writes:
>
> > On Thu, Jul 12, 2012 at 7:48 PM, Kevin Hilman <khilman@ti.com> wrote:
> >
> >> In the case of OMAP GPIO, unless it's an obvious fix, I would recommend
> >> you wait at least until you see some acks/tested tags from any of
> >>
> >> - Santosh Shilimkar <santosh.shilimkar@ti.com>
> >> - Rajendra Nayak <rnayak@ti.com>
> >> - Benoit Cousson <b-cousson@ti.com>
> >>
> >> or Tony, Paul or myself.
> >
> > Instead of trying to store this information in my and Grants brains and
> > us forgetting it, what about patching MAINTAINERS to reflect the fact
> > instead? That's better I think, plus I use that file a lot.
> >
> >> For major series, I have been collecting/queueing them for Grant after
> >> ensuring they have been well reviewed and well tested (although I am
> >> eagerly hoping to hand off this role to someone else.)
> >
> > Listing it under your GIT tree in MAINTAINERS for this driver will make
> > this work better I think.
> >
> > One path for OMAP GPIO patches, simple. It's obviously the
> > ambiguity that cause the trouble. Then you can also decide
> > on each cycle whether to send these to GPIO or ARM SoC
> > etc.
>
> Yeah, I understand the process, but I've been avoiding doing that
> because, well, I don't want the job.  I have been trying to get someone
> else at TI to maintain this driver, but have not been successful.
>
> So, until that happens, feel free to queue up the patch below.
>
> Santosh, note that I've put you as co-maintainer of this driver.
>
No problem Kevin.

Regards
Santosh