[PATCH] xhci: Bad Ethernet performance plugged in ASM1042A host
When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
performance was manifesting in Web browser use (like download
large file such as ISO image). It is known limitation of
ASM1042A that is not compatible with driver scheduling,
As a workaround we can modify flow control handling of ASM1042A.
Signed-off-by: Jiahau Chang
---
drivers/usb/host/pci-quirks.c | 62 +++
drivers/usb/host/pci-quirks.h | 1 +
drivers/usb/host/xhci-pci.c | 5
drivers/usb/host/xhci.c | 4 +++
drivers/usb/host/xhci.h | 1 +
5 files changed, 73 insertions(+)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index a9a1e4c..40a7220 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -77,6 +77,12 @@
#define USB_INTEL_USB3_PSSEN 0xD8
#define USB_INTEL_USB3PRM 0xDC
+/*ASMEDIA quirk use*/
+#define ASMT_DATA_WRITE0_REG 0xF8
+#define ASMT_DATA_WRITE1_REG 0xFC
+#define ASMT_CONTROL_REG 0xE0
+#define ASMT_CONTROL_WRITE_BIT 0x02
+
/*
* amd_chipset_gen values represent AMD different chipset generations
*/
@@ -412,6 +418,62 @@ void usb_amd_quirk_pll_disable(void)
}
EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
+void usb_asmedia_modify_flowcontrol_handling(struct pci_dev *pdev)
+{
+ u32 value_low, value_high;
+ unsigned char value;
+ unsigned long wait_time_count;
+
+ wait_time_count = 1000;
+ while (wait_time_count) {
+ pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
+ if (value == 0xff) {
+ dev_dbg(&pdev->dev, "%s: wait_write_ready IO_ERROR,
value=%x\n",
+ __func__, value);
+ goto err_exit;
+ } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
+ break;
+ }
+ wait_time_count--;
+ udelay(50);
+ }
+ if (wait_time_count == 0) {
+ dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
+ __func__);
+ goto err_exit;
+ }
+ value_low = 0x00010423;
+ value_high = 0xFA30;
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, value_low);
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, value_high);
+ pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
+ wait_time_count = 1000;
+ while (wait_time_count) {
+ pci_read_config_byte(pdev, ASMT_CONTROL_REG, &value);
+ if (value == 0xff) {
+ dev_dbg(&pdev->dev, "%s: wait_write_ready IO_ERROR,
value=%x\n",
+ __func__, value);
+ goto err_exit;
+ } else if ((value & ASMT_CONTROL_WRITE_BIT) == 0) {
+ break;
+ }
+ wait_time_count--;
+ udelay(50);
+ }
+ if (wait_time_count == 0) {
+ dev_dbg(&pdev->dev, "%s: wait_write_ready timeout\n",
+ __func__);
+ goto err_exit;
+ }
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE0_REG, 0xBA);
+ pci_write_config_dword(pdev, ASMT_DATA_WRITE1_REG, 0);
+ pci_write_config_byte(pdev, ASMT_CONTROL_REG, ASMT_CONTROL_WRITE_BIT);
+
+err_exit:
+ return;
+}
+EXPORT_SYMBOL_GPL(usb_asmedia_modify_flowcontrol_handling);
+
void usb_amd_quirk_pll_enable(void)
{
usb_amd_quirk_pll(0);
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index 0222195..5107442 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -11,6 +11,7 @@ bool usb_amd_prefetch_quirk(void);
void usb_amd_dev_put(void);
void usb_amd_quirk_pll_disable(void);
void usb_amd_quirk_pll_enable(void);
+void usb_asmedia_modify_flowcontrol_handling(struct pci_dev *pdev);
void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev);
void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
void sb800_prefetch(struct device *dev, int on);
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fcf1f3f..fba52f0 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -53,6 +53,7 @@
#define PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI 0x1aa8
#define PCI_DEVICE_ID_INTEL_APL_XHCI 0x5aa8
#define PCI_DEVICE_ID_INTEL_DNV_XHCI 0x19d0
+#define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142
static const char hcd_name[] = "xhci_hcd";
@@ -202,6 +203,10 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
pdev->device == 0x1042)
xhci->quirks |= XHCI_BROKEN_STREAMS;
+ if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
+ pdev->device == PCI_DEVICE_ID_ASMEDIA_1042A_XHCI)
+ xhci->quirks |= XHCI_ASMEDIA_MODIFY_FLOWCONTROL;
+
if (pdev->vendor == PC
Re: [PATCH 1/2] usb: gadget: core: introduce ->udc_set_speed() method
Hi, Alan Stern writes: >> Alan Stern writes: >> > On Tue, 6 Jun 2017, Felipe Balbi wrote: >> > >> >> Sometimes, the gadget driver we want to run has max_speed lower than >> >> what the UDC supports. In such situations, UDC might want to make sure >> >> we don't try to connect on speeds not supported by the gadget >> >> driver (e.g. super-speed capable dwc3 with high-speed capable g_midi) >> >> because that will just fail. >> >> >> >> In order to make sure this situation never happens, we introduce a new >> >> optional ->udc_set_speed() method which can be implemented by >> >> interested UDC drivers. >> >> >> >> Signed-off-by: Felipe Balbi >> > >> > dummy-hcd already checks for this in its dummy_pullup() routine. >> > Should other UDC drivers copy this approach? >> >> sounds like a layer violation to me :-s You're basically relying on the >> fact the the UDC (dummy, dwc3, chipidea, musb, etc) have access to a >> pointer to the usb_gadget_driver currently running. If that changes - >> and it's not too farfectched of a change, since UDC doesn't need to know >> which gadget driver is running - dummy may break. I would rather patch >> dummy a bit to implement ->udc_set_speed(). >> >> What do you think? > > Well, it wasn't a layering violation back in the days of the original > gadget stack. But the design has changed over time, and I take your > point. > > Currently, dummy_hcd uses the following fields from the gadget driver > structure: the disconnect, suspend, resume, and setup callbacks, and > the max_speed and function values (the last is only for a sysfs entry). > It seems reasonable to move all these things into the UDC core. Thank you. I'll patch dummy to implement ->udc_set_speed(). I'll also have a look at dummy's sysfs entries. cheers -- 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
[PATCH 2/2] HID: usbhid: Add HID_QUIRK_NO_INIT_REPORTS for Oculus Rift CV1
When plugging in an Oculus Rift CV1 HMD, it takes a long time until the hidraw
devices appear, specifically two control transfers time out querying the HID
report descriptors:
$ echo 1 > /sys/module/hid/parameters/debug
usb 1-3.1: new full-speed USB device number 11 using xhci_hcd
usb 1-3.1: New USB device found, idVendor=2833, idProduct=0031
usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3.1: Product: Rift
usb 1-3.1: Manufacturer: Oculus VR, Inc.
drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 0
hid-generic 0003:2833:0031.0005: Kicking head 1 tail 0
drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report
wValue=0x0101 wIndex=0x wLength=62
drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report
wValue=0x010b wIndex=0x wLength=64
[10 s delay]
drivers/hid/usbhid/hid-core.c: timeout waiting for ctrl or out queue to
clear
drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report
wValue=0x010c wIndex=0x wLength=64
hid-generic 0003:2833:0031.0005: usb_submit_urb(ctrl) failed: -1
hid-generic 0003:2833:0031.0005: timeout initializing reports
hid-generic 0003:2833:0031.0005: hiddev0,hidraw0: USB HID v1.10 Device
[Oculus VR, Inc. Rift] on usb-:00:14.0-3.1/input0
drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 1
hid-generic 0003:2833:0031.0006: Kicking head 1 tail 0
drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report
wValue=0x0101 wIndex=0x0001 wLength=62
drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report
wValue=0x010b wIndex=0x0001 wLength=64
[10 s delay]
drivers/hid/usbhid/hid-core.c: timeout waiting for ctrl or out queue to
clear
drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report
wValue=0x010c wIndex=0x0001 wLength=64
hid-generic 0003:2833:0031.0006: usb_submit_urb(ctrl) failed: -1
hid-generic 0003:2833:0031.0006: timeout initializing reports
hid-generic 0003:2833:0031.0006: hiddev0,hidraw1: USB HID v1.10 Device
[Oculus VR, Inc. Rift] on usb-:00:14.0-3.1/input1
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
These timeouts disappear when setting HID_QUIRK_NO_INIT_REPORTS. The hidraw
devices appear quickly and are functional.
Signed-off-by: Philipp Zabel
---
drivers/hid/usbhid/hid-quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 6316498b7812..7b2df4042167 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -111,6 +111,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_OCULUSVR, USB_DEVICE_ID_RIFT_CV1,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1610, HID_QUIRK_NOGET
},
{ USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_1640, HID_QUIRK_NOGET
},
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
--
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 1/2] HID: Add Oculus Rift CV1 id
Add VID/PID for Oculus Rift CV1. Signed-off-by: Philipp Zabel --- drivers/hid/hid-ids.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 8ca1e8ce0af2..2953d53a8cc9 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -1133,6 +1133,9 @@ #define USB_VENDOR_ID_MULTIPLE_17810x1781 #define USB_DEVICE_ID_RAPHNET_4NES4SNES_OLD0x0a9d +#define USB_VENDOR_ID_OCULUSVR 0x2833 +#define USB_DEVICE_ID_RIFT_CV1 0x0031 + #define USB_VENDOR_ID_DRACAL_RAPHNET 0x289b #define USB_DEVICE_ID_RAPHNET_2NES2SNES0x0002 #define USB_DEVICE_ID_RAPHNET_4NES4SNES0x0003 -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous, infinite warm reset attempts in Chipidea HDRC on multiple connect-disconects
On Tue, Jun 06, 2017 at 05:56:56PM +0530, lingareddy praneethreddy wrote: > I am using Chipidea HDRC on imx6sl platform. On connecting USB stick > (sometimes) and Android/ Apple phone (frequent) to ci-hdrc multiple > time it is seen that hub (ehci_hub_control()) reports continuous > USB_PORT_FEAT_C_RESET (infinitely) before a disconnect-connect caused > USB_PORT_FEAT_C_OVER_CURRENT. > > I have two queries: > 1. Can we avoid the continuous warm reset ( USB_PORT_FEAT_C_RESET ) > i.e. can we force hub to initialize again and enumerate the device > again? > 2. Do we need to initialize both controller and hub i.e. we > initialized controller (calling ehci_setup() and ehci_run()) but the > hub continued the resets until the overcurrent bit was set. > Try to disable over current at dts with property 'disable-over-current', if it can't fix your problem, follow Alan's suggestion. If it can fix your problem, try to fix your OC pinmux or polarity. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] usb-phy-generic: Add support to SMSC USB3315
On Tue, Jun 06, 2017 at 07:36:10PM +0200, Fabien Lahoudere wrote: > Hi Peter, > > On Tue, 2017-06-06 at 09:55 +0800, Peter Chen wrote: > > On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote: > > > On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote: > > > > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote: > > > > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote: > > > > > > On 05/26, Fabien Lahoudere wrote: > > > > > > > Hello > > > > > > > > > > > > > > I modify ci_hrdc_imx_probe to bypass "data->phy = > > > > > > > devm_usb_get_phy_by_phandle(&pdev- > > > > > > > >dev, > > > > > > > "fsl,usbphy", 0);". Everything works as expected and call > > > > > > > ci_ulpi_init. > > > > > > > > > > > > > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = > > > > > > > ulpi_register_interface(ci- > > > > > > > > dev, > > > > > > > > > > > > > > &ci->ulpi_ops);" (to initialize our phy), > > > > > > > "hw_phymode_configure(ci);" is called which is > > > > > > > the > > > > > > > original function that make our system to hang. > > > > > > > > > > > > > > Our phy is not initialised before calling ulpi_register_interface > > > > > > > so I don't understand > > > > > > > how > > > > > > > the > > > > > > > phy > > > > > > > can reply if it is not out of reset state. > > > > > > > > > > > > I haven't see any problem in hw_phymode_configure(). What's the > > > > > > value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If > > > > > > you phy needs to be taken out of reset to reply to the ulpi reads > > > > > > of the vendor/product ids, then it sounds like you have a similar > > > > > > situation to what I had. I needed to turn on some regulators to > > > > > > get those reads to work, otherwise they would fail, but knowing > > > > > > what needed to be turned on basically meant I needed to probe the > > > > > > ulpi driver so probing the ids wasn't going to be useful. So on > > > > > > my device the reads for the ids go through, but they get all > > > > > > zeroes back, which is actually ok because there aren't any bits > > > > > > set on my devices anyway. After the reads see 0, we fallback to > > > > > > DT matching, which avoids the "bring it out of reset/power it on" > > > > > > sorts of problems entirely. > > > > > > > > > > > > > > > > Yes the phy mode is configured to USBPHY_INTERFACE_MODE_ULPI. > > > > > Indeed, this phy need to be out of reset to work. For example > > > > > everything works fine if I > > > > > call > > > > > "_ci_usb_phy_init(ci);" before calling "hw_phymode_configure(ci);" > > > > > This function only init reset GPIO and clock. > > > > > > > > > > For information, the original patch I have to fix the issue: > > > > > > > > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > > > > > index 79ad8e9..21aaff1 100644 > > > > > --- a/drivers/usb/chipidea/core.c > > > > > +++ b/drivers/usb/chipidea/core.c > > > > > @@ -391,6 +391,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > > > > > case USBPHY_INTERFACE_MODE_UTMI: > > > > > case USBPHY_INTERFACE_MODE_UTMIW: > > > > > case USBPHY_INTERFACE_MODE_HSIC: > > > > > + case USBPHY_INTERFACE_MODE_ULPI: > > > > > ret = _ci_usb_phy_init(ci); > > > > > if (!ret) > > > > > hw_wait_phy_stable(); > > > > > @@ -398,7 +399,6 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > > > > > return ret; > > > > > hw_phymode_configure(ci); > > > > > break; > > > > > - case USBPHY_INTERFACE_MODE_ULPI: > > > > > case USBPHY_INTERFACE_MODE_SERIAL: > > > > > hw_phymode_configure(ci); > > > > > ret = _ci_usb_phy_init(ci); > > > > > -- > > > > > > > > Currently, the hw_phymode_configure is called twice for ULPI PHY, the > > > > two execution are between _ci_usb_phy_init, would you test which one > > > > causes hang? If the second causes hang, you can make a patch for > > > > hw_phymode_configure that if the required PORTSC_PTS is the same > > > > the value in register, do noop. > > > > > > The first one hangs, _ci_usb_phy_init is not called due to hang. > > > > > > > So, you need to comment out hw_phymode_configure at ci_ulpi_init, and you > > can't get vid/pid correctly, right? If it is, we may need to add power on > > sequence at chipidea core driver (ci_hdrc_probe) for clock and reset things. > > > > http://www.spinics.net/lists/linux-usb/msg157134.html > > > > I am wondering if we can call ci_usb_phy_init before calling ci_ulpi_init, > > since we need to let hardware be ready before reading vid/pid. > > Stephen & Fabien, does that work for you? > > > > I test the following patch and it works. But I am not sure that we can move > safely ci_ulpi_init. > I will investigate more tomorrow if it is a problem for other phys. > > Is it a good approach? > > Subject: [PATCH 1/1] power on phy before getting vid/pid >
Re: [PATCH v4 0/3] USB Audio Gadget refactoring
On Tue, Jun 6, 2017 at 12:41 PM, Felipe Balbi wrote: > > Hi, > > Greg KH writes: >>> > I'm OK with dropping legacy f_uac1 implementation. >>> > >>> > Another idea I was thinking about is to implement simple in-kernel >>> > driver which will do the same as existing alsaloop tool userspace >>> > tool does (so legacy users will need to load two kernel modules >>> > and get same functionality). But this seems to be a wrong way, >>> > since It known that Linux kernel community doesn't like to take drivers >>> > with same functionality as existing userspace tools already have. >>> > >>> > So bottom line: since I'm not a legacy f_uac1 user, there is no >>> > difference for me how to handle it - remove legacy f_uac1 completely, >>> > rename it to f_uac1_legacy or add separate f_uac1_acard function. >>> > >>> > So if dropping of legacy f_uac1 implementation is OK for you, >>> > I can do it quickly in next patchset. >>> >>> Personally, I don't want duplicated functionality and I think the >>> virtual sound card approach is much better. Then again, removing >>> functionality we already support is kind of odd. >>> >>> Greg, Alan, what do you guys think? Do we keep a duplicated function >>> around or do we just tell people to rely on alsaloop? Personally, I >>> think we're better off with the flexibility of the virtual sound card, >>> what's your take? >> >> If the in-kernel driver will do more things, and we don't break the >> existing setups using alsaloop, then I don't see the problem, except >> that we now have to maintain two things :) >> >> If you don't mind the maintenance, fine with me... > > Okay, I don't think many will continue to use f_uac1.c. Ruslan, can you > update your series so that current f_uac1.c gets renamed to > f_uac1_legacy.c and you introduce a *new* f_uac1.c instead? Yes sure, I'll post an updated patch series soon Best regards, Ruslan -- 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 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt
Hi Felipe,
On 6/4/2017 11:08 PM, Felipe Balbi wrote:
> Paul Zimmerman writes:
>> Forgot to CC linux-usb, doing that now
>>
>> On Fri, 2 Jun 2017 16:27:56 -0700, Paul Zimmerman wrote:
>>
>>> Felipe Balbi writes:
Thinh Nguyen writes:
> this could be, I don't remember if I checked this or not :-)
>
> Really, the best way here, IMHO, would be to re-verify what's going on
> with macOS and revert my orignal patch since it's, rather clearly,
> wrong.
>
Sure. Are you going to make a revert patch or I am?
>>>
>>> Well, after we really know what's going on with macOS and have a better
>>> fix, then who makes the revert is less important as long as problems get
>>> sorted out :-) Either way is fine for me.
>>>
>>
>> Do you have any update on this issue?
>>
>
> The patch ffb80fc672c3 ("usb: dwc3: gadget: skip Set/Clear Halt when
> invalid") still causes a regression for us. As there hasn't any update
> for the macOS issue, can I submit a revert patch for this?
I just came back from vacations ;-) I'll get back to this. Reverting
that commit won't do any good as we'd be exchanging one regression for
another. We really need to understand what's going on.
>>>
>>> Hi Felipe,
>>>
>>> I think we worked around this same issue in the Synopsys vendor driver
>>> after a customer reported a problem with CLEAR_FEATURE(ENDPOINT_HALT).
>>> I no longer have access to either the databook or the codebase, so I
>>> can't be sure about what the workaround was, but if either John or Thinh
>>> can have a look at the Clear Stall code in the vendor driver they should
>>> be able to figure it out.
>
> Thanks a lot Paul :-) Good to see you still have a look here every once
> in a while :-)
>
> John, Thinh could either of you check what Paul mentions here?
>
> cheers
>
Can you provide more detail on the issue you see on MAC OS? and how to
reproduce the issue?
Thanks,
Thinh
--
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: dwc2: add support for the DWC2 controller on Meson8 SoCs
Hi John,
On Tue, Jun 6, 2017 at 3:48 AM, John Youn wrote:
> On 5/25/2017 10:39 AM, Martin Blumenstingl wrote:
>> Hi John,
>>
>> On Sat, May 6, 2017 at 7:37 PM, Martin Blumenstingl
>> wrote:
>>> USB support in the Meson8 SoCs is provided by a DWC2 controller which
>>> works with the same settings as Meson8b and GXBB. Using the generic
>>> "snps,dwc2" binding results in an endless stream of "Overcurrent change
>>> detected" messages.
>>>
>>> Signed-off-by: Martin Blumenstingl
>> do you want me to re-send this with Rob's ACK?
>> also please let me know if something is still missing in this patch
>>
>>> ---
>>> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
>>> drivers/usb/dwc2/params.c | 2 ++
>>> 2 files changed, 3 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt
>>> b/Documentation/devicetree/bindings/usb/dwc2.txt
>>> index 6c7c2bce6d0c..b55be381ae85 100644
>>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>>> @@ -10,6 +10,7 @@ Required properties:
>>>- "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288
>>> Soc;
>>>- "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX
>>> SoCs;
>>>- "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX
>>> SoCs;
>>> + - "amlogic,meson8-usb": The DWC2 USB controller instance in Amlogic
>>> Meson8 SoCs;
>>>- "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic
>>> Meson8b SoCs;
>>>- "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic
>>> S905 SoCs;
>>>- "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands
>>> 460EX SoCs;
>>> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
>>> index 2990c347289f..0d6290ed66ea 100644
>>> --- a/drivers/usb/dwc2/params.c
>>> +++ b/drivers/usb/dwc2/params.c
>>> @@ -128,6 +128,8 @@ const struct of_device_id dwc2_of_match_table[] = {
>>> { .compatible = "lantiq,xrx200-usb", .data = dwc2_set_ltq_params },
>>> { .compatible = "snps,dwc2" },
>>> { .compatible = "samsung,s3c6400-hsotg" },
>>> + { .compatible = "amlogic,meson8-usb",
>>> + .data = dwc2_set_amlogic_params },
>>> { .compatible = "amlogic,meson8b-usb",
>>> .data = dwc2_set_amlogic_params },
>>> { .compatible = "amlogic,meson-gxbb-usb",
>>> --
>>> 2.12.2
>>>
>>
>
> Adding Felipe
>
>
> Acked-by: John Youn
thank you!
actually Greg seems to have picked it up already as it's part of his
v4.12-rc4 pull request: [0]
(I'm not sure why it went into v4.12-rc4 instead of -next/v4.13 - but
it probably won't hurt anyone)
[0] https://www.spinics.net/lists/linux-usb/msg157693.html
--
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 1/2] usb: gadget: core: introduce ->udc_set_speed() method
On Tue, 6 Jun 2017, Felipe Balbi wrote: > Hi, > > Alan Stern writes: > > On Tue, 6 Jun 2017, Felipe Balbi wrote: > > > >> Sometimes, the gadget driver we want to run has max_speed lower than > >> what the UDC supports. In such situations, UDC might want to make sure > >> we don't try to connect on speeds not supported by the gadget > >> driver (e.g. super-speed capable dwc3 with high-speed capable g_midi) > >> because that will just fail. > >> > >> In order to make sure this situation never happens, we introduce a new > >> optional ->udc_set_speed() method which can be implemented by > >> interested UDC drivers. > >> > >> Signed-off-by: Felipe Balbi > > > > dummy-hcd already checks for this in its dummy_pullup() routine. > > Should other UDC drivers copy this approach? > > sounds like a layer violation to me :-s You're basically relying on the > fact the the UDC (dummy, dwc3, chipidea, musb, etc) have access to a > pointer to the usb_gadget_driver currently running. If that changes - > and it's not too farfectched of a change, since UDC doesn't need to know > which gadget driver is running - dummy may break. I would rather patch > dummy a bit to implement ->udc_set_speed(). > > What do you think? Well, it wasn't a layering violation back in the days of the original gadget stack. But the design has changed over time, and I take your point. Currently, dummy_hcd uses the following fields from the gadget driver structure: the disconnect, suspend, resume, and setup callbacks, and the max_speed and function values (the last is only for a sysfs entry). It seems reasonable to move all these things into the UDC core. 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 1/2] usb: gadget: core: introduce ->udc_set_speed() method
Hi, Alan Stern writes: > On Tue, 6 Jun 2017, Felipe Balbi wrote: > >> Sometimes, the gadget driver we want to run has max_speed lower than >> what the UDC supports. In such situations, UDC might want to make sure >> we don't try to connect on speeds not supported by the gadget >> driver (e.g. super-speed capable dwc3 with high-speed capable g_midi) >> because that will just fail. >> >> In order to make sure this situation never happens, we introduce a new >> optional ->udc_set_speed() method which can be implemented by >> interested UDC drivers. >> >> Signed-off-by: Felipe Balbi > > dummy-hcd already checks for this in its dummy_pullup() routine. > Should other UDC drivers copy this approach? sounds like a layer violation to me :-s You're basically relying on the fact the the UDC (dummy, dwc3, chipidea, musb, etc) have access to a pointer to the usb_gadget_driver currently running. If that changes - and it's not too farfectched of a change, since UDC doesn't need to know which gadget driver is running - dummy may break. I would rather patch dummy a bit to implement ->udc_set_speed(). What do you think? -- 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: [RFC] usb-phy-generic: Add support to SMSC USB3315
Hi Peter, On Tue, 2017-06-06 at 09:55 +0800, Peter Chen wrote: > On Mon, Jun 05, 2017 at 11:52:26AM +0200, Fabien Lahoudere wrote: > > On Mon, 2017-06-05 at 17:43 +0800, Peter Chen wrote: > > > On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote: > > > > On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote: > > > > > On 05/26, Fabien Lahoudere wrote: > > > > > > Hello > > > > > > > > > > > > I modify ci_hrdc_imx_probe to bypass "data->phy = > > > > > > devm_usb_get_phy_by_phandle(&pdev- > > > > > > >dev, > > > > > > "fsl,usbphy", 0);". Everything works as expected and call > > > > > > ci_ulpi_init. > > > > > > > > > > > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = > > > > > > ulpi_register_interface(ci- > > > > > > > dev, > > > > > > > > > > > > &ci->ulpi_ops);" (to initialize our phy), > > > > > > "hw_phymode_configure(ci);" is called which is > > > > > > the > > > > > > original function that make our system to hang. > > > > > > > > > > > > Our phy is not initialised before calling ulpi_register_interface > > > > > > so I don't understand > > > > > > how > > > > > > the > > > > > > phy > > > > > > can reply if it is not out of reset state. > > > > > > > > > > I haven't see any problem in hw_phymode_configure(). What's the > > > > > value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If > > > > > you phy needs to be taken out of reset to reply to the ulpi reads > > > > > of the vendor/product ids, then it sounds like you have a similar > > > > > situation to what I had. I needed to turn on some regulators to > > > > > get those reads to work, otherwise they would fail, but knowing > > > > > what needed to be turned on basically meant I needed to probe the > > > > > ulpi driver so probing the ids wasn't going to be useful. So on > > > > > my device the reads for the ids go through, but they get all > > > > > zeroes back, which is actually ok because there aren't any bits > > > > > set on my devices anyway. After the reads see 0, we fallback to > > > > > DT matching, which avoids the "bring it out of reset/power it on" > > > > > sorts of problems entirely. > > > > > > > > > > > > > Yes the phy mode is configured to USBPHY_INTERFACE_MODE_ULPI. > > > > Indeed, this phy need to be out of reset to work. For example > > > > everything works fine if I > > > > call > > > > "_ci_usb_phy_init(ci);" before calling "hw_phymode_configure(ci);" > > > > This function only init reset GPIO and clock. > > > > > > > > For information, the original patch I have to fix the issue: > > > > > > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > > > > index 79ad8e9..21aaff1 100644 > > > > --- a/drivers/usb/chipidea/core.c > > > > +++ b/drivers/usb/chipidea/core.c > > > > @@ -391,6 +391,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > > > > case USBPHY_INTERFACE_MODE_UTMI: > > > > case USBPHY_INTERFACE_MODE_UTMIW: > > > > case USBPHY_INTERFACE_MODE_HSIC: > > > > + case USBPHY_INTERFACE_MODE_ULPI: > > > > ret = _ci_usb_phy_init(ci); > > > > if (!ret) > > > > hw_wait_phy_stable(); > > > > @@ -398,7 +399,6 @@ static int ci_usb_phy_init(struct ci_hdrc *ci) > > > > return ret; > > > > hw_phymode_configure(ci); > > > > break; > > > > - case USBPHY_INTERFACE_MODE_ULPI: > > > > case USBPHY_INTERFACE_MODE_SERIAL: > > > > hw_phymode_configure(ci); > > > > ret = _ci_usb_phy_init(ci); > > > > -- > > > > > > Currently, the hw_phymode_configure is called twice for ULPI PHY, the > > > two execution are between _ci_usb_phy_init, would you test which one > > > causes hang? If the second causes hang, you can make a patch for > > > hw_phymode_configure that if the required PORTSC_PTS is the same > > > the value in register, do noop. > > > > The first one hangs, _ci_usb_phy_init is not called due to hang. > > > > So, you need to comment out hw_phymode_configure at ci_ulpi_init, and you > can't get vid/pid correctly, right? If it is, we may need to add power on > sequence at chipidea core driver (ci_hdrc_probe) for clock and reset things. > > http://www.spinics.net/lists/linux-usb/msg157134.html > > I am wondering if we can call ci_usb_phy_init before calling ci_ulpi_init, > since we need to let hardware be ready before reading vid/pid. > Stephen & Fabien, does that work for you? > I test the following patch and it works. But I am not sure that we can move safely ci_ulpi_init. I will investigate more tomorrow if it is a problem for other phys. Is it a good approach? Subject: [PATCH 1/1] power on phy before getting vid/pid Signed-off-by: Fabien Lahoudere --- drivers/usb/chipidea/core.c | 12 drivers/usb/chipidea/ulpi.c | 19 +++ 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chi
Re: Please Add A Quectel EC25-E Device To A Proper Driver
> Judging from the product name and ids you provide above, this modem > should already be supported by the option driver since v4.11 and support > has also been backported to the stable trees (e.g. 4.4.58). > > So simply updating your kernel should do the trick here. > > Johan Fantastic news. I shall try to do that soon. -- TafT signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 9/9] usbip: vhci-hcd: Clean up the code by adding a new macro
On 05/18/2017 04:08 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> Each vhci has 2*VHCI_HC_PORTS ports, in which VHCI_HC_PORTS
> ports are HighSpeed (or below), and VHCI_HC_PORTS are SuperSpeed.
> This new macro VHCI_PORTS reflects this configuration.
>
> Signed-off-by: Yuyang Du
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/vhci.h | 5 -
> drivers/usb/usbip/vhci_sysfs.c | 10 +-
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/usbip/vhci.h b/drivers/usb/usbip/vhci.h
> index db28eb5..5cfb59e 100644
> --- a/drivers/usb/usbip/vhci.h
> +++ b/drivers/usb/usbip/vhci.h
> @@ -84,6 +84,9 @@ enum hub_speed {
> #define VHCI_HC_PORTS 8
> #endif
>
> +/* Each VHCI has 2 hubs (USB2 and USB3), each has VHCI_HC_PORTS ports */
> +#define VHCI_PORTS (VHCI_HC_PORTS*2)
> +
> #ifdef CONFIG_USBIP_VHCI_NR_HCS
> #define VHCI_NR_HCS CONFIG_USBIP_VHCI_NR_HCS
> #else
> @@ -145,7 +148,7 @@ static inline __u32 port_to_rhport(__u32 port)
>
> static inline int port_to_pdev_nr(__u32 port)
> {
> - return port / (VHCI_HC_PORTS * 2);
> + return port / VHCI_PORTS;
> }
>
> static inline struct vhci_hcd *hcd_to_vhci_hcd(struct usb_hcd *hcd)
> diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
> index 3ad68ff..5778b64 100644
> --- a/drivers/usb/usbip/vhci_sysfs.c
> +++ b/drivers/usb/usbip/vhci_sysfs.c
> @@ -92,7 +92,7 @@ static ssize_t status_show_vhci(int pdev_nr, char *out)
>
> spin_lock(&vdev->ud.lock);
> port_show_vhci(&out, HUB_SPEED_HIGH,
> -pdev_nr * VHCI_HC_PORTS * 2 + i, vdev);
> +pdev_nr * VHCI_PORTS + i,
> vdeshua...@osg.samsung.comv);
> spin_unlock(&vdev->ud.lock);
> }
>
> @@ -101,7 +101,7 @@ static ssize_t status_show_vhci(int pdev_nr, char *out)
>
> spin_lock(&vdev->ud.lock);
> port_show_vhci(&out, HUB_SPEED_SUPER,
> -pdev_nr * VHCI_HC_PORTS * 2 + VHCI_HC_PORTS + i,
> vdev);
> +pdev_nr * VHCI_PORTS + VHCI_HC_PORTS + i, vdev);
> spin_unlock(&vdev->ud.lock);
> }
>
> @@ -117,7 +117,7 @@ static ssize_t status_show_not_ready(int pdev_nr, char
> *out)
>
> for (i = 0; i < VHCI_HC_PORTS; i++) {
> out += sprintf(out, "hs %04u %03u ",
> - (pdev_nr * VHCI_HC_PORTS * 2) + i,
> + (pdev_nr * VHCI_PORTS) + i,
> VDEV_ST_NOTASSIGNED);
> out += sprintf(out, "000 0-0");
> out += sprintf(out, "\n");
> @@ -125,7 +125,7 @@ static ssize_t status_show_not_ready(int pdev_nr, char
> *out)
>
> for (i = 0; i < VHCI_HC_PORTS; i++) {
> out += sprintf(out, "ss %04u %03u ",
> - (pdev_nr * VHCI_HC_PORTS * 2) +
> VHCI_HC_PORTS + i,
> + (pdev_nr * VHCI_PORTS) + VHCI_HC_PORTS + i,
> VDEV_ST_NOTASSIGNED);
> out += sprintf(out, "000 0-0");
> out += sprintf(out, "\n");
> @@ -176,7 +176,7 @@ static ssize_t nports_show(struct device *dev, struct
> device_attribute *attr,
> /*
>* Half the ports are for SPEED_HIGH and half for SPEED_SUPER, thus the
> * 2.
>*/
> - out += sprintf(out, "%d\n", VHCI_HC_PORTS * vhci_num_controllers * 2);
> + out += sprintf(out, "%d\n", VHCI_PORTS * vhci_num_controllers);
> return out - s;
> }
> static DEVICE_ATTR_RO(nports);
>
--
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 8/9] usbip: vhci-hcd: Add USB3 port status bits
On 05/18/2017 04:08 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> As USB3 has (slightly) different bit meanings in the port
> status. Add a new status bit array for USB3.
>
> Signed-off-by: Yuyang Du
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/vhci_hcd.c | 56
> +++-
> 1 file changed, 50 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index 43cacbc..a71254b 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -66,7 +66,7 @@ static const char * const bit_desc[] = {
> "SUSPEND", /*2*/
> "OVER_CURRENT", /*3*/
> "RESET",/*4*/
> - "R5", /*5*/
> + "L1", /*5*/
> "R6", /*6*/
> "R7", /*7*/
> "POWER",/*8*/
> @@ -82,7 +82,7 @@ static const char * const bit_desc[] = {
> "C_SUSPEND",/*18*/
> "C_OVER_CURRENT", /*19*/
> "C_RESET", /*20*/
> - "R21", /*21*/
> + "C_L1", /*21*/
> "R22", /*22*/
> "R23", /*23*/
> "R24", /*24*/
> @@ -95,10 +95,49 @@ static const char * const bit_desc[] = {
> "R31", /*31*/
> };
>
> -static void dump_port_status_diff(u32 prev_status, u32 new_status)
> +static const char * const bit_desc_ss[] = {
> + "CONNECTION", /*0*/
> + "ENABLE", /*1*/
> + "SUSPEND", /*2*/
> + "OVER_CURRENT", /*3*/
> + "RESET",/*4*/
> + "L1", /*5*/
> + "R6", /*6*/
> + "R7", /*7*/
> + "R8", /*8*/
> + "POWER",/*9*/
> + "HIGHSPEED",/*10*/
> + "PORT_TEST",/*11*/
> + "INDICATOR",/*12*/
> + "R13", /*13*/
> + "R14", /*14*/
> + "R15", /*15*/
> + "C_CONNECTION", /*16*/
> + "C_ENABLE", /*17*/
> + "C_SUSPEND",/*18*/
> + "C_OVER_CURRENT", /*19*/
> + "C_RESET", /*20*/
> + "C_BH_RESET", /*21*/
> + "C_LINK_STATE", /*22*/
> + "C_CONFIG_ERROR", /*23*/
> + "R24", /*24*/
> + "R25", /*25*/
> + "R26", /*26*/
> + "R27", /*27*/
> + "R28", /*28*/
> + "R29", /*29*/
> + "R30", /*30*/
> + "R31", /*31*/
> +};
> +
> +static void dump_port_status_diff(u32 prev_status, u32 new_status, bool usb3)
> {
> int i = 0;
> u32 bit = 1;
> + const char * const *desc = bit_desc;
> +
> + if (usb3)
> + desc = bit_desc_ss;
>
> pr_debug("status prev -> new: %08x -> %08x\n", prev_status, new_status);
> while (bit) {
> @@ -113,8 +152,12 @@ static void dump_port_status_diff(u32 prev_status, u32
> new_status)
> else
> change = ' ';
>
> - if (prev || new)
> - pr_debug(" %c%s\n", change, bit_desc[i]);
> + if (prev || new) {
> + pr_debug(" %c%s\n", change, desc[i]);
> +
> + if (bit == 1) /* USB_PORT_STAT_CONNECTION */
> + pr_debug(" %c%s\n", change,
> "USB_PORT_STAT_SPEED_5GBPS");
> + }
> bit <<= 1;
> i++;
> }
> @@ -563,7 +606,8 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
> typeReq, u16 wValue,
> /* Only dump valid port status */
> if (rhport >= 0) {
> dump_port_status_diff(prev_port_status[rhport],
> - vhci_hcd->port_status[rhport]);
> + vhci_hcd->port_status[rhport],
> + hcd->speed == HCD_USB3);
> }
> }
> usbip_dbg_vhci_rh(" bye\n");
>
--
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 7/9] usbip: Add USB_SPEED_SUPER as valid arg
On 05/18/2017 04:08 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> With this patch, USB_SPEED_SUPER is a valid speed when attaching
> a USB3 SuperSpeed device.
>
> Signed-off-by: Yuyang Du
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/vhci_sysfs.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
> index cac2319..3ad68ff 100644
> --- a/drivers/usb/usbip/vhci_sysfs.c
> +++ b/drivers/usb/usbip/vhci_sysfs.c
> @@ -277,6 +277,7 @@ static int valid_args(__u32 pdev_nr, __u32 rhport, enum
> usb_device_speed speed)
> case USB_SPEED_FULL:
> case USB_SPEED_HIGH:
> case USB_SPEED_WIRELESS:
> + case USB_SPEED_SUPER:
> break;
> default:
> pr_err("Failed attach request for unsupported USB speed: %s\n",
>
--
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 6/9] usbip: vhci-hcd: Add USB3 SuperSpeed support
On 05/18/2017 04:08 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> This patch adds a USB3 HCD to an existing USB2 HCD and provides
> the support of SuperSpeed, in case the device can only be enumerated
> with SuperSpeed.
>
> The bulk of the added code in usb3_bos_desc and hub_control to support
> SuperSpeed is borrowed from the commit 1cd8fd2887e162ad ("usb: gadget:
> dummy_hcd: add SuperSpeed support").
>
> With this patch, each vhci will have VHCI_HC_PORTS HighSpeed ports
> and VHCI_HC_PORTS SuperSpeed ports.
>
> Suggested-by: Krzysztof Opasiak
> Signed-off-by: Yuyang Du
> Signed-off-by: Yuyang Du
Do you need this second signed-off??
Otherwise looks good.
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/vhci.h | 7 +-
> drivers/usb/usbip/vhci_hcd.c | 323
> ---
> drivers/usb/usbip/vhci_sysfs.c | 109
> tools/usb/usbip/libsrc/vhci_driver.c | 23 ++-
> tools/usb/usbip/libsrc/vhci_driver.h | 8 +-
> tools/usb/usbip/src/usbip_attach.c | 3 +-
> 6 files changed, 370 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/usb/usbip/vhci.h b/drivers/usb/usbip/vhci.h
> index 8a979fc..db28eb5 100644
> --- a/drivers/usb/usbip/vhci.h
> +++ b/drivers/usb/usbip/vhci.h
> @@ -72,6 +72,11 @@ struct vhci_unlink {
> unsigned long unlink_seqnum;
> };
>
> +enum hub_speed {
> + HUB_SPEED_HIGH = 0,
> + HUB_SPEED_SUPER,
> +};
> +
> /* Number of supported ports. Value has an upperbound of USB_MAXCHILDREN */
> #ifdef CONFIG_USBIP_VHCI_HC_PORTS
> #define VHCI_HC_PORTS CONFIG_USBIP_VHCI_HC_PORTS
> @@ -140,7 +145,7 @@ static inline __u32 port_to_rhport(__u32 port)
>
> static inline int port_to_pdev_nr(__u32 port)
> {
> - return port / VHCI_HC_PORTS;
> + return port / (VHCI_HC_PORTS * 2);
> }
>
> static inline struct vhci_hcd *hcd_to_vhci_hcd(struct usb_hcd *hcd)
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index 8cfba1d..43cacbc 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -232,6 +232,40 @@ static int vhci_hub_status(struct usb_hcd *hcd, char
> *buf)
> return changed ? retval : 0;
> }
>
> +/* usb 3.0 root hub device descriptor */
> +static struct {
> + struct usb_bos_descriptor bos;
> + struct usb_ss_cap_descriptor ss_cap;
> +} __packed usb3_bos_desc = {
> +
> + .bos = {
> + .bLength= USB_DT_BOS_SIZE,
> + .bDescriptorType= USB_DT_BOS,
> + .wTotalLength = cpu_to_le16(sizeof(usb3_bos_desc)),
> + .bNumDeviceCaps = 1,
> + },
> + .ss_cap = {
> + .bLength= USB_DT_USB_SS_CAP_SIZE,
> + .bDescriptorType= USB_DT_DEVICE_CAPABILITY,
> + .bDevCapabilityType = USB_SS_CAP_TYPE,
> + .wSpeedSupported= cpu_to_le16(USB_5GBPS_OPERATION),
> + .bFunctionalitySupport = ilog2(USB_5GBPS_OPERATION),
> + },
> +};
> +
> +static inline void
> +ss_hub_descriptor(struct usb_hub_descriptor *desc)
> +{
> + memset(desc, 0, sizeof *desc);
> + desc->bDescriptorType = USB_DT_SS_HUB;
> + desc->bDescLength = 12;
> + desc->wHubCharacteristics = cpu_to_le16(
> + HUB_CHAR_INDV_PORT_LPSM | HUB_CHAR_COMMON_OCPM);
> + desc->bNbrPorts = VHCI_HC_PORTS;
> + desc->u.ss.bHubHdrDecLat = 0x04; /* Worst case: 0.4 micro sec*/
> + desc->u.ss.DeviceRemovable = 0x;
> +}
> +
> static inline void hub_descriptor(struct usb_hub_descriptor *desc)
> {
> memset(desc, 0, sizeof(*desc));
> @@ -260,13 +294,15 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
> typeReq, u16 wValue,
>
> /*
>* NOTE:
> - * wIndex shows the port number and begins from 1.
> + * wIndex (bits 0-7) shows the port number and begins from 1?
>*/
> + wIndex = ((__u8)(wIndex & 0x00ff));
> usbip_dbg_vhci_rh("typeReq %x wValue %x wIndex %x\n", typeReq, wValue,
> wIndex);
> +
> if (wIndex > VHCI_HC_PORTS)
> pr_err("invalid port number %d\n", wIndex);
> - rhport = ((__u8)(wIndex & 0x00ff)) - 1;
> + rhport = wIndex - 1;
>
> vhci_hcd = hcd_to_vhci_hcd(hcd);
> vhci = vhci_hcd->vhci;
> @@ -286,34 +322,26 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
> typeReq, u16 wValue,
> case ClearPortFeature:
> switch (wValue) {
> case USB_PORT_FEAT_SUSPEND:
> + if (hcd->speed == HCD_USB3) {
> + pr_err(" ClearPortFeature:
> USB_PORT_FEAT_SUSPEND req not "
> +"supported for USB 3.0 roothub\n");
> + goto error;
> + }
> + usbip_dbg_vhci_rh(
> + " ClearPortFeature: USB_PORT_FEAT_SUSPEND\n");
> if (vhci_hcd->port
[PATCH v2 5/7] USB: of: fix root-hub device-tree node handling
In an attempt to work around a pinmux over-allocation issue in driver
core, commit dc5878abf49c ("usb: core: move root hub's device node
assignment after it is added to bus") moved the device-tree node
assignment until after the root hub had been registered.
This not only makes the device-tree node unavailable to the usb driver
during probe, but also prevents the of_node from being linked to in
sysfs and causes a race with user-space for the (recently added) devspec
attribute.
Use the new device_set_of_node_from_dev() helper to reuse the node of
the sysdev device, something which now prevents driver core from trying
to reclaim any pinctrl pins during probe.
Fixes: dc5878abf49c ("usb: core: move root hub's device node assignment after
it is added to bus")
Fixes: 51fa91475e43 ("usb/core: Added devspec sysfs entry for devices behind
the usb hub")
Signed-off-by: Johan Hovold
---
drivers/usb/core/hcd.c | 2 --
drivers/usb/core/usb.c | 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 5dea98358c05..2cff59e9c268 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1076,7 +1076,6 @@ static void usb_deregister_bus (struct usb_bus *bus)
static int register_root_hub(struct usb_hcd *hcd)
{
struct device *parent_dev = hcd->self.controller;
- struct device *sysdev = hcd->self.sysdev;
struct usb_device *usb_dev = hcd->self.root_hub;
const int devnum = 1;
int retval;
@@ -1123,7 +1122,6 @@ static int register_root_hub(struct usb_hcd *hcd)
/* Did the HC die before the root hub was registered? */
if (HCD_DEAD(hcd))
usb_hc_died (hcd); /* This time clean up */
- usb_dev->dev.of_node = sysdev->of_node;
}
mutex_unlock(&usb_bus_idr_lock);
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 62e1906bb2f3..17681d5638ac 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -416,8 +416,7 @@ static void usb_release_dev(struct device *dev)
usb_destroy_configuration(udev);
usb_release_bos_descriptor(udev);
- if (udev->parent)
- of_node_put(dev->of_node);
+ of_node_put(dev->of_node);
usb_put_hcd(hcd);
kfree(udev->product);
kfree(udev->manufacturer);
@@ -616,6 +615,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
dev->route = 0;
dev->dev.parent = bus->controller;
+ device_set_of_node_from_dev(&dev->dev, bus->sysdev);
dev_set_name(&dev->dev, "usb%d", bus->busnum);
root_hub = 1;
} else {
--
2.13.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 7/7] thermal: max77620: fix pinmux conflict on reprobe
Use the new helper for reusing a device-tree node of another device
instead of managing the node references explicitly.
This also makes sure that the new of_node_reuse flag is set if the
device is ever reprobed, something which specifically now avoids driver
core from attempting to claim any pinmux resources already claimed by
the parent device.
Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting
junction temp")
Cc: Laxman Dewangan
Signed-off-by: Johan Hovold
---
drivers/thermal/max77620_thermal.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/max77620_thermal.c
b/drivers/thermal/max77620_thermal.c
index 71d35f3c9215..159bbcee8821 100644
--- a/drivers/thermal/max77620_thermal.c
+++ b/drivers/thermal/max77620_thermal.c
@@ -112,12 +112,10 @@ static int max77620_thermal_probe(struct platform_device
*pdev)
}
/*
-* Drop any current reference to a device-tree node and get a
-* reference to the parent's node which will be balanced on reprobe or
-* on platform-device release.
+* The reference taken to the parent's node which will be balanced on
+* reprobe or on platform-device release.
*/
- of_node_put(pdev->dev.of_node);
- pdev->dev.of_node = of_node_get(pdev->dev.parent->of_node);
+ device_set_of_node_from_dev(&pdev->dev, pdev->dev.parent);
mtherm->tz_device = devm_thermal_zone_of_sensor_register(&pdev->dev, 0,
mtherm, &max77620_thermal_ops);
--
2.13.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/7] driver core/USB/thermal: fix device-tree node reuse
This series fixes a few issues related to device-tree node reuse.
It is fairly common for drivers to reuse the device-tree node of a
parent (or other ancestor) device when creating class or bus devices
(e.g. gpio chips, i2c adapters, iio chips, spi masters, serdev, phys,
usb root hubs). But reusing a device-tree node may cause problems *if*
the new device is later probed as for example driver core would
currently attempt to reinitialise an already active associated pinmux
configuration.
[ NB: For most examples above this is currently not a problem as the
devices reusing a node are never probed. ]
Other potential issues include the platform-bus code unconditionally
dropping the device-tree-node reference in its device destructor,
reinitialisation of other bus-managed resources such as clocks, and
(possibly) the recently added DMA-setup in driver core.
Instead of having drivers try to work around this (as is currently done
for USB root hubs), we can allow devices to reuse a device-tree node by
setting a flag in their struct device that can be used by core, bus and
driver code to avoid resources from being over-allocated.
The first two patches fix a device-tree node reference leak for
non-root-hub devices in USB. These were submitted yesterday to the USB
list, but are included here for completeness.
The third and fourth patches add a helper that can be used when reusing
a device-tree node of another device and that specifically sets a new
of_node_reused flag which is then used by driver core to skip the
automatic pinctrl configuration during probe.
The fifth patch removes the pinctrl over-allocation workaround from USB
core, which also had some undesirable side-effects.
The final two patches fix a device-tree node imbalance and
use-after-free in an thermal driver, where a platform device was reusing
the device-tree node of its parent mfd during probe. This would also
prevent the child device from being reprobed (e.g. due to probe
deferral) if the parent node defines a pinctrl configuration.
Note that this series is against 4.12-rc3.
For reference, here is a list of relevant commits leading up to the
current situation:
- [2013-01-22] ab78029ecc34 ("drivers/pinctrl: grab default handles from
device core")
- [2016-02-19] 69bec7259853 ("USB: core: let USB device know device node")
- [2016-04-25] dc5878abf49c ("usb: core: move root hub's device node
assignment after it is added to bus")
- [2016-10-06] 51fa91475e43 ("usb/core: Added devspec sysfs entry for devices
behind the usb hub")
- [2017-03-13] a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
- [2017-04-10] 09515ef5ddad ("of/acpi: Configure dma operations at probe time
for platform/amba/pci bus devices")
Greg, I'm not sure how best to handle merging this, but I guess all
could go in through driver-core-next to make handling dependencies
easier even if patches 1,2 and 6 could otherwise be considered for
4.12-rc.
Johan
Changes in v2
- update kernel doc comment (2/7)
- add missing kernel doc comment (3/7)
- add Peter's and Linus's acks (1/7 and 4/7)
Johan Hovold (7):
USB: core: fix device node leak
USB: of: document reference taken by child-lookup helper
driver core: add helper to reuse a device-tree node
driver core: fix automatic pinctrl management
USB: of: fix root-hub device-tree node handling
thermal: max77620: fix device-node reference imbalance
thermal: max77620: fix pinmux conflict on reprobe
drivers/base/core.c| 16
drivers/base/pinctrl.c | 3 +++
drivers/thermal/max77620_thermal.c | 8 ++--
drivers/usb/core/hcd.c | 2 --
drivers/usb/core/of.c | 3 ++-
drivers/usb/core/usb.c | 2 ++
include/linux/device.h | 4
7 files changed, 33 insertions(+), 5 deletions(-)
--
2.13.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 6/7] thermal: max77620: fix device-node reference imbalance
The thermal child device reuses the parent MFD-device device-tree node
when registering a thermal zone, but did not take a reference to the
node.
This leads to a reference imbalance, and potential use-after-free, when
the node reference is dropped by the platform-bus device destructor
(once for the child and later again for the parent).
Fix this by dropping any reference already held to a device-tree node
and getting a reference to the parent's node which will be balanced on
reprobe or on platform-device release, whichever comes first.
Note that simply clearing the of_node pointer on probe errors and on
driver unbind would not allow the use of device-managed resources as
specifically thermal_zone_of_sensor_unregister() claims that a valid
device-tree node pointer is needed during deregistration (even if it
currently does not seem to use it).
Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting
junction temp")
Cc: stable # 4.9
Cc: Laxman Dewangan
Signed-off-by: Johan Hovold
---
drivers/thermal/max77620_thermal.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/max77620_thermal.c
b/drivers/thermal/max77620_thermal.c
index e9a1fe342760..71d35f3c9215 100644
--- a/drivers/thermal/max77620_thermal.c
+++ b/drivers/thermal/max77620_thermal.c
@@ -104,8 +104,6 @@ static int max77620_thermal_probe(struct platform_device
*pdev)
return -EINVAL;
}
- pdev->dev.of_node = pdev->dev.parent->of_node;
-
mtherm->dev = &pdev->dev;
mtherm->rmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!mtherm->rmap) {
@@ -113,6 +111,14 @@ static int max77620_thermal_probe(struct platform_device
*pdev)
return -ENODEV;
}
+ /*
+* Drop any current reference to a device-tree node and get a
+* reference to the parent's node which will be balanced on reprobe or
+* on platform-device release.
+*/
+ of_node_put(pdev->dev.of_node);
+ pdev->dev.of_node = of_node_get(pdev->dev.parent->of_node);
+
mtherm->tz_device = devm_thermal_zone_of_sensor_register(&pdev->dev, 0,
mtherm, &max77620_thermal_ops);
if (IS_ERR(mtherm->tz_device)) {
--
2.13.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 3/7] driver core: add helper to reuse a device-tree node
Add a helper function to be used when reusing the device-tree node of
another device.
It is fairly common for drivers to reuse the device-tree node of a
parent (or other ancestor) device when creating class or bus devices
(e.g. gpio chips, i2c adapters, iio chips, spi masters, serdev, phys,
usb root hubs). But reusing a device-tree node may cause problems if the
new device is later probed as for example driver core would currently
attempt to reinitialise an already active associated pinmux
configuration.
Other potential issues include the platform-bus code unconditionally
dropping the device-tree node reference in its device destructor,
reinitialisation of other bus-managed resources such as clocks, and the
recently added DMA-setup in driver core.
Note that for most examples above this is currently not an issue as the
devices are never probed, but this is a problem for the USB bus which
has recently gained device-tree support. This was discovered and
worked-around in a rather ad-hoc fashion by commit dc5878abf49c ("usb:
core: move root hub's device node assignment after it is added to bus")
by not setting the of_node pointer until after the root-hub device has
been registered.
Instead we can allow devices to reuse a device-tree node by setting a
flag in their struct device that can be used by core, bus and driver
code to avoid resources from being over-allocated.
Note that the helper also grabs an extra reference to the device node,
which specifically balances the unconditional put in the platform-device
destructor.
Signed-off-by: Johan Hovold
---
drivers/base/core.c| 16
include/linux/device.h | 4
2 files changed, 20 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bbecaf9293be..c3064ff09af5 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2884,3 +2884,19 @@ void set_secondary_fwnode(struct device *dev, struct
fwnode_handle *fwnode)
else
dev->fwnode = fwnode;
}
+
+/**
+ * device_set_of_node_from_dev - reuse device-tree node of another device
+ * @dev: device whose device-tree node is being set
+ * @dev2: device whose device-tree node is being reused
+ *
+ * Takes another reference to the new device-tree node after first dropping
+ * any reference held to the old node.
+ */
+void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
+{
+ of_node_put(dev->of_node);
+ dev->of_node = of_node_get(dev2->of_node);
+ dev->of_node_reused = true;
+}
+EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518af5515..60ab00b13095 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -879,6 +879,8 @@ struct dev_links_info {
*
* @offline_disabled: If set, the device is permanently online.
* @offline: Set after successful invocation of bus type's .offline().
+ * @of_node_reused: Set if the device-tree node is shared with an ancestor
+ * device.
*
* At the lowest level, every device in a Linux system is represented by an
* instance of struct device. The device structure contains the information
@@ -966,6 +968,7 @@ struct device {
booloffline_disabled:1;
booloffline:1;
+ boolof_node_reused:1;
};
static inline struct device *kobj_to_dev(struct kobject *kobj)
@@ -1144,6 +1147,7 @@ extern int device_offline(struct device *dev);
extern int device_online(struct device *dev);
extern void set_primary_fwnode(struct device *dev, struct fwnode_handle
*fwnode);
extern void set_secondary_fwnode(struct device *dev, struct fwnode_handle
*fwnode);
+void device_set_of_node_from_dev(struct device *dev, const struct device
*dev2);
static inline int dev_num_vf(struct device *dev)
{
--
2.13.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 4/7] driver core: fix automatic pinctrl management
Commit ab78029ecc34 ("drivers/pinctrl: grab default handles from device
core") added automatic pin-control management to driver core by looking
up and setting any default pinctrl state found in device tree while a
device is being probed.
This obviously runs into problems as soon as device-tree nodes are
reused for child devices which are later also probed as pins would
already have been claimed by the ancestor device.
For example if a USB host controller claims a pin, its root hub would
consequently fail to probe when its device-tree node is set to the node
of the controller:
pinctrl-single 48002030.pinmux: pin PIN204 already requested by
48064800.ehci; cannot claim for usb1
pinctrl-single 48002030.pinmux: pin-204 (usb1) status -22
pinctrl-single 48002030.pinmux: could not request pin 204 (PIN204) from
group usb_dbg_pins on device pinctrl-single
usb usb1: Error applying setting, reverse things back
usb: probe of usb1 failed with error -22
Fix this by checking the new of_node_reused flag and skipping automatic
pinctrl configuration during probe if set.
Note that the flag is checked in driver core rather than in pinctrl
(e.g. in pinctrl_dt_to_map()) which would specifically have prevented
intentional use of a parent's pinctrl properties by a child device
(should such a need ever arise).
Fixes: ab78029ecc34 ("drivers/pinctrl: grab default handles from device core")
Acked-by: Linus Walleij
Signed-off-by: Johan Hovold
---
drivers/base/pinctrl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 5917b4b5fb99..eb929dd6ef1e 100644
--- a/drivers/base/pinctrl.c
+++ b/drivers/base/pinctrl.c
@@ -23,6 +23,9 @@ int pinctrl_bind_pins(struct device *dev)
{
int ret;
+ if (dev->of_node_reused)
+ return 0;
+
dev->pins = devm_kzalloc(dev, sizeof(*(dev->pins)), GFP_KERNEL);
if (!dev->pins)
return -ENOMEM;
--
2.13.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/7] USB: of: document reference taken by child-lookup helper
Document that the child-node lookup helper takes a reference to the device-tree node which needs to be dropped after use. Signed-off-by: Johan Hovold --- drivers/usb/core/of.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c index d563cbcf76cf..3863bb1ce8c5 100644 --- a/drivers/usb/core/of.c +++ b/drivers/usb/core/of.c @@ -28,7 +28,8 @@ * * Find the node from device tree according to its port number. * - * Return: On success, a pointer to the device node, %NULL on failure. + * Return: A pointer to the node with incremented refcount if found, or + * %NULL otherwise. */ struct device_node *usb_of_get_child_node(struct device_node *parent, int portnum) -- 2.13.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 1/7] USB: core: fix device node leak
Make sure to release any OF device-node reference taken when creating
the USB device.
Note that we currently do not hold a reference to the root hub
device-tree node (i.e. the parent controller node).
Fixes: 69bec7259853 ("USB: core: let USB device know device node")
Cc: stable # v4.6
Acked-by: Peter Chen
Signed-off-by: Johan Hovold
---
drivers/usb/core/usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 28b053cacc90..62e1906bb2f3 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -416,6 +416,8 @@ static void usb_release_dev(struct device *dev)
usb_destroy_configuration(udev);
usb_release_bos_descriptor(udev);
+ if (udev->parent)
+ of_node_put(dev->of_node);
usb_put_hcd(hcd);
kfree(udev->product);
kfree(udev->manufacturer);
--
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/9] usbip: vhci-hcd: Set the vhci structure up to work
On 05/18/2017 04:08 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> This patch enables the new vhci structure. Its lock protects
> both the USB2 hub and the shared USB3 hub.
>
> Signed-off-by: Yuyang Du
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/vhci.h | 2 -
> drivers/usb/usbip/vhci_hcd.c | 206
> -
> drivers/usb/usbip/vhci_rx.c| 16 ++--
> drivers/usb/usbip/vhci_sysfs.c | 26 --
> 4 files changed, 145 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/usb/usbip/vhci.h b/drivers/usb/usbip/vhci.h
> index 62ee537..8a979fc 100644
> --- a/drivers/usb/usbip/vhci.h
> +++ b/drivers/usb/usbip/vhci.h
> @@ -100,8 +100,6 @@ struct vhci {
> struct vhci_hcd {
> struct vhci *vhci;
>
> - spinlock_t lock;
> -
> u32 port_status[VHCI_HC_PORTS];
>
> unsigned resuming:1;
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index 2bc77ee..8cfba1d 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -123,7 +123,8 @@ static void dump_port_status_diff(u32 prev_status, u32
> new_status)
>
> void rh_port_connect(struct vhci_device *vdev, enum usb_device_speed speed)
> {
> - struct vhci_hcd *vhci = vdev_to_vhci_hcd(vdev);
> + struct vhci_hcd *vhci_hcd = vdev_to_vhci_hcd(vdev);
> + struct vhci *vhci = vhci_hcd->vhci;
> int rhport = vdev->rhport;
> u32 status;
> unsigned long flags;
> @@ -132,7 +133,7 @@ void rh_port_connect(struct vhci_device *vdev, enum
> usb_device_speed speed)
>
> spin_lock_irqsave(&vhci->lock, flags);
>
> - status = vhci->port_status[rhport];
> + status = vhci_hcd->port_status[rhport];
>
> status |= USB_PORT_STAT_CONNECTION | (1 << USB_PORT_FEAT_C_CONNECTION);
>
> @@ -147,16 +148,17 @@ void rh_port_connect(struct vhci_device *vdev, enum
> usb_device_speed speed)
> break;
> }
>
> - vhci->port_status[rhport] = status;
> + vhci_hcd->port_status[rhport] = status;
>
> spin_unlock_irqrestore(&vhci->lock, flags);
>
> - usb_hcd_poll_rh_status(vhci_hcd_to_hcd(vhci));
> + usb_hcd_poll_rh_status(vhci_hcd_to_hcd(vhci_hcd));
> }
>
> static void rh_port_disconnect(struct vhci_device *vdev)
> {
> - struct vhci_hcd *vhci = vdev_to_vhci_hcd(vdev);
> + struct vhci_hcd *vhci_hcd = vdev_to_vhci_hcd(vdev);
> + struct vhci *vhci = vhci_hcd->vhci;
> int rhport = vdev->rhport;
> u32 status;
> unsigned long flags;
> @@ -165,15 +167,15 @@ static void rh_port_disconnect(struct vhci_device *vdev)
>
> spin_lock_irqsave(&vhci->lock, flags);
>
> - status = vhci->port_status[rhport];
> + status = vhci_hcd->port_status[rhport];
>
> status &= ~USB_PORT_STAT_CONNECTION;
> status |= (1 << USB_PORT_FEAT_C_CONNECTION);
>
> - vhci->port_status[rhport] = status;
> + vhci_hcd->port_status[rhport] = status;
>
> spin_unlock_irqrestore(&vhci->lock, flags);
> - usb_hcd_poll_rh_status(vhci_hcd_to_hcd(vhci));
> + usb_hcd_poll_rh_status(vhci_hcd_to_hcd(vhci_hcd));
> }
>
> #define PORT_C_MASK \
> @@ -196,17 +198,15 @@ static void rh_port_disconnect(struct vhci_device *vdev)
> */
> static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
> {
> - struct vhci_hcd *vhci;
> - int retval;
> + struct vhci_hcd *vhci_hcd = hcd_to_vhci_hcd(hcd);
> + struct vhci *vhci = vhci_hcd->vhci;
> + int retval = DIV_ROUND_UP(VHCI_HC_PORTS + 1, 8);
> int rhport;
> int changed = 0;
> unsigned long flags;
>
> - retval = DIV_ROUND_UP(VHCI_HC_PORTS + 1, 8);
> memset(buf, 0, retval);
>
> - vhci = hcd_to_vhci_hcd(hcd);
> -
> spin_lock_irqsave(&vhci->lock, flags);
> if (!HCD_HW_ACCESSIBLE(hcd)) {
> usbip_dbg_vhci_rh("hw accessible flag not on?\n");
> @@ -215,7 +215,7 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
>
> /* check pseudo status register for each port */
> for (rhport = 0; rhport < VHCI_HC_PORTS; rhport++) {
> - if ((vhci->port_status[rhport] & PORT_C_MASK)) {
> + if ((vhci_hcd->port_status[rhport] & PORT_C_MASK)) {
> /* The status of a port has been changed, */
> usbip_dbg_vhci_rh("port %d status changed\n", rhport);
>
> @@ -247,7 +247,8 @@ static inline void hub_descriptor(struct
> usb_hub_descriptor *desc)
> static int vhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
> u16 wIndex, char *buf, u16 wLength)
> {
> - struct vhci_hcd *dum;
> + struct vhci_hcd *vhci_hcd;
> + struct vhci *vhci;
> int retval = 0;
> int rhport;
> unsigned long flags;
> @@ -267,13 +268,14 @@ static int vhci_hub_co
Re: [PATCH v2 4/9] usbip: vhci-hcd: Rework vhci_hcd_init
On 05/18/2017 04:08 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> A vhci struct is added as the platform-specific data to the vhci
> platform device, in order to get the vhci by its platform device.
> This is done in vhci_hcd_init().
>
> Signed-off-by: Yuyang Du
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/vhci_hcd.c | 51
>
> tools/usb/usbip/libsrc/vhci_driver.c | 2 +-
> tools/usb/usbip/libsrc/vhci_driver.h | 1 +
> 3 files changed, 30 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index 7a04497..2bc77ee 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -1173,24 +1173,6 @@ static struct platform_driver vhci_driver = {
> },
> };
>
> -static int add_platform_device(int id)
> -{
> - struct platform_device *pdev;
> - int dev_nr;
> -
> - if (id == 0)
> - dev_nr = -1;
> - else
> - dev_nr = id;
> -
> - pdev = platform_device_register_simple(driver_name, dev_nr, NULL, 0);
> - if (IS_ERR(pdev))
> - return PTR_ERR(pdev);
> -
> - vhcis[id].pdev = pdev;
> - return 0;
> -}
> -
> static void del_platform_devices(void)
> {
> struct platform_device *pdev;
> @@ -1219,23 +1201,46 @@ static int __init vhci_hcd_init(void)
> if (vhcis == NULL)
> return -ENOMEM;
>
> + for (i = 0; i < vhci_num_controllers; i++) {
> + vhcis[i].pdev = platform_device_alloc(driver_name, i);
> + if (!vhcis[i].pdev) {
> + i--;
> + while (i >= 0)
> + platform_device_put(vhcis[i--].pdev);
> + ret = -ENOMEM;
> + goto err_device_alloc;
> + }
> + }
> + for (i = 0; i < vhci_num_controllers; i++) {
> + void *vhci = &vhcis[i];
> + ret = platform_device_add_data(vhcis[i].pdev, &vhci,
> sizeof(void *));
> + if (ret)
> + goto err_driver_register;
> + }
> +
> ret = platform_driver_register(&vhci_driver);
> if (ret)
> goto err_driver_register;
>
> for (i = 0; i < vhci_num_controllers; i++) {
> - ret = add_platform_device(i);
> - if (ret)
> - goto err_platform_device_register;
> + ret = platform_device_add(vhcis[i].pdev);
> + if (ret < 0) {
> + i--;
> + while (i >= 0)
> + platform_device_del(vhcis[i--].pdev);
> + goto err_add_hcd;
> + }
> }
>
> pr_info(DRIVER_DESC " v" USBIP_VERSION "\n");
> return ret;
>
> -err_platform_device_register:
> - del_platform_devices();
> +err_add_hcd:
> platform_driver_unregister(&vhci_driver);
> err_driver_register:
> + for (i = 0; i < vhci_num_controllers; i++)
> + platform_device_put(vhcis[i].pdev);
> +err_device_alloc:
> kfree(vhcis);
> return ret;
> }
> diff --git a/tools/usb/usbip/libsrc/vhci_driver.c
> b/tools/usb/usbip/libsrc/vhci_driver.c
> index af88447..5b19a32 100644
> --- a/tools/usb/usbip/libsrc/vhci_driver.c
> +++ b/tools/usb/usbip/libsrc/vhci_driver.c
> @@ -248,7 +248,7 @@ int usbip_vhci_driver_open(void)
> vhci_driver->hc_device =
> udev_device_new_from_subsystem_sysname(udev_context,
> USBIP_VHCI_BUS_TYPE,
> -USBIP_VHCI_DRV_NAME);
> +USBIP_VHCI_DEVICE_NAME);
> if (!vhci_driver->hc_device) {
> err("udev_device_new_from_subsystem_sysname failed");
> goto err;
> diff --git a/tools/usb/usbip/libsrc/vhci_driver.h
> b/tools/usb/usbip/libsrc/vhci_driver.h
> index 33add14..dfe19c1 100644
> --- a/tools/usb/usbip/libsrc/vhci_driver.h
> +++ b/tools/usb/usbip/libsrc/vhci_driver.h
> @@ -11,6 +11,7 @@
> #include "usbip_common.h"
>
> #define USBIP_VHCI_BUS_TYPE "platform"
> +#define USBIP_VHCI_DEVICE_NAME "vhci_hcd.0"
> #define MAXNPORT 128
>
> struct usbip_imported_device {
>
--
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 3/9] usbip: vhci-hcd: Move VHCI platform device into vhci struct
On 05/18/2017 04:08 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> Every VHCI is a platform device, so move the platform_device struct
> into the VHCI struct.
>
> Signed-off-by: Yuyang Du
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/vhci.h | 3 ++-
> drivers/usb/usbip/vhci_hcd.c | 17 -
> drivers/usb/usbip/vhci_sysfs.c | 6 +++---
> 3 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/usbip/vhci.h b/drivers/usb/usbip/vhci.h
> index 9959584..62ee537 100644
> --- a/drivers/usb/usbip/vhci.h
> +++ b/drivers/usb/usbip/vhci.h
> @@ -90,6 +90,8 @@ struct vhci_unlink {
> struct vhci {
> spinlock_t lock;
>
> + struct platform_device *pdev;
> +
> struct vhci_hcd *vhci_hcd_hs;
> struct vhci_hcd *vhci_hcd_ss;
> };
> @@ -116,7 +118,6 @@ struct vhci_hcd {
> };
>
> extern int vhci_num_controllers;
> -extern struct platform_device **vhci_pdevs;
> extern struct vhci *vhcis;
> extern struct attribute_group vhci_attr_group;
>
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index 624265a..7a04497 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -58,8 +58,7 @@ static const char driver_name[] = "vhci_hcd";
> static const char driver_desc[] = "USB/IP Virtual Host Controller";
>
> int vhci_num_controllers = VHCI_NR_HCS;
> -
> -struct platform_device **vhci_pdevs;
> +struct vhci *vhcis;
>
> static const char * const bit_desc[] = {
> "CONNECTION", /*0*/
> @@ -1188,7 +1187,7 @@ static int add_platform_device(int id)
> if (IS_ERR(pdev))
> return PTR_ERR(pdev);
>
> - *(vhci_pdevs + id) = pdev;
> + vhcis[id].pdev = pdev;
> return 0;
> }
>
> @@ -1198,10 +1197,10 @@ static void del_platform_devices(void)
> int i;
>
> for (i = 0; i < vhci_num_controllers; i++) {
> - pdev = *(vhci_pdevs + i);
> + pdev = vhcis[i].pdev;
> if (pdev != NULL)
> platform_device_unregister(pdev);
> - *(vhci_pdevs + i) = NULL;
> + vhcis[i].pdev = NULL;
> }
> sysfs_remove_link(&platform_bus.kobj, driver_name);
> }
> @@ -1216,8 +1215,8 @@ static int __init vhci_hcd_init(void)
> if (vhci_num_controllers < 1)
> vhci_num_controllers = 1;
>
> - vhci_pdevs = kcalloc(vhci_num_controllers, sizeof(void *), GFP_KERNEL);
> - if (vhci_pdevs == NULL)
> + vhcis = kcalloc(vhci_num_controllers, sizeof(struct vhci), GFP_KERNEL);
> + if (vhcis == NULL)
> return -ENOMEM;
>
> ret = platform_driver_register(&vhci_driver);
> @@ -1237,7 +1236,7 @@ static int __init vhci_hcd_init(void)
> del_platform_devices();
> platform_driver_unregister(&vhci_driver);
> err_driver_register:
> - kfree(vhci_pdevs);
> + kfree(vhcis);
> return ret;
> }
>
> @@ -1245,7 +1244,7 @@ static void __exit vhci_hcd_exit(void)
> {
> del_platform_devices();
> platform_driver_unregister(&vhci_driver);
> - kfree(vhci_pdevs);
> + kfree(vhcis);
> }
>
> module_init(vhci_hcd_init);
> diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
> index d878faa..07f0d37 100644
> --- a/drivers/usb/usbip/vhci_sysfs.c
> +++ b/drivers/usb/usbip/vhci_sysfs.c
> @@ -32,7 +32,7 @@
> /* Sysfs entry to show port status */
> static ssize_t status_show_vhci(int pdev_nr, char *out)
> {
> - struct platform_device *pdev = *(vhci_pdevs + pdev_nr);
> + struct platform_device *pdev = vhcis[pdev_nr].pdev;
> struct vhci_hcd *vhci;
> char *s = out;
> int i = 0;
> @@ -206,7 +206,7 @@ static ssize_t store_detach(struct device *dev, struct
> device_attribute *attr,
> if (!valid_port(pdev_nr, rhport))
> return -EINVAL;
>
> - hcd = platform_get_drvdata(*(vhci_pdevs + pdev_nr));
> + hcd = platform_get_drvdata(vhcis[pdev_nr].pdev);
> if (hcd == NULL) {
> dev_err(dev, "port is not ready %u\n", port);
> return -EAGAIN;
> @@ -287,7 +287,7 @@ static ssize_t store_attach(struct device *dev, struct
> device_attribute *attr,
> if (!valid_args(pdev_nr, rhport, speed))
> return -EINVAL;
>
> - hcd = platform_get_drvdata(*(vhci_pdevs + pdev_nr));
> + hcd = platform_get_drvdata(vhcis[pdev_nr].pdev);
> if (hcd == NULL) {
> dev_err(dev, "port %d is not ready\n", port);
> return -EAGAIN;
>
--
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 2/9] usbip: vhci-hcd: Add vhci struct
On 05/18/2017 04:08 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> In order to support SuperSpeed devices, a USB3 HCD is added to
> share the USB2 HCD. As a result, a VHCI is composed of two
> vhci_hcds associated with the two HCDs respectively. So we add
> another level of abstraction, vhci, and thus this vhci structure.
>
> Signed-off-by: Yuyang Du
Looks good.
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/vhci.h | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/usbip/vhci.h b/drivers/usb/usbip/vhci.h
> index bff472f..9959584 100644
> --- a/drivers/usb/usbip/vhci.h
> +++ b/drivers/usb/usbip/vhci.h
> @@ -87,8 +87,17 @@ struct vhci_unlink {
>
> #define MAX_STATUS_NAME 16
>
> -/* for usb_bus.hcpriv */
> +struct vhci {
> + spinlock_t lock;
> +
> + struct vhci_hcd *vhci_hcd_hs;
> + struct vhci_hcd *vhci_hcd_ss;
> +};
> +
> +/* for usb_hcd.hcd_priv[0] */
> struct vhci_hcd {
> + struct vhci *vhci;
> +
> spinlock_t lock;
>
> u32 port_status[VHCI_HC_PORTS];
> @@ -108,6 +117,7 @@ struct vhci_hcd {
>
> extern int vhci_num_controllers;
> extern struct platform_device **vhci_pdevs;
> +extern struct vhci *vhcis;
> extern struct attribute_group vhci_attr_group;
>
> /* vhci_hcd.c */
>
--
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 1/9] usbip: vhci-hcd: Rename function names to reflect their struct names
On 05/18/2017 04:08 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> These helper function names are renamed to have their full struct
> names to avoid confusion:
>
> - hcd_to_vhci() -> hcd_to_vhci_hcd()
> - vhci_to_hcd() -> vhci_hcd_to_hcd()
> - vdev_to_vhci() -> vdev_to_vhci_hcd()
>
> Signed-off-by: Yuyang Du
Thanks. Looks good to me.
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/vhci.h | 11 +--
> drivers/usb/usbip/vhci_hcd.c | 34 +-
> drivers/usb/usbip/vhci_rx.c| 12 ++--
> drivers/usb/usbip/vhci_sysfs.c | 6 +++---
> 4 files changed, 31 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/usb/usbip/vhci.h b/drivers/usb/usbip/vhci.h
> index 88b71c4..bff472f 100644
> --- a/drivers/usb/usbip/vhci.h
> +++ b/drivers/usb/usbip/vhci.h
> @@ -134,7 +134,7 @@ static inline int port_to_pdev_nr(__u32 port)
> return port / VHCI_HC_PORTS;
> }
>
> -static inline struct vhci_hcd *hcd_to_vhci(struct usb_hcd *hcd)
> +static inline struct vhci_hcd *hcd_to_vhci_hcd(struct usb_hcd *hcd)
> {
> return (struct vhci_hcd *) (hcd->hcd_priv);
> }
> @@ -149,15 +149,14 @@ static inline const char *hcd_name(struct usb_hcd *hcd)
> return (hcd)->self.bus_name;
> }
>
> -static inline struct usb_hcd *vhci_to_hcd(struct vhci_hcd *vhci)
> +static inline struct usb_hcd *vhci_hcd_to_hcd(struct vhci_hcd *vhci_hcd)
> {
> - return container_of((void *) vhci, struct usb_hcd, hcd_priv);
> + return container_of((void *) vhci_hcd, struct usb_hcd, hcd_priv);
> }
>
> -static inline struct vhci_hcd *vdev_to_vhci(struct vhci_device *vdev)
> +static inline struct vhci_hcd *vdev_to_vhci_hcd(struct vhci_device *vdev)
> {
> - return container_of(
> - (void *)(vdev - vdev->rhport), struct vhci_hcd, vdev);
> + return container_of((void *)(vdev - vdev->rhport), struct vhci_hcd,
> vdev);
> }
>
> #endif /* __USBIP_VHCI_H */
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index 5d8b2c2..624265a 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -124,7 +124,7 @@ static void dump_port_status_diff(u32 prev_status, u32
> new_status)
>
> void rh_port_connect(struct vhci_device *vdev, enum usb_device_speed speed)
> {
> - struct vhci_hcd *vhci = vdev_to_vhci(vdev);
> + struct vhci_hcd *vhci = vdev_to_vhci_hcd(vdev);
> int rhport = vdev->rhport;
> u32 status;
> unsigned long flags;
> @@ -152,12 +152,12 @@ void rh_port_connect(struct vhci_device *vdev, enum
> usb_device_speed speed)
>
> spin_unlock_irqrestore(&vhci->lock, flags);
>
> - usb_hcd_poll_rh_status(vhci_to_hcd(vhci));
> + usb_hcd_poll_rh_status(vhci_hcd_to_hcd(vhci));
> }
>
> static void rh_port_disconnect(struct vhci_device *vdev)
> {
> - struct vhci_hcd *vhci = vdev_to_vhci(vdev);
> + struct vhci_hcd *vhci = vdev_to_vhci_hcd(vdev);
> int rhport = vdev->rhport;
> u32 status;
> unsigned long flags;
> @@ -174,7 +174,7 @@ static void rh_port_disconnect(struct vhci_device *vdev)
> vhci->port_status[rhport] = status;
>
> spin_unlock_irqrestore(&vhci->lock, flags);
> - usb_hcd_poll_rh_status(vhci_to_hcd(vhci));
> + usb_hcd_poll_rh_status(vhci_hcd_to_hcd(vhci));
> }
>
> #define PORT_C_MASK \
> @@ -206,7 +206,7 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
> retval = DIV_ROUND_UP(VHCI_HC_PORTS + 1, 8);
> memset(buf, 0, retval);
>
> - vhci = hcd_to_vhci(hcd);
> + vhci = hcd_to_vhci_hcd(hcd);
>
> spin_lock_irqsave(&vhci->lock, flags);
> if (!HCD_HW_ACCESSIBLE(hcd)) {
> @@ -268,7 +268,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
> typeReq, u16 wValue,
> pr_err("invalid port number %d\n", wIndex);
> rhport = ((__u8)(wIndex & 0x00ff)) - 1;
>
> - dum = hcd_to_vhci(hcd);
> + dum = hcd_to_vhci_hcd(hcd);
>
> spin_lock_irqsave(&dum->lock, flags);
>
> @@ -440,7 +440,7 @@ static void vhci_tx_urb(struct urb *urb, struct
> vhci_device *vdev)
> pr_err("could not get virtual device");
> return;
> }
> - vhci = vdev_to_vhci(vdev);
> + vhci = vdev_to_vhci_hcd(vdev);
>
> priv = kzalloc(sizeof(struct vhci_priv), GFP_ATOMIC);
> if (!priv) {
> @@ -468,7 +468,7 @@ static void vhci_tx_urb(struct urb *urb, struct
> vhci_device *vdev)
> static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
> gfp_t mem_flags)
> {
> - struct vhci_hcd *vhci = hcd_to_vhci(hcd);
> + struct vhci_hcd *vhci = hcd_to_vhci_hcd(hcd);
> struct device *dev = &urb->dev->dev;
> u8 portnum = urb->dev->portnum;
> int ret = 0;
> @@ -635,7 +635,7 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struct
> urb *urb,
> */
> static int vhci_urb_d
Re: [PATCH 5/7] USB: of: fix root-hub device-tree node handling
On Mon, Jun 05, 2017 at 12:51:04PM +0800, Peter Chen wrote:
> On Tue, May 30, 2017 at 06:25:52PM +0200, Johan Hovold wrote:
> > In an attempt to work around a pinmux over-allocation issue in driver
> > core, commit dc5878abf49c ("usb: core: move root hub's device node
> > assignment after it is added to bus") moved the device-tree node
> > assignment until after the root hub had been registered.
> >
> > This not only makes the device-tree node unavailable to the usb driver
> > during probe, but also prevents the of_node from being linked to in
> > sysfs and causes a race with user-space for the (recently added) devspec
> > attribute.
> >
> > Use the new device_set_of_node_from_dev() helper to reuse the node of
> > the sysdev device, something which now prevents driver core from trying
> > to reclaim any pinctrl pins during probe.
> >
> > Fixes: dc5878abf49c ("usb: core: move root hub's device node assignment
> > after it is added to bus")
> > Fixes: 51fa91475e43 ("usb/core: Added devspec sysfs entry for devices
> > behind the usb hub")
> > Signed-off-by: Johan Hovold
> I am OK with it, but I suggest adding it for new rc1 since it is based
> on the 1st patch which is a bug-fix. If this one is really needed for
> stable tree in future, you can cherry-pick it.
I agree, and didn't intent for this one to go into 4.12-rc. Let's see
how Greg wants to handle this. I'll add some comments to the cover
letter in v2.
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 v5 4/4] usb: usbip tool: Fix parse_status()
On 05/22/2017 04:20 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> In parse_status(), all nports number of idev's are initiated to
> 0 by memset(), it is simply wrong, because parse_status() reads
> the status sys file one by one, therefore, it can only update the
> according vhci_driver->idev's for it to parse.
>
> Reviewed-by: Krzysztof Opasiak
> Signed-off-by: Yuyang Du
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> tools/usb/usbip/libsrc/vhci_driver.c | 38
> ++--
> tools/usb/usbip/src/usbip_attach.c | 2 ++
> 2 files changed, 17 insertions(+), 23 deletions(-)
>
> diff --git a/tools/usb/usbip/libsrc/vhci_driver.c
> b/tools/usb/usbip/libsrc/vhci_driver.c
> index aa82c4b..f519c73 100644
> --- a/tools/usb/usbip/libsrc/vhci_driver.c
> +++ b/tools/usb/usbip/libsrc/vhci_driver.c
> @@ -36,18 +36,11 @@ imported_device_init(struct usbip_imported_device *idev,
> char *busid)
> return NULL;
> }
>
> -
> -
> static int parse_status(const char *value)
> {
> int ret = 0;
> char *c;
>
> -
> - for (int i = 0; i < vhci_driver->nports; i++)
> - memset(&vhci_driver->idev[i], 0, sizeof(vhci_driver->idev[i]));
> -
> -
> /* skip a header line */
> c = strchr(value, '\n');
> if (!c)
> @@ -58,6 +51,7 @@ static int parse_status(const char *value)
> int port, status, speed, devid;
> unsigned long socket;
> char lbusid[SYSFS_BUS_ID_SIZE];
> + struct usbip_imported_device *idev;
>
> ret = sscanf(c, "%d %d %d %x %lx %31s\n",
> &port, &status, &speed,
> @@ -72,30 +66,28 @@ static int parse_status(const char *value)
> port, status, speed, devid);
> dbg("socket %lx lbusid %s", socket, lbusid);
>
> -
> /* if a device is connected, look at it */
> - {
> - struct usbip_imported_device *idev =
> &vhci_driver->idev[port];
> + idev = &vhci_driver->idev[port];
>
> - idev->port = port;
> - idev->status= status;
> + memset(idev, 0, sizeof(*idev));
>
> - idev->devid = devid;
> + idev->port = port;
> + idev->status= status;
>
> - idev->busnum= (devid >> 16);
> - idev->devnum= (devid & 0x);
> + idev->devid = devid;
>
> - if (idev->status != VDEV_ST_NULL
> - && idev->status != VDEV_ST_NOTASSIGNED) {
> - idev = imported_device_init(idev, lbusid);
> - if (!idev) {
> - dbg("imported_device_init failed");
> - return -1;
> - }
> + idev->busnum= (devid >> 16);
> + idev->devnum= (devid & 0x);
> +
> + if (idev->status != VDEV_ST_NULL
> + && idev->status != VDEV_ST_NOTASSIGNED) {
> + idev = imported_device_init(idev, lbusid);
> + if (!idev) {
> + dbg("imported_device_init failed");
> + return -1;
> }
> }
>
> -
> /* go to the next line */
> c = strchr(c, '\n');
> if (!c)
> diff --git a/tools/usb/usbip/src/usbip_attach.c
> b/tools/usb/usbip/src/usbip_attach.c
> index 70a6b50..62a297f 100644
> --- a/tools/usb/usbip/src/usbip_attach.c
> +++ b/tools/usb/usbip/src/usbip_attach.c
> @@ -108,6 +108,8 @@ static int import_device(int sockfd, struct
> usbip_usb_device *udev)
> return -1;
> }
>
> + dbg("got free port %d", port);
> +
> rc = usbip_vhci_attach_device(port, sockfd, udev->busnum,
> udev->devnum, udev->speed);
> if (rc < 0) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/4] usb: usbip tool: Fix refresh_imported_device_list()
On 05/22/2017 04:20 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> The commit 0775a9cbc694e8c7 ("usbip: vhci extension: modifications
> to vhci driver") introduced multiple controllers, but the status
> of the ports are only extracted from the first status file, fix it.
>
> Reviewed-by: Krzysztof Opasiak
> Signed-off-by: Yuyang Du
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> tools/usb/usbip/libsrc/vhci_driver.c | 27 +--
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/tools/usb/usbip/libsrc/vhci_driver.c
> b/tools/usb/usbip/libsrc/vhci_driver.c
> index f6f3a19..aa82c4b 100644
> --- a/tools/usb/usbip/libsrc/vhci_driver.c
> +++ b/tools/usb/usbip/libsrc/vhci_driver.c
> @@ -108,18 +108,33 @@ static int parse_status(const char *value)
> return 0;
> }
>
> +#define MAX_STATUS_NAME 16
> +
> static int refresh_imported_device_list(void)
> {
> const char *attr_status;
> + char status[MAX_STATUS_NAME+1] = "status";
> + int i, ret;
>
> - attr_status = udev_device_get_sysattr_value(vhci_driver->hc_device,
> -"status");
> - if (!attr_status) {
> - err("udev_device_get_sysattr_value failed");
> - return -1;
> + for (i = 0; i < vhci_driver->ncontrollers; i++) {
> + if (i > 0)
> + snprintf(status, sizeof(status), "status.%d", i);
> +
> + attr_status =
> udev_device_get_sysattr_value(vhci_driver->hc_device,
> + status);
> + if (!attr_status) {
> + err("udev_device_get_sysattr_value failed");
> + return -1;
> + }
> +
> + dbg("controller %d", i);
> +
> + ret = parse_status(attr_status);
> + if (ret != 0)
> + return ret;
> }
>
> - return parse_status(attr_status);
> + return 0;
> }
>
> static int get_nports(void)
>
--
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 2/7] USB: of: document reference taken by child-lookup helper
On Tue, May 30, 2017 at 03:40:03PM -0700, Tyrel Datwyler wrote: > On 05/30/2017 09:25 AM, Johan Hovold wrote: > > Document that the child-node lookup helper takes a reference to the > > device-tree node which needs to be dropped after use. > > > > Signed-off-by: Johan Hovold > > --- > > drivers/usb/core/of.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c > > index d563cbcf76cf..17a4af02cf5b 100644 > > --- a/drivers/usb/core/of.c > > +++ b/drivers/usb/core/of.c > > @@ -28,6 +28,9 @@ > > * > > * Find the node from device tree according to its port number. > > * > > + * Takes a reference to the returned device-tree node, which needs to be > > + * dropped after use. > > + * > > * Return: On success, a pointer to the device node, %NULL on failure. > > I would use the same blurb used throughout drivers/of/* for consistency. > > * Returns a node pointer with refcount incremented, use > * of_node_put() on it when done. > */ > > Just my 2-cents I updated the comment to use a version of this also found in drivers/of: * Return: A pointer to the node with incremented refcount if found, or * %NULL otherwise. which is on kernel-doc format. I don't think we need to explicitly mention which function to manipulate the refcount with in every header. 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 v5 2/4] usb: usbip tool: Add ncontrollers in vhci_driver structure
On 05/22/2017 04:20 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> A new field ncontrollers is added to the vhci_driver structure.
> And this field is stored by scanning the vhci_hcd* dirs in the
> platform udev.
>
> Suggested-and-reviewed-by: Krzysztof Opasiak
> Signed-off-by: Yuyang Du
Looks good.
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> tools/usb/usbip/libsrc/vhci_driver.c | 36
>
> tools/usb/usbip/libsrc/vhci_driver.h | 1 +
> 2 files changed, 37 insertions(+)
>
> diff --git a/tools/usb/usbip/libsrc/vhci_driver.c
> b/tools/usb/usbip/libsrc/vhci_driver.c
> index 036b62b..f6f3a19 100644
> --- a/tools/usb/usbip/libsrc/vhci_driver.c
> +++ b/tools/usb/usbip/libsrc/vhci_driver.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include "sysfs_utils.h"
>
> #undef PROGNAME
> @@ -134,6 +135,33 @@ static int get_nports(void)
> return (int)strtoul(attr_nports, NULL, 10);
> }
>
> +static int vhci_hcd_filter(const struct dirent *dirent)
> +{
> + return strcmp(dirent->d_name, "vhci_hcd") >= 0;
> +}
> +
> +static int get_ncontrollers(void)
> +{
> + struct dirent **namelist;
> + struct udev_device *platform;
> + int n;
> +
> + platform = udev_device_get_parent(vhci_driver->hc_device);
> + if (platform == NULL)
> + return -1;
> +
> + n = scandir(udev_device_get_syspath(platform), &namelist,
> vhci_hcd_filter, NULL);
> + if (n < 0)
> + err("scandir failed");
> + else {
> + for (int i = 0; i < n; i++)
> + free(namelist[i]);
> + free(namelist);
> + }
> +
> + return n;
> +}
> +
> /*
> * Read the given port's record.
> *
> @@ -230,6 +258,14 @@ int usbip_vhci_driver_open(void)
> goto err;
> }
>
> + vhci_driver->ncontrollers = get_ncontrollers();
> + dbg("available controllers: %d", vhci_driver->ncontrollers);
> +
> + if (vhci_driver->ncontrollers <=0) {
> + err("no available usb controllers");
> + goto err;
> + }
> +
> if (refresh_imported_device_list())
> goto err;
>
> diff --git a/tools/usb/usbip/libsrc/vhci_driver.h
> b/tools/usb/usbip/libsrc/vhci_driver.h
> index fa2316c..33add14 100644
> --- a/tools/usb/usbip/libsrc/vhci_driver.h
> +++ b/tools/usb/usbip/libsrc/vhci_driver.h
> @@ -31,6 +31,7 @@ struct usbip_vhci_driver {
> /* /sys/devices/platform/vhci_hcd */
> struct udev_device *hc_device;
>
> + int ncontrollers;
> int nports;
> struct usbip_imported_device idev[MAXNPORT];
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/4] usb: usbip tool: Check the return of get_nports()
On 05/22/2017 04:20 AM, Yuyang Du wrote:
> From: Yuyang Du
>
> If we get nonpositive number of ports, there is no sense to
> continue, then fail gracefully.
>
> In addition, the commit 0775a9cbc694e8c72 ("usbip: vhci extension:
> modifications to vhci driver") introduced configurable numbers of
> controllers and ports, but we have a static port number maximum,
> MAXNPORT. If exceeded, the idev array will be overflown. We fix
> it by validating the nports to make sure the port number max is
> not exceeded.
>
> Reviewed-by: Krzysztof Opasiak
> Signed-off-by: Yuyang Du
> Acked-by: Shuah Khan
Greg,
Could you please pick this up.
thanks,
-- Shuah
> ---
> tools/usb/usbip/libsrc/vhci_driver.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/tools/usb/usbip/libsrc/vhci_driver.c
> b/tools/usb/usbip/libsrc/vhci_driver.c
> index f659c14..036b62b 100644
> --- a/tools/usb/usbip/libsrc/vhci_driver.c
> +++ b/tools/usb/usbip/libsrc/vhci_driver.c
> @@ -220,9 +220,16 @@ int usbip_vhci_driver_open(void)
> }
>
> vhci_driver->nports = get_nports();
> -
> dbg("available ports: %d", vhci_driver->nports);
>
> + if (vhci_driver->nports <= 0) {
> + err("no available ports");
> + goto err;
> + } else if (vhci_driver->nports > MAXNPORT) {
> + err("port number exceeds %d", MAXNPORT);
> + goto err;
> + }
> +
> if (refresh_imported_device_list())
> goto err;
>
>
--
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] usb: usbip: set buffer pointers to NULL after free
On 05/22/2017 05:02 AM, Michael Grzeschik wrote: > The usbip stack dynamically allocates the transfer_buffer and > setup_packet of each urb that got generated by the tcp to usb stub code. > As these pointers are always used only once we will set them to NULL > after use. This is done likewise to the free_urb code in vudc_dev.c. > This patch fixes double kfree situations where the usbip remote side > added the URB_FREE_BUFFER. > > Cc: sta...@vger.kernel.org > Signed-off-by: Michael Grzeschik Sorry for the delay. I was away last couple of weeks. The change looks good. Thanks for the fix. Acked-by: Shuah Khan thanks, -- Shuah > --- > v1 -> v2: - rephrased patch subject from: > "usb: usbip: avoid the usb layer to kfree our allocated buffer" > - changed to always let urb_destoy remove the transfer_buffer > v2 -> v3: - added stable to cc > - wrapped long line with over 80 chars > v3 -> v4: - rephrades patch subject from usb: > "usbip: let urb_destroy kfree the transfer_buffer" > - setting buffer pointers to NULL > instead of omitting flag URB_FREE_BUFFER > > drivers/usb/usbip/stub_main.c | 4 > drivers/usb/usbip/stub_tx.c | 4 > 2 files changed, 8 insertions(+) > > diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c > index 44ab43fc4fcc7..af10f7b131a49 100644 > --- a/drivers/usb/usbip/stub_main.c > +++ b/drivers/usb/usbip/stub_main.c > @@ -262,7 +262,11 @@ void stub_device_cleanup_urbs(struct stub_device *sdev) > kmem_cache_free(stub_priv_cache, priv); > > kfree(urb->transfer_buffer); > + urb->transfer_buffer = NULL; > + > kfree(urb->setup_packet); > + urb->setup_packet = NULL; > + > usb_free_urb(urb); > } > } > diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c > index 6b1e8c3f0e4b2..be50cef645d8a 100644 > --- a/drivers/usb/usbip/stub_tx.c > +++ b/drivers/usb/usbip/stub_tx.c > @@ -28,7 +28,11 @@ static void stub_free_priv_and_urb(struct stub_priv *priv) > struct urb *urb = priv->urb; > > kfree(urb->setup_packet); > + urb->setup_packet = NULL; > + > kfree(urb->transfer_buffer); > + urb->transfer_buffer = NULL; > + > list_del(&priv->list); > kmem_cache_free(stub_priv_cache, priv); > usb_free_urb(urb); > -- 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: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID
On Tue, Jun 6, 2017 at 3:03 PM, Alan Stern wrote: > On Mon, 5 Jun 2017, Alan Robertson wrote: > >> >> >> USBSTOR\DISK&VEN_LINUX&PROD_FILE-STOR_GADGET&REV_0404\123456789012&0 >> > >> > It looks like Windows is remembering an earlier version of your gadget >> > and matching it with the current version based on the serial number >> > string. >> >> I've changed the SN and still getting it showing as 'File-Stor Gadget' >> on Linux, Windows, router > > When you say "on Linux", you mean in some userspace program (some sort > of device manager), not in the kernel, right? Everything the kernel > knows about the gadget will show up in the "lsusb -v" output and in > /sys/kernel/debug/usb/devices (assuming you have mounted a debugfs > filesystem on /sys/kernel/debug). Sorry, yes - I mean in KDE - when I go to eject it I can see File-Stor mentioned >> > This all seems to be valid, except for the bcdDevice value. >> >> Does the 3/4/5 (vs 1/2/3) number of iManufac/Prod/Serial matter at all? > > No, it does not. OK >> > Try changing bcdDevice to a valid number, and change the serial number >> > string to something different from what you were using before. >> >> Have changed both and also cleared Windows USB cache with DriveCleanup >> from www.uwe-sieber.de (which forces redetection). Eject removable >> media is showing as Cruzer Switch, but it is still showing as "Linux >> File-Stor Gadget USB Device" in device manager (and as File-Stor on >> other non-Windows devices I tried). >> >> I'm guessing we've now changed all that's changeable with >> g_mass_storage but happy to take any further suggestions! - something >> is still making it appear subtly different to systems cf a native USB >> flash drive :( > > It's hard to say what that could be. From your description, the gadget > does not send any information to the host that could identify it as a > Linux-based gadget. Agree in lsusb -v there's nothing obvious, but the way File-Stor is coming up on router & KDE and Windows is also identifying as that (even after clearing devices and changing SN) make me think there must be something that is still 'giving the game away'! Sadly I've got no control of the devices I'm trying to use this in, I just know that they're not recognising this as a valid memory stick when they will happily recognise any other actual sticks that I try to use in them. > There's one more thing you can try: Use usbmon on a Linux host to > capture the packet data when the gadget is initialized and configured. OK will do. Cheers Alan -- 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: Please Add A Quectel EC25-E Device To A Proper Driver
On Tue, Jun 06, 2017 at 03:16:25PM +0100, T A F Thorne wrote: > Good afternoon, > > I am seeing a message in my syslog that instructs me to "Tell > Linux-usb@vger.kernel.org to add your device to a proper driver.". This > is me delivering the message as instructed. > > I have just plugged in a Quectel EC25-E LTE Module, mounted on a > Micro-PCIe to USB adaptor board. Broadly speaking this is very similar > to the Quectel UC20 module, that I think is already supported. > Previously I thought I had got the driver to come up after creating a > modified options module that added details of the modules vendor and > device IDs, then run `modprobe option vendor=0x2c7c product=0x0125`. > However this now seems to fail, possibly because I do not have the > modified kernel and module installed right now. Error from that step is > as follows: > Currently I am running an Ubuntu 16.04 distribution with the kernel > details being: > > $ uname -a > Linux thorne-ul-dt 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 > UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Judging from the product name and ids you provide above, this modem should already be supported by the option driver since v4.11 and support has also been backported to the stable trees (e.g. 4.4.58). So simply updating your kernel should do the trick here. 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
Please Add A Quectel EC25-E Device To A Proper Driver
Good afternoon, I am seeing a message in my syslog that instructs me to "Tell Linux-usb@vger.kernel.org to add your device to a proper driver.". This is me delivering the message as instructed. I have just plugged in a Quectel EC25-E LTE Module, mounted on a Micro-PCIe to USB adaptor board. Broadly speaking this is very similar to the Quectel UC20 module, that I think is already supported. The full section of the syslog is as follows: > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332593] usbcore: > registered new interface driver usbserial > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332615] usbcore: > registered new interface driver usbserial_generic > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332631] usbserial: USB > Serial support registered for generic > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332646] usbserial_generic > 3-2.4.1:1.0: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332648] usbserial_generic > 3-2.4.1:1.0: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332649] usbserial_generic > 3-2.4.1:1.0: generic converter detected > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332732] usb 3-2.4.1: > generic converter now attached to ttyUSB0 > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332744] usbserial_generic > 3-2.4.1:1.1: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332746] usbserial_generic > 3-2.4.1:1.1: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332747] usbserial_generic > 3-2.4.1:1.1: generic converter detected > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332805] usb 3-2.4.1: > generic converter now attached to ttyUSB1 > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332815] usbserial_generic > 3-2.4.1:1.2: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332817] usbserial_generic > 3-2.4.1:1.2: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332818] usbserial_generic > 3-2.4.1:1.2: generic converter detected > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332884] usb 3-2.4.1: > generic converter now attached to ttyUSB2 > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332892] usbserial_generic > 3-2.4.1:1.3: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332893] usbserial_generic > 3-2.4.1:1.3: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332895] usbserial_generic > 3-2.4.1:1.3: generic converter deteccted > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332950] usb 3-2.4.1: > generic converter now attached to ttyUSB3 > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332958] usbserial_generic > 3-2.4.1:1.4: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332960] usbserial_generic > 3-2.4.1:1.4: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332961] usbserial_generic > 3-2.4.1:1.4: generic converter detected > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.333017] usb 3-2.4.1: > generic converter now attached to ttyUSB4 > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB0): > port attributes not fully set > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB4): > port attributes not fully set > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB2): > port attributes not fully set > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB3): > port attributes not fully set > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB1): > port attributes not fully set Previously I thought I had got the driver to come up after creating a modified options module that added details of the modules vendor and device IDs, then run `modprobe option vendor=0x2c7c product=0x0125`. However this now seems to fail, possibly because I do not have the modified kernel and module installed right now. Error from that step is as follows: > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.387374] option: unknown > parameter 'vendor' ignored > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.387376] option: unknown > parameter 'product' ignored > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.387474] usbcore: > registered new interface driver option > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.387495] usbserial: USB > Serial support registered for GSM modem (1-port) > Jun 6 10:14:55 thorne-ul-dt ModemManager[1110]: (ttyUSB2): > port attributes not fully set > Jun 6 10:14:55 thorne-ul-dt ModemManager[1110]: (ttyUSB3): > port attributes not fully set > Jun 6 10:15:0
RE: Please Add A Quectel EC25-E Device To A Proper Driver
Good point. I shall try again with a reduced sign off... or better yet a non-corporate account once cleared to do so. All obvious it is my own statements then. Thomas A. F. Thorne Software Engineer Net2Edge -Original Message- From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold Sent: 06 June 2017 15:13 To: Thomas Thorne Cc: linux-usb@vger.kernel.org Subject: Re: Please Add A Quectel EC25-E Device To A Proper Driver On Tue, Jun 06, 2017 at 12:49:12PM +0100, Thomas A. F. Thorne MEng AUS MIET wrote: > Net2Edge Limited is a company registered in England & Wales (Company No. > 2438435, VAT No. GB 537553821) Kulite House, Stroudley Road, > Basingstoke > RG24 8UG. This email transmission is confidential and intended solely > for the person or organisation to whom it is addressed. If you are not > the intended recipient, you must not copy, distribute or disseminate > the information, or take any action in reliance of it. Any views > expressed in this message are those of the individual sender, except > where the sender specifically states them to be the views of any > organisation or employer. If you have received this message in error, > do not open any attachment but please notify the sender (above) and > delete this message from your system. Please rely on your own virus > check. Although all outbound mail is checked for viruses, no > responsibility is taken by the sender for any damage rising out of any bug or > virus infection. Not much we can do with a mail with a footer like this. Please resend without it. 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: Please Add A Quectel EC25-E Device To A Proper Driver
On Tue, Jun 06, 2017 at 12:49:12PM +0100, Thomas A. F. Thorne MEng AUS MIET wrote: > Net2Edge Limited is a company registered in England & Wales (Company No. > 2438435, VAT No. GB 537553821) Kulite House, Stroudley Road, Basingstoke > RG24 8UG. This email transmission is confidential and intended solely > for the person or organisation to whom it is addressed. If you are not > the intended recipient, you must not copy, distribute or disseminate the > information, or take any action in reliance of it. Any views expressed > in this message are those of the individual sender, except where the > sender specifically states them to be the views of any organisation or > employer. If you have received this message in error, do not open any > attachment but please notify the sender (above) and delete this message > from your system. Please rely on your own virus check. Although all > outbound mail is checked for viruses, no responsibility is taken by the > sender for any damage rising out of any bug or virus infection. Not much we can do with a mail with a footer like this. Please resend without it. 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: Continuous, infinite warm reset attempts in Chipidea HDRC on multiple connect-disconects
On Tue, 6 Jun 2017, lingareddy praneethreddy wrote: > I am using Chipidea HDRC on imx6sl platform. On connecting USB stick > (sometimes) and Android/ Apple phone (frequent) to ci-hdrc multiple > time it is seen that hub (ehci_hub_control()) reports continuous > USB_PORT_FEAT_C_RESET (infinitely) before a disconnect-connect caused > USB_PORT_FEAT_C_OVER_CURRENT. Can you post a debugging log? Do: echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control before plugging in the device, and then copy the dmesg output. > I have two queries: > 1. Can we avoid the continuous warm reset ( USB_PORT_FEAT_C_RESET ) > i.e. can we force hub to initialize again and enumerate the device > again? Reset _does_ initialize and enumerate the device again. > 2. Do we need to initialize both controller and hub i.e. we > initialized controller (calling ehci_setup() and ehci_run()) but the > hub continued the resets until the overcurrent bit was set. I don't understand this question. But remember, the hardware does not decide when to issue a reset. That decision is made by the driver software in the kernel. 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: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID
On Mon, 5 Jun 2017, Alan Robertson wrote: > >> >> USBSTOR\DISK&VEN_LINUX&PROD_FILE-STOR_GADGET&REV_0404\123456789012&0 > > > > It looks like Windows is remembering an earlier version of your gadget > > and matching it with the current version based on the serial number > > string. > > I've changed the SN and still getting it showing as 'File-Stor Gadget' > on Linux, Windows, router When you say "on Linux", you mean in some userspace program (some sort of device manager), not in the kernel, right? Everything the kernel knows about the gadget will show up in the "lsusb -v" output and in /sys/kernel/debug/usb/devices (assuming you have mounted a debugfs filesystem on /sys/kernel/debug). > > This all seems to be valid, except for the bcdDevice value. > > Does the 3/4/5 (vs 1/2/3) number of iManufac/Prod/Serial matter at all? No, it does not. > > Try changing bcdDevice to a valid number, and change the serial number > > string to something different from what you were using before. > > Have changed both and also cleared Windows USB cache with DriveCleanup > from www.uwe-sieber.de (which forces redetection). Eject removable > media is showing as Cruzer Switch, but it is still showing as "Linux > File-Stor Gadget USB Device" in device manager (and as File-Stor on > other non-Windows devices I tried). > > I'm guessing we've now changed all that's changeable with > g_mass_storage but happy to take any further suggestions! - something > is still making it appear subtly different to systems cf a native USB > flash drive :( It's hard to say what that could be. From your description, the gadget does not send any information to the host that could identify it as a Linux-based gadget. There's one more thing you can try: Use usbmon on a Linux host to capture the packet data when the gadget is initialized and configured. 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 1/2] usb: gadget: core: introduce ->udc_set_speed() method
On Tue, 6 Jun 2017, Felipe Balbi wrote: > Sometimes, the gadget driver we want to run has max_speed lower than > what the UDC supports. In such situations, UDC might want to make sure > we don't try to connect on speeds not supported by the gadget > driver (e.g. super-speed capable dwc3 with high-speed capable g_midi) > because that will just fail. > > In order to make sure this situation never happens, we introduce a new > optional ->udc_set_speed() method which can be implemented by > interested UDC drivers. > > Signed-off-by: Felipe Balbi dummy-hcd already checks for this in its dummy_pullup() routine. Should other UDC drivers copy this approach? 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] HID: Add quirk for Dell PIXART OEM mouse
On Tue, 6 Jun 2017, Sebastian Parschauer wrote: > >> This mouse is also known under other IDs. > > > > Do you know (some of the) other IDs? > > I mean the IDs from other vendors like the HP PixArt OEM mouse. AFAIK, > Dell MS116 is the only PixArt OEM mouse provided by Dell. Ah, so you didn't mean "device IDs" in the sense of VID/PID, but branding names. Queued in for-4.12/upstream-fixes branch. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HID: Add quirk for Dell PIXART OEM mouse
On 06.06.2017 14:06, Jiri Kosina wrote: > On Tue, 6 Jun 2017, Sebastian Parschauer wrote: > >> This mouse is also known under other IDs. > > Do you know (some of the) other IDs? I mean the IDs from other vendors like the HP PixArt OEM mouse. AFAIK, Dell MS116 is the only PixArt OEM mouse provided by Dell. The MS111 rather looks like Logitech and I can't find any idProduct or lsusb information for it on the web. There are product IDs 0x3012 and 0x3016 but these also seem to be Logitech. Cheers, Sebastian -- 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/2] usb: dwc3: gadget: implement ->udc_set_speed()
Use this method to make sure we don't try to connect on speeds not
supported by the gadget driver.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 101 ++
1 file changed, 58 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index d2bd28dc28b6..01cd7ddc9981 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1827,49 +1827,6 @@ static int __dwc3_gadget_start(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_DEV_IMOD(0), 0);
}
- reg = dwc3_readl(dwc->regs, DWC3_DCFG);
- reg &= ~(DWC3_DCFG_SPEED_MASK);
-
- /*
-* WORKAROUND: DWC3 revision < 2.20a have an issue
-* which would cause metastability state on Run/Stop
-* bit if we try to force the IP to USB2-only mode.
-*
-* Because of that, we cannot configure the IP to any
-* speed other than the SuperSpeed
-*
-* Refers to:
-*
-* STAR#9000525659: Clock Domain Crossing on DCTL in
-* USB 2.0 Mode
-*/
- if (dwc->revision < DWC3_REVISION_220A) {
- reg |= DWC3_DCFG_SUPERSPEED;
- } else {
- switch (dwc->maximum_speed) {
- case USB_SPEED_LOW:
- reg |= DWC3_DCFG_LOWSPEED;
- break;
- case USB_SPEED_FULL:
- reg |= DWC3_DCFG_FULLSPEED;
- break;
- case USB_SPEED_HIGH:
- reg |= DWC3_DCFG_HIGHSPEED;
- break;
- case USB_SPEED_SUPER_PLUS:
- reg |= DWC3_DCFG_SUPERSPEED_PLUS;
- break;
- default:
- dev_err(dwc->dev, "invalid dwc->maximum_speed (%d)\n",
- dwc->maximum_speed);
- /* fall through */
- case USB_SPEED_SUPER:
- reg |= DWC3_DCFG_SUPERSPEED;
- break;
- }
- }
- dwc3_writel(dwc->regs, DWC3_DCFG, reg);
-
/*
* We are telling dwc3 that we want to use DCFG.NUMP as ACK TP's NUMP
* field instead of letting dwc3 itself calculate that automatically.
@@ -2001,6 +1958,63 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
return 0;
}
+static void dwc3_gadget_set_speed(struct usb_gadget *g,
+ enum usb_device_speed speed)
+{
+ struct dwc3 *dwc = gadget_to_dwc(g);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(&dwc->lock, flags);
+ reg = dwc3_readl(dwc->regs, DWC3_DCFG);
+ reg &= ~(DWC3_DCFG_SPEED_MASK);
+
+ /*
+* WORKAROUND: DWC3 revision < 2.20a have an issue
+* which would cause metastability state on Run/Stop
+* bit if we try to force the IP to USB2-only mode.
+*
+* Because of that, we cannot configure the IP to any
+* speed other than the SuperSpeed
+*
+* Refers to:
+*
+* STAR#9000525659: Clock Domain Crossing on DCTL in
+* USB 2.0 Mode
+*/
+ if (dwc->revision < DWC3_REVISION_220A) {
+ reg |= DWC3_DCFG_SUPERSPEED;
+ } else {
+ switch (speed) {
+ case USB_SPEED_LOW:
+ reg |= DWC3_DCFG_LOWSPEED;
+ break;
+ case USB_SPEED_FULL:
+ reg |= DWC3_DCFG_FULLSPEED;
+ break;
+ case USB_SPEED_HIGH:
+ reg |= DWC3_DCFG_HIGHSPEED;
+ break;
+ case USB_SPEED_SUPER:
+ reg |= DWC3_DCFG_SUPERSPEED;
+ break;
+ case USB_SPEED_SUPER_PLUS:
+ reg |= DWC3_DCFG_SUPERSPEED_PLUS;
+ break;
+ default:
+ dev_err(dwc->dev, "invalid speed (%d)\n", speed);
+
+ if (dwc->revision & DWC3_REVISION_IS_DWC31)
+ reg |= DWC3_DCFG_SUPERSPEED_PLUS;
+ else
+ reg |= DWC3_DCFG_SUPERSPEED;
+ }
+ }
+ dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+
+ spin_unlock_irqrestore(&dwc->lock, flags);
+}
+
static const struct usb_gadget_ops dwc3_gadget_ops = {
.get_frame = dwc3_gadget_get_frame,
.wakeup = dwc3_gadget_wakeup,
@@ -2008,6 +2022,7 @@ static const struct usb_gadget_ops dwc3_gadget_ops = {
.pullup = dwc3_gadget_pullup,
.udc_start = dwc3_gadget_start,
.udc_stop = dwc3_gadget_stop,
+ .udc_set_speed = dwc3_gadget_set_speed,
};
/* -
[PATCH 1/2] usb: gadget: core: introduce ->udc_set_speed() method
Sometimes, the gadget driver we want to run has max_speed lower than
what the UDC supports. In such situations, UDC might want to make sure
we don't try to connect on speeds not supported by the gadget
driver (e.g. super-speed capable dwc3 with high-speed capable g_midi)
because that will just fail.
In order to make sure this situation never happens, we introduce a new
optional ->udc_set_speed() method which can be implemented by
interested UDC drivers.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/udc/core.c | 20
include/linux/usb/gadget.h| 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 62d52fc0fcdc..eec388bccb25 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1056,6 +1056,23 @@ static inline void usb_gadget_udc_stop(struct usb_udc
*udc)
}
/**
+ * usb_gadget_udc_set_speed - tells usb device controller speed supported by
+ *current driver
+ * @udc: The device we want to set maximum speed
+ * @speed: The maximum speed to allowed to run
+ *
+ * This call is issued by the UDC Class driver before calling
+ * usb_gadget_udc_start() in order to make sure that we don't try to
+ * connect on speeds the gadget driver doesn't support.
+ */
+static inline void usb_gadget_udc_set_speed(struct usb_udc *udc,
+ enum usb_device_speed speed)
+{
+ if (udc->gadget->ops->udc_set_speed)
+ udc->gadget->ops->udc_set_speed(udc->gadget, speed);
+}
+
+/**
* usb_udc_release - release the usb_udc struct
* @dev: the dev member within usb_udc
*
@@ -1288,6 +1305,9 @@ static int udc_bind_to_driver(struct usb_udc *udc, struct
usb_gadget_driver *dri
udc->dev.driver = &driver->driver;
udc->gadget->dev.driver = &driver->driver;
+ if (driver->max_speed < udc->gadget->max_speed)
+ usb_gadget_udc_set_speed(udc, driver->max_speed);
+
ret = driver->bind(udc->gadget, driver);
if (ret)
goto err1;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3ee5f2a7c0b4..1a4a4bacfae6 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -304,6 +304,7 @@ struct usb_gadget_ops {
int (*udc_start)(struct usb_gadget *,
struct usb_gadget_driver *);
int (*udc_stop)(struct usb_gadget *);
+ void(*udc_set_speed)(struct usb_gadget *, enum usb_device_speed);
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
--
2.11.0.295.gd7dffce1ce
--
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: Fix microtek driver compilation errors
On Tue, Jun 06, 2017 at 02:18:10PM +0200, Mariusz Skamra wrote: > This fixes compilation errors due to missing scsi_cmnd.h include. > > usb/image/microtek.c: In function ‘mts_slave_alloc’: > usb/image/microtek.c:326:3: error: dereferencing pointer to incomplete type > s->inquiry_len = 0x24; >^ > usb/image/microtek.c: In function ‘mts_slave_configure’: > usb/image/microtek.c:332:27: error: dereferencing pointer to incomplete type > blk_queue_dma_alignment(s->request_queue, (512 - 1)); >^ > usb/image/microtek.c: In function ‘mts_scsi_abort’: > usb/image/microtek.c:338:48: error: dereferencing pointer to incomplete type > struct mts_desc* desc = (struct mts_desc*)(srb->device->host->hostdata[0]); > ^ > etc. > > Signed-off-by: Mariusz Skamra > --- > drivers/usb/image/microtek.c | 1 + > 1 file changed, 1 insertion(+) really? When did this start breaking? I don't see it on any of my builds, what caused this to happen? 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
FW: Unable to perform remote wakeup of host with USB HID Composite Device
Hi I apologize in advance for this is my first email using this mailing list but I could really use some help. I have connected a composite USB device running the 4.0 Linux kernel to a PC running Ubuntu. One of its functions is to act as a HID device for mouse and keyboard to control the host. However, an issue that I am currently encountering is that if the host (running Ubuntu 14.10) is suspended, the composite USB device cannot wake it up however a normal connected USB mouse or keyboard on the same USB port can wake it up. Detailed lsusb information for my device is provided below. Any assistance is greatly appreciated in solving this issue. Bus 003 Device 003: ID 1d6b:0001 Linux Foundation Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 0 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice3.18 iManufacturer 1 Evertz Microsystem Ltd. iProduct2 Evertz TRXS10G Composite device iSerial 3 ev-53-trxs-10g-sn bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 226 bNumInterfaces 7 bConfigurationValue 1 iConfiguration 4 Conf 1 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 120mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 7 CDC Serial Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 5 CDC Abstract Control Model (ACM) CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x00 bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 6 CDC ACM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 9 Mass Storage Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bm
Continuous, infinite warm reset attempts in Chipidea HDRC on multiple connect-disconects
I am using Chipidea HDRC on imx6sl platform. On connecting USB stick (sometimes) and Android/ Apple phone (frequent) to ci-hdrc multiple time it is seen that hub (ehci_hub_control()) reports continuous USB_PORT_FEAT_C_RESET (infinitely) before a disconnect-connect caused USB_PORT_FEAT_C_OVER_CURRENT. I have two queries: 1. Can we avoid the continuous warm reset ( USB_PORT_FEAT_C_RESET ) i.e. can we force hub to initialize again and enumerate the device again? 2. Do we need to initialize both controller and hub i.e. we initialized controller (calling ehci_setup() and ehci_run()) but the hub continued the resets until the overcurrent bit was set. Thanks&Regards Praneeth Reddy L -- 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: Fix microtek driver compilation errors
This fixes compilation errors due to missing scsi_cmnd.h include. usb/image/microtek.c: In function ‘mts_slave_alloc’: usb/image/microtek.c:326:3: error: dereferencing pointer to incomplete type s->inquiry_len = 0x24; ^ usb/image/microtek.c: In function ‘mts_slave_configure’: usb/image/microtek.c:332:27: error: dereferencing pointer to incomplete type blk_queue_dma_alignment(s->request_queue, (512 - 1)); ^ usb/image/microtek.c: In function ‘mts_scsi_abort’: usb/image/microtek.c:338:48: error: dereferencing pointer to incomplete type struct mts_desc* desc = (struct mts_desc*)(srb->device->host->hostdata[0]); ^ etc. Signed-off-by: Mariusz Skamra --- drivers/usb/image/microtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/image/microtek.c b/drivers/usb/image/microtek.c index a4dbb0c..3622404 100644 --- a/drivers/usb/image/microtek.c +++ b/drivers/usb/image/microtek.c @@ -133,6 +133,7 @@ #include #include #include "../../scsi/scsi.h" +#include #include #include "microtek.h" -- 2.1.4 Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
Re: [PATCH] HID: Add quirk for Dell PIXART OEM mouse
On Tue, 6 Jun 2017, Sebastian Parschauer wrote: > This mouse is also known under other IDs. Do you know (some of the) other IDs? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] HID: Add quirk for Dell PIXART OEM mouse
This mouse is also known under other IDs. It needs the quirk
ALWAYS_POLL or will disconnect in runlevel 1 or 3.
Signed-off-by: Sebastian Parschauer
CC: sta...@vger.kernel.org
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 8ca1e8ce0af2..4f9a3938189a 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -319,6 +319,9 @@
#define USB_VENDOR_ID_DELCOM 0x0fc5
#define USB_DEVICE_ID_DELCOM_VISUAL_IND0xb080
+#define USB_VENDOR_ID_DELL 0x413c
+#define USB_DEVICE_ID_DELL_PIXART_USB_OPTICAL_MOUSE0x301a
+
#define USB_VENDOR_ID_DELORME 0x1163
#define USB_DEVICE_ID_DELORME_EARTHMATE0x0100
#define USB_DEVICE_ID_DELORME_EM_LT20 0x0200
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 6316498b7812..a88e7c7bea0a 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -85,6 +85,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE,
HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB,
HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_CREATIVELABS,
USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_DELL, USB_DEVICE_ID_DELL_PIXART_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_PS3,
HID_QUIRK_MULTI_INPUT },
--
2.12.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
[PATCH] usb: gadget: composite: make sure to reactivate function on unbind
If a function sets bind_deactivated flag, upon removal we will be left
with an unbalanced deactivation. Let's make sure that we conditionally
call usb_function_activate() from usb_remove_function() and make sure
usb_remove_function() is called from remove_config().
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/composite.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index d62f53d7f418..dd74c99d6ce1 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -315,6 +315,9 @@ void usb_remove_function(struct usb_configuration *c,
struct usb_function *f)
list_del(&f->list);
if (f->unbind)
f->unbind(c, f);
+
+ if (f->bind_deactivated)
+ usb_function_activate(f);
}
EXPORT_SYMBOL_GPL(usb_remove_function);
@@ -961,12 +964,8 @@ static void remove_config(struct usb_composite_dev *cdev,
f = list_first_entry(&config->functions,
struct usb_function, list);
- list_del(&f->list);
- if (f->unbind) {
- DBG(cdev, "unbind function '%s'/%p\n", f->name, f);
- f->unbind(config, f);
- /* may free memory for "f" */
- }
+
+ usb_remove_function(config, f);
}
list_del(&config->list);
if (config->unbind) {
--
2.11.0.295.gd7dffce1ce
--
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
Please Add A Quectel EC25-E Device To A Proper Driver
Good afternoon, I am seeing a message in my syslog that instructs me to "Tell Linux-usb@vger.kernel.org to add your device to a proper driver.". This is me delivering the message as instructed. I have just plugged in a Quectel EC25-E LTE Module, mounted on a Micro-PCIe to USB adaptor board. Broadly speaking this is very similar to the Quectel UC20 module, that I think is already supported. The full section of the syslog is as follows: > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332593] usbcore: > registered new interface driver usbserial > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332615] usbcore: > registered new interface driver usbserial_generic > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332631] usbserial: USB > Serial support registered for generic > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332646] usbserial_generic > 3-2.4.1:1.0: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332648] usbserial_generic > 3-2.4.1:1.0: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332649] usbserial_generic > 3-2.4.1:1.0: generic converter detected > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332732] usb 3-2.4.1: > generic converter now attached to ttyUSB0 > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332744] usbserial_generic > 3-2.4.1:1.1: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332746] usbserial_generic > 3-2.4.1:1.1: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332747] usbserial_generic > 3-2.4.1:1.1: generic converter detected > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332805] usb 3-2.4.1: > generic converter now attached to ttyUSB1 > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332815] usbserial_generic > 3-2.4.1:1.2: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332817] usbserial_generic > 3-2.4.1:1.2: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332818] usbserial_generic > 3-2.4.1:1.2: generic converter detected > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332884] usb 3-2.4.1: > generic converter now attached to ttyUSB2 > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332892] usbserial_generic > 3-2.4.1:1.3: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332893] usbserial_generic > 3-2.4.1:1.3: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332895] usbserial_generic > 3-2.4.1:1.3: generic converter deteccted > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332950] usb 3-2.4.1: > generic converter now attached to ttyUSB3 > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332958] usbserial_generic > 3-2.4.1:1.4: The "generic" usb-serial driver is only for testing and > one-off prototypes. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332960] usbserial_generic > 3-2.4.1:1.4: Tell linux-usb@vger.kernel.org to add your device to a > proper driver. > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.332961] usbserial_generic > 3-2.4.1:1.4: generic converter detected > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.333017] usb 3-2.4.1: > generic converter now attached to ttyUSB4 > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB0): > port attributes not fully set > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB4): > port attributes not fully set > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB2): > port attributes not fully set > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB3): > port attributes not fully set > Jun 6 10:14:53 thorne-ul-dt ModemManager[1110]: (ttyUSB1): > port attributes not fully set Previously I thought I had got the driver to come up after creating a modified options module that added details of the modules vendor and device IDs, then run `modprobe option vendor=0x2c7c product=0x0125`. However this now seems to fail, possibly because I do not have the modified kernel and module installed right now. Error from that step is as follows: > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.387374] option: unknown > parameter 'vendor' ignored > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.387376] option: unknown > parameter 'product' ignored > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.387474] usbcore: > registered new interface driver option > Jun 6 10:14:53 thorne-ul-dt kernel: [ 2662.387495] usbserial: USB > Serial support registered for GSM modem (1-port) > Jun 6 10:14:55 thorne-ul-dt ModemManager[1110]: (ttyUSB2): > port attributes not fully set > Jun 6 10:14:55 thorne-ul-dt ModemManager[1110]: (ttyUSB3): > port attributes not fully set > Jun 6 10:15:0
Re: [PATCH 0/9] tty: drop broken alt-speed handling
On Tue, 6 Jun 2017 12:54:32 +0200
Johan Hovold wrote:
> Setting an alt-speed using TIOCSSERIAL and SPD flags has been deprecated
> since v2.1.69 and has been broken for all tty drivers but serial-core
> since v3.10 and commit 6865ff222cca ("TTY: do not warn about setting
> speed via SPD_*") without anyone noticing (for four years).
We have the ability to set the speed directly via termios so I doubt
anyone is using the remaining hacks either but I guess someone may. All
looks good to me.
Reviewed-by: Alan Cox
Alan
--
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] usb: usbip: set buffer pointers to NULL after free
On Tue, Jun 06, 2017 at 11:36:03AM +0200, Michael Grzeschik wrote: > Gentle Ping. I'm waiting for a usbip maintainer to review it :) -- 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: gadget: udc: renesas_usb3: add DMAC support
Hi, > From: Felipe Balbi > Sent: Tuesday, June 6, 2017 6:40 PM > > Hi, > > Yoshihiro Shimoda writes: > > Hi, > > > >> From: Felipe Balbi > >> Sent: Friday, June 2, 2017 6:49 PM > >> > >> Hi, > >> > >> Yoshihiro Shimoda writes: > >> > Hi Felipe, > >> > > >> >> -Original Message- > >> >> From: Yoshihiro Shimoda > >> >> Sent: Wednesday, April 26, 2017 8:50 PM > >> >> > >> >> This patch set is based on the latest Feribe's usb.git / testing/next > >> >> branch > >> >> (the commit id = 28ea6be01e2cf244c461a40c8e9593816f894412.) > >> > > >> > I'm afraid but, would you review this patch set? > >> > This patch set can be applied on the today's testing/next branch. > >> > >> I was thinking that we need the fixes during the -rc cycle. No? In that > >> case, we need to get rid of the dependencies between 1-4 and patch 5. > > > > Indeed. > > > >> patches 1-4 are in my testing/fixes now. > > > > Thank you! > > I will resubmit the patch 5 later. > > Thanks a lot :-) If you can just rebase it on my testing/next, that'll > help a lot already. We will have a couple conflicts when merging, but > I'll make sure to solve them ;-) I got it! I submitted v2 patch now :) Best regards, Yoshihiro Shimoda > -- > 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 8/9] tty: ircomm: remove dead and broken ioctl code
On Tue, 6 Jun 2017 12:54:40 +0200 Johan Hovold wrote: > Remove three ifdefed and broken implementations of TIOCSSERIAL and > TIOCGICOUNT, and parity handling in set_termios which had suffered > severe bit rot. I would be amazed if the IRDA code still works. It's not been tested properly for years and it never followed the tty rules properly in the first place - so this looks good, although moving IRDA into staging and /dev/null would IMHO be far better. IRDA is dead, and IR remotes are handled via completely different code. Alan -- 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: gadget: udc: renesas_usb3: add support for dedicated DMAC
The USB3.0 peripheral controller on R-Car SoCs has a dedicated DMAC.
The DMAC needs a "PRD table" in system memory and the DMAC can have
four PRD tables. This patch adds support for the DMAC.
Signed-off-by: Yoshihiro Shimoda
---
This patch based on the latest Felipe's usb.git / testing/next branch
(the commit id = ad9721fbf4c4dd7e57372662b91adb8ba0c3a9fc).
Changes from v1:
- Rebase the latest testing/next branch.
- Remove adding a blank line.
- Remove some patches for fix because they was merged on testing/fix
(Thanks!).
drivers/usb/gadget/udc/renesas_usb3.c | 392 ++
1 file changed, 392 insertions(+)
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c
b/drivers/usb/gadget/udc/renesas_usb3.c
index 5a2d845..078f773 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -9,6 +9,7 @@
*/
#include
+#include
#include
#include
#include
@@ -27,6 +28,8 @@
#define USB3_AXI_INT_ENA 0x00c
#define USB3_DMA_INT_STA 0x010
#define USB3_DMA_INT_ENA 0x014
+#define USB3_DMA_CH0_CON(n)(0x030 + ((n) - 1) * 0x10) /* n = 1 to 4 */
+#define USB3_DMA_CH0_PRD_ADR(n)(0x034 + ((n) - 1) * 0x10) /* n = 1 to
4 */
#define USB3_USB_COM_CON 0x200
#define USB3_USB20_CON 0x204
#define USB3_USB30_CON 0x208
@@ -64,6 +67,22 @@
/* AXI_INT_ENA and AXI_INT_STA */
#define AXI_INT_DMAINT BIT(31)
#define AXI_INT_EPCINT BIT(30)
+/* PRD's n = from 1 to 4 */
+#define AXI_INT_PRDEN_CLR_STA_SHIFT(n) (16 + (n) - 1)
+#define AXI_INT_PRDERR_STA_SHIFT(n)(0 + (n) - 1)
+#define AXI_INT_PRDEN_CLR_STA(n) (1 << AXI_INT_PRDEN_CLR_STA_SHIFT(n))
+#define AXI_INT_PRDERR_STA(n) (1 << AXI_INT_PRDERR_STA_SHIFT(n))
+
+/* DMA_INT_ENA and DMA_INT_STA */
+#define DMA_INT(n) BIT(n)
+
+/* DMA_CH0_CONn */
+#define DMA_CON_PIPE_DIR BIT(15) /* 1: In Transfer */
+#define DMA_CON_PIPE_NO_SHIFT 8
+#define DMA_CON_PIPE_NO_MASK GENMASK(12, DMA_CON_PIPE_NO_SHIFT)
+#define DMA_COM_PIPE_NO(n) (((n) << DMA_CON_PIPE_NO_SHIFT) & \
+DMA_CON_PIPE_NO_MASK)
+#define DMA_CON_PRD_EN BIT(0)
/* LCLKSEL */
#define LCLKSEL_LSEL BIT(18)
@@ -231,8 +250,50 @@
#define USB3_EP0_BUF_SIZE 8
#define USB3_MAX_NUM_PIPES 30
#define USB3_WAIT_US 3
+#define USB3_DMA_NUM_SETTING_AREA 4
+/*
+ * To avoid double-meaning of "0" (xferred 65536 bytes or received zlp if
+ * buffer size is 65536), this driver uses the maximum size per a entry is
+ * 32768 bytes.
+ */
+#define USB3_DMA_MAX_XFER_SIZE 32768
+#define USB3_DMA_PRD_SIZE 4096
struct renesas_usb3;
+
+/* Physical Region Descriptor Table */
+struct renesas_usb3_prd {
+ u32 word1;
+#define USB3_PRD1_EBIT(30) /* the end of chain */
+#define USB3_PRD1_UBIT(29) /* completion of transfer */
+#define USB3_PRD1_DBIT(28) /* Error occurred */
+#define USB3_PRD1_INT BIT(27) /* Interrupt occurred */
+#define USB3_PRD1_LST BIT(26) /* Last Packet */
+#define USB3_PRD1_B_INCBIT(24)
+#define USB3_PRD1_MPS_80
+#define USB3_PRD1_MPS_16 BIT(21)
+#define USB3_PRD1_MPS_32 BIT(22)
+#define USB3_PRD1_MPS_64 (BIT(22) | BIT(21))
+#define USB3_PRD1_MPS_512 BIT(23)
+#define USB3_PRD1_MPS_1024 (BIT(23) | BIT(21))
+#define USB3_PRD1_MPS_RESERVED (BIT(23) | BIT(22) | BIT(21))
+#define USB3_PRD1_SIZE_MASKGENMASK(15, 0)
+
+ u32 bap;
+};
+#define USB3_DMA_NUM_PRD_ENTRIES (USB3_DMA_PRD_SIZE / \
+ sizeof(struct renesas_usb3_prd))
+#define USB3_DMA_MAX_XFER_SIZE_ALL_PRDS(USB3_DMA_PRD_SIZE / \
+sizeof(struct renesas_usb3_prd) * \
+USB3_DMA_MAX_XFER_SIZE)
+
+struct renesas_usb3_dma {
+ struct renesas_usb3_prd *prd;
+ dma_addr_t prd_dma;
+ int num;/* Setting area number (from 1 to 4) */
+ bool used;
+};
+
struct renesas_usb3_request {
struct usb_request req;
struct list_headqueue;
@@ -242,6 +303,7 @@ struct renesas_usb3_request {
struct renesas_usb3_ep {
struct usb_ep ep;
struct renesas_usb3 *usb3;
+ struct renesas_usb3_dma *dma;
int num;
char ep_name[USB3_EP_NAME_SIZE];
struct list_head queue;
@@ -270,6 +332,8 @@ struct renesas_usb3 {
struct renesas_usb3_ep *usb3_ep;
int num_usb3_eps;
+ struct renesas_usb3_dma dma[USB3_DMA_NUM_SETTING_AREA];
+
spinlock_t lock;
int disabled_count;
@@ -298,8 +362,18 @@ struct renesas_usb3 {
(i) < (usb3)->num_usb3_eps;\
(i)++, usb3_ep = usb3_get_ep(usb3, (i)))
+#define usb3_get_dma(usb3, i) (&(usb3)
Re: [PATCH] USB: qcserial: expose methods for modem control
On Tue, May 23, 2017 at 10:58:43PM -0700, Magnus Lynch wrote: > The qcserial driver fails to expose the .tiocmget and .tiocmset methods > available from usb_wwan. These methods are required by ioctl commands > dealing with the modem control signals DTR, RTS, etc. > > With these methods not set ioctl calls intended to control the DTR state > will fail. For example, pppd drops and raises DTR in preparation to dialing > the modem, which handles the case of the modem already being connected by > making it hang up and return to command mode. DTR control being unavailable > will lead to a protracted failure to connect as the modem will be stuck in > a state not responsive to command. > > I have tested that with this patch the described case is handled > successfully. There is an analogous method for .ioctl available from > usb_wwan (as used in option.c) but I conservatively left that for lack of > familiarity. > > Signed-off-by: Magnus Lynch Thanks for the patch. The change itself looks good to me, but the patch is whitespace damaged (tabs replaced with spaces, possibly your mailers fault) and does not apply. I suggest taking a look at git-send-email. Please fix this up and resend a v2. > diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c > index fd509ed6c..4ac137d 100644 > --- a/drivers/usb/serial/qcserial.c > +++ b/drivers/usb/serial/qcserial.c > @@ -454,6 +454,8 @@ static void qc_release(struct usb_serial *serial) > .write = usb_wwan_write, > .write_room = usb_wwan_write_room, > .chars_in_buffer = usb_wwan_chars_in_buffer, > + .tiocmget= usb_wwan_tiocmget, > + .tiocmset= usb_wwan_tiocmset, > .attach = qc_attach, > .release = qc_release, > .port_probe = usb_wwan_port_probe, 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] USB: serial: mos7840: add support for setting custom baud rate
On Thu, May 11, 2017 at 09:12:48PM +0300, Peter Mamonov wrote: > The patch implements TIOCSSERIAL ioctl call. The following fields of the > `struct serial_struct` are processed: > > - flags: ASYNC_SPD_MASK bits are processed. > > - baud_base: allow a user to specify arbitrary value less or equal the > maximum port speed. Use it later in conjunction with custom_divisor to > calculate the desired baud rate. > > - custom_divisor: save a user supplied value, use it later for baud rate > calculation. > > Custom baud rate may be applied using any combination of baud_base / > custom_divisor as follows: > > # stty -F /dev/ttyUSBX 38400 > # setserial /dev/ttyUSBX baud_base 1000 divisor 1 spd_cust # 1 kBaud > # setserial /dev/ttyUSBX baud_base 42000 divisor 42 spd_cust # 1 kBaud > > The patch is based on the code from the drivers/usb/serial/ftdi_sio.c. > > Signed-off-by: Peter Mamonov First, sorry for not getting back to you sooner on this one. The short story is that setting the speed using TIOCSSERIAL has been deprecated for a very long time, and the alt-speed handling (e.g. SPD_WARP) has been broken in tty core for about four years without anyone noticing. I've cleaned this up now, and specifically added a deprecation warning also to ftdi_sio. Instead you should be using BOTHER and the "new" TCSETS2 ioctl for setting non-standard baud rates. It's a bit cumbersome to use due to missing libc support, but it is the right interface for this. 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 6/9] tty: cyclades: drop broken alt-speed support
Setting an alt_speed using the ASYNC_SPD flags has been deprecated since
v2.1.69, and has been broken since v3.10 and commit 6865ff222cca ("TTY:
do not warn about setting speed via SPD_*") without anyone noticing.
Drop the broken alt-speed handling altogether, and add a ratelimited
warning about using TIOCCSERIAL to to change speed as being deprecated.
Note that using ASYNC_SPD_CUST is still supported.
Signed-off-by: Johan Hovold
---
drivers/tty/cyclades.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index 104f09c58163..d272bc4e7fb5 100644
--- a/drivers/tty/cyclades.c
+++ b/drivers/tty/cyclades.c
@@ -1975,18 +1975,6 @@ static void cy_set_line_char(struct cyclades_port *info,
struct tty_struct *tty)
cflag = tty->termios.c_cflag;
iflag = tty->termios.c_iflag;
- /*
-* Set up the tty->alt_speed kludge
-*/
- if ((info->port.flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
- tty->alt_speed = 57600;
- if ((info->port.flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
- tty->alt_speed = 115200;
- if ((info->port.flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
- tty->alt_speed = 230400;
- if ((info->port.flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
- tty->alt_speed = 460800;
-
card = info->card;
channel = info->line - card->first_line;
@@ -2295,12 +2283,16 @@ cy_set_serial_info(struct cyclades_port *info, struct
tty_struct *tty,
struct serial_struct __user *new_info)
{
struct serial_struct new_serial;
+ int old_flags;
int ret;
if (copy_from_user(&new_serial, new_info, sizeof(new_serial)))
return -EFAULT;
mutex_lock(&info->port.mutex);
+
+ old_flags = info->port.flags;
+
if (!capable(CAP_SYS_ADMIN)) {
if (new_serial.close_delay != info->port.close_delay ||
new_serial.baud_base != info->baud ||
@@ -2332,6 +2324,11 @@ cy_set_serial_info(struct cyclades_port *info, struct
tty_struct *tty,
check_and_exit:
if (tty_port_initialized(&info->port)) {
+ if ((new_serial.flags ^ old_flags) & ASYNC_SPD_MASK) {
+ /* warn about deprecation unless clearing */
+ if (new_serial.flags & ASYNC_SPD_MASK)
+ dev_warn_ratelimited(tty->dev, "use of SPD
flags is deprecated\n");
+ }
cy_set_line_char(info, tty);
ret = 0;
} else {
--
2.13.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 0/9] tty: drop broken alt-speed handling
Setting an alt-speed using TIOCSSERIAL and SPD flags has been deprecated
since v2.1.69 and has been broken for all tty drivers but serial-core
since v3.10 and commit 6865ff222cca ("TTY: do not warn about setting
speed via SPD_*") without anyone noticing (for four years).
Instead of reverting the offending commit, lets get rid of this legacy
code while adding back a warning about the SPD flags being deprecated to
the drivers that once implemented it. Note that drivers implementing
SPD_CUST will continue to support using a custom divisor.
Also note that serial-core did not rely on the TTY layer for SPD
handling and continues to support it while warning about deprecation
(since 2003 at least).
Greg, I suggest you take it all trough the TTY tree even if merging
through multiple trees and applying the final patch once everything is
upstream would be an option. Also the irda clean up does not depend on
the rest of series as the code implementing SPD handling was ifdefed
out.
Johan
Johan Hovold (9):
serial: rate limit custom-speed deprecation notice
USB: serial: ftdi_sio: simplify TIOCSSERIAL flag logic
USB: serial: ftdi_sio: remove broken alt-speed handling
tty: simserial: drop unused alt_speed handling
tty: amiserial: drop broken alt-speed support
tty: cyclades: drop broken alt-speed support
tty: rocket: drop broken alt-speed support
tty: ircomm: remove dead and broken ioctl code
tty: drop unused alt_speed from tty_struct
arch/ia64/hp/sim/simserial.c | 13 -
drivers/tty/amiserial.c| 23 ++--
drivers/tty/cyclades.c | 21
drivers/tty/rocket.c | 27 +++---
drivers/tty/serial/serial_core.c | 5 +-
drivers/usb/serial/ftdi_sio.c | 67 +--
include/linux/tty.h| 1 -
net/irda/ircomm/ircomm_tty_ioctl.c | 107 +
8 files changed, 34 insertions(+), 230 deletions(-)
--
2.13.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 1/9] serial: rate limit custom-speed deprecation notice
Contrary to what a comment claimed, the ASYNC_SPD flags and custom
divisor can be set by a non-privileged user so rate limit the
deprecation notice as was intended.
Signed-off-by: Johan Hovold
---
drivers/tty/serial/serial_core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 13bfd5dcffce..f534a40aebde 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -954,11 +954,10 @@ static int uart_set_info(struct tty_struct *tty, struct
tty_port *port,
old_custom_divisor != uport->custom_divisor) {
/*
* If they're setting up a custom divisor or speed,
-* instead of clearing it, then bitch about it. No
-* need to rate-limit; it's CAP_SYS_ADMIN only.
+* instead of clearing it, then bitch about it.
*/
if (uport->flags & UPF_SPD_MASK) {
- dev_notice(uport->dev,
+ dev_notice_ratelimited(uport->dev,
"%s sets custom speed on %s. This is
deprecated.\n",
current->comm,
tty_name(port->tty));
--
2.13.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 9/9] tty: drop unused alt_speed from tty_struct
Drop the now unused alt_speed field from struct tty_struct.
Setting an alt_speed using the ASYNC_SPD flags has been deprecated since
v2.1.69, and has been broken for all tty drivers but serial-core since
v3.10 and commit 6865ff222cca ("TTY: do not warn about setting speed via
SPD_*") without anyone noticing.
Note that serial-core still supports changing speed using TIOCSSERIAL
and SPD flags (including "alt-speeds"), but also warns about it being
deprecated since pre-git.
Signed-off-by: Johan Hovold
---
include/linux/tty.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index eccb4ec30a8a..585cf2b5ca94 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -316,7 +316,6 @@ struct tty_struct {
struct tty_struct *link;
struct fasync_struct *fasync;
- int alt_speed; /* For magic substitution of 38400 bps */
wait_queue_head_t write_wait;
wait_queue_head_t read_wait;
struct work_struct hangup_work;
--
2.13.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 2/9] USB: serial: ftdi_sio: simplify TIOCSSERIAL flag logic
Simplify TIOCSSERIAL flag logic somewhat.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index aba74f817dc6..df5c45a4b1d7 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1505,8 +1505,7 @@ static int set_serial_info(struct tty_struct *tty,
/* Do error checking and permission checking */
if (!capable(CAP_SYS_ADMIN)) {
- if (((new_serial.flags & ~ASYNC_USR_MASK) !=
-(priv->flags & ~ASYNC_USR_MASK))) {
+ if ((new_serial.flags ^ priv->flags) & ~ASYNC_USR_MASK) {
mutex_unlock(&priv->cfg_lock);
return -EPERM;
}
@@ -1530,8 +1529,7 @@ static int set_serial_info(struct tty_struct *tty,
check_and_exit:
write_latency_timer(port);
- if ((old_priv.flags & ASYNC_SPD_MASK) !=
-(priv->flags & ASYNC_SPD_MASK)) {
+ if ((priv->flags ^ old_priv.flags) & ASYNC_SPD_MASK) {
if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
tty->alt_speed = 57600;
else if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
@@ -1543,10 +1541,9 @@ static int set_serial_info(struct tty_struct *tty,
else
tty->alt_speed = 0;
}
- if (((old_priv.flags & ASYNC_SPD_MASK) !=
-(priv->flags & ASYNC_SPD_MASK)) ||
- (((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_CUST) &&
-(old_priv.custom_divisor != priv->custom_divisor))) {
+ if ((priv->flags ^ old_priv.flags) & ASYNC_SPD_MASK ||
+ ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_CUST &&
+priv->custom_divisor != old_priv.custom_divisor)) {
change_speed(tty, port);
mutex_unlock(&priv->cfg_lock);
}
--
2.13.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 8/9] tty: ircomm: remove dead and broken ioctl code
Remove three ifdefed and broken implementations of TIOCSSERIAL and
TIOCGICOUNT, and parity handling in set_termios which had suffered
severe bit rot.
Signed-off-by: Johan Hovold
---
net/irda/ircomm/ircomm_tty_ioctl.c | 107 +
1 file changed, 1 insertion(+), 106 deletions(-)
diff --git a/net/irda/ircomm/ircomm_tty_ioctl.c
b/net/irda/ircomm/ircomm_tty_ioctl.c
index f18070118d05..171c3dee760e 100644
--- a/net/irda/ircomm/ircomm_tty_ioctl.c
+++ b/net/irda/ircomm/ircomm_tty_ioctl.c
@@ -97,33 +97,7 @@ static void ircomm_tty_change_speed(struct ircomm_tty_cb
*self,
self->settings.flow_control &= ~IRCOMM_RTS_CTS_IN;
}
tty_port_set_check_carrier(&self->port, ~cflag & CLOCAL);
-#if 0
- /*
-* Set up parity check flag
-*/
-
- if (I_INPCK(self->tty))
- driver->read_status_mask |= LSR_FE | LSR_PE;
- if (I_BRKINT(driver->tty) || I_PARMRK(driver->tty))
- driver->read_status_mask |= LSR_BI;
-
- /*
-* Characters to ignore
-*/
- driver->ignore_status_mask = 0;
- if (I_IGNPAR(driver->tty))
- driver->ignore_status_mask |= LSR_PE | LSR_FE;
-
- if (I_IGNBRK(self->tty)) {
- self->ignore_status_mask |= LSR_BI;
- /*
-* If we're ignore parity and break indicators, ignore
-* overruns too. (For real raw support).
-*/
- if (I_IGNPAR(self->tty))
- self->ignore_status_mask |= LSR_OE;
- }
-#endif
+
self->settings.data_format = cval;
ircomm_param_request(self, IRCOMM_DATA_FORMAT, FALSE);
@@ -271,67 +245,6 @@ static int ircomm_tty_get_serial_info(struct ircomm_tty_cb
*self,
static int ircomm_tty_set_serial_info(struct ircomm_tty_cb *self,
struct serial_struct __user *new_info)
{
-#if 0
- struct serial_struct new_serial;
- struct ircomm_tty_cb old_state, *state;
-
- if (copy_from_user(&new_serial,new_info,sizeof(new_serial)))
- return -EFAULT;
-
-
- state = self
- old_state = *self;
-
- if (!capable(CAP_SYS_ADMIN)) {
- if ((new_serial.baud_base != state->settings.data_rate) ||
- (new_serial.close_delay != state->close_delay) ||
- ((new_serial.flags & ~ASYNC_USR_MASK) !=
-(self->flags & ~ASYNC_USR_MASK)))
- return -EPERM;
- state->flags = ((state->flags & ~ASYNC_USR_MASK) |
-(new_serial.flags & ASYNC_USR_MASK));
- self->flags = ((self->flags & ~ASYNC_USR_MASK) |
- (new_serial.flags & ASYNC_USR_MASK));
- /* self->custom_divisor = new_serial.custom_divisor; */
- goto check_and_exit;
- }
-
- /*
-* OK, past this point, all the error checking has been done.
-* At this point, we start making changes.
-*/
-
- if (self->settings.data_rate != new_serial.baud_base) {
- self->settings.data_rate = new_serial.baud_base;
- ircomm_param_request(self, IRCOMM_DATA_RATE, TRUE);
- }
-
- self->close_delay = new_serial.close_delay * HZ/100;
- self->closing_wait = new_serial.closing_wait * HZ/100;
- /* self->custom_divisor = new_serial.custom_divisor; */
-
- self->flags = ((self->flags & ~ASYNC_FLAGS) |
- (new_serial.flags & ASYNC_FLAGS));
- self->tty->low_latency = (self->flags & ASYNC_LOW_LATENCY) ? 1 : 0;
-
- check_and_exit:
-
- if (tty_port_initialized(self)) {
- if (((old_state.flags & ASYNC_SPD_MASK) !=
-(self->flags & ASYNC_SPD_MASK)) ||
- (old_driver.custom_divisor != driver->custom_divisor)) {
- if ((driver->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
- driver->tty->alt_speed = 57600;
- if ((driver->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
- driver->tty->alt_speed = 115200;
- if ((driver->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
- driver->tty->alt_speed = 230400;
- if ((driver->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
- driver->tty->alt_speed = 460800;
- ircomm_tty_change_speed(driver);
- }
- }
-#endif
return 0;
}
@@ -367,24 +280,6 @@ int ircomm_tty_ioctl(struct tty_struct *tty,
case TIOCGICOUNT:
pr_debug("%s(), TIOCGICOUNT not impl!\n", __func__);
-#if 0
- save_flags(flags); cli();
- cnow = driver->icount;
- restore_flags(flags);
- p_cuser = (struct serial_icounter_struct __user *) arg;
- if (put_user(cn
[PATCH 3/9] USB: serial: ftdi_sio: remove broken alt-speed handling
Remove the broken alt_speed code, and warn when trying to set the line
speed using TIOCSSERIAL and SPD flags.
The use of SPD flags to set the line speed has been deprecated since
v2.1.69 and support for alt_speed (e.g. "warp") has even been removed
from TTY core in v3.10 by commit 6865ff222cca ("TTY: do not warn about
setting speed via SPD_*"), effectively breaking all driver
implementations of this except for serial core.
Also remove the verbose and outdated comment on how to set baud rates.
Note that setting a custom divisor will continue to work with the
caveat that 38400 must again be selected every time the divisor is
changed since v2.6.24 and commit 669a6db1037e ("USB: ftd_sio: cleanups
and updates for new termios work") which started reporting back the
actual baud rate used.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 56 +++
1 file changed, 9 insertions(+), 47 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index df5c45a4b1d7..1cec03799cdf 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1244,42 +1244,13 @@ static __u32 get_ftdi_divisor(struct tty_struct *tty,
int div_okay = 1;
int baud;
- /*
-* The logic involved in setting the baudrate can be cleanly split into
-* 3 steps.
-* 1. Standard baud rates are set in tty->termios->c_cflag
-* 2. If these are not enough, you can set any speed using alt_speed as
-* follows:
-*- set tty->termios->c_cflag speed to B38400
-*- set your real speed in tty->alt_speed; it gets ignored when
-* alt_speed==0, (or)
-*- call TIOCSSERIAL ioctl with (struct serial_struct) set as
-* follows:
-* flags & ASYNC_SPD_MASK == ASYNC_SPD_[HI, VHI, SHI, WARP],
-* this just sets alt_speed to (HI: 57600, VHI: 115200,
-* SHI: 230400, WARP: 460800)
-* ** Steps 1, 2 are done courtesy of tty_get_baud_rate
-* 3. You can also set baud rate by setting custom divisor as follows
-*- set tty->termios->c_cflag speed to B38400
-*- call TIOCSSERIAL ioctl with (struct serial_struct) set as
-* follows:
-* o flags & ASYNC_SPD_MASK == ASYNC_SPD_CUST
-* o custom_divisor set to baud_base / your_new_baudrate
-* ** Step 3 is done courtesy of code borrowed from serial.c
-*I should really spend some time and separate + move this common
-*code to serial.c, it is replicated in nearly every serial driver
-*you see.
-*/
-
- /* 1. Get the baud rate from the tty settings, this observes
- alt_speed hack */
-
baud = tty_get_baud_rate(tty);
dev_dbg(dev, "%s - tty_get_baud_rate reports speed %d\n", __func__,
baud);
- /* 2. Observe async-compatible custom_divisor hack, update baudrate
- if needed */
-
+ /*
+* Observe deprecated async-compatible custom_divisor hack, update
+* baudrate if needed.
+*/
if (baud == 38400 &&
((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_CUST) &&
(priv->custom_divisor)) {
@@ -1288,8 +1259,6 @@ static __u32 get_ftdi_divisor(struct tty_struct *tty,
__func__, priv->custom_divisor, baud);
}
- /* 3. Convert baudrate to device-specific divisor */
-
if (!baud)
baud = 9600;
switch (priv->chip_type) {
@@ -1529,21 +1498,14 @@ static int set_serial_info(struct tty_struct *tty,
check_and_exit:
write_latency_timer(port);
- if ((priv->flags ^ old_priv.flags) & ASYNC_SPD_MASK) {
- if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
- tty->alt_speed = 57600;
- else if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
- tty->alt_speed = 115200;
- else if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
- tty->alt_speed = 230400;
- else if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
- tty->alt_speed = 460800;
- else
- tty->alt_speed = 0;
- }
if ((priv->flags ^ old_priv.flags) & ASYNC_SPD_MASK ||
((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_CUST &&
priv->custom_divisor != old_priv.custom_divisor)) {
+
+ /* warn about deprecation unless clearing */
+ if (priv->flags & ASYNC_SPD_MASK)
+ dev_warn_ratelimited(&port->dev, "use of SPD flags is
deprecated\n");
+
change_speed(tty, port);
mutex_unlock(&priv->cfg_lock);
}
--
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.or
[PATCH 5/9] tty: amiserial: drop broken alt-speed support
Setting an alt_speed using the ASYNC_SPD flags has been deprecated since
v2.1.69, and has been broken since v3.10 and commit 6865ff222cca ("TTY:
do not warn about setting speed via SPD_*") without anyone noticing.
Drop the broken alt-speed handling altogether, and add a ratelimited
warning about using TIOCCSERIAL to change speed as being deprecated.
Note that using ASYNC_SPD_CUST is still supported.
Signed-off-by: Johan Hovold
---
drivers/tty/amiserial.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index dea16bb8c46a..9820e20993db 100644
--- a/drivers/tty/amiserial.c
+++ b/drivers/tty/amiserial.c
@@ -570,18 +570,6 @@ static int startup(struct tty_struct *tty, struct
serial_state *info)
info->xmit.head = info->xmit.tail = 0;
/*
-* Set up the tty->alt_speed kludge
-*/
- if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
- tty->alt_speed = 57600;
- if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
- tty->alt_speed = 115200;
- if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
- tty->alt_speed = 230400;
- if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
- tty->alt_speed = 460800;
-
- /*
* and set the speed of the serial port
*/
change_speed(tty, info, NULL);
@@ -1084,14 +1072,9 @@ static int set_serial_info(struct tty_struct *tty,
struct serial_state *state,
check_and_exit:
if (tty_port_initialized(port)) {
if (change_spd) {
- if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
- tty->alt_speed = 57600;
- if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
- tty->alt_speed = 115200;
- if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
- tty->alt_speed = 230400;
- if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
- tty->alt_speed = 460800;
+ /* warn about deprecation unless clearing */
+ if (new_serial.flags & ASYNC_SPD_MASK)
+ dev_warn_ratelimited(tty->dev, "use of SPD
flags is deprecated\n");
change_speed(tty, state, NULL);
}
} else
--
2.13.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 7/9] tty: rocket: drop broken alt-speed support
Setting an alt_speed using the ROCKET_SPD flags has been deprecated
since v2.1.69, and has been broken since commit 6865ff222cca ("TTY: do
not warn about setting speed via SPD_*") without anyone noticing.
To make things worse commit 6df3526b6649 ("rocket: first pass at termios
reporting") in v2.6.25 started reporting back the actual baud rate used,
something which also required 38400 to again be set whenever changing a
SPD flag.
Drop the broken alt-speed handling altogether, and add a ratelimited
warning about using TIOCCSERIAL to change speed as being deprecated.
Note that the rocket driver has never supported using a custom divisor
(ASYNC_SPD_CUST equivalent).
Signed-off-by: Johan Hovold
---
drivers/tty/rocket.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
index b51a877da986..20d79a6007d5 100644
--- a/drivers/tty/rocket.c
+++ b/drivers/tty/rocket.c
@@ -947,18 +947,6 @@ static int rp_open(struct tty_struct *tty, struct file
*filp)
tty_port_set_initialized(&info->port, 1);
- /*
-* Set up the tty->alt_speed kludge
-*/
- if ((info->flags & ROCKET_SPD_MASK) == ROCKET_SPD_HI)
- tty->alt_speed = 57600;
- if ((info->flags & ROCKET_SPD_MASK) == ROCKET_SPD_VHI)
- tty->alt_speed = 115200;
- if ((info->flags & ROCKET_SPD_MASK) == ROCKET_SPD_SHI)
- tty->alt_speed = 230400;
- if ((info->flags & ROCKET_SPD_MASK) == ROCKET_SPD_WARP)
- tty->alt_speed = 460800;
-
configure_r_port(tty, info, NULL);
if (C_BAUD(tty)) {
sSetDTR(cp);
@@ -1219,23 +1207,20 @@ static int set_config(struct tty_struct *tty, struct
r_port *info,
return -EPERM;
}
info->flags = ((info->flags & ~ROCKET_USR_MASK) |
(new_serial.flags & ROCKET_USR_MASK));
- configure_r_port(tty, info, NULL);
mutex_unlock(&info->port.mutex);
return 0;
}
+ if ((new_serial.flags ^ info->flags) & ROCKET_SPD_MASK) {
+ /* warn about deprecation, unless clearing */
+ if (new_serial.flags & ROCKET_SPD_MASK)
+ dev_warn_ratelimited(tty->dev, "use of SPD flags is
deprecated\n");
+ }
+
info->flags = ((info->flags & ~ROCKET_FLAGS) | (new_serial.flags &
ROCKET_FLAGS));
info->port.close_delay = new_serial.close_delay;
info->port.closing_wait = new_serial.closing_wait;
- if ((info->flags & ROCKET_SPD_MASK) == ROCKET_SPD_HI)
- tty->alt_speed = 57600;
- if ((info->flags & ROCKET_SPD_MASK) == ROCKET_SPD_VHI)
- tty->alt_speed = 115200;
- if ((info->flags & ROCKET_SPD_MASK) == ROCKET_SPD_SHI)
- tty->alt_speed = 230400;
- if ((info->flags & ROCKET_SPD_MASK) == ROCKET_SPD_WARP)
- tty->alt_speed = 460800;
mutex_unlock(&info->port.mutex);
configure_r_port(tty, info, NULL);
--
2.13.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 4/9] tty: simserial: drop unused alt_speed handling
This driver was setting the deprecated and broken alt_speed based on port flags, but never provided a means to change the flags or to actually change the speed. Signed-off-by: Johan Hovold --- arch/ia64/hp/sim/simserial.c | 13 - 1 file changed, 13 deletions(-) diff --git a/arch/ia64/hp/sim/simserial.c b/arch/ia64/hp/sim/simserial.c index de8cba121013..70d52e9bb575 100644 --- a/arch/ia64/hp/sim/simserial.c +++ b/arch/ia64/hp/sim/simserial.c @@ -387,19 +387,6 @@ static int activate(struct tty_port *port, struct tty_struct *tty) } state->xmit.head = state->xmit.tail = 0; - - /* -* Set up the tty->alt_speed kludge -*/ - if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI) - tty->alt_speed = 57600; - if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI) - tty->alt_speed = 115200; - if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI) - tty->alt_speed = 230400; - if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP) - tty->alt_speed = 460800; - errout: local_irq_restore(flags); return retval; -- 2.13.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] xhci: AMD Promontory USB disable port support
> -Original Message-
> From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com]
> Sent: Monday, June 05, 2017 5:40 PM
> To: Jiahau Chang; linux-usb@vger.kernel.org; mathias.ny...@intel.com;
> g...@kroah.com
> Cc: kent@canonical.com; Justin_CY Chen(陳志勇); Yd Tseng(曾裕達);
> acelan@canonical.com; Lars Chang(張家豪)
> Subject: Re: [PATCH v3] xhci: AMD Promontory USB disable port support
>
> On 31.05.2017 10:41, Jiahau Chang wrote:
> > v3: Fix some checkpatch.pl warnings
> >
> > For AMD Promontory xHCI host, although you can disable USB 2.0 ports in
> BIOS
> > settings, those ports will be enabled anyway after you remove a device on
> > that port and re-plug it in again. It's a known limitation of the chip.
> > As a workaround we can clear the PORT_WAKE_BITS.
> >
> > Signed-off-by: Jiahau Chang
> > ---
> > drivers/usb/host/xhci-hub.c | 19 ++-
> > drivers/usb/host/xhci-pci.c | 13 +
> > drivers/usb/host/xhci.h | 2 ++
> > 3 files changed, 29 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> > index 0dde49c..aad32c6 100644
> > --- a/drivers/usb/host/xhci-hub.c
> > +++ b/drivers/usb/host/xhci-hub.c
> > @@ -1218,12 +1218,19 @@ int xhci_hub_control(struct usb_hcd *hcd, u16
> typeReq, u16 wValue,
> > xhci_dbg(xhci, "set port reset, actual port %d status =
> 0x%x\n", wIndex, temp);
> > break;
> > case USB_PORT_FEAT_REMOTE_WAKE_MASK:
> > - xhci_set_remote_wake_mask(xhci, port_array,
> > + if ((xhci->quirks & XHCI_U2_DISABLE_WAKE) &&
> > (hcd->speed <
> HCD_USB3)) {
> > + temp = readl(port_array[wIndex]);
> > + xhci_dbg(xhci, "skip set port remote wake mask,
> > "
> > + "actual port %d status =
> > 0x%x\n",
> > + wIndex, temp);
>
> Does this work?
>
> If I remember correctly USB_PORT_FEAT_REMOTE_WAKE_MASK is a USB3
> only feature.
> The (hcd->speed < HCD_USB3) condition should never be true here.
Yes, you are right. The USB_PORT_FEAT_REMOTE_WAKE_MASK is a USB3 only
feature. The relative dummy code is removed in V4.
>
> -Mathias
==
This email and any attachments to it contain confidential information and are
intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally,
please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard
copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on
this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those
of ASMedia Technology Inc. Thank you for your cooperation.
==
N�妓緶r��y���匒淅炮カv傂�)瑎{.n�+�極�{捱〇�傂n�r←屹��螐�刻俾&ｐ 埂��嶭�(剝���摃j"���m翯z嫡��僠fㄑ搬��坍�m�
Re: [PATCH v2] usb: xhci: Issue stop EP command only when the EP state is running
On 6/2/2017 8:21 PM, Alan Stern wrote: > On Fri, 2 Jun 2017, Shyam Sundar S K wrote: > >> on AMD platforms with SNPS 3.1 USB controller if stop endpoint command is >> issued the controller does not respond, when the EP is not in running >> state. HW completes the command execution and reports >> "Context State Error" completion code. This is as per the spec. However >> HW on receiving the second command additionally marks EP to Flow control >> state in HW which is RTL bug. The above bug causes the HW not to respond >> to any further doorbells that are rung by the driver. This causes the EP >> to not functional anymore and causes gross functional failures. >> >> As a workaround, not to hit this problem, its better we check the EP state >> and issue the stop EP command only when the EP is in running state. > Isn't there an unavoidable race? Suppose you check the EP state and > the controller says the endpoint is running. But then a STALL packet > is received and the controller stops the endpoint before you can issue > the Stop-EP command. How would you handle that? Hi Alan, Thank you for reviewing the patch. I think, to avoid this kind of race conditions; its better to have a variable to keep track of internal state changes as rightly pointed by Mathias (as per xhci specs, section 4.8.3). But, Mathias mentioned that those changes might not be required for this workaround and that can be taken at later point in time. So, I resubmitted the patch based on his latest suggestions. Thanks, Shyam > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] xhci: AMD Promontory USB disable port support
v4: Remove the patch code in case USB_PORT_FEAT_REMOTE_WAKE_MASK
For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS
settings, those ports will be enabled anyway after you remove a device on
that port and re-plug it in again. It's a known limitation of the chip.
As a workaround we can clear the PORT_WAKE_BITS.
Signed-off-by: Jiahau Chang
---
drivers/usb/host/xhci-hub.c | 2 ++
drivers/usb/host/xhci-pci.c | 13 +
drivers/usb/host/xhci.h | 2 ++
3 files changed, 17 insertions(+)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 0dde49c..8994676 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1461,6 +1461,8 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
t2 |= PORT_WKOC_E | PORT_WKCONN_E;
t2 &= ~PORT_WKDISC_E;
}
+ if ((xhci->quirks & XHCI_U2_DISABLE_WAKE) &&
(hcd->speed < HCD_USB3))
+ t2 &= ~PORT_WAKE_BITS;
} else
t2 &= ~PORT_WAKE_BITS;
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fcf1f3f..3b76d53 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -54,6 +54,11 @@
#define PCI_DEVICE_ID_INTEL_APL_XHCI 0x5aa8
#define PCI_DEVICE_ID_INTEL_DNV_XHCI 0x19d0
+#define PCI_DEVICE_ID_AMD_PROMONTORYA_40x43b9
+#define PCI_DEVICE_ID_AMD_PROMONTORYA_30x43ba
+#define PCI_DEVICE_ID_AMD_PROMONTORYA_20x43bb
+#define PCI_DEVICE_ID_AMD_PROMONTORYA_10x43bc
+
static const char hcd_name[] = "xhci_hcd";
static struct hc_driver __read_mostly xhci_pci_hc_driver;
@@ -135,6 +140,14 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
if (pdev->vendor == PCI_VENDOR_ID_AMD)
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
+ if ((pdev->vendor == PCI_VENDOR_ID_AMD) &&
+ ((pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_4) ||
+ (pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_3) ||
+ (pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_2) ||
+ (pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_1)))
+ xhci->quirks |= XHCI_U2_DISABLE_WAKE;
+
+
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
xhci->quirks |= XHCI_LPM_SUPPORT;
xhci->quirks |= XHCI_INTEL_HOST;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 73a28a9..48b262a 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1819,6 +1819,8 @@ struct xhci_hcd {
/* For controller with a broken Port Disable implementation */
#define XHCI_BROKEN_PORT_PED (1 << 25)
#define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
+#define XHCI_U2_DISABLE_WAKE(1 << 27)
+
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
--
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 v4 0/3] USB Audio Gadget refactoring
Hi, Greg KH writes: >> > I'm OK with dropping legacy f_uac1 implementation. >> > >> > Another idea I was thinking about is to implement simple in-kernel >> > driver which will do the same as existing alsaloop tool userspace >> > tool does (so legacy users will need to load two kernel modules >> > and get same functionality). But this seems to be a wrong way, >> > since It known that Linux kernel community doesn't like to take drivers >> > with same functionality as existing userspace tools already have. >> > >> > So bottom line: since I'm not a legacy f_uac1 user, there is no >> > difference for me how to handle it - remove legacy f_uac1 completely, >> > rename it to f_uac1_legacy or add separate f_uac1_acard function. >> > >> > So if dropping of legacy f_uac1 implementation is OK for you, >> > I can do it quickly in next patchset. >> >> Personally, I don't want duplicated functionality and I think the >> virtual sound card approach is much better. Then again, removing >> functionality we already support is kind of odd. >> >> Greg, Alan, what do you guys think? Do we keep a duplicated function >> around or do we just tell people to rely on alsaloop? Personally, I >> think we're better off with the flexibility of the virtual sound card, >> what's your take? > > If the in-kernel driver will do more things, and we don't break the > existing setups using alsaloop, then I don't see the problem, except > that we now have to maintain two things :) > > If you don't mind the maintenance, fine with me... Okay, I don't think many will continue to use f_uac1.c. Ruslan, can you update your series so that current f_uac1.c gets renamed to f_uac1_legacy.c and you introduce a *new* f_uac1.c instead? Thanks a lot -- balbi signature.asc Description: PGP signature
RE: [PATCH 0/5] usb: gadget: udc: renesas_usb3: add DMAC support
Hi, Yoshihiro Shimoda writes: > Hi, > >> From: Felipe Balbi >> Sent: Friday, June 2, 2017 6:49 PM >> >> Hi, >> >> Yoshihiro Shimoda writes: >> > Hi Felipe, >> > >> >> -Original Message- >> >> From: Yoshihiro Shimoda >> >> Sent: Wednesday, April 26, 2017 8:50 PM >> >> >> >> This patch set is based on the latest Feribe's usb.git / testing/next >> >> branch >> >> (the commit id = 28ea6be01e2cf244c461a40c8e9593816f894412.) >> > >> > I'm afraid but, would you review this patch set? >> > This patch set can be applied on the today's testing/next branch. >> >> I was thinking that we need the fixes during the -rc cycle. No? In that >> case, we need to get rid of the dependencies between 1-4 and patch 5. > > Indeed. > >> patches 1-4 are in my testing/fixes now. > > Thank you! > I will resubmit the patch 5 later. Thanks a lot :-) If you can just rebase it on my testing/next, that'll help a lot already. We will have a couple conflicts when merging, but I'll make sure to solve them ;-) -- balbi signature.asc Description: PGP signature
Re: [PATCH v4] usb: usbip: set buffer pointers to NULL after free
Gentle Ping. To verify this patch just test usbip with some USB Ethernet devices. On Mon, May 22, 2017 at 01:02:44PM +0200, Michael Grzeschik wrote: > The usbip stack dynamically allocates the transfer_buffer and > setup_packet of each urb that got generated by the tcp to usb stub code. > As these pointers are always used only once we will set them to NULL > after use. This is done likewise to the free_urb code in vudc_dev.c. > This patch fixes double kfree situations where the usbip remote side > added the URB_FREE_BUFFER. > > Cc: sta...@vger.kernel.org > Signed-off-by: Michael Grzeschik > --- > v1 -> v2: - rephrased patch subject from: > "usb: usbip: avoid the usb layer to kfree our allocated buffer" > - changed to always let urb_destoy remove the transfer_buffer > v2 -> v3: - added stable to cc > - wrapped long line with over 80 chars > v3 -> v4: - rephrades patch subject from usb: > "usbip: let urb_destroy kfree the transfer_buffer" > - setting buffer pointers to NULL > instead of omitting flag URB_FREE_BUFFER > > drivers/usb/usbip/stub_main.c | 4 > drivers/usb/usbip/stub_tx.c | 4 > 2 files changed, 8 insertions(+) > > diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c > index 44ab43fc4fcc7..af10f7b131a49 100644 > --- a/drivers/usb/usbip/stub_main.c > +++ b/drivers/usb/usbip/stub_main.c > @@ -262,7 +262,11 @@ void stub_device_cleanup_urbs(struct stub_device *sdev) > kmem_cache_free(stub_priv_cache, priv); > > kfree(urb->transfer_buffer); > + urb->transfer_buffer = NULL; > + > kfree(urb->setup_packet); > + urb->setup_packet = NULL; > + > usb_free_urb(urb); > } > } > diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c > index 6b1e8c3f0e4b2..be50cef645d8a 100644 > --- a/drivers/usb/usbip/stub_tx.c > +++ b/drivers/usb/usbip/stub_tx.c > @@ -28,7 +28,11 @@ static void stub_free_priv_and_urb(struct stub_priv *priv) > struct urb *urb = priv->urb; > > kfree(urb->setup_packet); > + urb->setup_packet = NULL; > + > kfree(urb->transfer_buffer); > + urb->transfer_buffer = NULL; > + > list_del(&priv->list); > kmem_cache_free(stub_priv_cache, priv); > usb_free_urb(urb); > -- > 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 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/6] mfd: intel_soc_pmic_bxtwc: Add chained IRQ support
On Mon, Jun 5, 2017 at 10:08 PM, wrote: > From: Kuppuswamy Sathyanarayanan > > Following patch set adds chained IRQ support to WCOVE PMIC driver. Assuming it has been tested, Reviewed-by: Andy Shevchenko to the patches which do not have it yet. > Changes since v3: > * Added fix for typec wcove driver. > > Changes since v4: > * Squashed following two commits, to keep the patch set bisectable. >usb: typec: typec_wcove: Use charger irq chip to get usbc virq >mfd: intel_soc_pmic_bxtwc: use chained irqs for second level irq chips > > Changes since v5: > * Changed irq->IRQ, pmic->PMIC in all commit messages. > * Squashed following two thermal driver related commits. > mfd: intel_soc_pmic_bxtwc: Remove thermal second level irqs > thermal: intel_bxt_pmic_thermal: Use first level PMIC thermal irq > * Squashed following two GPIO driver related commits. > mfd: intel_soc_pmic_bxtwc: Remove second level irq for gpio device > gpio: gpio-wcove: Use first level PMIC GPIO irq > > Kuppuswamy Sathyanarayanan (6): > mfd: intel_soc_pmic_bxtwc: Fix TMU interrupt index > mfd: intel_soc_pmic_bxtwc: Remove thermal second level IRQs > mfd: intel_soc_pmic_bxtwc: Remove second level IRQ for gpio device > mfd: intel_soc_pmic_bxtwc: Utilize devm_* functions in driver probe > mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips > platform/x86: intel_bxtwc_tmu: Remove first level IRQ unmask > > drivers/gpio/gpio-wcove.c| 14 +- > drivers/mfd/intel_soc_pmic_bxtwc.c | 232 > +-- > drivers/platform/x86/intel_bxtwc_tmu.c | 4 - > drivers/thermal/intel_bxt_pmic_thermal.c | 2 +- > drivers/usb/typec/typec_wcove.c | 2 +- > include/linux/mfd/intel_soc_pmic.h | 5 +- > 6 files changed, 175 insertions(+), 84 deletions(-) > > -- > 2.7.4 > -- 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 v6 5/6] mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips
On Mon, Jun 05, 2017 at 12:08:05PM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Whishkey cove PMIC has support to mask/unmask interrupts at two levels. > At first level we can mask/unmask interrupt domains like TMU, GPIO, ADC, > CHGR, BCU THERMAL and PWRBTN and at second level, it provides facility > to mask/unmask individual interrupts belong each of this domain. For > example, in case of TMU, at first level we have TMU interrupt domain, > and at second level we have two interrupts, wake alarm, system alarm that > belong to the TMU interrupt domain. > > Currently, in this driver all first level IRQs are registered as part of > IRQ chip(bxtwc_regmap_irq_chip). By default, after you register the IRQ > chip from your driver, all IRQs in that chip will masked and can only be > enabled if that IRQ is requested using request_irq() call. This is the > default Linux IRQ behavior model. And whenever a dependent device that > belongs to PMIC requests only the second level IRQ and not explicitly > unmask the first level IRQ, then in essence the second level IRQ will > still be disabled. For example, if TMU device driver request wake_alarm > IRQ and not explicitly unmask TMU level 1 IRQ then according to the default > Linux IRQ model, wake_alarm IRQ will still be disabled. So the proper > solution to fix this issue is to use the chained IRQ chip concept. We > should chain all the second level chip IRQs to the corresponding first > level IRQ. To do this, we need to create separate IRQ chips for every > group of second level IRQs. > > In case of TMU, when adding second level IRQ chip, instead of using PMIC > IRQ we should use the corresponding first level IRQ. So the following > code will change from > > ret = regmap_add_irq_chip(pmic->regmap, pmic->irq, ...) > > to, > > virq = regmap_irq_get_virq(&pmic->irq_chip_data, BXTWC_TMU_LVL1_IRQ); > > ret = regmap_add_irq_chip(pmic->regmap, virq, ...) > > In case of Whiskey Cove Type-C driver, Since USBC IRQ is moved under > charger level2 IRQ chip. We should use charger IRQ chip(irq_chip_data_chgr) > to get the USBC virtual IRQ number. > > Signed-off-by: Kuppuswamy Sathyanarayanan > > Acked-for-MFD-by: Lee Jones For the typec_wcove.c part: Revieved-by: Heikki Krogerus Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/5] usb: gadget: udc: renesas_usb3: add DMAC support
Hi, > From: Felipe Balbi > Sent: Friday, June 2, 2017 6:49 PM > > Hi, > > Yoshihiro Shimoda writes: > > Hi Felipe, > > > >> -Original Message- > >> From: Yoshihiro Shimoda > >> Sent: Wednesday, April 26, 2017 8:50 PM > >> > >> This patch set is based on the latest Feribe's usb.git / testing/next > >> branch > >> (the commit id = 28ea6be01e2cf244c461a40c8e9593816f894412.) > > > > I'm afraid but, would you review this patch set? > > This patch set can be applied on the today's testing/next branch. > > I was thinking that we need the fixes during the -rc cycle. No? In that > case, we need to get rid of the dependencies between 1-4 and patch 5. Indeed. > patches 1-4 are in my testing/fixes now. Thank you! I will resubmit the patch 5 later. Best regards, Yoshihiro Shimoda > -- > 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 v4 0/3] USB Audio Gadget refactoring
On Mon, Jun 05, 2017 at 12:22:13PM +0300, Felipe Balbi wrote: > > Hi, > > Ruslan Bilovol writes: > >> Ruslan Bilovol writes: > >>> I came to this patch series when wanted to do two things: > >>> - use UAC1 as virtual ALSA sound card on gadget side, > >>>just like UAC2 is used so it's possible to do rate > >>>resampling > >>> - have both playback/capture support in UAC1 > >>> > >>> Since I wanted to have same behavior for both UAC1/UAC2, > >>> obviously I've got an utility part (u_audio.c) for > >>> virtual ALSA sound card handling like we have > >>> for ethernet(u_ether) or serial(u_serial) functions. > >>> Function-specific parts (f_uac1/f_uac2) became almost > >>> as storage for class-specific USB descriptors, some > >>> boilerplate for configfs, binding and few USB > >>> config request handling. > >>> > >>> Originally in RFC [1] I've posted before, there was > >>> major change to f_uac1 after that it couldn't do > >>> direct play to existing ALSA sound card anymore, > >>> representing audio on gadget side as virtual > >>> ALSA sound card where audio streams are simply > >>> sinked to and sourced from it, so it may break > >>> current usecase for some people (and that's why > >>> it was RFC). > >>> > >>> During RFC discussion, it was agreed to not touch > >>> existing f_uac1 implementation and create new one > >>> instead. This patchset (v4) introduced new function > >>> named f_uac1_acard and doesn't touch current f_uac1 > >>> implementation, so people still can use old behavior > >> > >> Do you have a pointer to the original RFC discussion where this was > >> discussed? If we really *must* keep the old implementation, I would > >> rather rename that to f_uac1_legacy. Still, I find it unlikely that > >> anybody will care about the old implementation. > > > > It is on LKML (which is down for me) [1] or alternative archive [2] > > > >> > >>> Now, it's possible to use existing user-space > >>> applications for audio routing between Audio Gadget > >>> and real sound card. I personally use alsaloop tool > >>> from alsautils and have ability to create PCM > >>> loopback between two different ALSA cards using > >>> rate resampling, which was not possible with previous > >>> "direct play to ALSA card" approach in f_uac1. > >> > >> this is really good result and will actually make it a lot easier for > >> testing things out. > >> > >>> While here, also dropped redundant platform > >>> driver/device creation in f_uac2 driver (as well as > >>> didn't add "never implemented" volume/mute functionality > >>> in f_uac1 to f_uac1_acard) that made this work even > >>> easier to do. > >>> > >>> This series is tested with both legacy g_audio.ko and > >>> modern configfs approaches under Ubuntu 14.04 (UAC1 and > >>> UAC2) and under Windows7 x64 (UAC1 only) having > >>> perfect results in all cases. > >>> > >>> Comments, testing are welcome. > >>> > >>> v4 changes: > >>> - renamed f_uac1_newapi to f_uac1_acard that is > >>>more meaningful > >> > >> I really don't get why you wanna keep both f_uac1 and f_uac1_acard. Why > >> do we need to maintain the old uac1 implementation? Why two separate > >> files? > > > > In first RFC ([1],[2]) I did exactly what you wrote here (removed > > old uac1 implementation and replaced it by new one) but got feedback > > that it will break things for existing f_uac1 legacy users and it's better > > to > > have separate implementation. > > > > I'm OK with dropping legacy f_uac1 implementation. > > > > Another idea I was thinking about is to implement simple in-kernel > > driver which will do the same as existing alsaloop tool userspace > > tool does (so legacy users will need to load two kernel modules > > and get same functionality). But this seems to be a wrong way, > > since It known that Linux kernel community doesn't like to take drivers > > with same functionality as existing userspace tools already have. > > > > So bottom line: since I'm not a legacy f_uac1 user, there is no > > difference for me how to handle it - remove legacy f_uac1 completely, > > rename it to f_uac1_legacy or add separate f_uac1_acard function. > > > > So if dropping of legacy f_uac1 implementation is OK for you, > > I can do it quickly in next patchset. > > Personally, I don't want duplicated functionality and I think the > virtual sound card approach is much better. Then again, removing > functionality we already support is kind of odd. > > Greg, Alan, what do you guys think? Do we keep a duplicated function > around or do we just tell people to rely on alsaloop? Personally, I > think we're better off with the flexibility of the virtual sound card, > what's your take? If the in-kernel driver will do more things, and we don't break the existing setups using alsaloop, then I don't see the problem, except that we now have to maintain two things :) If you don't mind the maintenance, fine with me... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the
[PATCH v1 1/1] usb:xhci: update condition to select bus->sysdev from parent device
For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA
configuration"), sysdev points to devices known to the system firmware
or hardware for DMA parameters.
However, the parent of the system firmware/hardware device checking
logic does not work in ACPI boot mode. This patch updates the formulation
to check this case in both DT and ACPI.
Signed-off-by: Tung Nguyen
Signed-off-by: Thang Q. Nguyen
---
drivers/usb/host/xhci-plat.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index c04144b..e3e342a 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -187,7 +187,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
* 3. xhci_plat is grandchild of a pci device (dwc3-pci)
*/
sysdev = &pdev->dev;
- if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
+ if (sysdev->parent && (sysdev->fwnode->type == FWNODE_PDATA) &&
+ (is_of_node(sysdev->parent->fwnode) ||
+ is_acpi_device_node(sysdev->parent->fwnode)))
sysdev = sysdev->parent;
#ifdef CONFIG_PCI
else if (sysdev->parent && sysdev->parent->parent &&
--
1.7.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
