Re: USB gadget : generic functionfs function has no os_desc while rndis function has, why?
Thanks, Krysztof. I'm trying to follow your example and maybe to massage it into my need. One quick question - In your example, you set vendor code to be 0xBC. Is this code of any significance? What values should I use? b_vendor_code = 0xBC, Jun On Thu, Jan 4, 2018 at 8:22 AM, Krzysztof Opasiak wrote: > > > On 01/04/2018 06:58 AM, Jun Sun wrote: >> >> Hi, all, >> >> I'm playing with USB gadget with configfs on raspberry pi zero w. My >> goal is to setup a generic functionfs function that uses Windows OS >> descriptor so that windows would automatically install winusb driver. >> It seems I would have to >> >> - enable MS-specific os descriptor >> - specify the compatiblity id to be "WINUSB" >> - specify interface GUID (optional?) >> >> It seems simple enough. > > > You can checkout libusbgx example for a "good" values for RNDIS and expected > directory structure: > > https://github.com/libusbgx/libusbgx/blob/master/examples/gadget-rndis-os-desc.c > >> > >> However, the first problem I'm having is that I can't find the >> os_desc/ directory for the ffs function I created. > > > Because there is no such directory;) > os_desc in case of functionfs are provided by daemon together with USB > descriptors. > > Best regards, > -- > Krzysztof Opasiak > Samsung R&D Institute Poland > Samsung Electronics -- 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
usb: uas : working uas devices ?
Can anyone help me in selecting UASP/UAS device ? Any link/ model no. will be helpful. I could see unusual_uas.h has many devices which are not behaving well so don't want to take risk in selecting. Other then Trancend SSDs because I have that. Want to check on other disks. -- Best Regards, Tushar R Nimkar -- 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/2] usb: chipidea: imx: Fix ULPI on imx53
On Tue, Feb 06, 2018 at 04:50:41PM +0100, Sebastian Reichel wrote:
> Hi Peter,
>
> On Mon, Jan 29, 2018 at 11:33:15AM +0800, Peter Chen wrote:
> > On Wed, Jan 24, 2018 at 06:14:39PM +0100, Sebastian Reichel wrote:
> > > Traditionally, PORTSC should be set before initializing ULPI phys. But
> > > setting PORTSC before powering on the phy results in a kernel freeze
> > > on imx53 based GE PPD. As a workaround this initializes the phy early
> > > in the imx platform code and disables phy power management from the
> > > core.
> > >
> > > Signed-off-by: Fabien Lahoudere
> > > Signed-off-by: Sebastian Reichel
> > > ---
> > > drivers/usb/chipidea/ci_hdrc_imx.c | 12
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
> > > b/drivers/usb/chipidea/ci_hdrc_imx.c
> > > index de155c80eb70..e431c5aafe35 100644
> > > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > > @@ -83,6 +83,7 @@ struct ci_hdrc_imx_data {
> > > struct clk *clk;
> > > struct imx_usbmisc_data *usbmisc_data;
> > > bool supports_runtime_pm;
> > > + bool override_phy_control;
> > > bool in_lpm;
> > > /* SoC before i.mx6 (except imx23/imx28) needs three clks */
> > > bool need_three_clks;
> > > @@ -254,6 +255,7 @@ static int ci_hdrc_imx_probe(struct platform_device
> > > *pdev)
> > > int ret;
> > > const struct of_device_id *of_id;
> > > const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
> > > + struct device_node *np = pdev->dev.of_node;
> > >
> > > of_id = of_match_device(ci_hdrc_imx_dt_ids, &pdev->dev);
> > > if (!of_id)
> > > @@ -288,6 +290,14 @@ static int ci_hdrc_imx_probe(struct platform_device
> > > *pdev)
> > > }
> > >
> > > pdata.usb_phy = data->phy;
> > > +
> > > + if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
> > > + of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
> > > + pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
> > > + data->override_phy_control = true;
> > > + usb_phy_init(pdata.usb_phy);
> > > + }
> > > +
> > > pdata.flags |= imx_platform_flag->flags;
> > > if (pdata.flags & CI_HDRC_SUPPORTS_RUNTIME_PM)
> > > data->supports_runtime_pm = true;
> > > @@ -341,6 +351,8 @@ static int ci_hdrc_imx_remove(struct platform_device
> > > *pdev)
> > > pm_runtime_put_noidle(&pdev->dev);
> > > }
> > > ci_hdrc_remove_device(data->ci_pdev);
> > > + if (data->override_phy_control)
> > > + usb_phy_shutdown(data->phy);
> > > imx_disable_unprepare_clks(&pdev->dev);
> > >
> >
> > Sebastian, I have a question, do you have any USB or generic PHY drivers
> > for ULPI bus, any power controls are needed for your ULPI peripheral?
>
> The devicetree for GE PPD is available in the mainline kernel:
>
> $ grep -A9 "usbphy[23] {" arch/arm/boot/dts/imx53-ppd.dts
> usbphy2: usbphy2 {
> compatible = "usb-nop-xceiv";
> reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
> clock-names = "main_clk";
> clock-frequency = <2400>;
> clocks = <&clks IMX5_CLK_CKO2>;
> assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks
> IMX5_CLK_OSC>;
> assigned-clock-parents = <&clks IMX5_CLK_OSC>;
> };
>
> usbphy3: usbphy3 {
> compatible = "usb-nop-xceiv";
> reset-gpios = <&gpio2 19 GPIO_ACTIVE_LOW>;
> clock-names = "main_clk";
>
> clock-frequency = <2400>;
> clocks = <&clks IMX5_CLK_CKO2>;
> assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks
> IMX5_CLK_OSC>;
> assigned-clock-parents = <&clks IMX5_CLK_OSC>;
> };
>
> So currently the machine only uses drivers/usb/phy/phy-generic.c. Both
> USB phys are actually SMSC USB3315, which is also detected by the kernel:
>
> root@csmon :~# cat /sys/bus/ulpi/devices/ci_hdrc.*.ulpi/uevent
> DEVTYPE=ulpi_device
> MODALIAS=ulpi:v0424p0006
> DEVTYPE=ulpi_device
> MODALIAS=ulpi:v0424p0006
>
> So maybe drivers/usb/phy/phy-ulpi.c should be used, but I don't see
> a simple way to do so and using the generic PHY works.
>
It is correct you use phy-generic.c if it can let your design
work, thanks.
--
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: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
On Tue, Feb 06, 2018 at 07:54:53PM +0100, Herbert Poetzl wrote: > On Tue, Feb 06, 2018 at 07:38:42PM +0200, Mathias Nyman wrote: >> On 01.02.2018 02:43, Herbert Poetzl wrote: >>> On Wed, Jan 31, 2018 at 04:58:58PM +0200, Mathias Nyman wrote: On 30.01.2018 08:06, Herbert Poetzl wrote: > On Mon, Jan 29, 2018 at 02:26:52PM +0200, Mathias Nyman wrote: >> On 20.01.2018 06:20, Herbert Poetzl wrote: >>> I've recently acquired a Gigabyte Z170X Gaming 7-EK motherboard >>> with the Intel Z170 chipset and Sunrise Point-H USB 3.0 xHCI >>> Controller for running Linux. >>> Now most things seem to work fine (some problems with UEFI but >>> that was kind of expected), but the xhci_hcd module is filling >>> up my log files with a repeated message (ever 4 seconds): >>> [ 2137.036187] usb usb2-port1: Cannot enable. Maybe the USB cable is >>> bad? >>> [ 2137.036981] xhci_hcd :00:14.0: Cannot set link state. >>> [ 2137.037767] usb usb2-port1: cannot disable (err = -32) >>> Now I have no idea where usb2-port1 is or why it should have a >>> bad cable, the only USB devices I know of are the USB drive >>> I've booted the system from and the wireless keyboard/mouse >>> combo I'm using. >>> Both seem to work just fine and plugging those into different >>> USB ports doesn't change the message. >>> Bus 002 Device 002: ID 1b1c:1a00 Corsair >>> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub >>> Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver >>> Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd >>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Note: I have no idea what the Hitachi device is. >>> The current kernel is 4.14.13 (from Mageia 6). >>> Any idea what the problem here is and how I can fix or work >>> around it? >>> Please let me know if you need any additional information on >>> the system or environment. >> lsusb -v could show more details about the misbehaving device. >> Output of dmesg could tell something as well > During testing I found out that there is a correlation between > the BIOS and the observed error. > When I unplug the power supply for a few seconds, the problem > will completely disappear until the next time I enter the BIOS > and change something there (doesn't matter what and doesn't > affect the result). > It also seems to be related to the 'mystical' Hitachi device > I couldn't figure out what it is for or why it sits on each > USB bus. > You can find all the suggested output here ... > http://vserver.13thfloor.at/Stuff/XHCI_HCD/ > where 'failing' means that the problem is present and 'working' > means that everything seems fine. The Hitachi device is a built-in USB3 HUB, (USB3 so it supports both USB2 and USB3 sides) >>> I wasn't able to find the USB ID online and the Linux >>> USB ID database only seems to know the vendor not the >>> device IDs ... In the failing case the USB3 side of the hub doesn't properly finish reset, and gets stuck in a retry loop. It's possible that we keep retrying a warm reset even if device would require something else to reset it properly(normal reset, or disable device in between) >>> Well, I'm currently testing on that platform, so it >>> would be easy for me to try some patches for that ... >> Does reverting >> 37be6676 usb: hub: Fix auto-remount of safely removed or >> ejected USB-3 devices >> help? > Hmm, I did find 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 for > 4.9 and earlier but nothing which would revert cleanly for > 4.14.13 or later ... > Could you provide a hint how I can revert it easily for > 4.14.17 or 4.15.1? > Thanks in advance, > Herbert >> After reverting it the port should be disabled and re-enabled >> after a few unsuccessful port resets, and hopefully start >> working again. Following up on that, I did test with linux-4.9.0 without the patch and with the patch applied, but in both cases the result is the same: no error message and no second Hitachi HUB visible in lsusb. Rebooting to 4.14.13 brings back the error loop. Hope this helps, Herbert >> -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WebUSB - USB gadget] Prevent CDC-ACM from loading serial interface
On Wed, Feb 07, 2018 at 12:05:04AM +0100, Alberto Esposito wrote: > Thank you Greg for your reply :) it's such an honor to speak with you :) > > > You could, but then you would not be a cdc-acm device, right? > > that would not be a problem. I just need to send and receive data > between my usb gadget and chrome. Then don't lie to the operating system and say you are a cdc-acm device, and all will be fine. > >Why not just disconnect the driver from the device when you want to grab > > it instead? You can do that in userspace just fine, and I think libusb > > even has a function for it. > > That's what I did to test that everything was working on the device side. > > I would prefer that the user wouldn't have to install/do anything to > make it work. > > USB should be plug and play, WebUSB even more so. Surely webusb has an interface to disconnect the OS driver from the requested device? If not, then it needs to add that, for the obvious reasons you are having. > > I thought that was what webusb did already, odd that it's not working > > for you. Have you tried talking to the webusb developers for the > > browser you are using? > > the motivation behind this is that WebUSB should help support new > devices, not devices already in use by the OS. Then don't create a new device that the OS will always grab, because it is advertising itself as a device the OS knows about :) > If I could trick the OS not to load the device, then WebUSB would work > without modifications. No "trick" needed, either have webusb disconnect the driver from the device, or change your device to not have the OS bind a driver to it. good luck! greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WebUSB - USB gadget] Prevent CDC-ACM from loading serial interface
Thank you Greg for your reply :) it's such an honor to speak with you :) > You could, but then you would not be a cdc-acm device, right? that would not be a problem. I just need to send and receive data between my usb gadget and chrome. >Why not just disconnect the driver from the device when you want to grab > it instead? You can do that in userspace just fine, and I think libusb > even has a function for it. That's what I did to test that everything was working on the device side. I would prefer that the user wouldn't have to install/do anything to make it work. USB should be plug and play, WebUSB even more so. > I thought that was what webusb did already, odd that it's not working > for you. Have you tried talking to the webusb developers for the > browser you are using? the motivation behind this is that WebUSB should help support new devices, not devices already in use by the OS. If I could trick the OS not to load the device, then WebUSB would work without modifications. On Tue, Feb 6, 2018 at 11:41 PM, Greg KH wrote: > On Tue, Feb 06, 2018 at 11:31:40PM +0100, Alberto Esposito wrote: >> Hello everybody! >> >> I'm trying to connect to a serial interface created with usb gadget >> driver via WebUSB. >> >> I was successful in setting up the serial interface, but WebUSB >> refuses to work because it can't claim the interface, since it's busy. >> >> The culprit is the cdc-acm driver, which correctly see the interface >> and claims it first. >> >> How can I prevent the cdc-acm driver from claiming the interface, >> without modifications to the client? > > Sorry, you can't. > >> Can I change the interface descriptors somehow, so that cdc-acm >> doesn't recognize the device anymore? > > You could, but then you would not be a cdc-acm device, right? > >> Or maybe I have to create a new device type in the usb gadget driver, >> to cover this specific case? > > Why not just disconnect the driver from the device when you want to grab > it instead? You can do that in userspace just fine, and I think libusb > even has a function for it. > > I thought that was what webusb did already, odd that it's not working > for you. Have you tried talking to the webusb developers for the > browser you are using? > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WebUSB - USB gadget] Prevent CDC-ACM from loading serial interface
On Tue, Feb 06, 2018 at 11:31:40PM +0100, Alberto Esposito wrote: > Hello everybody! > > I'm trying to connect to a serial interface created with usb gadget > driver via WebUSB. > > I was successful in setting up the serial interface, but WebUSB > refuses to work because it can't claim the interface, since it's busy. > > The culprit is the cdc-acm driver, which correctly see the interface > and claims it first. > > How can I prevent the cdc-acm driver from claiming the interface, > without modifications to the client? Sorry, you can't. > Can I change the interface descriptors somehow, so that cdc-acm > doesn't recognize the device anymore? You could, but then you would not be a cdc-acm device, right? > Or maybe I have to create a new device type in the usb gadget driver, > to cover this specific case? Why not just disconnect the driver from the device when you want to grab it instead? You can do that in userspace just fine, and I think libusb even has a function for it. I thought that was what webusb did already, odd that it's not working for you. Have you tried talking to the webusb developers for the browser you are using? 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
[WebUSB - USB gadget] Prevent CDC-ACM from loading serial interface
Hello everybody! I'm trying to connect to a serial interface created with usb gadget driver via WebUSB. I was successful in setting up the serial interface, but WebUSB refuses to work because it can't claim the interface, since it's busy. The culprit is the cdc-acm driver, which correctly see the interface and claims it first. How can I prevent the cdc-acm driver from claiming the interface, without modifications to the client? Can I change the interface descriptors somehow, so that cdc-acm doesn't recognize the device anymore? Or maybe I have to create a new device type in the usb gadget driver, to cover this specific case? Best Regards Alberto E. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] uas: regression preventing some drives from being used
Hi, I use two hard drives in an enclosure connected to my PC using UAS. The enclosure is a JMicron JMS56x (152d:0562); the drives are a Fujitsu MHZ2160BH G2 (2"5, 160GB) and a Western Digital EFRX-68N32N0 (3"5, 4TB). Using a USB2 port, I can see both drives as expected. I used to be able to use both drives using a USB3 port (and UAS) in Linux 4.11 and 4.12, but I am experiencing a bug with Linux 4.14.13. When I plug the USB cable, I can see the following output in dmesg: [Tue Feb 6 22:17:49 2018] usb 4-2: new SuperSpeed USB device number 10 using xhci_hcd [Tue Feb 6 22:17:49 2018] usb 4-2: New USB device found, idVendor=152d, idProduct=0562 [Tue Feb 6 22:17:49 2018] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [Tue Feb 6 22:17:49 2018] usb 4-2: Product: JMS56x Series [Tue Feb 6 22:17:49 2018] usb 4-2: Manufacturer: JMicron [Tue Feb 6 22:17:49 2018] usb 4-2: SerialNumber: RANDOM__8A4D7F833EEF [Tue Feb 6 22:17:49 2018] scsi host6: uas [Tue Feb 6 22:17:50 2018] scsi 6:0:0:0: Direct-Access FUJITSU MHZ2160BH G2 0104 PQ: 0 ANSI: 6 [Tue Feb 6 22:17:50 2018] scsi 6:0:0:1: Direct-Access WDC WD40 EFRX-68N32N0 0104 PQ: 0 ANSI: 6 [Tue Feb 6 22:17:50 2018] sd 6:0:0:0: Attached scsi generic sg2 type 0 [Tue Feb 6 22:17:50 2018] sd 6:0:0:1: Attached scsi generic sg3 type 0 [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB) [Tue Feb 6 22:17:57 2018] sd 6:0:0:1: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] Write Protect is off [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] Mode Sense: 67 00 10 08 [Tue Feb 6 22:17:57 2018] sd 6:0:0:1: [sdc] Write Protect is off [Tue Feb 6 22:17:57 2018] sd 6:0:0:1: [sdc] Mode Sense: 67 00 10 08 [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA [Tue Feb 6 22:17:57 2018] sd 6:0:0:1: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA [Tue Feb 6 22:17:57 2018] sdb: sdb1 [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] Attached SCSI disk [Tue Feb 6 22:18:27 2018] sd 6:0:0:1: tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: IN [Tue Feb 6 22:18:27 2018] sd 6:0:0:1: tag#1 CDB: Inquiry 12 01 00 00 40 00 [Tue Feb 6 22:18:27 2018] scsi host6: uas_eh_device_reset_handler start [Tue Feb 6 22:18:28 2018] usb 4-2: reset SuperSpeed USB device number 10 using xhci_hcd [Tue Feb 6 22:18:28 2018] usb 4-2: device firmware changed [Tue Feb 6 22:18:28 2018] scsi host6: uas_post_reset: alloc streams error -19 after reset [Tue Feb 6 22:18:28 2018] usb 4-2: USB disconnect, device number 10 [Tue Feb 6 22:20:29 2018] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1 [Tue Feb 6 22:20:29 2018] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1 [Tue Feb 6 22:20:29 2018] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [Tue Feb 6 22:20:30 2018] INFO: task kworker/0:3:191 blocked for more than 120 seconds. [Tue Feb 6 22:20:30 2018] Not tainted 4.14.0-3-amd64 #1 Debian 4.14.13-1 [Tue Feb 6 22:20:30 2018] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [Tue Feb 6 22:20:30 2018] kworker/0:3 D0 191 2 0x8000 [Tue Feb 6 22:20:30 2018] Workqueue: usb_hub_wq hub_event [usbcore] [Tue Feb 6 22:20:30 2018] Call Trace: [Tue Feb 6 22:20:30 2018] ? __schedule+0x28e/0x880 [Tue Feb 6 22:20:30 2018] schedule+0x28/0x80 [Tue Feb 6 22:20:30 2018] schedule_preempt_disabled+0xa/0x10 [Tue Feb 6 22:20:30 2018] __mutex_lock.isra.1+0x1a0/0x4e0 [Tue Feb 6 22:20:30 2018] ? _dev_info+0x64/0x80 [Tue Feb 6 22:20:30 2018] ? usb_disconnect+0x57/0x260 [usbcore] [Tue Feb 6 22:20:30 2018] usb_disconnect+0x57/0x260 [usbcore] [Tue Feb 6 22:20:30 2018] hub_event+0x52b/0x15d0 [usbcore] [Tue Feb 6 22:20:30 2018] process_one_work+0x185/0x380 [Tue Feb 6 22:20:30 2018] worker_thread+0x2e/0x390 [Tue Feb 6 22:20:30 2018] ? process_one_work+0x380/0x380 [Tue Feb 6 22:20:30 2018] kthread+0x118/0x130 [Tue Feb 6 22:20:30 2018] ? kthread_create_on_node+0x70/0x70 [Tue Feb 6 22:20:30 2018] ret_from_fork+0x1f/0x30 [Tue Feb 6 22:20:30 2018] INFO: task scsi_eh_6:9856 blocked for more than 120 seconds. [Tue Feb 6 22:20:30 2018] Not tainted 4.14.0-3-amd64 #1 Debian 4.14.13-1 [Tue Feb 6 22:20:30 2018] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [Tue Feb 6 22:20:30 2018] scsi_eh_6 D0 9856 2 0x8000 [Tue Feb 6 22:20:30 2018] Call Trace: [Tue Feb 6 22:20:30 2018] ? __schedule+0x28e/0x880 [Tue Feb 6 22:20:30 2018] schedule+0x28/0x80 [Tue Feb 6 22:20:30 2018] async_synchronize_cookie_domain+0x96/0x140 [Tue Feb 6 22:20:30 2018] ? finish_wait+0x80/0x80 [Tue Feb 6 22:20:30 2018] sd_remove+0x48/0xc0 [sd_mod] [Tue Feb 6 22:20:30 2018] device_release_driver_internal+0x157/0x210 [Tue Feb 6 22:20:30 2018] bus_remove_device+0xe2/0x150 [Tue Feb 6 22:20:30 2018] device_del+0x1c9/0x340 [Tu
Re: [PATCH] usb: musb: fix enumeration after resume
Hi, On Tue, 6 Feb 2018 10:47:25 -0800 Tony Lindgren wrote: > * Andreas Kemnade [180127 08:34]: > > On dm3730 there are enumeration problems after resume. > > Investigation led to the cause that the MUSB_POWER_SOFTCONN > > bit is not set. If it was set before suspend (because it > > was enabled via musb_pullup()), it is set in > > musb_restore_context() so the pullup is enabled. But then > > musb_start() is called which overwrites MUSB_POWER and > > therefore disables MUSB_POWER_SOFTCONN, so no pullup is > > enabled and the device is not enumerated. > > I just gave this patch a quick try and things seem to behave > for me from PM point of view: > > Tested-by: Tony Lindgren > > Unrelated to this patch, I also noticed that we now somehow > higher idle power consumption initially when musb modules are > loaded. It used to idle after that but now to get things to > idle I had to plug and unplug a USB device once to the musb > port. > Hmm, I have seen this effect with some earlier kernels but not with 4.15. My observation is that current consumption went down again after a modprobe g_ether and ifconfig usb0 up I was loading modules piece by piece and waited 10s after each and then measured. Regards, Andreas pgpeNyIHRI9k7.pgp Description: OpenPGP digital signature
Re: [PATCH] usb: musb: fix enumeration after resume
Hi,
On Tue, 6 Feb 2018 12:46:05 -0600
Bin Liu wrote:
> Hi,
>
> On Sat, Jan 27, 2018 at 09:34:03AM +0100, Andreas Kemnade wrote:
> > On dm3730 there are enumeration problems after resume.
> > Investigation led to the cause that the MUSB_POWER_SOFTCONN
> > bit is not set. If it was set before suspend (because it
> > was enabled via musb_pullup()), it is set in
> > musb_restore_context() so the pullup is enabled. But then
> > musb_start() is called which overwrites MUSB_POWER and
> > therefore disables MUSB_POWER_SOFTCONN, so no pullup is
> > enabled and the device is not enumerated.
>
> Do you see the issue with the v4.15?
>
Yes. Tested without other patches.
It was also there in earlier kernels but I had not had motivation enough
to debug.
So maybe it deserves a CC: Stable
> > So let's do a subset of what musb_start() does
> > in the same way as musb_suspend() does it. Platform-specific
> > stuff it still called as there might be some phy-related stuff
> > which needs to be enabled.
> > Also interrupts are enabled, as it was the original idea
> > of calling musb_start() in musb_resume() according to
> > Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend,
> > enable them on resume")
>
> The logic in the fix makes sense, and I do see the same problem with
> AM335x on v4.9 kernel, but it doesn't happen on v4.15. I haven't checked
> if there is anything after musb_start() which sets MUSB_POWER_SOFTCON
> bit.
>
Well reconfiguring gadget from userspace helps.
Regards,
Andreas
pgpg045RDPWAb.pgp
Description: OpenPGP digital signature
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
On Tue, Feb 06, 2018 at 07:38:42PM +0200, Mathias Nyman wrote: > On 01.02.2018 02:43, Herbert Poetzl wrote: >> On Wed, Jan 31, 2018 at 04:58:58PM +0200, Mathias Nyman wrote: >>> On 30.01.2018 08:06, Herbert Poetzl wrote: On Mon, Jan 29, 2018 at 02:26:52PM +0200, Mathias Nyman wrote: > On 20.01.2018 06:20, Herbert Poetzl wrote: >> I've recently acquired a Gigabyte Z170X Gaming 7-EK motherboard >> with the Intel Z170 chipset and Sunrise Point-H USB 3.0 xHCI >> Controller for running Linux. >> Now most things seem to work fine (some problems with UEFI but >> that was kind of expected), but the xhci_hcd module is filling >> up my log files with a repeated message (ever 4 seconds): >> [ 2137.036187] usb usb2-port1: Cannot enable. Maybe the USB cable is >> bad? >> [ 2137.036981] xhci_hcd :00:14.0: Cannot set link state. >> [ 2137.037767] usb usb2-port1: cannot disable (err = -32) >> Now I have no idea where usb2-port1 is or why it should have a >> bad cable, the only USB devices I know of are the USB drive >> I've booted the system from and the wireless keyboard/mouse >> combo I'm using. >> Both seem to work just fine and plugging those into different >> USB ports doesn't change the message. >> Bus 002 Device 002: ID 1b1c:1a00 Corsair >> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub >> Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver >> Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Note: I have no idea what the Hitachi device is. >> The current kernel is 4.14.13 (from Mageia 6). >> Any idea what the problem here is and how I can fix or work >> around it? >> Please let me know if you need any additional information on >> the system or environment. > lsusb -v could show more details about the misbehaving device. > Output of dmesg could tell something as well During testing I found out that there is a correlation between the BIOS and the observed error. When I unplug the power supply for a few seconds, the problem will completely disappear until the next time I enter the BIOS and change something there (doesn't matter what and doesn't affect the result). It also seems to be related to the 'mystical' Hitachi device I couldn't figure out what it is for or why it sits on each USB bus. You can find all the suggested output here ... http://vserver.13thfloor.at/Stuff/XHCI_HCD/ where 'failing' means that the problem is present and 'working' means that everything seems fine. >>> The Hitachi device is a built-in USB3 HUB, (USB3 so it supports >>> both USB2 and USB3 sides) >> I wasn't able to find the USB ID online and the Linux >> USB ID database only seems to know the vendor not the >> device IDs ... >>> In the failing case the USB3 side of the hub doesn't properly >>> finish reset, and gets stuck in a retry loop. >>> It's possible that we keep retrying a warm reset even if device >>> would require something else to reset it properly(normal reset, >>> or disable device in between) >> Well, I'm currently testing on that platform, so it >> would be easy for me to try some patches for that ... > Does reverting > 37be6676 usb: hub: Fix auto-remount of safely removed or > ejected USB-3 devices > help? Hmm, I did find 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 for 4.9 and earlier but nothing which would revert cleanly for 4.14.13 or later ... Could you provide a hint how I can revert it easily for 4.14.17 or 4.15.1? Thanks in advance, Herbert > After reverting it the port should be disabled and re-enabled > after a few unsuccessful port resets, and hopefully start > working again. > -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: fix enumeration after resume
* Andreas Kemnade [180127 08:34]: > On dm3730 there are enumeration problems after resume. > Investigation led to the cause that the MUSB_POWER_SOFTCONN > bit is not set. If it was set before suspend (because it > was enabled via musb_pullup()), it is set in > musb_restore_context() so the pullup is enabled. But then > musb_start() is called which overwrites MUSB_POWER and > therefore disables MUSB_POWER_SOFTCONN, so no pullup is > enabled and the device is not enumerated. I just gave this patch a quick try and things seem to behave for me from PM point of view: Tested-by: Tony Lindgren Unrelated to this patch, I also noticed that we now somehow higher idle power consumption initially when musb modules are loaded. It used to idle after that but now to get things to idle I had to plug and unplug a USB device once to the musb port. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: fix enumeration after resume
Hi,
On Sat, Jan 27, 2018 at 09:34:03AM +0100, Andreas Kemnade wrote:
> On dm3730 there are enumeration problems after resume.
> Investigation led to the cause that the MUSB_POWER_SOFTCONN
> bit is not set. If it was set before suspend (because it
> was enabled via musb_pullup()), it is set in
> musb_restore_context() so the pullup is enabled. But then
> musb_start() is called which overwrites MUSB_POWER and
> therefore disables MUSB_POWER_SOFTCONN, so no pullup is
> enabled and the device is not enumerated.
Do you see the issue with the v4.15?
> So let's do a subset of what musb_start() does
> in the same way as musb_suspend() does it. Platform-specific
> stuff it still called as there might be some phy-related stuff
> which needs to be enabled.
> Also interrupts are enabled, as it was the original idea
> of calling musb_start() in musb_resume() according to
> Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend,
> enable them on resume")
The logic in the fix makes sense, and I do see the same problem with
AM335x on v4.9 kernel, but it doesn't happen on v4.15. I haven't checked
if there is anything after musb_start() which sets MUSB_POWER_SOFTCON
bit.
Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: power management problems in ehci-omap
On Tue, 6 Feb 2018 10:16:23 -0800 Tony Lindgren wrote: > * Andreas Kemnade [180206 18:04]: > > On Tue, 6 Feb 2018 09:17:37 -0800 > > Tony Lindgren wrote: > > > uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null) > > > for uart in $uarts; do > > > echo enabled > $uart/wakeup 2>&1 > > > echo auto > $uart/control 2>&1 > > > done > > > > > > > hmm, this looks a bit like runtime suspend. > > Not only that, it enables wakeup for UART also for suspend :) > We are using the rtc for wakeup and measure discharge of battery for a time frame of about 300 seconds. > That is if your dts has it configured with interrupts-extended > for the console UART like omap3-beagle-xm.dts has for example. > Seems like the gta04 dts don't have these.. And you also want > to have chosen with stdout-path = &uart3 or whatever the debug > UART is for earlycon to work. > > > I mean suspend aka echo mem >/sys/power/state > > > > > echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > And the above will enable SoC and PMIC off modes, which will also > take the suspend power to some much much lower value :) You need > to configure the PMIC too depending if the oscillator can be turned > off, in that case set "ti,twl4030-power-idle-osc-off". That too > seems to be missing in gta04 dts files.. > It was in our tree. It can be enabled for the gta04a5. We have even done that. But then suspend while charging breaks. I have no idea how to do a proper if-not-charging-power-idle-osc-off patch... Yes there are other places where we can optimize suspend current. But lets first find out why ehci-omap seems to cause trouble here. So we are looking for around 15mA of additional suspend current when the module is loaded. Shouldn't the reset line of the phy (usb-nop-xceiv) be set to low when going to suspend? I do not see code how to do it. I guess that is the reason. BTW: root@letux:~# cat /sys/bus/platform/devices/48064800.ehci/power/runtime_status active Regards, Andreas pgpnLxDAY7Lsv.pgp Description: OpenPGP digital signature
Re: power management problems in ehci-omap
* Andreas Kemnade [180206 18:04]: > On Tue, 6 Feb 2018 09:17:37 -0800 > Tony Lindgren wrote: > > uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null) > > for uart in $uarts; do > > echo enabled > $uart/wakeup 2>&1 > > echo auto > $uart/control 2>&1 > > done > > > > hmm, this looks a bit like runtime suspend. Not only that, it enables wakeup for UART also for suspend :) That is if your dts has it configured with interrupts-extended for the console UART like omap3-beagle-xm.dts has for example. Seems like the gta04 dts don't have these.. And you also want to have chosen with stdout-path = &uart3 or whatever the debug UART is for earlycon to work. > I mean suspend aka echo mem >/sys/power/state > > > echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode And the above will enable SoC and PMIC off modes, which will also take the suspend power to some much much lower value :) You need to configure the PMIC too depending if the oscillator can be turned off, in that case set "ti,twl4030-power-idle-osc-off". That too seems to be missing in gta04 dts files.. Regards, Tony -- 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
xhci_hcd: kernel 4.15.1 oops on suspend to ram
I'm running archlinux on a Dell XPS15 9550 and I connect it to a TB16 thunderbolt dock. Connected to the dock I have a 4k external display and a USB logitech transmitter for my wireless keyboard and mouse. The module 'xhci_pci' is automatically unloaded/reloaded on suspend/resume to make the TB16 dock work properly across suspend/resume cycles. Yesterday, I updated my kernel from 4.14.16 to 4.15.1 and now I get a kernel oops on suspend. I can replicate the oops every time: boot computer, connect to thunderbolt dock, suspend. I managed to get some logs of the kernel oops from EFI pstore. Find attached with this email. Jose <6>[4.237730] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) <6>[4.247641] input: HDA Intel PCH Headphone Mic as /devices/pci:00/:00:1f.3/sound/card0/input21 <6>[4.247691] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1f.3/sound/card0/input22 <6>[4.247730] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci:00/:00:1f.3/sound/card0/input23 <6>[4.247759] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1f.3/sound/card0/input24 <6>[4.247798] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci:00/:00:1f.3/sound/card0/input25 <6>[4.247825] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci:00/:00:1f.3/sound/card0/input26 <6>[4.259200] iwlwifi :02:00.0: base HW address: e4:a4:71:1e:b9:cd <6>[4.262652] intel_rapl: Found RAPL domain package <6>[4.262653] intel_rapl: Found RAPL domain core <6>[4.262654] intel_rapl: Found RAPL domain uncore <6>[4.262654] intel_rapl: Found RAPL domain dram <7>[4.334572] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' <4>[4.334739] (NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info(). <4>[4.334749] thermal thermal_zone11: failed to read out thermal zone (-61) <6>[4.557361] bbswitch: version 0.8 <6>[4.557364] bbswitch: Found integrated VGA device :00:02.0: \_SB_.PCI0.GFX0 <6>[4.557368] bbswitch: Found discrete VGA device :01:00.0: \_SB_.PCI0.PEG0.PEGP <4>[4.557374] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20170831/nsarguments-100) <6>[4.557433] bbswitch: detected an Optimus _DSM function <6>[4.583372] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 <6>[4.583372] Bluetooth: BNEP filters: protocol multicast <6>[4.583374] Bluetooth: BNEP socket layer initialized <6>[4.637286] nf_conntrack version 0.5.0 (65536 buckets, 262144 max) <6>[4.776757] pci :01:00.0: enabling device ( -> 0003) <6>[4.776827] bbswitch: Succesfully loaded. Discrete card :01:00.0 is on <6>[4.778171] bbswitch: disabling discrete graphics <6>[5.244795] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready <6>[5.513747] Bluetooth: hci0: Waiting for firmware download to complete <6>[5.514365] Bluetooth: hci0: Firmware loaded in 1395998 usecs <6>[5.514389] Bluetooth: hci0: Waiting for device to boot <6>[5.525401] Bluetooth: hci0: Device booted in 10763 usecs <6>[5.525548] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc <6>[5.529421] Bluetooth: hci0: Applying Intel DDC parameters completed <6>[6.826160] fuse init (API version 7.26) <6>[ 11.247153] Bluetooth: RFCOMM TTY layer initialized <6>[ 11.247178] Bluetooth: RFCOMM socket layer initialized <6>[ 11.247187] Bluetooth: RFCOMM ver 1.11 <3>[ 409.618986] ACPI Error: [SPRT] Namespace lookup failure, AE_ALREADY_EXISTS (20170831/dswload2-346) <3>[ 409.619005] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170831/psobject-252) <3>[ 409.619014] ACPI Error: Method parse/execution failed \_GPE._E42, AE_ALREADY_EXISTS (20170831/psparse-550) <3>[ 409.619028] ACPI Error: Method parse/execution failed \_GPE._E42, AE_ALREADY_EXISTS (20170831/psparse-550) <3>[ 409.619046] ACPI Exception: AE_ALREADY_EXISTS, while evaluating GPE method [_E42] (20170831/evgpe-646) <7>[ 409.743848] pci :06:00.0: [8086:1576] type 01 class 0x060400 <6>[ 409.743918] pci :06:00.0: enabling Extended Tags <7>[ 409.744011] pci :06:00.0: supports D1 D2 <7>[ 409.744014] pci :06:00.0: PME# supported from D0 D1 D2 D3hot D3cold <7>[ 409.744367] pci :07:00.0: [8086:1576] type 01 class 0x060400 <6>[ 409.70] pci :07:00.0: enabling Extended Tags <7>[ 409.744545] pci :07:00.0: supports D1 D2 <7>[ 409.744547] pci :07:00.0: PME# supported from D0 D1 D2 D3hot D3cold <7>[ 409.744673] pci :07:01.0: [8086:1576] type 01 class 0x060400 <6>[ 409.744742] pci :07:01.0: enabling Extended Tags <7>[ 409.744833] pci :07:01.0: supports D1 D2 <7>[ 409.744836] pci :07:01.0: PME# supported from D0 D1 D2 D3hot D3cold <7>[ 409.744943] pci :07:02.0: [8086:1576] type 01 class 0x060400 <6>[ 409.745646] pci :07:02.0: enabling
Re: power management problems in ehci-omap
On Tue, 6 Feb 2018 09:17:37 -0800 Tony Lindgren wrote: > * Andreas Kemnade [180206 16:56]: > > On Tue, 6 Feb 2018 08:04:52 -0800 > > Tony Lindgren wrote: > > > > > * Andreas Kemnade [180206 06:42]: > > > > rechecked with a board with really nothing connected there > > > > Same behaviour > > > > > > I've just verified that my test board power consumption goes > > > back to normal after rmmod ehci-omap with v4.15. > > > > > yes, for me too, I initially used a test script which does an > > echo rmmod ehci-omap > > > > without a real > > rmmod ehci-omap > > Ah OK :) > > > It just seems to be consistent with my observations in a fully booted > > system (where many things can play a role). Sorry for that confusion. > > Try with a minimal set of modules first, then modprobe and rmmod one > at a time until you find the module breaking PM? > Yes, that is basically what I do with this script: https://misc.andi.de1.cc/measure4.sh and https://misc.andi.de1.cc/measure5.sh I start from a bare kernel, check currents, load ehci-omap (I have also debugged many other pm things that way) check currents again. But since my rough observations with a fully loaded system seem to match with the echo rmmod behaviour, I did not notice my mistake. > You probably know this already, but just in case it helps.. > > First idle the UARTs and enable off mode with something like: > > uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d) > for uart in $uarts; do > echo 3000 > $uart/autosuspend_delay_ms 2>&1 > done > > uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null) > for uart in $uarts; do > echo enabled > $uart/wakeup 2>&1 > echo auto > $uart/control 2>&1 > done > hmm, this looks a bit like runtime suspend. I mean suspend aka echo mem >/sys/power/state > echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode > In earlier times this just caused trouble and a little lower current, maybe it is time to check again. > Then if using omap3, the attached debug hack patch can be used to > see which devices are not idling: > Yes, I will try out. It it about detecting whether the soc itself went into low power mode. But it does not check e.g. whether the phy is put into low power mode correctly. So ehci-usb in soc might be powered off and phy is still on. When I go to suspend, I get this message: "Successfully put all powerdomains to target state" @Nikolaus: Can you check IR at the end of the suspend time in https://misc.andi.de1.cc/measure5.sh the second suspend compared with the first whether the phy (the USB 2233) stays on. Regards, Andreas pgp3UOYw4KlKp.pgp Description: OpenPGP digital signature
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
On 01.02.2018 02:43, Herbert Poetzl wrote: On Wed, Jan 31, 2018 at 04:58:58PM +0200, Mathias Nyman wrote: On 30.01.2018 08:06, Herbert Poetzl wrote: On Mon, Jan 29, 2018 at 02:26:52PM +0200, Mathias Nyman wrote: On 20.01.2018 06:20, Herbert Poetzl wrote: I've recently acquired a Gigabyte Z170X Gaming 7-EK motherboard with the Intel Z170 chipset and Sunrise Point-H USB 3.0 xHCI Controller for running Linux. Now most things seem to work fine (some problems with UEFI but that was kind of expected), but the xhci_hcd module is filling up my log files with a repeated message (ever 4 seconds): [ 2137.036187] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 2137.036981] xhci_hcd :00:14.0: Cannot set link state. [ 2137.037767] usb usb2-port1: cannot disable (err = -32) Now I have no idea where usb2-port1 is or why it should have a bad cable, the only USB devices I know of are the USB drive I've booted the system from and the wireless keyboard/mouse combo I'm using. Both seem to work just fine and plugging those into different USB ports doesn't change the message. Bus 002 Device 002: ID 1b1c:1a00 Corsair Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Note: I have no idea what the Hitachi device is. The current kernel is 4.14.13 (from Mageia 6). Any idea what the problem here is and how I can fix or work around it? Please let me know if you need any additional information on the system or environment. lsusb -v could show more details about the misbehaving device. Output of dmesg could tell something as well During testing I found out that there is a correlation between the BIOS and the observed error. When I unplug the power supply for a few seconds, the problem will completely disappear until the next time I enter the BIOS and change something there (doesn't matter what and doesn't affect the result). It also seems to be related to the 'mystical' Hitachi device I couldn't figure out what it is for or why it sits on each USB bus. You can find all the suggested output here ... http://vserver.13thfloor.at/Stuff/XHCI_HCD/ where 'failing' means that the problem is present and 'working' means that everything seems fine. The Hitachi device is a built-in USB3 HUB, (USB3 so it supports both USB2 and USB3 sides) I wasn't able to find the USB ID online and the Linux USB ID database only seems to know the vendor not the device IDs ... In the failing case the USB3 side of the hub doesn't properly finish reset, and gets stuck in a retry loop. It's possible that we keep retrying a warm reset even if device would require something else to reset it properly(normal reset, or disable device in between) Well, I'm currently testing on that platform, so it would be easy for me to try some patches for that ... Does reverting 37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices help? After reverting it the port should be disabled and re-enabled after a few unsuccessful port resets, and hopefully start working again. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] SD card reader disappears after suspend
On 29.01.2018 16:24, Mathias Nyman wrote: On 25.01.2018 17:51, Alan Stern wrote: On Thu, 25 Jan 2018, Samuel Sadok wrote: 2018-01-23 17:31 GMT+01:00 Alan Stern : On Tue, 23 Jan 2018, Samuel Sadok wrote: Thanks Alan, While I was at it I also enabled debug logs for xhci_hcd and xhci_pci. $ echo module usbcore =p > /sys/kernel/debug/dynamic_debug/control $ echo module xhci_hcd =p > /sys/kernel/debug/dynamic_debug/control $ echo module xhci_pci =p > /sys/kernel/debug/dynamic_debug/control $ modprobe usbmon $ cat /sys/kernel/debug/usb/usbmon/0u > /tmp/usbmon.log $ # press power button dmesg: https://gist.github.com/anonymous/29b81574abf40605f999cfeefe98e341 usbmon: https://gist.github.com/anonymous/55b6d9bbf8b8c8627230b10d2b09dcb6 Both logs were collected at the same time so the timestamps should match. In fact they do, quite closely. But there is a noticeable gap in the usbmon trace, between lines 197 and 198 (the timestamp jumps from 35923531 to 38925126) and there obviously was a lot of activity on bus 1 in between. Yes you're right, that's inconvenient because the "failed to disable LTM" message occurs exactly in this gap. Are gaps like this expected / known? Any ideas on how to mitigate them? (I kinda want to avoid soldering an external bus monitor to the mainboard :) ) The text interface to usbmon uses a fixed-size buffer, and the size is a little on the low side if you're dealing with large latencies (which of course are unavoidable during a suspend/resume scenario). The size is determined by EVENT_MAX, defined around line 40 in drivers/usb/mon/mon_text.c: #define EVENT_MAX (4*PAGE_SIZE / sizeof(struct mon_event_text)) Just change the 4 to something considerably larger and you should be in good shape. Resume starts at dmesg line 1255. As far as I can judge, the earliest indication of something going wrong is line 1514: [ 36.087176] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with unaddressed device [ 36.087180] usb 2-4: Disable of device-initiated U1 failed. [ 36.087212] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with unaddressed device [ 36.087224] usb 2-4: Disable of device-initiated U2 failed. [ 36.087226] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with unaddressed device [ 36.087227] usb 2-4: usb_reset_and_verify_device Failed to disable LTM Yes, that's where the problem first seems to show up. Apparently usb_disable_ltm() fails because it can't communicate with the device, and usb_reset_and_verify_device() then aborts because of that failure. It shouldn't do this; after all, one very good reason for resetting the device is because we're unable to communicate with it. You could try editing the source code for usb_reset_and_verify_device() in drivers/usb/core/hub.c, to see what happens if it doesn't give up after usb_disable_ltm() fails. For the following logs I modified the "Failed to disable LTM" message and commented out the goto in the line below. Also I used kernel version 4.15-rc9 this time. I omitted upgrading the out-of-tree modules broadcom-wl and nouveau-fw, so don't mind errors related to that. The SD card reader is still missing after resume. dmesg & usbmon: https://gist.github.com/anonymous/fc597612d5ebbac40d7bef9f8f0b579a `usb_reset_and_verify_device()` is executed around dmesg line 1524. Again, the usbmon log has a major gap around that time. It looks like the system is trying to carry out multiple warm resets, or a single extremely long warm reset, when it really should give up and do a cold reset instead. It would be best to get Mathias's input on this. I don't know what is the right way to fix this problem. Alan Stern Just back form a week long sickleave, sorry about the delay. First glance it looks like we end up in compliance mode a lot during those warm resets. I need to look at this in more detail Does reverting 37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices help? Reverting it sets the USB3 port to RxDetect via ss.disabled after failing to reset a few times. kind of disabling/re-enabling the USB3 port. Doing a USB2 type "cold" bus reset (SE0) instead of a USB3 inband Hot or Warm reset could solve this as well, but I can't find a way to force a USB2 style cold reset on USB3 ports with xHCI. Setting the xhci port PORTSC register PR bit will issue a USB2 bus reset for USB2 protocol ports and Hot reset for USB3 protocol ports. The warm reset is a separate bit (WPR) in portsc register. Other things that needs attention (todo list): * hub_port_wait_reset() in hub.c checks for USB_PORT_STAT_RESET, returning -EBUSY before checking USB_PORT_STAT_CONNECTION, returning -ENOTCONN. This causes extra delays when doing several 200ms waits for warm reset to finish when the port should just be logically disconnected. * Fix the failing disable_lpm and disable_ltm issues in usb_reset_and_verify_device() that Alan pointed out. * make sure xhci sets udev->slot_id to zero when xhci
Re: power management problems in ehci-omap
* Andreas Kemnade [180206 16:56]:
> On Tue, 6 Feb 2018 08:04:52 -0800
> Tony Lindgren wrote:
>
> > * Andreas Kemnade [180206 06:42]:
> > > rechecked with a board with really nothing connected there
> > > Same behaviour
> >
> > I've just verified that my test board power consumption goes
> > back to normal after rmmod ehci-omap with v4.15.
> >
> yes, for me too, I initially used a test script which does an
> echo rmmod ehci-omap
>
> without a real
> rmmod ehci-omap
Ah OK :)
> It just seems to be consistent with my observations in a fully booted
> system (where many things can play a role). Sorry for that confusion.
Try with a minimal set of modules first, then modprobe and rmmod one
at a time until you find the module breaking PM?
You probably know this already, but just in case it helps..
First idle the UARTs and enable off mode with something like:
uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
echo 3000 > $uart/autosuspend_delay_ms 2>&1
done
uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
for uart in $uarts; do
echo enabled > $uart/wakeup 2>&1
echo auto > $uart/control 2>&1
done
echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode
Then if using omap3, the attached debug hack patch can be used to
see which devices are not idling:
> But suspend current is a problem. I have repeated the measurement with
> another board, so it is not a board problem.
I also verified v4.15 behaves for suspend current even with
echi-omap loaded just in case.
Regards,
Tony
8< ---
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Wed, 13 Dec 2017 16:36:45 -0800
Subject: [PATCH] NOT FOR MERGING: Test patch for dumping omap3 off idle
blocking bits
Allows seeing the deeper idle state blockers in
/sys/kernel/debug/pm_debug/count. For example, when
off idle is working on beaglboard xm, this is what
i see:
# sleep 5; cat /sys/kernel/debug/pm_debug/count
...
0006 48005020 (fa005020) cm_idlest_per blocking bits: 0001
e7bd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 0042
000d 48004a28 (fa004a28) cm_idlest3_core
---
arch/arm/mach-omap2/pm-debug.c | 68 ++
1 file changed, 68 insertions(+)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -142,10 +142,78 @@ static int pwrdm_dbg_show_timer(struct powerdomain
*pwrdm, void *user)
return 0;
}
+#include "iomap.h"
+
+struct dregs {
+ const char *desc;
+ u32 phys;
+ void __iomem*virt;
+ u32 mask;
+};
+
+#define PER_CM_BASE0x48005000
+#define PER_CM_REG(name, offset, mask) \
+ { name, PER_CM_BASE + offset, \
+ OMAP2_L4_IO_ADDRESS(PER_CM_BASE + offset), mask, }
+
+static struct dregs cm_per[] = {
+ PER_CM_REG("cm_idlest_per", 0x20, 0xfff8), /* p 513 */
+ { NULL, },
+};
+
+#define CORE_CM_BASE 0x48004a00
+#define CORE_CM_REG(name, offset, mask)\
+ { name, CORE_CM_BASE + offset, \
+ OMAP2_L4_IO_ADDRESS(CORE_CM_BASE + offset), mask, }
+
+static struct dregs cm_core[] = {
+ CORE_CM_REG("cm_idlest1_core", 0x20, 0x9c800109), /* p 467 */
+ CORE_CM_REG("cm_idlest3_core", 0x28, 0xfffb),
+ { NULL, },
+};
+
+void __dregs_dump(struct dregs *dregs, struct seq_file *s)
+{
+ for (; dregs->desc; dregs++) {
+ u32 val, blockers;
+
+ val = __raw_readl(dregs->virt);
+
+ seq_printf(s, "%08x %08x (%p) %s",
+ val, dregs->phys, dregs->virt,
+ dregs->desc);
+
+ if (dregs->mask) {
+ blockers = ~val;
+ blockers &= ~dregs->mask;
+
+ if (blockers)
+ seq_printf(s, " blocking bits: %08x",
+ blockers);
+ }
+
+ seq_printf(s, "\n");
+ }
+}
+
+void cm_per_dump(struct seq_file *s)
+{
+ __dregs_dump(cm_per, s);
+}
+
+void cm_core_dump(struct seq_file *s)
+{
+ __dregs_dump(cm_core, s);
+}
+
static int pm_dbg_show_counters(struct seq_file *s, void *unused)
{
pwrdm_for_each(pwrdm_dbg_show_counter, s);
clkdm_for_each(clkdm_dbg_show_counter, s);
+ if (cpu_is_omap34xx()) {
+ cm_per_dump(s);
+ cm_core_dump(s);
+ }
return 0;
}
--
2.16.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: power management problems in ehci-omap
On Tue, 6 Feb 2018 08:04:52 -0800 Tony Lindgren wrote: > * Andreas Kemnade [180206 06:42]: > > rechecked with a board with really nothing connected there > > Same behaviour > > I've just verified that my test board power consumption goes > back to normal after rmmod ehci-omap with v4.15. > yes, for me too, I initially used a test script which does an echo rmmod ehci-omap without a real rmmod ehci-omap It just seems to be consistent with my observations in a fully booted system (where many things can play a role). Sorry for that confusion. But suspend current is a problem. I have repeated the measurement with another board, so it is not a board problem. Regards, Andreas pgp3FPeMxsI6B.pgp Description: OpenPGP digital signature
Re: power management problems in ehci-omap
* Andreas Kemnade [180206 06:42]: > rechecked with a board with really nothing connected there > Same behaviour I've just verified that my test board power consumption goes back to normal after rmmod ehci-omap with v4.15. For ehci PM, it might be a bit easier to do nowadays that we have Linux generic wakeirq support if somebody wants to take a look at it. The PHY lines could have wakeirq events enabled for the pads, and there is an older series from Rogeq that does not use wakeirqs at: https://lkml.org/lkml/2013/7/10/355 Regards, Tony -- 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 6/7] typec: tcpm: Represent source supply through power_supply class
On 30 January 2018 13:12, Heikki Krogerus wrote: > Hi Adam, > > On Tue, Jan 02, 2018 at 03:50:54PM +, Adam Thomson wrote: > > This commit adds a power_supply class instance to represent a > > PD source's voltage and current properties. This provides an > > interface for reading these properties from user-space or other > > drivers. > > > > For PPS enabled Sources, this also provides write access to set > > the current and voltage and allows for swapping between standard > > PDO and PPS APDO. > > > > As this represents a superset of the information provided in the > > fusb302 driver, the power_supply instance in that code is removed > > as part of this change, so reverting the commit titled > > 'typec: tcpm: Represent source supply through power_supply class' > > > > > Signed-off-by: Adam Thomson > > --- > > .../ABI/testing/sysfs-class-power-tcpm-source-psy | 92 > > drivers/usb/typec/Kconfig | 1 + > > drivers/usb/typec/fusb302/Kconfig | 2 +- > > drivers/usb/typec/fusb302/fusb302.c| 63 +- > > drivers/usb/typec/tcpm.c | 233 > > - > > 5 files changed, 328 insertions(+), 63 deletions(-) > > create mode 100644 Documentation/ABI/testing/sysfs-class-power-tcpm-source- > psy > > > > diff --git a/Documentation/ABI/testing/sysfs-class-power-tcpm-source-psy > b/Documentation/ABI/testing/sysfs-class-power-tcpm-source-psy > > new file mode 100644 > > index 000..4986cba > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-class-power-tcpm-source-psy > > @@ -0,0 +1,92 @@ > > +What: /sys/class/power_supply/tcpm-source-psy/type > > +Date: December 2017 > > +Contact: Adam Thomson > > +Description: > > + This read-only property describes the main type of source supply. > > + Type-C is a USB standard so this property always returns "USB". > > + > > +What: /sys/class/power_supply/tcpm-source-psy/connected_type > > +Date: December 2017 > > +Contact: Adam Thomson > > +Description: > > + This read-only property describes the type of source supply that is > > + connected, if the supply is online. The value is always Type C > > + unless a source has been attached which is identified as USB-PD capable. > > + > > + Valid values: > > + - "USB_TYPE_C" : Type C connected supply, not UBS-PD capable > > + (default value) > > + - "USB_PD" : USB-PD capable source supply connected > > + - "USB_PD_PPS" : USB-PD PPS capable source supply connected > > + > > +What: /sys/class/power_supply/tcpm-source-psy/online > > +Date: December 2017 > > +Contact: Adam Thomson > > +Description: > > + This read-write property describes the online state of the source > > + supply. When the value of this property is not 0, and the supply allows > > + it, then it's possible to switch between online states (i.e. 1 -> 2, > > + 2 -> 1) > > + > > + Valid values: > > + - 0 : Offline, no source supply attached > > + - 1 : Fixed Online, Type-C or USB-PD capable supply > > + attached, non-configurable current and voltage > > + properties in this state. > > + - 2 : PPS Online, USB-PD PPS feature enabled, 'current_now' > > + and 'voltage_now' properties can be modified in this > > + state. Re-writing of this value again, once already > > + set, will re-request the same configured voltage and > > + current values. This can be used as a keep-alive for > > + the PPS connection. > > + [NOTE: This is value only selectable if > > + 'connected_type' reports a value of "USB_PD_PPS"] > > + > > +What: /sys/class/power_supply/tcpm-source-psy/voltage_min > > +Date: December 2017 > > +Contact: Adam Thomson > > +Description: > > + This read-only property describes the minimum voltage the source supply > > + can provide. > > + > > + Value in microvolts. > > + > > +What: /sys/class/power_supply/tcpm-source-psy/voltage_max > > +Date: December 2017 > > +Contact: Adam Thomson > > +Description: > > + This read-only property describes the maximum voltage the source supply > > + can provide. > > + > > + Value in microvolts. > > + > > +What: /sys/class/power_supply/tcpm-source-psy/voltage_now > > +Date: December 2017 > > +Contact: Adam Thomson > > +Description: > > + This read-write property describes the voltage the source supply is > > + providing now. This property can only be written to if the source supply > > + is in online state '2' (PPS enabled), otherwise it's read-only > > + information. > > + > > + Value in microvolts. > > + > > +What:
Re: [PATCH 2/2] usb: chipidea: imx: Fix ULPI on imx53
Hi Peter,
On Mon, Jan 29, 2018 at 11:33:15AM +0800, Peter Chen wrote:
> On Wed, Jan 24, 2018 at 06:14:39PM +0100, Sebastian Reichel wrote:
> > Traditionally, PORTSC should be set before initializing ULPI phys. But
> > setting PORTSC before powering on the phy results in a kernel freeze
> > on imx53 based GE PPD. As a workaround this initializes the phy early
> > in the imx platform code and disables phy power management from the
> > core.
> >
> > Signed-off-by: Fabien Lahoudere
> > Signed-off-by: Sebastian Reichel
> > ---
> > drivers/usb/chipidea/ci_hdrc_imx.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
> > b/drivers/usb/chipidea/ci_hdrc_imx.c
> > index de155c80eb70..e431c5aafe35 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > @@ -83,6 +83,7 @@ struct ci_hdrc_imx_data {
> > struct clk *clk;
> > struct imx_usbmisc_data *usbmisc_data;
> > bool supports_runtime_pm;
> > + bool override_phy_control;
> > bool in_lpm;
> > /* SoC before i.mx6 (except imx23/imx28) needs three clks */
> > bool need_three_clks;
> > @@ -254,6 +255,7 @@ static int ci_hdrc_imx_probe(struct platform_device
> > *pdev)
> > int ret;
> > const struct of_device_id *of_id;
> > const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
> > + struct device_node *np = pdev->dev.of_node;
> >
> > of_id = of_match_device(ci_hdrc_imx_dt_ids, &pdev->dev);
> > if (!of_id)
> > @@ -288,6 +290,14 @@ static int ci_hdrc_imx_probe(struct platform_device
> > *pdev)
> > }
> >
> > pdata.usb_phy = data->phy;
> > +
> > + if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
> > + of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
> > + pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
> > + data->override_phy_control = true;
> > + usb_phy_init(pdata.usb_phy);
> > + }
> > +
> > pdata.flags |= imx_platform_flag->flags;
> > if (pdata.flags & CI_HDRC_SUPPORTS_RUNTIME_PM)
> > data->supports_runtime_pm = true;
> > @@ -341,6 +351,8 @@ static int ci_hdrc_imx_remove(struct platform_device
> > *pdev)
> > pm_runtime_put_noidle(&pdev->dev);
> > }
> > ci_hdrc_remove_device(data->ci_pdev);
> > + if (data->override_phy_control)
> > + usb_phy_shutdown(data->phy);
> > imx_disable_unprepare_clks(&pdev->dev);
> >
>
> Sebastian, I have a question, do you have any USB or generic PHY drivers
> for ULPI bus, any power controls are needed for your ULPI peripheral?
The devicetree for GE PPD is available in the mainline kernel:
$ grep -A9 "usbphy[23] {" arch/arm/boot/dts/imx53-ppd.dts
usbphy2: usbphy2 {
compatible = "usb-nop-xceiv";
reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
clock-names = "main_clk";
clock-frequency = <2400>;
clocks = <&clks IMX5_CLK_CKO2>;
assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks
IMX5_CLK_OSC>;
assigned-clock-parents = <&clks IMX5_CLK_OSC>;
};
usbphy3: usbphy3 {
compatible = "usb-nop-xceiv";
reset-gpios = <&gpio2 19 GPIO_ACTIVE_LOW>;
clock-names = "main_clk";
clock-frequency = <2400>;
clocks = <&clks IMX5_CLK_CKO2>;
assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks
IMX5_CLK_OSC>;
assigned-clock-parents = <&clks IMX5_CLK_OSC>;
};
So currently the machine only uses drivers/usb/phy/phy-generic.c. Both
USB phys are actually SMSC USB3315, which is also detected by the kernel:
root@csmon :~# cat /sys/bus/ulpi/devices/ci_hdrc.*.ulpi/uevent
DEVTYPE=ulpi_device
MODALIAS=ulpi:v0424p0006
DEVTYPE=ulpi_device
MODALIAS=ulpi:v0424p0006
So maybe drivers/usb/phy/phy-ulpi.c should be used, but I don't see
a simple way to do so and using the generic PHY works.
-- Sebastian
signature.asc
Description: PGP signature
Re: [PATCH/RFC 0/6] Allow compile-testing NO_DMA
On Tue, Feb 6, 2018 at 2:05 PM, Robin Murphy wrote: > > It looks like we have only one real arch (score) without IOMEM, and two > (s390 and tile) where it is possible to configure out, so it does seem like > a reasonable feature to assume. Maybe we could have something like > asm-generic/no-io.h to provide an "unimplemented" version of those > interfaces. Agreed, there is no use trying to optimize for any of those three cases: For s390, all new machines come with PCI, so distros will enable it all the time. Few users run their own kernels even on older machines. score has been de-facto unmaintained for a few years, and tile has recently been orphaned with the hardware platform being abandoned by Mellanox. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/6] Allow compile-testing NO_DMA
On Tue, Feb 6, 2018 at 11:14 AM, Geert Uytterhoeven wrote: > Hi all, > > If NO_DMA=y, get_dma_ops() returns a reference to the non-existing > symbol bad_dma_ops, thus causing a link failure if it is ever used. > > The intention of this is twofold: > 1. To catch users of the DMA API on systems that do no support the DMA > mapping API, > 2. To avoid building drivers that cannot work on such systems anyway. > > However, the disadvantage is that we have to keep on adding dependencies > on HAS_DMA all over the place. > > Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or > more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus > already covering intention #2. Having to add an explicit dependency on > HAS_DMA here is cumbersome, and hinders compile-testing. > > Hence I think the time is ripe to reconsider the link failure. > This patch series: > - Changes get_dma_ops() to return NULL instead, > - Adds a few more dummies to enable compile-testing, > - Removes dependencies on HAS_DMA for symbols that already have > platform dependencies implying HAS_DMA. > > Note that adding more platform dependencies and/or dependencies on > COMPILE_TEST is encouraged! > > This may make life harder for UML, though, as UML usually satisfies all > other platform dependencies for HAS_DMA. Similarly, HAS_IOMEM is even > more complicated. Can/do we want to do something similar for > HAS_IOMEM? > > This series is against my current local tree, which has a few more > "depends on HAS_DMA" than upstream. Of course I will rebase, and split > the last patch per subsystem, if this RFC is welcomed positively. > > Compile-tested with allmodconfig and allyesconfig for m68k/sun3. David Woodhouse has been looking at some other structures with indirect pointers (kvm_x86_ops) to reduce the overhead that was added for avoiding speculative execution of those pointers. I wonder if there are any dma_map_ops operations that are in a fastpath that needs a similar optimization. If yes, we might want to think about how to do that part first to avoid rewriting the same code more than once. Otherwise, your approach seems fine. Arnd -- 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: dwc2: Fix interval type issue
The maximum value that unsigned char can hold is 255, meanwhile
the maximum value of interval is 2^(bIntervalMax-1)=2^15.
Signed-off-by: Grigor Tovmasyan
---
drivers/usb/dwc2/core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 0f0c21cf0192..51c3d5170b3b 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -217,7 +217,7 @@ struct dwc2_hsotg_ep {
unsigned char dir_in;
unsigned char index;
unsigned char mc;
- unsigned char interval;
+ u16 interval;
unsigned inthalted:1;
unsigned intperiodic:1;
--
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] usb: dwc2: Fix kernel doc's warnings.
Added descriptions for all not described parameters.
Signed-off-by: Grigor Tovmasyan
---
drivers/usb/dwc2/core.c | 7 +++
drivers/usb/dwc2/core.h | 131 ++-
drivers/usb/dwc2/debug.h | 2 +-
drivers/usb/dwc2/debugfs.c | 19 ---
drivers/usb/dwc2/gadget.c| 29 +++---
drivers/usb/dwc2/hcd.c | 3 +-
drivers/usb/dwc2/hcd.h | 14 +++--
drivers/usb/dwc2/hcd_ddma.c | 1 +
drivers/usb/dwc2/hcd_intr.c | 12
drivers/usb/dwc2/hcd_queue.c | 5 +-
drivers/usb/dwc2/params.c| 8 +++
drivers/usb/dwc2/pci.c | 6 ++
12 files changed, 183 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index dbca3b8890da..c47b56c887aa 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -281,6 +281,8 @@ static void dwc2_wait_for_mode(struct dwc2_hsotg *hsotg,
/**
* dwc2_iddig_filter_enabled() - Returns true if the IDDIG debounce
* filter is enabled.
+ *
+ *@hsotg: Programming view of DWC_otg controller
*/
static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg *hsotg)
{
@@ -399,6 +401,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool
skip_wait)
* If a force is done, it requires a IDDIG debounce filter delay if
* the filter is configured and enabled. We poll the current mode of
* the controller to account for this delay.
+ *
+ * @hsotg: Programming view of DWC_otg controller
+ * @host: Host mode flag
*/
void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
{
@@ -445,6 +450,8 @@ void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
* or not because the value of the connector ID status is affected by
* the force mode. We only need to call this once during probe if
* dr_mode == OTG.
+ *
+ *@hsotg: Programming view of DWC_otg controller
*/
void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
{
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 0f0c21cf0192..9252a7343a5a 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -164,12 +164,11 @@ struct dwc2_hsotg_req;
* and has yet to be completed (maybe due to data move, or simply
* awaiting an ack from the core all the data has been completed).
* @debugfs: File entry for debugfs file for this endpoint.
- * @lock: State lock to protect contents of endpoint.
* @dir_in: Set to true if this endpoint is of the IN direction, which
* means that it is sending data to the Host.
* @index: The index for the endpoint registers.
* @mc: Multi Count - number of transactions per microframe
- * @interval - Interval for periodic endpoints, in frames or microframes.
+ * @interval: Interval for periodic endpoints, in frames or microframes.
* @name: The name array passed to the USB core.
* @halted: Set if the endpoint has been halted.
* @periodic: Set if this is a periodic ep, such as Interrupt
@@ -182,6 +181,7 @@ struct dwc2_hsotg_req;
* @next_desc: index of next free descriptor in the ISOC chain under SW
control.
* @total_data: The total number of data bytes done.
* @fifo_size: The size of the FIFO (for periodic IN endpoints)
+ * @fifo_index: For Dedicated FIFO operation, only FIFO0 can be used for EP0.
* @fifo_load: The amount of data loaded into the FIFO (periodic IN)
* @last_load: The offset of data for the last start of request.
* @size_loaded: The last loaded size for DxEPTSIZE for periodic IN
@@ -523,7 +523,7 @@ struct dwc2_core_params {
*
* The values that are not in dwc2_core_params are documented below.
*
- * @op_mode Mode of Operation
+ * @op_mode: Mode of Operation
* 0 - HNP- and SRP-Capable OTG (Host & Device)
* 1 - SRP-Capable OTG (Host & Device)
* 2 - Non-HNP and Non-SRP Capable OTG (Host & Device)
@@ -531,40 +531,87 @@ struct dwc2_core_params {
* 4 - Non-OTG Device
* 5 - SRP-Capable Host
* 6 - Non-OTG Host
- * @archArchitecture
+ * @arch:Architecture
* 0 - Slave only
* 1 - External DMA
* 2 - Internal DMA
- * @power_optimized Are power optimizations enabled?
- * @num_dev_ep Number of device endpoints available
- * @num_dev_perio_in_ep Number of device periodic IN endpoints
+ * @power_optimized: Are power optimizations enabled?
+ * @num_dev_ep: Number of device endpoints available
+ * @num_dev_perio_in_ep: Number of device periodic IN endpoints
* available
- * @dev_token_q_depth Device Mode IN Token Sequence Learning Queue
+ * @dev_token_q_depth: Device Mode IN Token Sequence Learning Queue
* Depth
* 0 to 30
- * @host_perio_tx_q_depth
+ * @host_perio_tx_q_depth:
* Host Mode Periodic Request Queue Depth
Re: [PATCH v4 4/7] typec: tcpm: Add core support for sink side PPS
On Tue, Feb 06, 2018 at 02:33:08PM +, Adam Thomson wrote:
> On 30 January 2018 12:47, Heikki Krogerus wrote:
>
> > > +static int tcpm_pps_set_op_curr(struct tcpm_port *port, u16 op_curr)
> > > +{
> > > + unsigned int target_mw;
> > > + int ret = 0;
> > > +
> > > + mutex_lock(&port->swap_lock);
> > > + mutex_lock(&port->lock);
> > > +
> > > + if (!port->pps_data.active) {
> > > + ret = -EOPNOTSUPP;
> > > + goto port_unlock;
> > > + }
> > > +
> > > + if (port->state != SNK_READY) {
> > > + ret = -EAGAIN;
> > > + goto port_unlock;
> > > + }
> > > +
> > > + if (op_curr > port->pps_data.max_curr) {
> > > + ret = -EINVAL;
> > > + goto port_unlock;
> > > + }
> > > +
> > > + target_mw = (op_curr * port->pps_data.out_volt) / 1000;
> > > + if (target_mw < port->operating_snk_mw) {
> > > + ret = -EINVAL;
> > > + goto port_unlock;
> > > + }
> > > +
> > > + reinit_completion(&port->pps_complete);
> > > + port->pps_data.op_curr = op_curr;
> > > + port->pps_status = 0;
> > > + port->pps_pending = true;
> > > + tcpm_set_state(port, SNK_NEGOTIATE_PPS_CAPABILITIES, 0);
> >
> > Why not just take the swap_lock here..
>
> I believe this would result in deadlock. All of the existing uses of swap_lock
> acquire it first before the port->lock is then acquired (and vice-versa for
> unlock). We don't want the power role to change during this procedure, so we
> hold the swap_lock for the whole process. Have a look at tcpm_dr_set() and
> tcpm_pr_set() as examples of existing usage.
OK. Then I'm fine with this patch as well. FWIW:
Acked-by: Heikki Krogerus
--
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 v4 4/7] typec: tcpm: Add core support for sink side PPS
On 30 January 2018 12:47, Heikki Krogerus wrote:
> > +static int tcpm_pps_set_op_curr(struct tcpm_port *port, u16 op_curr)
> > +{
> > + unsigned int target_mw;
> > + int ret = 0;
> > +
> > + mutex_lock(&port->swap_lock);
> > + mutex_lock(&port->lock);
> > +
> > + if (!port->pps_data.active) {
> > + ret = -EOPNOTSUPP;
> > + goto port_unlock;
> > + }
> > +
> > + if (port->state != SNK_READY) {
> > + ret = -EAGAIN;
> > + goto port_unlock;
> > + }
> > +
> > + if (op_curr > port->pps_data.max_curr) {
> > + ret = -EINVAL;
> > + goto port_unlock;
> > + }
> > +
> > + target_mw = (op_curr * port->pps_data.out_volt) / 1000;
> > + if (target_mw < port->operating_snk_mw) {
> > + ret = -EINVAL;
> > + goto port_unlock;
> > + }
> > +
> > + reinit_completion(&port->pps_complete);
> > + port->pps_data.op_curr = op_curr;
> > + port->pps_status = 0;
> > + port->pps_pending = true;
> > + tcpm_set_state(port, SNK_NEGOTIATE_PPS_CAPABILITIES, 0);
>
> Why not just take the swap_lock here..
I believe this would result in deadlock. All of the existing uses of swap_lock
acquire it first before the port->lock is then acquired (and vice-versa for
unlock). We don't want the power role to change during this procedure, so we
hold the swap_lock for the whole process. Have a look at tcpm_dr_set() and
tcpm_pr_set() as examples of existing usage.
> > + return ret;
> > +}
> > +
> > +static int tcpm_pps_set_out_volt(struct tcpm_port *port, u16 out_volt)
> > +{
> > + unsigned int target_mw;
> > + int ret = 0;
> > +
> > + mutex_lock(&port->swap_lock);
> > + mutex_lock(&port->lock);
> > +
> > + if (!port->pps_data.active) {
> > + ret = -EOPNOTSUPP;
> > + goto port_unlock;
>
> Or, on top of what I said above, you could actually consider releasing
> the port lock here and just returning. Then you would not need those
> port_unlock and swap_unlock labels at all..
>
> mutex_unlock(&port->lock);
> return -EOPNOTSUPP;
Based on the comment above, I don't think this makes sense as you'd still need
to release the swap_lock as well, so there would be quite a lot of duplicated
code. Would prefer to stick with the present implementation.
--
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 1/7] typec: tcpm: Add PD Rev 3.0 definitions to PD header
On 30 January 2018 12:22, Heikki Krogerus wrote: > On Tue, Jan 02, 2018 at 03:50:49PM +, Adam Thomson wrote: > > This commit adds definitions for PD Rev 3.0 messages, including > > APDO PPS and extended message support for TCPM. > > > > Signed-off-by: Adam Thomson > > Just one nitpick. I noticed that you are exceeding the 80 character > limit per line in several places in this series, and I many cases it > does not look like splitting the line would make the code any less > readable. > > But I don't think that is critical, so if there are no other comments: > > > Acked-by: Heikki Krogerus Thanks for the Ack. The file, before I updated it, already had lines like this for similar definitions. With that in mind I'd erred on the side of style (and readability, at least in my opinion :)) rather than dropping onto new lines as they weren't going over by a great deal. However if there's a desire for this to change then I can update accordingly. -- 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: gadget: f_fs: get the correct address of comp_desc
Hi Jack,
在 2018年02月06日 02:17, Jack Pham 写道:
Hi William,
On Mon, Feb 05, 2018 at 07:33:38PM +0800, William Wu wrote:
Refer to the USB 3.0 spec '9.6.7 SuperSpeed Endpoint Companion',
the companion descriptor follows the standard endpoint descriptor.
This descriptor is only defined for SuperSpeed endpoints. The
f_fs driver gets the address of the companion descriptor via
'ds + USB_DT_ENDPOINT_SIZE', and actually, the ds variable is
a pointer to the struct usb_endpoint_descriptor, so the offset
of the companion descriptor which we get is USB_DT_ENDPOINT_SIZE *
sizeof(struct usb_endpoint_descriptor), the wrong offset is 63
bytes. This cause out-of-bound with the following error log if
CONFIG_KASAN and CONFIG_SLUB_DEBUG is enabled on Rockchip RK3399
Evaluation Board.
android_work: sent uevent USB_STATE=CONNECTED
configfs-gadget gadget: super-speed config #1: b
==
BUG: KASAN: slab-out-of-bounds in ffs_func_set_alt+0x230/0x398
Read of size 1 at addr ffc0ce2d0b10 by task irq/224-dwc3/364
Memory state around the buggy address:
ffc0ce2d0a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffc0ce2d0a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffc0ce2d0b00: 00 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffc0ce2d0b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffc0ce2d0c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==
Disabling lock debugging due to kernel taint
android_work: sent uevent USB_STATE=CONFIGURED
This patch adds struct usb_endpoint_descriptor * -> u8 * type conversion
for ds variable, then we can get the correct address of comp_desc
with offset USB_DT_ENDPOINT_SIZE bytes.
Signed-off-by: William Wu
---
drivers/usb/gadget/function/f_fs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 6756472..f13ead0 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1882,8 +1882,8 @@ static int ffs_func_eps_enable(struct ffs_function *func)
ep->ep->desc = ds;
if (needs_comp_desc) {
- comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
- USB_DT_ENDPOINT_SIZE);
+ comp_desc = (struct usb_ss_ep_comp_descriptor *)
+((u8 *)ds + USB_DT_ENDPOINT_SIZE);
ep->ep->maxburst = comp_desc->bMaxBurst + 1;
ep->ep->comp_desc = comp_desc;
}
Please see my alternative fix for this. I proposed changing this
function to use config_ep_by_speed() instead.
https://www.spinics.net/lists/linux-usb/msg165149.html
Thanks for your great job!
Your patch seems good, I will test your patch on my RK3399-EVB board.
William
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/6] Allow compile-testing NO_DMA
On 06/02/18 10:14, Geert Uytterhoeven wrote: Hi all, If NO_DMA=y, get_dma_ops() returns a reference to the non-existing symbol bad_dma_ops, thus causing a link failure if it is ever used. The intention of this is twofold: 1. To catch users of the DMA API on systems that do no support the DMA mapping API, 2. To avoid building drivers that cannot work on such systems anyway. However, the disadvantage is that we have to keep on adding dependencies on HAS_DMA all over the place. Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus already covering intention #2. Having to add an explicit dependency on HAS_DMA here is cumbersome, and hinders compile-testing. Hence I think the time is ripe to reconsider the link failure. This patch series: - Changes get_dma_ops() to return NULL instead, - Adds a few more dummies to enable compile-testing, - Removes dependencies on HAS_DMA for symbols that already have platform dependencies implying HAS_DMA. Note that adding more platform dependencies and/or dependencies on COMPILE_TEST is encouraged! This may make life harder for UML, though, as UML usually satisfies all other platform dependencies for HAS_DMA. Similarly, HAS_IOMEM is even more complicated. Can/do we want to do something similar for HAS_IOMEM? It looks like we have only one real arch (score) without IOMEM, and two (s390 and tile) where it is possible to configure out, so it does seem like a reasonable feature to assume. Maybe we could have something like asm-generic/no-io.h to provide an "unimplemented" version of those interfaces. Anyway, for this series: Acked-by: Robin Murphy Thanks, Robin. This series is against my current local tree, which has a few more "depends on HAS_DMA" than upstream. Of course I will rebase, and split the last patch per subsystem, if this RFC is welcomed positively. Compile-tested with allmodconfig and allyesconfig for m68k/sun3. Thanks for your comments! Geert Uytterhoeven (6): [RFC] dma-mapping: Convert NO_DMA get_dma_ops() into a real dummy [RFC] dma-coherent: Add NO_DMA dummies for managed DMA API [RFC] usb: gadget: Add NO_DMA dummies for DMA mapping API [RFC] mm: Add NO_DMA dummies for DMA pool API [RFC] scsi: Add NO_DMA dummies for SCSI DMA mapping API [RFC] Treewide: Remove depends on HAS_DMA in case of platform dependency drivers/ata/Kconfig | 2 -- drivers/crypto/Kconfig | 14 +++-- drivers/firewire/Kconfig| 1 - drivers/fpga/Kconfig| 1 - drivers/gpu/ipu-v3/Kconfig | 1 - drivers/i2c/busses/Kconfig | 3 -- drivers/iio/adc/Kconfig | 3 -- drivers/iommu/Kconfig | 5 ++-- drivers/lightnvm/Kconfig| 2 +- drivers/mailbox/Kconfig | 2 -- drivers/media/pci/dt3155/Kconfig| 1 - drivers/media/pci/solo6x10/Kconfig | 1 - drivers/media/pci/sta2x11/Kconfig | 1 - drivers/media/pci/tw5864/Kconfig| 1 - drivers/media/pci/tw686x/Kconfig| 1 - drivers/media/platform/Kconfig | 40 - drivers/media/platform/am437x/Kconfig | 2 +- drivers/media/platform/atmel/Kconfig| 4 +-- drivers/media/platform/blackfin/Kconfig | 1 - drivers/media/platform/davinci/Kconfig | 6 drivers/media/platform/marvell-ccic/Kconfig | 3 +- drivers/media/platform/rcar-vin/Kconfig | 2 +- drivers/media/platform/soc_camera/Kconfig | 3 +- drivers/media/platform/sti/c8sectpfe/Kconfig| 2 +- drivers/mmc/host/Kconfig| 10 ++- drivers/mtd/nand/Kconfig| 8 ++--- drivers/mtd/spi-nor/Kconfig | 2 +- drivers/net/ethernet/amd/Kconfig| 2 +- drivers/net/ethernet/apm/xgene-v2/Kconfig | 1 - drivers/net/ethernet/apm/xgene/Kconfig | 1 - drivers/net/ethernet/arc/Kconfig| 6 ++-- drivers/net/ethernet/broadcom/Kconfig | 2 -- drivers/net/ethernet/calxeda/Kconfig| 2 +- drivers/net/ethernet/hisilicon/Kconfig | 2 +- drivers/net/ethernet/marvell/Kconfig| 8 ++--- drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +- drivers/net/ethernet/renesas/Kconfig| 2 -- drivers/net/ethernet/socionext/Kconfig | 4 +-- drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 - drivers/net/wireless/quantenna/qtnfmac/Kconfig | 2 +- drivers/remoteproc/Kconfig | 1 - drivers/scsi/hisi_sas/Kconfig | 2 +- drivers/spi/Kconfig | 12 ++---
Re: [PATCH/RFC 4/6] mm: Add NO_DMA dummies for DMA pool API
Hi Geert,
On 06/02/18 10:14, Geert Uytterhoeven wrote:
Add dummies for dma{,m}_pool_{create,destroy,alloc,free}(), to allow
compile-testing if NO_DMA=y.
This prevents the following from showing up later:
ERROR: "dma_pool_destroy" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_free" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_create" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_destroy" [drivers/scsi/hisi_sas/hisi_sas_main.ko]
undefined!
ERROR: "dma_pool_free" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_create" [drivers/scsi/hisi_sas/hisi_sas_main.ko]
undefined!
ERROR: "dma_pool_alloc" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_free" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_create" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_destroy" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
Signed-off-by: Geert Uytterhoeven
---
include/linux/dmapool.h | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/linux/dmapool.h b/include/linux/dmapool.h
index 53ba737505df31c7..adeb5e56c3ad73a8 100644
--- a/include/linux/dmapool.h
+++ b/include/linux/dmapool.h
@@ -16,6 +16,7 @@
struct device;
+#ifdef CONFIG_HAS_DMA
struct dma_pool *dma_pool_create(const char *name, struct device *dev,
size_t size, size_t align, size_t allocation);
@@ -23,6 +24,17 @@ void dma_pool_destroy(struct dma_pool *pool);
void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
dma_addr_t *handle);
+void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t addr);
+#else /* !CONFIG_HAS_DMA */
+static inline struct dma_pool *dma_pool_create(const char *name,
+ struct device *dev, size_t size, size_t align, size_t allocation)
+{ return NULL; }
+static inline void dma_pool_destroy(struct dma_pool *pool) { }
+static inline void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
+ dma_addr_t *handle) { return NULL; }
+static inline void dma_pool_free(struct dma_pool *pool, void *vaddr,
+dma_addr_t addr) { }
+#endif /* !CONFIG_HAS_DMA */
static inline void *dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
dma_addr_t *handle)
@@ -30,14 +42,19 @@ static inline void *dma_pool_zalloc(struct dma_pool *pool,
gfp_t mem_flags,
return dma_pool_alloc(pool, mem_flags | __GFP_ZERO, handle);
}
-void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t addr);
-
/*
* Managed DMA pool
*/
+#ifdef CONFIG_HAS_DMA
struct dma_pool *dmam_pool_create(const char *name, struct device *dev,
size_t size, size_t align, size_t allocation);
void dmam_pool_destroy(struct dma_pool *pool);
+#else /* !CONFIG_HAS_DMA */
+static inline struct dma_pool *dmam_pool_create(const char *name,
+ struct device *dev, size_t size, size_t align, size_t allocation)
+{ return NULL; }
+static inline void dmam_pool_destroy(struct dma_pool *pool) { }
+#endif /* !CONFIG_HAS_DMA */
Nit: It might be tidier to add *all* the stubs down here so that there
only need be a single #ifdef, then move the dma_pool_zalloc definition
outside at the end (where we might eventually get rid of it anyway).
Other than that, though, I think I agree with the series in general -
more COMPILE_TEST is always good from the point of view of weeding out
drivers using architecture-specific DMA API internals which aren't part
of the proper generic interface.
Robin.
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/6] Allow compile-testing NO_DMA
On Tue, Feb 06, 2018 at 11:14:46AM +0100, Geert Uytterhoeven wrote: > The intention of this is twofold: > 1. To catch users of the DMA API on systems that do no support the DMA > mapping API, > 2. To avoid building drivers that cannot work on such systems anyway. > > However, the disadvantage is that we have to keep on adding dependencies > on HAS_DMA all over the place. > Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or > more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus > already covering intention #2. Having to add an explicit dependency on > HAS_DMA here is cumbersome, and hinders compile-testing. Thanks for doing this, hopefully it'll make everyone's life easier! Reviwed-by: Mark Brown signature.asc Description: PGP signature
Re: usb drivers in userspace
Hi, Ran Shalit writes: > On Tue, Feb 6, 2018 at 1:35 PM, Felipe Balbi > wrote: >> >> Hi, >> >> Ran Shalit writes: >>> Hello, >>> >>> Is it possible to write a usb driver in userspace ? >>> I see that for peripheral/gadget, there is gadgetfs which can be used for >>> that. >>> >>> What about host drivers ? >>> Can we use for example vfio (seems to be used with pci so I'm not >>> sure) ? Or is there another way ? >> >> Have a look at libusb (libusb.info, IIRC). It's probably what you're >> looking for. >> > Right! > I see now that there are 2 main solution nowadays for userspace usb drivers: > 1. libusb - for host driver > 2. libusb-gadget ( or gadgetfs) - for gadget drivers that's correct :-) libusb is far more mature, though :-) -- 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: usb drivers in userspace
On Tue, Feb 6, 2018 at 1:35 PM, Felipe Balbi wrote: > > Hi, > > Ran Shalit writes: >> Hello, >> >> Is it possible to write a usb driver in userspace ? >> I see that for peripheral/gadget, there is gadgetfs which can be used for >> that. >> >> What about host drivers ? >> Can we use for example vfio (seems to be used with pci so I'm not >> sure) ? Or is there another way ? > > Have a look at libusb (libusb.info, IIRC). It's probably what you're > looking for. > Right! I see now that there are 2 main solution nowadays for userspace usb drivers: 1. libusb - for host driver 2. libusb-gadget ( or gadgetfs) - for gadget drivers > good luck Thanks ! > > -- > 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: usb drivers in userspace
Hi, Ran Shalit writes: > Hello, > > Is it possible to write a usb driver in userspace ? > I see that for peripheral/gadget, there is gadgetfs which can be used for > that. > > What about host drivers ? > Can we use for example vfio (seems to be used with pci so I'm not > sure) ? Or is there another way ? Have a look at libusb (libusb.info, IIRC). It's probably what you're looking for. good luck -- 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
usb drivers in userspace
Hello, Is it possible to write a usb driver in userspace ? I see that for peripheral/gadget, there is gadgetfs which can be used for that. What about host drivers ? Can we use for example vfio (seems to be used with pci so I'm not sure) ? Or is there another way ? Thank you, Ran -- 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: uas failing on multiple disk access on a jmicron JMS567 bridge
2018-02-06 11:18 GMT+01:00 Oliver Neukum : > Am Mittwoch, den 31.01.2018, 12:45 +0100 schrieb Menion: >> you can see that short while after the two HD are mounted I start to >> get any sort of USB command errors. > > Well, no, all errors are Write(10). Thus my question whether you can > trigger it with any other command. Does it error out with Read(10), > too? > > Regards > Oliver > No As said the problems start when there are multiple write operation This is a multi bay enclosure. If there is only one HDD inside, there are no problems Unfortunately it is not simple to "silence" the activity on the HDD, since I run BTRFS on it. That is why I have asked also for a way to provide more info. If you google a little bit you will see that it is a very common problem -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uas failing on multiple disk access on a jmicron JMS567 bridge
Am Mittwoch, den 31.01.2018, 12:45 +0100 schrieb Menion: > you can see that short while after the two HD are mounted I start to > get any sort of USB command errors. Well, no, all errors are Write(10). Thus my question whether you can trigger it with any other command. Does it error out with Read(10), too? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB Gadget capabilities
Hi folks, I'm trying to identify hardware which has both USB host and USB gadget capabilities. Unfortunately, in some cases, datasheets are unavailable, or unclear, claiming only USB host support. However, digging further, it turns out that USB gadget support is also present, if one uses a USB A Male-to-Male cable. An example of this is the RTD1295, which, according to this article (https://www.cnx-software.com/2017/03/16/how-to-reinstall-android-firmware-on-realtek-rtd1295-tv-boxes/), which shows up as a device when the Male/Male cable is connected to the USB3 port at boot time. I'm not sure whether this is implemented in the boot-loader, or at an OS level. I have looked in the kernel usb-gadget sources, trying to find any hints, but was unable to come to a conclusion. I found the Raspberry Pi gadget functionality supported under the dwc2 driver, and saw the dwc3 driver as well, with some SoC specific glue layers. I guess my question is: what should I be looking for to determine whether a chipset actually supports USB gadget? Does USB3.0 inherently support USB gadget? Or just any based on DWC3? Thanks Rogan -- 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/RFC 0/6] Allow compile-testing NO_DMA
Hi all, If NO_DMA=y, get_dma_ops() returns a reference to the non-existing symbol bad_dma_ops, thus causing a link failure if it is ever used. The intention of this is twofold: 1. To catch users of the DMA API on systems that do no support the DMA mapping API, 2. To avoid building drivers that cannot work on such systems anyway. However, the disadvantage is that we have to keep on adding dependencies on HAS_DMA all over the place. Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus already covering intention #2. Having to add an explicit dependency on HAS_DMA here is cumbersome, and hinders compile-testing. Hence I think the time is ripe to reconsider the link failure. This patch series: - Changes get_dma_ops() to return NULL instead, - Adds a few more dummies to enable compile-testing, - Removes dependencies on HAS_DMA for symbols that already have platform dependencies implying HAS_DMA. Note that adding more platform dependencies and/or dependencies on COMPILE_TEST is encouraged! This may make life harder for UML, though, as UML usually satisfies all other platform dependencies for HAS_DMA. Similarly, HAS_IOMEM is even more complicated. Can/do we want to do something similar for HAS_IOMEM? This series is against my current local tree, which has a few more "depends on HAS_DMA" than upstream. Of course I will rebase, and split the last patch per subsystem, if this RFC is welcomed positively. Compile-tested with allmodconfig and allyesconfig for m68k/sun3. Thanks for your comments! Geert Uytterhoeven (6): [RFC] dma-mapping: Convert NO_DMA get_dma_ops() into a real dummy [RFC] dma-coherent: Add NO_DMA dummies for managed DMA API [RFC] usb: gadget: Add NO_DMA dummies for DMA mapping API [RFC] mm: Add NO_DMA dummies for DMA pool API [RFC] scsi: Add NO_DMA dummies for SCSI DMA mapping API [RFC] Treewide: Remove depends on HAS_DMA in case of platform dependency drivers/ata/Kconfig | 2 -- drivers/crypto/Kconfig | 14 +++-- drivers/firewire/Kconfig| 1 - drivers/fpga/Kconfig| 1 - drivers/gpu/ipu-v3/Kconfig | 1 - drivers/i2c/busses/Kconfig | 3 -- drivers/iio/adc/Kconfig | 3 -- drivers/iommu/Kconfig | 5 ++-- drivers/lightnvm/Kconfig| 2 +- drivers/mailbox/Kconfig | 2 -- drivers/media/pci/dt3155/Kconfig| 1 - drivers/media/pci/solo6x10/Kconfig | 1 - drivers/media/pci/sta2x11/Kconfig | 1 - drivers/media/pci/tw5864/Kconfig| 1 - drivers/media/pci/tw686x/Kconfig| 1 - drivers/media/platform/Kconfig | 40 - drivers/media/platform/am437x/Kconfig | 2 +- drivers/media/platform/atmel/Kconfig| 4 +-- drivers/media/platform/blackfin/Kconfig | 1 - drivers/media/platform/davinci/Kconfig | 6 drivers/media/platform/marvell-ccic/Kconfig | 3 +- drivers/media/platform/rcar-vin/Kconfig | 2 +- drivers/media/platform/soc_camera/Kconfig | 3 +- drivers/media/platform/sti/c8sectpfe/Kconfig| 2 +- drivers/mmc/host/Kconfig| 10 ++- drivers/mtd/nand/Kconfig| 8 ++--- drivers/mtd/spi-nor/Kconfig | 2 +- drivers/net/ethernet/amd/Kconfig| 2 +- drivers/net/ethernet/apm/xgene-v2/Kconfig | 1 - drivers/net/ethernet/apm/xgene/Kconfig | 1 - drivers/net/ethernet/arc/Kconfig| 6 ++-- drivers/net/ethernet/broadcom/Kconfig | 2 -- drivers/net/ethernet/calxeda/Kconfig| 2 +- drivers/net/ethernet/hisilicon/Kconfig | 2 +- drivers/net/ethernet/marvell/Kconfig| 8 ++--- drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +- drivers/net/ethernet/renesas/Kconfig| 2 -- drivers/net/ethernet/socionext/Kconfig | 4 +-- drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 - drivers/net/wireless/quantenna/qtnfmac/Kconfig | 2 +- drivers/remoteproc/Kconfig | 1 - drivers/scsi/hisi_sas/Kconfig | 2 +- drivers/spi/Kconfig | 12 ++-- drivers/staging/media/davinci_vpfe/Kconfig | 1 - drivers/staging/media/omap4iss/Kconfig | 1 - drivers/staging/vc04_services/Kconfig | 1 - drivers/tty/serial/Kconfig | 4 --- drivers/usb/gadget/udc/Kconfig | 4 +-- drivers/usb/mtu3/Kconfig| 2 +- drivers/video/fbdev/Kconfig | 3 +- include/linux/dma-mapping.h | 19 inc
[PATCH/RFC 2/6] dma-coherent: Add NO_DMA dummies for managed DMA API
Add dummies for dmam_{alloc,free}_coherent(), to allow compile-testing
if NO_DMA=y.
This prevents the following from showing up later:
ERROR: "dmam_alloc_coherent" [drivers/net/ethernet/arc/arc_emac.ko]
undefined!
ERROR: "dmam_free_coherent" [drivers/net/ethernet/apm/xgene/xgene-enet.ko]
undefined!
ERROR: "dmam_alloc_coherent" [drivers/net/ethernet/apm/xgene/xgene-enet.ko]
undefined!
ERROR: "dmam_alloc_coherent" [drivers/mtd/nand/hisi504_nand.ko] undefined!
ERROR: "dmam_alloc_coherent" [drivers/mmc/host/dw_mmc.ko] undefined!
Signed-off-by: Geert Uytterhoeven
---
include/linux/dma-mapping.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d78d7541f784875b..4d92956a4ddb8a5c 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -776,10 +776,19 @@ static inline void dma_deconfigure(struct device *dev) {}
/*
* Managed DMA API
*/
+#ifdef CONFIG_HAS_DMA
extern void *dmam_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp);
extern void dmam_free_coherent(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_handle);
+#else /* !CONFIG_HAS_DMA */
+static inline void *dmam_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp)
+{ return NULL; }
+static inline void dmam_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle) { }
+#endif /* !CONFIG_HAS_DMA */
+
extern void *dmam_alloc_attrs(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp,
unsigned long attrs);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 6/6] Treewide: Remove depends on HAS_DMA in case of platform dependency
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Notes: - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(), which does not exist if HAS_DMA=n (Do we need a dummy? The use of set_dma_ops() in this driver is questionable), - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their dependency on HAS_DMA, as they are selected from SND_SOC_APQ8016_SBC. Signed-off-by: Geert Uytterhoeven --- drivers/ata/Kconfig | 2 -- drivers/crypto/Kconfig | 14 +++-- drivers/firewire/Kconfig| 1 - drivers/fpga/Kconfig| 1 - drivers/gpu/ipu-v3/Kconfig | 1 - drivers/i2c/busses/Kconfig | 3 -- drivers/iio/adc/Kconfig | 3 -- drivers/iommu/Kconfig | 5 ++-- drivers/lightnvm/Kconfig| 2 +- drivers/mailbox/Kconfig | 2 -- drivers/media/pci/dt3155/Kconfig| 1 - drivers/media/pci/solo6x10/Kconfig | 1 - drivers/media/pci/sta2x11/Kconfig | 1 - drivers/media/pci/tw5864/Kconfig| 1 - drivers/media/pci/tw686x/Kconfig| 1 - drivers/media/platform/Kconfig | 40 - drivers/media/platform/am437x/Kconfig | 2 +- drivers/media/platform/atmel/Kconfig| 4 +-- drivers/media/platform/blackfin/Kconfig | 1 - drivers/media/platform/davinci/Kconfig | 6 drivers/media/platform/marvell-ccic/Kconfig | 3 +- drivers/media/platform/rcar-vin/Kconfig | 2 +- drivers/media/platform/soc_camera/Kconfig | 3 +- drivers/media/platform/sti/c8sectpfe/Kconfig| 2 +- drivers/mmc/host/Kconfig| 10 ++- drivers/mtd/nand/Kconfig| 8 ++--- drivers/mtd/spi-nor/Kconfig | 2 +- drivers/net/ethernet/amd/Kconfig| 2 +- drivers/net/ethernet/apm/xgene-v2/Kconfig | 1 - drivers/net/ethernet/apm/xgene/Kconfig | 1 - drivers/net/ethernet/arc/Kconfig| 6 ++-- drivers/net/ethernet/broadcom/Kconfig | 2 -- drivers/net/ethernet/calxeda/Kconfig| 2 +- drivers/net/ethernet/hisilicon/Kconfig | 2 +- drivers/net/ethernet/marvell/Kconfig| 8 ++--- drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +- drivers/net/ethernet/renesas/Kconfig| 2 -- drivers/net/ethernet/socionext/Kconfig | 4 +-- drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 - drivers/net/wireless/quantenna/qtnfmac/Kconfig | 2 +- drivers/remoteproc/Kconfig | 1 - drivers/scsi/hisi_sas/Kconfig | 2 +- drivers/spi/Kconfig | 12 ++-- drivers/staging/media/davinci_vpfe/Kconfig | 1 - drivers/staging/media/omap4iss/Kconfig | 1 - drivers/staging/vc04_services/Kconfig | 1 - drivers/tty/serial/Kconfig | 4 --- drivers/usb/gadget/udc/Kconfig | 4 +-- drivers/usb/mtu3/Kconfig| 2 +- drivers/video/fbdev/Kconfig | 3 +- sound/soc/bcm/Kconfig | 3 +- sound/soc/kirkwood/Kconfig | 1 - sound/soc/pxa/Kconfig | 1 - sound/soc/qcom/Kconfig | 6 ++-- 54 files changed, 58 insertions(+), 141 deletions(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index a7120d6211546949..9eaeed1fb237fa33 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -398,7 +398,6 @@ config SATA_DWC_VDEBUG config SATA_HIGHBANK tristate "Calxeda Highbank SATA support" - depends on HAS_DMA depends on ARCH_HIGHBANK || COMPILE_TEST help This option enables support for the Calxeda Highbank SoC's @@ -408,7 +407,6 @@ config SATA_HIGHBANK config SATA_MV tristate "Marvell SATA support" - depends on HAS_DMA depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \ ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST select GENERIC_PHY diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 4b741b83e23ff4de..3d27da7a430c0bc2 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -419,7 +419,7 @@ config CRYPTO_DEV_EXYNOS_RNG config CRYPTO_DEV_S5P tristate "Support for Sams
[PATCH/RFC 1/6] dma-mapping: Convert NO_DMA get_dma_ops() into a real dummy
If NO_DMA=y, get_dma_ops() returns a reference to the
non-existing symbol bad_dma_ops, thus causing a link failure if it is
ever used.
Make get_dma_ops() return NULL instead, to avoid the link failure.
This allows to improve compile-testing, and limits the need to keep on
sprinkling dependencies on HAS_DMA all over the place.
Signed-off-by: Geert Uytterhoeven
---
include/linux/dma-mapping.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 34fe8463d10ea3be..d78d7541f784875b 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -212,14 +212,14 @@ static inline void set_dma_ops(struct device *dev,
}
#else
/*
- * Define the dma api to allow compilation but not linking of
- * dma dependent code. Code that depends on the dma-mapping
- * API needs to set 'depends on HAS_DMA' in its Kconfig
+ * Define the dma api to allow compilation of dma dependent code.
+ * Code that depends on the dma-mapping API needs to set 'depends on HAS_DMA'
+ * in its Kconfig, unless it already depends on || COMPILE_TEST,
+ * where guarantuees the availability of the dma-mapping API.
*/
-extern const struct dma_map_ops bad_dma_ops;
static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
{
- return &bad_dma_ops;
+ return NULL;
}
#endif
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 4/6] mm: Add NO_DMA dummies for DMA pool API
Add dummies for dma{,m}_pool_{create,destroy,alloc,free}(), to allow
compile-testing if NO_DMA=y.
This prevents the following from showing up later:
ERROR: "dma_pool_destroy" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_free" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_create" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "dma_pool_destroy" [drivers/scsi/hisi_sas/hisi_sas_main.ko]
undefined!
ERROR: "dma_pool_free" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_create" [drivers/scsi/hisi_sas/hisi_sas_main.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_free" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_create" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
ERROR: "dma_pool_destroy" [drivers/mailbox/bcm-pdc-mailbox.ko] undefined!
Signed-off-by: Geert Uytterhoeven
---
include/linux/dmapool.h | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/linux/dmapool.h b/include/linux/dmapool.h
index 53ba737505df31c7..adeb5e56c3ad73a8 100644
--- a/include/linux/dmapool.h
+++ b/include/linux/dmapool.h
@@ -16,6 +16,7 @@
struct device;
+#ifdef CONFIG_HAS_DMA
struct dma_pool *dma_pool_create(const char *name, struct device *dev,
size_t size, size_t align, size_t allocation);
@@ -23,6 +24,17 @@ void dma_pool_destroy(struct dma_pool *pool);
void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
dma_addr_t *handle);
+void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t addr);
+#else /* !CONFIG_HAS_DMA */
+static inline struct dma_pool *dma_pool_create(const char *name,
+ struct device *dev, size_t size, size_t align, size_t allocation)
+{ return NULL; }
+static inline void dma_pool_destroy(struct dma_pool *pool) { }
+static inline void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
+ dma_addr_t *handle) { return NULL; }
+static inline void dma_pool_free(struct dma_pool *pool, void *vaddr,
+dma_addr_t addr) { }
+#endif /* !CONFIG_HAS_DMA */
static inline void *dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
dma_addr_t *handle)
@@ -30,14 +42,19 @@ static inline void *dma_pool_zalloc(struct dma_pool *pool,
gfp_t mem_flags,
return dma_pool_alloc(pool, mem_flags | __GFP_ZERO, handle);
}
-void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t addr);
-
/*
* Managed DMA pool
*/
+#ifdef CONFIG_HAS_DMA
struct dma_pool *dmam_pool_create(const char *name, struct device *dev,
size_t size, size_t align, size_t allocation);
void dmam_pool_destroy(struct dma_pool *pool);
+#else /* !CONFIG_HAS_DMA */
+static inline struct dma_pool *dmam_pool_create(const char *name,
+ struct device *dev, size_t size, size_t align, size_t allocation)
+{ return NULL; }
+static inline void dmam_pool_destroy(struct dma_pool *pool) { }
+#endif /* !CONFIG_HAS_DMA */
#endif
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 5/6] scsi: Add NO_DMA dummies for SCSI DMA mapping API
Add dummies for scsi_dma_{,un}map(), to allow compile-testing if
NO_DMA=y.
This prevents the following from showing up later:
ERROR: "scsi_dma_unmap" [drivers/firewire/firewire-sbp2.ko] undefined!
ERROR: "scsi_dma_map" [drivers/firewire/firewire-sbp2.ko] undefined!
Signed-off-by: Geert Uytterhoeven
---
include/scsi/scsi_cmnd.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index d8d4a902a88dedbc..6a123d1dd2f80624 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -171,8 +171,13 @@ extern void scsi_kunmap_atomic_sg(void *virt);
extern int scsi_init_io(struct scsi_cmnd *cmd);
+#ifdef CONFIG_SCSI_DMA
extern int scsi_dma_map(struct scsi_cmnd *cmd);
extern void scsi_dma_unmap(struct scsi_cmnd *cmd);
+#else /* !CONFIG_SCSI_DMA */
+static inline int scsi_dma_map(struct scsi_cmnd *cmd) { return -ENOSYS; }
+static inline void scsi_dma_unmap(struct scsi_cmnd *cmd) { }
+#endif /* !CONFIG_SCSI_DMA */
static inline unsigned scsi_sg_count(struct scsi_cmnd *cmd)
{
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 3/6] usb: gadget: Add NO_DMA dummies for DMA mapping API
Add dummies for usb_gadget_{,un}map_request{,_by_dev}(), to allow
compile-testing if NO_DMA=y.
This prevents the following from showing up later:
ERROR: "usb_gadget_unmap_request_by_dev"
[drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
ERROR: "usb_gadget_map_request_by_dev"
[drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
ERROR: "usb_gadget_map_request" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "usb_gadget_unmap_request" [drivers/usb/mtu3/mtu3.ko] undefined!
ERROR: "usb_gadget_map_request" [drivers/usb/gadget/udc/renesas_usb3.ko]
undefined!
ERROR: "usb_gadget_unmap_request" [drivers/usb/gadget/udc/renesas_usb3.ko]
undefined!
Signed-off-by: Geert Uytterhoeven
---
include/linux/usb/gadget.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 66a5cff7ee142d6a..b68e7f9b210be122 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -805,6 +805,7 @@ int usb_otg_descriptor_init(struct usb_gadget *gadget,
/* utility to simplify map/unmap of usb_requests to/from DMA */
+#ifdef CONFIG_HAS_DMA
extern int usb_gadget_map_request_by_dev(struct device *dev,
struct usb_request *req, int is_in);
extern int usb_gadget_map_request(struct usb_gadget *gadget,
@@ -814,6 +815,17 @@ extern void usb_gadget_unmap_request_by_dev(struct device
*dev,
struct usb_request *req, int is_in);
extern void usb_gadget_unmap_request(struct usb_gadget *gadget,
struct usb_request *req, int is_in);
+#else /* !CONFIG_HAS_DMA */
+static inline int usb_gadget_map_request_by_dev(struct device *dev,
+ struct usb_request *req, int is_in) { return -ENOSYS; }
+static inline int usb_gadget_map_request(struct usb_gadget *gadget,
+ struct usb_request *req, int is_in) { return -ENOSYS; }
+
+static inline void usb_gadget_unmap_request_by_dev(struct device *dev,
+ struct usb_request *req, int is_in) { }
+static inline void usb_gadget_unmap_request(struct usb_gadget *gadget,
+ struct usb_request *req, int is_in) { }
+#endif /* !CONFIG_HAS_DMA */
/*-*/
--
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: usb: uas: device reset most the time while enumeration- usb3.0
Am Montag, den 05.02.2018, 23:46 +0530 schrieb Tushar Nimkar: > Greg, > > I have cherry-picked 9 patches as follows. Those won't do you any good. Please test a) with 4.14 or 4.15 b) test on another host And tell me what read_capacity_16() does at USB2.0 speeds We need to determine whether error handling just works better at lower speed or high speed triggers the error. And with a current kernel if possible at all. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: udc: change comparison to bitshift when dealing with a mask
On Tue, Feb 06, 2018 at 09:50:40AM +0100, Wolfram Sang wrote: > Due to a typo, the mask was destroyed by a comparison instead of a bit > shift. > > Reported-by: Geert Uytterhoeven > Signed-off-by: Wolfram Sang > --- > Only build tested. Add. note: according to 'git grep', this macro is unused currently, so no regression. signature.asc Description: PGP signature
[PATCH] usb: gadget: udc: change comparison to bitshift when dealing with a mask
Due to a typo, the mask was destroyed by a comparison instead of a bit
shift.
Reported-by: Geert Uytterhoeven
Signed-off-by: Wolfram Sang
---
Only build tested.
drivers/usb/gadget/udc/goku_udc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/goku_udc.h
b/drivers/usb/gadget/udc/goku_udc.h
index 26601bf4e7a935..70023d40107997 100644
--- a/drivers/usb/gadget/udc/goku_udc.h
+++ b/drivers/usb/gadget/udc/goku_udc.h
@@ -25,7 +25,7 @@ struct goku_udc_regs {
# define INT_EP1DATASET 0x00040
# define INT_EP2DATASET 0x00080
# define INT_EP3DATASET 0x00100
-#define INT_EPnNAK(n) (0x00100 < (n)) /* 0 < n < 4 */
+#define INT_EPnNAK(n) (0x00100 << (n))/* 0 < n < 4 */
# define INT_EP1NAK 0x00200
# define INT_EP2NAK 0x00400
# define INT_EP3NAK 0x00800
--
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
