On Fri, Aug 24, 2012 at 02:55:00PM +0100, Krystian Garbaciak wrote:
> +static int da906x_set_voltage(struct regulator_dev *rdev,
> + int min_uV, int max_uV, unsigned *selector)
> +{
> + struct da906x_regulator *regl = rdev_get_drvdata(rdev);
> + const struct field *fvol = ®l->info->voltage;
> + int ret;
> + unsigned val;
> +
> + val = regulator_map_voltage_linear(rdev, min_uV, max_uV);
> + if (val < 0)
> + return -EINVAL;
> +
> + val = (val + fvol->offset) << fvol->shift;
> + ret = da906x_reg_update(regl->hw, fvol->addr, fvol->mask, val);
> + if (ret >= 0)
> + *selector = val;
> +
> + return ret;
> +}
This is just set_voltage_sel_regmap().
> +static int da906x_enable(struct regulator_dev *rdev)
> +{
> + struct da906x_regulator *regl = rdev_get_drvdata(rdev);
> + int ret;
> +
> + if (regl->info->suspend.mask) {
> + /* Make sure to exit from suspend mode on enable */
> + ret = da906x_reg_clear_bits(regl->hw, regl->info->suspend.addr,
> + regl->info->suspend.mask);
> + if (ret < 0)
> + return ret;
> +
> + /* BUCKs need mode update after wake-up from suspend state. */
> + ret = da906x_update_mode_internal(regl, SYS_STATE_NORMAL);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return regulator_enable_regmap(rdev);
If suspend_mask is optional the regulators using it should just use the
standard operation.
> +/* Regulator event handlers */
> +irqreturn_t da906x_ldo_lim_event(int irq, void *data)
By "event handler" you mean "interrupt"
> + bits = da906x_reg_read(hw, DA906X_REG_STATUS_D);
> + if (bits < 0)
> + return IRQ_HANDLED;
If you fail to detect an interrupt you report that you handled one...?
> + if (!da906x_pdata) {
> + dev_err(&pdev->dev, "No platform init data supplied\n");
> + return -ENODEV;
> + }
Platform data should be totally optional.
> + bcores_merged = (ret & DA906X_BCORE_MERGE) ? true : false;
> + bmem_bio_merged = (ret & DA906X_BUCK_MERGE) ? true : false;
The use of the ternery operation here is even worse than normal, you can
assign the values directly.
> > +static int da906x_set_voltage(struct regulator_dev *rdev,
> > + int min_uV, int max_uV, unsigned *selector)
> > +{
> > + struct da906x_regulator *regl = rdev_get_drvdata(rdev);
> > + const struct field *fvol = ®l->info->voltage;
> > + int ret;
> > + unsigned val;
> > +
> > + val = regulator_map_voltage_linear(rdev, min_uV, max_uV);
> > + if (val < 0)
> > + return -EINVAL;
> > +
> > + val = (val + fvol->offset) << fvol->shift;
> > + ret = da906x_reg_update(regl->hw, fvol->addr, fvol->mask, val);
> > + if (ret >= 0)
> > + *selector = val;
> > +
> > + return ret;
> > +}
>
> This is just set_voltage_sel_regmap().
Because, for some regulators, this is required: val += fvol->offset,
I was only able to reduce it to the following form.
+static int da9063_set_voltage(struct regulator_dev *rdev,
+ int min_uV, int max_uV, unsigned *selector)
+{
+ struct da9063_regulator *regl = rdev_get_drvdata(rdev);
+ const struct field *fvol = ®l->info->voltage;
+ int ret;
+ unsigned val;
+
+ val = regulator_map_voltage_linear(rdev, min_uV, max_uV);
+ if (val < 0)
+ return -EINVAL;
+
+ val += fvol->offset;
+
+ ret = regulator_set_voltage_sel_regmap(rdev, val);
+ if (ret >= 0)
+ *selector = val;
+
+ return ret;
+}
> > +static int da906x_enable(struct regulator_dev *rdev)
> > +{
> > + struct da906x_regulator *regl = rdev_get_drvdata(rdev);
> > + int ret;
> > +
> > + if (regl->info->suspend.mask) {
> > + /* Make sure to exit from suspend mode on enable */
> > + ret = da906x_reg_clear_bits(regl->hw, regl->info->suspend.addr,
> > + regl->info->suspend.mask);
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* BUCKs need mode update after wake-up from suspend state. */
> > + ret = da906x_update_mode_internal(regl, SYS_STATE_NORMAL);
> > + if (ret < 0)
> > + return ret;
> > + }
> > +
> > + return regulator_enable_regmap(rdev);
>
> If suspend_mask is optional the regulators using it should just use the
> standard operation.
I guess, you meant here to call regulator_enable_regmap() directly for
regulators NOT using suspend.mask. Then, I will do it.
> > +/* Regulator event handlers */
> > +irqreturn_t da906x_ldo_lim_event(int irq, void *data)
>
> By "event handler" you mean "interrupt"
Yes. I think, I will update the comment line.
> > + bits = da906x_reg_read(hw, DA906X_REG_STATUS_D);
> > + if (bits < 0)
> > + return IRQ_HANDLED;
>
> If you fail to detect an interrupt you report that you handled one...?
For me there is no sensible return value for this case.
However, I consider changing the reaction on read failure by reporting event
for all regulators, that might cause this interrupt:
+ bits = da9063_reg_read(hw, DA9063_REG_STATUS_D);
+ if (bits < 0)
+ bits = ~0;
I will update the driver according to your remaining comments.
Thank you for your comments,
Krystian
On Wed, Aug 29, 2012 at 03:50:00PM +0100, Krystian Garbaciak wrote:
> Because, for some regulators, this is required: val += fvol->offset,
> I was only able to reduce it to the following form.
What on earth makes you say this? The above is obviously linear.
Besides, you're missing several points here. One is that you should be
using the framework features, another is that you should be implementing
_sel.
> > > + bits = da906x_reg_read(hw, DA906X_REG_STATUS_D);
> > > + if (bits < 0)
> > > + return IRQ_HANDLED;
> > If you fail to detect an interrupt you report that you handled one...?
> For me there is no sensible return value for this case.
IRQ_NONE.
> On Wed, Aug 29, 2012 at 03:50:00PM +0100, Krystian Garbaciak wrote:
>
> > Because, for some regulators, this is required: val += fvol->offset,
> > I was only able to reduce it to the following form.
>
> What on earth makes you say this? The above is obviously linear.
>
> Besides, you're missing several points here. One is that you should be
> using the framework features, another is that you should be implementing
> _sel.
Sorry, I've missed an obvious thing here. Instead of adding selector offset at
runtime, I can substract apropriate voltage from .min_uV. Thanks for pointing
this out.
(trimmed the CC a bit)
Hi Krystian
On Fri, 31 Aug 2012, Krystian Garbaciak wrote:
> > On Wed, Aug 29, 2012 at 03:50:00PM +0100, Krystian Garbaciak wrote:
Sorry for picking up a random mail from this old thread, unfortunately, I
don't have "0/8" in my archive.
I have to write a driver for the da9063 PMIC. Do you have an idea, whether
it'd be compatible with this driver? Do you plan to continue your work on
this driver or would you mind if I try to use these your patches and
mainline them, preserving your authorship and copyright, of course?
Thanks
Guennadi
> > > Because, for some regulators, this is required: val += fvol->offset,
> > > I was only able to reduce it to the following form.
> >
> > What on earth makes you say this? The above is obviously linear.
> >
> > Besides, you're missing several points here. One is that you should be
> > using the framework features, another is that you should be implementing
> > _sel.
>
> Sorry, I've missed an obvious thing here. Instead of adding selector offset at
> runtime, I can substract apropriate voltage from .min_uV. Thanks for pointing
> this out.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Hi Guennadi Liakhovetski,
Now that Krystian no longer works for Dialog I think that I might be your best contact.
As far as I am aware without doing any checking, the DA906x driver should possibly cover the DA9063.
If you need a driver, that would imply that you have some chips. Have you tried our marketting department?
Best regards,
Tony Olech
> -----Original Message-----
> From: Guennadi Liakhovetski [mailto:[email protected]]
> Sent: 09 May 2013 15:06
> To: Krystian Garbaciak
> Cc: Mark Brown; [email protected]; Samuel Ortiz; Alessandro
> Zummo; Jean Delvare; Dmitry Torokhov; Richard Purdie; Anthony Olech
> Subject: Re: [RFC PATCH 2/8] regulator: Add Dialog DA906x voltage regulators
> support.
>
> (trimmed the CC a bit)
>
> Hi Krystian
>
> On Fri, 31 Aug 2012, Krystian Garbaciak wrote:
>
> > > On Wed, Aug 29, 2012 at 03:50:00PM +0100, Krystian Garbaciak wrote:
>
> Sorry for picking up a random mail from this old thread, unfortunately, I don't
> have "0/8" in my archive.
>
> I have to write a driver for the da9063 PMIC. Do you have an idea, whether it'd
> be compatible with this driver? Do you plan to continue your work on this driver
> or would you mind if I try to use these your patches and mainline them,
> preserving your authorship and copyright, of course?
>
> Thanks
> Guennadi
>
> > > > Because, for some regulators, this is required: val +=
> > > > fvol->offset, I was only able to reduce it to the following form.
> > >
> > > What on earth makes you say this? The above is obviously linear.
> > >
> > > Besides, you're missing several points here. One is that you should
> > > be using the framework features, another is that you should be
> > > implementing _sel.
> >
> > Sorry, I've missed an obvious thing here. Instead of adding selector
> > offset at runtime, I can substract apropriate voltage from .min_uV.
> > Thanks for pointing this out.
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer http://www.open-technology.de/
Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information,
some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it
is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
Please consider the environment before printing this e-mail
Hi Tony
On Thu, 9 May 2013, Anthony Olech wrote:
> Hi Guennadi Liakhovetski,
>
> Now that Krystian no longer works for Dialog I think that I might be
> your best contact.
> As far as I am aware without doing any checking, the DA906x driver
> should possibly cover the DA9063.
Good!
> If you need a driver, that would imply that you have some chips. Have
> you tried our marketting department?
Yes, this (and a da9210) PMICs are used on one of the boards, I'm working
with. I asked your marketing department for a da9210 datasheet, they tried
to check with the board vendor, who is also my customer for this project,
and so far they haven't been able to establish my involvement in this
development. Have you also got a da9210 Linux driver? Do I have to wait
for your marketing department clarifying my affiliation or could you make
that driver available to me too? Or do you mean you might have a newer
version of this driver available internally too?
Thanks
Guennadi
> Best regards,
>
> Tony Olech
>
>
> > -----Original Message-----
> > From: Guennadi Liakhovetski [mailto:[email protected]]
> > Sent: 09 May 2013 15:06
> > To: Krystian Garbaciak
> > Cc: Mark Brown; [email protected]; Samuel Ortiz; Alessandro
> > Zummo; Jean Delvare; Dmitry Torokhov; Richard Purdie; Anthony Olech
> > Subject: Re: [RFC PATCH 2/8] regulator: Add Dialog DA906x voltage regulators
> > support.
> >
> > (trimmed the CC a bit)
> >
> > Hi Krystian
> >
> > On Fri, 31 Aug 2012, Krystian Garbaciak wrote:
> >
> > > > On Wed, Aug 29, 2012 at 03:50:00PM +0100, Krystian Garbaciak wrote:
> >
> > Sorry for picking up a random mail from this old thread, unfortunately, I don't
> > have "0/8" in my archive.
> >
> > I have to write a driver for the da9063 PMIC. Do you have an idea, whether it'd
> > be compatible with this driver? Do you plan to continue your work on this driver
> > or would you mind if I try to use these your patches and mainline them,
> > preserving your authorship and copyright, of course?
> >
> > Thanks
> > Guennadi
> >
> > > > > Because, for some regulators, this is required: val +=
> > > > > fvol->offset, I was only able to reduce it to the following form.
> > > >
> > > > What on earth makes you say this? The above is obviously linear.
> > > >
> > > > Besides, you're missing several points here. One is that you should
> > > > be using the framework features, another is that you should be
> > > > implementing _sel.
> > >
> > > Sorry, I've missed an obvious thing here. Instead of adding selector
> > > offset at runtime, I can substract apropriate voltage from .min_uV.
> > > Thanks for pointing this out.
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe
> > > linux-kernel" in the body of a message to [email protected]
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> > >
> >
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer http://www.open-technology.de/
> Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information,
> some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it
> is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure,
> copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
>
> Please consider the environment before printing this e-mail
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Hi Guennadi,
without trying to step on our marketing department's toes, I can only suggest that you slurp the online archives of the LKML and ALSA mailing list.
The Linux Kernel Mailing List archive that I use is: http://lkml.indiana.edu/hypermail/linux/kernel
The ALSA mailing list archive that I use is: http://mailman.alsa-project.org/pipermail/alsa-devel
I usually run a perl/bash/wget script to download stuff of interest.
I can answer questions about our Open Source submission (because they are open source), but for definitive product information our marketing department is the first place to try.
Do you mean the da7210 (audio CODEC)? I don't offhand recognise the da9210 part number.
Best regards,
Tony Olech
> -----Original Message-----
> From: Guennadi Liakhovetski [mailto:[email protected]]
> Sent: 09 May 2013 15:29
> To: Anthony Olech
> Cc: Krystian Garbaciak; Mark Brown; [email protected]; Samuel
> Ortiz; Alessandro Zummo; Jean Delvare; Dmitry Torokhov; Richard Purdie
> Subject: RE: [RFC PATCH 2/8] regulator: Add Dialog DA906x voltage regulators
> support.
>
> Hi Tony
>
> On Thu, 9 May 2013, Anthony Olech wrote:
>
> > Hi Guennadi Liakhovetski,
> >
> > Now that Krystian no longer works for Dialog I think that I might be
> > your best contact.
> > As far as I am aware without doing any checking, the DA906x driver
> > should possibly cover the DA9063.
>
> Good!
>
> > If you need a driver, that would imply that you have some chips. Have
> > you tried our marketting department?
>
> Yes, this (and a da9210) PMICs are used on one of the boards, I'm working with.
> I asked your marketing department for a da9210 datasheet, they tried to check
> with the board vendor, who is also my customer for this project, and so far they
> haven't been able to establish my involvement in this development. Have you
> also got a da9210 Linux driver? Do I have to wait for your marketing
> department clarifying my affiliation or could you make that driver available to
> me too? Or do you mean you might have a newer version of this driver
> available internally too?
>
> Thanks
> Guennadi
>
> > Best regards,
> >
> > Tony Olech
> >
> >
> > > -----Original Message-----
> > > From: Guennadi Liakhovetski [mailto:[email protected]]
> > > Sent: 09 May 2013 15:06
> > > To: Krystian Garbaciak
> > > Cc: Mark Brown; [email protected]; Samuel Ortiz; Alessandro
> > > Zummo; Jean Delvare; Dmitry Torokhov; Richard Purdie; Anthony Olech
> > > Subject: Re: [RFC PATCH 2/8] regulator: Add Dialog DA906x voltage
> regulators
> > > support.
> > >
> > > (trimmed the CC a bit)
> > >
> > > Hi Krystian
> > >
> > > On Fri, 31 Aug 2012, Krystian Garbaciak wrote:
> > >
> > > > > On Wed, Aug 29, 2012 at 03:50:00PM +0100, Krystian Garbaciak wrote:
> > >
> > > Sorry for picking up a random mail from this old thread, unfortunately, I
> don't
> > > have "0/8" in my archive.
> > >
> > > I have to write a driver for the da9063 PMIC. Do you have an idea, whether
> it'd
> > > be compatible with this driver? Do you plan to continue your work on this
> driver
> > > or would you mind if I try to use these your patches and mainline them,
> > > preserving your authorship and copyright, of course?
> > >
> > > Thanks
> > > Guennadi
> > >
> > > > > > Because, for some regulators, this is required: val +=
> > > > > > fvol->offset, I was only able to reduce it to the following form.
> > > > >
> > > > > What on earth makes you say this? The above is obviously linear.
> > > > >
> > > > > Besides, you're missing several points here. One is that you should
> > > > > be using the framework features, another is that you should be
> > > > > implementing _sel.
> > > >
> > > > Sorry, I've missed an obvious thing here. Instead of adding selector
> > > > offset at runtime, I can substract apropriate voltage from .min_uV.
> > > > Thanks for pointing this out.
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > > linux-kernel" in the body of a message to [email protected]
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > Please read the FAQ at http://www.tux.org/lkml/
> > > >
> > >
> > > ---
> > > Guennadi Liakhovetski, Ph.D.
> > > Freelance Open-Source Software Developer http://www.open-
> technology.de/
> > Legal Disclaimer: This e-mail communication (and any attachment/s) is
> confidential and contains proprietary information,
> > some or all of which may be legally privileged. It is intended solely for the use
> of the individual or entity to which it
> > is addressed. Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure,
> > copying, distribution or any action taken or omitted to be taken in reliance on
> it, is prohibited and may be unlawful.
> >
> > Please consider the environment before printing this e-mail
> >
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information,
some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it
is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
Please consider the environment before printing this e-mail
On Thu, 9 May 2013, Anthony Olech wrote:
> Hi Guennadi,
>
> without trying to step on our marketing department's toes, I can only
> suggest that you slurp the online archives of the LKML and ALSA mailing
> list.
> The Linux Kernel Mailing List archive that I use is: http://lkml.indiana.edu/hypermail/linux/kernel
> The ALSA mailing list archive that I use is: http://mailman.alsa-project.org/pipermail/alsa-devel
>
> I usually run a perl/bash/wget script to download stuff of interest.
I've got these patches from an online archive, thanks.
> I can answer questions about our Open Source submission (because they
> are open source), but for definitive product information our marketing
> department is the first place to try.
>
> Do you mean the da7210 (audio CODEC)? I don't offhand recognise the da9210 part number.
No, my task description says "a da9210 PMIC." I think this one is meant:
http://www.dialog-semiconductor.com/products/power-management/DA9210
Thanks
Guennadi
> Best regards,
>
> Tony Olech
>
>
> > -----Original Message-----
> > From: Guennadi Liakhovetski [mailto:[email protected]]
> > Sent: 09 May 2013 15:29
> > To: Anthony Olech
> > Cc: Krystian Garbaciak; Mark Brown; [email protected]; Samuel
> > Ortiz; Alessandro Zummo; Jean Delvare; Dmitry Torokhov; Richard Purdie
> > Subject: RE: [RFC PATCH 2/8] regulator: Add Dialog DA906x voltage regulators
> > support.
> >
> > Hi Tony
> >
> > On Thu, 9 May 2013, Anthony Olech wrote:
> >
> > > Hi Guennadi Liakhovetski,
> > >
> > > Now that Krystian no longer works for Dialog I think that I might be
> > > your best contact.
> > > As far as I am aware without doing any checking, the DA906x driver
> > > should possibly cover the DA9063.
> >
> > Good!
> >
> > > If you need a driver, that would imply that you have some chips. Have
> > > you tried our marketting department?
> >
> > Yes, this (and a da9210) PMICs are used on one of the boards, I'm working with.
> > I asked your marketing department for a da9210 datasheet, they tried to check
> > with the board vendor, who is also my customer for this project, and so far they
> > haven't been able to establish my involvement in this development. Have you
> > also got a da9210 Linux driver? Do I have to wait for your marketing
> > department clarifying my affiliation or could you make that driver available to
> > me too? Or do you mean you might have a newer version of this driver
> > available internally too?
> >
> > Thanks
> > Guennadi
> >
> > > Best regards,
> > >
> > > Tony Olech
> > >
> > >
> > > > -----Original Message-----
> > > > From: Guennadi Liakhovetski [mailto:[email protected]]
> > > > Sent: 09 May 2013 15:06
> > > > To: Krystian Garbaciak
> > > > Cc: Mark Brown; [email protected]; Samuel Ortiz; Alessandro
> > > > Zummo; Jean Delvare; Dmitry Torokhov; Richard Purdie; Anthony Olech
> > > > Subject: Re: [RFC PATCH 2/8] regulator: Add Dialog DA906x voltage
> > regulators
> > > > support.
> > > >
> > > > (trimmed the CC a bit)
> > > >
> > > > Hi Krystian
> > > >
> > > > On Fri, 31 Aug 2012, Krystian Garbaciak wrote:
> > > >
> > > > > > On Wed, Aug 29, 2012 at 03:50:00PM +0100, Krystian Garbaciak wrote:
> > > >
> > > > Sorry for picking up a random mail from this old thread, unfortunately, I
> > don't
> > > > have "0/8" in my archive.
> > > >
> > > > I have to write a driver for the da9063 PMIC. Do you have an idea, whether
> > it'd
> > > > be compatible with this driver? Do you plan to continue your work on this
> > driver
> > > > or would you mind if I try to use these your patches and mainline them,
> > > > preserving your authorship and copyright, of course?
> > > >
> > > > Thanks
> > > > Guennadi
> > > >
> > > > > > > Because, for some regulators, this is required: val +=
> > > > > > > fvol->offset, I was only able to reduce it to the following form.
> > > > > >
> > > > > > What on earth makes you say this? The above is obviously linear.
> > > > > >
> > > > > > Besides, you're missing several points here. One is that you should
> > > > > > be using the framework features, another is that you should be
> > > > > > implementing _sel.
> > > > >
> > > > > Sorry, I've missed an obvious thing here. Instead of adding selector
> > > > > offset at runtime, I can substract apropriate voltage from .min_uV.
> > > > > Thanks for pointing this out.
> > > > >
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe
> > > > > linux-kernel" in the body of a message to [email protected]
> > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > > Please read the FAQ at http://www.tux.org/lkml/
> > > > >
> > > >
> > > > ---
> > > > Guennadi Liakhovetski, Ph.D.
> > > > Freelance Open-Source Software Developer http://www.open-
> > technology.de/
> > > Legal Disclaimer: This e-mail communication (and any attachment/s) is
> > confidential and contains proprietary information,
> > > some or all of which may be legally privileged. It is intended solely for the use
> > of the individual or entity to which it
> > > is addressed. Access to this email by anyone else is unauthorized. If you are
> > not the intended recipient, any disclosure,
> > > copying, distribution or any action taken or omitted to be taken in reliance on
> > it, is prohibited and may be unlawful.
> > >
> > > Please consider the environment before printing this e-mail
> > >
> >
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information,
> some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it
> is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure,
> copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
>
> Please consider the environment before printing this e-mail
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/