Hi Jamie,
Many thanks for your effort. If you need a new kernel for testing please let me
know.
Cheers,
Christian
Sent from my iPhone
> On 18. Jan 2018, at 02:59, Jamie Krueger
> wrote:
>
> Hi Madalin,
>
> On 01/16/2018 11:33 AM, Madalin-cristian Bucur wrote:
>
> Here are some results fro
On 17/01/18 22:25, Wei Yongjun wrote:
> Fix to return a negative error code from the request_irq() error
> handling case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
Reviewed-by: Alexey Kardashevskiy
> ---
> drivers/char/ipmi/ipmi_powernv.c | 5 +++--
>
9003a2498 removed checn from the DMA window pages allocator, however
the VFIO driver tests limits before doing so by calling
the get_table_size hook which was left behind; this fixes it.
Fixes: 9003a2498 "powerpc/powernv/ioda: Remove explicit max window size check"
Signed-off-by: Alexey Kardashevs
On Thu, 2018-01-18 at 12:27 +1100, Paul Mackerras wrote:
> > You need to check that it's a Nimbus using the top nimble of the bottom
> > 16 bits of PVR. For Cumulus, the fixes are either in 1.0 or 1.1 (to
> > check).
>
> OK, how about this for the check:
>
> if (cpu_has_feature(CPU_FTR_AR
Fix to return a negative error code from the request_irq() error
handling case instead of 0, as done elsewhere in this function.
Fixes: dce143c3381c ("ipmi/powernv: Convert to irq event interface")
Signed-off-by: Wei Yongjun
---
v1 -> v2: add fixes.
---
drivers/char/ipmi/ipmi_powernv.c | 5 +++--
On Wed, Jan 17, 2018 at 10:14:45PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2018-01-17 at 20:51 +1100, Paul Mackerras wrote:
> > +
> > + /*
> > +* POWER9 chips before version 2.02 can't have some threads in
> > +* HPT mode and some in radix mode on the same core.
> > +
On Thu, Jan 04, 2018 at 03:12:12PM -0600, Rob Herring wrote:
> Most subsystem specific functions have been moved into the respective
> subsystems. Only PCI and networking remain. This series moves most of the
> PCI related code to drivers/pci/of.c. Some bus address functions for PCI
> remain in of/
On Thu, Jan 04, 2018 at 03:12:12PM -0600, Rob Herring wrote:
> Most subsystem specific functions have been moved into the respective
> subsystems. Only PCI and networking remain. This series moves most of the
> PCI related code to drivers/pci/of.c. Some bus address functions for PCI
> remain in of/
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
arch/powerpc/kernel/setup-common.c
between commit:
349524bc0da6 ("powerpc: Don't preempt_disable() in show_cpuinfo()")
from the powerpc-fixes tree and commit:
f5f563012a70 ("powerpc: Make newline in cpuinfo uncondit
From: Christophe Leroy
Date: Tue, 16 Jan 2018 10:33:05 +0100 (CET)
> In case of TX timeout, fs_timeout() calls phy_stop(), which
> triggers the following BUG_ON() as we are in interrupt.
...
> This patch moves fs_timeout() actions into an async worker.
>
> Fixes: commit 48257c4f168e5 ("Add fs_e
On 17.01.2018 21:02, Nicolin Chen wrote:
> On Wed, Jan 17, 2018 at 08:38:48PM +0100, Maciej S. Szmigiero wrote:
>
>> However, I have a small nitpick regarding a comment newly added in
>> this version of patch 16:
>> +/*
>> + * Do not set SSI dev as the parent of AC97 CODEC
On Wed, Jan 17, 2018 at 08:38:48PM +0100, Maciej S. Szmigiero wrote:
> However, I have a small nitpick regarding a comment newly added in
> this version of patch 16:
> + /*
> + * Do not set SSI dev as the parent of AC97 CODEC device since
> + * it does not hav
On 17.01.2018 07:51, Nicolin Chen wrote:
> [ Maciej, could you please send your Tested-by/Reviewed-by for AC97
> once you confirm this series?
>
> And Caleb, this version does not need a test for non-AC97 cases.
>
> Thanks both! ]
>
> ==Change log==
> v5
> * Reworked the series by takin
parse_cache_info() parse device tree to detect various [i/d] cache properties.
But if no cache nodes found in device tree, these properties are set to zero
as default in init_cache_info().
Having a zero value could cause a infinite loop in rfi_flush_callback() since
l1d_size is used to determine t
On 01/16/18 18:50, Sukadev Bhattiprolu wrote:
> The Fast Thread Wake-up (FTW) driver provides user space applications an
> interface to the low latency Core-to-Core wakeup functionality in POWER9.
>
> This mechanism allows a thread on one core to efficiently send a message
> to a "waiting thread"
On 01/16/18 18:50, Sukadev Bhattiprolu wrote:
> Define the FTW_SETUP ioctl interface for fast thread wakeup (FTW). A
> follow-on patch will implement the FTW driver and ioctl.
>
> Thanks to input from Ben Herrenschmidt, Michael Neuling, Michael Ellerman.
>
> Signed-off-by: Sukadev Bhattiprolu
>
Mike Ellerman/Ben,
Do you know if we can make 4.16 with this?
-Bryant
On 1/5/18 10:45 AM, Bryant G. Ly wrote:
> This patch series will enable SR-IOV on PowerVM. A specific set of
> lids for PFW/PHYP is required. They are planned to release with
> 920 at the moment.
>
> For IBM internal tester
Frederic Barrat [fbar...@linux.vnet.ibm.com] wrote:
> Hi,
>
>
> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> > index 2010e4c..f20c1ad 100644
> > --- a/arch/powerpc/kernel/process.c
> > +++ b/arch/powerpc/kernel/process.c
> > @@ -1560,6 +1560,7 @@ void clear_threa
Allow PowerPC to skip the full memory barrier in switch_mm(), and
only issue the barrier when scheduling into a task belonging to a
process that has registered to use expedited private.
Threads targeting the same VM but which belong to different thread
groups is a tricky case. It has a few consequ
On Wed, Jan 17, 2018 at 05:52:24PM +0530, Naveen N. Rao wrote:
> Michael Ellerman reported the following call trace when running
> ftracetest:
>
> BUG: using __this_cpu_write() in preemptible [] code: ftracetest/6178
> caller is opt_pre_handler+0xc4/0x110
> CPU: 1 PID: 6178 Comm: ftracetes
On 01/17/2018 05:25 AM, Wei Yongjun wrote:
Fix to return a negative error code from the request_irq() error
handling case instead of 0, as done elsewhere in this function.
I think you are right here. However, you had a bunch of people on the email
that probably didn't need to be there, and did
On Tue, Jan 16, 2018 at 10:51 PM, Nicolin Chen wrote:
> [ Maciej, could you please send your Tested-by/Reviewed-by for AC97
> once you confirm this series?
>
> And Caleb, this version does not need a test for non-AC97 cases.
>
> Thanks both! ]
>
> ==Change log==
> v5
> * Reworked the series
Hi Kirill,
Thanks for reviewing this series.
On 16/01/2018 16:11, Kirill A. Shutemov wrote:
> On Fri, Jan 12, 2018 at 06:25:44PM +0100, Laurent Dufour wrote:
>> --
>> Benchmarks results
>>
>> Base kernel is 4.15-rc6-mmotm-2018-01-04-16-19
>> SPF is BASE + this series
>
> Do you h
On Thu, 1970-01-01 at 00:00 +, Madalin-cristian Bucur wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> > -Original Message-
> > From: Joakim Tjernl
> -Original Message-
> From: Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:25 PM
> To: David S . Miller
> Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> madskate...@gmail.com; 'Madalin-cristian Bucur' ;
> Andrew Lunn ; Joakim Tjernlund
>
> Subject: RE: DPAA Et
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Madalin-cristian Bucur
> Sent: Wednesday, January 17, 2018 4:16 PM
> To: Andrew Lunn ; Joakim Tjernlund
>
> Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> madskate..
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Wednesday, January 17, 2018 3:44 PM
> To: Joakim Tjernlund
> Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
>
> > That doesn't work really, having users to hit the bug, debug it, fix it
> and then
> >
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Tuesday, January 16, 2018 7:58 PM
> To: and...@lunn.ch
> Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
>
> On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote:
> >
> > Hi Joakim
>
The fallback RFI flush is used when firmware does not provide a way
to flush the cache. It's a "displacement flush" that evicts useful
data by displacing it with an uninteresting buffer.
The flush has to take care to work with implementation specific cache
replacment policies, so the recipe has be
> That doesn't work really, having users to hit the bug, debug it, fix it and
> then
> find it fixed already in upstream, then specifically request it to be
> backported to stable.
> I don't need this fix to be backported, already got it. Someone else might
> though.
The "someone else might th
Le 15/01/2018 à 14:39, Philippe Bergheaud a écrit :
Configure the P9 XSL_DSNCTL register with PHB indications found
in the device tree, or else use legacy hard-coded values.
Signed-off-by: Philippe Bergheaud
---
I'm still ok with v7, thanks for fixing the errno.
Acked-by: Frederic Barrat
On Fri, 2017-12-08 at 16:34:29 UTC, Christophe Leroy wrote:
> This patch remove CONFIG_PPC_HTDUMP if not PPC_BOOK3S_64 to avoid
> below compile failure on BOOK3S_32:
>
> CC arch/powerpc/mm/dump_linuxpagetables.o
> CC arch/powerpc/mm/dump_hashpagetable.o
> In file included from arch/p
On Tue, 2018-01-16 at 07:29:49 UTC, Christophe Leroy wrote:
> Since commit 0e6e01ff694ee ("CPM/QE: use genalloc to manage CPM/QE
> muram"), rheap is not used anymore.
>
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9a3b849bfe5cba18492acf5add
On Fri, 2018-01-12 at 02:28:49 UTC, Benjamin Herrenschmidt wrote:
> Trap numbers can have extra bits at the bottom that need to
> be filtered out. There are a few cases where we don't do that.
>
> It's possible that we got lucky but better safe than sorry.
>
> Signed-off-by: Benjamin Herrenschmid
On Fri, 2018-01-12 at 12:45:19 UTC, Christophe Leroy wrote:
> CPU6 ERRATA affects only MPC860 revisions prior to C.0. Manufacturing
> of those revisiosn was stopped in 1999-2000.
> Therefore, it has been almost 20 years since this ERRATA has been
> fixed in the silicon.
>
> This patch removes the
On Fri, 2018-01-12 at 02:28:48 UTC, Benjamin Herrenschmidt wrote:
> The only difference between EXC_COMMON_HV and EXC_COMMON is that the
> former adds "2" to the trap number which is supposed to represent the
> fact that this is an "HV" interrupt which uses HSRR0/1.
>
> However KVM is the only one
On Fri, 2018-01-12 at 02:28:45 UTC, Benjamin Herrenschmidt wrote:
> WORD2 if the TIMA isn't byte accessible and
> isn't that useful to know about, take out the
> pr_devel statement.
>
> Signed-off-by: Benjamin Herrenschmidt
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f5abe
Le 15/01/2018 à 14:39, Philippe Bergheaud a écrit :
P9 supports PCI tunneled operations (atomics and as_notify). This
patch adds support for tunneled operations on powernv, with a new
API, to be called by device drivers:
pnv_pci_get_tunnel_ind()
Tell driver the 16-bit ASN indication used b
On Wed, 2018-01-10 at 06:10:13 UTC, Benjamin Herrenschmidt wrote:
> We used to not put the newline between the CPU part and the summary
> part on UP kernels. This is a rather pointless ifdef so take it out.
>
> Signed-off-by: Benjamin Herrenschmidt
Applied to powerpc next, thanks.
https://git.k
On Wed, 2018-01-10 at 06:10:14 UTC, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/fbadeb6bb1685f7a53869e240284ff
cheers
On Wed, 2017-12-20 at 01:51:00 UTC, Benjamin Herrenschmidt wrote:
> These adapters can be found in a number of our systems, so let's
> enable the corresponding drivers by default.
>
> Signed-off-by: Benjamin Herrenschmidt
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/bba9bc8
On Tue, 2018-01-02 at 11:03:24 UTC, Michael Ellerman wrote:
> Add a test case of the error code reported when we take a SEGV on a
> mapped but inaccessible area. We broke this recently.
>
> Based on a test case from John Sperbeck .
>
> Signed-off-by: Michael Ellerman
> Acked-by: John Sperbeck
On Fri, 2017-12-15 at 08:14:54 UTC, Balbir Singh wrote:
> Our check was extra cautious, we've audited crash_send_ipi
> and it sends an IPI only to online CPU's. Removal of this
> check should have not functional impact on crash kdump.
>
> Signed-off-by: Balbir Singh
> Reviewed-by: Nicholas Piggin
On Mon, 2017-12-04 at 02:19:10 UTC, "Aneesh Kumar K.V" wrote:
> No functional change in this patch. This update gup_hugepte to use the
> helper. This will help later when we add memory keys.
>
> Signed-off-by: Aneesh Kumar K.V
Series applied to powerpc next, thanks.
https://git.kernel.org/power
On Fri, 2017-12-01 at 16:48:03 UTC, Nathan Fontenot wrote:
> Add required bits to the architecture vector to enable support
> of the ibm,dynamic-memory-v2 device tree property.
>
> Signed-off-by: Nathan Fontenot
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0c38ed6f6f0b78a40
On Fri, 2017-12-01 at 16:47:53 UTC, Nathan Fontenot wrote:
> The Power Hypervisor has introduced a new device tree format for
> the property describing the dynamic reconfiguration LMBs for a system,
> ibm,dynamic-memory-v2. This new format condenses the size of the
> property, especially on large m
On Fri, 2017-12-01 at 16:46:35 UTC, Nathan Fontenot wrote:
> Look up the device node for the associativity array property instead
> of having it passed in as a parameter. This changes precedes an update
> in which the calling routines for of_get_assoc_arrays() will not have
> the device node pointe
On Mon, 2017-11-06 at 08:50:45 UTC, Ram Pai wrote:
> Introduce pte_set_hidx().It sets the (H_PAGE_F_SECOND|H_PAGE_F_GIX) bits
> at the appropriate location in the PTE of 4K PTE. For 64K PTE, it sets
> the bits in the second part of the PTE. Though the implementation for
> the former just needs the
On Wed, 2017-02-01 at 01:54:38 UTC, Dmitry Torokhov wrote:
> Instead of manually coding the loop with of_find_node_by_type(), let's
> switch to the standard macro for iterating over nodes with given type.
>
> Also fixed a couple of refcount leaks in the aforementioned loops.
>
> Signed-off-by: Dm
On Tue, 2018-01-16 at 11:24:31 UTC, Michael Ellerman wrote:
> Expose the state of the RFI flush (enabled/disabled) via debugfs, and
> allow it to be enabled/disabled at runtime.
>
> eg: $ cat /sys/kernel/debug/powerpc/rfi_flush
> 1
> $ echo 0 > /sys/kernel/debug/powerpc/rfi_flush
> $ c
On Tue, 2018-01-16 at 11:24:01 UTC, Michael Ellerman wrote:
> The recent commit 87590ce6e373 ("sysfs/cpu: Add vulnerability folder")
> added a generic folder and set of files for reporting information on
> CPU vulnerabilities. One of those was for meltdown:
>
> /sys/devices/system/cpu/vulnerabil
On Mon, 2018-01-15 at 13:30:03 UTC, Michal Suchanek wrote:
> Commit 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
> settings") uses u64 in asm/hvcall.h without including linux/types.h
>
> This breaks hvcall.h users that do not include the header themselves.
>
> Fixes: 6e032b350c
On Wed, 2018-01-10 at 14:19:46 UTC, Michael Ellerman wrote:
> Remember when the biggest problem we had to worry about was hashed
> pointers, those were the days.
>
> These were missed in my earlier patch because they don't match "%p",
> but the macro is hiding a "%p", so these all end up being has
On Wed, 2018-01-10 at 13:28:56 UTC, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/274920a3ecd5f43af0cc380bc0a9ee
cheers
On Wed, 2018-01-10 at 06:10:12 UTC, Benjamin Herrenschmidt wrote:
> This causes warnings from cpufreq mutex code. This is also
> rather unnecessary and ineffective. If we really want to
> prevent concurrent unplug, we could take the unplug read
> lock but I don't see this being critical.
>
> Signe
The powerpc NMI IPIs may not be recoverable if they are taken in
some sections of code, and also there have been and still are issues
with taking NMIs (in KVM guest code, in firmware, etc) which makes them
a bit dangerous to use.
Generic code like softlockup detector and rcu stall detectors really
After using the new compiled 4.14 rc8 kernel without PAMU support posted by
Christian Zigotzky the X5000 can use the Network interface with some minor
issues.
I had to give the Eth0 a manual IP due to not responding on DHCP requests.
I can ping my Gateway, and even DNS queries work..
But when i
Michael Ellerman reported the following call trace when running
ftracetest:
BUG: using __this_cpu_write() in preemptible [] code: ftracetest/6178
caller is opt_pre_handler+0xc4/0x110
CPU: 1 PID: 6178 Comm: ftracetest Not tainted 4.15.0-rc7-gcc6x-gb2cd1df #1
Call Trace:
[c000f9ec39c0] [
I'm not sure if I like this, as said in the other mail. Seems a bit
arbitrary. I wouldn't mind making a single special opal call,
OPAL_MAYDAY, which is allowed through the reentrancy check, stops
all other CPUs, prints some opal backtraces, then allows the remaining
CPU to issue more OPAL calls, so
- Linux uses r13 as a per-cpu register.
- Does not restore r13 when returning from interrupt to kernel context
(MSR[PR]=0), to accommodate migrating to a different CPU.
- OPAL runs with MSR[PR]=0.
- OPAL uses r13 for its own register.
- OPAL runs with MSR[RI]=1.
This means that if we take an int
Fix to return a negative error code from the request_irq() error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/char/ipmi/ipmi_powernv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_powernv
On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> > > You appear to be using an old kernel. Take a look at:
> >
On Wed, 2018-01-17 at 20:51 +1100, Paul Mackerras wrote:
> +
> + /*
> +* POWER9 chips before version 2.02 can't have some threads in
> +* HPT mode and some in radix mode on the same core.
> +*/
> + if (cpu_has_feature(CPU_FTR_ARCH_300)) {
> + unsign
Le 17/01/2018 à 04:19, Aneesh Kumar K.V a écrit :
On 01/16/2018 10:18 PM, Christophe LEROY wrote:
Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
An application running with libhugetlbfs fails to allocate
additional pages to HEAP due to the hugemap being done
POWER9 has hardware bugs relating to transactional memory and thread
reconfiguration (changes to hardware SMT mode). Specifically, the core
does not have enough storage to store a complete checkpoint of all the
architected state for all four threads. The DD2.2 version of POWER9
includes hardware
This adds a CPU feature bit which is set for POWER9 "Nimbus" DD2.2
processors which will be used to enable software emulation for some
transactional memory instructions, in order to work around hardware
bugs.
Signed-off-by: Paul Mackerras
---
arch/powerpc/include/asm/cputable.h | 5 -
arch/
Hypervisor maintenance interrupts (HMIs) are generated by various
causes, signalled by bits in the hypervisor maintenance exception
register (HMER). In most cases calling OPAL to handle the interrupt
is the correct thing to do, but the "debug trigger" HMIs signalled by
PPC bit 17 (bit 46) of HMER
This moves the code that loads and unloads the guest SLB values so that
it is done while the guest LPCR value is loaded in the LPCR register.
The reason for doing this is that on POWER9, the behaviour of the
slbmte instruction depends on the LPCR[UPRT] bit. If UPRT is 1, as
it is for a radix host
POWER9 chip versions starting with v2.2 can support running with some
threads of a core in HPT mode and others in radix mode. This means
that we don't have to prohibit independent-threads mode when running
a HPT guest on a radix host, and we don't have to do any of the
synchronization between thre
The POWER9 "Nimbus" v2.2 (referred to as DD2.2) chip has some hardware
bugs fixed that were present in earlier versions, and contains new
workarounds for other hardware bugs.
POWER9 DD2.2 can run with some threads of a core in hashed page table
(HPT) MMU mode while other threads are in radix MMU m
This fixes a bug where it is possible to enter a guest on a POWER9
system without having the XIVE (interrupt controller) context loaded.
This can happen because we unload the XIVE context from the CPU
before doing the real-mode handling for machine checks. After the
real-mode handler runs, it is p
Le 17/01/2018 à 06:23, Aneesh Kumar K.V a écrit :
Christophe LEROY writes:
How should I split in separate patches ? Something like ?
1/ Slice support for PPC32 > 2/ Activate slice for 8xx
Yes something like that. Will you be able to avoid that
if (SLICE_NUM_HIGH) from the code? That
On the 8xx, we can have as many slices as PMD entries.
This means we could have 1024 slices in 4k size pages mode
and 64 slices in 16k size pages.
However, due to a stack overflow in slice_get_unmapped_area(),
we limit to 512 slices.
Signed-off-by: Christophe Leroy
---
v2: no change
arch/powe
While the implementation of the "slices" address space allows
a significant amount of high slices, it limits the number of
low slices to 16 due to the use of a single u64 low_slices_psize
element in struct mm_context_t
On the 8xx, the minimum slice size is the size of the area
covered by a single
bitmap_or() and bitmap_andnot() can work properly with dst identical
to src1 or src2. There is no need of an intermediate result bitmap
that is copied back to dst in a second step.
Signed-off-by: Christophe Leroy
---
v2: New in v2
arch/powerpc/mm/slice.c | 15 +++
1 file changed, 3
On the 8xx, the page size is set in the PMD entry and applies to
all pages of the page table pointed by the said PMD entry.
When an app has some regular pages allocated (e.g. see below) and tries
to mmap() a huge page at a hint address covered by the same PMD entry,
the kernel accepts the hint all
In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch enhances the
'slices' implementation to support 32 bits CPUs.
On PPC32, the address space is limited to 4Gbytes, hence only the low
slices will be used. As of today, the code uses
SLICE_L
On 17/01/2018 04:04, Andi Kleen wrote:
> Laurent Dufour writes:
>
>> From: Peter Zijlstra
>>
>> One of the side effects of speculating on faults (without holding
>> mmap_sem) is that we can race with free_pgtables() and therefore we
>> cannot assume the page-tables will stick around.
>>
>> Remov
78 matches
Mail list logo
