Re: [PATCH] usb: gadget: Correct usb EP argument for BOT status request
Hi Manish, (Added target-devel CC') On Mon, 2017-03-20 at 15:05 +0530, Manish Narani wrote: > This patch corrects the argument in usb_ep_free_request as it is > mistakenly set to ep_out. It should be ep_in for status request. > > Signed-off-by: Manish Narani > --- > drivers/usb/gadget/function/f_tcm.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/usb/gadget/function/f_tcm.c > b/drivers/usb/gadget/function/f_tcm.c > index d235113..a82e2bd 100644 > --- a/drivers/usb/gadget/function/f_tcm.c > +++ b/drivers/usb/gadget/function/f_tcm.c > @@ -373,7 +373,7 @@ static void bot_cleanup_old_alt(struct f_uas *fu) > usb_ep_free_request(fu->ep_in, fu->bot_req_in); > usb_ep_free_request(fu->ep_out, fu->bot_req_out); > usb_ep_free_request(fu->ep_out, fu->cmd.req); > - usb_ep_free_request(fu->ep_out, fu->bot_status.req); > + usb_ep_free_request(fu->ep_in, fu->bot_status.req); > > kfree(fu->cmd.buf); > Applied to target-pending/master. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t
Hi Elena, On Mon, 2017-03-06 at 16:21 +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova > Signed-off-by: Hans Liljestrand > Signed-off-by: Kees Cook > Signed-off-by: David Windsor > --- > drivers/target/target_core_iblock.c | 12 ++-- > drivers/target/target_core_iblock.h | 3 ++- > 2 files changed, 8 insertions(+), 7 deletions(-) After reading up on this thread, it looks like various subsystem maintainers are now picking these atomic_t -> refcount_t conversions.. That said, applied to target-pending/for-next and will plan to include for v4.12-rc1 merge window. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM
Hi Mathias, On 21 February 2017 at 10:09, Baolin Wang wrote: >> Do you have any comments about this patch? Thanks. >> >>>drivers/usb/host/xhci-plat.c | 41 >>> - >>>1 file changed, 36 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/usb/host/xhci-plat.c >>> b/drivers/usb/host/xhci-plat.c >>> index ed56bf9..5805c6a 100644 >>> --- a/drivers/usb/host/xhci-plat.c >>> +++ b/drivers/usb/host/xhci-plat.c >>> @@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device >>> *pdev) >>> if (ret) >>> goto dealloc_usb2_hcd; >>> >>> + pm_runtime_get_noresume(&pdev->dev); >>> + pm_runtime_set_active(&pdev->dev); >>> + pm_runtime_enable(&pdev->dev); >>> + >>> return 0; >>> >>> > > To me this looks like we are not really enabling runtime pm for xhci, we > increment the > usage count in probe, and keep it until remove is called. > > This would normally prevent parent dwc3 from runtime suspending, but I > see > that in patch 2/2 adds > pm_suspend_ignore_children(dev, true) to dwc3, and, that dwc3 actually > controls xhci runtime > pm by calling pm_runtime_get/put for xhci in its own dwc3 > runtime_suspend/resume callbacks. > > Looks a bit upside down to me, what's the reason for this? > > what prevents calling pm_runtime_put_* before leaving probe in xhci and > let > pm code handle > the runtime suspend and parent/child relationships? When dwc3 controller is working on host mode, which will create and add the USB hcd for host side. Then if we want to suspend dwc3 controller as host mode, the USB device (bus) of host side will runtime suspend automatically if there are no slave attached (by usb_runtime_suspend()--->usb_suspend_both()--->usb_suspend_interface()--->usb_suspend_device()--->generic_suspend()--->hcd_bus_suspend()--->xhci_bus_suspend()), but we should not suspend xHCI device (issuing xhci_suspend()) now, since some other controllers did not implement the runtime PM to control xHCI device's runtime state, which will cause other controllers can not resume xHCI device (issuing xhci_resume()) if the xHCI device suspend automatically by its child device. Thus we should get the runtime count for xHCI device in xhci_plat_probe() in case xHCI device will also suspend automatically by its child device. According to that, for xHCI device's parent: dwc3 device, we should put the xHCI device's runtime count to suspend xHCI device manually. >>> >>> Any more comments? >>> >> >> I think I at least partially understand your point. You don't want to enable >> runtime suspend for all xhci platform devices by default, but only for the >> ones >> that are part of dwc3. >> >> The implementation you suggest is that xhci platform driver always increase >> the xhci platform >> device usage counter during probe with pm_runtime_get_noresume(), and never >> decrement it, >> preventing xhci platform devices from runtime suspending by themselves. >> >> You then control xhci runtime suspend from dwc3 driver runtime suspend, >> allowing >> xhci platfrom controller to runtime suspend only when dwc3 runtime suspends >> by decrementing xhci >> platform device usage in dwc3 runtime suspend callback. >> As xhci is a child of dwc3 in this case, dwc3 would never runtime suspend >> as long as xhci is running, so >> dwc3 needed to be detached from xhci by setting dwc3 to ignore its children >> to get it to work. > > Yes, that's my point. > >> >> I don't yet understand why we can't just keep runtime pm disabled as a >> default for xhci platform devices. >> It could be enabled by whatever creates the platform device by setting some >> device property >> (or equivalent), which would be checked in xhci_plat_probe() before enabling >> runtime pm. It >> could then optionally be set in sysfs via power/control entry. > > I think runtime pm is not one hardware property, is it suitable if we > introduce one device property to enable/disable runtime pm? As I said, runtime pm is not one hardware property, I think it is not suitable if we introduce one device property to enable/disable runtime pm. Secondly, we only can resume the xhci platform device by getting the xhci usage counter from gadget driver, since the cable plug in/out events only can be notified to glue layer of gadget driver(like dwc3 glue layer). That means if we want to suspend xhci platform device, we must put xhci usage counter (so we can not keep their parent-child relationship intact). That is why we need pm_suspend_ignore_children(dev, true). Mathias, could you re-check this patch? Thanks. >> >> We would keep the usage counting intact, and only enable xhci platform >> device runtime pm >> if the platform supports
Re: extcon-usb-gpio ACPI support
Hi, On 03/20/2017 10:41 PM, Andy Shevchenko wrote: > There is a so called ACPI support for extcon-usb-gpio. > > Since GPIO ACPI library is going to be stricter and this driver might > not work anymore. > > I would like to know: > 1. Is there any real DSDT which contains device enumerated by this > driver? > 2. If "yes" on 1, does that DSDT contain _DSD method for the device? > 3. If "no" on 2, how is it supposed to work at all? > > So, regarding on the answers, I am in between of reverting > > commit 942c7924a51edb75baf805679141e97140e07218 > Author: Lu Baolu > Date: Tue Apr 26 08:35:54 2016 +0900 > > extcon: usb-gpio: add support for ACPI gpio interface > > *or* > > someone better to add real DSDT example to Documentation regarding this > driver. This patch is part of below patch set. http://www.spinics.net/lists/linux-usb/msg141872.html It uses acpi_dev_add_driver_gpios() to add an ACPI GPIO resource. This patch set has been abandoned. So it's safe if you revert it. For your question 1, my answer is "no as far as I can see". Best regards, Lu Baolu -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/5] usb: early: add driver for xhci debug capability
XHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. XHCI specification describes DbC in the section 7.6. This patch introduces the code to probe and initialize the debug capability hardware during early boot. With hardware initialized, the debug target (system on which this code is running) will present a debug device through the debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of the xHCI host. There isn't any precondition from the xHCI host side for the DbC to work. One use for this feature is kernel debugging, for example when your machine crashes very early before the regular console code is initialized. Other uses include simpler, lockless logging instead of a full-blown printk console driver and klogd. Cc: Ingo Molnar Cc: Mathias Nyman Signed-off-by: Lu Baolu --- arch/x86/Kconfig.debug| 23 + drivers/usb/Makefile |2 +- drivers/usb/early/Makefile|1 + drivers/usb/early/xhci-dbc.c | 1014 + drivers/usb/early/xhci-dbc.h | 211 + include/linux/usb/xhci-dbgp.h | 29 ++ 6 files changed, 1279 insertions(+), 1 deletion(-) create mode 100644 drivers/usb/early/xhci-dbc.c create mode 100644 drivers/usb/early/xhci-dbc.h create mode 100644 include/linux/usb/xhci-dbgp.h diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index 63c1d13..f586462 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -5,6 +5,9 @@ config TRACE_IRQFLAGS_SUPPORT source "lib/Kconfig.debug" +config EARLY_PRINTK_USB + bool + config X86_VERBOSE_BOOTUP bool "Enable verbose x86 bootup info messages" default y @@ -29,6 +32,7 @@ config EARLY_PRINTK config EARLY_PRINTK_DBGP bool "Early printk via EHCI debug port" depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB ---help--- Write kernel log output directly into the EHCI debug port. @@ -48,6 +52,25 @@ config EARLY_PRINTK_EFI This is useful for kernel debugging when your machine crashes very early before the console code is initialized. +config EARLY_PRINTK_USB_XDBC + bool "Early printk via the xHCI debug port" + depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB + ---help--- + Write kernel log output directly into the xHCI debug port. + + One use for this feature is kernel debugging, for example when your + machine crashes very early before the regular console code is + initialized. Other uses include simpler, lockless logging instead of + a full-blown printk console driver + klogd. + + For normal production environments this is normally not recommended, + because it doesn't feed events into klogd/syslogd and doesn't try to + print anything on the screen. + + You should normally N here, unless you want to debug early crashes or + need a very simple printk logging facility. + config X86_PTDUMP_CORE def_bool n diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 7791af6..53d1356 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -49,7 +49,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/ obj-$(CONFIG_USB_SERIAL) += serial/ obj-$(CONFIG_USB) += misc/ -obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/ +obj-$(CONFIG_EARLY_PRINTK_USB) += early/ obj-$(CONFIG_USB_ATM) += atm/ obj-$(CONFIG_USB_SPEEDTOUCH) += atm/ diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile index 24bbe51..fcde228 100644 --- a/drivers/usb/early/Makefile +++ b/drivers/usb/early/Makefile @@ -3,3 +3,4 @@ # obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o +obj-$(CONFIG_EARLY_PRINTK_USB_XDBC) += xhci-dbc.o diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c new file mode 100644 index 000..1268818 --- /dev/null +++ b/drivers/usb/early/xhci-dbc.c @@ -0,0 +1,1014 @@ +/** + * xhci-dbc.c - xHCI debug capability early driver + * + * Copyright (C) 2016 Intel Corporation + * + * Author: Lu Baolu + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#define pr_fmt(fmt)KBUILD_MODNAME ":%s: " fmt, __func__ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../host/xhci.h" +#include "xhci-dbc.h" + +static struct xdbc_state xdbc; +static bool early_console_keep; + +#define XDBC_TRACE +#ifdef XDBC_TRACE +#define
[PATCH v8 4/5] usb: serial: add dbc debug device support to usb_debug
This patch adds dbc debug device support to the usb_debug driver.
Signed-off-by: Lu Baolu
Acked-by: Johan Hovold
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
};
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+ { USB_DEVICE(0x0525, 0x127a) },
+ { USB_DEVICE(0x1d6b, 0x0004) },
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
/* This HW really does not support a serial break, so one will be
* emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
};
+static struct usb_serial_driver dbc_device = {
+ .driver = {
+ .owner =THIS_MODULE,
+ .name = "xhci_dbc",
+ },
+ .id_table = dbc_id_table,
+ .num_ports =1,
+ .break_ctl =usb_debug_break_ctl,
+ .process_read_urb = usb_debug_process_read_urb,
+};
+
static struct usb_serial_driver * const serial_drivers[] = {
- &debug_device, NULL
+ &debug_device, &dbc_device, NULL
};
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
MODULE_LICENSE("GPL");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/5] x86: add simple udelay calibration
Add a simple udelay calibration in x86 architecture-specific
boot-time initializations. This will get a workable estimate
for loops_per_jiffy. Hence, udelay() could be used after this
initialization.
Cc: Ingo Molnar
Cc: x...@kernel.org
Signed-off-by: Lu Baolu
---
arch/x86/kernel/setup.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4bf0c89..e70204e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -837,6 +837,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned
long v, void *p)
return 0;
}
+static void __init simple_udelay_calibration(void)
+{
+ unsigned int tsc_khz, cpu_khz;
+ unsigned long lpj;
+
+ if (!boot_cpu_has(X86_FEATURE_TSC))
+ return;
+
+ cpu_khz = x86_platform.calibrate_cpu();
+ tsc_khz = x86_platform.calibrate_tsc();
+
+ tsc_khz = tsc_khz ? : cpu_khz;
+ if (!tsc_khz)
+ return;
+
+ lpj = tsc_khz * 1000;
+ do_div(lpj, HZ);
+ loops_per_jiffy = lpj;
+}
+
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
* passed the efi memmap, systab, etc., so we should use these data structures
@@ -985,6 +1005,8 @@ void __init setup_arch(char **cmdline_p)
*/
x86_configure_nx();
+ simple_udelay_calibration();
+
parse_early_param();
#ifdef CONFIG_MEMORY_HOTPLUG
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 5/5] usb: doc: add document for USB3 debug port usage
Add Documentation/usb/usb3-debug-port.rst. This document includes the guide for using USB3 debug port. Cc: linux-...@vger.kernel.org Signed-off-by: Lu Baolu --- Documentation/usb/usb3-debug-port.rst | 100 ++ 1 file changed, 100 insertions(+) create mode 100644 Documentation/usb/usb3-debug-port.rst diff --git a/Documentation/usb/usb3-debug-port.rst b/Documentation/usb/usb3-debug-port.rst new file mode 100644 index 000..feb1a36 --- /dev/null +++ b/Documentation/usb/usb3-debug-port.rst @@ -0,0 +1,100 @@ +=== +USB3 debug port +=== + +:Author: Lu Baolu +:Date: March 2017 + +GENERAL +=== + +This is a HOWTO for using the USB3 debug port on x86 systems. + +Before using any kernel debugging functionality based on USB3 +debug port, you need to:: + + 1) check whether any USB3 debug port is available in + your system; + 2) check which port is used for debugging purposes; + 3) have a USB 3.0 super-speed A-to-A debugging cable. + +INTRODUCTION + + +The xHCI debug capability (DbC) is an optional but standalone +functionality provided by the xHCI host controller. The xHCI +specification describes DbC in the section 7.6. + +When DbC is initialized and enabled, it will present a debug +device through the debug port (normally the first USB3 +super-speed port). The debug device is fully compliant with +the USB framework and provides the equivalent of a very high +performance full-duplex serial link between the debug target +(the system under debugging) and a debug host. + +EARLY PRINTK + + +DbC has been designed to log early printk messages. One use for +this feature is kernel debugging. For example, when your machine +crashes very early before the regular console code is initialized. +Other uses include simpler, lockless logging instead of a full- +blown printk console driver and klogd. + +On the debug target system, you need to customize a debugging +kernel with CONFIG_EARLY_PRINTK_USB_XDBC enabled. And, add below +kernel boot parameter:: + + "earlyprintk=xdbc" + +If there are multiple xHCI controllers in your system, you can +append a host contoller index to this kernel parameter. This +index starts from 0. + +Current design doesn't support DbC runtime suspend/resume. As +the result, you'd better disable runtime power management for +USB subsystem by adding below kernel boot parameter:: + + "usbcore.autosuspend=-1" + +Before starting the debug target, you should connect the debug +port to a USB port (root port or port of any external hub) on +the debug host. The cable used to connect these two ports +should be a USB 3.0 super-speed A-to-A debugging cable. + +During early boot of the debug target, DbC will be detected and +initialized. After initialization, the debug host should be able +to enumerate the debug device in debug target. The debug host +will then bind the debug device with the usb_debug driver module +and create the /dev/ttyUSB device. + +If the debug device enumeration goes smoothly, you should be able +to see below kernel messages on the debug host:: + + # tail -f /var/log/kern.log + [ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd + [ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM. + [ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, idProduct=0004 + [ 1815.02] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 + [ 1815.03] usb 4-3: Product: Remote GDB + [ 1815.04] usb 4-3: Manufacturer: Linux + [ 1815.05] usb 4-3: SerialNumber: 0001 + [ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected + [ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0 + +You can use any communication program, for example minicom, to +read and view the messages. Below simple bash scripts can help +you to check the sanity of the setup. + +.. code-block:: sh + + = start of bash scripts = + #!/bin/bash + + while true ; do + while [ ! -d /sys/class/tty/ttyUSB0 ] ; do + : + done + cat /dev/ttyUSB0 + done + = end of bash scripts === -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/5] x86: add support for earlyprintk via USB3 debug port
Add support for earlyprintk by writing debug messages to the
USB3 debug port. Users can use this type of early printk by
specifying the kernel parameter of "earlyprintk=xdbc". This
gives users a chance of providing debugging output.
The hardware for USB3 debug port requires DMA memory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.
Cc: Ingo Molnar
Cc: x...@kernel.org
Signed-off-by: Lu Baolu
---
Documentation/admin-guide/kernel-parameters.txt | 1 +
arch/x86/kernel/early_printk.c | 5 +
arch/x86/kernel/setup.c | 4
3 files changed, 10 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45ca..ea1293d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -989,6 +989,7 @@
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+ earlyprintk=xdbc[xhciController#]
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 8a12199..0f08403 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -381,6 +382,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "efi", 3))
early_console_register(&early_efi_console, keep);
#endif
+#ifdef CONFIG_EARLY_PRINTK_USB_XDBC
+ if (!strncmp(buf, "xdbc", 4))
+ early_xdbc_parse_parameter(buf + 4);
+#endif
buf++;
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e70204e..2600b1d 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -70,6 +70,7 @@
#include
#include
+#include
#include
#include
@@ -1144,6 +1145,9 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
+ if (!early_xdbc_setup_hardware())
+ early_xdbc_register_console();
+
reserve_bios_regions();
if (efi_enabled(EFI_MEMMAP)) {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/5] usb: early: add support for early printk through USB3 debug port
xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. With DbC hardware initialized, the system will present a debug device through the USB3 debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework and provides the equivalent of a very high performance (USB3) full-duplex serial link between the debug host and target. The DbC functionality is independent of xHCI host. This patch set adds support for early printk functionality through a USB3 debug port by 1) initializing and enabling the DbC hardware during early boot; 2) registering a boot console to the system so that early printk messages can go through the USB3 debug port. It also includes some lines of changes in usb_debug driver so that it can be bound when a USB3 debug device is enumerated. --- Change log: v7->v8: - refine the Kconfig help text. - cleanup the unnecessary USB_EARLY_PRINTK bool. - refine comments and trace messages in the driver. - update usb3-debug-port.rst after internal reivew. v6->v7: - add a new patch "[PATCH 1/5] x86: add simple udelay calibration" to make udelay() work for early drivers. - [PATCH 2/5] usb: dbc: early driver for xhci debug capability - add a kernel thread to handle error cases, such as cable unplugging. - Fixed several code styles pointed out by Ingo. v5->v6: - rebase the patches on top of the latest 4.10-rc4 - run successfully in a 32-bit kernel - [PATCH 1/4] - remove ugly linebreaks to make code more readable - rename config names to make them consistency - move sleep-able ioremap() out of the lock area - rename reserved fields of register structures - make the vertical tabulation of struct fields consistent - [PATCH 2/4] - remove "#ifdef" in the generic code by creating proper wrappers in header file - [PATCH 3/4] - refine the title and commit message - [PATCH 4/4] - fix several typos and grammar errors in the document v4->v5: - add raw_spin_lock to make xdbc_bulk_write() reentrant. v3->v4: - Rename the document with .dst suffix. - Add the list of hardware that has been succesfuly tested on in the document. v2->v3: - Removed spinlock usage. - Removed work queue usage. - Refined the user guide document. v1->v2: - Refactor the duplicate code in xdbc_early_start() and xdbc_handle_external_reset(). - Free resources when hardware not used any more. - Refine the user guide document. Lu Baolu (5): x86: add simple udelay calibration usb: early: add driver for xhci debug capability x86: add support for earlyprintk via USB3 debug port usb: serial: add dbc debug device support to usb_debug usb: doc: add document for USB3 debug port usage Documentation/admin-guide/kernel-parameters.txt |1 + Documentation/usb/usb3-debug-port.rst | 100 +++ arch/x86/Kconfig.debug | 23 + arch/x86/kernel/early_printk.c |5 + arch/x86/kernel/setup.c | 26 + drivers/usb/Makefile|2 +- drivers/usb/early/Makefile |1 + drivers/usb/early/xhci-dbc.c| 1014 +++ drivers/usb/early/xhci-dbc.h| 211 + drivers/usb/serial/usb_debug.c | 28 +- include/linux/usb/xhci-dbgp.h | 29 + 11 files changed, 1436 insertions(+), 4 deletions(-) create mode 100644 Documentation/usb/usb3-debug-port.rst create mode 100644 drivers/usb/early/xhci-dbc.c create mode 100644 drivers/usb/early/xhci-dbc.h create mode 100644 include/linux/usb/xhci-dbgp.h -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM
Hi,
Baolin Wang writes:
>>> I don't yet understand why we can't just keep runtime pm disabled as a
>>> default for xhci platform devices.
>>> It could be enabled by whatever creates the platform device by setting some
>>> device property
>>> (or equivalent), which would be checked in xhci_plat_probe() before enabling
>>> runtime pm. It
>>> could then optionally be set in sysfs via power/control entry.
>>
>> I think runtime pm is not one hardware property, is it suitable if we
>> introduce one device property to enable/disable runtime pm?
>
> As I said, runtime pm is not one hardware property, I think it is not
> suitable if we introduce one device property to enable/disable runtime
> pm.
we already this functionality exposed on sysfs.
> Secondly, we only can resume the xhci platform device by getting the
> xhci usage counter from gadget driver, since the cable plug in/out
> events only can be notified to glue layer of gadget driver(like dwc3
> glue layer). That means if we want to suspend xhci platform device, we
this is a problem with the glue layer, IMO. It should be something like
so:
static irqreturn_t dwc3_foobar_wakeup(int irq, void *_glue)
{
struct dwc3_foobar_glue *glue = _glue;
u32 reg;
reg = real(glue->base, OFFSET);
if (reg & CONNECT)
pm_runtime_resume(&glue->dwc3);
return IRQ_HANDLED;
}
then dwc3's ->runtime_resume() should check if the event is supposed to
be handled by host or peripheral by checking which mode it was before
suspend and making the assumption that we don't change modes while
suspended. Something like:
static int dwc3_runtime_resume(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
[...]
if (dwc->is_host)
pm_runtime_resume(dwc->xhci.dev);
[...]
return 0;
}
> must put xhci usage counter (so we can not keep their parent-child
> relationship intact). That is why we need
> pm_suspend_ignore_children(dev, true).
you really shouldn't need that and it's still unclear why you think you
do.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v17 0/3] USB Type-C Connector class
On Tue, Feb 21, 2017 at 05:24:02PM +0300, Heikki Krogerus wrote: > The USB Type-C class is meant to provide unified interface to the > userspace to present the USB Type-C ports in a system. > > Changes since v16: > - Using PTR_ERR_OR_ZERO macro in typec_init(). I'm lost in the long thread here, is this series still ready to be merged in, or is there another version that is being worked on? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v17 0/3] USB Type-C Connector class
On Tue, Mar 21, 2017 at 11:23:37AM +0100, Greg KH wrote: > On Tue, Feb 21, 2017 at 05:24:02PM +0300, Heikki Krogerus wrote: > > The USB Type-C class is meant to provide unified interface to the > > userspace to present the USB Type-C ports in a system. > > > > Changes since v16: > > - Using PTR_ERR_OR_ZERO macro in typec_init(). > > I'm lost in the long thread here, is this series still ready to be > merged in, or is there another version that is being worked on? There was one documentation fix proposed Mats. The rest of the thread was not about these patches. I'll send one more version and fix the documentation. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v17 0/3] USB Type-C Connector class
On Tue, Feb 21, 2017 at 05:42:35PM +0200, Felipe Balbi wrote: > Just to clarify one thing here: wherever it says "Reviewed-by: Felipe > Balbi..." you could also read "Reviewed-and-Tested-by: Felipe Balbi..." > as I have been running these patches for past few months to test code on > Intel Joule. OK :-) Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] net: usb: usbnet: add new api ethtool_{get|set}_link_ksettings
Am Donnerstag, den 16.03.2017, 23:18 +0100 schrieb Philippe Reynes:
> The ethtool api {get|set}_settings is deprecated.
> We add the new api {get|set}_link_ksettings to this driver.
>
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
>
Unfortunately I lack hardware to test.
Phillipe and I had a patch collision. David, please take his
patch for the next merge window. It looks good and is comprehensive and
nobody has reported issues. We will never find testers for all those
drivers on this list.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/5] usb: early: add support for early printk through USB3 debug port
* Lu Baolu wrote: > xHCI debug capability (DbC) is an optional but standalone > functionality provided by an xHCI host controller. With DbC > hardware initialized, the system will present a debug device > through the USB3 debug port (normally the first USB3 port). > The debug device is fully compliant with the USB framework > and provides the equivalent of a very high performance (USB3) > full-duplex serial link between the debug host and target. > The DbC functionality is independent of xHCI host. > > This patch set adds support for early printk functionality > through a USB3 debug port by 1) initializing and enabling > the DbC hardware during early boot; 2) registering a boot > console to the system so that early printk messages can go > through the USB3 debug port. It also includes some lines > of changes in usb_debug driver so that it can be bound when > a USB3 debug device is enumerated. > [...] > > Lu Baolu (5): > x86: add simple udelay calibration > usb: early: add driver for xhci debug capability > x86: add support for earlyprintk via USB3 debug port > usb: serial: add dbc debug device support to usb_debug > usb: doc: add document for USB3 debug port usage > > Documentation/admin-guide/kernel-parameters.txt |1 + > Documentation/usb/usb3-debug-port.rst | 100 +++ > arch/x86/Kconfig.debug | 23 + > arch/x86/kernel/early_printk.c |5 + > arch/x86/kernel/setup.c | 26 + > drivers/usb/Makefile|2 +- > drivers/usb/early/Makefile |1 + > drivers/usb/early/xhci-dbc.c| 1014 > +++ > drivers/usb/early/xhci-dbc.h| 211 + > drivers/usb/serial/usb_debug.c | 28 +- > include/linux/usb/xhci-dbgp.h | 29 + > 11 files changed, 1436 insertions(+), 4 deletions(-) > create mode 100644 Documentation/usb/usb3-debug-port.rst > create mode 100644 drivers/usb/early/xhci-dbc.c > create mode 100644 drivers/usb/early/xhci-dbc.h > create mode 100644 include/linux/usb/xhci-dbgp.h Ok, this has now become a high quality series with picture-perfect patches AFAICS. Thomas also gave his Acked-by to all the patches. I've applied them locally to -tip (it appears the USB maintainers are still fine with this being carried in tip:x86/debug for a v4.12 merge, right?), and will push them out and will propagate them to linux-next as well if they pass testing. Thanks for the great work! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v18 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
This adds driver for the USB Type-C PHY on Intel WhiskeyCove
PMIC which is available on some of the Intel Broxton SoC
based platforms.
Signed-off-by: Heikki Krogerus
Reviewed-by: Mika Westerberg
Reviewed-and-Tested-by: Felipe Balbi
Tested-by: Guenter Roeck
---
drivers/usb/typec/Kconfig | 15 ++
drivers/usb/typec/Makefile | 1 +
drivers/usb/typec/typec_wcove.c | 377
3 files changed, 393 insertions(+)
create mode 100644 drivers/usb/typec/typec_wcove.c
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 17792f9114c6..dfcfe459b7cf 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -4,4 +4,19 @@ menu "USB Power Delivery and Type-C drivers"
config TYPEC
tristate
+config TYPEC_WCOVE
+ tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
+ depends on ACPI
+ depends on INTEL_SOC_PMIC
+ depends on INTEL_PMC_IPC
+ depends on BXT_WC_PMIC_OPREGION
+ select TYPEC
+ help
+ This driver adds support for USB Type-C detection on Intel Broxton
+ platforms that have Intel Whiskey Cove PMIC. The driver can detect the
+ role and cable orientation.
+
+ To compile this driver as module, choose M here: the module will be
+ called typec_wcove
+
endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 1012a8bed6d5..b9cb862221af 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_TYPEC)+= typec.o
+obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
diff --git a/drivers/usb/typec/typec_wcove.c b/drivers/usb/typec/typec_wcove.c
new file mode 100644
index ..d5a7b21fa3f1
--- /dev/null
+++ b/drivers/usb/typec/typec_wcove.c
@@ -0,0 +1,377 @@
+/**
+ * typec_wcove.c - WhiskeyCove PMIC USB Type-C PHY driver
+ *
+ * Copyright (C) 2017 Intel Corporation
+ * Author: Heikki Krogerus
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register offsets */
+#define WCOVE_CHGRIRQ0 0x4e09
+#define WCOVE_PHYCTRL 0x5e07
+
+#define USBC_CONTROL1 0x7001
+#define USBC_CONTROL2 0x7002
+#define USBC_CONTROL3 0x7003
+#define USBC_CC1_CTRL 0x7004
+#define USBC_CC2_CTRL 0x7005
+#define USBC_STATUS1 0x7007
+#define USBC_STATUS2 0x7008
+#define USBC_STATUS3 0x7009
+#define USBC_IRQ1 0x7015
+#define USBC_IRQ2 0x7016
+#define USBC_IRQMASK1 0x7017
+#define USBC_IRQMASK2 0x7018
+
+/* Register bits */
+
+#define USBC_CONTROL1_MODE_DRP(r) (((r) & ~0x7) | 4)
+
+#define USBC_CONTROL2_UNATT_SNKBIT(0)
+#define USBC_CONTROL2_UNATT_SRCBIT(1)
+#define USBC_CONTROL2_DIS_ST BIT(2)
+
+#define USBC_CONTROL3_PD_DIS BIT(1)
+
+#define USBC_CC_CTRL_VCONN_EN BIT(1)
+
+#define USBC_STATUS1_DET_ONGOING BIT(6)
+#define USBC_STATUS1_RSLT(r) ((r) & 0xf)
+#define USBC_RSLT_NOTHING 0
+#define USBC_RSLT_SRC_DEFAULT 1
+#define USBC_RSLT_SRC_1_5A 2
+#define USBC_RSLT_SRC_3_0A 3
+#define USBC_RSLT_SNK 4
+#define USBC_RSLT_DEBUG_ACC5
+#define USBC_RSLT_AUDIO_ACC6
+#define USBC_RSLT_UNDEF15
+#define USBC_STATUS1_ORIENT(r) (((r) >> 4) & 0x3)
+#define USBC_ORIENT_NORMAL 1
+#define USBC_ORIENT_REVERSE2
+
+#define USBC_STATUS2_VBUS_REQ BIT(5)
+
+#define USBC_IRQ1_ADCDONE1 BIT(2)
+#define USBC_IRQ1_OVERTEMP BIT(1)
+#define USBC_IRQ1_SHORTBIT(0)
+
+#define USBC_IRQ2_CC_CHANGEBIT(7)
+#define USBC_IRQ2_RX_PDBIT(6)
+#define USBC_IRQ2_RX_HRBIT(5)
+#define USBC_IRQ2_RX_CRBIT(4)
+#define USBC_IRQ2_TX_SUCCESS BIT(3)
+#define USBC_IRQ2_TX_FAIL BIT(2)
+
+#define USBC_IRQMASK1_ALL (USBC_IRQ1_ADCDONE1 | USBC_IRQ1_OVERTEMP | \
+USBC_IRQ1_SHORT)
+
+#define USBC_IRQMASK2_ALL (USBC_IRQ2_CC_CHANGE | USBC_IRQ2_RX_PD | \
+USBC_IRQ2_RX_HR | USBC_IRQ2_RX_CR | \
+USBC_IRQ2_TX_SUCCESS | USBC_IRQ2_TX_FAIL)
+
+struct wcove_typec {
+ struct mutex lock; /* device lock */
+ struct device *dev;
+ struct regmap *regmap;
+ struct typec_port *port;
+ struct typec_capability cap;
+ struct typec_partner *partner;
+};
+
+enum wcove_typec_func {
+ WCOVE_FUNC_DRIVE_VBUS = 1,
+ WCOVE_FUNC_ORIENTATION,
+ WCOVE_FUNC_ROLE,
+ WCOVE_FUNC_DRIVE_VCONN,
+};
+
[PATCH v18 0/3] USB Type-C Connector class
The USB Type-C class is meant to provide unified interface to the userspace to present the USB Type-C ports in a system. Changes since v17: - Small documentation improvements. Changes since v16: - Using PTR_ERR_OR_ZERO macro in typec_init(). Changes since v15: - "stingification" as proposed by Felipe - Checking ARRAY_SIZE in supported_accessory_modes() as proposed by Guenter Changes since v14: - Fixes proposed by Mika - "identity" directory for all discover identity VDOs instead of "vdo" attribute - alternate mode device names to just "svid-" Changes since v13: - New API. Everything is registered separately. Changes since v12: - Added prefer_role member to typec_capability structure as requested by Guenter Changes since v11: - The port drivers are responsible of removing the alternate modes (just like the documentation already said). Changes since v10: - Using ATTRIBUTE_GROUPS and DEVICE_ATTR marcos everywhere - Moved sysfs_match_string to lib/string.c - Rationalized uevents - Calling ida_destroy Changes since v9: - Minor typec_wcove.c cleanup as proposed by Guenter Roeck. No function affect. Changes since v8: - checking sysfs_streq() result correctly in sysfs_strmatch - fixed accessory check in supported_accessory_mode - using "none" as the only string that can clear the preferred role Changes since v7: - Removed "type" attribute from partners - Added supports_usb_power_delivery attribute for partner and cable Changes since v6: - current_vconn_role attr renamed to vconn_source (no API changes) - Small documentation improvements proposed by Vincent Palatin Changes since v5: - Only updating the roles based on driver notifications - Added MODULE_ALIAS for the WhiskeyCove module - Including the patch that creates the actual platform device for the WhiskeyCove Type-C PHY in this series. Changes since v4: - Remove the port lock completely Changes since v3: - Documentation cleanup as proposed by Roger Quadros - Setting partner altmodes member to NULL on removal and fixing a warning, as proposed by Guenter Roeck - Added the following attributes for partners and cables: * supports_usb_power_delivery * id_header_vdo - "id_header_vdo" is visible only when the partner or cable supports USB Power Delivery communication. - Partner attribute "accessory" is hidden when the partner type is not "Accessory". Changes since v2: - Notification on role and alternate mode changes - cleanups Changes since v1: - Completely rewrote alternate mode support - Patners, cables and cable plugs presented as devices. Heikki Krogerus (3): lib/string: add sysfs_match_string helper usb: USB Type-C connector class usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY Documentation/ABI/testing/sysfs-class-typec | 276 ++ Documentation/usb/typec.rst | 184 MAINTAINERS |9 + drivers/usb/Kconfig |2 + drivers/usb/Makefile|2 + drivers/usb/typec/Kconfig | 22 + drivers/usb/typec/Makefile |2 + drivers/usb/typec/typec.c | 1262 +++ drivers/usb/typec/typec_wcove.c | 377 include/linux/string.h | 10 + include/linux/usb/typec.h | 243 ++ lib/string.c| 26 + 12 files changed, 2415 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-typec create mode 100644 Documentation/usb/typec.rst create mode 100644 drivers/usb/typec/Kconfig create mode 100644 drivers/usb/typec/Makefile create mode 100644 drivers/usb/typec/typec.c create mode 100644 drivers/usb/typec/typec_wcove.c create mode 100644 include/linux/usb/typec.h -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v18 1/3] lib/string: add sysfs_match_string helper
Make a simple helper for matching strings with sysfs
attribute files. In most parts the same as match_string(),
except sysfs_match_string() uses sysfs_streq() instead of
strcmp() for matching. This is more convenient when used
with sysfs attributes.
Signed-off-by: Heikki Krogerus
Reviewed-by: Mika Westerberg
Reviewed-by: Felipe Balbi
Tested-by: Guenter Roeck
---
include/linux/string.h | 10 ++
lib/string.c | 26 ++
2 files changed, 36 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index 040eab355533..96e4ad598210 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -136,6 +136,16 @@ static inline int strtobool(const char *s, bool *res)
}
int match_string(const char * const *array, size_t n, const char *string);
+int __sysfs_match_string(const char * const *array, size_t n, const char *s);
+
+/**
+ * sysfs_match_string - matches given string in an array
+ * @_a: array of strings
+ * @_s: string to match with
+ *
+ * Helper for __sysfs_match_string(). Calculates the size of @a automatically.
+ */
+#define sysfs_match_string(_a, _s) __sysfs_match_string(_a, ARRAY_SIZE(_a), _s)
#ifdef CONFIG_BINARY_PRINTF
int vbin_printf(u32 *bin_buf, size_t size, const char *fmt,
diff --git a/lib/string.c b/lib/string.c
index b3c22a285a78..f47a72098c87 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -656,6 +656,32 @@ int match_string(const char * const *array, size_t n,
const char *string)
}
EXPORT_SYMBOL(match_string);
+/**
+ * __sysfs_match_string - matches given string in an array
+ * @array: array of strings
+ * @n: number of strings in the array or -1 for NULL terminated arrays
+ * @str: string to match with
+ *
+ * Returns index of @str in the @array or -EINVAL, just like match_string().
+ * Uses sysfs_streq instead of strcmp for matching.
+ */
+int __sysfs_match_string(const char * const *array, size_t n, const char *str)
+{
+ const char *item;
+ int index;
+
+ for (index = 0; index < n; index++) {
+ item = array[index];
+ if (!item)
+ break;
+ if (sysfs_streq(item, str))
+ return index;
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(__sysfs_match_string);
+
#ifndef __HAVE_ARCH_MEMSET
/**
* memset - Fill a region of memory with the given value
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v18 2/3] usb: USB Type-C connector class
The purpose of USB Type-C connector class is to provide unified interface for the user space to get the status and basic information about USB Type-C connectors on a system, control over data role swapping, and when the port supports USB Power Delivery, also control over power role swapping and Alternate Modes. Signed-off-by: Heikki Krogerus Reviewed-by: Mika Westerberg Reviewed-and-Tested-by: Felipe Balbi Tested-by: Guenter Roeck --- Documentation/ABI/testing/sysfs-class-typec | 276 ++ Documentation/usb/typec.rst | 184 MAINTAINERS |9 + drivers/usb/Kconfig |2 + drivers/usb/Makefile|2 + drivers/usb/typec/Kconfig |7 + drivers/usb/typec/Makefile |1 + drivers/usb/typec/typec.c | 1262 +++ include/linux/usb/typec.h | 243 ++ 9 files changed, 1986 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-typec create mode 100644 Documentation/usb/typec.rst create mode 100644 drivers/usb/typec/Kconfig create mode 100644 drivers/usb/typec/Makefile create mode 100644 drivers/usb/typec/typec.c create mode 100644 include/linux/usb/typec.h diff --git a/Documentation/ABI/testing/sysfs-class-typec b/Documentation/ABI/testing/sysfs-class-typec new file mode 100644 index ..d4a3d23eb09c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-typec @@ -0,0 +1,276 @@ +USB Type-C port devices (eg. /sys/class/typec/port0/) + +What: /sys/class/typec//data_role +Date: April 2017 +Contact: Heikki Krogerus +Description: + The supported USB data roles. This attribute can be used for + requesting data role swapping on the port. Swapping is supported + as synchronous operation, so write(2) to the attribute will not + return until the operation has finished. The attribute is + notified about role changes so that poll(2) on the attribute + wakes up. Change on the role will also generate uevent + KOBJ_CHANGE on the port. The current role is show in brackets, + for example "[host] device" when DRP port is in host mode. + + Valid values: host, device + +What: /sys/class/typec//power_role +Date: April 2017 +Contact: Heikki Krogerus +Description: + The supported power roles. This attribute can be used to request + power role swap on the port when the port supports USB Power + Delivery. Swapping is supported as synchronous operation, so + write(2) to the attribute will not return until the operation + has finished. The attribute is notified about role changes so + that poll(2) on the attribute wakes up. Change on the role will + also generate uevent KOBJ_CHANGE. The current role is show in + brackets, for example "[source] sink" when in source mode. + + Valid values: source, sink + +What: /sys/class/typec//vconn_source +Date: April 2017 +Contact: Heikki Krogerus +Description: + Shows is the port VCONN Source. This attribute can be used to + request VCONN swap to change the VCONN Source during connection + when both the port and the partner support USB Power Delivery. + Swapping is supported as synchronous operation, so write(2) to + the attribute will not return until the operation has finished. + The attribute is notified about VCONN source changes so that + poll(2) on the attribute wakes up. Change on VCONN source also + generates uevent KOBJ_CHANGE. + + Valid values: + - "no" when the port is not the VCONN Source + - "yes" when the port is the VCONN Source + +What: /sys/class/typec//power_operation_mode +Date: April 2017 +Contact: Heikki Krogerus +Description: + Shows the current power operational mode the port is in. The + power operation mode means current level for VBUS. In case USB + Power Delivery communication is used for negotiating the levels, + power operation mode should show "usb_power_delivery". + + Valid values: + - default + - 1.5A + - 3.0A + - usb_power_delivery + +What: /sys/class/typec//preferred_role +Date: April 2017 +Contact: Heikki Krogerus +Description: + The user space can notify the driver about the preferred role. + It should be handled as enabling of Try.SRC or Try.SNK, as + defined in USB Type-C specification, in the port drivers. By + default
Re: [PATCH v8 0/5] usb: early: add support for early printk through USB3 debug port
On Tue, Mar 21, 2017 at 12:33:28PM +0100, Ingo Molnar wrote: > > * Lu Baolu wrote: > > > xHCI debug capability (DbC) is an optional but standalone > > functionality provided by an xHCI host controller. With DbC > > hardware initialized, the system will present a debug device > > through the USB3 debug port (normally the first USB3 port). > > The debug device is fully compliant with the USB framework > > and provides the equivalent of a very high performance (USB3) > > full-duplex serial link between the debug host and target. > > The DbC functionality is independent of xHCI host. > > > > This patch set adds support for early printk functionality > > through a USB3 debug port by 1) initializing and enabling > > the DbC hardware during early boot; 2) registering a boot > > console to the system so that early printk messages can go > > through the USB3 debug port. It also includes some lines > > of changes in usb_debug driver so that it can be bound when > > a USB3 debug device is enumerated. > > > [...] > > > > Lu Baolu (5): > > x86: add simple udelay calibration > > usb: early: add driver for xhci debug capability > > x86: add support for earlyprintk via USB3 debug port > > usb: serial: add dbc debug device support to usb_debug > > usb: doc: add document for USB3 debug port usage > > > > Documentation/admin-guide/kernel-parameters.txt |1 + > > Documentation/usb/usb3-debug-port.rst | 100 +++ > > arch/x86/Kconfig.debug | 23 + > > arch/x86/kernel/early_printk.c |5 + > > arch/x86/kernel/setup.c | 26 + > > drivers/usb/Makefile|2 +- > > drivers/usb/early/Makefile |1 + > > drivers/usb/early/xhci-dbc.c| 1014 > > +++ > > drivers/usb/early/xhci-dbc.h| 211 + > > drivers/usb/serial/usb_debug.c | 28 +- > > include/linux/usb/xhci-dbgp.h | 29 + > > 11 files changed, 1436 insertions(+), 4 deletions(-) > > create mode 100644 Documentation/usb/usb3-debug-port.rst > > create mode 100644 drivers/usb/early/xhci-dbc.c > > create mode 100644 drivers/usb/early/xhci-dbc.h > > create mode 100644 include/linux/usb/xhci-dbgp.h > > Ok, this has now become a high quality series with picture-perfect patches > AFAICS. > > Thomas also gave his Acked-by to all the patches. > > I've applied them locally to -tip (it appears the USB maintainers are still > fine > with this being carried in tip:x86/debug for a v4.12 merge, right?), and will > push > them out and will propagate them to linux-next as well if they pass testing. Yes, no objection from me. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/5] usb: early: add support for early printk through USB3 debug port
* Greg Kroah-Hartman wrote: > > I've applied them locally to -tip (it appears the USB maintainers are still > > fine with this being carried in tip:x86/debug for a v4.12 merge, right?), > > and > > will push them out and will propagate them to linux-next as well if they > > pass > > testing. > > Yes, no objection from me. Cool, thanks! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Mon, Mar 20, 2017 at 8:15 PM, Diego Viola wrote: > On Mon, Mar 20, 2017 at 3:27 PM, Diego Viola wrote: >> On Mon, Mar 20, 2017 at 1:32 PM, Mathias Nyman >> wrote: >>> On 20.03.2017 17:39, Diego Viola wrote: On Mon, Mar 20, 2017 at 11:21 AM, Mathias Nyman wrote: > > On 19.03.2017 23:29, Diego Viola wrote: >> >> >>> >>> Still a problem with 4.11.0-rc2-ARCH+ > > 4.11-rc2 has better xhci tracing, it shows each URB enqueue and dequeue > and > giveback. > > Could you try enabling xhci tracing before suspending (not the same as > xhci > verbose dynamic debug) > It will generate a lot of data, so better to remove all extra USB > devices. > > xhci tracing can be added with: > > mount -t debugfs none /sys/kernel/debug > echo xhci-hcd >> /sys/kernel/debug/tracing/set_event > > and then send the output of cat /sys/kernel/debug/tracing/trace https://bugzilla.kernel.org/attachment.cgi?id=255367 This is with Linux 4.11.0-rc3-ARCH. USB mouse/keyboard was unplugged before booting the machine. I didn't do a suspend/resume before getting this trace, should I do that? Should I reproduce the hang and get a netconsole dmesg capture with tracing enabled? >>> >>> >>> A trace and a dmesg of the same suspend/reusume hang would be great. >> >> I can capture the dmesg with netconsole once the machine hangs, but >> I'm not sure how I could capture /sys/kernel/debug/tracing/trace after >> the hang. I'm unable to use ssh after the hang. >> >>> And if you can then one of a succesful suspend/resume for reference. >> >> Here's the trace after a successful suspend/resume: >> >> https://bugzilla.kernel.org/attachment.cgi?id=255369 >> >>> >>> (I haven't yet checked the one you added to bugzilla) >>> >>> -Mathias >> >> Diego > > ftrace_dump_on_oops is what I was looking for. > > Diego I tried ftrace_dump_on_oops but I can't see the trace coming in, not sure what I'm doing wrong. :( Diego -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/7] phylib MMD accessor cleanups
On Sun, Mar 19, 2017 at 03:30:38PM -0700, Florian Fainelli wrote: > Le 03/19/17 à 03:59, Russell King - ARM Linux a écrit : > > This series of patches does exactly that - we merge the functionality > > of the indirect accesses into the clause 45 accessors, and use these > > exclusively to access MMD registers. Internally, the new clause > > independent MMD accessors indirect via the PHY drivers read_mmd/write_mmd > > methods if present, otherwise fall back to using clause 45 accesses if > > the PHY is a clause 45 phy, or clause 22 indirect accesses if the PHY > > is clause 22. > > LGTM: > > Reviewed-by: Florian Fainelli Thanks. When I posted this last time around (19th Jan) I mentioned about marking the old _indirect() accessors with __deprecated - is that still something we want to do? I haven't tested this against net-next yet, so I don't know if there are any new users of the indirect accessors - going down the deprecated route would avoid breakage, but means having to submit a patch later to actually remove them. How would people want this handled? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] HID: remove initial reading of reports at connect
On Wed, 8 Mar 2017, Benjamin Tissoires wrote: > It looks like a bunch of devices do not like to be polled for their > reports at init time. When you look into the details, it seems that for > those that are requiring the quirk HID_QUIRK_NO_INIT_REPORTS, the driver > fails to retrieve part of the features/inputs while others (more > generic) work. > > IMO, it should be acceptable to remove the need for the quirk in the > general case. On the small amount of cases where we actually need to > read the current values, the driver in charge (hid-mt or wacom) already > retrieves the features manually. Applied to for-4.12/nuke-no-init-reports-quirk. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] HID: hiddev: move hiddev's minor number and refactoring
On Fri, 3 Mar 2017, Jaejoong Kim wrote: > Jaejoong Kim (2): > HID: cp2112: use proper hidraw name with minor number > HID: hiddev: reallocate hiddev's minor number Applied to for-4.12/hiddev. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] net: usb: mcs7830: use new api ethtool_{get|set}_link_ksettings
On 16.03.2017 23:18, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
>
> Signed-off-by: Philippe Reynes
> ---
> drivers/net/usb/mcs7830.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
> index 4f345bd..5771ff2 100644
> --- a/drivers/net/usb/mcs7830.c
> +++ b/drivers/net/usb/mcs7830.c
> @@ -464,9 +464,9 @@ static void mcs7830_get_regs(struct net_device *net,
> struct ethtool_regs *regs,
> .get_link = usbnet_get_link,
> .get_msglevel = usbnet_get_msglevel,
> .set_msglevel = usbnet_set_msglevel,
> - .get_settings = usbnet_get_settings,
> - .set_settings = usbnet_set_settings,
> .nway_reset = usbnet_nway_reset,
> + .get_link_ksettings = usbnet_get_link_ksettings,
> + .set_link_ksettings = usbnet_set_link_ksettings,
> };
>
> static const struct net_device_ops mcs7830_netdev_ops = {
>
$ modinfo mcs7830 usbnet mii -n
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/mcs7830.ko
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/usbnet.ko
/lib/modules/4.11.0-0.rc3.git0.1.fc26.x86_64/updates/mii.ko
$ lsmod | grep mcs7830
mcs783016384 0
usbnet 45056 1 mcs7830
mii16384 2 usbnet,mcs7830
$ nmcli -f GENERAL.DRIVER,GENERAL.STATE device show enp0s4f1u4
GENERAL.DRIVER: MOSCHIP usb-ethernet driver
GENERAL.STATE: 100 (connected)
Tested-by: poma
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/7] phylib MMD accessor cleanups
> Thanks. When I posted this last time around (19th Jan) I mentioned > about marking the old _indirect() accessors with __deprecated - is > that still something we want to do? > > I haven't tested this against net-next yet, so I don't know if there > are any new users of the indirect accessors - going down the deprecated > route would avoid breakage, but means having to submit a patch later to > actually remove them. > > How would people want this handled? Hi Russell We can get patches into net-next very quickly. So i suggest you rebase and resubmit and get it in. If something breaks, we add followup patches to fix it. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Tue, Mar 21, 2017 at 10:04 AM, Diego Viola wrote: > On Mon, Mar 20, 2017 at 8:15 PM, Diego Viola wrote: >> On Mon, Mar 20, 2017 at 3:27 PM, Diego Viola wrote: >>> On Mon, Mar 20, 2017 at 1:32 PM, Mathias Nyman >>> wrote: On 20.03.2017 17:39, Diego Viola wrote: > > On Mon, Mar 20, 2017 at 11:21 AM, Mathias Nyman > wrote: >> >> On 19.03.2017 23:29, Diego Viola wrote: >>> >>> Still a problem with 4.11.0-rc2-ARCH+ >> >> 4.11-rc2 has better xhci tracing, it shows each URB enqueue and dequeue >> and >> giveback. >> >> Could you try enabling xhci tracing before suspending (not the same as >> xhci >> verbose dynamic debug) >> It will generate a lot of data, so better to remove all extra USB >> devices. >> >> xhci tracing can be added with: >> >> mount -t debugfs none /sys/kernel/debug >> echo xhci-hcd >> /sys/kernel/debug/tracing/set_event >> >> and then send the output of cat /sys/kernel/debug/tracing/trace > > > https://bugzilla.kernel.org/attachment.cgi?id=255367 > > This is with Linux 4.11.0-rc3-ARCH. > > USB mouse/keyboard was unplugged before booting the machine. > > I didn't do a suspend/resume before getting this trace, should I do that? > > Should I reproduce the hang and get a netconsole dmesg capture with > tracing enabled? A trace and a dmesg of the same suspend/reusume hang would be great. >>> >>> I can capture the dmesg with netconsole once the machine hangs, but >>> I'm not sure how I could capture /sys/kernel/debug/tracing/trace after >>> the hang. I'm unable to use ssh after the hang. >>> And if you can then one of a succesful suspend/resume for reference. >>> >>> Here's the trace after a successful suspend/resume: >>> >>> https://bugzilla.kernel.org/attachment.cgi?id=255369 >>> (I haven't yet checked the one you added to bugzilla) -Mathias >>> >>> Diego >> >> ftrace_dump_on_oops is what I was looking for. >> >> Diego > > I tried ftrace_dump_on_oops but I can't see the trace coming in, not > sure what I'm doing wrong. :( > > Diego I was able to obtain the trace with this: hung_task_panic=1 no_console_suspend=1 ftrace_dump_on_oops Diego -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ohci-pci: add qemu quirk
On Mon, 20 Mar 2017, Gerd Hoffmann wrote:
> On a loaded virtualization host (dozen guests booting at the same time)
> it may happen that the ohci controller emulation doesn't manage to do
> timely frame processing, with the result that the io watchdog fires and
> considers the controller being dead, even though it's only the emulation
> being unusual slow due to the load peak.
>
> So, add a quirk for qemu and don't use the watchdog in case we figure we
> are running on emulated ohci. The virtual ohci controller masquerades
> as apple ohci controller, but we can identify it by subsystem id.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/usb/host/ohci-hcd.c | 3 ++-
> drivers/usb/host/ohci-pci.c | 16
> drivers/usb/host/ohci.h | 1 +
> 3 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index b6daf2e..5f81a2b 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -231,7 +231,8 @@ static int ohci_urb_enqueue (
>
> /* Start up the I/O watchdog timer, if it's not running */
> if (!timer_pending(&ohci->io_watchdog) &&
> - list_empty(&ohci->eds_in_use)) {
> + list_empty(&ohci->eds_in_use) &&
> + !(ohci->flags & OHCI_QUIRK_QEMU)) {
> ohci->prev_frame_no = ohci_frame_no(ohci);
> mod_timer(&ohci->io_watchdog,
> jiffies + IO_WATCHDOG_DELAY);
> diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
> index bb15096..a84aebe 100644
> --- a/drivers/usb/host/ohci-pci.c
> +++ b/drivers/usb/host/ohci-pci.c
> @@ -164,6 +164,15 @@ static int ohci_quirk_amd700(struct usb_hcd *hcd)
> return 0;
> }
>
> +static int ohci_quirk_qemu(struct usb_hcd *hcd)
> +{
> + struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> +
> + ohci->flags |= OHCI_QUIRK_QEMU;
> + ohci_dbg(ohci, "enabled qemu quirk\n");
> + return 0;
> +}
> +
> /* List of quirks for OHCI */
> static const struct pci_device_id ohci_pci_quirks[] = {
> {
> @@ -214,6 +223,13 @@ static int ohci_quirk_amd700(struct usb_hcd *hcd)
> PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
> .driver_data = (unsigned long)ohci_quirk_amd700,
> },
> + {
> + .vendor = PCI_VENDOR_ID_APPLE,
> + .device = 0x003f,
> + .subvendor = PCI_SUBVENDOR_ID_REDHAT_QUMRANET,
> + .subdevice = PCI_SUBDEVICE_ID_QEMU,
> + .driver_data= (unsigned long)ohci_quirk_qemu,
> + },
>
> /* FIXME for some of the early AMD 760 southbridges, OHCI
>* won't work at all. blacklist them.
> diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
> index 37f1725..a51b189 100644
> --- a/drivers/usb/host/ohci.h
> +++ b/drivers/usb/host/ohci.h
> @@ -418,6 +418,7 @@ struct ohci_hcd {
> #define OHCI_QUIRK_AMD_PLL 0x200 /* AMD PLL
> quirk*/
> #define OHCI_QUIRK_AMD_PREFETCH 0x400 /* pre-fetch
> for ISO transfer */
> #define OHCI_QUIRK_GLOBAL_SUSPEND 0x800 /* must suspend
> ports */
> +#define OHCI_QUIRK_QEMU 0x1000 /* relax timing
> expectations */
>
> // there are also chip quirks/bugs in init logic
Signed-off-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 2/7] net: phy: make phy_(read|write)_mmd() generic MMD accessors
Make phy_(read|write)_mmd() generic 802.3 clause 45 register accessors
for both Clause 22 and Clause 45 PHYs, using either the direct register
reading for Clause 45, or the indirect method for Clause 22 PHYs.
Allow this behaviour to be overriden by PHY drivers where necessary.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
---
drivers/net/phy/phy-core.c | 33 +
include/linux/phy.h| 24
2 files changed, 49 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index b8d8276a3099..d791100afab2 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -69,11 +69,18 @@ EXPORT_SYMBOL(phy_read_mmd_indirect);
*/
int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
{
- if (!phydev->is_c45)
- return -EOPNOTSUPP;
+ if (regnum > (u16)~0 || devad > 32)
+ return -EINVAL;
- return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr,
- MII_ADDR_C45 | (devad << 16) | (regnum & 0x));
+ if (phydev->drv->read_mmd)
+ return phydev->drv->read_mmd(phydev, devad, regnum);
+
+ if (phydev->is_c45) {
+ u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0x);
+ return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, addr);
+ }
+
+ return phy_read_mmd_indirect(phydev, regnum, devad);
}
EXPORT_SYMBOL(phy_read_mmd);
@@ -125,11 +132,21 @@ EXPORT_SYMBOL(phy_write_mmd_indirect);
*/
int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
{
- if (!phydev->is_c45)
- return -EOPNOTSUPP;
+ if (regnum > (u16)~0 || devad > 32)
+ return -EINVAL;
+
+ if (phydev->drv->read_mmd)
+ return phydev->drv->write_mmd(phydev, devad, regnum, val);
+
+ if (phydev->is_c45) {
+ u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0x);
+
+ return mdiobus_write(phydev->mdio.bus, phydev->mdio.addr,
+addr, val);
+ }
- regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0x);
+ phy_write_mmd_indirect(phydev, regnum, devad, val);
- return mdiobus_write(phydev->mdio.bus, phydev->mdio.addr, regnum, val);
+ return 0;
}
EXPORT_SYMBOL(phy_write_mmd);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index bcb4549b41d6..b8feeffeb64c 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -587,6 +587,30 @@ struct phy_driver {
*/
void (*link_change_notify)(struct phy_device *dev);
+ /*
+* Phy specific driver override for reading a MMD register.
+* This function is optional for PHY specific drivers. When
+* not provided, the default MMD read function will be used
+* by phy_read_mmd(), which will use either a direct read for
+* Clause 45 PHYs or an indirect read for Clause 22 PHYs.
+* devnum is the MMD device number within the PHY device,
+* regnum is the register within the selected MMD device.
+*/
+ int (*read_mmd)(struct phy_device *dev, int devnum, u16 regnum);
+
+ /*
+* Phy specific driver override for writing a MMD register.
+* This function is optional for PHY specific drivers. When
+* not provided, the default MMD write function will be used
+* by phy_write_mmd(), which will use either a direct write for
+* Clause 45 PHYs, or an indirect write for Clause 22 PHYs.
+* devnum is the MMD device number within the PHY device,
+* regnum is the register within the selected MMD device.
+* val is the value to be written.
+*/
+ int (*write_mmd)(struct phy_device *dev, int devnum, u16 regnum,
+u16 val);
+
/* A function provided by a phy specific driver to override the
* the PHY driver framework support for reading a MMD register
* from the PHY. If not supported, return -1. This function is
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 0/7] Clean up PHY MMD accessors
This series cleans up phylib's MMD accessors, so that we have a common way of accessing the Clause 45 register set. The current situation is far from ideal - we have phy_(read|write)_mmd() which accesses Clause 45 registers over Clause 45 accesses, and we have phy_(read|write)_mmd_indirect(), which accesses Clause 45 registers via Clause 22 register 13/14. Generic code uses the indirect methods to access standard Clause 45 features, and when we come to add Clause 45 PHY support to phylib, we would need to make these conditional upon the PHY type, or duplicate these functions. An alternative solution is to merge these accessors together, and select the appropriate access method depending upon the 802.3 clause that the PHY conforms with. The result is that we have a single set of phy_(read|write)_mmd() accessors. For cases which require special handling, we still allow PHY drivers to override all MMD accesses - except rather than just overriding the indirect accesses. This keeps existing overrides working. Combining the two also has another beneficial side effect - we get rid of similar functions that take arguments in different orders. The old direct accessors took the phy structure, devad and register number, whereas the indirect accessors took the phy structure, register number and devad in that order. Care must be taken when updating future drivers that the argument order is correct, and the function name is not merely replaced. This patch set is against net-next. drivers/net/phy/Makefile | 2 +- drivers/net/phy/bcm-phy-lib.c | 12 ++--- drivers/net/phy/dp83867.c | 25 +- drivers/net/phy/intel-xway.c | 26 +- drivers/net/phy/micrel.c | 13 +++-- drivers/net/phy/microchip.c | 5 +- drivers/net/phy/phy-core.c| 101 ++ drivers/net/phy/phy.c | 110 -- drivers/net/phy/phy_device.c | 4 +- drivers/net/usb/lan78xx.c | 10 ++-- include/linux/phy.h | 80 +- 11 files changed, 178 insertions(+), 210 deletions(-) RFC->v1: - minor update patch 2 to resolve a build error that the 0-day builder discovered. - reviewed-by / acked-bys added -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 5/7] net: phy: convert micrel to new read_mmd/write_mmd driver methods
Convert micrel to the new read_mmd/write_mmd driver methods. This
Clause 22 PHY does not support any MMD access method.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
---
drivers/net/phy/micrel.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 6742070ca676..b847184de6fc 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -637,8 +637,7 @@ static int ksz8873mll_config_aneg(struct phy_device *phydev)
* MMD extended PHY registers.
*/
static int
-ksz9021_rd_mmd_phyreg(struct phy_device *phydev, int ptrad, int devnum,
- int regnum)
+ksz9021_rd_mmd_phyreg(struct phy_device *phydev, int devad, u16 regnum)
{
return -1;
}
@@ -646,10 +645,10 @@ ksz9021_rd_mmd_phyreg(struct phy_device *phydev, int
ptrad, int devnum,
/* This routine does nothing since the Micrel ksz9021 does not support
* standard IEEE MMD extended PHY registers.
*/
-static void
-ksz9021_wr_mmd_phyreg(struct phy_device *phydev, int ptrad, int devnum,
- int regnum, u32 val)
+static int
+ksz9021_wr_mmd_phyreg(struct phy_device *phydev, int devad, u16 regnum, u16
val)
{
+ return -1;
}
static int kszphy_get_sset_count(struct phy_device *phydev)
@@ -962,8 +961,8 @@ static struct phy_driver ksphy_driver[] = {
.get_stats = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
- .read_mmd_indirect = ksz9021_rd_mmd_phyreg,
- .write_mmd_indirect = ksz9021_wr_mmd_phyreg,
+ .read_mmd = ksz9021_rd_mmd_phyreg,
+ .write_mmd = ksz9021_wr_mmd_phyreg,
}, {
.phy_id = PHY_ID_KSZ9031,
.phy_id_mask= MICREL_PHY_ID_MASK,
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 3/7] net: lan78xx: update for phy_(read|write)_mmd_indirect() removal
lan78xx appears to use phylib in a rather weird way, accessing the PHY partly through phylib, and partly by making direct accesses to it, including to the Clause 45 registers. As the indirect MMD accessors are going away, update this driver to use the plain phy_(read|write)_mmd() accessors instead. Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Acked-by: Woojung Huh Signed-off-by: Russell King --- drivers/net/usb/lan78xx.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c index 9889a70ff4f6..d885e0325422 100644 --- a/drivers/net/usb/lan78xx.c +++ b/drivers/net/usb/lan78xx.c @@ -1952,10 +1952,10 @@ static int lan8835_fixup(struct phy_device *phydev) struct lan78xx_net *dev = netdev_priv(phydev->attached_dev); /* LED2/PME_N/IRQ_N/RGMII_ID pin to IRQ_N mode */ - buf = phy_read_mmd_indirect(phydev, 0x8010, 3); + buf = phy_read_mmd(phydev, MDIO_MMD_PCS, 0x8010); buf &= ~0x1800; buf |= 0x0800; - phy_write_mmd_indirect(phydev, 0x8010, 3, buf); + phy_write_mmd(phydev, MDIO_MMD_PCS, 0x8010, buf); /* RGMII MAC TXC Delay Enable */ ret = lan78xx_write_reg(dev, MAC_RGMII_ID, @@ -1975,11 +1975,11 @@ static int ksz9031rnx_fixup(struct phy_device *phydev) /* Micrel9301RNX PHY configuration */ /* RGMII Control Signal Pad Skew */ - phy_write_mmd_indirect(phydev, 4, 2, 0x0077); + phy_write_mmd(phydev, MDIO_MMD_WIS, 4, 0x0077); /* RGMII RX Data Pad Skew */ - phy_write_mmd_indirect(phydev, 5, 2, 0x); + phy_write_mmd(phydev, MDIO_MMD_WIS, 5, 0x); /* RGMII RX Clock Pad Skew */ - phy_write_mmd_indirect(phydev, 8, 2, 0x1FF); + phy_write_mmd(phydev, MDIO_MMD_WIS, 8, 0x1FF); dev->interface = PHY_INTERFACE_MODE_RGMII_RXID; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/7] net: phy: move phy MMD accessors to phy-core.c
Move the phy_(read|write)__mmd() helpers out of line, they will become
our main MMD accessor functions, and so will be a little more complex.
This complexity doesn't belong in an inline function. Also move the
_indirect variants as well to keep like functionality together.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
---
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/phy-core.c | 135 +
drivers/net/phy/phy.c | 85
include/linux/phy.h| 20 +--
4 files changed, 138 insertions(+), 104 deletions(-)
create mode 100644 drivers/net/phy/phy-core.c
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 407b0b601ea8..82d915614646 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -1,7 +1,7 @@
# Makefile for Linux PHY drivers and MDIO bus drivers
libphy-y := phy.o phy_device.o mdio_bus.o mdio_device.o \
- mdio-boardinfo.o
+ mdio-boardinfo.o phy-core.o
libphy-$(CONFIG_SWPHY) += swphy.o
libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
new file mode 100644
index ..b8d8276a3099
--- /dev/null
+++ b/drivers/net/phy/phy-core.c
@@ -0,0 +1,135 @@
+/*
+ * Core PHY library, taken from phy.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include
+#include
+
+static inline void mmd_phy_indirect(struct mii_bus *bus, int prtad, int devad,
+ int addr)
+{
+ /* Write the desired MMD Devad */
+ bus->write(bus, addr, MII_MMD_CTRL, devad);
+
+ /* Write the desired MMD register address */
+ bus->write(bus, addr, MII_MMD_DATA, prtad);
+
+ /* Select the Function : DATA with no post increment */
+ bus->write(bus, addr, MII_MMD_CTRL, (devad | MII_MMD_CTRL_NOINCR));
+}
+
+/**
+ * phy_read_mmd_indirect - reads data from the MMD registers
+ * @phydev: The PHY device bus
+ * @prtad: MMD Address
+ * @devad: MMD DEVAD
+ *
+ * Description: it reads data from the MMD registers (clause 22 to access to
+ * clause 45) of the specified phy address.
+ * To read these register we have:
+ * 1) Write reg 13 // DEVAD
+ * 2) Write reg 14 // MMD Address
+ * 3) Write reg 13 // MMD Data Command for MMD DEVAD
+ * 3) Read reg 14 // Read MMD data
+ */
+int phy_read_mmd_indirect(struct phy_device *phydev, int prtad, int devad)
+{
+ struct phy_driver *phydrv = phydev->drv;
+ int addr = phydev->mdio.addr;
+ int value = -1;
+
+ if (!phydrv->read_mmd_indirect) {
+ struct mii_bus *bus = phydev->mdio.bus;
+
+ mutex_lock(&bus->mdio_lock);
+ mmd_phy_indirect(bus, prtad, devad, addr);
+
+ /* Read the content of the MMD's selected register */
+ value = bus->read(bus, addr, MII_MMD_DATA);
+ mutex_unlock(&bus->mdio_lock);
+ } else {
+ value = phydrv->read_mmd_indirect(phydev, prtad, devad, addr);
+ }
+ return value;
+}
+EXPORT_SYMBOL(phy_read_mmd_indirect);
+
+/**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
+{
+ if (!phydev->is_c45)
+ return -EOPNOTSUPP;
+
+ return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr,
+ MII_ADDR_C45 | (devad << 16) | (regnum & 0x));
+}
+EXPORT_SYMBOL(phy_read_mmd);
+
+/**
+ * phy_write_mmd_indirect - writes data to the MMD registers
+ * @phydev: The PHY device
+ * @prtad: MMD Address
+ * @devad: MMD DEVAD
+ * @data: data to write in the MMD register
+ *
+ * Description: Write data from the MMD registers of the specified
+ * phy address.
+ * To write these register we have:
+ * 1) Write reg 13 // DEVAD
+ * 2) Write reg 14 // MMD Address
+ * 3) Write reg 13 // MMD Data Command for MMD DEVAD
+ * 3) Write reg 14 // Write MMD data
+ */
+void phy_write_mmd_indirect(struct phy_device *phydev, int prtad,
+ int devad, u32 data)
+{
+ struct phy_driver *phydrv = phydev->drv;
+ int addr = phydev->mdio.addr;
+
+ if (!phydrv->write_mmd_indirect) {
+ struct mii_bus *bus = phydev->mdio.bus;
+
+ mutex_lock(&bus->mdio_lock);
+ mmd_phy_indirect(bus, prtad, devad, addr);
+
+ /* Write the data into MMD's selected register */
+
[PATCH net-next 4/7] net: phy: switch remaining users to phy_(read|write)_mmd()
Switch everyone over to using phy_read_mmd() and phy_write_mmd() now
that they are able to handle both Clause 22 indirect addressing and
Clause 45 direct addressing methods to the MMD registers.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
---
drivers/net/phy/bcm-phy-lib.c | 12
drivers/net/phy/dp83867.c | 25 +++--
drivers/net/phy/intel-xway.c | 26 +-
drivers/net/phy/microchip.c | 5 ++---
drivers/net/phy/phy.c | 25 ++---
drivers/net/phy/phy_device.c | 4 ++--
6 files changed, 42 insertions(+), 55 deletions(-)
diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/bcm-phy-lib.c
index 9656dbeb5de5..171010eb4d9c 100644
--- a/drivers/net/phy/bcm-phy-lib.c
+++ b/drivers/net/phy/bcm-phy-lib.c
@@ -201,8 +201,7 @@ int bcm_phy_set_eee(struct phy_device *phydev, bool enable)
int val;
/* Enable EEE at PHY level */
- val = phy_read_mmd_indirect(phydev, BRCM_CL45VEN_EEE_CONTROL,
- MDIO_MMD_AN);
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL);
if (val < 0)
return val;
@@ -211,12 +210,10 @@ int bcm_phy_set_eee(struct phy_device *phydev, bool
enable)
else
val &= ~(LPI_FEATURE_EN | LPI_FEATURE_EN_DIG1000X);
- phy_write_mmd_indirect(phydev, BRCM_CL45VEN_EEE_CONTROL,
- MDIO_MMD_AN, (u32)val);
+ phy_write_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL, (u32)val);
/* Advertise EEE */
- val = phy_read_mmd_indirect(phydev, BCM_CL45VEN_EEE_ADV,
- MDIO_MMD_AN);
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV);
if (val < 0)
return val;
@@ -225,8 +222,7 @@ int bcm_phy_set_eee(struct phy_device *phydev, bool enable)
else
val &= ~(MDIO_EEE_100TX | MDIO_EEE_1000T);
- phy_write_mmd_indirect(phydev, BCM_CL45VEN_EEE_ADV,
- MDIO_MMD_AN, (u32)val);
+ phy_write_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV, (u32)val);
return 0;
}
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 19865530e0b1..b57f20e552ba 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -133,14 +133,14 @@ static int dp83867_config_port_mirroring(struct
phy_device *phydev)
(struct dp83867_private *)phydev->priv;
u16 val;
- val = phy_read_mmd_indirect(phydev, DP83867_CFG4, DP83867_DEVADDR);
+ val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4);
if (dp83867->port_mirroring == DP83867_PORT_MIRROING_EN)
val |= DP83867_CFG4_PORT_MIRROR_EN;
else
val &= ~DP83867_CFG4_PORT_MIRROR_EN;
- phy_write_mmd_indirect(phydev, DP83867_CFG4, DP83867_DEVADDR, val);
+ phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4, val);
return 0;
}
@@ -231,8 +231,7 @@ static int dp83867_config_init(struct phy_device *phydev)
* register's bit 11 (marked as RESERVED).
*/
- bs = phy_read_mmd_indirect(phydev, DP83867_STRAP_STS1,
- DP83867_DEVADDR);
+ bs = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_STRAP_STS1);
if (bs & DP83867_STRAP_STS1_RESERVED)
val &= ~DP83867_PHYCR_RESERVED_MASK;
@@ -243,8 +242,7 @@ static int dp83867_config_init(struct phy_device *phydev)
if ((phydev->interface >= PHY_INTERFACE_MODE_RGMII_ID) &&
(phydev->interface <= PHY_INTERFACE_MODE_RGMII_RXID)) {
- val = phy_read_mmd_indirect(phydev, DP83867_RGMIICTL,
- DP83867_DEVADDR);
+ val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL);
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
val |= (DP83867_RGMII_TX_CLK_DELAY_EN |
DP83867_RGMII_RX_CLK_DELAY_EN);
@@ -255,25 +253,24 @@ static int dp83867_config_init(struct phy_device *phydev)
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
val |= DP83867_RGMII_RX_CLK_DELAY_EN;
- phy_write_mmd_indirect(phydev, DP83867_RGMIICTL,
- DP83867_DEVADDR, val);
+ phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIICTL, val);
delay = (dp83867->rx_id_delay |
(dp83867->tx_id_delay <<
DP83867_RGMII_TX_CLK_DELAY_SHIFT));
- phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
- DP83867_DEVADDR, delay);
+ phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIIDCTL,
+ delay);
if (dp83867->io_impedance >= 0) {
-
[PATCH net-next 7/7] net: phy: clean up mmd_phy_indirect()
Make mmd_phy_indirect() use the same terminology as the rest of the
code, making clear what each address is - phy address, devad, and
register number.
While here, remove the "inline" from this static function, leaving
it to the compiler to decide whether to inline this function, and
get rid of unnecessary parens.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
---
drivers/net/phy/phy-core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 80795ccd3fab..357a4d0d7641 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -9,17 +9,17 @@
#include
#include
-static inline void mmd_phy_indirect(struct mii_bus *bus, int prtad, int devad,
- int addr)
+static void mmd_phy_indirect(struct mii_bus *bus, int phy_addr, int devad,
+u16 regnum)
{
/* Write the desired MMD Devad */
- bus->write(bus, addr, MII_MMD_CTRL, devad);
+ bus->write(bus, phy_addr, MII_MMD_CTRL, devad);
/* Write the desired MMD register address */
- bus->write(bus, addr, MII_MMD_DATA, prtad);
+ bus->write(bus, phy_addr, MII_MMD_DATA, regnum);
/* Select the Function : DATA with no post increment */
- bus->write(bus, addr, MII_MMD_CTRL, (devad | MII_MMD_CTRL_NOINCR));
+ bus->write(bus, phy_addr, MII_MMD_CTRL, devad | MII_MMD_CTRL_NOINCR);
}
/**
@@ -49,7 +49,7 @@ int phy_read_mmd(struct phy_device *phydev, int devad, u32
regnum)
int phy_addr = phydev->mdio.addr;
mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, regnum, devad, phy_addr);
+ mmd_phy_indirect(bus, phy_addr, devad, regnum);
/* Read the content of the MMD's selected register */
val = bus->read(bus, phy_addr, MII_MMD_DATA);
@@ -88,7 +88,7 @@ int phy_write_mmd(struct phy_device *phydev, int devad, u32
regnum, u16 val)
int phy_addr = phydev->mdio.addr;
mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, regnum, devad, phy_addr);
+ mmd_phy_indirect(bus, phy_addr, devad, regnum);
/* Write the data into MMD's selected register */
bus->write(bus, phy_addr, MII_MMD_DATA, val);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 6/7] net: phy: remove the indirect MMD read/write methods
Remove the indirect MMD read/write methods which are now no longer
necessary.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Russell King
---
drivers/net/phy/phy-core.c | 119 +
include/linux/phy.h| 42
2 files changed, 34 insertions(+), 127 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index d791100afab2..80795ccd3fab 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -23,102 +23,41 @@ static inline void mmd_phy_indirect(struct mii_bus *bus,
int prtad, int devad,
}
/**
- * phy_read_mmd_indirect - reads data from the MMD registers
- * @phydev: The PHY device bus
- * @prtad: MMD Address
- * @devad: MMD DEVAD
- *
- * Description: it reads data from the MMD registers (clause 22 to access to
- * clause 45) of the specified phy address.
- * To read these register we have:
- * 1) Write reg 13 // DEVAD
- * 2) Write reg 14 // MMD Address
- * 3) Write reg 13 // MMD Data Command for MMD DEVAD
- * 3) Read reg 14 // Read MMD data
- */
-int phy_read_mmd_indirect(struct phy_device *phydev, int prtad, int devad)
-{
- struct phy_driver *phydrv = phydev->drv;
- int addr = phydev->mdio.addr;
- int value = -1;
-
- if (!phydrv->read_mmd_indirect) {
- struct mii_bus *bus = phydev->mdio.bus;
-
- mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, prtad, devad, addr);
-
- /* Read the content of the MMD's selected register */
- value = bus->read(bus, addr, MII_MMD_DATA);
- mutex_unlock(&bus->mdio_lock);
- } else {
- value = phydrv->read_mmd_indirect(phydev, prtad, devad, addr);
- }
- return value;
-}
-EXPORT_SYMBOL(phy_read_mmd_indirect);
-
-/**
* phy_read_mmd - Convenience function for reading a register
* from an MMD on a given PHY.
* @phydev: The phy_device struct
- * @devad: The MMD to read from
- * @regnum: The register on the MMD to read
+ * @devad: The MMD to read from (0..31)
+ * @regnum: The register on the MMD to read (0..65535)
*
* Same rules as for phy_read();
*/
int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
{
+ int val;
+
if (regnum > (u16)~0 || devad > 32)
return -EINVAL;
- if (phydev->drv->read_mmd)
- return phydev->drv->read_mmd(phydev, devad, regnum);
-
- if (phydev->is_c45) {
+ if (phydev->drv->read_mmd) {
+ val = phydev->drv->read_mmd(phydev, devad, regnum);
+ } else if (phydev->is_c45) {
u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0x);
- return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, addr);
- }
- return phy_read_mmd_indirect(phydev, regnum, devad);
-}
-EXPORT_SYMBOL(phy_read_mmd);
-
-/**
- * phy_write_mmd_indirect - writes data to the MMD registers
- * @phydev: The PHY device
- * @prtad: MMD Address
- * @devad: MMD DEVAD
- * @data: data to write in the MMD register
- *
- * Description: Write data from the MMD registers of the specified
- * phy address.
- * To write these register we have:
- * 1) Write reg 13 // DEVAD
- * 2) Write reg 14 // MMD Address
- * 3) Write reg 13 // MMD Data Command for MMD DEVAD
- * 3) Write reg 14 // Write MMD data
- */
-void phy_write_mmd_indirect(struct phy_device *phydev, int prtad,
- int devad, u32 data)
-{
- struct phy_driver *phydrv = phydev->drv;
- int addr = phydev->mdio.addr;
-
- if (!phydrv->write_mmd_indirect) {
+ val = mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, addr);
+ } else {
struct mii_bus *bus = phydev->mdio.bus;
+ int phy_addr = phydev->mdio.addr;
mutex_lock(&bus->mdio_lock);
- mmd_phy_indirect(bus, prtad, devad, addr);
+ mmd_phy_indirect(bus, regnum, devad, phy_addr);
- /* Write the data into MMD's selected register */
- bus->write(bus, addr, MII_MMD_DATA, data);
+ /* Read the content of the MMD's selected register */
+ val = bus->read(bus, phy_addr, MII_MMD_DATA);
mutex_unlock(&bus->mdio_lock);
- } else {
- phydrv->write_mmd_indirect(phydev, prtad, devad, addr, data);
}
+ return val;
}
-EXPORT_SYMBOL(phy_write_mmd_indirect);
+EXPORT_SYMBOL(phy_read_mmd);
/**
* phy_write_mmd - Convenience function for writing a register
@@ -132,21 +71,31 @@ EXPORT_SYMBOL(phy_write_mmd_indirect);
*/
int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
{
+ int ret;
+
if (regnum > (u16)~0 || devad > 32)
return -EINVAL;
- if (phydev->drv->read_mmd)
- return phydev->drv->write_mmd(phydev, devad, regnum, val);
-
- if (phydev->is_c45) {
+ if (phydev->dr
Re: [PATCH net] r8152: fix the list rx_done may be used without initialization
From: Hayes Wang Date: Tue, 14 Mar 2017 14:15:20 +0800 > The list rx_done would be initialized when the linking on occurs. > Therefore, if a napi is scheduled without any linking on before, > the following kernel panic would happen. > > BUG: unable to handle kernel NULL pointer dereference at 008 > IP: [] r8152_poll+0xe1e/0x1210 [r8152] > PGD 0 > Oops: 0002 [#1] SMP > > Signed-off-by: Hayes Wang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Tue, Mar 21, 2017 at 12:29 PM, Diego Viola wrote: > On Tue, Mar 21, 2017 at 10:04 AM, Diego Viola wrote: >> On Mon, Mar 20, 2017 at 8:15 PM, Diego Viola wrote: >>> On Mon, Mar 20, 2017 at 3:27 PM, Diego Viola wrote: On Mon, Mar 20, 2017 at 1:32 PM, Mathias Nyman wrote: > On 20.03.2017 17:39, Diego Viola wrote: >> >> On Mon, Mar 20, 2017 at 11:21 AM, Mathias Nyman >> wrote: >>> >>> On 19.03.2017 23:29, Diego Viola wrote: > > Still a problem with 4.11.0-rc2-ARCH+ >>> >>> 4.11-rc2 has better xhci tracing, it shows each URB enqueue and dequeue >>> and >>> giveback. >>> >>> Could you try enabling xhci tracing before suspending (not the same as >>> xhci >>> verbose dynamic debug) >>> It will generate a lot of data, so better to remove all extra USB >>> devices. >>> >>> xhci tracing can be added with: >>> >>> mount -t debugfs none /sys/kernel/debug >>> echo xhci-hcd >> /sys/kernel/debug/tracing/set_event >>> >>> and then send the output of cat /sys/kernel/debug/tracing/trace >> >> >> https://bugzilla.kernel.org/attachment.cgi?id=255367 >> >> This is with Linux 4.11.0-rc3-ARCH. >> >> USB mouse/keyboard was unplugged before booting the machine. >> >> I didn't do a suspend/resume before getting this trace, should I do that? >> >> Should I reproduce the hang and get a netconsole dmesg capture with >> tracing enabled? > > > A trace and a dmesg of the same suspend/reusume hang would be great. I can capture the dmesg with netconsole once the machine hangs, but I'm not sure how I could capture /sys/kernel/debug/tracing/trace after the hang. I'm unable to use ssh after the hang. > And if you can then one of a succesful suspend/resume for reference. Here's the trace after a successful suspend/resume: https://bugzilla.kernel.org/attachment.cgi?id=255369 > > (I haven't yet checked the one you added to bugzilla) > > -Mathias Diego >>> >>> ftrace_dump_on_oops is what I was looking for. >>> >>> Diego >> >> I tried ftrace_dump_on_oops but I can't see the trace coming in, not >> sure what I'm doing wrong. :( >> >> Diego > > I was able to obtain the trace with this: hung_task_panic=1 > no_console_suspend=1 ftrace_dump_on_oops > > Diego Here's the log I was able to obtain today, dmesg + ftrace at the time of the crash: https://bugzilla.kernel.org/attachment.cgi?id=255419 USB keyboard and mouse was plugged when I reproduced this. Please let me know if you need more info. Diego -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] net: usbnet: move to new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes
Date: Thu, 16 Mar 2017 23:18:46 +0100
> The ethtool api {get|set}_settings is deprecated. On usbnet, it
> was often implemented with usbnet_{get|set}_settings.
>
> In this serie, I add usbnet_{get|set}_link_ksettings
> in the first patch, then I update all the driver to
> use this new api, and in the last patch I remove the
> old api usbnet_{get|set}_settings.
Series applied, thanks Philippe.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] net: usb: usbnet: add new api ethtool_{get|set}_link_ksettings
From: Oliver Neukum
Date: Tue, 21 Mar 2017 12:33:03 +0100
> Am Donnerstag, den 16.03.2017, 23:18 +0100 schrieb Philippe Reynes:
>> The ethtool api {get|set}_settings is deprecated.
>> We add the new api {get|set}_link_ksettings to this driver.
>>
>> As I don't have the hardware, I'd be very pleased if
>> someone may test this patch.
>>
>
> Unfortunately I lack hardware to test.
> Phillipe and I had a patch collision. David, please take his
> patch for the next merge window. It looks good and is comprehensive and
> nobody has reported issues. We will never find testers for all those
> drivers on this list.
Ok.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] r8152: check hw version first
From: Hayes Wang Date: Fri, 17 Mar 2017 11:20:13 +0800 > Check hw version first in probe(). Do nothing if the driver doesn't > support the chip. > > Signed-off-by: Hayes Wang Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net,stable] qmi_wwan: add Dell DW5811e
From: Bjørn Mork
Date: Fri, 17 Mar 2017 17:20:48 +0100
> This is a Dell branded Sierra Wireless EM7455. It is operating in
> MBIM mode by default, but can be configured to provide two QMI/RMNET
> functions.
>
> Signed-off-by: Bjørn Mork
> ---
> Note regarding stable backports:
>
> This device should only be added to v4.5 and later. It depends on
> commit 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
> which has not been backported AFAIK.
Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phy: cpcap-usb: Add CPCAP PMIC USB support
Hi, On Thu, Mar 16, 2017 at 08:51:52PM -0700, Tony Lindgren wrote: > Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a > multiplexing USB PHY. > > This USB PHY can operate at least in four modes using pin multiplexing > and two control GPIOS: > > - Pass through companion PHY for the SoC USB PHY > - ULPI PHY for the SoC > - Pass through USB for the modem > - UART debug console for the SoC > > This patch adds support for droid 4 USB PHY and debug UART modes, > support for other modes can be added later on as needed. > > Both peripheral and host mode are working for the USB. The > host mode depends on the cpcap-charger driver for VBUS. > > VBUS and ID pin detection are done using cpcap-adc IIO ADC > driver. I tested UART, USB slave (cdc-ether) & USB host (keyboard & touchpad from Atrix lapdock) mode with Droid 4: Tested-by: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature
Re: [PATCH v8 0/5] usb: early: add support for early printk through USB3 debug port
Hi, On 03/21/2017 07:33 PM, Ingo Molnar wrote: >> Lu Baolu (5): >> > x86: add simple udelay calibration >> > usb: early: add driver for xhci debug capability >> > x86: add support for earlyprintk via USB3 debug port >> > usb: serial: add dbc debug device support to usb_debug >> > usb: doc: add document for USB3 debug port usage >> > >> > Documentation/admin-guide/kernel-parameters.txt |1 + >> > Documentation/usb/usb3-debug-port.rst | 100 +++ >> > arch/x86/Kconfig.debug | 23 + >> > arch/x86/kernel/early_printk.c |5 + >> > arch/x86/kernel/setup.c | 26 + >> > drivers/usb/Makefile|2 +- >> > drivers/usb/early/Makefile |1 + >> > drivers/usb/early/xhci-dbc.c| 1014 >> > +++ >> > drivers/usb/early/xhci-dbc.h| 211 + >> > drivers/usb/serial/usb_debug.c | 28 +- >> > include/linux/usb/xhci-dbgp.h | 29 + >> > 11 files changed, 1436 insertions(+), 4 deletions(-) >> > create mode 100644 Documentation/usb/usb3-debug-port.rst >> > create mode 100644 drivers/usb/early/xhci-dbc.c >> > create mode 100644 drivers/usb/early/xhci-dbc.h >> > create mode 100644 include/linux/usb/xhci-dbgp.h > Ok, this has now become a high quality series with picture-perfect patches > AFAICS. > > Thomas also gave his Acked-by to all the patches. > > I've applied them locally to -tip (it appears the USB maintainers are still > fine > with this being carried in tip:x86/debug for a v4.12 merge, right?), and will > push > them out and will propagate them to linux-next as well if they pass testing. > > Thanks for the great work! Thank you! Best regards, Lu Baolu -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM
Hi,
On 21 March 2017 at 16:07, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
I don't yet understand why we can't just keep runtime pm disabled as a
default for xhci platform devices.
It could be enabled by whatever creates the platform device by setting some
device property
(or equivalent), which would be checked in xhci_plat_probe() before
enabling
runtime pm. It
could then optionally be set in sysfs via power/control entry.
>>>
>>> I think runtime pm is not one hardware property, is it suitable if we
>>> introduce one device property to enable/disable runtime pm?
>>
>> As I said, runtime pm is not one hardware property, I think it is not
>> suitable if we introduce one device property to enable/disable runtime
>> pm.
>
> we already this functionality exposed on sysfs.
>From my understanding, Mathias suggested me to add one device property
(name like "usb-host-runtimePM") by platform_device_add_properties()
to enable/disable runtime PM when creating platform device, like
usb3_lpm_capable:
if (dwc->usb3_lpm_capable)
props[prop_idx++].name = "usb3-lpm-capable";
ret = platform_device_add_properties(xhci, props);
if (ret) {
dev_err(dwc->dev, "failed to add properties to xHCI\n");
goto err1;
}
What I think It is not suitable to introduce one device property like
above to enable/disable runtime PM, it is not one hardware attribute.
>
>> Secondly, we only can resume the xhci platform device by getting the
>> xhci usage counter from gadget driver, since the cable plug in/out
>> events only can be notified to glue layer of gadget driver(like dwc3
>> glue layer). That means if we want to suspend xhci platform device, we
>
> this is a problem with the glue layer, IMO. It should be something like
> so:
>
> static irqreturn_t dwc3_foobar_wakeup(int irq, void *_glue)
> {
> struct dwc3_foobar_glue *glue = _glue;
> u32 reg;
>
> reg = real(glue->base, OFFSET);
> if (reg & CONNECT)
> pm_runtime_resume(&glue->dwc3);
>
> return IRQ_HANDLED;
> }
>
> then dwc3's ->runtime_resume() should check if the event is supposed to
> be handled by host or peripheral by checking which mode it was before
> suspend and making the assumption that we don't change modes while
> suspended. Something like:
>
> static int dwc3_runtime_resume(struct device *dev)
> {
> struct dwc3 *dwc = dev_get_drvdata(dev);
>
> [...]
>
> if (dwc->is_host)
> pm_runtime_resume(dwc->xhci.dev);
>
> [...]
>
> return 0;
> }
Yeah, if we don't need to get xhci usage counter in xhci_plat_probe()
to avoid affecting other controller's runtime PM, we can do like this
and do not need to get/put counter.
>> must put xhci usage counter (so we can not keep their parent-child
>> relationship intact). That is why we need
>> pm_suspend_ignore_children(dev, true).
>
> you really shouldn't need that and it's still unclear why you think you
> do.
>
> --
> balbi
--
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
FW: Re: [PATCH v4] USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
Greg, hope you had not faced any issue (tab converted to spaces) with this
patch.
In case still facing any issue please let me know.
> There is race condition when two USB class drivers try to call
> init_usb_class at the same time and leads to crash.
> code path: probe->usb_register_dev->init_usb_class
>
> To solve this, mutex locking has been added in init_usb_class() and
> destroy_usb_class().
>
> As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class()
> because usb_class can never be NULL there.
Signed-off-by: Ajay Kaher
Acked-by: Alan Stern
---
drivers/usb/core/file.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..422ce7b 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
#define MAX_USB_MINORS 256
static const struct file_operations *usb_minors[MAX_USB_MINORS];
static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);
static int usb_open(struct inode *inode, struct file *file)
{
@@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)
static void destroy_usb_class(void)
{
- if (usb_class)
- kref_put(&usb_class->kref, release_usb_class);
+ mutex_lock(&init_usb_class_mutex);
+ kref_put(&usb_class->kref, release_usb_class);
+ mutex_unlock(&init_usb_class_mutex);
}
int usb_major_init(void)
@@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
if (intf->minor >= 0)
return -EADDRINUSE;
+ mutex_lock(&init_usb_class_mutex);
retval = init_usb_class();
+ mutex_unlock(&init_usb_class_mutex);
+
if (retval)
return retval;
--
1.7.9.5
Re: [kbuild-all] [PATCH 1/2] usb: phy: Introduce one extcon device into usb phy
On 03/20, Baolin Wang wrote: >Hi, > > >On 19 March 2017 at 19:42, kbuild test robot wrote: >> Hi Baolin, >> >> [auto build test ERROR on balbi-usb/next] >> [also build test ERROR on v4.11-rc2 next-20170310] >> [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/commits/Baolin-Wang/usb-phy-Introduce-one-extcon-device-into-usb-phy/20170319-175509 >> base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next >> config: i386-randconfig-i1-201712 (attached as .config) >> compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4 >> reproduce: >> # save the attached .config to linux build tree >> make ARCH=i386 >> >> All errors (new ones prefixed by >>): >> >>drivers/built-in.o: In function `usb_add_extcon': phy.c:(.text+0x231580): undefined reference to `extcon_get_edev_by_phandle' phy.c:(.text+0x2315d0): undefined reference to `devm_extcon_register_notifier' >>phy.c:(.text+0x231629): undefined reference to >> `devm_extcon_register_notifier' > >I am not sure how the errors were happened, since we will always >select EXTCON if we have selected USB_PHY, moreover we have included Hmm, this was a random config test and CONFIG_EXTCON was set as 'm', maybe you need to specify the dependency between CONFIG_USB_PHY and CONFIG_EXTCON ? Thanks, Xiaolong >the "linux/extcon.h" in phy.h file. > >-- >Baolin.wang >Best Regards >___ >kbuild-all mailing list >kbuild-...@lists.01.org >https://lists.01.org/mailman/listinfo/kbuild-all -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kbuild-all] [PATCH 1/2] usb: phy: Introduce one extcon device into usb phy
Hi, On 22 March 2017 at 14:32, Ye Xiaolong wrote: > On 03/20, Baolin Wang wrote: >>Hi, >> >> >>On 19 March 2017 at 19:42, kbuild test robot wrote: >>> Hi Baolin, >>> >>> [auto build test ERROR on balbi-usb/next] >>> [also build test ERROR on v4.11-rc2 next-20170310] >>> [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/commits/Baolin-Wang/usb-phy-Introduce-one-extcon-device-into-usb-phy/20170319-175509 >>> base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next >>> config: i386-randconfig-i1-201712 (attached as .config) >>> compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4 >>> reproduce: >>> # save the attached .config to linux build tree >>> make ARCH=i386 >>> >>> All errors (new ones prefixed by >>): >>> >>>drivers/built-in.o: In function `usb_add_extcon': > phy.c:(.text+0x231580): undefined reference to > `extcon_get_edev_by_phandle' > phy.c:(.text+0x2315d0): undefined reference to > `devm_extcon_register_notifier' >>>phy.c:(.text+0x231629): undefined reference to >>> `devm_extcon_register_notifier' >> >>I am not sure how the errors were happened, since we will always >>select EXTCON if we have selected USB_PHY, moreover we have included > > Hmm, this was a random config test and CONFIG_EXTCON was set as 'm', maybe you > need to specify the dependency between CONFIG_USB_PHY and CONFIG_EXTCON ? OK, I see. Thanks. -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
