Re: Type-C port on the Asmedia ASM1142
I agree with you, you are right in everything you wrote! It is annoying to see
theoretic numbers and not the actual numbers the hardware implementing the
specification can support but something else is in my mind
too...N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
RE: Type-C port on the Asmedia ASM1142
From: Adrian Bocaniciu > Sent: 30 September 2017 09:18 > On Fri, 29 Sep 2017 09:06:16 + > David Laight wrote: > > > > The correct names used in the new specification for the 4 speeds that can > > > be supported by a USB 3 > > > interface are: . > > > > I think I'd add the speed itself as well. > > I was reffering mostly to the identifiers and comments used in the kernel > source code. So was I, don't assume that people reading the code know all about the interface definitions. Naming the constants USB_GEN_1x1_4G (or similar) makes things clearer. ... > There is a stupid tradition started by someone at Intel, I suppose from > marketing, who had the mean > idea of presenting SATA 1.0 as 1.5 Gb/s and PCIe 1.0 as 2.5 Gb/s. > > Before that, nobody thought that it would be right to present, > e.g. Gigabit Ethernet as having a speed of 1.25 Gb/s. Or 10MHz ethernet as 20MHz :-) Although the physical bit rate has been used before. Can't quite remember what for though - might have been ATM. Actually, isn't it GE - which is only 800MHz ?? David -- 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: phy: tegra: Fix phy suspend for UDC
Commit dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124")
added UDC support for Tegra but with UDC support enabled, is was found
that Tegra30, Tegra114 and Tegra124 would hang on entry to suspend.
The hang occurred during the suspend of the USB PHY when the Tegra PHY
driver attempted to disable the PHY clock. The problem is that before
the Tegra PHY driver is suspended, the chipidea driver already disabled
the PHY clock and when the Tegra PHY driver suspended, it could not read
DEVLC register and caused the device to hang.
The Tegra USB PHY driver is used by both the Tegra EHCI driver and now
the chipidea UDC driver and so simply removing the disabling of the PHY
clock from the USB PHY driver would not work for the Tegra EHCI driver.
Fortunately, the status of the USB PHY clock can be read from the
USB_SUSP_CTRL register and therefore, to workaround this issue, simply
poll the register prior to disabling the clock in USB PHY driver to see
if clock gating has already been initiated. Please note that it can take
a few uS for the clock to disable and so simply reading this status
register once on entry is not sufficient.
Similarly when turning on the PHY clock, it is possible that the clock
is already enabled or in the process of being enabled, and so check for
this when enabling the PHY.
Please note that no issues are seen with Tegra20 because it has a slightly
different PHY to Tegra30/114/124.
Fixes: dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124")
Signed-off-by: Jon Hunter
---
Changes since V1:
- Added fixes tag
- Added test in PHY enable to see if clock is already on before enabling
drivers/usb/phy/phy-tegra-usb.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 5fe4a5704bde..ccc2bf5274b4 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -329,6 +329,14 @@ static void utmi_phy_clk_disable(struct tegra_usb_phy *phy)
unsigned long val;
void __iomem *base = phy->regs;
+ /*
+* The USB driver may have already initiated the phy clock
+* disable so wait to see if the clock turns off and if not
+* then proceed with gating the clock.
+*/
+ if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID, 0) == 0)
+ return;
+
if (phy->is_legacy_phy) {
val = readl(base + USB_SUSP_CTRL);
val |= USB_SUSP_SET;
@@ -351,6 +359,15 @@ static void utmi_phy_clk_enable(struct tegra_usb_phy *phy)
unsigned long val;
void __iomem *base = phy->regs;
+ /*
+* The USB driver may have already initiated the phy clock
+* enable so wait to see if the clock turns on and if not
+* then proceed with ungating the clock.
+*/
+ if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID,
+ USB_PHY_CLK_VALID) == 0)
+ return;
+
if (phy->is_legacy_phy) {
val = readl(base + USB_SUSP_CTRL);
val |= USB_SUSP_CLR;
--
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 v2] xhci: Cleanup current_cmd in xhci_cleanup_command_queue()
On 29.09.2017 14:07, Jeffy Chen wrote:
KASAN reported use-after-free bug when xhci host controller died:
[ 176.952537] BUG: KASAN: use-after-free in
xhci_handle_command_timeout+0x68/0x224
[ 176.960846] Write of size 4 at addr ffc0cbb01608 by task kworker/3:3/1680
...
[ 177.180644] Freed by task 0:
[ 177.183882] kasan_slab_free+0x90/0x15c
[ 177.188194] kfree+0x114/0x28c
[ 177.191630] xhci_cleanup_command_queue+0xc8/0xf8
[ 177.196916] xhci_hc_died+0x84/0x358
Problem here is that when the cmd_timer fired, it would try to access
current_cmd while the command queue is already freed by xhci_hc_died().
Cleanup current_cmd in xhci_cleanup_command_queue() to avoid that.
Fixes: d9f11ba9f107 ("xhci: Rework how we handle unresponsive or hoptlug removed
hosts")
Signed-off-by: Jeffy Chen
---
Thanks, adding patch to queue
-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 V2] usb: phy: tegra: Fix phy suspend for UDC
On Mon, Oct 02, 2017 at 12:22:53PM +0100, Jon Hunter wrote:
> Commit dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124")
> added UDC support for Tegra but with UDC support enabled, is was found
> that Tegra30, Tegra114 and Tegra124 would hang on entry to suspend.
>
> The hang occurred during the suspend of the USB PHY when the Tegra PHY
> driver attempted to disable the PHY clock. The problem is that before
> the Tegra PHY driver is suspended, the chipidea driver already disabled
> the PHY clock and when the Tegra PHY driver suspended, it could not read
> DEVLC register and caused the device to hang.
>
> The Tegra USB PHY driver is used by both the Tegra EHCI driver and now
> the chipidea UDC driver and so simply removing the disabling of the PHY
> clock from the USB PHY driver would not work for the Tegra EHCI driver.
> Fortunately, the status of the USB PHY clock can be read from the
> USB_SUSP_CTRL register and therefore, to workaround this issue, simply
> poll the register prior to disabling the clock in USB PHY driver to see
> if clock gating has already been initiated. Please note that it can take
> a few uS for the clock to disable and so simply reading this status
> register once on entry is not sufficient.
>
> Similarly when turning on the PHY clock, it is possible that the clock
> is already enabled or in the process of being enabled, and so check for
> this when enabling the PHY.
>
> Please note that no issues are seen with Tegra20 because it has a slightly
> different PHY to Tegra30/114/124.
>
> Fixes: dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124")
>
> Signed-off-by: Jon Hunter
> ---
> Changes since V1:
> - Added fixes tag
> - Added test in PHY enable to see if clock is already on before enabling
>
> drivers/usb/phy/phy-tegra-usb.c | 17 +
> 1 file changed, 17 insertions(+)
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
Re: [PATCH v4 0/3] initialize (multiple) PHYs in xhci-plat
On Sun, 2017-10-01 at 22:32 +0200, Martin Blumenstingl wrote: > Hello Greg, Hello Mathias, > > On Mon, Sep 18, 2017 at 10:49 AM, Greg KH wrote: > > On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote: > > > Hello Mathias, Hello Greg, > > > > > > On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl > > > wrote: > > > > This series is the outcome of a discussion with Felipe Balbi, > > > > see [0] and [1]. > > > > The quick-summary of this is: > > > > - dwc3 already takes one USB2 and one USB3 PHY and initializes these > > > > correct > > > > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and > > > > ohci-platform.c) do not have a limitation on the number of PHYs - they > > > > support one PHY per actual host port > > > > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two > > > > or three USB2 ports enabled on the internal root-hub. The SoCs also > > > > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are > > > > internally "connected" to the dwc3 roothub) need to be powered on, > > > > otherwise USB devices cannot be enumerated (even if just one PHY is > > > > disabled and if the device is plugged into another, enabled port) > > > > > > > > In my first attempt to get USB supported on the GXL and GXM SoCs I tried > > > > to work-around the problem that I could not pass multiple PHYs to the > > > > dwc3 controller. > > > > This was rejected by Rob Herring (which was definitely the thing to do > > > > in > > > > my opinion), see [2] > > > > > > > > This series adds a new "platform-roothub". This can be configured > > > > through > > > > devicetree by passing a child-node with "reg = <0>" to the USB > > > > controller. Additionally there has to be a child-node for each port on > > > > the root-hub. Each of the child-nodes takes a "phys" and "phy-names" > > > > property. This allows modeling the root-hub in devicetree similar to the > > > > USB device binding (documented in devicetree/bindings/usb/usb- > > > > device.txt) > > > > This avoids and backwards-compatibility problems (which was a concern > > > > regardless of the solution, see [3]) since the binding for the root-hub > > > > was previously not specified (and we're not using the "phys" property of > > > > the controller, which might have served different purposes before, > > > > depending on the drivers). > > > > > > > > Additionally this integrates the new platform-roothub into xhci-plat.c > > > > which automatically enables it for the dwc3 driver (in host-mode). > > > > > > > > > > > > Changes since RFCv3 at [6]: > > > > - moved the DT binding change from patch #3 to patch #1 as suggested > > > > by Rob Herring (and slightly adjusted the commit message to account > > > > for that) > > > > - added Tested-by from Chunfeng Yun (who confirmed that the whole > > > > concept and implementation works fine on Mediatek SoCs - many thanks > > > > again!) to patch #2 > > > > - added Rob Herring's ACK to patches 1 and 3 > > > > - dropped RFC status (RFCv3 -> PATCH v4) > > > > > > I just wanted to rebase this to v4.14-rc1 (now that this is out) - > > > however I noticed that v4 still applies to v4.14-rc1 cleanly (the > > > patches are still identical to v4 after rebasing). > > > > > > we have an ACK from the devicetree maintainers and a "Tested-by" for a > > > Mediatek (= non-Amlogic) SoC. > > > I already have patches for the Amlogic GXL/GXM platforms queued, those > > > are just waiting on this series. > > > > > > what is still missing to get this series into v4.15? > > > > Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let > > us catch up on patch review please... > > OK, I understand that. > please let me know once you've caught up with the review backlog - as > I said I would like to get this into 4.15 if nothing else comes up > during the code-review This series works well on the libretech-cc (le potato) For the series: Tested-by: Jerome Brunet > > > Thank you! > Regards, > Martin > > ___ > linux-amlogic mailing list > linux-amlo...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic -- 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 0/3] initialize (multiple) PHYs in xhci-plat
On Mon, Oct 02, 2017 at 02:35:08PM +0200, Jerome Brunet wrote: > On Sun, 2017-10-01 at 22:32 +0200, Martin Blumenstingl wrote: > > Hello Greg, Hello Mathias, > > > > On Mon, Sep 18, 2017 at 10:49 AM, Greg KH > > wrote: > > > On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote: > > > > Hello Mathias, Hello Greg, > > > > > > > > On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl > > > > wrote: > > > > > This series is the outcome of a discussion with Felipe Balbi, > > > > > see [0] and [1]. > > > > > The quick-summary of this is: > > > > > - dwc3 already takes one USB2 and one USB3 PHY and initializes these > > > > > correct > > > > > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c > > > > > and > > > > > ohci-platform.c) do not have a limitation on the number of PHYs - > > > > > they > > > > > support one PHY per actual host port > > > > > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has > > > > > two > > > > > or three USB2 ports enabled on the internal root-hub. The SoCs also > > > > > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are > > > > > internally "connected" to the dwc3 roothub) need to be powered on, > > > > > otherwise USB devices cannot be enumerated (even if just one PHY is > > > > > disabled and if the device is plugged into another, enabled port) > > > > > > > > > > In my first attempt to get USB supported on the GXL and GXM SoCs I > > > > > tried > > > > > to work-around the problem that I could not pass multiple PHYs to the > > > > > dwc3 controller. > > > > > This was rejected by Rob Herring (which was definitely the thing to do > > > > > in > > > > > my opinion), see [2] > > > > > > > > > > This series adds a new "platform-roothub". This can be configured > > > > > through > > > > > devicetree by passing a child-node with "reg = <0>" to the USB > > > > > controller. Additionally there has to be a child-node for each port on > > > > > the root-hub. Each of the child-nodes takes a "phys" and "phy-names" > > > > > property. This allows modeling the root-hub in devicetree similar to > > > > > the > > > > > USB device binding (documented in devicetree/bindings/usb/usb- > > > > > device.txt) > > > > > This avoids and backwards-compatibility problems (which was a concern > > > > > regardless of the solution, see [3]) since the binding for the > > > > > root-hub > > > > > was previously not specified (and we're not using the "phys" property > > > > > of > > > > > the controller, which might have served different purposes before, > > > > > depending on the drivers). > > > > > > > > > > Additionally this integrates the new platform-roothub into xhci-plat.c > > > > > which automatically enables it for the dwc3 driver (in host-mode). > > > > > > > > > > > > > > > Changes since RFCv3 at [6]: > > > > > - moved the DT binding change from patch #3 to patch #1 as suggested > > > > > by Rob Herring (and slightly adjusted the commit message to account > > > > > for that) > > > > > - added Tested-by from Chunfeng Yun (who confirmed that the whole > > > > > concept and implementation works fine on Mediatek SoCs - many thanks > > > > > again!) to patch #2 > > > > > - added Rob Herring's ACK to patches 1 and 3 > > > > > - dropped RFC status (RFCv3 -> PATCH v4) > > > > > > > > I just wanted to rebase this to v4.14-rc1 (now that this is out) - > > > > however I noticed that v4 still applies to v4.14-rc1 cleanly (the > > > > patches are still identical to v4 after rebasing). > > > > > > > > we have an ACK from the devicetree maintainers and a "Tested-by" for a > > > > Mediatek (= non-Amlogic) SoC. > > > > I already have patches for the Amlogic GXL/GXM platforms queued, those > > > > are just waiting on this series. > > > > > > > > what is still missing to get this series into v4.15? > > > > > > Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let > > > us catch up on patch review please... > > > > OK, I understand that. > > please let me know once you've caught up with the review backlog - as > > I said I would like to get this into 4.15 if nothing else comes up > > during the code-review > > This series works well on the libretech-cc (le potato) > For the series: > > Tested-by: Jerome Brunet Hey, I have one of those boards now, was just about to try to get it to work. Is this series necessary for it to run properly on 4.14-rc? 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: Support for buggy MIDI-keyboard VID:PID 1c75:0204
+Cc: Greg, Felipe and Takashi. I hope they would point you to a right direction. On Sun, Oct 1, 2017 at 9:07 PM, Владимир Мартьянов wrote: > Hello! > > I just bought MIDI keyboard WORLDE MINI (looks like full chinese clone > af Arturia Minilab with the same vid:pid) and it won't work in Linux. > When the device is connected, it resets again and again. There are > some threads on the internet about the same issue, but there is no > solution. > > The problem is in the device: it has iConfiguration=3 in the > Configuration Descriptor, but when this string is requested from the > device it just resets. The Linux requested this string when the device > is connected, so it can't work at all. I tested it by requesting the > string with ID=3 and the device resets. > > I patched drivers/usb/core/message.c by commenting call to : > if (cp->string == NULL && > !(dev->quirks & USB_QUIRK_CONFIG_INTF_STRINGS)) > cp->string = usb_cache_string(dev, cp->desc.iConfiguration); > and the problem gone. > > Should the Linux kernel concern about such buggy devices? If it > should, what's the best way to bypass the problem? > -- > 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 -- With Best Regards, Andy Shevchenko -- 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 05/18] net: use ARRAY_SIZE
On Sun, Oct 1, 2017 at 10:30 PM, Jérémy Lefaure
wrote:
> Using the ARRAY_SIZE macro improves the readability of the code. Also,
> it is not always useful to use a variable to store this constant
> calculated at compile time.
>
> + {&gainctrl_lut_core0_rev0, ARRAY_SIZE(gainctrl_lut_core0_rev0), 26,
> 192,
> +32},
For all such cases I would rather put on one line disregard checkpatch
warning for better readability.
--
With Best Regards,
Andy Shevchenko
--
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: Support for buggy MIDI-keyboard VID:PID 1c75:0204
Andy Shevchenko writes:
> +Cc: Greg, Felipe and Takashi. I hope they would point you to a right
> direction.
>
> On Sun, Oct 1, 2017 at 9:07 PM, Владимир Мартьянов
> wrote:
>> Hello!
>>
>> I just bought MIDI keyboard WORLDE MINI (looks like full chinese clone
>> af Arturia Minilab with the same vid:pid) and it won't work in Linux.
>> When the device is connected, it resets again and again. There are
>> some threads on the internet about the same issue, but there is no
>> solution.
>>
>> The problem is in the device: it has iConfiguration=3 in the
>> Configuration Descriptor, but when this string is requested from the
>> device it just resets. The Linux requested this string when the device
>> is connected, so it can't work at all. I tested it by requesting the
>> string with ID=3 and the device resets.
>>
>> I patched drivers/usb/core/message.c by commenting call to :
>> if (cp->string == NULL &&
>> !(dev->quirks & USB_QUIRK_CONFIG_INTF_STRINGS))
>> cp->string = usb_cache_string(dev, cp->desc.iConfiguration);
>> and the problem gone.
>>
>> Should the Linux kernel concern about such buggy devices? If it
>> should, what's the best way to bypass the problem?
well, just apply the quirk to your device:
modified drivers/usb/core/quirks.c
@@ -41,6 +41,10 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x0218, 0x0401), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
+ /* MIDI keyboard WORLDE MINI */
+ { USB_DEVICE(0x1c75, 0x0204), .driver_info =
+ USB_QUIRK_CONFIG_INTF_STRINGS },
+
/* HP 5300/5370C scanner */
{ USB_DEVICE(0x03f0, 0x0701), .driver_info =
USB_QUIRK_STRING_FETCH_255 },
Can you test the above change? If it works I can send it as a formal
patch.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH 05/18] net: use ARRAY_SIZE
Jérémy Lefaure writes: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time. > > Found with Coccinelle with the following semantic patch: > @r depends on (org || report)@ > type T; > T[] E; > position p; > @@ > ( > (sizeof(E)@p /sizeof(*E)) > | > (sizeof(E)@p /sizeof(E[...])) > | > (sizeof(E)@p /sizeof(T)) > ) > > Signed-off-by: Jérémy Lefaure > --- > drivers/net/ethernet/emulex/benet/be_cmds.c| 4 +- > drivers/net/ethernet/intel/i40e/i40e_adminq.h | 3 +- > drivers/net/ethernet/intel/i40evf/i40e_adminq.h| 3 +- > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 3 +- > drivers/net/ethernet/intel/ixgbevf/vf.c| 17 +- > drivers/net/usb/kalmia.c | 9 +- > .../broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 473 > ++--- > .../net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 9 +- > .../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 12 +- > .../net/wireless/realtek/rtlwifi/rtl8723be/table.c | 14 +- > .../net/wireless/realtek/rtlwifi/rtl8821ae/table.c | 34 +- > include/net/bond_3ad.h | 3 +- > net/ipv6/seg6_local.c | 6 +- > 13 files changed, 177 insertions(+), 413 deletions(-) We have a tree for wireless so usually it's better to submit wireless changes on their own but here I assume Dave will apply this to his tree. If not, please resubmit the wireless part in a separate patch. -- Kalle Valo -- 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: Support for buggy MIDI-keyboard VID:PID 1c75:0204
On Mon, 2 Oct 2017, Felipe Balbi wrote:
> >> Should the Linux kernel concern about such buggy devices? If it
> >> should, what's the best way to bypass the problem?
>
> well, just apply the quirk to your device:
>
> modified drivers/usb/core/quirks.c
> @@ -41,6 +41,10 @@ static const struct usb_device_id usb_quirk_list[] = {
> { USB_DEVICE(0x0218, 0x0401), .driver_info =
> USB_QUIRK_CONFIG_INTF_STRINGS },
>
> + /* MIDI keyboard WORLDE MINI */
> + { USB_DEVICE(0x1c75, 0x0204), .driver_info =
> + USB_QUIRK_CONFIG_INTF_STRINGS },
> +
> /* HP 5300/5370C scanner */
> { USB_DEVICE(0x03f0, 0x0701), .driver_info =
> USB_QUIRK_STRING_FETCH_255 },
>
> Can you test the above change? If it works I can send it as a formal
> patch.
But when you do, please put the new entry in the correct position
(sorted by VID, PID).
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usbip: tools: Install all headers needed for libusbip development
On 09/30/2017 07:18 PM, Ben Hutchings wrote:
> usbip_host_driver.h now depends on several additional headers, which
> need to be installed along with it.
>
> Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver
> ...")
> Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with
> ...")
> Signed-off-by: Ben Hutchings
> ---
> I don't know of any external users of libusbip, but if it is going to
> install headers to support such users it should do so properly.
Not sure how many. But for correctness, I think it is good to fix this.
>
> Ben.
>
> tools/usb/usbip/Makefile.am | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/usb/usbip/Makefile.am b/tools/usb/usbip/Makefile.am
> index 66f8bf038c9f..45eaa70a71e0 100644
> --- a/tools/usb/usbip/Makefile.am
> +++ b/tools/usb/usbip/Makefile.am
> @@ -1,6 +1,7 @@
> SUBDIRS := libsrc src
> includedir = @includedir@/usbip
> include_HEADERS := $(addprefix libsrc/, \
> - usbip_common.h vhci_driver.h usbip_host_driver.h)
> + usbip_common.h vhci_driver.h usbip_host_driver.h \
> + list.h sysfs_utils.h usbip_host_common.h)
>
> dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8)
>
Looks good to me.
Acked-by: Shuah Khan
Thanks for catching this.
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] USB: cdc-wdm: ignore -EPIPE from GetEncapsulatedResponse
On Fri, 2017-09-22 at 22:18 +0200, Bjørn Mork wrote:
> The driver will forward errors to userspace after turning most of
> them
> into -EIO. But all status codes are not equal. The -EPIPE (stall) in
> particular can be seen more as a result of normal USB signaling than
> an actual error. The state is automatically cleared by the USB core
> without intervention from either driver or userspace.
>
> And most devices and firmwares will never trigger a stall as a result
> of GetEncapsulatedResponse. This is in fact a requirement for CDC WDM
> devices. Quoting from section 7.1 of the CDC WMC spec revision 1.1:
>
> The function shall not return STALL in response to
> GetEncapsulatedResponse.
>
> But this driver is also handling GetEncapsulatedResponse on behalf of
> the qmi_wwan and cdc_mbim drivers. Unfortunately the relevant specs
> are not as clear wrt stall. So some QMI and MBIM devices *will*
> occasionally stall, causing the GetEncapsulatedResponse to return an
> -EPIPE status. Translating this into -EIO for userspace has proven to
> be harmful. Treating it as an empty read is safer, making the driver
> behave as if the device was conforming to the CDC WDM spec.
>
> There have been numerous reports of issues related to -EPIPE errors
> from some newer CDC MBIM devices in particular, like for example the
> Fibocom L831-EAU. Testing on this device has shown that the issues
> go away if we simply ignore the -EPIPE status. Similar handling of
> -EPIPE is already known from e.g. usb_get_string()
>
> The -EPIPE log message is still kept to let us track devices with
> this
> unexpected behaviour, hoping that it attracts attention from firmware
> developers.
>
> Cc:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100938
> Reported-and-tested-by: Christian Ehrig turn-bt.com>
> Reported-and-tested-by: Patrick Chilton
> Reported-and-tested-by: Andreas Böhler
> Signed-off-by: Bjørn Mork
> ---
> The fallout of this problem has been reported by a number of people
> for a long time. Many more than those being listed above. Apologies
> to all who didn't get the appropriate credit. Sorry, I am lousy with
> paper work and lost track of you all.
>
> Hoping the fix will make up for it...
FWIW, tested on the oldest MBIM devices I have (Ericsson F5321 and
Huawei EM820W for while with light traffic, browsing and git pull/push.
Neither of these devices exhibit the original problem of course.
Might find time to test on the newer ones this week or next, but it
seems OK.
Dan
>
> Bjørn
>
> drivers/usb/class/cdc-wdm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-
> wdm.c
> index 0b845e550fbd..9f001659807a 100644
> --- a/drivers/usb/class/cdc-wdm.c
> +++ b/drivers/usb/class/cdc-wdm.c
> @@ -194,8 +194,10 @@ static void wdm_in_callback(struct urb *urb)
> /*
> * only set a new error if there is no previous error.
> * Errors are only cleared during read/open
> + * Avoid propagating -EPIPE (stall) to userspace since it is
> + * better handled as an empty read
> */
> - if (desc->rerr == 0)
> + if (desc->rerr == 0 && status != -EPIPE)
> desc->rerr = status;
>
> if (length + desc->length > desc->wMaxCommand) {
--
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: phy: tegra: Fix phy suspend for UDC
On 02.10.2017 14:22, Jon Hunter wrote:
> Commit dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124")
> added UDC support for Tegra but with UDC support enabled, is was found
> that Tegra30, Tegra114 and Tegra124 would hang on entry to suspend.
>
> The hang occurred during the suspend of the USB PHY when the Tegra PHY
> driver attempted to disable the PHY clock. The problem is that before
> the Tegra PHY driver is suspended, the chipidea driver already disabled
> the PHY clock and when the Tegra PHY driver suspended, it could not read
> DEVLC register and caused the device to hang.
>
> The Tegra USB PHY driver is used by both the Tegra EHCI driver and now
> the chipidea UDC driver and so simply removing the disabling of the PHY
> clock from the USB PHY driver would not work for the Tegra EHCI driver.
> Fortunately, the status of the USB PHY clock can be read from the
> USB_SUSP_CTRL register and therefore, to workaround this issue, simply
> poll the register prior to disabling the clock in USB PHY driver to see
> if clock gating has already been initiated. Please note that it can take
> a few uS for the clock to disable and so simply reading this status
> register once on entry is not sufficient.
>
> Similarly when turning on the PHY clock, it is possible that the clock
> is already enabled or in the process of being enabled, and so check for
> this when enabling the PHY.
>
> Please note that no issues are seen with Tegra20 because it has a slightly
> different PHY to Tegra30/114/124.
>
> Fixes: dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124")
>
> Signed-off-by: Jon Hunter
> ---
Works on Tegra20 and fixes bogus CLK stabilization error message.
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
> Changes since V1:
> - Added fixes tag
> - Added test in PHY enable to see if clock is already on before enabling
>
> drivers/usb/phy/phy-tegra-usb.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
> index 5fe4a5704bde..ccc2bf5274b4 100644
> --- a/drivers/usb/phy/phy-tegra-usb.c
> +++ b/drivers/usb/phy/phy-tegra-usb.c
> @@ -329,6 +329,14 @@ static void utmi_phy_clk_disable(struct tegra_usb_phy
> *phy)
> unsigned long val;
> void __iomem *base = phy->regs;
>
> + /*
> + * The USB driver may have already initiated the phy clock
> + * disable so wait to see if the clock turns off and if not
> + * then proceed with gating the clock.
> + */
> + if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID, 0) == 0)
> + return;
> +
> if (phy->is_legacy_phy) {
> val = readl(base + USB_SUSP_CTRL);
> val |= USB_SUSP_SET;
> @@ -351,6 +359,15 @@ static void utmi_phy_clk_enable(struct tegra_usb_phy
> *phy)
> unsigned long val;
> void __iomem *base = phy->regs;
>
> + /*
> + * The USB driver may have already initiated the phy clock
> + * enable so wait to see if the clock turns on and if not
> + * then proceed with ungating the clock.
> + */
> + if (utmi_wait_register(base + USB_SUSP_CTRL, USB_PHY_CLK_VALID,
> +USB_PHY_CLK_VALID) == 0)
> + return;
> +
> if (phy->is_legacy_phy) {
> val = readl(base + USB_SUSP_CTRL);
> val |= USB_SUSP_CLR;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] use ARRAY_SIZE macro
Em Sun, 1 Oct 2017 20:52:20 -0400 Jérémy Lefaure escreveu: > Anyway, I can tell to each maintainer that they can apply the patches > they're concerned about and next time I may send individual patches. In the case of media, we'll handle it as if they were individual ones. Thanks, Mauro -- 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] r8152: add Linksys USB3GIGV1 id
On Sun, Oct 1, 2017 at 10:39 PM, David Miller wrote: > From: Grant Grundler > Date: Thu, 28 Sep 2017 11:35:00 -0700 > >> This linksys dongle by default comes up in cdc_ether mode. >> This patch allows r8152 to claim the device: >>Bus 002 Device 002: ID 13b1:0041 Linksys >> >> Signed-off-by: Grant Grundler > > Applied, thanks. thanks David, Doug, Oliver! :) cheers, grant -- 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: Support for buggy MIDI-keyboard VID:PID 1c75:0204
Oh, I didn't know about quirks.c. Your code solved the problem, thank you!
2017-10-02 16:09 GMT+03:00 Felipe Balbi :
> Andy Shevchenko writes:
>
>> +Cc: Greg, Felipe and Takashi. I hope they would point you to a right
>> direction.
>>
>> On Sun, Oct 1, 2017 at 9:07 PM, Владимир Мартьянов
>> wrote:
>>> Hello!
>>>
>>> I just bought MIDI keyboard WORLDE MINI (looks like full chinese clone
>>> af Arturia Minilab with the same vid:pid) and it won't work in Linux.
>>> When the device is connected, it resets again and again. There are
>>> some threads on the internet about the same issue, but there is no
>>> solution.
>>>
>>> The problem is in the device: it has iConfiguration=3 in the
>>> Configuration Descriptor, but when this string is requested from the
>>> device it just resets. The Linux requested this string when the device
>>> is connected, so it can't work at all. I tested it by requesting the
>>> string with ID=3 and the device resets.
>>>
>>> I patched drivers/usb/core/message.c by commenting call to :
>>> if (cp->string == NULL &&
>>> !(dev->quirks & USB_QUIRK_CONFIG_INTF_STRINGS))
>>> cp->string = usb_cache_string(dev, cp->desc.iConfiguration);
>>> and the problem gone.
>>>
>>> Should the Linux kernel concern about such buggy devices? If it
>>> should, what's the best way to bypass the problem?
>
> well, just apply the quirk to your device:
>
> modified drivers/usb/core/quirks.c
> @@ -41,6 +41,10 @@ static const struct usb_device_id usb_quirk_list[] = {
> { USB_DEVICE(0x0218, 0x0401), .driver_info =
> USB_QUIRK_CONFIG_INTF_STRINGS },
>
> + /* MIDI keyboard WORLDE MINI */
> + { USB_DEVICE(0x1c75, 0x0204), .driver_info =
> + USB_QUIRK_CONFIG_INTF_STRINGS },
> +
> /* HP 5300/5370C scanner */
> { USB_DEVICE(0x03f0, 0x0701), .driver_info =
> USB_QUIRK_STRING_FETCH_255 },
>
> Can you test the above change? If it works I can send it as a formal
> patch.
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] use ARRAY_SIZE macro
On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote: > On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote: > > On Mon, 2 Oct 2017 09:01:31 +1100 > > "Tobin C. Harding" wrote: > > > > > > In order to reduce the size of the To: and Cc: lines, each patch of the > > > > series is sent only to the maintainers and lists concerned by the patch. > > > > This cover letter is sent to every list concerned by this series. > > > > > > Why don't you just send individual patches for each subsystem? I'm not a > > > maintainer but I don't see > > > how any one person is going to be able to apply this whole series, it is > > > making it hard for > > > maintainers if they have to pick patches out from among the series (if > > > indeed any will bother > > > doing that). > > Yeah, maybe it would have been better to send individual patches. > > > > From my point of view it's a series because the patches are related (I > > did a git format-patch from my local branch). But for the maintainers > > point of view, they are individual patches. > > And the maintainers view is what matters here, if you wish to get your > patches reviewed and accepted... Mainly I'd just like to know which you're asking for. Do you want me to apply this, or to ACK it so someone else can? If it's sent as a series I tend to assume the latter. But in this case I'm assuming it's the former, so I'll pick up the nfsd one --b. -- 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
Random xHCI HC died on device disconnect
Hello, I am currently working on a custom Armada 385-based board running kernel 4.9.52. I have a USB 2.0 LTE modem connected to USB 3.0, and the modem sometimes crashes due to various internal (on the modem) reasons. The board supports restarting the USB-ports using GPIOs, and at random points when I restart the USB-port I get the following error in dmesg: [12446.639458] qmi_wwan 4-1:1.4: nonzero urb status received: -71 [12446.639462] qmi_wwan 4-1:1.4: wdm_int_callback - 0 bytes [12446.639466] qmi_wwan 4-1:1.4: wdm_int_callback - usb_submit_urb failed with result -19 [12446.658760] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 [12446.666837] option 4-1:1.0: device disconnected [12446.671576] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1 [12446.679686] option 4-1:1.1: device disconnected [12451.763245] xhci-hcd f10f8000.usb3: xHCI host not responding to stop endpoint command. [12451.771187] xhci-hcd f10f8000.usb3: Assuming host is dying, halting host. [12451.778027] xhci-hcd f10f8000.usb3: HC died; cleaning up [12451.783589] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2 [12451.791654] option 4-1:1.2: device disconnected [12451.796416] option1 ttyUSB3: GSM modem (1-port) converter now disconnected from ttyUSB3 [12451.804530] option 4-1:1.3: device disconnected [12451.809206] qmi_wwan 4-1:1.4 wwan0: unregister 'qmi_wwan' usb-f10f8000.usb3-1, WWAN/QMI device After this, the port is dead until I reboot the device and it is sufficient to do a soft reboot in order to bring the port back. Most of the time, restarting the port works fine and the time it takes for the error to occur seems random. In order to rule out (or at least reduce the probability of) that there is something wrong with the board I am testing, I found two other Armada-boards with upstream-support and compiled kernel 4.14-rc3 for them. The modem can be rebooted using AT-commands, so I created a small script which contained a loop where I rebooted the modem as soon as possible. Doing this, I was able to replicate the error I saw on my custom board- Does anyone have any tips on where to start looking, how to solve this issue or how to work around it? For me, if there is a way to restart the host controller, then that would be sufficient as I only have one USB device connected. When searching online, I find lots of references to similar issues, but they all (or at least the ones where a solution has been found) seem to related to suspend/resume. Thanks in advance for any help, Kristian -- 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: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be
Bringing in Josh on this, because the merge commit gets fingered because it seems to be an interaction between the new code from the merge and the ORC unwinder changes. It's probably some almost trivial code difference that just causes some code generation to change. And because Josh wasn't implicated in the merge, he didn't get cc'd by the kernel test robot. Of course, the stack trace itself seems to be pretty useless, since that randconfig doesn't have KALLSYMS enabled, so it's just random hex numbers. Josh, original email on lkml and a few other mailing lists, see for example: https://www.spinics.net/lists/devicetree/msg196692.html Any ideas? Linus On Sun, Oct 1, 2017 at 4:17 PM, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > commit 4879b7ae05431ebcd228a4ff25a81120b3d85891 > Merge tag 'dmaengine-4.12-rc1' of > git://git.infradead.org/users/vkoul/slave-dma > > Pull dmaengine updates from Vinod Koul: > "This time again a smaller update consisting of: > >- support for TI DA8xx dma controller and updates to the cppi driver > >- updates on bunch of drivers like xilinx, pl08x, stm32-dma, mv_xor, > ioat, dmatest" > > * tag 'dmaengine-4.12-rc1' of > git://git.infradead.org/users/vkoul/slave-dma: (35 commits) > dmaengine: pl08x: remove lock documentation > dmaengine: pl08x: fix pl08x_dma_chan_state documentation > dmaengine: pl08x: Use the BIT() macro consistently > dmaengine: pl080: Fix some missing kerneldoc > dmaengine: pl080: Cut some unused defines > dmaengine: dmatest: Add check for supported buffer count (sg_buffers) > dmaengine: dmatest: Select DMA_ENGINE_RAID as its needed for the > slave_sg test > dmaengine: virt-dma: Convert to use list_for_each_entry_safe() > dma-debug: use offset_in_page() macro > dmaengine: mv_xor: use offset_in_page() macro > dmaengine: dmatest: use offset_in_page() macro > dmaengine: sun4i: fix invalid argument > dmaengine: ioat: use setup_timer > dmaengine: cppi41: Fix an Oops happening in cppi41_dma_probe() > dmaengine: pl330: remove pdata based initialization > dmaengine: cppi: fix build error due to bad variable > dmaengine: imx-sdma: add 1ms delay to ensure SDMA channel is stopped > dmaengine: cppi41: use managed functions devm_*() > dmaengine: cppi41: fix cppi41_dma_tx_status() logic > dmaengine: qcom_hidma: pause the channel on shutdown > ... > > ecc721a72c Merge tag 'pwm/for-4.12-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm > be13ec668d Merge branch 'topic/pl330' into for-linus > 4879b7ae05 Merge tag 'dmaengine-4.12-rc1' of > git://git.infradead.org/users/vkoul/slave-dma > 9e66317d3c Linux 4.14-rc3 > 1418b85217 Add linux-next specific files for 20170929 > +---++++---+---+ > | | ecc721a72c | > be13ec668d | 4879b7ae05 | v4.14-rc3 | next-20170929 | > +---++++---+---+ > | boot_successes| 1009 | 1009 > | 909| 5 | 510 | > | boot_failures | 0 | 0 > | 1 | 4 | 153 | > | WARNING:kernel_stack | 0 | 0 > | 1 | 3 | 111 | > | BUG:unable_to_handle_kernel | 0 | 0 > | 0 | 3 | 48| > | Oops:#[##]| 0 | 0 > | 0 | 3 | 48| > | EIP:update_stack_state| 0 | 0 > | 0 | 3 | 48| > | Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0 | 0 > | 0 | 3 | 48| > | invoked_oom-killer:gfp_mask=0x| 0 | 0 > | 0 | 1 | 16| > | Mem-Info | 0 | 0 > | 0 | 1 | 16| > | EIP:clear_user| 0 | 0 > | 0 | 0 | 2 | > | EIP:copy_page_to_iter | 0 | 0 > | 0 | 0 | 1 | > +---++++---+---+ > > [ 98.541044] random: ubu
Re: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be
On Mon, Oct 02, 2017 at 01:09:31PM -0700, Linus Torvalds wrote:
> Bringing in Josh on this, because the merge commit gets fingered
> because it seems to be an interaction between the new code from the
> merge and the ORC unwinder changes. It's probably some almost trivial
> code difference that just causes some code generation to change.
>
> And because Josh wasn't implicated in the merge, he didn't get cc'd by
> the kernel test robot.
>
> Of course, the stack trace itself seems to be pretty useless, since
> that randconfig doesn't have KALLSYMS enabled, so it's just random hex
> numbers.
>
> Josh, original email on lkml and a few other mailing lists, see for example:
>
> https://www.spinics.net/lists/devicetree/msg196692.html
>
> Any ideas?
The bisect is pointing to a commit which is almost 5 months old, so this
is pre-ORC. Kallsyms *is* enabled, but the unwinder dump isn't smart
enough to realize it's dumping misaligned stack addresses:
[ 110.399425] WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811
has bad 'bp' value 01be
[ 110.399428] unwind stack type:0 next_sp: (null) mask:0x2 graph_idx:0
[ 110.399431] bd92bc2e: 92bc7f00 (0x92bc7f00)
[ 110.399433] bd92bc32: c27041bd (0xc27041bd)
So kallsyms doesn't help if I'm dumping bad data. Oops.
I tried to recreate it with the reproducer script and a similar GCC
version, but no luck.
Fengguang, assuming it's reliably recreatable, any chance you could
recreate with the following patch?
diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index 82c6d7f1fd73..64282ec73eb8 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -42,7 +42,7 @@ static void unwind_dump(struct unwind_state *state)
state->stack_info.type, state->stack_info.next_sp,
state->stack_mask, state->graph_idx);
- for (sp = state->orig_sp; sp; sp = PTR_ALIGN(stack_info.next_sp,
sizeof(long))) {
+ for (sp = PTR_ALIGN(state->orig_sp); sp; sp =
PTR_ALIGN(stack_info.next_sp, sizeof(long))) {
if (get_stack_info(sp, state->task, &stack_info, &visit_mask))
break;
--
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: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be
On Mon, Oct 02, 2017 at 04:26:54PM -0500, Josh Poimboeuf wrote:
> Fengguang, assuming it's reliably recreatable, any chance you could
> recreate with the following patch?
Sorry, here's a version which actually compiles.
diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index d145a0b1f529..00234fa5a33a 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -44,7 +44,8 @@ static void unwind_dump(struct unwind_state *state)
state->stack_info.type, state->stack_info.next_sp,
state->stack_mask, state->graph_idx);
- for (sp = state->orig_sp; sp; sp = PTR_ALIGN(stack_info.next_sp,
sizeof(long))) {
+ for (sp = PTR_ALIGN(state->orig_sp, sizeof(long)); sp;
+sp = PTR_ALIGN(stack_info.next_sp, sizeof(long))) {
if (get_stack_info(sp, state->task, &stack_info, &visit_mask))
break;
--
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: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be
On Mon, Oct 2, 2017 at 2:26 PM, Josh Poimboeuf wrote: > > The bisect is pointing to a commit which is almost 5 months old, so this > is pre-ORC. Kallsyms *is* enabled, but the unwinder dump isn't smart > enough to realize it's dumping misaligned stack addresses: Ahh, I didn't pick up on that "esp isn't aligned" part. That said, if %esp gets unaligned at some point, it's not clear exactly when we should align it. An unaligned stack pointer will continue to _work_ just potentially perform fairly badly. But more likely, we picked the wrong frame value to begin with. For example, maybe that decode_frame_pointer() logic really should check not that the low bit in bp is set, but instead check that it's a valid "unsigned long *" that has the low bit set. IOW, the difference would be that instead of checking if (!(regs & 0x1)) return NULL; if would check if ((regs & (sizeof(unsigned long)-1)) != 1) return NULL; but also maybe add logic to simply not trust a next frame pointer that isn't appropriately aligned. So I think adding PTR_ALIGN() there in the unwind dumper might be a bit late. By that time it has already accepted what looks like a garbage frame. No? Linus -- 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] rndis_host: support Novatel Verizon USB730L
From: Aleksander Morgado Date: Wed, 27 Sep 2017 23:31:03 +0200 > I'm not sure if binding this logic to a specific vid:pid (1410:9030) > would be more appropriate here, or if it's ok to just bind > class/subclass/protocol (as in the activesync case). Let me know > what you think. I don't have enough USB Networking knowledge to make a decision here. Some things seem confusing. For example, if we should be matching USB_CLASS_MISC, subclass=4, protocol=1 for RNDIS over Ethernet, then we why aren't we also matching USB_CLASS_MISC, subclass=4, protocol=2 for RNDIS over wireless and instead are matching "Remote RNDIS" in the form of USB_CLASS_WIRELSS, subclass=1, protocol=3? I really don't understand any of this magic :-) So someone more knowledgable needs to review this. -- 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 0/3] initialize (multiple) PHYs in xhci-plat
Hi Greg, On Mon, Oct 2, 2017 at 2:44 PM, Greg KH wrote: > On Mon, Oct 02, 2017 at 02:35:08PM +0200, Jerome Brunet wrote: >> On Sun, 2017-10-01 at 22:32 +0200, Martin Blumenstingl wrote: >> > Hello Greg, Hello Mathias, >> > >> > On Mon, Sep 18, 2017 at 10:49 AM, Greg KH >> > wrote: >> > > On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote: >> > > > Hello Mathias, Hello Greg, >> > > > >> > > > On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl >> > > > wrote: >> > > > > This series is the outcome of a discussion with Felipe Balbi, >> > > > > see [0] and [1]. >> > > > > The quick-summary of this is: >> > > > > - dwc3 already takes one USB2 and one USB3 PHY and initializes these >> > > > > correct >> > > > > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c >> > > > > and >> > > > > ohci-platform.c) do not have a limitation on the number of PHYs - >> > > > > they >> > > > > support one PHY per actual host port >> > > > > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has >> > > > > two >> > > > > or three USB2 ports enabled on the internal root-hub. The SoCs also >> > > > > provide separate USB2 PHYs, one per port. All USB2 PHYs (which are >> > > > > internally "connected" to the dwc3 roothub) need to be powered on, >> > > > > otherwise USB devices cannot be enumerated (even if just one PHY is >> > > > > disabled and if the device is plugged into another, enabled port) >> > > > > >> > > > > In my first attempt to get USB supported on the GXL and GXM SoCs I >> > > > > tried >> > > > > to work-around the problem that I could not pass multiple PHYs to the >> > > > > dwc3 controller. >> > > > > This was rejected by Rob Herring (which was definitely the thing to >> > > > > do >> > > > > in >> > > > > my opinion), see [2] >> > > > > >> > > > > This series adds a new "platform-roothub". This can be configured >> > > > > through >> > > > > devicetree by passing a child-node with "reg = <0>" to the USB >> > > > > controller. Additionally there has to be a child-node for each port >> > > > > on >> > > > > the root-hub. Each of the child-nodes takes a "phys" and "phy-names" >> > > > > property. This allows modeling the root-hub in devicetree similar to >> > > > > the >> > > > > USB device binding (documented in devicetree/bindings/usb/usb- >> > > > > device.txt) >> > > > > This avoids and backwards-compatibility problems (which was a concern >> > > > > regardless of the solution, see [3]) since the binding for the >> > > > > root-hub >> > > > > was previously not specified (and we're not using the "phys" >> > > > > property of >> > > > > the controller, which might have served different purposes before, >> > > > > depending on the drivers). >> > > > > >> > > > > Additionally this integrates the new platform-roothub into >> > > > > xhci-plat.c >> > > > > which automatically enables it for the dwc3 driver (in host-mode). >> > > > > >> > > > > >> > > > > Changes since RFCv3 at [6]: >> > > > > - moved the DT binding change from patch #3 to patch #1 as suggested >> > > > > by Rob Herring (and slightly adjusted the commit message to account >> > > > > for that) >> > > > > - added Tested-by from Chunfeng Yun (who confirmed that the whole >> > > > > concept and implementation works fine on Mediatek SoCs - many >> > > > > thanks >> > > > > again!) to patch #2 >> > > > > - added Rob Herring's ACK to patches 1 and 3 >> > > > > - dropped RFC status (RFCv3 -> PATCH v4) >> > > > >> > > > I just wanted to rebase this to v4.14-rc1 (now that this is out) - >> > > > however I noticed that v4 still applies to v4.14-rc1 cleanly (the >> > > > patches are still identical to v4 after rebasing). >> > > > >> > > > we have an ACK from the devicetree maintainers and a "Tested-by" for a >> > > > Mediatek (= non-Amlogic) SoC. >> > > > I already have patches for the Amlogic GXL/GXM platforms queued, those >> > > > are just waiting on this series. >> > > > >> > > > what is still missing to get this series into v4.15? >> > > >> > > Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let >> > > us catch up on patch review please... >> > >> > OK, I understand that. >> > please let me know once you've caught up with the review backlog - as >> > I said I would like to get this into 4.15 if nothing else comes up >> > during the code-review >> >> This series works well on the libretech-cc (le potato) >> For the series: >> >> Tested-by: Jerome Brunet > > Hey, I have one of those boards now, was just about to try to get it to > work. Is this series necessary for it to run properly on 4.14-rc? if you're speaking of the "libretech-cc (le potato)" board then indeed, it is however, it's just one piece of the whole puzzle: 1) we need this series to initialize all USB PHYs correctly 2) we need to initialize the USB3 PHY with a basic driver, see this series: [0] 3) all the USB PHYs and the dwc3 controller has to be added to the .dts files (no patchset wa
Re: write to a UVC device
> All of the character devices is not working properly with low level I/O. > > The details are >> taken care by the driver. Am I correct in understanding that this is >> not a way to do it with UVC, i.e. the sequence of steps is different >> (open, some different steps, close) ? > > yes. you need to know how to talk with UVC. > This article will be help. > > https://lwn.net/Articles/203924/ > > Jaejoong > Is there a way to "talk" to UVC without V4L2 or I absolutely need to use V4L2? At the moment I need something simple (just to write a buffer to UVC). -- Rail Shafigulin Software Engineer Esencia Technologies -- *ESENCIA TECHNOLOGIES, INC.*3945 Freedom Circle, Suite #360, Santa Clara CA 95054 Phone: +1 408 736 8284 Fax: +1 408 519 3475 http://www.esenciatech.com | http://www.lnttechservices.com -- 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: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be
On Mon, Oct 02, 2017 at 02:58:08PM -0700, Linus Torvalds wrote: > On Mon, Oct 2, 2017 at 2:26 PM, Josh Poimboeuf wrote: > > > > The bisect is pointing to a commit which is almost 5 months old, so this > > is pre-ORC. Kallsyms *is* enabled, but the unwinder dump isn't smart > > enough to realize it's dumping misaligned stack addresses: > > Ahh, I didn't pick up on that "esp isn't aligned" part. > > That said, if %esp gets unaligned at some point, it's not clear > exactly when we should align it. An unaligned stack pointer will > continue to _work_ just potentially perform fairly badly. True, but unaligned stacks seem to be very rare, and I don't remember ever seeing one with frame pointers enabled. I think the call return addresses will always be aligned, so I think it makes sense to align the starting address before dumping. > But more likely, we picked the wrong frame value to begin with. Agreed. > For example, maybe that decode_frame_pointer() logic really should > check not that the low bit in bp is set, but instead check that it's a > valid "unsigned long *" that has the low bit set. > > IOW, the difference would be that instead of checking > > if (!(regs & 0x1)) > return NULL; > > if would check > > if ((regs & (sizeof(unsigned long)-1)) != 1) > return NULL; Yeah, that would be an improvement. > but also maybe add logic to simply not trust a next frame pointer that > isn't appropriately aligned. Also a good idea. > So I think adding PTR_ALIGN() there in the unwind dumper might be a > bit late. By that time it has already accepted what looks like a > garbage frame. No? Yeah, maybe. I guess it really depends on what exactly the root cause is. It got a bad frame pointer somehow, but maybe not *too* bad because it still ended up in the task stack somehow. It's not clear how that happened, but it's possible the task stack had some clues about what led up to it. I'll implement your suggestions in addition to the patch to align sp in the dump code. Having all of them together would hopefully enable the unwinder to detect a bad condition as early as possible and also do a better job at dumping it. -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] use ARRAY_SIZE macro
On Mon, 2 Oct 2017 15:22:24 -0400
bfie...@fieldses.org (J. Bruce Fields) wrote:
> Mainly I'd just like to know which you're asking for. Do you want me to
> apply this, or to ACK it so someone else can? If it's sent as a series
> I tend to assume the latter.
>
> But in this case I'm assuming it's the former, so I'll pick up the nfsd
> one
Could you to apply the NFSD patch ("nfsd: use ARRAY_SIZE") with the
Reviewed-by: Jeff Layton ) tag please ?
This patch is an individual patch and it should not have been sent in a
series (sorry about that).
Thank you,
Jérémy
--
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 05/18] net: use ARRAY_SIZE
On Mon, 02 Oct 2017 16:46:29 +0300 Kalle Valo wrote: > We have a tree for wireless so usually it's better to submit wireless > changes on their own but here I assume Dave will apply this to his tree. > If not, please resubmit the wireless part in a separate patch. Ok, I note that. I'll wait Dave's answer and I'll split this patch if needed. Thank you, Jérémy -- 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 05/18] net: use ARRAY_SIZE
On Mon, 2 Oct 2017 16:07:36 +0300
Andy Shevchenko wrote:
> > + {&gainctrl_lut_core0_rev0, ARRAY_SIZE(gainctrl_lut_core0_rev0), 26,
> > 192,
> > +32},
>
> For all such cases I would rather put on one line disregard checkpatch
> warning for better readability.
I agree that it would be better. I didn't know that it was possible to
not follow this rule for anything else than a string.
I am waiting for more comments and I will send a v2.
Thank you,
Jérémy
--
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] extcon: Split out extcon header file for consumer and provider device
On Fri, Sep 29, 2017 at 8:01 AM, Chanwoo Choi wrote:
> The extcon has two type of extcon devices as following.
> - 'extcon provider deivce' adds new extcon device and detect the
>state/properties of external connector. Also, it notifies the
>state/properties to the extcon consumer device.
> - 'extcon consumer device' gets the change state/properties
>from extcon provider device.
> Prior to that, include/linux/extcon.h contains all exported API for
> both provider and consumer device driver. To clarify the meaning of
> header file and to remove the wrong use-case on consumer device,
> this patch separates into extcon.h and extcon-provider.h.
>
> [Description for include/linux/{extcon.h|extcon-provider.h}]
> - extcon.h includes the extcon API and data structure for extcon consumer
> device driver. This header file contains the following APIs:
> : Register/unregister the notifier to catch the change of extcon device
> : Get the extcon device instance
> : Get the extcon device name
> : Get the state of each external connector
> : Get the property value of each external connector
> : Get the property capability of each external connector
>
> - extcon-provider.h includes the extcon API and data structure for extcon
> provider device driver. This header file contains the following APIs:
> : Include 'include/linux/extcon.h'
> : Allocate the memory for extcon device instance
> : Register/unregister extcon device
> : Set the state of each external connector
> : Set the property value of each external connector
> : Set the property capability of each external connector
>
> Cc: Felipe Balbi
> Cc: Kishon Vijay Abraham I
> Cc: Greg Kroah-Hartman
> Cc: Sebastian Reichel
> Cc: Lee Jones
> Signed-off-by: Chanwoo Choi
> ---
For
> drivers/extcon/extcon-axp288.c| 2 +-
and
> drivers/phy/allwinner/phy-sun4i-usb.c | 2 +-
Acked-by: Chen-Yu Tsai
--
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: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be
Hi Josh,
On Mon, Oct 02, 2017 at 04:31:09PM -0500, Josh Poimboeuf wrote:
On Mon, Oct 02, 2017 at 04:26:54PM -0500, Josh Poimboeuf wrote:
Fengguang, assuming it's reliably recreatable, any chance you could
recreate with the following patch?
Sure, I'll try your patch on v4.14-rc3 since it looks the most
reproducible kernel. For the bisected 4879b7ae05, the warning only
shows up once out of 909 boots according to the below stats. So I'm
not sure whether it's the _first_ bad commit. To double confirm, I
just queued 5000 more boot tests for each of its parent commits.
ecc721a72c Merge tag 'pwm/for-4.12-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
be13ec668d Merge branch 'topic/pl330' into for-linus
4879b7ae05 Merge tag 'dmaengine-4.12-rc1' of
git://git.infradead.org/users/vkoul/slave-dma
9e66317d3c Linux 4.14-rc3
1418b85217 Add linux-next specific files for 20170929
+---++++---+---+
| | ecc721a72c |
be13ec668d | 4879b7ae05 | v4.14-rc3 | next-20170929 |
+---++++---+---+
| boot_successes| 1009 | 1009
| 909| 5 | 510 |
| boot_failures | 0 | 0
| 1 | 4 | 153 |
| WARNING:kernel_stack | 0 | 0
| 1 | 3 | 111 |
| BUG:unable_to_handle_kernel | 0 | 0
| 0 | 3 | 48|
| Oops:#[##]| 0 | 0
| 0 | 3 | 48|
| EIP:update_stack_state| 0 | 0
| 0 | 3 | 48|
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0 | 0
| 0 | 3 | 48|
| invoked_oom-killer:gfp_mask=0x| 0 | 0
| 0 | 1 | 16|
| Mem-Info | 0 | 0
| 0 | 1 | 16|
| EIP:clear_user| 0 | 0
| 0 | 0 | 2 |
| EIP:copy_page_to_iter | 0 | 0
| 0 | 0 | 1 |
+---++++---+---+
Sorry, here's a version which actually compiles.
OK.
Thanks,
Fengguang
diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index d145a0b1f529..00234fa5a33a 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -44,7 +44,8 @@ static void unwind_dump(struct unwind_state *state)
state->stack_info.type, state->stack_info.next_sp,
state->stack_mask, state->graph_idx);
- for (sp = state->orig_sp; sp; sp = PTR_ALIGN(stack_info.next_sp,
sizeof(long))) {
+ for (sp = PTR_ALIGN(state->orig_sp, sizeof(long)); sp;
+sp = PTR_ALIGN(stack_info.next_sp, sizeof(long))) {
if (get_stack_info(sp, state->task, &stack_info, &visit_mask))
break;
--
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
