[PATCH 1/1] usb: typec: tcpm: fix logbuffer index is wrong if _tcpm_log is re-entered
The port->logbuffer_head may be wrong if the two processes enters
_tcpm_log at the mostly same time. The 2nd process enters _tcpm_log
before the 1st process update the index, then the 2nd process will
not allocate logbuffer, when the 2nd process tries to use log buffer,
the index has already updated by the 1st process, so it will get
NULL pointer for updated logbuffer, the error message like below:
tcpci 0-0050: Log buffer index 6 is NULL
Cc: Heikki Krogerus
Cc: Guenter Roeck
Cc: Jun Li
Signed-off-by: Peter Chen
---
drivers/usb/typec/tcpm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 0ccd2ce1eb59..2ed07d0bf364 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -418,17 +418,18 @@ static void _tcpm_log(struct tcpm_port *port, const char
*fmt, va_list args)
u64 ts_nsec = local_clock();
unsigned long rem_nsec;
+ mutex_lock(>logbuffer_lock);
if (!port->logbuffer[port->logbuffer_head]) {
port->logbuffer[port->logbuffer_head] =
kzalloc(LOG_BUFFER_ENTRY_SIZE, GFP_KERNEL);
- if (!port->logbuffer[port->logbuffer_head])
+ if (!port->logbuffer[port->logbuffer_head]) {
+ mutex_unlock(>logbuffer_lock);
return;
+ }
}
vsnprintf(tmpbuffer, sizeof(tmpbuffer), fmt, args);
- mutex_lock(>logbuffer_lock);
-
if (tcpm_log_full(port)) {
port->logbuffer_head = max(port->logbuffer_head - 1, 0);
strcpy(tmpbuffer, "overflow");
--
2.14.1
--
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 v3] usb: xhci: increase CRS timeout value
Some controllers take almost 55ms to complete controller
restore state (CRS).
There is no timeout limit mentioned in xhci specification so
fixing the issue by increasing the timeout limit to 100ms
Signed-off-by: Ajay Gupta
Signed-off-by: Nagaraj Annaiah
---
Changes from v2->v3
Updated commit message for timeout value to 100ms
Changes from v1->v2
Updated timeout value from 55 to 100ms and added a comment.
drivers/usb/host/xhci.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 8c8da2d..fa7bd71 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1043,8 +1043,13 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
command = readl(>op_regs->command);
command |= CMD_CRS;
writel(command, >op_regs->command);
+ /* Some controllers take upto 55+ ms to complete
+* the controller restore so setting the timeout to
+* 100ms. Xhci specification doesn't mention any
+* timeout value.
+*/
if (xhci_handshake(>op_regs->status,
- STS_RESTORE, 0, 10 * 1000)) {
+ STS_RESTORE, 0, 100 * 1000)) {
xhci_warn(xhci, "WARN: xHC restore state timeout\n");
spin_unlock_irq(>lock);
return -ETIMEDOUT;
--
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 v2] usb: xhci: increase CRS timeout value
Some controllers take almost 55ms to complete controller
restore state (CRS).
There is no timeout limit mentioned in xhci specification so
fixing the issue by increasing the timeout limit to 55ms
Signed-off-by: Ajay Gupta
Signed-off-by: Nagaraj Annaiah
---
drivers/usb/host/xhci.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 8c8da2d..fa7bd71 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1043,8 +1043,13 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
command = readl(>op_regs->command);
command |= CMD_CRS;
writel(command, >op_regs->command);
+ /* Some controllers take upto 55+ ms to complete
+* the controller restore so setting the timeout to
+* 100ms. Xhci specification doesn't mention any
+* timeout value.
+*/
if (xhci_handshake(>op_regs->status,
- STS_RESTORE, 0, 10 * 1000)) {
+ STS_RESTORE, 0, 100 * 1000)) {
xhci_warn(xhci, "WARN: xHC restore state timeout\n");
spin_unlock_irq(>lock);
return -ETIMEDOUT;
--
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: 4.16.14: kernel tried to execute NX-protected page [after USB device went to charging state]
[ +CC: linux-usb, even if this does not look like a USB issue ] On Sat, Jun 09, 2018 at 11:50:34AM +0200, Udo van den Heuvel wrote: > Hello, > > My Holus GPSport 245 was used to download a gpx track. Afterwards I > turned the device off while it was attached to USB so it could charge. > Later I found these messages you can find below. > Is this an actual bug? Well, you've got some kind of corruption going on somewhere. > [223632.768623] usb 1-7: cp210x converter now attached to ttyUSB0 > [225389.048501] usb 1-7: USB disconnect, device number 6 > [225389.048758] cp210x ttyUSB0: cp210x converter now disconnected from > ttyUSB0 > [225389.048785] kernel tried to execute NX-protected page - exploit > attempt? (uid: 0) > [225389.048788] BUG: unable to handle kernel paging request at > c08b64e0 > [225389.048797] IP: usb_serial_exit+0x35df/0xff [usbserial] > [225389.048799] PGD 2ea00c067 P4D 2ea00c067 PUD 2ea00e067 PMD 408590067 > PTE 800109510163 > [225389.048807] Oops: 0011 [#1] PREEMPT SMP NOPTI > [225389.048809] Modules linked in: cp210x usbserial it87(O) hwmon_vid First, please try and reproduce this after blacklisting this out-of-tree it87 module. > fuse ipt_REJECT nf_reject_ipv4 xt_u32 xt_multiport iptable_filter > ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 > nf_defrag_ipv4 nf_nat_ipv4 nf_nat cpufreq_userspace > nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT > nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack > msr nf_conntrack ip6table_filter ip6_tables eeprom uvcvideo > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_usb_audio videodev > snd_hwdep videobuf2_common cdc_acm snd_usbmidi_lib snd_rawmidi amdgpu > snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec > snd_hda_core snd_seq snd_seq_device snd_pcm chash snd_timer gpu_sched > backlight snd ttm i2c_piix4 evdev acpi_cpufreq k10temp nfsd auth_rpcgss > nfs_acl > [225389.048857] lockd grace sunrpc binfmt_misc ip_tables x_tables > hid_generic sr_mod cdrom usbhid i2c_dev autofs4 [last unloaded: hwmon_vid] > [225389.048871] CPU: 1 PID: 5717 Comm: kworker/1:2 Tainted: G > O 4.16.14 #5 > [225389.048873] Hardware name: Gigabyte Technology Co., Ltd. X470 AORUS > ULTRA GAMING/X470 AORUS ULTRA GAMING-CF, BIOS F3g 05/10/2018 > [225389.048880] Workqueue: usb_hub_wq hub_event > [225389.048886] RIP: 0010:usb_serial_exit+0x35df/0xff [usbserial] > [225389.048889] RSP: 0018:90d3c8c27be8 EFLAGS: 00010282 > [225389.048892] RAX: c08b64e0 RBX: 8bd5d2190ae8 RCX: > > [225389.048895] RDX: 8001 RSI: 0282 RDI: > 8bd5d2190ad8 > [225389.048897] RBP: 8bd5d2190ad8 R08: R09: > > [225389.048899] R10: R11: R12: > 8bd392029480 > [225389.048902] R13: 8bd64b4d4e00 R14: 8bd64d2fc030 R15: > 8bd64d2fc030 > [225389.048905] FS: () GS:8bd65ee4() > knlGS: > [225389.048908] CS: 0010 DS: ES: CR0: 80050033 > [225389.048910] CR2: c08b64e0 CR3: 0003f0b5 CR4: > 003406e0 > [225389.048912] Call Trace: > [225389.048918] ? device_release+0x39/0xa0 > [225389.048924] ? kobject_put+0xa1/0x1c0 > [225389.048929] ? usb_serial_put+0x4c/0xf0 [usbserial] > [225389.048933] ? usb_serial_disconnect+0xdd/0x100 [usbserial] > [225389.048938] ? usb_unbind_interface+0x66/0x1e0 > [225389.048942] ? device_release_driver_internal+0x17a/0x230 > [225389.048946] ? bus_remove_device+0xe0/0x150 > [225389.048950] ? device_del+0x129/0x330 > [225389.048954] ? usb_disable_device+0x8d/0x230 > [225389.048958] ? usb_disconnect+0xb1/0x270 > [225389.048962] ? hub_event+0x5f5/0x13b0 > [225389.048967] ? SyS_uname+0x11/0xa0 > [225389.048971] ? process_one_work+0x1a1/0x2f0 > [225389.048974] ? worker_thread+0x26/0x3f0 > [225389.048978] ? process_one_work+0x2f0/0x2f0 > [225389.048982] ? kthread+0x109/0x120 > [225389.048986] ? kthread_create_on_node+0x60/0x60 > [225389.048991] ? ret_from_fork+0x22/0x40 > [225389.048994] Code: ff ff ff 29 1a 8b c0 ff ff ff ff 50 73 8b c0 ff ff > ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 34 8b c0 ff ff ff ff 00 00 00 00 00 00 00 00 00 65 8b c0 ff > [225389.049043] RIP: usb_serial_exit+0x35df/0xff [usbserial] RSP: > 90d3c8c27be8 > [225389.049045] CR2: c08b64e0 > [225389.049048] ---[ end trace 43c4e5674b0ca81f ]--- This looks to me like you've got a struct device whose release pointer is pointing into a non-executable page. The IP symbol looks weird usb_serial_exit+0x35df/0xff but this could correspond with usb_serial_port_release (check /proc/kallsyms as root). Enabling dynamic debugging for usbserial might give some indication of how far you get in usb_serial_put(), but this smells like an x86/mem (or hardware?) issue. Did you say you could reproduce this
Re: [PATCH v6] usb: gadget: udc: renesas_usb3: Add register of usb role switch
On Thu, May 31, 2018 at 03:11:33PM +0900, Yoshihiro Shimoda wrote:
> This patch adds role switch support for R-Car SoCs into the USB 3.0
> peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0
> dual-role device controller which has the USB 3.0 xHCI host and
> Renesas USB 3.0 peripheral.
>
> Unfortunately, the mode change register (DRD_CON) contains
> the USB 3.0 peripheral controller side only. So, this renesas_usb3
> driver manages the DRD_CON now. However, in peripheral mode, the host
> should stop. Also the host hardware needs to reinitialize its own
> registers when the mode changes from peripheral to host mode.
> Otherwise, the host cannot work correctly (e.g. detect a device
> as high-speed).
>
> To achieve this reinitialization by a driver, this driver also
> registers a role switch driver to manage the DRD_CON and get
> a device pointer of usb 3.0 host from "companion" property of OF.
> Then, when the usb role is changed, renesas_usb3_role_switch_set()
> will attach/release the xhci-plat driver to reinitialize the host
> hardware.
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Heikki Krogerus
> ---
> This patch set is based on Felipe's usb.git / testing/next branch
> (commit id = 47265c067c0d129f3a0e94bc221293a780af9d78).
>
> Changes from v5 (https://patchwork.kernel.org/patch/10426483/):
> - Add a new function "usb3_set_mode_by_role_sw()" instead of reusing
>usb3_set_mode() and add _usb3_set_mode().
> - Change a coding style of container_of.
> - Revise an error message in renesas_usb3_role_switch_set().
> - Add "const" for "renesas_usb3_role_switch_desc".
> - Simplify a condition check of usb_of_get_companion_dev().
>
> Changes from RFC v4 (https://patchwork.kernel.org/patch/10418265/):
> - Use "companion" device tree property simply instead of device_connection
>APIs with OF graph.
> - Merge patch 2 and 3 to one.
> - Revise the commit log (I should had revised this on RFC v4 though).
>
> Changes from RFC v3:
> - Rebase latest usb.git / testing/next branch.
> - Add graph parse into device_connection_find_match().
> - Use workqueue to call _usb3_set_mode() in patch 3.
>(I realized renesas_usb3_role_switch_set() cannot run on atomic because
> device_attach() might sleep.)
>
> Changes from RFC v2:
> - Add registering usb role switch into drivers/usb/gadget/udc/renesas_usb3
>because hardware resource (a register) is shared and remove individual
>usb role switch driver/dt-bindings for R-Car.
> - Remove "usb_role_switch_get_by_graph" API because the renesas_usb3 driver
>doesn't need such API now.
>
> Changes from RFC:
> - Remove "device-connection-id" and "usb role switch driver" dt-bingings.
> - Remove drivers/of code.
> - Add a new API for find the connection by using graph on devcon.c and
> roles.c.
> - Use each new API on the rcar usb role switch and renesas_usb3 drivers.
> - Update the dtsi file for r8a7795.
>
>
> drivers/usb/gadget/udc/Kconfig| 1 +
> drivers/usb/gadget/udc/renesas_usb3.c | 84
> ++-
> 2 files changed, 84 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
> index b838cae..78823cd 100644
> --- a/drivers/usb/gadget/udc/Kconfig
> +++ b/drivers/usb/gadget/udc/Kconfig
> @@ -193,6 +193,7 @@ config USB_RENESAS_USB3
> tristate 'Renesas USB3.0 Peripheral controller'
> depends on ARCH_RENESAS || COMPILE_TEST
> depends on EXTCON && HAS_DMA
> + select USB_ROLE_SWITCH
> help
> Renesas USB3.0 Peripheral controller is a USB peripheral controller
> that supports super, high, and full speed USB 3.0 data transfers.
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 5caf78b..f44a4b1 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -23,6 +23,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> /* register definitions */
> #define USB3_AXI_INT_STA 0x008
> @@ -335,6 +337,11 @@ struct renesas_usb3 {
> struct phy *phy;
> struct dentry *dentry;
>
> + struct usb_role_switch *role_sw;
> + struct device *host_dev;
> + struct work_struct role_work;
> + enum usb_role role;
> +
> struct renesas_usb3_ep *usb3_ep;
> int num_usb3_eps;
>
> @@ -651,6 +658,14 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
> }
> }
>
> +static void renesas_usb3_role_work(struct work_struct *work)
> +{
> + struct renesas_usb3 *usb3 =
> + container_of(work, struct renesas_usb3, role_work);
> +
> + usb_role_switch_set_role(usb3->role_sw, usb3->role);
> +}
> +
> static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> {
> if (host)
> @@ -659,6 +674,16 @@ static void usb3_set_mode(struct renesas_usb3 *usb3,
> bool host)
> usb3_set_bit(usb3, DRD_CON_PERI_CON,
Re: [PATCH v6 12/15] usb: typec: tcpm: set cc for drp toggling attach
On 06/11/2018 05:29 AM, Heikki Krogerus wrote: On Mon, May 28, 2018 at 10:52:44AM +0800, Li Jun wrote: In case of drp toggling, we may need set correct cc value for role control after attach as it may never been set. Is this something that should be considered as a fix? The problem with this patch is that it hides a problem. CC should have been set by the time a port reaches the attached state. The patch means that there is a state machine path where this does not happen. I'd rather understand that path and fix the problem where it happens. Guenter Signed-off-by: Li Jun --- drivers/usb/typec/tcpm.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c index d885bff..98ea916 100644 --- a/drivers/usb/typec/tcpm.c +++ b/drivers/usb/typec/tcpm.c @@ -2599,6 +2599,7 @@ static void tcpm_reset_port(struct tcpm_port *port) tcpm_set_attached_state(port, false); port->try_src_count = 0; port->try_snk_count = 0; + port->cc_req = TYPEC_CC_OPEN; port->supply_voltage = 0; port->current_limit = 0; port->usb_type = POWER_SUPPLY_USB_TYPE_C; @@ -2831,6 +2832,8 @@ static void run_state_machine(struct tcpm_port *port) break; case SRC_ATTACHED: + if (port->cc_req == TYPEC_CC_OPEN) + tcpm_set_cc(port, tcpm_rp_cc(port)); ret = tcpm_src_attach(port); tcpm_set_state(port, SRC_UNATTACHED, ret < 0 ? 0 : PD_T_PS_SOURCE_ON); @@ -3004,6 +3007,8 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state(port, SNK_UNATTACHED, PD_T_PD_DEBOUNCE); break; case SNK_ATTACHED: + if (port->cc_req == TYPEC_CC_OPEN) + tcpm_set_cc(port, TYPEC_CC_RD); ret = tcpm_snk_attach(port); if (ret < 0) tcpm_set_state(port, SNK_UNATTACHED, 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
Re: [PATCH v6 06/15] usb: typec: tcpm: support get typec and pd config from device properties
On 05/27/2018 07:52 PM, Li Jun wrote:
This patch adds support of get typec and power delivery config from
firmware description.
Signed-off-by: Li Jun
Except for the nitpick. on top of Heikki's comments:
Reviewed-by: Guenter Roeck
---
drivers/usb/typec/tcpm.c | 132 +++
1 file changed, 110 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index fcd22e8..aa17cd5 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -4241,6 +4241,81 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32
*src_vdo,
return nr_vdo;
}
+static int tcpm_fw_get_caps(struct tcpm_port *port,
+ struct fwnode_handle *fwnode)
+{
+ const char *cap_str;
+ int ret;
+ u32 mw;
+
+ if (!port || !fwnode)
+ return -EINVAL;
+
+ /* USB data support is optional */
+ ret = fwnode_property_read_string(fwnode, "data-role", _str);
+ if (ret == 0) {
+ port->typec_caps.data = typec_find_port_data_role(cap_str);
+ if (port->typec_caps.data < 0)
+ return -EINVAL;
+ }
+
+ ret = fwnode_property_read_string(fwnode, "power-role", _str);
+ if (ret < 0)
+ return ret;
+
+ port->typec_caps.type = typec_find_port_power_role(cap_str);
+ if (port->typec_caps.type < 0)
+ return -EINVAL;
+ port->port_type = port->typec_caps.type;
+
+ if (port->port_type == TYPEC_PORT_SNK)
+ goto sink;
+
+ /* Get soruce pdos */
+ ret = fwnode_property_read_u32_array(fwnode, "source-pdos",
+NULL, 0);
+ if (ret <= 0)
+ return -EINVAL;
+
+ port->nr_src_pdo = min(ret, PDO_MAX_OBJECTS);
+ ret = fwnode_property_read_u32_array(fwnode, "source-pdos",
+port->src_pdo, port->nr_src_pdo);
+ if ((ret < 0) || tcpm_validate_caps(port, port->src_pdo,
+ port->nr_src_pdo))
+ return -EINVAL;
+
+ if (port->port_type == TYPEC_PORT_SRC)
+ return 0;
+
+ /* Get the preferred power role for DRP */
+ ret = fwnode_property_read_string(fwnode, "try-power-role", _str);
+ if (ret < 0)
+ return ret;
+
+ port->typec_caps.prefer_role = typec_find_power_role(cap_str);
+ if (port->typec_caps.prefer_role < 0)
+ return -EINVAL;
+sink:
+ /* Get sink pdos */
+ ret = fwnode_property_read_u32_array(fwnode, "sink-pdos",
+NULL, 0);
+ if (ret <= 0)
+ return -EINVAL;
+
+ port->nr_snk_pdo = min(ret, PDO_MAX_OBJECTS);
+ ret = fwnode_property_read_u32_array(fwnode, "sink-pdos",
+port->snk_pdo, port->nr_snk_pdo);
+ if ((ret < 0) || tcpm_validate_caps(port, port->snk_pdo,
+ port->nr_snk_pdo))
+ return -EINVAL;
+
+ if (fwnode_property_read_u32(fwnode, "op-sink-microwatt", ) < 0)
+ return -EINVAL;
+ port->operating_snk_mw = mw / 1000;
+
"mw" should be "uw", really. The variable never holds "milliwatt".
+ return 0;
+}
+
int tcpm_update_source_capabilities(struct tcpm_port *port, const u32 *pdo,
unsigned int nr_pdo)
{
@@ -4526,12 +4601,36 @@ static int devm_tcpm_psy_register(struct tcpm_port
*port)
return PTR_ERR_OR_ZERO(port->psy);
}
+static int tcpm_copy_caps(struct tcpm_port *port,
+ const struct tcpc_config *tcfg)
+{
+ if (tcpm_validate_caps(port, tcfg->src_pdo, tcfg->nr_src_pdo) ||
+ tcpm_validate_caps(port, tcfg->snk_pdo, tcfg->nr_snk_pdo))
+ return -EINVAL;
+
+ port->nr_src_pdo = tcpm_copy_pdos(port->src_pdo, tcfg->src_pdo,
+ tcfg->nr_src_pdo);
+ port->nr_snk_pdo = tcpm_copy_pdos(port->snk_pdo, tcfg->snk_pdo,
+ tcfg->nr_snk_pdo);
+
+ port->nr_snk_vdo = tcpm_copy_vdos(port->snk_vdo, tcfg->snk_vdo,
+ tcfg->nr_snk_vdo);
+
+ port->operating_snk_mw = tcfg->operating_snk_mw;
+
+ port->typec_caps.prefer_role = tcfg->default_role;
+ port->typec_caps.type = tcfg->type;
+ port->typec_caps.data = tcfg->data;
+
+ return 0;
+}
+
struct tcpm_port *tcpm_register_port(struct device *dev, struct tcpc_dev
*tcpc)
{
struct tcpm_port *port;
int i, err;
- if (!dev || !tcpc || !tcpc->config ||
+ if (!dev || !tcpc ||
!tcpc->get_vbus || !tcpc->set_cc || !tcpc->get_cc ||
!tcpc->set_polarity || !tcpc->set_vconn || !tcpc->set_vbus ||
!tcpc->set_pd_rx || !tcpc->set_roles ||
Re: [PATCH v6 14/15] staging: typec: tcpci: Only touch target bit when enable vconn
On Mon, May 28, 2018 at 10:52:46AM +0800, Li Jun wrote: > We need regmap_update_bits to avoid touch any other bits when > enable or disable vconn. > > Reviewed-by: Guenter Roeck > Signed-off-by: Li Jun Reviewed-by: Heikki Krogerus > --- > drivers/staging/typec/tcpci.c | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c > index 11c2d37..ac6b418 100644 > --- a/drivers/staging/typec/tcpci.c > +++ b/drivers/staging/typec/tcpci.c > @@ -218,12 +218,9 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool > enable) > return ret; > } > > - ret = regmap_write(tcpci->regmap, TCPC_POWER_CTRL, > -enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0); > - if (ret < 0) > - return ret; > - > - return 0; > + return regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL, > + TCPC_POWER_CTRL_VCONN_ENABLE, > + enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0); > } > > static int tcpci_set_roles(struct tcpc_dev *tcpc, bool attached, 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 v6 13/15] staging: typec: tcpci: keep the disconnected cc line open
On Mon, May 28, 2018 at 10:52:45AM +0800, Li Jun wrote:
> While set polarity, we should keep the disconnected cc line to be
> open.
>
> Signed-off-by: Li Jun
Reviewed-by: Heikki Krogerus
> ---
> drivers/staging/typec/tcpci.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 4d3b0ae..11c2d37 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -185,15 +185,25 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
> enum typec_cc_polarity polarity)
> {
> struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> + unsigned int reg;
> int ret;
>
> - ret = regmap_write(tcpci->regmap, TCPC_TCPC_CTRL,
> -(polarity == TYPEC_POLARITY_CC2) ?
> -TCPC_TCPC_CTRL_ORIENTATION : 0);
> + /* Keep the disconnect cc line open */
> + ret = regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, );
> if (ret < 0)
> return ret;
>
> - return 0;
> + if (polarity == TYPEC_POLARITY_CC2)
> + reg |= TCPC_ROLE_CTRL_CC_OPEN << TCPC_ROLE_CTRL_CC1_SHIFT;
> + else
> + reg |= TCPC_ROLE_CTRL_CC_OPEN << TCPC_ROLE_CTRL_CC2_SHIFT;
> + ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + if (ret < 0)
> + return ret;
> +
> + return regmap_write(tcpci->regmap, TCPC_TCPC_CTRL,
> +(polarity == TYPEC_POLARITY_CC2) ?
> +TCPC_TCPC_CTRL_ORIENTATION : 0);
> }
>
> static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool enable)
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 v6 10/15] staging: typec: tcpci: enable vbus detection
On Mon, May 28, 2018 at 10:52:42AM +0800, Li Jun wrote: > TCPCI implementation may need SW to enable VBUS detection to generate > power status events. > > Reviewed-by: Guenter Roeck > Signed-off-by: Li Jun FWIW: Reviewed-by: Heikki Krogerus > --- > drivers/staging/typec/tcpci.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c > index 3b35fce..4d3b0ae 100644 > --- a/drivers/staging/typec/tcpci.c > +++ b/drivers/staging/typec/tcpci.c > @@ -373,6 +373,12 @@ static int tcpci_init(struct tcpc_dev *tcpc) > if (ret < 0) > return ret; > > + /* Enable Vbus detection */ > + ret = regmap_write(tcpci->regmap, TCPC_COMMAND, > +TCPC_CMD_ENABLE_VBUS_DETECT); > + if (ret < 0) > + return ret; > + > reg = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_FAILED | > TCPC_ALERT_TX_DISCARDED | TCPC_ALERT_RX_STATUS | > TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS; 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 v6 09/15] staging: typec: tcpci: register port before request irq
On Mon, May 28, 2018 at 10:52:41AM +0800, Li Jun wrote:
> From: Peter Chen
>
> With that we can clear any pending events and the port is registered
> so driver can be ready to handle typec events once we request irq.
>
> Signed-off-by: Peter Chen
> Signed-off-by: Li Jun
FWIW:
Reviewed-by: Heikki Krogerus
> ---
> drivers/staging/typec/tcpci.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index b63f147..3b35fce 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -537,24 +537,27 @@ static int tcpci_probe(struct i2c_client *client,
> if (IS_ERR(chip->data.regmap))
> return PTR_ERR(chip->data.regmap);
>
> + i2c_set_clientdata(client, chip);
> +
> /* Disable chip interrupts before requesting irq */
> err = regmap_raw_write(chip->data.regmap, TCPC_ALERT_MASK, ,
> sizeof(u16));
> if (err < 0)
> return err;
>
> + chip->tcpci = tcpci_register_port(>dev, >data);
> + if (IS_ERR(chip->tcpci))
> + return PTR_ERR(chip->tcpci);
> +
> err = devm_request_threaded_irq(>dev, client->irq, NULL,
> _tcpci_irq,
> IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> dev_name(>dev), chip);
> - if (err < 0)
> + if (err < 0) {
> + tcpci_unregister_port(chip->tcpci);
> return err;
> + }
>
> - chip->tcpci = tcpci_register_port(>dev, >data);
> - if (IS_ERR(chip->tcpci))
> - return PTR_ERR(chip->tcpci);
> -
> - i2c_set_clientdata(client, chip);
> return 0;
> }
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 v6 08/15] staging: typec: tcpci: use IS_ERR() instead of PTR_ERR_OR_ZERO()
On Mon, May 28, 2018 at 10:52:40AM +0800, Li Jun wrote: > As tcpm_register_port() and tcpci_register_port() never return > NULL and NULL is not a success in this case, use IS_ERR() to check > the return value of both. > > Signed-off-by: Li Jun FWIW: Reviewed-by: Heikki Krogerus > --- > drivers/staging/typec/tcpci.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c > index 076498a..b63f147 100644 > --- a/drivers/staging/typec/tcpci.c > +++ b/drivers/staging/typec/tcpci.c > @@ -509,7 +509,7 @@ struct tcpci *tcpci_register_port(struct device *dev, > struct tcpci_data *data) > return ERR_PTR(err); > > tcpci->port = tcpm_register_port(tcpci->dev, >tcpc); > - if (PTR_ERR_OR_ZERO(tcpci->port)) > + if (IS_ERR(tcpci->port)) > return ERR_CAST(tcpci->port); > > return tcpci; > @@ -551,7 +551,7 @@ static int tcpci_probe(struct i2c_client *client, > return err; > > chip->tcpci = tcpci_register_port(>dev, >data); > - if (PTR_ERR_OR_ZERO(chip->tcpci)) > + if (IS_ERR(chip->tcpci)) > return PTR_ERR(chip->tcpci); > > i2c_set_clientdata(client, chip); 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 v6 07/15] staging: typec: tcpci: remove unused tcpci_tcpc_config
On Mon, May 28, 2018 at 10:52:39AM +0800, Li Jun wrote:
> Since we will use config settings via device properties, so
> remove the hard code tcpci_tcpc_config.
>
> Signed-off-by: Li Jun
FWIW:
Reviewed-by: Heikki Krogerus
> ---
> drivers/staging/typec/tcpci.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index e59547a..076498a 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -464,17 +464,10 @@ static const struct regmap_config tcpci_regmap_config =
> {
> .max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */
> };
>
> -static const struct tcpc_config tcpci_tcpc_config = {
> - .type = TYPEC_PORT_DFP,
> - .default_role = TYPEC_SINK,
> -};
> -
> static int tcpci_parse_config(struct tcpci *tcpci)
> {
> tcpci->controls_vbus = true; /* XXX */
>
> - /* TODO: Populate struct tcpc_config from ACPI/device-tree */
> - tcpci->tcpc.config = _tcpc_config;
> tcpci->tcpc.fwnode = device_get_named_child_node(tcpci->dev,
>"connector");
> if (!tcpci->tcpc.fwnode) {
> --
> 2.7.4
--
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 v2] arm64: dts: msm8996: Use dwc3-qcom glue driver for USB
Hi Vivek, > I have a branch that's based on 4.17. You can pick that. > https://github.com/vivekgautam1/linux/commits/v4.17/db820c > Thanks a lot, I will test this branch. Julien -- *This email and any attachment thereto are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please be advised that disclosing, copying, distributing or taking any action in reliance on the contents of this email is strictly prohibited. In such case, please immediately advise the sender, and delete all copies and attachment from your system. This email shall not be construed and is not tantamount to an offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe on any discussion or contractual document whatsoever. No employee or agent is authorized to represent or bind SoftBank Robotics Europe to third parties by email, or act on behalf of SoftBank Robotics Europe by email, without express written confirmation by SoftBank Robotics Europe’ duly authorized representatives. * *Ce message électronique et éventuelles pièces jointes sont confidentiels, et exclusivement destinés à la personne ou l'entité à qui ils sont adressés. Si vous n'êtes pas le destinataire visé, vous êtes prié de ne pas divulguer, copier, distribuer ou prendre toute décision sur la foi de ce message électronique. Merci d'en aviser immédiatement l'expéditeur et de supprimer toutes les copies et éventuelles pièces jointes de votre système. Ce message électronique n'équivaut pas à une offre, à une acceptation d’offre, ou à un accord de SoftBank Robotics Europe sur toute discussion ou document contractuel quel qu’il soit, et ne peut être interprété comme tel. Aucun employé ou agent de SoftBank Robotics Europe n'est autorisé à représenter ou à engager la société par email, ou à agir au nom et pour le compte de la société par email, sans qu’une confirmation écrite soit donnée par le représentant légal de SoftBank Robotics Europe ou par toute autre personne ayant reçu délégation de pouvoir appropriée. * ** -- 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 v6 03/15] staging: typec: tcpci: add compatible string for nxp ptn5110
On Mon, May 28, 2018 at 10:52:35AM +0800, Li Jun wrote:
> Add nxp ptn5110 typec controller compatible string: "nxp,ptn5110",
> which is a standard tcpci chip with power delivery support. Meanwhile
> remove "usb,tcpci" because it doesn't follow the binding format rule
> and has not been used yet.
>
> Signed-off-by: Li Jun
FWIW:
Reviewed-by: Heikki Krogerus
> ---
> drivers/staging/typec/tcpci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 076d97e..dd29288 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -575,7 +575,7 @@ MODULE_DEVICE_TABLE(i2c, tcpci_id);
>
> #ifdef CONFIG_OF
> static const struct of_device_id tcpci_of_match[] = {
> - { .compatible = "usb,tcpci", },
> + { .compatible = "nxp,ptn5110", },
> {},
> };
> MODULE_DEVICE_TABLE(of, tcpci_of_match);
--
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 v2] usb: xhci: remove the code build warning
Hi Mathias, This patch is ready to apply, It is great that this patch can be applied to 4.18. thanks a lot. On 2018/6/6 22:36, Dongjiu Geng wrote: > Initialize the 'err' variate to remove the build warning, > the warning is shown as below: > > drivers/usb/host/xhci-tegra.c: In function 'tegra_xusb_mbox_thread': > drivers/usb/host/xhci-tegra.c:552:6: warning: 'err' may be used uninitialized > in this function [-Wuninitialized] > drivers/usb/host/xhci-tegra.c:482:6: note: 'err' was declared here > > Signed-off-by: Dongjiu Geng > Acked-by: Thierry Reding > --- > How to reproduce: > 1. make defconfig ARCH=arm > 2. make -j100 CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm > > Then you can see below warnings: > drivers/usb/host/xhci-tegra.c: In function 'tegra_xusb_mbox_thread': > drivers/usb/host/xhci-tegra.c:552:6: warning: 'err' may be used uninitialized > in this function [-Wuninitialized] > drivers/usb/host/xhci-tegra.c:482:6: note: 'err' was declared here > --- > drivers/usb/host/xhci-tegra.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c > index a8c1d07..d50549f 100644 > --- a/drivers/usb/host/xhci-tegra.c > +++ b/drivers/usb/host/xhci-tegra.c > @@ -481,7 +481,7 @@ static void tegra_xusb_mbox_handle(struct tegra_xusb > *tegra, > unsigned long mask; > unsigned int port; > bool idle, enable; > - int err; > + int err = 0; > > memset(, 0, sizeof(rsp)); > > -- 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 v6 12/15] usb: typec: tcpm: set cc for drp toggling attach
On Mon, May 28, 2018 at 10:52:44AM +0800, Li Jun wrote: > In case of drp toggling, we may need set correct cc value for role control > after attach as it may never been set. Is this something that should be considered as a fix? > Signed-off-by: Li Jun > --- > drivers/usb/typec/tcpm.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c > index d885bff..98ea916 100644 > --- a/drivers/usb/typec/tcpm.c > +++ b/drivers/usb/typec/tcpm.c > @@ -2599,6 +2599,7 @@ static void tcpm_reset_port(struct tcpm_port *port) > tcpm_set_attached_state(port, false); > port->try_src_count = 0; > port->try_snk_count = 0; > + port->cc_req = TYPEC_CC_OPEN; > port->supply_voltage = 0; > port->current_limit = 0; > port->usb_type = POWER_SUPPLY_USB_TYPE_C; > @@ -2831,6 +2832,8 @@ static void run_state_machine(struct tcpm_port *port) > break; > > case SRC_ATTACHED: > + if (port->cc_req == TYPEC_CC_OPEN) > + tcpm_set_cc(port, tcpm_rp_cc(port)); > ret = tcpm_src_attach(port); > tcpm_set_state(port, SRC_UNATTACHED, > ret < 0 ? 0 : PD_T_PS_SOURCE_ON); > @@ -3004,6 +3007,8 @@ static void run_state_machine(struct tcpm_port *port) > tcpm_set_state(port, SNK_UNATTACHED, PD_T_PD_DEBOUNCE); > break; > case SNK_ATTACHED: > + if (port->cc_req == TYPEC_CC_OPEN) > + tcpm_set_cc(port, TYPEC_CC_RD); > ret = tcpm_snk_attach(port); > if (ret < 0) > tcpm_set_state(port, SNK_UNATTACHED, 0); -- 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 v6 11/15] typec: tcpm: add starting value for drp toggling
On Mon, May 28, 2018 at 10:52:43AM +0800, Li Jun wrote:
> As DRP port autonomously toggles the Rp/Rd need a start value to
> begin with, so add one parameter for it in tcpm_start_drp_toggling.
>
> Reviewed-by: Guenter Roeck
> Signed-off-by: Li Jun
Reviewed-by: Heikki Krogerus
> ---
> drivers/usb/typec/tcpm.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index aa17cd5..d885bff 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -2436,15 +2436,15 @@ static int tcpm_set_charge(struct tcpm_port *port,
> bool charge)
> return 0;
> }
>
> -static bool tcpm_start_drp_toggling(struct tcpm_port *port)
> +static bool tcpm_start_drp_toggling(struct tcpm_port *port,
> + enum typec_cc_status cc)
> {
> int ret;
>
> if (port->tcpc->start_drp_toggling &&
> port->port_type == TYPEC_PORT_DRP) {
> tcpm_log_force(port, "Start DRP toggling");
> - ret = port->tcpc->start_drp_toggling(port->tcpc,
> - tcpm_rp_cc(port));
> + ret = port->tcpc->start_drp_toggling(port->tcpc, cc);
> if (!ret)
> return true;
> }
> @@ -2752,7 +2752,7 @@ static void run_state_machine(struct tcpm_port *port)
> if (!port->non_pd_role_swap)
> tcpm_swap_complete(port, -ENOTCONN);
> tcpm_src_detach(port);
> - if (tcpm_start_drp_toggling(port)) {
> + if (tcpm_start_drp_toggling(port, tcpm_rp_cc(port))) {
> tcpm_set_state(port, DRP_TOGGLING, 0);
> break;
> }
> @@ -2927,7 +2927,7 @@ static void run_state_machine(struct tcpm_port *port)
> tcpm_swap_complete(port, -ENOTCONN);
> tcpm_pps_complete(port, -ENOTCONN);
> tcpm_snk_detach(port);
> - if (tcpm_start_drp_toggling(port)) {
> + if (tcpm_start_drp_toggling(port, TYPEC_CC_RD)) {
> tcpm_set_state(port, DRP_TOGGLING, 0);
> break;
> }
> --
> 2.7.4
--
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 v6 06/15] usb: typec: tcpm: support get typec and pd config from device properties
On Mon, May 28, 2018 at 10:52:38AM +0800, Li Jun wrote:
> This patch adds support of get typec and power delivery config from
> firmware description.
>
> Signed-off-by: Li Jun
This looks good to me, assuming that everybody agrees with the names
used in the bindings. As usual, I would like Guenter to check tcpm.c
changes. I'm putting a few nitpicks below, but in any case:
Reviewed-by: Heikki Krogerus
> ---
> drivers/usb/typec/tcpm.c | 132
> +++
> 1 file changed, 110 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index fcd22e8..aa17cd5 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -4241,6 +4241,81 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32
> *src_vdo,
> return nr_vdo;
> }
>
> +static int tcpm_fw_get_caps(struct tcpm_port *port,
> + struct fwnode_handle *fwnode)
> +{
> + const char *cap_str;
> + int ret;
> + u32 mw;
> +
> + if (!port || !fwnode)
if (!fwnode) is enough.
> + return -EINVAL;
> +
> + /* USB data support is optional */
> + ret = fwnode_property_read_string(fwnode, "data-role", _str);
> + if (ret == 0) {
> + port->typec_caps.data = typec_find_port_data_role(cap_str);
> + if (port->typec_caps.data < 0)
> + return -EINVAL;
> + }
> +
> + ret = fwnode_property_read_string(fwnode, "power-role", _str);
> + if (ret < 0)
> + return ret;
> +
> + port->typec_caps.type = typec_find_port_power_role(cap_str);
> + if (port->typec_caps.type < 0)
> + return -EINVAL;
> + port->port_type = port->typec_caps.type;
> +
> + if (port->port_type == TYPEC_PORT_SNK)
> + goto sink;
> +
> + /* Get soruce pdos */
s/soruce/source/
> + ret = fwnode_property_read_u32_array(fwnode, "source-pdos",
> + NULL, 0);
> + if (ret <= 0)
> + return -EINVAL;
> +
> + port->nr_src_pdo = min(ret, PDO_MAX_OBJECTS);
> + ret = fwnode_property_read_u32_array(fwnode, "source-pdos",
> + port->src_pdo, port->nr_src_pdo);
> + if ((ret < 0) || tcpm_validate_caps(port, port->src_pdo,
> + port->nr_src_pdo))
> + return -EINVAL;
> +
> + if (port->port_type == TYPEC_PORT_SRC)
> + return 0;
> +
> + /* Get the preferred power role for DRP */
> + ret = fwnode_property_read_string(fwnode, "try-power-role", _str);
> + if (ret < 0)
> + return ret;
> +
> + port->typec_caps.prefer_role = typec_find_power_role(cap_str);
> + if (port->typec_caps.prefer_role < 0)
> + return -EINVAL;
> +sink:
> + /* Get sink pdos */
> + ret = fwnode_property_read_u32_array(fwnode, "sink-pdos",
> + NULL, 0);
> + if (ret <= 0)
> + return -EINVAL;
> +
> + port->nr_snk_pdo = min(ret, PDO_MAX_OBJECTS);
> + ret = fwnode_property_read_u32_array(fwnode, "sink-pdos",
> + port->snk_pdo, port->nr_snk_pdo);
> + if ((ret < 0) || tcpm_validate_caps(port, port->snk_pdo,
> + port->nr_snk_pdo))
> + return -EINVAL;
> +
> + if (fwnode_property_read_u32(fwnode, "op-sink-microwatt", ) < 0)
> + return -EINVAL;
> + port->operating_snk_mw = mw / 1000;
> +
> + return 0;
> +}
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] usb: xhci: increase CRS timeout value
On 11.06.2018 11:50, Oliver Neukum wrote: On Do, 2018-06-07 at 11:48 -0700, Ajay Gupta wrote: Some controllers take almost 55ms to complete controller restore state (CRS). There is no timeout limit mentioned in xhci specification so fix the issue by increasing the timeout limit to 55ms Hi, the chances that you saw the true worst case are slim. I would suggest you include at least a bit of a safety margin and a comment that explains it. Regards Oliver Agree with this, polling up to 100ms perhaps? -Mathias -- 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 v6 04/15] usb: typec: add fwnode to tcpc
On Mon, May 28, 2018 at 10:52:36AM +0800, Li Jun wrote:
> Add fwnode handle to get the fwnode so we can get typec configs
> it contains.
>
> Suggested-by: Heikki Krogerus
> Signed-off-by: Li Jun
Reviewed-by: Heikki Krogerus
> ---
> drivers/staging/typec/tcpci.c | 7 +++
> drivers/usb/typec/tcpm.c | 1 +
> include/linux/usb/tcpm.h | 2 ++
> 3 files changed, 10 insertions(+)
>
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index dd29288..e59547a 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -474,6 +475,12 @@ static int tcpci_parse_config(struct tcpci *tcpci)
>
> /* TODO: Populate struct tcpc_config from ACPI/device-tree */
> tcpci->tcpc.config = _tcpc_config;
> + tcpci->tcpc.fwnode = device_get_named_child_node(tcpci->dev,
> + "connector");
> + if (!tcpci->tcpc.fwnode) {
> + dev_err(tcpci->dev, "Can't find connector node.\n");
> + return -EINVAL;
> + }
>
> return 0;
> }
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 0ccd2ce..fcd22e8 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -4581,6 +4581,7 @@ struct tcpm_port *tcpm_register_port(struct device
> *dev, struct tcpc_dev *tcpc)
> else
> port->try_role = TYPEC_NO_PREFERRED_ROLE;
>
> + port->typec_caps.fwnode = tcpc->fwnode;
> port->typec_caps.prefer_role = tcpc->config->default_role;
> port->typec_caps.type = tcpc->config->type;
> port->typec_caps.data = tcpc->config->data;
> diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
> index b231b93..193920a 100644
> --- a/include/linux/usb/tcpm.h
> +++ b/include/linux/usb/tcpm.h
> @@ -110,6 +110,7 @@ enum tcpc_mux_mode {
> /**
> * struct tcpc_dev - Port configuration and callback functions
> * @config: Pointer to port configuration
> + * @fwnode: Pointer to port fwnode
> * @get_vbus:Called to read current VBUS state
> * @get_current_limit:
> * Optional; called by the tcpm core when configured as a snk
> @@ -138,6 +139,7 @@ enum tcpc_mux_mode {
> */
> struct tcpc_dev {
> const struct tcpc_config *config;
> + struct fwnode_handle *fwnode;
>
> int (*init)(struct tcpc_dev *dev);
> int (*get_vbus)(struct tcpc_dev *dev);
> --
> 2.7.4
--
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 v6 05/15] usb: typec: add API to get typec basic port power and data config
Hi Jun,
On Mon, May 28, 2018 at 10:52:37AM +0800, Li Jun wrote:
> This patch adds 3 APIs to get the typec port power and data type,
> and preferred power role by its name string.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/typec/class.c | 50
> +++
> include/linux/usb/typec.h | 3 +++
> 2 files changed, 53 insertions(+)
>
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index 53df10d..4c7d18c 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -802,6 +802,12 @@ static const char * const typec_port_types[] = {
> [TYPEC_PORT_DRP] = "dual",
> };
>
> +static const char * const typec_data_caps[] = {
> + [TYPEC_PORT_DFP] = "host",
> + [TYPEC_PORT_UFP] = "device",
> + [TYPEC_PORT_DRD] = "dual",
> +};
Since I guess you need to fix this patch in any case, could you rename
that to "typec_port_data_roles".
And while at it, how about using this as an opportunity to rename
typec_port_types to typec_port_power_roles?
So this just a suggestion, no need to actually change it :-) :
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index abbd33939109..97f7eb0e9879 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -918,12 +918,18 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
};
-static const char * const typec_port_types[] = {
+static const char * const typec_port_power_roles[] = {
[TYPEC_PORT_SRC] = "source",
[TYPEC_PORT_SNK] = "sink",
[TYPEC_PORT_DRP] = "dual",
};
+static const char * const typec_port_data_roles[] = {
+ [TYPEC_PORT_DFP] = "host",
+ [TYPEC_PORT_UFP] = "device",
+ [TYPEC_PORT_DRD] = "dual",
+};
+
static const char * const typec_port_types_drp[] = {
[TYPEC_PORT_SRC] = "dual [source] sink",
[TYPEC_PORT_SNK] = "dual source [sink]",
@@ -1054,7 +1060,7 @@ static ssize_t power_role_store(struct device *dev,
mutex_lock(>port_type_lock);
if (port->port_type != TYPEC_PORT_DRP) {
dev_dbg(dev, "port type fixed at \"%s\"",
-typec_port_types[port->port_type]);
+ typec_port_power_roles[port->port_type]);
ret = -EOPNOTSUPP;
goto unlock_and_ret;
}
@@ -1095,7 +1101,7 @@ port_type_store(struct device *dev, struct
device_attribute *attr,
return -EOPNOTSUPP;
}
- ret = sysfs_match_string(typec_port_types, buf);
+ ret = sysfs_match_string(typec_port_power_roles, buf);
if (ret < 0)
return ret;
@@ -1129,7 +1135,7 @@ port_type_show(struct device *dev, struct
device_attribute *attr,
return sprintf(buf, "%s\n",
typec_port_types_drp[port->port_type]);
- return sprintf(buf, "[%s]\n", typec_port_types[port->cap->type]);
+ return sprintf(buf, "[%s]\n", typec_port_power_roles[port->cap->type]);
}
static DEVICE_ATTR_RW(port_type);
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 3/3] USB: xhci-hcd: Add get_resuming_ports method
On 08.06.2018 23:59, Alan Stern wrote: This patch adds support for the new get_resuming_ports HCD method to the xhci-hcd driver. Signed-off-by: Alan Stern CC: Mathias Nyman Acked-by: Mathias Nyman -- 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] usb: cdc_acm: Add quirk for Uniden UBC125 scanner
On Mo, 2018-06-11 at 12:39 +0200, Houston Yaroschoff wrote: > Uniden UBC125 radio scanner has USB interface which fails to work > with cdc_acm driver: > usb 1-1.5: new full-speed USB device number 4 using xhci_hcd > cdc_acm 1-1.5:1.0: Zero length descriptor references > cdc_acm: probe of 1-1.5:1.0 failed with error -22 > > Adding the NO_UNION_NORMAL quirk for the device fixes the issue: > usb 1-4: new full-speed USB device number 15 using xhci_hcd > usb 1-4: New USB device found, idVendor=1965, idProduct=0018 > usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 1-4: Product: UBC125XLT > usb 1-4: Manufacturer: Uniden Corp. > usb 1-4: SerialNumber: 0001 > cdc_acm 1-4:1.0: ttyACM0: USB ACM device > > `lsusb -v` of the device: > > Bus 001 Device 015: ID 1965:0018 Uniden Corporation > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass2 Communications > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > idVendor 0x1965 Uniden Corporation > idProduct 0x0018 > bcdDevice0.01 > iManufacturer 1 Uniden Corp. > iProduct2 UBC125XLT > iSerial 3 0001 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 48 > bNumInterfaces 2 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 500mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 2 Communications > bInterfaceSubClass 2 Abstract (modem) > bInterfaceProtocol 0 None > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x87 EP 7 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 10 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber1 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass10 CDC Data > bInterfaceSubClass 0 Unused > bInterfaceProtocol 0 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Device Status: 0x > (Bus Powered) > > Signed-off-by: Houston Yaroschoff Acked-by: Oliver Neukum -- 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] usb: cdc_acm: Add quirk for Uniden UBC125 scanner
Uniden UBC125 radio scanner has USB interface which fails to work
with cdc_acm driver:
usb 1-1.5: new full-speed USB device number 4 using xhci_hcd
cdc_acm 1-1.5:1.0: Zero length descriptor references
cdc_acm: probe of 1-1.5:1.0 failed with error -22
Adding the NO_UNION_NORMAL quirk for the device fixes the issue:
usb 1-4: new full-speed USB device number 15 using xhci_hcd
usb 1-4: New USB device found, idVendor=1965, idProduct=0018
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: UBC125XLT
usb 1-4: Manufacturer: Uniden Corp.
usb 1-4: SerialNumber: 0001
cdc_acm 1-4:1.0: ttyACM0: USB ACM device
`lsusb -v` of the device:
Bus 001 Device 015: ID 1965:0018 Uniden Corporation
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x1965 Uniden Corporation
idProduct 0x0018
bcdDevice0.01
iManufacturer 1 Uniden Corp.
iProduct2 UBC125XLT
iSerial 3 0001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 48
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0 None
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x
(Bus Powered)
Signed-off-by: Houston Yaroschoff
---
drivers/usb/class/cdc-acm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 7b366a6c0b49..998b32d0167e 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1758,6 +1758,9 @@ static const struct usb_device_id acm_ids[] = {
{ USB_DEVICE(0x11ca, 0x0201), /* VeriFone Mx870 Gadget Serial */
.driver_info = SINGLE_RX_URB,
},
+ { USB_DEVICE(0x1965, 0x0018), /* Uniden UBC125XLT */
+ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */
+ },
{ USB_DEVICE(0x22b8, 0x7000), /* Motorola Q Phone */
.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
},
--
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
Re: [PATCH] usb: xhci: increase CRS timeout value
On Do, 2018-06-07 at 11:48 -0700, Ajay Gupta wrote: > Some controllers take almost 55ms to complete controller > restore state (CRS). > There is no timeout limit mentioned in xhci specification so > fix the issue by increasing the timeout limit to 55ms Hi, the chances that you saw the true worst case are slim. I would suggest you include at least a bit of a safety margin and a comment that explains it. 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
[PATCH] usb: storage: add error handling for kcalloc
When kcalloc fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling kcalloc.
Signed-off-by: Zhouyang Jia
---
drivers/usb/storage/alauda.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c
index 900591d..c56355c 100644
--- a/drivers/usb/storage/alauda.c
+++ b/drivers/usb/storage/alauda.c
@@ -437,6 +437,11 @@ static int alauda_init_media(struct us_data *us)
+ MEDIA_INFO(us).blockshift + MEDIA_INFO(us).pageshift);
MEDIA_INFO(us).pba_to_lba = kcalloc(num_zones, sizeof(u16*), GFP_NOIO);
MEDIA_INFO(us).lba_to_pba = kcalloc(num_zones, sizeof(u16*), GFP_NOIO);
+ if ((MEDIA_INFO(us).pba_to_lba == NULL)
+ || (MEDIA_INFO(us).lba_to_pba == NULL)) {
+ pr_warn("alauda_init_media: memory allocation failed\n");
+ return USB_STOR_TRANSPORT_ERROR;
+ }
if (alauda_reset_media(us) != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
--
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
Re: [RFC PATCH v4 1/8] usb: pd: include kernel.h
On Mon, Jun 11, 2018 at 09:08:59AM +0200, Greg Kroah-Hartman wrote: > On Fri, Jun 08, 2018 at 02:29:34PM +0300, Heikki Krogerus wrote: > > Some of the macros use le16_to_cpu(). > > What macros? > > Is this causing build errors today? If so, why should it not be > included now? There are no build errors today. I'll write a better commit message for this patch. I think I need to improve the commit messages of some of the other patches in this series as well. 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: [RFC PATCH v4 1/8] usb: pd: include kernel.h
On Fri, Jun 08, 2018 at 02:29:34PM +0300, Heikki Krogerus wrote: > Some of the macros use le16_to_cpu(). What macros? Is this causing build errors today? If so, why should it not be included now? 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 v3] storage: Widen bcdDevice range for SanDisk SDDR-31 quirk
On Sun, Jun 10, 2018 at 08:54:09PM +0200, Mark Knibbs wrote: > When I re-sent the patch with tabs I accidentally left the new maximum > bcdDevice at 0x00ff. Sorry! Hopefully this is finally OK. This should not be in the change log text, please remove it. > > > The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that > was only applied for bcdDevice 0x0009, but later firmware which reports > bcdDevice 0x0022 needs it too. > > Signed-off-by: Mark Knibbs > --- > diff --git a/drivers/usb/storage/unusual_devs.h > b/drivers/usb/storage/unusual_devs.h > index 747d3a9..dfcceaf 100644 Below the --- line you should put what changed for each version of the patch, so we have an idea of what to look for when reviewing it. > --- a/drivers/usb/storage/unusual_devs.h > +++ b/drivers/usb/storage/unusual_devs.h > @@ -1044,7 +1044,7 @@ UNUSUAL_DEV( 0x0781, 0x0001, 0x0200, 0x0200, > USB_SC_SCSI, USB_PR_CB, NULL, > US_FL_SINGLE_LUN ), Tabs all worked fine here. 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 v2] arm64: dts: msm8996: Use dwc3-qcom glue driver for USB
Hi, On 6/11/2018 12:06 PM, Julien Massot wrote: Hi, On 5/31/2018 4:17 PM, Manu Gautam wrote: Move from dwc3-of-simple to dwc3-qcom glue driver to support peripheral mode which requires qscratch wrapper programming on VBUS event. I would like to test usb otg as peripheral role, but that's not clear for me which patches are required on top of linux master branch or linaro qcom-lt integration branch, or a custom branch which integrate dt-binding phy or usb related patch. Can you point me the patches I need to apply, or a branch, to test peripheral feature ? I have a branch that's based on 4.17. You can pick that. https://github.com/vivekgautam1/linux/commits/v4.17/db820c Thanks Vivek Thanks, Julien -- 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] arm64: dts: msm8996: Use dwc3-qcom glue driver for USB
Hi, > On 5/31/2018 4:17 PM, Manu Gautam wrote: >> >> Move from dwc3-of-simple to dwc3-qcom glue driver to >> support peripheral mode which requires qscratch wrapper >> programming on VBUS event. I would like to test usb otg as peripheral role, but that's not clear for me which patches are required on top of linux master branch or linaro qcom-lt integration branch, or a custom branch which integrate dt-binding phy or usb related patch. Can you point me the patches I need to apply, or a branch, to test peripheral feature ? Thanks, Julien -- *This email and any attachment thereto are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please be advised that disclosing, copying, distributing or taking any action in reliance on the contents of this email is strictly prohibited. In such case, please immediately advise the sender, and delete all copies and attachment from your system. This email shall not be construed and is not tantamount to an offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe on any discussion or contractual document whatsoever. No employee or agent is authorized to represent or bind SoftBank Robotics Europe to third parties by email, or act on behalf of SoftBank Robotics Europe by email, without express written confirmation by SoftBank Robotics Europe’ duly authorized representatives. * *Ce message électronique et éventuelles pièces jointes sont confidentiels, et exclusivement destinés à la personne ou l'entité à qui ils sont adressés. Si vous n'êtes pas le destinataire visé, vous êtes prié de ne pas divulguer, copier, distribuer ou prendre toute décision sur la foi de ce message électronique. Merci d'en aviser immédiatement l'expéditeur et de supprimer toutes les copies et éventuelles pièces jointes de votre système. Ce message électronique n'équivaut pas à une offre, à une acceptation d’offre, ou à un accord de SoftBank Robotics Europe sur toute discussion ou document contractuel quel qu’il soit, et ne peut être interprété comme tel. Aucun employé ou agent de SoftBank Robotics Europe n'est autorisé à représenter ou à engager la société par email, ou à agir au nom et pour le compte de la société par email, sans qu’une confirmation écrite soit donnée par le représentant légal de SoftBank Robotics Europe ou par toute autre personne ayant reçu délégation de pouvoir appropriée. * ** -- 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
