subject:"\[PATCH v4 00\/20\] eeprom\: at24\: Add OF device ID table"

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

2017-05-22 Thread Javier Martinez Canillas

Hello Geert,

On Mon, May 22, 2017 at 9:30 PM, Geert Uytterhoeven
 wrote:
> Hi Javier,
>
> On Mon, May 22, 2017 at 7:15 PM, Javier Martinez Canillas
>  wrote:
 I also wonder why this is really needed if AFAIU "renesas,24c02" is
 compatible with "atmel,24c02". IOW, the driver doesn't need to
 differentiate between the two since the devices are the same and will
 always match using "atmel,24c02".
>>>
>>> It is needed, so that when a difference is found, it can be handled
>>> without updating the DT.
>>
>> Yes, I understand this. What I tried to ask is if there could really
>> be a difference for the same chip type between different vendors, or
>> is just that people were using other manufacturers in the compatible
>> string as a consequence of the DT binding doc and the I2C core
>> ignoring the vendor prefix.
>
> The devices from different vendors are not the same. They contain FLASH
> ROM of a specific size, and glue logic to expose an i2c slave
> interface providing
> an AT24-compatible command set.  They should behave similar within
> the limits of the AT24 "spec".  But the actual implementation may be 
> different.
>

I see, really appreciate your explanation. I'm not familiar with these
devices and driver but the patch-series are needed in order to make
sure that no regressions will happen once the I2C core reports a
proper OF modalias.

>> I don't mind though, I will leave the manufacturers that are different
>> than the atmel variants in the mainline DTS as you and Geert asked.
>
> OK, thanks!
>

Thanks a lot for your feedback!

> Gr{oetje,eeting}s,
>
> Geert
>
> --

Best regards,
Javier

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

2017-05-22 Thread Javier Martinez Canillas

Hello Rob,

Thanks a lot for your feedback.

On Mon, May 22, 2017 at 6:52 PM, Rob Herring  wrote:
> On Mon, May 22, 2017 at 9:46 AM, Javier Martinez Canillas
>  wrote:

[snip]

 | >
 | > at24@50 {
 | > -   compatible = "at24,24c02";
 | > +   compatible = "at24,24c02", "atmel,24c02";
 |
 | I think you can just drop the at24 compatibles. A new kernel doesn't
 | need it. An old kernel ignores the manufacturer. I checked that u-boot
 | only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
 | couldn't find anything.

 I think you misunderstood what Rob means.

 In the case above it makes sense to drop the first compatible, as "at24" is
 not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.

 However, in cases where a real vendor/part combo is specified, like on
 r8a7791-koelsch.dts:

 -   compatible = "renesas,24c02";
 +   compatible = "atmel,24c02";

 you do want to keep the real vendor/part combo, i.e.

  compatible = "renesas,24c02", "atmel,24c02";
>>>
>>> Yes, Geert is correct.
>>>
>>
>> Sorry for misunderstanding your previous comment...
>>
>> How this should be documented in the DT binding? Should I include
>> "renesas" as a valid manufacturer or only list the used
>>  pairs (i.e: "renesas,24c02")?
>
> However you are handling any of the vendors. I'll have to go look.
>

The current DT binding is quite lax when describing this. From
Documentation/devicetree/bindings/eeprom/eeprom.txt:

--
EEPROMs (I2C)

Required properties:

  - compatible : should be ",", like these:

"atmel,24c00", "atmel,24c01", "atmel,24c02", "atmel,24c04",
"atmel,24c08", "atmel,24c16", "atmel,24c32", "atmel,24c64",
"atmel,24c128", "atmel,24c256", "atmel,24c512", "atmel,24c1024"

"catalyst,24c32"

"microchip,24c128"

"ramtron,24c64"

"renesas,r1ex24002"

If there is no specific driver for , a generic
driver based on  is selected. Possible types are:
"24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64",
"24c128", "24c256", "24c512", "24c1024", "spd"

  - reg : the I2C address of the EEPROM
--

I think though that this is one of the cases where the Linux I2C
subsystem matching logic is leaking into the DT binding doc, since the
manufacturer prefix is ignored by the I2C core (the I2C device ID
table is used to match and to report a MODALIAS).

But I'll keep the description generic as it is now and only mention
the atmel variants (at and at24) as deprecated then.

>> I also wonder why this is really needed if AFAIU "renesas,24c02" is
>> compatible with "atmel,24c02". IOW, the driver doesn't need to
>> differentiate between the two since the devices are the same and will
>> always match using "atmel,24c02".
>
> It is needed, so that when a difference is found, it can be handled
> without updating the DT.
>

Yes, I understand this. What I tried to ask is if there could really
be a difference for the same chip type between different vendors, or
is just that people were using other manufacturers in the compatible
string as a consequence of the DT binding doc and the I2C core
ignoring the vendor prefix.

I don't mind though, I will leave the manufacturers that are different
than the atmel variants in the mainline DTS as you and Geert asked.

> Rob

Best regards,
Javier

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

2017-05-22 Thread Javier Martinez Canillas

Hello Geert and Rob,

On Mon, May 22, 2017 at 4:26 PM, Rob Herring  wrote:
> On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven
>  wrote:
>> Hi Javier,
>>
>> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
>>  wrote:
>>> This series is a follow-up to patch [0] that added an OF device ID table
>>> to the at24 EEPROM driver. As you suggested [1], this version instead of
>>> adding entries for every used  tuple, only adds a single
>>> entry for each chip type using the "atmel" vendor as a generic fallback.
>>>
>>> This is a re-spin that addresses some issues pointed out by Rob Herring.
>>>
>>> The first patch documents in the DT binding what's the correct vendor to
>>> use and what are the ones that are being deprecated. The second one adds
>>> the OF device ID table for the at24 driver and the next patches use this
>>> vendor in the compatible string to each DTS that defines a compatible I2C
>>> EEPROM device node.
>>>
>>> Patches can be applied independently since the DTS changes without driver
>>> changes are no-op and the OF table won't be used without the DTS changes.
>>>
>>> [0]: https://lkml.org/lkml/2017/3/14/589
>>> [1]: https://lkml.org/lkml/2017/3/15/99
>>>
>>> Best regards,
>>> Javier
>>>
>>> Changes in v4:
>>> - Document the manufacturers that have been deprecated (Rob Herring).
>>> - Only use the atmel manufacturer in the compatible string instead of
>>>   keeping the deprecated ones (Rob Herring).
>>
>> I think you're referring to this (https://lkml.org/lkml/2017/4/19/1136)?
>>
>> | > --- a/arch/arm/boot/dts/am335x-baltos.dtsi
>> | > +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
>> | > @@ -255,7 +255,7 @@
>> | > };
>> | >
>> | > at24@50 {
>> | > -   compatible = "at24,24c02";
>> | > +   compatible = "at24,24c02", "atmel,24c02";
>> |
>> | I think you can just drop the at24 compatibles. A new kernel doesn't
>> | need it. An old kernel ignores the manufacturer. I checked that u-boot
>> | only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
>> | couldn't find anything.
>>
>> I think you misunderstood what Rob means.
>>
>> In the case above it makes sense to drop the first compatible, as "at24" is
>> not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.
>>
>> However, in cases where a real vendor/part combo is specified, like on
>> r8a7791-koelsch.dts:
>>
>> -   compatible = "renesas,24c02";
>> +   compatible = "atmel,24c02";
>>
>> you do want to keep the real vendor/part combo, i.e.
>>
>>  compatible = "renesas,24c02", "atmel,24c02";
>
> Yes, Geert is correct.
>

Sorry for misunderstanding your previous comment...

How this should be documented in the DT binding? Should I include
"renesas" as a valid manufacturer or only list the used
 pairs (i.e: "renesas,24c02")?

I also wonder why this is really needed if AFAIU "renesas,24c02" is
compatible with "atmel,24c02". IOW, the driver doesn't need to
differentiate between the two since the devices are the same and will
always match using "atmel,24c02".

> Rob

Best regards,
Javier

[PATCH v4 00/20] eeprom: at24: Add OF device ID table

2017-05-22 Thread Javier Martinez Canillas

Hello Wolfram,

This series is a follow-up to patch [0] that added an OF device ID table
to the at24 EEPROM driver. As you suggested [1], this version instead of
adding entries for every used  tuple, only adds a single
entry for each chip type using the "atmel" vendor as a generic fallback.

This is a re-spin that addresses some issues pointed out by Rob Herring.

The first patch documents in the DT binding what's the correct vendor to
use and what are the ones that are being deprecated. The second one adds
the OF device ID table for the at24 driver and the next patches use this
vendor in the compatible string to each DTS that defines a compatible I2C
EEPROM device node.

Patches can be applied independently since the DTS changes without driver
changes are no-op and the OF table won't be used without the DTS changes.

[0]: https://lkml.org/lkml/2017/3/14/589
[1]: https://lkml.org/lkml/2017/3/15/99

Best regards,
Javier

Changes in v4:
- Document the manufacturers that have been deprecated (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).

Changes in v3:
- Fix wrong .data values for "atmel,24c02" and "atmel,24c64" entries.
- Add Geert Uytterhoeven reviewed-by tag.
- Add Geert Uytterhoeven reviewed-by tag.

Changes in v2:
- Only add a single OF device ID entry for each device type (Wolfram Sang).

Javier Martinez Canillas (20):
  dt-bindings: i2c: eeprom: Document vendor to be used and deprecated
ones
  eeprom: at24: Add OF device ID table
  ARM: dts: omap: Add generic compatible string for I2C EEPROM
  ARM: dts: turris-omnia: Add generic compatible string for I2C EEPROM
  ARM: dts: efm32: Add generic compatible string for I2C EEPROM
  ARM: dts: imx: Add generic compatible string for I2C EEPROM
  ARM: dts: keystone: Add generic compatible string for I2C EEPROM
  ARM: dts: lpc18xx: Add generic compatible string for I2C EEPROM
  ARM: dts: r7s72100: Add generic compatible string for I2C EEPROM
  ARM: dts: koelsch: Add generic compatible string for I2C EEPROM
  ARM: dts: socfpga: Add generic compatible string for I2C EEPROM
  ARM: dts: uniphier: Add generic compatible string for I2C EEPROM
  ARM: dts: zynq: Add generic compatible string for I2C EEPROM
  arm64: dts: ls1043a: Add generic compatible string for I2C EEPROM
  arm64: zynqmp: Add generic compatible string for I2C EEPROM
  powerpc/5200: Add generic compatible string for I2C EEPROM
  powerpc/fsl: Add generic compatible string for I2C EEPROM
  powerpc/512x: Add generic compatible string for I2C EEPROM
  powerpc/83xx: Add generic compatible string for I2C EEPROM
  powerpc/44x: Add generic compatible string for I2C EEPROM

 .../devicetree/bindings/eeprom/eeprom.txt  | 14 ++---
 arch/arm/boot/dts/am335x-baltos.dtsi   |  2 +-
 arch/arm/boot/dts/am335x-base0033.dts  |  2 +-
 arch/arm/boot/dts/am335x-bone-common.dtsi  | 10 ++--
 arch/arm/boot/dts/am335x-nano.dts  |  2 +-

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

2017-05-22 Thread Geert Uytterhoeven

Hi Javier,

On Mon, May 22, 2017 at 7:15 PM, Javier Martinez Canillas
 wrote:
>>> I also wonder why this is really needed if AFAIU "renesas,24c02" is
>>> compatible with "atmel,24c02". IOW, the driver doesn't need to
>>> differentiate between the two since the devices are the same and will
>>> always match using "atmel,24c02".
>>
>> It is needed, so that when a difference is found, it can be handled
>> without updating the DT.
>
> Yes, I understand this. What I tried to ask is if there could really
> be a difference for the same chip type between different vendors, or
> is just that people were using other manufacturers in the compatible
> string as a consequence of the DT binding doc and the I2C core
> ignoring the vendor prefix.

The devices from different vendors are not the same. They contain FLASH
ROM of a specific size, and glue logic to expose an i2c slave
interface providing
an AT24-compatible command set.  They should behave similar within
the limits of the AT24 "spec".  But the actual implementation may be different.

> I don't mind though, I will leave the manufacturers that are different
> than the atmel variants in the mainline DTS as you and Geert asked.

OK, thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

2017-05-22 Thread Rob Herring

On Mon, May 22, 2017 at 9:46 AM, Javier Martinez Canillas
 wrote:
> Hello Geert and Rob,
>
> On Mon, May 22, 2017 at 4:26 PM, Rob Herring  wrote:
>> On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven
>>  wrote:
>>> Hi Javier,
>>>
>>> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
>>>  wrote:
 This series is a follow-up to patch [0] that added an OF device ID table
 to the at24 EEPROM driver. As you suggested [1], this version instead of
 adding entries for every used  tuple, only adds a single
 entry for each chip type using the "atmel" vendor as a generic fallback.

 This is a re-spin that addresses some issues pointed out by Rob Herring.

 The first patch documents in the DT binding what's the correct vendor to
 use and what are the ones that are being deprecated. The second one adds
 the OF device ID table for the at24 driver and the next patches use this
 vendor in the compatible string to each DTS that defines a compatible I2C
 EEPROM device node.

 Patches can be applied independently since the DTS changes without driver
 changes are no-op and the OF table won't be used without the DTS changes.

 [0]: https://lkml.org/lkml/2017/3/14/589
 [1]: https://lkml.org/lkml/2017/3/15/99

 Best regards,
 Javier

 Changes in v4:
 - Document the manufacturers that have been deprecated (Rob Herring).
 - Only use the atmel manufacturer in the compatible string instead of
   keeping the deprecated ones (Rob Herring).
>>>
>>> I think you're referring to this (https://lkml.org/lkml/2017/4/19/1136)?
>>>
>>> | > --- a/arch/arm/boot/dts/am335x-baltos.dtsi
>>> | > +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
>>> | > @@ -255,7 +255,7 @@
>>> | > };
>>> | >
>>> | > at24@50 {
>>> | > -   compatible = "at24,24c02";
>>> | > +   compatible = "at24,24c02", "atmel,24c02";
>>> |
>>> | I think you can just drop the at24 compatibles. A new kernel doesn't
>>> | need it. An old kernel ignores the manufacturer. I checked that u-boot
>>> | only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
>>> | couldn't find anything.
>>>
>>> I think you misunderstood what Rob means.
>>>
>>> In the case above it makes sense to drop the first compatible, as "at24" is
>>> not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.
>>>
>>> However, in cases where a real vendor/part combo is specified, like on
>>> r8a7791-koelsch.dts:
>>>
>>> -   compatible = "renesas,24c02";
>>> +   compatible = "atmel,24c02";
>>>
>>> you do want to keep the real vendor/part combo, i.e.
>>>
>>>  compatible = "renesas,24c02", "atmel,24c02";
>>
>> Yes, Geert is correct.
>>
>
> Sorry for misunderstanding your previous comment...
>
> How this should be documented in the DT binding? Should I include
> "renesas" as a valid manufacturer or only list the used
>  pairs (i.e: "renesas,24c02")?

However you are handling any of the vendors. I'll have to go look.

> I also wonder why this is really needed if AFAIU "renesas,24c02" is
> compatible with "atmel,24c02". IOW, the driver doesn't need to
> differentiate between the two since the devices are the same and will
> always match using "atmel,24c02".

It is needed, so that when a difference is found, it can be handled
without updating the DT.

Rob

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

2017-05-22 Thread Rob Herring

On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven
 wrote:
> Hi Javier,
>
> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
>  wrote:
>> This series is a follow-up to patch [0] that added an OF device ID table
>> to the at24 EEPROM driver. As you suggested [1], this version instead of
>> adding entries for every used  tuple, only adds a single
>> entry for each chip type using the "atmel" vendor as a generic fallback.
>>
>> This is a re-spin that addresses some issues pointed out by Rob Herring.
>>
>> The first patch documents in the DT binding what's the correct vendor to
>> use and what are the ones that are being deprecated. The second one adds
>> the OF device ID table for the at24 driver and the next patches use this
>> vendor in the compatible string to each DTS that defines a compatible I2C
>> EEPROM device node.
>>
>> Patches can be applied independently since the DTS changes without driver
>> changes are no-op and the OF table won't be used without the DTS changes.
>>
>> [0]: https://lkml.org/lkml/2017/3/14/589
>> [1]: https://lkml.org/lkml/2017/3/15/99
>>
>> Best regards,
>> Javier
>>
>> Changes in v4:
>> - Document the manufacturers that have been deprecated (Rob Herring).
>> - Only use the atmel manufacturer in the compatible string instead of
>>   keeping the deprecated ones (Rob Herring).
>
> I think you're referring to this (https://lkml.org/lkml/2017/4/19/1136)?
>
> | > --- a/arch/arm/boot/dts/am335x-baltos.dtsi
> | > +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
> | > @@ -255,7 +255,7 @@
> | > };
> | >
> | > at24@50 {
> | > -   compatible = "at24,24c02";
> | > +   compatible = "at24,24c02", "atmel,24c02";
> |
> | I think you can just drop the at24 compatibles. A new kernel doesn't
> | need it. An old kernel ignores the manufacturer. I checked that u-boot
> | only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
> | couldn't find anything.
>
> I think you misunderstood what Rob means.
>
> In the case above it makes sense to drop the first compatible, as "at24" is
> not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.
>
> However, in cases where a real vendor/part combo is specified, like on
> r8a7791-koelsch.dts:
>
> -   compatible = "renesas,24c02";
> +   compatible = "atmel,24c02";
>
> you do want to keep the real vendor/part combo, i.e.
>
>  compatible = "renesas,24c02", "atmel,24c02";

Yes, Geert is correct.

Rob

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

2017-05-22 Thread Geert Uytterhoeven

Hi Javier,

On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
 wrote:
> This series is a follow-up to patch [0] that added an OF device ID table
> to the at24 EEPROM driver. As you suggested [1], this version instead of
> adding entries for every used  tuple, only adds a single
> entry for each chip type using the "atmel" vendor as a generic fallback.
>
> This is a re-spin that addresses some issues pointed out by Rob Herring.
>
> The first patch documents in the DT binding what's the correct vendor to
> use and what are the ones that are being deprecated. The second one adds
> the OF device ID table for the at24 driver and the next patches use this
> vendor in the compatible string to each DTS that defines a compatible I2C
> EEPROM device node.
>
> Patches can be applied independently since the DTS changes without driver
> changes are no-op and the OF table won't be used without the DTS changes.
>
> [0]: https://lkml.org/lkml/2017/3/14/589
> [1]: https://lkml.org/lkml/2017/3/15/99
>
> Best regards,
> Javier
>
> Changes in v4:
> - Document the manufacturers that have been deprecated (Rob Herring).
> - Only use the atmel manufacturer in the compatible string instead of
>   keeping the deprecated ones (Rob Herring).

I think you're referring to this (https://lkml.org/lkml/2017/4/19/1136)?

| > --- a/arch/arm/boot/dts/am335x-baltos.dtsi
| > +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
| > @@ -255,7 +255,7 @@
| > };
| >
| > at24@50 {
| > -   compatible = "at24,24c02";
| > +   compatible = "at24,24c02", "atmel,24c02";
|
| I think you can just drop the at24 compatibles. A new kernel doesn't
| need it. An old kernel ignores the manufacturer. I checked that u-boot
| only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
| couldn't find anything.

I think you misunderstood what Rob means.

In the case above it makes sense to drop the first compatible, as "at24" is
not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.

However, in cases where a real vendor/part combo is specified, like on
r8a7791-koelsch.dts:

-   compatible = "renesas,24c02";
+   compatible = "atmel,24c02";

you do want to keep the real vendor/part combo, i.e.

 compatible = "renesas,24c02", "atmel,24c02";

like in v3, which is what I gave my Reviewed-by for.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

[PATCH v4 00/20] eeprom: at24: Add OF device ID table

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table

8 matches

Site Navigation

Mail list logo

Footer information