On Mon, 2016-05-30 at 16:18 +1000, Rashmica Gupta wrote:
> MPIC was only used by Power3 which is now unsupported, so drop support
> for MPIC. XICS is now the only supported interrupt controller for
> pSeries so make the XICS functions generic.
The second half I'm not sure ... XIVE is around the co
On Mon, May 30, 2016 at 9:28 AM, Geert Uytterhoeven
wrote:
> + /home/kisskb/slave/src/arch/powerpc/include/asm/nohash/64/pgalloc.h:
> error: implicit declaration of function 'pte_fragment_fre'
> [-Werror=implicit-function-declaration]/home/kisskb/slave/src/arch/powerpc/mm/pgtable.c:
> At top
On Mon, 23 May 2016 10:28:28 +0200
Greg Kurz wrote:
> A strange behaviour is observed when comparing PCI hotplug in QEMU, between
> x86 and pseries. If you consider the following steps:
> - start a VM
> - add a PCI device via the QEMU monitor before the rtasd has started (for
> example starting
On 13.05.2016 05:35, Paul Mackerras wrote:
> On Thu, May 12, 2016 at 01:26:44PM +0200, Thomas Huth wrote:
>> The SIAR and SDAR registers are available twice, one time as SPRs
>> 780 / 781 (unprivileged, but read-only), and one time as the SPRs
>> 796 / 797 (privileged, but read and write). The Linu
On Sun, May 29, 2016 at 10:03:50PM +1000, Anton Blanchard wrote:
> From: Anton Blanchard
>
> In both __giveup_fpu() and __giveup_altivec() we make two modifications
> to tsk->thread.regs->msr. gcc decides to do a read/modify/write of
> each change, so we end up with a load hit store:
>
>
Anton Blanchard writes:
> Hi Ben,
>
>> That is surprising, do we have any idea what specifically increases
>> the overhead so significantly ? Does gcc know about ldbrx/stdbrx ? I
>> notice in our io.h for example we still do manual ld/std + swap
>> because old processors didn't know these, we sho
On 2016/05/24 03:45PM, Madhavan Srinivasan wrote:
>
>
> On Thursday 19 May 2016 08:40 PM, Anju T wrote:
> > Detour buffer contains instructions to create an in memory pt_regs.
> > After the execution of prehandler a call is made for instruction emulation.
> > The NIP is decided after the probed i
On Thu, May 26, 2016 at 02:21:42PM -0700, Andrew Morton wrote:
> On Thu, 5 May 2016 17:57:13 +1000 "Oliver O'Halloran"
> wrote:
>
> > As a part of memory initialisation the architecture passes an array to
> > free_area_init_nodes() which specifies the max PFN of each memory zone.
> > This array
Hi Scott,
On 17 May 2016 at 01:41, Scott Wood wrote:
> On Wed, Apr 27, 2016 at 10:35:25AM +0200, Alessio Igor Bogani wrote:
>> + bcsr@4,0 {
>> + compatible = "artesyn,mvme7100-bcsr";
>> + reg = <4 0 0x1>;
>> + };
>> +
>> +
Add support for the Artesyn MVME7100 Single Board Computer.
The MVME7100 is a 6U form factor VME64 computer with:
- A two e600 cores Freescale MPC8641D CPU
- 2 GB of DDR2 onboard memory
- Four Gigabit Ethernets
- Five 16550 compatible UARTs
- One USB 2.0 port
- Two PCI/PCI
Hi,
> I see the same issue in unmap_page_range(), __hash_page_64K(),
> handle_mm_fault().
This looks to be about 10% slower on POWER8:
#include
#include
#include
#define ITERATIONS 1000
#define MEMSIZE (128 * 1024 * 1024)
int main(void)
{
unsigned long i = ITERATIONS;
hello everyone
I'm trying to run qemu for powerpc architecture but either
*1/* i got a black screen with this sentence " QEMU 2.4.0.1 monitor - type
help for more information"
(QEMU)
if i run this command ./ppc-softmmu/qemu-system-ppc -M ppce500 -kernel
../linux-4.4.1/arch/po
On Mon, 2016-05-30 at 14:12 +0530, Aneesh Kumar K.V wrote:
> /* Encode and de-code a swap entry */
> @@ -516,10 +533,12 @@ static inline pte_t pte_swp_mksoft_dirty(pte_t
> pte)
> {
> return __pte(pte_val(pte) | _PAGE_SWP_SOFT_DIRTY);
> }
These kind of setters (and mkspecial etc...) coul
The resource_alignment will releases memory resources allocated
by firmware so that kernel can reassign new resources later on.
But this will cause the problem that no resources can be
allocated by kernel if PCI_PROBE_ONLY was set, e.g. on pSeries
platform because PCI_PROBE_ONLY force kernel to use
This series aims to add an option for PCI resource allocator to
force BARs not to share PAGE_SIZE. This would make sense to VFIO
driver. Because current VFIO implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs which may share the same page
with other BARs for security reasons
Now we use the IORESOURCE_STARTALIGN to identify bridge resources
in __assign_resources_sorted(). That's quite fragile. We can't
make sure that the PCI devices' resources will not use
IORESOURCE_STARTALIGN any more.
In this patch, we try to use a more robust way to identify
bridge resources.
Sign
When using resource_alignment kernel parameter, the current
implement reassigns the alignment by changing resources' size
which can potentially break some drivers. For example, the driver
uses the size to locate some register whose length is related
to the size.
This patch adds a new option "nores
When vfio passthrough a PCI device of which MMIO BARs are
smaller than PAGE_SIZE, guest will not handle the mmio
accesses to the BARs which leads to mmio emulations in host.
This is because vfio will not allow to passthrough one BAR's
mmio page which may be shared with other BARs. Otherwise,
there
On Thursday, May 26, 2016 9:44:10 AM CEST Ulf Hansson wrote:
> On 26 May 2016 at 06:05, Yangbo Lu wrote:
> > Hi Uffe,
> >
> > Could we merge this patchset? ...
> > It has been a long time to wait for Arnd's response...
> >
> > Thanks a lot.
> >
> >
>
> As we are still in the merge window I won't
We keep running into cases where device drivers want to know the exact
version of the SoC a they are currently running on. In the past, this
has usually been done through a vendor specific API that can be called
by a driver, or by directly accessing some kind of version register
that is not part of
From: Yangbo Lu
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
[arnd turned t
This is a rewrite of an earlier patch from Yangbo Lu, adding a quirk
for the NXP QorIQ T4240 in the detection of the host device version.
Unfortunately, this device cannot be detected using the compatible
string, as we have to support existing DTS files that use the generic
"fsl,t4240-esdhc" ident
On Mon, May 30, 2016 at 7:15 PM, Mel Gorman wrote:
> On Thu, May 26, 2016 at 02:21:42PM -0700, Andrew Morton wrote:
>> On Thu, 5 May 2016 17:57:13 +1000 "Oliver O'Halloran"
>> wrote:
>>
>> > As a part of memory initialisation the architecture passes an array to
>> > free_area_init_nodes() which
All users of this driver are PowerPC specific and the header file
has no business in the global include/linux/ hierarchy, so move
it back before anyone starts using it on ARM.
This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
Signed-off-by: Arnd Bergmann
---
This part of the series i
We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs assigned for it. In other words, the hardware
c
Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that users can write directly
to MSI-X table and generate an incorrect MSIs.
However, this will cause some performance issue when there
are some critical device registers in the same page as the
MSI-X table.
On ARM HW the capability of IRQ remapping is abstracted on
MSI controller side. MSI_FLAG_IRQ_REMAPPING is used to advertise
this [1].
To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when MSI_FLAG_IRQ_REMAPPING is set.
Some iommu drivers would be initialized after PCI device
enumeration. So PCI_BUS_FLAGS_MSI_REMAP would not be set
when probing PCI devices although IOMMU enables capability
of IRQ remapping. This patch tests this capability and
set the flag when iommu driver is initialized.
Signed-off-by: Yongji X
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
Reviewed-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c |8
1 file changed, 8 insertions(+)
dif
The capability of IRQ remapping is abstracted on IOMMU side on
some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for this.
To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when IOMMU_CAP_INTR_REMAP is set.
Signe
This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping. This capability can ensure that a
given PCI device can only shoot the MSIs assigned for it. That
means a userspace driver could never hurt other devices or system
by writing to the exposed MSI-X table dire
On 05/24/2016 03:15 PM, Shreyas B. Prabhu wrote:
POWER ISA v3 defines a new idle processor core mechanism. In summary,
a) new instruction named stop is added.
b) new per thread SPR named PSSCR is added which controls the behavior
of stop instruction.
Supported idle states and value t
Benjamin Herrenschmidt writes:
> On Mon, 2016-05-30 at 14:12 +0530, Aneesh Kumar K.V wrote:
>> /* Encode and de-code a swap entry */
>> @@ -516,10 +533,12 @@ static inline pte_t pte_swp_mksoft_dirty(pte_t
>> pte)
>> {
>> return __pte(pte_val(pte) | _PAGE_SWP_SOFT_DIRTY);
>> }
>
> These
On Monday, May 30, 2016 3:14:38 PM CEST Arnd Bergmann wrote:
> We keep running into cases where device drivers want to know the exact
> version of the SoC a they are currently running on. In the past, this
> has usually been done through a vendor specific API that can be called
> by a driver, or by
On Mon, May 30, 2016 at 07:27:11AM +1000, Benjamin Herrenschmidt wrote:
> > > This enables us to share the same page table code for
> > > both radix and hash. Radix use a hardware defined big endian
> > > page table
> > This is measurably worse (a little over 2% on POWER8) on a futex
> > microbench
Hi Ram,
On 05/28/2016 05:36 AM, Ram Pai wrote:
> On Tue, May 24, 2016 at 06:45:12PM +0530, Shreyas B. Prabhu wrote:
[snip]
>> @@ -230,11 +236,18 @@ static DEVICE_ATTR(fastsleep_workaround_applyonce,
>> 0600,
>> show_fastsleep_workaround_applyonce,
>> stor
On Fri, 27 May 2016, Aneesh Kumar K.V wrote:
> When we converted the asm routines to C functions, we missed updating
> HPTE_R_R based on _PAGE_ACCESSED. ASM code used to copy over the lower
> bits from pte via.
>
> andi. r3,r30,0x1fe/* Get basic set of flags */
>
> Fixes: 'commit 89f
Nothing on these architectures ever includes the asm/mc146818rtc.h
file, the drivers that used to do this have been fixed long ago,
and the remaining users are all PC-specific.
This removes the files for good.
Signed-off-by: Arnd Bergmann
Acked-by: Alexandre Belloni
---
arch/frv/include/asm/mc
The q40 platform is the only machine in the kernel that provides
RTC_PLL_GET/RTC_PLL_SET ioctl commands in its rtc through the
mach_get_rtc_pll/mach_set_rtc_pll callbacks.
However, this currenctly works only in the old-style genrtc
driver, not the (somewhat) modern rtc-generic driver replacing
it.
The genrtc driver serves no purpose on mn10300 because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.
I assume it was initially only added for completeness when the
mn10300 port was
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and m68k has another abstraction on top, which is a bit
silly.
This changes the m68k rtc-generic device to provide its
rtc_class_ops directly, to reduce the number of layers
by one.
S
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and powerpc has another abstraction on top, which is a bit
silly.
This changes the powerpc rtc-generic device to provide its
rtc_class_ops directly, to reduce the number of layers
by o
The asm/rtc.h header is only used for the old gen_rtc driver
that has been replaced by rtc-generic. According to Geert
Uytterhoeven, nobody has used the old driver on m68k for
a long time, so we can now just remove the header file
and disallow the driver in Kconfig.
All files that used to include
The genrtc driver serves no purpose on Alpha because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.
The defconfig uses CONFIG_RTC=y, so this driver is not used by default.
At one po
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and on sh, that goes through another indirection using
the rtc_sh_get_time/rtc_sh_set_time functions.
This changes the sh rtc-generic device to provide its
rtc_class_ops directly, skip
This is the promised resend of the removal of the genrtc driver and some
related code, now that we are at a good time to merge this for the coming
merge window.
The contents are the same as before, except fixing the build regressions
reported by the 0day builder: on both x86 and mn10300 the rearra
This architecture selects RTC_CLASS unconditionally, so the GEN_RTC
has not worked here for a long time.
Now we can remove both the asm/rtc.h header and the Kconfig dependency
for CONFIG_GEN_RTC.
Signed-off-by: Arnd Bergmann
---
arch/parisc/include/asm/rtc.h | 131 --
PowerPC is the last architecture using the GEN_RTC driver on some
machines, but we can migrate them all to using the RTC_DRV_GENERIC
driver instead now.
This moves over the CONFIG_GEN_RTC option from drivers/char into
arch/powerpc/platforms/Kconfig and makes it just select the
replacement driver i
No architecture uses the genrtc driver any more, so let's kill it off
for good. This now also includes asm-generic/rtc.h, which is otherwise
completely unused.
Signed-off-by: Arnd Bergmann
---
drivers/char/Kconfig | 26 ---
drivers/char/Makefile | 1 -
drivers/char/genrtc.c | 539
All architectures using this driver are now converted to
provide their own operations, so this one can be turned
into a trivial stub driver relying on its platform data.
Signed-off-by: Arnd Bergmann
---
drivers/rtc/rtc-generic.c | 35 +--
1 file changed, 1 inserti
Drivers should not really include stuff from asm-generic directly,
and the PC-style cmos rtc driver does this in order to reuse the
mc146818 implementation of get_rtc_time/set_rtc_time rather than
the architecture specific one for the architecture it gets built for.
To make it more obvious what is
arch/mips/sni/time.c includes asm-generic/rtc.h for no apparent reason,
and it works fine without that header, so lets remove the inclusion
in preparation of deleting the file.
Signed-off-by: Arnd Bergmann
---
arch/mips/sni/time.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/sni/
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and on pa-risc, that is implemented using an open-coded
version of rtc_time_to_tm/rtc_tm_to_time.
This changes the parisc rtc-generic device to provide its
rtc_class_ops directly, usin
Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
which in turn disables the selection of the CONFIG_RTC and
CONFIG_GEN_RTC drivers that contain a two older implementations of
the CONFIG_RTC_DRV_CMOS driver.
Hi,
On 30/05/2016 at 20:57:48 +0200, Arnd Bergmann wrote :
> This is the promised resend of the removal of the genrtc driver and some
> related code, now that we are at a good time to merge this for the coming
> merge window.
>
Thanks a lot!
I'm applying the series right now so it sits in linux
On Mon, 2016-05-30 at 09:39 -0700, Hugh Dickins wrote:
> I don't mean to be churlish, and subtract from your triumph in tracking
> this down (assuming you have), but that commit log... okay, it's intended
> for powerpc mmu experts, not me, but if it hasn't already gone into git,
> then a rewrite co
On Fri, 2016-05-27 at 13:06 +, John W Walthour wrote:
>
> Those come from
> XSL_databook_09_June_2014.pdf
Where do I find that?
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, 2016-05-26 at 11:05 +0200, Safa Hamza wrote:
> hello every one
> please can any one suggest to me a powerpc cross compiler package or from
> source, i have downloaded cross compiler package such as powerpc64le and i
> got a little endian and big endian problem, i have tried also to downl
On Fri, 2016-05-27 at 10:07 +0200, Laurent Dufour wrote:
> On 21/04/2016 18:00, Laurent Dufour wrote:
> > On 13/04/2016 07:14, Michael Ellerman wrote:
> > > On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote:
> > > > On 07/04/2016 23:49, Michael Ellerman wrote:
> > > > > On 7 April 2016 7
On Mon, 2016-05-30 at 10:04 +0200, Thomas Huth wrote:
> On 13.05.2016 05:35, Paul Mackerras wrote:
> > On Thu, May 12, 2016 at 01:26:44PM +0200, Thomas Huth wrote:
> > > The SIAR and SDAR registers are available twice, one time as SPRs
> > > 780 / 781 (unprivileged, but read-only), and one time as
On 31/05/16 09:01, Michael Ellerman wrote:
Those come from
XSL_databook_09_June_2014.pdf
Where do I find that?
My understanding is that it's IBM Confidential and isn't available to
the general community, unfortunately.
Andrew
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.d
On Sun, 2016-05-29 at 22:03 +1000, Anton Blanchard wrote:
> From: Anton Blanchard
>
> In many cases we disable interrupts right before calling
> find_linux_pte_or_hugepte().
>
> find_linux_pte_or_hugepte() first checks interrupts are disabled
> before calling __find_linux_pte_or_hugepte():
>
>
On Thu, May 26, 2016 at 9:29 PM, Safa Hamza wrote:
>
> thanks for replying, I tried a powerpc cross compiler from the list you have
> send but I always got this error
>
> VDSO32L arch/powerpc/kernel/vdso32/vdso32.so.dbg
> /home/marwa/Bureau/lauterbach/powerpc/gcc-4.6.3-nolibc/powerpc64-linux/bin/
On 30/05/16 17:32, Benjamin Herrenschmidt wrote:
On Mon, 2016-05-30 at 16:18 +1000, Rashmica Gupta wrote:
MPIC was only used by Power3 which is now unsupported, so drop support
for MPIC. XICS is now the only supported interrupt controller for
pSeries so make the XICS functions generic.
The se
On 31/05/16 11:34, Rashmica wrote:
On 30/05/16 17:32, Benjamin Herrenschmidt wrote:
On Mon, 2016-05-30 at 16:18 +1000, Rashmica Gupta wrote:
MPIC was only used by Power3 which is now unsupported, so drop support
for MPIC. XICS is now the only supported interrupt controller for
pSeries so ma
On Tue, 2016-05-31 at 11:34 +1000, Rashmica wrote:
>
> On 30/05/16 17:32, Benjamin Herrenschmidt wrote:
> >
> > On Mon, 2016-05-30 at 16:18 +1000, Rashmica Gupta wrote:
> > >
> > > MPIC was only used by Power3 which is now unsupported, so drop support
> > > for MPIC. XICS is now the only support
Michael Ellerman writes:
> On Sun, 2016-05-29 at 22:03 +1000, Anton Blanchard wrote:
>
>> From: Anton Blanchard
>>
>> In many cases we disable interrupts right before calling
>> find_linux_pte_or_hugepte().
>>
>> find_linux_pte_or_hugepte() first checks interrupts are disabled
>> before callin
On Tue, 2016-05-31 at 08:59 +0530, Aneesh Kumar K.V wrote:
> Michael Ellerman writes:
> > On Sun, 2016-05-29 at 22:03 +1000, Anton Blanchard wrote:
> > > From: Anton Blanchard
> > >
> > > In many cases we disable interrupts right before calling
> > > find_linux_pte_or_hugepte().
> > >
> > > fin
On Tue, 2016-05-31 at 09:48 +1000, oliver wrote:
> On Thu, May 26, 2016 at 9:29 PM, Safa Hamza wrote:
> >
> > thanks for replying, I tried a powerpc cross compiler from the list you have
> > send but I always got this error
> >
> > VDSO32L arch/powerpc/kernel/vdso32/vdso32.so.dbg
> > /home/ma
On Tue, 2016-05-31 at 12:48 +1000, Rashmica wrote:
>
> Oliver just informed me that it is only replacing XICS for p9. Should
> I leave this for the person adding in the XIVE code?
That would be me ;-) It will cost you a beer !
Cheers,
Ben.
___
Linuxpp
On Tue, 2016-05-31 at 12:48 +1000, Rashmica wrote:
> On 31/05/16 11:34, Rashmica wrote:
> > On 30/05/16 17:32, Benjamin Herrenschmidt wrote:
> > > On Mon, 2016-05-30 at 16:18 +1000, Rashmica Gupta wrote:
> > > > MPIC was only used by Power3 which is now unsupported, so drop support
> > > > for MPIC
On Tue, 2016-05-31 at 15:04 +1000, Michael Ellerman wrote:
> I haven't heard of this "XIVE" thing but anyway ..
>
> I would hope we can come up with a better abstraction than this for XICS/XIVE,
> so I'm inclined to merge this anyway. Worst case we end up putting some of it
> back.
Just merge it,
If we do not provide the PVR for POWER8NVL, a guest on this
system currently ends up in PowerISA 2.06 compatibility mode on
KVM, since QEMU does not provide a generic PowerISA 2.07 mode yet.
So some new instructions from POWER8 (like "mtvsrd") get disabled
for the guest, resulting in crashes when u
On Tue, 2016-05-10 at 14:57 +1000, Oliver O'Halloran wrote:
> POWER ISA v3 adds large decrementer (LD) mode of operation which increases
> the size of the decrementer register from 32 bits to an implementation
> defined with of up to 64 bits.
>
> This patch adds support for the LD on processors wi
LPCR cannot be updated when running in guest mode.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/pgtable-radix.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index 18b2c11604f
When we converted the asm routines to C functions, we missed updating
HPTE_R_R based on _PAGE_ACCESSED. ASM code used to copy over the lower
bits from pte via.
andi. r3,r30,0x1fe/* Get basic set of flags */
Fixes: 'commit 89ff725051d1 ("powerpc/mm: Convert __hash_page_64K to C")'
W
This should not have any impact on hash, because hash does tlb
invalidate with every pte update and we don't implement
flush_tlb_* functions for hash. With radix we should make an explicit
call to flush tlb outside pte update.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/pgtable-book3s64.
Michael Ellerman writes:
> On Tue, 2016-05-31 at 08:59 +0530, Aneesh Kumar K.V wrote:
>> Michael Ellerman writes:
>> > On Sun, 2016-05-29 at 22:03 +1000, Anton Blanchard wrote:
>> > > From: Anton Blanchard
>> > >
>> > > In many cases we disable interrupts right before calling
>> > > find_linux
Allo Alexandre,
On Mon, May 30, 2016 at 10:32 PM, Alexandre Belloni
wrote:
> On 30/05/2016 at 20:57:48 +0200, Arnd Bergmann wrote :
>> This is the promised resend of the removal of the genrtc driver and some
>> related code, now that we are at a good time to merge this for the coming
>> merge win
79 matches
Mail list logo
