There is no need to have the 'dummy_mask' variable static since new
value always be assigned before use it.
Signed-off-by: YueHaibing
---
drivers/usb/host/ehci-ps3.c | 2 +-
drivers/usb/host/ohci-ps3.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-p
On Wed, Jan 23, 2019 at 07:52:12AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 22, 2019 at 02:52:44PM -0600, Bin Liu wrote:
> > Hi Johan,
> >
> > On Tue, Jan 22, 2019 at 02:16:30PM -0600, Bin Liu wrote:
> > > On Tue, Jan 22, 2019 at 05:19:39PM +, Måns Rullgård wrote:
> > > > Bin Liu writes
Hi Maynard,
On 1/23/2019 10:52 AM, Maynard CABIENTE wrote:
> Hi Minas,
>
> On Wednesday, January 23, 2019 1:42 AM, Minas Harutyunyan wrote:
>>
>> Can you provide USB trace for above fragment.
>>
>
> Is it ok to have a 14MB attachment on this e-mail list? My USB trace was
> taken using the Ellis
Adds test for stack initialization coverage. We have several build options
that control the level of stack variable initialization. This test lets us
visualize which options cover which cases, and provide tests for options
that are currently not available (padding initialization).
All options pass
This adds a new plugin "stackinit" that attempts to perform unconditional
initialization of all stack variables[1]. It has wider effects than
GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y since BYREF_ALL does not consider
non-structures. A notable weakness is that padding bytes in many cases
remain uninitializ
Variables declared in a switch statement before any case statements
cannot be initialized, so move all instances out of the switches.
After this, future always-initialized stack variables will work
and not throw warnings like this:
fs/fcntl.c: In function ‘send_sigio_to_task’:
fs/fcntl.c:738:13: w
This attempts to duplicate the proposed gcc option -finit-local-vars[1]
in an effort to implement the "always initialize local variables" kernel
development goal[2].
Enabling CONFIG_GCC_PLUGIN_STACKINIT should stop all "uninitialized
stack variable" flaws as long as they don't depend on being zero
On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be initialized, so move all instances out of the switches.
> > After this, future always-initialized stack
On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote:
>
> On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > > Variables declared in a switch statement before any case statements
> > > cannot be initialized, so move all instances out of the
./drivers/usb/misc/ftdi-elan.c:972:10-12: WARNING: possible condition with no
effect (if == else)
./drivers/usb/misc/ftdi-elan.c:983:9-11: WARNING: possible condition with no
effect (if == else)
./drivers/usb/misc/ftdi-elan.c:2052:11-13: WARNING: possible condition with no
effect (if == else)
S
On Wed, Jan 23, 2019 at 08:34:42PM +0800, YueHaibing wrote:
> ./drivers/usb/misc/ftdi-elan.c:972:10-12: WARNING: possible condition with no
> effect (if == else)
> ./drivers/usb/misc/ftdi-elan.c:983:9-11: WARNING: possible condition with no
> effect (if == else)
> ./drivers/usb/misc/ftdi-elan.c:2
On 2019/1/23 20:43, Greg KH wrote:
> On Wed, Jan 23, 2019 at 08:34:42PM +0800, YueHaibing wrote:
>> ./drivers/usb/misc/ftdi-elan.c:972:10-12: WARNING: possible condition with
>> no effect (if == else)
>> ./drivers/usb/misc/ftdi-elan.c:983:9-11: WARNING: possible condition with no
>> effect (if ==
> On Jan 23, 2019, at 5:09 AM, Jann Horn wrote:
>
> AFAICS this only applies to switch statements (because they jump to a
> case and don't execute stuff at the start of the block), not blocks
> after if/while/... .
It bothers me that we are going out of our way to deprecate valid C constructs
On Wed, Jan 23, 2019 at 09:17:38PM +0800, YueHaibing wrote:
> On 2019/1/23 20:43, Greg KH wrote:
> > On Wed, Jan 23, 2019 at 08:34:42PM +0800, YueHaibing wrote:
> >> ./drivers/usb/misc/ftdi-elan.c:972:10-12: WARNING: possible condition with
> >> no effect (if == else)
> >> ./drivers/usb/misc/ftdi-
Hello Miquel,
On Tue, 22 Jan 2019 20:16:35 +0100, Miquel Raynal wrote:
> > Do we really need different compatible strings for those ? I assume the
> > IP block is exactly the same for the two PHYs, right ? If so, we should
> > use the same compatible string.
>
> For what I understand, the PHYs
On 2019/1/23 21:41, Greg KH wrote:
> On Wed, Jan 23, 2019 at 09:17:38PM +0800, YueHaibing wrote:
>> On 2019/1/23 20:43, Greg KH wrote:
>>> On Wed, Jan 23, 2019 at 08:34:42PM +0800, YueHaibing wrote:
./drivers/usb/misc/ftdi-elan.c:972:10-12: WARNING: possible condition with
no effect (if
On Wed, Jan 09, 2019 at 09:24:37AM +0100, Johan Hovold wrote:
On Tue, Jan 08, 2019 at 02:24:53PM -0500, Sasha Levin wrote:
From: Nikolaj Fogh
[ Upstream commit 6abd837104a3a8e1cda64fc4d7675f6c3ece9d8b ]
Improve baud-rate generation by using rounding-to-closest instead of
truncation in divisor
On Wed, Jan 23, 2019 at 09:55:49AM +0100, Johan Hovold wrote:
> On Wed, Jan 23, 2019 at 07:52:12AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 22, 2019 at 02:52:44PM -0600, Bin Liu wrote:
> > > Hi Johan,
> > >
> > > On Tue, Jan 22, 2019 at 02:16:30PM -0600, Bin Liu wrote:
> > > > On Tue, Jan
On Tue, Jan 22, 2019 at 2:28 PM Alan Stern wrote:
>
> In the absence of any better suggestions, you can always try using git
> bisect between 4.19.4 and 4.19.8. The amount of churn ought to be
> relatively small, so it shouldn't take too long to home in on the
> commit which caused the problem.
>
On Wed, 23 Jan 2019, Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> Variables declared in a switch statement before any case statements
>> cannot be initialized, so move all instances out of the switches.
>> After this, future always-initialized stack variables will
The variable 'empty_packets' does not used in any other places
except for self increment, so it can be removed.
Signed-off-by: YueHaibing
---
drivers/usb/misc/ftdi-elan.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 76c718
YueHaibing (2):
usb: ftdi-elan: remove a unnecessary variable 'empty_packets'
usb: ftdi-elan: Fix if == else warnings in ftdi_elan_respond_engine
drivers/usb/misc/ftdi-elan.c | 26 --
1 file changed, 26 deletions(-)
--
2.7.0
Fixes the following coccinelle warning:
./drivers/usb/misc/ftdi-elan.c:972:10-12: WARNING: possible condition with no
effect (if == else)
./drivers/usb/misc/ftdi-elan.c:983:9-11: WARNING: possible condition with no
effect (if == else)
./drivers/usb/misc/ftdi-elan.c:2052:11-13: WARNING: possible c
On Wed, 23 Jan 2019, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Greg KH wrote:
>> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>>> Variables declared in a switch statement before any case statements
>>> cannot be initialized, so move all instances out of the switches.
>>> After this,
The i.MX USB controller may drive the usb power line directly, but the
polarity depends on the board. Reset state of the polarity is low-active so
add this property to allow it to be high-active.
Signed-off-by: Philipp Puschmann
Reviewed-by: Rob Herring
---
Changes in v4: do not limit to i.MX6
This patch adds support to set the power line polarity for i.MX SoCs.
To let the USB controller control the power it may be necessary to configure
the polarity of the power line. So far the polarity was configured
by Bootloader or alternatively the power line was muxed as gpio and
driven by a regu
'num' is a u8 variable, it never greater than 255,
So the if branch is dead code and can be removed.
Signed-off-by: YueHaibing
---
drivers/usb/gadget/function/uvc_configfs.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/usb/gadget/function/uvc_configfs.c
b/drivers/usb/gadge
On Wed, Jan 23, 2019 at 08:09:47AM -0600, Bin Liu wrote:
> On Wed, Jan 23, 2019 at 09:55:49AM +0100, Johan Hovold wrote:
> > On Wed, Jan 23, 2019 at 07:52:12AM +0100, Greg Kroah-Hartman wrote:
> > > That's not what any other host controller returns when a device is
> > > removed, so either you are
On Wed, 23 Jan 2019, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> >> Variables declared in a switch statement before any case statements
> >> cannot be initialized, so move all instances out of the switches.
> >> After t
On Wed, Jan 23, 2019 at 03:55:47PM +0100, Johan Hovold wrote:
> On Wed, Jan 23, 2019 at 08:09:47AM -0600, Bin Liu wrote:
> > On Wed, Jan 23, 2019 at 09:55:49AM +0100, Johan Hovold wrote:
> > > On Wed, Jan 23, 2019 at 07:52:12AM +0100, Greg Kroah-Hartman wrote:
>
> > > > That's not what any other h
On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> On Wed, 23 Jan 2019, Jani Nikula wrote:
>> On Wed, 23 Jan 2019, Greg KH wrote:
>> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> >> Variables declared in a switch statement before any case statements
>> >> cannot be initialized, so m
On Wed, 23 Jan 2019, Bin Liu wrote:
> On Wed, Jan 23, 2019 at 03:55:47PM +0100, Johan Hovold wrote:
> > On Wed, Jan 23, 2019 at 08:09:47AM -0600, Bin Liu wrote:
> > > On Wed, Jan 23, 2019 at 09:55:49AM +0100, Johan Hovold wrote:
> > > > On Wed, Jan 23, 2019 at 07:52:12AM +0100, Greg Kroah-Hartman
On Wed, 23 Jan 2019, YueHaibing wrote:
> There is no need to have the 'dummy_mask' variable static since new
> value always be assigned before use it.
>
> Signed-off-by: YueHaibing
> ---
> drivers/usb/host/ehci-ps3.c | 2 +-
> drivers/usb/host/ohci-ps3.c | 2 +-
> 2 files changed, 2 insertions(
On Wed, 2019-01-23 at 03:03 -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
>
> fs
On Wed, Jan 23, 2019 at 11:05:40AM -0500, Alan Stern wrote:
> On Wed, 23 Jan 2019, Bin Liu wrote:
>
> > On Wed, Jan 23, 2019 at 03:55:47PM +0100, Johan Hovold wrote:
> > > On Wed, Jan 23, 2019 at 08:09:47AM -0600, Bin Liu wrote:
> > > > On Wed, Jan 23, 2019 at 09:55:49AM +0100, Johan Hovold wrote:
Hi Greg,
On Wednesday, January 23, 2019 2:09 AM, Greg KH wrote:
> On Wed, Jan 23, 2019 at 06:52:00AM +, Maynard CABIENTE wrote:
> > This e-mail, and any document attached hereby, may contain confidential
> > and/or privileged information. If you are not the intended recipient (or
> > have re
On Wed, 23 Jan 2019, Bin Liu wrote:
> > One possibility is to giveback URBs with certain errors (such as
> > -EPROTO) only at a frame boundary, or at 1-ms intervals. This feels
> > like a very artificial solution, though.
>
> My plan is to add an error counter in musb driver endpoint struct, if
We assign "urb->hcpriv = qh;" a few lines down. The valid qh for the urb is
hep->hcpriv in this code path.
Fixes: 714bc5ef3eda ("musb: potential use after free")
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/musb_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
On Thu, Jan 24, 2019 at 4:44 AM Jani Nikula wrote:
>
> On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> > On Wed, 23 Jan 2019, Jani Nikula wrote:
> >> On Wed, 23 Jan 2019, Greg KH wrote:
> >> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> >> >> Variables declared in a switch statem
This patch does not change any functionality but reduces the size of
struct scsi_cmnd.
Cc: Oliver Neukum
Cc: Douglas Gilbert
Cc: Hannes Reinecke
Cc: Christoph Hellwig
Cc: linux-usb@vger.kernel.org
Signed-off-by: Bart Van Assche
---
drivers/scsi/scsi_lib.c | 2 --
drivers/usb/storage/uas.c
On Wed, 23 Jan 2019, Yinbo Zhu wrote:
> From: Suresh Gupta
>
> PHY_CLK_VALID bit for UTMI PHY in USBDR does not set even
> if PHY is providing valid clock. Workaround for this
> involves resetting of PHY and check PHY_CLK_VALID bit
> multiple times. If PHY_CLK_VALID bit is still not set even
> a
On Wed, 23 Jan 2019, Yinbo Zhu wrote:
> From: Nikhil Badola
>
> Set USB_EN bit to select ULPI phy for USB controller version 2.5
>
> Signed-off-by: Nikhil Badola
> Signed-off-by: Yinbo Zhu
> ---
> Change in v3:
> Code base already has patch[5/6], so remove it.
>
> drivers/us
On Wed, 23 Jan 2019, Yinbo Zhu wrote:
> From: Ramneek Mehresh
>
> USB erratum-A006918 workaround tries to start internal PHY inside
> uboot (when PLL fails to lock). However, if the workaround also
> fails, then USB initialization is also stopped inside Linux.
> Erratum-A006918 workaround failur
On Wed, 23 Jan 2019, Yinbo Zhu wrote:
> From: Yinbo Zhu
>
> This patch is to add member has_fsl_erratum_a006918 in platform data
This should come before patch 3/5. Otherwise that patch will get a
compile error when it tries to reference the has_fsl_erratum_a006918
field and the field hasn't
On Wed, 23 Jan 2019, Yinbo Zhu wrote:
> From: Nikhil Badola
>
> Remove USB errata checking code from driver. Applicability of erratum
> is retrieved by reading corresponding property in device tree.
> This property is written during device tree fixup.
>
> Signed-off-by: Ramneek Mehresh
> Signe
On Wed, Jan 23, 2019 at 04:17:30PM +0200, Jani Nikula wrote:
> Can't have:
>
> switch (i) {
> int j;
> case 0:
> /* ... */
> }
>
> because it can't be turned into:
>
> switch (i) {
> int j = 0; /* not valid C */
> case 0:
>
On Mon, 21 Jan 2019, Miquel Raynal wrote:
> Add suspend/resume callbacks to reset the host controller properly
> during S2RAM operation.
>
> Signed-off-by: Miquel Raynal
> ---
> drivers/usb/host/ehci-orion.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/dr
On Mon, 21 Jan 2019, Miquel Raynal wrote:
> No need to initialize the PHY from the driver's probe. It is done by
> the core automatically and doing it twice would increment the
> phy->powercount counter to 2 instead of 1. During later suspend
> operation, the counter will be decremented to one, no
On Wed, Jan 23, 2019 at 12:42:36PM -0500, Alan Stern wrote:
> On Wed, 23 Jan 2019, Bin Liu wrote:
>
> > > One possibility is to giveback URBs with certain errors (such as
> > > -EPROTO) only at a frame boundary, or at 1-ms intervals. This feels
> > > like a very artificial solution, though.
> >
Hi Minas,
On Wednesday, January 23, 2019 3:58 AM Minas Harutyunyan
wrote:
> But before it, could you please add some debug print in
> dwc2_hsotg_suspend() function. I suspect that host side autosuspend mass
> storage device(s) this is why dwc2 driver complete request with ERROR:
> -108. Based on
On Thu, Jan 24, 2019 at 8:18 AM Matthew Wilcox wrote:
>
> On Wed, Jan 23, 2019 at 04:17:30PM +0200, Jani Nikula wrote:
> > Can't have:
> >
> > switch (i) {
> > int j;
> > case 0:
> > /* ... */
> > }
> >
> > because it can't be turned into:
> >
> >
On Wed, 23 Jan 2019, Bin Liu wrote:
> On Wed, Jan 23, 2019 at 12:42:36PM -0500, Alan Stern wrote:
> > On Wed, 23 Jan 2019, Bin Liu wrote:
> >
> > > > One possibility is to giveback URBs with certain errors (such as
> > > > -EPROTO) only at a frame boundary, or at 1-ms intervals. This feels
> >
Bin Liu writes:
>> > > Why doesn't the same problem occur with other types of host controller?
>> >
>> > Not sure, I am on musb for most of the times. Maybe other HCD doesn't
>> > giveback URBs with -EPROTO in such error case.
>>
>> ehci-hcd also uses -EPROTO.
>
> Is it possible to test the use
From: Dmitry Torokhov
In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain
Acked-by: Greg Kroah-Hartman
Tested-by: Sukum
From: Dmitry Torokhov
USB devices permanently connected to USB ports may be described in ACPI
tables and share ACPI devices with ports they are connected to. See [1]
for details.
This will allow us to describe sideband resources for devices, such as,
for example, hard reset line for BT USB contr
Add a hook to allow the BT driver to do device or command specific
handling in case of timeouts. This is to be used by Intel driver to
reset the device after certain number of timeouts.
Signed-off-by: Rajat Jain
---
v5: Drop the quirk, and rename the hook function to cmd_timeout()
v4: same as v1
If the platform provides it, use the reset gpio to reset the Intel BT
chip, as part of cmd_timeout handling. This has been found helpful on
Intel bluetooth controllers where the firmware gets stuck and the only
way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain
---
v5
On Mon, 14 Jan 2019, Paul Elder wrote:
> On Fri, Jan 11, 2019 at 10:50:11AM -0500, Alan Stern wrote:
> > On Fri, 11 Jan 2019, Paul Elder wrote:
> >
> > > On Wed, Jan 09, 2019 at 02:06:31PM -0500, Alan Stern wrote:
> > > > On Wed, 9 Jan 2019, Paul Elder wrote:
> > > >
> > > > > A usb gadget funct
On Wed, Jan 23, 2019 at 04:10:12PM -0500, Alan Stern wrote:
> On Mon, 14 Jan 2019, Paul Elder wrote:
>
> > On Fri, Jan 11, 2019 at 10:50:11AM -0500, Alan Stern wrote:
> > > On Fri, 11 Jan 2019, Paul Elder wrote:
> > >
> > > > On Wed, Jan 09, 2019 at 02:06:31PM -0500, Alan Stern wrote:
> > > > > O
V4L2_EVENT_PRIVATE_START is used in g_uvc.h but is defined in
videodev2.h, which is not included and causes a compiler warning:
linux/usb/g_uvc.h:15:28: error: ‘V4L2_EVENT_PRIVATE_START’ undeclared here (not
in a function)
#define UVC_EVENT_FIRST (V4L2_EVENT_PRIVATE_START + 0)
Include videode
Since "usb: gadget: uvc: enqueue uvc_request_data in setup handler
for control OUT requests" it is no longer necessary for userspace to
call ioctl UVCIOC_SEND_RESPONSE in response to receiving a
UVC_EVENT_SETUP from the uvc function driver for a control OUT request.
This change means that for cont
Currently, for uvc class-specific control IN and OUT requests, in the
setup handler a UVC_EVENT_SETUP with the setup control is enqueued to
userspace. In response to this, the uvc function driver expects
userspace to call ioctl UVCIOC_SEND_RESPONSE containing uvc request
data.
In the case of contr
This patch series adds a mechanism to allow asynchronously validating
the data stage of a control OUT request, and for stalling or suceeding
the request accordingly. This mechanism is implemented for MUSB, and is
used by UVC. At the same time, UVC packages the setup stage and data
stage data togeth
Implement the mechanism for optional explicit status stage for the MUSB
driver. This allows a function driver to specify what to reply for the
status stage. The functionality for an implicit status stage is
retained.
Signed-off-by: Paul Elder
v1 Reviewed-by: Laurent Pinchart
v1 Acked-by: Bin Liu
We now have a mechanism to signal the UDC driver to reply to a control
OUT request with STALL or ACK, and we have packaged the setup stage data
and the data stage data of a control OUT request into a single
UVC_EVENT_DATA for userspace to consume. After telling the UDC to delay
the status stage, th
A usb gadget function driver may or may not want to delay the status
stage of a control OUT request. An instance where it might want to is to
asynchronously validate the data of a class-specific request.
A function driver that wants an explicit status stage should set the
newly added explicit_stat
On 2019/1/24 0:09, Alan Stern wrote:
> On Wed, 23 Jan 2019, YueHaibing wrote:
>
>> There is no need to have the 'dummy_mask' variable static since new
>> value always be assigned before use it.
>>
>> Signed-off-by: YueHaibing
>> ---
>> drivers/usb/host/ehci-ps3.c | 2 +-
>> drivers/usb/host/ohci
The ax88772_bind() should return error code immediately when the PHY
was not reset properly through ax88772a_hw_reset().
Otherwise, The asix_get_phyid() will block when get the PHY
Identifier from the PHYSID1 MII registers through asix_mdio_read()
due to the PHY isn't ready. Furthermore, it will
The QCA Rome USB Bluetooth controller has several issues once LPM gets
enabled:
- Fails to get enumerated in coldboot. [1]
- Drains more power (~ 0.2W) when the system is in S5. [2]
- Disappears after a warmboot. [2]
The issue happens because the device lingers at LPM L1 in S5, so device
can't get
There is a rare race condition that may happen during a Disconnect
Interrupt if we have a started request that happens to be
dequeued *after* completion of End Transfer command. If that happens,
that request will be left waiting for completion of an End Transfer
command that will never happen.
If
Now that we modified the code to fix a race condition, it's clear that
DWC3_EP_END_TRANSFER_PENDING is unnecessary, considering that
DWC3_EP_TRANSFER_STARTED will remain set until End Transfer completes.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h | 1 -
drivers/usb/dwc3/gadget.c
We must wait until End Transfer completes in order to clear
DWC3_EP_TRANSFER_STARTED, otherwise we may confuse the driver.
This patch is in preparation to fix a rare race condition that happens
upon Disconnect Interrupt.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 19 +--
We have a proper flag for testing that we have a valid transfer in
flight, let's use that instead.
This patch is in preparation to fix a rare race condition that happens
upon Disconnect Interrupt.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 4 ++--
1 file changed, 2 insertions(+
74 matches
Mail list logo
