Re: [PATCH] ftdi_sio: add Id for Physik Instrumente E-870
On Thu, Mar 29, 2018 at 08:39:37AM +0200, Teichmann, Martin wrote: > This adds support for the Physik Instrumente E-870 PIShift Drive > Electronics, a Piezo motor driver. > > Signed-off-by: Martin Teichmann Now applied with an updated commit summary (prefix). Thanks, Johan -- 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: chipidea: Don't select EXTCON
Not all chipidea users need EXTCON, so it's better to avoid unconditionally select EXTCON, this could save us 2KB kernel Image size. Signed-off-by: Jisheng Zhang --- drivers/usb/chipidea/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index 785f0ed037f7..97509172d536 100644 --- a/drivers/usb/chipidea/Kconfig +++ b/drivers/usb/chipidea/Kconfig @@ -1,7 +1,6 @@ config USB_CHIPIDEA tristate "ChipIdea Highspeed Dual Role Controller" depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA - select EXTCON select RESET_CONTROLLER help Say Y here if your system has a dual role high speed USB -- 2.16.3 -- 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
[GIT PULL] USB-serial updates for v4.17-rc1
The following changes since commit 4a3928c6f8a53fa1aed28ccba227742486e8ddcb: Linux 4.16-rc3 (2018-02-25 18:50:41 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-4.17-rc1 for you to fetch changes up to 79a0b33165d8d8ec0840fcfc74fd0a8f219abeee: USB: serial: ftdi_sio: add Id for Physik Instrumente E-870 (2018-03-29 10:06:45 +0200) USB-serial updates for v4.17-rc1 Here are the USB-serial updates for 4.17-rc1, including a reimplementation of the option-driver interface masking which allows for a more compact notation when adding new device entries. Included are also a couple of clean ups and a new ftdi_sio device id. All but the device-id commit have been in linux-next (without any reported issues). Signed-off-by: Johan Hovold Johan Hovold (3): USB: serial: option: reimplement interface masking USB: serial: option: drop redundant interface-class test USB: serial: option: use mass-storage class define Teichmann, Martin (1): USB: serial: ftdi_sio: add Id for Physik Instrumente E-870 drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 1 + drivers/usb/serial/option.c | 457 +- 3 files changed, 155 insertions(+), 304 deletions(-) -- 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: musb: Support gadget mode when the port is set to dual role
On Wed, Mar 28, 2018 at 11:52:13PM +0200, Paul Kocialkowski wrote: > This allows dual-role ports to be reported as having gadget mode by the > musb_has_gadget helper. This is required to enable MUSB at all with MUSB > glue layers that set the port mode to MUSB_PORT_MODE_DUAL_ROLE at init. > > Most notably, this allows calling musb_start when needed in the virtual > MUSB root HUB, regardless of whether the current mode should be gadget > or host. > > This fixes USB OTG on Allwinner devices that I could test it with, > mainly A20 devices. > > Signed-off-by: Paul Kocialkowski Surely there's more to it than that. The gadget mode of A20 boards have been working in the past, including when compiling with mUSB setup as dual role. Is this a regression since a particular commit? Or is there another, deeper issue overlooked in the commit log? Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [GIT PULL] USB-serial updates for v4.17-rc1
On Thu, Mar 29, 2018 at 11:10:41AM +0200, Johan Hovold wrote: > The following changes since commit 4a3928c6f8a53fa1aed28ccba227742486e8ddcb: > > Linux 4.16-rc3 (2018-02-25 18:50:41 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git > tags/usb-serial-4.17-rc1 Pulled and pushed out, 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
[PATCH 2/5] usb: chipidea: usbmisc: evdo can be set e/o reset
From: Michael Trimarchi
evdo bit can be set or reset. We can not trust evdo bit
status after bootloader stage
Signed-off-by: Michael Trimarchi
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/usbmisc_imx.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index a52f5a8..1f47ef6 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -151,14 +151,18 @@ static int usbmisc_imx25_post(struct imx_usbmisc_data
*data)
if (data->index)
return 0;
- if (data->evdo) {
- spin_lock_irqsave(&usbmisc->lock, flags);
- reg = usbmisc->base + MX25_USB_PHY_CTRL_OFFSET;
- val = readl(reg);
- writel(val | MX25_BM_EXTERNAL_VBUS_DIVIDER, reg);
- spin_unlock_irqrestore(&usbmisc->lock, flags);
- usleep_range(5000, 1); /* needed to stabilize voltage */
- }
+ spin_lock_irqsave(&usbmisc->lock, flags);
+ reg = usbmisc->base + MX25_USB_PHY_CTRL_OFFSET;
+ val = readl(reg);
+
+ if (data->evdo)
+ val |= MX25_BM_EXTERNAL_VBUS_DIVIDER;
+ else
+ val &= ~MX25_BM_EXTERNAL_VBUS_DIVIDER;
+
+ writel(val, reg);
+ spin_unlock_irqrestore(&usbmisc->lock, flags);
+ usleep_range(5000, 1); /* needed to stabilize voltage */
return 0;
}
--
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 3/5] usb: chipidea: usbmisc: small clean up
From: Michael Trimarchi
The register write can be done outside the if and else condition
Signed-off-by: Michael Trimarchi
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/usbmisc_imx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 1f47ef6..34ad5bf 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -315,13 +315,12 @@ static int usbmisc_imx6q_set_wakeup
val = readl(usbmisc->base + data->index * 4);
if (enabled) {
val |= wakeup_setting;
- writel(val, usbmisc->base + data->index * 4);
} else {
if (val & MX6_BM_WAKEUP_INTR)
pr_debug("wakeup int at ci_hdrc.%d\n", data->index);
val &= ~wakeup_setting;
- writel(val, usbmisc->base + data->index * 4);
}
+ writel(val, usbmisc->base + data->index * 4);
spin_unlock_irqrestore(&usbmisc->lock, flags);
return ret;
--
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 1/5] usb: chipidea: usbmisc: evdo is only specific to OTG port
From: Michael Trimarchi
The USB_PHY_CTRL_FUNC is used specific for OTG port as described
in user manual. EVDO need to be set only for index 0 that
correspond to OTG port
Signed-off-by: Michael Trimarchi
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/usbmisc_imx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 8cdf0af1..a52f5a8 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -148,6 +148,9 @@ static int usbmisc_imx25_post(struct imx_usbmisc_data *data)
if (data->index > 2)
return -EINVAL;
+ if (data->index)
+ return 0;
+
if (data->evdo) {
spin_lock_irqsave(&usbmisc->lock, flags);
reg = usbmisc->base + MX25_USB_PHY_CTRL_OFFSET;
--
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 0/5] usb: chipidea: updates for v4.17-rc1
Hi Greg, This series including the bug fix for imx53 and some cleanups. Due to network problem during nxp and qualcomm merge, I can't do ssh for kernel.org currently, I am sorry I can't upload my code, then can't send pull request either. I hope ssh access can be recovered soon. Thanks. Michael Trimarchi (3): usb: chipidea: usbmisc: evdo is only specific to OTG port usb: chipidea: usbmisc: evdo can be set e/o reset usb: chipidea: usbmisc: small clean up Sebastian Reichel (2): usb: chipidea: imx: Cleanup ci_hdrc_imx_platform_flag usb: chipidea: imx: Fix ULPI on imx53 drivers/usb/chipidea/ci_hdrc_imx.c | 15 +-- drivers/usb/chipidea/usbmisc_imx.c | 26 -- 2 files changed, 29 insertions(+), 12 deletions(-) -- 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 4/5] usb: chipidea: imx: Cleanup ci_hdrc_imx_platform_flag
From: Sebastian Reichel
Some trivial cleanups, that do not change functionality.
Signed-off-by: Sebastian Reichel
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 3b45c25f..de155c8 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -20,7 +20,6 @@
struct ci_hdrc_imx_platform_flag {
unsigned int flags;
- bool runtime_pm;
};
static const struct ci_hdrc_imx_platform_flag imx23_usb_data = {
@@ -29,7 +28,7 @@ static const struct ci_hdrc_imx_platform_flag imx23_usb_data
= {
};
static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
- CI_HDRC_DISABLE_STREAMING,
+ .flags = CI_HDRC_DISABLE_STREAMING,
};
static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
--
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 5/5] usb: chipidea: imx: Fix ULPI on imx53
From: Sebastian Reichel
Traditionally, PORTSC should be set before initializing ULPI phys. But
setting PORTSC before powering on the phy results in a kernel freeze
on imx53 based GE PPD. As a workaround this initializes the phy early
in the imx platform code and disables phy power management from the
core.
Signed-off-by: Fabien Lahoudere
Signed-off-by: Sebastian Reichel
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index de155c8..e431c5a 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -83,6 +83,7 @@ struct ci_hdrc_imx_data {
struct clk *clk;
struct imx_usbmisc_data *usbmisc_data;
bool supports_runtime_pm;
+ bool override_phy_control;
bool in_lpm;
/* SoC before i.mx6 (except imx23/imx28) needs three clks */
bool need_three_clks;
@@ -254,6 +255,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
int ret;
const struct of_device_id *of_id;
const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
+ struct device_node *np = pdev->dev.of_node;
of_id = of_match_device(ci_hdrc_imx_dt_ids, &pdev->dev);
if (!of_id)
@@ -288,6 +290,14 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
}
pdata.usb_phy = data->phy;
+
+ if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
+ of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
+ pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
+ data->override_phy_control = true;
+ usb_phy_init(pdata.usb_phy);
+ }
+
pdata.flags |= imx_platform_flag->flags;
if (pdata.flags & CI_HDRC_SUPPORTS_RUNTIME_PM)
data->supports_runtime_pm = true;
@@ -341,6 +351,8 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
pm_runtime_put_noidle(&pdev->dev);
}
ci_hdrc_remove_device(data->ci_pdev);
+ if (data->override_phy_control)
+ usb_phy_shutdown(data->phy);
imx_disable_unprepare_clks(&pdev->dev);
return 0;
--
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: [PATCH 0/5] usb: chipidea: updates for v4.17-rc1
On Thu, Mar 29, 2018 at 05:52:44PM +0800, Peter Chen wrote: > Hi Greg, > > This series including the bug fix for imx53 and some cleanups. > Due to network problem during nxp and qualcomm merge, I can't > do ssh for kernel.org currently, I am sorry I can't upload my > code, then can't send pull request either. I hope ssh access > can be recovered soon. Thanks. Not a problem, patches work just fine :) 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 v4 07/13] staging: typec: tcpci: register port before request irq
On Thu, Mar 29, 2018 at 12:06:12AM +0800, Li Jun wrote:
> 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
These sign offs aren't clear.
Sign offs mean that you handled the patch but didn't include any of
SCO's copyrighted UNIX code into it. Normally they're in the order of
who touched the code. So Peter touched the code first. Should he get
authorship credit? How did he touch the code first if he didn't write
the code? It doesn't make sense.
> ---
> drivers/staging/typec/tcpci.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 4f7ad10..9e0014b 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -537,25 +537,26 @@ 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, &val,
> sizeof(u16));
> if (err < 0)
> return err;
>
> + chip->tcpci = tcpci_register_port(&client->dev, &chip->data);
> + if (PTR_ERR_OR_ZERO(chip->tcpci))
> + return PTR_ERR(chip->tcpci);
When a function returns both error pointers and NULL that means that
NULL is a secial case of success. Like for example:
p->my_feature = get_optional_feature();
If it returns NULL that means the optional feature isn't there, but it's
fine because it's optional. But if it returns an error pointer that
means the feature is there but the hardware is buggy or something so
we shouldn't continue.
If you return PTR_ERR(NULL) that means success.
I don't think this code makes sense just from looking at it and also
when I checked tcpci_register_port() doesn't return NULL.
> +
> err = devm_request_threaded_irq(&client->dev, client->irq, NULL,
> _tcpci_irq,
> IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> dev_name(&client->dev), chip);
> if (err < 0)
> - return err;
> + tcpci_unregister_port(chip->tcpci);
Can you put the "return err;" back, because that's better style. It's
better to keep the error path and success path separate if you can.
if (err < 0) {
tcpci_unregister_port(chip->tcpci);
return err;
}
return 0;
regards,
dan carpenter
--
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
Sorry, Patch wrong (was: patch "USB: serial: ftdi_sio: add Id for Physik Instrumente E-870" added to usb-testing)
Dear Greg, dear Johan, dear list,
I'm very sorry I was a bit quick in sending you a patch for the PI E-870
device, because it's actually wrong. Everything seemed to work fine, until I
realized that once in a while two characters were missing. Checking dmesg I
realized error messages had piled up. It turns out, the device is not
compatible with the ftdi_sio driver in the end. I hope this can be undone...
The device, however works with a usb-serial-simple driver. Unfortunately, it is
not as easy as for the E-870 to supply a patch, as usb-serial-simple does not
just contain a list of VID and PIDs, but actually creates a new entry somewhere
in /sys/bus for each vendor. I would like to send in patch for this later, but
this time properly tested...
Sincerely Yours
Martin Teichmann
- Original Message -
From: "Greg KH"
To: "martin teichmann" , "Johan Hovold"
, sta...@vger.kernel.org
Sent: Thursday, 29 March, 2018 11:24:18
Subject: patch "USB: serial: ftdi_sio: add Id for Physik Instrumente E-870"
added to usb-testing
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: add Id for Physik Instrumente E-870
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the usb-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 79a0b33165d8d8ec0840fcfc74fd0a8f219abeee Mon Sep 17 00:00:00 2001
From: "Teichmann, Martin"
Date: Thu, 29 Mar 2018 08:39:37 +0200
Subject: USB: serial: ftdi_sio: add Id for Physik Instrumente E-870
This adds support for the Physik Instrumente E-870 PIShift Drive
Electronics, a Piezo motor driver.
Signed-off-by: Martin Teichmann
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index f58c4ff6b387..85774cf4cc8f 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -893,6 +893,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(PI_VID, PI_1014_PID) },
{ USB_DEVICE(PI_VID, PI_1015_PID) },
{ USB_DEVICE(PI_VID, PI_1016_PID) },
+ { USB_DEVICE(PI_VID, PI_E870_PID) },
{ USB_DEVICE(KONDO_VID, KONDO_USB_SERIAL_PID) },
{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 8b4ecd2bd297..14dff44a2a93 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -978,6 +978,7 @@
#define PI_1014_PID0x1014 /* PI Device */
#define PI_1015_PID0x1015 /* PI Device */
#define PI_1016_PID0x1016 /* PI Digital Servo Module */
+#define PI_E870_PID0x1019 /* PI E-870 Piezomotor Controller */
/*
* Kondo Kagaku Co.Ltd.
--
2.16.3
--
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: musb: Support gadget mode when the port is set to dual role
Hi,
On Thu, 2018-03-29 at 11:23 +0200, Maxime Ripard wrote:
> On Wed, Mar 28, 2018 at 11:52:13PM +0200, Paul Kocialkowski wrote:
> > This allows dual-role ports to be reported as having gadget mode by
> > the
> > musb_has_gadget helper. This is required to enable MUSB at all with
> > MUSB
> > glue layers that set the port mode to MUSB_PORT_MODE_DUAL_ROLE at
> > init.
> >
> > Most notably, this allows calling musb_start when needed in the
> > virtual
> > MUSB root HUB, regardless of whether the current mode should be
> > gadget
> > or host.
> >
> > This fixes USB OTG on Allwinner devices that I could test it with,
> > mainly A20 devices.
> >
> > Signed-off-by: Paul Kocialkowski
>
> Surely there's more to it than that. The gadget mode of A20 boards
> have been working in the past, including when compiling with mUSB
> setup as dual role.
>
> Is this a regression since a particular commit? Or is there another,
> deeper issue overlooked in the commit log?
The root of the issue here is that musb_start is not called at any point
without this patch. My understanding of the flow is the following: when
the PHY detects that there was a VBUS/ID change, it will notify its
listeners (mainly the musb sunxi glue layer). This will then schedule
the driver's work (sunxi_musb_work), which does nothing since the
SUNXI_MUSB_FL_ENABLED bit was never set. This bit is only set after
calling sunxi_musb_enable, which is called from musb_platform_enable,
that originates from musb_start.
Currently I see two places where musb_start is called:
* musb_virthub
* musb_gadget
In the latter case, it is in turn called from udc_start, which should
probably (correct me if I'm wrong) happen later in the call chain than
ID/VBUS change notification time.
In the former case, musb_start is called in the root controller hub
control, when setting the USB_PORT_FEAT_POWER feature. This looks
perfectly legit and IMO this is where it should be initially calling
musb_start in the dual role case. The kernel is indeed setting the
feature, only that it fails to enable musb without this patch.
First, I'd like to make sure that this understanding of the flow is
correct as I may have missed something here. Does it make sense?
Then, it seems that the offending commit is: be9d39881fc4f
("usb: musb: host: rely on port_mode to call musb_start()")
That itself fixed: ae44df2e21b5
("usb: musb: call musb_start() only once in OTG mode")
Still, this commit was authored in June 2015, so almost 3 years ago.
In the meantime, the sunxi driver has received feature improvements, so
it seems hard to believe that it was broken all this time...
Cheers,
signature.asc
Description: This is a digitally signed message part
[PATCH] Revert "USB: serial: ftdi_sio: add Id for Physik Instrumente E-870"
This reverts commit 79a0b33165d8d8ec0840fcfc74fd0a8f219abeee.
Turns out this is not an FTDI device after all.
Reported-by: Martin Teichmann
Cc: stable
Signed-off-by: Johan Hovold
---
Greg,
I included the stable tag above as the offending patch had it, but I
will try to remember to speak out in case it gets added to the stable
queue in the first place.
Thanks,
Johan
drivers/usb/serial/ftdi_sio.c | 1 -
drivers/usb/serial/ftdi_sio_ids.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 85774cf4cc8f..f58c4ff6b387 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -893,7 +893,6 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(PI_VID, PI_1014_PID) },
{ USB_DEVICE(PI_VID, PI_1015_PID) },
{ USB_DEVICE(PI_VID, PI_1016_PID) },
- { USB_DEVICE(PI_VID, PI_E870_PID) },
{ USB_DEVICE(KONDO_VID, KONDO_USB_SERIAL_PID) },
{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 14dff44a2a93..8b4ecd2bd297 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -978,7 +978,6 @@
#define PI_1014_PID0x1014 /* PI Device */
#define PI_1015_PID0x1015 /* PI Device */
#define PI_1016_PID0x1016 /* PI Digital Servo Module */
-#define PI_E870_PID0x1019 /* PI E-870 Piezomotor Controller */
/*
* Kondo Kagaku Co.Ltd.
--
2.16.3
--
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: Sorry, Patch wrong (was: patch "USB: serial: ftdi_sio: add Id for Physik Instrumente E-870" added to usb-testing)
On Thu, Mar 29, 2018 at 01:49:02PM +0200, Teichmann, Martin wrote: > Dear Greg, dear Johan, dear list, > > I'm very sorry I was a bit quick in sending you a patch for the PI > E-870 device, because it's actually wrong. Everything seemed to work > fine, until I realized that once in a while two characters were > missing. Checking dmesg I realized error messages had piled up. It > turns out, the device is not compatible with the ftdi_sio driver in > the end. I hope this can be undone... No worries, I just sent a revert patch to Greg. > The device, however works with a usb-serial-simple driver. > Unfortunately, it is not as easy as for the E-870 to supply a patch, > as usb-serial-simple does not just contain a list of VID and PIDs, but > actually creates a new entry somewhere in /sys/bus for each vendor. I > would like to send in patch for this later, but this time properly > tested... Try first to determine what chip this really is (e.g. by opening the device). Chances are there's already a driver for it. Full "lsusb -v" might also give some clues. Thanks, Johan -- 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 v4 04/13] usb: typec: add fwnode to tcpc
Hi,
On Thu, Mar 29, 2018 at 12:06:09AM +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
> ---
> drivers/staging/typec/tcpci.c | 14 +++---
> drivers/usb/typec/tcpm.c | 1 +
> include/linux/usb/tcpm.h | 2 ++
> 3 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index ed76327..4f7ad10 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -463,17 +464,16 @@ 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 = &tcpci_tcpc_config;
That will break bisectablitity. tcpm.c is still accessing the config
at this point.
Just leave those untouched in here, and clean-up in separate patch
that comes after the patch that prepares tcpm.c.
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: Wakeup from USB on i.MX6S
Hi and sorry for the long time to the new answere. I think meanwhile I've lost the trust in that I'm able to get this wakeup on usb plugin running properly by myself. And, of course, there was a lot of work besides that wakeup problem. Meanwhile our board supplier classified our wish as a special custom feature and won't "implement"/"fix" it for free. :) > Would you measure the DP/DM signal between HUB and i.mx6 after echo mem > to /sys/power/state? Besides, does the HUB will be re-enumerated after > mem-sleep? Would you show me some kernel log during suspend/resume > for mem-sleep? I'm afraid I don't have the right equipment to measure a signal on a connector with 320 pins spread over 8 cm while the correct signal seems to be on the underside of 2 boards laying parallel on each other. :) But of course I can show you the logs. I hope, with "kernel log" you meant "var/logs/messages". The other files in /var/logs are not being changed during the sleep/wakeup process process. 1st The logs of mem-sleep + resume when only the wakeup button and serial input is enabled as wakeup source. I woke it up using serial input. Mar 26 13:18:23 emtrion-mx6 user.info kernel: [ 1131.540666] PM: Syncing filesystems ... done. Mar 26 13:18:23 emtrion-mx6 user.debug kernel: [ 1131.713587] PM: Preparing system for sleep (mem) Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1131.731182] Freezing user space processes ... (elapsed 0.007 seconds) done. Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1131.741783] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. Mar 26 13:18:35 emtrion-mx6 user.debug kernel: [ 1131.752465] PM: Suspending system (mem) Mar 26 13:18:35 emtrion-mx6 user.warn kernel: [ 1131.752481] windows pfad zu datei kopierenfsdggsfdgsgsdfsdgsfsdsfdSuspending console(s) (use no_console_suspend to debug) Mar 26 13:18:35 emtrion-mx6 user.err kernel: [ 1131.891004] fec 2188000.ethernet eth0: Graceful transmit stop did not complete! Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1131.893766] PM: suspend of devices complete after 120.759 msecs Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1131.893786] PM: suspend devices took 0.140 seconds Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1131.916027] PM: late suspend of devices complete after 22.201 msecs Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1131.937767] PM: noirq suspend of devices complete after 21.697 msecs Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1131.937786] Disabling non-boot CPUs ... Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1132.252197] PM: noirq resume of devices complete after 314.183 msecs Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1132.270129] PM: early resume of devices complete after 16.491 msecs Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1132.334240] Suspended for 10.646 seconds Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1132.403717] PM: resume of devices complete after 133.549 msecs Mar 26 13:18:35 emtrion-mx6 user.err kernel: [ 1132.419340] fsl-asoc-card sound: ASoC: CODEC DAI sgtl5000 not registered Mar 26 13:18:35 emtrion-mx6 user.err kernel: [ 1132.419361] fsl-asoc-card sound: snd_soc_register_card failed (-517) Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1132.419467] PM: resume devices took 0.140 seconds Mar 26 13:18:35 emtrion-mx6 user.debug kernel: [ 1132.494804] PM: Finishing wakeup. Mar 26 13:18:35 emtrion-mx6 user.info kernel: [ 1132.494811] Restarting tasks ... done. Mar 26 13:18:44 emtrion-mx6 user.info kernel: [ 1141.658428] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx 2nd the logs with all wakeup sources enabled which results in abnormal wakeup: Mar 26 13:22:48 emtrion-mx6 user.info kernel: [ 1385.770596] PM: Syncing filesystems ... done.<\r><\n> Mar 26 13:22:48 emtrion-mx6 user.debug kernel: [ 1385.943617] PM: Preparing system for sleep (mem)<\r><\n> Mar 26 13:22:49 emtrion-mx6 user.info kernel: [ 1385.961206] Freezing user space processes ... (elapsed 0.007 seconds) done.<\r><\n> Mar 26 13:22:49 emtrion-mx6 user.info kernel: [ 1385.972191] Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.<\r><\n> Mar 26 13:22:49 emtrion-mx6 user.debug kernel: [ 1385.983700] PM: Suspending system (mem)<\r><\n> Mar 26 13:22:49 emtrion-mx6 user.warn kernel: [ 1385.983716] Suspending console(s) (use no_console_suspend to debug)<\r><\n> Mar 26 13:22:49 emtrion-mx6 user.err kernel: [ 1386.081787] fec 2188000.ethernet eth0: Graceful transmit stop did not complete!<\r><\n> Mar 26 13:22:49 emtrion-mx6 user.info kernel: [ 1386.083278] PM: suspend of devices complete after 84.635 msecs<\r><\n> Mar 26 13:22:49 emtrion-mx6 user.info kernel: [ 1386.083287] PM: suspend devices took 0.090 seconds<\r><\n> Mar 26 13:22:49 emtrion-mx6 user.info kernel: [ 1386.094787] PM: late suspend of devices complete after 11.477 msecs<\r><\n> Mar 26 13:22:49 emtrion-mx6 user.info kernel: [ 1386.106324] PM: noirq suspend of devices comp
[PATCH v2 1/3] usb: dwc2: Enable BNA interrupt for IN endpoints
In DDMA mode required to enable BNA interrupt for
both directions.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 6c32bf26e48e..c231321656f9 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3320,8 +3320,10 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
hsotg->regs + DOEPMSK);
/* Enable BNA interrupt for DDMA */
- if (using_desc_dma(hsotg))
+ if (using_desc_dma(hsotg)) {
dwc2_set_bit(hsotg->regs + DOEPMSK, DOEPMSK_BNAMSK);
+ dwc2_set_bit(hsotg->regs + DIEPMSK, DIEPMSK_BNAININTRMSK);
+ }
dwc2_writel(0, hsotg->regs + DAINTMSK);
--
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 v2 0/3] usb: dwc2: gadget: Update ISOC DDMA flow.
This series fully update existing ISOC DDMA flow which initially based on 2 descriptor chains. Switching between desc chains performing based on BNA interrupt. Because of BNA interrupt few packets can be lost. 1/3 patch unmask ISOC IN BNA interrupt only. 2/3 patch changing ISOC IN/OUT flow as described above. 3/3 patch add High bandwidth ISOC OUT transfers support. All patches were tested on HAPS-DX7 platform using internal USB test tool. Changes from version 1: In patch 2/3 removed redundant warning print in dwc2_hsotg_ep_queue() (Zengtao (B) ) In patch 2/3 replace loop counter from 'ret' to 'i' in dwc2_gadget_start_isoc_ddma() (Zengtao (B) ) In patch 3/3 fix 2 kbuild test robot warnings. In patch 3/3 updated target_frame number width from 11-bit to 14-bit. In patches 2/3 and 3/3 updated all requests completion status codes to 0 instead of error codes (ENODATA, EIO, ETIMEDOUT). In case of errors, set request actual length to 0, to keep consistency with original code. Changes from version 0: Fix kbuild test robot warnings on idents. Minas Harutyunyan (3): usb: dwc2: Enable BNA interrupt for IN endpoints usb: dwc2: Change ISOC DDMA flow usb: dwc2: Add High Bandwidth ISOC OUT support drivers/usb/dwc2/core.h | 2 - drivers/usb/dwc2/gadget.c | 498 -- 2 files changed, 348 insertions(+), 152 deletions(-) -- 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 v2 2/3] usb: dwc2: Change ISOC DDMA flow
Changed existing two descriptor-chain flow to one chain.
In two-chain implementation BNA interrupt used for switching between
two chains. BNA interrupt asserted because of returning to
beginning of the chain based on L-bit of last descriptor.
Because of that we lose packets. This issue resolved by using one
desc-chain.
Removed all staff related to two desc-chain flow from
DDMA ISOC related functions.
Removed request length checking from dwc2_gadget_fill_isoc_desc()
function. Request length checking added to dwc2_hsotg_ep_queue()
function. If request length greater than descriptor limits then
request not added to queue. Additional checking done for High
Bandwidth ISOC OUT's which not supported by driver. In
dwc2_gadget_fill_isoc_desc() function also checked desc-chain
status (full or not) to avoid of reusing not yet processed
descriptors.
In dwc2_gadget_start_isoc_ddma() function creation of desc-chain
always started from descriptor 0. Before filling descriptors, they
were initialized by HOST BUSY status.
In dwc2_gadget_complete_isoc_request_ddma() added checking for
desc-chain rollover. Also added checking completion status.
Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC,
otherwise complete with actual=0.
Actually removed dwc2_gadget_start_next_isoc_ddma() function because
now driver use only one desc-chain and instead that function added
dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts.
Handling BNA interrupt done by flushing TxFIFOs for OUT EPs,
completing request with actual=0 and resetting desc-chain number and
target frame to initial values for restarting transfers.
On handling NAK request completed with actual=0. Incremented target
frame to allow fill desc chain and start transfers.
In DDMA mode avoided of frame number incrementing, because tracking
of frame number performed in dwc2_gadget_fill_isoc_desc() function.
When core assert XferCompl along with BNA, we should ignore XferCompl
in dwc2_hsotg_epint() function.
On BNA interrupt replaced dwc2_gadget_start_next_isoc_ddma() by above
mentioned BNA handler.
In dwc2_hsotg_ep_enable() function added sanity check of bInterval
for ISOC IN in DDMA mode, because HW not supported EP's with
bInterval more than 12.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/core.h | 2 -
drivers/usb/dwc2/gadget.c | 234 +-
2 files changed, 109 insertions(+), 127 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index d83be5651f87..093d078adaf4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -178,7 +178,6 @@ struct dwc2_hsotg_req;
* @desc_list_dma: The DMA address of descriptor chain currently in use.
* @desc_list: Pointer to descriptor DMA chain head currently in use.
* @desc_count: Count of entries within the DMA descriptor chain of EP.
- * @isoc_chain_num: Number of ISOC chain currently in use - either 0 or 1.
* @next_desc: index of next free descriptor in the ISOC chain under SW
control.
* @total_data: The total number of data bytes done.
* @fifo_size: The size of the FIFO (for periodic IN endpoints)
@@ -231,7 +230,6 @@ struct dwc2_hsotg_ep {
struct dwc2_dma_desc*desc_list;
u8 desc_count;
- unsigned char isoc_chain_num;
unsigned intnext_desc;
charname[10];
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c231321656f9..d6a57606e49f 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -793,9 +793,7 @@ static void dwc2_gadget_config_nonisoc_xfer_ddma(struct
dwc2_hsotg_ep *hs_ep,
* @dma_buff: usb requests dma buffer.
* @len: usb request transfer length.
*
- * Finds out index of first free entry either in the bottom or up half of
- * descriptor chain depend on which is under SW control and not processed
- * by HW. Then fills that descriptor with the data of the arrived usb request,
+ * Fills next free descriptor with the data of the arrived usb request,
* frame info, sets Last and IOC bits increments next_desc. If filled
* descriptor is not the first one, removes L bit from the previous descriptor
* status.
@@ -810,34 +808,17 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 mask = 0;
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
- if (len > maxsize) {
- dev_err(hsotg->dev, "wrong len %d\n", len);
- return -EINVAL;
- }
-
- /*
-* If SW has already filled half of chain, then return and wait for
-* the other chain to be processed by HW.
-*/
- if (hs_ep->next_desc == MAX_DMA_DESC_NUM_GENERIC / 2)
- return -EBUSY;
- /* Increment frame number by interval for IN */
- if (hs_ep->dir_in)
- dwc2_gadget_incr_frame_num(hs_ep);
-
- index = (MAX_DMA_DESC_NUM_GENERIC / 2) * hs_ep->isoc_ch
[PATCH v2 3/3] usb: dwc2: Add High Bandwidth ISOC OUT support
Updated checking of chain full condition based on mult count.
For each packet in uframe (dpi) created new desc by
setting size of transfer to mps. Buffer addresses in descs
differ by mps in function dwc2_gadget_fill_isoc_desc().
In function dwc2_gadget_start_isoc_ddma() upadted loop
boundaries according to desc chain length.
In function dwc2_hsotg_ep_queue() added request length
checking for HB ISOC OUT transfers. Added dword aligned
limitation on maxpacket size for HB ISOC OUT's.
In function dwc2_gadget_complete_isoc_request_ddma()
separated processing of descs for HB ISOC OUT.
If completed descs PID equal MDATA do nothing, else
get remaining for frame descs and process them.
Actual length accumulated based on descs. Break
execution of the loop if data packet PID not MDATA.
If host sends less than mult data packets then skipping
unused desc for current uframe by restarting ISOC transfers.
In function dwc2_hsotg_ep_enable() desc chain allocation/
deallocation increased by mult times. Added bInterval
limit checking for HB ISOC OUT because on completion frame
number from desc used to check frame elapsed or no.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 344 +-
1 file changed, 278 insertions(+), 66 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d6a57606e49f..c0db308e3665 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -806,55 +806,82 @@ static int dwc2_gadget_fill_isoc_desc(struct
dwc2_hsotg_ep *hs_ep,
u32 index;
u32 maxsize = 0;
u32 mask = 0;
+ u8 dpi, i;
+ /* Get descritor length limits */
maxsize = dwc2_gadget_get_desc_params(hs_ep, &mask);
index = hs_ep->next_desc;
- desc = &hs_ep->desc_list[index];
+
+ dpi = 1;
+ if (!hs_ep->dir_in)
+ dpi = hs_ep->mc;
/* Check if descriptor chain full */
- if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
- DEV_DMA_BUFF_STS_HREADY) {
- dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
- return 1;
+ for (i = 0; i < dpi; i++) {
+ /* Check descriptor chain rollover */
+ if ((index + i) >= dpi * MAX_DMA_DESC_NUM_GENERIC)
+ index = -1;
+
+ desc = &hs_ep->desc_list[index + i];
+ if ((desc->status >> DEV_DMA_BUFF_STS_SHIFT) ==
+ DEV_DMA_BUFF_STS_HREADY) {
+ dev_dbg(hsotg->dev, "%s: desc chain full\n", __func__);
+ return 1;
+ }
}
- /* Clear L bit of previous desc if more than one entries in the chain */
- if (hs_ep->next_desc)
- hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
+ for (i = 0; i < dpi; i++) {
+ index = hs_ep->next_desc;
- dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc # %d\n",
- __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out", index);
+ /* Clear L bit of previous desc if more
+* than one entries in the chain
+*/
+ if (hs_ep->next_desc)
+ hs_ep->desc_list[index - 1].status &= ~DEV_DMA_L;
- desc->status = 0;
- desc->status |= (DEV_DMA_BUFF_STS_HBUSY << DEV_DMA_BUFF_STS_SHIFT);
+ desc = &hs_ep->desc_list[index];
- desc->buf = dma_buff;
- desc->status |= (DEV_DMA_L | DEV_DMA_IOC |
-((len << DEV_DMA_NBYTES_SHIFT) & mask));
+ dev_dbg(hsotg->dev, "%s: Filling ep %d, dir %s isoc desc #
%d\n",
+ __func__, hs_ep->index, hs_ep->dir_in ? "in" : "out",
+ index);
- if (hs_ep->dir_in) {
- desc->status |= ((hs_ep->mc << DEV_DMA_ISOC_PID_SHIFT) &
-DEV_DMA_ISOC_PID_MASK) |
- ((len % hs_ep->ep.maxpacket) ?
-DEV_DMA_SHORT : 0) |
- ((hs_ep->target_frame <<
- DEV_DMA_ISOC_FRNUM_SHIFT) &
-DEV_DMA_ISOC_FRNUM_MASK);
- }
+ desc->status = 0;
+ desc->status |= (DEV_DMA_BUFF_STS_HBUSY <<
+ DEV_DMA_BUFF_STS_SHIFT);
- desc->status &= ~DEV_DMA_BUFF_STS_MASK;
- desc->status |= (DEV_DMA_BUFF_STS_HREADY << DEV_DMA_BUFF_STS_SHIFT);
+ desc->buf = dma_buff + i * hs_ep->ep.maxpacket;
+ desc->status |= (DEV_DMA_L | DEV_DMA_IOC);
+ if (hs_ep->dir_in)
+ desc->status |= ((len << DEV_DMA_NBYTES_SHIFT)
+ & mask);
+ else
+ desc->status |= ((hs_ep->ep.maxpacket <<
+ DEV_DMA_NBYTES_SHIFT) & mask);
+
+ if (hs_
[PATCH] usb: musb: gadget: misplaced out of bounds check
From: Heinrich Schuchardt
musb->endpoints[] has array size MUSB_C_NUM_EPS.
We must check array bounds before accessing the array and not afterwards.
Signed-off-by: Heinrich Schuchardt
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_gadget_ep0.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index 18da4873e52e..91a5027b5c1f 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -89,15 +89,19 @@ static int service_tx_status_request(
}
is_in = epnum & USB_DIR_IN;
- if (is_in) {
- epnum &= 0x0f;
+ epnum &= 0x0f;
+ if (epnum >= MUSB_C_NUM_EPS) {
+ handled = -EINVAL;
+ break;
+ }
+
+ if (is_in)
ep = &musb->endpoints[epnum].ep_in;
- } else {
+ else
ep = &musb->endpoints[epnum].ep_out;
- }
regs = musb->endpoints[epnum].regs;
- if (epnum >= MUSB_C_NUM_EPS || !ep->desc) {
+ if (!ep->desc) {
handled = -EINVAL;
break;
}
--
1.9.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] musb patches for v4.17-rc1
Hi Greg, Here is one musb patch for v4.17 rc, which fixes an improper array boundary check. Please let me know if any change is needed. regards, -Bin. --- Heinrich Schuchardt (1): usb: musb: gadget: misplaced out of bounds check drivers/usb/musb/musb_gadget_ep0.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) -- 1.9.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
Re: [PATCH] usb: musb: gadget: misplaced out of bounds check
On Thu, Mar 29, 2018 at 10:48:28AM -0500, Bin Liu wrote: > From: Heinrich Schuchardt > > musb->endpoints[] has array size MUSB_C_NUM_EPS. > We must check array bounds before accessing the array and not afterwards. > > Signed-off-by: Heinrich Schuchardt > Signed-off-by: Bin Liu > --- > drivers/usb/musb/musb_gadget_ep0.c | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) Should this also go to the stable kernels? 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] usb: musb: gadget: misplaced out of bounds check
On Thu, Mar 29, 2018 at 06:36:42PM +0200, Greg Kroah-Hartman wrote: > On Thu, Mar 29, 2018 at 10:48:28AM -0500, Bin Liu wrote: > > From: Heinrich Schuchardt > > > > musb->endpoints[] has array size MUSB_C_NUM_EPS. > > We must check array bounds before accessing the array and not afterwards. > > > > Signed-off-by: Heinrich Schuchardt > > Signed-off-by: Bin Liu > > --- > > drivers/usb/musb/musb_gadget_ep0.c | 14 +- > > 1 file changed, 9 insertions(+), 5 deletions(-) > > Should this also go to the stable kernels? Your call. My understanding is this is just a potential, and the code looks wrong - checking the boundary after used it, but the ep index won't be able to over the boundary anyway. Though I don't have enough security knowledge to judge if the bug has an security hole... Regards, -Bin. -- 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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4
Hi!
> > Does ofonod work for you? I could not get that one to work...
>
> Because it's looking for a Gobi modem but the MDM6600 isn't one and
> doesn't expose that layout (and doesn't really need to anyway). I
> don't think ofono has a generic QMI driver, so you'd either need to for
> ce it to use the telitqmi or quectelqmi drivers, or write your own
> generic QMI one.
You are right, it is detected as gobi now:
user@devuan:/my/ofono$ sudo python2 test/list-modems
[ /gobi_0 ]
SystemPath =
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
Features =
Emergency = 0
Powered = 0
Lockdown = 0
Interfaces =
Online = 0
Type = hardware
...and nothing works.
commit db9b292f9290b97c87a8d4b4836af4763c06a39c
Author: Bassem Boubaker
Date: Mon Mar 19 17:57:31 2018 +0100
I tried this:
diff --git a/plugins/udevng.c b/plugins/udevng.c
index ff5d41af..6b103254 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1578,8 +1578,6 @@ static struct {
{ "mbm","cdc_ether","0930" },
{ "mbm","cdc_ncm", "0930" },
{ "hso","hso" },
- { "gobi", "qmi_wwan" },
- { "gobi", "qcserial" },
{ "sierra", "qmi_wwan", "1199" },
{ "sierra", "qcserial", "1199" },
{ "sierra", "sierra"},
@@ -1602,6 +1600,8 @@ static struct {
{ "telit", "cdc_acm", "1bc7", "0021" },
{ "telitqmi", "qmi_wwan", "1bc7", "1201" },
{ "telitqmi", "option", "1bc7", "1201" },
+ { "telitqmi", "qmi_wwan", "22b8", "2a70" },
+ { "telitqmi", "option", "22b8", "2a70" },
{ "nokia", "option", "0421", "060e" },
{ "nokia", "option", "0421", "0623" },
{ "samsung","option", "04e8", "6889" },
But no luck:
ofonod[15879]: plugins/udevng.c:create_modem()
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
ofonod[15879]: plugins/udevng.c:create_modem() driver=telitqmi
ofonod[15879]: src/modem.c:ofono_modem_create() name: (null), type:
telitqmi
ofonod[15879]: plugins/udevng.c:setup_telitqmi()
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
ofonod[15879]: plugins/udevng.c:setup_telitqmi() /dev/cdc-wdm0
255/251/255 05 (null) usbmisc
ofonod[15879]: plugins/udevng.c:setup_telitqmi() wwan0 255/251/255 05
(null) net
ofonod[15879]: plugins/udevng.c:setup_telitqmi() /dev/cdc-wdm1
255/251/255 06 (null) usbmisc
ofonod[15879]: plugins/udevng.c:setup_telitqmi() wwan1 255/251/255 06
(null) net
ofonod[15879]: plugins/udevng.c:setup_telitqmi() /dev/cdc-wdm2
255/251/255 07 (null) usbmisc
ofonod[15879]: plugins/udevng.c:setup_telitqmi() wwan2 255/251/255 07
(null) net
ofonod[15879]: plugins/udevng.c:setup_telitqmi() /dev/cdc-wdm3
255/251/255 08 (null) usbmisc
ofonod[15879]: plugins/udevng.c:setup_telitqmi() wwan3 255/251/255 08
(null) net
ofonod[15879]: plugins/udevng.c:destroy_modem()
/sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/usb2/2-1
ofonod[15879]: src/modem.c:ofono_modem_remove() 0x596480
ofonod[15879]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm0
ofonod[15879]: plugins/udevng.c:destroy_modem() wwan0
ofonod[15879]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm1
ofonod[15879]: plugins/udevng.c:destroy_modem() wwan1
ofonod[15879]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm2
ofonod[15879]: plugins/udevng.c:destroy_modem() wwan2
ofonod[15879]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm3
ofonod[15879]: plugins/udevng.c:destroy_modem() wwan3
ofonod[15879]: plugins/upower.c:upower_connect() upower connect
ofonod[15879]: plugins/hfp_hf_bluez5.c:connect_handler() Registering
External Profile handler ...
With quectelqmi result was similar.
I know there are AT commands available at /dev/ttyUSB4. Is there easy
way to make ofonod connect to that?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v4 01/13] dt-bindings: connector: add properties for typec
Hi Li,
On 03/28/2018 06:06 PM, Li Jun wrote:
> Add bingdings supported by current typec driver, so user can pass
> all those properties via dt.
>
> Signed-off-by: Li Jun
> ---
> .../bindings/connector/usb-connector.txt | 39
> ++
> 1 file changed, 39 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..922f22b 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,29 @@ Optional properties:
> - type: size of the connector, should be specified in case of USB-A, USB-B
>non-fullsize connectors: "mini", "micro".
>
> +Optional properties for usb-c-connector:
> +- power-type: should be one of "source", "sink" or "dual"(DRP) if typec
> + connector has power support.
> +- try-power-role: preferred power role if "dual"(DRP) can support Try.SNK
> + or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC.
> +- data-type: should be one of "host", "device", "dual"(DRD) if typec
> + connector supports USB data.
> +
> +Required properties for usb-c-connector with power delivery support:
> +- source-pdos: An array of u32 with each entry providing supported power
> + source data object(PDO), the detailed bit definitions of PDO can be found
> + in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> + Source_Capabilities Message, the order of each entry(PDO) should follow
> + the PD spec chapter 6.4.1. Required for power source and power dual role.
> +- sink-pdos: An array of u32 with each entry providing supported power
> + sink data object(PDO), the detailed bit definitions of PDO can be found
> + in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
> + Sink Capabilities Message, the order of each entry(PDO) should follow
> + the PD spec chapter 6.4.1. Required for power sink and power dual role.
> +- op-sink-microwatt-hours: Sink required operating power in micro
> + watt-hours, if source offered power is less then it, Capability Mismatch
> + is set, required for power sink and power dual role.
This doesn't make sense. The unit of power is watt (W), watt-hour on the other
hand
is a measurement of energy. I think "op-sink-microwatt" is what we want here.
// Mats
> +
> Required nodes:
> - any data bus to the connector should be modeled using the OF graph bindings
>specified in bindings/graph.txt, unless the bus is between parent node and
> @@ -73,3 +96,19 @@ ccic: s2mm005@33 {
> };
> };
> };
> +
> +3. USB-C connector attached to a typec port controller(ptn5110), which has
> +power delivery support and enables drp.
> +
> +typec: ptn5110@50 {
> + ...
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + power-type = "dual";
> + try-power-role = "sink";
> + source-pdos = <0x380190c8>;
> + sink-pdos = <0x380190c8 0x3802d0c8>;
> + op-sink-microwatt-hours = <900>;
> + };
> +};
>
--
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 v4 10/13] usb: typec: tcpm: set cc for drp toggling attach
Hi Li, On 03/28/2018 06:06 PM, 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. > > 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 218c230..72d4232 100644 > --- a/drivers/usb/typec/tcpm.c > +++ b/drivers/usb/typec/tcpm.c > @@ -2126,6 +2126,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 = 0; I don't think it's OK to use "0" here. cc_req is an enum so why not use "|TYPEC_CC_OPEN"?| > } > > static void tcpm_detach(struct tcpm_port *port) > @@ -2361,6 +2362,8 @@ static void run_state_machine(struct tcpm_port *port) > break; > > case SRC_ATTACHED: > + if (!port->cc_req) 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); > @@ -2531,6 +2534,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) Ditto. > + tcpm_set_cc(port, TYPEC_CC_RD); > ret = tcpm_snk_attach(port); > if (ret < 0) > tcpm_set_state(port, SNK_UNATTACHED, 0); // Mats -- 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 v4 10/13] usb: typec: tcpm: set cc for drp toggling attach
On Thu, Mar 29, 2018 at 12:06:15AM +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. > Isn't CC set by the lower level driver in this case ? In other words, is it ever necessary to call back into the low level driver to set CC again ? Doing that in attached state seems a bit late. It may make more sense to update port->cc_req when the state machine leaves DRP_TOGGLING state, ie in _tcpm_cc_change(), and to do it without callback into the low level driver (it should not be necessary). 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 218c230..72d4232 100644 > --- a/drivers/usb/typec/tcpm.c > +++ b/drivers/usb/typec/tcpm.c > @@ -2126,6 +2126,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 = 0; > } > > static void tcpm_detach(struct tcpm_port *port) > @@ -2361,6 +2362,8 @@ static void run_state_machine(struct tcpm_port *port) > break; > > case SRC_ATTACHED: > + if (!port->cc_req) > + 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); > @@ -2531,6 +2534,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) > + tcpm_set_cc(port, TYPEC_CC_RD); > ret = tcpm_snk_attach(port); > if (ret < 0) > tcpm_set_state(port, SNK_UNATTACHED, 0); > -- > 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
