On Thu, May 17, 2018 at 01:43:35PM -0400, ant wrote:
>
> Did I not say it right?
>
> Or perhaps a kernel or some other issue?
>
>
> =
>
>
> (no need to CC I'm subscribed to list),
>
> Hello,
>
> My USB keyboard is being dropped by the kernel at various times
> and I cannot figure out
From: kbuild test robot
Use kmemdup rather than duplicating its implementation
Generated by: scripts/coccinelle/api/memdup.cocci
Fixes: fe1c559e1567 ("ACS ACR122U not working: pn533_usb 1-1:1.0: NFC: Couldn't
poweron...")
CC: Greg KH
Signed-off-by: kbuild test robot
Signed-off-by: Julia La
On 17.05.2018 18:06, kbuild test robot wrote:
> Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings")
> Signed-off-by: kbuild test robot
It should be static of course, my bad.
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drd.c |2 +-
> 1 file changed, 1 inse
On 2018-05-17 13:50, Heikki Krogerus wrote:
On Wed, May 16, 2018 at 11:11:02PM +0200, Mats Karrman wrote:
On 05/16/2018 01:43 PM, Heikki Krogerus wrote:
On Tue, May 15, 2018 at 11:24:07PM +0200, Mats Karrman wrote:
Hi Heikki,
On 05/15/2018 09:30 AM, Heikki Krogerus wrote:
Hi Mats,
On Fri
Hi,
> > There are historical reasons for a lot of things, but that's not
> > necessarily a reason to continue taking shortcuts.
>
> But on second thought, I think your approach here makes sense. If
> usbserial ever gains generic IXON support, we'd just fall back to the
> line-discipline implement
Hi,
> That looks like an HX device according to the current way we identify
> these types (which may be wrong).
That at least matches the labeling on the chip, so I guess that might be
correct?
> Continuation lines (e.g. the broken if statement) should be indented
> substantially to the right, w
Hi Greg,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
> -Original Message-
> From: Tiago Brusamarello [mailto:tbr...@gmail.com]
> Sent: Thursday, May 17, 2018 4:29 PM
> To: Leo Li
> Cc: linux-usb@vger.kernel.org; Nikhil Badola
> Subject: [PATCH v3 1/1] drivers: usb: Introduce FSL_USB2_PHY_UTMI_DUAL
> for usb gadget
>
> From: Nikhil Badola
From: Nikhil Badola
Introduce FSL_USB2_PHY_UTMI_DUAL in gadget driver for setting
phy in SOCs with utmi dual phy
Signed-off-by: Nikhil Badola
Tested-by: Tiago Brusamarello
---
Changes since v2:
* Reformatted the patch so it can be applied in the main tree
Changes since v1:
* Removed Freesc
Initialization for SoCs with dual role phy is being bypassed since
FSL_USB2_PHY_UTMI_DUAL macro is not being evaluated in the FSL gadget
driver. In this state a controller configured in peripheral mode will
not work as a gadget. This patch addresses this issue.
Tested on 4.14.32 using a hardware w
pdev_nr and rhport can be controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue
'vhcis'
drivers/usb/usbip/vhci_sys
Hello
Thanks for your quick response.
I'll be away on holidays for the coming two weeks, but after that I'll
certainly try taking the patch for a test drive for a couple of days
(as the issue seemed intermittent).
I'll also notify the users on the Arch linux forum of the patch, as
there wer
On 05/17/2018 02:15 PM, Greg Kroah-Hartman wrote:
Shouldn't we just do this in one place, in the valid_port() function?
That way it keeps the range checking logic in one place (now it is in 3
places in the function), which should make maintenance much simpler.
Yep, I thought about that, the
On Thu, May 17, 2018 at 12:57:49PM -0500, Gustavo A. R. Silva wrote:
> Hi Greg,
>
> On 05/17/2018 01:51 AM, Greg Kroah-Hartman wrote:
> > On Wed, May 16, 2018 at 05:22:00PM -0500, Gustavo A. R. Silva wrote:
> > > pdev_nr and rhport can be controlled by user-space, hence leading to
> > > a potentia
On Thu, 17 May 2018, Alexander Kappner wrote:
> Oliver and Alan,
>
> thank for investigating.
>
> > this is suspicious. You do not actually whether US_FL_NO_WP_DETECT
> > by itself would make the device work. Can you please test that?
>
> US_FL_NO_WP_DETECT without US_FL_IGNORE_UAS does not mak
Oliver and Alan,
thank for investigating.
> this is suspicious. You do not actually whether US_FL_NO_WP_DETECT
> by itself would make the device work. Can you please test that?
US_FL_NO_WP_DETECT without US_FL_IGNORE_UAS does not make a difference,
even with the patch you included applied:
[
Hi Greg,
On 05/17/2018 01:51 AM, Greg Kroah-Hartman wrote:
On Wed, May 16, 2018 at 05:22:00PM -0500, Gustavo A. R. Silva wrote:
pdev_nr and rhport can be controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the
Did I not say it right?
Or perhaps a kernel or some other issue?
=
(no need to CC I'm subscribed to list),
Hello,
My USB keyboard is being dropped by the kernel at various times
and I cannot figure out how to fix this. Maybe I have messed up
somewhere but I think I'm reading the docu
On Thu, May 17, 2018 at 09:44:40AM -0700, Randy Dunlap wrote:
> On 05/17/2018 09:20 AM, Greg KH wrote:
> >> + file_data = kzalloc(sizeof(*file_data), GFP_KERNEL);
> >> + if (!file_data)
> >> + return -ENOMEM;
> >> +
> >> + pr_debug("%s - called\n", __func__);
> > Please do not add "trac
On 05/17/2018 12:06 AM, Stephen Rothwell wrote:
>
> The usb-gadget tree gained a conflict against the usb tree.
>
on x86_64:
drivers/usb/gadget/udc/aspeed-vhub/hub.o: In function
`ast_vhub_std_hub_request':
hub.c:(.text+0x3a7): undefined reference to `usb_gadget_get_string'
CONFIG_LIB_USBCOM
On Thu, May 17, 2018 at 03:17:01PM +0100, Carlos Manuel Santos wrote:
> Thank you for you quick reply. I didn't have the opportunity to test
> with older kernels, I'm afraid.
> I never built a kernel patch but I can give it a try! :)
Let's drag this back on the mailing list, it's better that way,
On 05/17/2018 09:20 AM, Greg KH wrote:
>> +file_data = kzalloc(sizeof(*file_data), GFP_KERNEL);
>> +if (!file_data)
>> +return -ENOMEM;
>> +
>> +pr_debug("%s - called\n", __func__);
> Please do not add "tracing" functions like this. The kernel has a
> wonderful built-in fun
On Thu, May 17, 2018 at 06:40:04PM +0200, Greg KH wrote:
> Adding the network and NFC developers as this really is a NFC driver
> bug, not a USB core issue...
>
> On Thu, May 17, 2018 at 04:12:17PM +0200, Greg KH wrote:
> > On Thu, May 17, 2018 at 02:10:57PM +0100, Carlos Manuel Santos wrote:
> >
Adding the network and NFC developers as this really is a NFC driver
bug, not a USB core issue...
On Thu, May 17, 2018 at 04:12:17PM +0200, Greg KH wrote:
> On Thu, May 17, 2018 at 02:10:57PM +0100, Carlos Manuel Santos wrote:
> > Hello.
> > I'm having troubles with this NFC card reader. It seems
On Thu, May 17, 2018 at 07:03:24PM +0200, Guido Kiener wrote:
> The working group "VISA for Linux" of the IVI Foundation
> www.ivifoundation.org specifies common rules, shared libraries and
> drivers to implement the specification of "VPP-4.3: The VISA Library"
> on Linux to be compatible with impl
On Thu, May 17, 2018 at 07:03:28PM +0200, Guido Kiener wrote:
> - add USBTMC488_IOCTL_TRIGGER to send TRIGGER Bulk-OUT header
> according to Subclass USB488 Specification
>
> The usbtmc trigger command is equivalent to the IEEE 488 GET (Group
> Execute Trigger) action. While the "*TRG" comma
On Thu, May 17, 2018 at 07:03:26PM +0200, Guido Kiener wrote:
> - Add 'struct usbtmc_file_data' for each file handle to cache last
> srq_byte (=Status Byte with SRQ) received by usbtmc_interrupt(..)
>
> - usbtmc488_ioctl_read_stb returns cached srq_byte when available for
> each file handle to
The ioctls USBTMC_IOCTL_SET_OUT_HALT or USBTMC_IOCTL_SET_IN_HALT
send a SET_FEATURE(HALT) request to the corresponding OUT or IN pipe.
Useful for testing devices and client applications: The ioctls force
the device to simulate the error state at the specified pipe.
Signed-off-by: Guido Kiener
Re
All T&M instruments should also work with rigol_quirk = 1 code path.
So remove unnecessary code in rigol_quirk = 0 code path to simplify the driver.
Tested-by: Dave Penkler
Reviewed-by: Steve Bayless
Signed-off-by: Guido Kiener
---
drivers/usb/class/usbtmc.c | 81 ++
Wait until an SRQ (service request) is received on the interrupt pipe
or until the given period of time is expired. In contrast to the
poll() function this ioctl does not return when other (a)synchronous
I/O operations fail with EPOLLERR.
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
--
- ioctl USBTMC_IOCTL_WRITE sends an (a)synchronous generic message
to bulk OUT. The message is split into chunks of 4k (page size).
Message size is aligned to 32 bit boundaries.
With flag USBTMC_FLAG_ASYNC the ioctl is non blocking.
With flag USBTMC_FLAG_APPEND additional urbs are queued a
- Optimize read/write functions for better bandwidth and
fixes reading of long transfers
- add ioctl USBTMC_IOCTL_AUTO_ABORT to configure auto_abort for
each specific file handle.
- add ioctl USBTMC_IOCTL_MSG_IN_ATTR that returns the specific
bmTransferAttributes field of the last DEV_DEP_M
- add USBTMC488_IOCTL_TRIGGER to send TRIGGER Bulk-OUT header
according to Subclass USB488 Specification
The usbtmc trigger command is equivalent to the IEEE 488 GET (Group
Execute Trigger) action. While the "*TRG" command can be sent as
data to perform the same operation, in some situatio
Add ioctls USBTMC_IOCTL_GET_TIMEOUT / USBTMC_IOCTL_SET_TIMEOUT to
get/set I/O timeout for specific file handle.
Different operations on an instrument can take different lengths of
time thus it is important to be able to set the timeout slightly
longer than the expected duration of each operation t
Insert a sleep of 50 ms between subsequent CHECK_CLEAR_STATUS
control requests to avoid stressing the instrument with repeated
requests.
Some instruments need time to cleanup internal I/O buffers.
Polling and repeated requests slow down the response time of
devices.
Signed-off-by: Guido Kiener
R
- fix ioctls USBTMC_IOCTL_ABORT_BULK_OUT/IN
- add ioctls USBTMC_IOCTL_ABORT_BULK_OUT_TAG and
USBTMC_IOCTL_ABORT_BULK_IN_TAG for test purpose.
Useful for testing devices and client applications: The ioctls
allow to test the abort mechanism and the response of the
device when using differen
- add ioctl USBTMC_IOCTL_API_VERSION to get current API version
- add info message to show API version
- replace USBTMC_TIMEOUT macros with common used USB_CTRL_GET_TIMEOUT
or USB_CTRL_SET_TIMEOUT macros.
- delete some superfluous code lines.
- update ioctl-number.txt
Signed-off-by: Guido Kiener
- Add 'struct usbtmc_file_data' for each file handle to cache last
srq_byte (=Status Byte with SRQ) received by usbtmc_interrupt(..)
- usbtmc488_ioctl_read_stb returns cached srq_byte when available for
each file handle to avoid race conditions of concurrent applications.
- SRQ now sets EPOLL
Add USBTMC_IOCTL_CTRL_REQUEST to send arbitrary requests on the
control pipe. Used by specific applications of IVI Foundation,
Inc. to implement VISA API functions: viUsbControlIn/Out.
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
drivers/usb/class/usbtmc.c | 61
The working group "VISA for Linux" of the IVI Foundation
www.ivifoundation.org specifies common rules, shared libraries and
drivers to implement the specification of "VPP-4.3: The VISA Library"
on Linux to be compatible with implementations on other operating systems.
The USBTMC protocol is part o
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: fbbe3b8c2c9c5f84caf668703c26154cb4fbb9d1
commit: 5f0b74e54890c354d6ac0124ea7a96adf22845d0 [7522/8111] USB: dwc3: get
extcon device by OF graph bindings
reproduce:
# apt-get install sparse
gi
Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings")
Signed-off-by: kbuild test robot
---
drd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index 2706824..218371f 100644
--- a/drivers/usb/dwc3/drd.c
+
rror: Oops: 5 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 4.17.0-rc5-next-20180517 #782
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> Workqueue: events deferred_probe_work_func
> PC is at usb_ep_alloc_request+0x1c/0x200
&
On Thu, 17 May 2018, Alexander Kappner wrote:
> Hi Alan,
>
> thanks for reviewing. (This is my first contribution that touches
> usb-storage, so please bear with me.)
>
> > That's kind of weird. Does the drive work under Windows in UAS mode?
>
> On the Windows 10 VM that I just spun up for
Hi
> -Original Message-
> From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com]
> Sent: 2018年5月17日 22:24
> To: Jun Li
> Cc: Mats Karrman ; robh...@kernel.org;
> gre...@linuxfoundation.org; li...@roeck-us.net; a.ha...@samsung.com;
> cw00.c...@samsung.com; shufan_...@richtek.com; Pe
On Thu, May 17, 2018 at 02:05:41PM +, Jun Li wrote:
> Hi Heikki,
>
> > > I reread this patch and tried to see it more in the context of the
> > > other patches and the existing code. The naming of the existing string
> > > tables doesn't help in getting this right, however I have a proposal:
>
On Thu, May 17, 2018 at 02:10:57PM +0100, Carlos Manuel Santos wrote:
> Hello.
> I'm having troubles with this NFC card reader. It seems kernel driver
> pn533 is not working properly.
> At this moment I have my work stalled. I need to add NFC support to a
> software product and I can't get the devi
Hi Heikki,
> > I reread this patch and tried to see it more in the context of the
> > other patches and the existing code. The naming of the existing string
> > tables doesn't help in getting this right, however I have a proposal:
> >
> > typec_find_port_power_role() to get to TYPEC_PORT_SRC/SNK/D
Hi Mario,
On Thu, May 17, 2018 at 01:01:20PM +, mario.limoncie...@dell.com wrote:
> > > Heikki,
> > >
> > > I confirmed with internal team that UCSI is implemented on XPS 9370
> > > and was confirmed to be working properly with Windows 10 RS2+.
> >
> > Just to double check: "UCSI was confirme
Hi Mats
> I reread this patch and tried to see it more in the context of the other
> patches
> and the existing code. The naming of the existing string tables doesn't help
> in
> getting this right, however I have a proposal:
>
> typec_find_port_power_role() to get to TYPEC_PORT_SRC/SNK/DRP
> t
Am Donnerstag, den 17.05.2018, 12:29 +0530 schrieb Tushar Nimkar:
> Those commands issued from different layers say: sd.. uas.. scsi..
> so making them to go one after other. Once REPORT_LUN done go with
> READ_CAPACITY_16.
> This is only for the UAS devices. I believe no disturb to BOT behavior.
On Thu, May 17, 2018 at 01:58:36PM +0100, Marc Zyngier wrote:
> This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7.
>
> Now that we can properly reset the uPD72020x without a hard PCI reset,
> let's get rid of the existing quirks.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/usb/ho
On Thu, May 17, 2018 at 01:58:34PM +0100, Marc Zyngier wrote:
> We now have 32 different quirks, and the field that holds them
> is full. Let's bump it up to the next stage so that we can handle
> some more... The type is now an unsigned long long, which is 64bit
> on most architectures.
>
> Signe
Hi
> -Original Message-
> From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com]
> Sent: 2018年5月16日 20:25
> To: Jun Li ; Mats Karrman
> Cc: robh...@kernel.org; gre...@linuxfoundation.org; li...@roeck-us.net;
> a.ha...@samsung.com; cw00.c...@samsung.com; shufan_...@richtek.com;
> Pe
> -Original Message-
> From: Peter Chen
> Sent: 2018年5月16日 16:36
> To: Jun Li ; robh...@kernel.org; gre...@linuxfoundation.org;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net
> Cc: a.ha...@samsung.com; cw00.c...@samsung.com;
> shufan_...@richtek.com; gso...@gmail.com; devicet...@vg
Hi Mats,
>
> Uhm, typing too fast again, I am. A better name would be just
> typec_find_role().
> What I mean is that the function could be used for any situation when
> someone wants to map a string to a TYPEC_{SOURCE,SINK} constant so it is
> unnecessary to limit its usage to just preferred role
Hi
> -Original Message-
> From: Peter Chen
> Sent: 2018年5月16日 15:22
> To: Jun Li ; robh...@kernel.org; gre...@linuxfoundation.org;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net
> Cc: a.ha...@samsung.com; cw00.c...@samsung.com;
> shufan_...@richtek.com; gso...@gmail.com; devicet...@v
Hello.
I'm having troubles with this NFC card reader. It seems kernel driver
pn533 is not working properly.
At this moment I have my work stalled. I need to add NFC support to a
software product and I can't get the device to work. NFC tools won't
work, the device is not detected.
This is what I ge
Am Donnerstag, den 17.05.2018, 01:15 -0700 schrieb Alexander Kappner:
> Yes. Without this flag, the device keeps throwing similar errors on
> usb-storage. That's the same result I get on a host that doesn't have UAS
> compiled in. Here's a dmesg:
Hi,
this is suspicious. You do not actually whet
> -Original Message-
> From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com]
> Sent: Thursday, May 17, 2018 4:00 AM
> To: Limonciello, Mario
> Cc: g...@kroah.com; pmenzel+linux-...@molgen.mpg.de; linux-
> u...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: `ucsi_acpi:
Some Renesas controllers get into a weird state if they are reset while
programmed with 64bit addresses (they will preserve the top half of the
address in internal, non visible registers).
You end up with half the address coming from the kernel, and the other
half coming from the firmware.
Also,
Back around the 4.13 timeframe, we tried to address a rather bad issue
with the Renesas uPD72020x USB3 controller family, that have a
horrible issue with the programming of the base addresses which tend
to stick on XHCI reset. This makes transitionning from 64bit to 32bit
addresses completely unsaf
This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7.
Now that we can properly reset the uPD72020x without a hard PCI reset,
let's get rid of the existing quirks.
Signed-off-by: Marc Zyngier
---
drivers/usb/host/pci-quirks.c | 20
drivers/usb/host/pci-quirks.h | 1
We now have 32 different quirks, and the field that holds them
is full. Let's bump it up to the next stage so that we can handle
some more... The type is now an unsigned long long, which is 64bit
on most architectures.
Signed-off-by: Marc Zyngier
---
drivers/usb/host/xhci.c | 6 +++---
drivers/u
On Wed, May 16, 2018 at 10:55:36PM +0200, Mats Karrman wrote:
> Hi,
>
> On 05/16/2018 02:25 PM, Heikki Krogerus wrote:
>
> > Hi guys,
> >
> > On Tue, May 15, 2018 at 10:52:57PM +0200, Mats Karrman wrote:
> >> Hi,
> >>
> >> On 05/14/2018 11:36 AM, Jun Li wrote:
> >>
> >>> Hi
> -Original M
0c
pgd = (ptrval)
[000c] *pgd=
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 4.17.0-rc5-next-20180517 #782
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
PC is at usb_ep_all
On Wed, May 16, 2018 at 11:11:02PM +0200, Mats Karrman wrote:
> On 05/16/2018 01:43 PM, Heikki Krogerus wrote:
>
> > On Tue, May 15, 2018 at 11:24:07PM +0200, Mats Karrman wrote:
> >> Hi Heikki,
> >>
> >> On 05/15/2018 09:30 AM, Heikki Krogerus wrote:
> >>
> >>> Hi Mats,
> >>>
> >>> On Fri, May 11
Hi Artur,
Thanks for the reply!
On Thu, May 17, 2018 at 09:10:06AM +, Artur Petrosyan wrote:
> Hi Mani,
>
> We need some detailed information to perform debugging.
>
> 1. Could you please share the documentation of "96Boards HiKey" board, at
> least dwc core configuration parameters. Or du
On Wed, May 16, 2018 at 11:47:39AM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 16, 2018 at 11:42:07AM +0200, Johan Hovold wrote:
> > We already have the tty port when probing a usb-serial port so use
> > tty_port_register_device() directly instead of tty_port_install() later
> > to set up the po
On Thu, May 17, 2018 at 10:29:14AM +0200, Johan Hovold wrote:
> On Thu, May 17, 2018 at 05:39:21AM +0200, Florian Zumbiehl wrote:
> > Now, I agree that signaling lack of support would be better in general, but
> > it does change what the code does for (still) unsupported cases. After all,
> > usbs
Hi Mani,
We need some detailed information to perform debugging.
1. Could you please share the documentation of "96Boards HiKey" board, at least
dwc core configuration parameters. Or dump of GHWCFG1-4.
2. Could you please share with us full debug log of dwc2 loading and plug the
USB device.
3.
Hi,
On Wed, May 16, 2018 at 04:13:31PM +, mario.limoncie...@dell.com wrote:
>
>
> > -Original Message-
> > From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com]
> > Sent: Wednesday, May 16, 2018 6:58 AM
> > To: Greg KH; Paul Menzel
> > Cc: linux-usb@vger.kernel.org; linux-ke
On Thu, May 17, 2018 at 05:39:21AM +0200, Florian Zumbiehl wrote:
> Hi,
>
> > > Note that the patch has only been fully tested with kernel 4.9.28, and
> > > test-compiled against 4.16.8. Tested only with the pl2303 adapters I have
> > > available (which seem to be type 0 if I interpret the code co
Hi Alan,
thanks for reviewing. (This is my first contribution that touches
usb-storage, so please bear with me.)
> That's kind of weird. Does the drive work under Windows in UAS mode?
On the Windows 10 VM that I just spun up for testing this, access to the
drive uses "usbstor.inf" (rather t
On 16.05.2018 20:38, Christian Brauns wrote:
Hi
I'm running 4.16.8-1-ARCH and that controller does not work, whereas I remember
it was working sometime before.
Now I'm travelling, don't have the controller with me, especially because it
does not work anymore.
This is what a part of dmesg lo
75 matches
Mail list logo
