From: Li, Zhen-Hua zhen-h...@hp.com
This patch is trying to fix bug QXCR1001261767.
On some HP platform, when usb driver inits the iLo Virtual USB Controller,
there may be a warning Controller not stopped yet!. It is because driver does
not wait enough time.
This patch adds more time waiting
Hi,
Here is a full log from the beginning which shows another problem.
When the SCSI_READ_10 command below is received, there is a disconnect
or port reset which causes the (-32) broken pipe problem.
You really need to fix the old problems before worrying about new
problems. The set_halt
Recently, I test my usb host driver(not ehci or any widely used usb
host) with a Ralink's wifi device(use a linux-3.0.39 kernel).
But, if transferring data through FTP for a long time, I found that
usb_hcd_link_urb_to_ep() (It is called by hcd's urb_enqueue function)
returns -EPERM sometimes.
Alan Stern wrote:
On Fri, 19 Apr 2013, Joe Rayhawk wrote:
On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote:
On Fri, 19 Apr 2013, Clemens Ladisch wrote:
Alan Stern wrote:
+ next = uhci-frame_number + 2;
That 2 is the minimum latency, in frames (one frame per ms).
One
Hi,
On Thu, Apr 18, 2013 at 05:20:11PM +0530, Kishon Vijay Abraham I wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Hi,
On Mon, Apr 15, 2013 at 02:45:39PM +0200, Laurent Pinchart wrote:
Those optional operations are used to release and reacquire the queue
lock when videobuf2 needs to perform operations that sleep for a long
time, such as waiting for a buffer to be complete. Implement them to
On Tue, Apr 09, 2013 at 02:29:25PM +0200, Florian Fainelli wrote:
This patch removes the depends on USB from all config symbols in
drivers/usb/host/Kconfig and replace that with an if USB / endif block
as suggested by Alan Stern. Some source ... Kconfig lines have been
shuffled around to
On Tuesday 23 April 2013 14:16:56 Felipe Balbi wrote:
On Mon, Apr 15, 2013 at 02:45:39PM +0200, Laurent Pinchart wrote:
Those optional operations are used to release and reacquire the
queue lock when videobuf2 needs to perform operations that sleep for
a long time, such as waiting
Hi Greg,
Here are a few urgent fixes for my latest pull request. Good to know
people have been testing.
With these we will have a rather good -rc1 and anything else can be
fixed during the -rc cycle.
Let me know if you would prefer to wait until -rc1 to apply these
commits.
cheers
The
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_ncm.c | 26 ++
1 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/f_ncm.c
Here I present the conversion of everthing that is required to provide
the equivalent of g_ncm.ko with configfs.
This is the second version of the series after discussion with Alan
and Michal's review - thank you guys.
A branch will be available here (from 24th April 2013):
In order to convert to configfs the usb functions need to be converted
to a new interface and compiled as modules. This patch creates an rndis
module which will be used by the new functions. After all users of
f_rndis are converted to the new interface, this module can be
merged with f_rndis
Converting ncm to the new function interface requires converting
the USB ncm's function code and its users.
This patch converts the f_ncm.c to the new function interface.
The file is now compiled into a separate usb_f_ncm.ko module.
The old function interface is provided by means of a preprocessor
Add an interface to create a struct netdev_dev filled with default values,
an interface to fill the struct with useful values and an interface to
read the values set.
The patch also adds an interface to register the net device associated
with an ethernet-over-usb link.
Signed-off-by: Andrzej
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |1 +
drivers/usb/gadget/ncm.c | 57 +++-
2 files changed, 36 insertions(+), 22 deletions(-)
diff --git
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_ncm.c | 166
drivers/usb/gadget/u_ncm.h |9 +++
2 files changed, 175 insertions(+), 0 deletions(-)
diff
The current ST Micro Connect Lite uses the FT4232H hi-speed quad USB UART
FTDI chip. It is also possible to drive STM reference targets populated with an
on-board JTAG debugger based on the FT2232H chip with the same
STMicroelectronics tools.
For this reason, the ST Micro Connect Lite PIDs
The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports.
The first two ports are reserved for the JTAG interface.
We enable by default ports 2 and 3 as UARTs (where port 2 is a
conventional RS-232 UART)
Signed-off-by: Adrian Thomasset adrian.thomas...@st.com
---
Hi,
On Thu, Apr 4, 2013 at 8:16 PM, Alan Stern st...@rowland.harvard.edu wrote:
Apologies for delay in replying.
On Thu, 4 Apr 2013, Felipe Balbi wrote:
Some subsystems handle this issue by calling pm_runtime_get_sync()
before probing a driver and pm_runtime_put_sync() after unbinding
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: Li, Zhen-Hua zhen-h...@hp.com
This patch is trying to fix bug QXCR1001261767.
What is that bug number? Where can it be referenced? If you are going
to put it in a public place (like a kernel changelog), it needs to be
On Tue, 23 Apr 2013, Peter Chen wrote:
On Mon, Apr 22, 2013 at 11:26:05AM -0400, Alan Stern wrote:
On Mon, 22 Apr 2013, Peter Chen wrote:
Hi all,
Recently, I have several customers troubled in safe recover USB
function during the ESD situation (or some other situations, like
On Tue, 23 Apr 2013, linux fddl wrote:
Recently, I test my usb host driver(not ehci or any widely used usb
host) with a Ralink's wifi device(use a linux-3.0.39 kernel).
But, if transferring data through FTP for a long time, I found that
usb_hcd_link_urb_to_ep() (It is called by hcd's
On Tue, 23 Apr 2013, victor yeo wrote:
Hi,
Here is a full log from the beginning which shows another problem.
When the SCSI_READ_10 command below is received, there is a disconnect
or port reset which causes the (-32) broken pipe problem.
You really need to fix the old problems
On Tue, 23 Apr 2013, Clemens Ladisch wrote:
Alan Stern wrote:
On Fri, 19 Apr 2013, Joe Rayhawk wrote:
On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote:
On Fri, 19 Apr 2013, Clemens Ladisch wrote:
Alan Stern wrote:
+ next = uhci-frame_number + 2;
That 2 is
If we can ever get to a state where we can solely search for DMA channels
by name, this will almost completely alleviate the requirement to pass
copious amounts of information though platform data. Here we take the
first step towards this. The next step will be to enable Device Tree
complete with
In its current state, the ux500-musb driver uses platform data pointers
blindly with no prior checking. If no platform data pointer is passed
this will Oops the kernel. In this patch we ensure platform data and
board data are present prior to using them.
Cc: Felipe Balbi ba...@ti.com
Cc:
For all ux500 based platforms the maximum number of end-points are used.
Move this knowledge into the driver so we can relinquish the burden from
platform data. This also removes quite a bit of complexity from the driver
and will aid us when we come to enable the driver for Device Tree.
Cc:
The MUSB HDRC configuration never changes between each of the ux500
supported platforms, so there's little point passing it though platform
data. If we set it in the driver instead, we can make good use of it
when booting with either ATAGs or Device Tree.
Cc: Felipe Balbi ba...@ti.com
Cc:
The dma_mask will always be the same as the coherent_dma_mask, so let's
cut down on the platform_data burden and set it as such in the driver.
This also saves us from supporting it separately when we come to enable
this driver for Device Tree.
Cc: Felipe Balbi ba...@ti.com
Cc:
Alan Stern wrote:
On Tue, 23 Apr 2013, Clemens Ladisch wrote:
Why is having a queue of two URB with one packet each suddenly not
allowed?
It _is_ allowed when URB_ISO_ASAP is clear. I have never fully
understood why the audio driver sets that flag. By setting it, you are
telling the host
On Tue, 23 Apr 2013, Greg KH wrote:
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: Li, Zhen-Hua zhen-h...@hp.com
This patch is trying to fix bug QXCR1001261767.
What is that bug number? Where can it be referenced? If you are going
to put it in a public place
Hello.
Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130422' tag. It was created to fix the shortcomings in the
R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so
spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees
On Tuesday 23 April 2013, Lee Jones wrote:
+Required properties:
+ - compatible : Should be stericsson,db8500-musb
+ - reg: Offset and length of registers
+ - interrupts : Interrupt; mode, number and trigger
+ - mode : One of; host, otg, or peripheral
I think we don't have any
USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file. Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename r8a7779_late_devices[]
to r8a7779_standard_devices[] -- this seems legitimate since
On Tue, Apr 23, 2013 at 05:14:06PM +0200, Arnd Bergmann wrote:
On Tuesday 23 April 2013, Lee Jones wrote:
+Required properties:
+ - compatible : Should be stericsson,db8500-musb
+ - reg: Offset and length of registers
+ - interrupts : Interrupt; mode, number and trigger
+ - mode
Sometimes there is a need to initialize some non-standard registers mapped to
the EHCI region before accessing the standard EHCI registers. Add pre_setup()
method with 'struct usb_hcd *' parameter to be called just before ehci_setup()
to the 'ehci-platform' driver's platform data for this
Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto
On Tue, 23 Apr 2013, Clemens Ladisch wrote:
Alan Stern wrote:
On Tue, 23 Apr 2013, Clemens Ladisch wrote:
Why is having a queue of two URB with one packet each suddenly not
allowed?
It _is_ allowed when URB_ISO_ASAP is clear. I have never fully
understood why the audio driver sets
Now that the EHCI internal buffer setup is done by the platform code, we can
remove such code from this driver as it never really belonged here. We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).
The patch has been tested on the
On Tuesday 23 April 2013, Felipe Balbi wrote:
On Tue, Apr 23, 2013 at 05:14:06PM +0200, Arnd Bergmann wrote:
On Tuesday 23 April 2013, Lee Jones wrote:
+Required properties:
+ - compatible : Should be stericsson,db8500-musb
+ - reg: Offset and length of registers
+ -
Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon
Hi,
On Tue, Apr 23, 2013 at 05:27:10PM +0200, Arnd Bergmann wrote:
+Required properties:
+ - compatible : Should be stericsson,db8500-musb
+ - reg: Offset and length of registers
+ - interrupts : Interrupt; mode, number and trigger
+ - mode : One of; host, otg,
The memory region that is used by the driver overlaps EHCI and OHCI register
regions for absolutely no reason now -- fix it by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...
Currently the driver hard-codes USBPCTRL0 register to 0. It is wrong since this
register contains board-specific USB ports configuration and so its value should
be somehow passed via the platform data. Add linux/usb/rcar-phy.h file with
the 'struct rcar_phy_platform_data' containing various bit
Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY
Set the USBPCTRL0 register from the passed platform data in rcar_usb_phy_init();
don't reset it to 0 in rcar_usb_phy_shutdown() anymore as that does not make
sense. Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.
The patch has been tested
Hello.
Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130422' tag and the R8A7779/Marzen patchset I've posted.
It was created to add support of R8A7778/BOCK-W USB to the platform code and
the USB common PHY driver, and so spans both
Hi everyone,
These are a couple of simple patches to fix bugs that break allyesconfig
and that are only present in linux-next at the moment. Please apply
to the appropriate trees or provide feedback!
Arnd Bergmann (5):
mfd: ab8500: remove broken ab8500_debug_register_interrupt logic
usb:
A lot of platform code calls into the usb phy core at the moment, which
does not work if it is built as a loadable module. This will hopefully
change when those platforms are all converted to DT based probing,
but for now, the easiest solution is to change it from tristate
to bool.
This solves at
The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up during USB-PHY startup depending on
whether a ferrite bead is in use or not. So, we now
Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC; add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.
Also, don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for
Register the USB PHY device from bockw_init(), passing the platform data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Hi,
On Tue, Apr 23, 2013 at 05:54:32PM +0200, Arnd Bergmann wrote:
A lot of platform code calls into the usb phy core at the moment, which
does not work if it is built as a loadable module. This will hopefully
change when those platforms are all converted to DT based probing,
but for now, the
On Tuesday 23 April 2013, Felipe Balbi wrote:
looks like this is the only way, indeed. Do you need on the merge window
on can this wait until -rc1 ? I just sent a pull request to Greg with
urgent fixes for the merge window.
Greg, if you want to take this one as a patch, go for it:
Hi,
On Tue, Apr 23, 2013 at 06:11:35PM +0200, Arnd Bergmann wrote:
On Tuesday 23 April 2013, Felipe Balbi wrote:
looks like this is the only way, indeed. Do you need on the merge window
on can this wait until -rc1 ? I just sent a pull request to Greg with
urgent fixes for the merge window.
On Tue, Apr 23, 2013 at 02:38:20PM +0300, Felipe Balbi wrote:
Hi Greg,
Here are a few urgent fixes for my latest pull request. Good to know
people have been testing.
With these we will have a rather good -rc1 and anything else can be
fixed during the -rc cycle.
Let me know if you would
On Tue, Apr 23, 2013 at 07:07:59PM +0300, Felipe Balbi wrote:
Hi,
On Tue, Apr 23, 2013 at 05:54:32PM +0200, Arnd Bergmann wrote:
A lot of platform code calls into the usb phy core at the moment, which
does not work if it is built as a loadable module. This will hopefully
change when
Hi everyone,
This is a set of bug fixes for build errors and warnings I am
seeing in the various defconfigs and/or allmodconfig builds
on linux-next. The majority of these showed up because we now
include a lot more platforms in allmodconfig than we used to.
Please apply to appropriate
Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
which does not work if one of them or both are loadable modules, resulting
in an error like:
drivers/built-in.o: In function `utmi_phy_clk_disable':
drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to
On Tue, 23 Apr 2013, Arnd Bergmann wrote:
Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
which does not work if one of them or both are loadable modules, resulting
in an error like:
drivers/built-in.o: In function `utmi_phy_clk_disable':
On Tue, 23 Apr 2013, Vivek Gautam wrote:
Alright, so here's my understanding:
I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said
that it could be done before that so that DWC3 sees an enabled PHY
during probe.
Basically right. Help me to understand the overall
On Tue, Apr 23, 2013 at 12:46:30PM +0100, Adrian Thomasset wrote:
The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports.
The first two ports are reserved for the JTAG interface.
We enable by default ports 2 and 3 as UARTs (where port 2 is a
conventional RS-232 UART)
On Tue, Apr 23, 2013 at 06:30:50PM +0200, Arnd Bergmann wrote:
Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
which does not work if one of them or both are loadable modules, resulting
in an error like:
drivers/built-in.o: In function `utmi_phy_clk_disable':
On Tue, Apr 23, 2013 at 06:30:51PM +0200, Arnd Bergmann wrote:
It makes no sense for a symbol to be both exported and marked __init,
because any users in modules would be calling this function after
it gets discarded. Further, this patch revolves a section mismatch
warning from
Hello.
On 04/22/2013 08:00 AM, Simon Horman wrote:
Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'.
Enable USB storage driver and SCSI disk driver that it needs as well...
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
I realise that this is not
On Mon, 2013-04-22 at 12:35 -0700, David Rientjes wrote:
On Fri, 19 Apr 2013, Joe Perches wrote:
@@ -966,11 +934,13 @@ static int realtek_cr_autosuspend_setup(struct
us_data *us)
static void realtek_cr_destructor(void *extra)
{
struct rts51x_chip *chip = (struct rts51x_chip
Hi,
On Tue, Apr 23, 2013 at 10:23 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 23 Apr 2013, Vivek Gautam wrote:
Alright, so here's my understanding:
I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said
that it could be done before that so that DWC3 sees an
On Tue, 23 Apr 2013, Vivek Gautam wrote:
Hi,
On Tue, Apr 23, 2013 at 10:23 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Tue, 23 Apr 2013, Vivek Gautam wrote:
Alright, so here's my understanding:
I suggested letting e.g. DWC3 enable the PHY's runtime_pm; Alan said
On 04/23/13 01:00, Stephen Rothwell wrote:
Hi all,
Changes since 20130422:
on i386, when CONFIG_PM_RUNTIME is not enabled so REALTEK_AUTOPM is not
enabled:
drivers/usb/storage/realtek_cr.c: In function 'realtek_cr_destructor':
drivers/usb/storage/realtek_cr.c:942:11: error: 'struct
On Tuesday 23 April 2013, Alan Stern wrote:
On Tue, 23 Apr 2013, Arnd Bergmann wrote:
@@ -733,7 +731,9 @@ static int tegra_ehci_probe(struct platform_device
*pdev)
tegra-phy = tegra_usb_phy_open(pdev-dev, instance, hcd-regs,
pdata-phy_config,
Both phy-tegra-usb.c and ehci-tegra.c export symbols used by the other one,
which does not work if one of them or both are loadable modules, resulting
in an error like:
drivers/built-in.o: In function `utmi_phy_clk_disable':
drivers/usb/phy/phy-tegra-usb.c:302: undefined reference to
It makes no sense for a symbol to be both exported and marked __init,
because any users in modules would be calling this function after
it gets discarded. Further, this patch revolves a section mismatch
warning from usbhs_init_phys(), which is intentionally not marked
__init:
WARNING:
On Tue, Apr 23, 2013 at 09:07:21PM +0200, Arnd Bergmann wrote:
It makes no sense for a symbol to be both exported and marked __init,
because any users in modules would be calling this function after
it gets discarded. Further, this patch revolves a section mismatch
warning from
On Tuesday 23 April 2013, Felipe Balbi wrote:
On Tue, Apr 23, 2013 at 09:07:21PM +0200, Arnd Bergmann wrote:
It makes no sense for a symbol to be both exported and marked __init,
because any users in modules would be calling this function after
it gets discarded. Further, this patch
On Mon, Apr 22, 2013 at 02:38:57PM -0400, Tony Camuso wrote:
On 04/18/2013 05:12 PM, Sarah Sharp wrote:
On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote:
Sarah,
This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7.
I can attach the S3_Suspend_message.log, if you like,
Hello.
On 04/23/2013 07:03 PM, Lee Jones wrote:
In its current state, the ux500-musb driver uses platform data pointers
blindly with no prior checking. If no platform data pointer is passed
this will Oops the kernel. In this patch we ensure platform data and
board data are present prior to
Hello.
On 04/23/2013 03:46 PM, Adrian Thomasset wrote:
The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports.
The first two ports are reserved for the JTAG interface.
We enable by default ports 2 and 3 as UARTs (where port 2 is a
conventional RS-232 UART)
Signed-off-by:
On 04/18/2013 05:12 PM, Sarah Sharp wrote:
On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote:
Sarah,
This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7.
= snip =
Is it hanging on suspend or on resume?
3.9.0-rc8 hangs in both suspend and resume on a hp z620 running
On Tue, Apr 23, 2013 at 04:18:00PM -0400, Tony Camuso wrote:
On 04/18/2013 05:12 PM, Sarah Sharp wrote:
On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote:
Sarah,
This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7.
= snip =
Is it hanging on suspend or on resume?
The current EHCI code sleeps a flat 110ms in the resume path if there
was a USB 1.1 device connected to its companion controller during
suspend, waiting for the device to reappear and reset so that it can be
handed back to the companion. This is necessary if the device uses
persist, so that the
On 04/23/2013 10:07 PM, Greg KH wrote:
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: Li, Zhen-Hua zhen-h...@hp.com
This patch is trying to fix bug QXCR1001261767.
Sorry for the bug number. Please ignore this line.
What is that bug number? Where can it be referenced?
On Wed, Apr 24, 2013 at 07:55:18AM +0800, ZhenHua wrote:
On 04/23/2013 10:07 PM, Greg KH wrote:
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: Li, Zhen-Hua zhen-h...@hp.com
This patch is trying to fix bug QXCR1001261767.
Sorry for the bug number. Please ignore this
I did not found any url you can visit. And we will file a bug on SLES
bugzilla site if possible.
I paste the bug discription here:
When booting SLES 11 SP2 on our server , messages like the following are
logged during boot:
[ 254.087187] uhci_hcd :07:00.4: Controller not stopped yet!
83 matches
Mail list logo